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

Reply via email to