incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: Radical revamp (was: an experiment)
Date Tue, 17 Aug 2010 02:22:37 GMT
On Mon, Aug 16, 2010 at 22:00, Noel J. Bergman <noel@devtech.com> wrote:
> Greg Stein wrote:
>...
>> 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 private@$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?

Presumably 3+ ASF Members is sufficient oversight. Given these Members
are the ONLY PMC members, then they must also remain pretty active in
their podling which implies oversight.

"oversight from others" is NOT a goal, when you have 3+ PMC members
already. My proposal ups that from "3+ PMC members" to "3+ ASF
Members", which (IMO) is a stronger guarantee.

(tho, for the most part, IPMC members *are* ASF Members, but Joe's
recent suggestions (which are good!) would alter that balance)

And do not minimize the peanut gallery problem. That is a very real
issue, and the "flipside" as you suggest is not a necessary part of
the process.

>> 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.

Empirically speaking... no, you cannot. The peanut gallery gets in the way.

>> 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.

I'm not asking for consensus. I'm proposing a whole new approach. And
this particular approach minimizes the "external effects" of
graduation: no mailing list renames, no subversion moves, no reporting
moves, etc.

>> 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,

Yes. Thus, my point that the Board is going to have to weigh in on
this topic at some point. But it needs some rounds of support and
beat-downs here on general@ before it is in a reasonable proposal
state for the Board. We also need some podlings who would like to
volunteer for this new approach, for the Board to consider.

> what *are* the graduation metrics, and who votes on
> graduation?

Dunno. I raised that in my original email.

I suspect that the metrics would be defined by the Incubator:
basically the checklist of considerations already present.

Regarding the vote: as I mentioned: the PMC comprised of the ASF
Members. It is possible that the PMC might add some non-Members over
time (like a regular PMC can and does), but I'm not very supportive of
this for projects in a *podling* state. I'd rather all those people
are added to the PMC at graduation time. There could be two ways to
graduate:

1) the PMC self-graduates
2) the PMC proposes graduation to the Board

I prefer the latter, as a final checkup/signoff to the process. The
PMC would need to arrive with $materials demonstrating satisfactory
completion of all incubation requirements.

Note: if *all* podlings move to this process, then the Incubator would
reduce to docs rather than oversight; which could imply a merge into
ComDev. But as I mentioned: I'm not sure the Members requirement is a
bar that most podlings can reach, so the Incubator is not going
anywhere, any time soon.

>> 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

Dunno. The question was raised, and it is a good question for
discussion. What *are* we attempting to protect by limiting releases
from podlings? Does that hold in this scenario? Are there other
modifications to the restrictions that can occur for these
TLP-podlings? etc.

A discussion points, nothing much more than that.

> 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?

Yup, good questions all. It was a fair point raised on IRC that I'm
bringing here.

>> Using this model decentralizes the process
>
> So does having 3+ PMC Members today.

The IPMC is anything but decentralized. And empirical evidence shows
it to peanut-gallery-ism.

>> 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.

Yups. The Incubator has provided a lot of focus on what we need, what
kinds of problems arise, and what we don't need.

I maintain that "additional oversight" is not required given the
composition of these TLPs membership (all ASF Members). So there is no
real loss in this proposed construct. Just a high bar of involvement
to *get* there.

>> 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.

Yup. Reference Justin's point about the Subversion PMC not recognizing
their own self-governance. Their initial introduction to the ASF put
them at the mercy of an invisible and nebulous group called "the
Incubator Project Management Committee". If the initial intro was a
self-governing PMC, then I think we wouldn't have the same kinds of
(admittedly minor) problems with queries about how to get certain
things done, or if they were allowed.

>> 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?

I suspect the OODT guys might want to try this (it has four ASF
Members as Mentors who could comprise the PMC). Subversion would have
done this, based on my own thoughts/experiences and knowledge of what
the ASF needs/wants.

Cheers,
-g

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message