What does it mean to be a Mozillian?

Last week I wrote about certain issues with the authorization scheme we currently use for Mozillians.org. I described a specific problem that I personally want to solve. In the ensuing conversations online and elsewhere, several Mozillians pointed out that I offered no solution. Quite right.

In this post, I’ll propose a way to solve Mozillians.org’s authorization issues, particularly the concern I have about using the word “vouched” to describe Mozillians.org’s members. But to get there, we’ll have to tackle a much larger philosophical question: What does it mean to be a Mozillian? I will offer my answer to that question below, but the question belongs to the community. Its answer requires a chorus of voices. I look forward to hearing from the numerous others working on this question; until then, I offer the below.

To be a Mozillian, a person needn’t have an account in Mozillians.org. And not all accounts in Mozillians.org belong to Mozillians. Nevertheless, for the remainder of this post, I intend to treat the user population of Mozillians.org as synonymous with the group of people we call, “Mozillians.” Here’s why:

  1. If you have an account on Mozillians.org, other people (including Mozillians) are apt assume you are a Mozillian in word and deed.
  2. If other people would identify you as a Mozillian based on your actions or principles, then you can get an account on Mozillians.org.

Ergo, being a Mozillian and having an account on Mozillians.org are interchangeable, at least in some contexts.

And in that case, we should be very careful when we tinker with the Mozillians.org signup process. A person who does not share the principles of a Mozillian, or who has not taken the actions expected of a Mozillian, should not be able to join Mozillians.org. A person who shares those principles and has taken those actions should get an account easily. So signing up for Mozillians.org should require some verification of principles and action.

That’s the spirit behind the current signup process. Right now, in order to join Mozillians.org, a prospective Mozillian must “get vouched”. Getting vouched means finding an existing Mozillian — ostensibly, to prove yourself to them — and asking them to make you a full member of Mozillians.org by vouching you.

But as I discussed at length in my earlier post, the vouching system has some important flaws. One of them is that it’s not true to life. People don’t become Mozillians by finding some other Mozillian and asking if they can be a Mozillian too. People become Mozillians through action and principle.

So, when designing the Mozillians signup process, we need to identify the actions and principles that clearly make someone a Mozillian, then build them in code. Our signup process will explain what it means to be a Mozillian and it will verify that people joining Mozillians.org are, indeed, Mozillians.

Which means that, in order to fix the Mozillians.org’s authorization issues, we have to answer a fundamental question: What does it mean to be a Mozillian? What are the principles and actions that distinguish a Mozillian from a run-of-the-mill netizen?

What are the principles and actions that distinguish a Mozillian?

I think the answer is simple: Being a Mozillian means you actively and intentionally advance the principles in Mozilla’s Manifesto.

Of course that simple answer masks significant complexity. It’s difficult to even talk about what being a Mozillian means because we have overloaded the term “Mozillian.” We use it to identify members of a movement and we also use it to describe an authorization flag. We’ll never come to any consensus about a word that we use differently in different contexts. So let’s disambiguate.

1. We use “Mozillian” to describe a group of people who relate to Mozilla’s brand, products and principles.

When Mozillians.org was built, its intended audience was the so-called “core contributors“: people who have leadership positions within one of Mozilla’s projects. This group comprises a few hundred individuals. Not all of them have accounts on Mozillians.org.

Nowadays, Mozillians.org accounts include nearly 1,800 belonging to people who participated in Mozilla’s 2013 Summit event, which was billed as a global gathering of Mozillians. The majority of Summit attendees are “active contributors“: people who have volunteered substantial time and interacted with other Mozillians in the past 12 months. Some of them are core contributors, some are not. All of them are quite committed to actively working on Mozilla’s behalf.

Mozillians.org’s 4,000 users also include at least a few “casual contributors“: people who have contributed to Mozilla’s work in some way – say, by submitting a crash report or filing a bug – but don’t put in time for Mozilla every week. Some would say casual contributors aren’t Mozillians, which makes their accounts in Mozillians.org a data quality issue.

In each of the above cases, we use “Mozillians” to describe a group of people who relate to Mozilla. They specifically relate to Mozilla through action. But action alone isn’t enough to identify a Mozillian. Mozillians are Mozillians only if they self-identify as such. “Mozillian” is an identity someone assumes because they are aware of the principles in the Mozilla Manifesto and intend to advance them.

2) We use “Mozillian” to describe a group of people who can be trusted with sensitive data and access.

When “Mozillian” described a few hundred people, most of them daily contributors, it made sense to treat membership in the group as a signal of trust. If you were a Mozillian, you may have received press releases pre-embargo, seen web sites before launch, heard product announcements early, or received some other access or account. All of this was granted simply because you were a Mozillian.

Now, with more than 4,000 accounts on Mozillians.org, that single authorization flag is insufficient. While some groups share things with all Mozillians, not all groups do. IT teams don’t grant someone commit access to a repository simply because they’re a Mozillian; they grant commit access to people who have passed through a specific process unrelated to being a Mozillian. Public relations and press liasons don’t always share pre-embargo press with all Mozillians; folks working on security issues don’t always share vulnerability information with all Mozillians; product teams don’t always share pre-release product announcements with all Mozillians. Each group shares information with a subset of Mozillians who’ve joined a smaller trust network through some mechanism independent of the mechanism that makes someone a Mozillian.

In the future, the Mozillians network will be even less suitable for granting access. Mozilla is a giant world-wide movement aspiring to grow. We hope to have a million Mozillians one day. That’s not a trust network. Membership in the movement implies shared principles, but doesn’t guarantee complete alignment or trust. If we wish to grow the network, we must acknowledge this.

This evolution doesn’t restrict our ability to use trusted groups to share things with Mozillians. Instead, by relieving the overall network of an unrealistic expectation that it should always be trusted, we create the possibility of ever richer, more specific communities of trust. Whenever trust is required for some activity, an authorization group will emerge. The group’s curators will determine what process distinguishes its members. With a few small tweaks, Mozillians.org can be a repository of such groups.

The authorization connotations of “Mozillian” are falling away even now. “Mozillian” no longer means, “people we automatically share sensitive things with.”

Both of the above cases describe an evolution: of the concept “Mozillian,” of the group collectively called “Mozillians,” and of the membership of Mozillians.org. In the past the community was small and trusted. Now it is not-so-small and not-so-trusted. And in the future it may have many, many more members.

But the community’s current definition doesn’t scale; instead, it impedes evolution. Vouching isn’t how we become Mozillians; restricting our membership to daily contributors isn’t how we grow to have a million Mozillians. We need to encourage casual contributors to become Mozillians. We need an inclusive definition of “Mozillian,” one that admits people who have varying levels of commitment and time. These Mozillians will value Mozilla’s Manifesto just as much as Mozilla’s core contributors do – they’ll just have less time to spend volunteering.

We need an inclusive definition of “Mozillian”

In the future, when we have 1 million Mozillians, “Mozillian” will be a term we use to describe people who…

  1. Self-identify as being a Mozillian
  2. Take some individual or collective action to advance the principles in the Manifesto

We can’t wait for the first million to join us before we start thinking of ourselves this way. We have to create an inclusive network now that invites the exponential growth we aspire to. To get there, we should agree: Mozillians are people who actively and intentionally advance the principles in Mozilla’s Manifesto. People who actively and intentionally advance the principles in Mozilla’s Manifesto are Mozillians.

Now, having grappled with philosophy far exceeding my capabilities, I return to more familiar territory. Whew!

Once we’ve explained in simple terms what it means to be a Mozillian, we simply have to devise a Mozillians.org signup process that encodes it. If we were to do so with the definition I offer above, then we would ask people signing up for Mozillians.org to read the Manifesto and input a URL (to a pull request submitted, a bug closed, an addon distributed, a Manifesto principle tweeted, a t-shirt bought, et cetera). We’d take their signup as proof of self-identification and we’d use the URL to verify action taken.

That’s how I’d solve the Mozillians.org authorization issue. I’m sure others have great ideas too! Here’s what I think those ideas should do:

  1. Define in simple terms what it means to be a Mozillian. Bonus points if the definition scales!
  2. Explain how to encode it in a web application signup process.

Please do comment, share, critique, and improve upon this post.

What does it mean to be a Mozillian?

9 thoughts on “What does it mean to be a Mozillian?

  1. ozten says:

    I think the solution will be primarily a people solution and not a technical solution.

    I think the act of self-identifying as a Mozillian and signing into Mozilla websites with a vouched Mozillian identity is enough friction to separate Mozillians from the general public.

    I like that you break down authorization into different classes. Maybe ‘pre-release product announcements’ should be treated like we treat security issues or people’s t-shirt sizes. This information is only available to a “need to know” group of people.

    Being vouched isn’t enough to get access to sensitive information.

    Vouching is of debatable utility, but it does provide a low quality assurance that this person was involved in the project. This is nice for semi-private spaces on the web.

    I think the responsibility of qualifying groups of people to disseminate information or capabilities falls on the person sharing that information and not on the “million Mozillian sign up” mechanism.

    For pre-release info, PR or engagement should figure out a way to find out who wants access to pre-product announcements periodically and curate that list of people entrusted with that information. This may need to be fine grained, like ‘pre-release Andorid’.

    Of course technology can help us curate these lists. It would be great to see people active on Fennec mailing lists, SUMO and bugzilla in the last 30 days. But…

    Maybe we need guidelines and some minimal technology to help these gatekeepers curate these lists. This technology may or may not be Mozillians.org. A spreadsheet and mailchimp can go a long way without custom software being written.

  2. Hoosteeno says:

    Ozten, I thanks for your comment. Sounds like we’re in almost perfect agreement. 🙂

    I agree that “vouched” is a bar, quite low, that people have to get over to join the community. And I agree that having a bar is valuable. But I think the word “vouched” itself can be interpreted (and is regularly interpreted) to imply something about trust that isn’t true now and gets less true as we grow. My earlier blog post went into detail about this.

    Thought experiment: What if the word we used for the current mechanism was “confirmed”? You want to be a Mozillians.org user, you have to get another Mozillians.org user to confirm that you’ve contributed to the project. It has a completely different connotation, doesn’t it? You might individually choose to share different information with someone who is a confirmed contributor than you would with someone who is vouched.

  3. Once you put aside the idea of granting permissions based on a Mozillians profile, the goals of restricting access become much different IMHO. The restrictions lend some value to the identity, and give us a basic sense of social trust – not the trust to keep secrets, but more the trust that the person isn’t going to troll and is going to interact with others in a honest and positive fashion. I can imagine giving access to prototypes to this audience, for instance, because you can at least hope for a more sympathetic but also engaged audience. Not because the prototype is secret, but because you don’t want to invite the public to piss on your work while passing by. If a Mozillian pisses on your work at least there’s a chance they will do it for a good reason, and I would expect that you could followup and get a response from that person if you wanted to engage with their critique.

    As such I think the evidence a person provides to become a member should be more social than digital. We want someone to be proud of their membership. Anything we automate about the verification process will reduce that pride, because being validated by a computer doesn’t provide a basis for pride. The personal effort “we” (“we” I guess meaning established Mozillians) invest into the onboarding reflects the value of the membership, so even deoptimizing might be right to some degree. Instead of vouching, can we go even further? For example: an existing Mozillian could be required to write a paragraph describing the positive things about the potential member.

  4. Hoosteeno says:

    Ian, you make an excellent point. Being inside the network implies sympathy. I think this aligns fairly well with the first sense of “Mozillian” I describe, but I didn’t characterize it like that.

    I wonder how much we should depend on the signup process to enforce social norms within the network? Only a little bit, I think. I believe that growing the network depends in part on optimizing onboarding, and I also believe that growing the network is more important than selecting for subtle alignments.

    I think the very same tools that might power unique authorization needs could power unique alignment requirements. To take your example: A group could emerge for people who want to see prototypes. The curator of the group could draft some rules of participation, such as “Participants won’t piss on attempts. Making things is hard. Criticizing things is easy.”

  5. gervmarkham says:

    I think that if you posit that all of these groups of trusted people are different, then you leave each person who wants to do some non-public sharing with an admin nightmare. And that will result in people doing the easy thing, which is often using MoCo-internal comms channels.

    I think we would do much better if we had a small number of groups whose membership criteria were known and whose general trust level was also known, and then a lot of sharing would default to one of those groups, with a specialist group only being spun up in a few circumstances.

    See the current discussion on my “Mafia-style” group proposal for one way of defining a trusted set.

  6. davidwboswell says:

    As someone who was involved in the initial launch of mozillians.org along with Gerv and Ozten, I can say that it’s fine with me to move away from the concept of vouching. If I remember the conversations correctly, vouching came up as a possible way forward in the absence of a better solution that could verify someone’s activities.

    I like the focus on activity and I think we could streamline this process even further using this concept. One idea that came out of brainstorming before would be to get rid of the sign-up process entirely. We could simply send invitations to people as they start getting involved.

    We’ve modeled this out using the Webdev contribution pathway. Check out step #3 at the link below. We could send invitations out to everyone who has gotten their first pull request merged — that would verify activity and would also make the discovery process simpler for new volunteers since they wouldn’t need to know about mozillians.org.


  7. Hoosteeno says:

    I had no idea that the whole crew of Mozillians.org founders would comment here. Thanks, everyone.

    Gerv, the proposal you link to is great. I think other groups will require different levels of trust, and we shouldn’t try to prevent them from flourishing. But I also think that any group providing sufficient trust to serve prominent Mozilla services — I’m thinking about a Trusted Discussions service served to the MozMafia trust network — will be a de-facto standard that other services will also depend on. In other words, I think organic processes will produce the result you desire.

    David, the conversion point invitation idea is also great. Maybe its triggers can include other actions. Mozillians could easily be an invite-only network but it should include non-committers.

  8. davidwboswell says:

    > Mozillians could easily be an invite-only network but it should include
    > non-committers.

    Definitely. If we went to an invite-only model, the burden would be on us to map all of the different types of contribution pathways that exist. Fortunately, that’s what we want to do anyway with a Pathways Working Group. This would need to extend across the whole range of current opportunities as well as be dynamic to include new opportunities as they emerge.

Comments are closed.