Russ Allbery:
> Bill Allombert <ballo...@debian.org> writes:
> 
>> This is one of the reasons I do not attend DebConf anymore. We are an
>> online organization. Consultation should happen online. Metting are nice
>> but they should not be used to vet consensus and ignore absentees.
> 
>> So I object to Adrian being overriden on that ground.
> 
> That's only a part of what went into this, but I will strongly defend
> using the opportunity of in-person meetings to judge consensus.  It's very
> difficult to judge consensus over email because only the strong opinions
> are visible.  There are frequently situations where there's a large
> sentiment in one direction or another that isn't expressed in long threads
> full of lots of back and forth between a small handful of people who may
> or may not have representative opinions.
> 
> We can't always do it, and we obviously have to be sensitive to the fact
> that not everyone is in the room, but we're also going for consensus, not
> unanimity.  When we have the opportunity to get direction from a large
> gathering of developers, we should make use of it.
> 
> [..]

This was off-topic but now the thread is over I'd like to add some things here:

I don't think using the opportunity of in-person meetings to judge consensus is 
such a great thing. This has been a common theme recently cropping up in FOSS 
environments, pushed by certain groups and justified by the observations that 
"only strong opinions are visible [in email threads]". Much of the time, these 
groups overlap greatly with people that are used to doing things in a physical 
setting, including making decisions by judging crowd consensus.

Debian is primarily an online organisation as Bill says, these are its roots, 
this is how it became so big, and this is where the vast majority of productive 
work is done. I think discrediting all of that simply because "some people are 
loud on mailing lists" is really short-sighted and distorted. These cases are 
few, and not representative. I myself have contributed to a few of these cases, 
but again it's not representative of the vast majority of work that I do. I 
don't feel it's right for people to be judging online discussion methods, by 
focusing on a few negative cases and ignoring all the positive aspects.

Personally, and I'm sure many people are similar, I prefer to have long 
technical discussions like this in writing via email, and not face-to-face. I'm 
a very slow thinker, I don't make very good decisions in the fast-paced context 
of a normal physical conversation. If I sometimes seem like I do, it's usually 
only because I've thought about the problem beforehand and have my main points 
decided. 

Physical discussions encourage non-technical interactions - if you can pick the 
right words and presentation, you can make a crowd empathise with you for 
largely non-technical reasons. I don't think this is a good thing, we should 
recognise that this happens and not allow it to take over Debian's decision 
making processes. Online technical discussions are safer against these sorts of 
effects. People with long technical points to make, don't feel put off by the 
presence of a large non-technical crowd - and here I include "technical people" 
that have not properly thought about the topic or have no stake in the 
discussion. I truly think these latter opinions should be given less weight 
than a properly reasoned and well-thought-out opinion.

These sorts of points, which are vital to a healthy discussion, are easier to 
make in writing. You have an adequate amount of time to think, and you don't 
get interrupted by people who get bored by your thinking time and move the 
conversation on elsewhere before you have a chance to properly respond. Indeed 
in this thread there were lots of good points brought up criticising the 
wording of this policy, that nobody thought about during physical discussions 
at DebConf (which I didn't participate in for these reasons).

TL;DR: Debian is primarily an online organisation and that is its strength; 
physical meetings are overrated for making long-term technical decisions.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Reply via email to