On Sat, Oct 17, 2015 at 10:23 AM, Sam Ruby <ru...@intertwingly.net> wrote:
> 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.
>
> 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.
>
> 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.
>
> 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.
This approach seems promising.
Folks may have heard some of us describe the Incubator as a
"curriculum"[0] -- but what exactly defines the "curriculum"?
Here are three candidates:
* The incubation checklist[1] a.k.a. each podling's "status page"
* ComDev's Maturity Model[2]
* The draft "Project Requirements" document[3] which gathers together
pointers to all ASF policy documents.
My take is that these are complementary efforts and that it is worth
ruminating on what each has to offer.
The Maturity Model defines evaluation criteria. It is probably the most
useful for the task we're focused on now, which is how to decide when a
proposed TLP is ready, regardless of the path it took towards readiness.
The incubation checklist is what we use to track a podling's incremental
progress through the Incubator. You could see it as an Incubator-specific
concrete realization of the Maturity Model, though as it is implemented today
it only covers a fraction of the Model's bullet points.
The Project Requirements document encompasses only policy, and thus only
covers a subset of the curriculum. However, because the Foundation's current
policy documentation is unbounded, irregular, and bloated, mastering this part
of the curriculum requires disproportionate effort.
I believe that if we can streamline all aspects of the curriculum, incubation
can take far less time and effort than it does today. And if we can reduce
the average time-to-incubate, many problems will simply solve themselves.
Marvin Humphrey
[0] The "curriculum" originally referred to the knowledge gained by a podling
release manager while guiding a release candidate through the Incubator.
[1] http://incubator.apache.org/projects/incubation-status-template.html
[2] https://community.apache.org/apache-way/apache-project-maturity-model.html
[3] http://www.apache.org/dev/project-requirements
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
