User:Pmasson

Revision as of 03:35, 6 March 2017

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:

• LinkedIn
• Twitter
• Personal Blog

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:
  • (NOTE: while this tutorial points to Simon Tatham's "How to Report Bugs Effectively", the Sugar bug tracker points to a differnt wiki page, "BugSquad/Bug Report." I am assuming you're interested in how to communicate an issue, not the nuts and bolts of how to create and submit a ticket in Trac.)
  • (NOTE: Also, the instructions on "Submit Bugs/Problems states bug reports should be posted to GitHub, while this tutorial points to Trac. Also the number of issues and activity in Trac compared to Github makes me think that Trac is in use now, and a migration to Github is underway, or that this tutorial is out of date/incorrect)"
  • 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:
  • Sugar seems to be using two tools for bug/issue reporting/tracking, GitHub's "issues" feature for their website and their own instance of Trac for the Sugar platform
  • Issues specific to GitHub seem to be specific to the Sugar website, and most repos have 0 issues. Sugar's use of Github seems to be dedicated to code distribution and related content/activities (e.g. documentation, issues with builds, etc.)
  • The issues in Trac include: