community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: project supervision
Date Fri, 16 Mar 2012 21:20:49 GMT
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 and
> best practices for how Apache projects are expected to work.  But for 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 guideline
> 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.  We 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.  That means being careful to limit the specific rules we
> 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 world.
>  But even here I sometimes find it hard when other participants think 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 the
> exact same problem you're trying to explain the best practices for.  There
> are a lot of community members who want to learn from all of our experiences
> 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.  And where should we best
> document findings?
>
> http://www.apache.org/dev/
> and
> http://community.apache.org/committers/index.html
>
> - Shane
>

Mime
View raw message