User:TWahls

(Difference between revisions)
Jump to: navigation, search
(adding TOC)
Line 46: Line 46:
 
* attempt to quantify the relative difficulty/approachability of these features, and choose one for further investigation
 
* 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
 
* 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.

Revision as of 15:43, 7 June 2016

Contents

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

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.

Personal tools
Namespaces
Variants
Actions
Events
Learning Resources
HFOSS Projects
Evaluation
Navigation
Toolbox