incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <johndam...@apache.org>
Subject Re: [DISCUSS] Podling report format changes
Date Thu, 02 Feb 2017 01:25:57 GMT
I think we're all squared away on this.  I'll commit the changes in the
next day or so, and we'll see what it looks like in March.

John

On Wed, Jan 25, 2017 at 2:52 PM John D. Ament <johndament@apache.org> wrote:

> Jim,
>
> No, its all good and I appreciate your time on this.  The APMM has been a
> source of confusion repeatedly.  If nothing else, this email reminded me I
> need to shake that tree out a bit.
>
> John
>
>
> On Wed, Jan 25, 2017 at 12:03 AM Jim Apple <jbapple@cloudera.com> wrote:
>
> Ah, sorry for the paragraphs, then.
>
> On Tue, Jan 24, 2017 at 5:52 PM, John D. Ament <johndament@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 <jbapple@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.ament@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-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message