Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions blog/authors.yml
Original file line number Diff line number Diff line change
Expand Up @@ -26,3 +26,9 @@ wxnzb:
title: Kmesh Contributor
url: https://github.com/wxnzb
image_url: https://avatars.githubusercontent.com/u/149587405?v=4

jayesh9747:
name: Jayesh Savaliya
title: Kmesh Maintainer
url: https://github.com/jayesh9747
image_url: https://avatars.githubusercontent.com/u/123955234

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

For consistency with other author entries in this file, it's recommended to add the ?v=4 query parameter to the image_url. This parameter helps with cache busting when the avatar image is updated.

  image_url: https://avatars.githubusercontent.com/u/123955234?v=4

Copy link

Copilot AI Feb 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing "v=4" query parameter in the image URL. Other author entries in authors.yml include this parameter (e.g., line 4, 10, 16, 22, 28), so for consistency, this URL should be "https://avatars.githubusercontent.com/u/123955234?v=4".

Suggested change
image_url: https://avatars.githubusercontent.com/u/123955234
image_url: https://avatars.githubusercontent.com/u/123955234?v=4

Copilot uses AI. Check for mistakes.
135 changes: 135 additions & 0 deletions blog/lfx_2025_website_migration/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,135 @@
---
title: "From Contributor to Maintainer: My LFX Mentorship Journey"
authors:
- jayesh9747
date: 2025-02-14
sidebar_position: 2
---
Comment on lines 1 to 7

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The file path for this blog post seems inconsistent with the project's guidelines and the content of the post. The project's guide, docs/developer-guide/website/create-blog.md, recommends a file naming convention of YYYY-MM-DD-title.md. The current folder name lfx_2025_website_migration will also create a confusing URL slug, as the blog post is about a mentorship journey, not website migration.

It is recommended to rename the file to better reflect its content and adhere to the project's conventions. For example: blog/2025-02-14-from-contributor-to-maintainer-lfx-journey.md. Since a file rename cannot be suggested directly, please consider this change for better maintainability and user experience.


### Introduction

Hi everyone! I'm Jayesh Savaliya, a B.Tech student at IIIT Pune passionate about backend technologies and open source. Over the last two years, I've been selected for the C4GT program twice (2024 & 2025) - yes, they let me back in - and recently completed LFX Mentorship 2025 (Term 1), where I somehow went from fixing typos to being responsible for reviewing other people's code at Kmesh.

In this blog, I'll share my journey and the strategies that actually worked (no generic "just be passionate" advice, I promise).

---

### My Background

When I applied to LFX, I wasn't starting from scratch. I had already battle-tested myself with:
- **Sunbird** (EkStep Foundation) via C4GT, where I learned that education tech is harder than it looks

Check failure on line 20 in blog/lfx_2025_website_migration/index.md

View workflow job for this annotation

GitHub Actions / build (1.23)

Lists should be surrounded by blank lines

blog/lfx_2025_website_migration/index.md:20 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "- **Sunbird** (EkStep Foundati..."] https://github.com/DavidAnson/markdownlint/blob/v0.38.0/doc/md032.md
- **Mifos**, a GSoC organization focused on financial services (because debugging payment systems at 2 AM builds character)
- Various backend projects where I definitely didn't break production. Much.

#### Choosing Kmesh

I shortlisted projects from the LFX portal based on three key criteria:
1. **Tech stack relevance** - Technologies I wanted to master

Check failure on line 27 in blog/lfx_2025_website_migration/index.md

View workflow job for this annotation

GitHub Actions / build (1.23)

Lists should be surrounded by blank lines

blog/lfx_2025_website_migration/index.md:27 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "1. **Tech stack relevance** - ..."] https://github.com/DavidAnson/markdownlint/blob/v0.38.0/doc/md032.md
2. **Learning potential** - Projects that would challenge and grow my skills
3. **Active maintainers** - Communities with responsive, helpful mentors

I chose Kmesh, a high-performance service mesh data plane built on eBPF and programmable kernel technologies. Kmesh's sidecarless architecture eliminates proxy overhead, resulting in better performance and lower resource consumption.

Honestly? It had "eBPF" in the description and I wanted to sound cool at tech meetups. But it turned out to be genuinely fascinating work with a great community.

---

### How to Succeed in Open Source Programs

Here's my three-step approach that worked for LFX:

#### 1. Make Meaningful Contributions

Start small and scale up gradually. Don't be the person who says "I'll rewrite the entire architecture!" on day one.

Instead:
- **Weeks 1-2:** Fix typos, improve logs, update documentation

Check failure on line 46 in blog/lfx_2025_website_migration/index.md

View workflow job for this annotation

GitHub Actions / build (1.23)

Lists should be surrounded by blank lines

blog/lfx_2025_website_migration/index.md:46 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "- **Weeks 1-2:** Fix typos, im..."] https://github.com/DavidAnson/markdownlint/blob/v0.38.0/doc/md032.md
- **Weeks 3-4:** Fix small bugs, add tests
- **Week 5+:** Work on core features and refactoring

This progression shows mentors you're not just throwing random PRs at the wall hoping something sticks.

#### 2. Write a Strong Proposal

Your proposal should be:
- **Clear:** Explain your approach in straightforward language

Check failure on line 55 in blog/lfx_2025_website_migration/index.md

View workflow job for this annotation

GitHub Actions / build (1.23)

Lists should be surrounded by blank lines

blog/lfx_2025_website_migration/index.md:55 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "- **Clear:** Explain your appr..."] https://github.com/DavidAnson/markdownlint/blob/v0.38.0/doc/md032.md
- **Structured:** Include a realistic timeline with milestones
- **Convincing:** Demonstrate why you're the right person for the project

Make sure your proposal reflects genuine engagement with the project, not just surface-level research.

#### 3. Be Actively Involved

Stay engaged in project channels (Slack, Discord, mailing lists). Communicate regularly with mentors, ask thoughtful questions, and contribute to discussions.

But also: don't be *that* person who asks questions Google could answer or pings everyone at 3 AM with "quick question." Balance is everything.

**The Formula:** Consistent contributions + Strong proposal + Active communication = Standing out

---

### The Path to Maintainership

Becoming a maintainer wasn't planned. It happened naturally through sustained engagement after the mentorship period ended.

#### Consistency

I continued contributing regularly after my initial PRs were merged:
- Fixing overlooked bugs

Check failure on line 78 in blog/lfx_2025_website_migration/index.md

View workflow job for this annotation

GitHub Actions / build (1.23)

Lists should be surrounded by blank lines

blog/lfx_2025_website_migration/index.md:78 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "- Fixing overlooked bugs"] https://github.com/DavidAnson/markdownlint/blob/v0.38.0/doc/md032.md
- Adding requested features
- Refactoring code for better maintainability

#### Learning Mindset

I embraced every learning opportunity, even when I had no idea what I was doing. eBPF concepts? Started clueless, ended slightly less clueless. Performance optimization? Learned by making things slower first. CI/CD improvements? Broke the build a few times, but now I own it.

#### Patience & Feedback

Code reviews can be humbling (read: brutal). I learned to take feedback seriously even when it stung, iterate quickly, and stay patient when things inevitably broke.

#### Taking Initiative

I started acting like a maintainer before having the title:
- Suggesting project improvements

Check failure on line 93 in blog/lfx_2025_website_migration/index.md

View workflow job for this annotation

GitHub Actions / build (1.23)

Lists should be surrounded by blank lines

blog/lfx_2025_website_migration/index.md:93 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "- Suggesting project improveme..."] https://github.com/DavidAnson/markdownlint/blob/v0.38.0/doc/md032.md
- Writing comprehensive tests (because flaky tests are the worst)
- Automating repetitive tasks (laziness is a virtue in programming)
- Reviewing other contributors' work

By the end of my mentorship, the trust I built with the team led to being granted maintainer access. Going from "hey, can I fix this typo?" to "you're now responsible for reviewing PRs" was equal parts surreal and terrifying.

---

### Key Takeaways

Here's what I learned that might help you:

**Start small, stay consistent** - Begin with simple contributions and build from there. Consistency matters more than individual genius.

**Focus on learning** - Getting selected is great, but learning enough to make real contributions is what counts.

**Communicate effectively** - Ask questions, share progress, and be helpful. Respectful, clear communication goes a long way.

**Suggest improvements** - If you see something that could be better, speak up. Good ideas are always welcome.

**Embrace feedback** - Your first PR won't be perfect. Nobody's is. Take feedback as learning opportunities, iterate, and move on. Arguing about semicolons is not a productive use of anyone's time.

You don't need to be a genius. You just need to show up, contribute meaningfully, and improve consistently.

---

### Final Thoughts

The LFX Mentorship taught me more than just technical skills. I learned how to work with distributed teams across timezones, think critically about production software (logs are your friends!), and grow into a leadership role in an open source community.

If you're considering applying to LFX or any open source program, take the leap. With consistent effort and genuine engagement, you can make a real impact. If I can go from nervous first-time contributor to maintainer, so can you.

---

### Connect With Me

Feel free to reach out if you want to discuss open source, eBPF, or systems programming:

- [LinkedIn](https://linkedin.com/in/jayesh-savaliya)
- [GitHub](https://github.com/jayesh9747)

Thanks for reading, and see you in the next PR!
Loading