How to Make Your First CNCF Project Contribution (Docs, PRs, and Slack)

Introduction

In my guide on getting started with CNCF and KubeCon, step 3 was “make a non-code contribution first.” This post is the detailed version of that step, because it is the one most beginners get stuck on. Not because it is hard, but because nobody tells you the actual sequence, and guessing wrong wastes a lot of confidence.

Here is the sequence that consistently works, based on how CNCF’s own contributor documentation describes it and how experienced contributors describe their own first PRs.

Step 1: Use the Project Before You Contribute to It

This sounds obvious, but skipping it is the most common mistake. Install the project, run its getting-started tutorial, and use it the way a real user would before you touch its issue tracker. This is not wasted time. It is how you naturally discover the small gaps, typos, and confusing steps that make for a good first contribution, and it means your first PR comes from lived experience rather than a random issue you picked blind.

Step 2: Read CONTRIBUTING.md Before Anything Else

Every CNCF project has a CONTRIBUTING.md file in its GitHub repo. It tells you exactly how that specific project wants new contributors to behave, and it is different enough project to project that skipping it causes avoidable friction.

The one thing almost all CNCF and Linux Foundation projects share is the Developer Certificate of Origin (DCO). Instead of a separate legal agreement, you certify each commit is your own work by adding a sign-off line to your commit message.

git commit -s -m "Fix typo in installation guide"

The -s flag adds a Signed-off-by: Your Name <your-email> line automatically. Forgetting this is the single most common reason a beginner’s first PR gets blocked by an automated check, and it is a two-second fix once you know about it.

Step 3: Find a “Good First Issue”

Most CNCF project repos label beginner-friendly issues as good first issue or help wanted. Filter the issue tracker by these labels first. CLOTributor (clotributor.dev) is an official CNCF tool that searches “good first issue” tasks across every CNCF project at once, filterable by language and skill level, so you don’t have to browse each repo one by one. If a project has none open at the moment, that is normal too. Ask in the project’s Slack channel or comment on the project board rather than assuming there is nothing for you.

Resist the urge to jump into three projects at once. Pick one, understand its workflow deeply, and get your first PR merged there before branching out.

Step 4: Claim the Issue Before You Start

Before writing any code or docs changes, comment on the issue saying you would like to work on it. Something as simple as “I’d like to work on this” is enough. This avoids two contributors duplicating the same work, and it is standard etiquette across CNCF projects.

Step 5: Join the Project’s Slack Channel and Say Hello

CNCF hosts a shared Slack workspace at slack.cncf.io, and most individual projects have their own channel inside it (#argo-general, #prometheus, #opentelemetry, and so on). Introduce yourself briefly, mention the issue you picked, and ask questions there if you get stuck. This is also the same channel where you will eventually see mentorship opportunities and community calls announced, so joining it early pays off beyond just this one contribution.

Step 6: Submit a Small, Focused Pull Request

Keep your first PR narrow. Fix the one thing the issue describes, nothing more. Fill out the PR template completely if the project has one, since it directly helps reviewers understand your change faster. Expect code review feedback. It is a normal part of the process and not a judgment on you personally, even when the comments read as blunt or terse. Most maintainers reviewing your PR are volunteers fitting it in around their day jobs.

Non-Code Ways to Contribute

If you are not comfortable with code yet, or your background is not development, these all count as real contributions:

• Fixing documentation typos or unclear steps
• Reviewing open pull requests and leaving genuine feedback
• Triaging issues: reproducing a bug report and adding reproduction details
• Helping answer questions in the project’s Slack channel
• Contributing to the Cloud Native Glossary, which explicitly welcomes non-native English speakers and first-time contributors
• Joining a Technical Advisory Group (TAG) or Working Group (WG) discussion without writing any code at all

None of these require you to be a strong Go developer, even though a large share of CNCF projects are written in Go.

What Happens After Your First PR Merges

Nothing dramatic, and that is the point. You now understand one project’s contribution workflow end to end. From here, the natural next step is either going deeper into that same project, or applying that experience to an LFX Mentorship application, where prior contribution experience to the project is one of the strongest signals a mentor looks for.

Conclusion

Your first CNCF contribution is not about proving you are a strong engineer. It is about proving you can follow a project’s process, communicate clearly, and finish something small. Do that once, and every next contribution gets easier because the workflow stops being unfamiliar.

Happy Engineering!