On Tue, Jan 24, 2017 at 8:54 PM Julian Hyde <jh...@apache.org> wrote:
> 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 > > Julian, Exactly those. But ultimately, freeform to let the podling describe how they feel they are doing maturity wise. E.g. I wouldn't want to write down it must be one of those 4 items. Obviously I'd update http://incubator.apache.org/guides/ppmc.html to include this new section to explain how they feel they're doing. John > > > > 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 > >
