Open source · process · 2026-05-12

How I triage a small open-source issue

I do not pick issues only because they look easy. A small-looking issue can still be a bad use of time if the repository is inactive, the reproduction path is unclear, or the expected behavior is mostly opinion.

My first pass is simple: check recent commits, open pull requests, maintainer replies, test setup, and whether the issue has a concrete definition of done. If any of those are missing, I either ask a clarifying question or move on.

What I look for

• A recent commit or maintainer response, ideally within the last few months.
• A bug report with enough context to reproduce or write a narrow test.
• A code path that can be changed without redesigning the project.
• Existing tests, or at least a command that proves the project still runs.

What I avoid

I usually avoid stale repositories, issues with several ignored pull requests, and tasks where the requested change is more product direction than code. Those can be useful discussions, but they are not good first contributions.

The rule I keep coming back to

A good contribution should make the maintainer's job easier. That means a small diff, a clear test or verification step, and a pull request description that explains the reason for the change without overselling it.