A comprehensive guide for new contributors to the Cloud Native Computing Foundation (CNCF) ecosystem, compiled from real community conversations in the #cncf-new-contributors Slack channel spanning from November 2023 to December 2025.
This document represents the collective wisdom of hundreds of community interactions, distilled into actionable guidance for anyone looking to begin their journey in the cloud native open source world.
- Getting Started
- Finding the Right Project
- Finding Issues to Work On
- Understanding Large Codebases
- Technical Skills & Learning Go
- Non-Code Contributions
- Mentorship Programs (GSoC, LFX)
- Kubernetes-Specific Contributions
- Community Engagement
- KubeCon & Events
- Career Development
- Common Challenges & Solutions
- Essential Resources
A: Welcome to the cloud native community! You're joining a vibrant ecosystem of developers, operators, and enthusiasts who are building the future of computing infrastructure. The journey can seem daunting at first—there are over 180 projects in the CNCF landscape, each with its own community, codebase, and contribution processes—but don't let that intimidate you.
The single best starting point is contribute.cncf.io/contributors/getting-started. This comprehensive guide was created specifically to help newcomers navigate the ecosystem and covers:
- What CNCF is and how it operates as an organization
- The different ways you can contribute (code, documentation, community, and more)
- How to find projects that match your interests and skill level
- Community norms, expectations, and cultural guidelines
Before diving into Slack channels to ask questions, community members strongly recommend taking time to explore what's already available. This isn't gatekeeping—it's practical advice born from experience. The #cncf-new-contributors channel has seen the same questions asked hundreds of times, and nearly all of them have been thoroughly answered in the pinned resources.
Here's what you should do first:
- Read through the pinned items at the top of the channel (click the pin icon)
- Check the bookmarks section for curated resources
- Scroll through previous conversations to see how others have navigated similar situations
- Visit the resources linked in the channel description
This self-guided exploration will give you context that makes subsequent conversations much more productive. When you do ask questions, you'll be able to ask specific, targeted questions that community members can answer meaningfully.
A: After you've familiarized yourself with the basic resources, here's a practical progression that has worked for countless contributors before you:
Week 1: Exploration Phase
Start by exploring the CNCF Landscape. This visual map shows every CNCF project organized by category—from container runtimes and orchestration to observability, security, and beyond. Spend time understanding what problems different categories of projects solve. Don't rush this phase; understanding where projects fit in the ecosystem will help you make better decisions later.
As you browse, identify two or three areas that genuinely interest you. Maybe you're fascinated by how distributed systems maintain consistency, or perhaps you're drawn to security challenges in containerized environments. Your interests will guide your contribution journey, so it's worth reflecting on what excites you.
Week 2: Narrowing Down
Join the Slack channels for the projects that caught your attention. Most projects have at least one channel, and larger projects often have multiple (like #project-dev for developers and #project-users for users). Lurk for a while. See what questions people are asking, how maintainers respond, and get a feel for the community culture.
Subscribe to the project's mailing list if they have one—many important discussions happen there rather than in Slack. Look for Google Groups or links in the project's README or CONTRIBUTING file.
Week 3: Active Engagement
Attend a community meeting. Almost every CNCF project holds regular video calls where contributors discuss ongoing work, review proposals, and answer questions. These meetings are almost always recorded, so you can watch previous sessions first to understand the format. When you're ready, join a live call. You don't need to say anything—just listening is valuable. But if you feel comfortable, introduce yourself briefly. Communities appreciate knowing who's watching and interested.
Week 4: First Contribution
Start small. Your first contribution doesn't need to be a complex feature or major bug fix. In fact, it probably shouldn't be. Consider:
- Fixing a typo in documentation
- Improving an error message
- Adding a missing test case
- Clarifying confusing documentation
These small contributions help you learn the contribution workflow (forking, branching, submitting PRs, responding to reviews) without the pressure of complex code changes. They also help you build relationships with maintainers who will review your work.
A: First, know that this feeling is completely normal and almost universal among new contributors. The cloud native ecosystem is vast and complex, and it takes time to develop mental models for how everything fits together. Even experienced engineers who are new to this space report feeling overwhelmed initially.
Here's how to work through the fog:
Pick ONE project and commit to it. This is perhaps the most important piece of advice. The natural instinct when feeling lost is to cast a wide net—join many channels, explore many projects, try to learn everything at once. This approach almost always leads to shallow engagement and slower progress. Instead, choose a single project and go deep. You can always expand later once you've established yourself somewhere.
Get the project running locally. This is non-negotiable for code contributions and incredibly valuable even for documentation work. Clone the repository, follow the development setup instructions, and get the project building and running on your machine. This process will teach you more about the project than hours of reading documentation. You'll encounter real problems and learn how to solve them. If the setup instructions are unclear or broken, congratulations—you've found your first contribution opportunity!
Join the project's Slack channel and introduce yourself. A simple message like "Hi, I'm [name], and I'm interested in contributing to [project]. I've got it running locally and I'm looking for a good first issue to work on" goes a long way. Most communities are welcoming and will point you in the right direction.
Attend a community meeting and show your face. Video calls can feel intimidating, but they're one of the best ways to build relationships in open source. Maintainers remember people they've seen in meetings, and that familiarity makes future interactions smoother. You'll also hear about work that needs doing that might not be captured in GitHub issues.
Ask specific questions rather than general ones. "How do I contribute?" is hard to answer because there are so many possible responses. "How do I set up the development environment for [project] on macOS?" or "I'm trying to fix issue #1234 but I'm not sure where the relevant code lives—can someone point me to the right files?" are much easier to answer and more likely to get helpful responses.
A: This varies widely depending on your background, the complexity of the project, and how much time you can dedicate. However, based on community experiences, here's a rough timeline:
First month: You're learning the basics—how to navigate the codebase, who the key maintainers are, what the contribution workflow looks like. You might make your first small contribution (documentation, typo fix, small bug fix).
Months 2-3: You're starting to understand the architecture. You can follow discussions in meetings and mailing lists. You're probably working on slightly more substantial contributions and getting feedback on your PRs.
Months 4-6: You've built relationships with other contributors. You're reviewing other people's PRs (this is a great way to learn!). You understand the project's roadmap and can identify where help is needed.
After 6 months: You're a recognized contributor. People know your name. You might be mentoring newcomers yourself.
Remember, this is a marathon, not a sprint. Consistent, sustained engagement matters more than intense bursts of activity. Many successful contributors report that their most productive period was after a year or more of involvement.
A: This is one of the most common questions in the channel, and the community has developed a clear philosophy about it. The key insight, shared by contributors with decades of open source experience, is that you should choose based on interest rather than current skills.
One community member with over 15 years of FOSS experience put it eloquently:
"Matching projects to your existing skills is the wrong way to approach it, unless you don't aim to build up your skills set. Instead, I'd suggest you to consider this approach: 1) Define your interests, 2) Find projects that match your interests, 3) Build skills to match the projects of your interests. IOW, interests should drive your skills development. It usually though is the step 1 that is the hardest part. Skills are like hammers, it is easy to learn how to use a new hammer, but it is usually very difficult to figure what you would really love to build with the (new) hammer in hand."
This advice might seem counterintuitive at first. After all, if you're already proficient in Python, wouldn't it make sense to find Python projects? But consider this: you'll be spending months or years working on this project. If you choose something solely because it matches your current skills but don't find the problem domain interesting, you'll likely lose motivation and drift away. Conversely, if you're genuinely excited about a project's mission, learning a new language or technology becomes part of the adventure rather than a barrier.
Practical approach to finding your project:
Step 1: Explore problem domains, not technologies. Browse the CNCF Landscape by category. Ask yourself: Do I care about making systems more observable and debuggable? Am I passionate about security and protecting infrastructure from attacks? Do I find distributed data storage fascinating? Am I interested in how applications get deployed and managed? Your answers will point you toward project categories.
Step 2: Research a few candidates. For each project that catches your interest, read the project's main README and documentation. Try to understand: What problem does this solve? Who uses it? What makes it different from alternatives? Watch an introductory talk on the CNCF YouTube channel.
Step 3: Evaluate the community. This is often overlooked but critically important. A welcoming, active community makes the difference between a great experience and a frustrating one. Look for:
- Recent GitHub activity (PRs being merged, issues being responded to)
- Active Slack channels with helpful discussions
- Regular community meetings
- Clear contribution guidelines
- "Good first issue" labels that are actually maintained
Step 4: Try before you commit. Before diving deep, spend a week or two with your top candidate. Join the Slack, attend a meeting, try to run the project locally. See if the community feels like a place you want to spend time. If not, move to your next candidate.
A: CNCF categorizes projects into three maturity levels, and understanding these can help you choose where to focus your efforts:
Graduated Projects
These are the flagships of the CNCF ecosystem—projects that have proven themselves through widespread adoption, robust governance, and demonstrated sustainability. Examples include Kubernetes, Prometheus, Envoy, Helm, Containerd, and CoreDNS.
Advantages of contributing to graduated projects:
- High impact: your work affects millions of users
- Excellent documentation and well-established processes
- Large communities with many people to learn from
- Strong resume signal for career advancement
Challenges:
- Can be intimidating due to large, complex codebases
- Harder to have significant impact as an individual contributor
- More established hierarchies can mean slower advancement
- Competition for high-profile issues
Incubating Projects
These projects are growing and maturing but haven't yet reached graduation. Examples include Argo, Flux, Knative, OpenTelemetry, Falco, and many others.
Advantages:
- More opportunities to make significant contributions
- Communities are often actively seeking new contributors
- Still substantial user bases and real-world impact
- More room to shape the project's direction
Challenges:
- Processes may be less polished
- Documentation might have gaps
- Community size varies widely
Sandbox Projects
These are early-stage projects that CNCF has accepted but that are still proving themselves. The sandbox is designed to be the entry point for emerging technologies.
Advantages:
- Highest potential for individual impact
- Often more personal attention from maintainers
- Opportunity to be a founding contributor
- Less complex codebases to understand
Challenges:
- Higher risk of project not succeeding
- May have limited resources and documentation
- Smaller user communities
For new contributors, incubating and sandbox projects are often the best starting point. The communities tend to be more accessible, and there's more room to grow. However, if you're specifically interested in a graduated project, don't let that discourage you—every project welcomes new contributors who are genuinely engaged.
A: While the philosophy is to choose by interest, it's also helpful to know where your existing skills apply. Here's a mapping based on common backgrounds:
For Go developers (or those willing to learn Go): You're in luck—Go is the dominant language in the CNCF ecosystem. Kubernetes, Prometheus, Envoy (some components), Helm, Harbor, Argo, Flux, and dozens of other projects use Go as their primary language. You'll have the widest selection of projects to choose from. If you don't know Go yet, learning it opens the most doors.
For Python developers: KubeFlow is the primary home for Python in CNCF, focusing on machine learning operations. OpenTelemetry has Python SDKs and instrumentation libraries. Various CLI tools and integrations use Python. The Cloud Native AI (CNAI) space is growing and often Python-friendly.
For JavaScript/TypeScript developers: Backstage is your flagship project—a developer portal platform built with TypeScript and React. It's a large, active project with a welcoming community. Various web UIs and dashboard projects also use JavaScript/TypeScript.
For Java developers: Strimzi (Kafka on Kubernetes) is Java-based. Many enterprise integrations and operators are written in Java. The ecosystem is smaller than Go but growing.
For Rust developers: Linkerd2-proxy is written in Rust and represents cutting-edge work in service mesh technology. Several newer projects are exploring Rust for performance-critical components. This is a growing area.
For security professionals: TAG Security welcomes contributors interested in security practices across the ecosystem. Project-specific options include Falco (runtime security), Kubescape (security posture management), Open Policy Agent (policy as code), and SPIFFE/SPIRE (identity).
For networking experts: Cilium, Envoy, Linkerd, and various CNI plugins are central to cloud native networking. The TAG Network group coordinates networking-related efforts.
For ML/Data Science practitioners: KubeFlow is the primary project, covering the entire ML lifecycle on Kubernetes. The Cloud Native AI space is rapidly evolving with new projects and initiatives.
For DevOps/SRE practitioners: Argo (workflows, CD, events, rollouts), Flux (GitOps), Crossplane (infrastructure as code), and many others directly address DevOps workflows. Your operational experience is valuable for documentation, testing, and real-world feedback.
A: Yes, absolutely—many experienced contributors work across multiple projects. However, the strong recommendation from the community is to start with one project and establish yourself there first.
Here's why this matters: Building influence and relationships in an open source community takes time. Maintainers need to recognize your name, understand your capabilities, and trust your judgment. This trust is built through consistent, quality contributions over months, not days. If you spread your attention across five projects, you'll make slow progress in all of them and won't build the depth of relationships that make contribution rewarding.
A good rule of thumb:
- First 6 months: Focus on one project
- Months 6-12: Consider occasionally contributing to a second related project
- Year 2 and beyond: Expand as your time and interests allow
Many contributors find that going deep on one project teaches skills and patterns that transfer to other projects anyway. The mechanics of Kubernetes contribution, for example, have influenced processes across the ecosystem.
A: Finding the right first issue is crucial—you want something challenging enough to learn from but not so complex that you get stuck. The CNCF community has created excellent tools specifically for this purpose.
CLOTributor: Your Best Friend
The community's top recommendation is CLOTributor. This purpose-built tool aggregates contribution opportunities across the entire CNCF ecosystem and makes them searchable and filterable.
"Take special note of the section 'Be sure to visit the CLOTributor website to find open issues suitable for new contributors.'" — Community guidance
Here's how to use CLOTributor effectively:
-
Start with filters: Click on "Filters" and select "good first issue" to see only beginner-friendly issues. You can also filter by project, programming language, and more.
-
Read before claiming: Don't just grab the first issue you see. Read through several options and choose one where you understand the problem being described, even if you don't yet know the solution.
-
Check the issue's age and activity: An issue opened two years ago with no comments might be stale or already fixed. Recent issues with maintainer engagement are better candidates.
-
Comment before starting: Leave a comment expressing interest: "Hi, I'd like to work on this. Is it still available?" This prevents duplicate work and opens a dialogue with maintainers who can provide guidance.
GitHub Labels: Direct from the Source
Every CNCF project uses GitHub for source control, and most use standardized labels to mark issues suitable for newcomers:
good-first-issueorgood first issue— Explicitly marked as suitable for new contributorshelp-wantedorhelp wanted— Maintainers are actively seeking helpbeginner-friendly— Similar to good first issuelow-hanging-fruit— Easy to tackle with limited contextdocumentation— Often a great entry point regardless of coding skill
You can search directly on GitHub. For example, to find good first issues in the Kubernetes org:
is:open is:issue label:"good first issue" org:kubernetes
Community Meetings and Mailing Lists
Don't underestimate the value of attending meetings and following mailing lists. Maintainers often mention work that needs doing in conversation before it becomes a formal issue. If you hear someone say "we really need to clean up the error handling in that module" and offer to help, you've found work that might not be captured anywhere else.
Project Roadmaps
Many projects publish roadmaps showing planned work. Look for items marked as "needs contributor" or similar. These give you context about where the project is heading and let you align your contributions with the project's priorities.
A: This is a common concern, especially when you're just starting out. Here are several strategies:
Create your own issues. The best way to find issues is often to use the project as a real user. Deploy it, configure it, try to accomplish real tasks with it. When you hit confusing documentation, unclear error messages, or bugs—congratulations, you've found contribution opportunities. File an issue describing what you encountered, and offer to fix it yourself. Maintainers love contributors who find and fix their own issues.
Documentation is always needed. Every project needs better documentation. Try to follow the getting started guide as a new user. Where did you get confused? What steps were missing? What worked but wasn't explained? Turn your learning experience into documentation improvements. This requires no special access and minimal code knowledge but provides tremendous value.
Testing is perpetually understaffed. Review the project's test coverage. Are there code paths without tests? Edge cases not handled? Adding tests is valuable work that also teaches you the codebase. You have to understand what code does to test it effectively.
Review other people's PRs. This might seem backward—how can you review if you're new?—but it's one of the best learning techniques. Read through open PRs. Try to understand what they're changing and why. Leave thoughtful comments, even if just asking questions about things you don't understand. This demonstrates engagement and helps you learn. Maintainers appreciate having more eyes on code.
Triage issues. Many projects have large backlogs of issues that haven't been categorized, prioritized, or verified. Offer to help triage: reproduce bugs, ask clarifying questions, add labels, identify duplicates. This is valuable work that requires no code and teaches you about the project.
A: This is more nuanced than it might appear. Just because someone is assigned to an issue doesn't mean they're actively working on it.
Check for recent activity. Look at the issue's history. Is the assignee actively commenting? Have they submitted a draft PR? If the last activity was months ago, the issue may be effectively abandoned.
Ask politely. Leave a comment: "Hi @assignee, I'm interested in this issue. Are you still working on it, or would you be open to me taking it over? Happy to collaborate if you'd like to pair on it." Most people are understanding about life getting in the way of open source work.
Look for collaboration opportunities. Sometimes the assigned person has started but gotten stuck. Offering to help complete the work together can be welcome. Open source is collaborative by nature.
Find related issues. Many issues have related problems in the backlog. If the specific issue you wanted is taken, look for similar ones in the same area of the codebase.
Consider whether it's actually blocked. Sometimes issues are assigned but have dependencies on other work. Understanding these relationships might reveal other issues you could tackle that would unblock the original one.
A: This challenge comes up repeatedly in the channel, and the community has developed battle-tested strategies for tackling it. The key insight is that you don't need to understand the entire codebase—you need to understand enough to make your first contribution, and understanding will grow organically from there.
Step 1: Get the project running locally (Non-negotiable)
Community leader dims emphasizes this repeatedly:
"The idea is to be able to modify some code and build things and then run it. That's the first step I try to get to when I start looking at a new project. Once you have that then you can try things. If you can't do this then no amount of looking at code will help."
This might seem obvious, but many newcomers skip this step, trying to understand code by reading alone. That rarely works. When you can run the code, you can:
- Set breakpoints and step through execution
- Add print statements to trace flow
- Modify code and see what breaks
- Run tests to understand expected behavior
The setup process itself teaches you about dependencies, architecture, and project structure.
Step 2: Understand through PR reviews
This is perhaps the most underrated learning technique:
"Next step is to regularly do PR reviews in one or two repos. Regularly does not mean 24x7. It means every week set aside some time to dig into reviews (or issue triage or both). That's the way to know who is doing what and where and what code they are changing for which feature or bug. If you do this consistently then you will get the hang of it."
Why does this work so well? Each PR is a focused change with context. The PR description explains why the change is being made. The diff shows exactly what code is affected. Review comments from maintainers teach you about project conventions and subtleties. Over time, these small windows into the codebase build into comprehensive understanding.
Step 3: Engage with the community
"Then plug yourself into where they talk about new features etc, join their calls, mailing list, slack etc. There are a lot of things that people talk about but don't end up as an issue. If you can pay attention and pick some stuff and use that to open an issue and PR, you are on the next step of the journey."
The codebase is only half the story. Understanding why decisions were made, what problems people are trying to solve, and where the project is heading gives context that makes the code more comprehensible.
A: Many projects have recorded code walkthroughs that can dramatically accelerate your understanding. These are gold mines for newcomers.
Kubernetes:
- Code Base Tour: kubectl — A detailed walkthrough of how the kubectl CLI is structured
- A Tour of the Kubernetes Source Code — IBM's comprehensive written guide
Istio:
- Istio Code Walkthrough — Tetrate's tour of the Istio codebase
General CNCF:
- Search the CNCF YouTube channel for "[project name] code walkthrough" or "[project name] deep dive"
- Look for "maintainer track" talks from KubeCon—these often dive into architecture and implementation details
The community suggests:
"Look through the PDFs for talks that are interesting from last KubeCon, especially those marked as 'intro' or 'introduction' in the title. Click on each talk and you can see the PDF for the same. You can also find the video for each talk by searching YouTube."
Finding project-specific resources:
When you've identified a project you're interested in, search for:
- "[project name] architecture"
- "[project name] deep dive"
- "[project name] contributor guide"
- "[project name] getting started"
Many projects also have their own YouTube channels or playlists with technical content.
A: Beyond the high-level strategy, here are specific tactical techniques recommended by the community:
Write tests for existing code. One community member shared:
"It's also an idea to write some unit tests or e2e tests for existing code. It's going to give you a good understanding of the code and also I am sure it's going to figure out some bugs or improvement areas!"
This technique forces you to understand what code is supposed to do, not just what it currently does. You'll discover edge cases, undocumented behavior, and sometimes bugs.
Trace a single request from start to finish. Pick a specific operation (e.g., "create a pod" in Kubernetes, "record a span" in OpenTelemetry) and follow it through the entire codebase. Use your IDE's "find references" feature to jump from function to function. This gives you a concrete path through the code rather than trying to understand everything at once.
Start with the tests. Tests often explain intended behavior more clearly than documentation. Before reading implementation code, read the tests for that code. They show how the code is meant to be used and what invariants it maintains.
Use your IDE effectively. Modern IDEs offer powerful navigation features:
- "Go to definition" — Jump to where a function/type is defined
- "Find usages" — See everywhere something is called
- "Find implementations" — For interfaces, see all concrete implementations
- Breakpoints and debugging — Step through actual execution
- Search across the codebase — Find all occurrences of a term
Read the project's architecture documentation. Many projects have architecture docs, ADRs (Architecture Decision Records), or design documents. These explain why things are structured a certain way, which is often more valuable than understanding what the code does.
Ask questions. If you've made a genuine effort to understand something and are still stuck, ask in Slack or in the issue thread. Explain what you've tried and where you're confused. Most maintainers are happy to point you in the right direction. Good questions show engagement and can even surface documentation gaps.
A: The honest answer is: it depends on what you want to do, but knowing Go dramatically expands your options.
Go is the dominant language in the CNCF ecosystem. Kubernetes, Prometheus, Envoy's control plane, Helm, containerd, CoreDNS, etcd, and dozens of other major projects are written primarily in Go. This isn't an accident—Go was designed at Google specifically for the kind of infrastructure work that CNCF projects do: concurrent, networked, systems programming.
That said, you can absolutely contribute without knowing Go:
Projects using other languages:
- Python: KubeFlow (ML operations), OpenTelemetry (Python SDK and instrumentation), various tools
- TypeScript/JavaScript: Backstage (developer portals), various web UIs
- Rust: Linkerd2-proxy (high-performance networking)
- Java: Strimzi (Kafka on Kubernetes), various enterprise integrations
Contribution types that don't require any particular language:
- Documentation improvements
- Issue triage and user support
- Testing and QA
- Community management
- Blog posts and tutorials
- Design and UX work
However, if you're planning to become a significant code contributor to the CNCF ecosystem, learning Go is one of the best investments you can make. The language is designed to be simple and learnable, and proficiency opens doors to most major projects.
A: The community has converged on a recommended learning path:
Phase 1: Official tutorials (1-2 weeks)
Start with the official resources, which are excellent:
- Tour of Go: An interactive tutorial that runs in your browser. Takes a few hours and covers all the basics.
- Go by Example: Practical examples of common patterns. Great reference to return to.
- Go Learn page: Curated learning resources from the Go team.
Phase 2: Build something small (1-2 weeks)
Don't try to contribute to a CNCF project immediately. First, build something small on your own:
- A CLI tool that does something useful
- A simple HTTP server
- A program that reads and transforms data
This gives you a safe environment to make mistakes and learn.
Phase 3: Read good Go code (ongoing)
One community member shared this gem:
"The underrated way to learn a new language is from code reviews!"
Read the Go standard library source code: github.com/golang/go/tree/master/src. It's idiomatic, well-documented, and written by the language designers. Reading how the standard library implements things teaches you Go patterns better than any tutorial.
Also review PRs in CNCF projects you're interested in. You'll see how experienced Go developers write and how maintainers give feedback.
Phase 4: Read "The Go Programming Language" (optional but recommended)
The book by Donovan and Kernighan is slightly outdated (predates modules) but provides excellent foundations. It's particularly good for understanding Go's philosophy and design decisions.
A: Go was explicitly designed to be simple and learnable. Rob Pike, one of Go's creators, has talked about designing a language that new Google engineers could become productive in quickly. This design philosophy benefits you.
Go's characteristics:
- Syntax: Clean and minimal. Reads somewhat like C but simpler. No inheritance hierarchies to untangle.
- Concurrency: Goroutines and channels are unique to Go and the biggest new concept for most learners. They're also one of Go's greatest strengths.
- Tooling: Excellent built-in tooling.
gofmtmeans you never argue about style.go vetcatches common mistakes.go testis built-in. - Errors: Go handles errors explicitly rather than with exceptions. This takes adjustment but leads to clearer code.
Transition patterns by background:
Coming from Python: You might find Go verbose initially—there's more boilerplate, explicit type declarations, and no list comprehensions. But you'll appreciate the clarity once adjusted, and the performance difference is dramatic.
Coming from Java: You'll feel at home with interfaces and static typing. Go's interfaces are simpler (implicit rather than explicit). The lack of generics until recently was frustrating; now they exist but are used sparingly.
Coming from JavaScript/TypeScript: The biggest adjustment is static typing and compilation. Go's type system is simpler than TypeScript's. You'll need to think about memory and pointers, though Go's garbage collection handles most complexity.
Coming from Rust: Go will feel easy. You'll miss Rust's expressiveness and ownership model, but you'll appreciate faster compilation and simpler mental models.
Realistic timeline: Most developers report becoming productive in Go within 2-4 weeks of focused learning. Becoming truly idiomatic takes longer—maybe 2-3 months of regular use. But you can make valuable contributions well before reaching that point.
A: Emphatically yes! Non-code contributions are not just welcome—they're essential to project health. Community leader dims has emphasized:
"Plenty of things to do for non-code contributions as well!"
Projects need far more than code. They need documentation, testing, community management, design, and advocacy. In many ways, non-code contributions are undervalued relative to their importance—which means there's often more opportunity and less competition in these areas.
Documentation
Every project needs better documentation. Tutorials, reference guides, architecture documents, troubleshooting guides, migration guides—the list is endless. Documentation is often the first experience users have with a project, so improvements here have outsized impact.
What makes documentation contribution accessible:
- You don't need deep technical knowledge to notice unclear instructions
- Your fresh perspective as a newcomer is actually valuable—you can identify what's confusing
- The feedback loop is fast—you can see your changes immediately
- It's often the lowest barrier to getting a PR merged
How to get started:
- Try to follow the project's getting started guide
- Note everywhere you got confused or had to search for additional information
- Open a PR improving those areas
- Rinse and repeat for other documentation
Issue triage
Large projects accumulate hundreds or thousands of open issues. Many haven't been categorized, verified, or prioritized. Triage work involves:
- Reproducing reported bugs to confirm they're real
- Adding labels to categorize issues
- Identifying duplicate issues
- Asking reporters for additional information
- Closing issues that are stale or no longer relevant
This work requires no code but requires understanding the project well enough to categorize issues accurately.
Community management
Open source communities need people who:
- Welcome newcomers and help them get oriented
- Organize and run meetings
- Maintain community calendars and resources
- Moderate discussions and resolve conflicts
- Build relationships between contributors
If you're a people person, this might be your niche.
Testing and QA
You don't need to write tests to help with testing:
- Manual testing of releases before they go out
- Reporting bugs you find during testing
- Writing test plans and test cases
- Validating that fixes actually work
Technical writing and content
Beyond documentation, projects need:
- Blog posts explaining features or use cases
- Tutorials and how-to guides
- Conference talk proposals
- Case studies from real-world usage
- Video content and screencasts
Design
Projects need UX and visual design for:
- Websites and documentation sites
- CLI output and error messages
- Dashboards and web UIs
- Logos and branding
- Diagrams explaining architecture
Translation and localization
Many projects want to support non-English speakers. If you're fluent in another language, translation work is extremely valuable.
A: Each project handles blog contributions differently, but here's general guidance:
For the main CNCF blog: Follow the CNCF Blog Guidelines. The CNCF blog accepts:
- Announcements about CNCF projects
- Technical tutorials and how-tos
- Case studies from organizations using CNCF projects
- Opinion pieces on cloud native topics
Submit via PR following the guidelines, or contact CNCF marketing for larger pieces.
For project-specific blogs:
Most projects that have blogs host them in their documentation repository. For example:
- Knative: github.com/knative/docs — look in the blog directory
- Istio: github.com/istio/istio.io — similar structure
To find a project's blog contribution process:
- Look at their website for existing blog posts
- Find the repository behind the website
- Look for CONTRIBUTING.md or blog guidelines
- Study existing blog post PRs for format
Pro tip from the community:
"I think a better idea is to help review the blogs in their queue first"
Before submitting your own blog post, review other people's blog PRs. This helps you:
- Understand the expected format and style
- Build relationships with maintainers who review content
- Learn what topics have already been covered
- Give back to the community
When you do submit your own post, you'll know the process and have established credibility.
A: Several resources are specifically designed for non-code contributors:
- CNCF Non-Code Contributors Guide — Official starting point
- Kubernetes Non-Code Contributions — Kubernetes-specific guidance
- Incentivizing Non-Code Contributions — Framework document
- Getting Started in Kubernetes with Non-Code Contributions — Salesforce's guide
Join the #tag-cs-non-code-contrib channel in CNCF Slack to connect with others focused on non-code contributions.
A: CNCF participates in two major mentorship programs that provide structured, supported opportunities for contributors, often with stipends:
Google Summer of Code (GSoC)
GSoC is Google's flagship program connecting students and newcomers with open source organizations. CNCF has participated for many years, and dozens of CNCF projects offer mentorship projects.
- Duration: Flexible, with 90-hour, 175-hour, and 350-hour project sizes
- Stipend: Yes, amount varies by location
- Timeline: Applications typically open in spring
- Eligibility: Open to newcomers to open source who are 18+
- Repository: github.com/cncf/mentoring/tree/main/programs/summerofcode
LFX Mentorship
LFX is the Linux Foundation's own mentorship program, with multiple cohorts throughout the year.
- Duration: 12 weeks per term
- Stipend: Yes, $3,000-6,000 depending on location
- Timeline: Three terms per year (spring, summer, fall)
- Eligibility: See LFX Eligibility Guide
- Portal: mentorship.lfx.linuxfoundation.org
Both programs are tracked at: github.com/cncf/mentoring
A: The most important thing to understand is that preparation should start well before applications open. By the time applications are due, you should already be a known contributor to the project you're applying to.
Here's a timeline-based approach:
3-6 months before applications:
Start exploring the CNCF ecosystem and identify projects that interest you. This is the "finding your project" phase covered earlier in this FAQ. Don't worry about specific mentorship projects yet—focus on understanding the project and community.
2-3 months before applications:
Begin contributing to your target project. Start small—documentation improvements, bug fixes, answering questions in Slack. The goal is to:
- Get familiar with the contribution workflow
- Build relationships with maintainers who might be mentors
- Demonstrate consistent, quality work
- Show up at community meetings
Community guidance emphasizes this point:
"Get to know the project between now and when the deadlines are due and possibly reach out to the mentors (after you get familiar with the project and previous work) and see if there is a scope for follow-on work. You could even help write a proposal if the mentors are up for it."
1-2 months before applications:
Study past projects to understand what successful proposals look like. Review:
- Previous mentorship projects for the organization
- The project idea list as it develops
- Comments from mentors on the mailing list or Slack
If a project idea interests you, reach out to the listed mentor. Ask clarifying questions about the scope, express your interest, and discuss how you might approach it.
When applications open:
By this point, you should have:
- Multiple contributions merged to the project
- Relationship with at least one potential mentor
- Clear understanding of the project idea you're applying for
- Draft proposal that you've discussed with the mentor
Write a strong proposal that demonstrates:
- Your understanding of the problem
- A realistic timeline with concrete milestones
- Awareness of potential challenges
- Your relevant background and previous contributions
A: Project ideas are published in the mentoring repository:
- GSoC ideas: github.com/cncf/mentoring/blob/main/programs/summerofcode/
- LFX projects: Listed on the LFX Mentorship Portal
For GSoC, there's typically a deadline for projects to submit ideas (e.g., March 11). The list develops over time, so check back regularly.
Important nuance: Not all mentorship opportunities are published as formal ideas. If you've been contributing to a project and have a mentor relationship, you might propose your own project idea. Some of the best mentorship experiences come from contributor-proposed projects that address real needs the contributor identified through their work.
A: Eligibility requirements are documented at:
Key requirements typically include:
- Age 18 or older
- Legal right to work in your country of residence
- Availability for the program duration
- Not currently employed full-time by a Linux Foundation member company (check current rules)
Requirements may change between terms, so always check the current documentation.
A: It depends on the specific program and project:
GSoC offers multiple project sizes specifically to accommodate different schedules:
- 90-hour projects (~10 hours/week for 9 weeks)
- 175-hour projects (~15-20 hours/week)
- 350-hour projects (more traditional full-time commitment)
The smaller project sizes may be feasible alongside employment, though it requires careful time management.
LFX typically expects a more substantial time commitment. Check current requirements on the LFX portal.
If you're employed, be transparent with your mentor about your availability. Many mentors are willing to work with contributors who have limited time, as long as expectations are set clearly upfront.
A: Kubernetes is by far the largest project in the CNCF ecosystem, with its own extensive infrastructure for contributor onboarding. While the principles from the rest of this FAQ apply, Kubernetes has additional resources worth knowing about.
Step 1: Join Kubernetes Slack
Kubernetes has its own Slack workspace, separate from the main CNCF Slack. Get an invite at slack.k8s.io.
Step 2: Read the contributor documentation
The Kubernetes community has invested heavily in contributor documentation:
- kubernetes.dev — The contributor portal
- Contributor Cheatsheet — Quick reference
- Community Repository — Governance, SIGs, and processes
Step 3: Find your SIG
Kubernetes is organized into Special Interest Groups (SIGs) that own different areas. More on this below.
Step 4: Attend New Contributor Orientation
Kubernetes runs monthly New Contributor Orientation sessions specifically designed for newcomers. Check the community calendar or the bookmark in #cncf-new-contributors for the schedule.
Step 5: Start small
Despite Kubernetes's size and complexity, there are still approachable entry points. SIG-Docs (documentation) and SIG-Contributor-Experience are particularly welcoming to newcomers.
A: SIGs (Special Interest Groups) are the organizational units that own different areas of Kubernetes. Each SIG is responsible for a subset of the codebase, associated documentation, and related community processes.
Finding SIGs:
The full list lives at: github.com/kubernetes/community/blob/master/sig-list.md
Each SIG has:
- Charter: Defines scope and responsibilities
- README: Lists chairs, meetings, and contact information
- Slack channel: For day-to-day discussion
- Mailing list: For announcements and formal discussions
- Regular meetings: Usually weekly or bi-weekly video calls
Popular beginner-friendly SIGs:
- SIG-Docs: Owns all Kubernetes documentation. No Go required! Great for writers and those learning the project.
- SIG-Testing: Owns test infrastructure and testing frameworks. Good for those interested in quality engineering.
- SIG-CLI: Owns kubectl and other command-line tools. More approachable than core components.
- SIG-Contributor-Experience: Owns the contributor experience itself. Meta but important!
Community advice on choosing:
"Pick a couple of SIG(s), try to follow what they do and feel free to drop something not interesting and pick something else as you go down the road."
Browse the charters to find SIGs whose scope interests you. Attend a few meetings to get a feel for the community. Don't feel locked in—it's fine to explore before committing.
A: Kubernetes organization membership on GitHub provides certain privileges (write access to certain repos, ability to run certain CI jobs, etc.) and is a recognition of sustained contribution.
Requirements: github.com/kubernetes/community/blob/master/community-membership.md#member
The requirements include:
- Enabled two-factor authentication on GitHub
- Actively contributed to the project (issues, PRs, reviews)
- Sponsored by two existing members
- Member of at least one SIG
Process:
- Accumulate contributions over time (typically several months)
- Document your contributions (PRs merged, issues triaged, reviews done)
- Find two sponsors who can vouch for your work
- Open a membership request issue in kubernetes/org
Tips for success:
- Document everything: Keep a running list of your contributions
- It's easier to get sponsors from people you've worked with: If a maintainer has reviewed your PRs multiple times, they know your work
- Review existing membership requests: Look at closed membership issues to see how others presented their contributions
- Quality over quantity: Thoughtful contributions matter more than sheer numbers
The community emphasizes building relationships first:
"It's easier to get sponsors for your membership by people you worked with before."
A: Yes, extensive resources exist:
Curated collections:
- bit.ly/kubernetes-resources — Community-maintained list of beginner resources
KubeCon talks:
- The CNCF YouTube channel has thousands of KubeCon talks
- Search for "Cloud Native Novice" to find beginner-friendly tracks
- Search for "Maintainer Track" for deep dives into specific areas
- Search for "intro" or "introduction" in talk titles
Monthly orientation:
- Kubernetes runs monthly New Contributor Orientation sessions
- Check the community calendar
- A bookmark is pinned in #cncf-new-contributors
Written guides:
- developer.ibm.com/articles/a-tour-of-the-kubernetes-source-code/ — Detailed source code tour
- Project-specific READMEs in github.com/kubernetes/community
A: CNCF Slack hosts channels for most CNCF projects. To find them:
- In the Slack sidebar, click "Add channels" (or the + icon next to "Channels")
- Click "Browse channels"
- Search for your project name
- Join relevant channels
Note: Many projects have multiple channels:
#project-name— General discussion and user questions#project-name-dev— Development and contributor discussion#project-name-users— User-focused discussion#sig-xxx— SIG-specific channels (in Kubernetes)
Some projects have their own Slack workspaces entirely:
- Kubernetes: slack.k8s.io — Separate from CNCF Slack
- Projects listed in their documentation
When in doubt, check the project's README or community page for the authoritative Slack information.
A: Almost every CNCF project holds regular video meetings. Finding them:
CNCF Calendar: cncf.io/calendar/
This calendar contains ALL CNCF-related meetings. It can be overwhelming—there are dozens of meetings each week. Tips for navigating:
- Use the search/filter function to find specific projects
- Subscribe to the calendar and filter by project
- Ask in project Slack channels which meetings are most relevant
Kubernetes Calendar: kubernetes.dev/community/calendar/
Kubernetes has its own calendar covering all SIG meetings.
Project-specific:
- Check the project's README.md
- Look for CONTRIBUTING.md
- Search the project's documentation for "meeting" or "community"
What to expect in meetings:
- Most are open to anyone—you don't need an invitation
- Many are recorded and posted to YouTube
- Format varies: some have structured agendas, others are open discussion
- It's okay to just listen on your first few calls
- Introducing yourself briefly is welcome but not required
A: TAGs (Technical Advisory Groups) are cross-project groups that provide guidance and coordination across the CNCF ecosystem. Unlike projects that build and maintain specific software, TAGs focus on best practices, reviews, and ecosystem-wide concerns.
Current TAGs:
| TAG | Focus Area | Example Activities |
|---|---|---|
| TAG Security | Security practices | Security audits, best practices guides, CVE response |
| TAG Storage | Storage technologies | Storage landscape, CSI standards |
| TAG Network | Networking | Service mesh guidance, CNI coordination |
| TAG Runtime | Container runtimes | OCI standards, runtime comparisons |
| TAG App Delivery | Application deployment | GitOps, deployment patterns |
| TAG Observability | Monitoring, logging, tracing | OpenTelemetry coordination, best practices |
| TAG Contributor Strategy | Contributor experience | This channel!, contributor growth |
| TAG Environmental Sustainability | Green computing | Carbon footprint, efficiency |
How to engage with TAGs:
- TAG listing
- Each TAG has its own Slack channel, mailing list, and regular meetings
- TAGs often have working groups focused on specific initiatives
- TAGs welcome contributors who want to work on cross-cutting concerns
Why contribute to a TAG vs. a project:
- TAGs are great if you're interested in the ecosystem broadly rather than one specific technology
- They offer opportunities for non-code contributions (writing papers, organizing initiatives)
- You'll meet people from many different projects
- Less code, more coordination and documentation
A: Most CNCF projects use mailing lists for announcements, design discussions, and governance. Mailing lists capture important discussions that might be missed in ephemeral Slack conversations.
Finding mailing lists:
- Check the project's README or CONTRIBUTING.md
- Look for links to Google Groups or lists.cncf.io
- Ask in the project's Slack channel
Common patterns:
[email protected]— Development discussion[email protected]— User discussion[email protected]— Announcements only
For the TOC (Technical Oversight Committee): lists.cncf.io/g/cncf-toc
Subscribing to mailing lists is valuable because:
- Important decisions are often discussed there first
- It shows you're engaged (maintainers notice who's subscribed)
- You can search archives to understand project history
- Some opportunities are shared there before anywhere else
A: KubeCon + CloudNativeCon is the flagship event of the CNCF community, bringing together thousands of developers, operators, and vendors working in the cloud native space. It's the largest gathering of people working on Kubernetes and related technologies.
Event schedule:
- North America: Usually October/November (e.g., Salt Lake City, Chicago, Detroit)
- Europe: Usually March/April (e.g., Paris, Amsterdam, Valencia)
- China: Usually summer
What happens at KubeCon:
- Keynotes: Major announcements, industry trends, community updates
- Breakout sessions: Technical talks on specific topics
- Maintainer tracks: Deep dives into specific projects
- Tutorials and workshops: Hands-on learning
- Project pavilion: Booths where you can meet project maintainers
- Contributor summit: Pre-conference day for active contributors
- Hallway track: Informal conversations and networking
- Parties and social events: Community bonding
For new contributors, KubeCon is an incredible opportunity to:
- Meet maintainers you've been working with remotely
- Learn about projects you might want to contribute to
- Attend contributor-focused sessions
- Network with potential employers
- Get inspired by seeing the scale of the community
A: Yes! The Linux Foundation offers several scholarship programs to make KubeCon accessible:
Diversity Scholarships: For underrepresented groups in open source and technology. Covers conference registration and may include travel support.
Need-Based Scholarships: For those who can't afford to attend but would benefit from the experience.
Speaker Support: Accepted speakers receive complimentary registration and may receive travel support.
Application: Scholarship applications open several months before each event. Check the specific event page at events.linuxfoundation.org.
Important visa advice from the community:
"For those from countries where you need a visa to get to EU [or other KubeCon locations], please start the process(es) early!"
Visa processing can take months, and the Linux Foundation can provide invitation letters to support visa applications. Don't wait until the last minute.
Convince your boss resources: Many events have "convince your boss" pages with templates and arguments for workplace funding: events.linuxfoundation.org/kubecon-cloudnativecon-europe/attend/convince-your-boss/
A: You can still engage with the community even if you can't attend KubeCon:
Virtual participation:
- Some KubeCons offer virtual attendance options
- Keynotes and many sessions are streamed live
- All recordings are posted to the CNCF YouTube channel within days
Local events:
CNCF Community Groups are local meetup groups that exist in cities worldwide. Find one near you or start one: community.cncf.io
Kubernetes Community Days (KCDs) are single-day or multi-day events organized by local communities. They're smaller and more accessible than KubeCon but still provide great content and networking. Find them at community.cncf.io.
Online communities:
- Slack channels remain active during and after events
- Twitter/X discussions using event hashtags
- Blog posts and social media recaps
A: KCDs are community-organized events that bring the Kubernetes and cloud native community together at a local or regional level. They're officially supported by CNCF but organized by volunteers.
Characteristics:
- Usually 1-2 days
- Dozens to hundreds of attendees (vs. thousands at KubeCon)
- Local speakers and attendees
- Lower cost than KubeCon
- More intimate networking opportunities
Finding KCDs: community.cncf.io lists upcoming KCDs.
Starting a KCD: If there's no KCD in your area, you can organize one! CNCF provides resources and guidance for organizers at github.com/cncf/kubernetes-community-days.
A: CNCF encourages local community building through Community Groups (formerly called meetups).
Check if one exists: Visit community.cncf.io to see if there's already a group in your area.
Start a new group: If not, you can apply to start one via github.com/cncf/communitygroups.
CNCF provides:
- Use of CNCF branding
- Meetup.com group hosting
- Access to community resources
- Swag for events
- Guidance and best practices
Community member shared:
"Would be awesome to see a KCD or community group there"
Running a meetup is a significant non-code contribution to the ecosystem!
A: Many community members have explicitly joined with career goals in mind, and contributing to CNCF projects can indeed advance your career significantly.
Direct benefits:
Skill development: You'll learn from some of the best engineers in the industry. Reviewing PRs from experienced developers, getting feedback on your own code, and understanding production-grade systems accelerates your growth.
Portfolio building: Open source contributions are public and verifiable. Unlike proprietary work you can't share, CNCF contributions demonstrate your skills to any potential employer.
Networking: The cloud native community is relatively small at the core. Regular contributors know each other, recommend each other for jobs, and collaborate across companies. Your contributions introduce you to this network.
Recognition: Becoming a known contributor gives you visibility. Maintainers get invited to speak at conferences, write for industry publications, and advise companies.
Job opportunities: Many companies actively recruit from the contributor pool. They know that someone who can contribute to complex projects like Kubernetes can likely contribute to their codebase too.
One community member explicitly shared their goal:
"I want to change this by contributing to CNCF projects and land a new job with this."
This is a legitimate and common path.
Indirect benefits:
Technical credibility: Being able to say "I contributed to Kubernetes" or "I'm a Prometheus maintainer" carries weight in technical discussions.
Interview advantages: You'll have concrete examples to discuss. Instead of hypothetical "how would you..." questions, you can point to real problems you've solved in public.
Understanding of production systems: CNCF projects are used at massive scale. Understanding how they work gives you insight into production challenges you won't get elsewhere.
A: CNCF Ambassadors are recognized community advocates who spread the word about cloud native technologies. It's an honor that comes with tangible benefits.
What Ambassadors do:
- Speak at conferences and meetups
- Write blog posts and create content
- Organize community events
- Mentor newcomers
- Represent the CNCF community
Benefits:
- Conference passes (including KubeCon)
- Speaking opportunities
- Exclusive swag
- Access to ambassador resources and network
- Recognition on CNCF website
How to become one:
- Be active in the community: Contribute, speak, write, organize. Build a track record.
- Establish visibility: Be known for something. Maybe you organize a popular meetup, or you're the go-to person for a particular project, or you've written extensively about cloud native topics.
- Apply: Applications open periodically at cncf.io/people/ambassadors/
When someone in the channel celebrated becoming an ambassador:
"Happy to share that now I am a CNCF Ambassador!"
The community responded with congratulations, showing how valued this achievement is.
Note: Ambassador status isn't just for maintainers or heavy code contributors. Community organizers, content creators, and educators are also recognized.
A: Several resources exist specifically for cloud native job seekers:
CNCF Slack channels:
#jobs— Job postings#careers— Career discussions and advice
Major employers in the ecosystem: Companies that heavily contribute to CNCF projects often hire from the community:
- Google, Microsoft, Amazon, Red Hat, VMware
- Smaller cloud native companies: HashiCorp, Datadog, Grafana Labs, Solo.io, etc.
Job boards:
- CNCF jobs board (check cncf.io)
- General job boards filtering for "Kubernetes", "Cloud Native", specific project names
Networking: Many jobs are never posted publicly. Building relationships in the community leads to opportunities. Maintainers know when their employers are hiring and can refer strong contributors.
A: This is a real barrier for some contributors, especially those in developing regions or students with older hardware. The community has solutions:
Cloud development environments:
"Try github codespaces or gitpod.io - I think they are free for open source projects. I don't think your machine will be a hurdle in your learning as long as you are keen to learn."
- GitHub Codespaces: Free tier available for open source work. Provides full development environments in the cloud.
- Gitpod: gitpod.io — Free for open source. Integrates with GitHub repos.
Both solutions let you develop on a powerful cloud machine while using your browser or VS Code locally.
Lighter-weight Kubernetes options:
- kind (Kubernetes IN Docker): Runs Kubernetes clusters in Docker containers. Lower overhead than full VMs.
- k3s: Lightweight Kubernetes distribution. Designed for resource-constrained environments.
- Minikube: Single-node cluster for local development. Can configure resource limits.
Non-code contributions: If hardware is truly a limitation, consider non-code contributions that don't require running heavy workloads: documentation, issue triage, community work.
Contribution types that are less resource-intensive:
- CLI tools (smaller footprint than full systems)
- Documentation and website contributions
- SDK development for languages you can run locally
A: Don't take it personally! There are several common reasons:
The question was already answered: Community members see the same questions repeatedly. If you haven't looked at pinned items, bookmarks, and scroll-back, you're more likely to get a pointer to those resources than a direct answer. Do your homework first.
The question was too broad: "How do I contribute?" is nearly impossible to answer well. "How do I set up the development environment for [specific project] on macOS?" is answerable. Specific questions get better responses.
Wrong channel: Project-specific questions belong in project-specific channels. The community regularly redirects:
"Wrong channel for this question. Try #sig-testing on k8s slack." "Check out the #kubeflow channels"
Timezone differences: CNCF is a global community. Active times vary. Wait 24 hours before assuming no response. Someone in another timezone might answer when they come online.
People are busy: Most contributors are volunteers. They answer when they can. Patience is appreciated.
How to increase your chances:
- Show you've done research ("I've read the getting started guide and set up my environment, but I'm stuck on...")
- Be specific about what you're trying to do and where you're stuck
- Include relevant context (OS, versions, error messages)
- Ask in the right channel
- Be patient and polite
A: Good bug reports are valuable contributions! Here's the process:
Before reporting:
- Search existing issues: The bug may already be reported. Search GitHub issues for relevant keywords.
- Reproduce reliably: Make sure you can reproduce the bug consistently. Note the exact steps.
- Check if it's user error: Review documentation to make sure you're using the feature correctly.
When reporting:
- Check for templates: Many projects have issue templates. Fill them out completely.
- Include details: Steps to reproduce, expected behavior, actual behavior, environment (OS, versions, configuration).
- Provide logs: Relevant log output helps maintainers diagnose.
- Minimal reproduction: If possible, create a minimal test case that demonstrates the bug.
Security bugs: If the bug has security implications, don't report it publicly! Look for a SECURITY.md file in the repository that explains how to report security issues privately. Most projects have a security@[project].io email or a private reporting mechanism.
Offering to fix: If you're willing to fix the bug yourself, say so in the issue. Maintainers often prioritize issues where someone is ready to do the work.
A: Waiting for PR reviews is one of the most frustrating parts of open source contribution. Here's how to handle it:
Be patient: Maintainers are often volunteers with day jobs. Complex PRs take time to review properly. One to two weeks for an initial review is not unusual for larger projects.
Make your PR review-friendly:
- Write clear PR descriptions explaining what and why
- Keep PRs focused and reasonably sized
- Add tests and documentation
- Respond promptly to review feedback
Politely ping: After one to two weeks with no response, a friendly comment is appropriate: "Hi, just checking if someone has had a chance to look at this. Happy to address any feedback or answer questions."
Attend meetings: Mention your PR in project meetings. This raises visibility and might prompt someone to take a look.
Offer to help: Sometimes the blocker is maintainer bandwidth. You could offer: "Is there anything I can do to help move this forward? I'm happy to split it into smaller PRs, add more tests, or address any concerns."
Understand priorities: Not all PRs are equal. Bug fixes and requested features get more attention than unsolicited refactoring. If your PR addresses a known issue, it's more likely to get reviewed quickly.
If truly stuck: If you've waited weeks with no response despite polite pings, you might escalate by asking in Slack which maintainer is appropriate to review, or by raising it at a community meeting.
A: Absolutely normal—nearly universal, in fact. Imposter syndrome affects contributors at all levels, from newcomers to seasoned maintainers.
Recognize the signs:
- Feeling like you don't belong
- Worrying that you'll be "found out" as incompetent
- Attributing success to luck rather than skill
- Comparing yourself unfavorably to others
Reality check:
- Everyone started as a beginner. The most prolific contributors weren't born knowing Kubernetes.
- Maintainers want you to succeed. They invest time in reviewing PRs because they want more contributors, not to gatekeep.
- Your perspective is valuable. Newcomers see things that veterans miss. Your "naive" questions often reveal documentation gaps.
- Small contributions matter. Not every PR needs to be a major feature. Typo fixes, test improvements, and documentation updates are all valuable.
Strategies that help:
- Celebrate small wins. Each merged PR is an achievement. Keep a list of your contributions.
- Remember everyone struggles. Look at early commits from people you admire—they made mistakes too.
- Ask questions without shame. Smart people ask questions. That's how they got smart.
- Find community. Connect with other newcomers who understand what you're going through.
- Take breaks. Burnout amplifies imposter syndrome. It's okay to step back.
The cloud native community is generally welcoming. People remember being new. Most will go out of their way to help someone who's genuinely trying.
| Resource | URL | Description |
|---|---|---|
| CNCF Contributors Portal | contribute.cncf.io | Main starting point for all contribution guidance |
| CLOTributor | clotributor.dev | Find good first issues across all CNCF projects |
| CNCF Landscape | landscape.cncf.io | Visual map of all CNCF and cloud native projects |
| CNCF Calendar | cncf.io/calendar | All community meetings across the ecosystem |
| Resource | URL | Description |
|---|---|---|
| CNCF Mentoring | github.com/cncf/mentoring | GSoC, LFX, and other mentorship programs |
| KubeByExample | kubebyexample.com | Interactive learning paths for Kubernetes |
| CNCF YouTube | youtube.com/@cncf | Thousands of recorded talks and tutorials |
| Intro to Open Source Course | kubebyexample.com/learning-paths/intro-open-source-lesson-1 | Comprehensive course on contributing |
| Resource | URL | Description |
|---|---|---|
| Kubernetes Slack Invite | slack.k8s.io | Join the Kubernetes Slack workspace |
| K8s Contributor Guide | kubernetes.dev | Official contributor documentation |
| SIG List | github.com/kubernetes/community/blob/master/sig-list.md | All Kubernetes Special Interest Groups |
| K8s Resources Collection | bit.ly/kubernetes-resources | Curated beginner resources |
| Resource | URL | Description |
|---|---|---|
| Community Groups | community.cncf.io | Local meetups and KCDs worldwide |
| TAG Contributor Strategy | github.com/cncf/tag-contributor-strategy | Initiatives to help contributors |
| CNCF Blog Guidelines | github.com/cncf/foundation/blob/main/blog-guidelines.md | How to write for the CNCF blog |
| KubeCon Events | events.linuxfoundation.org | Flagship conferences |
| Resource | URL | Description |
|---|---|---|
| Tour of Go | go.dev/tour | Interactive tutorial |
| Go by Example | gobyexample.com | Practical examples |
| Go Learn | go.dev/learn | Official learning resources |
| Go Standard Library | github.com/golang/go/tree/master/src | Read idiomatic Go code |
Many projects have their own excellent contribution resources:
- Knative: knative.dev/blog/articles/getting-started-blog-p0/ — Multi-part blog series on contributing
- Kubernetes: kubernetes.dev/docs/contributor-cheatsheet/ — Quick reference for K8s contributors
- MetalLB: Mentioned in community as particularly contributor-friendly
- Kubescape: Active contributor channel
#kubescapeand#kubescape-dev - Cilium: cilium.io/get-involved/ — How to join the Cilium community
- A Beginner's Guide to Contributing to CNCF Open Source Projects — CNCF blog
- Why and How to Start Contributing to CNCF — Community guide
- Getting Started in Kubernetes with Non-Code Contributions — Salesforce's guide
- How (and Why) to Make Your First Contribution to a CNCF Project — OSS EU talk with slides
- Read contribute.cncf.io/contributors/getting-started/
- Browse the CNCF Landscape
- Pick ONE project that interests you
- Join its Slack channel and introduce yourself
- Clone the repo and get it running locally
- Find a "good first issue" on CLOTributor
- Make your first contribution (docs, tests, or small code fix)
- Attend a project community meeting
- Subscribe to the project mailing list
- Review other people's PRs
- Ask questions when stuck (specific questions get better answers!)
- Set up your development environment properly
- Become a regular contributor to one project
- Help other newcomers in Slack
- Consider applying for GSoC/LFX if eligible
- Attend a local meetup or KCD
- Write a blog post about your journey
- Start reviewing PRs regularly
- Establish yourself as a trusted contributor
- Consider expanding to a second project
- Mentor newer contributors
- Speak at a meetup or conference
- Consider leadership opportunities (SIG role, working group, etc.)
Collected quotes from experienced contributors in the channel:
"Start slow. By doing PR reviews to see what is being changed and where."
"Pick an area of their interest and narrow down the projects."
"The underrated way to learn a new language is from code reviews!"
"It's often better to talk to maintainers ahead of time and figure out ideas about projects."
"More specific the question, easier to answer!"
"There are a lot of things that people talk about but don't end up as an issue. If you can pay attention and pick some stuff and use that to open an issue and PR, you are on the next step of the journey."
"Matching projects to your existing skills is the wrong way to approach it... interests should drive your skills development."
"The idea is to be able to modify some code and build things and then run it. That's the first step. If you can't do this then no amount of looking at code will help."
"I don't think your machine will be a hurdle in your learning as long as you are keen to learn."
This FAQ was compiled from real conversations in the #cncf-new-contributors Slack channel spanning November 2023 to December 2025, representing the collective wisdom of over 850 community members and 2,200+ messages.
Special thanks to dims, Daniel Krook, Calum Murray, Emily Fox, Chris Aniszczyk, Leo L., Tim Bannister, and the countless community members who generously share their knowledge with newcomers every day.
Last updated: December 2025