----- Original message ----------------------------------------> From: Stephen McConnell <[EMAIL PROTECTED]> To: Jakarta General List <[EMAIL PROTECTED]> Received: Sat, 27 Dec 2003 06:48:59 +0100 Subject: Re: Indemnification of the PMC
>If I understand correctly, the opinions of an individual are not the >same as a motion passed by the BOD. It is my understanding the BOD has >not passed any resolution that grants a PMC member any of the rights >implied by the message quoted below. In fact, my understanding is that >the role of PMC implies no rights at all - just extra responsibility. >Is there anything concrete to suggest otherwise? The ASF's authority to indemnify individuals stems from Section 12.1 of the ASF bylaws: <http://apache.org/foundation/bylaws.html> This section provides for indemnification of directors, officers, and members, as well as individuals "serving at the request of the corporation ...". The theory is that the PMC Committee members fall under the latter clause. Since, the corporate resolution only installs the PMC (the argument goes), plain-vanilla committers don't fall under section 12.3, since they don't serve at the "request of the corporation". Though, section 12.1 does not specify PMC members as such, and so there's some wriggle room there. From a legal standpoint, the safest thing is to be an ASF Member *and* serve on the relevant PMC. (Something more of us ASF Members need to do this year is nominate more Jakarta-bred committers to the ASF.) For those of you with access to the ASF Members list, there's a good post by Roy dated 12-Mar-2003 that sums up the indemnification issues as well as the issues surrounding the role of the PMC. According to the ASF Bylaws and the Jakarta resolution, <http://tinyurl.com/3x6rs> being on the PMC doesn't grant "additional responsibility", it grants *all* the responsibility. While, in practice, the lowly Jakarta committers now handle the active, day-to-day management of the codebase, it is not their "responsibility" to do so. Personally, I think that this perception that being on the PMC means more work than being a committer is a nonsense. Elsewhere, most or all of the committers are PMC members. Elsewhere, committers who are not a PMC members are the exception rather than the rule. The reason being on the PMC here may seem like more work, is because we are *making* it more work than it should be. Within Jakarta, we've gotten the fallacious idea that the PMC is a steering committee that sets the "strategic direction" for the project. This idea is not based on the ASF bylaws or the Jakarta resolution. The guidelines altered the role of the PMC years ago, either as a misunderstanding or as an experiment. The bylaws specifically say that the chairman "shall establish rules and procedures for the day to day management", which is what our committee spends a lot of time trying to do. As for what the PMC is supposed to be doing, the bylaws state that "Each Project Management Committee shall be responsible for the active management of one or more projects". Within Jakarta, we've trying to fill the chairman role with a committee and let the committers take responsibility for the active management of our codebase. (Recently subject to the PMC's rubber stamp.) IMHO, this is why there seems to be a fundamental disconnect between Jakarta and the rest of the ASF. We've reduced the chair to a "notetaker", given the PMC the chair's responsibilities, and given the committers the PMC's responsibilities. Jakarta folks and the ASF board folks on not on the same page, and we talk past each other. Here's how Roy Feilding styles the roles: ---- project = "something the ASF wants to accomplish", management = "making decisions for progress toward a goal", and committee = "the people voting on decisions" ---- Roy also stated that: "The PMC must equal the voters on a given project, or the entire theory of delegated authority, responsibility, and oversight upon which the ASF depends for legal defense of its contributors [is defeated]". The PMCs were based on the Apache Core Group. The PMC is *not* suppose to be some "other-worldly land where benevolent beings ponder deep issues and create solutions". The PMC is them that make the real, day-to-day decisions that foster the project's community and create and maintain the project's codebase. At Jakarta, that would be the committers -- ALL the committers. It's possible we might also want to create some type of executive steering committee within Jakarta that could do the sort of stuff the current PMC seems to want to do. But, we cannot usurp the PMC constituted by the ASF for some other role. We must make the PMC what the PMC is intended to be: The committers who make the day-to-day decisions. If we did want to get back to basics, we should start by going back to the HTTPD guidelines, <http://httpd.apache.org/dev/guidelines.html> and make the minimum number of changes needed to update them for Jakarta. (Yes, I'm volunteering.) The core idea of the ASF is that * HTTPD came up with a system that *worked*, and the foundation encourages its use on other projects. Our subprojects work because its *the HTTPD guidelines* we follow in practice. The set of subproject committers have acted like a subproject PMC, which has enabled us to build strong communities and useful, innovative products. When things have gone wrong, they have gone wrong because the subprojects don't have a clear channel of communication with experienced members working on other subprojects. IMHO, we need to do is what is being proposed on another thread: * Let subprojects know we expect them to file regular reports with the PMC, which include bullets for oversight, and * Make all the committers PMC members, since, from an ASF perspective, our committers are the PMC. In this way, all the committers would be "indemnified" -- at least to whatever extent the ASF can afford to indemnify anyone :) A related topic is the use of author tags. Here's a post Greg Stein made to the community at apache.org list: <http://tinyurl.com/yrlhu> -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
