Bug#844431: Revised patch: Oppose
Russ Allbery:
> Bill Allombert <ballombe@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 to: