User:Kate.lockwood

Latest revision as of 01:49, 7 February 2017

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.

Class Activities

I was impressed by all the great ideas for ways to get students involved in open source. I would be doing this as part of a software engineering course (most likely). Since it seems like I likely won't be able to get the students up to speed fast enough to have them do a large coding project, I think I'd probably do a series of open source assignments alongside their capstone programming project. I think a progression something like this might work:

1. Join the mailing lists for a project - write a reflection
2. Open source scavenger hunt (this was an idea in the reading)
3. Download and use the project, follow the manual and note any changes/edits you would make. Create a new example [As a class we could submit everyone's documentation edits]
4. Another class documentation project like the glossary or something
5. Bug clean up activity where groups are assigned 3-5 bugs from the ticket system and asked to try to recreate them, etc (this was also from the reading)
6. Each group choose 1 bug to attempt to solve (if they can't write the code themselves, write up the proposed solution)

I'd like to intersperse some readings on open source including some of the ones from part 1. I think it would be a great way for students to get an overview of both software engineering on a larg(er) project and OSS.

Bug Reports

1. Define what each of the column names below indicate. Include the range of possible values for 2-7 below. Feel free to explore beyond the page to find more information.

• • ID: unique identifier for the bug.
  • Sev: severity {blocker, critical, major, normal, minor, trivial, enhancement}
  • Pri: priority {immediate, highest, high, normal, low, lowest}
  • OS: operating system/platform - assuming this could be any OS
  • Product: the product (or sub-project) the bug belongs to (the values would depend on the project)
  • Status: where in the life cycle the bug is - I found three different lists for this
    • {open, patch-for-review, resolved, declined, invalid, duplicate, verified, stalled}
    • {new, unconfirmed, assigned, reopened, needinfo}
    • {unconfirmed, confirmed, in_progress, fixed, invalid, wontfix, duplicate, worksforme}
  • Resolution: {resolved, verified}
  • Summary: short description of the bug

1. Describe how you discovered the definitions and how did you find the information from above (hint: the advanced search shows the options or the Reports link has a link)?

At first I tried to Google for documentation but couldn't find anything in the Bugzilla documentation. I found some good documentation from the MediaWiki project, but it turns out that documentation was specific to how bugs are tracked in that project. Then I clicked on the reports link as suggested. I found it kind of tricky to track all this down actually.

1. Identify the order in which the bugs are initially displayed?

By changed date (newest first)

1. What is the meaning of the shading of some bug reports?

From clicking through to some bug reports, it looks like the shaded ones have at least one user listed under "CC list"

1. What is the meaning of the colors used when describing a bug (red, gray, black)?

The color coding is for the importance of the bug: Red: normal critical Black: normal normal Gray: normal enhancement

1. Select a bug that you think that you might be able to fix and look at it more closely (click on the bug number).

For this I chose bug 754249

• • Identify when the bug was submitted: 08/28/2015
  • Identify if there has been recent discussion about the bug?: It looks like there was a lot of discussion on the day the bug was submitted but nothing since
  • Is the bug current? Yes?
  • Is the bug assigned? To whom? to gtk-bugs
  • Describe what you would need to do to fix the bug. This bug was an enhancement request about adding tooltip text to some buttons. I could go into the code and add appropriate tool tip text (probably taken from the documentation) to the buttons.

1. Repeat the previous step with a different kind of bug.

For this I chose bug 741944

• • Identify when the bug was submitted: 12/24/2014
  • Identify if there has been recent discussion about the bug? None
  • Is the bug current? Bug is still listed as unconfirmed
  • Is the bug assigned? To whom? Banshee maintainers
  • Describe what you would need to do to fix the bug. This but was (normal normal) about unsupported file types. I'd first confirm the bug by testing it out myself. If the bug was confirmed, I'd look into what would be required to support the requested types.

Class Activities 2

I am situating my activities in a software engineering class. The students will be doing a capstone programming project and if I can't figure out how to use FOSS for that, then I'll do the FOSS assignments in a separate track to introduce students to larger project management and to FOSS. I don't really do much lecture in my classes, so I would probably use other mixed methods to present the material. I like to do inverted classroom as well where I assign videos/readings/etc for homework and do active learning in the classroom.

I think the overall pacing would be about one open source activity a week, but some could build on previous weeks. I'd want the FOSS thread to run throughout the semester. If students do end up coding for a FOSS project as their capstone I would probably need a lot more direct involvement from the project community and would need to align with their timeline. By doing a series of shorter assignments related to FOSS I can adjust deadlines to fit with the semester schedule and also avoid having students potentially miss an important deadline for the project.

Overall my outcomes related to the FOSS part of class would be:

• Students should understand what FOSS is, how to find FOSS software, and how FOSS software is licensed
• Students should understand the FOSS model of software development
• Students should be familiar with source/version control and how to use it in FOSS and their own projects
• Students should feel comfortable interacting with members of the FOSS community (via IRC and other channels)
• Students should make a contribution to an open source project (documentation, editing, bug tracking, etc)

Right now my biggest concern is that the assignment(s) are all very rough. I am looking forward to talking more about potential projects and assignments at the face to face meeting. I'd like to get a better sense of what is doable in a semester. I have the constraints of working within a senior level software engineering capstone