At each Open Source Comes to Campus event, participants ask unique, thought-provoking questions. We decided to write down these questions and answer them more fully on our blog. If you have any additional suggestions or advice, please add them in the comments!

These questions are from our UMass Amherst event.  This post was co-written with Shauna Gordon-McKeon.

Why do we focus on bugs in the bug tracker, rather than adding new features?

One student asked why in Open Source Comes to Campus’s project time, where we help students make their first contributions to open source projects, we focus on bugs rather than features. From what I could tell, this came from not understanding the wide variety of items that appear in a project’s bug trackers, so I took a minute to explain that.

Bug trackers in an open source project are used for tracking progress on all kinds of work. They’re intended to be action-oriented to-do lists, not necessarily just lists of known times a program will fail. This means all sorts of items show up in them:

• suggestions for how to change the project’s website
• bugs, such as inputs that will cause the program to crash
• feature requests by users
• known issues in the current code, such as suggestions by the maintainer on how to improve the code’s layout for clarity

Having said that, we do focus on small tasks in the project time, many of which are small bug fixes or documentation changes. In the 3-4 hours students have, there is a lot to do: get acquainted with the internals of a program, gain enough proficiency in the tools around the project to create a patch, and work with a mentor to make sure it is a precise, correct fix to an issue.

Why are there multiple IRC servers?

To summarize: there are different IRC servers because different people seem to enjoy running the IRC server software for their particular chosen communities to communicate. One great reference on IRC history is this page by Daniel Stenberg, the maintainer of cURL.

To understand that, it’s helpful to know a few things. First, IRC is a protocol, not a centralized service. Second, IRC has the ability to have multiple servers collaborate to appear as one “network.” Third, different server/network operators have different goals, which result in different policies and often the creation of new networks.

Internet Relay Chat is a loosely standardized.  The standard lets people write their own chat programs (clients) and servers (also known as daemons) if they want to. Rather than being carefully designed as a protocol that would permit creating lots of different clients and servers, the standard simply evolved out of the first IRC client and server.

When you choose to connect your IRC client (for example, X-Chat) to the Freenode IRC network, you could be connecting to any one of a few different physical servers; you can see a list here. Any of those servers should act equivalently; you can talk to any user on any server on the network. (When this interconnectivity fails, it is known as a network split, also known as netsplit.)

While freenode is the network we use at Open Source Comes to Campus, and for the OpenHatch IRC channel, it is not the only IRC network. For one example, Debian (a free software project) uses OFTC as a result of disagreements about the way the Freenode staff ran the network in 2002. Freenode and OFTC are themed around community projects, but other networks exist purely to support chat, or to support chat about particular topics. At the small end, tech companies often run their own IRC servers for private use, and services like grove.io offer help running those servers. At the large end, you can see how popular other “top 10” IRC networks are in this netsplit.de graph.

What can you use Git/Github for, besides code?

You can use Git to store almost anything, provided you have enough space on your computer, and/or on Github, to house it.  Github is especially useful for plain text files, including program files, because Github allows you to easily visualize changes to plain text.  You can do a diff and see where characters have been inserted and deleted easily.  With an image, you can store the information about which pixels have been altered but reading that in text form won’t mean much to most people.  Github also allows you to edit plain text files directly from the browser.

So what kind of text-based projects can be versioned with Git?

• There have been several efforts to keep track of legislation via version control systems.  For instance, Gesetze follows the German Bundestag.

• The White House has put part of their open data initiative on Github and has been accepting issues and pull requests.

• The city of Chicago has started sharing its open data via Github.

• Hundreds of people have put up repositories of poetry, and a friend of mine uses git to keep track of her novel.

• Even more people have put their resumes on Github.

• Some educators are sharing syllabi.

• Some scientists are publishing their raw data, as well as the scripts they use for processing and analyzing it, on Github.

• I (Shauna) have a repository for scans of a weekly newspaper from the 1870s.

How do open source projects review changes, and how do those changes differ from something like Wikipedia?

One key cultural element of Wikipedia, at least so far in history, is that anyone’s edits to English Wikipedia immediately become part of the “live” version of the encyclopedia. By contrast, to maintain quality, open source projects typically permit only a handful of people to directly “merge” changes into the main project. Therefore, submitted changes go through review.

Different communities have different standards and processes. Sometimes, there is no review at all, just automatic merging by the maintainer. In other cases, like Linux, submissions go to a mailing list for review. Others, like the OpenHatch web app, use web-based tools like Github pull requests. A great reference for a more complicated process is the OpenStack Gerrit Workflow documentation page.