On Fri, Mar 16, 2012 at 9:55 AM, Shane Curcuru <a...@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 >
