By Sarthak Ivare
A Little About Me
I'm Sarthak Ivare, a 2nd-year Computer Science student from Pune, India passionate about DevOps — building CI/CD pipelines, containerizing applications, and setting up monitoring infrastructure. Outside college I spend most of my time working on real-world DevOps projects and contributing to open source.
How It All Started
It started with a project. I was building a monitoring stack using AWS EC2, Prometheus, and Grafana — the kind of hands-on work I genuinely enjoy. While studying Grafana deeply for that project, I discovered it was an open source project with a large active community. That curiosity led me to explore how open source contribution actually works.
I had heard about it before but never done it. I had no idea how PRs worked in a real production repository or how maintainers communicated. So I decided to find out.
My First Attempt — and the Advice That Changed My Approach
Before finding my first issue in Grafana Loki, I came across a code-related PR and jumped straight into commenting, thinking I could help. JStickler, the Loki docs maintainer, responded kindly but gave me advice I didn't expect:
"As a beginner, you should start with good first issues — they'll help you understand the contribution process."
That one comment reframed everything. Instead of trying to look impressive immediately, I went back to basics — filtered issues by good first issue label and started reading properly.
Finding the Right Issue
I found issue #19816 — the documentation around duration fields in Grafana Loki was ambiguous. The docs had a single generic description for that didn't distinguish between Prometheus duration fields and Go native duration fields, which actually support different time units.
Small docs fix. But real, needed, and something I understood. Before starting I commented on the issue asking if I could work on it. JStickler confirmed — go ahead.
The Mistake That Taught Me the Most
I forked the Loki repository, studied the codebase for a couple of days on Ubuntu, and made my changes. But I made a classic beginner mistake — I pushed directly to the main branch of my fork instead of creating a feature branch.
JStickler caught it and pointed out something else I had missed — the file I edited had a clear note at line 6:
"DO NOT EDIT THIS FILE — This file has been automatically generated from its .template, regenerate with make doc from root directory."
She guided me to make edits in /docs/templates/configuration.template instead. Rather than closing my PR she helped me fix it.
That moment taught me something no tutorial ever could — maintainers in good open source communities want you to succeed. They are not gatekeepers, they are guides.
The Fix Itself
The change clarified the distinction between two duration field types in Grafana Loki:
Prometheus duration fields — support: ms, s, m, h, d, w, y
Go native duration fields — support: ns, us, µs, ms, s, m, h
Two bullet points. But it removed real ambiguity that was confusing users configuring Loki.
JStickler merged it on April 23 after 8 review conversations — the real back and forth of a production review process.
What the 4-5 Days Actually Looked Like
Day 1-3: Forked the repo, studied Loki's docs structure, read contribution guidelines
Day 4: Found the issue, asked the maintainer, started making changes
Day 5: Opened the PR — made the branch mistake and Fixed based on JStickler's feedback, addressed review comments
Merged: April 23
What I Learned
- Read the contribution guide before anything else. Every repo has one. It tells you exactly where to make changes and what maintainers expect.
- Ask before you start. A simple comment on the issue saves everyone time and signals you're serious.
- Mistakes are part of the process. My PR had multiple commits because I kept fixing things. That's completely normal.
- Small contributions are real contributions. A docs fix that helps thousands of users configure Loki correctly — that matters.
- Take advice from maintainers seriously. JStickler's "start with good first issues" comment changed my entire approach to open source.
What Happened Next
That first PR gave me the confidence to keep going. I continued contributing to Grafana Loki and also started contributing to Kubescape — a CNCF Kubernetes security tool — where I worked on CI/CD integration guides for Jenkins and GitLab among other contributions.
Consistent small contributions compound into something real over time.
For Students Reading This
If you're a CS student wanting to start open source:
-Pick a tool you actually use — genuine interest shows
-Start with documentation — lowest barrier, still genuinely valuable
-Don't wait until you feel ready — you learn by doing
-Take maintainer feedback seriously — it's gold
-Find projects with kind maintainers — Grafana Loki has them
Your first PR doesn't have to be impressive. It just has to be merged.
Sarthak Ivare is a CS student from Pune, India focused on DevOps engineering. He contributes to Grafana Loki and CNCF Kubescape. Find him on GitHub at https://github.com/ivaresarthak-cloud and connect on Linkedin at https://www.linkedin.com/in/sarthak-ivare-94b25b3a3
Top comments (0)