[RFC] branch --bind

[Martin Pool]

2010/1/11 Stephen J. Turnbull <stephen at xemacs.org>:
> Martin Pool writes:
>
>  > and we also need to get better at resolving questions like this,
>  > without it getting into mutually-assured-discouragement.
>
> Actually, I think Ian has the right of it.  Make it a priority.  That
> means you need to get somebody to do it, ie, make that person
> responsible for getting it done.  Your people all know how to do that
> right (consulting users, other experts, etc, integrating various
> requirements and suggestions), so any of the interested parties would
> do.
>
> In other words, questions that lead to m-a-d outcomes do so because
> all concerned realize this is something that should be a priority, but
> they're frustrated because their other responsibilities mean they can
> only work on it part time, and they know they have no claim on others'
> time and commitment to not complain about design decisions.

That's true, and this kind of jointly concentrated effort, or absence
of it, has been behind things that turned out well or badly in the
past.

One thing we do is not swamp people with priorities, so they have at
least some time to think about this.

However, we can't make things a priority just because somebody happens
to spend a couple of hours on it on the weekend.  It seems to me the
options are:

 * say, "thanks, but no, not until we can all think about this", which
at least limits how much we can sink into it; the drawback is that
things don't move at all
 * take it by default, with those left out of the conversation not
having their say - that is bad
 * immediately switch course to this - there is some risk of thrashing
 * look for smaller bits to take first, which is what I hope to try here

-- 
Martin <http://launchpad.net/~mbp/>