Hey folks,
I started writing this e-mail in November or so. My normal approach
with stuff like this is wait for a non-contentious quiet period before
starting a new thread, to maximize the chance the words will be read
for what they say rather than interpreted in the context of some
heated debate. Unfortunately, heated debates have been happening here
for a long time, with little break, and though I have something here
that is not hot, it still needs contributing.
So, sorry about the timing, but I'm posting it anyway!!!! Mwuhahah. Hah?
cheers,
Leo
TL;DR [10][12]
==========
There ought to be more gentle, humble, consensus-building
conversations. And, hugging.
TOC
===
* TL;DR
* TOC [11]
* Preface
* Community over policy
* Consensus-building
* Poldermodel
* Community-building
* Focus and feelings
* Lack of a call to action
* References
Preface [0]
===========
[RT] are Random Thoughts. This is a tradition in the Cocoon
community. RTs are basically long and thought-provoking mails with new
project propositions, that are discussed and scrutinized at length.
One distinguishing characteristic about RTs is the complete and utter
lack of consistency with respect to quality: some are pure crap,
others are pure genius. Even the original author of a RT is not sure
which category any given posting falls into at the time it is issued.
This posting is no exception.
Community over policy
=====================
We have this shorthand saying of "community over code": at apache,
while we value code, when given the choice, we value community more.
Of course there is a lot of complexity and nuance that you lose in the
summary, but, once you understand the meaning, the shorthand is
useful.
I would like to add "community over policy": at apache, while we
accept some policy is needed, when given the choice, we value
community more. Note the words "I would like", because I don't think
that's where we are today and I also don't think we have consensus on
it.
A partial corollary would be that the incubator policy documentation
is done not when there is nothing left to add, but when there is
nothing left to take away. I think everyone agrees with that in
principle, but it may not get the focus it deserves in practice.
Unfortunately bureaucracies have the tendency to grow more
bureaucratic over time. Beyond a certain threshold, those
bureaucracies then ever so gently shun away a certain class of people,
then another, until only bureaucrats remain.
Consensus-building
==================
The most important new communication skill to learn for people when
they get into apache-style open source is probably the nitty gritty of
how to build consensus. I've never quite seen how to do that online
written down. It involves something like
* write for a global audience, [2]
* use principled negotiation, and [3]
* speak softly, be humble. [4]
It is quite difficult to lose ambiguity, to remove localized
colloquialisms without sounding too formal, to avoid using hard words
like colloquialism, and still convey the message you want to convey.
This is hard to teach and harder to master.
Once you figure out how to write, you then need to figure out how to
write it concisely. And when you know how to do that, you still need
to figure out the right things to write. That is, you need to actively
restructure your thoughts, plans and ideas to be easy enough (as easy
as possible?) to get consensus on. If you're a rigid thinker (perhaps
because you're a software developer?) the natural form of your
thoughts probably is not the easiest-agreeable form.
Unfortunately most of the messages to general@incubator from people
that have been around apache a while don't use this style at all. I've
seen the prevalence of an authoritative, declarative and
confrontational style increase further and further over the years here
(and elsewhere at apache).
It's unfortunate, but the incubator does not set a good example these
days when it comes to "how to build consensus" [9]. A big part of the
reason for that is that the incubator is solving hard problems, but
another part of the reason is the way that communication happens. It's
especially difficult for me to see this and harder to correct. That's
partly because I learned a lot of how to do this from the same people
I know see dive into confrontation after confrontation, but mostly
because I want to avoid even a hint of censorship.
Poldermodel
===========
As an aside. To provide some missing cultural context. I'm Dutch.
According to Wikipedia [1],
The polder model is a term with uncertain origin that was first
used to describe the internationally acclaimed Dutch version of
consensus policy in economics, specifically in the 1980s and
1990s.[citation needed] However, the term was quickly adopted for
a much wider meaning, for similar cases of consensus
decision-making, which are supposedly typically Dutch. It is
described with phrases like 'a pragmatic recognition of
pluriformity' and 'cooperation despite differences'.
(...)
A third explanation refers to a unique aspect of the Netherlands,
largely consisting of polders, land regained from the sea, which
requires constant pumping and maintenance of the dykes. So ever
since the Middle Ages, when this was started, different societies
living in the same polder were forced to cooperate because
without unanimous agreement on shared responsibility for
maintenance of the dikes and pumping stations, the polders would
have flooded and everyone would have suffered. Crucially, even
when different cities in the same polder were at war, they still
had to cooperate in this respect. This is thought to have taught
the Dutch to set aside differences for a greater purpose.
Here's a grim thought: do consensus-based models arrive only out of
necessity? If so, Apache is in trouble (like The Netherlands) because
it is wealthy in just about every way (like The Netherlands). Perhaps
the necessity will arise again when new people stop coming to apache
and communities arise elsewhere. But that will not happen as long as
apache is as wealthy as it is. So then maybe the best way to save
apache is to manufacture necessity? Perhaps we should build a direct
competitor that is Like Apache, But Sexier(tm)? That's a lot of
work...
[This is a good example of using localized cultural and political
references, and so it's probably a bad idea to include. But then if so
it's a good example of breaking the rules, that aren't rules in the
first place. I'm leaving it in.]
Community-building
==================
The second really important skill to master is building a community.
Aside from using the right form of communication [5], there are many
big and little things for projects to do and focus on. Recently, in
fact on Sunday the 15th, Jukka wrote:
> In the recent years we've spent a lot of time
> focusing on procedural and legal details, while community building and
> social dynamics haven't gotten much attention. Perhaps we should start
> looking at how to build up that aspect of the Incubator, possibly in
> cooperation with ComDev as already mentioned.
>
> Instead of introducing new rules and responsibilities to address this
> issue, I think what we could do is to start collecting things like
> case studies and best practices from podlings that have managed to
> solve commonly seen issues. Or we could form a "community building
> task force" of say a few volunteers who could be called in to help
> podlings that have trouble with this. Or something else; I think
> there's a lot of opportunities for improvement here.
As far as I know, apache doesn't have any of this written down. Some
of it probably could be written down, but a lot of it might be just a
little too intangible or fleeting to work well as something you put on
a website. That's partly why we have a mentoring model: as a way to
help transfer the intangibles into podlings. I always tell people that
they should build a website that's as good as rubyonrails.org and then
come back for the next step. It's a cheap trick: they never come back
:)
Focus & feelings
================
Yay, our project got in! Ok so I have to build consensus. And I
have to build community. And vote. And learn all these acronyms.
And send in this CLA thing. And talk to my boss about my
contract.
And I have to subscribe to a mailing list where people are
arguing in the abstract about other people's projects? And get
conflicting advice about the same thing from these people? And
write balanced/accurate self-reflecting reports describing my
non-existent community? How do I write about things that are not
going too well without sounding like the project is dead? Who
reads this stuff anyway?
If you could pick 3 things that you want a new committer to "get" and
focus on, is "write a reasonable board report" on there? If not, is it
in the top 10?
Or from a mentor perspective...
Yay, our project got in! Ok so I have to help them bring their
development out in the open. And help them navigate the
bureaucracy. Hmm someone is asking me what to tell their boss
about their contract...Help! I don't understand half of this
myself?
Wait, this document says one thing and another document says
another thing...where do I ask? Oh, general@. But this mailing
list is full of angry e-mails (it's even worse than our dev list
lol) I'm not sure I want to dip my toe into that right now. Do I
have to stay subscribed? I guess so. Oh well.
Oh now they're angry at _me_? Sorry guys I meant well....hmm so
maybe I'll just go work on this bug. No. No. I must do the right
thing and help these people. I promised. Hpfff....well I'm
definitely never doing this again...
Does that sound like it could be how some mentors feel? Does that
matter to you? Would you prefer a mentor teaches a new community the
things they understand about doing open development [6], or do you
expect them to (re)learn "the incubator way" and teach _that_? How
high up is "know how to get license files right in binary releases" on
the list of things a mentor should focus on?
Can we make these poor imaginary people feel better? Should we? If so, how?
Well for starters, it's a people thing, and so it's got very little to
do with rules or policies or codes of behavior. It's not necessarily a
community or consensus thing either -- even in a one on one
conversation about an abstract incubator topic that won't ever be
decided one way or the other, it's a people thing. If you're very good
at this stuff you can make people feel good about completely 'losing'
a vote :-)
So remember that other people are people too. You can't really expect
them to do everything at once or always understand what you mean or
avoid making the same mistake twice. Most [7] of the people that are
here are in fact here because they *care*. About their projects, about
their current and future users, about apache looking cool to
newcomers, about the apache brand being an indication of a certain
kind of quality, about apache surviving the next decade without major
lawsuits, about collaborative commons-based peer production, about
following the processes appropriate for a Committee of a 501(c)3
Delaware Foundation. Those other people may care about other things
than you do, but they care.
That means more often than not when those other people write
something, there are feelings expressed in what they write. Perhaps
they took extra care to remove those feelings from the message, but
they are feeling it anyway. Recognize and respect those feelings.
These are all nice people, the good guys, trying to do the right
thing. My favorite skype emoticon is (hug), which shows an animation
of a teddybear giving you a hug. I wish there was an ASCII equivalent.
(hug) (hug) (hug) ;-) <--- please imagine getting hugged by 3
teddybears. Thanks :).
Incubating, mentoring, designing community growth processes...these
are very *soft* things. Many approaches that are often used when
discussing the relative merits of a particular implementation of a
particular algorithm or a software design choice...those aren't so
good approaches when dealing with this soft stuff.
Lack of a call to action
========================
It's pretty common when writing an e-mail here to want to accomplish
something specific. Change this or that rule, vote on this or that
project or release, discuss and decide how to handle some certain
difficult problem.When writing a long e-mail it's a good idea to make
that clear at the end :-)
By contrast, I don't have a concrete call to action here, and I'm
providing no clarity. That makes this a bad [RT], perhaps (I do like
breaking rules). I'm not saying we should scrap half the rules (we
probably shouldn't) or that we should stop discussing hard contentious
topics (we definitely shouldn't).
Instead, I thought I'd start with trying to nudge your thoughts and
your mental state a little bit into a certain direction. Something
about nice, and humble, and gentle, and caring, and teddybears. It's
an experiment, a random thought. Let me know if it worked. If you do
come up with any concrete plans or actions, please put them in a new
thread :)
References [8]
==============
[0] this preface originally by Sam Ruby :). I last used it in, what,
2003? I found it in an old e-mail (full of typos) about creating
Excalibur, which was about salvaging what was left of Avalon, which as
a project is probably still the most spectacular failure at Apache,
and one of the original triggers for creating the incubator. I guess
my thoughts got less and less random after that, or rather I think I
get more and more afraid of publishing the random stuff each year.
[1] http://en.wikipedia.org/wiki/Polder_Model
[2] http://techthinker.com/writing-for-a-global-audience/
[3] http://en.wikipedia.org/wiki/Getting_to_YES
[4] http://changethis.com/manifesto/show/19.SpeakSoftly -- ironically
this is not for a global audience at all, but I've never found a
reasonable guide to humility, so this'll have to do
[5] which is definitely not just about building consensus; you
probably have to be or sound a little revolutionary to attract new
people, and similarly there's nothing that gets attention as easily as
conflict
[6] and doing it "the apache way" I guess
[7] Some people are probably just here because it's part of their job.
That's quite ok, too :-)
[8] http://xkcd.com/285/
[9] instead everybody always writes broad sweeping generalizations
like this. Oh, there's another one. Boy this is hard!
[10] http://en.wikipedia.org/wiki/Wikipedia:Too_long;_didn%27t_read
[11] have you ever noticed how often automatic-TOC-generation in
various software packages includes the TOC header when you really
don't want it to? *Infuriating*! But if you do it yourself, it feels
kind of good. Try it! :-)
[12] I would like to apologize for not renumbering these footnotes.
Also, I would like to apologize for calling these footnotes
'references'. Also, for sentence fragments.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
