Open Source Comes to Campus/Curriculum/Tools/transcript: Difference between revisions

Hi, I'm Shauna Gordon-McKeon.

 

Projects with a significant number of community members usually have separate lists for different audiences. The most common split is to have two lists, one for users and one for developers, but larger projects have more... sometimes a lot more.

 

 

I enjoy that the fact that their list of discontinued lists is much, much longer than the total number of lists most projects have. Anyway, most projects will only have one or two lists, and many don't have any. When joining a project with multiple mailing lists, check to make sure it's the right one, either by reading descriptions of the list or reading through past posts to get a feel for what it’s usually used for.

Why don't you pause this video and try joining the #openhatch channel on the network Freenode? Make sure to say hi! If you haven't already installed an IRC client, you can follow our instructions to do so here:

 

 

There are a number of neat things that IRC and your IRC client should let you do. For instance, when you type "/me" and then a statement, it appears in this different format. Also, when someone uses your IRC nickname in the channel, your client should alert you in various ways, such as making a noise, or turning the notification icon a different color or, as you can see here, highlighting that remark in the channel. In addition to channels, IRC also allows for direct messages. You can start a direct message with someone by typing "/msg", the users name, and then the message.

Moving on from IRC, the next communication tool is the issue tracker. Issue trackers are used by projects to organize what needs to be improved. Let's take a look at some projects' issue trackers.

 

 

As you can see, they all have the same basic structure. They have a dashboard which lets you search through issues, and then when you click on the issue, you find out more about it. Going back to the dashboards, there are some columns you'll find on virtually every tracker. For instance, the unique ID field, or the brief summary of the issue, or who created the issue, or when the last update to that issue was.

Many projects will also have some custom fields in their issue trackers. For instance, OpenStates is an effort to make civic data from US States such as legislator contact info, voting records, and committee meetings available. They do this by scraping information from state government websites. You can see they have a column labeled states, so people can indicate whether their issue is with a particular state. Other projects may have different customizations. You can often find descriptions of how a particular issue tracker is configured, for instance by going to links labeled 'Documentation', 'Instructions', or simply 'Help'.

 

 

So that's how you use an issue tracker. But how do you read an issue? Let's take a look at some real issues that were reported in open source projects' issue trackers. In a moment, I'm going to link you to an activity we give as a handout in our in person events. The instructions for the activity assume you have a partner. If you happen to be watching this video with someone, great! You can be each others partners. If you're watching it alone, feel free to join us in the openhatch IRC channel and find a partner there. Or you can just ignore that part.

The activity description links to two issue tracker threads, ‘No December’ and ‘Can’t Print… Sometimes’. For one or both, read through the thread and see if you can answer the associated questions about what the problem is and how it got fixed. You should pause the video now, and come back to hear my explanations.

 

 

Let’s look at the ‘No December’ bug first.

All right, I hope you enjoyed that activity. Let's take a look at one last issue thread:

 

 

I wonder how long before the joke gets dated and I have to take it out of this presentation.

There's actually a function called diff on your terminal. I'm not going to get into the details of it here, because most version control systems don't require you to generate your own diffs, but if you're interested, you can pause the video and check out our diff tutorial.

 

 

Let's go back to your research paper. What if you were writing a research paper wthl millions of friends and strangers? What if this research paper spanned millions of different topics and sub-topics? Such a research paper does exist. We call it Wikipedia.

 

 

With so many people editing so many pages, it's only natural that the beating heart of Wikipedia is a version control system. On any page, you can go to the tab 'View History' and access any version of the page that has ever existed. You can also compare any two versions. When you do, Wikipedia will show you a diff. You can see here how they display it, with the older version on the left and the newer on the right, with removals in beige and additions in blue. You can also see, at the top, what is often called a commit message - a brief summary of why the change was made. Having commit messages is very useful when you're scanning a long list of changes. As you can see, many of Wikipedia’s editors don’t know about commit messages, which makes scanning the many changes that have been made to their pages extra difficult.

At our events, we like to find a fun change that was made in the host school's wikipedia page. This was my personal favorite.

 

 

We ran back to back events at Bloomington and Purdue. This got a big laugh at both places. I especially like the commit message explaining why the change was deleted.

I have a project myself

 

 

that does not have a single line of code, but instead a bunch of scans of issues of a radical 1870s feminist newspaper, and text docs which are transcriptions of them.