You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2015/10/15 11:46:46 UTC
[graduation] Maturity model-based assessment of Groovy for its graduation
Hi Incubator PMC,
FYI I have started an experiment at
https://github.com/apache/incubator-groovy/blob/master/MATURITY.adoc ,
using our maturity model to evaluate Groovy before its mentors suggest
its graduation (which should happen very soon).
So far this has helped uncover a few issues that we (at least I)
hadn't noticed otherwise. Nothing major, but interesting, and I think
it can be useful for the IPMC and Board once they have to decide to
graduate the podling.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [graduation] Maturity model-based assessment of Groovy for its graduation
Posted by Serge Huber <sh...@jahia.com>.
I’ll get right on creating one for Unomi, I’ve been wanting to use this since you first told me about it Bertrand :)
cheers,
Serge…
> On 19 nov. 2015, at 20:33, Bertrand Delacretaz <bd...@apache.org> wrote:
>
> Hi,
>
> On Thu, Oct 15, 2015 at 5:46 AM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
>> FYI I have started an experiment at
>> https://github.com/apache/incubator-groovy/blob/master/MATURITY.adoc ,
>> using our maturity model to evaluate Groovy...
>
> Groovy graduated now and doesn't have a good place to keep that
> document, so I'm pasting it below in case other podlings want to use
> it as an example.
>
> It will also stay at
>
> https://github.com/apache/incubator-groovy/blob/576b3c5d6a7022ac4a8df1ef118666456ce627fb/MATURITY.adoc
>
> -Bertrand
>
> **** GROOVY MATURITY *****
>
> = Groovy Podling Maturity Assessment
>
> == Overview
>
> This is an assessment of the Groovy podling's maturity, meant to help inform
> the decision (of the mentors, community, Incubator PMC and ASF Board of
> Directors) to graduate it as a top-level Apache project.
>
> It is based on the ASF project maturity model at
> https://community.apache.org/apache-way/apache-project-maturity-model.html
>
> Maintaining such a file is a new, experimental idea as part of the continuous
> improvement of the ASF incubation process. Groovy is the first podling where
> that happens.
>
> == Status of this document
> All open items resolved, ready for PPMC approval voting.
>
> == Overall assessment
> All the below items are marked OK, Groovy looks ready to graduate,
> discussions and votes
> are ongoing on the project's dev list as I write this (October 2015).
>
> == Maturity model assessment
> Mentors and community members are encouraged to contribute to this
> and comment on it.
>
> === Code
>
> ==== CD10
> _The project produces Open Source software, for distribution to the
> public at no charge._
>
> OK: of course.
>
> ==== CD20
> _The project's code is easily discoverable and publicly accessible._
>
> OK: http://groovy-lang.org/ (see CO10) includes a "fork me on Github" banner.
>
> ==== CD30
> _The code can be built in a reproducible way using widely available
> standard tools._
>
> OK: the build uses Gradle and continuous integration is used.
>
> ==== CD40
> _The full history of the project's code is available via a source code
> control system, in a way that allows any released version to be
> recreated._
>
> OK: Using Git, main repository at
> https://git-wip-us.apache.org/repos/asf/incubator-groovy.git, releases
> are cut
> from that repository.
>
> ==== CD50
> _The provenance of each line of code is established via the source
> code control system, in a reliable way based on strong authentication
> of the committer.
> When third-party contributions are committed, commit messages provide
> reliable information about the code provenance._
>
> OK, see CD40
>
> === Licenses and Copyright
>
> ==== LC10
> _The code is released under the Apache License, version 2._0._
>
> OK, LICENSE file has been accepted in release votes.
>
> ==== LC20
> _Libraries that are mandatory dependencies of the project's code do
> not create more restrictions than the Apache License does._
>
> OK: The list of dependencies at
> https://wiki.apache.org/incubator/GroovyProposal has been verified
> when entering incubation.
>
> The current dependency licenses (including build, runtime and optional
> dependencies) are found at
> https://github.com/apache/incubator-groovy/tree/master/licenses
>
> Assembling the licenses depending on the artifacts is done here:
> https://github.com/apache/incubator-groovy/blob/master/gradle/assemble.gradle
> so that the various artifacts get their correct sets of licenses.
>
> Release reviews have not shown any incompatible licenses.
>
> ==== LC30
> _The libraries mentioned in LC20 are available as Open Source software._
>
> OK, see LC20
>
> ==== LC40
> _Committers are bound by an Individual Contributor Agreement (the
> "Apache iCLA") that defines which code they are allowed to commit and
> how they need to identify code that is not their own._
>
> OK, all committers have iCLAs on file.
>
> ==== LC50
> _The copyright ownership of everything that the project produces is
> clearly defined and documented._
>
> OK, obvious for an ASF project.
>
> === Releases
>
> ==== RE10
> _Releases consist of source code, distributed using standard and open
> archive formats that are expected to stay readable in the long term._
>
> OK, verified in release votes.
>
> ==== RE20
> _Releases are approved by the project's PMC (see CS10), in order to
> make them an act of the Foundation._
>
> OK, releases have been voted by the Incubator PMC.
>
> ==== RE30
> _Releases are signed and/or distributed along with digests that can be
> reliably used to validate the downloaded archives._
>
> OK, verified in release votes.
>
> ==== RE40
> _Convenience binaries can be distributed alongside source code but
> they are not Apache Releases -- they are just a convenience provided
> with no guarantee._
>
> OK: https://dist.apache.org/repos/dist/release/incubator/groovy/2.4.5-incubating/
> for example clearly differentiates
> between source releases and distributions.
>
> === Quality
>
> ==== QU10
> _The project is open and honest about the quality of its code. Various
> levels of quality and maturity for various modules are natural and
> acceptable as long as they are clearly communicated._
>
> OK, Groovy has a long history of being a good citizen about quality.
>
> ==== QU20
> _The project puts a very high priority on producing secure software._
>
> OK, see QU10
>
> ==== QU30
> _The project provides a well-documented channel to report security
> issues, along with a documented way of responding to them._
>
> OK: http://groovy-lang.org/ does include a "security" link to
> http://groovy-lang.org/security.html which in turns points
> to http://www.apache.org/security/.
>
> The website also include the mandatory links listed at
> http://www.apache.org/foundation/marks/pmcs.html#navigation
>
> ==== 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._
>
> OK, see QU10.
>
> ==== QU50
> _The project strives to respond to documented bug reports in a timely manner._
>
> OK, response times on the users list and jira are good.
>
> === Community
>
> ==== CO10
> _The project has a well-known homepage that points to all the
> information required to operate according to this maturity model._
>
> OK: http://groovy.apache.org/ redirects to http://groovy-lang.org/ for
> now. The plan
> for the future is to use the former for Groovy development topics, and
> the latter
> for its user community.
>
> ==== CO20
> _The community welcomes contributions from anyone who acts in good
> faith and in a respectful manner and adds value to the project._
>
> OK, the community is working well in this respect.
>
> ==== CO30
> _Contributions include not only source code, but also documentation,
> constructive bug reports, constructive discussions, marketing and
> generally anything that adds value to the project._
>
> OK, Groovy has elected some non-coding committers.
>
> ==== CO40
> _The community is meritocratic and over time aims to give more rights
> and responsibilities to contributors who add value to the project._
>
> OK, Groovy has elected a few committers during incubation.
>
> ==== CO50
> _The way in which contributors can be granted more rights such as
> commit access or decision power is clearly documented and is the same
> for all contributors._
>
> OK, based on the standard ASF docs.
>
> ==== CO60
> _The community operates based on consensus of its members (see CS10)
> who have decision power. Dictators, benevolent or not, are not welcome
> in Apache projects._
>
> OK, demonstrated during incubation.
>
> ==== CO70
> _The project strives to answer user questions in a timely manner._
>
> OK, see QU50.
>
> === Consensus Building
>
> ==== 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._
>
> OK: will be at people.apache.org/committers-by-project.html#groovy-pmc
> once the project graduates.
>
> ==== CS20
> _Decisions are made by consensus among PMC members and are documented
> on the project's main communications channel. Community opinions are
> taken into account but the PMC has the final word if needed._
>
> OK, the Groovy team has been making and documenting decisions on its
> dev list during incubation.
>
> ==== CS30
> _Documented voting rules are used to build consensus when discussion
> is not sufficient._
>
> OK, using the standard ASF voting process,
> http://www.apache.org/foundation/voting.html
>
> ==== CS40
> _In Apache projects, vetoes are only valid for code commits and are
> justified by a technical explanation, as per the Apache voting rules
> defined in CS30._
>
> OK, vetoes haven't been abused during incubation.
>
> ==== CS50
> _All "important" discussions happen asynchronously in written form on
> the project's main communications channel. Offline, face-to-face or
> private discussions that affect the project are also documented on
> that channel._
>
> OK, see CS20.
>
> === Independence
>
> ==== IN10
> _The project is independent from any corporate or organizational influence._
>
> OK, no such influence has been detected during incubation.
>
> ==== IN20
> _Contributors act as themselves as opposed to representatives of a
> corporation or organization._
>
> OK, no worrying signals here during incubation.
>
> **** GROOVY MATURITY *****
>
> ---------------------------------------------------------------------
> 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
Re: [graduation] Maturity model-based assessment of Groovy for its graduation
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Thu, Oct 15, 2015 at 5:46 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> FYI I have started an experiment at
> https://github.com/apache/incubator-groovy/blob/master/MATURITY.adoc ,
> using our maturity model to evaluate Groovy...
Groovy graduated now and doesn't have a good place to keep that
document, so I'm pasting it below in case other podlings want to use
it as an example.
It will also stay at
https://github.com/apache/incubator-groovy/blob/576b3c5d6a7022ac4a8df1ef118666456ce627fb/MATURITY.adoc
-Bertrand
**** GROOVY MATURITY *****
= Groovy Podling Maturity Assessment
== Overview
This is an assessment of the Groovy podling's maturity, meant to help inform
the decision (of the mentors, community, Incubator PMC and ASF Board of
Directors) to graduate it as a top-level Apache project.
It is based on the ASF project maturity model at
https://community.apache.org/apache-way/apache-project-maturity-model.html
Maintaining such a file is a new, experimental idea as part of the continuous
improvement of the ASF incubation process. Groovy is the first podling where
that happens.
== Status of this document
All open items resolved, ready for PPMC approval voting.
== Overall assessment
All the below items are marked OK, Groovy looks ready to graduate,
discussions and votes
are ongoing on the project's dev list as I write this (October 2015).
== Maturity model assessment
Mentors and community members are encouraged to contribute to this
and comment on it.
=== Code
==== CD10
_The project produces Open Source software, for distribution to the
public at no charge._
OK: of course.
==== CD20
_The project's code is easily discoverable and publicly accessible._
OK: http://groovy-lang.org/ (see CO10) includes a "fork me on Github" banner.
==== CD30
_The code can be built in a reproducible way using widely available
standard tools._
OK: the build uses Gradle and continuous integration is used.
==== CD40
_The full history of the project's code is available via a source code
control system, in a way that allows any released version to be
recreated._
OK: Using Git, main repository at
https://git-wip-us.apache.org/repos/asf/incubator-groovy.git, releases
are cut
from that repository.
==== CD50
_The provenance of each line of code is established via the source
code control system, in a reliable way based on strong authentication
of the committer.
When third-party contributions are committed, commit messages provide
reliable information about the code provenance._
OK, see CD40
=== Licenses and Copyright
==== LC10
_The code is released under the Apache License, version 2._0._
OK, LICENSE file has been accepted in release votes.
==== LC20
_Libraries that are mandatory dependencies of the project's code do
not create more restrictions than the Apache License does._
OK: The list of dependencies at
https://wiki.apache.org/incubator/GroovyProposal has been verified
when entering incubation.
The current dependency licenses (including build, runtime and optional
dependencies) are found at
https://github.com/apache/incubator-groovy/tree/master/licenses
Assembling the licenses depending on the artifacts is done here:
https://github.com/apache/incubator-groovy/blob/master/gradle/assemble.gradle
so that the various artifacts get their correct sets of licenses.
Release reviews have not shown any incompatible licenses.
==== LC30
_The libraries mentioned in LC20 are available as Open Source software._
OK, see LC20
==== LC40
_Committers are bound by an Individual Contributor Agreement (the
"Apache iCLA") that defines which code they are allowed to commit and
how they need to identify code that is not their own._
OK, all committers have iCLAs on file.
==== LC50
_The copyright ownership of everything that the project produces is
clearly defined and documented._
OK, obvious for an ASF project.
=== Releases
==== RE10
_Releases consist of source code, distributed using standard and open
archive formats that are expected to stay readable in the long term._
OK, verified in release votes.
==== RE20
_Releases are approved by the project's PMC (see CS10), in order to
make them an act of the Foundation._
OK, releases have been voted by the Incubator PMC.
==== RE30
_Releases are signed and/or distributed along with digests that can be
reliably used to validate the downloaded archives._
OK, verified in release votes.
==== RE40
_Convenience binaries can be distributed alongside source code but
they are not Apache Releases -- they are just a convenience provided
with no guarantee._
OK: https://dist.apache.org/repos/dist/release/incubator/groovy/2.4.5-incubating/
for example clearly differentiates
between source releases and distributions.
=== Quality
==== QU10
_The project is open and honest about the quality of its code. Various
levels of quality and maturity for various modules are natural and
acceptable as long as they are clearly communicated._
OK, Groovy has a long history of being a good citizen about quality.
==== QU20
_The project puts a very high priority on producing secure software._
OK, see QU10
==== QU30
_The project provides a well-documented channel to report security
issues, along with a documented way of responding to them._
OK: http://groovy-lang.org/ does include a "security" link to
http://groovy-lang.org/security.html which in turns points
to http://www.apache.org/security/.
The website also include the mandatory links listed at
http://www.apache.org/foundation/marks/pmcs.html#navigation
==== 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._
OK, see QU10.
==== QU50
_The project strives to respond to documented bug reports in a timely manner._
OK, response times on the users list and jira are good.
=== Community
==== CO10
_The project has a well-known homepage that points to all the
information required to operate according to this maturity model._
OK: http://groovy.apache.org/ redirects to http://groovy-lang.org/ for
now. The plan
for the future is to use the former for Groovy development topics, and
the latter
for its user community.
==== CO20
_The community welcomes contributions from anyone who acts in good
faith and in a respectful manner and adds value to the project._
OK, the community is working well in this respect.
==== CO30
_Contributions include not only source code, but also documentation,
constructive bug reports, constructive discussions, marketing and
generally anything that adds value to the project._
OK, Groovy has elected some non-coding committers.
==== CO40
_The community is meritocratic and over time aims to give more rights
and responsibilities to contributors who add value to the project._
OK, Groovy has elected a few committers during incubation.
==== CO50
_The way in which contributors can be granted more rights such as
commit access or decision power is clearly documented and is the same
for all contributors._
OK, based on the standard ASF docs.
==== CO60
_The community operates based on consensus of its members (see CS10)
who have decision power. Dictators, benevolent or not, are not welcome
in Apache projects._
OK, demonstrated during incubation.
==== CO70
_The project strives to answer user questions in a timely manner._
OK, see QU50.
=== Consensus Building
==== 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._
OK: will be at people.apache.org/committers-by-project.html#groovy-pmc
once the project graduates.
==== CS20
_Decisions are made by consensus among PMC members and are documented
on the project's main communications channel. Community opinions are
taken into account but the PMC has the final word if needed._
OK, the Groovy team has been making and documenting decisions on its
dev list during incubation.
==== CS30
_Documented voting rules are used to build consensus when discussion
is not sufficient._
OK, using the standard ASF voting process,
http://www.apache.org/foundation/voting.html
==== CS40
_In Apache projects, vetoes are only valid for code commits and are
justified by a technical explanation, as per the Apache voting rules
defined in CS30._
OK, vetoes haven't been abused during incubation.
==== CS50
_All "important" discussions happen asynchronously in written form on
the project's main communications channel. Offline, face-to-face or
private discussions that affect the project are also documented on
that channel._
OK, see CS20.
=== Independence
==== IN10
_The project is independent from any corporate or organizational influence._
OK, no such influence has been detected during incubation.
==== IN20
_Contributors act as themselves as opposed to representatives of a
corporation or organization._
OK, no worrying signals here during incubation.
**** GROOVY MATURITY *****
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [graduation] Maturity model-based assessment of Groovy for its graduation
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Oct 19, 2015 at 2:10 AM, Sam Ruby <ru...@intertwingly.net> wrote:
> ...In particular, this document isn't a "metric", is is more of a
> checklist...
Yeah that was part of the maturity model's design [1]: avoid the
levels of compliance that many such models have, but rather make it
modular and granular.
I'm glad this seems to be working well, and the idea of focusing on
the Incubator output (resolutions + maturity evaluation) rather than
its process sounds very good to me.
-Bertrand
[1] If you're curious the comdev discussions that led to the current
version of the maturity model are at
http://s.apache.org/apache_maturity_model
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [graduation] Maturity model-based assessment of Groovy for its graduation
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Oct 17, 2015 at 1:48 PM, Joe Schaefer <jo...@gmail.com> wrote:
> Just looked over Bertrand's document and I must say while I had high
> expectations Bertrand has managed to surpass them. That this is a
> functional and itemized list of details is just perfect- even better that
> there are citations and references along with it!
>
> Excellent job Bertrand!
Ditto. I wish more of the pushback identified specific questions that
were over the top or overkill. I can honestly say that I didn't find
any. Some (like the licensing questions) may need to be tweaked over
time (e.g., I personally am aware of a number of projects with non
optional dependency on a JDK), but that can be worked over time.
In particular, this document isn't a "metric", is is more of a
checklist, with common sense things like "is the code open source, are
dependencies OK, have you made releases, is voting working smoothly,
is the community interdependent of external influences". Nor are the
questions pass/fail.
While this is indeed an all volunteer organization, I will submit that
those that vote on graduation matters and those that vote on Establish
resolutions are also volunteers; and making this information available
at the times of those votes will save a considerable amount of
volunteer effort.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [graduation] Maturity model-based assessment of Groovy for its graduation
Posted by Joe Schaefer <jo...@gmail.com>.
Just looked over Bertrand's document and I must say while I had high
expectations Bertrand has managed to surpass them. That this is a
functional and itemized list of details is just perfect- even better that
there are citations and references along with it!
Excellent job Bertrand!
On Sat, Oct 17, 2015 at 1:14 AM, Greg Stein <gs...@gmail.com> wrote:
> I concur, and similarly pushed back just a few days ago on another
> suggestion of such "policy".
>
> Not really sure that an ASF-wide metric is appropriate (ie. all communities
> are different, and freedom to set their own path is important), but there
> is definitely value in some in the model. It can with provide
> insight/review, and critical thinking about a community.
>
> Cheers,
> -g
>
> On Thu, Oct 15, 2015 at 7:21 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> > If we are to use the maturity model as the guideline regarding podling
> > graduation, then certainly the model should be voted on and approved
> > by the membership as *the* model for the ASF, right?
> >
> > Basically, it looks to me that the model is proposing and creating
> policy,
> > and this is something that needs to be done 'correctly', if you get my
> > meaning.
> >
> > > On Oct 15, 2015, at 5:46 AM, Bertrand Delacretaz <
> bdelacretaz@apache.org>
> > wrote:
> > >
> > > Hi Incubator PMC,
> > >
> > > FYI I have started an experiment at
> > > https://github.com/apache/incubator-groovy/blob/master/MATURITY.adoc ,
> > > using our maturity model to evaluate Groovy before its mentors suggest
> > > its graduation (which should happen very soon).
> > >
> > > So far this has helped uncover a few issues that we (at least I)
> > > hadn't noticed otherwise. Nothing major, but interesting, and I think
> > > it can be useful for the IPMC and Board once they have to decide to
> > > graduate the podling.
> > >
> > > -Bertrand
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
>
Re: [graduation] Maturity model-based assessment of Groovy for its graduation
Posted by Greg Stein <gs...@gmail.com>.
I concur, and similarly pushed back just a few days ago on another
suggestion of such "policy".
Not really sure that an ASF-wide metric is appropriate (ie. all communities
are different, and freedom to set their own path is important), but there
is definitely value in some in the model. It can with provide
insight/review, and critical thinking about a community.
Cheers,
-g
On Thu, Oct 15, 2015 at 7:21 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> If we are to use the maturity model as the guideline regarding podling
> graduation, then certainly the model should be voted on and approved
> by the membership as *the* model for the ASF, right?
>
> Basically, it looks to me that the model is proposing and creating policy,
> and this is something that needs to be done 'correctly', if you get my
> meaning.
>
> > On Oct 15, 2015, at 5:46 AM, Bertrand Delacretaz <bd...@apache.org>
> wrote:
> >
> > Hi Incubator PMC,
> >
> > FYI I have started an experiment at
> > https://github.com/apache/incubator-groovy/blob/master/MATURITY.adoc ,
> > using our maturity model to evaluate Groovy before its mentors suggest
> > its graduation (which should happen very soon).
> >
> > So far this has helped uncover a few issues that we (at least I)
> > hadn't noticed otherwise. Nothing major, but interesting, and I think
> > it can be useful for the IPMC and Board once they have to decide to
> > graduate the podling.
> >
> > -Bertrand
> >
> > ---------------------------------------------------------------------
> > 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
>
>
Re: [graduation] Maturity model-based assessment of Groovy for its graduation
Posted by Paul King <pa...@asert.com.au>.
I thought I'd comment from Groovy's point of view, being on the
"receiving" end of the audit.
I felt that the structure the audit provided to discussions about "Are
we there yet?" was very valuable. It didn't feel to me like the audit
was imposing any new requirement or policy that I hadn't heard about
before - just presenting a structured checklist to make sure we hadn't
forgotten anything and to avoid going over ground multiple times for
things which had been decided/discussed previously.
It was also presented to us as a guideline. I think this is a very
healthy way to view it. Most of our mentors seemed to have had a "gut
feel" for when projects are ready for graduation. A guideline doesn't
preclude that human aspect but does assist with focusing the
discussion around the important points and making it less subjective
in many areas. Also, as a guideline it would leave open the ability
for us to make a case for why a particular audit item may not apply or
might apply differently to us. We didn't end up having any such
requirement but if we did and we found an acceptable compromise, then
it would be recorded for future reference.
So, I'd certainly recommend any project adopting the maturity model as
a guideline.
Cheers, Paul.
On Fri, Oct 16, 2015 at 12:40 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
>> On Oct 15, 2015, at 10:03 AM, Rich Bowen <rb...@rcbowen.com> wrote:
>>
>>
>>
>> On 10/15/2015 08:21 AM, Jim Jagielski wrote:
>>> If we are to use the maturity model as the guideline regarding podling
>>> graduation, then certainly the model should be voted on and approved
>>> by the membership as *the* model for the ASF, right?
>>>
>>> Basically, it looks to me that the model is proposing and creating policy,
>>> and this is something that needs to be done 'correctly', if you get my
>>> meaning.
>>
>> +1
>>
>> This is why, in that other thread, I suggested that mentors voluntarily evaluate their podlings based on these guidelines, but didn't suggest any kind of actual policy change or requirement.
>>
>
> My only concern is that if it becomes a de-facto 'standard' w/o
> being vetted and approved by the membership/board/incubator/etc...
>
>
> ---------------------------------------------------------------------
> 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
Re: [graduation] Maturity model-based assessment of Groovy for its graduation
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Oct 15, 2015, at 10:03 AM, Rich Bowen <rb...@rcbowen.com> wrote:
>
>
>
> On 10/15/2015 08:21 AM, Jim Jagielski wrote:
>> If we are to use the maturity model as the guideline regarding podling
>> graduation, then certainly the model should be voted on and approved
>> by the membership as *the* model for the ASF, right?
>>
>> Basically, it looks to me that the model is proposing and creating policy,
>> and this is something that needs to be done 'correctly', if you get my
>> meaning.
>
> +1
>
> This is why, in that other thread, I suggested that mentors voluntarily evaluate their podlings based on these guidelines, but didn't suggest any kind of actual policy change or requirement.
>
My only concern is that if it becomes a de-facto 'standard' w/o
being vetted and approved by the membership/board/incubator/etc...
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [graduation] Maturity model-based assessment of Groovy for its
graduation
Posted by Rich Bowen <rb...@rcbowen.com>.
On 10/15/2015 08:21 AM, Jim Jagielski wrote:
> If we are to use the maturity model as the guideline regarding podling
> graduation, then certainly the model should be voted on and approved
> by the membership as *the* model for the ASF, right?
>
> Basically, it looks to me that the model is proposing and creating policy,
> and this is something that needs to be done 'correctly', if you get my
> meaning.
+1
This is why, in that other thread, I suggested that mentors voluntarily
evaluate their podlings based on these guidelines, but didn't suggest
any kind of actual policy change or requirement.
--Rich
>
>> On Oct 15, 2015, at 5:46 AM, Bertrand Delacretaz <bd...@apache.org> wrote:
>>
>> Hi Incubator PMC,
>>
>> FYI I have started an experiment at
>> https://github.com/apache/incubator-groovy/blob/master/MATURITY.adoc ,
>> using our maturity model to evaluate Groovy before its mentors suggest
>> its graduation (which should happen very soon).
>>
>> So far this has helped uncover a few issues that we (at least I)
>> hadn't noticed otherwise. Nothing major, but interesting, and I think
>> it can be useful for the IPMC and Board once they have to decide to
>> graduate the podling.
>>
>> -Bertrand
>>
>> ---------------------------------------------------------------------
>> 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
>
--
Rich Bowen - rbowen@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [graduation] Maturity model-based assessment of Groovy for its graduation
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Thu, Oct 15, 2015 at 3:11 PM, Stephen Mallette <sp...@gmail.com> wrote:
> ...As someone who is going through incubation right now, I think I would have
> liked to have been looking at the maturity model from day 1 of incubation...
Yes, that would be nice IMO.
As that's quite a new tool we are still experimenting. For now,
existing podlings who want to try it are of course free to create
their own MATURITY document for ongoing review.
A structured text version of the current maturity model can be found here:
https://raw.githubusercontent.com/apache/incubator-groovy/9161ff15cf74b746a507e2105a4c828c0ef667c3/MATURITY.adoc
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [graduation] Maturity model-based assessment of Groovy for its graduation
Posted by Stephen Mallette <sp...@gmail.com>.
As someone who is going through incubation right now, I think I would have
liked to have been looking at the maturity model from day 1 of incubation.
On Thu, Oct 15, 2015 at 8:30 AM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> On Thu, Oct 15, 2015 at 2:21 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> > ...If we are to use the maturity model as the guideline regarding podling
> > graduation, then certainly the model should be voted on and approved
> > by the membership as *the* model for the ASF, right?...
>
> That would be good yes. In the meantime it can still be used by the
> people who vote on graduation to inform their voting decision, IMO.
>
> (and note that a vote should be tied to a specific revision of that
> model, as I suppose it will evolve slightly over time)
>
> -Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [graduation] Maturity model-based assessment of Groovy for its graduation
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Oct 15, 2015 at 2:21 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> ...If we are to use the maturity model as the guideline regarding podling
> graduation, then certainly the model should be voted on and approved
> by the membership as *the* model for the ASF, right?...
That would be good yes. In the meantime it can still be used by the
people who vote on graduation to inform their voting decision, IMO.
(and note that a vote should be tied to a specific revision of that
model, as I suppose it will evolve slightly over time)
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [graduation] Maturity model-based assessment of Groovy for its graduation
Posted by Jim Jagielski <ji...@jaguNET.com>.
If we are to use the maturity model as the guideline regarding podling
graduation, then certainly the model should be voted on and approved
by the membership as *the* model for the ASF, right?
Basically, it looks to me that the model is proposing and creating policy,
and this is something that needs to be done 'correctly', if you get my
meaning.
> On Oct 15, 2015, at 5:46 AM, Bertrand Delacretaz <bd...@apache.org> wrote:
>
> Hi Incubator PMC,
>
> FYI I have started an experiment at
> https://github.com/apache/incubator-groovy/blob/master/MATURITY.adoc ,
> using our maturity model to evaluate Groovy before its mentors suggest
> its graduation (which should happen very soon).
>
> So far this has helped uncover a few issues that we (at least I)
> hadn't noticed otherwise. Nothing major, but interesting, and I think
> it can be useful for the IPMC and Board once they have to decide to
> graduate the podling.
>
> -Bertrand
>
> ---------------------------------------------------------------------
> 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
Re: [graduation] Maturity model-based assessment of Groovy for its
graduation
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 15/10/15 16:28, Filip Hanik a écrit :
> On Thursday, October 15, 2015, Emmanuel Lécharny <el...@gmail.com>
> wrote:
>
>> Le 15/10/15 13:17, Rich Bowen a écrit :
>>> A huge +1, but I wonder about a few things. Who does the work?
>> I guess that each PMC should be responsible for this work, with a dead
>> line soft enough that it allows each check to be done with no stress,
>> and under the supervision of some members in charge of helping them.
>>
>>> Who
>>> evaluates the results?
>> Either the board, or a group gathered for that purpose.
>
> the board? doesn't that become a bottleneck.
Indeed. The board can delegate ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [graduation] Maturity model-based assessment of Groovy for its graduation
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Oct 15, 2015 at 9:28 AM, Filip Hanik <fi...@hanik.com> wrote:
> On Thursday, October 15, 2015, Emmanuel Lécharny <el...@gmail.com>
> wrote:
> > Le 15/10/15 13:17, Rich Bowen a écrit :
>
>...
> > > Who
> > > evaluates the results?
> >
> > Either the board, or a group gathered for that purpose.
>
> the board? doesn't that become a bottleneck.
>
Not at all. "Bottleneck" implies motion that is slower than some desired
value. There's nothing saying "3 days" or "3 years".
But regardless, the Board reviews 70 reports *every* month. Every TLP
reports at least once per quarter. I don't think this would phase the Board
at all :-P ... it has more bandwidth than you'd expect.
Cheers,
-g
(with Director hat on)
Re: [graduation] Maturity model-based assessment of Groovy for its graduation
Posted by Filip Hanik <fi...@hanik.com>.
On Thursday, October 15, 2015, Emmanuel Lécharny <el...@gmail.com>
wrote:
> Le 15/10/15 13:17, Rich Bowen a écrit :
> > A huge +1, but I wonder about a few things. Who does the work?
>
> I guess that each PMC should be responsible for this work, with a dead
> line soft enough that it allows each check to be done with no stress,
> and under the supervision of some members in charge of helping them.
>
> > Who
> > evaluates the results?
>
> Either the board, or a group gathered for that purpose.
the board? doesn't that become a bottleneck.
>
> > What happens when projects "fail"?
> Well, I guss some corrective actions should be applied. The question is
> more about which of the item must be considered as mandatory, and which
> can simply be considered as optional.
>
>
> Bottom line, we most certainly will have to create a group of
> volunteers, for a limited period of time, a bit like the shepperds we
> have in Incubator.
>
> <side note>
> Actually, I think that at some point, we will need to audit each project
> periodically to check if they respect the various rules we now have (and
> that includes checking the N&L, a task that sebb is doing - and he
> deserves some respect for that ! -, and other aspects relative to the
> web site, the packages, etc...). But this is just something I feel in my
> guts, not something I see as necessary atm. I certainly don't want The
> ASF to become a giant buraucracy !!!
> </side note>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> <javascript:;>
> For additional commands, e-mail: general-help@incubator.apache.org
> <javascript:;>
>
>
Re: [graduation] Maturity model-based assessment of Groovy for its
graduation
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 15/10/15 13:17, Rich Bowen a écrit :
> A huge +1, but I wonder about a few things. Who does the work?
I guess that each PMC should be responsible for this work, with a dead
line soft enough that it allows each check to be done with no stress,
and under the supervision of some members in charge of helping them.
> Who
> evaluates the results?
Either the board, or a group gathered for that purpose.
> What happens when projects "fail"?
Well, I guss some corrective actions should be applied. The question is
more about which of the item must be considered as mandatory, and which
can simply be considered as optional.
Bottom line, we most certainly will have to create a group of
volunteers, for a limited period of time, a bit like the shepperds we
have in Incubator.
<side note>
Actually, I think that at some point, we will need to audit each project
periodically to check if they respect the various rules we now have (and
that includes checking the N&L, a task that sebb is doing - and he
deserves some respect for that ! -, and other aspects relative to the
web site, the packages, etc...). But this is just something I feel in my
guts, not something I see as necessary atm. I certainly don't want The
ASF to become a giant buraucracy !!!
</side note>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [graduation] Maturity model-based assessment of Groovy for its graduation
Posted by Rich Bowen <rb...@rcbowen.com>.
A huge +1, but I wonder about a few things. Who does the work? Who
evaluates the results? What happens when projects "fail"?
Le 15/10/15 11:46, Bertrand Delacretaz a écrit :
> Hi Incubator PMC,
>
> FYI I have started an experiment at
> https://github.com/apache/incubator-groovy/blob/master/MATURITY.adoc ,
> using our maturity model to evaluate Groovy before its mentors suggest
> its graduation (which should happen very soon).
>
> So far this has helped uncover a few issues that we (at least I)
> hadn't noticed otherwise. Nothing major, but interesting, and I think
> it can be useful for the IPMC and Board once they have to decide to
> graduate the podling.
That's an interesting exercise !
Having read the document Betrand has completed for Groovy, I do think
that an audit of all the existing TLP should be done in the next month
to check if all the iterms are correctly fullfiled. I suspect we would
be surprised...
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [graduation] Maturity model-based assessment of Groovy for its
graduation
Posted by Ross Gardler <Ro...@microsoft.com>.
Absolutely should be voluntary. We don't need more red tape. We need better guidance.
The model is good guidance. Individual volunteers should evaluate from their own perspective and work towards improving areas they feel attached to.
That is, someone in the project from day one will not have the same view as someone new to the community. The model is qualitative not quantative and thus open to interpretation. I'd hate for us to be too formal in its application, ir will only lead to more debate over what is/is not best practice.
Sent from my Windows Phone
________________________________
From: Bertrand Delacretaz<ma...@apache.org>
Sent: 10/19/2015 1:15 AM
To: Incubator General<ma...@incubator.apache.org>
Subject: Re: [graduation] Maturity model-based assessment of Groovy for its graduation
On Mon, Oct 19, 2015 at 3:25 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
> ...that might just be me...
I agree that each of our projects regularly evaluating their state
against the maturity model would be useful. We can either make that a
requirement (like once a year as part of the board reporting) or make
that an optional "quality label" that projects can display on their
website, like a regularly updated version of what we're doing for the
Groovy podling at [1].
I prefer the latter, a voluntary public report that can be used by the
project's community as well as the board as a tool for evaluating the
project's health but without imposing more process on our projects.
(and as others have said this would be a more a discussion for comdev,
it's not incubator-specific)
-Bertrand
[1] https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fapache%2fincubator-groovy%2fblob%2fmaster%2fMATURITY.adoc&data=01%7c01%7cRoss.Gardler%40microsoft.com%7ce2726e97741446892af008d2d85d83b8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=S9OUjkxEVetVVYnnNOs4oP47WnfSqnvPB%2fTpfzF2iHk%3d
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [graduation] Maturity model-based assessment of Groovy for its graduation
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Oct 19, 2015 at 3:25 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
> ...that might just be me...
I agree that each of our projects regularly evaluating their state
against the maturity model would be useful. We can either make that a
requirement (like once a year as part of the board reporting) or make
that an optional "quality label" that projects can display on their
website, like a regularly updated version of what we're doing for the
Groovy podling at [1].
I prefer the latter, a voluntary public report that can be used by the
project's community as well as the board as a tool for evaluating the
project's health but without imposing more process on our projects.
(and as others have said this would be a more a discussion for comdev,
it's not incubator-specific)
-Bertrand
[1] https://github.com/apache/incubator-groovy/blob/master/MATURITY.adoc
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [graduation] Maturity model-based assessment of Groovy for its
graduation
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 18/10/15 10:48, Martijn Dashorst a écrit :
> -1 on requiring all projects to do this exercise. It is not policy,
> and frankly as a volunteer organization we can let the communities
> themselves determine whether this is something they want to spend
> their time on.
Well, I unerstand your concerns, but it seems odd that we engage podling
to go through such a process that we haven't asked the TLP to do in the
past, and not check that the TLPs at large are compliant with such a
check list.
>
> I thought we were a community for/over code, not a bureaucracy for/over code.
As a community focused foundation, I'd rather see such an exercise as a
reinsurance for the larger community that are our users that we do
fulfill The ASF expectations in various areas. Calling that bureaucratcy
is a bit like saying the checklist every pilot is doing before take off
a spurious and annoying task...
>
> If/when a community finds itself in a hard spot, perhaps *then* it is
> valuable to assess the maturity model, to see how/what can be improved
> upon. But requiring this of all projects? With a deadline too?
Would'nt it be too late ? Wouldn't it be a better idea to check
peridodically that no hard spot is appearing ? Fixing a community is way
more difficult than anticipating potential pitfalls that can derail the
process later on...
But that might just be me...
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [graduation] Maturity model-based assessment of Groovy for its graduation
Posted by Martijn Dashorst <ma...@gmail.com>.
-1 on requiring all projects to do this exercise. It is not policy,
and frankly as a volunteer organization we can let the communities
themselves determine whether this is something they want to spend
their time on.
I thought we were a community for/over code, not a bureaucracy for/over code.
If/when a community finds itself in a hard spot, perhaps *then* it is
valuable to assess the maturity model, to see how/what can be improved
upon. But requiring this of all projects? With a deadline too?
Martijn
On Thu, Oct 15, 2015 at 12:14 PM, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 15/10/15 11:46, Bertrand Delacretaz a écrit :
>> Hi Incubator PMC,
>>
>> FYI I have started an experiment at
>> https://github.com/apache/incubator-groovy/blob/master/MATURITY.adoc ,
>> using our maturity model to evaluate Groovy before its mentors suggest
>> its graduation (which should happen very soon).
>>
>> So far this has helped uncover a few issues that we (at least I)
>> hadn't noticed otherwise. Nothing major, but interesting, and I think
>> it can be useful for the IPMC and Board once they have to decide to
>> graduate the podling.
>
> That's an interesting exercise !
>
> Having read the document Betrand has completed for Groovy, I do think
> that an audit of all the existing TLP should be done in the next month
> to check if all the iterms are correctly fullfiled. I suspect we would
> be surprised...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [graduation] Maturity model-based assessment of Groovy for its
graduation
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 15/10/15 13:49, Bertrand Delacretaz a écrit :
> On Thu, Oct 15, 2015 at 12:14 PM, Emmanuel Lécharny <el...@gmail.com> wrote:
>> ...I do think
>> that an audit of all the existing TLP should be done in the next month
>> to check if all the iterms are correctly fullfiled....
> That would be interesting but that's 167 TLPs if my memory is
> correct...that's a a lot of work for next month ;-)
I was not specifically thinking about such a short term target ;-) In my
mind, this is something that could take a full year...
And, no, that is not an incubator concern, I'm just bouncing the ball
one step farther...
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [graduation] Maturity model-based assessment of Groovy for its graduation
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Oct 15, 2015 at 12:14 PM, Emmanuel Lécharny <el...@gmail.com> wrote:
> ...I do think
> that an audit of all the existing TLP should be done in the next month
> to check if all the iterms are correctly fullfiled....
That would be interesting but that's 167 TLPs if my memory is
correct...that's a a lot of work for next month ;-)
Maybe we can ask each PMC to do this within a reasonable time frame,
say 3 months...but that's not an Incubator concern then.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [graduation] Maturity model-based assessment of Groovy for its
graduation
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 15/10/15 11:46, Bertrand Delacretaz a écrit :
> Hi Incubator PMC,
>
> FYI I have started an experiment at
> https://github.com/apache/incubator-groovy/blob/master/MATURITY.adoc ,
> using our maturity model to evaluate Groovy before its mentors suggest
> its graduation (which should happen very soon).
>
> So far this has helped uncover a few issues that we (at least I)
> hadn't noticed otherwise. Nothing major, but interesting, and I think
> it can be useful for the IPMC and Board once they have to decide to
> graduate the podling.
That's an interesting exercise !
Having read the document Betrand has completed for Groovy, I do think
that an audit of all the existing TLP should be done in the next month
to check if all the iterms are correctly fullfiled. I suspect we would
be surprised...
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org