User:Pmasson
Patrick Masson currently serves as the General Manager and a Board Director for the Open Source Initiative (OSI). Prior to the OSI Patrick worked in higher education technology for over twenty years: first as a Programmer Analyst at The University of California Los Angeles (UCLA), and Director of the UCLA Media Lab, then Chief Information Officer at The State University of New York, College of Technology at Delhi (SUNY Delhi), and most recently, as the Chief Technology Officer for UMassOnline within the University of Massachusetts' Office of the President.
In addition to his role with the OSI, Patrick also an Adjunct Professor at the University at Albany, teaching Open Source Principles and Practices within the College of Engineering and Applied Sciences' Department of Informatics.
He served on the Jasig Foundation's Board of Directors, and is currently on the Apereo Foundation's Advisory Council as well as Brandeis University's Graduate Professional Studies Advisory Board. He is the co-founder and current chair of the Educause Constituent Group on Openness. Patrick was also elected to his local Board of Education in 2014.
For fun, Patrick plays in a variety of ice hockey leagues.
Links and references:
POSSE Activities
Intro to FOSS Project Anatomy (Activity)
The Sugar Labs Project
- Roles most applicable for your students: Content Writer, People Person, Developer, Designer, and Translator.
- Commonalities/differences across roles: While each role, and the tasks undertaken, require different/unique skill sets, each participant will need to undertake their activities in an open, transparent, collaborative way. Developers and designers, translators and community managers (People Persons), will all need to communicate, share, etc. The outputs may be different, but the principles and practices that generate those outputs are the same. These roles also require individuals to accept feedback, with an honest and receptive manor, accepting the the project's success and community are more valuable than any one idea, contribution, etc.
- General process for submitting a bug:
- Visit Sugar's relevant repo on GitHub (join GitHub if needed)
- Provide the developers with enough detailed instructions so that they can replicate the issue for themselves.
- Describe what went wrong (what you expected, vs. what was observed).
- Include any error messages
- You can include your own diagnosis, but always include the symptoms you observed as well.
- Be responsive if the developers follow up, be patient if they do not.
- Write clearly, be precise.
- Types/categories of tickets listed & information available for each ticket:
