All, over on the [EMAIL PROTECTED], Avalon is used as an example in the reorg discussions. Sam Ruby said something for us all to think about...see below. Also a related snippet from an e-mail by Rod Waldhoff.
cheers, Leo (just trying to provide some useful digest for people who have no time to shift through 100 messages/day ;) -----Forwarded Message----- From: Sam Ruby <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Incubator, Jakarta, and new projects Date: 23 Oct 2002 06:35:23 -0400 Stephen McConnell wrote: > > Coming back to the Jakarta PMC as a concrete example, Avalon as a > community within Jakarta, and myself as a committer within that > community, I do see a need for greater "structure" between the PMC and > the communities it manages. By structure I mean things like > responsibilities and obligation of a community towards its PMC - a > project reporting once a quarter - is an example. Project reporting can > be view by communities as a mechanism to promote their own activities, > flag potential need for support (e.g. there are a couple of threads > running in Apache concerning "full or short licenses"), the ability to > escalate hot topics (usable by a PMC in risk identification and > evaluation - and the promotion of PMC success stories up to the board), > through to things like simple position statements from the community. > > However - consolidating the opinions of a community requires something > that does not currently exist with PMC communities - structure and > framework. Today there isn't a structure or framework within which the > Avalon community could actually reach agreement on something like an end > of quarter report without some sort of mediation. That needs to come > from the community itself - a community electing a PMC Liaison (please > note that I am not assuming that this is a PMC member - more explicitly > I think it should not be a PMC member) - a PMC Liaison would be charged > with the responsibility of making the PMC work for the community and > potentially facilitating communication of PMC decisions and position on > matters pertinent to the community back into the community. > > Finally, there is the question of problem management. In Avalon (at > least in the 9 months that I've been a committer), I've witnessed > occasions when we haven't been able to reach agreements on things. > Situations where there are disputes on the legality of -1s is a good > example. In this situations (where I have had a direct and personal > involvement), the only resource open to me was to bring the issue to > attention of the PMC - however - the reality of that situation was that > I was very strongly advised not to escalate something up to the PMC - > sort of something like " don't do that whatever you do!". A couple of > things have happened since then that have changed my opinion and > relationship I envisage between a community and its PMC. Firstly this > list - I have learnt more from this list in the last couple of weeks > about the process and the people than all of the bits and pieces I've > been picking up slowly as a commiter. Secondly, I have witnessed the > result, and continue to observe the result of unresolved disputes over > on the Avalon project. What this brings me to is the opinion that > communities need to able to put in place their own management structures > - a committee that handles things like establishing and maintaining > scope and direction, internal policing, support back towards their > members - but most importantly, a structure in which -1s are not > allowed, majority decision rule, and the community elects is > representatives. Based on the discussion in this list, is appears that it would behoove the Avalon community to begin to form a PMC like structure (I say "PMC like" as there seems to be open naming issues at this point). Once formed, this group can work with the board and/or Jakarta to figure out what the right division of labor should be. One part of that discussion will be how to recognize internal structure of avalon itself, an example being: Apache Jakarta Avalon Excalibur Merlin. One thing I will say is that I do not envision that there will ever be a tolerance within the ASF for a place where "-1s are not allowed". If there comes to pass a point where irreconcilable differences are encountered, then the right thing to do is to fork the project. If there is a desire to retain the name of the original project, then the name goes with the majority of the committers. - Sam Ruby -----Forwarded Message----- From: Rod Waldhoff <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: community (was Re: 2 tier vs 3 tier [was Re: Incubator, Jakarta, and new projects]) Date: 23 Oct 2002 13:01:40 -0500 <snipping explanation of the uniqueness and value of the communities around ASF projects and how to preserve them/> Recently, I think I've seen some consensus forming around the following ideas (or at least I'd like to think it is consensus): A) It may be time to convert some things currently categorized as "sub-projects" into true ASF projects, peers to what was once their containing project. This would/should be driven by those sub-project communities themselves, although the discussion here on the reorg list and elsewhere may help them to understand that such a proposal would be welcome or at least considered, and the role of that step in a larger, flatter ASF vision. B) We should apply more formal structure, recognition and accountability to "sub-project" management. Perhaps this means a more formal "SPMC" role, overseeing (and legally accountable for?) a given sub-project, but still under the umbrella of a top-level PMC? This seems like a convenient stepping stone for having fewer sub-projects and more top-level projects, but without simply tossing out the current containers (and formal recognition of their communities) altogether. In my opinion, these steps would be valuable in and of themselves, would begin to address many of the concerns expressed here from a number of perspectives, and lays a solid foundation for evolutionary change. -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
