User:ADalal

Revision as of 20:20, 26 October 2016

Bio

Amy Csizmar Dalal is an Associate Professor of Computer Science at Carleton College in Northfield, MN. She teaches courses at the introductory level, as well as Data Structures, Software Design, Computer Organization and Architecture, Human-Computer Interaction, Computer Networks, and Computer Security. She also regularly supervises senior capstone projects and is very involved in integrating academic civic engagement into her courses. Her research interests include quality of service/quality of experience of Internet applications; self-healing networks; human-computer interaction; streaming media; network measurement; and performance analysis of computer and communication networks.

In her spare time, Amy is an avid runner and voracious reader and likes to spend as much time as possible outdoors.

Email: adalal@carleton.edu
Twitter: @drcsiz
Website: http://cs.carleton.edu/faculty/adalal
Blog: http://acdalal.wordpress.com

Part A Activities

Project Anatomy Activity notes

Sugar labs project

• The most natural roles for my students would probably be developer, designer (for HCI classes and/or capstone projects), and content writer (technical content).
• It looks like you submit bugs through the repository, and then I assume they are auto-added to the bugtracker. I found it interesting that most of the bugs I clicked on when poking around the bugtracker were many years old --- kind of a scary thought! I wish there was a way to sort by date added so it's easier to see the newer bugs. Also, the process for submitting a bug does not seem to be very user-friendly --- the issues page doesn't provide a lot of info on what data the developers would like to know, and the "how to submit a bug report" guide was long, rambly, and at times condescending.
• Last commit was 3/10/2014 (?!) according to the Activity page
• The roadmap is updated at the beginning of each release cycle

Sahana Eden project

• There are definitely distinct roles in this project. This project also had a much different "feel" than Sugar Labs. Whereas the Sugar Labs page seemed a bit more hierarchical ("contact this person if you want to contribute as an X"), these pages seem more to invite the person to jump in and start playing around with things. I also found the information on submitting bugs under the Testing page to be WAY more accessible and useful than the one for the Sugar Labs project. In summary, Sugar Labs felt like you had to join an exclusive club to contribute, while Sahana seems more open.
• The bugtracking page is way better organized and easier to follow than the one for Sugar Labs. You can actually see dates and things are better categorized.
• Roadmap: again, the info here seems well-organized, with succinct summaries of deliverables or work-in-progress. Seems like no recent activity, though, so it's unclear when/how often these are updated.

Summary: It was interesting to see how differently each project presented itself. It's made me think that one of the important factors in deciding on a project for a class should be how welcoming the community seems. I could see how, for instance, someone who maybe is not as sure of themselves as a CS major could feel overwhelmed or put off by the way a project is presented, and how this could actually turn someone off from CS, rather than attracting them to CS.

Part B Activities

FOSS Field Trip

See blog post (link will be posted shortly)

Project Evaluation

Project under consideration: OpenMRS (which is also the project I'm currently considering for my classes).

Viability criteria

• Based on the data from OpenHub and the OpenMRS page, I would rate this project 3 (high) on the size/scale/complexity scale.
• Based on the number of commits from looking at the repository and from the OpenHub stats, I would say OpenMRS is definitely active. There have been commits in the last several months and new developers have joined and committed code in the last several months.
• It seems from the IRC logs, Talk activity, and downloads that this project has an active community. The IRC logs indicate that people can easily get help in real time (there seems to be activity over most hours of the day); similarly, there are active discussion threads on Talk. I'm guessing from the stats that there was a major release in August of this year given that downloads went up by a factor of 2-3 (and are now back down by a factor of 3).

Approachability criteria

This project gets a B+/A- for approachability. There is an extensive set of developer guides that seem to be fairly well written (from my quick skim), and seem to make it way less scary to start contributing code. Contributing in the testing and documentation areas are somewhat well-documented. However, I wonder if "contact the developers' email list" as one of the first instructions for getting involved as a tester is off-putting to some people. Similarly, the documentation for the documentation area lists areas where documentation is needed, but it's less clear if this is up to date and who is "in charge" of curating this content.

That said, this project appears to have thought carefully about how to attract potential contributors and make them feel welcome, which is very refreshing and professional.

Suitability

• There seems to be good, clear documentation about how to "claim" a ticket and resolve an issue. I also noticed a lot of the introductory issues have a good deal of discussion about the best way to approach the problem, and some already have unit tests. This would definitely decrease the learning curve for my students. That said, I could see wanting to do an in-class lab activity to help my students get everything set up and ready to go before they tackle one of the issues.
• As I mentioned in the previous section, IRC and Talk activity indicate that questions are usually answered in a timely manner, and the documentation for developers seems to have taken into account most questions new users would have about getting started. I would rate newcomer support highly.

Summary

After reviewing this project, I think it would be a good fit for a Comps project (our version of the senior capstone course). Our students work in teams over 2 academic terms, so there would be enough time to get up and running (install the environment, claim and resolve some issues, submit patches and unit tests) and also make non-trivial contributions to the project. I could see the value in identifying one or more key "contacts" that my students would interface with to make things easier, but I suppose I'd have to negotiate this beforehand.

FOSS in Courses