User:Scrain

Revision as of 18:56, 10 November 2014

Dr. Steven P. Crain

I am an Assistant Professor in Computer Science at the lovely SUNY Plattsburgh [1] nestled in the Champlain Valley at the base of the Adirondack Mountains. When I am not working with students, I am often seen hiking in the mountains or sliding silently along a ski trail. (OK, so really I am seen in a jumbled up mess at the bottom of a small hill....) I am an aspiring 46er [2] and have hiked 12 of the 46 high peaks in the Adirondacks so far, though I am aiming to add 4 more this week.

My research area is machine learning, with a special interest in humanitarian applications. I often work with the Diabetes Hands Foundation [3] on search and recommendation projects. As a rule, I would rather focus on involving undergraduate students in my work than on churning out publications.

Notes on Participation in HFOSS

Hiking Computer Science Blog

IRC

How do people interact?

The interactions are informal, productive and collegial.

What is the pattern of communication?

The meeting focuses on one person at a time, but everyone chimes in with whatever will be helpful, either for solving a problem the focal person is facing or to build community. Normally the post is understood to be directed to the focal person, but a specific person can be addresses if they raise a point that warrants discussion.

Are there any terms that seem to have special meaning?

There are many common software development terms (e.g. VM, UML). Beyond that, "lab" may have special meaning.

Can you make any other observations?

This is definitely a productive working meeting. They tackle one issue at a time, and try to either work through whatever is blocking as a group or at least point the person in a productive direction. When issues are more work than they are worth, they table the issue and find more productive things to work on.

Summarize your observations of #mifos

I found the IRC channel easily using a web search for "mifos freenode." There are 1 or 2 people hanging out on the channel, but no discussion going on at present. The channel topic indicates that the channel is logged, but the link to the log goes to a non-responsive server. The Internet Archive [4] has record of an IRC session log from 2010, but the log itself did not get archived.

Summarize your observations of #openmrs

Given that #mifos was a flop, I also looked at #openmrs. This channel has a bunch of automatic updates whenever anyone starts working on a task or commits a change. Also, the result of automatic builds gets logged to the channel. People generally start conversations by saying "hi" to the person they need to talk to. In one conversation, someone was concerned that a design decision another made might not be wise long-term. He asked if the decision might be bad in the future. A collegial conversation proceeded in which they worked out the best plan and figured out who would implement it. Other conversations revolved around figuring our how to migrate features from one release to another and making arrangements to work together on particular tasks at a convenient mutually agreeable time.

Sugar Labs

What is unique about each Sugar Labs team?

Activity Team

The activities team is trying to foster development of shared activities. They have two coordinators and a large number of contributors listed on their contacts.

Development Team

The development team is responsible for the code and releases. They currently have a core of key people, but are looking for someone who can help coordinate them.

Documentation Team

The documentation team is producing documentation, including technical docs, videos and tutorials. Their contacts list two editors, one providing mentoring to new people and one helping to coordinate efforts.

Tracker

The tracker tracks enhancements, defects and tasks. For each issue, the tracker provides metadata (status, who opened it, when, who is watching it, which part of the project is effected, etc) a description of the issue, history of discussion about the issue and attachments that help explain it better.

Repository

Sugar labs uses the common repository hosted by Git at [5].

Release Cycles

Sugar labs is a large project with a lot going on. They organize the work on the many aspects around an explicit release cycle for the whole project. At the begining of each cycle, each team updates its roadmap to document what work they will do and what the relevant local mile stones and deadlines need to be to make the release cycle deadlines.

Sahana Eden

Community

This project is more organized in its approach in comparison with Sugar Labs. For example, developers are required to take some training and sign agreements before commencing. The public persona is also less personal, focusing more on the team identities than the individuals who lead them.

Developers

There are a lot of hoops to being a developer, including taking technical training and signing license agreements.

Testers

Less organized, you just have a manual to read through and follow the testing procedure. If you find any bugs, you submit them like ordinary bugs from anybody using the project. Not clear how to get good test coverage without knowing who is testing and what they are testing.

Designers

Potential designers are given guidelines on the ideal image of the sites, and can submit suggestions on how to improve the site to be more usable and attractive.

Tracker

How is the information here different than the information found on the Sugar Labs tracker page?

Instead of a form for customizing the list of issues to display, there are a set of prefabricated flavors of the report. The issues have less detail about how they relate to the project structure and do not have support for attachments. Each issue is assigned to a person who is responsible for the fix.

Click the Active Tickets link. Indicate the types/categories of tickets listed on this page as well as the information available for each ticket.

Types include defect/bug, documentation, enhancement, task. Each issue has a number, owner, description, status, time created, history, associated component, version, severity.

Repository

This is also hosted on Git, at [6].

Release Cycle

The release cycle is planned around completing certain selected functionality instead of planning for releases at certain times. The next release was planned to be done 3 years ago, but there is still work to go. The next cycle is planned out as well, and the following cycle is just sketched out.

Field Trip

Field Trip

Project Evaluation: Mifos

Mifos Evaluation

Getting Involved: OpenMRS

I had thought Mifos would be interesting, but I think OpenMRS will work better for me pedagogically. I am interested in:

• incorporating some of my research results in personalized recommendation of resources specific to patients.

• adding data mining integration to publicly available data, especially the FDA adverse drug events data. I am especially interested in this having some personal experience with the consequences of doctors not having a good way to study this data in the context of a specific patient.

• testing and documentation.

Course Applications

For my software engineering course, I liked the Heidi Ellis's Case Study using a FOSS project as a running project in a software engineering course. I am thinking that OpenMRS could play an excellent role in this course, giving students a chance to: figure out what a component in a complex software project does and document it, with an audience of developers (e.g. UML diagramming) or users; perform tests; write automated tests. I might also be able to use it in the section on using revision control systems, but I would need to make a local repository they could mess around in.

For my data mining course, I generally give a large project that the class as a whole tackles. For this to work, I need something that can be broken into about 5 components that different groups of students can work on. I think that my idea of adding support for the adverse drug events data would work very well for that. One group of students can figure out how OpenMRS stores data, and how best the Adverse Event data should be incorporated into the existing database schema. Another group can work on the import itself, including parsing and cleaning the data and converting it into a format that integrates nicely with OpenMRS. Another group can work on extracting data about a specific patient for a personalized view of the adverse events. Another group can focus on mining the data given that other groups have imported it and provided an appropriate model of the target patient. The last group can manage the project and handle integration issues with the other teams.

I am also wondering about using OpenMRS a little in my computer security course. It could be a good example of an application with strict legal and ethical privacy and auditing constraints. I don't want to make that too strong a component of the course yet, because I am really hoping to not redesign this course quite yet....

Bug Trackers

Part 1

I have used many different issue trackers over the years, so most of this I just knew. To get the values in use I just sorted on a particular column. When I wasn't sure, I looked at an example ticket with the uncertain field value to see what was going on with it. For each field, I found a link to a page explaining the significance of the possible values.

The bug list is initially sorted by status.

Bugs that are trivial or enhancements are greyed out, since they are not really things needing attention in the same way as other bugs. Red is used to indicate blocking or critical issues.

• ID: The identifier for a specific bug.
• Sev: The severity
  • Blocking, this bug is so serious it is preventing important development activities.
  • Critical, essential for correct operation of the product
  • Major, a bug affecting core functionality
  • Normal, a bug affecting ordinary functionality
  • Minor, a bug affecting peripheral functionality
  • Trivial, a bug that does not really make an important difference, like a typo
  • Enhancement, proposed new functionality
• Pri: The priority of the bug.
  • Low: Low priority
  • Normal: Normal priority
  • High: High priority
  • Urgent: Urgent priority
• OS: Which operating system ports exhibit the bug. I suspect that more bugs are really ALL than are marked that way.
  • All: All operating systems exhibit the bug.
  • Windows
  • Mac
  • Solaris
  • Open Solaris
  • Linux
  • other: Some other operating system.
• Product: which module contains the bug.
  • Aisle Riot
  • at-spi
  • atk
  • balsa
  • banshee
  • baobab
  • bjiben
  • caribou
  • cheese
  • clutter
  • clutter-gtk
  • conduit
  • congolmerate
  • devhelp
  • dia
  • doxygen
  • ekiga
  • empathy
  • epiphany
  • evince
  • evolution
  • f-spot
  • gconf editor
  • gdm
  • gedit
  • And many, many others!

• Status: how the work on the bug is progressing
  • Needinfo: cannot fix this without more information
  • Reopened: we thought we had that fixed....
  • Assigned: somebody is working on it.
  • New: just been added, nobody has looked at it seriously yet.
  • Unconfirmed: Not sure what this means. Maybe somebody thinks they fixed it, and is waiting for independent testing? No... docs say that nobody has independently confirmed that the bug is real.

• Resolution: Not showing up, because it is by default only showing unresolved bugs. In general, it is blank until somebody fixes it, then goes to RESOLVED.

• Summary: A brief, user-created description of the issue.

Specific Bugs

I took a look at bug 381153, which relates to correctly reporting the reading direction of text that includes multiple languages, e.g. English reads left to right and Hebrew or Arabic read right to left. It is important that accessibility software know the proper sequence of characters.

• Identify when the bug was submitted: 2006-12-01 05:34:21 UTC
• Identify if there has been recent discussion about the bug: Yes, although this is an older bug, it was discussed just a month ago, noting that the solution is different now and the old proposed patch is obsolete.
• Is the bug current? Yes.
• Is the bug assigned? To whom? Technically yes, it is assigned to the mailing list gtk-bugs.
• Describe what you would need to do to fix the bug.

In order to fix the bug, I would first need to install a gtk+ application and some accessibility software (probably a screen reader). This would allow me to verify that the bug exists and understand better exactly how it manifests. Next, I would need to examine the screen reader code to see how it is using the text direction attribute and examine the existing gtk+, gtkpango code and the patch that was submitted for consideration with the original bug report. Once I understood how the code works and how it is supposed to work, it will hopefully be relatively straight-forward to add correction for the text direction. I ahve worked with text direction with mixed English/Hebrew in other software before, so at least I have a basis of understanding the problem. Having fixed the problem, it appears that the best thing is to attach a new proposed patch to the bug. It looks like the people subscribed to the bug would be able to review the patch and get it included. Of course, I would need to double check the instructions for fixing bugs to make sure that is the correct procedure to follow.

I next took a look at Bug 347475, which prevents users of the Gnome On-Screen Keyboard (GOk) from recovering after they accidentally enter an invalid date. An error dialog pops up, but there is something preventing the GOk software from dismissing the dialog.

• Identify when the bug was submitted: 2006-07-14 02:57:52 UTC
• Identify if there has been recent discussion about the bug: There was some discussion up until 2 years ago, but nothing recently.
• Is the bug current? Yes and no. There is dispute as to whether the bug is valid. The program apparently works correctly as specified, but it poses significant usability problems for end users. The usability problem is probably still present.
• Is the bug assigned? To whom? No, it is marked UNCONFIRMED.
• Describe what you would need to do to fix the bug.

The problem seems to be that sometimes error dialogs do a "mouse grab" which means that they force the user to only interact with the dialog until they have dealt with the error. This is evil from a general usability point of view. (What if I need to compare information in the dialog with something else it is covering? What if I want a screenshot of the error? The user should have control of the mouse, not an app.) but crippling for users who need to interact with an accessibility program that will interact with the dialog for them. I certainly won't convince too many programmers that they don't really need a mouse grab, so the trick is to find a way to get mouse grabs in general to play nicely with accessibility software. So, it turns out that this bug really has nothing to do with Evolution's calendar support and everything to do with Gnome architecture. That means that I need to first study the Gnome architecture, how mouse grabs fit into the general Gnome philosophy and architecture, and propose a modification to the architecture that would address the conflict. Two possible solutions, I would need to understand Gnome better to pick: A) The accessibility software could act like the pointer to all other applications, so that the mouse grab controls what the accessibility software can direct while leaving the user free to direct the accessibility software with the real pointer. B) The accessibility software could have an attribute that allows it to share the pointer, even when another apps does a mouse grab. The trick is to keep developers from abusing this so that mouse grabs become meaningless because everyone overrides them.

Once I had a proposed solution, I would need to find the communication channel where the core architects for the project hang out, in order to run the proposed solution by them. This isn't the kind of change somebody just makes and hopes people like it!

Part 2: Reports

How many bug reports were opened in the last week? How many were closed?

I looked at the summary report for last week. A total of 321 bugs were opened and 444 were closed.

What was the general trend last week? Were more bugs opened than closed or vice versa?

More were closed than opened.

Who were the top three bug closers? Why is this important to know?

These are the people to coordinate with if you want to fix bug.

• Bastien Nocera
• Jean-François Fortin Tam
• Emmanuele Bassi (:ebassi)

Who were the top three bug reporters? Are these the same as the top three bug closes? What is the overlap in these two lists?

Who are the top three contributors of patches?

Who are the top three reviewers of patches? What is the overlap between these lists and the bug closers and bug reporters? What is the overlap between patch contributors and patch reviewers?

Click on the “Generic Reports” link.

Plot the Severity of each Version of the Accessibility features of Empathy.

What other reports can you generate?

About Working With OpenMRS

I am trying to get OpenMRS installed on my laptop, Windows 7, 64-bit. I already had JDK installed, but I needed to install Maven, Eclipse and GitHub. Actually, I am not sure if I really needed GitHub.

After making a fork of openmrs, I tried to install it according to the instructions, but 2 of the tests failed in openmrs-api. Who knows at this point—the error is probably somebody else's to worry about and not a show stopper for me. I found that "mvn install -fn" will go ahead and install even though there are some failures.