community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: project supervision
Date Fri, 16 Mar 2012 21:20:49 GMT
On Fri, Mar 16, 2012 at 9:55 AM, Shane Curcuru <> 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:

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.


> In any case, this is a great place to discuss.  And where should we best
> document findings?
> and
> - Shane

View raw message