proposal: don't bump proposals to in-progress

[Martin Pool]

in short: reviewers, please don't bump mps back to in-progress; leave
them in need-review as long as they're being piloted

discussion: If somebody's put in the work to address a bug or add a
feature to Bazaar, we want to help them get it landed, by speedy
positive review, or helping write the tests, or whatever the case may
be.

It seems to me that "work in progress" is a bit of a boneyard for
merge proposals, because it mixes together stuff that's effectively
stalled with things that need just a bit more work to get in.  We can
drive-to-zero the needs-review queue but wip is basically not covered
by this.

Launchpad could do some things to track them more, but that's out of
scope for this mail, about what we can do right now.  (But, it is open
source, and we could perhaps fix some of them.)

So, when reviewing new patches:
 * if it's ok, land it
 * if you ask the person to make some changes, please leave it in
needs review, so we can help out if it seems to get stuck
 * if something is stalling and you think the author may have trouble
doing the needed work (typically, tests), please do it, or offer
 * if you're the author of the patch and don't want review or help at
the moment, of course you can move it to wip, but reviewers shouldn't
push it there (or ask the contributor to do this)
 * if something is running for a long time, make sure there's an inprogress bug
 * if the patch is not a good tradeoff to pilot, link it to a bug and
move it to wip, but be clear with yourself this is very nearly
rejection and saying to the contributor they need to do more before we
pick it up.  realistically this might be appropriate if it's eg a very
small start towards a hard or unimportant bug.

This may cause things to accumulate in needsreview that can't easily
be finished off; in that case we might need to reconsider whether we
need to draw the line differently about what we will finish vs asking
others to finish.  But I think it's better to actually make that
decision rather than having some things lost.

Martin