On 01/18/2011 02:15, David Holland wrote:
On Tue, Jan 18, 2011 at 07:06:52AM +0200, Jukka Ruohonen wrote:
> > Why was this removed when there was an active discussion about removing
> > it where no concensus was reached? This sort of thing where commis
> > occur before a discussion is finished seems to be occurring more and
> > more often.
>
> Maybe because the whole tech-userlevel@ mailing list has become poisonous?
> I know several people who abstain from posting anything to the list because
> of the nature of the list and these discussions.
I think that's a vast exaggeration. Then again, maybe you think I'm
part of the problem?
> If one can not use his or her own discretion with what must be one of the
> most trivial files in the system, there is something fundamentally wrong.
> It is easy to block and freeze things (even by an user) simply by posting
> regularly to tech-userlevel@ just to show that there was no "consensus".
The things that appear trivial from a technical perspective are also
commonly the things that are most visible in people's day-to-day use
of the system. Of course something like "operator", which many people
refer to regularly, is going to concern them more than stuff "deep in
the kernel". And in that context, proposing gratuitous changes with no
clear rationale is guaranteed to cause a fuss.
Understanding how this works is essential to working on the visible
parts of the system. Blowing off concerns people raise just because
you think their concerns aren't important (and hence "bikeshedding")
is not the right approach; neither is skipping the review entirely.
It's perfectly possible to propose things on tech-userlevel and get
them agreed on. It just requires doing a little more planning up front
to make sure the proposal has clear motivations and benefits and
addresses likely concerns.
There is a fine art between listening to everybody and getting things
done. When you are listening to people and they are reasonable, then
the process works out well. If the conversation becomes circular, then
you need to thank them for their opinion and move forward. Sometimes
moving forward means that you go with a majority viewpoint if the
minority can't articulate a good technical reason for the objection.
Other times moving forward may mean abandoning your plans. Still other
times (and this is usual), your plans are modified based on input you
received. The more you fight the process, the more the process will
fight you and you'll have an unsatisfactory outcome.
Knowing how to balance this all, as well as having the patience to
practice this dance, can be difficult to know at first, but often the
rewards are better in the end.
Unfortunately, the delayed gratification necessary to do this often
matches poorly with the desire to scratch an itch and move on.
Warner