ASD

about insights blog +follow

posted on Fri, Sep 09 '16 under tag: mozilla

Mozilla India underwent a restructure in Mozilla India Meetup 2016. What’s the new structure? Will it be any good? What are the new challenges that face Mozilla India in this regard?

Thanks to George there was an impetus to refresh Mozilla India to a state where it isn’t broken. The refresh was set to happen in a community meetup. This meetup happened on 26-28 August in Pune. Before the meetup, there was a meta (planning) meetup in Pune to figure out how the meetup should be. In the planning meetup people were divided into teams that focused on various parts of the meetup.

One of the teams was the strategy/structure options team. (There’s an interesting back story to how this team was formed instead of just deciding a structure within the planning meetup. Ping me in private to listen to that). The role of this team was to come up with various possible structures for Mozilla India through an open consultation with the community (TRAI made this a fashion) and consolidate those into one nice and neat structure that hopefully works.

So, there was a call for proposals and a reminder. And there were a total of 10 (decimal number) proposals submitted which were put in a google drive folder and left for scrutiny by community.

Kaustav and I were added to the strategy group for being valuable in this process. (It was decided in the planning meetup itself that two additional slots of the strategy group would be filled in this fashion. The others in the group were selected by drawing names (Deb, Vnisha, Prathamesh, Vineel), or because they absolutely had to be in the team (George)). So, the 7 of us had a lot of video calls and chats (just days before time ran out and the meetup started). The ideas from various proposals were summed up.

Just a couple of days before the meetup, we decided to split up so that we didn’t run out of time. Deb, Kaustav, and I worked on drafting the integrated draft proposal. Vnisha, Prathamesh, and George on orchestration of the sessions introducing the proposal. This etherpad shows that. Towards the end of the pad you can also read the rough draft we built starting that night.

By next day, there was a Google Doc with the draft proposal. This one looks pretty and got printed as handouts during the meetup.

Day 1 of meetup

Thanks to Jafar, Tripad, and Kaustav, and I don’t know who else, there was live-streaming of almost all parts of the meetup. Links to videos here.

The proposal was introduced on day 1 in the morning itself and questions were asked and comments were made and clarifications were sought and given and so on.

The tl;dr of the proposal at this stage was - have open, transparent, accountable teams with decentralized decision making and utmost flexibility and adaptability in structure; mainly functional teams (with long term focus) and focus teams (possibly cross-functional, with short term focus on particular events), and also a meta team to glue things together; supported by various infrastructure and communication channels.

The discussion focused mainly on what a functional team is, what a focus team is, what the role of meta team is, etc.

Why did we have this structure? Because the task force model wasn’t versatile enough to handle quick bursts of activity that’s demanded by emergency issues. Because a lot of opacity existed in the past that made contributors not be efficient in contributing. Because being flexible is probably better than being rigid when you have no clue about what will work and what won’t.

I think one of the fundamental differences between task force model and the new model is that there are no explicit leaders in the current model. (There is a role called “facilitator” in the new model but this role is more about reporting and being accountable rather than about leadership.) And another is that people are given a lot of trust by default. So, what we hope to achieve here is people stop looking up at someone else for commands and start taking up (and has the power to do so) initiatives and getting things done by themselves.

This distributed authority model is not something new in communities similar to ours. For example, the cornerstone of Wikipedia’s success is trusting everyone and allowing anyone to boldly edit articles and people using this opportunity to create articles according to their interests. Open source code can be “forked” without asking for permission and contributions can be made easily. We hope Mozilla India will be a place where people who understand and care for the Mozilla mission can (and do) come in and do things without asking or waiting for anyone’s permission

Another interesting, but overlooked, facet is flexibility. Flexibility translates to freedom. Freedom to make Mozilla India the way one wants it to be. No part of the structure is set in stone. Various self-checks mechanisms can be used to point out and change the parts of the community by anyone who thinks there is a better way to do it. Thus, hopefully, an year from now nobody will be able to complain that they aren’t able to contribute to Mozilla because of some problem with the structure of the community.

One of the points to note here is that this proposal is aspirational to a great extent. That is, it is something to be worked towards. For example, the parts that deal about recognition - keeping track of metrics - needs tools and processes that do not exist yet. George describes it so:

“This is an aspirational strategy, not one that we will be able to implement all parts of tomorrow. If you only set goals for that which is already invented then you’re likely to move only incrementally forward at best.”

Also, a lot of questions are left with partial answers - How does the community settle on a communication channel? How does the grievances and arbitration process look like? When and how does the transition happen? This is where the meta team comes in. A meta team can figure out answers to these questions soon.

Then there were a lot of back and forth conversations about the potentials and pitfalls of the structure. By afternoon we had realized the mistake that we hadn’t thought about geographical teams at all (although regional Mozilla communities, arguably, have a great role in making this refresh essential). So, people sat down and quickly added a different dimension of teams called geographical teams.

Geographical teams consist of people who are in the same place at any point in time. Now, we already have various communities for different regions in India. According to the new structure, these communities can continue to exist, only that these regional communities allow people who join Mozilla via them access to the entire set of people (and with them their expertise, skills, etc.) who constitute Mozilla India.

To elaborate, I have seen regional communities who have elaborate structures within themselves. These may or may not have mirrored the past Mozilla India structure. I have seen new contributors join these regional communities but never reach the Mozilla India task forces, because their attention is withered away by the structure of the regional community itself. The current proposal essentially is asking regional communities to rethink their role in enabling participation.

By reducing the role of a regional community to just being a geographical team, more people can join the functional and focus teams of Mozilla India where they benefit from access to people (staff, and Mozillians from other regions), resources, etc., and a chance to work with a wider target audience. Also, regional communities does not have to have reinvent their own wheels in maintaining different teams if they funnel participation into Mozilla India teams.

If everyone buys this idea, within next few months, the number of people working in various teams of Mozilla India will be greater than or equal to the sum of the number of people in each regional community (which sadly isn’t true right now)

It is also interesting to note that iterative improvement of the structure started immediately after it was introduced (and I hope this continues into the future).

Day 2

Next day was about imagining various teams and making them real.

Meetup participants were invited to list down teams that they see forming and these lists were consolidated to create a list of important teams. Here’s an important point though - this list is neither final nor exhaustive. Rather, it’s a starting point. The list was created so that people could divide themselves and start working on some of the teams that need to be.

Here’s the list of functional teams, again:

There was also a very small list of focus teams created, but I won’t list them here because focus teams, by definition are very volatile and keep forming and dissolving.

Notice, the functional teams in the current list are significantly different from the task forces we had in the past. This is indeed an experiment, but also a welcome change. For example, there’s no “technology” functional team consisting of coders. Rather there is “mature technology” and “future technology”. This can help in ensuring contributions balancing what’s stable technology (like firefox) and what’s evolving (like servo).

The list of functional teams here also mostly have corresponding teams on the Mozilla staff side. So, it is easier for communicating and getting help from Mozilla.

Based on the list and their interests people were divided into many different groups to work on setting some objectives, criteria, and goals for these functional teams (and focus teams). But due to limited time and enough chaos, this didn’t work out well for many functional teams.

Anyhow, it was only an exercise of “what could be” that happened at the meetup and people should now come up and discuss among themselves and form various functional groups. The success of the new structure is when this happens organically without anyone (not even the meta team) having to intervene. Let’s hope, in the coming weeks, that people talk up about things that they care about and form groups, discuss, disagree, resolve disputes, form consensus, and start functioning on their own.

Also, on day 2 a provisional meta team was formed which has the sole purpose of forming the meta team within two months. This provisional meta team currently includes the 7 people in the strategy group (George, Deb, Vnisha, Prathamesh, Kaustav, Vineel, and me) and the 3 Reps in Reps council (Umesh, Faisal, and Shahid).

Aftermath

The meetup was just an introduction. Bulk of the work in restructuring our community should be done by the community members themselves. It is now upon us to think, talk, document, and move forward all the teams and the structure we have.

Anyhow, there were many conference calls after the meetup. (In one of these, Kaustav filled me in on the details of the meetup that I missed in in view of attending the meetup only via web stream.) Brad made some interesting points in one call.

Kaustav took the initiative in converting the structure proposal from Google doc to an actual version controlled doc which is hosted at github.com/MozillaIndia/openbook and can be read online at leanpub.com/mozillaindia-openbook. The beauty of this is that further modifications to the structure can be made as simple pull requests.

Various functional and focus teams have already started talking. View or modify the list here. If you do not see in this list the team you are interested in, make some noise and get it added.

As for the provisional meta team, we haven’t yet started working together as the provisional meta team and we hope to soon.

If you have any questions or comments, please add them to this discourse topic.