As most people reading this have probably seen, xkcd found a
particularly entertaining Wikipedia
argument. (It is all true. There are at least 40,000 words arguing over
whether to capitalize an "i" in a page title. I went and looked last
night and spent several hours following the conversation.)
This is, of course, funny, and I'm sure lots of people went away smiling
at an excellent example of
bikeshed painting
on the Internet. But I think it's rather more serious than it appears to
be. In fact, I would go so far as to say that it is a visible
manifestation of a deeply-rooted problem that is the core of why I
personally refuse to contribute to Wikipedia in any way that requires me
to invest non-trivial time or become a member of that community.
To explain that statement requires a bit of background.
One of the very first services I found when I joined the Internet in 1993
was Usenet. Originally, I talked about comics collecting and then Magic:
The Gathering, but I eventually ended up involved in Usenet governance. I
spent more than ten years deeply invested in Usenet hierarchy
administration; roughly, the process of agreeing on names for and
sometimes moderators for global Usenet discussion groups, as well as all
the supporting infrastructure for Usenet news server administrators to
agree upon and share articles in those groups.
Usenet newsgroup creation was, throughout that period, a consensus-driven
process. There was a voting system that was used to measure consensus,
but the voting system was largely designed to ensure that rough consensus
existed (it was heavily skewed towards not changing anything). We took
great pride in that fact. I'm sure that one could find many articles from
me proudly championing the concept of a consensus-based decision-making
process against many alternatives.
That means I was also there when the toxic flaws at the heart of a
consensus-based process completely destroyed it and, as a side effect,
destroyed the community of people who had formed around it. I will never
again invest my time and energy in a community that operates solely via a
consensus process unless that community is small enough that consensus can
actually work (which means not much more than twenty people). Consensus
decision-making in large groups destroys communities and hurts people.
These sorts of extended arguments on Wikipedia are not rare anomolies.
They happen with some frequency; just by going through the debate xkcd
references and looking at pointers, you can easily find others (Sega
Genesis, cat ownership vs. companionship, endless notability debates...
there are many). They look funny from outside, but from inside they're
hugely demoralizing. Even when they don't get heated and spill over into
personal animosity (and if they don't do that, you're lucky), they consume
astonishingly vast quantities of time exactly not the resource that you
want to be squandering in volunteer projects. And they do so without
giving back anything emotionally.
I know these arguments very well. One of the most contentious and angry
arguments in the history of Usenet newsgroup creation was the argument
over whether, when breaking up a group into multiple more focused groups,
to rename the original group to end in *.misc or leave its existing name.
This argument went on for years and led to deep, lingering hatred between
the participants. It's the same sort of thing.
These arguments happen in the way that they happen because there is toxic
waste at the center of Wikipedia's governance process. And that toxic
waste hurts people, wastes their time, and destroys their willingness to
volunteer. It undermines community, which is sad and ironic because the
whole point of consensus decision-making is to create, support, and
empower community. But it doesn't work. It doesn't work for two very
simple but very closely-related reasons: it's impossible to ever end an
argument, and there is no incentive for anyone to shut up. As a result,
it is nearly impossible to get the decision-making to cohere into
something that is timely, consistent, unambiguous, and
final.
These are not optional requirements of a decision-making process. Without
them, people will lose faith in the decision-making process itself, and
some people will learn that, as long as they never stop talking about
something, they can prolong the debate indefinitely and possibly
eventually get their way.
Now, of course, I'm deeply involved and invested in Debian. And on the
surface, it may look like Debian also uses a consensus-based
decision-making process. But while Debian decision-making has some
problems, it's much healthier for a few reasons that are useful to
examine:
-
Individual packages in Debian are not managed by consensus, but rather
fall under the authority of the package maintainer, who is either a
single person or a small team. (Consensus works in small teams; it's
great if the number of people involved is five or less.) This
drastically limits the number of decisions that are subject to a
large-scale consensus process. Nearly all decisions in Debian are
made directly by the person doing the work, and only in exceptional
circumstances can some larger process be invoked.
This, on the surface, sounds like it could be similar to Wikipedia,
but note that appeals to a larger process are much rarer in
Debian than they are in Wikipedia. There is a strong bias in favor of
letting the person working on the package do their job however they
want to do it. This is more social than structural, but it's a core
value (and we should be very careful about changing it).
As a result, Debian operates less by mass consensus and more as a
federation of semi-autonomous fiefdoms. This sounds worse: it sounds
authoritarian and non-democratic. But it's significantly more
functional, and it doesn't waste people's time.
-
On appeal, and for broader questions that necessarily cut across
multiple packages, there are several people in Debian who are
perceived as having clear authority to make timely and relatively
final decisions, who are almost never overruled, and who can therefore
effectively end arguments. These include core teams like ftp-master
or the release team, formal appeal bodies like the Technical
Committee, and the Debian Project Leader. Not all of this ability is
written in black and white in the governance process, but that's not
the important part; the important part is that it works in practice to
provide timely, consistent, unambiguous, and final decisions most of
the time. (Some parts work better than others, and we do struggle
with timely, but I've seen much, much worse.)
-
There is a well-established ultimate appeal (a General Resolution),
the ultimate appeal process is very specific and concrete, there is
little or no ambiguity or human interpretation involved in analyzing
the results, it is time-limited, and it's almost universally
respected. Everyone abides by the result of a GR if matters get to
that point, and while it's theoretically possible to propose another
GR immediately to overturn the first one, this doesn't happen in
practice. There's also substantial pushback against invoking the GR
process for anything that isn't really important.
We still occasionally devolve into endless discussion, usually on some
technical topic that cuts across the distribution and usually when the
options haven't cohered enough for any authority to make a useful decision
(often because it's too early for it to be possible to make a final
decision). Those cases, such as the recurring systemd vs. upstart
discussion, are still quite frustrating. But they're also relatively rare
and largely ignorable because they have to be about just the right sort of
issue. Wikipedia has these sorts of arguments
all the time, and
they're much less ignorable, because consensus is invoked for every minor
dispute on any page in the entire project. You
have to participate
in endless consensus process or risk having your work undone, reverted, or
removed.
We would all like all decisions to be made by consensus, since we don't
want anyone in a volunteer project to lose (and because we all love to
convince other people we're right). And for small teams, consensus is
wonderful. But that's precisely because governance in small teams is very
easy; humans are naturally adapted for decision-making in small teams and
have a huge variety of natural tools, tendencies, and abilities devoted to
making those sorts of decisions. You rarely need any formal
decision-making process; most decisions will just happen.
You need a decision-making process when enough people are involved that
mutual social pressure can't bring a dispute to resolution, and when
you're in that situation, consensus is a horrible process.
Due to my past experiences, I'm almost certainly at the extreme in dislike
of consensus processes. Most people are not going to refuse to
participate in communities solely on that basis. But be aware that 40,000
words of discussion about something that an outsider will not consider
particularly important is not an accidental phenomenon. It's not
something that just happens randomly on the Internet. It's an effect, and
symptom, of a governance process, or lack thereof, and it's something that
you can do something about if you want to.
when francesca started her DPL game, I also started
thinking about people I'd like to encourage to stand as a DPL candidate.
unfortunately my initial "short list" contained 18 names, which doesn't fit
the game's rules very well.
after waiting a bit, 9 of them were mentioned by others already, so I can
leave them out here (which also means no public hug,
sorry, please complain to the inventor of the game!). from the remaining 9,
I've now chosen my Fantastic Four (in alphabtic order of first names):
in my opinion, the DPL task is mostly about managing, & those four
people are in my experience all very good at organising projects &
dealing with people, & are therefore well suited for this task.
let's see if they feel motivated to take on the challenge!
(the nomination period has already started,
so don't hestitate!)
Open question to enthusiasts, theoretical computing scientists and
mathematicians of all sorts: is it possible to construct a valid
In fact, I like DPLs who don't like the idea of being a leader 
Playing the 
* Inspired by 
On Friday, I uploaded an initial package for
One of the thing CDBS provides is support for verifying / generating
debian/copyright file. This feature will be help full if new files
show up in newer releases. It can also be helpful to generate the
first version of copyright file. But don't blindly follow this
feature, you need to cross verify the things it generates.
To use this feature add the following line to your debian/rules file
first
It was interesting to read recently from Martin F. Krafft