User:Scrain
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.
Contents |
Notes on Participation in HFOSS
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
Project Evaluation: Mifos
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.
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.