Jim, No, its all good and I appreciate your time on this. The APMM has been a source of confusion repeatedly. If nothing else, this email reminded me I need to shake that tree out a bit.
John On Wed, Jan 25, 2017 at 12:03 AM Jim Apple <jbap...@cloudera.com> wrote: > Ah, sorry for the paragraphs, then. > > On Tue, Jan 24, 2017 at 5:52 PM, John D. Ament <johndam...@apache.org> > wrote: > > Jim, > > > > Don't read too deeply into my use of "Podling Maturity Assessment." The > > sections of the current summary are simply "Ready to Graduate", "Some > > Community Growth", "No Release" and "Still Getting Started." I'm simply > > asking the podling to decide which of those 4 best describe themselves. > > > > John > > > > On Tue, Jan 24, 2017 at 8:40 PM Jim Apple <jbap...@cloudera.com> wrote: > > > >> There were a number of people who opposed the use of the maturity > >> model on this list in 2016. For instance, Greg Stein said: "There has > >> been past controversy on including that as a graduation step. I'm not > >> clear that was a proper addition." and "The Board has never required > >> the IPMC to use the APMM as a requirement for graduation." > >> > >> I find it to be pretty strange. Two examples: > >> > >> 1. "Convenience binaries can be distributed alongside source code but > >> they are not Apache Releases -- they are just a convenience provided > >> with no guarantee." > >> > >> I don't imagine this REQUIRES binaries, since > >> http://www.apache.org/legal/release-policy says: > >> > >> "The Apache Software Foundation produces open source software. All > >> releases are in the form of the source materials needed to make > >> changes to the software being released." > >> > >> So, if this isn't requiring binary releases, it seems to simply be > >> limiting them. That's fair enough, but how is that level level 4 of > >> "Releases" while "Releases are signed and/or distributed along with > >> digests", which requires actual work, is only level 3. Level 4 can be > >> achieved whilst napping by not guaranteeing anything while > >> sleepwalking. > >> > >> 2. A number of the items don't seem to be mentioned in any other > >> incubating guide or don't seem to me to be true of TLPs in general. > >> Adding them here makes it look like there is new incubator policy that > >> snuck in the back door. Here are things I don't recall seeing > >> elsewhere: > >> > >> "The code can be built in a reproducible way using widely available > >> standard tools." -- widely available? > >> > >> "The project is open and honest about the quality of its code." -- > >> Does anywhere else in the incubation documentation describe any sort > >> of quality disclosure procedure? What does this even mean -- what is > >> the scale? > >> > >> "The project puts a high priority on backwards compatibility" -- Is > >> this mentioned anywhere else on the incubation webpages? > >> > >> "The way in which contributors can be granted more rights such as > >> commit access or decision power is clearly documented" -- is this even > >> true for most TLPs? I spent some time looking at how big data TLPs > >> describe commit bit approvals, and most seem to be extremely vague in > >> describing what constitutes enough of a contribution to be granted the > >> bit. > >> > >> "The project is independent from any corporate or organizational > >> influence." -- Didn't Stratos just get moved to the attic because its > >> main corporate backer stopped backing it? How many other TLPs are in > >> this same boat? > >> > >> On Tue, Jan 24, 2017 at 5:15 PM, John D. Ament <john.d.am...@gmail.com> > >> wrote: > >> > All, > >> > > >> > The Incubator PMC has received feedback from the board that changes > may > >> > need to be made to the structure of our report. Specifically, there > is > >> > confusion from the board members over how podlings get classified. > There > >> > is also a request to increase and improve mentor feedback on podling > >> > reports. Based on this input, I would like to propose the following > >> > changes to our report format. I would like to try to implement this > for > >> > the March report, if not before then. > >> > > >> > 1. Eliminate the podling summary section of the report. It shouldn't > be > >> on > >> > the report manager to classify each podling. We have begun > leveraging a > >> > maturity model for podlings, while its not required to fulfill it > serves > >> as > >> > an equivalent to this section. The list of podlings who failed to > report > >> > shall remain. > >> > > >> > 2. Add a "Podling Maturity Assessment" to the individual podling > reports. > >> > This would give a clear opportunity for each podling to describe how > they > >> > are doing, perhaps compared to the maturity model or our classic > >> categories. > >> > > >> > 3. Change the mentor sign off section to include a per-mentor comment. > >> > E.g. instead of the current: > >> > > >> > [ ](podling) mentor1 > >> > [ ](podling) mentor2 > >> > [ ](podling) mentor3 > >> > > >> > It would be: > >> > > >> > [ ](podling) mentor1 > >> > Comments: > >> > [ ](podling) mentor2 > >> > Comments: > >> > [ ](podling) mentor3 > >> > Comments: > >> > > >> > And rename Shepherd/Mentor notes: to just "Shepherd notes:" > >> > > >> > Thoughts? > >> > > >> > John > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >> For additional commands, e-mail: general-h...@incubator.apache.org > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
