|
|
| (22 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| = Mozilla.com/org Web Team =
| |
|
| |
|
| This is a page to document web team projects and processes.
| |
|
| |
| ==== Release Cycles ====
| |
|
| |
| In Q1 we tried a bi-monthly release cycle to varying success. After meeting during our Q2 onsite we decided to experiment with a weekly release cycle in order to release changes faster instead of waiting 2 weeks for the next cycle. We also decided to change our process in a couple of other ways listed here.
| |
|
| |
| '''Q2 Experiment:'''
| |
|
| |
| *'Slush' (our keyword for code freeze) each Monday. Push content each Tuesday.
| |
| *Set expectations with stakeholders that content will be live by X instead of live on x
| |
| *Document pushes on a public calendar (https://wiki.mozilla.org/Webdev:Releases) include start/end dates and link to bug query
| |
| *Cancel Tuesday Triage. Keep Thursday status meeting
| |
| *Use more tracking bugs
| |
| *Meet regarding how to track bugs in Bugzilla (QAWanted, process, etc.)
| |
| *Alternate between devs: keep plane flying vs. working on infrastructure improvements
| |
|
| |
| ''All in all - do double the releases with half the meetings. ''
| |
|
| |
| '''Continue:'''
| |
|
| |
| *Using milestones
| |
| *Using a release cycle of some sort
| |