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
