Release change proposal
- From: Benjamin Tissoires <benjamin tissoires gmail com>
- To: board-list gnome org
- Cc: marketing-list gnome org, spider gnome org
- Subject: Release change proposal
- Date: Sat, 3 Aug 2013 11:22:08 +0200
Hi,
after the Q&A with the board of this morning session, I discussed with
Spider, and we thought that instead of having _one_ person in charge
of aggregating all the changes once the release is done, we could
spread this work among all of us.
So, here is the formal proposal we wrote:
Change proposal:
The basic idea is that we shouldn't overload maintainers, but we
should also not require a heroic effort by single person.
Effort needs to be spread out amongst many people, and the work
needs to be integrated in our normal release practices.
Just because you are maintainer, doesn't mean you must do it, you
only have to make sure someone does it. It could be required to be
documented as part of patch submitting or code review, the way tests,
documentation and other things are related to a feature.
* All module maintainers should ( in the release cycle ) be clear
about what features are added as new and removed.
This can involve rationale for the change ( Why did we remove
transparency from the terminal? ) but that is not a must. The
Marketing team can always ask the maintainers for details.
* The major changes should be documented between alpha and beta? (
but always before UI freeze ), thus giving us ~3 months before "proper
release" to do user interaction and communication on forums, slashdot
and other things.
* It is the Release Teams responsibility to ensure that all
modules _do_ these "feature changes", but it is the module owners
responsibility to _write_ them or make someone write it for them.
* Marketing team should follow these changes and work from them to
avoid major user hostility that may be caused by missing features.
* Marketing should work on this to inform users/ slowly drip
"changes" to public attention _before_ the code drops as "stable".
( Note that just because this is documented, the code doesn't need
to be removed at this time, but the _intention_ should be very clear.
)
It's free software, we do change our minds at times.
The bikeshed should be green.
Cheers,
Benjamin & Spider
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]