Mozilla India Restructure Proposal
Can Mozilla India become a guardian of the open Web in India?
Mozilla India is going through a tough phase where contributors are increasing and meaningful contributions are not.
This document consists of a proposal to restructure Mozilla India aimed at maximizing impact and growth.
- Teams teams everywhere.
- Everyone is a leader.
- Work in the open.
- Invite participation.
Teams are ad-hoc groups of people that form in response to solving a particular challenge or a series of challenges. There is no hierarchy in a team. Everyone is a leader and everyone can lead their own path to the solution. Members of a team are peers who help in completing the solution.
Working in the open is a shortcut to many things - letting everyone know, getting more people involved, early feedback and course correction, etc. It should be mandatory that every activity that’s happening in Mozilla India be in the open.
In addition to working in the open, there should be intentional invitations for participation from teams. These can take the form of beginner tasks, feedback forms, etc.
These four principles are fundamental and inviolable. We can lay down criteria to figure out if anything violates these principles.
When should a team be formed?
A team needs to be formed when there’s any task that needs more time for an individual to finish than how much it would take to form a team and finish it.
How is a team formed?
A team is formed when a group of people come together without violating the fundamental principles to solve a task that is not being worked on by any other team.
That is, if you form a group, say, to solve a Firefox bug, and you make a wiki page or a discourse topic about the purpose of your team, how your team communicates, how to get involved, etc, and nobody in your team has an exclusive last say on anything, then you have a team.
To make discovery of teams easy there shall be a central place (a URL) which has a table listing down all teams, their purpose, their communication channel(s), and an optional link to get more info.
When does a team cease to exist?
A team doesn’t exist as soon as
- its task is done
- it violates the fundamental principles
- there is nobody working in it
Who are the members of a team?
Anyone who involves themselves in the team’s work is a member.
What are the other possibilities of a team?
Teams can mingle with each other. For example, if there’s a team that works on mobilizing people they can have their members working in various other important teams to make sure those other teams have success in mobilizing more people.
Teams can regroup. A team is never static. It can split into different teams, merge with other teams, disburse itself, reform, etc infinite number of times. Teams are flexible.
Teams can be inside teams. Any team can have teams within it focusing on sub-tasks. These teams are not sub-teams because they should also fulfill all the criteria of a team.
Any person can be a member of multiple teams.
A team has collective responsibility. If a team fails to achieve its task, all the members are responsible.
Why is everyone in a team a leader?
Notice that teams do not have a single leader and everyone is a leader. This is because that’s how it has been in the free culture. Nobody dictates nobody on how to do something. Everyone is free to lead themselves to a solution.
But this doesn’t necessarily mean that there will be no leadership within teams. Members who have the qualities of a leader will automatically lead others. Although, nobody will be called a “leader”.
Who will represent teams?
The teams can decide within itself who should represent themselves in any situation. They can change their representative at any time and they can have multiple representatives for multiple situations.
Will there not be disagreements in teams?
Yes, there will be. There will be disagreements and even fights on how things should be. How can these be solved without a leader? Through consensus. But what if a consensus can’t be reached? I will suggest later in this post that there be a team which focuses on reaching consensus. So, such a team can be consulted to reach consensus.
Work in the open
How much of work should be in the open?
As much as possible. At least a word should be mentioned about anything that took a couple of hours to do.
Where is “open”?
Open is in the open Web. That is, there should be a URL which is publicly accessible. Discourse, wiki, etc provide such URLs.
Open is where people can see. If a wiki page is created deep in a userspace and nobody ever sees it apart from you, that isn’t really open. Open is such that someone who is listening to at least one official communication channel of Mozilla India will be able to see it if they pay attention.
Patches are welcome
Aren’t patches always welcome? Just saying that you’re open to contribution from others isn’t enough invitation for others to contribute. Teams must make it dead simple for others to get started contributing. They should proactively seek participation from outsiders.
Teams that absolutely need to be
|Mobilizers||To get more people participating in various teams, especially the teams that have a large impact on mozilla’s mission|
|Communication||To help teams communicate|
|Mediators||To seek and settle disputes and disagreements|
|Onboarders||To welcome newcomers and get them on board|
These are just a few. A lot of teams can be formed with wide or narrow focuses.
To run this community as described above, Mozilla India needs the following Infrastructure.
mozillaindia.org can serve as a canonical website.
Teams must also be able to set up web-pages if they want to. They shouldn’t have to spend money for doing this. Subdomains of mozillaindia.org could be made use for the same.
Github pages can be used to allow teams to easily set up their web presence.
A wiki could be set-up but we have a history there.
Mozilla India already has one main blog.
We should consider creating more blogs for different kinds of blog posts. There could be a community blog where various community members can write. (Like openstreetmap.org/diary)
We also need a planet to aggregate all our blog feeds.
The community India category of mozilla discourse can be used as the primary official forum for our community.
The mailing list can be used as a secondary forum. Where by secondary I mean, it’s still an official forum, but discourse is the primary preference for all communication.
It’s imperative that we have accounts on Twitter, Facebook, Instagram, YouTube, etc. Creative use of these can help us reach more and more people.
Control of Infrastructure
By controlling the infrastructure of Mozilla India one can virtually control Mozilla India. Therefore, it is important that we rethink the way our infrastructure is managed.
I propose that there be a team for managing each infrastructure. These teams should have a minimum of 2 members in the beginning. These members should be elected by the community and be responsible and accountable.
Additionally, every six months a new member should be elected to each of these teams. Thus, new people will keep coming hopefully bringing with them innovative ideas. The infrastructure that need teams include, but aren’t limited to:
- DNS (mozillaindia.org)
- Discourse topic moderators
- Mailing list moderators
- Facebook group moderators
- Facebook page admins
- Twitter account access
- Blog administrators (for each blog)
- YouTube admins
- Instagram account access
- Github organization access
Next time, we should not need a community meetup for changing the way Mozilla India works. It should be possible for any team to make modifications to any part of our community structure. I propose the following procedure for the same.
- Only teams can propose modifications. These shall be like RFCs.
- Proposals should be made on the primary communication channel and mirrored or cross-posted to all possible communication channels.
- Proposals should be clear and detailed. General ideas should be taken up for discussion as a team first and only when clearly refined be brought up as proposal.
- A clear consensus shall be formed through discussions on what action need to be taken about the proposal.
- Based on consensus reached through feedback these proposals can be ratified and incorporated into the structure of our community or whatever the consensus was.
This structure shall have a canonical location with a URL and be iteratively improved in the future. It shall be put in place by the community through the community meetup in 2016.
There are a lot of topics this proposal doesn’t talk about (like recognition, documentation, events organization, etc). I believe I have laid out the foundation that is required to allow teams to form which can discuss and create structures on the topics that aren’t touched up on by this proposal.
tl;dr Do whatever you want.