Mailing-List: contact dev-help@community.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@community.apache.org
MIME-Version: 1.0
In-Reply-To: <4F63465F.2020007@shanecurcuru.org>
References: 
 <CALhtWkfBqd4ynj6xERmpBpMv-8E_5=t2yC0povb73yS6_+XBdw@mail.gmail.com>
	<4F63465F.2020007@shanecurcuru.org>
Date: Fri, 16 Mar 2012 17:20:49 -0400
Message-ID: 
 <CAP-ksohLOMj8T_opdXR2_HBPbBEMQ2B063assVBKpmHSqy2vpQ@mail.gmail.com>
Subject: Re: project supervision
From: Rob Weir <robweir@apache.org>
To: dev@community.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 16, 2012 at 9:55 AM, Shane Curcuru <asf@shanecurcuru.org> wrote=
:
> On 2012-02-29 8:14 AM, Benson Margulies wrote:
> ...
>
>> This leads me to wonder about supervision in the Foundation. PMC
>> members are responsible for supervision of their project. However, I
>> submit that there are some limitations to this. The PMC is the
>> community. If the community get peculiar, the PMC is as likely as not
>> to be part and parcel of the overall drift. Pick your metaphor: the
>> boiled frog, the Stockholm Syndrome, whatever.
>>
>> The board is responsible for supervising the projects, but I felt that
>> it would be kinder and more productive to try to start a conversation
>> here about if or how the Foundation could improve project supervision
>> and see if it resulted in a coherent proposal to the board, rather
>> than start another noisy thread on the board list.
>
> ...
>
> Excellent question - although also a rather broad question. Fundamentally=
,
> isn't one way to look at it: What are the rules, guidelines, and best
> practices of running an Apache project?
>
> I've always thought it was a good idea to better document - meaning both
> more documentation, as well as better written documentation - the rules a=
nd
> best practices for how Apache projects are expected to work. =C2=A0But fo=
r me, a
> key barrier is the inevitable discussion - then argument - then flamewar =
-
> that often appears when either you: 1) attempt to document something that
> others think is Wrong, or 2) attempt to write down a rule or even guideli=
ne
> or even suggestion that others think is Telling People What To Do.
>
> I've learned in the past couple of years that we do need to be careful in
> laying out any rules - i.e. requirements - for Apache projects. =C2=A0We =
really
> do need to give the maximum freedom to our project communities that still
> allows for sufficient oversight and functioning of all our project
> communities. =C2=A0That means being careful to limit the specific rules w=
e
> require of our projects.
>

If you set rules, then you are tempted to enforce them.  Very messy.
So don't set rules.  That problem goes away.

Instead think of it like pattern language, ala Christopher Alexander:

http://en.wikipedia.org/wiki/Pattern_language

Document guidelines/best practices in terms of observations of what
works well (or doesn't work well) in a given context.  A recipe book
of sorts.

> That said, I think there are a LOT of best practices (guidelines, even
> SHOULDs along with the MAYs) that we could do a far, far better job of
> documenting and explaining to our projects, our communities, and the worl=
d.
> =C2=A0But even here I sometimes find it hard when other participants thin=
k I'm
> Wrong, and their way is the only One True Way.
>
> But even for every example of someone complaining, there are a handful of
> examples of other projects who you suddenly realize are trying to solve t=
he
> exact same problem you're trying to explain the best practices for. =C2=
=A0There
> are a lot of community members who want to learn from all of our experien=
ces
> with long-lived projects, and plenty of examples of different Apache
> projects reinventing the same suggested wheels over and over again.
>

Design patterns, organized into pattern languages, encode these kinds
of observations into a structured form.

No silver bullet, of course, but it does give a way to structure the
problem, and sometimes that helps.

-Rob

> In any case, this is a great place to discuss. =C2=A0And where should we =
best
> document findings?
>
> http://www.apache.org/dev/
> and
> http://community.apache.org/committers/index.html
>
> - Shane
>