Engagement/Websites/Firefox/Webteam: Difference between revisions
Jump to navigation
Jump to search
m (Created page with "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 ...") |
mNo edit summary |
||
| Line 1: | Line 1: | ||
Mozilla.com/org Web Team | = Mozilla.com/org Web Team = | ||
This is a page to document web team projects and processes. | This is a page to document web team projects and processes. | ||
Release Cycles | ==== Release Cycles ==== | ||
Q2 Experiment: | 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. | *'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 | *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 | *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 | *Cancel Tuesday Triage. Keep Thursday status meeting | ||
*Use more tracking bugs | *Use more tracking bugs | ||
*Meet regarding how to track bugs in Bugzilla (QAWanted, process, etc.) | *Meet regarding how to track bugs in Bugzilla (QAWanted, process, etc.) | ||
*Alternate between devs: keep plane flying vs. working on infrastructure improvements | *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 milestones | |||
*Using a release cycle of some sort | *Using a release cycle of some sort | ||
Revision as of 23:18, 12 April 2011
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