You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Joe Schaefer <jo...@yahoo.com> on 2012/01/31 01:06:43 UTC
[DISCUSS] eliminate vetoes on personnel votes
It is clear that with all the turmoil of late and people
lightly tossing around -1's that the notion of having veto
authority over personnel matters makes little sense on this
PMC. Therefore I propose we adopt the policy that personnel
votes are by straight majority consensus, iow no vetoes allowed.
I intend to offer a policy vote on this issue over the coming
days and that vote, as with all procedural votes, is NOT subject
to veto.
Any other rational opinions?
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message -----
> From: William A. Rowe Jr. <wr...@rowe-clan.net>
> To: Joe Schaefer <jo...@yahoo.com>
> Cc: "general@incubator.apache.org" <ge...@incubator.apache.org>
> Sent: Tuesday, January 31, 2012 1:12 PM
> Subject: Re: [DISCUSS] eliminate vetoes on personnel votes
>
> On 1/31/2012 11:38 AM, Joe Schaefer wrote:
>>
>> Plainly wrong: It has been repeatedly established (even by the Chair)
>> that policy decisions here are not subject to veto. This is one of those
> times.
>> Furthermore the documentation [1] clearly points out that procedural issues
>> are to be decided by majority consensus, and nothing could be more
> procedural
>> than a vote about how to count votes.
>>
>> [1] http://www.apache.org/foundation/voting.html
>
> You assert this is simply policy. I assert that this is a fundamental
> to "project bylaws", much like "we don't fork" (if we
> don't), or "all
> votes require 3 +1's". You change such things only by consensus or by
> board mandate.
You can assert whatever you want Bill, it has no impact on the situation
at hand. People here weren't even aware of the "right" you seem to have
taken upon, but I'm here to tell you it's a "privilege"- one that can
be taken away by your peers should they agree that it's being abused.
> Greg just finished explaining that only the chair can submit any
> changes to the PMC. Try changing that with a simple majority vote.
Relevance being that I am not empowered to make board-level decisions?
BFD, never claimed the contrary.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 1/31/2012 11:38 AM, Joe Schaefer wrote:
>
> Plainly wrong: It has been repeatedly established (even by the Chair)
> that policy decisions here are not subject to veto. This is one of those times.
> Furthermore the documentation [1] clearly points out that procedural issues
> are to be decided by majority consensus, and nothing could be more procedural
> than a vote about how to count votes.
>
> [1] http://www.apache.org/foundation/voting.html
You assert this is simply policy. I assert that this is a fundamental
to "project bylaws", much like "we don't fork" (if we don't), or "all
votes require 3 +1's". You change such things only by consensus or by
board mandate.
Greg just finished explaining that only the chair can submit any
changes to the PMC. Try changing that with a simple majority vote.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message -----
> From: William A. Rowe Jr. <wr...@rowe-clan.net>
> To: general@incubator.apache.org
> Cc: Joe Schaefer <jo...@yahoo.com>
> Sent: Tuesday, January 31, 2012 12:11 PM
> Subject: Re: [DISCUSS] eliminate vetoes on personnel votes
>
> On 1/30/2012 6:06 PM, Joe Schaefer wrote:
>> It is clear that with all the turmoil of late and people
>> lightly tossing around -1's that the notion of having veto
>> authority over personnel matters makes little sense on this
>> PMC. Therefore I propose we adopt the policy that personnel
>> votes are by straight majority consensus, iow no vetoes allowed.
>>
>> I intend to offer a policy vote on this issue over the coming
>> days and that vote, as with all procedural votes, is NOT subject
>> to veto.
>
> Just FTR; as a proposal to modify a policy/process which requires
> consensus today, your eventual [VOTE] does require consensus to be
> adopted. You can't do an end run around the current policy with
> a simple majority.
Plainly wrong: It has been repeatedly established (even by the Chair)
that policy decisions here are not subject to veto. This is one of those times.
Furthermore the documentation [1] clearly points out that procedural issues
are to be decided by majority consensus, and nothing could be more procedural
than a vote about how to count votes.
[1] http://www.apache.org/foundation/voting.html
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 1/30/2012 6:06 PM, Joe Schaefer wrote:
> It is clear that with all the turmoil of late and people
> lightly tossing around -1's that the notion of having veto
> authority over personnel matters makes little sense on this
> PMC. Therefore I propose we adopt the policy that personnel
> votes are by straight majority consensus, iow no vetoes allowed.
>
> I intend to offer a policy vote on this issue over the coming
> days and that vote, as with all procedural votes, is NOT subject
> to veto.
Just FTR; as a proposal to modify a policy/process which requires
consensus today, your eventual [VOTE] does require consensus to be
adopted. You can't do an end run around the current policy with
a simple majority.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by Christian Grobmeier <gr...@gmail.com>.
On Tue, Jan 31, 2012 at 10:43 AM, Ross Gardler
<rg...@opendirective.com> wrote:
> On 31 January 2012 00:06, Joe Schaefer <jo...@yahoo.com> wrote:
>> It is clear that with all the turmoil of late and people
>> lightly tossing around -1's that the notion of having veto
>> authority over personnel matters makes little sense on this
>> PMC. Therefore I propose we adopt the policy that personnel
>> votes are by straight majority consensus, iow no vetoes allowed.
>>
>> I intend to offer a policy vote on this issue over the coming
>> days and that vote, as with all procedural votes, is NOT subject
>> to veto.
>
> +1 - it has always been my understanding that only code can be vetoed.
+1, I thought that as well.
Cheers
Christian
> Ross
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by Martijn Dashorst <ma...@gmail.com>.
On Tue, Jan 31, 2012 at 10:43 AM, Ross Gardler
<rg...@opendirective.com> wrote:
> On 31 January 2012 00:06, Joe Schaefer <jo...@yahoo.com> wrote:
>> It is clear that with all the turmoil of late and people
>> lightly tossing around -1's that the notion of having veto
>> authority over personnel matters makes little sense on this
>> PMC. Therefore I propose we adopt the policy that personnel
>> votes are by straight majority consensus, iow no vetoes allowed.
>>
>> I intend to offer a policy vote on this issue over the coming
>> days and that vote, as with all procedural votes, is NOT subject
>> to veto.
>
> +1 - it has always been my understanding that only code can be vetoed.
This was my understanding as well. +1 to making it so.
Martijn
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by Ross Gardler <rg...@opendirective.com>.
On 31 January 2012 00:06, Joe Schaefer <jo...@yahoo.com> wrote:
> It is clear that with all the turmoil of late and people
> lightly tossing around -1's that the notion of having veto
> authority over personnel matters makes little sense on this
> PMC. Therefore I propose we adopt the policy that personnel
> votes are by straight majority consensus, iow no vetoes allowed.
>
> I intend to offer a policy vote on this issue over the coming
> days and that vote, as with all procedural votes, is NOT subject
> to veto.
+1 - it has always been my understanding that only code can be vetoed.
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by Chris Douglas <cd...@apache.org>.
+1 -C
On Mon, Jan 30, 2012 at 4:10 PM, Mattmann, Chris A (388J)
<ch...@jpl.nasa.gov> wrote:
> +1 from me.
>
> Sent from my iPhone
>
> On Jan 30, 2012, at 4:07 PM, "Joe Schaefer" <jo...@yahoo.com> wrote:
>
>> It is clear that with all the turmoil of late and people
>> lightly tossing around -1's that the notion of having veto
>> authority over personnel matters makes little sense on this
>> PMC. Therefore I propose we adopt the policy that personnel
>> votes are by straight majority consensus, iow no vetoes allowed.
>>
>> I intend to offer a policy vote on this issue over the coming
>> days and that vote, as with all procedural votes, is NOT subject
>> to veto.
>>
>> Any other rational opinions?
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
+1 from me.
Sent from my iPhone
On Jan 30, 2012, at 4:07 PM, "Joe Schaefer" <jo...@yahoo.com> wrote:
> It is clear that with all the turmoil of late and people
> lightly tossing around -1's that the notion of having veto
> authority over personnel matters makes little sense on this
> PMC. Therefore I propose we adopt the policy that personnel
> votes are by straight majority consensus, iow no vetoes allowed.
>
> I intend to offer a policy vote on this issue over the coming
> days and that vote, as with all procedural votes, is NOT subject
> to veto.
>
> Any other rational opinions?
>
>
> ---------------------------------------------------------------------
> 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: [DISCUSS] eliminate vetoes on personnel votes
Posted by ant elder <an...@gmail.com>.
On Tue, Jan 31, 2012 at 5:18 PM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Tue, Jan 31, 2012 at 1:06 AM, Joe Schaefer <jo...@yahoo.com> wrote:
>> Any other rational opinions?
>
> I don't recall a case where a candidate was not elected because of an
> unnecessarily strict -1. All I'm seeing now is abstract discussion
> about hypothetical votes and a lot of hot air.
>
> I'd go for a policy vote only once there's a concrete case (i.e. a
> failed vote) where progress is being obstructed by reasons that the
> majority finds unreasonable.
>
> BR,
>
> Jukka Zitting
+1 to that.
I'd really like this flood of emails to stop, i've not read many since
last week, can't you all take a break? If some policy is being changed
can't it wait a few weeks till a quieter time so it really getting the
proper attention of PMC members?
...ant
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, Jan 31, 2012 at 6:43 PM, Joe Schaefer <jo...@yahoo.com> wrote:
> There are currently 29 outstanding no votes made on
> a discussion thread merely for the fact that those
> candidates names were listed.
I count those as votes once I see them in an actual VOTE thread. We've
had similar VOTEs earlier, the last one passing just a few days ago,
and I haven't seen a -1 on them so I don't see much of a problem yet.
> There is currently a -1 on a current vote thread there
> as well.
Indeed there is! I stand corrected. Sorry for missing that one.
Assuming that vote indeed fails, the case for re-evaluating policy
gets much stronger. I'd question though, is it then better to change
the voting rules, or rather to clarify the responsibilities expected
of IPMC members?
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by Joe Schaefer <jo...@yahoo.com>.
There are currently 29 outstanding no votes made on
a discussion thread merely for the fact that those
candidates names were listed. Are you not reading
private@incubator?
There is currently a -1 on a current vote thread there
as well.
----- Original Message -----
> From: Jukka Zitting <ju...@gmail.com>
> To: general <ge...@incubator.apache.org>
> Cc:
> Sent: Tuesday, January 31, 2012 12:18 PM
> Subject: Re: [DISCUSS] eliminate vetoes on personnel votes
>
> Hi,
>
> On Tue, Jan 31, 2012 at 1:06 AM, Joe Schaefer <jo...@yahoo.com>
> wrote:
>> Any other rational opinions?
>
> I don't recall a case where a candidate was not elected because of an
> unnecessarily strict -1. All I'm seeing now is abstract discussion
> about hypothetical votes and a lot of hot air.
>
> I'd go for a policy vote only once there's a concrete case (i.e. a
> failed vote) where progress is being obstructed by reasons that the
> majority finds unreasonable.
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> 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: [DISCUSS] eliminate vetoes on personnel votes
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Jan 31, 2012 at 12:18, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Tue, Jan 31, 2012 at 1:06 AM, Joe Schaefer <jo...@yahoo.com> wrote:
>> Any other rational opinions?
>
> I don't recall a case where a candidate was not elected because of an
> unnecessarily strict -1. All I'm seeing now is abstract discussion
> about hypothetical votes and a lot of hot air.
>
> I'd go for a policy vote only once there's a concrete case (i.e. a
> failed vote) where progress is being obstructed by reasons that the
> majority finds unreasonable.
Unfortunately, that is usually a poor approach. One person needs to
raise the "policy change" request, and that invariably ends up looking
like "one person who is upset with the result". That person will
either stay quiet, or may be alienated by their request. I think it is
always best to settle these things *before* putting somebody in the
position of having to be the Bad Guy and (apparently) question/attack
a vote result.
I think this has been a very useful discussion. I've already seen some
emails (a couple private) of people surprised that a PMC nomination
could even be vetoed. That Joe's suggestion is an actual change from
what they expected. Thus... we have some good clarification on
precedent, what may be good practice, and what (specifically) the IPMC
may want to do.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, Jan 31, 2012 at 1:06 AM, Joe Schaefer <jo...@yahoo.com> wrote:
> Any other rational opinions?
I don't recall a case where a candidate was not elected because of an
unnecessarily strict -1. All I'm seeing now is abstract discussion
about hypothetical votes and a lot of hot air.
I'd go for a policy vote only once there's a concrete case (i.e. a
failed vote) where progress is being obstructed by reasons that the
majority finds unreasonable.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Jan 30, 2012 at 23:53, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> On Jan 30, 2012, at 4:06 PM, Joe Schaefer wrote:
>> It is clear that with all the turmoil of late and people
>> lightly tossing around -1's that the notion of having veto
>> authority over personnel matters makes little sense on this
>> PMC. Therefore I propose we adopt the policy that personnel
>> votes are by straight majority consensus, iow no vetoes allowed.
>>
>> I intend to offer a policy vote on this issue over the coming
>> days and that vote, as with all procedural votes, is NOT subject
>> to veto.
>
> Seems like a good idea.
>
> I did't realize that -1 votes were vetoes on such matters. I think that a -1 should carry the weight of a veto in the eyes of fellow peers such that a consensus would be sought. If both sides agree to disagree then the tally proceeds.
This is how we operate in the Apache Subversion project. It is usually
couched as "let's wait a bit [with explanation]" rather than the
negative-connotation of a "-1". But the point is that if there is
somebody a bit worried, then the discussion turns to "okay. what is
the concern? cool. let's watch for that to be remedied, and discuss
again."
The short answer is that in the Subversion project, we go for
*consensus* rather than strict voting rules.
IMO, this also models the Board's approach. If there is a discussion
or a concern, then the Board typically tables a vote. Looking at
history, there are *very* few cases where the Board has not voted
unanimously. We defer the vote and continue discussion, then come back
at the next meeting for a vote. For those non-unanimous votes, the
results have been mixed; so... lately (heh. years), my view has always
been "table" rather than push through a contentious vote.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jan 30, 2012, at 4:06 PM, Joe Schaefer wrote:
> It is clear that with all the turmoil of late and people
> lightly tossing around -1's that the notion of having veto
> authority over personnel matters makes little sense on this
> PMC. Therefore I propose we adopt the policy that personnel
> votes are by straight majority consensus, iow no vetoes allowed.
>
> I intend to offer a policy vote on this issue over the coming
> days and that vote, as with all procedural votes, is NOT subject
> to veto.
Seems like a good idea.
I did't realize that -1 votes were vetoes on such matters. I think that a -1 should carry the weight of a veto in the eyes of fellow peers such that a consensus would be sought. If both sides agree to disagree then the tally proceeds.
> Any other rational opinions?
As opposed to any other type of opinions? Really, I am getting quite tired of your loaded statements.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jan 30, 2012, at 5:41 PM, Joe Schaefer wrote:
> This is getting sillier by the moment...
I don't care for these kinds of statements. Please try to keep the conversation civil.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 1/30/2012 7:41 PM, Joe Schaefer wrote:
> Lemme get this straight: a person who makes a class-action
> veto against a whole swath of people should have those votes
> upheld to protect that person from the tyranny of the majority?
No. Joe, take a break. Then come back, and reread both threads,
and do the math. I proposed no such thing, in fact my proposal
argues against exactly that sort of thing; allow a supermajority
to prevent against both abuses.
Your hostility is not helping the incubator or your desired goals.
You might use some time afk.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by Joe Schaefer <jo...@yahoo.com>.
Lemme get this straight: a person who makes a class-action
veto against a whole swath of people should have those votes
upheld to protect that person from the tyranny of the majority?
This is getting sillier by the moment...
----- Original Message -----
> From: William A. Rowe Jr. <wr...@rowe-clan.net>
> To: general@incubator.apache.org
> Cc: Joe Schaefer <jo...@yahoo.com>
> Sent: Monday, January 30, 2012 8:34 PM
> Subject: Re: [DISCUSS] eliminate vetoes on personnel votes
>
> On 1/30/2012 6:06 PM, Joe Schaefer wrote:
>> It is clear that with all the turmoil of late and people
>> lightly tossing around -1's that the notion of having veto
>> authority over personnel matters makes little sense on this
>> PMC. Therefore I propose we adopt the policy that personnel
>> votes are by straight majority consensus, iow no vetoes allowed.
>
> -1
>
> The argument is very simple, you don't allow a simple majority to
> tyrannize the minority. So the ASF has long held a simple standard
> of consensus on all committee additions and subtractions. Some
> majority might be irked at [insert name here]'s [actions|inaction|
> comments|silence] but that was never grounds to remove a committee
> member. If you want to propose some supermajority metric other than
> "unanimous", that could work (e.g. 2/3 or 3/4 in agreement).
>
> ---------------------------------------------------------------------
> 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: [DISCUSS] eliminate vetoes on personnel votes
Posted by Dave Fisher <da...@comcast.net>.
Sent from my iPhone
On Jan 30, 2012, at 7:47 PM, "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
> On 1/30/2012 7:44 PM, Dave Fisher wrote:
>>
>>
>> Sent from my iPhone
>>
>> On Jan 30, 2012, at 5:34 PM, "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
>>
>>> On 1/30/2012 6:06 PM, Joe Schaefer wrote:
>>>> It is clear that with all the turmoil of late and people
>>>> lightly tossing around -1's that the notion of having veto
>>>> authority over personnel matters makes little sense on this
>>>> PMC. Therefore I propose we adopt the policy that personnel
>>>> votes are by straight majority consensus, iow no vetoes allowed.
>>>
>>> -1
>>>
>>> The argument is very simple, you don't allow a simple majority to
>>> tyrannize the minority. So the ASF has long held a simple standard
>>> of consensus on all committee additions and subtractions. Some
>>> majority might be irked at [insert name here]'s [actions|inaction|
>>> comments|silence] but that was never grounds to remove a committee
>>> member. If you want to propose some supermajority metric other than
>>> "unanimous", that could work (e.g. 2/3 or 3/4 in agreement
>>
>> In your plan then a -1 is really a -2 or -3?
>>
>> Sounds like a filibuster...
>
> No, I'm -1 to this proposal. I'd support his proposal if it were
> modified to provide for a measurable super-majority consensus.
>
When you have supermajorities then 2/3 means each -1 carries 2x the weight. Ok? We agree we are just using different math,
Regards,
Dave
>
>
> ---------------------------------------------------------------------
> 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: [DISCUSS] eliminate vetoes on personnel votes
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Jan 31, 2012 at 13:20, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Greg Stein wrote on Tue, Jan 31, 2012 at 12:12:50 -0500:
>> In that light, we're talking about "what kinds of voting results
>> should be forwarded by the Chair?" If the Chair sends a request to the
>> Board to add somebody and reports "5 +1 votes, 2 -1 votes"... would
>> that be sufficient? 2/3rds or 3/4ths doesn't really matter. The Board
>> is going to investigate the consensus and what is going on behind
>> those negative votes.
>
> "Investigate"? Isn't it going to tell the PMC to decide whether or not
> they are recommending the addition of the person?
Typically, when there are negative votes, the Board will try to figure
out what is going on. The PMC (obviously) has not made up its mind as
a whole. The votes may be normal, everyday concerns against
membership, but it can signal more than that.
To put it another way: votes that reach the Board are typically
unanimous. Thus, if a vote is *not* unanimous, something funny is
going on and should be looked at.
If you have a jackass blocking nominations, then the Board will ACK
the addition. If there are real concerns, then the Board will hold up.
[something like that; obviously, I don't speak for the entire Board;
I'm offering my predictions of behavior based on my own vote, and what
I believe the other Directors would do]
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Greg Stein wrote on Tue, Jan 31, 2012 at 12:12:50 -0500:
> In that light, we're talking about "what kinds of voting results
> should be forwarded by the Chair?" If the Chair sends a request to the
> Board to add somebody and reports "5 +1 votes, 2 -1 votes"... would
> that be sufficient? 2/3rds or 3/4ths doesn't really matter. The Board
> is going to investigate the consensus and what is going on behind
> those negative votes.
"Investigate"? Isn't it going to tell the PMC to decide whether or not
they are recommending the addition of the person?
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 1/31/2012 11:12 AM, Greg Stein wrote:
>
> I'm a little unclear on wrowe's original message talking about
> "supermajority" and whether that was for *addition* or for *removal*.
> I'm assuming that it was only about addition because I've never seen
> any PMC-based ejection of a PMC member. The Board has wiped out PMC
> rosters before, but I really don't foresee any need to discuss (here)
> "rules" around removal.
>
> So we're only talking about addition.
Talk about what you want. The subject line was clearly inclusive of
all.
> Please remember that these are *recommendations* to the Board. In
> effect, there is really no such thing as a "veto", except that a Chair
> may simply refuse to send a request to the Board for the addition when
> a -1 appears. (and note the Board could do an end-around anyways and
> simply put that person on the PMC regardless of the vote/Chair(!))
Right right... this is only binding on "committee recommendation" which
is then subject to the decision of the chair which is then subject to
the decisions of the board, yadda yadda.
> In that light, we're talking about "what kinds of voting results
> should be forwarded by the Chair?" If the Chair sends a request to the
> Board to add somebody and reports "5 +1 votes, 2 -1 votes"... would
> that be sufficient? 2/3rds or 3/4ths doesn't really matter. The Board
> is going to investigate the consensus and what is going on behind
> those negative votes.
>
> Shoot. If the Chair doesn't forward that result, somebody else could
> forward it with "hey. we think $JOHN should be on the PMC, but the
> Chair isn't forwarding cuz of these negative votes." Bang. Again, an
> inspection results.
Good points.
> I think the short answer gets back to Joe's suggestion (and my
> concurrence): simply allow for a majority vote; forward that to the
> Board; let them decide.
>
> Keep it simple. "Rules" don't matter much when you're talking about
> forwarding recommendations to the Board.
Ok, let's keep it concensus, if you want to keep it anything.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Jan 31, 2012 at 11:58, Mattmann, Chris A (388J)
<ch...@jpl.nasa.gov> wrote:
> Hi Guys,
>
> On Jan 31, 2012, at 1:17 AM, Emmanuel Lecharny wrote:
>>>>
>>> Oh, so you want a supermajority in terms of those who have voted, not in
>>> terms of the membership of the IPMC? Not unreasonable. Let's see what
>>> others think.
>>
>> I would easily +1 a proposal with a 3/4 majority of the *voters*.
>
> +1 I'm fine with this compromise.
I'm a little unclear on wrowe's original message talking about
"supermajority" and whether that was for *addition* or for *removal*.
I'm assuming that it was only about addition because I've never seen
any PMC-based ejection of a PMC member. The Board has wiped out PMC
rosters before, but I really don't foresee any need to discuss (here)
"rules" around removal.
So we're only talking about addition.
Please remember that these are *recommendations* to the Board. In
effect, there is really no such thing as a "veto", except that a Chair
may simply refuse to send a request to the Board for the addition when
a -1 appears. (and note the Board could do an end-around anyways and
simply put that person on the PMC regardless of the vote/Chair(!))
In that light, we're talking about "what kinds of voting results
should be forwarded by the Chair?" If the Chair sends a request to the
Board to add somebody and reports "5 +1 votes, 2 -1 votes"... would
that be sufficient? 2/3rds or 3/4ths doesn't really matter. The Board
is going to investigate the consensus and what is going on behind
those negative votes.
Shoot. If the Chair doesn't forward that result, somebody else could
forward it with "hey. we think $JOHN should be on the PMC, but the
Chair isn't forwarding cuz of these negative votes." Bang. Again, an
inspection results.
I think the short answer gets back to Joe's suggestion (and my
concurrence): simply allow for a majority vote; forward that to the
Board; let them decide.
Keep it simple. "Rules" don't matter much when you're talking about
forwarding recommendations to the Board.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Guys,
On Jan 31, 2012, at 1:17 AM, Emmanuel Lecharny wrote:
>>>
>> Oh, so you want a supermajority in terms of those who have voted, not in
>> terms of the membership of the IPMC? Not unreasonable. Let's see what
>> others think.
>
> I would easily +1 a proposal with a 3/4 majority of the *voters*.
+1 I'm fine with this compromise.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 1/31/12 3:06 AM, Joe Schaefer wrote:
> ----- Original Message -----
>
>> From: William A. Rowe Jr.<wr...@rowe-clan.net>
>> To: general@incubator.apache.org
>> Cc:
>> Sent: Monday, January 30, 2012 9:01 PM
>> Subject: Re: [DISCUSS] eliminate vetoes on personnel votes
>>
>> On 1/30/2012 7:51 PM, Joe Schaefer wrote:
>>> ----- Original Message -----
>>>
>>>> From: William A. Rowe Jr.<wr...@rowe-clan.net>
>>>> To: general@incubator.apache.org
>>>> Cc:
>>>> Sent: Monday, January 30, 2012 8:47 PM
>>>> Subject: Re: [DISCUSS] eliminate vetoes on personnel votes
>>>>
>>>> On 1/30/2012 7:44 PM, Dave Fisher wrote:
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Jan 30, 2012, at 5:34 PM, "William A. Rowe Jr."
>>>> <wr...@rowe-clan.net> wrote:
>>>>>> On 1/30/2012 6:06 PM, Joe Schaefer wrote:
>>>>>>> It is clear that with all the turmoil of late and people
>>>>>>> lightly tossing around -1's that the notion of having
>> veto
>>>>>>> authority over personnel matters makes little sense on
>> this
>>>>>>> PMC. Therefore I propose we adopt the policy that
>> personnel
>>>>>>> votes are by straight majority consensus, iow no vetoes
>> allowed.
>>>>>> -1
>>>>>>
>>>>>> The argument is very simple, you don't allow a simple
>> majority to
>>>>>> tyrannize the minority. So the ASF has long held a simple
>> standard
>>>>>> of consensus on all committee additions and subtractions.
>> Some
>>>>>> majority might be irked at [insert name here]'s
>> [actions|inaction|
>>>>>> comments|silence] but that was never grounds to remove a
>> committee
>>>>>> member. If you want to propose some supermajority metric
>> other than
>>>>>> "unanimous", that could work (e.g. 2/3 or 3/4 in
>> agreement
>>>>> In your plan then a -1 is really a -2 or -3?
>>>>>
>>>>> Sounds like a filibuster...
>>>> No, I'm -1 to this proposal. I'd support his proposal if it
>> were
>>>> modified to provide for a measurable super-majority consensus.
>>> Define supermajority in a way that isn't patently absurd and perhaps
>>> I'll consider amending it.
>> 2/3. 3/4. Take your pick. I'd argue on the high end. Consider that
>> to defeat a 3/4 supermajority consisting of 9 votes requires more than
>> 2 people against. This committee has an order of magnitude more voters.
>> Simple obstructionism is easy to deal with.
> Oh, so you want a supermajority in terms of those who have voted, not in
> terms of the membership of the IPMC? Not unreasonable. Let's see what
> others think.
I would easily +1 a proposal with a 3/4 majority of the *voters*.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jan 30, 2012, at 6:06 PM, Joe Schaefer wrote:
> ----- Original Message -----
>
>> From: William A. Rowe Jr. <wr...@rowe-clan.net>
>> To: general@incubator.apache.org
>> Cc:
>> Sent: Monday, January 30, 2012 9:01 PM
>> Subject: Re: [DISCUSS] eliminate vetoes on personnel votes
>>
>> On 1/30/2012 7:51 PM, Joe Schaefer wrote:
>>> ----- Original Message -----
>>>
>>>> From: William A. Rowe Jr. <wr...@rowe-clan.net>
>>>> To: general@incubator.apache.org
>>>> Cc:
>>>> Sent: Monday, January 30, 2012 8:47 PM
>>>> Subject: Re: [DISCUSS] eliminate vetoes on personnel votes
>>>>
>>>> On 1/30/2012 7:44 PM, Dave Fisher wrote:
>>>>>
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Jan 30, 2012, at 5:34 PM, "William A. Rowe Jr."
>>>> <wr...@rowe-clan.net> wrote:
>>>>>
>>>>>> On 1/30/2012 6:06 PM, Joe Schaefer wrote:
>>>>>>> It is clear that with all the turmoil of late and people
>>>>>>> lightly tossing around -1's that the notion of having
>> veto
>>>>>>> authority over personnel matters makes little sense on
>> this
>>>>>>> PMC. Therefore I propose we adopt the policy that
>> personnel
>>>>>>> votes are by straight majority consensus, iow no vetoes
>> allowed.
>>>>>>
>>>>>> -1
>>>>>>
>>>>>> The argument is very simple, you don't allow a simple
>> majority to
>>>>>> tyrannize the minority. So the ASF has long held a simple
>> standard
>>>>>> of consensus on all committee additions and subtractions.
>> Some
>>>>>> majority might be irked at [insert name here]'s
>> [actions|inaction|
>>>>>> comments|silence] but that was never grounds to remove a
>> committee
>>>>>> member. If you want to propose some supermajority metric
>> other than
>>>>>> "unanimous", that could work (e.g. 2/3 or 3/4 in
>> agreement
>>>>>
>>>>> In your plan then a -1 is really a -2 or -3?
>>>>>
>>>>> Sounds like a filibuster...
>>>>
>>>> No, I'm -1 to this proposal. I'd support his proposal if it
>> were
>>>> modified to provide for a measurable super-majority consensus.
>>>
>>> Define supermajority in a way that isn't patently absurd and perhaps
>>> I'll consider amending it.
>>
>> 2/3. 3/4. Take your pick. I'd argue on the high end. Consider that
>> to defeat a 3/4 supermajority consisting of 9 votes requires more than
>> 2 people against. This committee has an order of magnitude more voters.
>> Simple obstructionism is easy to deal with.
>
> Oh, so you want a supermajority in terms of those who have voted, not in
> terms of the membership of the IPMC? Not unreasonable. Let's see what
> others think.
Seems reasonable to me as well.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message -----
> From: William A. Rowe Jr. <wr...@rowe-clan.net>
> To: general@incubator.apache.org
> Cc:
> Sent: Monday, January 30, 2012 9:01 PM
> Subject: Re: [DISCUSS] eliminate vetoes on personnel votes
>
> On 1/30/2012 7:51 PM, Joe Schaefer wrote:
>> ----- Original Message -----
>>
>>> From: William A. Rowe Jr. <wr...@rowe-clan.net>
>>> To: general@incubator.apache.org
>>> Cc:
>>> Sent: Monday, January 30, 2012 8:47 PM
>>> Subject: Re: [DISCUSS] eliminate vetoes on personnel votes
>>>
>>> On 1/30/2012 7:44 PM, Dave Fisher wrote:
>>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Jan 30, 2012, at 5:34 PM, "William A. Rowe Jr."
>>> <wr...@rowe-clan.net> wrote:
>>>>
>>>>> On 1/30/2012 6:06 PM, Joe Schaefer wrote:
>>>>>> It is clear that with all the turmoil of late and people
>>>>>> lightly tossing around -1's that the notion of having
> veto
>>>>>> authority over personnel matters makes little sense on
> this
>>>>>> PMC. Therefore I propose we adopt the policy that
> personnel
>>>>>> votes are by straight majority consensus, iow no vetoes
> allowed.
>>>>>
>>>>> -1
>>>>>
>>>>> The argument is very simple, you don't allow a simple
> majority to
>>>>> tyrannize the minority. So the ASF has long held a simple
> standard
>>>>> of consensus on all committee additions and subtractions.
> Some
>>>>> majority might be irked at [insert name here]'s
> [actions|inaction|
>>>>> comments|silence] but that was never grounds to remove a
> committee
>>>>> member. If you want to propose some supermajority metric
> other than
>>>>> "unanimous", that could work (e.g. 2/3 or 3/4 in
> agreement
>>>>
>>>> In your plan then a -1 is really a -2 or -3?
>>>>
>>>> Sounds like a filibuster...
>>>
>>> No, I'm -1 to this proposal. I'd support his proposal if it
> were
>>> modified to provide for a measurable super-majority consensus.
>>
>> Define supermajority in a way that isn't patently absurd and perhaps
>> I'll consider amending it.
>
> 2/3. 3/4. Take your pick. I'd argue on the high end. Consider that
> to defeat a 3/4 supermajority consisting of 9 votes requires more than
> 2 people against. This committee has an order of magnitude more voters.
> Simple obstructionism is easy to deal with.
Oh, so you want a supermajority in terms of those who have voted, not in
terms of the membership of the IPMC? Not unreasonable. Let's see what
others think.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 1/30/2012 7:51 PM, Joe Schaefer wrote:
> ----- Original Message -----
>
>> From: William A. Rowe Jr. <wr...@rowe-clan.net>
>> To: general@incubator.apache.org
>> Cc:
>> Sent: Monday, January 30, 2012 8:47 PM
>> Subject: Re: [DISCUSS] eliminate vetoes on personnel votes
>>
>> On 1/30/2012 7:44 PM, Dave Fisher wrote:
>>>
>>>
>>> Sent from my iPhone
>>>
>>> On Jan 30, 2012, at 5:34 PM, "William A. Rowe Jr."
>> <wr...@rowe-clan.net> wrote:
>>>
>>>> On 1/30/2012 6:06 PM, Joe Schaefer wrote:
>>>>> It is clear that with all the turmoil of late and people
>>>>> lightly tossing around -1's that the notion of having veto
>>>>> authority over personnel matters makes little sense on this
>>>>> PMC. Therefore I propose we adopt the policy that personnel
>>>>> votes are by straight majority consensus, iow no vetoes allowed.
>>>>
>>>> -1
>>>>
>>>> The argument is very simple, you don't allow a simple majority to
>>>> tyrannize the minority. So the ASF has long held a simple standard
>>>> of consensus on all committee additions and subtractions. Some
>>>> majority might be irked at [insert name here]'s [actions|inaction|
>>>> comments|silence] but that was never grounds to remove a committee
>>>> member. If you want to propose some supermajority metric other than
>>>> "unanimous", that could work (e.g. 2/3 or 3/4 in agreement
>>>
>>> In your plan then a -1 is really a -2 or -3?
>>>
>>> Sounds like a filibuster...
>>
>> No, I'm -1 to this proposal. I'd support his proposal if it were
>> modified to provide for a measurable super-majority consensus.
>
> Define supermajority in a way that isn't patently absurd and perhaps
> I'll consider amending it.
2/3. 3/4. Take your pick. I'd argue on the high end. Consider that
to defeat a 3/4 supermajority consisting of 9 votes requires more than
2 people against. This committee has an order of magnitude more voters.
Simple obstructionism is easy to deal with.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message -----
> From: William A. Rowe Jr. <wr...@rowe-clan.net>
> To: general@incubator.apache.org
> Cc:
> Sent: Monday, January 30, 2012 8:47 PM
> Subject: Re: [DISCUSS] eliminate vetoes on personnel votes
>
> On 1/30/2012 7:44 PM, Dave Fisher wrote:
>>
>>
>> Sent from my iPhone
>>
>> On Jan 30, 2012, at 5:34 PM, "William A. Rowe Jr."
> <wr...@rowe-clan.net> wrote:
>>
>>> On 1/30/2012 6:06 PM, Joe Schaefer wrote:
>>>> It is clear that with all the turmoil of late and people
>>>> lightly tossing around -1's that the notion of having veto
>>>> authority over personnel matters makes little sense on this
>>>> PMC. Therefore I propose we adopt the policy that personnel
>>>> votes are by straight majority consensus, iow no vetoes allowed.
>>>
>>> -1
>>>
>>> The argument is very simple, you don't allow a simple majority to
>>> tyrannize the minority. So the ASF has long held a simple standard
>>> of consensus on all committee additions and subtractions. Some
>>> majority might be irked at [insert name here]'s [actions|inaction|
>>> comments|silence] but that was never grounds to remove a committee
>>> member. If you want to propose some supermajority metric other than
>>> "unanimous", that could work (e.g. 2/3 or 3/4 in agreement
>>
>> In your plan then a -1 is really a -2 or -3?
>>
>> Sounds like a filibuster...
>
> No, I'm -1 to this proposal. I'd support his proposal if it were
> modified to provide for a measurable super-majority consensus.
Define supermajority in a way that isn't patently absurd and perhaps
I'll consider amending it.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 1/30/2012 7:44 PM, Dave Fisher wrote:
>
>
> Sent from my iPhone
>
> On Jan 30, 2012, at 5:34 PM, "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
>
>> On 1/30/2012 6:06 PM, Joe Schaefer wrote:
>>> It is clear that with all the turmoil of late and people
>>> lightly tossing around -1's that the notion of having veto
>>> authority over personnel matters makes little sense on this
>>> PMC. Therefore I propose we adopt the policy that personnel
>>> votes are by straight majority consensus, iow no vetoes allowed.
>>
>> -1
>>
>> The argument is very simple, you don't allow a simple majority to
>> tyrannize the minority. So the ASF has long held a simple standard
>> of consensus on all committee additions and subtractions. Some
>> majority might be irked at [insert name here]'s [actions|inaction|
>> comments|silence] but that was never grounds to remove a committee
>> member. If you want to propose some supermajority metric other than
>> "unanimous", that could work (e.g. 2/3 or 3/4 in agreement
>
> In your plan then a -1 is really a -2 or -3?
>
> Sounds like a filibuster...
No, I'm -1 to this proposal. I'd support his proposal if it were
modified to provide for a measurable super-majority consensus.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by Dave Fisher <da...@comcast.net>.
Sent from my iPhone
On Jan 30, 2012, at 5:34 PM, "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
> On 1/30/2012 6:06 PM, Joe Schaefer wrote:
>> It is clear that with all the turmoil of late and people
>> lightly tossing around -1's that the notion of having veto
>> authority over personnel matters makes little sense on this
>> PMC. Therefore I propose we adopt the policy that personnel
>> votes are by straight majority consensus, iow no vetoes allowed.
>
> -1
>
> The argument is very simple, you don't allow a simple majority to
> tyrannize the minority. So the ASF has long held a simple standard
> of consensus on all committee additions and subtractions. Some
> majority might be irked at [insert name here]'s [actions|inaction|
> comments|silence] but that was never grounds to remove a committee
> member. If you want to propose some supermajority metric other than
> "unanimous", that could work (e.g. 2/3 or 3/4 in agreement
In your plan then a -1 is really a -2 or -3?
Sounds like a filibuster...
Regards,
Dave
>
> ---------------------------------------------------------------------
> 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: [DISCUSS] eliminate vetoes on personnel votes
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 1/30/2012 6:06 PM, Joe Schaefer wrote:
> It is clear that with all the turmoil of late and people
> lightly tossing around -1's that the notion of having veto
> authority over personnel matters makes little sense on this
> PMC. Therefore I propose we adopt the policy that personnel
> votes are by straight majority consensus, iow no vetoes allowed.
-1
The argument is very simple, you don't allow a simple majority to
tyrannize the minority. So the ASF has long held a simple standard
of consensus on all committee additions and subtractions. Some
majority might be irked at [insert name here]'s [actions|inaction|
comments|silence] but that was never grounds to remove a committee
member. If you want to propose some supermajority metric other than
"unanimous", that could work (e.g. 2/3 or 3/4 in agreement).
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by Christian Grobmeier <gr...@gmail.com>.
On Tue, Jan 31, 2012 at 9:52 PM, Doug Cutting <cu...@apache.org> wrote:
> On 01/30/2012 05:12 PM, Greg Stein wrote:
>> I've never liked vetoes for this. One person can hold an entire PMC hostage
>> simply for disliking someone (or worse: subtle corporate concerns masked
>> otherwise). People have said in the past, "you should have veto so you're
>> not forced to work with somebody you dislike." I respond, "grow up. we work
>> with annoying people all the time, and the majority says they *can* work
>
> When this question came up in another context, Roy's concern, as I
> recall it, was something to the effect that if you don't allow vetoes of
> proposed PMC members then you might create a dysfunctional PMC.
Interesting. Reading this I think "joining a pmc on request" is not
good and adding people to a pmc just they can have binding votes is
not good aswell.
> (Roy,
> please correct me if I miss-recall.) A PMC needs to regularly reach
> consensus. If person X has technical ideas that are incompatible with
> person Y then perhaps they should not be on the same PMC. At least
> that's the way I recall Roy's argument...
>
> Also note that if you get to the point where one person is vetoing a PMC
> addition then the rest of the PMC could vote to remove that one person.
> A veto is effectively asking the PMC to choose between you and the new
> person, a strident move.
>
> A less confrontational approach is to have a discussion before any vote,
> where folks can air their concerns. If folks voice significant concerns
> then it might not be wise to hold a vote.
>
> Finally I'll observe that if supermajority would result in a different
> result than consensus then the PMC probably has serious problems
> collaborating that need to be fixed.
> Doug
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by "William A. Rowe Jr." <wr...@apache.org>.
On 1/31/2012 3:28 PM, Roy T. Fielding wrote:
>
> Having said that, I should note that the context of Incubator is
> significantly different than a normal PMC. If incubator wants to structure
> itself more like a board and less like a project, I really don't have
> much to say against that. Note that it should effect all of the decision
> guidelines that give veto power, not just personnel decisions.
That touched on something. The incubator is a meta-committee. It is
entrusted with and given more latitude to operate subprojects even as
the board has attempted to squash or at least minimize the practice
at other projects. Probably every issue that happened at Jakarta (etc)
all could and probably will happen here at some point.
Is there latitude to assign PPMC's full and proper subcommittee status,
such that their actions are binding?
Perhaps this is something that happens later in the project, following
the initial phase of incubation. Perhaps the PPMC is charged with
bootstrapping itself into a subcommittee consisting of those who will
serve at the TLP committee; modulo early signers-on who had not made
any actual contribution during incubation. Perhaps the mentors become
pivotal in identifying those PPMC participants who made contributions
and proposing the subcommittee to the IPMC?
So you have an almost-TLP, still operating under the oversight of the
incubator, until the final incubation requirements are met and the
subcommittee is passed on verbatim to the board as a TLP.
This would seem to solve certain desires for more PPMC autonomy and
self-governance.
Back to Roy's point, the incubator PMC produces almost no code. It
is not a TLP in any sense of the word we know, although that seems to
be lost or ignored in several discussions about incubator operation.
But a subcommittee would have the onus of operating as a familiar
code-producing TLP PMC in every respect.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by Donald Whytock <dw...@gmail.com>.
May I suggest bumping thoughts of cashiering the incubator to its own
thread? It seems a much bigger question than whether to prevent
vetoes on PPMC membership votes.
Don
On Tue, Jan 31, 2012 at 6:21 PM, William A. Rowe Jr. <wr...@apache.org> wrote:
> On 1/31/2012 5:05 PM, Mattmann, Chris A (388J) wrote:
>>
>> In replacement, I propose the following concrete actions:
>>
>> 1. Move the Incubator process/policy/documentation, etc., to ComDev - I
>> agree with gstein on this. I think it could be maintained by the ASF community
>> folks there, and updated over time. But it's not vastly or rapidly changing really
>> anymore.
>>
>> 2. Discharge the Incubator PMC and the role of Incubator VP -- pat everyone on
>> the back, go have a beer, watch the big game together, whatever. Call it a
>> success, not a failure.
>>
>> 3. Suggest at the board level that an Incubation "process" still exists at Apache,
>> in the same way that it exists today. New projects write a proposal, the proposal
>> is VOTEd on by the board at the board's next monthly meeting, and those
>> that cannot be are QUEUED for the next meeting, or VOTEd on during out of
>> board inbetween time on board@. Refer those wanting to "Incubate" at Apache
>> to the existing Incubator documentation maintained by the ComDev community.
>> Tell them to ask questions there, about the process, about what to do, or if
>> ideas make sense. But *not* to VOTE on whether they are accepted or not.
>
> Note that at the time the incubator was created, there was no particular
> process. Projects entered the ASF helter-skelter, without really following
> any template.
>
> Also, the legal committee was not a resource, comdev was not a resource,
> trademarks was not a resource, press was not a resource.
>
> I think it's sort of silly to suggest that resource needs are completely
> isolated to either incubating efforts, or TLP efforts.
>
> So the question is, what does the incubator provide today that should be
> persisted as a resource to any incubating or full project? Obviously,
> mentorship; but comdev seems like a really good home for that.
>
>
> ---------------------------------------------------------------------
> 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: [DISCUSS] eliminate vetoes on personnel votes
Posted by "William A. Rowe Jr." <wr...@apache.org>.
On 1/31/2012 5:05 PM, Mattmann, Chris A (388J) wrote:
>
> In replacement, I propose the following concrete actions:
>
> 1. Move the Incubator process/policy/documentation, etc., to ComDev - I
> agree with gstein on this. I think it could be maintained by the ASF community
> folks there, and updated over time. But it's not vastly or rapidly changing really
> anymore.
>
> 2. Discharge the Incubator PMC and the role of Incubator VP -- pat everyone on
> the back, go have a beer, watch the big game together, whatever. Call it a
> success, not a failure.
>
> 3. Suggest at the board level that an Incubation "process" still exists at Apache,
> in the same way that it exists today. New projects write a proposal, the proposal
> is VOTEd on by the board at the board's next monthly meeting, and those
> that cannot be are QUEUED for the next meeting, or VOTEd on during out of
> board inbetween time on board@. Refer those wanting to "Incubate" at Apache
> to the existing Incubator documentation maintained by the ComDev community.
> Tell them to ask questions there, about the process, about what to do, or if
> ideas make sense. But *not* to VOTE on whether they are accepted or not.
Note that at the time the incubator was created, there was no particular
process. Projects entered the ASF helter-skelter, without really following
any template.
Also, the legal committee was not a resource, comdev was not a resource,
trademarks was not a resource, press was not a resource.
I think it's sort of silly to suggest that resource needs are completely
isolated to either incubating efforts, or TLP efforts.
So the question is, what does the incubator provide today that should be
persisted as a resource to any incubating or full project? Obviously,
mentorship; but comdev seems like a really good home for that.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 2/1/2012 4:52 PM, Benson Margulies wrote:
> At the risk of seeming trite, +1, but ...
>
> This lengthy proposal shifts the supervision responsibility of
> podlings from an big IPMC to a set of mentors approved by the board at
> the advice of a small iPMC.
No. Forget IPMC. The VP, Project Incubation and their committee doesn't
advise, the members as a whole do, and propose the initial list of mentors.
general@ doesn't change, it's still the place for 'me, too!' offers to
mentor an incoming proposal. But yes, that set of mentors provides the
initial guidance to the project and is responsible for reporting to the
board. As a board reporting committee, the board too also has supervision
based on those reports. One thing that does not change; every ASF member
has oversight privilage over most every private list at the ASF, including
our current PPMC and new Incubating PMC private lists.
> In other words, a project is born when
> three? foundation members, or others deemed appropriate by the small
> iPMC, are constituted as a project by the board, with one (the
> recently invented champion) as the chair.
When 3+ mentors step up on general, the members participating on general@
give something approaching consensus, the VP, Project Incubation simply
submits a resolution and the board takes it up and passes it (as is, or
amended). And yes, the champion is the logical first-chair until the
project graduates or they are replaced for other reasons.
The board could also take up a resolution to charter an Incubating PMC
without the advisory vote on general@. That is a bit different than
today, when "imposing" a podling onto Incubator would be somewhat absurd.
> It seems to me that this ups the ante quite a bit on the accidental
> argument I started about mentor qualifications. The board absolutely
> does not want to have to provide direct supervision all the podlings:
> that's what the Board's formal feedback to the IPMC just now is about.
> So, under this scheme, the particular mentors that make up the initial
> PMC of a project are the ones the Board is trusting, and if any step
> down, they absolutely need to be replaced.
Bingo :)
> I support proposing this structure to the Board, but I wouldn't be
> terribly surprised if the answer is 'no'.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 2/1/2012 5:14 PM, Mattmann, Chris A (388J) wrote:
>
> On Feb 1, 2012, at 2:52 PM, Benson Margulies wrote:
>>
>> It seems to me that this ups the ante quite a bit on the accidental
>> argument I started about mentor qualifications. The board absolutely
>> does not want to have to provide direct supervision all the podlings:
>
> It certainly makes your proposal about mentor qualifications important,
> yes. But I wouldn't say that the 2nd part naturally follows. Why wouldn't
> the board want to supervise podlings? IOW, what's the difference between
> ~100 Apache projects, versus ~150? We're going to grow to 150 some-day
> anyways and I bet we'll still have a board of 9 directors.
Today, the board reviews some 30 reports, one of which is many pages long.
Under the proposed schema the board might review some 50 reports, each of
which is several paragraphs long, and the net length of the monthly board
report doesn't change at all. Even the two or three paragraphs of
commentary usually offered by the VP would still be there, observing the
comings and goings of general@ activity.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Benson,
On Feb 1, 2012, at 2:52 PM, Benson Margulies wrote:
> At the risk of seeming trite, +1, but ...
>
> This lengthy proposal shifts the supervision responsibility of
> podlings from an big IPMC to a set of mentors approved by the board at
> the advice of a small iPMC.
Yea Bill's amendments keeping the VP Incubator and the small IPMC
do, but I'd say, those aren't necessary, we don't need them. Looks like
Bill and I pretty much agree on everything else, and reading ahead below,
so do you for the most part?
> In other words, a project is born when
> three? foundation members, or others deemed appropriate by the small
> iPMC,
s/small IPMC/membership of the foundation/
> are constituted as a project by the board, with one (the
> recently invented champion) as the chair.
+1
>
> It seems to me that this ups the ante quite a bit on the accidental
> argument I started about mentor qualifications. The board absolutely
> does not want to have to provide direct supervision all the podlings:
It certainly makes your proposal about mentor qualifications important,
yes. But I wouldn't say that the 2nd part naturally follows. Why wouldn't
the board want to supervise podlings? IOW, what's the difference between
~100 Apache projects, versus ~150? We're going to grow to 150 some-day
anyways and I bet we'll still have a board of 9 directors.
> that's what the Board's formal feedback to the IPMC just now is about.
> So, under this scheme, the particular mentors that make up the initial
> PMC of a project are the ones the Board is trusting, and if any step
> down, they absolutely need to be replaced.
Yep that's true, Benson.
>
> I support proposing this structure to the Board, but I wouldn't be
> terribly surprised if the answer is 'no'.
We'll see, I've learned not to make predictions *grin*
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by Benson Margulies <bi...@gmail.com>.
At the risk of seeming trite, +1, but ...
This lengthy proposal shifts the supervision responsibility of
podlings from an big IPMC to a set of mentors approved by the board at
the advice of a small iPMC. In other words, a project is born when
three? foundation members, or others deemed appropriate by the small
iPMC, are constituted as a project by the board, with one (the
recently invented champion) as the chair.
It seems to me that this ups the ante quite a bit on the accidental
argument I started about mentor qualifications. The board absolutely
does not want to have to provide direct supervision all the podlings:
that's what the Board's formal feedback to the IPMC just now is about.
So, under this scheme, the particular mentors that make up the initial
PMC of a project are the ones the Board is trusting, and if any step
down, they absolutely need to be replaced.
I support proposing this structure to the Board, but I wouldn't be
terribly surprised if the answer is 'no'.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by Karl Wright <da...@gmail.com>.
I don't think one approach precludes the other. Agreed that incubator
needs to keep going in the interim. Perhaps we can spin off groups
one at a time, starting with just one to get the bugs worked out?
Karl
On Thu, Feb 2, 2012 at 8:13 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
> On Fri, Feb 03, 2012 at 12:52:33AM +0100, Leo Simons wrote:
>> The basic idea is to split the current single really big group that is
>> the incubator into smaller groups that still cooperate and discuss and
>> whatnot, but are accountable and overseen separately. These smaller
>> groups become their own committees with their own VPs that report to
>> the Board.
>>
>> Is that a reasonable re-statement of the abstract idea? Is that
>> something we can all get behind?
>
> Completing such a task will be a lot of work, and who knows what complications
> and disagreements lie ahead? We have an incremental solution in front of us
> which mitigates some of our most pressing problems: the measured expansion of
> Joe Schaefer's successful "experiment" to add PPMC Members who have
> demonstrated a thorough understanding of the Apache Way to the IPMC.
>
> I don't support this boil-the-ocean revamp if it blocks the less ambitious
> reforms. An indefinite period where release votes continue to drag on for
> weeks is unacceptable.
>
> Marvin Humphrey
>
>
> ---------------------------------------------------------------------
> 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: Incubator, or "Incubation"?
Posted by Ross Gardler <rg...@opendirective.com>.
On 3 February 2012 01:13, Marvin Humphrey <ma...@rectangular.com> wrote:
> On Fri, Feb 03, 2012 at 12:52:33AM +0100, Leo Simons wrote:
>> The basic idea is to split the current single really big group that is
>> the incubator into smaller groups that still cooperate and discuss and
>> whatnot, but are accountable and overseen separately. These smaller
>> groups become their own committees with their own VPs that report to
>> the Board.
>>
>> Is that a reasonable re-statement of the abstract idea? Is that
>> something we can all get behind?
I have *not* had time to digest this thread yet. So my comments below
are based on the above re-statement of the abstract idea.
I promised some details about my past experiences leading a team to
provide mentoring to over 600 UK institutions with over 1000 projects
active at any one time (note that does not mean we had hands on
activity with all those projects, in fact not all of them were
software development projects, in reality we handled hundreds not
thousands, but then we were only 5 people, only one of which knew real
open development and only one other was technical). Unfortunately I
have not had the time to get this down into a sensible post and the
discussions here have been far too fast moving for me to keep up
during this busy time outside the ASF.
That being said, the approach I eventually took in that previous
activity was to encourage individuals to own "verticals", that is
areas of work that the individual was interested in. Somewhere where
they could get direct personal benefit from being involved with these
projects.
Where the individuals doing this work cared about the work they were
doing (i.e. it wasn't "just" a job) this strategy worked very well.
We developed a defined support plan. This provided models by which we
could evaluate the community progress of the project and, more
importantly, identified where the weakest points were. This helped
guide the allocation of community focused resources within the
projects and their mentors. I've never introduced this here because I
believe volunteers would find the idea of "measuring" (or worse being
measured) distasteful. Indeed we never told the projects of the
results of their evaluation, or even that we were doing them for this
reason. We just used them as internal tools.
Here in the ASF I don't think there is such a strong need for these
tools. In principle our mentors should know what to focus on next,
they shouldn't need the tool, they have personal experience.
Nevertheless, as the incubator has grown we have found that
differences of opinion about the best way to do things result in very
confused messages for our podlings. Whilst I don't think using a
formal evaluation tool is a good idea here, I do think documentation
of the mentoring process around the kind of evaluations we did would
be a good idea. We don't need all projects applying guidelines in
exactly the same way, but we do need some consistency in the generic
advice we give podlings. It is for this reason I asked (elsewhere) for
the nominees for the PMC chair to describe how they would like to work
with ComDev moving forwards. I would be happy for ComDev to help in
this regard, I have not spoken to the ComDev PMC as I still don't have
the concise statement of intent that I requested.
Ross
>
> Completing such a task will be a lot of work, and who knows what complications
> and disagreements lie ahead? We have an incremental solution in front of us
> which mitigates some of our most pressing problems: the measured expansion of
> Joe Schaefer's successful "experiment" to add PPMC Members who have
> demonstrated a thorough understanding of the Apache Way to the IPMC.
>
> I don't support this boil-the-ocean revamp if it blocks the less ambitious
> reforms. An indefinite period where release votes continue to drag on for
> weeks is unacceptable.
>
> Marvin Humphrey
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
--
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Fri, Feb 03, 2012 at 12:52:33AM +0100, Leo Simons wrote:
> The basic idea is to split the current single really big group that is
> the incubator into smaller groups that still cooperate and discuss and
> whatnot, but are accountable and overseen separately. These smaller
> groups become their own committees with their own VPs that report to
> the Board.
>
> Is that a reasonable re-statement of the abstract idea? Is that
> something we can all get behind?
Completing such a task will be a lot of work, and who knows what complications
and disagreements lie ahead? We have an incremental solution in front of us
which mitigates some of our most pressing problems: the measured expansion of
Joe Schaefer's successful "experiment" to add PPMC Members who have
demonstrated a thorough understanding of the Apache Way to the IPMC.
I don't support this boil-the-ocean revamp if it blocks the less ambitious
reforms. An indefinite period where release votes continue to drag on for
weeks is unacceptable.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by Karl Wright <da...@gmail.com>.
I like this general direction as well; seems much more manageable. +1.
Karl
On Thu, Feb 2, 2012 at 6:52 PM, Leo Simons <ma...@leosimons.com> wrote:
> Hey folks,
>
> I just wanted to chime in with a +1 for the general direction. I think
> there's actually a lot of work to do to iron out how to reorganize
> things. Before digging in, I suggest we abstract out a little bit to
> see if we have consensus on the overall goals and desired end state
> before starting to debate the details, or the process by which to get
> there.
>
> 1) There are people who produce guides, rules and policy that describe
> the incubation process. These rules are then imposed on other groups
> at apache by board decree.
> 2) At any point in time, there shall be many groups of people
> following the incubation process.
> 3) There is a mechanism in place to provide oversight over all the
> different ongoing incubations.
> 4) The differences between communities going through incubation and
> those that aren't is clear and understood by all (including end users,
> press, etc).
>
> I think the above invariants describe both incubation as of yesterday
> and incubation as of tomorrow. But, we have some issues with the
> current incubator.
>
> a) The volume of incubation activity has grown such that oversight is difficult.
> b) Large group sizes (particularly general@ and IPMC roster) make
> accountability and consensus-building difficult.
> c) meritocracy is hampered by having the people doing the work not
> having binding votes on their own work.
> d) ... <<add your own similar issues>> ...
>
> The basic realization is that combining all the people from 1) and 2)
> into effectively one big group [1] is no longer the best idea.
>
> So, we want to redesign how we organize into groups, and associated
> with that we want to tune our oversight mechanisms.
>
> The basic idea is to split the current single really big group that is
> the incubator into smaller groups that still cooperate and discuss and
> whatnot, but are accountable and overseen separately. These smaller
> groups become their own committees with their own VPs that report to
> the Board.
>
> Is that a reasonable re-statement of the abstract idea? Is that
> something we can all get behind?
>
> The next steps then involve deciding just how to split things up.
> Since I'm off to go skiing tomorrow I won't be around next week to
> participate in the details of all that. Have fun :-)
>
> cheerio,
>
> Leo
>
> [1] the choice of the vague term 'group' is intentional: give us some
> degrees of freedom to design the structure, in a formal *and* an
> informal sense. One kind of group is a PMC, but there's also another
> kind of group which is "people subscribed to a mailing list" and
> another one "people that read the stuff that's on the mailing list"
> and another which is "people who feel responsible for what's going on
> on that mailing list", etc.
>
> On Wed, Feb 1, 2012 at 11:25 PM, William A. Rowe Jr. <wr...@apache.org> wrote:
>> On 1/31/2012 5:05 PM, Mattmann, Chris A (388J) wrote:
>>>
>>> On Jan 31, 2012, at 1:28 PM, Roy T. Fielding wrote:
>>>>
>>>> Having said that, I should note that the context of Incubator is
>>>> significantly different than a normal PMC. If incubator wants to structure
>>>> itself more like a board and less like a project, I really don't have
>>>> much to say against that. Note that it should effect all of the decision
>>>> guidelines that give veto power, not just personnel decisions.
>>>
>>> Isn't that the problem right now though? Like it or not, the Incubator PMC
>>> has evolved into a mini-board, in the worse sense of the word. You guys
>>> have a monthly meeting via telecon; an agenda; a set of action items, and
>>> you still don't get everything that you want to get done, done.
>>>
>>> A very small percentage of folks within the IPMC actually maintain that type
>>> of board-like oversight over its podlings. And thus, because of that, the more
>>> I think about it, quite honestly, I don't know what the Incubator PMC is doing
>>> other than delay the inveitable eventuality that many of these projects will
>>> graduate and become TLPs and thus "the board's problem"; whereas many
>>> of them will not graduate, and become "not Apache's problem". We have an
>>> Attic for projects that make it to TLP for that. Heck, we have SVN and could
>>> even reboot Incubator dead projects if a group of individuals came along
>>> and wanted to maintain the code.
>>>
>>> My conclusion from all the ruckus recently has been that the Incubator "PMC"
>>> is nothing more than an Incubator "mailing list" where many ASF veterans
>>> and those that care about the foundation discuss (and sometimes argue)
>>> about the foundation's policies and interpretations of law that not even lawyers
>>> are perfect at -- we're all human yet we try and get on our high horse here
>>> and act like we speak in absolutes and the will of one or a small subset is
>>> the will of the many when we all know that in the end, if it's not fun anymore,
>>> we wouldn't be here.
>>>
>>> What would be so bad about saying that the Incubator, over its existence,
>>> has served its purpose and has devolved into an umbrella project of the type
>>> that we are looking to get rid of at the Foundation. I agree with Bill on the
>>> perspective that I'm sure at some point (and it's probably already happened),
>>> we will experience Jakarta type symptoms and potentially may go down that
>>> road. Instead of couching it as "scary HUGE" change that several Apache
>>> vets have expressed to me that the Foundation doesn't like, how about we
>>> don't call it a "change" at all; and simply a "success". IOW, the Incubator itself
>>> has "graduated" and it's time for it to be "Attic'ed".
>>>
>>> In replacement, I propose the following concrete actions:
>>>
>>> 1. Move the Incubator process/policy/documentation, etc., to ComDev - I
>>> agree with gstein on this. I think it could be maintained by the ASF community
>>> folks there, and updated over time. But it's not vastly or rapidly changing really
>>> anymore.
>>>
>>> 2. Discharge the Incubator PMC and the role of Incubator VP -- pat everyone on
>>> the back, go have a beer, watch the big game together, whatever. Call it a
>>> success, not a failure.
>>>
>>> 3. Suggest at the board level that an Incubation "process" still exists at Apache,
>>> in the same way that it exists today. New projects write a proposal, the proposal
>>> is VOTEd on by the board at the board's next monthly meeting, and those
>>> that cannot be are QUEUED for the next meeting, or VOTEd on during out of
>>> board inbetween time on board@. Refer those wanting to "Incubate" at Apache
>>> to the existing Incubator documentation maintained by the ComDev community.
>>> Tell them to ask questions there, about the process, about what to do, or if
>>> ideas make sense. But *not* to VOTE on whether they are accepted or not.
>>>
>>> 4. Require every podling to have at least 3 ASF members on it, similar to the
>>> current Incubator process.
>>>
>>> 5. Operate podlings *exactly the same* as a TLP. There is a chair. There is a
>>> committee. Committee members have binding VOTEs on releases.
>>>
>>> I'm sure folks will argue this is blasphemy or that it will just add to the board's
>>> work, or that .... I'm ugly ... whatever. The fact of the matter is we kick spinning
>>> around in circle's trying to fix process issues that have been band-aided for
>>> years and that are now leaking like a sieve whenever we decide it's time to
>>> shine a light on them. When things are going "well" in the Incubator, it's not
>>> because they are well. It's because no one is asking questions and they've
>>> chosen to ignore some of the gaping holes on the poor wounded body that
>>> remains. And then when some folks go and point out the gaping holes, we
>>> get these huge song and dances that don't amount to anything other than
>>> the old mantra "incremental change; don't rock the boat too much; XXX board
>>> member won't go for it; not here at Apache". Whatever.
>>>
>>> I think the board knows there is an issue with the Incubator. A lot of IPMC
>>> members do too. Some of us have spoken up; others haven't. I present
>>> above what I feel are concrete steps that could be actioned upon that
>>> I believe would improve the overall process and bring to light what is
>>> already occuring:
>>>
>>> 1. podlings are themselves distinct communities and will interpret our
>>> human laws and Apache doctrine the same as any other human when you
>>> put 10 of them in a room -- in 10 different ways.
>>>
>>> 2. podlings are more and more able to pick up on the basic principles of
>>> the Incubator documentation; its legal oversight and its processes. They
>>> aren't perfect, but neither are any of us. It's pretty good and we've got plenty
>>> of RMs (as evidenced by other discussions) that can produce an Apache
>>> release that hasn't gotten us sued yet.
>>>
>>> 3. mentors encourage their podlings to operate autonomously. general@ is
>>> often labeled "the wild west" and for good reason. If I went over to HTTPD
>>> and started spewing my OODT nonsense, many of you would scream foul
>>> and blasphemy just like I'd do if you guys came over into OODT and started
>>> flexing "your specific interpretations" of our commonly agreed upon mantra.
>>> That's what general@ is like. I don't think it makes sense, and I think those
>>> mentors who are doing a good job on their projects and those projects
>>> that are doing well would do well the same as TLPs. Many of the other
>>> side conversations around this issue are suggesting that -- why nominate
>>> folks for the IPMC when we could simply graduate the podlings?
>>>
>>> Anyways I could type more but I think I've beat this horse to death. I appeal
>>> to you and to the rest of the board members reading this thread will consider
>>> my proposal. Thanks for reading.
>>>
>>> --Chris, who I'll note *does* care about the IPMC and *does* care a ton about Apache
>>> and the folks here and our hallowed status as an awesome open source organization.
>>
>> Giving this thread all due consideration, with its own subject;
>>
>> I'd modify your proposal just a smidge. Keep an Incubator VP with a very small
>> operational committee just to help move the podling through the entire process
>> of wrangling the necessary proposal, votes and board resolutions. Some amount
>> of process documentation would remain under that VP and their committee.
>>
>> Take "VP, Project Incubation" out of the role of judging incoming or graduating
>> projects. Leave general@ for the process of submitting a proposal to come in
>> as an incubating podling or leave by way of graduation, the attic, or graveyard
>> (full purge in the rare case of questionable IP provenience).
>>
>> Make every podling a proper PMC to include its mentors. Make a choice between
>> including all listed initial contributors, or instead, have the mentors promote
>> the actual contributors given time and merit, based on a well thought out and
>> somewhat predictable flowchart.
>>
>> Have ComDev drive the effort to ensure all projects are nurtured by finding new
>> mentorship of old, graduated projects as well as incubating projects who had lost
>> their mentors. This might avoid some cases of the board imposing a full PMC reset
>> on established projects.
>>
>> Most importantly, have the voting by the full membership on general@ to recommend
>> to the board accepting a podling or graduating a podling to a TLP. Why? Given
>> the example of the hotly contested AOO podling, if the membership (represented
>> by Incubator PMC members) did not ultimately have the discussion that was held,
>> and if the board had 'imposed' accepting AOO on the foundation, it would have
>> done internal harm. Now maybe only 50 of the members care to review proposals
>> and cast such votes. That's OK, they are still representative of the membership.
>> If a member wants to gripe on the member's private list, they can be gently but
>> emphatically nudged to take their concerns to the general@ discussion of the
>> proposed project.
>>
>> In short, all incoming projects continue into an "Incubation" phase as we all
>> understand it, subject to additional scrutiny and oversight by a collection
>> of mentors and additional scrutiny by the board, reflected in their monthly
>> and then quarterly report. A scorecard continues for the incubating projects
>> of the milestones they must reach to graduate into a full fledged project.
>> And we can even continue to restrict them to an incubation.apache.org domain
>> until they reach that milestone.
>>
>> But they are plugged in from day one into the same array of services offered
>> by Board/Legal/Infrastructure/Press/Trademarks/ComDev/ConCom with mentors to
>> help them navigate. Beyond VP, Project Incubation, we will probably uncover
>> other obvious services that the ASF should provide as a VP or committee of
>> peers to nurture incoming podlings into successful, healthy projects.
>>
>> Every previous restriction on incubating podlings has been eliminated over
>> the past 8 years. There is no reason to continue the incubator committee
>> as an ombudsman, when every issue that applies to each incubating podling
>> simultaneously applies to each established project.
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Incubator, or "Incubation"?
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I just wanted to chime in with a +1 for the general direction.
+1 from me, too.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by Leo Simons <ma...@leosimons.com>.
Hey folks,
I just wanted to chime in with a +1 for the general direction. I think
there's actually a lot of work to do to iron out how to reorganize
things. Before digging in, I suggest we abstract out a little bit to
see if we have consensus on the overall goals and desired end state
before starting to debate the details, or the process by which to get
there.
1) There are people who produce guides, rules and policy that describe
the incubation process. These rules are then imposed on other groups
at apache by board decree.
2) At any point in time, there shall be many groups of people
following the incubation process.
3) There is a mechanism in place to provide oversight over all the
different ongoing incubations.
4) The differences between communities going through incubation and
those that aren't is clear and understood by all (including end users,
press, etc).
I think the above invariants describe both incubation as of yesterday
and incubation as of tomorrow. But, we have some issues with the
current incubator.
a) The volume of incubation activity has grown such that oversight is difficult.
b) Large group sizes (particularly general@ and IPMC roster) make
accountability and consensus-building difficult.
c) meritocracy is hampered by having the people doing the work not
having binding votes on their own work.
d) ... <<add your own similar issues>> ...
The basic realization is that combining all the people from 1) and 2)
into effectively one big group [1] is no longer the best idea.
So, we want to redesign how we organize into groups, and associated
with that we want to tune our oversight mechanisms.
The basic idea is to split the current single really big group that is
the incubator into smaller groups that still cooperate and discuss and
whatnot, but are accountable and overseen separately. These smaller
groups become their own committees with their own VPs that report to
the Board.
Is that a reasonable re-statement of the abstract idea? Is that
something we can all get behind?
The next steps then involve deciding just how to split things up.
Since I'm off to go skiing tomorrow I won't be around next week to
participate in the details of all that. Have fun :-)
cheerio,
Leo
[1] the choice of the vague term 'group' is intentional: give us some
degrees of freedom to design the structure, in a formal *and* an
informal sense. One kind of group is a PMC, but there's also another
kind of group which is "people subscribed to a mailing list" and
another one "people that read the stuff that's on the mailing list"
and another which is "people who feel responsible for what's going on
on that mailing list", etc.
On Wed, Feb 1, 2012 at 11:25 PM, William A. Rowe Jr. <wr...@apache.org> wrote:
> On 1/31/2012 5:05 PM, Mattmann, Chris A (388J) wrote:
>>
>> On Jan 31, 2012, at 1:28 PM, Roy T. Fielding wrote:
>>>
>>> Having said that, I should note that the context of Incubator is
>>> significantly different than a normal PMC. If incubator wants to structure
>>> itself more like a board and less like a project, I really don't have
>>> much to say against that. Note that it should effect all of the decision
>>> guidelines that give veto power, not just personnel decisions.
>>
>> Isn't that the problem right now though? Like it or not, the Incubator PMC
>> has evolved into a mini-board, in the worse sense of the word. You guys
>> have a monthly meeting via telecon; an agenda; a set of action items, and
>> you still don't get everything that you want to get done, done.
>>
>> A very small percentage of folks within the IPMC actually maintain that type
>> of board-like oversight over its podlings. And thus, because of that, the more
>> I think about it, quite honestly, I don't know what the Incubator PMC is doing
>> other than delay the inveitable eventuality that many of these projects will
>> graduate and become TLPs and thus "the board's problem"; whereas many
>> of them will not graduate, and become "not Apache's problem". We have an
>> Attic for projects that make it to TLP for that. Heck, we have SVN and could
>> even reboot Incubator dead projects if a group of individuals came along
>> and wanted to maintain the code.
>>
>> My conclusion from all the ruckus recently has been that the Incubator "PMC"
>> is nothing more than an Incubator "mailing list" where many ASF veterans
>> and those that care about the foundation discuss (and sometimes argue)
>> about the foundation's policies and interpretations of law that not even lawyers
>> are perfect at -- we're all human yet we try and get on our high horse here
>> and act like we speak in absolutes and the will of one or a small subset is
>> the will of the many when we all know that in the end, if it's not fun anymore,
>> we wouldn't be here.
>>
>> What would be so bad about saying that the Incubator, over its existence,
>> has served its purpose and has devolved into an umbrella project of the type
>> that we are looking to get rid of at the Foundation. I agree with Bill on the
>> perspective that I'm sure at some point (and it's probably already happened),
>> we will experience Jakarta type symptoms and potentially may go down that
>> road. Instead of couching it as "scary HUGE" change that several Apache
>> vets have expressed to me that the Foundation doesn't like, how about we
>> don't call it a "change" at all; and simply a "success". IOW, the Incubator itself
>> has "graduated" and it's time for it to be "Attic'ed".
>>
>> In replacement, I propose the following concrete actions:
>>
>> 1. Move the Incubator process/policy/documentation, etc., to ComDev - I
>> agree with gstein on this. I think it could be maintained by the ASF community
>> folks there, and updated over time. But it's not vastly or rapidly changing really
>> anymore.
>>
>> 2. Discharge the Incubator PMC and the role of Incubator VP -- pat everyone on
>> the back, go have a beer, watch the big game together, whatever. Call it a
>> success, not a failure.
>>
>> 3. Suggest at the board level that an Incubation "process" still exists at Apache,
>> in the same way that it exists today. New projects write a proposal, the proposal
>> is VOTEd on by the board at the board's next monthly meeting, and those
>> that cannot be are QUEUED for the next meeting, or VOTEd on during out of
>> board inbetween time on board@. Refer those wanting to "Incubate" at Apache
>> to the existing Incubator documentation maintained by the ComDev community.
>> Tell them to ask questions there, about the process, about what to do, or if
>> ideas make sense. But *not* to VOTE on whether they are accepted or not.
>>
>> 4. Require every podling to have at least 3 ASF members on it, similar to the
>> current Incubator process.
>>
>> 5. Operate podlings *exactly the same* as a TLP. There is a chair. There is a
>> committee. Committee members have binding VOTEs on releases.
>>
>> I'm sure folks will argue this is blasphemy or that it will just add to the board's
>> work, or that .... I'm ugly ... whatever. The fact of the matter is we kick spinning
>> around in circle's trying to fix process issues that have been band-aided for
>> years and that are now leaking like a sieve whenever we decide it's time to
>> shine a light on them. When things are going "well" in the Incubator, it's not
>> because they are well. It's because no one is asking questions and they've
>> chosen to ignore some of the gaping holes on the poor wounded body that
>> remains. And then when some folks go and point out the gaping holes, we
>> get these huge song and dances that don't amount to anything other than
>> the old mantra "incremental change; don't rock the boat too much; XXX board
>> member won't go for it; not here at Apache". Whatever.
>>
>> I think the board knows there is an issue with the Incubator. A lot of IPMC
>> members do too. Some of us have spoken up; others haven't. I present
>> above what I feel are concrete steps that could be actioned upon that
>> I believe would improve the overall process and bring to light what is
>> already occuring:
>>
>> 1. podlings are themselves distinct communities and will interpret our
>> human laws and Apache doctrine the same as any other human when you
>> put 10 of them in a room -- in 10 different ways.
>>
>> 2. podlings are more and more able to pick up on the basic principles of
>> the Incubator documentation; its legal oversight and its processes. They
>> aren't perfect, but neither are any of us. It's pretty good and we've got plenty
>> of RMs (as evidenced by other discussions) that can produce an Apache
>> release that hasn't gotten us sued yet.
>>
>> 3. mentors encourage their podlings to operate autonomously. general@ is
>> often labeled "the wild west" and for good reason. If I went over to HTTPD
>> and started spewing my OODT nonsense, many of you would scream foul
>> and blasphemy just like I'd do if you guys came over into OODT and started
>> flexing "your specific interpretations" of our commonly agreed upon mantra.
>> That's what general@ is like. I don't think it makes sense, and I think those
>> mentors who are doing a good job on their projects and those projects
>> that are doing well would do well the same as TLPs. Many of the other
>> side conversations around this issue are suggesting that -- why nominate
>> folks for the IPMC when we could simply graduate the podlings?
>>
>> Anyways I could type more but I think I've beat this horse to death. I appeal
>> to you and to the rest of the board members reading this thread will consider
>> my proposal. Thanks for reading.
>>
>> --Chris, who I'll note *does* care about the IPMC and *does* care a ton about Apache
>> and the folks here and our hallowed status as an awesome open source organization.
>
> Giving this thread all due consideration, with its own subject;
>
> I'd modify your proposal just a smidge. Keep an Incubator VP with a very small
> operational committee just to help move the podling through the entire process
> of wrangling the necessary proposal, votes and board resolutions. Some amount
> of process documentation would remain under that VP and their committee.
>
> Take "VP, Project Incubation" out of the role of judging incoming or graduating
> projects. Leave general@ for the process of submitting a proposal to come in
> as an incubating podling or leave by way of graduation, the attic, or graveyard
> (full purge in the rare case of questionable IP provenience).
>
> Make every podling a proper PMC to include its mentors. Make a choice between
> including all listed initial contributors, or instead, have the mentors promote
> the actual contributors given time and merit, based on a well thought out and
> somewhat predictable flowchart.
>
> Have ComDev drive the effort to ensure all projects are nurtured by finding new
> mentorship of old, graduated projects as well as incubating projects who had lost
> their mentors. This might avoid some cases of the board imposing a full PMC reset
> on established projects.
>
> Most importantly, have the voting by the full membership on general@ to recommend
> to the board accepting a podling or graduating a podling to a TLP. Why? Given
> the example of the hotly contested AOO podling, if the membership (represented
> by Incubator PMC members) did not ultimately have the discussion that was held,
> and if the board had 'imposed' accepting AOO on the foundation, it would have
> done internal harm. Now maybe only 50 of the members care to review proposals
> and cast such votes. That's OK, they are still representative of the membership.
> If a member wants to gripe on the member's private list, they can be gently but
> emphatically nudged to take their concerns to the general@ discussion of the
> proposed project.
>
> In short, all incoming projects continue into an "Incubation" phase as we all
> understand it, subject to additional scrutiny and oversight by a collection
> of mentors and additional scrutiny by the board, reflected in their monthly
> and then quarterly report. A scorecard continues for the incubating projects
> of the milestones they must reach to graduate into a full fledged project.
> And we can even continue to restrict them to an incubation.apache.org domain
> until they reach that milestone.
>
> But they are plugged in from day one into the same array of services offered
> by Board/Legal/Infrastructure/Press/Trademarks/ComDev/ConCom with mentors to
> help them navigate. Beyond VP, Project Incubation, we will probably uncover
> other obvious services that the ASF should provide as a VP or committee of
> peers to nurture incoming podlings into successful, healthy projects.
>
> Every previous restriction on incubating podlings has been eliminated over
> the past 8 years. There is no reason to continue the incubator committee
> as an ombudsman, when every issue that applies to each incubating podling
> simultaneously applies to each established project.
>
> ---------------------------------------------------------------------
> 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: Incubator, or "Incubation"?
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Bill,
On Feb 3, 2012, at 10:19 AM, William A. Rowe Jr. wrote:
> On 2/3/2012 11:11 AM, Sam Ruby wrote:
>> On Fri, Feb 3, 2012 at 5:26 AM, Greg Stein <gs...@gmail.com> wrote:
>>> Below is *precisely* my view on the matter. Bill annoys me sometimes
>>> :-P, but I have to say that I'm in 100% concurrence with him w.r.t
>>> thoughts/positioning below.
>>
>> While I agree that in an ideal world that's how things *ought* to
>> operate, do we the name of a potential chair who is ready, willing,
>> and able to execute on such?
>
> Chris is clearly willing, he authored the plan.
+1.
>
> Moreso, there are those of us who would support him in execution of
> such an effort.
Thanks a lot.
>
> But is he willing to stay the 6 months beyond dissolving the IPMC as the
> VP, Project Incubation if the board believes such a post is necessary,
> particularly if the board hasn't convinced him of its value? I can't
> answer for him, but I trust there will be enough participants for the
> board to select a different individual if 1) it wants that post beyond
> dissolution of "IPMC", and 2) Chris can't bring himself to continue.
Yeah to be honest, I have 2 other officer positions (OODT + Tika)
and am active in a lot of other projects. So as today, I'd say, if you
want that VP, Incubation role (as the dude who will execute the plan,
and who will be accountable for it) to continue beyond 6 months,
then I would likely have to be replaced then. But who knows
what 6 months time will bring anyways with respect to my feelings.
Dunno.
I like your attitude though -- if I need to be replaced then, replace me.
No biggie.
>
> That particular inflection point is quite a ways down the road, even
> in the fastest of plans to begin adopting "Foo Project, Incubating" TLPs.
+1, precisely.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by Ross Gardler <rg...@opendirective.com>.
On 3 February 2012 23:38, Sam Ruby <ru...@intertwingly.net> wrote:
> On Fri, Feb 3, 2012 at 5:37 PM, Roy T. Fielding <fi...@gbiv.com> wrote:
>> On Feb 3, 2012, at 2:00 PM, Sam Ruby wrote:
>>> There is a place in the middle, which very much intrigues me. Instead
>>> of replacing 1 IPMC with n PMCs, having n+1 PMCs, with the Incubator
>>> playing a role much like legal or trademarks (or infra or press
>>> or...). In particular, when problems arise the board would direct the
>>> PPMC to work with this group.
>>>
>>> This group would be much smaller than the current Incubator, but would
>>> continue indefinitely.
>>
>> IMO, that sounds like ComDev. ComDev was created, at least in part, to
>> complete the documentation tasks that Incubator dropped and act as an
>> Apache-wide community builder regardless of project status.
Nope. ComDev was created to manage GSoC and other such activities.
That being said, it is true that we have found it helpful to create a
different type of documentation to support that goal.
> "whether that resource goes by the name of 'incubator' or 'comdev', I
> care not" [1]
>
> That being said, I would want to verify that the ComDev chair agreed
> before I would support such a change. If so, I'm in.
So would I (as ComDev chair ;-)
I just posted elsewhere on this topic with a new subject. This part of
the discussion can go there. Thanks for highlighting this Sam.
Ross
>
>> ....Roy
>
> - Sam Ruby
>
> [1] http://mail-archives.apache.org/mod_mbox/incubator-general/201202.mbox/%3CCAFG6u8HTFBDxqwT_3_oKeD67y_dPzdZLAtH9WG8Nmy0CgY3J1Q%40mail.gmail.com%3E
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
--
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by Sam Ruby <ru...@intertwingly.net>.
On Fri, Feb 3, 2012 at 5:37 PM, Roy T. Fielding <fi...@gbiv.com> wrote:
> On Feb 3, 2012, at 2:00 PM, Sam Ruby wrote:
>> There is a place in the middle, which very much intrigues me. Instead
>> of replacing 1 IPMC with n PMCs, having n+1 PMCs, with the Incubator
>> playing a role much like legal or trademarks (or infra or press
>> or...). In particular, when problems arise the board would direct the
>> PPMC to work with this group.
>>
>> This group would be much smaller than the current Incubator, but would
>> continue indefinitely.
>
> IMO, that sounds like ComDev. ComDev was created, at least in part, to
> complete the documentation tasks that Incubator dropped and act as an
> Apache-wide community builder regardless of project status.
<chuckle>
"whether that resource goes by the name of 'incubator' or 'comdev', I
care not" [1]
That being said, I would want to verify that the ComDev chair agreed
before I would support such a change. If so, I'm in.
> ....Roy
- Sam Ruby
[1] http://mail-archives.apache.org/mod_mbox/incubator-general/201202.mbox/%3CCAFG6u8HTFBDxqwT_3_oKeD67y_dPzdZLAtH9WG8Nmy0CgY3J1Q%40mail.gmail.com%3E
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 2/3/2012 4:46 PM, Mattmann, Chris A (388J) wrote:
> On Feb 3, 2012, at 2:37 PM, Roy T. Fielding wrote:
>
>> On Feb 3, 2012, at 2:00 PM, Sam Ruby wrote:
>>> There is a place in the middle, which very much intrigues me. Instead
>>> of replacing 1 IPMC with n PMCs, having n+1 PMCs, with the Incubator
>>> playing a role much like legal or trademarks (or infra or press
>>> or...). In particular, when problems arise the board would direct the
>>> PPMC to work with this group.
>>>
>>> This group would be much smaller than the current Incubator, but would
>>> continue indefinitely.
>>
>> IMO, that sounds like ComDev. ComDev was created, at least in part, to
>> complete the documentation tasks that Incubator dropped and act as an
>> Apache-wide community builder regardless of project status.
>
> +1, Roy. In my proposal, that is ComDev.
And the proposed edit doesn't change ComDev's role one bit in terms of
the documentation of ASF project documentation, either.
The only proposed edit if the board desires would be to retain a VP,
Project Incubation as the board's agent in making things happen when
the champion/mentors are less familiar with the technical details, and
align the day to day process of incubation to address the board's ever
evolving requirements and concerns.
Think of VP, Project Incubation as the Board's and ComDev's agent for
change as it becomes necessary. Like VP, Java Community it would be
a stub/inactive placeholder most of the rest of the time.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
On Feb 3, 2012, at 2:37 PM, Roy T. Fielding wrote:
> On Feb 3, 2012, at 2:00 PM, Sam Ruby wrote:
>> There is a place in the middle, which very much intrigues me. Instead
>> of replacing 1 IPMC with n PMCs, having n+1 PMCs, with the Incubator
>> playing a role much like legal or trademarks (or infra or press
>> or...). In particular, when problems arise the board would direct the
>> PPMC to work with this group.
>>
>> This group would be much smaller than the current Incubator, but would
>> continue indefinitely.
>
> IMO, that sounds like ComDev. ComDev was created, at least in part, to
> complete the documentation tasks that Incubator dropped and act as an
> Apache-wide community builder regardless of project status.
+1, Roy. In my proposal, that is ComDev.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Feb 3, 2012, at 2:00 PM, Sam Ruby wrote:
> There is a place in the middle, which very much intrigues me. Instead
> of replacing 1 IPMC with n PMCs, having n+1 PMCs, with the Incubator
> playing a role much like legal or trademarks (or infra or press
> or...). In particular, when problems arise the board would direct the
> PPMC to work with this group.
>
> This group would be much smaller than the current Incubator, but would
> continue indefinitely.
IMO, that sounds like ComDev. ComDev was created, at least in part, to
complete the documentation tasks that Incubator dropped and act as an
Apache-wide community builder regardless of project status.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by Greg Stein <gs...@gmail.com>.
I believe there is a minor typo below:
On Fri, Feb 3, 2012 at 17:00, Sam Ruby <ru...@intertwingly.net> wrote:
> On Fri, Feb 3, 2012 at 1:19 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>> On 2/3/2012 11:11 AM, Sam Ruby wrote:
>>> On Fri, Feb 3, 2012 at 5:26 AM, Greg Stein <gs...@gmail.com> wrote:
>>>> Below is *precisely* my view on the matter. Bill annoys me sometimes
>>>> :-P, but I have to say that I'm in 100% concurrence with him w.r.t
>>>> thoughts/positioning below.
>>>
>>> While I agree that in an ideal world that's how things *ought* to
>>> operate, do we the name of a potential chair who is ready, willing,
>>> and able to execute on such?
>>
>> Chris is clearly willing, he authored the plan.
>
> I may be misreading or not following, but I see the original (now
> elided) description as being at least subtly different than what Chris
> is proposing.
>
> What we currently have is a Incubator. The board sees the list of
> members of that PMC as those who oversee the entire project. The
> Incubator sees the list of members of itself as mentors to various
> podlings who need not have any additional role.
>
> I saw what Bill described as fixing that by more closely aligning what
> the Incubator sees itself with how the Board sees the incubator. The
> net effect would be a much smaller list of IPMC members.
>
> I see what Chris described as reducing the IPMC members to zero.
>
> There is a place in the middle, which very much intrigues me. Instead
> of replacing 1 IPMC with n PMCs, having n+1 PMCs, with the Incubator
> playing a role much like legal or trademarks (or infra or press
> or...). In particular, when problems arise the board would direct the
> PPMC to work with this group.
^^ should be IPMC, I believe.
(and FWIW, this is the model that I believe we should move to; in a
couple years, we may find this new-IPMC can be phased out, but I'd
like to see the new model well-tested first)
>
> This group would be much smaller than the current Incubator, but would
> continue indefinitely.
>
> This (at least to me) doesn't seem to be something that Chris is signing up for.
>
>> Moreso, there are those of us who would support him in execution of
>> such an effort.
>
> +1
>
>> But is he willing to stay the 6 months beyond dissolving the IPMC as the
>> VP, Project Incubation if the board believes such a post is necessary,
>> particularly if the board hasn't convinced him of its value? I can't
>> answer for him, but I trust there will be enough participants for the
>> board to select a different individual if 1) it wants that post beyond
>> dissolution of "IPMC", and 2) Chris can't bring himself to continue.
>
> "hasn't convinced him of its value" is evidence that what you are
> describing is different than what Chis is proposing. Hence, my
> question: is there anybody willing to sign up for what you are
> describing? I ask this is something I would support.
>
>> That particular inflection point is quite a ways down the road, even
>> in the fastest of plans to begin adopting "Foo Project, Incubating" TLPs.
>
> I'm not so sure. Chris is talking about reducing the Incubator to
> zero in a matter of months.
>
> - Sam Ruby
>
> ---------------------------------------------------------------------
> 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: Incubator, or "Incubation"?
Posted by Sam Ruby <ru...@intertwingly.net>.
On Fri, Feb 3, 2012 at 1:19 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> On 2/3/2012 11:11 AM, Sam Ruby wrote:
>> On Fri, Feb 3, 2012 at 5:26 AM, Greg Stein <gs...@gmail.com> wrote:
>>> Below is *precisely* my view on the matter. Bill annoys me sometimes
>>> :-P, but I have to say that I'm in 100% concurrence with him w.r.t
>>> thoughts/positioning below.
>>
>> While I agree that in an ideal world that's how things *ought* to
>> operate, do we the name of a potential chair who is ready, willing,
>> and able to execute on such?
>
> Chris is clearly willing, he authored the plan.
I may be misreading or not following, but I see the original (now
elided) description as being at least subtly different than what Chris
is proposing.
What we currently have is a Incubator. The board sees the list of
members of that PMC as those who oversee the entire project. The
Incubator sees the list of members of itself as mentors to various
podlings who need not have any additional role.
I saw what Bill described as fixing that by more closely aligning what
the Incubator sees itself with how the Board sees the incubator. The
net effect would be a much smaller list of IPMC members.
I see what Chris described as reducing the IPMC members to zero.
There is a place in the middle, which very much intrigues me. Instead
of replacing 1 IPMC with n PMCs, having n+1 PMCs, with the Incubator
playing a role much like legal or trademarks (or infra or press
or...). In particular, when problems arise the board would direct the
PPMC to work with this group.
This group would be much smaller than the current Incubator, but would
continue indefinitely.
This (at least to me) doesn't seem to be something that Chris is signing up for.
> Moreso, there are those of us who would support him in execution of
> such an effort.
+1
> But is he willing to stay the 6 months beyond dissolving the IPMC as the
> VP, Project Incubation if the board believes such a post is necessary,
> particularly if the board hasn't convinced him of its value? I can't
> answer for him, but I trust there will be enough participants for the
> board to select a different individual if 1) it wants that post beyond
> dissolution of "IPMC", and 2) Chris can't bring himself to continue.
"hasn't convinced him of its value" is evidence that what you are
describing is different than what Chis is proposing. Hence, my
question: is there anybody willing to sign up for what you are
describing? I ask this is something I would support.
> That particular inflection point is quite a ways down the road, even
> in the fastest of plans to begin adopting "Foo Project, Incubating" TLPs.
I'm not so sure. Chris is talking about reducing the Incubator to
zero in a matter of months.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 2/3/2012 11:11 AM, Sam Ruby wrote:
> On Fri, Feb 3, 2012 at 5:26 AM, Greg Stein <gs...@gmail.com> wrote:
>> Below is *precisely* my view on the matter. Bill annoys me sometimes
>> :-P, but I have to say that I'm in 100% concurrence with him w.r.t
>> thoughts/positioning below.
>
> While I agree that in an ideal world that's how things *ought* to
> operate, do we the name of a potential chair who is ready, willing,
> and able to execute on such?
Chris is clearly willing, he authored the plan.
Moreso, there are those of us who would support him in execution of
such an effort.
But is he willing to stay the 6 months beyond dissolving the IPMC as the
VP, Project Incubation if the board believes such a post is necessary,
particularly if the board hasn't convinced him of its value? I can't
answer for him, but I trust there will be enough participants for the
board to select a different individual if 1) it wants that post beyond
dissolution of "IPMC", and 2) Chris can't bring himself to continue.
That particular inflection point is quite a ways down the road, even
in the fastest of plans to begin adopting "Foo Project, Incubating" TLPs.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by Sam Ruby <ru...@intertwingly.net>.
On Fri, Feb 3, 2012 at 5:26 AM, Greg Stein <gs...@gmail.com> wrote:
> Below is *precisely* my view on the matter. Bill annoys me sometimes
> :-P, but I have to say that I'm in 100% concurrence with him w.r.t
> thoughts/positioning below.
While I agree that in an ideal world that's how things *ought* to
operate, do we the name of a potential chair who is ready, willing,
and able to execute on such?
- Sam Ruby
> On Thu, Feb 2, 2012 at 12:25, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>> Wow... a post that was too long even for me :) We might want to break
>> this down into a couple of distinct topic threads for simplicities sake.
>>
>> Anyways, just one commment;
>>
>> On 2/2/2012 10:56 AM, Mattmann, Chris A (388J) wrote:
>>>
>>> On Feb 1, 2012, at 6:38 PM, Greg Stein wrote:
>>>
>>>> I can easily see a small group of
>>>> people maintaining that overall status and recommendation to graduate.
>>>> I can see this group shepherding the initial incubating-TLP resolution
>>>> to the Board. (a graduation resolution, if needed, could easily be
>>>> handled by the TLP itself by graduation time)
>>>
>>> I can see what you and Bill are saying too and it's not a blocker for me,
>>> but I'd urge you to consider the extra overhead that it would add, compared
>>> to the benefit of simply saying, the incoming project is simply any other
>>> ASF project, has the notion that those 3 ASF members that MUST be
>>> on the incoming project's PMC as identified in their proposal. And that
>>> those 3 ASF members could come from a collective set of what you guys
>>> are saying is this special, reduced IPMC like entity. I'm guessing that
>>> organically that's what would happen anyways. Only a small set of
>>> ASF members will volunteer to be on these incoming projects and help
>>> shepherd them in just the way it works today.
>>
>> You mention also "No need for the position anymore. Just another report to
>> have to read as a board member, and someone to middle-man, when what the
>> board ought to be doing is talking to the new project's VP, day 1."
>>
>> What I have tried to clearly state is; don't think of this VP as the
>> middle man. Think of this VP as the expediter. The one who takes a whole
>> stack of customs, duty, shipping and tarriff forms, and boils it down to
>> "Fill this in, and we'll submit these things".
>>
>> This VP would not be in the middle. They would be on the sideline. If
>> the mentors are entirely capable, perhaps ex-PMC chairs themselves, then
>> marvelous. If they are PMC members who have never submitted a resolution
>> in their lives, the VP is there to assist.
>>
>> The VP keeps the "files" on process. Not the lofty PMC Bylaws and Best
>> Practices and Nurturing Your Community documents, but the cookie cutter
>> "Your proposal should state" formal documentation. Think in terms of
>> ASF Legal, or better yet, Trademarks. They don't stand 'over' any
>> committee. They gather, define and communicate process. That is the
>> role of VP, Project Incubation. Individual PMCs (even incubating PMCs)
>> assume the *responsibility* for following those processes. Not a traffic
>> cop, but a tourist guide.
>>
>> It seems outside of the remit of ComDev to deal with this aspect, just
>> as it's outside the remit of ComDev to do the actual logistics of retiring
>> to and caring for the projects in the Attic. Sure, ComDev will have some
>> good 'getting started', 'how to' docs about both incubation and retirement.
>> But they aren't the resolution wranglers charged with following up on the
>> board's feedback. If a new incubating PMC resolution is broken, that VP
>> would step in to guide the mentors and podling to fix their proposal before
>> the board reconsiders it at a subsequent meeting.
>>
>> So yes, it is a necessary task the board is going to delegate out, whether
>> it is framed as the IPMC, or the VP, Project incubation. It can't be left
>> in a hundred different hands to drop.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Greg,
On Feb 3, 2012, at 2:26 AM, Greg Stein wrote:
> Below is *precisely* my view on the matter. Bill annoys me sometimes
> :-P, but I have to say that I'm in 100% concurrence with him w.r.t
> thoughts/positioning below.
I was in "sort of concurrence" as well.
I think what you guys are proposing is that you want to keep the Incubator
VP around to manage/oversee the implementation of my proposal to deconstruct
the Incubator.
Let's say for 6 months or something, while it's implemented. Is that fair?
If that's the case, I'm +1 to keep the position around, and I'm +1 to
fill the role and implement the proposal and be the person responsible
for reporting out on it to the board.
Cheers,
Chris
>
> On Thu, Feb 2, 2012 at 12:25, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>> Wow... a post that was too long even for me :) We might want to break
>> this down into a couple of distinct topic threads for simplicities sake.
>>
>> Anyways, just one commment;
>>
>> On 2/2/2012 10:56 AM, Mattmann, Chris A (388J) wrote:
>>>
>>> On Feb 1, 2012, at 6:38 PM, Greg Stein wrote:
>>>
>>>> I can easily see a small group of
>>>> people maintaining that overall status and recommendation to graduate.
>>>> I can see this group shepherding the initial incubating-TLP resolution
>>>> to the Board. (a graduation resolution, if needed, could easily be
>>>> handled by the TLP itself by graduation time)
>>>
>>> I can see what you and Bill are saying too and it's not a blocker for me,
>>> but I'd urge you to consider the extra overhead that it would add, compared
>>> to the benefit of simply saying, the incoming project is simply any other
>>> ASF project, has the notion that those 3 ASF members that MUST be
>>> on the incoming project's PMC as identified in their proposal. And that
>>> those 3 ASF members could come from a collective set of what you guys
>>> are saying is this special, reduced IPMC like entity. I'm guessing that
>>> organically that's what would happen anyways. Only a small set of
>>> ASF members will volunteer to be on these incoming projects and help
>>> shepherd them in just the way it works today.
>>
>> You mention also "No need for the position anymore. Just another report to
>> have to read as a board member, and someone to middle-man, when what the
>> board ought to be doing is talking to the new project's VP, day 1."
>>
>> What I have tried to clearly state is; don't think of this VP as the
>> middle man. Think of this VP as the expediter. The one who takes a whole
>> stack of customs, duty, shipping and tarriff forms, and boils it down to
>> "Fill this in, and we'll submit these things".
>>
>> This VP would not be in the middle. They would be on the sideline. If
>> the mentors are entirely capable, perhaps ex-PMC chairs themselves, then
>> marvelous. If they are PMC members who have never submitted a resolution
>> in their lives, the VP is there to assist.
>>
>> The VP keeps the "files" on process. Not the lofty PMC Bylaws and Best
>> Practices and Nurturing Your Community documents, but the cookie cutter
>> "Your proposal should state" formal documentation. Think in terms of
>> ASF Legal, or better yet, Trademarks. They don't stand 'over' any
>> committee. They gather, define and communicate process. That is the
>> role of VP, Project Incubation. Individual PMCs (even incubating PMCs)
>> assume the *responsibility* for following those processes. Not a traffic
>> cop, but a tourist guide.
>>
>> It seems outside of the remit of ComDev to deal with this aspect, just
>> as it's outside the remit of ComDev to do the actual logistics of retiring
>> to and caring for the projects in the Attic. Sure, ComDev will have some
>> good 'getting started', 'how to' docs about both incubation and retirement.
>> But they aren't the resolution wranglers charged with following up on the
>> board's feedback. If a new incubating PMC resolution is broken, that VP
>> would step in to guide the mentors and podling to fix their proposal before
>> the board reconsiders it at a subsequent meeting.
>>
>> So yes, it is a necessary task the board is going to delegate out, whether
>> it is framed as the IPMC, or the VP, Project incubation. It can't be left
>> in a hundred different hands to drop.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by Greg Stein <gs...@gmail.com>.
Below is *precisely* my view on the matter. Bill annoys me sometimes
:-P, but I have to say that I'm in 100% concurrence with him w.r.t
thoughts/positioning below.
On Thu, Feb 2, 2012 at 12:25, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> Wow... a post that was too long even for me :) We might want to break
> this down into a couple of distinct topic threads for simplicities sake.
>
> Anyways, just one commment;
>
> On 2/2/2012 10:56 AM, Mattmann, Chris A (388J) wrote:
>>
>> On Feb 1, 2012, at 6:38 PM, Greg Stein wrote:
>>
>>> I can easily see a small group of
>>> people maintaining that overall status and recommendation to graduate.
>>> I can see this group shepherding the initial incubating-TLP resolution
>>> to the Board. (a graduation resolution, if needed, could easily be
>>> handled by the TLP itself by graduation time)
>>
>> I can see what you and Bill are saying too and it's not a blocker for me,
>> but I'd urge you to consider the extra overhead that it would add, compared
>> to the benefit of simply saying, the incoming project is simply any other
>> ASF project, has the notion that those 3 ASF members that MUST be
>> on the incoming project's PMC as identified in their proposal. And that
>> those 3 ASF members could come from a collective set of what you guys
>> are saying is this special, reduced IPMC like entity. I'm guessing that
>> organically that's what would happen anyways. Only a small set of
>> ASF members will volunteer to be on these incoming projects and help
>> shepherd them in just the way it works today.
>
> You mention also "No need for the position anymore. Just another report to
> have to read as a board member, and someone to middle-man, when what the
> board ought to be doing is talking to the new project's VP, day 1."
>
> What I have tried to clearly state is; don't think of this VP as the
> middle man. Think of this VP as the expediter. The one who takes a whole
> stack of customs, duty, shipping and tarriff forms, and boils it down to
> "Fill this in, and we'll submit these things".
>
> This VP would not be in the middle. They would be on the sideline. If
> the mentors are entirely capable, perhaps ex-PMC chairs themselves, then
> marvelous. If they are PMC members who have never submitted a resolution
> in their lives, the VP is there to assist.
>
> The VP keeps the "files" on process. Not the lofty PMC Bylaws and Best
> Practices and Nurturing Your Community documents, but the cookie cutter
> "Your proposal should state" formal documentation. Think in terms of
> ASF Legal, or better yet, Trademarks. They don't stand 'over' any
> committee. They gather, define and communicate process. That is the
> role of VP, Project Incubation. Individual PMCs (even incubating PMCs)
> assume the *responsibility* for following those processes. Not a traffic
> cop, but a tourist guide.
>
> It seems outside of the remit of ComDev to deal with this aspect, just
> as it's outside the remit of ComDev to do the actual logistics of retiring
> to and caring for the projects in the Attic. Sure, ComDev will have some
> good 'getting started', 'how to' docs about both incubation and retirement.
> But they aren't the resolution wranglers charged with following up on the
> board's feedback. If a new incubating PMC resolution is broken, that VP
> would step in to guide the mentors and podling to fix their proposal before
> the board reconsiders it at a subsequent meeting.
>
> So yes, it is a necessary task the board is going to delegate out, whether
> it is framed as the IPMC, or the VP, Project incubation. It can't be left
> in a hundred different hands to drop.
>
>
> ---------------------------------------------------------------------
> 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: Incubator, or "Incubation"?
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Joe,
On Feb 2, 2012, at 2:37 PM, Joe Schaefer wrote:
> My overall thoughts on this subject is that it is
> interesting to see Bill participating in a discussion
> that more or less amounts to knocking down the cathedral
> we've erected here and replacing it with a bazaar.
> Personally I'm not willing to walk with you guys
> down that route just yet, but the thinking behind
> the "experiment" I've been talking about was to
> just tweakthe cathedral with a hybrid "outdoor market"
> model.
Thanks yep that's basically it. I have found your experiment
successful; need no more data points; have found the
Incubator itself over its lifespan to have been successful,
and am looking to focus scarce Apache attention and
resources towards the future, celebrating with respect
towards the past, but also recognizing where we need
to go as a foundation.
We don't need to ope any more outdoor markets; we already
have a successful bazaar in front of us!
Cheers,
Chris
>
>
>
>> ________________________________
>> From: "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>
>> To: William A. Rowe Jr. <wr...@rowe-clan.net>
>> Cc: "general@incubator.apache.org" <ge...@incubator.apache.org>
>> Sent: Thursday, February 2, 2012 2:08 PM
>> Subject: Re: Incubator, or "Incubation"?
>>
>> Hey Bill,
>>
>> On Feb 2, 2012, at 10:54 AM, William A. Rowe Jr. wrote:
>>
>>> On 2/2/2012 12:49 PM, Mattmann, Chris A (388J) wrote:
>>>>
>>>> OK. If that VP isn't a flow-through and isn't visible when things are working
>>>> optimally, then why have him/her?
>>>
>>> Because when the process needs revision, and it will, the board doesn't want to
>>> revise it. ComDev shouldn't have to revise it. The board wants to point to one
>>> individual and say 'this part is broke, fix it', and have it done.
>>
>>
>> Interesting. I hadn't thought of that -- you see the process as (inevitably) evolving.
>> I see it as basically done, with so little revision it hardly warrants the creation of
>> an officer to oversee it.
>>
>> Cheers,
>> Chris
>>
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Chris Mattmann, Ph.D.
>> Senior Computer Scientist
>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> Office: 171-266B, Mailstop: 171-246
>> Email: chris.a.mattmann@nasa.gov
>> WWW: http://sunset.usc.edu/~mattmann/
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Adjunct Assistant Professor, Computer Science Department
>> University of Southern California, Los Angeles, CA 90089 USA
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by Joe Schaefer <jo...@yahoo.com>.
My overall thoughts on this subject is that it is
interesting to see Bill participating in a discussion
that more or less amounts to knocking down the cathedral
we've erected here and replacing it with a bazaar.
Personally I'm not willing to walk with you guys
down that route just yet, but the thinking behind
the "experiment" I've been talking about was to
just tweakthe cathedral with a hybrid "outdoor market"
model.
Interesting discussion to watch tho, especially if
it starts to bear fruit.
>________________________________
> From: "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>
>To: William A. Rowe Jr. <wr...@rowe-clan.net>
>Cc: "general@incubator.apache.org" <ge...@incubator.apache.org>
>Sent: Thursday, February 2, 2012 2:08 PM
>Subject: Re: Incubator, or "Incubation"?
>
>Hey Bill,
>
>On Feb 2, 2012, at 10:54 AM, William A. Rowe Jr. wrote:
>
>> On 2/2/2012 12:49 PM, Mattmann, Chris A (388J) wrote:
>>>
>>> OK. If that VP isn't a flow-through and isn't visible when things are working
>>> optimally, then why have him/her?
>>
>> Because when the process needs revision, and it will, the board doesn't want to
>> revise it. ComDev shouldn't have to revise it. The board wants to point to one
>> individual and say 'this part is broke, fix it', and have it done.
>
>
>Interesting. I hadn't thought of that -- you see the process as (inevitably) evolving.
>I see it as basically done, with so little revision it hardly warrants the creation of
>an officer to oversee it.
>
>Cheers,
>Chris
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Chris Mattmann, Ph.D.
>Senior Computer Scientist
>NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>Office: 171-266B, Mailstop: 171-246
>Email: chris.a.mattmann@nasa.gov
>WWW: http://sunset.usc.edu/~mattmann/
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Adjunct Assistant Professor, Computer Science Department
>University of Southern California, Los Angeles, CA 90089 USA
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
>
Re: Incubator, or "Incubation"?
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Bill,
On Feb 2, 2012, at 10:54 AM, William A. Rowe Jr. wrote:
> On 2/2/2012 12:49 PM, Mattmann, Chris A (388J) wrote:
>>
>> OK. If that VP isn't a flow-through and isn't visible when things are working
>> optimally, then why have him/her?
>
> Because when the process needs revision, and it will, the board doesn't want to
> revise it. ComDev shouldn't have to revise it. The board wants to point to one
> individual and say 'this part is broke, fix it', and have it done.
Interesting. I hadn't thought of that -- you see the process as (inevitably) evolving.
I see it as basically done, with so little revision it hardly warrants the creation of
an officer to oversee it.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 2/2/2012 12:49 PM, Mattmann, Chris A (388J) wrote:
>
> OK. If that VP isn't a flow-through and isn't visible when things are working
> optimally, then why have him/her?
Because when the process needs revision, and it will, the board doesn't want to
revise it. ComDev shouldn't have to revise it. The board wants to point to one
individual and say 'this part is broke, fix it', and have it done.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Bill,
On Feb 2, 2012, at 10:33 AM, William A. Rowe Jr. wrote:
> On 2/2/2012 12:27 PM, Mattmann, Chris A (388J) wrote:
>>
>> I guess the key difference between this small (but important) part of
>> our interpretation of this Incubator fix resolution that we're discussing
>> is the following:
>>
>> You (and maybe Greg?) feel that you need 1 VP guy (and perhaps
>> a committee/or not) to help out these projects-from-day-1-new-projects
>> that will be coming into the ASF, and that you need information flow up
>> from that guy and responsibility/culpability from that guy to the board,
>> and on down from it.
>
> Nope, that VP would not be a flow-through. Not even visible when things
> are working optimally;
OK. If that VP isn't a flow-through and isn't visible when things are working
optimally, then why have him/her?
You might say: For when things go wrong.
I'll say:
- in the case that things go wrong, it's up to the committee to:
- fix itself (elect a new chair, fork and tell us where to stick it; decide to
attic themselves, etc.)
- if it can't fix itself, it's the board's problem and they will fix it (with their
bazooka and tank).
- part of that committee includes N>=3 ASF members (at least). If they can't fix it,
and if they can't figure out how to elect a new chair, what is it a committee for
anyways? Send it to the Attic; tell them to take a walk; whatever.
This isn't divide and conquer. The responsibility *is* there. It's with the
incoming Project's VP who like any other VP will be the eyes and ears
of the board until replaced, death, resignation or whatever that long list
on the resolutions consists of; I forget right now.
>
>> I, on the other hand, feel that the N(=3?) ASF members that have to be
>> part of the new project's PMC from day 1, and that that new project's
>> VP (from day 1), are sufficient to provide that information flow up, and
>> responsibility/culpability. And guidance. And pointers to ASF resources
>> like ComDev (which will hold the Incubator docs), like Legal, like etc.
>> Just like the way it works today on our projects.
>
> Exactly. When those N(>=3) mentors don't have it together, this VP can
> step in to facilitate.
If those N>=3 don't have it together, then the committee will realize it, just
like any other committee. Or it won't realize it and the board will when
the reports start to suck or have red flags in them. This is no different
than a TLP today.
> Those mentors have to follow this VP's documented
> process flow established to expedite things for the board's benefit. When
> (not if) the process changes and evolves, it's on this VP to make the
> necessary modifications.
Agreed with everything above; it's just not owned by this VP. It's the process
flow of the foundation; owned by its members, operated by its board of
directors and shared by its community.
>
> But that VP won't be a gating factor if the mentors are experienced with
> the process. Responsibility for incubating projects is /not/ on the VP.
>
+1 to that should this VP be created which would definitely be against my
will :) I hold out hope I can convince us of adding another officer position
instead of trying this without one like it was pre 2002.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 2/2/2012 12:27 PM, Mattmann, Chris A (388J) wrote:
>
> I guess the key difference between this small (but important) part of
> our interpretation of this Incubator fix resolution that we're discussing
> is the following:
>
> You (and maybe Greg?) feel that you need 1 VP guy (and perhaps
> a committee/or not) to help out these projects-from-day-1-new-projects
> that will be coming into the ASF, and that you need information flow up
> from that guy and responsibility/culpability from that guy to the board,
> and on down from it.
Nope, that VP would not be a flow-through. Not even visible when things
are working optimally;
> I, on the other hand, feel that the N(=3?) ASF members that have to be
> part of the new project's PMC from day 1, and that that new project's
> VP (from day 1), are sufficient to provide that information flow up, and
> responsibility/culpability. And guidance. And pointers to ASF resources
> like ComDev (which will hold the Incubator docs), like Legal, like etc.
> Just like the way it works today on our projects.
Exactly. When those N(>=3) mentors don't have it together, this VP can
step in to facilitate. Those mentors have to follow this VP's documented
process flow established to expedite things for the board's benefit. When
(not if) the process changes and evolves, it's on this VP to make the
necessary modifications.
But that VP won't be a gating factor if the mentors are experienced with
the process. Responsibility for incubating projects is /not/ on the VP.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Bill,
On Feb 2, 2012, at 9:25 AM, William A. Rowe Jr. wrote:
> Wow... a post that was too long even for me :) We might want to break
> this down into a couple of distinct topic threads for simplicities sake.
Sorry I have a big mouth :) Thanks for breaking it down.
Comments below.
>
> Anyways, just one commment;
>
> On 2/2/2012 10:56 AM, Mattmann, Chris A (388J) wrote:
>>
>> On Feb 1, 2012, at 6:38 PM, Greg Stein wrote:
>>
>>> I can easily see a small group of
>>> people maintaining that overall status and recommendation to graduate.
>>> I can see this group shepherding the initial incubating-TLP resolution
>>> to the Board. (a graduation resolution, if needed, could easily be
>>> handled by the TLP itself by graduation time)
>>
>> I can see what you and Bill are saying too and it's not a blocker for me,
>> but I'd urge you to consider the extra overhead that it would add, compared
>> to the benefit of simply saying, the incoming project is simply any other
>> ASF project, has the notion that those 3 ASF members that MUST be
>> on the incoming project's PMC as identified in their proposal. And that
>> those 3 ASF members could come from a collective set of what you guys
>> are saying is this special, reduced IPMC like entity. I'm guessing that
>> organically that's what would happen anyways. Only a small set of
>> ASF members will volunteer to be on these incoming projects and help
>> shepherd them in just the way it works today.
>
> You mention also "No need for the position anymore. Just another report to
> have to read as a board member, and someone to middle-man, when what the
> board ought to be doing is talking to the new project's VP, day 1."
>
> What I have tried to clearly state is; don't think of this VP as the
> middle man. Think of this VP as the expediter. The one who takes a whole
> stack of customs, duty, shipping and tarriff forms, and boils it down to
> "Fill this in, and we'll submit these things".
Yeah I could see this VP actually being of some use, if it's 1 guy who
assumes that responsibility. I just cringe when I think of a VP and a
"committee of well intended [fill in the blank here] people who care
and..." blah blah blah.
We don't have this extra need for the rest of our TLPs some of which
include a chair that has never heard of the board@ list, nor all of the
little nitty-gritty stuff that has to be done. But somehow, some way, they
make it.
My supposition is that they make it because there are N ASF members
and some subset of those N that have "done it before" or "seen it done"
before and they guide the new chair (out of Incubation) for the new
project and tell him how to get it done. That's what I just did on Gora
and what I regularly see done in other projects.
I guess the key difference between this small (but important) part of
our interpretation of this Incubator fix resolution that we're discussing
is the following:
You (and maybe Greg?) feel that you need 1 VP guy (and perhaps
a committee/or not) to help out these projects-from-day-1-new-projects
that will be coming into the ASF, and that you need information flow up
from that guy and responsibility/culpability from that guy to the board,
and on down from it.
I, on the other hand, feel that the N(=3?) ASF members that have to be
part of the new project's PMC from day 1, and that that new project's
VP (from day 1), are sufficient to provide that information flow up, and
responsibility/culpability. And guidance. And pointers to ASF resources
like ComDev (which will hold the Incubator docs), like Legal, like etc.
Just like the way it works today on our projects.
>
> This VP would not be in the middle. They would be on the sideline. If
> the mentors are entirely capable, perhaps ex-PMC chairs themselves, then
> marvelous. If they are PMC members who have never submitted a resolution
> in their lives, the VP is there to assist.
>
> The VP keeps the "files" on process. Not the lofty PMC Bylaws and Best
> Practices and Nurturing Your Community documents, but the cookie cutter
> "Your proposal should state" formal documentation. Think in terms of
> ASF Legal, or better yet, Trademarks. They don't stand 'over' any
> committee. They gather, define and communicate process. That is the
> role of VP, Project Incubation. Individual PMCs (even incubating PMCs)
> assume the *responsibility* for following those processes. Not a traffic
> cop, but a tourist guide.
Yep I agree with both paragraphs above; it's just to me you can s/Incubation
VP/new Project's VP + 3 ASF PMC members that are part of it.
>
> It seems outside of the remit of ComDev to deal with this aspect, just
> as it's outside the remit of ComDev to do the actual logistics of retiring
> to and caring for the projects in the Attic. Sure, ComDev will have some
> good 'getting started', 'how to' docs about both incubation and retirement.
> But they aren't the resolution wranglers charged with following up on the
> board's feedback. If a new incubating PMC resolution is broken, that VP
> would step in to guide the mentors and podling to fix their proposal before
> the board reconsiders it at a subsequent meeting.
Yep sorry, another not so clear point of my proposal. Let me make it clear.
I'm not saying ComDev should take over "the responsibility" of each of these
new projects and the meddling (errr...helping, yay!) to show them the ASF
resources that are out there; make sure they file their reports; the "resolution
wrangers" you're talking about. To me, that's part of the new committee that's
about to be formed, and it should be spearheaded by that new committee's
VP (Champion), along with the 3 ASF members on the PMC that have to be
part of the proposal.
>
> So yes, it is a necessary task the board is going to delegate out, whether
> it is framed as the IPMC, or the VP, Project incubation. It can't be left
> in a hundred different hands to drop.
>
Agreed; not a hundred hands, but in hands of the new committee's chair (VP
or Champion) and the 3 ASF members (at least) that should be part of its
PMC.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Wow... a post that was too long even for me :) We might want to break
this down into a couple of distinct topic threads for simplicities sake.
Anyways, just one commment;
On 2/2/2012 10:56 AM, Mattmann, Chris A (388J) wrote:
>
> On Feb 1, 2012, at 6:38 PM, Greg Stein wrote:
>
>> I can easily see a small group of
>> people maintaining that overall status and recommendation to graduate.
>> I can see this group shepherding the initial incubating-TLP resolution
>> to the Board. (a graduation resolution, if needed, could easily be
>> handled by the TLP itself by graduation time)
>
> I can see what you and Bill are saying too and it's not a blocker for me,
> but I'd urge you to consider the extra overhead that it would add, compared
> to the benefit of simply saying, the incoming project is simply any other
> ASF project, has the notion that those 3 ASF members that MUST be
> on the incoming project's PMC as identified in their proposal. And that
> those 3 ASF members could come from a collective set of what you guys
> are saying is this special, reduced IPMC like entity. I'm guessing that
> organically that's what would happen anyways. Only a small set of
> ASF members will volunteer to be on these incoming projects and help
> shepherd them in just the way it works today.
You mention also "No need for the position anymore. Just another report to
have to read as a board member, and someone to middle-man, when what the
board ought to be doing is talking to the new project's VP, day 1."
What I have tried to clearly state is; don't think of this VP as the
middle man. Think of this VP as the expediter. The one who takes a whole
stack of customs, duty, shipping and tarriff forms, and boils it down to
"Fill this in, and we'll submit these things".
This VP would not be in the middle. They would be on the sideline. If
the mentors are entirely capable, perhaps ex-PMC chairs themselves, then
marvelous. If they are PMC members who have never submitted a resolution
in their lives, the VP is there to assist.
The VP keeps the "files" on process. Not the lofty PMC Bylaws and Best
Practices and Nurturing Your Community documents, but the cookie cutter
"Your proposal should state" formal documentation. Think in terms of
ASF Legal, or better yet, Trademarks. They don't stand 'over' any
committee. They gather, define and communicate process. That is the
role of VP, Project Incubation. Individual PMCs (even incubating PMCs)
assume the *responsibility* for following those processes. Not a traffic
cop, but a tourist guide.
It seems outside of the remit of ComDev to deal with this aspect, just
as it's outside the remit of ComDev to do the actual logistics of retiring
to and caring for the projects in the Attic. Sure, ComDev will have some
good 'getting started', 'how to' docs about both incubation and retirement.
But they aren't the resolution wranglers charged with following up on the
board's feedback. If a new incubating PMC resolution is broken, that VP
would step in to guide the mentors and podling to fix their proposal before
the board reconsiders it at a subsequent meeting.
So yes, it is a necessary task the board is going to delegate out, whether
it is framed as the IPMC, or the VP, Project incubation. It can't be left
in a hundred different hands to drop.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Greg,
First off, thanks for commenting on this. My
replies below:
On Feb 1, 2012, at 6:38 PM, Greg Stein wrote:
> On Wed, Feb 1, 2012 at 21:22, Mattmann, Chris A (388J)
> <ch...@jpl.nasa.gov> wrote:
>> Hi Bill,
>>
>> On Feb 1, 2012, at 3:26 PM, William A. Rowe Jr. wrote:
>> ...
>>> VP Project Incubation
>>> works with those Champions. Much like the foundation-wide security@a.o team
>>> works with all the individual projects as a resource, but isn't responsible
>>> for the oversight of individual project security defects.
>>
>> Yeah, I get what you're saying. You say the VP Incubator is a resource, but to me
>> the role is the head of a committee that just adds extra burden and overhead to
>> what should inherently be distributed and decentralized.
>>
>>>
>>> I don't see this working without an appointed coordinator.
>>
>>
>> I do :) just with the coordinating living within the project, just like TLPs,
>> and that's the Champion/VP of the podling.
>
> This proposal creates a differentiation between "normal" TLPs and
> "incubating" TLPs.
I honestly didn't mean to do that, but I can see how it could be
interpreted that way. I don't want to distinguish between them. Let's
just say that they are projects like any other projects, with the following
principles:
1. In the Incubator proposal used to run by the membership to
create the project, at least 3 of the initial PMC members must be
ASF members.
2. A proposed VP (or Champion either name is fine with me) should
be identified as part of the submitted proposal. That is the PMC chair,
until otherwise changed by board resolution just like any other project.
> The incubating TLPs have extra restrictions on them
> (branding, releases, etc), and they need extra tracking to determine
> whether they are ready to graduate.
This is true, but in reality they aren't extra restrictions they are simply
specific brand guidance, given to any other TLP, along with the
special Incubator stuff.
> I can easily see a small group of
> people maintaining that overall status and recommendation to graduate.
> I can see this group shepherding the initial incubating-TLP resolution
> to the Board. (a graduation resolution, if needed, could easily be
> handled by the TLP itself by graduation time)
I can see what you and Bill are saying too and it's not a blocker for me,
but I'd urge you to consider the extra overhead that it would add, compared
to the benefit of simply saying, the incoming project is simply any other
ASF project, has the notion that those 3 ASF members that MUST be
on the incoming project's PMC as identified in their proposal. And that
those 3 ASF members could come from a collective set of what you guys
are saying is this special, reduced IPMC like entity. I'm guessing that
organically that's what would happen anyways. Only a small set of
ASF members will volunteer to be on these incoming projects and help
shepherd them in just the way it works today.
>
> Mailing lists need somebody to "own" them, too, or they end up in a
> weird state. This new-fangled Incubator group would be the owner of
> the general@ list where proposals come in and are discussed.
Yeah I agree, but can't we say that ComDev "owns" general@incubator
after my proposal is implemented?
And yes, I forgot to specify this initially well didn't forget, I just didn't think of
it, so thanks for you and Bill and for discussion to help flesh it out. I'd like
to add that to my proposal. ComDev owns general@incubator.
>
> The VP of an incubating-TLP has ASF experience, but is otherwise "just
> another peer on the PMC" and is the liaison with the Board. I'm not
> sure that it makes sense to give them these "extra burden[s]" that
> you're talking about.
I think it's the same burdens that all VPs get, which is what the projects
should be striving for from day 1. We always have this odd situation
in the Incubator to date when a new project starts, especially with
an elected chair that isn't used to interacting with the board. There's
some knowledge that has to be gained, so outright even after graduation
the podling has some learning to do under the existing method and so does
its VP once it becomes TLP. Let's start that learning, day 1, and get them
interacting and just call them regular projects.
As Bill stated, before the Incubator, this is what you guys did anyways. I'm just
saying let's go back to that in the ASF, WITH the added benefit that now the
Incubator over its lifespan has delivered to us, the foundation:
1. a set of awesome guidelines, policies, procedures and documentation. Its
new home will be ComDev. ComDev does that anyways like you said, and
I agree with that.
2. a process, a great process that new projects coming into the ASF should
follow to start operating as ASF TLPs, from the get go.
3. great knowledge and discussion forever archived fleshing out the
boundary cases of many of the parts of our foundation. Thank you
Incubator for this.
That being said, with 1-3, some help from ComDev (which I think they
aren't opposed to, but would be happy to cross post, or raise a new
thread over there to make sure), and with the existing attitude of many
of the IPMC members that care about bringing projects into the foundation
(which includes a majority of board members who are also IPMC members, or
at least read the Incubator MLs), I think we're fine. No need for the position
anymore. Just another report to have to read as a board member, and
someone to middle-man, when what the board ought to be doing is
talking to the new project's VP, day 1.
> Decentralization is good, but I concur with
> Bill's analogy to security@ -- a group that helps to start and track
> the incubation status of some of our TLPs.
I hear what you guys are saying and if it's the only way to get some change
around here I'll listen, but I just don't think it's needed. It's another meta-
committee, with no purpose. The purpose and deliverables are here, and
can go forward and be used.
>
> By the time a TLP is ready to graduate, they might be self-aware
> enough to self-certify, but I'd be more comfortable with an Incubator
> group doing the review and recommendation.
Can't this just be the membership of the foundation? That's the Incubator
group going forward. With 100+ IPMC members, and with the basic tenant
today that any ASF member can simply be an IPMC member with an ACK
and with 99% of the Incubator PMC being ASF members, I think that naturally
follows.
>
> All this said, I can see an argument to combine this "Incubation"
> function/operations with ComDev. Certainly, the latter will have all
> the education resources. The question is whether the execution is
> distinct or rolled into ComDev.
+1, yep you and I are eye to eye on this (and I think on the above too, we're
not far off, neither is Bill). We're nearing consensus. Churn a bit on the
above and let me know what you think.
Peace out.
Cheers,
Chris
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by Donald Whytock <dw...@gmail.com>.
Isn't there also something along the lines of what's called "culpable
deniability"? Since podlings may be in states where their offerings
might not be as legal as TLPs (licensing issues, trademark/branding
issues, etc.), is it not more convenient for them to be relegated to
an area specifically designated as "not officially supported"? This
is very clearly demarked by a subdomain and a subproject, and if
there's to be a subdomain and a subproject it makes sense that there
are people specifically managing them.
I submit that the IPMC is an effect of the incubator rather than a
cause. I think the mechanisms need to be in place so that
not-yet-legal projects can exist and work on becoming legal projects,
and that it's just as well that staff exists to manage them.
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Feb 1, 2012 at 21:22, Mattmann, Chris A (388J)
<ch...@jpl.nasa.gov> wrote:
> Hi Bill,
>
> On Feb 1, 2012, at 3:26 PM, William A. Rowe Jr. wrote:
>...
>> VP Project Incubation
>> works with those Champions. Much like the foundation-wide security@a.o team
>> works with all the individual projects as a resource, but isn't responsible
>> for the oversight of individual project security defects.
>
> Yeah, I get what you're saying. You say the VP Incubator is a resource, but to me
> the role is the head of a committee that just adds extra burden and overhead to
> what should inherently be distributed and decentralized.
>
>>
>> I don't see this working without an appointed coordinator.
>
>
> I do :) just with the coordinating living within the project, just like TLPs,
> and that's the Champion/VP of the podling.
This proposal creates a differentiation between "normal" TLPs and
"incubating" TLPs. The incubating TLPs have extra restrictions on them
(branding, releases, etc), and they need extra tracking to determine
whether they are ready to graduate. I can easily see a small group of
people maintaining that overall status and recommendation to graduate.
I can see this group shepherding the initial incubating-TLP resolution
to the Board. (a graduation resolution, if needed, could easily be
handled by the TLP itself by graduation time)
Mailing lists need somebody to "own" them, too, or they end up in a
weird state. This new-fangled Incubator group would be the owner of
the general@ list where proposals come in and are discussed.
The VP of an incubating-TLP has ASF experience, but is otherwise "just
another peer on the PMC" and is the liaison with the Board. I'm not
sure that it makes sense to give them these "extra burden[s]" that
you're talking about. Decentralization is good, but I concur with
Bill's analogy to security@ -- a group that helps to start and track
the incubation status of some of our TLPs.
By the time a TLP is ready to graduate, they might be self-aware
enough to self-certify, but I'd be more comfortable with an Incubator
group doing the review and recommendation.
All this said, I can see an argument to combine this "Incubation"
function/operations with ComDev. Certainly, the latter will have all
the education resources. The question is whether the execution is
distinct or rolled into ComDev.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Bill,
On Feb 1, 2012, at 3:26 PM, William A. Rowe Jr. wrote:
> On 2/1/2012 5:11 PM, Mattmann, Chris A (388J) wrote:
>>
>> On Feb 1, 2012, at 2:25 PM, William A. Rowe Jr. wrote:
>>>
>>> I'd modify your proposal just a smidge. Keep an Incubator VP with a very small
>>> operational committee just to help move the podling through the entire process
>>> of wrangling the necessary proposal, votes and board resolutions. Some amount
>>> of process documentation would remain under that VP and their committee.
>>
>> I think this modification adds overhead that I think we have already. ComDev
>> can provide this guidance and I think that's what the natural purpose for it is.
>
> Simply, there needs to be someone (backed by a committee with specific individual
> responsibilities, if that person likes) to shepherd state changes into a board
> resolutions, ensure they hit the board agenda, maintain what we call the
> 'incubation web site' today, and answer inquiries about 'how do we go about X?'
> You can suggest that the directors, members and site-dev people take on all of
> those tasks, but we know that randomly distributed responsibilities don't work
> out so well. That's why there is now a collection of these VP roles at the ASF.
But I didn't suggest those set of people. You did. And I purposefully didn't suggest
them just as you purposefully threw them up as people you wouldn't think were
right for the role to illustrate your point. As you hint at below (and that's where
I'll respond), my proposal suggests empowering the actual chairs of the committees
of podlings as those responsible. That's the role of the Champion and it's no different
than the role of a VP, let's be done with it and say the Champion is the initial Podling
VP, subject to the same rigamarole and replaceability, rotation, whatever that any
chair is. The point is: podlings can start acting like projects from day 1, that's what
we encourage. They *are* projects. And if they aren't, we'll find out soon enough.
>
>>> Take "VP, Project Incubation" out of the role of judging incoming or graduating
>>> projects. Leave general@ for the process of submitting a proposal to come in
>>> as an incubating podling or leave by way of graduation, the attic, or graveyard
>>> (full purge in the rare case of questionable IP provenience).
>>>
>>> Make every podling a proper PMC to include its mentors. Make a choice between
>>> including all listed initial contributors, or instead, have the mentors promote
>>> the actual contributors given time and merit, based on a well thought out and
>>> somewhat predictable flowchart.
>>>
>>> Have ComDev drive the effort to ensure all projects are nurtured by finding new
>>> mentorship of old, graduated projects as well as incubating projects who had lost
>>> their mentors. This might avoid some cases of the board imposing a full PMC reset
>>> on established projects.
>>>
>>> Most importantly, have the voting by the full membership on general@ to recommend
>>> to the board accepting a podling or graduating a podling to a TLP.
>>
>> If the full membership is making the recommendation then i see no need for a VP
>> Incubator and I think it should be disbanded. However, I agree with your statements
>> above and think they jive with my proposal.
>
> I view this more as giving the members the opportunity to raise questions and issues
> of how a particular project proposal would fit here, which is what they do anyways.
> This only makes it more formal. You keep the VP simply as the record keeper and
> executor of the decisions on general@.
I agree with your sentiments towards the membership's role. However, I maintain,
I still don't think you need the VP of the Incubator; it's just extra overhead that's not
needed.
>
>>> Why? Given
>>> the example of the hotly contested AOO podling, if the membership (represented
>>> by Incubator PMC members) did not ultimately have the discussion that was held,
>>> and if the board had 'imposed' accepting AOO on the foundation, it would have
>>> done internal harm. Now maybe only 50 of the members care to review proposals
>>> and cast such votes. That's OK, they are still representative of the membership.
>>> If a member wants to gripe on the member's private list, they can be gently but
>>> emphatically nudged to take their concerns to the general@ discussion of the
>>> proposed project.
>>
>> Yes yes yes. Perfect. That's right. Let the membership VOTE for the proposal
>> and then recommend to the board. That's a great idea. And I guess that would
>> mean that general@ stays around. I could live with that so long as the VP
>> Incubator and the IPMC is discharged. As I said, I think they have more than
>> served their purpose.
>
> Well, the scope of general@ shrinks dramatically, although it can continue to be
> a place for a recently approved project to holler "help, we need more help!".
+1. Super +1. Yes, I agree.
>
> You might view the VP as overlapping the Champion.
Yep, I do.
> But do we want every one
> of the Champions to have to be intimately familiar with the form of the board
> resolutions, or consolidate some of the book-keeping?
Sure, we do. That's what a VP does, and what a Champion should do too.
I propose that a Champion is just the VP, while the podling is in the Incubation
"stage".
> VP Project Incubation
> works with those Champions. Much like the foundation-wide security@a.o team
> works with all the individual projects as a resource, but isn't responsible
> for the oversight of individual project security defects.
Yeah, I get what you're saying. You say the VP Incubator is a resource, but to me
the role is the head of a committee that just adds extra burden and overhead to
what should inherently be distributed and decentralized.
>
> I don't see this working without an appointed coordinator.
I do :) just with the coordinating living within the project, just like TLPs,
and that's the Champion/VP of the podling.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 2/1/2012 5:11 PM, Mattmann, Chris A (388J) wrote:
>
> On Feb 1, 2012, at 2:25 PM, William A. Rowe Jr. wrote:
>>
>> I'd modify your proposal just a smidge. Keep an Incubator VP with a very small
>> operational committee just to help move the podling through the entire process
>> of wrangling the necessary proposal, votes and board resolutions. Some amount
>> of process documentation would remain under that VP and their committee.
>
> I think this modification adds overhead that I think we have already. ComDev
> can provide this guidance and I think that's what the natural purpose for it is.
Simply, there needs to be someone (backed by a committee with specific individual
responsibilities, if that person likes) to shepherd state changes into a board
resolutions, ensure they hit the board agenda, maintain what we call the
'incubation web site' today, and answer inquiries about 'how do we go about X?'
You can suggest that the directors, members and site-dev people take on all of
those tasks, but we know that randomly distributed responsibilities don't work
out so well. That's why there is now a collection of these VP roles at the ASF.
>> Take "VP, Project Incubation" out of the role of judging incoming or graduating
>> projects. Leave general@ for the process of submitting a proposal to come in
>> as an incubating podling or leave by way of graduation, the attic, or graveyard
>> (full purge in the rare case of questionable IP provenience).
>>
>> Make every podling a proper PMC to include its mentors. Make a choice between
>> including all listed initial contributors, or instead, have the mentors promote
>> the actual contributors given time and merit, based on a well thought out and
>> somewhat predictable flowchart.
>>
>> Have ComDev drive the effort to ensure all projects are nurtured by finding new
>> mentorship of old, graduated projects as well as incubating projects who had lost
>> their mentors. This might avoid some cases of the board imposing a full PMC reset
>> on established projects.
>>
>> Most importantly, have the voting by the full membership on general@ to recommend
>> to the board accepting a podling or graduating a podling to a TLP.
>
> If the full membership is making the recommendation then i see no need for a VP
> Incubator and I think it should be disbanded. However, I agree with your statements
> above and think they jive with my proposal.
I view this more as giving the members the opportunity to raise questions and issues
of how a particular project proposal would fit here, which is what they do anyways.
This only makes it more formal. You keep the VP simply as the record keeper and
executor of the decisions on general@.
>> Why? Given
>> the example of the hotly contested AOO podling, if the membership (represented
>> by Incubator PMC members) did not ultimately have the discussion that was held,
>> and if the board had 'imposed' accepting AOO on the foundation, it would have
>> done internal harm. Now maybe only 50 of the members care to review proposals
>> and cast such votes. That's OK, they are still representative of the membership.
>> If a member wants to gripe on the member's private list, they can be gently but
>> emphatically nudged to take their concerns to the general@ discussion of the
>> proposed project.
>
> Yes yes yes. Perfect. That's right. Let the membership VOTE for the proposal
> and then recommend to the board. That's a great idea. And I guess that would
> mean that general@ stays around. I could live with that so long as the VP
> Incubator and the IPMC is discharged. As I said, I think they have more than
> served their purpose.
Well, the scope of general@ shrinks dramatically, although it can continue to be
a place for a recently approved project to holler "help, we need more help!".
You might view the VP as overlapping the Champion. But do we want every one
of the Champions to have to be intimately familiar with the form of the board
resolutions, or consolidate some of the book-keeping? VP Project Incubation
works with those Champions. Much like the foundation-wide security@a.o team
works with all the individual projects as a resource, but isn't responsible
for the oversight of individual project security defects.
I don't see this working without an appointed coordinator.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator, or "Incubation"?
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Bill,
On Feb 1, 2012, at 2:25 PM, William A. Rowe Jr. wrote:
>> [...snip large thought...please check archives here to see it:
http://s.apache.org/S0i
....]
>>
>> Anyways I could type more but I think I've beat this horse to death. I appeal
>> to you and to the rest of the board members reading this thread will consider
>> my proposal. Thanks for reading.
>>
>> --Chris, who I'll note *does* care about the IPMC and *does* care a ton about Apache
>> and the folks here and our hallowed status as an awesome open source organization.
>
> Giving this thread all due consideration, with its own subject;
Thanks Bill.
>
> I'd modify your proposal just a smidge. Keep an Incubator VP with a very small
> operational committee just to help move the podling through the entire process
> of wrangling the necessary proposal, votes and board resolutions. Some amount
> of process documentation would remain under that VP and their committee.
I think this modification adds overhead that I think we have already. ComDev
can provide this guidance and I think that's what the natural purpose for it is.
>
> Take "VP, Project Incubation" out of the role of judging incoming or graduating
> projects. Leave general@ for the process of submitting a proposal to come in
> as an incubating podling or leave by way of graduation, the attic, or graveyard
> (full purge in the rare case of questionable IP provenience).
>
> Make every podling a proper PMC to include its mentors. Make a choice between
> including all listed initial contributors, or instead, have the mentors promote
> the actual contributors given time and merit, based on a well thought out and
> somewhat predictable flowchart.
>
> Have ComDev drive the effort to ensure all projects are nurtured by finding new
> mentorship of old, graduated projects as well as incubating projects who had lost
> their mentors. This might avoid some cases of the board imposing a full PMC reset
> on established projects.
>
> Most importantly, have the voting by the full membership on general@ to recommend
> to the board accepting a podling or graduating a podling to a TLP.
If the full membership is making the recommendation then i see no need for a VP
Incubator and I think it should be disbanded. However, I agree with your statements
above and think they jive with my proposal.
> Why? Given
> the example of the hotly contested AOO podling, if the membership (represented
> by Incubator PMC members) did not ultimately have the discussion that was held,
> and if the board had 'imposed' accepting AOO on the foundation, it would have
> done internal harm. Now maybe only 50 of the members care to review proposals
> and cast such votes. That's OK, they are still representative of the membership.
> If a member wants to gripe on the member's private list, they can be gently but
> emphatically nudged to take their concerns to the general@ discussion of the
> proposed project.
Yes yes yes. Perfect. That's right. Let the membership VOTE for the proposal
and then recommend to the board. That's a great idea. And I guess that would
mean that general@ stays around. I could live with that so long as the VP
Incubator and the IPMC is discharged. As I said, I think they have more than
served their purpose.
>
> In short, all incoming projects continue into an "Incubation" phase as we all
> understand it, subject to additional scrutiny and oversight by a collection
> of mentors and additional scrutiny by the board, reflected in their monthly
> and then quarterly report. A scorecard continues for the incubating projects
> of the milestones they must reach to graduate into a full fledged project.
+1.
> And we can even continue to restrict them to an incubation.apache.org domain
> until they reach that milestone.
Meh, I don't think that matters, honestly. If they want to be newfoo.apache.org, who
cares, so long as they are following the website and trademarks guidelines for
what the website should say aka *large bold words* saying Incubation :)
>
> But they are plugged in from day one into the same array of services offered
> by Board/Legal/Infrastructure/Press/Trademarks/ComDev/ConCom with mentors to
> help them navigate. Beyond VP, Project Incubation, we will probably uncover
> other obvious services that the ASF should provide as a VP or committee of
> peers to nurture incoming podlings into successful, healthy projects.
Yep, agreed with the above, minus the VP Incubation (or Incubator VP role),
and associated committee. There's no need for it.
>
> Every previous restriction on incubating podlings has been eliminated over
> the past 8 years. There is no reason to continue the incubator committee
> as an ombudsman, when every issue that applies to each incubating podling
> simultaneously applies to each established project.
Yep, and there's no reason to continue the Incubator committee, period.
Thanks for the comments BIll.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
re: Incubator, or "Incubation"?
Posted by "William A. Rowe Jr." <wr...@apache.org>.
On 1/31/2012 5:05 PM, Mattmann, Chris A (388J) wrote:
>
> On Jan 31, 2012, at 1:28 PM, Roy T. Fielding wrote:
>>
>> Having said that, I should note that the context of Incubator is
>> significantly different than a normal PMC. If incubator wants to structure
>> itself more like a board and less like a project, I really don't have
>> much to say against that. Note that it should effect all of the decision
>> guidelines that give veto power, not just personnel decisions.
>
> Isn't that the problem right now though? Like it or not, the Incubator PMC
> has evolved into a mini-board, in the worse sense of the word. You guys
> have a monthly meeting via telecon; an agenda; a set of action items, and
> you still don't get everything that you want to get done, done.
>
> A very small percentage of folks within the IPMC actually maintain that type
> of board-like oversight over its podlings. And thus, because of that, the more
> I think about it, quite honestly, I don't know what the Incubator PMC is doing
> other than delay the inveitable eventuality that many of these projects will
> graduate and become TLPs and thus "the board's problem"; whereas many
> of them will not graduate, and become "not Apache's problem". We have an
> Attic for projects that make it to TLP for that. Heck, we have SVN and could
> even reboot Incubator dead projects if a group of individuals came along
> and wanted to maintain the code.
>
> My conclusion from all the ruckus recently has been that the Incubator "PMC"
> is nothing more than an Incubator "mailing list" where many ASF veterans
> and those that care about the foundation discuss (and sometimes argue)
> about the foundation's policies and interpretations of law that not even lawyers
> are perfect at -- we're all human yet we try and get on our high horse here
> and act like we speak in absolutes and the will of one or a small subset is
> the will of the many when we all know that in the end, if it's not fun anymore,
> we wouldn't be here.
>
> What would be so bad about saying that the Incubator, over its existence,
> has served its purpose and has devolved into an umbrella project of the type
> that we are looking to get rid of at the Foundation. I agree with Bill on the
> perspective that I'm sure at some point (and it's probably already happened),
> we will experience Jakarta type symptoms and potentially may go down that
> road. Instead of couching it as "scary HUGE" change that several Apache
> vets have expressed to me that the Foundation doesn't like, how about we
> don't call it a "change" at all; and simply a "success". IOW, the Incubator itself
> has "graduated" and it's time for it to be "Attic'ed".
>
> In replacement, I propose the following concrete actions:
>
> 1. Move the Incubator process/policy/documentation, etc., to ComDev - I
> agree with gstein on this. I think it could be maintained by the ASF community
> folks there, and updated over time. But it's not vastly or rapidly changing really
> anymore.
>
> 2. Discharge the Incubator PMC and the role of Incubator VP -- pat everyone on
> the back, go have a beer, watch the big game together, whatever. Call it a
> success, not a failure.
>
> 3. Suggest at the board level that an Incubation "process" still exists at Apache,
> in the same way that it exists today. New projects write a proposal, the proposal
> is VOTEd on by the board at the board's next monthly meeting, and those
> that cannot be are QUEUED for the next meeting, or VOTEd on during out of
> board inbetween time on board@. Refer those wanting to "Incubate" at Apache
> to the existing Incubator documentation maintained by the ComDev community.
> Tell them to ask questions there, about the process, about what to do, or if
> ideas make sense. But *not* to VOTE on whether they are accepted or not.
>
> 4. Require every podling to have at least 3 ASF members on it, similar to the
> current Incubator process.
>
> 5. Operate podlings *exactly the same* as a TLP. There is a chair. There is a
> committee. Committee members have binding VOTEs on releases.
>
> I'm sure folks will argue this is blasphemy or that it will just add to the board's
> work, or that .... I'm ugly ... whatever. The fact of the matter is we kick spinning
> around in circle's trying to fix process issues that have been band-aided for
> years and that are now leaking like a sieve whenever we decide it's time to
> shine a light on them. When things are going "well" in the Incubator, it's not
> because they are well. It's because no one is asking questions and they've
> chosen to ignore some of the gaping holes on the poor wounded body that
> remains. And then when some folks go and point out the gaping holes, we
> get these huge song and dances that don't amount to anything other than
> the old mantra "incremental change; don't rock the boat too much; XXX board
> member won't go for it; not here at Apache". Whatever.
>
> I think the board knows there is an issue with the Incubator. A lot of IPMC
> members do too. Some of us have spoken up; others haven't. I present
> above what I feel are concrete steps that could be actioned upon that
> I believe would improve the overall process and bring to light what is
> already occuring:
>
> 1. podlings are themselves distinct communities and will interpret our
> human laws and Apache doctrine the same as any other human when you
> put 10 of them in a room -- in 10 different ways.
>
> 2. podlings are more and more able to pick up on the basic principles of
> the Incubator documentation; its legal oversight and its processes. They
> aren't perfect, but neither are any of us. It's pretty good and we've got plenty
> of RMs (as evidenced by other discussions) that can produce an Apache
> release that hasn't gotten us sued yet.
>
> 3. mentors encourage their podlings to operate autonomously. general@ is
> often labeled "the wild west" and for good reason. If I went over to HTTPD
> and started spewing my OODT nonsense, many of you would scream foul
> and blasphemy just like I'd do if you guys came over into OODT and started
> flexing "your specific interpretations" of our commonly agreed upon mantra.
> That's what general@ is like. I don't think it makes sense, and I think those
> mentors who are doing a good job on their projects and those projects
> that are doing well would do well the same as TLPs. Many of the other
> side conversations around this issue are suggesting that -- why nominate
> folks for the IPMC when we could simply graduate the podlings?
>
> Anyways I could type more but I think I've beat this horse to death. I appeal
> to you and to the rest of the board members reading this thread will consider
> my proposal. Thanks for reading.
>
> --Chris, who I'll note *does* care about the IPMC and *does* care a ton about Apache
> and the folks here and our hallowed status as an awesome open source organization.
Giving this thread all due consideration, with its own subject;
I'd modify your proposal just a smidge. Keep an Incubator VP with a very small
operational committee just to help move the podling through the entire process
of wrangling the necessary proposal, votes and board resolutions. Some amount
of process documentation would remain under that VP and their committee.
Take "VP, Project Incubation" out of the role of judging incoming or graduating
projects. Leave general@ for the process of submitting a proposal to come in
as an incubating podling or leave by way of graduation, the attic, or graveyard
(full purge in the rare case of questionable IP provenience).
Make every podling a proper PMC to include its mentors. Make a choice between
including all listed initial contributors, or instead, have the mentors promote
the actual contributors given time and merit, based on a well thought out and
somewhat predictable flowchart.
Have ComDev drive the effort to ensure all projects are nurtured by finding new
mentorship of old, graduated projects as well as incubating projects who had lost
their mentors. This might avoid some cases of the board imposing a full PMC reset
on established projects.
Most importantly, have the voting by the full membership on general@ to recommend
to the board accepting a podling or graduating a podling to a TLP. Why? Given
the example of the hotly contested AOO podling, if the membership (represented
by Incubator PMC members) did not ultimately have the discussion that was held,
and if the board had 'imposed' accepting AOO on the foundation, it would have
done internal harm. Now maybe only 50 of the members care to review proposals
and cast such votes. That's OK, they are still representative of the membership.
If a member wants to gripe on the member's private list, they can be gently but
emphatically nudged to take their concerns to the general@ discussion of the
proposed project.
In short, all incoming projects continue into an "Incubation" phase as we all
understand it, subject to additional scrutiny and oversight by a collection
of mentors and additional scrutiny by the board, reflected in their monthly
and then quarterly report. A scorecard continues for the incubating projects
of the milestones they must reach to graduate into a full fledged project.
And we can even continue to restrict them to an incubation.apache.org domain
until they reach that milestone.
But they are plugged in from day one into the same array of services offered
by Board/Legal/Infrastructure/Press/Trademarks/ComDev/ConCom with mentors to
help them navigate. Beyond VP, Project Incubation, we will probably uncover
other obvious services that the ASF should provide as a VP or committee of
peers to nurture incoming podlings into successful, healthy projects.
Every previous restriction on incubating podlings has been eliminated over
the past 8 years. There is no reason to continue the incubator committee
as an ombudsman, when every issue that applies to each incubating podling
simultaneously applies to each established project.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Roy,
On Jan 31, 2012, at 1:28 PM, Roy T. Fielding wrote:
> On Jan 31, 2012, at 12:52 PM, Doug Cutting wrote:
>
>> On 01/30/2012 05:12 PM, Greg Stein wrote:
>>> I've never liked vetoes for this. One person can hold an entire PMC hostage
>>> simply for disliking someone (or worse: subtle corporate concerns masked
>>> otherwise). People have said in the past, "you should have veto so you're
>>> not forced to work with somebody you dislike." I respond, "grow up. we work
>>> with annoying people all the time, and the majority says they *can* work
>>
>> When this question came up in another context, Roy's concern, as I
>> recall it, was something to the effect that if you don't allow vetoes of
>> proposed PMC members then you might create a dysfunctional PMC. (Roy,
>> please correct me if I miss-recall.)
>
> Well, it boils down to the fact that making someone a PMC member gives
> them veto power over the changes you make. The only way that works
> socially is if everyone currently on the PMC agrees that person is a peer.
>
> Having said that, I should note that the context of Incubator is
> significantly different than a normal PMC. If incubator wants to structure
> itself more like a board and less like a project, I really don't have
> much to say against that. Note that it should effect all of the decision
> guidelines that give veto power, not just personnel decisions.
Isn't that the problem right now though? Like it or not, the Incubator PMC
has evolved into a mini-board, in the worse sense of the word. You guys
have a monthly meeting via telecon; an agenda; a set of action items, and
you still don't get everything that you want to get done, done.
A very small percentage of folks within the IPMC actually maintain that type
of board-like oversight over its podlings. And thus, because of that, the more
I think about it, quite honestly, I don't know what the Incubator PMC is doing
other than delay the inveitable eventuality that many of these projects will
graduate and become TLPs and thus "the board's problem"; whereas many
of them will not graduate, and become "not Apache's problem". We have an
Attic for projects that make it to TLP for that. Heck, we have SVN and could
even reboot Incubator dead projects if a group of individuals came along
and wanted to maintain the code.
My conclusion from all the ruckus recently has been that the Incubator "PMC"
is nothing more than an Incubator "mailing list" where many ASF veterans
and those that care about the foundation discuss (and sometimes argue)
about the foundation's policies and interpretations of law that not even lawyers
are perfect at -- we're all human yet we try and get on our high horse here
and act like we speak in absolutes and the will of one or a small subset is
the will of the many when we all know that in the end, if it's not fun anymore,
we wouldn't be here.
What would be so bad about saying that the Incubator, over its existence,
has served its purpose and has devolved into an umbrella project of the type
that we are looking to get rid of at the Foundation. I agree with Bill on the
perspective that I'm sure at some point (and it's probably already happened),
we will experience Jakarta type symptoms and potentially may go down that
road. Instead of couching it as "scary HUGE" change that several Apache
vets have expressed to me that the Foundation doesn't like, how about we
don't call it a "change" at all; and simply a "success". IOW, the Incubator itself
has "graduated" and it's time for it to be "Attic'ed".
In replacement, I propose the following concrete actions:
1. Move the Incubator process/policy/documentation, etc., to ComDev - I
agree with gstein on this. I think it could be maintained by the ASF community
folks there, and updated over time. But it's not vastly or rapidly changing really
anymore.
2. Discharge the Incubator PMC and the role of Incubator VP -- pat everyone on
the back, go have a beer, watch the big game together, whatever. Call it a
success, not a failure.
3. Suggest at the board level that an Incubation "process" still exists at Apache,
in the same way that it exists today. New projects write a proposal, the proposal
is VOTEd on by the board at the board's next monthly meeting, and those
that cannot be are QUEUED for the next meeting, or VOTEd on during out of
board inbetween time on board@. Refer those wanting to "Incubate" at Apache
to the existing Incubator documentation maintained by the ComDev community.
Tell them to ask questions there, about the process, about what to do, or if
ideas make sense. But *not* to VOTE on whether they are accepted or not.
4. Require every podling to have at least 3 ASF members on it, similar to the
current Incubator process.
5. Operate podlings *exactly the same* as a TLP. There is a chair. There is a
committee. Committee members have binding VOTEs on releases.
I'm sure folks will argue this is blasphemy or that it will just add to the board's
work, or that .... I'm ugly ... whatever. The fact of the matter is we kick spinning
around in circle's trying to fix process issues that have been band-aided for
years and that are now leaking like a sieve whenever we decide it's time to
shine a light on them. When things are going "well" in the Incubator, it's not
because they are well. It's because no one is asking questions and they've
chosen to ignore some of the gaping holes on the poor wounded body that
remains. And then when some folks go and point out the gaping holes, we
get these huge song and dances that don't amount to anything other than
the old mantra "incremental change; don't rock the boat too much; XXX board
member won't go for it; not here at Apache". Whatever.
I think the board knows there is an issue with the Incubator. A lot of IPMC
members do too. Some of us have spoken up; others haven't. I present
above what I feel are concrete steps that could be actioned upon that
I believe would improve the overall process and bring to light what is
already occuring:
1. podlings are themselves distinct communities and will interpret our
human laws and Apache doctrine the same as any other human when you
put 10 of them in a room -- in 10 different ways.
2. podlings are more and more able to pick up on the basic principles of
the Incubator documentation; its legal oversight and its processes. They
aren't perfect, but neither are any of us. It's pretty good and we've got plenty
of RMs (as evidenced by other discussions) that can produce an Apache
release that hasn't gotten us sued yet.
3. mentors encourage their podlings to operate autonomously. general@ is
often labeled "the wild west" and for good reason. If I went over to HTTPD
and started spewing my OODT nonsense, many of you would scream foul
and blasphemy just like I'd do if you guys came over into OODT and started
flexing "your specific interpretations" of our commonly agreed upon mantra.
That's what general@ is like. I don't think it makes sense, and I think those
mentors who are doing a good job on their projects and those projects
that are doing well would do well the same as TLPs. Many of the other
side conversations around this issue are suggesting that -- why nominate
folks for the IPMC when we could simply graduate the podlings?
Anyways I could type more but I think I've beat this horse to death. I appeal
to you and to the rest of the board members reading this thread will consider
my proposal. Thanks for reading.
--Chris, who I'll note *does* care about the IPMC and *does* care a ton about Apache
and the folks here and our hallowed status as an awesome open source organization.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jan 31, 2012, at 12:52 PM, Doug Cutting wrote:
> On 01/30/2012 05:12 PM, Greg Stein wrote:
>> I've never liked vetoes for this. One person can hold an entire PMC hostage
>> simply for disliking someone (or worse: subtle corporate concerns masked
>> otherwise). People have said in the past, "you should have veto so you're
>> not forced to work with somebody you dislike." I respond, "grow up. we work
>> with annoying people all the time, and the majority says they *can* work
>
> When this question came up in another context, Roy's concern, as I
> recall it, was something to the effect that if you don't allow vetoes of
> proposed PMC members then you might create a dysfunctional PMC. (Roy,
> please correct me if I miss-recall.)
Well, it boils down to the fact that making someone a PMC member gives
them veto power over the changes you make. The only way that works
socially is if everyone currently on the PMC agrees that person is a peer.
Having said that, I should note that the context of Incubator is
significantly different than a normal PMC. If incubator wants to structure
itself more like a board and less like a project, I really don't have
much to say against that. Note that it should effect all of the decision
guidelines that give veto power, not just personnel decisions.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by Doug Cutting <cu...@apache.org>.
On 01/30/2012 05:12 PM, Greg Stein wrote:
> I've never liked vetoes for this. One person can hold an entire PMC hostage
> simply for disliking someone (or worse: subtle corporate concerns masked
> otherwise). People have said in the past, "you should have veto so you're
> not forced to work with somebody you dislike." I respond, "grow up. we work
> with annoying people all the time, and the majority says they *can* work
When this question came up in another context, Roy's concern, as I
recall it, was something to the effect that if you don't allow vetoes of
proposed PMC members then you might create a dysfunctional PMC. (Roy,
please correct me if I miss-recall.) A PMC needs to regularly reach
consensus. If person X has technical ideas that are incompatible with
person Y then perhaps they should not be on the same PMC. At least
that's the way I recall Roy's argument...
Also note that if you get to the point where one person is vetoing a PMC
addition then the rest of the PMC could vote to remove that one person.
A veto is effectively asking the PMC to choose between you and the new
person, a strident move.
A less confrontational approach is to have a discussion before any vote,
where folks can air their concerns. If folks voice significant concerns
then it might not be wise to hold a vote.
Finally I'll observe that if supermajority would result in a different
result than consensus then the PMC probably has serious problems
collaborating that need to be fixed.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Posted by Greg Stein <gs...@gmail.com>.
+1
I've never liked vetoes for this. One person can hold an entire PMC hostage
simply for disliking someone (or worse: subtle corporate concerns masked
otherwise). People have said in the past, "you should have veto so you're
not forced to work with somebody you dislike." I respond, "grow up. we work
with annoying people all the time, and the majority says they *can* work
with this person."
On Jan 30, 2012 7:07 PM, "Joe Schaefer" <jo...@yahoo.com> wrote:
> It is clear that with all the turmoil of late and people
> lightly tossing around -1's that the notion of having veto
> authority over personnel matters makes little sense on this
> PMC. Therefore I propose we adopt the policy that personnel
> votes are by straight majority consensus, iow no vetoes allowed.
>
> I intend to offer a policy vote on this issue over the coming
> days and that vote, as with all procedural votes, is NOT subject
> to veto.
>
> Any other rational opinions?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>