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.
Contents |
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...") - focus on what product is and nature of the community for this course level 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, finding the license, understanding Creative Commons (from learning activities)
CS1
Reading about FOSS - something broad for context, maybe from The Cathedral and the Bazaar? Test a Beta shadow a contributor - posse report on a project, focus more on activity of community, whether its good to engage with identify data structures used in a project Given coding standard & sample code, list the changes needed for code to meet standard. Given sample code, infer and document coding standard. Analyze existing code to understand what it does and how it works. Bash ativity (activities) git activity & 2 Intro to project identification writing a bug report project anatomy
