Module proposal draft

["John (J5) Palmieri" <johnp redhat com>]

This should go along with the schedule once we have something we wish to
send to the gnome community so they can look it over and propose
changes.

To all module maintainers,

The GNOME Release Team, after some discussion has come up with a new
procedure for getting modules accepted into the next release of GNOME.
This new procedure is built on top of years of experience doing GNOME
releases and it is our hope that it will lead to less confusion and up
the quality of our already stellar releases.  In that vein this is more
of a tweak than an overhaul, taking into account lessons learned from
the past.

Procedure for proposing modules for inclusion:

All modules should be proposed BEFORE the 2.15.1 release.  Any existing
modules planning big changes should also announce this before the
release.  This allows everyone to have a good overview of the direction
we wish to head towards for 2.16.  It also puts potential modules on
notice and allows us to track their progress throughout the release
process making it easier to decide which modules are ready to be
accepted into the next release.

Module integration:

All modules and changes proposed for 2.16 should be integrated early in
the release process (added to jhbuld/GARNOME, etc.) - preferably by
2.15.1 or 2.15.2.  This allows for testing early and allows us to better
see where we are heading.  Don't propose a module and rely on other
developers to integrate it.

Module progress:

Modules should show a steady progress throughout the release cycle.
Module owners should show they can hit release deadlines and towards the
end concentrate on stabilization over feature addition.  One of the
stipulations of becoming part of the GNOME release cycle is to be able
to maintain regular releases in sync with the rest of the desktop.
Doing so before the module is part of GNOME gives the release team
confidence that it should be included.

Module rejection:

If a module has not proved itself by the 2.15.4 release we will take the
most conservative choice and drop or revert it in the release.  This is
to avoid yay/nay votes from happening late in the cycle.  It is our hope
that by this point it will be clear which module will make the cut. 

-- 
John (J5) Palmieri <johnp redhat com>