I’ve heard some people take the approach of “merge everything”. Whatever people contribute, merge it. People like to feel like their time is valuable, and that their work is valued.
You can follow up the merge with polish or tweaks but if you merge contributions you’re more likely to see more.
😆 I don’t think you’re supposed to take it literally. And it’s advice for everyone’s pet open source projects that no one else ever seems to contribute to, not really good advice for software that holds up civilization.
Oh for sure. I don’t think this advice applies to projects that already have a following. But many, perhaps most, projects don’t have much of a following even if you intended for others to use it. If you have a pet project that a reasonably small number of users, you might find you get occasional pull requests but they never meet the code standards, or you ask for changes but they never happen and the pull request sits there, or you reject them because you wouldn’t have structured it like that - well consider accepting the pull request and merging as is. Then you can follow up with changes to fix code quality with your own changes.
This approach shows you appreciate the contribution, even though it’s not perfect. If you find the same person contributing often but making the same errors, then for sure mention it in a way that’s easy for them to understand how to resolve it. But if you’re rigid then you probably won’t get so many contributions as people will think they aren’t up to your standards.
I’d also argue that merging then fixing up yourself later would be more time efficient than reviewing code and providing feedback on changes to be made 😆
I do this with my .net barcode parserbuilder project. I make a few comments on the pr for them to fix, merge it and then go over it myself to clean it up. This way they feel appreciated because its merged and the code stays clean and consistent :)
I’ve heard some people take the approach of “merge everything”. Whatever people contribute, merge it. People like to feel like their time is valuable, and that their work is valued.
You can follow up the merge with polish or tweaks but if you merge contributions you’re more likely to see more.
XZ says thank you.
😆 I don’t think you’re supposed to take it literally. And it’s advice for everyone’s pet open source projects that no one else ever seems to contribute to, not really good advice for software that holds up civilization.
SamePicture.jpeg
deleted by creator
Oh for sure. I don’t think this advice applies to projects that already have a following. But many, perhaps most, projects don’t have much of a following even if you intended for others to use it. If you have a pet project that a reasonably small number of users, you might find you get occasional pull requests but they never meet the code standards, or you ask for changes but they never happen and the pull request sits there, or you reject them because you wouldn’t have structured it like that - well consider accepting the pull request and merging as is. Then you can follow up with changes to fix code quality with your own changes.
This approach shows you appreciate the contribution, even though it’s not perfect. If you find the same person contributing often but making the same errors, then for sure mention it in a way that’s easy for them to understand how to resolve it. But if you’re rigid then you probably won’t get so many contributions as people will think they aren’t up to your standards.
I’d also argue that merging then fixing up yourself later would be more time efficient than reviewing code and providing feedback on changes to be made 😆
I do this with my .net barcode parserbuilder project. I make a few comments on the pr for them to fix, merge it and then go over it myself to clean it up. This way they feel appreciated because its merged and the code stays clean and consistent :)