User:Kate.lockwood

Revision as of 19:47, 12 August 2015

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.

IRC Chat Log

The IRC chat log seemed pretty friendly and informal. While the general topic of the conversation was controlled by #topic posts, there was some back and forth to previous topics and people would sometimes interject with other questions and ideas. Also, there seemed to sometimes be several conversations going on at the same time. The people involved seemed to be using the conversation for multiple purposes. Some of the chat related to troubleshooting specific problems that people were having while some of it focused on higher level questions about the Mousetrap project and there was also some logistics (like scheduling meetings). The terms that had special meaning were easy to pick out because all of the commands start with the # symbol. I thought it was neat to see how the meetbot was able to create the meeting notes including action items from the transcript. While it was a little confusing at first watching the conversation jump around a little, that was probably mostly due to not being familiar with the project. I can see how IRC is a very useful tool for open source projects both to keep notes of decisions/conversations and also as a way to provide an archive for people who have to miss meetings.

BONUS: I am not sure, but is it possible that the two unassigned actions didn't get picked up because the names in the #action items were not exactly the same as the user names ? (e.g. Heidi instead of heidi)?

Observing an IRC Channel

I chose to observe the Sahana IRC channel. I logged in and I think there were other people in the chat room (at least one other POSSE person), but there wasn't any conversation going on. I did at some point get a message asking me to introduce myself, but I wasn't sure what to do. I felt a little bad that I was just there to "lurk" and didn't really have anything to add to the conversation or the project. In retrospect, having now gone through the anatomy part of the assignment and realizing that many projects have multiple IRC channels, I think I might have more luck looking at a specific team channel (like a development team for a given project) since there is likely to be more conversation among people who are working on a common set of goals. I had the hardest time with this assignment. I didn't really want to introduce myself on the IRC because I felt like then someone would feel like they had to respond and I'd be wasting someone's time (since I wasn't really there to help out). I hope next time I check out the IRC for a project I am ready to ask a substantive question or to pitch in on the project.

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.