As the chair here, I start from the premise that I've been invited to serve as the chair of the incubator as we know it. I have some sympathy for Chris M's views, but the job I have here is, first and foremost, to facilitate making the existing thing work. So I expect to be one of the last people to jump on a helicopter labelled 'shut down the IPMC and replace it with something radically different, up to and including nothing at all.' My job is to facilitate 'Incremental changes,' to quote what might be a plurality of the current board members.
Some negatives are hardy perennials, but deserve some careful examination. 'oppressive process': Some recent messages emphasized the oppressive nature of the IPMC. It seems to me that 90% of this has always been the struggle to get the legal boilerplate into order and thus releases approved. After Marvin and Bertrand's wonderful writing effort here, I think that we might have cured that issue. We have a flock of new podlings; let's see how they do when they go into the release cycle. If the new documentation avoids 7-spin release cycles, I'm not sure what's left of the fascist regime. I cannot recall the last time the IPMC had much to say about adding a committer or anything else that podlings do except make releases. 'supervision': As Shane emphasizes, the shortage of volunteer attention is a problem whether you have the IPMC as we know it or Chris M's proposal. Chris' proposal has the advantage of rubbing everyone's nose in the problem, where in contrast the IPMC as we know it can serve as a rug under which it can be swept. However, we don't have to blow up the IPMC to get tough on this. We could set a higher bar for new podlings, and we could take more draconian steps if a podling runs out of mentor. I'm not _proposing_ either of these, merely observing that this PMC could take those steps. We could just adopt Ross' structure, which adds some further emphasis to shepherding, and see how we do. 'decision-making': There are too many people who are members of this committee for us to expect traditional consensus process to function very well. Unless you believe that full consensus process is an defining trait of all Apache operations at all scales on all days, that's not a reason to blow up the IPMC. One way to look Ross' proposal is that it could split policy-making from supervision. His flock-of-shepherds becomes the policy committee, and the rest of the IPMC is in the supervision business. . On Fri, Mar 29, 2013 at 2:38 PM, Shane Curcuru <a...@shanecurcuru.org> wrote: > Personally, I would find IPMC issues much easier to follow if we all > limited threads to more specific topics, and started new threads for new > specific topics. This one is still pretty buried. > > On 3/29/2013 1:11 PM, Ross Gardler wrote: > ... > > I don't accept that using yourself as an example of how we can find >> sufficient mentors for all new entries is evidence that your proposal will >> scale and thus address the concerns I have expressed. You are not a >> typical >> mentor, most of us need sleep. >> > > This is a critical point. Not only does it show that Chris has a high bus > factor (although he's no Sam, that's for sure), it's also wildly > unrepresentative of the average ASF Member, or in fact any likely Incubator > area contributor. > > > I don't believe this topic needs debating as I don't believe the >> incubation >> process is broken. Your proposal doesn't actually solve the core problems >> of whether policy says this or that or whether best practice is this or >> that - which ultimately is the only thing the IPMC gets bogged down in. >> Your proposal simply moves all the hard parts to the membership and thus >> to >> the board. Moving problems does not solve them. >> > > I'll just offer one general commentary here. It feels like a lot of > discussion recently has gone into the minutiae of decision making rules. > What it feels like we need are both 1) more shepherds who are > *predictably* active at assisting with their podlings and getting > well-written reports in shape, and 2) more direct leadership that seeks > basic consensus on very specific and clear new changes, but doesn't let > discussions get weighed down with too many options, or stalled by a > relative handful of -0s. > > 1) here is critical, and... I don't know how to get more predictably > active people, but that's exactly what I've been trying to say with "we > need to grow more organizational volunteers" in my board statements. > > 2) is simply a reflection (and perhaps a not thoroughly thought through > one) of the reality that we've shown we're bad at scaling *organizational* > decision making to the Membership scale. (Note that this is different than > *technical* decision making.) > > An analogy is the success of the three VP positions reborn from the fiery > demise of the PRC. The PRC had every interested member trying to help > drive everything, but rarely finishing things. The current three VPs each > work with interested members for backup and advise, but fundamentally are > responsible as individuals for covering their areas to the board. > > - Shane > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > general-unsubscribe@incubator.**apache.org<general-unsubscr...@incubator.apache.org> > For additional commands, e-mail: > general-help@incubator.apache.**org<general-h...@incubator.apache.org> > >
