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 > >
