On Sat, Oct 17, 2015 at 10:23 AM, Sam Ruby <ru...@intertwingly.net> wrote:
> On Thu, Oct 15, 2015 at 2:55 PM, Ted Dunning <ted.dunn...@gmail.com> > wrote: > > > > > So here we go. The first step (What Apache Incubator Does) can be edited > at > > > > > https://docs.google.com/document/d/1dxUVHGWcj83wIVnskYL7iM7PiiScLLNS4HjGHa6LsgA/edit?usp=sharing > > 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.
