[csw-maintainers] On examining proposals (was: new mailing list?)

[Maciej (Matchek) Blizinski]

On Tue, Jan 19, 2010 at 5:24 PM, Philip Brown <phil at bolthole.com> wrote:
>>It's a classic example when somebody makes a proposal, the vast
>>majority of maintainers support the idea, Phil says no, and the topic
>>dies a quiet death.  I would like this not to happen any more.
>
>
> I will mention here that the most common reason for this sort of
> cycle, is that I point out potential problems in the proposal, and
> no-one can come up with decent fixes for the problems in the proposal
> that I bring up.
> So then the flawed proposal dies. And in a logically based system,
> that is a GOOD thing.
> Flawed proposals SHOULD "die a quiet death". Not every proposal should
> succeed; even
> initially popular ones.
>
>
> That being said... I didnt even say "no this list should not be
> created or used".
> I only pointed out that it wont fully achieve specific things that Ben
> stated he thought it would do.
>
> It was nice to see that on this proposal, people actually replied to
> my comments in a useful manner, calmly and rationally. This is GOOD! I
> LIKE this! :-) My goal is not "stop all proposals", but only "point
> out any flaws in them that I can see". If people actually address
> those flaws, then I will cheerfully support a proposal I may have been
> initially against.

I'm glad that this thread touched on the proposal examination topic.
It's also related to one of Sebastian's e-mails[1] and relevant to the
last post in the alternatives topic (the one cc'd to board@).  You
mention that I haven't responded to the issues that you've raised
about the alternatives package.  This is true, I haven't responded to
them, and I've submitted the package for release without any changes
and without further technical discussions.  This is mostly because
I've lost my faith in technical discussions such as the one about
alternatives.  I'll try to explain why.

I'll start with pointing out some assumptions, that, as I understand,
linger behind any discussion over a proposal.  The first one is that
you, Phil Brown, are in the central decision making position.  I
haven't seen it written anywhere, but from how I see things are
working around here, it's pretty clear that if you say "yes", it
happens, and if you say "no", it doesn't.  I'm not sure if the
leadership position is something you consciously aimed for, or
something that by itself emerged out of the chaos, but in either case,
from all the people in OpenCSW, you seem to have the most power in
stopping things from happening.

You said that the proposals die when you point out potential problems
in the proposal, and no one can come up with decent fixes.  That's
correct, you do point out potential problems, and in most cases the
issues you raise are valid in the sense that they are sentences which
indeed seem to be logically true.  For instance, that
"update-alternatives" is a long word to type.  This is something that
could be in some context described as a flaw, and could be potentially
addressed by providing a shorter name.

In the case of the mailing list, you indeed haven't said that "no,
this list should not be created or used".  But I don't think that it's
possible, in your position, to avoid this context and this implicit
meaning, when you point out potential problems.  When you write "here
is flaw A" and it's hard to solve, it pretty much means that the
proposal won't pass.  I know that it's frustrating when any message
you write can have implicit meanings that you haven't intended.
Language is ambiguous.  Smileys can help, but if you input a smiley,
it's still ambiguous: do you smile because you're friendly, or is it
an ironic smirk?  If someone reads the smiley the later way, you're
unlikely to see them cooperating with you in the future.  However,
there's a bunch of specific implicit interpretations of your messages,
that you can pretty safely assume to be there, especially considering
that you're a release manager.  One of the way to interpret them is
the search for a potential answer to the question: "does Phil approve
of the proposal or does he not?", and "what is there to be done before
Phil accepts the proposal?"

I'm sure that people read and carefully consider all the potential
problems that you point out.  In some cases they respond and this
leads to the improvement of the proposal, but there are multiple ways
in which this process can go wrong.  If the back-and-forth discussion
goes on for too long, and new issues are introduced when the old ones
are resolved, the proponents of the proposal might get an impression
that there are flaws in the flaw search procedure.  Or, to put it
bluntly, that flaws are being made up all along as necessary, just to
keep at least one flaw on the stack, so that the proposal never
passes.  I'm not saying that this is what actually happens, but this
hypothesis is sometimes startlingly consistent with the observation.
Once someone gets this impression, it triggers a chain reaction: they
don't trust the process any more, they start assuming malevolence of
the other party.  When it happens, it's hard to undo.  Because all the
communication is tainted, it loses value.  In other words, it doesn't
matter any more what any of the sides is saying; the only thing that
still matters is what they do.  Any pointed out flaws lose any actual
technical meaning, they are only seen as just another way of saying
"no".

After all, flaws are relatively easy to find, no matter how good the
proposal is.  There will be often a tradeoff situation, and you can
keep on always pointing out that negative side of the tradeoff.  Given
some power, one can make it a game which is impossible to win.

This situation is somewhat similar to internet trolling.  In trolling,
one of the sides abuses the conversation by putting forward
disagreeing or otherwise challenging statements only to make the other
side uncomfortable and upset.  The main difference is that trolling
mostly bases itself on the asymmetrical emotional engagement, while in
the case of technical proposals that we use to have, it's probably
something else.  Perhaps asymmetrical technical engagement (one side
is dependent on the technology being examined, while the other is
not).  Or maybe it's about the decision making power.  Or both.

I understand that the job of a release manager is saying "no".  The
vital part is to say "no" at the right times, and it takes a lot of
effort to be accurate in it.  It's very, very important to foresee any
potential problems, as fixing a problem that has made it outside can
take 10-100 times more effort than it would have taken otherwise.
This should not be underestimated.  It's therefore very important that
the people on the receiving end of the "no" understand and accept the
reasoning behind it.

How to mitigate this communication breakdown problem?  I think that
the first thing is to bring implicit to the explicit.  When a flaw is
pointed out, is it put forward as a show stopper or just a side note?
It would also help if you, being in the leadership position, to
present a summary of the gains and losses from each possible choice,
what would be the size of the impact of each potential problem, and
what would be the tipping point on the yes/no balance.  How many
people would be affected by the flaw?  Can it be supported by any
statistics or estimated numbers?  What would be the positive impact of
the proposal?  What would be the overall outcome for the project?  Can
there be any other solution that solves the original problem?

Of course, you can shrug and say that you don't care about that and if
there's a communication problem, you just stop working with the
individual in question.  Sure, it's one of the things you can do.
Maybe it's not worth your time to do research and make more extensive
evaluations.  Maybe it's not worth your time to work to regaining lost
cooperation.  But being in the leadership position, you bear a large
share of the responsibility to keep the community in a good shape,
whether you want it or not.  When you consider this thought, don't
find flaws on just one side of the argument.  Try to see flaws and
values on both sides.  Or perhaps you'll find a third solution?

Maciej

[1] http://lists.opencsw.org/pipermail/maintainers/2009-December/005185.html