User:TWahls

Bio

Tim Wahls is an Associate Professor of Computer Science in the Department of Mathematics and Computer Science at Dickinson College. The computer science program at Dickinson currently has 3.5 faculty members and 67 students as declared majors.

Dr. Wahls's research interests are in programming languages and formal software engineering methods, currently focussed on the development of code generation tools for B and Event-B. Three of these tools have been incorporated into open-source projects, notably the EventB2SQL tool, which generates Java, PHP and Android applications from Event-B models. He is also the project administrator and lead developer for FARMDATA, an open-source record keeping system for organic produce farms.

IRC Assignment

Answers to IRC questions

• The interactions seems to be very similar to that found in an (informal) face-to-face meeting - free flowing discussion with light direction from the moderator.
• The communication is relatively linear and informal. There is a mix of one-to-one and one-to-many (at times verging on many-to-many) discussion.
• I don't really observe any terms with meanings beyond the ordinary English ones (other than the obvious MeetBot commands).
• The tone of the conversation is very friendly and supportive.
• Answer to bonus question: looks like only the moderator can issue MeetBot commands?

Summary of IRC monitoring

I monitored the #OpenMRS IRC feed on April 30 and May 1. There was a little discussion of how to create a user ID on the OpenMRS talk page, and some announcements from the OpenMRSBot and the GitHub page for the project. The discussion about creating a user ID was a bit chippy on the part of one of the users - definitely less supportive and friendly than the Mousetrap example that we were given.

Answers to Guided Tour Questions

Sugar Project

• Roles most applicable to students would include: developer, translator (we have many international students) and content writer (many of our students are double majors and could likely contribute content in a non-technical area at a level appropriate for children). These roles are all rather different: development is straight up computer science/software engineering, translation relies on fluency in multiple human languages, and writing content would not require technical or foreign language skills.
• Bugs are reported by submitting a bug report to the bug tracker system. Bugs become work tickets. It appears that a user must register for an account in order to submit a bug report. Ticket types include defect, enhancement and task. The information available for each ticket includes ticket number, summary, status, owner, type, priority and milestone.
• The Sugar code repository is web-based, as evidenced by the fact that I can browse the code via my web browser.
• The Roadmap lays out a schedule for releases and freeze points, including tickets considered for the release. I think this is related to including features requested via the tickets in the release, and "freezing" addition of new features etc. while those to be included in the next release are completed and tested.

Sahana Project

• Sugar does not have a tester role - I assume this is subsumed as part of the developer role there. The developer roles otherwise seem similar in both projects. The designer roles are a bit different in that designers in Sugar are contributing graphic design elements to the educational games under development (as well as the website), while designers in Sahana seem to do more traditional website and application graphic design. Sahana does not have a content writer role, presumably because the application manages specific content for different users.
• The information available in the Sahana bug tracker is similar to that in Sugar, although the interface is different in that Sahana bugs are browsed via reports that group bugs together by title (essentially a category).
• Under the "Active Tickets" link, the types are defect/bug, enhancement, task and documentation - a superset of those found in the Sugar bug tracker. The information available for each ticket includes ticket number, summary, component, version, priority, type, owner, status and creation date.
• Sahana does use a common repository, hosted at github. I would categorize this as web-based, since code for any github project can be browsed via a web-browser.
• The Sahana Roadmap describes "milestones", which appear to coincide with releases? Each milestone includes a categorized list of features to be completed, as well as a summary of included tickets and their status.

Blogging activity

My brand new blog is now available here!

HFOSS Activities/Assignments

Possible HFOSS activities/assignments:

1. Installing the developer version of OpenMRS and getting it to run successfully

• this is an obvious one, but certainly a necessary prerequisite for doing anything with the code!
• requires installing numerous tools/packages that will almost certainly be unfamiliar to students
• excellent documentation is available here: https://wiki.openmrs.org/display/docs/Step+by+Step+Installation+for+Developers

2. Identifying a possible OpenMRS feature to work on

• find the OpenMRS technical road map
• review the list of features to be included in an upcoming release
• attempt to quantify the relative difficulty/approachability of these features, and choose one for further investigation
• attempt to locate specific region(s) of the code that are relevant to the chosen feature

Bug Tracker Assignment

Bug Reports

2. Meaning of Columns in Bugzilla (and range of possible values):

• ID: identification number
• Sev: severity (does not appear in the report)
• Pri: priority (does not appear in the report)
• OS: Operation System (does not appear in the report)
• Product: the product (application) that has the bug. Some possible values: banshee, gnome-nettool, metacity, ...
• Status: status of the bug. Some possible values: NEW, UNCO (unconfirmed), CONFIRMED, RESOLVED, IN-PROGRESS, ...
• Resolution: how the bug was resolved. Some possible values: FIXED, INVALID, WONTFIX, DUPLICATE, WORKSFORME
• Summary: a summary description of the bug

3. Using the bug report table itself, the search descriptions and the reports link.

4. Bugs are initially ordered by ID number.

5. I can not find any pattern or meaning in terms of which reports are shaded.

6. Red appears to indicate a critical bug, gray an enhancement and black a normal bug.

7. Details of a bug that I might be able to fix:

• submitted: 12/6/2009
• last discussion: 4/25/2011 (not recent)
• whether this bug is current is a matter of definition. It hasn't been resolved and so is current in that sense, but no work appears to have been done on it recently.
• the bug is assigned to aisleriot-maint
• fixing this bug entails replacing hard-coded cursors in aisleriot (solitaire card game) with gdk cursors. From the discussion, the preferred fix seems to be updating the cursor theme spec (?) to make better cursors available for a wide variety of applications. So this fix is harder than it appeared at first glance.

8. Repeating 7 with a different bug:

• submitted: 3/02/2015
• last discussion: 3/14/2015 (not overly recent)
• whether this bug is current is a matter of definition. It hasn't been resolved and so is current in that sense, but no work appears to have been done on it recently.
• the bug is assigned to Clocks maintainer(s)
• to fix this bug, I would add keyboard shortcuts for navigating the menu in the stopwatch application. So this is really more of an enhancement than a bug fix.

Collective Reports

3. 273 bugs were opened in the past week, and 293 were closed.

4. The general trend was (slightly) towards more open bugs - although not significant in the context of 48002 total reports overall.

5. The top three bug closers were: Michael Gratton (37), Tim-Philipp Müller (23) and Matthias Clasen (19). This tells us who is actively contributing to the project code.

6. The top three bug reporters were: Bastien Nocera (15), Allan Day (8) and Christoph Reiter (5). There is no overlap among the top three in the bug closers list, but 4 names are in common in the top 15 lists.

7. The top three contributors of patches were: Bastien Nocera (25), Michael Olbrich (17) and Sebastian Dröge (15).

8. The top three reviewers of patches were: Sebastian Dröge (35), Tim-Philipp Müller (21) and Bastien Nocera (19). Three names appear on both the patch contributor and reviewer lists, and both of these lists overlap significantly with the bug closers list - which is logical in the sense that contributing a patch would be one way of closing a bug.

11. The majority of braille bugs were in class "normal".

12. Reports can be generated by classification, component, resolution, product and status.

FOSS in Courses 2

Activity 1: Installing the developer version of OpenMRS and getting it to run successfully (in-class activity)

1. Learning Outcomes:

• familiarity with VirtualBox and installing virtual machines
• familiarity with git and basic git configuration

2. Prerequisite Knowledge:

• working from the command line (Linux)
• some idea of version control (previous git experience ideal)

3. Time Requirements:

• instructor: likely several full work days. I've already spent a couple hours on this with minimal progress.
• student completion: hopefully 1 class/lab period (2 hours) if I can give them sufficient resources
• calendar time: first week of class (1 week)
• synchronization: none required

4. HFOSS Community Input:

• I've already gotten some advice on best approaches for this (use a VM) from a POSSE member

5. Contribution Back to HFOSS Project:

• none

6. Assessment/Grading Approach:

• none. This is a prerequisite for doing anything, so its an ungraded in-class assignment that I would help students with as much as necessary.

7. Questions/Concerns:

• How difficult is it to install VirtualBox?
• How difficult is it to install a VM on VirtualBox?
• Will this approach work across different OSes and hardware configurations?
• Are there performance concerns with using a VM?

8. Stumbling Blocks/Barriers:

• Getting permission to set this up in labs if necessary.
• What if students don't have their own laptops?

Activity 2: Identifying a possible OpenMRS feature to work on (homework)

1. Learning Outcomes:

• familiarity with OpenMRS developer documentation
• familiarity with the OpenMRS technical roadmap

2. Prerequisite Knowledge:

• some basic understanding of the FOSS development process (releases, how to contribute)
• a basic understanding of bug/issue trackers

3. Time Requirements:

• instructor: could be minimal (just providing students a URL), but should be more extensive, as a good deal of research into OpenMRS would be useful for evaluating student work.
• student: probably 5 - 8 hours outside of class researching and comparing various bugs/features.
• calendar time: a week?
• synchronization with community: none

4. HFOSS Community Input:

• it would be appropriate for students (and the instructor) to reach out for advice/information on accessibility of various features/bugs.

5. Contribution Back to HFOSS Project:

• a more detailed evaluation of the approachability/difficulty of various bugs/features could be useful to the community, except that students wouldn't really have the background knowledge of OpenMRS to evaluate well. But I could certainly imagine them adding this information as comments on bugs on the introductory tickets page: https://issues.openmrs.org/browse/TRUNK-1931?filter=10068

6. Assessment/Grading Approach:

• this would be a team activity
• each team would submit a short (1 - 2 page) evaluation of their chosen bug/feature including difficulty level and relevant source code locations (if students can determine them)
• reports would be graded on writing style, completeness, thoroughness of research performed and correctness of difficulty assessment.
• if students placed information from their reports as comments on the introductory tickets page, then any community response to those comments could be factored in to grading.

7. Questions/Concerns:

• Would students be able to get the basics of OpenMRS and FOSS development quickly (in the first few weeks of the semester)?
• Would students be overwhelmed by the complexity of OpenMRS?
• Could students gather enough information to make an informed assessment in one week?

8. Stumbling Blocks/Barriers:

• time required
• amount of prerequisite knowledge needed
• student enthusiasm for this application area