[drupal-devel] Let's accept more interim solutions

[Nedjo Rogers]

> > > 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.