ReMo/SOPs/Proposals

From MozillaWiki
< ReMo‎ | SOPs
Jump to: navigation, search

Remo logo vertical.png Main | Join | Procedures (SOPs) | Leadership (Resources) | Meetings | Website | FAQ


This document describes the process to submit and approve a change to Mozilla Reps program structure and processes.

Initial proposal

Any Rep can create and submit a proposal via any mentor.

It’s not mandatory but encouraged to first present the proposal idea on Reps discourse to gather feedback and comments from other Reps before jumping into next steps. This will help to have a more solid proposal.

A proposal should have a mentor who will basically 'own' the process of getting proper feedback, leading the process, and corresponding with Council.

Each proposal should have the following template:

  • Title: Short title
  • Description: Description about what changes are proposed.
  • Impact Area: What part of the program is this affecting?
  • Owner: Mentor vouching the proposal.
  • Backer(s): Name of another mentor(s) backing the proposal (this can be defined during the mentor review phase)
  • Type: New Proposal or Update of existing
  • Priority: Honest assessment of how important this proposal is to the health and progress of the program. P1 is reserved for items relating to security, privacy and safety. P2 items that directly related to work in progress, or just completed. P3 are proposals unrelated to existing goals.

The proposal should be stored in an online editable format: Etherpad, shared GDoc…

Mentor review

The proposal should be “backed” by at least another mentor of the program. The mentor owning the proposal will share it with the reps-mentors list for feedback. The ‘backing mentor(s)’ will also need to include a short description of why they support the proposal.

For a minimum discussion-period of one week, the proposal will be reviewed through discussion on the mentors distribution list, and may be amended as a result of feedback.

Council review and final draft

Once mentors feel the proposal is solid, the mentor owning the proposal will send it to Council.

Council will review and amend a final draft as soon as possible depending on the priority, they will discuss them during Council meetings and list them on a public proposals queue.

Once the Council feels the proposal is solid, a voting will take place in the portal to approve or deny it.

Additional feedback

If approved, it will be shared with mentors again for feedback and communicated to Reps if there is no concerns.

If not approved, the Council will inform mentors about the reasons and possible improvements.