I'd like to open up a discussion on how we should handle code changes. I like the review, then commit model, which appears to be what Crunch follows as well (according to its bylaws):
Action Description Approval Binding Votes Days Code Change A change made to a codebase of the project and committed by a committer. This includes source code, documentation, website content, etc. Lazy approval (not counting the vote of the contributor), moving to lazy majority if a -1 is received Active committers 1 I'd like to know what people's thoughts are on this commit policy. Also I'd like to discuss how the commit should actually be applied and by whom. Here are some thoughts I had: 1. When a patch is applied, it should be applied as a single commit. So, commit history should be squashed. This squashing can be done by either the person submitting the patch or by the person committing the patch. 2. Patches should be committed by someone who is not the submitter. 3. If the person committing the patch must squash commits, then they should use --author to retain the original author. 4. The person committing the patch should add --signoff to indicate they signed off on it in the commit message. What do people think about this? Please share any useful learnings from other projects :) -Matt