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.