Excellent minutes, thanks for doing this!
On Thu, Jul 31, 2014 at 10:58 AM, Allan Day <[email protected]> wrote: > 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). > _______________________________________________ > [email protected] > https://mail.gnome.org/mailman/listinfo/release-team > Release-team lurker? Do NOT participate in discussions. _______________________________________________ [email protected] https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
