Chris,

Thanks, this is very helpful. I have created tickets for these items (hope
you don't mind I made you the reporter):

https://issues.apache.org/jira/issues/?jql
=project%20%3D%20APEXCORE%20and%20labels%20%3D%20tlp

I was under the impression that the "Who We Are" page should be setup at
time of graduation to replace the information on the status page. But if it
is best practice, we will do the double maintenance ;-)

Thanks again,
Thomas

On Wed, Jan 27, 2016 at 4:58 PM, Chris Nauroth <[email protected]>
wrote:

> I agree that it's good to start the graduation discussion, pending
> resolution of the documentation and release items mentioned by other
> mentors in the thread.  I've been very impressed with this community's
> level of activity and openness.
>
> I took a pass through the maturity model, and I'd like to call out the
> items that may need additional work.  I also have pointed out examples of
> how an existing project meets these criteria.  (I used Hadoop, because
> it's the project I know best.)
>
> This exercise is best done as a self-evaluation by the most involved
> contributors, so it's possible that my perspective is incomplete.  I
> encourage more of the deeply involved community members to review the
> maturity model in detail and draw their own conclusions.
>
> Also, I want to make sure it's clear that the maturity model is not an
> absolute list of requirements.  It is the community's choice on whether or
> not to address these points before a graduation proposal.  However, some
> IPMC members do use the maturity model as a checklist to gauge the health
> of a podling, so you'll bolster your case for graduation with the wider
> IPMC if you choose to take action on them.  I also think all of these
> things are generally good for the project anyway, so it's not just a
> matter of satisfying bureaucratic demands.
>
> QU30
> The project provides a well-documented channel to report security issues,
> along with a documented way of responding to them.
>
> I couldn't find a security vulnerability process documented at
> apex.incubator.apache.org.  Example:
> http://hadoop.apache.org/mailing_lists.html
>
> QU40
> The project puts a high priority on backwards compatibility and aims to
> document any incompatible changes and provide tools and documentation to
> help users transition to new features.
>
> I couldn't find backwards-compatibility guidelines documented at
> apex.incubator.apache.org.  Example:
> http://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/Comp
> atibility.html
>
> CS10
> The project maintains a public list of its contributors who have decision
> power -- the project's PMC (Project Management Committee) consists of
> those contributors.
>
> I couldn't find a "Who We Are" page at apex.incubator.apache.org.  I think
> the information is accurate in the incubation status page though.
> Example: https://hadoop.apache.org/who.html
>
> CS30
> Documented voting rules are used to build consensus when discussion is not
> sufficient.
>
> I couldn't find any statement of this.  Example:
> http://hadoop.apache.org/bylaws.html
>
>
> --Chris Nauroth
>
>
>
>
> On 1/25/16, 2:28 PM, "Sandesh Hegde" <[email protected]> wrote:
>
> >+1
> >
> >Code: CD50
> >Licenses and Copyright: LC50
> >Quality: QU50
> >Community: CO50
> >Independence: IN20
> >Releases: RE40
> >
> >Thanks
> >
> >
> >On Mon, Jan 25, 2016 at 2:09 PM Justin Mclean <[email protected]>
> >wrote:
> >
> >> Hi,
> >>
> >> It¹s not required but you might want to rate yourself with this [1]
> >>like a
> >> few other projects have done. [2][3]
> >>
> >> Thanks,
> >> Justin
> >>
> >> 1.
> >>
> >>
> https://community.apache.org/apache-way/apache-project-maturity-model.htm
> >>l
> >> 2. https://zest.apache.org/community/maturity.html
> >> 3.
> >>
> >>
> https://github.com/apache/groovy/blob/576b3c5d6a7022ac4a8df1ef118666456ce
> >>627fb/MATURITY.adoc
>
>

Reply via email to