In sum: early in the cycle - now! - is the time to be clearing the deck,
I did not get this idea from your first post. But if you put it this way, I tend to agree.
Yeah. But that sounds completely different from the proposal to accept "interim" solutions.
I'm sorry if I've muddied the waters by addressing different ideas under the same discussion. I'll try to clarify. I believe I and others are making two related but distinct points: 1. In general, let's be a bit quicker to accept "interim" solutions--that is, to apply changes in stages. I don't see this in any way as lowering our standards. The aim, rather, is to speed up the development process, reducing (sometimes excessive and counterproductive) barriers to improvement of the code. Here's a common cycle in our current approach: * Problem or limitation is identified in existing code * Solution is proposed * Various objections are raised, but (often) no better solution proposed or coded * Time is spent over the course of several months addressing objections * Fresh objections are raised, some based on new changes elsewhere in the core * A new release comes out * Original identified problem remains, unaddressed This could have various possible outcomes: * Issue is eventually fixed * Contributor gives up, and stops submitting patches * Issue sits unaddressed until eventually someone else picks it up The cycle I'm suggesting is something like: * Problem or limitation is identified in existing code * Solution is proposed * Various issues are raised, and submitter (or others) codes responses * Patch is applied, remaining issues are noted * Further work is done to address remaining issues * Fresh patch is reviewed and applied I favour this approach particularly when the patch addresses an identified problem or deficiency in the existing core (as opposed to simply introducing brand new functionality). Does the proposal address a deficiency, is it an improvement on what we have, does it apply without raising bugs, and does it leave the door open to further refinements? Then, generally speaking, I want it in, whether or not it's been infinitely refined. That can come later. 2. Keeping (1) in mind, let's make a particular effort to clear the patch queue and apply improvements early in the development cycle. I'd say, in general, our current threshold is what I'd look for as we're nearing a code freeze (say, the last month). What I'm looking for is high standards but lower barriers in the rest of the cycle.