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

Reply via email to