Proposal for restructuring of Mozilla India community

proposal-mozin-restructure_kaustav.txt

Proposal for restructuring of Mozilla India community
=====================================================

Author   : Kaustav Das Modak <[email protected]>
Date     : Jul 24, 2016
Location : Bangalore
Status   : Proposal
License  : CC0 1.0 [1]
Version  : 1.0.0


1. About The Document
---------------------

This document is a response to the open call for ideas issued by the
Mozilla India community seeking inputs in restructuring the community
structure and processes. It intends to propose an organizational
structure that can help the Mozilla India community attract and retain
contributors while keeping the process as light-weight, transparent,
open and accessible as possible and yet operating at scale.


2. Terminologies Used
---------------------

- Community member : An individual contributor to Mozilla.

- Responsibilities : The voluntary efforts a community member has
  agreed to undertake.

- Open : The attribute of a process which allows community members to
  participate in the decision phase of that process and take up
  responsibilities for transforming those decisions to action.

- Transparent : The attribute of a process which requires the
  responsible members to publish information about every decision and
  action related to that process and make those information available
  by default to all community members.

- Accessible : The attribute of a process which focuses on simplifying
  participation irrespective of community members' physical and mental
  abilities, without any discrimination based on their gender, age,
  origin, genetic and racial identity.

- Scale : The ability of a process to operate efficiently irrespective
  of the number of community members participating in it.


3. General Structural Guidelines
--------------------------------

While defining structural guidelines for Mozilla India, we have to
take into account a wide variety of linguistic and cultural
differences spread across a vast geographical area.

The goal of such a general structure is to help the community operate
cohesively, while maintaining high degree of flexibility and
individual freedom. It needs to be generic enough to be applied to any
function of the community, yet must be flexible enough to be adapted
to specific use cases. In short, it should be simple and scalable.


A. The community should be an enabler.

    The community should act as a matrix, where community members come
    together to meet and learn with fellow members who share similar
    ideologies and passions about the Mozilla mission. The focus of
    the community should be to build efficient tools and processes to
    allow such collaborations and exchanges.


B. The community should operate on a trust-first model.

    Our current community models operate on an exclusive trust-chain
    model. A new member has to gain trust by getting vouches or by
    taking up responsibilities and delivering them. Existing members
    validate the contribution of new members and induct them into the
    chain. If this chain was to be a scorecard, then every new member
    starts with zero and has to accumulate trust points to get deeper
    into the trust chain. While this works for small systems, such a
    process fails miserably for large scale implementations with the
    trust chain itself becoming a bottleneck for new members to get
    in.

    The alternate is to have a trust-first model. Instead of a new
    member having to prove themselves from Day 0, they always start
    off with a given level of trust. This will give them access to
    contribute to anything they want. A moderator can always moderate
    such actions, but does not necessarily have to. If the new member
    makes meaningful contributions, they get deeper into the trust
    chain. If they do not, they remain where they are. Only in extreme
    cases, like violations of code of conduct, will the member get
    their access stripped off.

    This can result in an initial chaos. But that system will settle
    itself. If the accesses provided are useful to the system, then
    there will be more good actors than bad actors. Consider Wikipedia
    for an example. Would it have scaled if everyone had to wait for 3
    vouches to make their first edit?


C. Any executive responsibility should have at least 2 members.

    Most community members are volunteers. They have other primary
    responsibilities outside the community - studies, work, family
    etc. Even though they are highly capable and committed to the
    Mozilla mission, volunteer community members may often have to
    choose their primary responsibilities over the responsibilities
    they have taken in the community. This leads to bottlenecks when
    an existing community member responsible for certain execution has
    to focus elsewhere.

    One way of mitigating this issue is to always at least have 2
    community members in charge of a role, bearing equal
    responsibilities. In the event where the one of the assignee is
    unavailable, the other person can help offload the task and find
    another person suitable and willing to take up the role.


D. Executive responsibilities should always have even number members.

    Voting does not solve an issue as nicely as an informed and
    well-formed argument does. This becomes a serious issue when an
    important decision needs to be taken. One way to avoid lobbying
    (intentional or unintentional) is to remove effectiveness of
    voting to come to a consensus.

    Such a setup can be implemented by ensuring every decision making
    or executive role always has even number of members.


E. Decentralize everything, except primary communication medium

    Assigning responsibilities, selection procedures, recognition
    modes, operations and onboarding should be as decentralized as
    possible. There should be no central authority controlling who
    gets to participate and who doesn't. Participation should be open
    to anyone who has the attitude and enthusiasm to contribute. In
    cases where specific skill-sets are required, there should be
    provisions for new members to pair with existing members and learn
    along the way. At no point, should there be one decision maker.

    That being said, a primary communication channel should be the
    only thing operated in a centralized manner. This will be the
    medium for publishing updates, asking for contributions or
    reaching out to the public. This is necessary to avoid
    fragmentation of important communication. It can be called an
    "official channel", if neeeded.

    If multiple official communication channels are needed, they
    should be added only if one primary channel cannot handle all the
    data types required for efficient communication. In such a case,
    the first option should be to try and find a communication
    platform that supports all the required data types. If nothing
    such is found, only then the fallback should be to introduce a
    second official channel.


4. Communications
-----------------

One of the major challenges of the Mozilla India community is to
ensure proper flow of information among regional
sub-communities. Having organically grown from the beginning, groups
of contributors use communication platforms that they are comfortable
with. While anyone should have the choice of choosing whatever
communications platform they want for their work, the lack of
well-adopted primary communication channel prevents regional
sub-communities from effectively communicating with each other.


A. Current scenario

    The current list of communication channels for entire Mozilla
    India include:

    - community-india mailing list [2]
    - Mozilla India Telegram group [3]
    - #india on Mozilla IRC
    - Mozilla India group on Facebook [4]
    - @MozillaIN on Twitter [5]
    - "Communities/India" sub-category in Mozilla Discourse [6]

    At present, the community-india mailing list is not very active
    and Discourse sub-category is rarely used. The Mozilla India
    Telegram group sees daily activities, often with interesting
    conversations. The #india IRC channel has seen gradually reducing
    traffic over the last 2 years.

    Adoption of the mailing list seems to have gone down while the
    usage of the Telegram group has steadily risen, owing to its
    real-time and interactive nature. But, Telegram is a closed
    communication platform. It may be very useful for a quick chat
    with everyone, but it cannot be archived (unless using a bot) and
    threads tend to get lost very quickly. Add to that, each
    sub-community have their own Telegram groups, so people end up
    cross-posting everywhere, hoping to reach a wider audience.

    The social media groups are useful for sending out information,
    but are not that useful for engaging members in conversation,
    compared to Discourse or Telegram.

    Discourse has all the features apart from the real-time nature of
    conversation. It has archival, threading, mentions, upvotes,
    rich-media support and thread-linking. However, it is overly
    underused.


B. Proposed solution: Discussions

    - Given the conversation features that Discourse has, adopt the
      Mozilla Discourse sub-category as primary communication channel.

    - Bridge the mailing list to Discourse so that emails sent there
      open a thread in the Discourse forum, and replies to thread via
      those emails are posted as replies to the Discourse thread. That
      is, do not leave those behind those who still prefer using an
      email client.

    - Keep a bot in the Mozilla India Telegram group which will post
      about new Discourse threads in the group. That way, those
      following Telegram mainly will not lose out on interesting
      conversations.

    - Bridge Mozilla India Telegram group to an IRC channel for those
      on IRC to follow.

    - Encourage long conversations in Telegram or IRC to move to
      Discourse.

    - If these features are not possible to integrate in the main
      Mozilla Discourse, deploying a Mozilla India specific discourse
      should be considered as only as a backup option, owing to the
      infrastructural overhead its maintenance will add. Though, a
      dedicated discourse instance will allow better control to tweak
      it to the needs of the Mozilla India community, it will come at
      the cost of fragmenting information from the larger Mozilla
      context.


C. Proposed solution: PR and Marketing

    - Post announcements on Discourse with a specific tag or in a
      specific category.

    - Mirror Mozilla India announcements (events, surveys,
      invitations) across social media channels with link to the
      announcement on Discourse.


D. Proposed solution: Blogs

    As Mozilla India blogs are public facing assets, they need a light-weight review system.

    - Allow anyone with a valid Mozillians ID to apply for an account
      on the Mozilla India blog.

    - Moderators can do regular passes to approve valid accounts.

    - Each newly valid accounts can draft posts, but cannot
      publish. Moderators can assign editors and publish those posts
      after a review cycle.


E. Proposed solution: Inter-sub-community information exchanges

    With a setup like the one mentioned above, regional
    sub-communities can publish their achievements and issues on the
    Discourse. They can do either of these:

    - Publish a quarterly update of what happened in the last 3 months
      in their region and an optional rough sketch of what they plan
      to do in the next 3 months.

    - Create region specific posts on Discourse with appropriate
      tags. So, even if someone from another region does not get
      directly involved, they will be aware of what's going on in
      another region. Chances are, if they find it interesting, they
      may clone or fork that idea for their region.


5. Team Structures
------------------

This section can be considered as a delta added to the existing Task
Force model to make it scale. It draws from the principles mentioned
in Section 3: "General Structural Guidelines" above.


A. Information

    - Each team will have a functional objective. This can be
      technical, advocacy, logistics, documentation etc.

    - Each team will have a set of skill requirements so that team
      members and interested community members can have a clear idea
      of the skills to contribute to that team.

B. Facilitation

    - Each team will have an even number of facilitators, minimum 2.

    - Facilitators will be primarily responsible to help the rest of
      the team members and communicate updates to the rest of the
      community.

    - Facilitators will also act as arbitrars for cases where a
      mediation is required within the team.

    - A facilitator should be well-versed in the requirements of the
      team so that they can make informed decisions.


C. Team members, operation and onboarding

    - Team members can share tasks depending on the nature of the
      team.

    - A facilitator can lay down their responsibilities if they have
      other commitments. In that case, someone from the team can step
      in as a facilitator, provided they are willing to share the
      responsibility.

    - Ownership of a team is _not_ limited to the
      facilitators. Ownership is shared across the team.

    - Getting into a team is as straightforward as acquiring required
      skills and trying to solve a few issues. There are no other
      onboarding guidelines.


6. Community Operations
-----------------------

For the community to be a successful enabler, there has be a set of
people helping others achieve their goals. This calls for a dedicated
operations team in the community, who will try to manage the logistics
and resources so that other teams and individuals can make the most
out of their contribution to the community.

This team is essentially the Event Task Force rebooted to the format
of the team structure mentioned above. Some of its core
responsibilities will include (but not limited to):

- Handling logistics of national level events.

- Having team members across regions who can help with operations in
  their respective regions.

- Handling budgets for events.

- Ensuring other teams have access to the resources they need. This
  will include interfacing with teams in Mozilla, if required.


> Note: This document talks about only one team (the Ops team) in
  specific. The rest of the teams can be built according to functional
  demands and interests of the community members.


7. Recognition
---------------

Recognition is not just about quantifiable metrics, as in, who has the
highest number of commits or who has the highest number of bugs
filed. While that may make sense for certain teams, it does not
necessarily do justice to those contributors who find whatever time
they can to contribute to the Mozilla mission. Recognition is about
thanking anyone and everyone for their efforts, without which the
Mozilla mission would not have been nearly as successful in its reach
as it is today.

There can be multiple possible options for recognizing contributors,
including (but not limited to):

- A central dashboard that accumulates metrics across systems and
  presents a coherent list of contributions.

- A "community spotlight" which interviews individual members each
  month.

- A "This month in X" or "This quarter in X" update that also lists
  the names of people who contributed during that period. A good
  example is the "This week in Rust" newsletter.

- Updated listing pages for each team reflecting active members.

- Felicitating outstanding contributions at local and national events.


8. Grievance Addressal
----------------------

Grievances when not sorted can be the cause of rot in the morale of a
community. There needs to be active measures taken to help community
members air their grievances. But, unless these grievances are taken
seriously, they are of no real value. There are also issues about
whether a grievance can trigger unconsciously biased reactions in
those in charge of solves those grievances.

We need a sort-of Bugzilla-for-humans, with optional anonymity. Any
such system needs to have a code of conduct to guide posting of
grievances so that it does not get derailed by pointing fingers at
individuals.

Grievance redressal systems can be made of multiple layers:

- Build a diverse team to address sensitive grievances.

- Use Discourse with anonymous posting mode.

    - Have a category in Discourse which will allow members to post
      anonymously.

    - These posts will be visible to everyone else and other members
      can comment and initiate a discussion.

- Use an anonymous form.

    - This will help in addressing personal and sensitive grievances,
      including harassment and other offences.

    - This data will not be open to comments. It will be addressed
      privately by the grievance addressal team.


9. Self-checks
---------------

One of the most important traits of a scalable system is being able to
identify its own flaws and rectify them. This is important to be
implemented as a process in the community to ensure low-effort
scalability.

Here are a few checks that the community needs to perform on a
periodic basis:

- Identify teams with less than average activity. Dig deeper and
  identify the issues, if any, keeping in mind that the level of
  activity will vary between teams.

- Identify unresolved grievances. Try to identify patterns across
  grievances. Dig deeper and identify the root cause of those
  grievances.

- Identify lack of activity among veteran contributors. Dig deeper and
  try to figure out why they may have lost interest.

- Conduct anonymous surveys to identify any hurdles that new community
  members may be facing. Try to identify patterns and resolve them.

- Another important trait of a scalable system is continuity. A system
  cannot scale unless the processes it has put into place are executed
  regularly. There needs to be checks on whether any process is
  harming the evolution of the system. If any such process is found,
  it needs to be adapted as early as possible.

- Ideally, do all of these once a quarter.


---

[1]: https://creativecommons.org/publicdomain/zero/1.0/
[2]: https://lists.mozilla.org/listinfo/community-india
[3]: https://telegram.me/MozillaIN
[4]: https://www.facebook.com/groups/MozillaIndia
[5]: https://twitter.com/MozillaIN
[6]: https://discourse.mozilla-community.org/c/communities/india