Work Week
Contents
What is it?
A Work Week is a meeting on specific topic where all participants want to define and coordinate on the specific topics. It becomes very useful to quickly coordinate and solve issues without delay and plan projects for the year to come. It has its own costs so for making the meeting fruitful, these are quick tips guidelines on how to prepare a work week meeting and making it effective for everyone.
How To
How long in advance?
The earlier, the better. There will be a lot of things to prepare from logistics to agenda, to notifications to different participants. Participants may also require visas for travel which can take some time. Make efforts to plan 8 weeks in advance, not less than 4 weeks.
Where?
Space Booking
Community Participation
The community is what makes Mozilla. People actively contributing to the projects and more specifically to the topics discussed at the work week should be part of the work week. You want to have all people who are contributing and advancing the project.
On the other hand, it might be difficult or impossible for some projects to pay for the travel and hosting (for volunteers for example).
Remote Participation
It might be important to plan for remote participation for some of the topics through teleconferences and/or IRC. So people who have not been able to travel for any reasons can contribute meaningfully to the discussions/works. Teleconferencing works better with small breakout sessions than big, noisy rooms. For larger talks, consider recording them so they can be shared with all contributors.
Agenda
Different models exist on how to plan agendas for Work Weeks, and it probably depends heavily on the type of group/team and the goals of the Work Week on what model works well for you.
Very different models might be needed for other groups like closely-knit developer teams or Work Weeks with the target of crunching down on open bugs. Please add to this wiki with examples that worked well for specific kind of groups and/or goals.
Examples
Stability
For the highly heterogenous and over-arching group that we have at Stability Work Weeks for example, the model we used in 2013 was very helpful:
- A highly structured agenda for Monday and Tuesday with 30-60 minute slots to discuss specific topics, pulling in people from different affected teams (in person when they are local to the meeting location, via Vidyo when they're not)
- one or two multi-hour topics scheduled on Wednesday where all or most of the group need to hash out a plan together
- Leaving the rest of the week to ad-hoc meetings (possibly coming out of the early-in-the-week discussions, e.g. planning on how to actually implement something that came up there as a solution) and collaborative work on code and bug triage.
Talkilla
This is a little like the Stability weeks, but possibly less structured.
The general intentions are to allow a large focus on pairing and working together, and not taking up too much time in meetings, but obviously having the face to face meetings that are needed that help move the project forward faster.
- Prior to the week: start thinking about goals for the week (using Agile, this can be difficult to get precise goals, but generally some topics can be set up).
- Structured Monday morning:
- "Getting there" - generally any admin stuff, overview of where we are on the project, roadmap discussions
- Confirm:
- Goals for the week - confirm what was said prior to the week, add any additional goals
- Initial list of ad-hoc discussions
- Monday afternoon
- Maybe some meetings, general hacking if possible.
- Majority of the week:
- Meet at an appropriate time.
- Quick Stand-up of previous day's activities
- Revisit the goals & ad-hoc discussions list
- plan some discussions for that day
- work out hacking and pairing
- The day then consists of meetings/discussions/hacking
- Final day:
- More of the same, but finishing with a wash-up before people start to leave
Minutes
Report
Writing a summary report along the minutes taken during the meeting is a very good tool for sharing and recording the memory of your activities. It enables further participation and understanding of the benefits of your activities. Do it quickly after the work week (usually no more than 2 weeks).
Put it in a space which is under the Mozilla URI space (mozilla.org) for example the wiki or a blog hosted at Mozilla. HTML or plain text is far better than using PDF, google doc or doc.
Send a notice to the mailing-list where you announced the work and the agenda.
