2 ms·
> It's not about the PRs. It's about everything that goes before you submit your first PR. Reading mailing lists. Actively participating in discussions with the
by strken 6y ago
> It's not about the PRs. It's about everything that goes before you submit your first PR. Reading mailing lists. Actively participating in discussions with the maintainers. Reading the docs.
I've only had 5 or so PRs accepted[0], and all of them have been tiny bugfixes for broken tools. I have no goddamned idea how to get an actual feature merged, because maintainers never comment on the proof-of-concept PRs I put up, even if they have tests and documentation updates. Maybe it's all about mailing lists and out-of-band communication.
[0] not for Hacktober, just in general
- mook 6y agoUnsolicited advice, please feel free to ignore; hopefully you'll be okay with it: Bug fixes tend to not need justification (since the maintainers presumably already agreed), but new features depend on the maintainers agreeing that they want it in the project. Before making the PR, try to find the relevant issue (or create one if it doesn't already exist), and get the maintainer to indicate that they want the feature. Once they've written that down, they're primed to accept it because they'd feel worse about not processing the thing they already committed to.
- watwut 6y agoReality is that giving you such feedback on proof of concept work takes effort, time and is work. As such maintenence needs reason to spend time with it. Do unless you see them engage with past pull requests like that, assume they don't.
- srtjstjsj 6y agoIt's fine. Your fork repo has your new feature, and people can use your fork if they want the feature.