User:Mlang

Revision as of 13:32, 29 May 2013

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).