You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by "Roy T. Fielding" <fi...@apache.org> on 2003/11/22 18:15:15 UTC
Add 'practice' PMC structure to projects in incubation
[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" <fi...@apache.org>
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 private@project.apache.org
or project-private@apache.org, 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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Add 'practice' PMC structure to projects in incubation
Posted by Leo Simons <le...@apache.org>.
Noel made an interesting suggestion on the PMC list:
---
Alternatively, the PPMC could consist of the Incubator PMC, the destination
PMC (in cases where there is one), and project Committers. In that case,
there is a single streamlined process, without additional interconnects.
This does have the advantage of providing PMC education to committers who
will someday have to form a PMC. And it preserves the direct legal
oversight of the PMC.
--- Noel
---
I think this is real nice. Streamlined!
We'll have to make clear to everyone that the final authority
(legally, the only authority) always remains the Incubator PMC,
but I see no problem with allowing the Incubator PMC to reach
decisions on a mailing list other than pmc@incubator, if it so
pleases.
cheers!
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Add 'practice' PMC structure to projects in incubation
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sam Ruby wrote:
> Roy T. Fielding wrote:
...
>> 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.
...
> P.S. Can somebody explain to me why a number of core members of the
> HTTPD community feel so threatened by the non-HTTPD PMCS (generally
> lumped into the generic category of "Jakarta") that they feel the need
> to bash it at every opporunity? It gets tiresome.
I don't see the bashing you are talking about in these comments, but I
tool sometimes feel some diffidence from either side, which is normal
given the lack of discussion about these issues between the communities
in these years.
Some very interesting, balanced and fruitful discussion is going on here
between members of projects all over Apache. Finally we are all
discussing on these things and getting somewhere, and I'm positive that
things will soon change. :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Add 'practice' PMC structure to projects in incubation
Posted by Sam Ruby <ru...@apache.org>.
Roy T. Fielding wrote:
> 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.
I know of a case where an individual identified a code base that he
avowed that he would never contribute to but active sought voting
privileges to that codebase so that he could block items that he felt
was harmful. To me, requiring people to actually participate in the
solution to problems that they identify is a good check and balance.
I also can't imagine a more profound way of voting on the direction that
a project can take than by actually doing the work. In fact, that is
the essense of what at Apache appeals to me: whenever possible the
responsibility for any given item is pushed down to the people who
actually are doing the work.
Teasing apart these two concepts is difficult. Let's face it: any
formal system that we try to apply to the real world is going to have
anomolies. Officers who aren't members. Members who contribute in ways
other than code.
I for one, would rather we not focus on the exceptions, and try to make
things more uniform - even if that ends up with giving people who have
the right to vote the right to commit. After all, if we trust them
enough to vote, we should trust them enough to NOT commit changes that
they are not qualified to make.
- Sam Ruby
P.S. Can somebody explain to me why a number of core members of the
HTTPD community feel so threatened by the non-HTTPD PMCS (generally
lumped into the generic category of "Jakarta") that they feel the need
to bash it at every opporunity? It gets tiresome.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Add 'practice' PMC structure to projects in incubation
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
> 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.
The board did not create umbrella PMCs -- XML was Xerces and Jakarta
was Tomcat/Watchdog. They grew beyond that because their names implied
more, and nobody wanted to slow them down just because they had moved
beyond their original scope. In fact, I had to threaten to shut them
down before the groups were even willing to restate their charters to
reflect what they had grown into.
Ultimately, it is very difficult (and often unreasonable) to insist that
a group of volunteers adopt a more rational set of self-management
principles, even when they run smack into the problems caused by their
own disorganization. Status quo is such a warm and fuzzy place, and
most people just want to code on their own projects. Besides, everyone
likes growth, and very few people like restructuring.
What some folks fail to understand is that a hierarchical structure,
like XML and Jakarta, does not reduce the workload of the board at all.
In fact, in my entire history on the board, I never once had to deal
directly with an issue on any of the single-level projects -- those
projects have always been self-governing because everyone in them
knows *they* are responsible for making the decision, not some other
group in "management".
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Add 'practice' PMC structure to projects in incubation
Posted by Berin Lautenbach <be...@ozemail.com.au>.
Roy,
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,
Berin
Roy 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" <fi...@apache.org>
> 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 private@project.apache.org
> or project-private@apache.org, 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Add 'practice' PMC structure to projects in incubation
Posted by Jim Jagielski <ji...@jagunet.com>.
On Nov 23, 2003, at 10:10 AM, Nicola Ken Barozzi wrote:
> There is only one thing that would *really* change and that has not
> been done till now.
>
> Committers could be given commit access long before having project
> member status, and would thus be able to commit but not vote. This
> makes it possible to keep a high bar for membership of the project but
> a lower bar for committing.
>
> Is this possible/wanted?
>
I think the problem here is when:
1. There is a significant delay between someone becoming a committer
and
a member
2. When the committer has no desire to be a member.
The below is just for illustration purposes... it's NOT the way
it is, but is a good way to explain what we mean by "bar for
membership" (or whatever). Say to become a member you need 10
ASF points. My own personal feeling is that the number of
points "required" for committer-ship should be like 7
or maybe even 8. That is, the "higher bar" is for commit
privs, and *that* is a real accomplishment, and a significant
indication of trust, etc... ASF membership is a little
hop from there.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Add 'practice' PMC structure to projects in incubation
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> Nicola Ken Barozzi wrote:
>
>> Committers could be given commit access long before having project
>> member status, and would thus be able to commit but not vote. This
>> makes it possible to keep a high bar for membership of the project but
>> a lower bar for committing.
>>
>> Is this possible/wanted?
>
> I think I don't like it. If you're committing, you're doing the work.
> If you're doing the work, you should have a say in everything that
> concerns your work (meritocracy).
This sets a bar higher for being able to start to commit.
I'm fine with it, as long as commit access/PMC membership is not handed
out like candy.
There are groups here that AFAIK are much faster in giving commit access
than others, so this would take their ways in consideration.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Add 'practice' PMC structure to projects in incubation
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Conor MacNeill wrote:
> hi Greg,
>
> Maybe it would be a good idea to forward this or somethign similar to the
> committers list. I'd say there is a number of a committers who are not
> aware of these legal issues.
>
> Whaddayareckon?
Add members to it too, please.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Add 'practice' PMC structure to projects in incubation
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
hi Greg,
Maybe it would be a good idea to forward this or somethign similar to the
committers list. I'd say there is a number of a committers who are not
aware of these legal issues.
Whaddayareckon?
Conor
> If you don't have a binding vote, then you are not responsible. The people
> *with* the binding votes are. If you make a commit, then they have the
> right to change it however they like, or to leave it. But it is at *their*
> discretion.
>
> And the theory is: by definition, the only binding votes [regarding a
> codebase] come from people on the PMC.
>
> Therefore, if you really want to have a say in the code that you're
> working on, then you want to be part of the PMC.
>
> All work is protected, as long as the above rules are followed. Things
> break down when non-PMC committers have votes, or the PMC is not
> exercising their discretion/oversight. In those cases, the committer is
> "acting on their own" and cannot be covered by the ASF.
>
> Note that while the *work* is protected, the ASF is only obligated to
> (legally) indemnify Directors, officers, and Members (see section 12.1 of
> the Bylaws). While the ASF may choose to defend PMC members, it is not
> required to do so. Thus, any committer "should" want to seek out
> Membership in the ASF or to become a PMC Chair (Chairs are officers). Also
> note that the ASF doesn't have obligations towards non-PMC committers.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Add 'practice' PMC structure to projects in incubation
Posted by Greg Stein <gs...@apache.org>.
On Tue, Nov 25, 2003 at 11:43:33PM -0500, Noel J. Bergman wrote:
>...
> When the James project was initially looking at TLP status, Nicola Ken
> forwarded a message from Roy that included a comment to the effect that if
> Committers understood their legal exposure, they would demand TLP status,
> rather than needing to be pushed into it. At least that is my recollection
> of it.
Correct.
The premise here is that a TLP is "closer" to the code than any kind of
umbrella thing could ever be. Thus, the notion of oversight and,
therefore, protection is much easier to establish.
> I don't believe that I really understood the whole issue until the
> past few days, and I am only assuming that my understanding of it is correct
> now. But if I am right, the upshot is that in order to be protected, you
> either cannot have a binding vote, or you have to be on the PMC.
Correct.
If you don't have a binding vote, then you are not responsible. The people
*with* the binding votes are. If you make a commit, then they have the
right to change it however they like, or to leave it. But it is at *their*
discretion.
And the theory is: by definition, the only binding votes [regarding a
codebase] come from people on the PMC.
Therefore, if you really want to have a say in the code that you're
working on, then you want to be part of the PMC.
All work is protected, as long as the above rules are followed. Things
break down when non-PMC committers have votes, or the PMC is not
exercising their discretion/oversight. In those cases, the committer is
"acting on their own" and cannot be covered by the ASF.
Note that while the *work* is protected, the ASF is only obligated to
(legally) indemnify Directors, officers, and Members (see section 12.1 of
the Bylaws). While the ASF may choose to defend PMC members, it is not
required to do so. Thus, any committer "should" want to seek out
Membership in the ASF or to become a PMC Chair (Chairs are officers). Also
note that the ASF doesn't have obligations towards non-PMC committers.
Cheers,
-g
--
gstein@apache.org ... ASF Chairman ... http://www.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Add 'practice' PMC structure to projects in incubation
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > At some point, hopefully not too far down the pike, the
> > Committer is voted into the PMC. Until that happens,
> > the Committer does not have a binding vote. Cannot
> > have a binding vote, because to have one outside of the
> > legal structure would expose the Committer.
> Can you explain exactly what you mean by the last sentence above?
As I understand the situation, the ASF Bylaws are setup in a specific manner
so as to provide legal protection in the event that someone should want to
file a lawsuit. The mechanism that affords that protection is the PMC. For
more detail, see Roy's message:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=general@incubator.apache
.org&msgNo=2642.
When the James project was initially looking at TLP status, Nicola Ken
forwarded a message from Roy that included a comment to the effect that if
Committers understood their legal exposure, they would demand TLP status,
rather than needing to be pushed into it. At least that is my recollection
of it. I don't believe that I really understood the whole issue until the
past few days, and I am only assuming that my understanding of it is correct
now. But if I am right, the upshot is that in order to be protected, you
either cannot have a binding vote, or you have to be on the PMC.
Hopefully, Roy will either affirm this understanding, or correct my error.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Add 'practice' PMC structure to projects in incubation
Posted by Phil Steitz <ph...@steitz.com>.
Noel J. Bergman wrote:
> Nicola Ken Barozzi wrote:
>
>
>>Committers could be given commit access long before having project
>>member status, and would thus be able to commit but not vote. This
>>makes it possible to keep a high bar for membership of the project but
>>a lower bar for committing.
>>
>>Is this possible/wanted?
>
>
> As I understand it, this was the initial structure. A Contributor posts a
> patch, the patch is reviewed and committed. At some point, a frequent
> Contributor is offered the opportunity to become a Committer. The Committer
> is allowed to commit a change, but the PMC is still responsible to review
> the commit. At some point, hopefully not too far down the pike, the
> Committer is voted into the PMC. Until that happens, the Committer does not
> have a binding vote. Cannot have a binding vote, because to have one
> outside of the legal structure would expose the Committer.
Can you explain exactly what you mean by the last sentence above?
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Add 'practice' PMC structure to projects in incubation
Posted by "Noel J. Bergman" <no...@devtech.com>.
Nicola Ken Barozzi wrote:
> Committers could be given commit access long before having project
> member status, and would thus be able to commit but not vote. This
> makes it possible to keep a high bar for membership of the project but
> a lower bar for committing.
>
> Is this possible/wanted?
As I understand it, this was the initial structure. A Contributor posts a
patch, the patch is reviewed and committed. At some point, a frequent
Contributor is offered the opportunity to become a Committer. The Committer
is allowed to commit a change, but the PMC is still responsible to review
the commit. At some point, hopefully not too far down the pike, the
Committer is voted into the PMC. Until that happens, the Committer does not
have a binding vote. Cannot have a binding vote, because to have one
outside of the legal structure would expose the Committer.
Leo Simons wrote:
> I think I don't like it. If you're committing, you're doing the work.
> If you're doing the work, you should have a say in everything that
> concerns your work (meritocracy).
Because the PMC is responsible for reviewing every change (and because we
have SCM), it allows someone to be granted commit karma before they have
earned sufficient trust to be entrusted with managing the project. If you
have an active newcomer, the process can be significantly hampered by having
to go through e-mailed patches, so you can grant commit karma to streamline
the process, without having to go straight to PMC status.
This is a simple structure. It simplifies a lot of the various sets of
rules and interactions, and it explains some of the oddities present in our
current conflicting rule sets. My understanding is that this is the way
that the ASF was designed to work, but things got bent during expansion.
Ironically, the original "rules" scale better, since the PMC oversight
requirement cannot be removed.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Add 'practice' PMC structure to projects in incubation
Posted by Leo Simons <le...@apache.org>.
Nicola Ken Barozzi wrote:
> Committers could be given commit access long before having project
> member status, and would thus be able to commit but not vote. This
> makes it possible to keep a high bar for membership of the project but
> a lower bar for committing.
>
> Is this possible/wanted?
I think I don't like it. If you're committing, you're doing the work. If
you're
doing the work, you should have a say in everything that concerns your
work (meritocracy).
Yes, there is the "chicken-egg" problem where people are planning to do
the work, but haven't yet. Should they receive commit access but be denied
the right to vote? Don't think so. Its about trust...if you give 'em an
account,
you trust 'em to not misuse voting privs either. If they violate that
trust (rare
occassion!), its often easier to coach them as equals rather than from
the top
down.
Its also about management...with commit priviledge comes management
responsibility. Don't want to take your share of the 'management overhead'?
Then you're not getting commit privs, either. I love that.
IMV, most apache people are coders at heart, and only get involved with
all the 'management' concerns when they are somehow forced to (like when
no-one does it for them but its needed anyway).
(This is also the 'code smell' surrounding incubator: many of the people
doing the coding @ incubator are not involved with doing the incubating,
and its the other way around as well.)
in summary:
+1 to a "core group" / "practice PMC" / "committer list" for incubating
projects
+1 to self-management
-0 on all p&p which seperates priviledge from responsibility
back to my corner!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Add 'practice' PMC structure to projects in incubation
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Roy T. Fielding wrote:
...
> 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.
Having had basically all opinions about this in the past years, and
having been on diverse projects, I have come to the conclusion that I
basically agree.
In particular, the Incubator PMC has been since the start an "umbrella
PMC", similar to what Jakarta and XML, mainly because it cannot easily
be made in a different way. This has made me see the shortcoming of the
approach in clearer detail.
These months of incubations have showed us in clear evidence some basic
facts that cannot be forgotten. The funny thing is that it's what we all
know, but applied to the incubator it was hard to understand.
1 - oversight must be done by the as many people as possible, just
like more eyes see more bugs -> more mentors
2 - the "management" of a project must be done by those that run
the project day by day -> PMC==committers
3 - it's ok to create "subprojects" in a project as long as the
project remains united as one in decision making -> core groups
Let's make for example Cocoon, which can IMHO take advantage right now
of this way of doing things.
Cocoon has already a set of committers that are all on the PMC.
There are two projects with close ties to Cocoon, that are Forrest and
Lenya, Forrest under XML and Lenya in Incubation. Let's assume that
Forrest goes under Cocoon and that Lenya exits incubation.
Cocoon as a project could as well consist of all long-stating committers
of these codebases, and take all decisions together. This is already in
part a fact, as the Cocoon PMC has started to vote a Lenya release as
they feel part of the project, and Cocoon committers have access to Forrest.
Then there would be three core groups, one for Cocoon, one for Lenya and
one for Forrest. There would this be a single project, a single PMC, and
just a partitioning of competence on parts of code.
There is only one thing that would *really* change and that has not been
done till now.
Committers could be given commit access long before having project
member status, and would thus be able to commit but not vote. This makes
it possible to keep a high bar for membership of the project but a lower
bar for committing.
Is this possible/wanted?
> 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.
This is a possibility, that is ok for me.
Another possibility would be to define in the rules that the incubating
project cannot voe itself out.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Add 'practice' PMC structure to projects in incubation
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Phil Steitz wrote:
...
>
> Are you proposing that committers who are not PMC members or "Project
> Committers" should not have voting rights?
On the PMC list it has come out that we were misunderstanding each other
over the term "binding votes".
Let me explain what we said.
Some talked about a vote made by committers (==ones with CVS access) on
an incubating project, and called
binding votes == votes by ones with CVS karma
non-binding votes == votes by lurkers
Then it was replied that only PMC members can cast "binding" votes, and
that these are thus all non-binding.
Why?
Because only the PMC members can make decisions on behalf of the
foundation, and thus are the only ones who's votes are "binding".
So then it was said that it doesn't make sense, because the Incubator
PMC cannot decide knowingly about what committers an incubating project
wants.
So the only way out of this catch22 is that all project committers are
PMC members (and hence the core-group proposal). :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Add 'practice' PMC structure to projects in incubation
Posted by Phil Steitz <ph...@steitz.com>.
Roy 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.
Are you proposing that committers who are not PMC members or "Project
Committers" should not have voting rights?
>
> 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.
Seems to conflict with the statement above (unless I misunderstood).
>
> 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
Thanks for sharing the post below. This clears up a few things for me at
least. At the risk of appearing dense, however, I am still not
understanding exactly why "The PMC must equal the voters on a given
project...." It seems to me that it *might* be possible (safe?) to have
all *decisions* approved by the PMC, while the process (voting) to
arrive at those decisions could include [binding?] input from non-PMC
members. What am I missing?
Phil
>
> ===============
> From: "Roy T. Fielding" <fi...@apache.org>
> 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 private@project.apache.org
> or project-private@apache.org, 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org