[RT] Community over policy, and similar thoughts

[Leo Simons <ma...@leosimons.com>]

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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [RT] Community over policy, and similar thoughts

[Sam Ruby <ru...@intertwingly.net>]

On Mon, Jan 16, 2012 at 11:58 AM, Benson Margulies
<bi...@gmail.com> wrote:
> Don,
>
> I think that place where you, Leo, and Sam meet up is in the
> identification and clarification of *minimal* legal and procedural
> requirements.
>
> Sam's repeated over and over that he is, in effect, trying to
> establish the minimal level of oversight and supervision of podlings
> (and that the question of what to do about aged or problematic
> podlings is a subsequent community discussion topic). There's been an
> attempt to clarify the minimal requirements for podling releases. And
> my sad attempt to focus a thread was to clarify minimal requirements
> for graduation.

I agree with this, but I would like to reduce it a bit further:

    We all need to talk more.

Yes, talk is frustrating at times, but it is necessary.

I think that we have also identified a structural problem.  The
incubator PMC consists of the set of mentors.  Each mentor is focusing
on their own set of podlings.  I don't see any operational evidence
that anybody here reviews podling reports critically (identifying
issues, tracking them to closure) before forwarding such to the board.

We may also have semantic gaps.  Leo's [RT] may be presuming that a
podling's "board report"[sic] is merely a bureaucratic requirement.
First, I believe that the purpose of reports is to foster
communication.  Furthermore, while the board requires the Incubator
PMC to provide a report, forwarding on podling reports along with a
brief preamble is the way the Incubator PMC has chosen (to date) to
meet that requirement.  While appreciated, there is no board
requirement to forward on podling reports.

Despite the structural problem and semantic gap, we've made progress.
I've learned more about Kato's status in this messy discussion than I
ever did by reviewing the reports provided.  Based on what I have
heard, I do believe that dormant is a good term for the project.
Robert appears to want to identify that some sort of external agent is
responsible for that status.  I actually disagree with this in
principle, but am unlikely to pursue that if we can come to some sort
of consensus on a label for the status.

In any case, I hope somebody beats me to a thorough review of next
month's podling reports, but if not, I intend to repeat the the
process where I provide feedback here before providing feedback that
will ultimately be published on the ASF web site as a part of the ASF
board meetings.

- Sam Ruby

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [RT] Community over policy, and similar thoughts

[Benson Margulies <bi...@gmail.com>]

Don,

I think that place where you, Leo, and Sam meet up is in the
identification and clarification of *minimal* legal and procedural
requirements.

Sam's repeated over and over that he is, in effect, trying to
establish the minimal level of oversight and supervision of podlings
(and that the question of what to do about aged or problematic
podlings is a subsequent community discussion topic). There's been an
attempt to clarify the minimal requirements for podling releases. And
my sad attempt to focus a thread was to clarify minimal requirements
for graduation.

--benson

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [RT] Community over policy, and similar thoughts

[Donald Whytock <dw...@gmail.com>]

Fair enough.  I used to run into this in high school, where something
that had been done the year before a freshman came in was suddenly a
tradition that had to be done every year.  You could probably compare
it to Terry Pratchett's senior mayfly ("It's way too bright around
here now.  Not like it was in the good ol' hours.").[1]

There still needs to be something one can bootstrap a community with.
Oral tradition is a wonderful thing, "make it up as you go" is very
liberating, but some people work really really well with checklists
and flowcharts.  Something somewhere should say, "If you don't do
anything else, you at least have to do this."  Perhaps break it down
into "must", "should", and "worked before".

Don

[1] http://en.wikipedia.org/wiki/Reaper_Man

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [RT] Community over policy, and similar thoughts

[Leo Simons <ma...@leosimons.com>]

Hey Don,

Thanks for your reply. You are quite right, of course. I hope I am
also right at the same time :-). Maybe I can clarify...

On Mon, Jan 16, 2012 at 4:48 PM, Donald Whytock <dw...@gmail.com> wrote:
> Like Apache, But Sexier...LABS?  I can totally see that.  Anyone want
> to start an Apache LABS podling?

I am assuming you know but I will nevertheless redundantly point out
for those that don't that there is actually a http://labs.apache.org/
. It is pretty cool and has a relatively sexy web site :)

> But while community can be flexible in a lot of ways, policy generally
> can't be.  The rules are there; exceptions can be made, but in terms
> of law it's generally safer to assume they won't be.  So, as much as I
> hate to say it, I don't think "community over policy" can actually
> work.

Indeed, some of the rules apache has are rules that it has to have
because of the law. Some others come from its tax status -- apache
could ignore those rules, but then it would lose a financially
beneficial tax status. Others rules apache has written down in its
bylaws [1], and the apache members could jump through a bunch of hoops
to change some of those.

But, then, a lot of the rules that apache has are there because apache
wants to have them.

I will write you out an example.

Once upon a time the incubator had said that incubating projects
should not do binary releases, for a couple of reasons:
* to avoid users downloading incubating software: apache was concerned
that end users would not understand the tentative status of incubating
projects;
* to give projects yet another incentive to do their incubation
process quickly: incubation should be as short as possible. Back then
I think we thought 3-6 months would be the norm;
* legal umbrella: apache the Foundation appoints Officers who have
Committees who make Decisions on behalf of the Foundation. Releasing
software is such a Decision and it's reserved for PMCs. Podlings don't
have PMCs so who should release?

But then along came a project that really wanted to release early,
release often, and also do binary releases [2]. Their mentor had
actually encouraged this since he believed "release early, release
often" is good engineering and community-building practice. So what to
do?

Well, the issue was discussed, at some length, and it was decided that
perhaps we could have releases if we added a disclaimer, and that the
incubator PMC would vote and assume responsibility for the release.
The project added the disclaimer to its website and made its release.
Everything seemed fine, so someone turned those words into a template
[3] and stuck them on the policy website along with a description of
how to do a release. That was in September 2003 [4], and it's been
policy since [5].

If for some reason you find these disclaimers really really horrible,
you can go back into the commit history for the policy docs, and then
into the e-mail archives to figure out why the policy says what it
says, think about it some more, and perhaps come up with a better
idea. Then that idea can be discussed and the policy can be changed,
by the community :-)

I personally think this is *fascinating* history. I'm weird like that.

Unfortunately in 2012 those words from 2003 seem to have significantly
gained in weight. A lot of projects have followed the rule without
complaining, so why should you? This is not just some words some guy
wrote, it's a community decision with a rule on a pretty website (not
on a rebel CSS-less wiki with an "edit this page" invitation), and it
has the word policy slapped on top of it.

These days we probably have mentors that had never thought about open
source communities, when the incubator had those rules already on the
website. They've seen that rule, and they hand the rule to their
podlings, who then follow the rule. The feeling is very different and
the dynamic is different: it has changed from "hmm, how should we
tackle this" into "do what the rules say". This isn't bad per se (it's
a good rule, probably), but I believe we do need to spend effort to
compensate for the lack of positive feeling.

Hence, community over (but not against) policy!


cheerio,


Leo

[1] http://www.apache.org/foundation/bylaws.html
[2] http://mail-archives.apache.org/mod_mbox/incubator-general/200309.mbox/%3C4C2F1577F2EF2840A9AE9EC61860C8810A0FDC@usseex01.amer.bea.com%3E
[3] I tried to find the first version of the wiki page, but that was
hosted on a machine owned by sun and inside a sun data centre, and we
didn't migrate all the history (sort of in violation of apache
infrastructure rules even then, but hey, projects really really wanted
wikis and there was no apache hosted wiki...oh man, those dare-devil
incubator rebels, breaking the rules!)
[4] http://mail-archives.apache.org/mod_mbox/incubator-general/200310.mbox/%3C4C2F1577F2EF2840A9AE9EC61860C8810A1008@usseex01.amer.bea.com%3E
[5] http://incubator.apache.org/guides/branding.html

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [RT] Community over policy, and similar thoughts

[Donald Whytock <dw...@gmail.com>]

Like Apache, But Sexier...LABS?  I can totally see that.  Anyone want
to start an Apache LABS podling?

I'm speaking as someone who lurks on a few prodling lists, plus the
incubator.  There's stuff I've picked up sort of by osmosis (absorbing
through membranes and the skin, rather like how one learns in a
college class by falling asleep on one's book), stuff I assume from
what I perceive as the nature of the beast, and stuff I may well be
dead wrong about.

I like what you've said about community.  I appreciate the idea of
community over policy, community over bureaucracy, people over rules.

Having said that...My understanding is that Apache is a legal entity.
It has a registered life and purpose.  It has assets, both tangible
and non-tangible.  It receives assets and distributes assets.  And it
does this, in cooperation with governments and financial institutions,
by following specific rules.  Rules that have to be followed so that
various other legal entities, not limited to governments and financial
institutions, don't take the assets away from it.

I'm not sure, but I believe accepting contributions from people incurs
certain rules in and of itself, along the lines of, "We will use the
assets you transfer to us in such-and-such a way.  You can trust us
when we say that."  I assume that to use assets for something other
than what one says when one asks for them constitutes
misrepresentation and can lead to civil incivility.

Because of this, Apache has a duty to require that these rules be
followed by people that Apache invites to participate in activities
voluntarily.  On the one hand, there are Ts that have to be crossed
and Is that require a pixel or two over them.  On the other hand, if
people don't want to participate, for whatever reason (duty, fun, ego,
a drive to participate in something bigger than oneself), they're not
going to.

It has to be hard to deal with both of these things at the same time.
I think I've seen "The Apache Way" used to describe both rule
adherence and social curling[1], though not typically in the same
sentence.

Depending on the person, one or the other may make more sense.  Some
people may be more bureaucractically sensitive, others may be more
community savvy.  Both people will, in response to a "What do I do
now?" query, present their answers as they see them.  These answers
may seem contradictory, but nevertheless represent answers that need
to be taken together.

But while community can be flexible in a lot of ways, policy generally
can't be.  The rules are there; exceptions can be made, but in terms
of law it's generally safer to assume they won't be.  So, as much as I
hate to say it, I don't think "community over policy" can actually
work.  "Community within policy", or "community in the context of
policy", perhaps.  But the policy kindasorta has to be there.  It has
to be visible, and it has to be explained.  And in some cases someone
might actually have to explain what a T is, and how it can be crossed.

I look forward to being proven wrong.

Don

[1] http://en.wikipedia.org/wiki/Curling

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org