Work Week: Difference between revisions
(→Community Participation: community participation) |
(→Agenda) |
||
| Line 20: | Line 20: | ||
=== Agenda === | === 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. | |||
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 topic(s) scheduled on Wednesday where all or most of the group need to hash out a plan together, and 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. | |||
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. | |||
=== Minutes === | === Minutes === | ||
=== Report === | === Report === | ||
Revision as of 13:41, 20 January 2014
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. 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.
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.
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 topic(s) scheduled on Wednesday where all or most of the group need to hash out a plan together, and 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.
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.