I opened a pull request on Netflix's codebase. It didn't get merged. Here's why that still mattered.

Kavya — Sat, 16 May 2026 07:29:17 +0000

Let me be honest with you. I was not sitting at a desk with a plan when this happened. I was looking for open source repositories to contribute to, mostly because I needed to build a portfolio and everyone online keeps saying "contribute to open source" without really telling you what that means when you are just starting out.
So I started applying.Metaflow caught my attention because it is a Python ML pipeline framework built by Netflix engineers and used in actual production machine learning workflows. Not a toy project. Not a tutorial repo. Something real people depend on.
I found issue #3144.

The bug
timeout_decorator.py had a problem. The file used signal.SIGALRM — a POSIX signal that lets you set an alarm for a process and interrupt it after a timeout. Clean concept. One problem: SIGALRM does not exist on Windows. It is a Unix-only feature.
So if you were a Windows user trying to use Metaflow's @timeout decorator, Python would throw an AttributeError or ImportError when it hit the signal.SIGALRM line. No helpful message. No graceful exit. Just a crash that tells you nothing useful about why it happened.
This is one of those bugs that is easy to miss when you are building on a Mac or Linux machine, which most ML engineers are. But for anyone on Windows trying to use the framework, it was a silent wall.

What I did
The fix itself was not complicated. I added import sys at the top of the file and wrapped the SIGALRM-dependent code in platform checks.
In task_pre_step, before any SIGALRM logic runs, I added:
pythonif sys.platform == "win32":
raise RuntimeError(
"The @timeout decorator is not supported on Windows "
"(SIGALRM is POSIX-only)."
)
In task_post_step, I added a guard so the cleanup code — signal.alarm(0) — would also be skipped on Windows:
pythonif sys.platform != "win32":
signal.alarm(0)
Eight lines changed. Five removed, eight added. The idea was simple: if you are on Windows, fail immediately with a clear message instead of crashing with a confusing error somewhere deeper in the stack.

The review
This is where it got interesting.
An automated reviewer called Greptile analyzed the PR and gave it a confidence score of 4 out of 5. Safe to merge. The logic was sound. The platform guard was correctly placed before any SIGALRM access could be reached, so the module-level import signal was harmless even on Windows.
But then it flagged something I had missed.

"The error raised here is RuntimeError, but the rest of this decorator uses MetaflowException for user-facing configuration errors."

It was right. I had used a generic Python exception. But everywhere else in that file — and across Metaflow's decorator system generally — they raise MetaflowException, which is the project's own exception class. It routes through Metaflow's formatting pipeline, gets caught cleanly by @catch, and produces a properly formatted error message for the user.
My RuntimeError bypassed all of that. It would work. But it was not how Metaflow does things. It was like writing a fix that solved the problem but ignored the style guide of the codebase you were writing it in.
That is a real thing you only learn by actually reading a large production codebase carefully. Not from tutorials. Not from LeetCode. From opening files and understanding how the pieces fit together.

Why it was closed
The PR was closed without merging. The maintainer closed it, which means either the fix needed changes, or there was something else going on with the issue. My best guess: they wanted MetaflowException instead of RuntimeError before merging, and I had not yet updated the PR when it was closed.
I am not going to pretend that does not sting a little. You spend time reading a codebase used in Netflix's production ML systems, you find a real bug, you write a fix that a bot rates 4 out of 5, and it still does not get merged.
But here is what actually happened. A bot trained on software engineering standards reviewed my code and gave it a near-passing score. A real maintainer looked at it. I learned what MetaflowException is, why it exists, and why consistency in exception handling matters at scale. I learned that production codebases have conventions that go beyond "does the code work" — they care about "does this code fit the system it lives in."
That is not a lesson you get from building your own projects. You only get it by reading someone else's.

What I would do differently
Change RuntimeError to MetaflowException. That is it. One word. And honestly I learned more from that one bot comment than from most courses I have taken, because it was specific, it was about real code I wrote, and it pointed to something I had to go understand before I could fix it. go understand before I could fix it.
If you are a student trying to break into engineering and you have been told to "just contribute to open source" without being told how — here is what actually helped me:
Find a bug that is small enough that you can understand the whole fix but real enough that it matters. Read the files around the bug, not just the bug itself. Understand the conventions of the codebase before you write a single line. And submit the PR even if you are not sure. The review will teach you more than the research.
The PR is closed. The branch is still sitting there with unmerged commits. And I now know exactly what SIGALRM is, why it does not exist on Windows, what MetaflowException is and why Netflix engineers created it, and how production-grade exception handling differs from "just throw an error and see what happens."
That is worth a lot more than a merged commit.

The PR is #3185 on Netflix/metaflow if you want to read the review yourself.

I built a Jira bot from my broken laptop because LinkedIn made me feel like I had to

Kavya — Tue, 07 Apr 2026 16:01:27 +0000

I was eating ramen and scrolling LinkedIn when I noticed something.
Project managers complaining that engineers never update Jira. Engineers complaining that PMs create tickets with zero context. Both groups agreeing that converting meeting notes into tickets manually is a nightmare. Job posts asking for "Jira automation experience." Everyone nodding. Nobody building anything.
I am a college student with zero work experience and a laptop that takes four minutes to open Chrome. So naturally, I decided to build the thing they were all complaining about.

The skeleton in the PM and engineer relationship
Here is what nobody says out loud: the real problem is not Jira. It is that after every meeting, someone has to do the boring work of translating what was said into structured tickets. PMs don't want to do it. Engineers don't want to do it. It falls into a gap and either gets done badly or not at all.
I figured if I could automate even 60% of that, I'd be solving something real. Not a tutorial project. An actual problem that people with real salaries were venting about publicly.

How it started (badly)
I found Atlassian. I Googled "Jira API free tier for students." I dug through forums and documentation for days because everything useful seemed to cost money. I had no idea what I was doing. My GitHub was rusty. My laptop was running on prayers and a 40% battery that never charges past 40%.
I wrote the first version in online compilers because my machine couldn't handle running a local server without freezing. Someone eventually told me about Replit. That saved me.
It took about two weeks to get something that actually ran.

What the tool does
You paste a meeting transcript into a form. The app scans it for action items using keyword matching — words like "will," "to do," "action item," "needs to." It then connects to the Jira API and creates real tickets automatically.
No OpenAI. No API bills. Just Python, Flask, keyword logic, and a lot of Stack Overflow.

The part that actually humbled me
The API was not the hard part. The hard part was that people talk like humans.
"Maybe someone should look into that" is not an action item. "We should probably circle back on this" is not an action item. "I feel like the timeline needs revisiting" is definitely not an action item, but my first version created a Jira ticket for it anyway.
I spent days tweaking keyword rules to stop the bot from hallucinating tasks. It is still not perfect. But it no longer files a ticket every time someone says "we should."
That problem — messy human language versus structured systems — is apparently what engineers at big companies work on too. I did not expect to stumble into it from a bowl of ramen.

Deployment, which was its own story
Vercel did not work. I tried for a day. Moved to Render. Got it running. Celebrated. Then my original Jira API key expired and I had to recreate all my environment variables from scratch.
One full extra day. For an expired key.
Nobody tells you about this part.

What is still broken (honestly)
It only handles plain text. No audio transcripts yet. It cannot assign tickets to specific people. If the Jira API slows down, the page just hangs — I have not added proper timeout handling. And the keyword matching misses anything phrased indirectly.
Next version: better error handling, maybe a lightweight NLP layer so it understands "John said he'd take care of the auth bug" as an action item assigned to John.

Why I'm writing this
Because the LinkedIn posts that made me build this were from people with years of experience who were still annoyed by a problem a college student with a broken laptop could take a shot at.
You don't need the job to build the thing. Build the thing and then get the job.
Live demo: https://meeting-to-jira-assistant.onrender.com/
GitHub: https://github.com/k-kj0

DEV Community: Kavya

I opened a pull request on Netflix's codebase. It didn't get merged. Here's why that still mattered.

I built a Jira bot from my broken laptop because LinkedIn made me feel like I had to