2 ms·
Regardless of your opinion, if you have any interest in code quality (hint: you should), then you should respect the contributing guidelines for the project you
by jonaf 10y ago
Regardless of your opinion, if you have any interest in code quality (hint: you should), then you should respect the contributing guidelines for the project you are contributing to.
Your argument / opinion as stated could have "commit history" replaced with "unit tests" and in many circles (for some reason), people are still making that argument. For a project to be healthy, a critical eye must be used for every change: from the code, to the tests, to the commit message. If you don't care about any one of these, you are saying you don't care about the quality of the software. I would deny your PR on principle. My project needs more quality than it needs more contributors.
Note that I did not suggest squashing is good or bad. My opinion on that is not related to the fact that you should care about it and treat it as just as important as your contribution, and you should respect the project enough to abide their guidelines for contribution (unless your contribution is revising those guidelines).
- marssaxman 10y agoOf course. I'm not talking about projects where I have already made a commitment to participate, though: I'm talking about the process before that, where there's some open-source project I am using or otherwise interested in, and I consider getting involved and contributing. The higher the initial barrier to entry, the more likely it is that I'll just shrug my shoulders and say "fuck it". A complex process for contributing changes, with lots of unusual fiddly steps about exactly how commits should be formatted, makes it more likely that I won't ever make that first commit - especially because the first commit tends to be something trivial where it's as much about dipping my toe in and seeing if I want to do something as about the actual change I've made. So, yes, I certainly do respect the project enough to abide by their guidelines for contribution: but if those guidelines demand too much work of me, that respect will take the form of quietly walking away and spending my time on something else, and the maintainers of the project will likely never know I had any interest in helping to begin with. Guessing that there might be other people like me in the world, then, I suggest that having a complex and specific process for open-source contribution is likely to reduce the pool of devs willing to get involved, and it's worth considering whether the amount of work saved by requiring devs to jump through these hoops outweighs the obstacle that creates for recruitment.