User:Pmasson

Latest revision as of 03:18, 19 April 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.

Patrick is an active user of a variety of open source software applications--from the desktop to the enterprise--and has contributed to the Sakai Project, Moodle, uPortal, and a variety of other open source projects specific to higher education.

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 the various components of Sugar and even the tools used to develop/manage Sugar (e.g IRC). Other information included in a ticket include the status of the project, type, owner, etc.
• Date of SugarLabs' last commit:
  • Feb 5, 2017
• Relationship between release cycle and roadmap:
  • The roadmap is updated at the beginning of each release cycle.

The Sahana Eden Project

• Summary of community information:
  • Developers' link provides information on how to contact/communicate (i.e. the mailing list), training resources, a development environment (and documentation), developer guidelines and a CLA.
  • Testers' link provides three types of QA needed: technical issues related to the application itself; installation/integration issues, and; test cases from non-technical users.
  • Designers
• Sahana vs. Sugar Labs tracker page:
  • Both use Trac (again, I'll note confusion over use of Github with Sugar).
• Information available for each ticket:
  • Ticket number, summary of the issue, component affected, version of Sahana affected, priority of the issue, type of issue, owner of the issue, status, who created the issue/ticket.
• Date of last commit (an update of the repository
  • Mar 5, 2017
• Information about Sahana Eden's release cycle and roadmap:
  • Next release is 0.9.0 Medway, which is 92% complete.
  • 1.0 Avon is also under development and is 73% complete.
  • The page includes a variety of new and enhanced features as well as bug fixes.

FOSS Field Trip (Activity)

Part 1 - Github

1. Number of repositories in "education": 12,071
2. Information related to "Commits": Commits per week, and per day of week.
3. Number of repositories in "humanitarian": 285
4. The last updates for HTBox/crisischeckin: Latest commit Aug 7, 2016; last issue opened, Oct 21, 2016; last pull request, opened Nov 4, 2016, last wiki update, Jun 17, 2016.
5. Number of repositories in "disaster management": 139

Part 2 - OpenHub

1. Number of projects on OpenHub: 3470
2. KDE Education code located on GitHub? No
3. Number of similar projects: 10
4. OpenHub information provided about projects: Summary, stats (commits, contributors, language(s), timeframes, etc.), organizational (KDE) and participant information.
5. Number of repositories in "humanitarian": aprox. 40 (assuming 10/page)
6. Number of repositories in "disaster management": 60 (assuming 10/page)
7. Why do so many projects do not have activity information available? Activity is based on current development, many projects are stable and archived, but not under active development by their communities.
8. Information about "Organizations" on OpenHub: Dashboard with stats on various activity by organization: volume, ranked order, new orgs, stats by sector.
9. Last commit listed by OpenHub for OpenMRS Core: 18-August-2016
10. Last commit listed by GitHub for OpenMRS COre: 22-March-2017
11. Reason why these sites have different information: OpenHub is a reference resource, "offering analytics and search services for discovering, evaluating, tracking, and comparing open source code and projects." Github is a version control platform for managing distributed software development efforts and housing source code. The two services provide different services. Github provides services to develop projects, OpenHub "is not a forge" but rather provides services to assess/compare projects.
12. Benefits of using both GitHub and OpenHub to search for a project: Allow potential contributors--or even those looking to start a project--to find existing efforts; assess the "maturity" of a project; review the profiles (experience, activities, skill sets) of contributors working across projects; assess license compatibility within and across projects;
13. Drawbacks of using both GitHub and OpenHub to search for a project? Black Ducks analytics, search algorithms and data are proprietary and not *open* for review.

Project Evaluation (Activity)

Intro to Copyright and Licensing (Activity)

1. Identify the license for the following projects:
   • OpenMRS: Mozilla Public License, version 2.0
   • Apache Fineract: Apache License v2.0
   • regulately-back-end: None
2. “Cans” the “cannots” and the “musts”:
   • Mozilla Public License, version 2.0:
     • Cans - Commercial Use, Modify, Distribute, Sublicense, Place Warranty, Use Patent Claims
     • Cannots - Hold Liable, Use Trademark
     • Musts - Include Copyright, Include License, Disclose Source, Include Original
   • Apache License v2.0
     • Cans - Commercial Use, Modify, Distribute, Sublicense, Private Use, Use Patent Claims, Place Warranty
     • Cannots - Hold Liable, Use Trademark
     • Musts - Include Copyright, Include License, State Changes, Include Notice
   • regulately-back-end: None (defaults to "All rights reserved")
3. Comfortability in contributing code to projects and why (or why not).
   • Mozilla Public License, version 2.0 (OpenMRS): Yes, I am fine with permissive licenses and like that patent claims are addressed. I am also fine with weak copyleft licenses, indeed copyleft as well. I guess the project trumps the license for me (but then again, I don't work with/for proprietary commercial software vendors.
   • Apache License v2.0 (Apache Fineract): Again, I am fine with permissive licenses and like that patent claims are addressed and am not a zealot regarding copyleft.
   • Non-licensed / All rights reserved (regulately-back-end): No. Not only would I not want to submit code to a project that is not licensed, as my code would be assigned to the copyright holder (unless they agreed to adopt a license of my own attached to my original work), I would not even be legally allowed to copy/modify/distribute the project's code without the copyright holder's consent. The lack of a license, to me, highlights the immaturity of the project and ignorance of the project owner/copyright holder--a sign that the project might not be worth engaging with. Even if I could come to an agreement over my contributions, the project will never develop a community of contributors as no one is allowed to use it. Open source licenses provide "permission first" and thus foster use, modification, distribution and collaboration. Without a license none of this can happen and the project is crippled.

FOSS in Courses 1 (Instructors)

Course description and one or two possible activities that students can complete as part of the course: The course focuses on the principles and practices of open source development and communities. While many of those involved in, or interested in, starting or participating in an open source project may have the technical abilities and experience to develop software, they may not appreciate the differences in how open source projects are managed, compared to traditionally run efforts. This course provides students with guiding principles to promote community, collaboration and contribution, recognizing the organizational differences and operational practices between remote, distribute and decentralized models and traditional approaches where resources are managed and controlled centrally. Activities

• Identify common communications platforms across projects/communities
• Identify common roles for individuals engaged in open source communities of practice
  • Identify common activities within those roles

Intro to Bug Trackers (Activity)

1. Open a browser and go to the GNOME Accessibility Bugs
   • Completed
2. Column definitions:
   1. ID: Ticket number, unique identifier
   2. Sev: This indicates how severe the problem is - from blocker ("application unusable") to trivial ("minor cosmetic issue"). You can also use this field to indicate whether a bug is an enhancement request.
   3. Pri: The bug assignee uses this field to prioritize his or her bugs. It's a good idea not to change this on other people's bugs.
   4. OS: The computing environment where the bug was found.
   5. Product: A "Product" has one or more Components in it.
   6. Status & Resolution: These define exactly what state the bug is in - from not even being confirmed as a bug, through to being fixed and the fix confirmed by Quality Assurance. The different possible values for Status and Resolution on your installation should be documented in the context-sensitive help for those items.
   7. Summary A one-sentence summary of the problem.
3. How you discovered the definitions:
   • Went to the "help" section: https://www.bugzilla.org/docs/4.4/en/html/bug_page.html
4. Order in which the bugs are initially displayed:
   • Based on the search query. In this example, "UNCONFIRMED, NEW, ASSIGNED, REOPENED, NEEDINFO"
5. Colors used when describing a bug (red, gray, black)?
   • Importance, critical/blocker, enhancement, normal.
6. Select a bug: 317764
   1. Bug was submitted: 2005-10-02 19:58
   2. Recent discussion about the bug: 2016-06-30 03:34:02
   3. Is the bug current? Yes
   4. Is the bug assigned? To whom? gnome-themes-standard-maint
   5. Describe what you would need to do to fix the bug: Close the ticket as the issue is no longer relevant.

Intro to GitHub (Activity)

Correctly completing the activity on GitHub: forked, edited, pulled...

FOSS in Courses 2 (Instructors)

An existing course syllabus is available here.