Re: [PROPOSAL] As it ever were (draft 2)

[Stephen McConnell]

Geir Magnusson Jr. wrote:

On Dec 28, 2003, at 7:51 PM, Stephen McConnell wrote:

Ted:

First off - appologies because I havn't read every message on
Jakarta.  But it seems to me that someone has said that the
very notion of federation employed by the board to facilitate
management (i.e. the establishment of sub-structures) is for
some reason "not-allowed" beyond the level of the board (that's
just a conclusion based on recent posts to this list).
Basically I agree with just about everthing you saying in you
message - but I'm seeing what appears to be a group attempting
to work around constraints that eliminate the potential for
composite projects.  AFAIAC, if Jakarta put in place an
appropriate managemrnt model (involving sub-PMC or whatever),
is there anything politically incorrect with that approach?


As far as I know, there is nothing that prevents any sub-structures.  
However, one school of thought (the one I subscribe to) believes that 
substructures aren't needed.  As we aren't trying to manage from 
above, but rather trying aggregate oversight "from below" by bringing 
interested committers into the PMC and providing education on oversight. 


Your sentiments are very close to my own.

But instead of thinking about substructures as unit to mange - think 
about substructures as units that provide a Jakarta PMC with information 
that you need in order to fulfil the reposibilities of the Jakarta PMC.  
Its' like saying - "hey guys - a bunch of Jakart PMC members cannot do 
everyting alone - we need some support - and one way to get support is 
to put in some structure (a.k.a. delegation of reponsibility) to the 
subprojects that the Jakarta PMC is responsible for.  If those 
subprojects jump-up and say - "hey, here is an elected representative 
who hase volunteered to keep you up to date" and even better - they say 
"our elected representative is only there to present the opinion of a 
bunch of a committed committers - and by the way - we are calling 
ourselves a PMC or XPM or ZPC or whatever".

Bottom line - I was involved with an unmanged suproject of Jakarta.   
That project has now exited Jakarta because the Board provided the 
management model.  What I'm thinking is that there is no reason why the 
Jakarta PMC cannot provide the environment to its subproject (i.e. 
provide the managemewnt model) to take on responsibility - and though 
this, strengthen and support the Jakarta PMC.

Stephen.




geir

Stephen.

Ted Husted wrote:

- Original message >
From: Stephen Colebourne <[EMAIL PROTECTED]>
To: Jakarta General List <[EMAIL PROTECTED]>
Received: Sun, 28 Dec 2003 14:16:26 +
Subject: Re: [PROPOSAL] As it ever were  (draft 2)

Since the PMC cannot delegate its responsibilities, the report would
have to be prepared by a PMC member, ideally one directly involved 
with
subproject. (A likely suspect being the DEV list moderator.)



Er, doesn't this just emphasize how broken this process is?

Not that I see. It formalizes what should have been done from the 
beginning.
We tried to do it before, but we then run into the politics of 
whether the person making the report is the PMC "representative" to 
the subproject.
The fundamental disconnect is that all of the committers should be 
on the PMC, because all of the committers are the decision-makers 
for one or more of our various products.


-PROPOSITION (2)-
[snip]
Work regarding a specific subproject can continue to occur on that
subproject's DEV list. PMC members (aka committers) following that 
list
can vote on its releases and other day-to-day affairs. So long as the
minimum quorum is met, the vote is legal and binding.



So, we are trying to delegate power to subprojects? Er, but we 
can't now can
we.

No. We are instituting a "minimum threshold meritocracy" for each 
product. The PMC members/committers who are working on a product, 
and interested in its development, and the ones who make the 
decisions about that product. That's how it works now socially, and 
that's how it should work legally.


So who can vote? 'Following the list' is a very vague term. 
Presumably I can
simply subscribe to struts-dev and then vote, never having even 
used struts?
It also seems highly dubious to say that a vote is legal and 
binding if most
of the PMC never knew the vote occurred.

As it stands today, any of the current PMC members could do exactly 
that.
And, this is also how it works in the Commons today. If I want to 
chime in on a product and start committing, other volunteers are 
happy for the help.
If you did subscribe to the Struts list and took an interest in the 
product, I'm sure we'd welcome your commits. You're an Apache 
Committer, and I'm sure you've earned your stripe. Not by trying to 
do harm, but by trying to do go

Re: [PROPOSAL] As it ever were (draft 2)

[Geir Magnusson Jr.]

On Dec 28, 2003, at 7:51 PM, Stephen McConnell wrote:

Ted:

First off - appologies because I havn't read every message on
Jakarta.  But it seems to me that someone has said that the
very notion of federation employed by the board to facilitate
management (i.e. the establishment of sub-structures) is for
some reason "not-allowed" beyond the level of the board (that's
just a conclusion based on recent posts to this list).
Basically I agree with just about everthing you saying in you
message - but I'm seeing what appears to be a group attempting
to work around constraints that eliminate the potential for
composite projects.  AFAIAC, if Jakarta put in place an
appropriate managemrnt model (involving sub-PMC or whatever),
is there anything politically incorrect with that approach?
As far as I know, there is nothing that prevents any sub-structures.  
However, one school of thought (the one I subscribe to) believes that 
substructures aren't needed.  As we aren't trying to manage from above, 
but rather trying aggregate oversight "from below" by bringing 
interested committers into the PMC and providing education on 
oversight.

geir

Stephen.

Ted Husted wrote:

- Original message >
From: Stephen Colebourne <[EMAIL PROTECTED]>
To: Jakarta General List <[EMAIL PROTECTED]>
Received: Sun, 28 Dec 2003 14:16:26 +
Subject: Re: [PROPOSAL] As it ever were  (draft 2)

Since the PMC cannot delegate its responsibilities, the report would
have to be prepared by a PMC member, ideally one directly involved 
with
subproject. (A likely suspect being the DEV list moderator.)



Er, doesn't this just emphasize how broken this process is?

Not that I see. It formalizes what should have been done from the 
beginning.
We tried to do it before, but we then run into the politics of 
whether the person making the report is the PMC "representative" to 
the subproject.
The fundamental disconnect is that all of the committers should be on 
the PMC, because all of the committers are the decision-makers for 
one or more of our various products.


-PROPOSITION (2)-
[snip]
Work regarding a specific subproject can continue to occur on that
subproject's DEV list. PMC members (aka committers) following that 
list
can vote on its releases and other day-to-day affairs. So long as 
the
minimum quorum is met, the vote is legal and binding.



So, we are trying to delegate power to subprojects? Er, but we can't 
now can
we.

No. We are instituting a "minimum threshold meritocracy" for each 
product. The PMC members/committers who are working on a product, and 
interested in its development, and the ones who make the decisions 
about that product. That's how it works now socially, and that's how 
it should work legally.


So who can vote? 'Following the list' is a very vague term. 
Presumably I can
simply subscribe to struts-dev and then vote, never having even used 
struts?
It also seems highly dubious to say that a vote is legal and binding 
if most
of the PMC never knew the vote occurred.

As it stands today, any of the current PMC members could do exactly 
that.
And, this is also how it works in the Commons today. If I want to 
chime in on a product and start committing, other volunteers are 
happy for the help.
If you did subscribe to the Struts list and took an interest in the 
product, I'm sure we'd welcome your commits. You're an Apache 
Committer, and I'm sure you've earned your stripe. Not by trying to 
do harm, but by trying to do good.

The value of administrative [vote]s on the DEV list are often 
overrated. A veto must have technical merit to be binding. Malicious 
vetos are not valid. And, as you know, when someone tried to enforce 
their own will over the will of the community, the ultimate result 
(sadly) was a suspension of write access.



Under proposition (1), the significant events occurring for each
subproject would be reported to the PMC list, for the review of the 
PMC
at-large.



So the PMC is reviewing events already happened, not actively 
managing. Er,
sounds like the relationship between the board and a PMC to me.

No, the committers to each subproject are committee members. Most 
Apache projects practice a minimum threshold meritocracy. We don't 
expect every committer to be involved in every decision, or cast 
votes or opinion outside their area of interest or expertise. If 
three committers/members vote +1, we're good to go.
The PMC was not meant to be a legislative body: it's suppose to be 
the core group, the decision-makers, the active managers, the 
committers.


PMC membership is voluntary. Anyone can resign from the PMC at any
time. If a volunteer would like to be a committer, but not a PMC 
member,
then each subproject can then decide whether to support separate
committer and PMC member roles or not.



I wou

Re: [PROPOSAL] As it ever were (draft 2)

[Stephen McConnell]

Ted:

First off - appologies because I havn't read every message on
Jakarta.  But it seems to me that someone has said that the
very notion of federation employed by the board to facilitate
management (i.e. the establishment of sub-structures) is for
some reason "not-allowed" beyond the level of the board (that's
just a conclusion based on recent posts to this list).
Basically I agree with just about everthing you saying in you
message - but I'm seeing what appears to be a group attempting
to work around constraints that eliminate the potential for
composite projects.  AFAIAC, if Jakarta put in place an
appropriate managemrnt model (involving sub-PMC or whatever),
is there anything politically incorrect with that approach?
Stephen.

Ted Husted wrote:

- Original message >
From: Stephen Colebourne <[EMAIL PROTECTED]>
To: Jakarta General List <[EMAIL PROTECTED]>
Received: Sun, 28 Dec 2003 14:16:26 +
Subject: Re: [PROPOSAL] As it ever were  (draft 2)
 

Since the PMC cannot delegate its responsibilities, the report would
have to be prepared by a PMC member, ideally one directly involved with
subproject. (A likely suspect being the DEV list moderator.)
 

 

Er, doesn't this just emphasize how broken this process is?
   

Not that I see. It formalizes what should have been done from the beginning. 

We tried to do it before, but we then run into the politics of whether the person making the report is the PMC "representative" to the subproject. 

The fundamental disconnect is that all of the committers should be on the PMC, because all of the committers are the decision-makers for one or more of our various products. 

 

-PROPOSITION (2)-
[snip]
Work regarding a specific subproject can continue to occur on that
subproject's DEV list. PMC members (aka committers) following that list
can vote on its releases and other day-to-day affairs. So long as the
minimum quorum is met, the vote is legal and binding.
 

 

So, we are trying to delegate power to subprojects? Er, but we can't now can
we.
   

No. We are instituting a "minimum threshold meritocracy" for each product. The PMC members/committers who are working on a product, and interested in its development, and the ones who make the decisions about that product. That's how it works now socially, and that's how it should work legally. 

 

So who can vote? 'Following the list' is a very vague term. Presumably I can
simply subscribe to struts-dev and then vote, never having even used struts?
It also seems highly dubious to say that a vote is legal and binding if most
of the PMC never knew the vote occurred.
   

As it stands today, any of the current PMC members could do exactly that. 

And, this is also how it works in the Commons today. If I want to chime in on a product and start committing, other volunteers are happy for the help. 

If you did subscribe to the Struts list and took an interest in the product, I'm sure we'd welcome your commits. You're an Apache Committer, and I'm sure you've earned your stripe. Not by trying to do harm, but by trying to do good.

The value of administrative [vote]s on the DEV list are often overrated. A veto must have technical merit to be binding. Malicious vetos are not valid. And, as you know, when someone tried to enforce their own will over the will of the community, the ultimate result (sadly) was a suspension of write access.

 

Under proposition (1), the significant events occurring for each
subproject would be reported to the PMC list, for the review of the PMC
at-large.
 

 

So the PMC is reviewing events already happened, not actively managing. Er,
sounds like the relationship between the board and a PMC to me.
   

No, the committers to each subproject are committee members. Most Apache projects practice a minimum threshold meritocracy. We don't expect every committer to be involved in every decision, or cast votes or opinion outside their area of interest or expertise. If three committers/members vote +1, we're good to go. 

The PMC was not meant to be a legislative body: it's suppose to be the core group, the decision-makers, the active managers, the committers. 

 

PMC membership is voluntary. Anyone can resign from the PMC at any
time. If a volunteer would like to be a committer, but not a PMC member,
then each subproject can then decide whether to support separate
committer and PMC member roles or not.
 

 

I would suggest that there is nothing in this proposal that will cause the
board members to have any more faith in Jakarta than they do now. And thats
because it changes nothing of significance.
   

It changes everything. It turns Jakarta from a place that is supposedly governed by an "other wordly elite" to a place that practice "minimum threshold meritocracy" -- both socially and le

Re: [PROPOSAL] As it ever were (draft 2)

[Geir Magnusson Jr.]

On Dec 28, 2003, at 10:48 AM, Ted Husted wrote:

- Original message >
From: Stephen Colebourne <[EMAIL PROTECTED]>
To: Jakarta General List <[EMAIL PROTECTED]>
Received: Sun, 28 Dec 2003 14:16:26 +0000
Subject: Re: [PROPOSAL] As it ever were  (draft 2)
Since the PMC cannot delegate its responsibilities, the report would
have to be prepared by a PMC member, ideally one directly involved 
with
subproject. (A likely suspect being the DEV list moderator.)

Er, doesn't this just emphasize how broken this process is?
Not that I see. It formalizes what should have been done from the 
beginning.
This is getting strangely confusing.  What we all have been talking 
about is getting all possible people from the Jakarta sub-projects on 
the PMC.  In doing that, we have coverage of the codebases, and people 
will be responsible for things they are involved in, *and*, in the 
event they see something in a project they aren't involved in, can get 
involved.

I agree w/ Ted, partially.  From his previous note, suggesting that 
specific reporting responsibillity falls to the -dev list moderator, I 
disagree that this should be requires as this limits participation 
(instead of 2 possible people, it's back to 1), and might make someone 
not want to help out via list moderation if it also placed additional 
requirements on them.

We tried to do it before, but we then run into the politics of whether 
the person making the report is the PMC "representative" to the 
subproject.
Right - given that any PMC member can report issues, the PMC chair 
simply summarizes what has been happening over the last month for the 
board.  If subproject  had nothing interesting going on (i.e. all 
is well), he or she would either just say that, or omit it alltogether, 
focusing only on the issues that arose.

The fundamental disconnect is that all of the committers should be on 
the PMC, because all of the committers are the decision-makers for one 
or more of our various products.
100% true.

geir



-PROPOSITION (2)-
[snip]
Work regarding a specific subproject can continue to occur on that
subproject's DEV list. PMC members (aka committers) following that 
list
can vote on its releases and other day-to-day affairs. So long as the
minimum quorum is met, the vote is legal and binding.

So, we are trying to delegate power to subprojects? Er, but we can't 
now can
we.
No. We are instituting a "minimum threshold meritocracy" for each 
product. The PMC members/committers who are working on a product, and 
interested in its development, and the ones who make the decisions 
about that product. That's how it works now socially, and that's how 
it should work legally.


So who can vote? 'Following the list' is a very vague term. 
Presumably I can
simply subscribe to struts-dev and then vote, never having even used 
struts?
It also seems highly dubious to say that a vote is legal and binding 
if most
of the PMC never knew the vote occurred.
As it stands today, any of the current PMC members could do exactly 
that.

And, this is also how it works in the Commons today. If I want to 
chime in on a product and start committing, other volunteers are happy 
for the help.

If you did subscribe to the Struts list and took an interest in the 
product, I'm sure we'd welcome your commits. You're an Apache 
Committer, and I'm sure you've earned your stripe. Not by trying to do 
harm, but by trying to do good.

The value of administrative [vote]s on the DEV list are often 
overrated. A veto must have technical merit to be binding. Malicious 
vetos are not valid. And, as you know, when someone tried to enforce 
their own will over the will of the community, the ultimate result 
(sadly) was a suspension of write access.


Under proposition (1), the significant events occurring for each
subproject would be reported to the PMC list, for the review of the 
PMC
at-large.

So the PMC is reviewing events already happened, not actively 
managing. Er,
sounds like the relationship between the board and a PMC to me.
No, the committers to each subproject are committee members. Most 
Apache projects practice a minimum threshold meritocracy. We don't 
expect every committer to be involved in every decision, or cast votes 
or opinion outside their area of interest or expertise. If three 
committers/members vote +1, we're good to go.

The PMC was not meant to be a legislative body: it's suppose to be the 
core group, the decision-makers, the active managers, the committers.


PMC membership is voluntary. Anyone can resign from the PMC at any
time. If a volunteer would like to be a committer, but not a PMC 
member,
then each subproject can then decide whether to support separate
committer and PMC member roles or not.

I would suggest that there is nothing in this proposal that will 
cause the
board members to have any 

Re: [PROPOSAL] As it ever were (draft 2)

[Ted Husted]

- Original message >
From: Stephen Colebourne <[EMAIL PROTECTED]>
To: Jakarta General List <[EMAIL PROTECTED]>
Received: Sun, 28 Dec 2003 14:16:26 +0000
Subject: Re: [PROPOSAL] As it ever were  (draft 2)

>> Since the PMC cannot delegate its responsibilities, the report would
>> have to be prepared by a PMC member, ideally one directly involved with
>> subproject. (A likely suspect being the DEV list moderator.)

>Er, doesn't this just emphasize how broken this process is?

Not that I see. It formalizes what should have been done from the beginning.

We tried to do it before, but we then run into the politics of whether the person 
making the report is the PMC "representative" to the subproject.

The fundamental disconnect is that all of the committers should be on the PMC, because 
all of the committers are the decision-makers for one or more of our various products.


>> -PROPOSITION (2)-
>> [snip]
>> Work regarding a specific subproject can continue to occur on that
>> subproject's DEV list. PMC members (aka committers) following that list
>> can vote on its releases and other day-to-day affairs. So long as the
>> minimum quorum is met, the vote is legal and binding.

>So, we are trying to delegate power to subprojects? Er, but we can't now can
>we.

No. We are instituting a "minimum threshold meritocracy" for each product. The PMC 
members/committers who are working on a product, and interested in its development, 
and the ones who make the decisions about that product. That's how it works now 
socially, and that's how it should work legally.


>So who can vote? 'Following the list' is a very vague term. Presumably I can
>simply subscribe to struts-dev and then vote, never having even used struts?
>It also seems highly dubious to say that a vote is legal and binding if most
>of the PMC never knew the vote occurred.

As it stands today, any of the current PMC members could do exactly that.

And, this is also how it works in the Commons today. If I want to chime in on a 
product and start committing, other volunteers are happy for the help.

If you did subscribe to the Struts list and took an interest in the product, I'm sure 
we'd welcome your commits. You're an Apache Committer, and I'm sure you've earned your 
stripe. Not by trying to do harm, but by trying to do good.

The value of administrative [vote]s on the DEV list are often overrated. A veto must 
have technical merit to be binding. Malicious vetos are not valid. And, as you know, 
when someone tried to enforce their own will over the will of the community, the 
ultimate result (sadly) was a suspension of write access.


>> Under proposition (1), the significant events occurring for each
>> subproject would be reported to the PMC list, for the review of the PMC
>> at-large.

>So the PMC is reviewing events already happened, not actively managing. Er,
>sounds like the relationship between the board and a PMC to me.

No, the committers to each subproject are committee members. Most Apache projects 
practice a minimum threshold meritocracy. We don't expect every committer to be 
involved in every decision, or cast votes or opinion outside their area of interest or 
expertise. If three committers/members vote +1, we're good to go.

The PMC was not meant to be a legislative body: it's suppose to be the core group, the 
decision-makers, the active managers, the committers.


>> PMC membership is voluntary. Anyone can resign from the PMC at any
>> time. If a volunteer would like to be a committer, but not a PMC member,
>> then each subproject can then decide whether to support separate
>> committer and PMC member roles or not.

>I would suggest that there is nothing in this proposal that will cause the
>board members to have any more faith in Jakarta than they do now. And thats
>because it changes nothing of significance.

It changes everything. It turns Jakarta from a place that is supposedly governed by an 
"other wordly elite" to a place that practice "minimum threshold meritocracy" -- both 
socially and legally. Today our social order is out-of-synch with our legal status. 
This proposal legalizes what already happens in practice.

* It provides a forum where ALL the decision makers can discuss oversight (not just a 
chosen few).

AND,

* It puts reporting in the lap of the decision-makers for each product, which ensures 
it stays on the *decision-makers* radar, and is not pushed up to some body that cannot 
possible oversee our products.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] As it ever were (draft 2)

[Ted Husted]

> -PROPOSITION (1)-
>
> * Require all Jakarta products (or subprojects) to file regular reports
> with the PMC.
You mean 'make each subproject work like a TLP' don't you?

> Since the PMC cannot delegate its responsibilities, the report would
> have to be prepared by a PMC member, ideally one directly involved with
> subproject. (A likely suspect being the DEV list moderator.)
Er, doesn't this just emphasise how broken this process is?

> -PROPOSITION (2)-
> [snip]
> Work regarding a specific subproject can continue to occur on that
> subproject's DEV list. PMC members (aka committers) following that list
> can vote on its releases and other day-to-day affairs. So long as the
> minimum quorum is met, the vote is legal and binding.
So, we are trying to delegate power to subprojects? Er, but we can't now can
we.

So who can vote? 'Following the list' is a very vague term. Presumably I can
simply subscribe to struts-dev and then vote, never having even used struts?
It also seems highly dubious to say that a vote is legal and binding if most
of the PMC never knew the vote occurred.

> Under proposition (1), the significant events occurring for each
> subproject would be reported to the PMC list, for the review of the PMC
> at-large.
So the PMC is reviewing events already happened, not actively managing. Er,
sounds like the relationship between the board and a PMC to me.

> PMC membership is voluntary. Anyone can resign from the PMC at any
> time. If a volunteer would like to be a committer, but not a PMC member,
> then each subproject can then decide whether to support separate
> committer and PMC member roles or not.

--
I would suggest that there is nothing in this proposal that will cause the
board members to have any more faith in Jakarta than they do now. And thats
because it changes nothing of significance.

Stephen








-
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]

Re: [PROPOSAL] As it ever were (draft 2)

[Stephen Colebourne]

> -PROPOSITION (1)-
>
> * Require all Jakarta products (or subprojects) to file regular reports
> with the PMC.
You mean 'make each subproject work like a TLP' don't you?

> Since the PMC cannot delegate its responsibilities, the report would
> have to be prepared by a PMC member, ideally one directly involved with
> subproject. (A likely suspect being the DEV list moderator.)
Er, doesn't this just emphasise how broken this process is?

> -PROPOSITION (2)-
> [snip]
> Work regarding a specific subproject can continue to occur on that
> subproject's DEV list. PMC members (aka committers) following that list
> can vote on its releases and other day-to-day affairs. So long as the
> minimum quorum is met, the vote is legal and binding.
So, we are trying to delegate power to subprojects? Er, but we can't now can
we.

So who can vote? 'Following the list' is a very vague term. Presumably I can
simply subscribe to struts-dev and then vote, never having even used struts?
It also seems highly dubious to say that a vote is legal and binding if most
of the PMC never knew the vote occurred.

> Under proposition (1), the significant events occurring for each
> subproject would be reported to the PMC list, for the review of the PMC
> at-large.
So the PMC is reviewing events already happened, not actively managing. Er,
sounds like the relationship between the board and a PMC to me.

> PMC membership is voluntary. Anyone can resign from the PMC at any
> time. If a volunteer would like to be a committer, but not a PMC member,
> then each subproject can then decide whether to support separate
> committer and PMC member roles or not.

--
I would suggest that there is nothing in this proposal that will cause the
board members to have any more faith in Jakarta than they do now. And thats
because it changes nothing of significance.

Stephen








-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] As it ever were

[Geir Magnusson Jr.]

Exactly - lets not overdo this with too much process.  Lets just get 
people who have genuine interest onto the PMC, covering the project(s) 
they work on, and then keep growing.

geir

On Dec 24, 2003, at 2:46 PM, Henri Yandell wrote:

Post a list of projects and get PMC people to volunteer to post 
reports,
chase up CLAs and improve PMC-to-non-PMC ratio, and record who has
volunteered. Keep going until all projects are covered by the minimum
number, which can be 1 to start with.

Hen

On Wed, 24 Dec 2003, Ted Husted wrote:

(Again, sorry about the quoting.)

o·ver·sight

1. An unintentional omission or mistake.
2. Watchful care or management; supervision


The board expects PMCs to exercise (2) so as to avoid (1). :)

For a PMC this boils down to issues of "committer consensus" and
"intellectual property". In the past, there have been incidents at
Jakarta on both counts that lead to suspension of access, for both
individuals and modules (on different occasions).
IMHO, if we were to

* require subprojects to file regular reports with bullets regarding
consensus and oversight, and
* subscribe all committers to the PMC list where these reports are 
filed

then we'd be able to defuse these happenstances before they turn into
incidents.
IMHO, the one and only set of individuals that can provide "watchful
care" over a codebase is the set of committers we already have for 
each
subproject.

IMHO, each and every committer to a Jakarta subproject has already
passed through a gauntlet that proves they are PMC material and 
entitled
to binding votes.

All we need to do is complete the process that promotes our committers
to PMC members with binding votes, as our original guidelines
contemplated, and require subprojects to provide regular status 
reports.
(Just as the board requires our project to report.)

As both Roy and Greg have said, if the Jakarta committers truly
understood how few rights and privileges they have, they would be
demanding both ASF and PMC membership. Few do, so few have.
-Ted.



-
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]

--
Geir Magnusson Jr   203-247-1713(m)
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] As it ever were

[Geir Magnusson Jr.]

On Dec 24, 2003, at 12:11 PM, Costin Manolache wrote:

Ted,

I think we must focus on what we agree on - it seems nobody is against
expanding the PMC to include most committers ( or all active 
committers who don't decline ).

I'm not sure I understand Geir's current position, but I think he still
agrees we need to include most people. I don't think anyone can argue 
for excluding some active committers - I'm ok with a wait period ( i.e
people who have been active committers for at least N months ), but it 
has to be a deterministic process.


My current position hasn't changed.  We should try to include 100% of 
Jakarta committers, but recognize that we won't find that number who 
are willing to assume the oversight responsibility of being on the PMC. 
 This isn't surprising, and is what other projects like httpd 
experience as well.

And I agree, it must be a deterministic process - not a sweep.

In addition to that, there are other things we need to do - like 
making sure we have clearly identified people who will prepare the 
reports for
each codebase ( be it moderators, release managers, rotation, drafts 
or whatever a project wants to do - as long as the result is 2-3 names 
and
a monthly report ).
We also need to clearly identify what the board means by "oversight" ( 
to be honest - I don't know, I just have a vague idea, haven't seen 
any official definition :-). Since this "oversight" is motivated by 
legal concerns - I think we need a definition understandable by 
everyone, not just guesses.

But doing it all at once is very unlikely to work - with all the 
strong opinions around jakarta. Divide and conquer - first step is to 
grow the PMC - IMO you need to simplify your PROPOSAL to make it 
focused to one point ( instead of solving more problems at once ), and 
move to VOTE.

I don't understand why he's going about it this way.

geir

--
Geir Magnusson Jr   203-247-1713(m)
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] As it ever were (draft 2)

[Ted Husted]

[PROPOSAL] As it ever were

I've incorporated many of the suggestions made on the list and prepared
another draft for community review.
-ISSUE-

The ASF Board has indicated that it does not believe that the Jakarta
PMC, in its present form, is capable of providing oversight of all the
subprojects under its purview.
The role of the Jakarta PMC is two-fold:

* The PMC is responsible the active management of the project

* The PMC provides oversight for the project

-Management-

When the board creates a project, it passes a resolution. Resolutions
regarding Jakarta
have been passed here:

  

and here

  

The board's authority to create Projects and PMCs stems from section 6.3
of the ASF bylaws:
  

From a legal perspective, the PMC is the only entity that the board
recognizes as being responsible for the management of a project. Only
committee members have "binding" votes. Only committee members would be
indemnified by the ASF in the event of a law suit
.

In fact, most of the rights and responsibilities we at Jakarta have
ascribed to "committers" in fact belong only to "PMC members".
Originally, we envisioned the PMC to be a steering committee
, responsible for the "strategic direction and
success of the Jakarta Project". But this is *not* the case. The PMC
doesn't just "set the agenda", it is the body that *actively manages*
the project. The PMC has the rights and responsibilities that most of us
would ascribe to the subproject committers.
-Oversight-

As used here, the term oversight follows its dictionary definition:

o·ver·sight

   1. An unintentional omission or mistake.
   2. Watchful care or management; supervision


The board expects PMCs to exercise (2) so as to avoid (1). :) All good
managers must provide oversight, and a PMC is no exception.
For a PMC, oversight boils down to issues of "committer consensus" and
"intellectual property". In the past, there have been incidents at
Jakarta on both counts that lead to suspension of access, for both
individuals and modules (on different occasions).
Jakarta now manages 21 subprojects (with Pluto on the way), and another
40+ components in the Commons and Commons Sandbox, The board's question
is "How can the Jakarta PMC, as it is now constituted, possibly provide
oversight for all of this code?".
-CURRENT APPROACH-

The PMC has decided to expand its membership to an indefinite number and
is actively soliciting nominations of qualified committers. So far, the
PMC has rejected the idea of nominating all the committers or any
committers who volunteers. Each new nominee must be voted in by the PMC
(or not).
At this time, no other changes are on the agenda.

For additional background, see

* 

* 

and the archives for the general list

*  or .

-PROPOSED CHANGES-

(1) Require all Jakarta products (or subprojects) to file regular
reports with the PMC
(2) Promote all Jakarta Committers to the Jakarta PMC, nunc pro tunc

-PROPOSITION (1)-

* Require all Jakarta products (or subprojects) to file regular reports
with the PMC.
A key element of oversight is vigilance. One way to achieve vigilance is
regular reporting. Just as the board requires the vice president of a
project to file regular reports, the PMC should require each subproject
to file a similar report.
Here is a format often used by projects reporting to the board:



* What code releases have been made?

* Legal issues:

* Cross-project issues:

* Any problems with committers, members, etc?

* Plans and expectations for the next period?



Since the PMC cannot delegate its responsibilities, the report would
have to be prepared by a PMC member, ideally one directly involved with
subproject. (A likely suspect being the DEV list moderator.)
Failure to report would have to be considered a serious matter,
possibly leading to blocking CVS access. Accordingly, each subproject
would want to be very, very sure these reports are in fact being filed.
-PROPOSITION (2)-

* Promote all Jakarta Committers to the Jakarta PMC, nunc pro tunc

The original Jakarta guidelines state that committers have the binding
votes and make the decisions regarding the codebase. We now know that,
from an ASF perspective, committers have write-access to the codebase,
but the PMC members have binding votes and make the decisions.
The idea of committers with non-binding votes has been broached many
times over the years. Each time, the consensus has been that we vote
most with our commits, and that every volunteer committing to a Jakarta
codebase is entitled to a binding vote (and veto).
Whenever we selected any committer for any Jakarta codebase, we did so
with the expectation that they would be responsible for its "active
management". We were in fact not mer

Re: [PROPOSAL] As it ever were

[Phil Steitz]

Ted Husted wrote:
(Again, sorry about the quoting.)

o·ver·sight

   1. An unintentional omission or mistake.
   2. Watchful care or management; supervision


The board expects PMCs to exercise (2) so as to avoid (1). :)

For a PMC this boils down to issues of "committer consensus" and 
"intellectual property". In the past, there have been incidents at 
Jakarta on both counts that lead to suspension of access, for both 
individuals and modules (on different occasions)

IMHO, if we were to

* require subprojects to file regular reports with bullets regarding 
consensus and oversight, and

* subscribe all committers to the PMC list where these reports are filed

then we'd be able to defuse these happenstances before they turn into 
incidents.
Thanks for directly addressing the oversight issue.  This looks like a 
good plan to me. Can you explain a little more

a) what kinds of "issues" we need to worry most about;
b) what kinds of things should go into the reports; and
c) how subproject committers could share the responsibility of creating 
the reports.

IMHO, the one and only set of individuals that can provide "watchful 
care" over a codebase is the set of committers we already have for each 
subproject.
I agree.
IMHO, each and every committer to a Jakarta subproject has already 
passed through a gauntlet that proves they are PMC material and entitled 
to binding votes.
Until I understand fully what the responsibilities are, I am not sure that 
I agree with this, partly because subproject committers may not have 
"signed up for" a role beyond the subproject.  I agree with your 
statements about votes being binding, however, so we clearly need to 
change (or "legalize" ;) something.

All we need to do is complete the process that promotes our committers 
to PMC members with binding votes, as our original guidelines 
contemplated, and require subprojects to provide regular status reports. 
(Just as the board requires our project to report.)
This will solve the problem of committers having binding votes on the 
codebase that they work on, but it may not be the best solution for the 
Jakarta PMC.  Is it totally out of bounds from the ASF perspective to 
allow subproject committers to have binding votes for their subprojects 
without being PMC members?  I know that this has been discussed and 
categorical statements have been made, but I frankly do not get it. If the 
Jakarta PMC reviews and aggregates all of the subproject reports and 
includes representation from each of the subprojects, where is the gap in 
oversight?  I don't mean to be argumentative or dense here, but it is very 
important that we understand clearly what the constraints are (and why 
these constraints exist, and whether they can be changed as the ASF scales).
As both Roy and Greg have said, if the Jakarta committers truly 
understood how few rights and privileges they have, they would be 
demanding both ASF and PMC membership. Few do, so few have.
IIUC, it is mostly a matter of legal protection, not so much "rights and 
privileges" (unless you view indemnification as a right or privilege). 
Here again, a little more background / facts would be helpful, as well as 
some indication of what is "written in stone" and why that is so.

Phil
-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [PROPOSAL] As it ever were

[Danny Angus]

> As both Roy and Greg have said, if the Jakarta committers truly 
> understood how few rights and privileges they have, they would be 
> demanding both ASF and PMC membership. Few do, so few have.

Well I kind of asked for PMC nomination, are you saying that we should, or indeed 
could, ask for membership? 

d.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] As it ever were

[Henri Yandell]

Post a list of projects and get PMC people to volunteer to post reports,
chase up CLAs and improve PMC-to-non-PMC ratio, and record who has
volunteered. Keep going until all projects are covered by the minimum
number, which can be 1 to start with.

Hen

On Wed, 24 Dec 2003, Ted Husted wrote:

> (Again, sorry about the quoting.)
>
> o·ver·sight
>
> 1. An unintentional omission or mistake.
> 2. Watchful care or management; supervision
>
> 
>
> The board expects PMCs to exercise (2) so as to avoid (1). :)
>
> For a PMC this boils down to issues of "committer consensus" and
> "intellectual property". In the past, there have been incidents at
> Jakarta on both counts that lead to suspension of access, for both
> individuals and modules (on different occasions).
>
> IMHO, if we were to
>
> * require subprojects to file regular reports with bullets regarding
> consensus and oversight, and
>
> * subscribe all committers to the PMC list where these reports are filed
>
> then we'd be able to defuse these happenstances before they turn into
> incidents.
>
> IMHO, the one and only set of individuals that can provide "watchful
> care" over a codebase is the set of committers we already have for each
> subproject.
>
> IMHO, each and every committer to a Jakarta subproject has already
> passed through a gauntlet that proves they are PMC material and entitled
> to binding votes.
>
> All we need to do is complete the process that promotes our committers
> to PMC members with binding votes, as our original guidelines
> contemplated, and require subprojects to provide regular status reports.
> (Just as the board requires our project to report.)
>
> As both Roy and Greg have said, if the Jakarta committers truly
> understood how few rights and privileges they have, they would be
> demanding both ASF and PMC membership. Few do, so few have.
>
> -Ted.
>
>
>
> -
> 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]

Re: [PROPOSAL] As it ever were

[Ted Husted]

(Again, sorry about the quoting.)

o·ver·sight

   1. An unintentional omission or mistake.
   2. Watchful care or management; supervision


The board expects PMCs to exercise (2) so as to avoid (1). :)

For a PMC this boils down to issues of "committer consensus" and 
"intellectual property". In the past, there have been incidents at 
Jakarta on both counts that lead to suspension of access, for both 
individuals and modules (on different occasions).

IMHO, if we were to

* require subprojects to file regular reports with bullets regarding 
consensus and oversight, and

* subscribe all committers to the PMC list where these reports are filed

then we'd be able to defuse these happenstances before they turn into 
incidents.

IMHO, the one and only set of individuals that can provide "watchful 
care" over a codebase is the set of committers we already have for each 
subproject.

IMHO, each and every committer to a Jakarta subproject has already 
passed through a gauntlet that proves they are PMC material and entitled 
to binding votes.

All we need to do is complete the process that promotes our committers 
to PMC members with binding votes, as our original guidelines 
contemplated, and require subprojects to provide regular status reports. 
(Just as the board requires our project to report.)

As both Roy and Greg have said, if the Jakarta committers truly 
understood how few rights and privileges they have, they would be 
demanding both ASF and PMC membership. Few do, so few have.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] As it ever were

[Costin Manolache]

Ted,

I think we must focus on what we agree on - it seems nobody is against
expanding the PMC to include most committers ( or all active committers 
who don't decline ).

I'm not sure I understand Geir's current position, but I think he still
agrees we need to include most people. I don't think anyone can argue 
for excluding some active committers - I'm ok with a wait period ( i.e
people who have been active committers for at least N months ), but it 
has to be a deterministic process.

In addition to that, there are other things we need to do - like making 
sure we have clearly identified people who will prepare the reports for
each codebase ( be it moderators, release managers, rotation, drafts or 
whatever a project wants to do - as long as the result is 2-3 names and
a monthly report ).
We also need to clearly identify what the board means by "oversight" ( 
to be honest - I don't know, I just have a vague idea, haven't seen any 
official definition :-). Since this "oversight" is motivated by legal 
concerns - I think we need a definition understandable by everyone, not 
just guesses.

But doing it all at once is very unlikely to work - with all the strong 
opinions around jakarta. Divide and conquer - first step is to grow the 
PMC - IMO you need to simplify your PROPOSAL to make it focused to one 
point ( instead of solving more problems at once ), and move to VOTE.

Costin

Ted Husted wrote:
I apologize for not quoting. I'm experiencing technical difficulties and 
making do the best I can.

I meant what I said. We must make an immediate, good faith effort to 
correct the false and misleading information in the Jakarta guidelines, 
and give all committers due notice of their true status. Otherwise, 
there's a point where we cross the line.

The PMC does not now nor has it ever affirmed each and every decision 
made by the committers. It may affirm some of the release votes, but 
there's a lot that goes into making a release. And, AFAIK, the PMC is 
not authorized to delegate its decision making to non-members.

IMHO, we all thought we had the rights and responsibilities of PMC 
members in the first place. When each and every of these committers were 
appointed by a subproject, they had the traditional role of a PMC member 
in mind. Hence, the proposal is to make all Jakarta committers PMC 
members, which, I believe, was the underlying intent of the original 
guidelines, and what we all thought was happening in the first place.

I reject the idea that being a PMC member brings additional 
responsibility. All committers are already responsible for 
decision-making and oversight. We simply need a mechanism that reminds 
everyone of our existing responsibilities.

If all committers are subscribed to the PMC list, and each subproject is 
given the explicit responsibility for regular reporting, I sincerely 
believe we will be able to easily dispatch the oversight issues. All we 
need is a little infrastructure, and the volunteers will take care of 
the rest.

A long-standing principle at Jakarta has always been that the highest, 
best votes are the commits. We have always rejected the idea of 
committers without binding votes. To say now that votes are "socially" 
binding but not "legally" binding is inconsistent with community standards.

I am happy that we do have communities that will honor the votes of all 
its committers, whether they are legally binding or not. But, our 
legalities should reflect the community standards, which are that a 
committer is a committer.

Obviously, if a committer wants to opt-out and become a developer again, 
that is their choice. But we should not be second-guessing the 
communities by opting-in committers to the PMC. The community thought 
they were good enough to have binding votes and binding vetos: who are 
we to say different?

I've proposed my solution: Promote everyone who doesn't opt-out to the 
PMC; subscribe all committers to the PMC list; require regular reports 
from each subproject.

AFAIK, the only other option on the table is to continue to nominate 
committers willy-nilly and hope-against-hope that a few more heartbeats 
will somehow give the PMC the wisdom to make decisions on the 
subproject's behalf and the mystic ability to oversee all the codebases.

I don't think we need to create a Jakarta elite. I think we need to do 
what we meant to do in the first place: let the committers make the 
binding decisions.

Accordingly, if a positive consensus develops among the committers 
regarding the original proposal, we can bring it as a vote in the 
Jakarta way. Otherwise, I would just let the proposal drop, so that the 
consensus view can proceed.

-Ted.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] As it ever were

[Ted Husted]

I apologize for not quoting. I'm experiencing technical difficulties and 
making do the best I can.

I meant what I said. We must make an immediate, good faith effort to 
correct the false and misleading information in the Jakarta guidelines, 
and give all committers due notice of their true status. Otherwise, 
there's a point where we cross the line.

The PMC does not now nor has it ever affirmed each and every decision 
made by the committers. It may affirm some of the release votes, but 
there's a lot that goes into making a release. And, AFAIK, the PMC is 
not authorized to delegate its decision making to non-members.

IMHO, we all thought we had the rights and responsibilities of PMC 
members in the first place. When each and every of these committers were 
appointed by a subproject, they had the traditional role of a PMC member 
in mind. Hence, the proposal is to make all Jakarta committers PMC 
members, which, I believe, was the underlying intent of the original 
guidelines, and what we all thought was happening in the first place.

I reject the idea that being a PMC member brings additional 
responsibility. All committers are already responsible for 
decision-making and oversight. We simply need a mechanism that reminds 
everyone of our existing responsibilities.

If all committers are subscribed to the PMC list, and each subproject is 
given the explicit responsibility for regular reporting, I sincerely 
believe we will be able to easily dispatch the oversight issues. All we 
need is a little infrastructure, and the volunteers will take care of 
the rest.

A long-standing principle at Jakarta has always been that the highest, 
best votes are the commits. We have always rejected the idea of 
committers without binding votes. To say now that votes are "socially" 
binding but not "legally" binding is inconsistent with community standards.

I am happy that we do have communities that will honor the votes of all 
its committers, whether they are legally binding or not. But, our 
legalities should reflect the community standards, which are that a 
committer is a committer.

Obviously, if a committer wants to opt-out and become a developer again, 
that is their choice. But we should not be second-guessing the 
communities by opting-in committers to the PMC. The community thought 
they were good enough to have binding votes and binding vetos: who are 
we to say different?

I've proposed my solution: Promote everyone who doesn't opt-out to the 
PMC; subscribe all committers to the PMC list; require regular reports 
from each subproject.

AFAIK, the only other option on the table is to continue to nominate 
committers willy-nilly and hope-against-hope that a few more heartbeats 
will somehow give the PMC the wisdom to make decisions on the 
subproject's behalf and the mystic ability to oversee all the codebases.

I don't think we need to create a Jakarta elite. I think we need to do 
what we meant to do in the first place: let the committers make the 
binding decisions.

Accordingly, if a positive consensus develops among the committers 
regarding the original proposal, we can bring it as a vote in the 
Jakarta way. Otherwise, I would just let the proposal drop, so that the 
consensus view can proceed.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] As it ever were

[Geir Magnusson Jr.]

On Dec 24, 2003, at 6:28 AM, Ted Husted wrote:

My complaint is this:

Our current base of committers were led to believe they have binding 
votes. We are now told this is not the case. The committers we now 
have were all elected on the premise that they had binding votes and 
oversight responsibilities for their codebase. They were in fact 
elected as if they were to be members of the PMC.

Personally, I feel it is an abomination to think we have the right to 
hand-pick a subset of these committers and bestow upon them binding 
votes. Our communities deserve to be represented by the set of 
committers that they have already chosen, not an arbitrary subset 
deemed to be "PMC material".

I call for the Jakarta Chair, as the ASF Vice President in charge of 
Jakarta, to do the Right Thing and promote all Jakarta committers to 
the Jakarta Project Managemenet Committee.

I disagree, and I think you are going a bit far.  I call for the 
Jakarta Chair to let us continue the discussion and keep working 
towards our solution :)

Anything less breaks the covenant we made with each and every Jakarta 
committer, as published in the original Jakarta guidelines. We said 
committers had binding votes, and it is now our obligation to make it 
so. If we fail to make a good faith effort to correct our oversight, 
then we will have accepted all these contributions under false 
pretenses.
"False pretenses" means that there is the "intent to cheat".  I assume 
you didn't know that, and thus will retract it.

What we have said is that the committer has write access to the 
repository and voting rights allowing them to affect the future, and so 
far, that's how it worked.  I don't remember one complaint to the 
contrary.

We have a community that respects the vote of every committer.  Period.

The fact that we have a *legal* structure, the ASF as a corporation, 
that requires the board to know about every corporate activity is what 
the PMC is for - the board delegates oversight to the PMC.  So when a 
community votes, and that community isn't all on the PMC, then you have 
a vote which is legally not binding,  although totally respected by the 
community, which becomes a legally-binding vote when the PMC is 
informed, and the PMC acknowledges it.

So while the argument that a vote of committers is not binding legally, 
it is socially binding, and it becomes a binding legal vote when the 
PMC approves it, as the PMC is in effect voting by proxy, respecting 
the decision of the community.  That actually is no different than the 
board representing the wishes of the ASF membership.

What we are thus solving is not a community issue, but a legal one.  
Bringing as many informed, interested people as possible onto the PMC 
increases oversight, increases communication between the subprojects, 
and IMO, strengthens community.  Right now, we couldn't make a clear 
case that we have enough PMC representation for all the codebases.

I'm assuming the source of this idea of yours was the conversation we 
had on the PMC list about grandfathering in every committer.  While 
suggesting it originally as I too thought it would be the fast approach 
to the desired solution, I no longer support the idea of doing it in a 
blanket maneuver, and here's why :

1) Being on the PMC does imply responsibility.  Some people are not 
interested in that responsibility and just want to commit.  I think 
that should be allowed.  Not encouraged, but allowed.

2) Roping everyone into the PMC without ensuring things like CLA and 
understanding of responsibilities makes the whole thing a farce - we 
couldn't demonstrate that the chain of oversight from the board to the 
sub-projects is clear and manageable, because we have no clue who we 
just asked to represent the ASF in project governance, nor do we have 
any indication of their interest.

Thus, while painful and work intensive, adding people one by one lets 
us produce a healthy, active PMC rather than simply a redefinition of 
terms.   I hope you can see what I'm trying to say, and hoping you want 
to help out on the 'work intensive' part :)

geir

--
Geir Magnusson Jr   203-247-1713(m)
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] As it ever were

[Ted Husted]

My complaint is this:

Our current base of committers were led to believe they have binding 
votes. We are now told this is not the case. The committers we now have 
were all elected on the premise that they had binding votes and 
oversight responsibilities for their codebase. They were in fact elected 
as if they were to be members of the PMC.

Personally, I feel it is an abomination to think we have the right to 
hand-pick a subset of these committers and bestow upon them binding 
votes. Our communities deserve to be represented by the set of 
committers that they have already chosen, not an arbitrary subset deemed 
to be "PMC material".

I call for the Jakarta Chair, as the ASF Vice President in charge of 
Jakarta, to do the Right Thing and promote all Jakarta committers to the 
Jakarta Project Managemenet Committee.

Anything less breaks the covenant we made with each and every Jakarta 
committer, as published in the original Jakarta guidelines. We said 
committers had binding votes, and it is now our obligation to make it 
so. If we fail to make a good faith effort to correct our oversight, 
then we will have accepted all these contributions under false pretenses.

If all committers are PMC members, then all committers can then be 
subscribed to the PMC list. Each subproject can be given the 
responsibility of submitting to the PMC list a regular report as to 
their status. Routine business can be conducted in the subproject DEV 
list by the PMC members associated with that subproject. In the event 
there is an unreported oversight issue, any Jakarta Committer/PMC member 
will be able to bring it up on the PMC list at will.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] As it ever were

[Henri Yandell]

On Tue, 23 Dec 2003, Ted Husted wrote:

>  > Make release managers the default stewards

My suggestion:

Work out what people on the PMC are members of the PMC for. ie) I consider
myself a Taglibs and Commons developer [both umberella projects so not
great examples].

List which projects people are on the PMC for. These people are now
required to submit a report to the chair (PMC in general). Whether they
break it down further [ie) Commons], or choose one amongst themselves is
up to themselves.

So basically the PMC making a requirement of a part of their community to
be responsible for a part of their codebase.

Hen


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] As it ever were

[Tetsuya Kitahata]

On Tue, 23 Dec 2003 12:10:03 -0500
(Subject: Re: [PROPOSAL] As it ever were)
Ted Husted wrote:

>  > steward
> 
> The proposal is to expand the role of the moderator, rather than
> invent an overlapping role with similar responsibilities. If the
> volunteer is not up to task, then another volunteer can be sought.
> (Hence, the language about the Chair appointing another volunteer.)
> The idea is that they have *already* volunteered to moderate the list.
> If one individual doesn't want to volunteer, another can be found.

You can check who is/are current moderator(s) of XX subproject,
by using the method which can be found at
/committers/docs/mailinglist-tips.txt ("committers" module)
'How to know "Who is moderator of XX list" / "Number of subscribers"'
section (resource.txt is also good)

You may post to the address which can be found there with this two
lines body -- 
===
[EMAIL PROTECTED]
gump
==(two lines)==

--

Hope this helps.

-- Tetsuya. ([EMAIL PROTECTED])



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] As it ever were

[Ted Husted]

> Make release managers the default stewards

Not every subproject has a clearly defined release manager. In Struts, 
we are even starting to have multiple people collaborate on the release 
manager role.

The key to oversight is persistence. Since it is not possible for every 
committee member to be personally aware of what's happening in every 
subproject, we need regular reports from someone who does -- just as the 
board needs regular reports from each chair.

We don't need for subprojects to have a "chair", but we do need someone 
to tender regular reports as to the subproject's status. The keyword 
being "regular".

The person making these reports should already have a working knowledge 
of the subproject and be able to report based on what they already know. 
Of course, what they know is based on reading and understanding the 
traffic on the lists.

Ideally, the DEV list moderator should also be someone who is plugged 
into the subproject. So, instead of starting out by creating two roles 
with overlapping responsibilities, I'm suggesting we try extending the 
list moderator's role first. List moderator is the only persistent role 
that must already exist for each subproject's DEV list.

In some cases, we may need to have different volunteers fulfilling each 
role. But, personally, I like to try making do with what we have before 
running out and creating something new.

I also don't want to get bogged down with finding a steward for each 
subproject. The DEV list moderators are there, so let's use them. If a 
list moderator doesn't want to steward, then I'm sure they can find 
someone who does. Hey, we all friends here. :)

The key point is that the chair, and its PMC, need consistent, reliable 
reports, so that the chair can report in turn to the board. We need each 
subproject to fulfill the responsibility of regular reporting by 
whatever means necessary. We also need to push that responsibility down 
to the subproject. The people working in the subproject are the only 
ones truly aware of its status.

Should we encourage subprojects to "elect" a steward? No. AFAIK, we 
don't elect roles like list moderator or release manager. People just 
step up and offer to do the job -- as it should be. But if a subproject 
wants to a elect a steward, or a list moderator, or a release manager. 
that's their business. All we need is for the job to get done.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] As it ever were

[Costin Manolache]

Ted Husted wrote:
 > steward

The proposal is to expand the role of the moderator, rather than invent 
an overlapping role with similar responsibilities. If the volunteer is 
not up to task, then another volunteer can be sought. (Hence, the 
language about the Chair appointing another volunteer.) The idea is that 
they have *already* volunteered to moderate the list. If one individual 
doesn't want to volunteer, another can be found.
They volunteer to moderate a mailing list, not send reports or be a 
sub-commitee secretary ( if sub-commitee would be allowed - which AFAIK 
is not ) :-)

My point was that there is no need for another "role" or hierarchy. 
Would we start organizing elections for mailing list moderator ?


 > delegate

The proposal does not "delegate" the board's responsibility. To be 
binding, anything voted on any DEV list would still need the a 3+ quorum 
of PMC members. PMC members would be voting on PMC business.

There is nothing anywhere that says all the PMC business has to take 
place on a single list. If PMC members want to subscribe to all the 
lists and monitor all the PMC business, that's their choice. Conversely, 
if PMC members want to "abstain" from the routine business surrounding a 
given codebase, they don't have to subscribe to that DEV list.
I agree with that.
But keep in mind that any PMC member can subscribe to any jakarta 
mailing list he wants and vote or -1 if he sees a problem !

I still think that important votes should take place on jakarta pmc list 
- this will keep the entire PMC in the loop.


Meanwhile, through the steward's reports, the committee-at-large is 
being kept in the loop as to each subproject's "big picture".

The proposal does the things.


What about changing from mail list moderator to the current release 
manager(s) ? Each codebase already has one ( or few ) release managers,
and they are already responsible for announcing releases and important
events.




* It realizes the fact that Jakarta doesn't have non-binding committers 
(meaning that all committers must become PMC members).
May. It is not mandatory.


* It provides a clear mechanism for "scoping" the work of the PMC. The 
business of each subproject can be conducted by people who are in-touch 
with that subproject on that subproject's DEV list.
+1 ( but votes should still be on [EMAIL PROTECTED] )


* It provides a clear channel for oversight.
+1



The steward's reports are designed to ensure that someone is at least 
thinking about these matters on a regular basis. Since it's someone's 
role to report on these things, they are more likely to be reported. 
Some issues we had in the past would not be readily addressed, since all 
the committers will be on the PMC list. A PMC member won't have to go 
off and "talk to a subproject" and report back. The subproject 
committers can hash issues out on the PMC list, where other members can 
provide input. And, any committer/PMC-member who thought there *might* 
be a problem, can now bring it up directly on the PMC list, whether the 
steward brings it up or not.
Well, a PMC member won't "talk to a subproject" - it may talk with 
fellow PMC members if he is not tracking that project.

Anyway - I think it's a good idea to have someone send reports, I just 
think that the release managers are a better choice. They are already 
responsible for making the proposal and vote for the release.

Costin



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] As it ever were

[Ted Husted]

> steward

The proposal is to expand the role of the moderator, rather than invent 
an overlapping role with similar responsibilities. If the volunteer is 
not up to task, then another volunteer can be sought. (Hence, the 
language about the Chair appointing another volunteer.) The idea is that 
they have *already* volunteered to moderate the list. If one individual 
doesn't want to volunteer, another can be found.

> delegate

The proposal does not "delegate" the board's responsibility. To be 
binding, anything voted on any DEV list would still need the a 3+ quorum 
of PMC members. PMC members would be voting on PMC business.

There is nothing anywhere that says all the PMC business has to take 
place on a single list. If PMC members want to subscribe to all the 
lists and monitor all the PMC business, that's their choice. Conversely, 
if PMC members want to "abstain" from the routine business surrounding a 
given codebase, they don't have to subscribe to that DEV list.

Meanwhile, through the steward's reports, the committee-at-large is 
being kept in the loop as to each subproject's "big picture".

The proposal does the things.

* It realizes the fact that Jakarta doesn't have non-binding committers 
(meaning that all committers must become PMC members).

* It provides a clear mechanism for "scoping" the work of the PMC. The 
business of each subproject can be conducted by people who are in-touch 
with that subproject on that subproject's DEV list.

* It provides a clear channel for oversight.

The steward's reports are designed to ensure that someone is at least 
thinking about these matters on a regular basis. Since it's someone's 
role to report on these things, they are more likely to be reported. 
Some issues we had in the past would not be readily addressed, since all 
the committers will be on the PMC list. A PMC member won't have to go 
off and "talk to a subproject" and report back. The subproject 
committers can hash issues out on the PMC list, where other members can 
provide input. And, any committer/PMC-member who thought there *might* 
be a problem, can now bring it up directly on the PMC list, whether the 
steward brings it up or not.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] As it ever were

[Costin Manolache]

+1 on almost everything

I don't like the "PMC steward" thing - except for bootstraping the
process. It also violates the rule that you can't volunteer other people:-)
Also the "delegation" is not allowed by the board AFAIK, and I don't
think it is a good idea to create another layer ( steward/moderator ).
In any case - let's do one thing at a time and have a [VOTE] thread
for bootstraping - and after the new members are added we can move to
another step. This also has the benefit that all comitters will have
a binding vote for the next steps.
I would also propose that the vote for the chair and any reorganization 
be held after extending the PMC.

Costin

Ted Husted wrote:
Re: Proposal to grandfather Active Committers to Jakarta subprojects as
PMC Members.
As it stands, most Jakarta committers have assumed that they already
have the rights, privileges, and responsibilities granted PMC members.
(Mainly because it was written that way in the Jakarta bylaws).
When all these committers were elected, it was with the understanding
they had binding votes and oversight responsibility, as stated by the
original Jakarta bylaws. It could be said that we have been electing PMC
members, rather than only committers, all along, without realizing it.
Following our original bylaws and practices, there is no such thing as a
committer without the rights and responsibilities of PMC membership.
Accordingly, a stipulation of becoming (or remaining) a committer to a
Jakarta subproject can said to be PMC membership, as it is described by
the ASF bylaws.
To complete the process we've already begun, I suggest a [VOTE] be
brought on each [EMAIL PROTECTED] list to nominate the list of
its active committers to the PMC. This vote will also serve as notice to
committers who wish to opt-out.
To bootstrap the process, the current moderator of each DEV list can be
asked to bring the vote and report the result. If necessary, a new
moderator can be installed by the Chair.
The moderator of each dev list will also act as the "PMC steward" for
the subproject. The list moderator is suggested since that individual is
already suppose to be monitoring the list where this activity occurs.
The steward will have the responsibility of immediately
reporting any new committers/PMC members elected to a subproject, so
that they can be affirmed by the chair and notice given the board.
All PMC members (which is to say all active committers to jakarta-* CVS
repositories) will be subscribed to the PMC list, which will be a
required list for PMC membership, like [EMAIL PROTECTED]
The PMC business for each subproject will continue to take place on its
own dev list. The steward for each project will report to the [EMAIL PROTECTED] list
the status of his or her subproject, covering such points as:


* What code releases have been made?

* Legal issues:

* Cross-project issues:

* Any problems with committers, members, etc?

* Plans and expectations for the next period?



The chair can then summarize these reports for presentation to the board.

Effectively, each dev list becomes a sub-committee of the PMC. (Divide
and conquer.) The list moderator/steward becomes the subcommittee's
secretary, with the additional responsibility of summarizing the result
of our ongoing meetings.
As appropriate, the steward or any PMC member can bring up oversight
issues to the PMC list. Routine matters, such as releases, can be
approved by the PMC members who are committers to a given subproject. So
long as the usual 3+ quorum is met, there would be no reason to bring
routine votes before the [EMAIL PROTECTED] list. Of course, the result would be
tabulated on the steward's report, which *is* published to the [EMAIL PROTECTED] list.
-Ted.

Pro-forma [VOTE]

It has come to our attention that the Committers to a Jakarta subproject
must also be members of the Jakarta Project Management Committee to have
binding votes. To complete the legal process, the current PMC is asking
each subproject to nominate it's active committers to the PMC.
Since we have never supported the idea of non-voting committers at
Jakarta, and only PMC members have binding votes, if a committer is
unwilling to serve on the Jakarta PMC, we will be unable to continue to
extend write access to any jakarta-* CVS to that individual.
Each PMC member will also be subscribed to the Jakarta PMC list.
*However, all subproject business can continue to occur on this DEV list
as always!* In the future, we anticipate that the PMC list will be very
low-volume. (Really, we do!)
The only change is that the owner of the DEV list must also serve as the
PMC steward for the subproject. The steward must submit monthly status
reports for the project and immediately report any new Committers to the
PMC list.
But, other than that, it will be business as usual.

Accordingly, we ask that the Committers to this subproject nominate the
following individuals to the Jakarta PMC. Please check all that apply.
[ ] $committer

Any committer 

Re: [PROPOSAL] As it ever were

[Geir Magnusson Jr.]

I don't think that crossposting would be good  keep it here

On Dec 22, 2003, at 4:52 PM, Tetsuya Kitahata wrote:

Hello, folks.

I am a moderator of three -dev lists in jakarta.
What should I do next? Forwardin' this Pro-forma to
each -dev lists?
T.I.A.

-- Tetsuya. ([EMAIL PROTECTED])

On Sun, 21 Dec 2003 21:07:26 -0500
(Subject: Re: [PROPOSAL] As it ever were)
Geir Magnusson Jr. wrote:
This is what I proposed some weeks ago.   I think you would serve the
community well if you also posted a summary of pros and cons that we
had discussed.
On Dec 21, 2003, at 6:14 PM, Ted Husted wrote:

Re: Proposal to grandfather Active Committers to Jakarta subprojects 
as
PMC Members.

As it stands, most Jakarta committers have assumed that they already
have the rights, privileges, and responsibilities granted PMC 
members.
(Mainly because it was written that way in the Jakarta bylaws).

When all these committers were elected, it was with the understanding
they had binding votes and oversight responsibility, as stated by the
original Jakarta bylaws. It could be said that we have been electing
PMC
members, rather than only committers, all along, without realizing 
it.

Following our original bylaws and practices, there is no such thing 
as
a
committer without the rights and responsibilities of PMC membership.
Accordingly, a stipulation of becoming (or remaining) a committer to 
a
Jakarta subproject can said to be PMC membership, as it is described 
by
the ASF bylaws.

To complete the process we've already begun, I suggest a [VOTE] be
brought on each [EMAIL PROTECTED] list to nominate the list of
its active committers to the PMC. This vote will also serve as notice
to
committers who wish to opt-out.
To bootstrap the process, the current moderator of each DEV list can 
be
asked to bring the vote and report the result. If necessary, a new
moderator can be installed by the Chair.

The moderator of each dev list will also act as the "PMC steward" for
the subproject. The list moderator is suggested since that individual
is
already suppose to be monitoring the list where this activity occurs.
The steward will have the responsibility of immediately
reporting any new committers/PMC members elected to a subproject, so
that they can be affirmed by the chair and notice given the board.
All PMC members (which is to say all active committers to jakarta-* 
CVS
repositories) will be subscribed to the PMC list, which will be a
required list for PMC membership, like [EMAIL PROTECTED]

The PMC business for each subproject will continue to take place on 
its
own dev list. The steward for each project will report to the [EMAIL PROTECTED]
list
the status of his or her subproject, covering such points as:



* What code releases have been made?

* Legal issues:

* Cross-project issues:

* Any problems with committers, members, etc?

* Plans and expectations for the next period?



The chair can then summarize these reports for presentation to the
board.
Effectively, each dev list becomes a sub-committee of the PMC. 
(Divide
and conquer.) The list moderator/steward becomes the subcommittee's
secretary, with the additional responsibility of summarizing the 
result
of our ongoing meetings.

As appropriate, the steward or any PMC member can bring up oversight
issues to the PMC list. Routine matters, such as releases, can be
approved by the PMC members who are committers to a given subproject.
So
long as the usual 3+ quorum is met, there would be no reason to bring
routine votes before the [EMAIL PROTECTED] list. Of course, the result would be
tabulated on the steward's report, which *is* published to the [EMAIL PROTECTED]
list.
-Ted.

Pro-forma [VOTE]

It has come to our attention that the Committers to a Jakarta
subproject
must also be members of the Jakarta Project Management Committee to
have
binding votes. To complete the legal process, the current PMC is 
asking
each subproject to nominate it's active committers to the PMC.

Since we have never supported the idea of non-voting committers at
Jakarta, and only PMC members have binding votes, if a committer is
unwilling to serve on the Jakarta PMC, we will be unable to continue 
to
extend write access to any jakarta-* CVS to that individual.

Each PMC member will also be subscribed to the Jakarta PMC list.
*However, all subproject business can continue to occur on this DEV
list
as always!* In the future, we anticipate that the PMC list will be 
very
low-volume. (Really, we do!)

The only change is that the owner of the DEV list must also serve as
the
PMC steward for the subproject. The steward must submit monthly 
status
reports for the project and immediately report any new Committers to
the
PMC list.

But, other than that, it will be business as usual.

Accordingly, we ask that the Committers to this subproject nominate 
the
following individuals to the Jakarta PMC. Please check all that 
apply.

[ ] $committer

Any committer who wishes

Re: [PROPOSAL] As it ever were

[Tetsuya Kitahata]

Hello, folks.

I am a moderator of three -dev lists in jakarta.
What should I do next? Forwardin' this Pro-forma to
each -dev lists?

T.I.A.

-- Tetsuya. ([EMAIL PROTECTED])

On Sun, 21 Dec 2003 21:07:26 -0500
(Subject: Re: [PROPOSAL] As it ever were)
Geir Magnusson Jr. wrote:

> This is what I proposed some weeks ago.   I think you would serve the 
> community well if you also posted a summary of pros and cons that we 
> had discussed.
> 
> On Dec 21, 2003, at 6:14 PM, Ted Husted wrote:
> 
> > Re: Proposal to grandfather Active Committers to Jakarta subprojects as
> > PMC Members.
> >
> > As it stands, most Jakarta committers have assumed that they already
> > have the rights, privileges, and responsibilities granted PMC members.
> > (Mainly because it was written that way in the Jakarta bylaws).
> >
> > When all these committers were elected, it was with the understanding
> > they had binding votes and oversight responsibility, as stated by the
> > original Jakarta bylaws. It could be said that we have been electing 
> > PMC
> > members, rather than only committers, all along, without realizing it.
> >
> > Following our original bylaws and practices, there is no such thing as 
> > a
> > committer without the rights and responsibilities of PMC membership.
> > Accordingly, a stipulation of becoming (or remaining) a committer to a
> > Jakarta subproject can said to be PMC membership, as it is described by
> > the ASF bylaws.
> >
> > To complete the process we've already begun, I suggest a [VOTE] be
> > brought on each [EMAIL PROTECTED] list to nominate the list of
> > its active committers to the PMC. This vote will also serve as notice 
> > to
> > committers who wish to opt-out.
> >
> > To bootstrap the process, the current moderator of each DEV list can be
> > asked to bring the vote and report the result. If necessary, a new
> > moderator can be installed by the Chair.
> >
> > The moderator of each dev list will also act as the "PMC steward" for
> > the subproject. The list moderator is suggested since that individual 
> > is
> > already suppose to be monitoring the list where this activity occurs.
> > The steward will have the responsibility of immediately
> > reporting any new committers/PMC members elected to a subproject, so
> > that they can be affirmed by the chair and notice given the board.
> >
> > All PMC members (which is to say all active committers to jakarta-* CVS
> > repositories) will be subscribed to the PMC list, which will be a
> > required list for PMC membership, like [EMAIL PROTECTED]
> >
> > The PMC business for each subproject will continue to take place on its
> > own dev list. The steward for each project will report to the [EMAIL PROTECTED] 
> > list
> > the status of his or her subproject, covering such points as:
> >
> > 
> >
> > * What code releases have been made?
> >
> > * Legal issues:
> >
> > * Cross-project issues:
> >
> > * Any problems with committers, members, etc?
> >
> > * Plans and expectations for the next period?
> >
> > 
> >
> > The chair can then summarize these reports for presentation to the 
> > board.
> >
> > Effectively, each dev list becomes a sub-committee of the PMC. (Divide
> > and conquer.) The list moderator/steward becomes the subcommittee's
> > secretary, with the additional responsibility of summarizing the result
> > of our ongoing meetings.
> >
> > As appropriate, the steward or any PMC member can bring up oversight
> > issues to the PMC list. Routine matters, such as releases, can be
> > approved by the PMC members who are committers to a given subproject. 
> > So
> > long as the usual 3+ quorum is met, there would be no reason to bring
> > routine votes before the [EMAIL PROTECTED] list. Of course, the result would be
> > tabulated on the steward's report, which *is* published to the [EMAIL PROTECTED] 
> > list.
> >
> > -Ted.
> >
> > Pro-forma [VOTE]
> >
> > It has come to our attention that the Committers to a Jakarta 
> > subproject
> > must also be members of the Jakarta Project Management Committee to 
> > have
> > binding votes. To complete the legal process, the current PMC is asking
> > each subproject to nominate it's active committers to the PMC.
> >
> > Since we have never supported the idea of non-voting committers at
> > Jakarta, and only PMC members have binding votes, if a committer is
> > unwilling to serve on the Jak

Re: [PROPOSAL] As it ever were

[Geir Magnusson Jr.]

This is what I proposed some weeks ago.   I think you would serve the 
community well if you also posted a summary of pros and cons that we 
had discussed.

On Dec 21, 2003, at 6:14 PM, Ted Husted wrote:

Re: Proposal to grandfather Active Committers to Jakarta subprojects as
PMC Members.
As it stands, most Jakarta committers have assumed that they already
have the rights, privileges, and responsibilities granted PMC members.
(Mainly because it was written that way in the Jakarta bylaws).
When all these committers were elected, it was with the understanding
they had binding votes and oversight responsibility, as stated by the
original Jakarta bylaws. It could be said that we have been electing 
PMC
members, rather than only committers, all along, without realizing it.

Following our original bylaws and practices, there is no such thing as 
a
committer without the rights and responsibilities of PMC membership.
Accordingly, a stipulation of becoming (or remaining) a committer to a
Jakarta subproject can said to be PMC membership, as it is described by
the ASF bylaws.

To complete the process we've already begun, I suggest a [VOTE] be
brought on each [EMAIL PROTECTED] list to nominate the list of
its active committers to the PMC. This vote will also serve as notice 
to
committers who wish to opt-out.

To bootstrap the process, the current moderator of each DEV list can be
asked to bring the vote and report the result. If necessary, a new
moderator can be installed by the Chair.
The moderator of each dev list will also act as the "PMC steward" for
the subproject. The list moderator is suggested since that individual 
is
already suppose to be monitoring the list where this activity occurs.
The steward will have the responsibility of immediately
reporting any new committers/PMC members elected to a subproject, so
that they can be affirmed by the chair and notice given the board.

All PMC members (which is to say all active committers to jakarta-* CVS
repositories) will be subscribed to the PMC list, which will be a
required list for PMC membership, like [EMAIL PROTECTED]
The PMC business for each subproject will continue to take place on its
own dev list. The steward for each project will report to the [EMAIL PROTECTED] 
list
the status of his or her subproject, covering such points as:



* What code releases have been made?

* Legal issues:

* Cross-project issues:

* Any problems with committers, members, etc?

* Plans and expectations for the next period?



The chair can then summarize these reports for presentation to the 
board.

Effectively, each dev list becomes a sub-committee of the PMC. (Divide
and conquer.) The list moderator/steward becomes the subcommittee's
secretary, with the additional responsibility of summarizing the result
of our ongoing meetings.
As appropriate, the steward or any PMC member can bring up oversight
issues to the PMC list. Routine matters, such as releases, can be
approved by the PMC members who are committers to a given subproject. 
So
long as the usual 3+ quorum is met, there would be no reason to bring
routine votes before the [EMAIL PROTECTED] list. Of course, the result would be
tabulated on the steward's report, which *is* published to the [EMAIL PROTECTED] 
list.

-Ted.

Pro-forma [VOTE]

It has come to our attention that the Committers to a Jakarta 
subproject
must also be members of the Jakarta Project Management Committee to 
have
binding votes. To complete the legal process, the current PMC is asking
each subproject to nominate it's active committers to the PMC.

Since we have never supported the idea of non-voting committers at
Jakarta, and only PMC members have binding votes, if a committer is
unwilling to serve on the Jakarta PMC, we will be unable to continue to
extend write access to any jakarta-* CVS to that individual.
Each PMC member will also be subscribed to the Jakarta PMC list.
*However, all subproject business can continue to occur on this DEV 
list
as always!* In the future, we anticipate that the PMC list will be very
low-volume. (Really, we do!)

The only change is that the owner of the DEV list must also serve as 
the
PMC steward for the subproject. The steward must submit monthly status
reports for the project and immediately report any new Committers to 
the
PMC list.

But, other than that, it will be business as usual.

Accordingly, we ask that the Committers to this subproject nominate the
following individuals to the Jakarta PMC. Please check all that apply.
[ ] $committer

Any committer who wishes to opt-out may notify the Jakarta chair
([EMAIL PROTECTED]). If you opt-out, regardless of the vote, you will 
not
be subscribed to the PMC list, and your write access to jakarta CVS
repositories will be removed. (Sorry, but it's part of the package 
now.)

###



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Geir Magnusso