Greg Stein wrote:
> Justin Erenkrantz wrote:
> > I view this as potentially the crux of the problem - people who aren't
> > stakeholders in the community shouldn't have a say. Right now, they
> > feel they do. So, if we want to mandate at least 3 mentors - fine,
> > but that must come at the cost of telling the rest of the IPMC to go
> > away - unless they actively contribute to the community and earn
> > merit...of course.
> Consider this:
> Make the podling a TLP comprised of *only* ASF Members, with at least
> *three* minimum (preferably more, to deal with idle times). The
> podling committers are invited onto the priv...@$podling.apache.org
> mailing list, but have non-binding votes. They are there for private
> discussion, to offer non-binding votes on committers, and to "see" how
> a private mailing is used and how it is NOT used.
How does that differ from the current system (given the assumption of 3+ PMC
Members), except that it precludes potential oversight from others -- the
flipside of "solves the peanut gallery problem" that apparently plagued
Subversion?
> Since you have (at least) three people on the PMC, you can accomplish
> all necessary business: releases, adding accounts, and deciding to ask
> the Board for your "graduation".
Yes. You can do that today, too, with 3+ PMC Members.
> The mailing lists can be in the "right place", but can have footers
> attached noting the "incubation" status. The $podling.apache.org
> website "should" redirect to (say) incubator.apache.org/projects/$podling
> and have all the standard disclaimers. At graduation, they get the
> apache.org site and a few redirects are put in place. Releases should
> also have all the same caveats, warnings, and disclaimers.
We could do that now, except that people have previously disliked the idea
of $podling.apache.org being provided prior to graduation, for either e-mail
or web site addresses. If the consensus is to change that, fine.
> Graduation could simply be a TLP deciding to add the rest of the
> committers to its PMC and asking infrastructure to create the website,
> etc. Or it could require a Board resolution which also mass-adds PMC
> members. It's kind of unclear how much oversight the Board should have
> on the graduation (note that the (pseudo) TLP will be filing reports
> just like any other TLP, so the Board sees its progress).
Please clarify. Wouldn't the Board have to establish this TLP
pre-Incubation, what *are* the graduation metrics, and who votes on
graduation?
> Restrictions like those on websites or releases could be relaxed. It
> was a fair question to ask, "why keep those in place? what are we
> trying to protect?"
Why relax them uniquely for such projects? And presumably we are protecting
the ASF brand, as well as downstream consumers who rely on our output,
including clean licensing, etc. But getting back to the first point, is
there some rationale to relax them for these podlings and not for others?
If we can justify them for some, should we re-examine them in general?
> Using this model decentralizes the process
So does having 3+ PMC Members today.
> removes vocal minorities
True. The flipside is that it also removes additional oversight. Remember
that the Board created the Incubator because of problems with existing
projects trying incubation on their own. But we have learned a lot since
then.
> allows for better tuning of a PMC process to its community, and breaks
> down the Incubator umbrella project.
Possibly so, which would be good things.
> Finding 3+ Members to be on these mini/pseudo TLPs would be quite
> difficult. I don't think this kind of process would be available or
> workable to *all* podlings. But for projects with active Member
> support, this could be a valid approach
> Thoughts?
I think that it is a very interesting proposal, that could work very well in
specific circumstances, and I'd be willing to see it tried as an experiment,
if the Board buys into it. Do we have any such projects pending or already
in the Incubator?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
