User:Emily.lovell

Latest revision as of 01:49, 7 February 2017

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 pursuing related dissertation work.

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)

Version Control Activity

Thinking more specifically about one activity in particular, I would really like for my students in either class to learn about version control. As an undergraduate, version control felt like an afterthought – and I half-learned CVS which felt outdated even for the time. I had to learn Subversion on my own when I started graduate school and I'm still trying to wrap my head around Git. I volunteered for an Open Hatch workshop last year and really liked one of the activities we did with students, which had them fork a simple website project, make some changes, commit and merge them. Students really enjoyed it too! So, I'm already thinking about how to adapt a similar activity for the next time that I teach.

Here are some ideas:

Possible Learning Outcomes

• Learn about why version control is useful - starting with a non-code example. (Sharing/modifying a recipe, maybe? I saw this as an example somewhere...)
• Recognize the difference between code that lives locally on a student's machine versus code that is part of a central repository or "live" on a website.
• Learn about the process for creating a pull request and merging changes into the main repository for a project.
• Learn how to install and configure some settings of a tool by installing Git and configuring username & email address.
• Get hands-on experience with version control tools: using Git on the command line, using the Github website.

Prerequisite Knowledge

• Familiarity with terminal/command line.
• Familiarity with whatever language is being used in the file(s) to be modified (HTML and CSS in the Open Hatch activity I participated in).

Time Required

• Instructor Prep: I'm guessing it would take ~2 hours to setup some repositories on Github for students to use for this activity and to ensure that the code/files being used were appropriate for the student audience.
• Student completion: To be done in-class, and could probably be done in a 1.5-2 hour class.
• This activity would be independent of any particular HFOSS project, so we wouldn't have to worry about syncing with an outside community/schedule.

Input Required from the HFOSS Community

• None in particular. This project also would not generate output that is directly contributed back to an HFOSS project. (Although I am hoping that it would help lead to that happening later!)

Assessment/Grading Approach

• This activity would be done in teams.
• Students would be graded on their committed code, which the instructor would merge back into the master branch of the project. If the committed code isn't yet in the condition it should be, the instructor could offer comments/feedback on further revisions. This way, students could still receive credit (or partial credit) even if their pull request wasn't approved on first attempt.

Questions/Concerns About the Activity

• I would definitely like to add a bit of content/further explanation to the version of the activity that I've facilitated before, to clarify certain points regarding git.
• The original activity has students modifying a simple HTML/CSS website. This might work well for my CS0 class because we do cover HTML as a topic, but I think a CS1 class might benefit more from modifying code for a simple "Hello World" type Java program. When we ran the activity last year at Hartnell College, students were familiar with Java but many had not seen HTML/CSS before. While dabbling in a new language on-the-fly might not feel so daunting to an experienced programmer, some students froze at having to think about new languages in addition to the other content being presented.

Potential Stumbling Blocks or Barriers

• Another challenge when I helped facilitate this activity before was students' understanding of code that is local versus living in a remote/public repository. I'd like to think more about how to frame these ideas and re-emphasize the differences throughout the hands-on activity.

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.