On Saturday, January 24, 2015, Ross Gardler (MS OPEN TECH) < ross.gard...@microsoft.com <javascript:_e(%7B%7D,'cvml','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? 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 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. 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. With pTLC I fear that the incoming community will feel empowered, the 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. 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. 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 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 <javascript:;>] > > Sent: Friday, January 23, 2015 2:34 PM > > To: general@incubator.apache.org <javascript:;> > > Subject: my pTLP view > > > > On Friday, January 23, 2015, Ross Gardler (MS OPEN TECH) < > > ross.gard...@microsoft.com <javascript:;> <javascript:_e(%7B%7D,'cvml',' > > ross.gard...@microsoft.com <javascript:;>');>> 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:aha...@adobe.com <javascript:;>> > > > Sent: 1/23/2015 12:06 PM > > > To: general@incubator.apache.org <javascript:;><mailto: > > general@incubator.apache.org <javascript:;>> > > > Cc: Chris Mattmann<mailto:mattm...@apache.org <javascript:;>>; Jim > > Jagielski<mailto: > > > j...@jagunet.com <javascript:;>> > > > Subject: Re: my pTLP view > > > > > > > > > > > > On 1/23/15, 6:53 AM, "jan i" <j...@apache.org <javascript:;>> 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-unsubscr...@incubator.apache.org > > <javascript:;> > > For additional commands, e-mail: general-h...@incubator.apache.org > > <javascript:;> > > > > > -- > Sent from My iPad, sorry for any misspellings. > -- Sent from My iPad, sorry for any misspellings.
