The Council is the program’s 9-member governing body composed of 2 permanently appointed Staff members and 7 elected volunteers who are serving 12-month terms. The Council exists to ensure that the Mozilla Reps program runs smoothly, oversees the governance and finances of the program and serves as an advisory body within the Mozilla organization. The Reps Council takes strategic decisions regarding the program with input by the rest of the leadership body.
- Provide a governance and support structure to assist Mozilla Reps worldwide
- Oversee global Rep activities
- Oversee global budget /swag management for events
- Represent Mozilla Reps interests within the Mozilla organization
- Resolve disputes
- Provide guidance for Mozilla Reps
Election/Designation of Council Members
The 7 volunteers sitting on the council are elected by existing Mozilla Reps for 12-month terms depending on their previous term (if any) as a Council member.
Eligibility and criteria based on Council experience in 2016-2017 terms are:
- Take initiative on leading projects inside Reps
- Be critical to help shape the volunteer strategy
- Have a clear understand Mozilla’s current direction and goals
- Have strategic thinking
- Be able to communicate Reps mission and vision to the rest of the org and volunteers
- Understand and be able to communicate Reps as the leading mobilizers program
- Be able to articulate his/her opinion in strategic meetings
- Be available to meet with the rest of the org on weekly basis
- Have a strong background around the open web (and free software) movement
- Expertise on the ground with local communities and grassroots efforts
- Be recognized as a supportive leader inside the Mozilla community
- Have existing relationships across the organization with both volunteers and employees
Initial full post about the new skill sets and commitment needed.
For more information on the Mozilla Reps election process, click here.
You can find out the history of the council and more info here.
You can find the list of the current Council members here. To contact the Council, please send an email to email@example.com.
|Current Council Chair||Mail @||Office hours|
|Manel Rhaiemfirstname.lastname@example.org||18:00pm UTC to 19:00pm UTC daily|
Previous Council Chairs can be found in the Council chair persons archive.
On November 1st, 2012, the Mozilla Reps Council began designating a chairperson to help make the council work more efficiently and effectively. The "Council Chair" is designated a rotating 2-month basis and has the following responsibilities:
- Chair council meetings
- Send meeting reminders to the council until one day before the meeting with the agenda link
- Scan reps list for news/issues and add it to the meeting agenda (if needed)
- Create meeting agenda and gather agenda items from all members
- Follow-up on action items with designated owners
- Make sure that all tasks are tracked in the Reps repository on Github
- Be the spokesperson at the organizational level (eg. team meetings, offsites, town hall meetings, mailing lists)
- Respond to people that reach out to the Council
- Keep overall program goals and objectives in check and ensure that everything is on track
- Create council meetings notes on Discourse until Thursday before the Reps Call
- Make a formal onboarding meeting with next council chair
The Council chair can be reached at email@example.com
- Konstantina/Nuke will assign the current chair person to the above alias
Tasks and Responsibilities of Council Members
Members of the Council have specific tasks to complete and responsibilities to agree to once they join the Council, including:
- Participate in the Open Innovation monthly meetings (monthly)
- Shape and give feedback on the Community Development OKRs (Objectives and Key Results) (every half year)
- Participate on the Reps weekly Call (weekly)
- Interview Mozilla Corporation and Mozilla Foundation board members (once or twice per year)
- Shape Reps program half-yearly and yearly - via the Reps OKRs (in the beginning of each half year)
- Implement OKRs depending on strategy
- Lead the monthly Newsletter Team (monthly)
- Overseeing the Onboarding Team (monthly)
- Overseeing the Review Team (monthly)
- Shape the coaching program (monthly)
- Introduce new Reps to the program (quarterly)
- Give feedback and overview the Activate campaign strategy (monthly)
- Decide on the Reps program budget allocation (half-yearly)
- Lead community feedback and connect it with Mozilla leadership
- Lead the re-commitment process (quarterly)
- Participate in the Council weekly Call (weekly)
- Be in contact and reply within 72h (exceptions when absence is announced) to Council threads
Council Leave of Absence
If a Council member must step away from the program and cannot fulfill his/her duties (eg. vacation), then the Council member must do the following:
- Notify the Council at least 1 month before of their anticipated absence
- Find another Council member who agrees to cover for them while they're absent, including participation at meetings
NB: if a Council member realises that they must be absent from the program for more than 1 month, then the Council must be notified as soon as possible in order to find a permanent replacement.
Dropping out of Council
Any Council member can resign from their Council seat whenever they deem necessary. Reasons are not communicated by default, the Council member is allowed to communicate these if they want to. Additionally the Module Owner and Reps Peers oversee Council members according to the criteria mentioned above and make sure Council is operational. If the Reps Peers see that someone on Council might need help, they reach out and ask how we could help to have more impact. In rare cases the Module Owner may remove Council members from their seat if no other approach has lead to improvement.
In both cases the Council member stepping out will be replaced by a new Council member. The new Council member will fulfill the full rest of the term. Example: Council member steps out of Council for personal reasons after 4 months being on Council. The replacing Council member will stay in Council for the rest of the term - 8 months.
Peers holding Council accountable
The Reps Peers are responsible to hold Council accountable to their tasks.
- Every Council member should participate (not only reading) in discussions happening on Discourse and the Council alias
- Every Council member should regularly participate in meetings - there are exceptions of course as Council members usually are very distributed and have day jobs. If somebody is not able to attend feedback and updates should be left in the meeting notes before the meeting and the full meeting notes should be read after the missed meeting to get up to date again.
- Every Council member should work on their assigned OKRs and give regular status updates
- Every Council member should give feedback for other working documents and discussions
- Reps Council should actively engage in Open Innovation discussions and be up-to-date on recent developments by following the Monthly Open Innovation Calls (either live or recorded, or by consulting the slides and looking up important information in the recording if something is not clear)
- Every Council member should write small reports on the Reps Portal when they do activities for the Reps * Program (such as writing a document). This does not need to be granular (“Finished document A so it’s ready for Council review” instead of “I wrote one sentence in document A”). This is additional to the regular updates in the GitHub issue as long as we don’t take GitHub activity into account for Portal reports/activity.
- Every current/future Council member should agree to use Github for sharing updates and activities
- Every Council member should give a small update after every half year summarizing their work (mostly OKR related)
- Every Council member should create issues to document their work in the Reps GitHub repository and keep them up to date
- Decisions should be recorded in the voting tool by creating votings as this better facilitates async voting. Votings in person can be conducted without voting if enough votes can be gathered.
- Finished working documents should lead to a post on Discourse to update Reps
- Where applicable, feedback should be gathered before starting a working document to gather Reps feedback and to inform them about what the Council member is gonna work on
- OKRs should not be published later than 3 weeks into the half-year
Asking for Peers feedback
- Council should ask Peers actively for feedback - Peers can however give feedback without a specific ask - feedback doesn’t need to be on a working document, this can also be in the middle of a discussion in Discourse. The Council members ask Peers for feedback for strategic parts of their working documents once Council reviews those as well. Feedback can of course be asked already before that if valuable (e.g. “what do you think of this direction?”). Council members can also give feedback to Peers whenever they see fit.
- Council should make Peers aware of any conflicts or escalations as soon as they are aware of it
- Council can define a “bridge person” (does not by default mean the current council chair) that interacts with Peers on a regular basis if Council decides to do so
Workflow / Prioritization
- Council Updates in the Reps Weekly Call should be distributed among the Council members so it’s not always the same person doing the update. This should be decided async by the Council before the call. The Peers advice this to be done as an action item during prior Council call.
- OKRs and responsibilities should be equally distributed by taking into consideration bandwidth and availability of the council members.
- OKRs should have high priority, other business (except conflict resolution and top priority incidents) should be planned for the future (next half-year OKRs for example)
- Council members should work together on the OKRs, provide timely feedback to not block each other
- Council member should fill out the timeline for the OKRs they are responsible for to identify possible resource problems (vacations, day job, …). OKRs with identified shortcomings in resourcing should have at least one other Council member supporting.
Interaction of Peers and Council
- Peers give context of previous discussions/incidents in day-to-day discussions where needed
- Peers give feedback where they think it’s valuable without being asked
- Peers help with the OKR process by reviewing and giving feedback to OKRs early in the process
- Peers help with the Reps program vision by providing reviews and feedback to longer-term plans
- Peers are heavily involved in strategic discussions around the Reps Program and are always part of strategic discussions
Contact the Council
In case you want to contact the council for questions/inquiries or suggestions you should use one of the following channels:
- firstname.lastname@example.org email alias
To make sure that this is in compliance with our voting, the first person to be asked to step in will be the one Rep voted most, but not making the cut in the previous elections. If 4 spots were open, we will ask the 5th in the voting ranking to take on this new responsibility. If this person does not want to step up, it’s up to the Module Owner to decide on a replacement for the rest of the term. If the remaining time of the resigning Rep’s term is less than 3 months, the Module Owner can decide to nominate another Rep who has been on Council before to decrease the onboarding overhead.