Organization structure

Mozilla India Restructure Proposal

Vision for the community

Enable the community to uphold the Mozilla mission at any scale, while remaining relevant to individual contributors.

Fundamental principles to help achieve the vision

Maintain transparency of operations (ensures openness)
Invite participation explicitly (includes trust-first model)
Decentralize decision making
Maintain ubiquity of communications
Ensure accountability through clear metrics and documentation of actions and decisions.
Use flexible and adaptive structure which keeps on improving itself through constant feedback and evaluation.

Code of Conduct

The community code of conduct will adopt the very same Mozilla’s up-to-date CoC.

Organizational Structure

Basics

Any non-general role will be shared by 2 persons to ensure redundancy of human resources and contingency plan.
Each team in the following structure tree will have a role of facilitator (shared by 2 people)
- They work as the communication interface for the team with the outside world and the meta team
- They work as the arbitrators to help finalize team decisions (and save from it needing to bubble up to meta team)
- They ensure execution of the undertaken responsibilities of the team and publish activity reports publicly and to the overseeing body
- In any case either of the facilitators discontinues or becomes unavailable for the role, a second facilitator is chosen from the team within a preset timeout
- Any concern about the team’s health, deliverable, execution should be resolved by the facilitators, and to be flagged to the overseeing team if failed within preset timeout
- Any concern about peer teams’ health, operation, and execution should also be noted, reviewed and resolved OR flagged to the common overseeing team, as soon as observed
Each team can have their own preferred internal communication channels, but they would have to conform to the community preferred channels to document, broadcast and publish activity reports
Teams need to be formed with clear objectives.
While choosing team members, teams should look out for the best suited, capable and passionate individuals who are willing to pursue the objectives of the team.
Community’s operation process will follow a meritocratic processes instead of a democratic process.
Every part of the community should have well documented and discoverable waypoints/pathways
Self-checks at any level and at any given time is encouraged, and decided resolution is applied to evolve the community structure on the fly.
Every entity (individual or team) in the community starts with a preset level of trust
The level of trust allows for different level of responsibilities to be undertaken
The trust level can be gained or lost, based on the activities/track-records

Hierarchy

Meta Team

Core of the community identity
Experience based membership
Sets goals, allocates resources
Oversees community operations
Resolves conflicts and grievances
Is accountable to the community through a self-evaluation report at least once every 6 months.

Functional Teams

Persistent teams
Strategic objectives
Limited memberships
Responsible for functional growth
Overseen by Meta Team, peer reviewed by other functional teams

Focus Teams

Temporary teams
Tactical objectives
Scalable Memberships
Responsible for campaign deliverables
Overseen by participating functional teams

Geographic Groups

Persistent group
Core purpose is to enable functions that benefit from geographic coordination
Membership is by virtue of someone’s presence in that geographic area, and it will be seamless for any person to move to a new geographical group
Supported by Meta Team

Communications and PR

A set of centralized communication media will be necessary for the community’s internal discussions and external outreach. The goal of such a communication system is to encourage visibility of information while remaining relevant for focused group discussions.

Discourse for discussions
- Threaded, searchable, near-real-time
- Can be piped to our existing community-india mailing list.
- Sub-categories can help in grouping discussions
Telegram for real-time discussions
- Real-time discussions that do not need to be threaded.
Wiki for canonical resources
- collaboratively editable, references, non-real-time
- Can use wiki.mozilla.org/India
Blog.MozillaIndia
- PR, outreach, announcements
Social media
- PR and engagement - outreach, announcements

Infrastructure accesses required

DNS & Email Liaisons
Web server access
Discourse admins
Mailing list admins
Telegram admins
Blog admins
Wiki admins
Social network admins
Facebook groups and pages
Twitter access
YouTube admins
Instagram access
Bugzilla admins
Github organization access groups

Recognition

Individual activity metrics, funneled from various resources will be listed publicly and will serve as the primary medium of recognition.
This process will require gradual improvement to be more concise as more and more activity facets are discovered and added in.
Individual rewards will be for Mozilla to distribute; the local community will only ensure availability of the data for decision making.

Self-checks, grievances and arbitration

Self-checks can happen in any level, by anyone, by using data and activity log with references.
For any issue i.e. coming from the self-checks should be raised to the concerned bodies.
Failing to resolve any issue flagged at any level should be documented and escalated.

* * *

There will be different ways to put forward a grievance for resolution, by different order of anonymity.
Grievances (breaking of CoC, inter-personal discomfort, reporting peers/processes etc) has to be directly escalated to the meta team.
The lack of escalation steps is there to ensure homogeneous treatments for the issues raised, and not bottleneck at any steps or go unresolved.