----- Original message ----------------------------------------> From: Danny Angus <[EMAIL PROTECTED]> To: Jakarta General List <[EMAIL PROTECTED]> Received: Sat, 27 Dec 2003 22:58:55 +0000 Subject: RE: Indemnification of the PMC
>Seems to me that part of the reason it is difficult to resolve the issues confronting >Jakarta is that several initial assumptions are required, and that these are not >stated or >clearly implied anywhere. >Greg assures us that the board aren't likely to act precipitately (if thats how you >spell it), >and we haven't had "official" communications from The Members of The Board on the >topic, yet there are a lot of hints about the unsuitability of Jakarta's present >organisation. >I think we could do with some concrete direction, or at least an affirmation of our >mandate to continue what we are currently doing. Because to me it is increasingly >feeling like we're trying to fix something which (apart from a few details like the >bylaws) >isn't broken on the basis of speculation and conjecture, and the danger in that is >obvious, we'll end up breaking the thing we're trying to fix, or failing to fix the >parts which >are broken. >And with the utmost respect for Sam hopefully that is something a new Chairman, with >more time and fresh enthusiasm for the role, will be able to provide. Well, first, the idea of "consensus" is at the core of the Apache culture. Consensus means that everyone involved has agreed that a course of action is the best available. It may not be everyone's first choice, but it is a solution everyone can live with. Consensus is not something that is easy to represent in a list of rules and procedures. It's a process of human engineering and difficult to reduce to writing. It would even be harder to reduce to writing for every community. Communities are like all other human relationship. Each one is a little bit difference, and, in human terms, the little differences can mean a lot. Now, with Jakarta, there seems to be a belief that we should be following a deterministic process with definitive procedures. Elsewhere in ASF land, there's a feeling that if you need to call upon a formal procedure (say, by exercising a veto), then consensus has failed. When this happens, many Apaches might feel that the real problem isn't the technical issue underlying the veto, but the consensus issue underlying the *need* to veto. Procedure is a fail-safe. Achieving consensus through discussion is the nominal process. The Apaches on the board don't like to make dictates, since dictates defeat consensus. They are not our bosses as much as they are our colleagues. They want to us to sort this out for ourselves. Because, if we can't sort it out ourselves, then we're not building a community that can endure. Tough love. As for what we are suppose to be doing here, the board has already made two mandates. One in section 6.3 of the bylaws <http://apache.org/foundation/bylaws.html> and another by resolution <http://tinyurl.com/3x6rs>. The PMC is responsible for the active management of the Jakarta codebase. Part of good management is effective oversight <http://tinyurl.com/2eyvg>, which is to say solving little problems before they become big problems. We know oversight is failing because we've had to take some drastic measures over the years. One subproject could not resolve an issue, either through consensus or by following the voting process. As a result, a committer lost his write access. By Apache standards, having to do such a thing is a red-letter scandal. Consensus oversight failed. We've also had to temporarily restrict access to CVS modules because of unresolved IP issues. All the issues were resolvable and should have been resolved *proactively* rather than *reactively*. IP oversight failed. There is no doubt that the Jakarta subprojects are healthy. Every project has its hiccups, and Jakarta is no exception. But, we seem to lack a mechanism that allows issues of consensus and IP to come to to forefront *before* it is too late. The "infrastructure club" is our final fail-save, employed as a last, desperate measure. Denying access to resources is a black-mark that screams "oversight has failed". It's not an "oh well" that we can sweep under the rug and forget about. Other ASF projects have fewer lines of code to worry about, and most, or all, of the committers are on the PMC. If a committer/member has a problem, he or she can bring it up directly on the PMC list, without having to find an intermediary or post a sensitive observation on a public list. IMHO, we need to put aside the maverick guidelines posted at Jakarta and just try to do things the ASF Way. * We need to put *all* the decision-markers on the PMC. At Jakarta, that means *all* the committers, and * We need to insist that all subprojects file regular reports, with some statutory bullets to ensure everyone is still thinking about consensus and oversight. If anyone reading this message agrees, or disagrees, please respond to the "As it ever were" proposal under another thread. Let's see if we can build a consensus and then create and maintain a solution that works. IMHO, the ASF Way *will* work if we let it; we've just never tried to let it. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
