Skip to content

Instantly share code, notes, and snippets.

@kaustavdm

kaustavdm/proposal-mozin-restructure_kaustav.txt

Last active July 30, 2016 03:55
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save kaustavdm/3de32e4df00a42c4908b681efec251fc to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save kaustavdm/3de32e4df00a42c4908b681efec251fc to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. Kaustav Das Modak revised this gist Jul 30, 2016. 1 changed file with 5 additions and 5 deletions.
    10 changes: 5 additions & 5 deletions proposal-mozin-restructure_kaustav.txt
    View file
    Original file line number Diff line number Diff line change
    @@ -449,11 +449,11 @@ periodic basis:
    - 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.
    - 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.

  2. Kaustav Das Modak revised this gist Jul 24, 2016. 1 changed file with 7 additions and 9 deletions.
    16 changes: 7 additions & 9 deletions proposal-mozin-restructure_kaustav.txt
    View file
    Original file line number Diff line number Diff line change
    @@ -4,9 +4,9 @@ Proposal for restructuring of Mozilla India community
    Author : Kaustav Das Modak <[email protected]>
    Date : Jul 24, 2016
    Location : Bangalore
    Status : Draft
    Status : Proposal
    License : CC0 1.0 [1]
    Version : 1.0.0-rc1
    Version : 1.0.0


    1. About The Document
    @@ -69,7 +69,7 @@ A. The community should be an enabler.
    allow such collaborations and exchanges.


    B. The community should operate on a trust-first model
    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
    @@ -217,9 +217,9 @@ B. Proposed solution: Discussions
    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
    information of new Discourse threads in the group. That way,
    those following Telegram mainly will not lose out on interesting
    - 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
    @@ -255,7 +255,7 @@ D. Proposed solution: Blogs
    - Allow anyone with a valid Mozillians ID to apply for an account
    on the Mozilla India blog.

    - Moderators can do daily passes to approve valid accounts.
    - 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
    @@ -370,7 +370,6 @@ 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):

    @@ -406,7 +405,6 @@ individuals.

    Grievance redressal systems can be made of multiple layers:


    - Build a diverse team to address sensitive grievances.

    - Use Discourse with anonymous posting mode.
  3. Kaustav Das Modak revised this gist Jul 24, 2016. 1 changed file with 29 additions and 1 deletion.
    30 changes: 29 additions & 1 deletion proposal-mozin-restructure_kaustav.txt
    View file
    Original file line number Diff line number Diff line change
    @@ -6,7 +6,7 @@ Date : Jul 24, 2016
    Location : Bangalore
    Status : Draft
    License : CC0 1.0 [1]
    Version : 0.2.2
    Version : 1.0.0-rc1


    1. About The Document
    @@ -429,7 +429,35 @@ Grievance redressal systems can be made of multiple layers:
    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.


    ---
  4. Kaustav Das Modak revised this gist Jul 24, 2016. 1 changed file with 32 additions and 1 deletion.
    33 changes: 32 additions & 1 deletion proposal-mozin-restructure_kaustav.txt
    View file
    Original file line number Diff line number Diff line change
    @@ -6,7 +6,7 @@ Date : Jul 24, 2016
    Location : Bangalore
    Status : Draft
    License : CC0 1.0 [1]
    Version : 0.2.1
    Version : 0.2.2


    1. About The Document
    @@ -392,7 +392,38 @@ including (but not limited to):
    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
  5. Kaustav Das Modak revised this gist Jul 24, 2016. 1 changed file with 26 additions and 1 deletion.
    27 changes: 26 additions & 1 deletion proposal-mozin-restructure_kaustav.txt
    View file
    Original file line number Diff line number Diff line change
    @@ -6,7 +6,7 @@ Date : Jul 24, 2016
    Location : Bangalore
    Status : Draft
    License : CC0 1.0 [1]
    Version : 0.2.0
    Version : 0.2.1


    1. About The Document
    @@ -361,8 +361,33 @@ responsibilities will include (but not limited to):
    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
    ----------------------
  6. Kaustav Das Modak revised this gist Jul 24, 2016. 1 changed file with 23 additions and 6 deletions.
    29 changes: 23 additions & 6 deletions proposal-mozin-restructure_kaustav.txt
    View file
    Original file line number Diff line number Diff line change
    @@ -6,7 +6,7 @@ Date : Jul 24, 2016
    Location : Bangalore
    Status : Draft
    License : CC0 1.0 [1]
    Version : 0.1.9
    Version : 0.2.0


    1. About The Document
    @@ -332,28 +332,45 @@ C. Team members, operation and onboarding
    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.

    7. Resource Allocation
    ----------------------
    - 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.


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




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




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


  7. Kaustav Das Modak revised this gist Jul 24, 2016. 1 changed file with 53 additions and 15 deletions.
    68 changes: 53 additions & 15 deletions proposal-mozin-restructure_kaustav.txt
    View file
    Original file line number Diff line number Diff line change
    @@ -6,10 +6,10 @@ Date : Jul 24, 2016
    Location : Bangalore
    Status : Draft
    License : CC0 1.0 [1]
    Version : 0.1.8
    Version : 0.1.9


    1. About the document
    1. About The Document
    ---------------------

    This document is a response to the open call for ideas issued by the
    @@ -20,7 +20,7 @@ contributors while keeping the process as light-weight, transparent,
    open and accessible as possible and yet operating at scale.


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

    - Community member : An individual contributor to Mozilla.
    @@ -46,7 +46,7 @@ open and accessible as possible and yet operating at scale.
    of the number of community members participating in it.


    3. General structural guidelines
    3. General Structural Guidelines
    --------------------------------

    While defining structural guidelines for Mozilla India, we have to
    @@ -279,43 +279,81 @@ E. Proposed solution: Inter-sub-community information exchanges
    may clone or fork that idea for their region.


    5. Onboarding pathways
    ----------------------
    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

    6. Community operations
    -----------------------
    - 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.

    7. Team structures
    ------------------
    - 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.

    8. Resource allocation

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




    7. Resource Allocation
    ----------------------




    9. Recognition
    8. Recognition
    ---------------




    10. Grievance addressal
    -----------------------
    9. Grievance Addressal
    ----------------------




    11. Self-checks
    10. Self-checks
    ---------------


  8. Kaustav Das Modak revised this gist Jul 24, 2016. 1 changed file with 0 additions and 14 deletions.
    14 changes: 0 additions & 14 deletions proposal-mozin-restructure_kaustav.txt
    View file
    Original file line number Diff line number Diff line change
    @@ -238,20 +238,6 @@ B. Proposed solution: Discussions
    context.


    Mailing List ----
    | ^ |
    | | |-- Automated
    v | |
    Discourse --> Telegram --> IRC ___|

    ^ v v ----
    : : : |
    : : : |-- Manual
    .<..encourage <.......<... ___|

    Figure 1: Discussion data-flow matrix


    C. Proposed solution: PR and Marketing

    - Post announcements on Discourse with a specific tag or in a
  9. Kaustav Das Modak revised this gist Jul 24, 2016. 1 changed file with 18 additions and 1 deletion.
    19 changes: 18 additions & 1 deletion proposal-mozin-restructure_kaustav.txt
    View file
    Original file line number Diff line number Diff line change
    @@ -6,7 +6,7 @@ Date : Jul 24, 2016
    Location : Bangalore
    Status : Draft
    License : CC0 1.0 [1]
    Version : 0.1.7
    Version : 0.1.8


    1. About the document
    @@ -276,6 +276,23 @@ D. Proposed solution: Blogs
    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. Onboarding pathways
    ----------------------

  10. Kaustav Das Modak revised this gist Jul 24, 2016. 1 changed file with 125 additions and 12 deletions.
    137 changes: 125 additions & 12 deletions proposal-mozin-restructure_kaustav.txt
    View file
    Original file line number Diff line number Diff line change
    @@ -6,7 +6,7 @@ Date : Jul 24, 2016
    Location : Bangalore
    Status : Draft
    License : CC0 1.0 [1]
    Version : 0.1.6
    Version : 0.1.7


    1. About the document
    @@ -156,55 +156,163 @@ E. Decentralize everything, except primary communication medium
    second official channel.


    4. Intra-community communications
    ---------------------------------
    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

    5. Inter-community communications
    ---------------------------------
    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.

    6. Onboarding pathways
    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
    information of 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.


    Mailing List ----
    | ^ |
    | | |-- Automated
    v | |
    Discourse --> Telegram --> IRC ___|

    ^ v v ----
    : : : |
    : : : |-- Manual
    .<..encourage <.......<... ___|

    Figure 1: Discussion data-flow matrix


    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 daily 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.


    5. Onboarding pathways
    ----------------------




    7. Community operations
    6. Community operations
    -----------------------




    8. Team structures
    7. Team structures
    ------------------




    9. Resource allocation
    8. Resource allocation
    ----------------------




    10. Recognition
    9. Recognition
    ---------------




    11. Grievance addressal
    10. Grievance addressal
    -----------------------




    12. Self-checks
    11. Self-checks
    ---------------


    @@ -213,3 +321,8 @@ E. Decentralize everything, except primary communication medium
    ---

    [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
  11. Kaustav Das Modak revised this gist Jul 24, 2016. 1 changed file with 27 additions and 1 deletion.
    28 changes: 27 additions & 1 deletion proposal-mozin-restructure_kaustav.txt
    View file
    Original file line number Diff line number Diff line change
    @@ -6,7 +6,7 @@ Date : Jul 24, 2016
    Location : Bangalore
    Status : Draft
    License : CC0 1.0 [1]
    Version : 0.1.5
    Version : 0.1.6


    1. About the document
    @@ -129,6 +129,32 @@ D. Executive responsibilities should always have even number members.
    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. Intra-community communications
    ---------------------------------
  12. Kaustav Das Modak revised this gist Jul 24, 2016. 1 changed file with 14 additions and 3 deletions.
    17 changes: 14 additions & 3 deletions proposal-mozin-restructure_kaustav.txt
    View file
    Original file line number Diff line number Diff line change
    @@ -6,7 +6,7 @@ Date : Jul 24, 2016
    Location : Bangalore
    Status : Draft
    License : CC0 1.0 [1]
    Version : 0.1.4
    Version : 0.1.5


    1. About the document
    @@ -46,8 +46,8 @@ open and accessible as possible and yet operating at scale.
    of the number of community members participating in it.


    3. Structural guidelines
    ------------------------
    3. General structural guidelines
    --------------------------------

    While defining structural guidelines for Mozilla India, we have to
    take into account a wide variety of linguistic and cultural
    @@ -116,8 +116,19 @@ C. Any executive responsibility should have at least 2 members.
    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.



    4. Intra-community communications
    ---------------------------------
  13. Kaustav Das Modak revised this gist Jul 24, 2016. 1 changed file with 15 additions and 2 deletions.
    17 changes: 15 additions & 2 deletions proposal-mozin-restructure_kaustav.txt
    View file
    Original file line number Diff line number Diff line change
    @@ -6,7 +6,7 @@ Date : Jul 24, 2016
    Location : Bangalore
    Status : Draft
    License : CC0 1.0 [1]
    Version : 0.1.3
    Version : 0.1.4


    1. About the document
    @@ -101,7 +101,20 @@ B. The community should operate on a trust-first model

    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.

  14. Kaustav Das Modak revised this gist Jul 24, 2016. 1 changed file with 121 additions and 7 deletions.
    128 changes: 121 additions & 7 deletions proposal-mozin-restructure_kaustav.txt
    View file
    Original file line number Diff line number Diff line change
    @@ -6,22 +6,22 @@ Date : Jul 24, 2016
    Location : Bangalore
    Status : Draft
    License : CC0 1.0 [1]
    Version : 0.1.2
    Version : 0.1.3


    About the document
    ------------------
    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 transparent, open and
    accessible as possible and yet operating at scale.
    contributors while keeping the process as light-weight, transparent,
    open and accessible as possible and yet operating at scale.


    Terminologies used
    ------------------
    2. Terminologies used
    ---------------------

    - Community member : An individual contributor to Mozilla.

    @@ -46,6 +46,120 @@ Terminologies used
    of the number of community members participating in it.


    3. 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.



    D. Executive responsibilities should always have even number members.


    4. Intra-community communications
    ---------------------------------




    5. Inter-community communications
    ---------------------------------




    6. Onboarding pathways
    ----------------------




    7. Community operations
    -----------------------




    8. Team structures
    ------------------




    9. Resource allocation
    ----------------------




    10. Recognition
    ---------------




    11. Grievance addressal
    -----------------------




    12. Self-checks
    ---------------




    ---

    [1]: https://creativecommons.org/publicdomain/zero/1.0/
  15. Kaustav Das Modak revised this gist Jul 24, 2016. 1 changed file with 29 additions and 0 deletions.
    29 changes: 29 additions & 0 deletions proposal-mozin-restructure_kaustav.txt
    View file
    Original file line number Diff line number Diff line change
    @@ -6,6 +6,8 @@ Date : Jul 24, 2016
    Location : Bangalore
    Status : Draft
    License : CC0 1.0 [1]
    Version : 0.1.2


    About the document
    ------------------
    @@ -17,6 +19,33 @@ structure that can help the Mozilla India community attract and retain
    contributors while keeping the process as transparent, open and
    accessible as possible and yet operating at scale.


    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.


    ---

    [1]: https://creativecommons.org/publicdomain/zero/1.0/
  16. kaustavdm created this gist Jul 24, 2016.
    22 changes: 22 additions & 0 deletions proposal-mozin-restructure_kaustav.txt
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,22 @@
    Proposal for restructuring of Mozilla India community
    =====================================================

    Author : Kaustav Das Modak <[email protected]>
    Date : Jul 24, 2016
    Location : Bangalore
    Status : Draft
    License : CC0 1.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 transparent, open and
    accessible as possible and yet operating at scale.

    ---

    [1]: https://creativecommons.org/publicdomain/zero/1.0/