From Beginner Contributor to KubeStellar LFX Mentee

Ghanshyam Singh — Sun, 31 May 2026 09:43:47 +0000

If someone had told me a year ago that I would be contributing to a CNCF project, mentoring other contributors, reporting more than 140 bugs, and being selected for an LFX Mentorship, I probably would not have believed them.

Back in June 2025, I was just another student curious about open source.

I had heard people talk about GitHub contributions, CNCF projects, Kubernetes, community calls, and all the exciting opportunities available in the cloud-native ecosystem. But honestly, I did not really know how any of it worked.

I was not an experienced contributor. I was not a Kubernetes expert. I did not have a long list of impressive pull requests.

I was just curious.

That curiosity ended up changing my life.

Discovering CNCF and KubeStellar

Around June 2025, I started exploring projects within the CNCF ecosystem. I wanted to understand how real-world open-source projects worked and how contributors collaborated across the world.

While exploring different projects, I came across KubeStellar.

At first, it was just another interesting project on my screen. But the more I explored it, the more fascinated I became. The idea of simplifying multi-cluster Kubernetes management felt incredibly powerful, and I wanted to learn more.

The problem was that learning and contributing were two completely different things.

I quickly realized that I could not simply read documentation and magically become a contributor. I needed to set up my environment, understand the project architecture, learn Kubernetes concepts, and actually start participating.

Even my laptop had other plans.

Running local Kubernetes environments was not exactly easy on my machine. I spent time upgrading and fixing my setup before I could comfortably run local clusters. After several rounds of troubleshooting, configuring tools, and experimenting with KIND clusters, I finally had an environment where I could start learning by doing.

Looking back now, it feels funny.

At the time, getting a cluster running successfully felt like a huge achievement.

My First Steps Into Open Source

One thing people do not talk about enough is how intimidating open source can feel when you are new.

Most people think the hard part is understanding the code.

For me, the hard part was the people.

Not because the community was not welcoming. Actually, it was the opposite. Everyone was incredibly supportive.

But I had never worked with a global team before. I had never joined technical community meetings before. I had never publicly discussed bugs, features, ideas, or architecture decisions before.

Every Tuesday and Thursday at 8:30 PM IST, I joined the KubeStellar community meetings.

And honestly?

I was nervous every single time.

Before every meeting, I would mentally prepare myself to speak. Sometimes it was a question. Sometimes it was an update. Sometimes it was simply sharing what I had been working on.

Even when I felt nervous, I pushed myself to participate.

Those small moments might sound insignificant, but they completely changed my confidence over time.

Each meeting made me a little more comfortable. Each discussion taught me something new. Each interaction helped me grow.

Today, when I look back, I realize that learning how to communicate in a community was just as valuable as learning Kubernetes itself.

Becoming an Unpaid Mentee

My first major opportunity came through KubeStellar's unpaid mentorship program.

This was where everything started becoming real.

During the mentorship, I worked on the A2A project, contributing to CLI improvements, documentation, and website-related work.

More importantly, I started understanding how open source actually functions behind the scenes.

Before that, GitHub felt like a platform where people uploaded code.

Now I was seeing the full picture.

Ideas became issues.
Issues became discussions.
Discussions became pull requests.
Pull requests became features.
And behind all of it were real people collaborating to build something meaningful.

The mentorship ran from August to November, and those months taught me more than I could have learned from any tutorial.

By the time it ended, I was not just contributing.

I had become part of the community.

If you want to explore the project that pulled me deeper into the ecosystem, start here:

Falling in Love With Open Source

Even after the mentorship ended, I did not stop contributing.

In fact, I became even more involved.

I explored other open-source organizations, contributed across projects, learned new technologies, and continued participating in community discussions.

Somewhere during that journey, open source stopped feeling like a way to improve my resume.

It became something much more meaningful.

I genuinely enjoyed helping people. I enjoyed learning in public. I enjoyed collaborating with contributors from different backgrounds and different parts of the world.

For the first time, I felt like I was not just consuming technology.

I was helping build it.

The LFX Application

When the LFX Mentorship applications opened, I decided to apply.

To be honest, I did not have huge expectations.

LFX is highly competitive, and there are many talented contributors applying every term. I submitted my application, prepared for interviews, and hoped for the best.

But deep down, I was not sure whether I would be selected.

Then one day, I received the email.

I had been selected.

I still remember the excitement.

Months of learning, contributing, attending meetings, asking questions, fixing issues, and staying consistent had finally led to this moment.

For me, the selection was not just an achievement. It was proof that growth happens when you keep showing up.

Working on the Future of Multi-Cluster Kubernetes

During LFX Term 1 from March to May, I worked on the KubeStellar Console project.

The vision behind the project was incredibly exciting.

KubeStellar Console aims to simplify multi-cluster Kubernetes operations through an AI-powered experience. Instead of manually managing every aspect of Kubernetes, users can interact with intelligent workflows and automation to manage their environments more efficiently.

My focus was on improving AI Missions and helping build an agent capable of handling operational workflows across Kubernetes environments.

This meant spending a lot of time testing, validating behavior, reproducing issues, understanding edge cases, and improving the overall experience.

A large part of my work involved using KIND clusters to simulate real-world scenarios and verify how different workflows behaved under various conditions.

Every day felt like a new learning opportunity.

What I Worked on Technically

The technical part of the mentorship was where things became intense in the best way.

KubeStellar A2A sits at an interesting intersection: Kubernetes operations, multi-cluster workflows, automation, and AI-assisted interfaces. My work was not limited to writing code in isolation. It involved understanding how user intent could become a reliable operational action inside a Kubernetes environment.

Some of the areas I spent time on:

Testing AI Missions and validating whether generated workflows behaved correctly.
Reproducing bugs using local KIND clusters and different kubeconfig contexts.
Checking cluster discovery, namespace listing, resource lookup, and multi-cluster behavior.
Reviewing CLI behavior and making sure commands were understandable for new users.
Improving documentation so contributors could set up, test, and debug faster.
Validating edge cases around failed clusters, missing context, invalid input, and partial workflow failures.

The work forced me to think less like someone trying to make a demo pass and more like someone responsible for a real user journey.

Local testing loop:
1. Create or reset KIND clusters
2. Configure kubeconfig contexts
3. Run the A2A workflow or CLI command
4. Reproduce the issue with clear steps
5. Capture logs, screenshots, and expected behavior
6. Report or validate the fix

That loop became a habit.

It also taught me that good engineering is not only about building features. It is also about making failures understandable.

A bug report is not just "this is broken." A good bug report is a map that helps someone else reach the same problem and fix it with confidence.

Sleepless Nights, Bugs, and Ownership

One lesson that LFX taught me was ownership.

When you are working on a real project with real users, bugs are not just bugs.

They are problems that affect someone's experience.

There were multiple nights when I stayed awake much longer than planned.

Debugging. Testing. Investigating issues. Verifying fixes. Trying to understand why something worked yesterday but not today.

Sometimes the solution appeared in minutes. Sometimes it took hours. Sometimes it took days.

But that is part of engineering.

And that is where some of the biggest learning happened.

142 Bug Reports Later

By the end of the mentorship, I had submitted 142 bug reports.

That number still surprises me.

Each bug report represented investigation, testing, reproduction, documentation, and communication.

It was not just about finding issues.

It was about helping improve the project and making it better for future users and contributors.

Through that process, I learned how important quality assurance, testing, and attention to detail are in large-scale open-source projects.

Lessons From A2A and Multi-Cluster Testing

The A2A project helped me understand why multi-cluster Kubernetes tooling is difficult.

In a single-cluster setup, you already have many moving parts: workloads, namespaces, services, RBAC, kubeconfig, logs, events, controllers, and user permissions.

In a multi-cluster setup, that complexity multiplies.

Now the system has to answer harder questions:

Which cluster should this action target?
What happens if one cluster is reachable and another is not?
How do we expose useful errors without overwhelming the user?
Can an AI-assisted workflow explain what it is about to do?
Can the same workflow be tested safely before applying changes?

These questions made me appreciate the value of dry runs, clear command output, reproducible test cases, and careful documentation.

They also made me respect the people building infrastructure tools even more. The best tools feel simple because someone has already absorbed a lot of complexity for the user.

From Being Mentored to Mentoring Others

Perhaps the most rewarding part of the entire journey was realizing how much I had grown.

A year earlier, I was nervous about speaking in community meetings.

During my mentorship, I had the opportunity to help mentor four unpaid mentees.

I answered questions, shared knowledge, helped contributors navigate the project, and supported them whenever possible.

That experience meant a lot to me because it reminded me of where I started.

The same community that helped me learn had given me the opportunity to help others learn too.

And honestly, that is one of the most beautiful things about open source.

Knowledge gets shared. People help each other. Everyone grows together.

Thank You to My Mentors

This journey would not have been the same without the people who reviewed my work, answered questions, gave direction, and trusted me with responsibility.

A huge thank you to Andy Anderson and Rishi Mondal for their mentorship, patience, technical guidance, and constant support throughout the journey.

They helped me understand not only the project, but also how to think like an open-source contributor: communicate clearly, document decisions, respect maintainers' time, and keep improving the work until it becomes genuinely useful.

I am also grateful to the KubeStellar community, the Linux Foundation LFX Mentorship program, CNCF, and every contributor who made the community feel welcoming.

The best mentorship does not just help you finish a task. It changes how you approach the next hard problem.

Final Thoughts

When people ask me what I gained from open source, my answer is simple.

Yes, I learned Kubernetes. Yes, I learned testing, debugging, collaboration, and cloud-native technologies.

But more importantly, I learned confidence.

I learned how to communicate. I learned how to work with people across the world. I learned how to ask questions. I learned how to contribute even when I was not completely sure of myself.

My journey from a beginner contributor to a KubeStellar LFX mentee was not perfect.

There were challenges, mistakes, sleepless nights, and moments of self-doubt.

But there was also growth, community, learning, and opportunity.

And if there is one thing I have learned from this journey, it is this:

You do not need to be an expert before you start. Sometimes all you need is curiosity, consistency, and the courage to show up.

DEV Community: Ghanshyam Singh