Table of Contents
I’m a beginner programmer. I know what loops do, I can read Python, and I’ve done basic git pushes and pulls. But I’d never submitted a pull request. I didn’t even know what a PR was a few hours ago.
Now I have 7 pull requests across 3 different repos, including a bug fix in a famous 3,259-star chess engine, and a fully tested toolkit that helps anyone find and contribute to open source projects.
This post is about how I did it, what went wrong, what I learned, and whether AI-assisted contributions are actually helpful or just noise.
The Toolkit
I built a structured workflow toolkit (source on GitHub) with 13 Python modules covering the full contribution lifecycle: discovery, evaluation, forking, branching, validation, PR submission, and progression tracking. 50+ property-based tests. Full spec documentation.
Cost: 57 Kiro tokens. Kiro did the coding. I made decisions.
The Contributions
Round 1: distreqx (JAX probability distributions, 47 stars)
| # | PR | What I Did | Difficulty |
|---|---|---|---|
| 1 | #99 | Fleshed out docs homepage with feature tables, examples, “Why distreqx?” section | Easy |
| 2 | #100 | Added jaxtyping shape annotations to Normal distribution | Easy |
| 3 | #101 | Added 17 tests: jit, grad, correctness (analytic), edge cases | Medium |
Round 2: Rapid Fire
| # | PR | Repo | What I Did | Difficulty |
|---|---|---|---|---|
| 4 | #64 | command-line-chess (535 stars) | Added Bishop & Queen movement tests | Medium |
| 5 | #65 | command-line-chess | Added InputParser notation tests (8 tests) | Medium |
| 6 | #133 | sunfish (3,259 stars) | Fixed real bug: self.ec → self.wc (castling rights) | Medium |
| 7 | (none) | distreqx | Bernoulli type hints (branch pushed, PR rate-limited) | Easy |
Honest Assessment: Is This Actually Helpful?
I asked myself, and Kiro, this question directly. Here’s the honest answer:
The sunfish fix (#133) is the most unambiguously useful. It’s a real bug in real code that was open for over a year. The NNUE chess engine was referencing a non-existent field (self.ec instead of self.wc), which means castling rights weren’t being saved/restored correctly during move generation. Two characters fixed it.
The tests are genuinely helpful. The distreqx tests verify mathematical properties (entropy of standard normal = 0.5*log(2πe), gradient of log_prob matches calculus, jit compilation works). The chess tests cover pieces that had zero coverage. Maintainers need this.
The docs are helpful but replaceable. Anyone could have written feature tables. The value is that someone actually did it.
The type hints are the weakest. They improve IDE experience and documentation, but submitting them one distribution at a time might annoy a maintainer who’d prefer a single consolidated PR. Lesson learned.
Is Using AI “Cheating”?
No. Here’s why:
- Maintainers care about the result, not the process. A correct bug fix is a correct bug fix regardless of how you found it.
- AI doesn’t make the decisions. I chose which repos to contribute to, which issues to tackle, and approved every change before submission.
- The code still has to be correct. Kiro wrote the test code, but the tests verify real mathematical properties. If they’re wrong, they fail.
- Transparency matters. I’m writing this blog post openly about the process. No deception.
That said, rapid-firing multiple PRs to the same repo might come across as spammy. Quality over quantity is the move going forward.
What I’d Do Differently
- Ask before submitting multiple PRs. Drop a comment on the issue first: “I’d like to work on this. Any preferences on approach?” This shows you’re a collaborator, not a bot.
- Batch related changes. Instead of 3 separate type-hint PRs, do all distributions in one PR.
- Run the full test suite locally before submitting. I verified changes were syntactically correct but didn’t run the full jax test suite (would need GPU setup). CI will catch issues, but it’s better to catch them first.
- Wait for merges before moving to the next repo. Merged PRs are worth 10x open PRs for credibility.
Does This Help My Credibility?
Honestly: a little, not a lot. Here’s the realistic picture:
- GitHub profile: Shows green contribution squares and PR activity. Better than an empty profile.
- The sunfish contribution: Having a merged PR on a 3,259-star repo is a real signal. But it needs to get merged first.
- The blog post: Demonstrating process, tooling, and self-awareness about AI usage is probably more valuable than the PRs themselves for professional branding.
- For job applications: 1-2 merged PRs to well-known projects matter more than 7 open PRs to small ones.
The real credibility comes when PRs get accepted. I’ll check back in a week.
For Other Beginners
If you’re thinking about contributing to open source:
- Start with issues labeled “good first issue” or “help wanted.” Maintainers literally asked for help.
- Documentation and tests are undervalued. They’re low-risk, always welcome, and force you to read the code.
- Small is fine. A two-character bug fix that’s correct is worth more than a 500-line feature that’s broken.
- Use AI tools without shame. They handle the scary parts (git commands, PR formatting) while you focus on understanding the change.
- Be a collaborator, not a drive-by. Comment on issues, ask questions, respond to feedback.
Technical Stack
- Kiro: AI development environment
- Python 3.8+: Helper modules
- Hypothesis: Property-based testing
- GitHub CLI: Fork/PR operations
- Spec-driven development: Requirements → Design → Tasks → Implementation
What’s Next
- Wait for PR reviews and respond to feedback
- Look for contributions in my other interest areas (Go game, Obsidian, Raspberry Pi, education tools)
- Try a harder contribution: a real feature addition or refactor
- Update this blog post with merge results
Built with Kiro in 57 tokens. Toolkit source: professor314/open-source-contribution-workflow