New release processes

[Allan Day <aday gnome org>]

Hi all,

Here's my attempt to summarise the processes that we discussed in
yesterday's meeting. I've had to fill in some gaps and make some
guesses. It's very much a draft.

One issue that we didn't agree on during the BoF - I've moved the
governance (ie. when the Release Team has a formalised opportunity to
say no) part of the process from feature proposes to moduleset
changes. This is mainly because I don't feel that the Release Team is
in a position to require a feature proposal in order for that feature
to land.

Looking forward to hearing your thoughts on this.

Allan

---

Planning process

 * Major/interesting changes that are planned by modules are listed on
the wiki for each release, in the same way as with the current feature
process.
 * Plans can include any initiative, whether it affects user
experience or is purely technical in nature. Plans do not have to be
specific to the current release cycle - they are a statement of intent
and desire, rather than a concrete commitment to deliver a feature
within a specific time period.
 * Maintainers are encouraged to add their plans at the beginning of
each cycle (within a 2 week planning phase). The Release Team sends
reminders to d-d-l for this.
 * The Release Team works with maintainers of priority modules during
this period, in order to ensure that their plans are documented. It
can also add any plans that it knows about on behalf of maintainers.
 * Plans do not need to be approved by the Release Team, and there is
no acceptance period. However, the Release Team can intervene if
advertised plans are problematic or controversial.
 * At the end of the planning phase, the Release Team reviews the
plans that have been added to the wiki. At this point, the Release
Team can intervene if necessary. The Release Team then sends a mail to
d-d-l which summarises plans for the coming cycle.
 * Plans can be added to the wiki after the planning phase, at any
point during the release cycle. When this happens, it is the
responsibility of the plan proposer to notify d-d-l by email.

Roadmap process

 * During the planning phase, the Release Team prompts maintainers to
review their bugs and mark priority issues for the user experience.
This is done using the target-milestone field in Bugzilla.
 * At the end of the planning phase, the Release Team:
 - Reviews the list of target-milestone bugs and marks issues that are
important at a project-level. This is done with the gnome-target
Bugzilla field.
 - Add their own bugs to the gnome-target list. This is done with
input from the Design Team.
 - Discusses the list of gnome-target bugs with maintainers, to get a
sense of whether the maintainer can commit to fixing them during the
current cycle.
 - Publishes the list of gnome-target bugs on d-d-l, putting emphasis
on bugs which need help from outside the module.
 * At regular intervals during the release cycle:
 - New bugs can be proposed for the gnome-target. [How would this happen?]
 - The Release Team reviews the in-progress gnome-target list.
 - Sends an update to d-d-l.

Moduleset change process

 * Only the Release Team can change the JHBuild moduleset definitions.
 * If the Release Team updates a moduleset, they send a notification to d-d-l.
 * If a developer or maintainer wants to add/remove a dependency or
module, they must send a request to the Release Team (via d-d-l?)
 * New modules must adhere to documented standards (this would be an
updated version of the old module inclusion guidelines). This will
include adherence to the new version of the HIG.

Post-release meetings

 * One week after a release, the Release Team organises a debrief
meeting with representatives of the GNOME project teams (documentaton,
design, accessibility, QA, internationalisation, engagement).