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 Wed, 25 Jan 2017 19:52:12 GMT
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