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). _______________________________________________ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.