[ArneBab]

"Merge first, fix later"

I agree with merge first fix later, if you have sufficient work hours to actually do the fix: in the Freenet project we lost many contributors, because their code wasn’t merged in time, so they just lost interest: “my effort is wasted here”.

Truth is: Those who get their code merged quickly are more likely to review other code, so they grow the community.

You can only do that if you actually have the time to keep quality up.

[PieterH]

"Quality" is a false goal. Remember the first arguments over Wikipedia and article "quality"? It is exactly the same here. You need people, contributors, eyeballs. Get that, and quality will emerge smoothly over time. Losing a contributor because "quality" matters more is self-destructive.

The rules I explained work together. If you allow large confusing patches, or features that don't solve clear problems, then it won't work as well.