> > I would favor a place where a contributor can mark if s/he would > > recommend the committer should *not* use the squash option. > > That of course could be defined in the contributor guidelines or PR > template (although there it might be a bit confusing to new users that > don't know what this is talking about). Do you know how other project > handle that?
Haven't seen anything like this before. > In the end it is always the decision of the committer how contributed > code makes it into the code base, so having good guidelines for us > would probably be the best solution, right? Yes. General common sense may prove to be the major principle, as I think it has in the past. For example: * Someone raises a PR with bug fixes and major refactoring in separate commits (should not be squashed) * Someone else raises a PR with a single fix, but with extra commits to fix issues with the first commit (*should* be squashed) I wonder if we can track these discussions in a better way, somehow. I have no time to help with these things right now. I think better tracking could help ensure these important tasks do not get forgotten. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
