On Feb 11, 2008, at 8:59 AM, William A. Rowe, Jr. wrote:
Niclas Hedhman wrote:On Monday 04 February 2008 04:11, Robert Burrell Donkin wrote:Personally, I don't see a difference between inactive committers in a podling than for a TLP.STM that something along these lines would be a more lightweight but equally effective process. we could ask the PPMC if it's pruned inactive committers from the graudation list.
I think there is a big difference between pruning committers from a podling and doing so for a TLP.
A podling is created with anyone who can sign an ICLA, accepted as a committer. The understanding that everyone who signs up will actually show up. In practice, this is not true, not necessarily due to any bad faith on anyone's part. So at graduation, the incubator PMC has to decide whether there is a community with independent actors who are "committed" to making the project a continuing effort. If there are committers who are not actually contributing, it makes the PMC's job a lot harder. It also diminishes the concept of meritocracy when folks who never participated are granted privileges that they didn't earn.
On the other hand, a duly constituted PMC doesn't allow non- participants to become committers or PMC members. Everyone must be voted in as committer or PMC member.
Should existing projects "prune" their committer lists on an annual basis? I think there is no need.The only argument for doing so is subversion access by 'abandoned' accounts. With the oversight of commit logs, in practice this is not an issue, so the one aspect that root might be concerned with is a user who does not use their people.apache.org shell login for a substantial period of time. Andthose cases would be better handled by infrastructure with an ASF-wide policy to achieve their goals of security for the foundation machines.So I don't see a difference with 'pruning' TLP committers. The only time I'd encourage it is to revoke bits that we never used (you'll notice over the long history of a project folks are given commit privs and never usethem. In this case, the project didn't have a chance to perform anyoversight if the privilege was used correctly, time makes it less likelythat the project will pay appropriate attention.)This is almost the exact same issue with a podling; if a user never actuallyparticipates, as the project graduates should they remain a committer?
The difference is that committers in a TLP have been granted this privilege based on their merit, not just by updating a wiki page saying that they're interested.
My gut check suggests the projects should ask those never-active committers if they plan to participate, or if are unlikely to ever do so. If not, adjust the committers access list appropriately (inviting them to come backwhenever they have cycles and interest to contribute)
We already have the concept of emeritus members who, having contributed in the past, are no longer active. I'd like to leave it up to each PMC to decide whether or when to change the status of previous committers/PMC members.
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
