Q&A highlight
Postedabout 2 months ago
Key Takeaways
Every meaningful project I’ve worked on has benefited more from inclusion than exclusion. The person I help may or may not become a significant contributor to my project, but many times they become the person that can help me with something I’m learning. And so what if I never run across that person again? Maybe they will remember the kindness they received and pass it along.
Anyway, when someone makes a post about a typo in the docs or error message of Racket, or something that can be solved editing one or two files, I like to post something like:
> Nice report. The error is in the file [whatever]. Do you want to fix it and send a pull request? Otherwise we can fix it.
Some people want to contribute and are happy with that. It's a good first step. They may send something more complicated later. Or just be happy to have a commit merged. (Anyway, good bugs reports are very useful, even if the submitter does not fix it.)
As a general recommendation, start with tiny changes. Fixing typos is good because they must be fixed. For features, it's better let's say up to 6 hours of work. You never know if they are going to merge it, so it's better to waste few time. Later, once you have a few contributions try longer tasks.
I actually did a recent conference talk called "Maintaining a Library and a Community" where I discussed how being an OSS maintainer is really about communicating with your users and contributors, more than it is about writing code yourself. And yes, a big part of that is responding to issues _and_ reviewing externally-contributed PRs:
- https://blog.isquaredsoftware.com/2024/11/presentations-main...
I also even just tweeted over the weekend about how a user filed a PR to add a good new option to one of my libraries, but I still had to take time to review it, figure out what additional functionality should be added, then add tests and docs:
Not affiliated with Hacker News or Y Combinator. We simply enrich the public API with analytics.