User:Mlang

Matthew Lang is an Assistant Professor of Computer Science at Moravian College in Bethlehem, PA. Prior to Moravian, Matt received his PhD from The Ohio State University in 2009. His areas of interest are distributed algorithms, parallel computing, and computer science education.

Part A: Introduction to IRC

Conversation reflection:

• How do people interact? In short, succinct messages.
• What is the pattern of communication? In a meeting, chat participants focus on a single thread of conversation (as opposed to maintaining several threads, as they do when not meeting).
• Are there any terms that seem to have special meaning? Yes, the commands to the bot.

Part A: Project Anatomy

Sugar Labs:

• Community: The three teams have differing focuses and have non-intersecting sets of members. The activity and documentation teams are more outward facing and therefore have more information about how to participate in their missions.
• Tracker: There are three categories of tickets: immediate priority, urgent priority, and non-blocker bugs. All tickets except for the latter are further sub-divided by severity (blocker, critical, and major). Each ticket contains information about relevant versions, the component that the ticket applies to, its status, who is responsible for the ticket, and who reported it.
• Repository: The project hosts its own repository.
• Release cycle/Roadmap: At the beginning of each release cycle, the roadmap is updated for that release cycle.

Sahana Eden:

• Community: The Eden project seems to have more loosely-defined teams and roles for those teams than the Sugar Labs project. The development page has a nice list of tasks to work on.
• Tracker: Tickets are divided into three categories: critical, major, and minor. Information for each ticket is the same as the Sugar Labs project.
• Repository: The project uses github to host its repository.
• Roadmap: The Sugar Labs project seems to have a much more clearly defined process for its roadmap/release cycle (or at least more documentation).

Part B: FOSS in Course Planning I

One of the nice things about the OpenMRS project is its clear documentation about getting started as a developer on the project. In addition, the core technologies and design of the application are also very well documented. I plan on integrating HFOSS into a software engineering capstone course (much like Heidi's). I imagine beginning the class with assignments similar to the "FOSS field trip" followed by a self-guided exploration of the documentation of OpenMRS. I could also imagine an assignment where different groups take one of the OpenMRS bugs categorized as "introductory" and write a summary describing the issue and a plan for addressing it (perhaps culminating with a presentation to the class). This could then dovetail into an assignment where groups carry out their plans (and then report back to the class).

Part B: Project Evaluation

OpenMRS Evaluation: File:Lang openmrs.xlsx

Part C: Bug Tracker Activity

Part 1: Field definitions:

• ID: a uid for the issue
• Sev: the severity of the issue (domain: blocker, critical, major, normal, trivial, enhancement)
• Pri: the priority of the issue (domain: immediate, urgent, high, normal, low)
• OS: the operating system that the bug/issue was found on
• Product: the component/application that the bug/issue was found on
• Status: the state that the issue is in (domain: unconfirmed, new, assigned, needinfo, reopened, resolved, verified, closed)
• Resolution: the disposition of the issue at its resolution (domain: fixed, duplicate, wontfix, notabug, notgnome, incomplete, invalid, obsolete)
• Summary: a brief (one line) description of the issue

I discovered the information by initiating a new bug and reading the documentation for the bug tracker (A Bug's Life Cycle). They are initially ordered by priority and the shading is related to the severity of the bug (gray = enhancement, red = critical).

Part 2: There were 423 reports opened and 481 closed last week (58 more were closed than open). The top bug closers and bug reporters had only a small intersection. It seems as though the top closers are developers or are responsible for vetting commits to the project whereas the reporters are developers, testers, and users who may contribute patches. This seems to be confirmed by the correlation between the list of the top submitters of patches and the list of bug reporters and the list of top patch reviewers and bug closers. The report generator tool is very flexible.

Part C: FOSS in Course Planning II

1. Identify some possible learning outcomes that should be fulfilled with the activities/task.
2. Describe any pre-requisite knowledge needed to complete the activity.
3. Estimate the time required for instructor prep, for student completion and elapsed calendar time. Are you going to have to synchronize your activity with the community or can the activity/topic be covered independent of the HFOSS community schedule?
4. Think about possible input required from the HFOSS community. How much input is required and what kind?
5. If the result of the activity is contributed back to the HFOSS project, describe the contribution and its usefulness.
6. Describe the assessment/grading approach - What will the basis for grading be? Will this be a team activity or individual? Is there a role for the HFOSS community in helping assess student work? For instance, must the work be committed or otherwise accepted by the community?
7. List any questions or concerns that you have about the activity/task.
8. List any stumbling blocks or barriers to carrying out the activity/task.