incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <>
Subject Re: a few steps before approving a project
Date Sat, 03 Sep 2005 06:25:19 GMT
On Wed, Aug 31, 2005 at 11:01:29AM -0700, Cliff Schmidt wrote:
> I'd like to suggest a few changes to the process of approving new
> project proposals.

I think I like your goals and some of your plans, but question whether
its smart to paint this as "changes to process". Just see how far you
get with "changes to documentation". Documentation changes are lazy
consensus around here :-)

> - change the Incubator PMC charter (not that we have a official
> charter) to include approving of all new projects, so that once a
> sponsor PMC (if not the Incubator PMC) approves a new project, the
> Incubator PMC still has to give a final approval.

Disagree. You can educate PMCs about whatever it would be that would
lead the incubator to make a different decision than they would, but
lets not have the incubator do more than absolutely neccessary.

> - ensure all proposals use the same standard template -- we've
> recently gotten proposals that simply copied some other proposal they
> saw -- we're not really making sure that any one set of standard
> questions is answered.

Yes please. Simple matter of writing a good template and putting it
somewhere visible on the site.

> - add a question to the template asking whether the person(s)
> proposing are aware of similar open source projects inside or outside
> the ASF.  I'm not suggesting that a project wouldn't get approved if
> there is some similar high profile open source project, but at least
> we are explicitly asking the question and getting the information.

Sure. Make it lots of questions, including FAQs from previous proposals.
Like this one. Information is good.

It'd be great if the PRC could add a bunch of questions to our template
if it helps to get the right information to them.

> - consider having a formal liaison at a few key external open source
> communities to give a friendly notice to whenever the Incubator PMC
> knows there's a proposal that could be controversial.   This really
> only works if we add the new proposal question mentioned above and
> create a more centralized process of looping the Incubator PMC in
> *before* a project is approved.

Ugh. I'm not volunteering. Can't open source communities continue to
function according to group based asynchronous web-based communication
mechanisms (such as this mailing list)? For example, we really haven't
needed a formal liason at the FSF in order to talk to them. If we can
manage to get various lawyers interacting with us through mailing lists,
why can't it be the same with open source orgs? Just send them all an
invite to read this mailing list!

> - require that the Incubator PMC loops in the PRC on any project that
> could have any chance of media attention (either because of the
> overall significance of the project, the potential for controversy,
> expected vendor press releases, or the opportunity to release a joint
> statement with some other organization).

Eh, yeah, sure. The incubator appreciates any and all help it can get
from the PRC. We obviously need it. A little more concretely, would a
simple Fwd of new project proposals to the prc@ do? Would that be
enough? If not, what else?

> I really don't want to add more process than necessary


> , but

I just *knew* you were going to say that!

> as the ASFs importance continues to grow, I think there a few issues that
> should be addressed with each new project, and I'm hoping steps like
> these could help that to happen.  Of course, an incubating project
> isn't an officially endorsed ASF project, but we still call it "Apache
> foo" and it's certainly perceived by the outside as being an action by
> the ASF when it is accepted for incubation.

And it is, after all, there's at least one PMC that votes on it. PMCs
are perfectly capable of carrying out actions on behalf of the ASF,
heck, they're the primary bodies for carrying out those actions.


We've never needed to go out of our way to go and tell people about our
various actions, since the stuff we do is publicly visible anyway. I
don't want that to change. There's a sliding scale here that ends with
warning a dozen marketing departments everytime we fart. They can just
subscribe to our announce@ lists like everyone else. And we'll send
them a press release when we want their attention.

You know, I'm not too happy with new project proposals now being
extensively prepared in private and drumrolls sounding when they "go
public". We did that with Harmony and I wasn't happy about it then,
and everytime I see it happening at least some kind of mess results. It
all gets in the way of the incubation work we have to do.

I think the "procedural fix" is that PMCs send new subproject proposals
this way (and the prc@ way) for the first time long before its voted on
so we can discuss things and form some consensus before various colors
of shite hit the fan. Eg

  From: me
  To: general@incubator
  Date: january 2005
  Subject: J2SE project?

  So, ehm, hi! Let's do a J2SE implementation @ Apache. I put some ideas
  on the wiki:

  WDYT? Feel free to patch the proposal!


Yes, we do our laundry in public, and yes, that must be a nightmare from
a PR perspective. We shouldn't stop doing our laundry in public though.

> BTW, the XMLBeans PMC just voted to add a single member to the PMC,
> and even that required a 72-hour wait after getting Board
> acknowledgement (which is fine with me)....why should there be
> fewer checks to get an entire project approved?

Eh, ain't there a whole bunch of checks as part of a process called
"incubation"? Which takes about two friggin' years on average??

Incubation is not meant to be viewed as endorsement of stuff by the ASF.
It is the start of a process of checks that may eventually lead to
endorsement. If PR departments don't get that, they can be educated. If
they can't be educated, they can, oh, I dunno, be ignored.

The Incubator is responsible for legal and IP vetting and for something
we might dub "community health ensurance". We shouldn't make ourselves
responsible for anything beyond that.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message