Yoav Shapira wrote: > Hi, > >> My view is that we shouldn't keep wasting our time on such a separation. > > I think the separation is valid. Jim put it nicely earlier today > (paraphrased here): committership is the right to vote a code base, > PMC membership is the right to oversee a project. In my mind there > definitely is a separation, and the latter requires more trust. +1 I see "PMC==committers" as an aspiration, not something that can defined away. > This > is especially true for projects whose committership is granted (at > first maybe) on a partial basis, e.g. only to some directory trees > within the project's SVN repository. So if I were to go just with > that, I'd say -0 (if only because I don't have the energy and > bandwidth to contribute alternative suggestions, so I don't want to -1 > the issue). > > You mentioned that we're bad at remembering to add people to the PMC: > agreed, but I don't think the solution to that is a policy-level one. I agree here as well. We should be aiming to a) get as many committers as possible both wanting and deserving the additional trust that PMC membership represents and b) nominating them once they have earned that trust and indicated that they are willing to participate in the oversight of the project.
I agree that we can all improve the speed with which we nominate people, but I bet if you did the super svn-analysis, you would find that people with sustained contributions do tend to get nominated over time. I think the large number of non-PMC committers is at least in part attributable to "vanishing committers" or committers whose activity is at best sporadic. With my PMC member hat on, I would be hard pressed to +1 a mass addition of PMC members based on historical commit votes from all across Jakarta, with no support provided for any of the nominees. > Instead, I would opt for a simple command-line tool, to be run at the > PMC's discretion (or indeed, probably at any committers' discretion), > that looks at svn-authorization and spits out who's a committer for > project X but not on the PMC for that project. With the crew here, > we'll probably have this tool done in your choice of the top 20 > programming languages in under an hour. Heck we can even make it a > cron / gump / nag the PMC chair every month type of thing. > > The above said, I think Jakarta is a different beast. Because it's an > umbrella project, it has many disparate groups of people doing their > own thing. In a nicer world, those smaller groups would be > responsible for their oversight, so we'd have multiple smaller PMCs > instead of one big Jakarta one. And I think that's where we're > heading gradually, as we graduate projects, make them dormant, move > them elsewhere, etc. > > But because of the current structure of Jakarta and its current > membership, I'd probably say +0. It's not optimal, but it might be > the best solution for a large and largely mature umbrella-type > project. > Here I disagree. When you think about it, making committers==PMC analytic really amounts to dissolving the PMC. It could be that dissolving Jakarta is a good idea sometime soon, but as long as it exists as an apache project, it needs a PMC which is more than just a collection of committers with binding votes on code. This is why PMCs exist at apache and why you can't *define* the PMC to be the set of committers. As an alternative to Hen's "invite everyone" proposal, I would be fine with allowing and encouraging self-nominations. That would bring out committers who really want to be part of the PMC, but still allow us to vote them in. Phil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
