incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ross Gardler (MS OPEN TECH)" <Ross.Gard...@microsoft.com>
Subject RE: my pTLP view
Date Fri, 23 Jan 2015 22:47:20 GMT
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:jani@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.Gardler@microsoft.com <javascript:_e(%7B%7D,'cvml','Ross.Gardler@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 released....is 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:aharui@adobe.com>
> Sent: ‎1/‎23/‎2015 12:06 PM
> To: general@incubator.apache.org<mailto:general@incubator.apache.org>
> Cc: Chris Mattmann<mailto:mattmann@apache.org>; Jim Jagielski<mailto:
> jim@jagunet.com>
> Subject: Re: my pTLP view
>
>
>
> On 1/23/15, 6:53 AM, "jan i" <jani@apache.org> 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 project 
> if it isn’t going to operate like a project -If culture is important, 
> then you need to designate a group of folks who can certify that you 
> “get it”.  It could be the ASF members, but I’m not sure all members 
> “get it”.  Or maybe it is some smaller group.  It could be the current 
> Incubator folks.
> -Make it clear to newcomers that there is a different culture.  I 
> don’t think I see that emphasized when new projects knock on our door.  
> When I came in, I knew there was this thing called meritocracy, but I 
> did not know about the “no hierarchy”, bias towards consensus vs 
> voting, voting rules or source-only-releases and more and that these 
> things were also important.
> -Consider experimenting with having more casual observers from this 
> group of cultural advisors than having fewer committed ones.
> -See if required notifications for more things can help keep track of 
> new communities.
>
> -Alex
>
>
>
>  
> B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
> CB    [  X  ܚX K  K[XZ[    [ \ [ ][  X  ܚX P [  X ] ܋ \ X  K ܙ B  ܈ Y  
> ] [ۘ[
>   [X[     K[XZ[    [ \ [ Z [   [  X ] ܋ \ X  K ܙ B
>


--
Sent from My iPad, sorry for any misspellings.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Mime
View raw message