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
