The Mozilla India Open Book
The Mozilla India Open Book
Mozilla India
Buy on Leanpub 
Version   : 0.3.0

Published : 2016-09-12

Introduction

About

This book serves as the canonical document for the organizational structure adopted by the Mozilla India community.

It is collaboratively written by Mozillians. The Meta Team of Mozilla India serve as its editors and maintainers.

A bit of history

This book was put into place right after the Mozilla India Meetup at Pune in August, 2016, to help document the outcome of the efforts to restructure the Mozilla India.

Contribute

The source code of this book is hosted publicly on Github. You are welcome to put forward your suggestions, edits or additions to the book. If you are interested, take a look at the repository.

TL;DR

Here is a quick summary of the currently proposed organizational structure for the Mozilla India community. If you are interested in the full proposal, skip to the next chapter.

Proposal summary

Have open, transparent, accountable teams where individual contributors can work together with the highest amount of flexibility. Adopt a participatory process that does not add excess process overhead. Everyone is urged to take up the things they like and work together with others, and in the process, improve the structure itself.

Overall team composition consists of “Functional Teams” (with long term focus) and “Focus Teams” (possibly cross-functional, with short term focus on particular events/use cases). These teams are formed around functional contribution areas, with a degree of alignment with Mozilla’s key concerns.

The “Meta Team” glues things together and ensures smooth function and cross-team collaboration. The teams are supported by various infrastructure and communication channels.

Each team will have two “facilitators” who will act as the communication interface of the team with the outside world. They will take up accountability on behalf of their teams.

There are also “Geographic Groups” that consist of Mozillians in particular regions and help in discovering and connecting Mozillians by location.

Ownership is on everyone for the roles they take up. Leadership builds as a result of achieving expertise through constant practice and grows organically.

Self-evaluation, backed by data, is done at every point to understand effectiveness and impact of the community and its initiatives.

This is a constantly evolving, fluid and flexible structure. Nothing is set in stone.

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.
*    *    *
  • Arbitration process for any conflict should follow a reason and argument based process.
  • Arbitration process should only come into effect if the members of a team fail to resolve a conflict.
  • Arbitration process should ensure the vision and fundamental principles in order to achieve appropriate resolution.
  • At any step/team if the arbitration process fails to resolve, it is then immediately escalated to the overseeing team to take up.

FAQ