John, What did you have in mind for “podling maturity assessment”? If it is simply one of the existing phases - “still getting started”, “no release”, “community growth”, “ready to graduate” - I can’t see that being contentious.
Julian > On Jan 24, 2017, at 5:39 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