|
|
| (23 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
| |
|
| |
| Do double the releases with half the meetings.
| |
|
| |
| Continue:
| |
| *Using milestones
| |
| *Using a release cycle of some sort
| |