The concept of the GEP was freely inspired from Pytho=
n's PEP (Python Enhancement Proposal).

=20

Rationale: Why=
a GEP?

=20

For non-trivial, complex or strategic features, discussions on mailing-l=
ists are difficult to lead and follow, and often don't help reach a concens=
us. Writing a proper document explaining the design and implications of sai=
d feature allows both the originator of the idea and the community at large=
to have a chance to provide interesting and useful feedback and helps bett=
er undestanding the rationale, the design decisions, the impact of the prop=
osal.

=20

What's in a GEP?=20

A GEP is:

=20

=20

led by a "Leader" who is responsible for the=
writing and progress of the proposal

=20

assigned a unique "Number"

=20

has got a "Title" describing succintly its i=
ntent

=20

has a "Type"

=20

has a "Status" giving information on its pro=
gress

=20

has a "Version" number indicating its curren=
t revision

=20

gives a "Last modification" date

=20

gives a "Creation" date

=20

features an "Abstract" explaining the intent=
of the GEP

=20

gives a "Rationale" for this enhancement

=20

=20

The type of a GEP can be of the following:

=20

=20

"Informational": if the GEP provides some in=
formation or guidance on a topic related to Groovy (this GEP is of such typ=
e, as well as the list of all existing GEPs)

=20

"Feature": if the GEP is about the implement=
ation of a new feature, enhancement or a change in Groovy

=20

"Process": if the GEP describes a process re=
lated to the Groovy project (examples: the Groovy release process, how to e=
nroll new committers, etc.)

=20

=20

If the GEP is a Feature GEP, it should also:

=20

=20

define a "Target" Groovy version for its int=
egration

=20

provide a "Reference implementation" properl=
y covered by unit tests and commented (JavaDoc comments as well as inline c=
omments) so that the Groovy community can play with the enhancement and pro=
vide useful feedback

=20

detail the "Impact" on Groovy, especially in=
terms of backward-compatibility

=20

=20

The "Status" of a GEP can be:

=20

=20

"Draft": when a GEP is currently in the writ=
ing and is in discussion but hasn't yet reached a state ready for inclusion=
in Groovy

=20

"Accepted": when the draft GEP, as is, is in=
a state which doesn't mandate any additional modification, is ready to be =
integrated into Groovy and has been accepted by the development team, follo=
wing the usual Codehaus Manifesto principles

=
=20

"Rejected": when concensus emerges or a deve=
lopment team decision has been made that deems the proposal should not be i=
ntegrated into Groovy

=20

"Final": when the GEP has been integrated in=
to a released version of Groovy and has been properly documented in the Gro=
ovy wiki

list existing papers or documentations related to this feature that pro=
vides additonal material for understanding the concepts or implementation d=
ifficulties

=20

provide samples showing how the feature should be used and how idiomati=
c Groovy the solution is

=20

=20

The general wo=
rkflow

=20

The general workflow of a Groovy Enhancement Proposal is as follows:

=
=20

=20

The inception of a GEP generally stems from a discussion on the Groovy =
mailing-lists about a new feature or change when the Groovy Despot and the =
development team deem necessary to properly document and articulate this ne=
w idea, for further discussion and analysis. Generally, simple bug fixes an=
d minor enhancements don't require a full-blown GEP. A GEP is started solel=
y with the agreement of the Groovy Despot.

=20

A unique Number is assigned by the Groovy Despot and a=
meaningful "Title" is created for this GEP.

=20

A proposed Target Groovy version is proposed for the i=
nclusion of this GEP.

=20

A Leader for this effort (usually the instigator of th=
e GEP or the lead developer of it) takes care of the creation of the GEP, o=
f writing a detailed document proposing this enhancement, and eventually of=
providing a reference implementation as a branch or through a patch for th=
e targeted Groovy version.

=20

Once the development team and the "Leader" are happy with the=
status of the GEP, a decision should be made to act the integration of thi=
s GEP into Groovy and a JIRA issue for this task should be created. As per =
the Codehaus Manifesto rules, the Groovy Despot has the last say on the acc=
eptation of the GEP as a Final status GEP.

=20

The integration of the GEP in Groovy is Final once pro=
per documentation is added to the Groovy wiki and that the reference implem=
entation has reached maturity and provides a good test suite covering the f=
eature.

=20

If the GEP doesn't fulfill all the requirements of the GEP process, the=
GEP can be Rejected.