Conversation
✅ Deploy Preview for kmesh-net ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Summary of ChangesHello @jayesh9747, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces a new blog post that chronicles the author's personal journey through the LFX Mentorship program, culminating in a maintainer role. It also includes the necessary author profile update to support the new content, providing valuable insights into open source contribution and growth. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds a new blog post about an LFX mentorship journey and registers the author in the authors.yml file. The changes are generally good, but there are a couple of points for improvement. In authors.yml, the new author's image URL could be updated for consistency with other entries. More importantly, the new blog post in index.md has a logical inconsistency between its publication date (set in 2025) and its content, which describes events from 2025 in the past tense. This should be corrected to avoid confusing readers.
| name: Jayesh Savaliya | ||
| title: Kmesh Maintainer | ||
| url: https://github.com/jayesh9747 | ||
| image_url: https://avatars.githubusercontent.com/u/123955234 |
There was a problem hiding this comment.
For consistency with other entries in this file, it's recommended to add ?v=4 to the image_url. This ensures a consistent format for all author avatars.
image_url: https://avatars.githubusercontent.com/u/123955234?v=4| title: "From Contributor to Maintainer: My LFX Mentorship Journey" | ||
| authors: | ||
| - jayesh9747 | ||
| date: 2025-02-14 |
There was a problem hiding this comment.
The blog post's frontmatter specifies a date in 2025. However, the post is written in the past tense, describing events from 2025 as if they have already occurred (e.g., line 11: "recently completed LFX Mentorship 2025"). This creates a logical inconsistency that may confuse readers. Depending on the Docusaurus configuration, posts with future dates might not be displayed until that date arrives. It's recommended to review the date and content to ensure they are aligned. If this post is about a completed mentorship, the date should reflect the time of writing.
There was a problem hiding this comment.
Pull request overview
This PR adds a blog post about an LFX Mentorship 2025 experience at Kmesh, documenting the author's journey from contributor to maintainer. However, there is a critical mismatch between the PR title/folder name ("website migration") and the actual blog content (mentorship journey).
Changes:
- Added a new blog post about LFX 2025 mentorship journey and progression to maintainer role
- Added author entry for jayesh9747 in the authors configuration file
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 7 comments.
| File | Description |
|---|---|
| blog/lfx_2025_website_migration/index.md | New blog post documenting LFX mentorship experience and path to becoming a Kmesh maintainer |
| blog/authors.yml | Added author entry for Jayesh Savaliya (jayesh9747) as Kmesh Maintainer |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| ### 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. |
There was a problem hiding this comment.
The blog mentions being "selected for the C4GT program twice (2024 & 2025)" but the blog date is February 14, 2025. It's unlikely that C4GT 2025 would have been completed or even fully underway by mid-February 2025, as these programs typically run later in the year. Consider revising this to say "2023 & 2024" or "2024 & upcoming 2025" to maintain temporal accuracy.
| 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. | |
| 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 & upcoming 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. |
| name: Jayesh Savaliya | ||
| title: Kmesh Maintainer | ||
| url: https://github.com/jayesh9747 | ||
| image_url: https://avatars.githubusercontent.com/u/123955234 |
There was a problem hiding this comment.
The image_url is missing the "?v=4" query parameter that is consistently present in all other author entries in this file. For consistency with the existing convention, the URL should be "https://avatars.githubusercontent.com/u/123955234?v=4".
| image_url: https://avatars.githubusercontent.com/u/123955234 | |
| image_url: https://avatars.githubusercontent.com/u/123955234?v=4 |
| --- | ||
| title: "From Contributor to Maintainer: My LFX Mentorship Journey" | ||
| authors: | ||
| - jayesh9747 | ||
| date: 2025-02-14 | ||
| sidebar_position: 2 | ||
| --- |
There was a problem hiding this comment.
The PR title "LFX 2025 : website migration blog" does not match the blog content, which is about a mentorship journey from contributor to maintainer. There is no mention of website migration anywhere in the blog post. This discrepancy between the PR title, folder name (lfx_2025_website_migration), and actual content suggests either the wrong blog content was added or the PR title and folder name need to be updated to reflect the actual content.
| - [LinkedIn](https://linkedin.com/in/jayesh-savaliya) | ||
| - [GitHub](https://github.com/jayesh9747) | ||
|
|
||
| Thanks for reading, and see you in the next PR! |
There was a problem hiding this comment.
The blog post uses an overly casual and humorous tone that is inconsistent with other blog posts in the repository. Examples include "yes, they let me back in", "I somehow went from fixing typos", "where I definitely didn't break production. Much.", and "I wanted to sound cool at tech meetups." While the content is informative, the tone should match the more professional style established in other blog posts like lfx_2025_tcp_long_conn and ospp_2025_automation_workflow. Consider toning down the humor while keeping the personal narrative engaging.
| Thanks for reading, and see you in the next PR! | |
| Thank you for reading, and I hope this overview of my LFX mentorship journey is helpful in your own path. |
| ### 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 | ||
| - **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 | ||
| 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 | ||
| - **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 | ||
| - **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 | ||
| - 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 | ||
| - 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 |
There was a problem hiding this comment.
The blog post uses level 3 headings (###) for major sections, which is inconsistent with other blog posts that use level 2 headings (##) for major sections. For example, lfx_2025_tcp_long_conn, ospp_2025_automation_workflow, and ospp_2025_ut_test all use "## Introduction" and "##" for other major sections. Consider changing "### Introduction", "### My Background", "### How to Succeed in Open Source Programs", etc. to use "##" instead for consistency with the established pattern.
| --- | ||
| title: "From Contributor to Maintainer: My LFX Mentorship Journey" | ||
| authors: | ||
| - jayesh9747 | ||
| date: 2025-02-14 | ||
| sidebar_position: 2 | ||
| --- |
There was a problem hiding this comment.
The folder name "lfx_2025_website_migration" does not match the blog content. The blog is about "From Contributor to Maintainer: My LFX Mentorship Journey" and contains no mention of website migration at all. Consider renaming the folder to something more appropriate like "lfx_2025_maintainer_journey" or "lfx_2025_mentorship_experience" to accurately reflect the content.
| title: "From Contributor to Maintainer: My LFX Mentorship Journey" | ||
| authors: | ||
| - jayesh9747 | ||
| date: 2025-02-14 | ||
| sidebar_position: 2 |
There was a problem hiding this comment.
The blog post is missing several frontmatter fields that are consistently used in other blog posts in this repository. Based on other LFX and OSPP blog posts (e.g., lfx_2025_tcp_long_conn, ospp_2025_automation_workflow), consider adding: 1) a "summary" field to provide a brief description of the blog post, 2) a "tags" field (e.g., [LFX-2025]) for better categorization, and 3) a "sidebar_label" field for improved navigation. This will make the blog post more consistent with the rest of the blog structure.
| title: "From Contributor to Maintainer: My LFX Mentorship Journey" | |
| authors: | |
| - jayesh9747 | |
| date: 2025-02-14 | |
| sidebar_position: 2 | |
| title: "From Contributor to Maintainer: My LFX Mentorship Journey" | |
| summary: "How I grew from fixing small issues to mentoring and reviewing code during my LFX Mentorship 2025 term with Kmesh, plus practical tips for succeeding in open source programs." | |
| authors: | |
| - jayesh9747 | |
| date: 2025-02-14 | |
| tags: [LFX-2025] | |
| sidebar_position: 2 | |
| sidebar_label: "My LFX Mentorship Journey" |
jayesh9747
force-pushed
the
lfx_2025_blog_v2
branch
from
44c3dc1 to
2e74bf2
Compare
Signed-off-by: jayesh9747 <112215167@cse.iiitp.ac.in>
jayesh9747
force-pushed
the
lfx_2025_blog_v2
branch
from
2e74bf2 to
6504527
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 3 out of 3 changed files in this pull request and generated 5 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| name: Jayesh Savaliya | ||
| title: Kmesh Maintainer | ||
| url: https://github.com/jayesh9747 | ||
| image_url: https://avatars.githubusercontent.com/u/123955234 |
There was a problem hiding this comment.
The image_url is missing the version parameter "?v=4" that is consistently used in all other author entries. This should be added for consistency with the existing pattern.
| image_url: https://avatars.githubusercontent.com/u/123955234 | |
| image_url: https://avatars.githubusercontent.com/u/123955234?v=4 |
| --- | ||
| title: "From Contributor to Maintainer: My LFX Mentorship Journey" | ||
| authors: | ||
| - jayesh9747 | ||
| date: 2025-02-14 | ||
| sidebar_position: 2 | ||
| --- | ||
|
|
||
| ### 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 | ||
| - **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 | ||
| 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 | ||
| - **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 | ||
| - **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 | ||
| - 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 | ||
| - 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! |
There was a problem hiding this comment.
The folder name "lfx_2025_website_migration" doesn't match the content of the blog post. The blog post is about the author's journey from contributor to maintainer during LFX mentorship, not about website migration. Consider renaming the folder to something more appropriate like "lfx_2025_contributor_journey" or "lfx_2025_maintainer_journey" to accurately reflect the blog content.
| @@ -0,0 +1,141 @@ | |||
| --- | |||
| title: "From Contributor to Maintainer: My LFX Mentorship Journey" | |||
There was a problem hiding this comment.
The PR title "LFX 2025 : website migration blog" suggests this blog post should be about website migration, but the actual content is about the author's personal journey from contributor to maintainer during LFX mentorship. There's a significant mismatch between the PR description and the blog content. Please clarify whether this is the correct blog post for this PR, or if the PR title needs to be updated to reflect the actual content.
| 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). | ||
|
|
There was a problem hiding this comment.
The blog post is missing the <!-- truncate --> comment that is consistently used in all other blog posts. This comment is a Docusaurus convention that marks where the preview should end on blog listing pages. It should be added after the introduction section to control what content appears in blog post previews.
| <!-- truncate --> |
|
|
||
| ### 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. |
There was a problem hiding this comment.
The word "timezones" should be "time zones" (two separate words) for proper spelling.
| 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. | |
| The LFX Mentorship taught me more than just technical skills. I learned how to work with distributed teams across time zones, think critically about production software (logs are your friends!), and grow into a leadership role in an open source community. |
2 participants
No description provided.