incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <j...@apache.org>
Subject my pTLP view
Date Fri, 23 Jan 2015 22:33:51 GMT
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�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB�
> � [��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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message