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 01:58:00 GMT
On Tue, Jan 24, 2017 at 8:54 PM Julian Hyde <jhyde@apache.org> wrote:

> 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
>
>
Julian,

Exactly those.  But ultimately, freeform to let the podling describe how
they feel they are doing maturity wise.  E.g. I wouldn't want to write down
it must be one of those 4 items.

Obviously I'd update http://incubator.apache.org/guides/ppmc.html to
include this new section to explain how they feel they're doing.

John


>
>
> > On Jan 24, 2017, at 5:39 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