Presenter: Kevin Burke
Liveblogger: Farhan Attamimi
A guide to becoming a contributor to the Go project.
Kevin Burke talks us through his journey to becoming a contributor to Go. He encourages developers to start contributing with small changes to build trust and ownership, and gives tips on how you can make your first contributions.
It seems there's this magic threshold to becoming a contributor. Defining who is a contributor, and people wanting to become contributors reminds Kevin of a scene from the Truman show:
Just because the stdlib isnt changing that much doesn't mean there aren't tons of ways to contribute. Ashley McNamara's talk at GopherCon last year dispelled a myth that you have to be a programming wizard to contribute.
The easiest way to contribute is by using Go. Surely, most people at GopherCon do use Go, but at the margin, use Go more than you already are. Use Go in ways you're uncomfortable with and in ways its not typically used, and report back to the broader community.
When you are using Go, notice when things don't match up with your expectation, or are confusing, and dig in.
At one point, Kevin was working on a program that parsed all Go contributor emails. He ran into an unexpected issue where a particular email was causing
mail.ParseAddress to return an error:
mail.ParseAddress('A (middle) B <[email protected]>') >>> mail: no angle-addr
The error was confusing because angled brackets were there, and the error was appearing for another reason. This is a corner case, and therefore seems like a small fix. Many people might think it's too small to matter. But...
Russ Cox estimates that there are now 1.1 million Go developers. 1% of these developers use net/mail, this is 11000 people. If 1% hit this edge case, that means 110 people will potentiall see this. Fixing this one small edge case could impact 110 people and improve their development experience, so it does matter!
Another way to contribute is to simply tell someone when something doesn't work. Contributing error reports is a skill.
This is a guideline for writing and contributing good error reports. A good error report should answer:
A good error report can vastly increase the chances the issue gets fixed. Good reports are the difference from an issue that simple states "This doesnt work" to "This is why this thing is broken, and here's how it could be fixed".
When trying to diagnose errors, it is extremely helpful to compress a faulty program down to the smallest possible unit where you can reproduce the error. This is a valuable skill for contributing and getting issues fixed in Go and projects in general.
The 3 characteristics of an ideal reduced test case:
This reduced case is a simple 7-line program. The chances of this getting fixed are super high since it's easily reproducible:
The process of narrowing down a problem can lead to hypotheses on what the problem actual is, and helps you actually take a stab at fixing it.
Examples are code snippets that sit alongside documentation.
Examples help because people don't read anything on the internet. People scan for the information they're looking for, and examples have super high information density.
fmt package has a huge API, but it has a single example in the entire package:
Kevin gave this talk in October last year, and checked the
fmt package to see if there are any new examples. Still, nobody has added examples. Please contribute to it so Kevin can update his slides.
It's easy for docs to not exist or get out of date. If people don't use something you built, it's likely because the documentation is not up to par.
scrypt package will take a password into a 32-byte string such that it's very expensive to guess. This is valuable for hashing passwords on websites, etc. It has one function in this package called the
key function. The problem is the documentation references info from 2009:
Even if you know what the fix is going to be, file an issue. Other people will run into the same problem. Filing an issue is a good way to rank on Google highly, and get others to the information, since Google is often the entry point to documentation and issues. Communicates the progress of the issue.
Issue Kevin filed about the 2009 documentation:
This issue led to this contribution:
He updated the docs and made it future proof so people in years later can figure out what the params should be. This change included a comprehensive commit message, and followed contribution guidelines, which helps build trust with maintainers and gets you comfortable with contributing.
golang.org hosts a bunch of packages that are widely used. Compared to the core Go project, these are more experimental and the contribution process is less rigorous. This makes these packages a great place to get started and make code contributions. All of the code that makes up the Go build environment lives in the golang.org/x repos. For example, gopherbot:
This is the Trybot page:
When you submit a change, it is run it on all these different environments to make sure they're all happy with the change. The image above is the environment. The page is not very good, and there are a lot of improvements to be made. It's not been done because existing contributors may not have the time or skills to invest in this. A change to update this page would be really helpful to the Go team, and these contributions can be made by most people. Making changes like this gives you a sense of ownership over this tool, and spurs you on to make larger changes, introduces you to the team, and so on.
If you were street racing in Tokyo, it would make sense to make a flashy entrance nad announce your presence. But we're not. We're incrementally making a programming language better.
Your first contributions should be really small. There's a lot of other stuff going on beyond the actual code change when you first get started with contributing.
Kevin's first change was literally one character:
While the change isn't big, there is more going on here: he learned to follow the guidelines on how to contribute, which builds trust with the maintainers, and proves that he can make a change. And, ultimately, this tiny change is useful, as it saves people a redirect.
The next two changes came 2 months after his first change, and they were both fixing spelling mistakes. Again, not large changes, but helps to build this trust. After making these two changes, he started reading the commit logs, and noticed changes as they came in. This was useful to understand recent changes and the codebase in general, and may open up opportunities or generate ideas for things to fix.
Small commits are very common
Just because commits are small don;t mean they aren't important. It's a good way for the team to build trust in you, understand the contribution process, and build ownership over the codebase.
I've seen someone barely dip their toe into adjusting the Node.js website ...helped on-board more committers, and is now one of the top level decision makers in Node.js Core.
This is very common. Small commits are important because they open the door to larger ownership over the codebase.
This project lets you practice committing. You get a directory, and you can put anything you want in there. Then, people will review your change to make sure it fits the contributing guidelines. For example, this review makes sure the change has a license header with a copyright statement:
Practicing here is highly recommend to understand how the Go contributing process works. The contribution guidelines are different than most companies, so it's a good way to practice and understand.
There are many places where it's expected you'll get stuck (bad docs, confusing concepts, things you don't know you don't knoow), so reach out before giving up.
..as long as you're enthusiastic and open to feedback, it;ll be well received.