community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shane Curcuru <>
Subject Re: project supervision
Date Fri, 16 Mar 2012 13:55:43 GMT
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.

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.

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

- Shane

View raw message