This is an atrocity, but I’m here to help! We’ll leave the silly dictionary gimmick for the end (you wouldn’t want a report on a new medical initiative to focus on how doctors use funny words like “stat”, would you?), but I’ll give you some definitions, too, because the linked video leaves you with more questions than answers.
What’s Github?
Github is a place to host coding projects. It incorporates a lot of cool social aspects.
Isn’t “Social” just something you tack onto the description of a project to get investors?
It is, indeed! But like most words that are horribly overused, “social” is horribly overused because it’s been attached to a lot of legitimately cool things. Github is one of those things.
What makes Github important?
The notion that I can collaborate with people I’ve never even met.
Code occupies an interesting niche: it’s a tremendously creative pursuit, but at the end of the day it’s mostly about accomplishing something practical. Working with physical objects naturally invites contention—after all, building a prototype can be expensive and every design decision can’t coexist in the same object. By contrast, creative pursuits tend to center around intangibles, which are easily copied and shared, and can exist in many forms simultaneously.
While the traditional artists haven’t let go of their egos enough to collaborate at any real scale, programmers have the additional incentive of a practical, working, final product. Those are difficult to make alone. So Github provides a mechanism for random people to come together to work on code collaboratively.
Now we should pause here to mention that Github didn’t invent open source or collaborative coding. They didn’t even invent the Git software upon which they operate. What they did was tie lots of great features together into something that’s easy to use.
If you are a programmer, or a technically inclined individual, you can peruse hundreds of thousands of works in progress to see how your peers go about solving problems similar to yours. If you spot something that you think could be improved upon, you can write a note in the margins of the code, “Have you considered doing this like X?” Now suddenly you’re a collaborator with a team of people you’ve never met and never thought you’d be working with. If you think you can make an improvement or fix a bug you can—again, right in your browser—make a copy of their code (called a “fork”; see the dictionary at the end), then make the change and point them at your version. If they like your work, they can pull your change into their own code.
Imagine doing this as a composer. There’s a website you can visit where hundreds of thousands of people post their work as they’re working on it. You can draw inspiration from their work or scribble suggestions to them. You’re allowed to make a copy of their work into your own workspace, then edit it to create your own version. For this you are not made to feel guilty or accused of stealing, because the point is to make great music. And the website tracks everyone’s contributions, so its easy recognize the people doing the hard work. (As a sidenote, I’ve long wanted to make a website just like this, so if you’re interested in helping, let’s start coding!)
So Github is a place to host coding projects that provides easy tools for people to collaborate on code. Those of us who work on code a lot appreciate being able to do the organizational work in a user-friendly way in the browser, rather than all at the command line. There are plenty of sites like Github, but they’ve become a dominant player because of their focus on the user experience (and in no small part the popularity of the underlying Git technology.)
A New New Dictionary?
“Repository” — the original report defines this as “a big chunk of code that can be edited.” I’m not sure why this bears defining. Repository here means what it always means: “A central clearing house.” In this case, of code and the history of the changes to that code. These are often referred to as “repos”, but that’s not particular to Github either.
“Forked” — defined in the report as “code editing”, but that isn’t right. Code editing is called… well, code editing. Forking a repository is making a full copy of it so you have your own personal version. Usually this is done so that you can edit code that you wouldn’t otherwise be able to edit. For example, if we’ve never met, I’m unlikely to let you edit the code to my project. But you could fork my project and now the fork is your project, which you’re free to edit. You might do this because you want to take my code in a different direction, or just so that you can make the change and point me to it as a suggestion of what to do.
“Pull request”—defined in the report as “requesting edit rights”, but this misses the point. It would be hard to collaborate if I had to trust everyone who wanted to contribute to my project. Github provides lots of easy tools that help me collaborate with people even if I don’t trust them yet. A pull request is one of these. If I make my project visible to others (as most projects are), you can fork it to get your own copy. Then you can make changes to your fork, publicly where I can see them. When your changes are done, you can package them up in a tidy little message called a pull request, which basically says “here are some changes I think you should pull into your project.” I can look at the request and, if I like your changes, incorporate them into my project with a single click. If I like your changes but I think they need improvement, I can comment on the pull request just like I can on any other code. And if I don’t like your changes, I can just ignore the request.
“Code writer”—this isn’t defined in the report, but it is used. Nobody knows what this means. Unless you’re high on paint-fumes, people who write code are called programmers.
