One of the neat things about Open Source is all the things you get to learn about teamwork and coordinating with others. This can lead to great things, but sometimes it's so easy to start off excited, and then pick a project and drown immediately.

Bob Killen [recently distilled his contributor lessons](https://twitter.com/MrBobbyTables/status/1678823563527090185) over years of contributing to Kubernetes and other Cloud Native projects. Consider this the blog version:

# Research First

The best tip we can recommend is to educate yourself about the project, its community and their contributor processes BEFORE asking questions. Look for a CONTRIBUTING.md file in the repository and start from there.

People are much more willing to help you if you ask "Hey, I noticed this issue is still open. I’m interested in working on it, but couldn’t find info on <foo>, is there a good reference or person I can talk to about it?" vs "Hey, I’m new to <project> and want to contribute, where do I start"?

Starting with `good-first-issue` labelled issues never hurts, and you can use tools like [CLOtributor](https://clotributor.dev) to aggregate good first issues across projects, so if you fancy a certain language or tech stack you can start from a knowledgeable place.

# Give it a hot minute

If you open a PR, give it a little time before asking for reviews.

OSS is a global phenomenon that spans all time zones. It involves people that do it as a hobby on weekends, or others may do it as part of their $dayjob, but also have to balance it with their other projects.

That doesn't mean you need to wait forever before reaching out, but don’t go repeatedly asking for reviews right after opening your pull request. It may take a few days for the person to get to it. If it has been a bit, its okay to give it a nudge. Everyone is drowning in GitHub notifications, so don't be afraid to point out where you need a review, but just be cognizant of the load and be mindful of the existing open requests.

# Start with contributions you KNOW you can do.

Learning and growth are wonderful parts of Open Source, but when starting out, take on something in an area where you can flex your experience.

We can’t tell you how many people have reached out to maintainers asking to get involved in the most complex and difficult parts of the project without understanding the fundamentals. This leads to a lot of frustration both from the contributor and the maintainers.

Remember, the maintainers who work in those areas have likely been contributing for years. They didn’t just jump into it either.

# Trivial pursuits are not fun

Reviewing pull requests can take time. This usually involves running a bunch of automated test suites, then it can take a human a non-trivial amount of time to review a submission.

Make it count!

- Tired: Sending a pull request to an entire team to fix one misspelled word in the docs
- Wired: Spending a bit more time thinking about how best to improve multiple parts of the page

# Don’t over commit.

Related to the last one, but start small and with things you know you can do in a reasonable time frame.

It is common for new contributors to get excited and volunteer or self assign every new issue coming in, and in the end they can’t deliver on most of them. This frustrates them, the maintainers and the other potential new contributors getting started.

# Learn the git basics

You should be familiar with general pull request based workflow, branching, squashing and rebasing. You don’t have to be able to do them without looking up a reference, but know what they are and when they should be used. Certain projects [document their workflow](https://www.kubernetes.dev/docs/guide/github-workflow/) so that project conventions can be shared.

There are plenty of people who contribute non-code contributions and others that can get by without learning git, but you will have a MUCH better experience if you’re familiar with it and can have a basic working set of skills. Don't worry, git itself ensures that you will never truly understand it, so don't beat yourself up over it.

# Be intentional

Many of these tips boil down to one thing: if you want to contribute to a project, to become a maintainer, then be intentional. Learn what you can beforehand, be willing to continue to learn, and get engaged in the right places.

Maintainers will SERIOUSLY bend over backward to help or mentor those demonstrating that commitment, who will stick around, and who can be grown into future maintainers.

It's how the projects keep themselves going. Technical skills like git, CI/CD, and review workflow come with time and practice.