incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <>
Subject Re: Starting from the other end
Date Sat, 17 Oct 2015 21:33:05 GMT
On Sat, Oct 17, 2015 at 10:23 AM, Sam Ruby <> wrote:

> On Thu, Oct 15, 2015 at 2:55 PM, Ted Dunning <>
> wrote:
> >
> > So here we go. The first step (What Apache Incubator Does) can be edited
> at
> >
> >
> I guess somebody has to go first.
> My first impression: this description focus on how and not why, and it
> focuses on current (and therefore potentially legacy) processes.
> That's not to say it isn't useful, but another view should, in my
> opinion, be prepared first or at least in parallel.

Actually, what I want to focus on what the incubator does and decrease the
amount of how in the document as much as is practical.

Also, I would *very* strongly discourage preparing multiple documents about
how the incubator works.

Let's write down what we all think that the incubator does and then work to
fix that.  Obviously, independent paths are independent sort of thing and
can be specified independently, but let's focus efforts on the incubator to
get a singular vision.

> I'm growing increasingly enamored of the approach Bertrand (and
> others) are advocating: focusing on what the incubator ideally
> produces, namely a regular stream of Establish resolutions each
> accompanied by documentation assessing to the maturity of the proposed
> community.

This is an excellent thing to add to the document preamble.  Could you
propose something, either in a comment or as a text edit?

> If that becomes the accepted goal, then as a Director I only need to
> care about the end results, and as a mentor, I only need to care about
> the community or communities that I am working with.  Beyond that,
> different communities could be free to experiment with different
> processes.

That is quite possible. But I don't think that the current document
actually contradicts this flexibility.  If it does, can you suggest changes?

As I mentioned above, I think that having a clean focus on end-product is
an excellent change to the document as well.

> The end result is that the documentation that you (Ted) are producing,
> and for that matter the documentation exists on the Incubator web
> site, amounts to current best practices.  Which is a good thing, but
> perhaps should be considered less binding.

Well, I think that is one of the confusions that I would like to address
with this document. Ultimately, we should document what is required (that
projects be educated in the requirements of being a TLP) and what is
considered best practice.  There are second level requirements that are
deemed necessary by the incubator to function in a consistent fashion as
well (quarterly reports, mentors and so on). Some of this should be
considered requirements on incubating projects imposed by the incubator.

> We already have what amounts to three paths: there is the full
> Incubation process; there is is IP clearance, and there is straight to
> TLP.  We can view these as three points on a spectrum.  Having a well
> defined exit criteria and only applying the parts of the process that
> were needed to address deficiencies might have helped with projects
> like Subversion.

That is well and good, but what I am focussed on here is making the
Incubator process work as well as possible.  If the people working on
making a consistent process for other paths would like to crib this work,
that is great, but that is not the focus of the incubator.

But please, do make comments on the document itself.  Or suggest changes to
clarify or sharpen the document.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message