Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of gstein@gmail.com designates
 209.85.216.175 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=qJ/wPAkrY/39kbmSJ5o6RGFDTAds1c0wRyk84G3kttt23sN0uyZNLt9FStlPEiHqek
         84Vd22dxCoaeJmQfAGyaOKIq7NQ/998bMRz6EpjNFajSGNBfxrPxcGl4sBGokOeKVICb
         Cbo7GcEmXeHatRa92+9UjVJIem+vjhmY4CLsM=
MIME-Version: 1.0
Date: Mon, 16 Aug 2010 20:29:16 -0400
Message-ID: <AANLkTikBgomZO6mR438nbqORFFSGYp+xCX40HcJATx+7@mail.gmail.com>
Subject: Radical revamp (was: an experiment)
From: Greg Stein <gstein@gmail.com>
To: general@incubator.apache.org, Justin Erenkrantz <jerenkrantz@apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 16, 2010 at 12:45, Justin Erenkrantz <justin@erenkrantz.com> wr=
ote:
> On Mon, Aug 16, 2010 at 9:36 AM, Noel J. Bergman <noel@devtech.com> wrote=
:
>> And if the Mentors aren't being active, voting, etc., then *that* is wha=
t
>> needs to be addressed.
>
> As I've repeatedly stated before (here and elsewhere), in the podlings
> I've been recently involved with, having three mentors isn't the
> issue. =A0It's the PMC members who aren't involved sticking their nose
> in and trying to poison the community.
>
>> We have one of the largest PMCs in the ASF. =A0If we
>
> I view this as potentially the crux of the problem - people who aren't
> stakeholders in the community shouldn't have a say. =A0Right now, they
> feel they do. =A0So, 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. =A0-- justin

I threw out a radical idea on IRC and a few of us walked through it.
At its core, it solves the "peanut gallery" problem that you're
talking about.

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

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

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.

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

This pattern can be documented by the Incubator or the Community
Development project. Doesn't matter, but it would certainly be
standardized much like we're standardizing within the Incubator
itself.

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

Using this model decentralizes the process, removes vocal minorities,
allows for better tuning of a PMC process to its community, and breaks
down the Incubator umbrella project.

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 (tho what does it say about
projects without this kind of active support?). Obviously, we'd also
need Board buy-in for the construction of these TLPs (tho, it *is*
only comprised of Members).

Thoughts?

Cheers,
-g

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