There are people submitting code with wrong licenses or no attribution.
There are people just submitting for the sake of submitting - I dare github profiles for this.
There are people who could need some feedback on their code, so that future contributions have better quality.
And it can be very burdensome for a maintainer, assuming he maintains within its free time, to perfectly communicate and elaborate on each contribution.
Also, maybe the project has a feature freeze because in the aimed architecture the same solution would be implemented externally.
Its just not that simple and people generalizing or concluding too fast are mostlikely in the wrong.
Bad PR travles faster and further though.
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 see where you came from.
There are people submitting code with wrong licenses or no attribution. There are people just submitting for the sake of submitting - I dare github profiles for this. There are people who could need some feedback on their code, so that future contributions have better quality.
And it can be very burdensome for a maintainer, assuming he maintains within its free time, to perfectly communicate and elaborate on each contribution.
Also, maybe the project has a feature freeze because in the aimed architecture the same solution would be implemented externally.
Its just not that simple and people generalizing or concluding too fast are mostlikely in the wrong. Bad PR travles faster and further though.
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 😆