User:Kate.lockwood

Kate Lockwood is an Assistant Professor in the Computer and Information Systems Department at the University of St. Thomas.

Prior to coming to St. Thomas, Kate taught at California State University, Monterey Bay for five years.

Kate's main interests are artificial intelligence, cognitive modelling and computer science education (particularly at the CS1 and CS2 level).

When she's not busy, Kate enjoys reading, craft beer, running, hanging out with her husband and two small children, and learning new home improvement skills from You Tube videos.

Sugar Labs Entry

Community: The Activity Team for Sugar had a large list of people and two coordinators. I thought it was interesting that anyone could add themselves to the team - I had assumed you'd have to ask to join, but there were directions for adding yourself and for choosing a to-do to work on! The development team was much smaller (4 - I didn't notice any overlap with the activity team list) and did not have a coordinator. There was a posting about vacancies. I thought the vacancies page was great because it clearly laid out some of the roles that still needed to be filled and would be a good point of entry for someone looking to get more involved. One thing that would be good to know is what the desired skills/level of experience is for each of the open positions. For example, would any of them be a good fit for someone newer to the project? The documentation team didn't provide a list of all members, but it did provide a link to the mailing list. I'd say the one commonality among the different teams was that they provided information about how the team communicates on IRC.

Tracker: There were 179 bugs in the tracker when I checked. It looks like the types of bugs are "defect" and "enhancement" - I am guessing those are pretty much "bug"/"feature" (or feature request). For every ticket in the system, you can see:

• Ticket number
• Summary of the bug
• The owner
• The status
• The type
• The priority
• The milestone

I thought pretty much all of the categories were pretty self explanatory, except for milestone.

Repository: It looks like Sugar uses Gitorious which is a hosted (web-based?) repository for open source projects using Git.

Release Cycle: I admit that here is where I started to get a little confused (also a little bit while poking around the repository). It looks like the Roadmap lays out the goals (features to be developed) for each release cycle and also the dates for the feature freezes. Then the release cycle is how the modules that are part of the release are frozen, put together, and distributed as a new release.

Sahana Entry

Community: Sahana, like Sugar Labs, seemed like a very welcoming place. One big difference I noted was that none of the Sahana groups listed members. At Sugar Labs, the team pages tended to be pretty sparse and contained mostly membership information (and some basic information about IRC). At Sahana, each team page had documentation (or links to documentation) that laid out the guidelines for the team and some ideas of the specific type of help that was needed. I think that the additional guidelines can be helpful, especially for someone just starting out. If you are new to a project and want to get a good idea of how to help without bugging people, good guidelines and documentation are a great place to start. For the development team there was also a training session. I could see some people getting a little discouraged by that, but I personally would feel a lot more comfortable contributing to a project where I had gone through some specific training about what was expected of contributors. The training might also be a great resource for students. I bookmarked this to come back to later as I would be interested in looking at the training, even if I don't decide to contribute to the project.

Tracker: The Sahana tracker is a bit different than the Sugar Labs tracker in that the tickets are sortable by category on the main page rather than going directly to the list of all tickets. The categories of active tickets are: defect/bug, enhancement, and task. The information available for each ticket was pretty similar to the information available for the tickets at Sugar Labs. For Sahana, the ticket information included: a ticket number, a short summary, the component involved, version, priority, type, owner, status, and the date the ticket was created.

Repository: The installation instructions look really helpful for people setting up an environment that would allow them to contribute to the project. If I am understanding correctly, it looks like Sahana uses Git. If I understand correctly that's a web-based repository. I think I probably need to learn a little bit more about how the different repositories and version control systems work.

Release Cycle: It looks like Sahana organizes their roadmap around features which are then divided into different tickets. There is a cool tracker bar that shows what percentage of the tickets for that release have been completed. It also looks like there are several releases being worked on concurrently. It looks like the project is way behind (4 years!) the dates it wanted to schedule the releases. I wonder if that is due to low participation or feature creep?

I thought it was interesting to look at the two projects and get a feel for how they are organized.