Thunderbird/Proposal: New Release and Governance Model: Difference between revisions

← Older edit

Thunderbird/Proposal: New Release and Governance Model (view source)

Revision as of 10:22, 7 March 2013

3,183 bytes added , 7 March 2013

no edit summary

Standard8

canmove, Confirmed users, Bureaucrats and Sysops emeriti

3,627

edits

@@ Line 1: / Line 1: @@
+{{Warning|This is an out-of-date document stored for historical purposes as it contains links to discussions that where previously held. The full and complete document is available [[Thunderbird/New_Release_and_Governance_Model|here]]}}
 Mozilla is focusing a lot of its efforts towards important web and mobile projects, while Thunderbird remains a pure desktop only email client. We have come to the conclusion that continued innovation on Thunderbird is not a priority for Mozilla and that the most critical needs for the product are on-going security and stability. In fact, it is quite possible that Thunderbird is already pretty much what its users want and there is not a high demand for innovation in this field.
@@ Line 15: / Line 17: @@
 === Governance model ===
-Thunderbird will be driven by a lightweight structure, focusing on producing security updates and suited to welcome community contributed innovations:
+Thunderbird is driven by a lightweight structure, focusing on producing security updates and suited to welcome community contributed innovations:
 * Thunderbird modules owners (https://wiki.mozilla.org/Modules) will remain in charge of their module and will allow community contributions innovation on their own merits. Module ownership is open to any contributor and can evolve over time.
-* A Release Drivers team will produce the Thunderbird updates every six weeks and work with module owners on the planning and integration of the community contributed innovations.<br/><br/>
+* A Release Drivers team will produce the Thunderbird updates every six weeks and will work with module owners on the planning and integration of the community contributed innovations.<br/><br/>
-* Mozilla will continue to provide paid staff, logistics and infrastructure for the release drivers team to produce updates and new releases with the same level of quality than today. Support will continue to be provided by the Thunderbird community and Mozilla will continue to provide the required infrastructure.<br/>
+* Mozilla will continue to provide paid staff, logistics and infrastructure for the release drivers team to produce updates and new releases with the same level of quality than before. Support will continue to be provided by the Thunderbird community and Mozilla will continue to provide the required infrastructure.<br/>
 === Timeline and getting involved ===
@@ Line 37: / Line 39: @@
 Each section below addresses one aspect of maintaining and building Thunderbird. They reflect the discussions that have taken place with volunteers and Mozilla employees during the summer of 2012.
-== AMO ==
-* Add-on Review mechanisms to continue working as they are with the AMO editor team
-* Compatibility bumps still need to be done per release ([[Thunderbird/Release_Driving/Rapid_Release_Activities/Compatibility_Bump|partial documentation complete]])
-Link to etherpad: https://etherpad.mozilla.org/tb-amo
 == Governance ==
@@ Line 67: / Line 62: @@
 * Support: Roland Tanglao
 * Release Engineering: John Hopkins
+* Business Development & Legal: Jean-Baptiste Piacentino
 Infrastructure to build and support Thunderbird will remain untouched (Release Engineering, Web Services and Support services).
@@ Line 77: / Line 73: @@
 * Mainstream and ESR releases will not be merged to allow for the intermediate release.
 * We will examine the possibilities for relaxing the rules for stability and security fixes on the ESR branch to allow a greater range of fixes to be landed.
-* Daily, Earlybird and Beta channels will continue to be developed as they are currently, providing the platforms for helping ensure stability for the next feature release, and for Localizers to translate the required strings.
+* Daily, Earlybird and Beta channels will continue to be developed
+** this will continue to provide the platforms for helping ensure stability for the next feature release and
+** for Localizers to translate the required strings
+* Releases on the beta channel will be reduced to one per gecko cycle
+** An additional release may happen if a severe (stability/security) issue affecting beta users is found
+** Additional releases will happen in the two cycles in the run-up to the next feature release to help to ensure stability
-* Need diagram here
+* '''ToDo''': Need diagram here
 Although the intermediate release is not desired at the current time, for an intermediate release to happen, the following would be required:
@@ Line 92: / Line 93: @@
 == Localization ==
+* In-product l10n:
+** Due to the release pattern, localizers can continue to work as the have been with the rapid release
+** If an intermediate release is held, we would need to work out how to back-port sign-offs and changes to an intermediate release branch
+** Currently there are no plans to allow localizers to do updates on the ESR branch, but this is open to feedback and may change
+* Website L10n:
+** This should remain the same process as it is now, unless mozilla.org policies change
+* '''ToDo''':
+** We need to complete the documentation for management of L10n (product & website)
 Link to etherpad: https://etherpad.mozilla.org/tb-localization
-== Quality Assurance ==
+== AMO ==
-Link to etherpad: https://etherpad.mozilla.org/tb-qa
-== Roadmap ==
+* Add-on Review mechanisms to continue working as they are with the AMO editor team
-Link to etherpad: https://etherpad.mozilla.org/tb-roadmap
+* Compatibility bumps still need to be done per release ([[Thunderbird/Release_Driving/Rapid_Release_Activities/Compatibility_Bump|partial documentation complete]])
-=== Papercuts ===
+Link to etherpad: https://etherpad.mozilla.org/tb-amo
-Papercuts are those issues which aren't complicated to fix but cause a fairly persistent annoyance in operation. As a means for driving forward Tb's development we want a significant number of developers to commit to fixing five papercuts in a single year.
-The Wiki is [[Thunderbird/Papercuts|here]].
+== Quality Assurance ==
-Link to etherpad: https://etherpad.mozilla.org/tb-papercuts
+* Ludovic will continue to lead and head up QA
+* This is already a community-involved process
+* Todo: Document how bugs get from triage to developers
-=== Lightning ===
+Link to etherpad: https://etherpad.mozilla.org/tb-qa
-Link to etherpad: https://etherpad.mozilla.org/tb-lightning
 == Services & Web Sites ==
@@ Line 121: / Line 131: @@
 == Support ==
+* Support sites are already largely community supported and driven
+* support.mozillamessaging.com will continue until SUMO integrates Thunderbird KB in to the support.mozilla.org KB (currently scheduled for late Q4 as part of multi-platform work for Firefox OS and Firefox Mobile to be confirmed in early to mid Q4)
+* get satisfaction continues as Thunderbird support forum until SUMO integrates Thunderbird forums into the support.mozilla.org forums (currently scheduled in Q1 as part of multi-platform work for Firefox Mobile, to be confirmed in mid to late Q4)
+* Add-on support is status-quo - there's not much we can do in the KB. In Get Satisfaction it is suggested the use of an add-on specific tag e.g. 'conversations' for Thunderbird Conversations add-on, 'lightning' for Lightning, etc. - this really to me is an AMO issue but happy to use tags on GS until AMO has a better support experience for add-ons
+* Roland continues to lead support
+** Will still produce support reports 48 hours after release and the Monday after a release
 Link to etherpad: https://etherpad.mozilla.org/tb-support
 == Docs ==
+* Documentation will continue to be on support.mozillamessaging.com, or support.mozilla.org as mentioned in the support section
+* Documentation has good community involvement already, contact via the support mailing list
+* Need to ensure that the necessary documentation for releases is co-ordinated with release drivers
+* TBD: who is responsible for approving KB contributions?
 Link to etherpad: https://etherpad.mozilla.org/tb-docs
 == Engagement ==
+* Engagement will be taken care of by a contributor. A Mozilla Reps is identified
+* it will cover the maintenance of current Facebook and Twitter accounts, opening new channels if needed
+* being a virtual module owner
+* managing eventual contributors event logistics
+* updating Start Page editorial calendar twice a year
+* liaising with MozGear for swags allocation to Friend of the Tree
+* keeping the Mozilla brand usage in line within Mozilla guidelines
 Link to Etherpad: https://etherpad.mozilla.org/QNUuZdC0pU
+== Lightning ==
+* Lightning will suffer from less manpower, specifically with Build Config and UI Design
+* Lightning's pace of development won't be significantly affected by this change
+* There may be a benefit during upgrades, as fewer binary-compatibility issues will arise.
+* Daily/Earlybird builds have to be monitored more closely, as they are the only notice for major platform changes that might affect Lightning.
+Link to etherpad: https://etherpad.mozilla.org/tb-lightning