User:Emily.lovell

Emily Lovell

Emily Lovell is a doctoral student in Computer Science at UC Santa Cruz, where she works as a teaching assistant during the school year and teaches an introductory computer science course each summer. She is especially interested in how HFOSS involvement might positively impact diversity, inclusivity, and retention in computer science programs – and is hoping to pursue dissertation work in this area.

Previously, Emily completed a master's degree in the High-Low Tech research group at the MIT Media Lab, where her research focused on electronic textiles as an alternative pathway to learning about electronics and programming. She's also spent time studying electronic music and graphic design – and she loves collaborating with museums and supporting outreach efforts.

In her spare time, Emily can be found hiking, climbing, baking, playing the ukulele, and spending time with her dog.

---

Intro IRC Activity Notes

How do people interact?

One way is for someone to address a group of users/the entire channel with a question or request; another is for a user to address another user individually (although visible to everyone else in the channel, as opposed to directly messaging them).

What is the pattern of communication?

Conversations often seem to take on an interleaved sort of structure, where two sets of users might each be having a one-to-one conversation but in the presence of anyone logged into a given channel. Or sometimes one user has moved onto the next topic/question, while another user is still elaborating on a response. I think that the latter can happen simply due to time delays - and given that there is no way of knowing when another user in a channel is in the middle of typing a response. Overall tone is very informal, though.

Are there any terms that seem to have special meaning?

The terms prefaced by hashtags are meetbot commands, which I think dictate how the minutes will be distilled out of the more verbose meeting log. I don't see it as much in this particular sample conversation, but in other IRC channels that I observed there were a lot of common abbreviations being used (AFK, FWIW, etc.)

What advantages might IRC have over other real-time communication methods (like Google Chat or Facebook Messenger?) Are there potential disadvantages?

I see a lot of advantages: accessibility to those with low internet speeds, text-searchable record of conversation, ability to lurk when one is otherwise engaged (or perhaps not ready to engage), opportunity for those who feel spoken-over in traditional meetings to be heard. Major disadvantage that I see is that it can sometimes be challenging to follow the multithread conversation style, and of course that there is something very rich about video/face-to-face meetings.

Can you make any other observations?

I had to track down an admin to reclaim an old nick that I used in college and noticed that a lot of admins will stay in a channel but not be checking it regularly; however, if you send them a direct message, then they'll tune in and be happy to help! (I used IRC a lot in college with my classmates to provide homework help to one another. We used to all leave ourselves signed into a shared channel so that we could all see the questions that others had, and then each question would have maximum visibility and chance of being answered by someone else.)

Bonus question: Why didn't Heidi and Darci's actions get picked up by the meetbot?

I was thinking Darci's actions didn't get picked up by the meetbot because she is designated as the chair? But I have no idea about Heidi!

Observations of the chosen IRC channel (either from chosen HFOSS channel or from project channel)

First I tried hanging out in the #sahana and #sahana-eden channels, since I've recently been supporting a labmate on a Sahana Eden-based project and have some context to understand conversation happening there... but I found that there wasn't much activity in these channels. So then I tried #openMRS and was able to observe a lot more: automated announcements from a bot, questions from users about writing unit tests, specific questions about code. Overall I was actually surprised by the technical specificity of questions being asked (and answered!)

Project Anatomy Activity Notes

The Sugar Labs Project

Community

The Activity Team is responsible for developing and maintaining Sugar activities and also supporting independent developers in doing so; the Development Team focuses on developing and maintaining the core Sugar environment; and the Documentation team is in charge of supporting the Sugar community with helpful documentation (tutorials, reference materials, etc.)

Common to all teams is that they do not exist as islands; they instead work closely with one or two other teams to coordinate realization of their goals. Most teams seem to have semi-regular meetings and varying degrees of wiki documentation such as background information and links to relevant technical resources.

The greatest notable difference between these three teams (at surface level) is the level of documentation. The Activity Team has, by far, the most information on their wiki page - and they explicitly mention mentorship as a component of their duties. However, I suspect that one reason the Activity Team has so much more documentation is because they interface with outside developers on a more regular basis than some of the other teams.

Tracker

Types/categories of tickets: Defect, Enhancement, Task.

Information provided for each ticket: Ticket #, Summary, Status, Owner, Type, Priority, Milestone (if any).

Repository

It looks like Sugar Labs is using git, but in the process of migrating their code from Github to their own servers. (The Activity Team mentioned this on their page, actually.)

Release Cycle

Sugar Labs updates their roadmap at the beginning of each release cycle. The roadmap specifies various feature proposals and an overall timeline for the next upcoming release. The release cycle and roadmap are interrelated because the roadmap specifies freeze points, which enable focus to shift to testing and documentation. This shift from development to refinement is what allows the release cycle to move from one stage to another, eventually enabling a version of the product to be shared with end users.

The Sahana Eden Project

Community

Developers can contribute in a variety of ways involving code, with some specific ideas offered on the Eden website; Testers can help with testing and integration from both non-technical and technical standpoints; and Designers can contribute expertise with graphic design, HTML, and CSS.

Some specific ways to get started contributing are outlined for each of these three areas, with a welcoming and appreciative tone. Different between these areas is that some have more documentation than others.

Sahana Eden's roles seem to be much more broadly defined than the teams of Sugar Labs. The Eden community seems smaller/less mature than that of Sugar, although I really like that they offer some very specific steps on how to get involved (e.g. introduce yourself on mailing lists/IRC, participate in online training, install a dev environment).

Tracker

Types/categories of tickets: Defect/bug, Documentation, Task, Enhancement.

Information provided for each ticket: Ticket #, Summary, Component, Version, Priority, Type, Owner, Status, Created Date.

The Sahana Eden tracker differs from the Sugar Labs tracker in that it organizes and displays tickets in a different order. I think it's initially easier on the eyes, but harder to manually filter for specific types of tickets.

Repository

Sahana Eden is using git, which is a distributed web-based repository. Additionally, their code is stored on Github.

Release Cycle

Sahana Eden provides graphics showing progress made so far towards the next milestone, based on completion of relevant tickets. More detailed notes list the status of individual subgoals for the next upcoming release.

Different from Sugar Labs, Sahana Eden also lays out future milestones even before the current one is complete. This allows public tracking of longer term goals.

FOSS in Courses Activity Notes

For the past two summers I've been teaching UCSC's most introductory computer science class, essentially a CS0 curriculum. I have a lot of non-majors in the class but my hope is always to spark the interest of some students who would be a great fit for further computer science coursework. I believe it'll definitely be possible for me to re-teach this class in the future with an open source focus, although another possibility may be for me to teach an open source themed section of our CS1 class (which focuses on Java) instead. I've gathered rough notes, below, on relevant existing activities for each of these courses.

In either case, I like the idea of having students share their results on a wiki – both because wikis are so frequently used by open source communities and because this would enable them to share experiences with their classmates.

CS0

• Reading about FOSS - something broad for context, maybe from The Cathedral and the Bazaar?
• Diagnose a bug (from "14 Ways...")
• Join an IRC channel or mailing list, report on observations about communication style (from "14 ways...")
• Create an example (from "14 Ways...") - nice way to get students contributing ASAP without necessitating technical knowledge
• Interview a contributor (from "50 Ways...")
• Report on a project (from "50 Ways...") - for this course level, focus on what product is and nature of the community
• Work remotely with another student to write profiles (from "50 Ways...") - expose students to communication tools used by devs
• Licensing/IP & cultural/policy implications (from "50 Ways...") - this could replace current essay on digital privacy
• Have students generate private/public keys and send encrypted messages (from "50 Ways...)" - this seems less directly tied to HFOSS, but ties very well to the existing course curriculum which covers encryption and feels very abstract in its present state
• Choosing a license (from learning activities)
• Finding the license (from learning activities)
• Understanding Creative Commons (from learning activities)

CS1

• Reading about FOSS - something broad for context, maybe from The Cathedral and the Bazaar?
• Test a beta (from "14 Ways...") - would be great combined experience of installing new software and testing it
• Shadow a contributor (from "50 Ways...")
• Report on a project (from "50 Ways...") - for this course level, focus on activity within community and whether would be constructive to engage with as well as technical infrastructure of project
• Identify data structures used in a project (from "50 Ways...")
• Given coding standard & sample code, list the changes needed for code to meet standard (from "50 Ways...")
• Given sample code, infer and document coding standard (from "50 Ways...")
• Analyze existing code to understand what it does and how it works (from "50 Ways...")
• Bash activity (from learning activities) - practical tool intro
• Git activity & Git activity 2 (from learning activities) - another practical tool intro
• Intro to project identification (from learning activities)
• Writing a bug report (from learning activities)
• Project anatomy (from learning activities)

Bug Tracker Activity Notes

Bug Reports

The column names that I found differed from those listed in the activity, and were as follows:

• ID - ticket # for a particular bug
• product - which specific GNOME product is affected (banshee, gnome-nettool, gnome-panel, gnome-settings, and many others)
• comp - component affected, which is a second tier of specification (general, registry, mouse, focus, accessibility, and many others)
• assignee - team or user responsible for addressing the issue
• status - current status of the issue (UNCO/unconfirmed, new, assigned, reopened, needinfo, resolved, verified)
• resolution - what happened to the issue (if still open: ---, if closed: fixed, invalid, wontfix, duplicate, worksforme)
• summary - brief description of the issue/bug/feature request

I found some of the more elusive possible values/definitions by clicking Reports -> Explanation of Various Terms and Fields.

Unconfirmed tickets appear first, followed by those labeled New. It seems like tickets are ordered within those categories by the date that they were last modified (most recent dates appearing first). I couldn't figure out why some bugs were shaded with a gray background and some weren't, but I did determine that the color of the text corresponds to relative importance. (Gray is normal enhancement, black is normal normal, and red is normal critical.)

I picked two bugs to compare: #650310 and #669597.

Bug #650310: Need to improve AtkRelation docs

• Submitted on 5/16/2011.
• Not much recent discussion, although it appears it was reassigned on 6/23/2011.
• I'm not sure if the bug is current as I'm unable to test it myself, but it doesn't appear to have ever been resolved.
• Currently assigned to ATK maintainer(s).
• If I were to try fixing this bug, I think I would start by talking to some existing developers to try and gather more information. I'm not sure what is meant by "accessible relations" in the original report, but it references an IRC conversation that a log might exist for. My end goal would be to develop and test some examples to add to the documentation.

Bug #669597: Sticky keys description rather misleading

• Submitted on 2/7/2012.
• Did have some discussion going, but only up until 4/21/2013.
• I'm not sure if the bug is current as I'm unable to test it myself, but it doesn't appear to have ever been resolved.
• Currently assigned to Control-Center Maintainers.
• If I were to try fixing this bug, I think I would start by finding in the code where the description in question is located. Once doing so, I think it would be safe to change to a proposed replacement description that garnered some support in the ticket's discussion thread.

Collective Reports

In the past week, 325 tickets were opened and 272 were closed. This means the general trend for last week was that more bugs/issues were being reported than resolved.

The top three bug closers for the last week are: 1. Matthias Clasen 2. Bastien Nocera 3. Carlos Soriano This is evidence that these three developers are very active within the community. I imagine they might be good resources if I had a question.

The top three bug reporters for the last week are: 1. Bastien Nocera 2. Alexander Larsson 3. Andreas Nilsson Bastien Nocera also appeared in the top three bug closers for the last week.

The top three patch contributors for the last week are: 1. Carlos Soriano 2. Bastien Nocera 3. Sebastian Dröge Carlos Soriano was also one of the top three bug closers and Bastien Nocera appears in the top three of every category so far.

The top three patch reviewers for the last week are: 1. Sebastian Dröge 2. Bastien Nocera 3. Matthias Clasen All three of these developers appear in the top three for another category. Sebastian Dröge and Bastien Nocera are also top patch contributors. Bastien Nocera and Matthias Clasen also both appear in the top three for bug closers, bug reporters, or both.

When I generated a line graph of the severity of bugs by component for Orca, I found that most braille bugs are of the class normal. I think it would take more time playing around with all of the settings for me to generate useful graphs, but it seems possible to take into consideration how much a ticket is commented on, bug severity, ticket status, and many more factors.