Thankyou. Read with great interest, and it put a few things into perspective. Particularly the fact that to me the Practice PMCs made no sense from my perspective (based in the XML project's world). I think I now understand why.
Couple of things came to mind whilst I was ruminating on the contents.
Firstly - am not so sure that changing the name of PMC to Core Group is either necessary or sufficient to fix things. I note that you mention the codification of the requirements placed on the Core Group into a universal Apache Guidelines document. For this I am absolutely +1 - one of the biggest problems facing the PMCs is a lack of clear understanding of what is required. The only way to overcome that problem is to clearly document requirements. E-mails going over the issues every 6-12 months 'aint going to cut it. I suspect if there was a clear set of guidelines and a board that was brutal about enforcing them then things might change.
Secondly, given the original intent of the concept of a PMC, I am curious as to why the board permitted umbrella PMCs such as XML and Jakarta. You can change the name of PMC to Core Group, and put strict guidelines in place, but the spirit what you want is not going to happen until everyone on a given PMC is on the -dev lists that the PMC is responsible for. That sounds fair, but is impractical for the PMCs of the large, divided projects.
So a possible suggestion. FWIW. Maybe a step towards where things need to be? (Evolution rather than revolution?)
Can we turn a project such as XML into a federation of projects rather than one big project? In terms of infrastructure (web site, mailing lists, cvs etc.) leave it as it is, with maybe a bunch of volunteers from each member project helping out with those items.
Each sub-project gets turned into a formal TLP, but not in the sense that is implied today (where TLP = web site, = mailing lists etc.). Rather the TLPs simply report to the board, have their own PMCs and are responsible for the code decisions. That puts the decision making requirements back where I think the board wants it to be. With a small core group of individuals responsible for each particular code base.
It also helps the Foundation scale as it reduces the requirements placed on infrastructure@ (new web sites etc.)
As I said - FWIW.
Cheers,
BerinRoy T. Fielding wrote:
[Moved from the PMC list -- folks have got to stop proposing such things on the wrong list.]
A long time ago, the name PMC was created in an attempt to genericize the way that the Apache Group operated, using terminology that would be easily understood by a judge or IRS inspector. Unfortunately, the name seems to have overwhelmed its history. I described that in a message to the members on March 12, 2003, which I'll include below. However, I've been so overwhelmed with issues/fires this past year that I never got around to fixing it.
Geir has proposed that we create practice PMCs (a.k.a. subprojects) as part of incubation, and that we call them "Project Committers" lists rather than PMCs. I am +1 on the notion in general, but I would prefer to call them core groups instead. My rationale is that "committer" privilege is a mechanism that we frequently give to people on the basis of what they are planning to do, whereas the core group are those people who have earned long-term voting rights whether or not they happen to code. Jakarta got into a weird state wherein committer == voter and commit-access was given out like candy, thus leading to the notion that committers run ASF projects. I don't believe it is appropriate to link voting with cvs access.
The key thing to note is that voting is a decision-making process and we want that decision to be an ASF decision. Furthermore, we want the decision to be made as close to the volunteers doing the work as possible, preferably by the volunteers themselves, whatever that work may be.
The ability to make ASF decisions starts with the board and is delegated to officers and their associated committees. Anyone casting binding votes (meaning votes that are counted toward making a decision) must be listed as a member of the committee on which they are voting, even if their votes are limited to a subcommittee. Therefore, my preference is for a fluid structure of incubating subprojects wherein every voter is listed as being in one or more core groups and the entire set of voters is listed as the incubator pmc.
I am aware that this would mean incubating projects would be able to vote themselves out of incubation. I think that if such a project had their shit together to the extent that they could run such a vote and get it past the majority of incubator members, then they no longer need to be incubated.
....Roy
=============== From: "Roy T. Fielding" <[EMAIL PROTECTED]> Date: Wed Mar 12, 2003 9:46:04 PM America/Los_Angeles To: members at apache.org Subject: PMCs gone wild
I am getting a bit frustrated at what appears to be a serious attitude problem within the Apache projects. A lot of people seem to wait around until "the man" makes a decision, sometimes doing nothing other than gripe about the lack of concern that "the man" has for their pet issue, or simply believing that they are not allowed to do anything until "the man" says it's okay to start. I am not just talking about the newer Jakarta projects: this attitude has become endemic throughout the ASF, and folks are far-too-frequently suggesting that decisions should be relegated to "subprojects" or that projects should be "managed" by only a subset of the voters.
"the man" is usually their perception of a PMC as some other-worldly land where benevolent beings ponder deep issues and create solutions. [Sometimes "the man" is the ASF board, but that is very rare -- most people have the sense to realize that the board's solution to a squeeky wheel is to yank it off, throw it away, and install a new wheel -- which usually isn't the effect desired by most wheels.]
I think I know what is causing this attitude, and sadly it points back to one of the decisions I thought was a good idea when we were crafting the ASF bylaws. You have to understand some background on that first...
The ASF bylaws were crafted by Drew Wright using a Delaware nonprofit template and a ton of input from more than a year of discussion amongst the Apache Group (circa 1998), discussion at the post-ApacheCon'98 group meeting, and yet more discussion on the old apache-core mailing list. Our goal was to create a legitimate corporate infrastructure around Apache without changing how Apache decisions were made or the volunteer nature of the foundation. By legitimate, I mean something that would be defensible in a court of law if some asswipe were to sue the foundation for something we did as a group.
The concept of a Project Management Committee was created in the bylaws to be analogous to the Apache httpd core. A PMC is the legally sanctioned body authorized by the Board of Directors to do things (e.g., approve changes, release code, etc.) on behalf of the ASF for a given project. Why? Because it means that when the PMC votes to do something, they are "doing" on behalf of the ASF instead of themselves, and hence any repercussions from what was done must be addressed to the ASF as a corporation rather than to just the people as individuals.
[Note that it is still possible to get sued as an individual -- it simply isn't possible to selectively sue that person for something decided by the ASF, and any competent judge will immediately dismiss a defendant from a joint suit if their actions were directed by the corporation by way of its bylaws (the PMC). This is separate from indemnification, which I'll try to explain below.]
For those of you who aren't aware of US corporate law, there are only a few legitimate ways for a corporation to delegate authority:
o Board -- by default, the board of directors has authority over and responsibility for all corporate decisions and assets;
o Officers -- the board can delegate some authority to an individual named as an officer of the corporation, provided that responsibility is maintained through active oversight of their activities with communication back to the board;
o Committees -- an officer can call on other individuals to compose a group that, upon approval by the board, is tasked with authority and responsibility for that scope, in which case the officer's responsibility is reduced to maintaining oversight of the decision-making process itself and providing feedback from the committee to the board;
o Contracted employees -- an officer can make a contract between the corporation and some person or corporation for the purpose of doing some action on behalf of the corporation; this does not delegate authority or responsibility, and the officer must maintain active oversight of the contract. Employees of a corporation are typically hired by the President/COO under the terms of an employment contract, though really big corporations will delegate that further to division officers (V.P.'s).
We don't have employees, so the latter option is right out. We don't contract very often because it is an expensive process and we simply do not have the money to cover it. We can't make everyone an officer because the board cannot maintain direct oversight over everyone and the law does not recognize as legitimate any corporate structure for which the line of oversight cannot be reasonably maintained.
So, we are left with committees, which is pretty much exactly how Apache httpd was operating at the time, and Drew did an excellent job capturing that in appropriate legalese that could be easily understood by any future lawyer (e.g., a civil or IRS judge) that might have a reason to inspect our bylaws. Hence, PMC.
Unfortunately, the name is filled with historical legacy that leads to a natural prejudice: Project [my boss gives me those things] Management [people who tell me what to do] Committee [people who sit around discussing things]. Yikes! It doesn't seem to matter how many times I tell people that
project = "something the ASF wants to accomplish", management = "making decisions for progress toward a goal", and committee = "the people voting on decisions"
it still comes back as "the PMC" is some other group outside the development mailing list that makes all "real" decisions on behalf of the project. Bullocks! That is absolute, unadulterated CRAP!
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 becomes just a load of horseshit that any greedy lawyer can and will bypass on their way to our personal assets.
I am tired of dealing with people's prejudices. I hereby request that the ASF bylaws be changed to replace PMC with Core Group, that it further explicitly state that members of the core are the only people allowed to vote on actions by a project, and that all external actions by a project (such as a software release) must be publicly approved by vote of the core according to a single Apache Guidelines document that shall be the bylaws for all projects within the ASF. Each project shall maintain a primary public dev list, cvs module, and cvs commit list within which all project votes will take place and be recorded, aside from those discussions that are legally or ethically required to be private. A single private mailing list per project, called [EMAIL PROTECTED] or [EMAIL PROTECTED], shall replace the pmc@ lists and may include any persons deemed necessary by the project core.
Does anyone object? I will make the appropriate diffs to the bylaws once it is clear that this is a direction worth pursuing. We have a members vote due sometime soon, so we may as well get started.
If infrastructure doesn't want a hostname per project (meaning code base), then please eliminate all such hostnames. We can and should have all projects start at www.apache.org and @apache.org for static content and lists, and only use cvs, jakarta, tcl, and perl for dynamic content requiring a special set-up.
....Roy
p.s. Indemnification is a promise by the corporation to pay the legal expenses of an *individual* if that *individual* becomes subject to criminal or civil proceedings as a result of their actions under a role identified by the corporation, as long as such person acted in good faith and in a manner that such person reasonably believed to be in, or not be opposed to, the best interests of the corporation. In other words, a member is only indemnified for their actions as a member (not much). A director or officer is only indemnified for their actions as a director or within the scope of their mandate as an officer. A PMC member is indemnified under the category of "who is or was serving at the request of the corporation as an officer or director of another corporation, partnership, joint venture, trust or other enterprise" and only to the extent of that enterprise (the project). A committer who is not a PMC member is not authorized by the corporation to make decisions, and hence cannot act on behalf of the corporation, and thus is not indemnified by the corporation for those actions regardless of their status as a member, director, or officer.
Likewise, we should all realize and understand that the ASF's ability to indemnify an individual is strictly limited to the assets held by the ASF. Beyond that, we are on our own as far as personal liability.
It is a far better defense that an outside entity cannot successfully sue an individual for damages due to a decision made by a PMC, so it is in everyone's best interests that all of the people voting on an issue be officially named as members of the PMC (or whatever entity is so defined by the bylaws).
===============
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
