incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: Making up policy on the fly
Date Wed, 19 Aug 2009 17:15:23 GMT
----- Original Message ----

> From: "William A. Rowe, Jr." <>
> To:
> Sent: Wednesday, August 19, 2009 1:01:04 PM
> Subject: Re: Making up policy on the fly
> Craig L Russell wrote:
> > 
> > On Aug 19, 2009, at 12:23 AM, ant elder wrote:
> >>
> >> +1. And i'd go further and say while the ASF does not have a clear
> >> policy on something that is an ASF issue then the IPMC should not be
> >> trying to make up our own, and, we should be trying to shield
> >> poddlings from these ambiguities.
> > 
> > I'd go exactly the other direction.
> > 
> > The fact that policy has "should" instead of "must" tells me that best
> > practice is to do the "should" but for historical reasons, it's not a
> > requirement. Historically some PMCs have not done the "should" and we
> > can't go back and change history, but going forward, projects "should"
> > comply.
> > 
> > The incubator should be the place where "should" becomes "must" so as to
> > align newcomers to Apache with best practice. If there's some very good
> > reason for a podling to eschew best practice, then let's hear it.
> Exactly.  The incubator enforces Best Practices even when these are poorly
> documented or incomplete, and discusses why they should be normalized.
> Quit looking at the exceptions; "but the Poo project does it this way!";
> because Poo might have it wrong, but the board isn't compelled at this
> time to fix it because the fix might do more harm than good.
> In the meantime, we have dozens of projects who are here to learn the
> *right* way to build code and communities in collaborative, meritocratic
> manner that survives competitors working together on the same code, and
> from the mistakes of other projects.  E.g. it is the board's opinion that
> @author tags harm the evolution of software, adding individual 'ownership'
> to pieces of code which are the project's now.  Exceptions were granted
> to not disrupt *existing* ASF projects; there was no exception granted for
> incoming projects.
> This is why mentoring is an active, not a passive task.

Amen to all of the above.


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

View raw message