Re: my pTLP view

[jan i]

On 23 January 2015 at 14:42, Greg Stein  wrote:

> Roman kicked off a query about  "next steps", with links to several wiki
> pages on possibilities. The "IncubatorV2" page which describes a
> "probationary TLP" is nothing like I have thought about.
>
> In my mind, a pTLP looks *exactly* like any other PMC. They report directly
> to the Board, they have infrastructure like any other project (eg.
> FOO.apache.org). But they have two significant differences:
>
> 1. probationary text is prominent, much like we require "incubating" to be
> prominent in various locations/messages for podlings
>
> 2. the initial PMC is comprised of only ASF Members. committers can be
> chosen however the community decides. but the *project* is reviewed by
> people with (hopefully/theoretically) experience with the Foundation and
> its views on communities
>

I agree with everything else you write, but the demand for "only ASF
Members" seems very hard. If I come to ASF with a community and a project,
I really would feel unhappy being cut out of the loop (PMC cares about the
community, not the committers following our role definition).

Would it not be possible to write "The initial PMC must be comprised of
more than 50% ASF Members", or something similar.

If this came to vote, I would give it a -1, because we cannot and should
not "overrule" an existing community, but merely guide them.

rgds
jan I

>
> That's it. By creating a PMC that understands what is needed, then they can
> groom new PMC members, and use the standard process for adding them to the
> PMC. The Board doesn't care about committership, so the pTLP can do
> whatever it wants in that regard.
>
> The Board might not accept a pTLP resolution because it wants more
> greybeards on there, to help the community. Removing the "probationary"
> label, is up to the pTLP to request, and the Board to approve. It is
> usually pretty obvious when a community has reached that point, if you are
> talking about active ASF/PMC Members. But the Board would apply its own
> level of trust.
>
> There is a big element here, which didn't exist 12 years ago: the Board's
> ability to review many projects. Before the Incubator, there weren't that
> many projects. The Directors didn't have a lot of experience with a lot of
> breadth. Nowadays, we review the work of *dozens* of projects every month.
> If one is a pTLP instead of a regular TLP? Not a big deal. They have some
> operational restrictions, but the report should be showing us a typical
> Apache community.
>
> The other aspect is IP clearance and management, which also didn't exist a
> dozen years ago (and the Incubator was basically started in response to
> some IP problems). We have a much better understanding there. Today, we
> have the Incubator performing that, but no reason we can't have pTLPs
> managing that process. We file "forms" about clearance with the Incubator,
> but really: that should be filed $somehow defined by the VP of Legal
> Affairs (and *that* position/process didn't exist until years after the
> Incubator was established).
>
> TLPs are a recognition of a community. We can create probationary
> communities, supported by ComDev, Legal, other communities, and reviewed by
> the Board.
>
> Speaking as a Director of the ASF, if a Resolution arrived on the Board's
> Agenda to create such a pTLP, then I would be supportive. The pTLP
> construct is independent of the Apache Incubator. Anybody is free to define
> how they want to approach it, and then ask the Board if they are willing to
> try it.
>
> Cheers,
> -g
>

Re: my pTLP view

[Chris Mattmann]

+1000. My view too and with my support too.



-Original Message-
From: Greg Stein 
Date: Friday, January 23, 2015 at 5:42 AM
To: "general@incubator.apache.org" , Chris
Mattmann , Jim Jagielski 
Subject: my pTLP view

>Roman kicked off a query about  "next steps", with links to several wiki
>pages on possibilities. The "IncubatorV2" page which describes a
>"probationary TLP" is nothing like I have thought about.
>
>
>In my mind, a pTLP looks *exactly* like any other PMC. They report
>directly to the Board, they have infrastructure like any other project
>(eg.
>FOO.apache.org ). But they have two significant
>differences:
>
>
>1. probationary text is prominent, much like we require "incubating" to
>be prominent in various locations/messages for podlings
>
>
>2. the initial PMC is comprised of only ASF Members. committers can be
>chosen however the community decides. but the *project* is reviewed by
>people with (hopefully/theoretically) experience with the Foundation and
>its views on communities
>
>
>That's it. By creating a PMC that understands what is needed, then they
>can groom new PMC members, and use the standard process for adding them
>to the PMC. The Board doesn't care about committership, so the pTLP can
>do whatever it wants in that regard.
>
>
>The Board might not accept a pTLP resolution because it wants more
>greybeards on there, to help the community. Removing the "probationary"
>label, is up to the pTLP to request, and the Board to approve. It is
>usually pretty obvious when a community has
> reached that point, if you are talking about active ASF/PMC Members. But
>the Board would apply its own level of trust.
>
>
>There is a big element here, which didn't exist 12 years ago: the Board's
>ability to review many projects. Before the Incubator, there weren't that
>many projects. The Directors didn't have a lot of experience with a lot
>of breadth. Nowadays, we review
> the work of *dozens* of projects every month. If one is a pTLP instead
>of a regular TLP? Not a big deal. They have some operational
>restrictions, but the report should be showing us a typical Apache
>community.
>
>
>The other aspect is IP clearance and management, which also didn't exist
>a dozen years ago (and the Incubator was basically started in response to
>some IP problems). We have a much better understanding there. Today, we
>have the Incubator performing that,
> but no reason we can't have pTLPs managing that process. We file "forms"
>about clearance with the Incubator, but really: that should be filed
>$somehow defined by the VP of Legal Affairs (and *that* position/process
>didn't exist until years after the Incubator
> was established).
>
>
>TLPs are a recognition of a community. We can create probationary
>communities, supported by ComDev, Legal, other communities, and reviewed
>by the Board.
>
>
>Speaking as a Director of the ASF, if a Resolution arrived on the Board's
>Agenda to create such a pTLP, then I would be supportive. The pTLP
>construct is independent of the Apache Incubator. Anybody is free to
>define how they want to approach it, and then
> ask the Board if they are willing to try it.
>
>
>Cheers,
>-g
>
>
>
>
>



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

RE: my pTLP view

[Ross Gardler (MS OPEN TECH)]

I would support it as an experiment.

I will support it because it is one of the few actionable suggestions on the 
table.

My caution has been expressed elsewhere. So I'll summarize as a reminder:

1) I supported just such an experiment a couple of years ago. It didn't go well 
(not disastrous, but not as expected). This is different from the original 
experiment as it removes the IPMC completely, but it wasn't the IPMC that was a 
problem.

2) Changing the oversight body doesn't magically make mentors as attentive as 
they need to be. There is *much* more work in fixing the problem than changing 
the oversight role.

Neither of these items mean pTLP will fail. I am supportive of the proposal as 
long as there is sufficient examination of the PMC membership on creation 
(which I see no reason to doubt).

Ross

Sent from my Windows Phone

From: Chris Mattmann<mailto:mattm...@apache.org>
Sent: ‎1/‎23/‎2015 7:18 AM
To: Greg Stein<mailto:gst...@gmail.com>; 
general@incubator.apache.org<mailto:general@incubator.apache.org>; Chris 
Mattmann<mailto:mattm...@apache.org>; Jim Jagielski<mailto:j...@jagunet.com>
Subject: Re: my pTLP view

+1000. My view too and with my support too.



-Original Message-
From: Greg Stein 
Date: Friday, January 23, 2015 at 5:42 AM
To: "general@incubator.apache.org" , Chris
Mattmann , Jim Jagielski 
Subject: my pTLP view

>Roman kicked off a query about  "next steps", with links to several wiki
>pages on possibilities. The "IncubatorV2" page which describes a
>"probationary TLP" is nothing like I have thought about.
>
>
>In my mind, a pTLP looks *exactly* like any other PMC. They report
>directly to the Board, they have infrastructure like any other project
>(eg.
>FOO.apache.org <http://FOO.apache.org>). But they have two significant
>differences:
>
>
>1. probationary text is prominent, much like we require "incubating" to
>be prominent in various locations/messages for podlings
>
>
>2. the initial PMC is comprised of only ASF Members. committers can be
>chosen however the community decides. but the *project* is reviewed by
>people with (hopefully/theoretically) experience with the Foundation and
>its views on communities
>
>
>That's it. By creating a PMC that understands what is needed, then they
>can groom new PMC members, and use the standard process for adding them
>to the PMC. The Board doesn't care about committership, so the pTLP can
>do whatever it wants in that regard.
>
>
>The Board might not accept a pTLP resolution because it wants more
>greybeards on there, to help the community. Removing the "probationary"
>label, is up to the pTLP to request, and the Board to approve. It is
>usually pretty obvious when a community has
> reached that point, if you are talking about active ASF/PMC Members. But
>the Board would apply its own level of trust.
>
>
>There is a big element here, which didn't exist 12 years ago: the Board's
>ability to review many projects. Before the Incubator, there weren't that
>many projects. The Directors didn't have a lot of experience with a lot
>of breadth. Nowadays, we review
> the work of *dozens* of projects every month. If one is a pTLP instead
>of a regular TLP? Not a big deal. They have some operational
>restrictions, but the report should be showing us a typical Apache
>community.
>
>
>The other aspect is IP clearance and management, which also didn't exist
>a dozen years ago (and the Incubator was basically started in response to
>some IP problems). We have a much better understanding there. Today, we
>have the Incubator performing that,
> but no reason we can't have pTLPs managing that process. We file "forms"
>about clearance with the Incubator, but really: that should be filed
>$somehow defined by the VP of Legal Affairs (and *that* position/process
>didn't exist until years after the Incubator
> was established).
>
>
>TLPs are a recognition of a community. We can create probationary
>communities, supported by ComDev, Legal, other communities, and reviewed
>by the Board.
>
>
>Speaking as a Director of the ASF, if a Resolution arrived on the Board's
>Agenda to create such a pTLP, then I would be supportive. The pTLP
>construct is independent of the Apache Incubator. Anybody is free to
>define how they want to approach it, and then
> ask the Board if they are willing to try it.
>
>
>Cheers,
>-g
>
>
>
>
>



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: my pTLP view

[Bertrand Delacretaz]

Hi,

On Fri, Jan 23, 2015 at 2:42 PM, Greg Stein  wrote:
> ...1. probationary text is prominent,...

> ...2. the initial PMC is comprised of only ASF Members...

I like that proposal, it's simple and looks actionable.

The only worry is what happens if the ASF Members on the PMC become
inactive - those folks will need to be serious about their job, to
make sure they elect the appropriate people to the PMC before leaving.
Doesn't sound impossible though.

-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: my pTLP view

[Greg Stein]

They are reporting to the Board. We know what inactivity looks like. So we
ask the PMC to fix it, or we shut them down. Just this week, you messaged a
PMC asking if they had enough actives. There is ample precedent for us
detecting and working through inactivity.
On Jan 23, 2015 9:46 AM, "Bertrand Delacretaz" 
wrote:

> Hi,
>
> On Fri, Jan 23, 2015 at 2:42 PM, Greg Stein  wrote:
> > ...1. probationary text is prominent,...
>
> > ...2. the initial PMC is comprised of only ASF Members...
>
> I like that proposal, it's simple and looks actionable.
>
> The only worry is what happens if the ASF Members on the PMC become
> inactive - those folks will need to be serious about their job, to
> make sure they elect the appropriate people to the PMC before leaving.
> Doesn't sound impossible though.
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: my pTLP view

[Greg Stein]

On Jan 23, 2015 8:53 AM, "jan i"  wrote:
>
> On 23 January 2015 at 14:42, Greg Stein  wrote:
> >...
>
> I agree with everything else you write, but the demand for "only ASF
> Members" seems very hard. If I come to ASF with a community and a project,
> I really would feel unhappy being cut out of the loop (PMC cares about the
> community, not the committers following our role definition).
>
> Would it not be possible to write "The initial PMC must be comprised of
> more than 50% ASF Members", or something similar.

It would be a Resolution put before the Board. So the initial mix can be
whatever you can get away with. :-)

As a Director, I'd look for 100%. But with some rationale, one or two
others could be fine.

> If this came to vote, I would give it a -1, because we cannot and should
> not "overrule" an existing community, but merely guide them.

The community is who agreed on the approach and placed it before the Board,
for pTLP status. And only the Board would be voting on that Resolution.

Cheers,
-g

Re: my pTLP view

[Alex Harui]

On 1/23/15, 6:53 AM, "jan i"  wrote:
>
>I agree with everything else you write, but the demand for "only ASF
>Members" seems very hard. If I come to ASF with a community and a project,
>I really would feel unhappy being cut out of the loop

Time for my weekly musings.  Sorry, no oaths and anthems this week.

I agree with Jan I.  Thinking back only a few years to when I was new to
Apache and going through the incubator, if the original PMC was comprised
only of seasoned ASF folks, I would have felt more like those ASF folks
were my managers and been more passive about learning about Apache because
I would expect these authority figures to train me.  Sometimes the better
way to learn is by doing.  IMO, it is better to make folks who really have
a stake in the success of the project feel that responsibility.

To me, that’s the problem I’ve having with all of these proposals.  They
seem too “top-down”, like the podling is a baby in need of true
incubation, like hand-holding and feeding.  Really, a podling is made up
of adults and “all" I think you really need is to make it clear to
newcomers that there is a different culture at Apache and that you are
expected to understand it, exercise it, and propagate it to latecomers in
order to become a full Apache project.  I just think that coddling
newcomers takes the risk of creating newcomers that can’t stand on their
own legs.  IMO, you want to test the newcomers to make sure they can
perform autonomously and proactively.

Maybe instead of the name “Incubator” we should call it “University”.
Lots of businesses send new employees to a “University” where corporate
culture is part of the lessons. But even that is “top-down” like you are
expected to go to class.  How about “Driving School”?  In driving school
you drive the car and get advice.  The instructor only takes control in an
emergency.  And the culture around driving, the “unwritten rules of the
road” that aren’t in the instruction manual, is part of what you learn
while you are doing.

New Apache instruction manuals are being written by Marvin and Bertrand et
al, so the rest comes down to “How do you teach culture?”  I’ve never
moved to another country to live, but I would argue that I had to learn a
new culture when I left my west coast high school and went to Boston for
college.  You can write up your culture and folks can read it, but a lot
of it just comes from trying it and being corrected as soon as possible,
hopefully in a nice way.


So let the newcomers drive.  Now, how do you make sure there is an
instructor in the car, that instructors are paying attention, and are
teaching the right rules?  If your driving instructor is a New York City
cab driver, you would get a decidedly different outcome than if the
driving instructor was my mom.  I think I’m hearing in these threads that
there is too much variance in the instruction at Apache.  Culling back to
a core that truly gets it and training new instructors might be required
if that’s true.

In driving school, the instructor in the car has a significant stake in
the outcome.  He/she truly has “skin in the game”.  I don’t see any easy
way for our mentors to have the same stake, especially given they are
volunteers.

In real communities, cultural errors are caught by the villagers being
embedded.  They see you doing something you shouldn’t take you aside and
tell you what you need to do differently.  The thing is, there are usually
few newcomers and lots of villagers.  New projects usually overwhelm the
villagers/mentors with new folks.  Maybe a solution is even more ASF folks
on each podling’s list.  Sure that dilutes responsibility, but with
volunteers, responsibility is always difficult to require.
Volunteer-staffed house-building project coordinators don’t try to find a
few volunteers to commit whole days, they try to find dozens of volunteers
knowing each might only hammer a few nails before leaving, but
collectively things get done.

The Incubator has one solution in place already.  Certain podling tasks
require notification before you get started on them and final approval
when you finish.  Maybe more podling tasks like report writing and
discussing potential committers need to follow the same pattern. Maybe
podlings should be encouraged to notify the incubator when the temperature
of a discussion rises, or maybe we need a tool that notifies the
villagers/incubators/members when any podling thread grows over 10 posts.

And if you have the right notifications, you get one other benefit.  If a
podling doesn’t emit any notifications for a while, you can assume
something is wrong there, even if their board report implies differently.

So:

-Whether there is a separate group called Incubator or anything else to
offload the board regarding report collection and review should be purely
a decision of load balancing.  If the board has time then you don’t need a
subcommittee, if not, create one.
-That group might be better organized as a subcommittee than a 

Re: my pTLP view

[Mattmann, Chris A (3980)]

+1 to both of these points from Greg.

++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattm...@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++






-Original Message-
From: Greg Stein 
Reply-To: "general@incubator.apache.org" 
Date: Friday, January 23, 2015 at 12:05 PM
To: "general@incubator.apache.org" 
Cc: Jim Jagielski , Chris Mattmann 
Subject: Re: my pTLP view

>On Jan 23, 2015 8:53 AM, "jan i"  wrote:
>>
>> On 23 January 2015 at 14:42, Greg Stein  wrote:
>> >...
>>
>> I agree with everything else you write, but the demand for "only ASF
>> Members" seems very hard. If I come to ASF with a community and a
>>project,
>> I really would feel unhappy being cut out of the loop (PMC cares about
>>the
>> community, not the committers following our role definition).
>>
>> Would it not be possible to write "The initial PMC must be comprised of
>> more than 50% ASF Members", or something similar.
>
>It would be a Resolution put before the Board. So the initial mix can be
>whatever you can get away with. :-)
>
>As a Director, I'd look for 100%. But with some rationale, one or two
>others could be fine.
>
>> If this came to vote, I would give it a -1, because we cannot and should
>> not "overrule" an existing community, but merely guide them.
>
>The community is who agreed on the approach and placed it before the
>Board,
>for pTLP status. And only the Board would be voting on that Resolution.
>
>Cheers,
>-g

Re: my pTLP view

[Roman Shaposhnik]

On Fri, Jan 23, 2015 at 5:42 AM, Greg Stein  wrote:
> Roman kicked off a query about  "next steps", with links to several wiki
> pages on possibilities. The "IncubatorV2" page which describes a
> "probationary TLP" is nothing like I have thought about.
>
> In my mind, a pTLP looks *exactly* like any other PMC. They report directly
> to the Board, they have infrastructure like any other project (eg.
> FOO.apache.org). But they have two significant differences:
>
> 1. probationary text is prominent, much like we require "incubating" to be
> prominent in various locations/messages for podlings
>
> 2. the initial PMC is comprised of only ASF Members. committers can be
> chosen however the community decides. but the *project* is reviewed by
> people with (hopefully/theoretically) experience with the Foundation and
> its views on communities

These are indeed the two linchpins for the whole thing.

Now, if pTLPs are successful we *may*, very carefully, decide to relax
#2, but only on the exceptional basis. Much like we allow non ASF
folks to join IPMC.

> The Board might not accept a pTLP resolution because it wants more
> greybeards on there, to help the community.

I, in fact, feel it to be a good thing. I don't think there's nearly enough
focus on vetting the initial list of mentors on some of the Incubator
proposals these days. Raising the bar to be 'the board' makes it
so much more important for podlings to recruit folks who can
actually help them.

> There is a big element here, which didn't exist 12 years ago: the Board's
> ability to review many projects. Before the Incubator, there weren't that
> many projects. The Directors didn't have a lot of experience with a lot of
> breadth. Nowadays, we review the work of *dozens* of projects every month.
> If one is a pTLP instead of a regular TLP? Not a big deal. They have some
> operational restrictions, but the report should be showing us a typical
> Apache community.

Correct.

> Speaking as a Director of the ASF, if a Resolution arrived on the Board's
> Agenda to create such a pTLP, then I would be supportive. The pTLP
> construct is independent of the Apache Incubator. Anybody is free to define
> how they want to approach it, and then ask the Board if they are willing to
> try it.

The way it is shaping up, I think that'll be part of the two pronged approach
I'd recommend to try for a 6 month:
   1. do a very minimum amount of reform at the IPMC and existing podlings
   2. run an experiment with a few candidates (either existing or new ones)
   around pTLP
If, after 6 months, we feel that #2 is working, we'll start channeling all new
incoming projects into pTLPs and let IPMC evolve into something else
in a very natural way (no revolution required).

I'm really happy to see that the board may be willing to engage in a controlled
experiment like this one. Getting a level of board support was my biggest
concern at this point.

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

RE: my pTLP view

[Ross Gardler (MS OPEN TECH)]

A good mentor is a guide, not a manager.

The proposals might seem top down, but when executed correctly, they are not.

Sent from my Windows Phone

From: Alex Harui<mailto:aha...@adobe.com>
Sent: ‎1/‎23/‎2015 12:06 PM
To: general@incubator.apache.org<mailto:general@incubator.apache.org>
Cc: Chris Mattmann<mailto:mattm...@apache.org>; Jim 
Jagielski<mailto:j...@jagunet.com>
Subject: Re: my pTLP view



On 1/23/15, 6:53 AM, "jan i"  wrote:
>
>I agree with everything else you write, but the demand for "only ASF
>Members" seems very hard. If I come to ASF with a community and a project,
>I really would feel unhappy being cut out of the loop

Time for my weekly musings.  Sorry, no oaths and anthems this week.

I agree with Jan I.  Thinking back only a few years to when I was new to
Apache and going through the incubator, if the original PMC was comprised
only of seasoned ASF folks, I would have felt more like those ASF folks
were my managers and been more passive about learning about Apache because
I would expect these authority figures to train me.  Sometimes the better
way to learn is by doing.  IMO, it is better to make folks who really have
a stake in the success of the project feel that responsibility.

To me, that’s the problem I’ve having with all of these proposals.  They
seem too “top-down”, like the podling is a baby in need of true
incubation, like hand-holding and feeding.  Really, a podling is made up
of adults and “all" I think you really need is to make it clear to
newcomers that there is a different culture at Apache and that you are
expected to understand it, exercise it, and propagate it to latecomers in
order to become a full Apache project.  I just think that coddling
newcomers takes the risk of creating newcomers that can’t stand on their
own legs.  IMO, you want to test the newcomers to make sure they can
perform autonomously and proactively.

Maybe instead of the name “Incubator” we should call it “University”.
Lots of businesses send new employees to a “University” where corporate
culture is part of the lessons. But even that is “top-down” like you are
expected to go to class.  How about “Driving School”?  In driving school
you drive the car and get advice.  The instructor only takes control in an
emergency.  And the culture around driving, the “unwritten rules of the
road” that aren’t in the instruction manual, is part of what you learn
while you are doing.

New Apache instruction manuals are being written by Marvin and Bertrand et
al, so the rest comes down to “How do you teach culture?”  I’ve never
moved to another country to live, but I would argue that I had to learn a
new culture when I left my west coast high school and went to Boston for
college.  You can write up your culture and folks can read it, but a lot
of it just comes from trying it and being corrected as soon as possible,
hopefully in a nice way.


So let the newcomers drive.  Now, how do you make sure there is an
instructor in the car, that instructors are paying attention, and are
teaching the right rules?  If your driving instructor is a New York City
cab driver, you would get a decidedly different outcome than if the
driving instructor was my mom.  I think I’m hearing in these threads that
there is too much variance in the instruction at Apache.  Culling back to
a core that truly gets it and training new instructors might be required
if that’s true.

In driving school, the instructor in the car has a significant stake in
the outcome.  He/she truly has “skin in the game”.  I don’t see any easy
way for our mentors to have the same stake, especially given they are
volunteers.

In real communities, cultural errors are caught by the villagers being
embedded.  They see you doing something you shouldn’t take you aside and
tell you what you need to do differently.  The thing is, there are usually
few newcomers and lots of villagers.  New projects usually overwhelm the
villagers/mentors with new folks.  Maybe a solution is even more ASF folks
on each podling’s list.  Sure that dilutes responsibility, but with
volunteers, responsibility is always difficult to require.
Volunteer-staffed house-building project coordinators don’t try to find a
few volunteers to commit whole days, they try to find dozens of volunteers
knowing each might only hammer a few nails before leaving, but
collectively things get done.

The Incubator has one solution in place already.  Certain podling tasks
require notification before you get started on them and final approval
when you finish.  Maybe more podling tasks like report writing and
discussing potential committers need to follow the same pattern. Maybe
podlings should be encouraged to notify the incubator when the temperature
of a discussion rises, or maybe we need a tool that notifies the
villagers/incubators/members when any podling thread grows over 10 posts.

And if you have the right notificatio

Re: my pTLP view

[Alex Harui]

On 1/23/15, 1:34 PM, "Ross Gardler (MS OPEN TECH)"
 wrote:

>A good mentor is a guide, not a manager.
>
>The proposals might seem top down, but when executed correctly, they are
>not.

OK, I’ll accept that, but if executed correctly, the current Incubator
probably doesn’t need changing either.

IMO, it is hard to find a lot of really dedicated volunteers.  So your
choices are to work the really good ones really hard, try to “manage”
other volunteers, or try to find a way to work without really dedicated
volunteers.

In my experience, the more you try to control and check on these other
volunteers, the faster they will go away.

Apache has a really great system of accepting code from volunteers with
limited time.   You don’t have to make a time commitment, just occasional
code commitment.  Can the ASF find a way to teach culture via volunteers
with limited time?  Probably.  That’s why I mentioned the notion of having
more ASF people involved in a project, but not as the initial PMC.  Real
communities teach their culture by hanging out around the newcomers, but
no one person is signed up to do the teaching.  They do it by having lots
of villagers watching the newbies checking on what the newbies are doing
and saying when they can.  That’s hard to do on email, but if certain
newbie efforts require a shout out outside their list, then it is easier
for this larger band of villagers to hear that something important is
going on.

-Alex

RE: my pTLP view

[Ross Gardler (MS OPEN TECH)]

As ASF member *should* know that empowering the ones doing the work is the 
Apache Way. A good member who is a mentor will ensure that they unblock 
anything that prevents those doing the work having the influence.

Look, theoretically, the board have ultimate power over all the projects at the 
ASF. According to the byelaws the board can do anything they want. Taking that 
logic a step further the president can unilaterally do almost anything they 
want. We avoid this situation by only electing people into those positions who 
are not going to abuse that "power" and instead use it to empower those doing 
the work.

I repeat again a good mentor is nothing more than a guide.

So why not make the project community the ones with the authority of a PMC? Two 
main reasons, that I can see:

a) we don't know the newcomers - how can we be sure they we not misuse heir 
"power"?
b) they hold the keys to the release process, that's what protects the 
contributors legally, we can’t remove that

The pTLP proposal does not change the way things work today. The incoming 
community don't have any voting authority - it's with the mentors and the IPMC.

All that being said, while I will (and already did two years ago) support some 
experimentation with the pTLP model I still feel that an Incubator with teeth 
scales better.

Ross

Microsoft Open Technologies, Inc.
A subsidiary of Microsoft Corporation

-Original Message-
From: jan i [mailto:j...@apache.org] 
Sent: Friday, January 23, 2015 2:34 PM
To: general@incubator.apache.org
Subject: my pTLP view

On Friday, January 23, 2015, Ross Gardler (MS OPEN TECH) < 
ross.gard...@microsoft.com 
> wrote:

> A good mentor is a guide, not a manager.
>
> The proposals might seem top down, but when executed correctly, they 
> are not.

No offense but how can you not call it top down, when the people trusted by the 
original community is removed and replaced by a bunch of potentially unknown 
people?

Having only ASF members is nearly the sane as saying "hi guys, we accept your 
project if you let us take over", and we ask you not do community (only 
committer)  work until WE deem you worthy of building YOUR community.
Remember the difference between committer and PMC please. The PPMC today plays 
an important role and you just remove it, and think ASF members can replace 
that without looking at the effect such an action will have.

Not having the original community in the PMC, also means the original community 
looses totally control over what is being releasedis that really fair?

Sorry this is not the ASF I work for an strongly believe in. A project that 
comes to ASF with a community has a right to continue evolve its community as 
PMC with its own trusted people, and we as members need to HELP them if they 
have problems in the apache way NOT replace them.

I really think you need to look at this from both sides and replace 
control/babysitting with help/guidance.

Sorry for this strong worded mail, but I really feel we risk ruining everything 
we stand for.

jan i

>
> Sent from my Windows Phone
> 
> From: Alex Harui<mailto:aha...@adobe.com>
> Sent: ‎1/‎23/‎2015 12:06 PM
> To: general@incubator.apache.org<mailto:general@incubator.apache.org>
> Cc: Chris Mattmann<mailto:mattm...@apache.org>; Jim Jagielski j...@jagunet.com>
> Subject: Re: my pTLP view
>
>
>
> On 1/23/15, 6:53 AM, "jan i"  wrote:
> >
> >I agree with everything else you write, but the demand for "only ASF 
> >Members" seems very hard. If I come to ASF with a community and a 
> >project, I really would feel unhappy being cut out of the loop
>
> Time for my weekly musings.  Sorry, no oaths and anthems this week.
>
> I agree with Jan I.  Thinking back only a few years to when I was new 
> to Apache and going through the incubator, if the original PMC was 
> comprised only of seasoned ASF folks, I would have felt more like 
> those ASF folks were my managers and been more passive about learning 
> about Apache because I would expect these authority figures to train 
> me.  Sometimes the better way to learn is by doing.  IMO, it is better 
> to make folks who really have a stake in the success of the project feel that 
> responsibility.
>
> To me, that’s the problem I’ve having with all of these proposals.  
> They seem too “top-down”, like the podling is a baby in need of true 
> incubation, like hand-holding and feeding.  Really, a podling is made 
> up of adults and “all" I think you really need is to make it clear to 
> newcomers that there is a different culture at Apache and that you are 
> expected to understand it, exercise it, and propagate it to latecomers 
> in order to become a full Apache project.  I just think that coddling 
> new

Re: my pTLP view

[Roman Shaposhnik]

On Fri, Jan 23, 2015 at 2:33 PM, jan i  wrote:
> On Friday, January 23, 2015, Ross Gardler (MS OPEN TECH) <
> ross.gard...@microsoft.com
> > wrote:
>
>> A good mentor is a guide, not a manager.
>>
>> The proposals might seem top down, but when executed correctly, they are
>> not.
>
> No offense but how can you not call it top down, when the people trusted by
> the original community is removed and replaced by a bunch of potentially
> unknown people?

Wait a second here. I think we're talking about two different things (which
is partially my fault). For existing poddlings -- the proposal is to keep
business as usual, unless the podling wishes to join the pTLP crowd.

And for new ones (or existing volunteering for it) the whole point of the
exercise is that it will be their job to recruit the kind of mentors that:
  1. board will trust
  2. the community will trust
Both are hugely important.

Now, if you're asking the question of: why should the original community
be trusted 100% -- the answer is the same as to why we required projects
to incubate to begin with. That trust needs to be built. It can't be assumed.

> Having only ASF members is nearly the sane as saying "hi guys, we accept
> your project if you let us take over", and we ask you not do community
> (only committer)  work until WE deem you worthy of building YOUR community.

It is NOT just their community. It is their community that needs to become
an extension of ASF community. There's give-n-take on both sides here.

> Remember the difference between committer and PMC please. The PPMC today
> plays an important role

Honestly I haven't seen a single podling where PPMC wouldn't be just
an ephemeral concept. In fact, that's part of the reason I keep advoacting
C == PPMC. There's honestly no operational difference today.

> Not having the original community in the PMC, also means the original
> community looses totally control over what is being releasedis that
> really fair?

What makes you say that? The way process works is this: every committer
can suggest a release by offering an artifact for a vote. That vote needs
to clear the +3 PMC, but unless there's a consensus among committers
no sane PMC would bulldoze over that.

I think we're making a mistake here thinking that PPMC == steering committee.
I'd say that Apache Way I know and love is where every single committer
is empowered to be part of the steering committee. PMC does not hold
an exclusive
right on setting technical agenda for the project. In fact, to paraphrase
Chris, PMC is supposed to be all about recruiting business, not so
much technology.

> Sorry this is not the ASF I work for an strongly believe in. A project that
> comes to ASF with a community has a right to continue evolve its community
> as PMC with its own trusted people, and we as members need to HELP them if
> they have problems in the apache way NOT replace them.

Yeah and they will -- that's why that community == original committers.

> Sorry for this strong worded mail, but I really feel we risk ruining
> everything we stand for.

It is good to hash things out. But here's the bit I feel strong about: one
of the things that make me stick with ASF is the core belief in
meritocracy and flat organization structure. That's why committers
MUST hold the keys to the technology roadmap. Even a hint of
the fact that it is PMC would kill the buzz for me.

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: my pTLP view

[Roman Shaposhnik]

On Fri, Jan 23, 2015 at 2:47 PM, Ross Gardler (MS OPEN TECH)
 wrote:
> All that being said, while I will (and already did two years ago) support 
> some experimentation with
> the pTLP model I still feel that an Incubator with teeth scales better.

But we wouldn't know until we try. And that's why I'd be proposing the two
prong approach over the weekend (once I have time to catch up with
all the feedback). The two can be tried in parallel.

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

RE: my pTLP view

[Ross Gardler (MS OPEN TECH)]

+1

Microsoft Open Technologies, Inc.
A subsidiary of Microsoft Corporation

-Original Message-
From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman 
Shaposhnik
Sent: Friday, January 23, 2015 2:51 PM
To: general@incubator.apache.org
Subject: Re: my pTLP view

On Fri, Jan 23, 2015 at 2:47 PM, Ross Gardler (MS OPEN TECH) 
 wrote:
> All that being said, while I will (and already did two years ago) 
> support some experimentation with the pTLP model I still feel that an 
> Incubator with teeth scales better.

But we wouldn't know until we try. And that's why I'd be proposing the two 
prong approach over the weekend (once I have time to catch up with all the 
feedback). The two can be tried in parallel.

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: my pTLP view

[jan i]

On Friday, January 23, 2015, Ross Gardler (MS OPEN TECH) <
ross.gard...@microsoft.com> wrote:

> As ASF member *should* know that empowering the ones doing the work is the
> Apache Way. A good member who is a mentor will ensure that they unblock
> anything that prevents those doing the work having the influence.

correct, and any ASF member knows that that PMC is the driving community
force, we even define the difference roles of committer  and PMC like that.

>
> Look, theoretically, the board have ultimate power over all the projects
> at the ASF. According to the byelaws the board can do anything they want.
> Taking that logic a step further the president can unilaterally do almost
> anything they want. We avoid this situation by only electing people into
> those positions who are not going to abuse that "power" and instead use it
> to empower those doing the work.

and I agree to that, but I cannot see the board force a release, whereas a
PMC full of only ASF members would have to do it, because only the PMC is
responsible for releases with its votes.

>
> I repeat again a good mentor is nothing more than a guide.
>
> So why not make the project community the ones with the authority of a
> PMC? Two main reasons, that I can see:
>
> a) we don't know the newcomers - how can we be sure they we not misuse
> heir "power"?
> b) they hold the keys to the release process, that's what protects the
> contributors legally, we can’t remove that
>
> The pTLP proposal does not change the way things work today. The incoming
> community don't have any voting authority - it's with the mentors and the
> IPMC.


I am sorry but unless I have misunderstood something, the full PPMC votes
for a release and then the IPMC vote to accept or reject it. With the pTLC
proposal ASF members (the PMC)  suggest and accept the release, actually
they can theoretically force a release without asking a single person in
the original community.

This proposal cuts out the PPMC vote, and let ASF members decide when a
release is to be made.

We have a good way today where the community (PPMC) suggest and vote for a
release and the IPMC accept/reject the release.


>
> All that being said, while I will (and already did two years ago) support
> some experimentation with the pTLP model I still feel that an Incubator
> with teeth scales better.

+1

rgds
jan i

>
> Ross
>
> Microsoft Open Technologies, Inc.
> A subsidiary of Microsoft Corporation
>
> -Original Message-
> From: jan i [mailto:j...@apache.org ]
> Sent: Friday, January 23, 2015 2:34 PM
> To: general@incubator.apache.org 
> Subject: my pTLP view
>
> On Friday, January 23, 2015, Ross Gardler (MS OPEN TECH) <
> ross.gard...@microsoft.com   ross.gard...@microsoft.com ');>> wrote:
>
> > A good mentor is a guide, not a manager.
> >
> > The proposals might seem top down, but when executed correctly, they
> > are not.
>
> No offense but how can you not call it top down, when the people trusted
> by the original community is removed and replaced by a bunch of potentially
> unknown people?
>
> Having only ASF members is nearly the sane as saying "hi guys, we accept
> your project if you let us take over", and we ask you not do community
> (only committer)  work until WE deem you worthy of building YOUR community.
> Remember the difference between committer and PMC please. The PPMC today
> plays an important role and you just remove it, and think ASF members can
> replace that without looking at the effect such an action will have.
>
> Not having the original community in the PMC, also means the original
> community looses totally control over what is being releasedis that
> really fair?
>
> Sorry this is not the ASF I work for an strongly believe in. A project
> that comes to ASF with a community has a right to continue evolve its
> community as PMC with its own trusted people, and we as members need to
> HELP them if they have problems in the apache way NOT replace them.
>
> I really think you need to look at this from both sides and replace
> control/babysitting with help/guidance.
>
> Sorry for this strong worded mail, but I really feel we risk ruining
> everything we stand for.
>
> jan i
>
> >
> > Sent from my Windows Phone
> > 
> > From: Alex Harui<mailto:aha...@adobe.com >
> > Sent: ‎1/‎23/‎2015 12:06 PM
> > To: general@incubator.apache.org  general@incubator.apache.org >
> > Cc: Chris Mattmann<mailto:mattm...@apache.org >; Jim
> Jagielski > j...@jagunet.com >
> > Subject: Re: my pTLP view
> >
> >
> >
> > On 1/23/15, 6:53 AM, "jan i" &

RE: my pTLP view

[Ross Gardler (MS OPEN TECH)]

No, the PMC is *not* the driving force. The project community is, even where 
the PMC is a subset of the committers. Since it is the set of active 
*contributors* that are important, they are the ones doing the work.


I don't understand your argument about releases. Nothing changes under under 
the pTLP proposal with respect to how a release is made. In any ASF project the 
full community votes for a release if they want to. Only the PMC have binding 
votes, but they should listen to the community in casting those votes (same is 
true for podlings where the podling community votes on a release but it needs 
to be formalized by the IPMC via its mentors).

Ross

Microsoft Open Technologies, Inc.
A subsidiary of Microsoft Corporation

-Original Message-
From: jan i [mailto:j...@apache.org] 
Sent: Friday, January 23, 2015 3:21 PM
To: general@incubator.apache.org
Subject: Re: my pTLP view

On Friday, January 23, 2015, Ross Gardler (MS OPEN TECH) < 
ross.gard...@microsoft.com> wrote:

> As ASF member *should* know that empowering the ones doing the work is 
> the Apache Way. A good member who is a mentor will ensure that they 
> unblock anything that prevents those doing the work having the influence.

correct, and any ASF member knows that that PMC is the driving community force, 
we even define the difference roles of committer  and PMC like that.

>
> Look, theoretically, the board have ultimate power over all the 
> projects at the ASF. According to the byelaws the board can do anything they 
> want.
> Taking that logic a step further the president can unilaterally do 
> almost anything they want. We avoid this situation by only electing 
> people into those positions who are not going to abuse that "power" 
> and instead use it to empower those doing the work.

and I agree to that, but I cannot see the board force a release, whereas a PMC 
full of only ASF members would have to do it, because only the PMC is 
responsible for releases with its votes.

>
> I repeat again a good mentor is nothing more than a guide.
>
> So why not make the project community the ones with the authority of a 
> PMC? Two main reasons, that I can see:
>
> a) we don't know the newcomers - how can we be sure they we not misuse 
> heir "power"?
> b) they hold the keys to the release process, that's what protects the 
> contributors legally, we can’t remove that
>
> The pTLP proposal does not change the way things work today. The 
> incoming community don't have any voting authority - it's with the 
> mentors and the IPMC.


I am sorry but unless I have misunderstood something, the full PPMC votes for a 
release and then the IPMC vote to accept or reject it. With the pTLC proposal 
ASF members (the PMC)  suggest and accept the release, actually they can 
theoretically force a release without asking a single person in the original 
community.

This proposal cuts out the PPMC vote, and let ASF members decide when a release 
is to be made.

We have a good way today where the community (PPMC) suggest and vote for a 
release and the IPMC accept/reject the release.


>
> All that being said, while I will (and already did two years ago) 
> support some experimentation with the pTLP model I still feel that an 
> Incubator with teeth scales better.

+1

rgds
jan i

>
> Ross
>
> Microsoft Open Technologies, Inc.
> A subsidiary of Microsoft Corporation
>
> -Original Message-
> From: jan i [mailto:j...@apache.org ]
> Sent: Friday, January 23, 2015 2:34 PM
> To: general@incubator.apache.org 
> Subject: my pTLP view
>
> On Friday, January 23, 2015, Ross Gardler (MS OPEN TECH) < 
> ross.gard...@microsoft.com   ross.gard...@microsoft.com ');>> wrote:
>
> > A good mentor is a guide, not a manager.
> >
> > The proposals might seem top down, but when executed correctly, they 
> > are not.
>
> No offense but how can you not call it top down, when the people 
> trusted by the original community is removed and replaced by a bunch 
> of potentially unknown people?
>
> Having only ASF members is nearly the sane as saying "hi guys, we 
> accept your project if you let us take over", and we ask you not do 
> community (only committer)  work until WE deem you worthy of building YOUR 
> community.
> Remember the difference between committer and PMC please. The PPMC 
> today plays an important role and you just remove it, and think ASF 
> members can replace that without looking at the effect such an action will 
> have.
>
> Not having the original community in the PMC, also means the original 
> community looses totally control over what is being releasedis 
> that really fair?
>
> Sorry this is not the ASF I work for an strongly believe in. A project 
&

Re: my pTLP view

[Roman Shaposhnik]

On Fri, Jan 23, 2015 at 4:18 PM, jan i  wrote:
> Remember we talk rules here, and rules should be made so the reflect what
> we want, and I believe it is important that the community is represented in
> the PMC, not 100% but also not 0%.

I still don't understand what's the extra bit of 'shine' that PMC posses
that makes it so desirable? What do you think the original community
(all committers) would NOT be able to do if they are not part of
the PMC? To me, it boils down to two things:
   #1 vote on releases
   #2 vote on new committers
I honestly don't see anything else.

Now, with #1 -- this is business as usual. No changes to IPMC model.
#2 actually raises a good point: if you want to conduct that vote
on private@ how do you make sure the community's vote count?
My answer is simple: open up private to all of the committers on pTLP
(C == PPMC is what most of them should be doing anyway). Make
them vote. Beyond a slight optics issue this is no different from a TLP
PMC conducting a vote and then forwarding it to the board. The board
reserves the right to say 'no', but how many times has it been
exercised?

> I read the rules instead of believing in "should". If a PMC does not like a
> technical direction, they can block it totally within the rules, even if
> all non-PMC prefers it.

No. I don't think they can. Do you know of a precedent?

> I think my problem is that I agree with both you and Roman, The PMC should
> leave technical matters including releases to the total community. But
> alone by talking about "binding" and "non-binding" votes creates two
> levels, and if the PMC does not include the incoming community the
> disconnect gets bigger.

Then, may be, the problem is that our terminology doesn't reflect our
values (and I hope we can all agree which one out of these two
needs to be tweaked).

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: my pTLP view

[Greg Stein]

On Fri, Jan 23, 2015 at 6:18 PM, jan i  wrote:

> On Saturday, January 24, 2015, Ross Gardler (MS OPEN TECH) <
> ross.gard...@microsoft.com
> > wrote:
>
> > No, the PMC is *not* the driving force. The project community is, even
> > where the PMC is a subset of the committers. Since it is the set of
> active
> > *contributors* that are important, they are the ones doing the work.
>
> I totally agree, but pTLC calls for a PMC that can be 0% subset of the
> community, how can the PMC in this situation reflect the community?
>

Because the Board chose to put people onto the PMC that understand: *guide*
the community. Not *rule* the community.

Even better is when the ASF/PMC members are *part* of the community, rather
than just being present to assist with that guidance.

In the current Incubator model, a "Champion" is chosen. That is usually a
person who has some self-interest in the project, and becomes *part* of the
community. So you already have some overlap there.


>
> Remember we talk rules here, and rules should be made so the reflect what
> we want, and I believe it is important that the community is represented in
> the PMC, not 100% but also not 0%.
>

No. We DON'T talk about rules here. I said "create a PMC with a couple
requirements". Then the project does what works best for their community,
within the overall view of what the ASF believes makes a great project.

Rules exist to provide guidance when consensus does not exist. That is all
a rule is good for. A project with a strong consensus model doesn't need
rules.

> > I don't understand your argument about releases. Nothing changes under
> > under the pTLP proposal with respect to how a release is made. In any
ASF
> > project the full community votes for a release if they want to. Only the
> > PMC have binding votes, but they should listen to the community in
casting
> > those votes (same is true for podlings where the podling community
votes on
> > a release but it needs to be formalized by the IPMC via its mentors).

> I read the rules instead of believing in "should". If a PMC does not like
a
> technical direction, they can block it totally within the rules, even if
> all non-PMC prefers it.

Sure... they *could*. How long do you honestly believe the Board would
allow that to continue? Seriously.

You propose a situation that just won't ever happen.

> I think my problem is that I agree with both you and Roman, The PMC should
> leave technical matters including releases to the total community. But
> alone by talking about "binding" and "non-binding" votes creates two
> levels, and if the PMC does not include the incoming community the
> disconnect gets bigger.

There *are* two different levels. That is how it works. Always has. Always
will. Accept that.

But that doesn't mean those with binding votes should (or WOULD!!) ignore
those without. I don't see that happen. Do you? I would guess not. So it
isn't something to worry about.

I also specifically said "ASF Members" because I believe *they* know how to
run a community. Not to use the ASF legal structure against it, but to help
the community work *within* the structure. As Ross said: to empower the
community.

> With pTLC I fear that the incoming community will feel empowered,  the
[ I'm assuming you meant: "not feel empowered" ]
> community does not (according to the rules) need to vote, just let the ASF
> members do the work. With PPMC the podling must make a vote otherwise a
> release will never happen.

That won't happen. The community will do the work. If not, then there
wasn't a community.

You are looking at an extreme failure mode "according to what is possible
in the rules". I am telling you: that won't happen. We don't allow our
communities to do that, and we won't create a PMC that allows that to
happen. And the Board will be reviewing the project to *ensure* it doesn't
happen.

> Again please remember I read the suggested rules and see what could go
> wrong, in a perfect world we would not have wars and every project would
> function perfect.

Your pessimism is unwarranted.

-g

Re: my pTLP view

[Greg Stein]

On Fri, Jan 23, 2015 at 4:33 PM, Alex Harui  wrote:

> On 1/23/15, 1:34 PM, "Ross Gardler (MS OPEN TECH)"
>  wrote:
>
> >A good mentor is a guide, not a manager.
> >
> >The proposals might seem top down, but when executed correctly, they are
> >not.
>
> OK, I'll accept that, but if executed correctly, the current Incubator
> probably doesn't need changing either.
>

Yup. So it keeps doing its thing. The existence of pTLPs at the ASF does
not preclude or replace the Incubator.


>
> IMO, it is hard to find a lot of really dedicated volunteers.  So your
> choices are to work the really good ones really hard, try to "manage"
> other volunteers, or try to find a way to work without really dedicated
> volunteers.
>
> In my experience, the more you try to control and check on these other
> volunteers, the faster they will go away.
>

Sure. And the pTLP allows the community to work at its best, with the
peanut gallery (read: general@incubator and the IPMC) getting in their
face. There are *way* fewer controls/checks in the pTLP approach. It relies
on the ASF members to share their knowledge and to provide the needed
guidance. No extra controls or checks, beyond those of a normal TLP. (well,
except for that "probationary" or "provisional" warning)


>
> Apache has a really great system of accepting code from volunteers with
> limited time.   You don't have to make a time commitment, just occasional
> code commitment.  Can the ASF find a way to teach culture via volunteers
> with limited time?  Probably.  That's why I mentioned the notion of having
> more ASF people involved in a project, but not as the initial PMC.  Real
> communities teach their culture by hanging out around the newcomers, but
> no one person is signed up to do the teaching.  They do it by having lots
> of villagers watching the newbies checking on what the newbies are doing
> and saying when they can.  That's hard to do on email, but if certain
> newbie efforts require a shout out outside their list, then it is easier
> for this larger band of villagers to hear that something important is
> going on.
>

That is certainly a possibility, and has always been possible here in the
Incubator. Hasn't happened. And when you *do* add a whole bunch of people?
Guess what happens? ... John thinks Joe is paying attention. Joe thinks
John is paying attention. Nobody does. The podling goes pear-shaped.

Regardless, nothing about the pTLP proposal interferes with your ability to
test your theory. The pTLP proposal is not exclusionary. You are welcome to
set up a new podling with 20 Mentors.

My proposal is for communities who want to try a different path. It isn't
and won't be the only path.

Based on my personal experience when Apache Subversion went through
incubation... the pTLP approach would have worked much better. We had a
half-dozen ASF Members that could have formed the initial PMC. They would
have added the next 20 right off the bat. And after some IP clearance,
would have been done, and asked for removal of the "provisional" flag. The
community was designed as an Apache community from the start. But the
Incubator attempted to apply checklist items that didn't make sense. Those
checklists were for communities that had no understanding of Apache. The
Incubator model works very well for some, not so well for others.

Mentors are important, yes. And we don't have enough. Mandating they fall
into a single mentoring approach? Or that their available time must be
allocated in a certain way? Nah... Let them follow what interests them, and
to follow their thoughts on shaping a community into a fantastic Apache
community.

Cheers,
-g

Re: my pTLP view

[Andrew Purtell]

I find the direction this discussion has gone personally disappointing, but
I might be missing understanding of some crucial point.

> 2. the initial PMC is comprised of only ASF Members. committers can be
​> ​
chosen however the community decides. but the *project* is reviewed by
​> people with (hopefully/theoretically) experience with the Foundation and
> its views on communities

So should I take my successful project and community to Apache, the first
thing that happens is the foundation creates a Project Management Committee
out of the membership, not the incoming community. This might be fine for
new projects made up of familiar faces, but not where there is new blood.
Those of us in such a new incoming community might get the commit bit but
can't vote on adding committers, or making releases. We don't have a
binding vote on our own committership / fate / ability to manage our own
sources. This situation is primed for mistrust, conflict, and heartache the
second the members and the incoming community disagree about some
substantial aspect of the project direction. The incoming community is
disempowered and has no recourse but to go along with the outcome of Apache
politics or abandon the project. As a responsible steward of my community,
I would never consider bringing my project to Apache under these
circumstances.

This may also increase the risk a project is coming here due to an
excessive fascination with the Apache brand, because otherwise the bargain
seems poor (in my view).


On Fri, Jan 23, 2015 at 5:10 PM, Greg Stein  wrote:

> On Fri, Jan 23, 2015 at 6:18 PM, jan i  wrote:
>
> > On Saturday, January 24, 2015, Ross Gardler (MS OPEN TECH) <
> > ross.gard...@microsoft.com
> > > wrote:
> >
> > > No, the PMC is *not* the driving force. The project community is, even
> > > where the PMC is a subset of the committers. Since it is the set of
> > active
> > > *contributors* that are important, they are the ones doing the work.
> >
> > I totally agree, but pTLC calls for a PMC that can be 0% subset of the
> > community, how can the PMC in this situation reflect the community?
> >
>
> Because the Board chose to put people onto the PMC that understand: *guide*
> the community. Not *rule* the community.
>
> Even better is when the ASF/PMC members are *part* of the community, rather
> than just being present to assist with that guidance.
>
> In the current Incubator model, a "Champion" is chosen. That is usually a
> person who has some self-interest in the project, and becomes *part* of the
> community. So you already have some overlap there.
>
>
> >
> > Remember we talk rules here, and rules should be made so the reflect what
> > we want, and I believe it is important that the community is represented
> in
> > the PMC, not 100% but also not 0%.
> >
>
> No. We DON'T talk about rules here. I said "create a PMC with a couple
> requirements". Then the project does what works best for their community,
> within the overall view of what the ASF believes makes a great project.
>
> Rules exist to provide guidance when consensus does not exist. That is all
> a rule is good for. A project with a strong consensus model doesn't need
> rules.
>
> > > I don't understand your argument about releases. Nothing changes under
> > > under the pTLP proposal with respect to how a release is made. In any
> ASF
> > > project the full community votes for a release if they want to. Only
> the
> > > PMC have binding votes, but they should listen to the community in
> casting
> > > those votes (same is true for podlings where the podling community
> votes on
> > > a release but it needs to be formalized by the IPMC via its mentors).
>
> > I read the rules instead of believing in "should". If a PMC does not like
> a
> > technical direction, they can block it totally within the rules, even if
> > all non-PMC prefers it.
>
> Sure... they *could*. How long do you honestly believe the Board would
> allow that to continue? Seriously.
>
> You propose a situation that just won't ever happen.
>
> > I think my problem is that I agree with both you and Roman, The PMC
> should
> > leave technical matters including releases to the total community. But
> > alone by talking about "binding" and "non-binding" votes creates two
> > levels, and if the PMC does not include the incoming community the
> > disconnect gets bigger.
>
> There *are* two different levels. That is how it works. Always has. Always
> will. Accept that.
>
> But that doesn't mean those with binding votes should (or WOULD!!) ignore
> those without. I don't see that happen. Do you? I would guess not. So it
> isn't something to worry about.
>
> I also specifically said "ASF Members" because I believe *they* know how to
> run a community. Not to use the ASF legal structure against it, but to help
> the community work *within* the structure. As Ross said: to empower the
> community.
>
> > With pTLC I fear that the incoming community will feel empowered,  the
> [ I'm assuming you meant:

Re: my pTLP view

[Roman Shaposhnik]

On Fri, Jan 23, 2015 at 5:42 PM, Andrew Purtell  wrote:
> Those of us in such a new incoming community might get the commit bit but
> can't vote on adding committers,

See my reply to Jan. C == PPMC solves this completely.

> or making releases.

This is *exactly* what is happening today with every single poddling.
Why are you bringing this up as a *new* concern around pTLP?

> We don't have a
> binding vote on our own committership / fate / ability to manage our own
> sources.

I'll be a stickler here: literally  the only new issue that doesn't
exist today is that there won't be a by-law guaranteeing community
that they can *override* ASF members vote on new committers. That is it!
Everything else stays *exactly* the same. Not a single change
to how IPMC *rules* are structured.

> This situation is primed for mistrust, conflict, and heartache the
> second the members and the incoming community disagree about some
> substantial aspect of the project direction. The incoming community is
> disempowered and has no recourse but to go along with the outcome of Apache
> politics or abandon the project. As a responsible steward of my community,
> I would never consider bringing my project to Apache under these
> circumstances.

Wow! This is a pretty gross overstatement if you ask me. Remember,
all of the above is predicated on a *single* possibility. Not even a
guarantee a *possibility*. That ASF PMC members of pTLP will start
actively overriding  votes on adding new members to the community.
This is literally *the only* power they will be getting that doesn't
exist in IPMC today.

The chances of that are slim to none, so I have no choice but to call
the above a strawman.

> This may also increase the risk a project is coming here due to an
> excessive fascination with the Apache brand, because otherwise the bargain
> seems poor (in my view).

Like I said -- we won't know until we try. We will try with *willing*
participants. If they like it and if the board likes it -- we will start
migrating folks. If not -- we'll stop.

Thanks,
Roman.

P.S. This is my time to apologize for harsh tone. But really? Really:
"The incoming community is disempowered and has no recourse
but to go along with the outcome of Apache politics or abandon the project."

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: my pTLP view

[Andrew Purtell]

You are approaching this question with complete trust and faith in the
Apache process, being an Apache member, but an incoming / foreign community
will not have this, not universally. Take the emotion out of this, because
I certainly am not being emotional here, but instead trying to evaluate
this change from the perspective of an outsider. I assume the objective is
to be and remain an inviting place for building community and code,
attracting new blood.

I think everyone can accept an organization has a Board with a final say.
What I find attractive about the current incubation model is Apache
welcomes new communities by making them voting stakeholders in their new
project, they become a PPMC, a podling. Sure, the IPMC provides oversight,
and the board again, but the PPMC can make binding votes on committers,
releases, everything that matters - provisionally, of course, which is
completely acceptable. This all changes if the PMC does not include any
members of the incoming community. There isn't even a provisional ownership
stake in the endeavor. When Apache grants the incoming community a
provisional binding stake in the process, this establishes trust.

I don't agree that the chances ASF PMC members of pTLP will start actively
overriding votes is slim to none.  I've been around here for a while and
spent some time in Hadoop land. The process is not infallable. The
membership is not infallable. To ensure the probability of better outcomes
no matter what happens during an incubation, the incoming community should
be treated more like partners in a common endeavor with a full stake in the
process than what is proposed here.

>
​
The incoming community is disempowered and has no recourse but to go along
with the outcome of Apache politics or abandon the project.

How is this not true? What can the incoming community make a binding vote
on, under this proposal?


On Fri, Jan 23, 2015 at 5:53 PM, Roman Shaposhnik  wrote:

> On Fri, Jan 23, 2015 at 5:42 PM, Andrew Purtell 
> wrote:
> > Those of us in such a new incoming community might get the commit bit but
> > can't vote on adding committers,
>
> See my reply to Jan. C == PPMC solves this completely.
>
> > or making releases.
>
> This is *exactly* what is happening today with every single poddling.
> Why are you bringing this up as a *new* concern around pTLP?
>
> > We don't have a
> > binding vote on our own committership / fate / ability to manage our own
> > sources.
>
> I'll be a stickler here: literally  the only new issue that doesn't
> exist today is that there won't be a by-law guaranteeing community
> that they can *override* ASF members vote on new committers. That is it!
> Everything else stays *exactly* the same. Not a single change
> to how IPMC *rules* are structured.
>
> > This situation is primed for mistrust, conflict, and heartache the
> > second the members and the incoming community disagree about some
> > substantial aspect of the project direction. The incoming community is
> > disempowered and has no recourse but to go along with the outcome of
> Apache
> > politics or abandon the project. As a responsible steward of my
> community,
> > I would never consider bringing my project to Apache under these
> > circumstances.
>
> Wow! This is a pretty gross overstatement if you ask me. Remember,
> all of the above is predicated on a *single* possibility. Not even a
> guarantee a *possibility*. That ASF PMC members of pTLP will start
> actively overriding  votes on adding new members to the community.
> This is literally *the only* power they will be getting that doesn't
> exist in IPMC today.
>
> The chances of that are slim to none, so I have no choice but to call
> the above a strawman.
>
> > This may also increase the risk a project is coming here due to an
> > excessive fascination with the Apache brand, because otherwise the
> bargain
> > seems poor (in my view).
>
> Like I said -- we won't know until we try. We will try with *willing*
> participants. If they like it and if the board likes it -- we will start
> migrating folks. If not -- we'll stop.
>
> Thanks,
> Roman.
>
> P.S. This is my time to apologize for harsh tone. But really? Really:
> "
> ​​
> The incoming community is disempowered and has no recourse
> but to go along with the outcome of Apache politics or abandon the
> project."
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: my pTLP view

[Niclas Hedhman]

On Sat, Jan 24, 2015 at 5:34 AM, Ross Gardler (MS OPEN TECH) <
ross.gard...@microsoft.com> wrote:

> A good mentor is a guide, not a manager.
>
>
And a good manager is a Mentor ;-)

Niclas

Re: my pTLP view

[Greg Stein]

On Fri, Jan 23, 2015 at 8:08 PM, Andrew Purtell  wrote:
>...

> project, they become a PPMC, a podling. Sure, the IPMC provides oversight,
> and the board again, but the PPMC can make binding votes on committers,
> releases, everything that matters - provisionally, of course, which is
> completely acceptable.


"provisionally, of course" .. that is exactly Roman's point. TODAY, the
PPMC has no ownership. It is completely subjugated to the whims of the IPMC.

The pTLP concept replaces the IPMC with a group of a few ASF Members that
are dedicated/interested in that specific community. The community doesn't
end up with 100+ random IPMC members who care less about the community.
Instead, it gets some volunteers who are responsible to listen, to guide,
and to assist the community with becoming part of the Foundation.

That community can still create consensus. And the PMC will/should obey
that consensus. If it does NOT, then the Board axes them. Every PMC works
this way. Always has.

The PMC may be "all powerful" (or more specifically: the VP singularly),
but when the Board hears that a VP or a PMC is working against the
community? Shit gets real, and heads start to roll. The Board doesn't take
kindly to that.

This all changes if the PMC does not include any
> members of the incoming community. There isn't even a provisional ownership
> stake in the endeavor. When Apache grants the incoming community a
> provisional binding stake in the process, this establishes trust.
>

The incoming community has NEVER had a stake in the outcome. That's what
Roman has been trying to say.

You seem to be under the impression that the PMC will work against the
community. That is a baseless opinion. Name a precedent.

I've been here for 16+ years. I haven't seen that yet. As a Director for
almost 14 years, I have reviewed *thousands* of project reports. Read
umpteen mailing lists. Reviewed archives. Investigated JIRA conflicts. Not
once have I seen a PMC actively work against its community, as you describe.

Have you? Would love a pointer, if you have one.


> I don't agree that the chances ASF PMC members of pTLP will start actively
> overriding votes is slim to none.  I've been around here for a while and
> spent some time in Hadoop land. The process is not infallable. The
> membership is not infallable. To ensure the probability of better outcomes
> no matter what happens during an incubation, the incoming community should
> be treated more like partners in a common endeavor with a full stake in the
> process than what is proposed here.
>

Again, you believe the PMC won't act as partners. I call bullshit.

Cheers,
-g

RE: my pTLP view

[Ross Gardler (MS OPEN TECH)]

What makes you think the PPMC today had more influence than the contributors to 
a pushing?

Votes have been mentioned, but votes remain the same. Despite what people on 
this thread are saying PPMC members do not have a binding vote. That does not 
change.

Besides, the whole thing is moot because pTLP is an *option*

Sent from my Windows Phone

From: Andrew Purtell<mailto:apurt...@apache.org>
Sent: ‎1/‎23/‎2015 6:09 PM
To: general@incubator.apache.org<mailto:general@incubator.apache.org>
Subject: Re: my pTLP view

You are approaching this question with complete trust and faith in the
Apache process, being an Apache member, but an incoming / foreign community
will not have this, not universally. Take the emotion out of this, because
I certainly am not being emotional here, but instead trying to evaluate
this change from the perspective of an outsider. I assume the objective is
to be and remain an inviting place for building community and code,
attracting new blood.

I think everyone can accept an organization has a Board with a final say.
What I find attractive about the current incubation model is Apache
welcomes new communities by making them voting stakeholders in their new
project, they become a PPMC, a podling. Sure, the IPMC provides oversight,
and the board again, but the PPMC can make binding votes on committers,
releases, everything that matters - provisionally, of course, which is
completely acceptable. This all changes if the PMC does not include any
members of the incoming community. There isn't even a provisional ownership
stake in the endeavor. When Apache grants the incoming community a
provisional binding stake in the process, this establishes trust.

I don't agree that the chances ASF PMC members of pTLP will start actively
overriding votes is slim to none.  I've been around here for a while and
spent some time in Hadoop land. The process is not infallable. The
membership is not infallable. To ensure the probability of better outcomes
no matter what happens during an incubation, the incoming community should
be treated more like partners in a common endeavor with a full stake in the
process than what is proposed here.

>
​
The incoming community is disempowered and has no recourse but to go along
with the outcome of Apache politics or abandon the project.

How is this not true? What can the incoming community make a binding vote
on, under this proposal?


On Fri, Jan 23, 2015 at 5:53 PM, Roman Shaposhnik  wrote:

> On Fri, Jan 23, 2015 at 5:42 PM, Andrew Purtell 
> wrote:
> > Those of us in such a new incoming community might get the commit bit but
> > can't vote on adding committers,
>
> See my reply to Jan. C == PPMC solves this completely.
>
> > or making releases.
>
> This is *exactly* what is happening today with every single poddling.
> Why are you bringing this up as a *new* concern around pTLP?
>
> > We don't have a
> > binding vote on our own committership / fate / ability to manage our own
> > sources.
>
> I'll be a stickler here: literally  the only new issue that doesn't
> exist today is that there won't be a by-law guaranteeing community
> that they can *override* ASF members vote on new committers. That is it!
> Everything else stays *exactly* the same. Not a single change
> to how IPMC *rules* are structured.
>
> > This situation is primed for mistrust, conflict, and heartache the
> > second the members and the incoming community disagree about some
> > substantial aspect of the project direction. The incoming community is
> > disempowered and has no recourse but to go along with the outcome of
> Apache
> > politics or abandon the project. As a responsible steward of my
> community,
> > I would never consider bringing my project to Apache under these
> > circumstances.
>
> Wow! This is a pretty gross overstatement if you ask me. Remember,
> all of the above is predicated on a *single* possibility. Not even a
> guarantee a *possibility*. That ASF PMC members of pTLP will start
> actively overriding  votes on adding new members to the community.
> This is literally *the only* power they will be getting that doesn't
> exist in IPMC today.
>
> The chances of that are slim to none, so I have no choice but to call
> the above a strawman.
>
> > This may also increase the risk a project is coming here due to an
> > excessive fascination with the Apache brand, because otherwise the
> bargain
> > seems poor (in my view).
>
> Like I said -- we won't know until we try. We will try with *willing*
> participants. If they like it and if the board likes it -- we will start
> migrating folks. If not -- we'll stop.
>
> Thanks,
> Roman.
>
> P.S. This is my time to apologize fo

Re: my pTLP view

[Andrew Purtell]

With a PPMC we invite newcomers to make votes we call binding on matters of
their own project. Under the pTLP proposal they will not have this unless
they happen to already be part of the Apache membership. I don't find it a
distinction without a difference. I think it withholds an ownership stake
in the process. All of this may be word games on some level, but words do
matter.



On Fri, Jan 23, 2015 at 11:01 PM, Ross Gardler (MS OPEN TECH) <
ross.gard...@microsoft.com> wrote:

> What makes you think the PPMC today had more influence than the
> contributors to a pushing?
>
> Votes have been mentioned, but votes remain the same. Despite what people
> on this thread are saying PPMC members do not have a binding vote. That
> does not change.
>
> Besides, the whole thing is moot because pTLP is an *option*
>
> Sent from my Windows Phone
> 
> From: Andrew Purtell<mailto:apurt...@apache.org>
> Sent: ‎1/‎23/‎2015 6:09 PM
> To: general@incubator.apache.org<mailto:general@incubator.apache.org>
> Subject: Re: my pTLP view
>
> You are approaching this question with complete trust and faith in the
> Apache process, being an Apache member, but an incoming / foreign community
> will not have this, not universally. Take the emotion out of this, because
> I certainly am not being emotional here, but instead trying to evaluate
> this change from the perspective of an outsider. I assume the objective is
> to be and remain an inviting place for building community and code,
> attracting new blood.
>
> I think everyone can accept an organization has a Board with a final say.
> What I find attractive about the current incubation model is Apache
> welcomes new communities by making them voting stakeholders in their new
> project, they become a PPMC, a podling. Sure, the IPMC provides oversight,
> and the board again, but the PPMC can make binding votes on committers,
> releases, everything that matters - provisionally, of course, which is
> completely acceptable. This all changes if the PMC does not include any
> members of the incoming community. There isn't even a provisional ownership
> stake in the endeavor. When Apache grants the incoming community a
> provisional binding stake in the process, this establishes trust.
>
> I don't agree that the chances ASF PMC members of pTLP will start actively
> overriding votes is slim to none.  I've been around here for a while and
> spent some time in Hadoop land. The process is not infallable. The
> membership is not infallable. To ensure the probability of better outcomes
> no matter what happens during an incubation, the incoming community should
> be treated more like partners in a common endeavor with a full stake in the
> process than what is proposed here.
>
> >
> ​
> The incoming community is disempowered and has no recourse but to go along
> with the outcome of Apache politics or abandon the project.
>
> How is this not true? What can the incoming community make a binding vote
> on, under this proposal?
>
>
> On Fri, Jan 23, 2015 at 5:53 PM, Roman Shaposhnik  wrote:
>
> > On Fri, Jan 23, 2015 at 5:42 PM, Andrew Purtell 
> > wrote:
> > > Those of us in such a new incoming community might get the commit bit
> but
> > > can't vote on adding committers,
> >
> > See my reply to Jan. C == PPMC solves this completely.
> >
> > > or making releases.
> >
> > This is *exactly* what is happening today with every single poddling.
> > Why are you bringing this up as a *new* concern around pTLP?
> >
> > > We don't have a
> > > binding vote on our own committership / fate / ability to manage our
> own
> > > sources.
> >
> > I'll be a stickler here: literally  the only new issue that doesn't
> > exist today is that there won't be a by-law guaranteeing community
> > that they can *override* ASF members vote on new committers. That is it!
> > Everything else stays *exactly* the same. Not a single change
> > to how IPMC *rules* are structured.
> >
> > > This situation is primed for mistrust, conflict, and heartache the
> > > second the members and the incoming community disagree about some
> > > substantial aspect of the project direction. The incoming community is
> > > disempowered and has no recourse but to go along with the outcome of
> > Apache
> > > politics or abandon the project. As a responsible steward of my
> > community,
> > > I would never consider bringing my project to Apache under these
> > > circumstances.
> >
> > Wow! This is a pretty gross overstatement if you ask me. Remember,

Re: my pTLP view

[Branko Čibej]

On 25.01.2015 19:16, Andrew Purtell wrote:
> With a PPMC we invite newcomers to make votes we call binding on matters of
> their own project.

As other people have said, PPMC members (that are not also IPMC members)
do not have binding votes, neither for releases nor for inviting new
committers/PPMC members. The "binding" bit lies with the IPMC, which can
revoke any formal decision made by the PPMC.

That hardly ever happens (it's most likely when there are problems with
a podling's first few releases), which is why you get the impression
that the PPMC can make binding decisions. In this respect, there's no
practical difference between the current IPMC model and the proposed
pTLP model.

Of course, when it comes to /technical/ decisions, there's no such thing
as a vote, so the term "binding" does not apply. Consensus, of one form
or another, always rules: and the IPMC or mentors can't meddle in this case.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: my pTLP view

[Andrew Purtell]

> That hardly ever happens (it's most likely when there are problems with
​> ​
a podling's first few releases), which is why you get the impression
​> ​
that the PPMC can make binding decisions.

​Close. The PPMC membership feels they have made a decision that matters
with equal input.
Certainly on PPMCs I've been on,
​there is awareness that everything is
provisional
​. Still, a
 process takes place on PPMC mailing lists leading to a tallied outcome.
The input that leads to this output is the consensus or voting of *a group
of equal peers*.
​ This output is handed to the IPMC in aggregate. ​
When casting votes on the PPMC lists there are no +1 (binding) or +1
(non-binding) distinctions made. PPMC sends the outcome over to the IPMC
feeling some level of ownership having just participated in a decision
making process as equal
​s​
. (Or at least so I think, in some perhaps quaint notion.) Of course in
IPMC voting it is different, but the IPMC is where supervision happens, or
doesn't, as some argue.


On Sun, Jan 25, 2015 at 10:35 AM, Branko Čibej  wrote:

> On 25.01.2015 19:16, Andrew Purtell wrote:
> > With a PPMC we invite newcomers to make votes we call binding on matters
> of
> > their own project.
>
> As other people have said, PPMC members (that are not also IPMC members)
> do not have binding votes, neither for releases nor for inviting new
> committers/PPMC members. The "binding" bit lies with the IPMC, which can
> revoke any formal decision made by the PPMC.
>
> That hardly ever happens (it's most likely when there are problems with
> a podling's first few releases), which is why you get the impression
> that the PPMC can make binding decisions. In this respect, there's no
> practical difference between the current IPMC model and the proposed
> pTLP model.
>
> Of course, when it comes to /technical/ decisions, there's no such thing
> as a vote, so the term "binding" does not apply. Consensus, of one form
> or another, always rules: and the IPMC or mentors can't meddle in this
> case.
>
> -- Brane
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: my pTLP view

[Branko Čibej]

On 25.01.2015 19:51, Andrew Purtell wrote:
>> That hardly ever happens (it's most likely when there are problems with
> ​> ​
> a podling's first few releases), which is why you get the impression
> ​> ​
> that the PPMC can make binding decisions.
>
> ​Close. The PPMC membership feels they have made a decision that matters
> with equal input.
> Certainly on PPMCs I've been on,
> ​there is awareness that everything is
> provisional
> ​. Still, a
>  process takes place on PPMC mailing lists leading to a tallied outcome.
> The input that leads to this output is the consensus or voting of *a group
> of equal peers*.
> ​ This output is handed to the IPMC in aggregate. ​
> When casting votes on the PPMC lists there are no +1 (binding) or +1
> (non-binding) distinctions made. PPMC sends the outcome over to the IPMC
> feeling some level of ownership having just participated in a decision
> making process as equal
> ​s​
> . (Or at least so I think, in some perhaps quaint notion.) Of course in
> IPMC voting it is different, but the IPMC is where supervision happens, or
> doesn't, as some argue.

This is *exactly* the way things work in a TLP. Any committer can
propose a release. The PMC must (!) start a (public) vote. Anyone can
vote, with PMC votes being binding. /Any/ -1 vote, either from PMC
member or plain committer, should block the release and trigger a
discussion to find a solution; and in this discussion (which purpose is
to reach consensus on a solution), PMC members have no more voice than
any other community member.

If the PMC decides to ignore a -1 on a release vote, they'd better have
really good reasons for that, or I'd expect the Board to come down like
a ton of bricks on that PMC.

The situation is slightly different with new committer/PMC member
nominations and votes, which are private; you have a point there.

-- Brane

> On Sun, Jan 25, 2015 at 10:35 AM, Branko Čibej  wrote:
>
>> On 25.01.2015 19:16, Andrew Purtell wrote:
>>> With a PPMC we invite newcomers to make votes we call binding on matters
>> of
>>> their own project.
>> As other people have said, PPMC members (that are not also IPMC members)
>> do not have binding votes, neither for releases nor for inviting new
>> committers/PPMC members. The "binding" bit lies with the IPMC, which can
>> revoke any formal decision made by the PPMC.
>>
>> That hardly ever happens (it's most likely when there are problems with
>> a podling's first few releases), which is why you get the impression
>> that the PPMC can make binding decisions. In this respect, there's no
>> practical difference between the current IPMC model and the proposed
>> pTLP model.
>>
>> Of course, when it comes to /technical/ decisions, there's no such thing
>> as a vote, so the term "binding" does not apply. Consensus, of one form
>> or another, always rules: and the IPMC or mentors can't meddle in this
>> case.
>>
>> -- Brane
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: my pTLP view

[Andrew Purtell]

> This is *exactly* the way things work in a TLP.

Yes, everyone new to the Foundation on the PPMC has a sense of equal
ownership in the process. The PPMC makes a decision together as equals,
then the decision is reviewed as a whole. But this is not how things would
work in a pTLP, right? Individuals there would effectively cast votes +1
(binding), or -1 (binding), +1 (non-binding), or -1 (non-binding), etc.,
depending if they are a Member or not. Maybe in practice the pTLP PMC
wouldn't write down their votes like that, but somehow the distinction must
be presented in the tallies to be meaningful.



On Sun, Jan 25, 2015 at 11:11 AM, Branko Čibej  wrote:

> On 25.01.2015 19:51, Andrew Purtell wrote:
> >> That hardly ever happens (it's most likely when there are problems with
> > ​> ​
> > a podling's first few releases), which is why you get the impression
> > ​> ​
> > that the PPMC can make binding decisions.
> >
> > ​Close. The PPMC membership feels they have made a decision that matters
> > with equal input.
> > Certainly on PPMCs I've been on,
> > ​there is awareness that everything is
> > provisional
> > ​. Still, a
> >  process takes place on PPMC mailing lists leading to a tallied outcome.
> > The input that leads to this output is the consensus or voting of *a
> group
> > of equal peers*.
> > ​ This output is handed to the IPMC in aggregate. ​
> > When casting votes on the PPMC lists there are no +1 (binding) or +1
> > (non-binding) distinctions made. PPMC sends the outcome over to the IPMC
> > feeling some level of ownership having just participated in a decision
> > making process as equal
> > ​s​
> > . (Or at least so I think, in some perhaps quaint notion.) Of course in
> > IPMC voting it is different, but the IPMC is where supervision happens,
> or
> > doesn't, as some argue.
>
> This is *exactly* the way things work in a TLP. Any committer can
> propose a release. The PMC must (!) start a (public) vote. Anyone can
> vote, with PMC votes being binding. /Any/ -1 vote, either from PMC
> member or plain committer, should block the release and trigger a
> discussion to find a solution; and in this discussion (which purpose is
> to reach consensus on a solution), PMC members have no more voice than
> any other community member.
>
> If the PMC decides to ignore a -1 on a release vote, they'd better have
> really good reasons for that, or I'd expect the Board to come down like
> a ton of bricks on that PMC.
>
> The situation is slightly different with new committer/PMC member
> nominations and votes, which are private; you have a point there.
>
> -- Brane
>
> > On Sun, Jan 25, 2015 at 10:35 AM, Branko Čibej  wrote:
> >
> >> On 25.01.2015 19:16, Andrew Purtell wrote:
> >>> With a PPMC we invite newcomers to make votes we call binding on
> matters
> >> of
> >>> their own project.
> >> As other people have said, PPMC members (that are not also IPMC members)
> >> do not have binding votes, neither for releases nor for inviting new
> >> committers/PPMC members. The "binding" bit lies with the IPMC, which can
> >> revoke any formal decision made by the PPMC.
> >>
> >> That hardly ever happens (it's most likely when there are problems with
> >> a podling's first few releases), which is why you get the impression
> >> that the PPMC can make binding decisions. In this respect, there's no
> >> practical difference between the current IPMC model and the proposed
> >> pTLP model.
> >>
> >> Of course, when it comes to /technical/ decisions, there's no such thing
> >> as a vote, so the term "binding" does not apply. Consensus, of one form
> >> or another, always rules: and the IPMC or mentors can't meddle in this
> >> case.
> >>
> >> -- Brane
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: my pTLP view

[Andrew Purtell]

Oh, my mistake! (smile) I confused pTLP with the "Strawman" proposal there
for a minute. In the pTLP proposal, there are no new-to-the-Foundation
project members on the pTLP PMC.

"All proposals for new ASF projects must include an initial PMC chair and
an initial set of PMC members. These people must be acceptable to the
board. It is the responsibility of the Incubator Committee to vett these
people. All of them must have experience on existing PMCs"


Newcomers to Apache *might* get committership depending how the
only-members-as-PMC decide. They don't get even non-binding stakeholdership
in decisionmaking on new commiters, releases, and so on.


On Sun, Jan 25, 2015 at 11:49 AM, Andrew Purtell 
wrote:

> > This is *exactly* the way things work in a TLP.
>
> Yes, everyone new to the Foundation on the PPMC has a sense of equal
> ownership in the process. The PPMC makes a decision together as equals,
> then the decision is reviewed as a whole. But this is not how things
> would work in a pTLP, right? Individuals there would effectively cast
> votes +1 (binding), or -1 (binding), +1 (non-binding), or -1
> (non-binding), etc., depending if they are a Member or not. Maybe in
> practice the pTLP PMC wouldn't write down their votes like that, but
> somehow the distinction must be presented in the tallies to be meaningful.
>
>
>
> On Sun, Jan 25, 2015 at 11:11 AM, Branko Čibej  wrote:
>
>> On 25.01.2015 19:51, Andrew Purtell wrote:
>> >> That hardly ever happens (it's most likely when there are problems with
>> > ​> ​
>> > a podling's first few releases), which is why you get the impression
>> > ​> ​
>> > that the PPMC can make binding decisions.
>> >
>> > ​Close. The PPMC membership feels they have made a decision that matters
>> > with equal input.
>> > Certainly on PPMCs I've been on,
>> > ​there is awareness that everything is
>> > provisional
>> > ​. Still, a
>> >  process takes place on PPMC mailing lists leading to a tallied outcome.
>> > The input that leads to this output is the consensus or voting of *a
>> group
>> > of equal peers*.
>> > ​ This output is handed to the IPMC in aggregate. ​
>> > When casting votes on the PPMC lists there are no +1 (binding) or +1
>> > (non-binding) distinctions made. PPMC sends the outcome over to the IPMC
>> > feeling some level of ownership having just participated in a decision
>> > making process as equal
>> > ​s​
>> > . (Or at least so I think, in some perhaps quaint notion.) Of course in
>> > IPMC voting it is different, but the IPMC is where supervision happens,
>> or
>> > doesn't, as some argue.
>>
>> This is *exactly* the way things work in a TLP. Any committer can
>> propose a release. The PMC must (!) start a (public) vote. Anyone can
>> vote, with PMC votes being binding. /Any/ -1 vote, either from PMC
>> member or plain committer, should block the release and trigger a
>> discussion to find a solution; and in this discussion (which purpose is
>> to reach consensus on a solution), PMC members have no more voice than
>> any other community member.
>>
>> If the PMC decides to ignore a -1 on a release vote, they'd better have
>> really good reasons for that, or I'd expect the Board to come down like
>> a ton of bricks on that PMC.
>>
>> The situation is slightly different with new committer/PMC member
>> nominations and votes, which are private; you have a point there.
>>
>> -- Brane
>>
>> > On Sun, Jan 25, 2015 at 10:35 AM, Branko Čibej 
>> wrote:
>> >
>> >> On 25.01.2015 19:16, Andrew Purtell wrote:
>> >>> With a PPMC we invite newcomers to make votes we call binding on
>> matters
>> >> of
>> >>> their own project.
>> >> As other people have said, PPMC members (that are not also IPMC
>> members)
>> >> do not have binding votes, neither for releases nor for inviting new
>> >> committers/PPMC members. The "binding" bit lies with the IPMC, which
>> can
>> >> revoke any formal decision made by the PPMC.
>> >>
>> >> That hardly ever happens (it's most likely when there are problems with
>> >> a podling's first few releases), which is why you get the impression
>> >> that the PPMC can make binding decisions. In this respect, there's no
>> >> practical difference between the current IPMC model and the proposed
>> >> pTLP model.
>> >>
>> >> Of course, when it comes to /technical/ decisions, there's no such
>> thing
>> >> as a vote, so the term "binding" does not apply. Consensus, of one form
>> >> or another, always rules: and the IPMC or mentors can't meddle in this
>> >> case.
>> >>
>> >> -- Brane
>> >>
>> >>
>> >> -
>> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> >> For additional commands, e-mail: general-h...@incubator.apache.org
>> >>
>> >>
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>
>

Re: my pTLP view

[Greg Stein]

On Sun, Jan 25, 2015 at 1:49 PM, Andrew Purtell  wrote:

> > This is *exactly* the way things work in a TLP.
>
> Yes, everyone new to the Foundation on the PPMC has a sense of equal
> ownership in the process. The PPMC makes a decision together as equals,
> then the decision is reviewed as a whole. But this is not how things would
> work in a pTLP, right? Individuals there would effectively cast votes +1
> (binding), or -1 (binding), +1 (non-binding), or -1 (non-binding), etc.,
> depending if they are a Member or not. Maybe in practice the pTLP PMC
> wouldn't write down their votes like that, but somehow the distinction must
> be presented in the tallies to be meaningful.
>

Nah. First: votes should be rare in the first place. Go for consensus
instead. Apache Subversion has had maybe 3 votes in its 15 year history.

And if you *do* end up voting? People already know who is binding or not.
This isn't some star chamber PMC. Everybody knows each other already. If
the PMC is voting differently from the others, then you have a problem,
regardless of not/binding.

Anyways... we'll run the experiment, and see how it works. We may have a
candidate already.

Cheers,
-g

Re: my pTLP view

[Andrew Purtell]

In all of the projects I have been PMC or PPMC on, we vote on releases, new
committers, and elevating committers to PMC.


On Sun, Jan 25, 2015 at 11:56 AM, Greg Stein  wrote:

> On Sun, Jan 25, 2015 at 1:49 PM, Andrew Purtell 
> wrote:
>
> > > This is *exactly* the way things work in a TLP.
> >
> > Yes, everyone new to the Foundation on the PPMC has a sense of equal
> > ownership in the process. The PPMC makes a decision together as equals,
> > then the decision is reviewed as a whole. But this is not how things
> would
> > work in a pTLP, right? Individuals there would effectively cast votes +1
> > (binding), or -1 (binding), +1 (non-binding), or -1 (non-binding), etc.,
> > depending if they are a Member or not. Maybe in practice the pTLP PMC
> > wouldn't write down their votes like that, but somehow the distinction
> must
> > be presented in the tallies to be meaningful.
> >
>
> Nah. First: votes should be rare in the first place. Go for consensus
> instead. Apache Subversion has had maybe 3 votes in its 15 year history.
>
> And if you *do* end up voting? People already know who is binding or not.
> This isn't some star chamber PMC. Everybody knows each other already. If
> the PMC is voting differently from the others, then you have a problem,
> regardless of not/binding.
>
> Anyways... we'll run the experiment, and see how it works. We may have a
> candidate already.
>
> Cheers,
> -g
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: my pTLP view

[Greg Stein]

Apache Subversion uses discussion/consensus for all of those. We throw out
+1 and similar as shorthand for our preference, but we never tally, as it
isn't a formal vote.

On Sun, Jan 25, 2015 at 1:58 PM, Andrew Purtell  wrote:

> In all of the projects I have been PMC or PPMC on, we vote on releases, new
> committers, and elevating committers to PMC.
>
>
> On Sun, Jan 25, 2015 at 11:56 AM, Greg Stein  wrote:
>
> > On Sun, Jan 25, 2015 at 1:49 PM, Andrew Purtell 
> > wrote:
> >
> > > > This is *exactly* the way things work in a TLP.
> > >
> > > Yes, everyone new to the Foundation on the PPMC has a sense of equal
> > > ownership in the process. The PPMC makes a decision together as equals,
> > > then the decision is reviewed as a whole. But this is not how things
> > would
> > > work in a pTLP, right? Individuals there would effectively cast votes
> +1
> > > (binding), or -1 (binding), +1 (non-binding), or -1 (non-binding),
> etc.,
> > > depending if they are a Member or not. Maybe in practice the pTLP PMC
> > > wouldn't write down their votes like that, but somehow the distinction
> > must
> > > be presented in the tallies to be meaningful.
> > >
> >
> > Nah. First: votes should be rare in the first place. Go for consensus
> > instead. Apache Subversion has had maybe 3 votes in its 15 year history.
> >
> > And if you *do* end up voting? People already know who is binding or not.
> > This isn't some star chamber PMC. Everybody knows each other already. If
> > the PMC is voting differently from the others, then you have a problem,
> > regardless of not/binding.
> >
> > Anyways... we'll run the experiment, and see how it works. We may have a
> > candidate already.
> >
> > Cheers,
> > -g
> >
>
>
>
> --
> Best regards,
>
>- Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

Re: my pTLP view

[Greg Stein]

Go to the FIRST POST of this thread (titled: "my pTLP view"!!). THAT is
what we're talking about. Not the Strawman.

On Sun, Jan 25, 2015 at 1:56 PM, Andrew Purtell  wrote:

> Oh, my mistake! (smile) I confused pTLP with the "Strawman" proposal there
> for a minute. In the pTLP proposal, there are no new-to-the-Foundation
> project members on the pTLP PMC.
>
> "All proposals for new ASF projects must include an initial PMC chair and
> an initial set of PMC members. These people must be acceptable to the
> board. It is the responsibility of the Incubator Committee to vett these
> people. All of them must have experience on existing PMCs"
>
>
> Newcomers to Apache *might* get committership depending how the
> only-members-as-PMC decide. They don't get even non-binding stakeholdership
> in decisionmaking on new commiters, releases, and so on.
>
>
> On Sun, Jan 25, 2015 at 11:49 AM, Andrew Purtell 
> wrote:
>
> > > This is *exactly* the way things work in a TLP.
> >
> > Yes, everyone new to the Foundation on the PPMC has a sense of equal
> > ownership in the process. The PPMC makes a decision together as equals,
> > then the decision is reviewed as a whole. But this is not how things
> > would work in a pTLP, right? Individuals there would effectively cast
> > votes +1 (binding), or -1 (binding), +1 (non-binding), or -1
> > (non-binding), etc., depending if they are a Member or not. Maybe in
> > practice the pTLP PMC wouldn't write down their votes like that, but
> > somehow the distinction must be presented in the tallies to be
> meaningful.
> >
> >
> >
> > On Sun, Jan 25, 2015 at 11:11 AM, Branko Čibej  wrote:
> >
> >> On 25.01.2015 19:51, Andrew Purtell wrote:
> >> >> That hardly ever happens (it's most likely when there are problems
> with
> >> > ​> ​
> >> > a podling's first few releases), which is why you get the impression
> >> > ​> ​
> >> > that the PPMC can make binding decisions.
> >> >
> >> > ​Close. The PPMC membership feels they have made a decision that
> matters
> >> > with equal input.
> >> > Certainly on PPMCs I've been on,
> >> > ​there is awareness that everything is
> >> > provisional
> >> > ​. Still, a
> >> >  process takes place on PPMC mailing lists leading to a tallied
> outcome.
> >> > The input that leads to this output is the consensus or voting of *a
> >> group
> >> > of equal peers*.
> >> > ​ This output is handed to the IPMC in aggregate. ​
> >> > When casting votes on the PPMC lists there are no +1 (binding) or +1
> >> > (non-binding) distinctions made. PPMC sends the outcome over to the
> IPMC
> >> > feeling some level of ownership having just participated in a decision
> >> > making process as equal
> >> > ​s​
> >> > . (Or at least so I think, in some perhaps quaint notion.) Of course
> in
> >> > IPMC voting it is different, but the IPMC is where supervision
> happens,
> >> or
> >> > doesn't, as some argue.
> >>
> >> This is *exactly* the way things work in a TLP. Any committer can
> >> propose a release. The PMC must (!) start a (public) vote. Anyone can
> >> vote, with PMC votes being binding. /Any/ -1 vote, either from PMC
> >> member or plain committer, should block the release and trigger a
> >> discussion to find a solution; and in this discussion (which purpose is
> >> to reach consensus on a solution), PMC members have no more voice than
> >> any other community member.
> >>
> >> If the PMC decides to ignore a -1 on a release vote, they'd better have
> >> really good reasons for that, or I'd expect the Board to come down like
> >> a ton of bricks on that PMC.
> >>
> >> The situation is slightly different with new committer/PMC member
> >> nominations and votes, which are private; you have a point there.
> >>
> >> -- Brane
> >>
> >> > On Sun, Jan 25, 2015 at 10:35 AM, Branko Čibej 
> >> wrote:
> >> >
> >> >> On 25.01.2015 19:16, Andrew Purtell wrote:
> >> >>> With a PPMC we invite newcomers to make votes we call binding on
> >> matters
> >> >> of
> >> >>> their own project.
> >> >> As other people have said, PPMC members (that are not also IPMC
> >> members)
> >> >> do not have binding votes, neither for releases nor for inviting new
> >> >> committers/PPMC members. The "binding" bit lies with the IPMC, which
> >> can
> >> >> revoke any formal decision made by the PPMC.
> >> >>
> >> >> That hardly ever happens (it's most likely when there are problems
> with
> >> >> a podling's first few releases), which is why you get the impression
> >> >> that the PPMC can make binding decisions. In this respect, there's no
> >> >> practical difference between the current IPMC model and the proposed
> >> >> pTLP model.
> >> >>
> >> >> Of course, when it comes to /technical/ decisions, there's no such
> >> thing
> >> >> as a vote, so the term "binding" does not apply. Consensus, of one
> form
> >> >> or another, always rules: and the IPMC or mentors can't meddle in
> this
> >> >> case.
> >> >>
> >> >> -- Brane
> >> >>
> >> >>
> >> >> 

Re: my pTLP view

[Andrew Purtell]

Yes, and I briefly confused the two, and fessed up.

On Sun, Jan 25, 2015 at 12:03 PM, Greg Stein  wrote:

> Go to the FIRST POST of this thread (titled: "my pTLP view"!!). THAT is
> what we're talking about. Not the Strawman.
>
> On Sun, Jan 25, 2015 at 1:56 PM, Andrew Purtell 
> wrote:
>
> > Oh, my mistake! (smile) I confused pTLP with the "Strawman" proposal
> there
> > for a minute. In the pTLP proposal, there are no new-to-the-Foundation
> > project members on the pTLP PMC.
> >
> > "All proposals for new ASF projects must include an initial PMC chair and
> > an initial set of PMC members. These people must be acceptable to the
> > board. It is the responsibility of the Incubator Committee to vett these
> > people. All of them must have experience on existing PMCs"
> >
> >
> > Newcomers to Apache *might* get committership depending how the
> > only-members-as-PMC decide. They don't get even non-binding
> stakeholdership
> > in decisionmaking on new commiters, releases, and so on.
> >
> >
> > On Sun, Jan 25, 2015 at 11:49 AM, Andrew Purtell 
> > wrote:
> >
> > > > This is *exactly* the way things work in a TLP.
> > >
> > > Yes, everyone new to the Foundation on the PPMC has a sense of equal
> > > ownership in the process. The PPMC makes a decision together as equals,
> > > then the decision is reviewed as a whole. But this is not how things
> > > would work in a pTLP, right? Individuals there would effectively cast
> > > votes +1 (binding), or -1 (binding), +1 (non-binding), or -1
> > > (non-binding), etc., depending if they are a Member or not. Maybe in
> > > practice the pTLP PMC wouldn't write down their votes like that, but
> > > somehow the distinction must be presented in the tallies to be
> > meaningful.
> > >
> > >
> > >
> > > On Sun, Jan 25, 2015 at 11:11 AM, Branko Čibej 
> wrote:
> > >
> > >> On 25.01.2015 19:51, Andrew Purtell wrote:
> > >> >> That hardly ever happens (it's most likely when there are problems
> > with
> > >> > ​> ​
> > >> > a podling's first few releases), which is why you get the impression
> > >> > ​> ​
> > >> > that the PPMC can make binding decisions.
> > >> >
> > >> > ​Close. The PPMC membership feels they have made a decision that
> > matters
> > >> > with equal input.
> > >> > Certainly on PPMCs I've been on,
> > >> > ​there is awareness that everything is
> > >> > provisional
> > >> > ​. Still, a
> > >> >  process takes place on PPMC mailing lists leading to a tallied
> > outcome.
> > >> > The input that leads to this output is the consensus or voting of *a
> > >> group
> > >> > of equal peers*.
> > >> > ​ This output is handed to the IPMC in aggregate. ​
> > >> > When casting votes on the PPMC lists there are no +1 (binding) or +1
> > >> > (non-binding) distinctions made. PPMC sends the outcome over to the
> > IPMC
> > >> > feeling some level of ownership having just participated in a
> decision
> > >> > making process as equal
> > >> > ​s​
> > >> > . (Or at least so I think, in some perhaps quaint notion.) Of course
> > in
> > >> > IPMC voting it is different, but the IPMC is where supervision
> > happens,
> > >> or
> > >> > doesn't, as some argue.
> > >>
> > >> This is *exactly* the way things work in a TLP. Any committer can
> > >> propose a release. The PMC must (!) start a (public) vote. Anyone can
> > >> vote, with PMC votes being binding. /Any/ -1 vote, either from PMC
> > >> member or plain committer, should block the release and trigger a
> > >> discussion to find a solution; and in this discussion (which purpose
> is
> > >> to reach consensus on a solution), PMC members have no more voice than
> > >> any other community member.
> > >>
> > >> If the PMC decides to ignore a -1 on a release vote, they'd better
> have
> > >> really good reasons for that, or I'd expect the Board to come down
> like
> > >> a ton of bricks on that PMC.
> > >>
> > >> The situation is slightly different with new committer/PMC member
> > >> nominations and votes, which are private; you have a point there.
> > >>
> > >> -- Brane
> > >>
> > >> > On Sun, Jan 25, 2015 at 10:35 AM, Branko Čibej 
> > >> wrote:
> > >> >
> > >> >> On 25.01.2015 19:16, Andrew Purtell wrote:
> > >> >>> With a PPMC we invite newcomers to make votes we call binding on
> > >> matters
> > >> >> of
> > >> >>> their own project.
> > >> >> As other people have said, PPMC members (that are not also IPMC
> > >> members)
> > >> >> do not have binding votes, neither for releases nor for inviting
> new
> > >> >> committers/PPMC members. The "binding" bit lies with the IPMC,
> which
> > >> can
> > >> >> revoke any formal decision made by the PPMC.
> > >> >>
> > >> >> That hardly ever happens (it's most likely when there are problems
> > with
> > >> >> a podling's first few releases), which is why you get the
> impression
> > >> >> that the PPMC can make binding decisions. In this respect, there's
> no
> > >> >> practical difference between the current IPMC model and the
> proposed
> > >> >> pTLP model.
> > >> >>
> > >> >>

Re: my pTLP view

[Andrew Purtell]

I'm not arguing with you Greg (smile), honestly, Subversion sounds like a
very laid back place to participate. It's different in Bigtop, HBase,
Phoenix, Whirr (of historical note), and Hadoop (secondhand observation),
Hive (secondhand observation), ZooKeeper (secondhand observation) and
others. Formal votes are called on releases, committerships, PMC elevation,
branch merges (with even additional hurdles by bylaw), and are most
definitely talled.

On Sun, Jan 25, 2015 at 12:01 PM, Greg Stein  wrote:

> Apache Subversion uses discussion/consensus for all of those. We throw out
> +1 and similar as shorthand for our preference, but we never tally, as it
> isn't a formal vote.
>
> On Sun, Jan 25, 2015 at 1:58 PM, Andrew Purtell 
> wrote:
>
> > In all of the projects I have been PMC or PPMC on, we vote on releases,
> new
> > committers, and elevating committers to PMC.
> >
> >
> > On Sun, Jan 25, 2015 at 11:56 AM, Greg Stein  wrote:
> >
> > > On Sun, Jan 25, 2015 at 1:49 PM, Andrew Purtell 
> > > wrote:
> > >
> > > > > This is *exactly* the way things work in a TLP.
> > > >
> > > > Yes, everyone new to the Foundation on the PPMC has a sense of equal
> > > > ownership in the process. The PPMC makes a decision together as
> equals,
> > > > then the decision is reviewed as a whole. But this is not how things
> > > would
> > > > work in a pTLP, right? Individuals there would effectively cast votes
> > +1
> > > > (binding), or -1 (binding), +1 (non-binding), or -1 (non-binding),
> > etc.,
> > > > depending if they are a Member or not. Maybe in practice the pTLP PMC
> > > > wouldn't write down their votes like that, but somehow the
> distinction
> > > must
> > > > be presented in the tallies to be meaningful.
> > > >
> > >
> > > Nah. First: votes should be rare in the first place. Go for consensus
> > > instead. Apache Subversion has had maybe 3 votes in its 15 year
> history.
> > >
> > > And if you *do* end up voting? People already know who is binding or
> not.
> > > This isn't some star chamber PMC. Everybody knows each other already.
> If
> > > the PMC is voting differently from the others, then you have a problem,
> > > regardless of not/binding.
> > >
> > > Anyways... we'll run the experiment, and see how it works. We may have
> a
> > > candidate already.
> > >
> > > Cheers,
> > > -g
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> >- Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: my pTLP view

[Branko Čibej]

On 25.01.2015 21:07, Andrew Purtell wrote:
> I'm not arguing with you Greg (smile), honestly, Subversion sounds like a
> very laid back place to participate. It's different in Bigtop, HBase,
> Phoenix, Whirr (of historical note), and Hadoop (secondhand observation),
> Hive (secondhand observation), ZooKeeper (secondhand observation) and
> others. Formal votes are called on releases, committerships, PMC elevation,
> branch merges (with even additional hurdles by bylaw), and are most
> definitely talled.

Sigh ... well, all I can really add here is that the projects you
mention might benefit from a bit of therapy to cure their control-freak
reflex.

The reason why communities should reach consensus through public
discussion is that, when instead you have a formal vote every time
someone gets an itch, you're likely to end up with some very nasty
behind-the-scenes vote swapping. Of course I'm not accusing anyone of
doing that ... though, sadly, I've heard rumours.

Suffice it to say that what you describe is not the ASF Way.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: my pTLP view

[Bertrand Delacretaz]

On Fri, Jan 23, 2015 at 8:58 PM, Greg Stein  wrote:
> ...They are reporting to the Board. We know what inactivity looks like. So we
> ask the PMC to fix it, or we shut them down

I know how that works, it's just that with your pTLP proposal the
podling is "at the mercy" of their mentors - if the Incubator PMC
disappears it might be hard for them to recruit initial or new
mentors. Not a blocker for me, just an observation.

-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: my pTLP view

[Benson Margulies]

On Sun, Jan 25, 2015 at 3:53 PM, Bertrand Delacretaz
 wrote:
> On Fri, Jan 23, 2015 at 8:58 PM, Greg Stein  wrote:
>> ...They are reporting to the Board. We know what inactivity looks like. So we
>> ask the PMC to fix it, or we shut them down
>
> I know how that works, it's just that with your pTLP proposal the
> podling is "at the mercy" of their mentors - if the Incubator PMC
> disappears it might be hard for them to recruit initial or new
> mentors. Not a blocker for me, just an observation.

I want to be clear about the hypothetical here. I think it is, "The
board establishes a PMC containing some people whom it knows and
trusts, and there is a larger community of some other people whom it
would like to get to know and trust. (Or, even, the board included
some of the second group in the PMC at the outset.) Before the second
group merges with the first group, the first group loses motivation
and disappears."

It seems to me that this is not likely. To me, at least, signing up to
be a PMC member is a much clearer commitment than signing up as a
mentor, and, while I might be distracted for a month here and there,
I'm not going to just wander away. I think I'd be pretty much typical
(in this one tiny respect) of anyone that the board for a new PMC. To
get into the pickle Bertrand is musing about, more than one of the
group has to wander off, so that the remainder are not available to
help recruit some successors from the general membership.


>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: my pTLP view

[Dave Fisher]

On Jan 25, 2015, at 1:22 PM, Benson Margulies wrote:

> On Sun, Jan 25, 2015 at 3:53 PM, Bertrand Delacretaz
>  wrote:
>> On Fri, Jan 23, 2015 at 8:58 PM, Greg Stein  wrote:
>>> ...They are reporting to the Board. We know what inactivity looks like. So 
>>> we
>>> ask the PMC to fix it, or we shut them down
>> 
>> I know how that works, it's just that with your pTLP proposal the
>> podling is "at the mercy" of their mentors - if the Incubator PMC
>> disappears it might be hard for them to recruit initial or new
>> mentors. Not a blocker for me, just an observation.
> 
> I want to be clear about the hypothetical here. I think it is, "The
> board establishes a PMC containing some people whom it knows and
> trusts, and there is a larger community of some other people whom it
> would like to get to know and trust. (Or, even, the board included
> some of the second group in the PMC at the outset.) Before the second
> group merges with the first group, the first group loses motivation
> and disappears."
> 
> It seems to me that this is not likely. To me, at least, signing up to
> be a PMC member is a much clearer commitment than signing up as a
> mentor, and, while I might be distracted for a month here and there,
> I'm not going to just wander away. I think I'd be pretty much typical
> (in this one tiny respect) of anyone that the board for a new PMC. To
> get into the pickle Bertrand is musing about, more than one of the
> group has to wander off, so that the remainder are not available to
> help recruit some successors from the general membership.

+1.

I think that in this pTLP proposal there are no IPMC Mentors. These are not 
needed. Why? The Apache Members are coming in as the PMC. This is a much more 
serious commitment than being a Mentor. The pTLP is not an IPMC entity.

Incubator life cycle for a pTLP.
- Proposal to be a pTLP.
- IPMC recommendation to the Board as a possible fit to be a pTLP.

Board life cycle for a pTLP.
- Board accepts - they can accept no matter what the IPMC opines.
- Board manages it like a TLP. Appoints Board Shepherd, etc. Not the IPMC's 
responsibility any longer.
- Board decides when the probationary period is over and the little "p" is 
removed.

Regards,
Dave

> 
> 
>> 
>> -Bertrand
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

RE: my pTLP view

[Ross Gardler (MS OPEN TECH)]

And even in the strawman (at least how I wrote it) there is even less of a gap 
from today's model to the pTLP proposal under discussion here.

Sent from my Windows Phone

From: Greg Stein<mailto:gst...@gmail.com>
Sent: ‎1/‎25/‎2015 12:03 PM
To: general@incubator.apache.org<mailto:general@incubator.apache.org>
Subject: Re: my pTLP view

Go to the FIRST POST of this thread (titled: "my pTLP view"!!). THAT is
what we're talking about. Not the Strawman.

On Sun, Jan 25, 2015 at 1:56 PM, Andrew Purtell  wrote:

> Oh, my mistake! (smile) I confused pTLP with the "Strawman" proposal there
> for a minute. In the pTLP proposal, there are no new-to-the-Foundation
> project members on the pTLP PMC.
>
> "All proposals for new ASF projects must include an initial PMC chair and
> an initial set of PMC members. These people must be acceptable to the
> board. It is the responsibility of the Incubator Committee to vett these
> people. All of them must have experience on existing PMCs"
>
>
> Newcomers to Apache *might* get committership depending how the
> only-members-as-PMC decide. They don't get even non-binding stakeholdership
> in decisionmaking on new commiters, releases, and so on.
>
>
> On Sun, Jan 25, 2015 at 11:49 AM, Andrew Purtell 
> wrote:
>
> > > This is *exactly* the way things work in a TLP.
> >
> > Yes, everyone new to the Foundation on the PPMC has a sense of equal
> > ownership in the process. The PPMC makes a decision together as equals,
> > then the decision is reviewed as a whole. But this is not how things
> > would work in a pTLP, right? Individuals there would effectively cast
> > votes +1 (binding), or -1 (binding), +1 (non-binding), or -1
> > (non-binding), etc., depending if they are a Member or not. Maybe in
> > practice the pTLP PMC wouldn't write down their votes like that, but
> > somehow the distinction must be presented in the tallies to be
> meaningful.
> >
> >
> >
> > On Sun, Jan 25, 2015 at 11:11 AM, Branko Čibej  wrote:
> >
> >> On 25.01.2015 19:51, Andrew Purtell wrote:
> >> >> That hardly ever happens (it's most likely when there are problems
> with
> >> > ​> ​
> >> > a podling's first few releases), which is why you get the impression
> >> > ​> ​
> >> > that the PPMC can make binding decisions.
> >> >
> >> > ​Close. The PPMC membership feels they have made a decision that
> matters
> >> > with equal input.
> >> > Certainly on PPMCs I've been on,
> >> > ​there is awareness that everything is
> >> > provisional
> >> > ​. Still, a
> >> >  process takes place on PPMC mailing lists leading to a tallied
> outcome.
> >> > The input that leads to this output is the consensus or voting of *a
> >> group
> >> > of equal peers*.
> >> > ​ This output is handed to the IPMC in aggregate. ​
> >> > When casting votes on the PPMC lists there are no +1 (binding) or +1
> >> > (non-binding) distinctions made. PPMC sends the outcome over to the
> IPMC
> >> > feeling some level of ownership having just participated in a decision
> >> > making process as equal
> >> > ​s​
> >> > . (Or at least so I think, in some perhaps quaint notion.) Of course
> in
> >> > IPMC voting it is different, but the IPMC is where supervision
> happens,
> >> or
> >> > doesn't, as some argue.
> >>
> >> This is *exactly* the way things work in a TLP. Any committer can
> >> propose a release. The PMC must (!) start a (public) vote. Anyone can
> >> vote, with PMC votes being binding. /Any/ -1 vote, either from PMC
> >> member or plain committer, should block the release and trigger a
> >> discussion to find a solution; and in this discussion (which purpose is
> >> to reach consensus on a solution), PMC members have no more voice than
> >> any other community member.
> >>
> >> If the PMC decides to ignore a -1 on a release vote, they'd better have
> >> really good reasons for that, or I'd expect the Board to come down like
> >> a ton of bricks on that PMC.
> >>
> >> The situation is slightly different with new committer/PMC member
> >> nominations and votes, which are private; you have a point there.
> >>
> >> -- Brane
> >>
> >> > On Sun, Jan 25, 2015 at 10:35 AM, Branko Čibej 
> >> wrote:
> >> >
> >> >> On 25.01.2015 19:

Re: my pTLP view

[Greg Stein]

On Sun, Jan 25, 2015 at 4:01 PM, Dave Fisher  wrote:

>
> On Jan 25, 2015, at 1:22 PM, Benson Margulies wrote:
>
> > On Sun, Jan 25, 2015 at 3:53 PM, Bertrand Delacretaz
> >  wrote:
> >> On Fri, Jan 23, 2015 at 8:58 PM, Greg Stein  wrote:
> >>> ...They are reporting to the Board. We know what inactivity looks
> like. So we
> >>> ask the PMC to fix it, or we shut them down
> >>
> >> I know how that works, it's just that with your pTLP proposal the
> >> podling is "at the mercy" of their mentors - if the Incubator PMC
> >> disappears it might be hard for them to recruit initial or new
> >> mentors. Not a blocker for me, just an observation.
> >
> > I want to be clear about the hypothetical here. I think it is, "The
> > board establishes a PMC containing some people whom it knows and
> > trusts, and there is a larger community of some other people whom it
> > would like to get to know and trust. (Or, even, the board included
> > some of the second group in the PMC at the outset.) Before the second
> > group merges with the first group, the first group loses motivation
> > and disappears."
> >
> > It seems to me that this is not likely. To me, at least, signing up to
> > be a PMC member is a much clearer commitment than signing up as a
> > mentor, and, while I might be distracted for a month here and there,
> > I'm not going to just wander away. I think I'd be pretty much typical
> > (in this one tiny respect) of anyone that the board for a new PMC. To
> > get into the pickle Bertrand is musing about, more than one of the
> > group has to wander off, so that the remainder are not available to
> > help recruit some successors from the general membership.
>

Very well-stated, and very clear, Benson. Thanks. Yes... that matches my
own thoughts precisely. The "failure mode" based around absent PMC members
is very unlikely.

But carry it a bit further: one of those is the VP. An Officer of the
Foundation. If that person disappears, it is quickly obvious, so we don't
need to worry about this case (easily noted and fixed). If the other
members of the PMC disappear ... well, that VP can *still* appoint people
onto the PMC, to get the roster back up to (3) active people who can +1
releases, and can acknowledge that the commits/direction of the project
comport with the PMC and the Foundation.

[ for those not aware: yes, the VP can unilaterally add people to the PMC;
no need to have 3 actives; so a reboot is always possible if a VP is around
]


>
> +1.
>
> I think that in this pTLP proposal there are no IPMC Mentors. These are
> not needed. Why? The Apache Members are coming in as the PMC. This is a
> much more serious commitment than being a Mentor. The pTLP is not an IPMC
> entity.
>

In the model that I have proposed: correct. This is simply another TLP
which the Board has mandated the "probationary/provisional" label upon.
Even the "requirement" for only ASF Members is a suggestion. A community
can arrive with any initial list of PMC members, but speaking with my
Director hat: no, the initial list should be small, greybearded, and
well-known. They can make an argument for one or two others, I'd think, so
the "rule" is more like advice on how to get the Board to approve it :-)

While we don't like BDFL's or tech leads at the ASF, many incoming projects
have individuals that fit into such a role. I'd expect that person to get
onto the initial PMC list. But I would never approve without (3) or more
ASF Members on the list.


> Incubator life cycle for a pTLP.
> - Proposal to be a pTLP.
> - IPMC recommendation to the Board as a possible fit to be a pTLP.
>

Sure. Or a community can directly approach the Board. However, the Board is
really bad about engaging a community in discussion, so the approach kind
of needs to be packaged with a high chance of approval (since back/forth
won't happen). That generally means an individual Director would work with
the community to put the proposal together (based on their impression of
what the Board would accept, and their own part in discussions during the
Board meeting to make it happen).


> Board life cycle for a pTLP.
> - Board accepts - they can accept no matter what the IPMC opines.
> - Board manages it like a TLP. Appoints Board Shepherd, etc. Not the
> IPMC's responsibility any longer.
> - Board decides when the probationary period is over and the little "p" is
> removed.
>

Yessir.

Cheers,
-g

Re: my pTLP view

[Bertrand Delacretaz]

On Sun, Jan 25, 2015 at 11:01 PM, Dave Fisher  wrote:
> ...The Apache Members are coming in as the PMC. This is a much more
> serious commitment than being a Mentor. The pTLP is not an
> IPMC entity

Ok, I agree that if those PMC members take that as seriously as you
think there shouldn't be any problems.

-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: my pTLP view

[Marvin Humphrey]

On Mon, Jan 26, 2015 at 1:13 AM, Bertrand Delacretaz
 wrote:
> On Sun, Jan 25, 2015 at 11:01 PM, Dave Fisher  wrote:
>> ...The Apache Members are coming in as the PMC. This is a much more
>> serious commitment than being a Mentor. The pTLP is not an
>> IPMC entity
>
> Ok, I agree that if those PMC members take that as seriously as you
> think there shouldn't be any problems.

I'm skeptical. Having ASF Members swear that they "really really mean
it" doesn't transform them into core developers overnight.  The
project is still being overseen by outsiders with limited investment.
The same flawed incentive structure which afflicts the Incubator
persists.

Should work or life changes force these ASF Members to make hard
choices, the pTLP is still a volunteer effort that they didn't start
on their own and may not be getting paid to work on -- and it will be
prioritized appropriately. As a result, I would expect attrition at
roughly the same rates as Incubator Mentors.

Marvin Humphrey

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: my pTLP view

[Andrew Purtell]

Yes, formal votes for all decisions has been my *universal* experience on
all projects I have participated in at Apache. It's like there are two (or
more) different foundations, culturally. Thanks for the consideration.

On Sun, Jan 25, 2015 at 12:40 PM, Branko Čibej  wrote:

> On 25.01.2015 21:07, Andrew Purtell wrote:
> > I'm not arguing with you Greg (smile), honestly, Subversion sounds like a
> > very laid back place to participate. It's different in Bigtop, HBase,
> > Phoenix, Whirr (of historical note), and Hadoop (secondhand observation),
> > Hive (secondhand observation), ZooKeeper (secondhand observation) and
> > others. Formal votes are called on releases, committerships, PMC
> elevation,
> > branch merges (with even additional hurdles by bylaw), and are most
> > definitely talled.
>
> Sigh ... well, all I can really add here is that the projects you
> mention might benefit from a bit of therapy to cure their control-freak
> reflex.
>
> The reason why communities should reach consensus through public
> discussion is that, when instead you have a formal vote every time
> someone gets an itch, you're likely to end up with some very nasty
> behind-the-scenes vote swapping. Of course I'm not accusing anyone of
> doing that ... though, sadly, I've heard rumours.
>
> Suffice it to say that what you describe is not the ASF Way.
>
> -- Brane
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: my pTLP view

[Alan D. Cabrera]

TL;DR I think this is a good idea.

I thought long and hard about this during the weekend and I’ve changed my mind 
about this; I’ll spare you my handwringing thought processes.  Some things that 
I personally would like to see:

- do away w/ the pTLP name, just make it a regular TLP
- ComDev should be charged w/ augmenting their maturity model with “profiles” 
which can be applied to such TLPs, e.g.
- committers==PMC
- codebase going through IP clearance
- PMC considers TLP properly diverse
- PMC considers TLP properly active
- item 2 is too strict


Regards,
Alan


> On Jan 23, 2015, at 5:42 AM, Greg Stein  wrote:
> 
> Roman kicked off a query about  "next steps", with links to several wiki
> pages on possibilities. The "IncubatorV2" page which describes a
> "probationary TLP" is nothing like I have thought about.
> 
> In my mind, a pTLP looks *exactly* like any other PMC. They report directly
> to the Board, they have infrastructure like any other project (eg.
> FOO.apache.org). But they have two significant differences:
> 
> 1. probationary text is prominent, much like we require "incubating" to be
> prominent in various locations/messages for podlings
> 
> 2. the initial PMC is comprised of only ASF Members. committers can be
> chosen however the community decides. but the *project* is reviewed by
> people with (hopefully/theoretically) experience with the Foundation and
> its views on communities
> 
> That's it. By creating a PMC that understands what is needed, then they can
> groom new PMC members, and use the standard process for adding them to the
> PMC. The Board doesn't care about committership, so the pTLP can do
> whatever it wants in that regard.
> 
> The Board might not accept a pTLP resolution because it wants more
> greybeards on there, to help the community. Removing the "probationary"
> label, is up to the pTLP to request, and the Board to approve. It is
> usually pretty obvious when a community has reached that point, if you are
> talking about active ASF/PMC Members. But the Board would apply its own
> level of trust.
> 
> There is a big element here, which didn't exist 12 years ago: the Board's
> ability to review many projects. Before the Incubator, there weren't that
> many projects. The Directors didn't have a lot of experience with a lot of
> breadth. Nowadays, we review the work of *dozens* of projects every month.
> If one is a pTLP instead of a regular TLP? Not a big deal. They have some
> operational restrictions, but the report should be showing us a typical
> Apache community.
> 
> The other aspect is IP clearance and management, which also didn't exist a
> dozen years ago (and the Incubator was basically started in response to
> some IP problems). We have a much better understanding there. Today, we
> have the Incubator performing that, but no reason we can't have pTLPs
> managing that process. We file "forms" about clearance with the Incubator,
> but really: that should be filed $somehow defined by the VP of Legal
> Affairs (and *that* position/process didn't exist until years after the
> Incubator was established).
> 
> TLPs are a recognition of a community. We can create probationary
> communities, supported by ComDev, Legal, other communities, and reviewed by
> the Board.
> 
> Speaking as a Director of the ASF, if a Resolution arrived on the Board's
> Agenda to create such a pTLP, then I would be supportive. The pTLP
> construct is independent of the Apache Incubator. Anybody is free to define
> how they want to approach it, and then ask the Board if they are willing to
> try it.
> 
> Cheers,
> -g

Re: my pTLP view

[Alex Harui]

I can see how it could work for some new communities, but I don’t think it
will work for all.  I would imagine some potential podlings don’t have
well-established communities.  They might just be a few folks with a good
idea and looking to recruit lots of new folks for the initial committers
list.  In such a case, it sort of makes sense for there to be an option,
if enough ASF members want to be on that initial committers list not to
mentor, but to be real committers, for the board to bypass incubation and
establish a pTLP.

For Flex, we did not have an established community of developers coming in
with the code.  But I don’t know that we could have recruited enough ASF
members to be committers.  Flex was different enough to not be closely
related to any other Apache project.  Folks were interested in seeing if
Flex could be a viable Apache project, but I don’t think any existing ASF
members have actually become Flex committers.  I think I’ve processed new
accounts for each of our committers.  So would that mean that some future
Flex would just not come to Apache?

On 1/26/15, 10:09 AM, "Alan D. Cabrera"  wrote:

>TL;DR I think this is a good idea.
>
>I thought long and hard about this during the weekend and I’ve changed my
>mind about this; I’ll spare you my handwringing thought processes.  Some
>things that I personally would like to see:
>
>- do away w/ the pTLP name, just make it a regular TLP
>- ComDev should be charged w/ augmenting their maturity model with
>“profiles” which can be applied to such TLPs, e.g.
>- committers==PMC
>- codebase going through IP clearance
>- PMC considers TLP properly diverse
>- PMC considers TLP properly active
>- item 2 is too strict
>
>
>Regards,
>Alan
>
>
>> On Jan 23, 2015, at 5:42 AM, Greg Stein  wrote:
>> 
>> Roman kicked off a query about  "next steps", with links to several wiki
>> pages on possibilities. The "IncubatorV2" page which describes a
>> "probationary TLP" is nothing like I have thought about.
>> 
>> In my mind, a pTLP looks *exactly* like any other PMC. They report
>>directly
>> to the Board, they have infrastructure like any other project (eg.
>> FOO.apache.org). But they have two significant differences:
>> 
>> 1. probationary text is prominent, much like we require "incubating" to
>>be
>> prominent in various locations/messages for podlings
>> 
>> 2. the initial PMC is comprised of only ASF Members. committers can be
>> chosen however the community decides. but the *project* is reviewed by
>> people with (hopefully/theoretically) experience with the Foundation and
>> its views on communities
>> 
>> That's it. By creating a PMC that understands what is needed, then they
>>can
>> groom new PMC members, and use the standard process for adding them to
>>the
>> PMC. The Board doesn't care about committership, so the pTLP can do
>> whatever it wants in that regard.
>> 
>> The Board might not accept a pTLP resolution because it wants more
>> greybeards on there, to help the community. Removing the "probationary"
>> label, is up to the pTLP to request, and the Board to approve. It is
>> usually pretty obvious when a community has reached that point, if you
>>are
>> talking about active ASF/PMC Members. But the Board would apply its own
>> level of trust.
>> 
>> There is a big element here, which didn't exist 12 years ago: the
>>Board's
>> ability to review many projects. Before the Incubator, there weren't
>>that
>> many projects. The Directors didn't have a lot of experience with a lot
>>of
>> breadth. Nowadays, we review the work of *dozens* of projects every
>>month.
>> If one is a pTLP instead of a regular TLP? Not a big deal. They have
>>some
>> operational restrictions, but the report should be showing us a typical
>> Apache community.
>> 
>> The other aspect is IP clearance and management, which also didn't
>>exist a
>> dozen years ago (and the Incubator was basically started in response to
>> some IP problems). We have a much better understanding there. Today, we
>> have the Incubator performing that, but no reason we can't have pTLPs
>> managing that process. We file "forms" about clearance with the
>>Incubator,
>> but really: that should be filed $somehow defined by the VP of Legal
>> Affairs (and *that* position/process didn't exist until years after the
>> Incubator was established).
>> 
>> TLPs are a recognition of a community. We can create probationary
>> communities, supported by ComDev, Legal, other communities, and
>>reviewed by
>> the Board.
>> 
>> Speaking as a Director of the ASF, if a Resolution arrived on the
>>Board's
>> Agenda to create such a pTLP, then I would be supportive. The pTLP
>> construct is independent of the Apache Incubator. Anybody is free to
>>define
>> how they want to approach it, and then ask the Board if they are
>>willing to
>> try it.
>> 
>> Cheers,
>> -g
>


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For 

RE: my pTLP view

[Ross Gardler (MS OPEN TECH)]

It's an *option* not the only route. Working for some but not others is just 
fine.

Ross

-Original Message-
From: Alex Harui [mailto:aha...@adobe.com] 
Sent: Monday, January 26, 2015 11:23 AM
To: general@incubator.apache.org
Cc: Chris Mattmann; Jim Jagielski
Subject: Re: my pTLP view

I can see how it could work for some new communities, but I don’t think it will 
work for all.  I would imagine some potential podlings don’t have 
well-established communities.  They might just be a few folks with a good idea 
and looking to recruit lots of new folks for the initial committers list.  In 
such a case, it sort of makes sense for there to be an option, if enough ASF 
members want to be on that initial committers list not to mentor, but to be 
real committers, for the board to bypass incubation and establish a pTLP.

For Flex, we did not have an established community of developers coming in with 
the code.  But I don’t know that we could have recruited enough ASF members to 
be committers.  Flex was different enough to not be closely related to any 
other Apache project.  Folks were interested in seeing if Flex could be a 
viable Apache project, but I don’t think any existing ASF members have actually 
become Flex committers.  I think I’ve processed new accounts for each of our 
committers.  So would that mean that some future Flex would just not come to 
Apache?

On 1/26/15, 10:09 AM, "Alan D. Cabrera"  wrote:

>TL;DR I think this is a good idea.
>
>I thought long and hard about this during the weekend and I’ve changed 
>my mind about this; I’ll spare you my handwringing thought processes.  
>Some things that I personally would like to see:
>
>- do away w/ the pTLP name, just make it a regular TLP
>- ComDev should be charged w/ augmenting their maturity model with 
>“profiles” which can be applied to such TLPs, e.g.
>- committers==PMC
>- codebase going through IP clearance
>- PMC considers TLP properly diverse
>- PMC considers TLP properly active
>- item 2 is too strict
>
>
>Regards,
>Alan
>
>
>> On Jan 23, 2015, at 5:42 AM, Greg Stein  wrote:
>> 
>> Roman kicked off a query about  "next steps", with links to several 
>> wiki pages on possibilities. The "IncubatorV2" page which describes a 
>> "probationary TLP" is nothing like I have thought about.
>> 
>> In my mind, a pTLP looks *exactly* like any other PMC. They report 
>>directly  to the Board, they have infrastructure like any other 
>>project (eg.
>> FOO.apache.org). But they have two significant differences:
>> 
>> 1. probationary text is prominent, much like we require "incubating" 
>>to be  prominent in various locations/messages for podlings
>> 
>> 2. the initial PMC is comprised of only ASF Members. committers can 
>> be chosen however the community decides. but the *project* is 
>> reviewed by people with (hopefully/theoretically) experience with the 
>> Foundation and its views on communities
>> 
>> That's it. By creating a PMC that understands what is needed, then 
>>they can  groom new PMC members, and use the standard process for 
>>adding them to the  PMC. The Board doesn't care about committership, 
>>so the pTLP can do  whatever it wants in that regard.
>> 
>> The Board might not accept a pTLP resolution because it wants more  
>>greybeards on there, to help the community. Removing the "probationary"
>> label, is up to the pTLP to request, and the Board to approve. It is  
>>usually pretty obvious when a community has reached that point, if you 
>>are  talking about active ASF/PMC Members. But the Board would apply 
>>its own  level of trust.
>> 
>> There is a big element here, which didn't exist 12 years ago: the 
>>Board's  ability to review many projects. Before the Incubator, there 
>>weren't that  many projects. The Directors didn't have a lot of 
>>experience with a lot of  breadth. Nowadays, we review the work of 
>>*dozens* of projects every month.
>> If one is a pTLP instead of a regular TLP? Not a big deal. They have 
>>some  operational restrictions, but the report should be showing us a 
>>typical  Apache community.
>> 
>> The other aspect is IP clearance and management, which also didn't 
>>exist a  dozen years ago (and the Incubator was basically started in 
>>response to  some IP problems). We have a much better understanding 
>>there. Today, we  have the Incubator performing that, but no reason we 
>>can't have pTLPs  managing that process. We file "forms" about 
>>clearance with the Incubator,  but really: that should be filed 
>>$somehow defined by 

Re: my pTLP view

[Bertrand Delacretaz]

On Mon, Jan 26, 2015 at 8:22 PM, Alex Harui  wrote:
> ...For Flex, we did not have an established community of developers coming in
> with the code.  But I don’t know that we could have recruited enough ASF
> members to be committers

I agree with that, I was a Flex mentor but only interested in the
community side of things, I have no technical knowledge and no
technical interest in Flex.

I think that kind of mentorship is still possible with Greg's pTLP
model, but as others have said people who have no technical interest
in the project are more likely to become inactive than those who are
active committers.

In any case, it's fine for people to become inactive in Apache
projects so the same has to be true for pTLPs. I guess the board will
just have to pay closer attention to those projects, considering them
more "fragile" than well-established TLPs maybe.

-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: my pTLP view

[Bertrand Delacretaz]

On Mon, Jan 26, 2015 at 7:09 PM, Alan D. Cabrera  wrote:
> ...- do away w/ the pTLP name, just make it a regular TLP...

I don't like that, IMO pTLPs have to be explicitly flagged, to make
sure both users and Apache folks are aware of their "immaturity".

-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: my pTLP view

[Alan D. Cabrera]

> On Jan 27, 2015, at 12:31 AM, Bertrand Delacretaz  
> wrote:
> 
> On Mon, Jan 26, 2015 at 7:09 PM, Alan D. Cabrera  wrote:
>> ...- do away w/ the pTLP name, just make it a regular TLP...
> 
> I don't like that, IMO pTLPs have to be explicitly flagged, to make
> sure both users and Apache folks are aware of their "immaturity".

I had considered that.  What I was thinking was that what ever specific 
concerns there can be for the pTLP also apply to a mature TLP.  Having various 
“profiles” that apply to projects can provide a finer degree of visibility.  To 
be sure every project has its nuances and some will be exceptionally unusual, 
but those will already be on the board’s “radar”.

In short, the pTLP designation is a bit too opaque.  Anyway, that’s what I was 
thinking.


Regards,
Alan


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: my pTLP view

[Bertrand Delacretaz]

On Tue, Jan 27, 2015 at 3:38 PM, Alan D. Cabrera  wrote:
> In short, the pTLP designation is a bit too opaque

So you mean all TLPs should have status labels?

Might be useful...probatory, active, low activity, attic candidate...why not.

-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: my pTLP view

[Alan D. Cabrera]

> On Jan 27, 2015, at 6:58 AM, Bertrand Delacretaz  
> wrote:
> 
> On Tue, Jan 27, 2015 at 3:38 PM, Alan D. Cabrera  wrote:
>> In short, the pTLP designation is a bit too opaque
> 
> So you mean all TLPs should have status labels?
> 
> Might be useful...probatory, active, low activity, attic candidate...why not.

Yeah, these coupled w/ ComDev’s maturity model would help people grok at a 
glance what’s generally going on w/ the project instead of being forced to go 
on an easter egg hunt through Jira issues, mailing lists, and commit logs, to 
try to access the general character of a project.


Regards,
Alan


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: my pTLP view

[Roman Shaposhnik]

On Tue, Jan 27, 2015 at 6:58 AM, Bertrand Delacretaz
 wrote:
> On Tue, Jan 27, 2015 at 3:38 PM, Alan D. Cabrera  wrote:
>> In short, the pTLP designation is a bit too opaque
>
> So you mean all TLPs should have status labels?
>
> Might be useful...probatory, active, low activity, attic candidate...why not.

Absolutely. And it belongs to a different effort (just trying as hard as I can
not to boil the ocean with pTLP for now).

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: my pTLP view

[Benson Margulies]

On Tue, Jan 27, 2015 at 12:14 PM, Roman Shaposhnik  wrote:
> On Tue, Jan 27, 2015 at 6:58 AM, Bertrand Delacretaz
>  wrote:
>> On Tue, Jan 27, 2015 at 3:38 PM, Alan D. Cabrera  
>> wrote:
>>> In short, the pTLP designation is a bit too opaque
>>
>> So you mean all TLPs should have status labels?
>>
>> Might be useful...probatory, active, low activity, attic candidate...why not.
>
> Absolutely. And it belongs to a different effort (just trying as hard as I can
> not to boil the ocean with pTLP for now).

I support Greg's idea that, in the initial experiment, they are
flagged (and presumably required to DISCLAIM and respect PR
restrictions), because that's the incremental path of not changing
everything all at the same time. I support Bertrand's suggestion that,
if this idea really turns out to work, the flag may go into the attic
over time.

>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org