Vouched Improvements on Mozillians.org

Back in October I wrote a few blog posts describing a significant problem with the way we admit new members into the Mozillians.org community platform. Yesterday the Mozillians.org team fixed it!

Before yesterday, everyone with a “vouched” account in Mozillians.org was empowered to vouch others. But we never explained what it meant to vouch someone: What it implied, what it granted. As a result, the standard for being vouched was arbitrary, the social significance of being vouched was diluted, and the privileges granted to vouched users were distributed more widely than they ought to be.

Yesterday the Mozillians.org development team released a major refactor of the vouching system. For the first time we have a shared definition and understanding of vouching: A vouch signals participation and contribution in Mozilla’s community, and grants access to content and systems not available to the general public.

The new vouch system includes features that…

  • ask a “voucher” to explain to the community why they are vouching someone
  • grant the “vouching” privilege only to people who have themselves been vouched multiple times
  • remove “legacy vouches” from accounts that were vouched before we agreed what vouching meant and whose current contributor status can’t be easily verified

It is much clearer now who can access non-public information using Mozillians.org (people who have been vouched because they participate and contribute to Mozilla) and how that list of people can grow (through individual judgments by people who have themselves been vouched numerous times).

When we know the composition of a network and understand how it will grow, we can make better decisions about sharing things with the network. We can confidently choose to share some things because we understand whom we’re sharing with. And we can reasonably choose to withhold some things for the very same reason. Understanding a network simultaneously encourages more sharing and reduces inadvertent disclosure.

Thanks to the Mozillians.org development team for making these excellent improvements!

Site launch: Affiliates 2.0!

Cross-posted from http://blog.mozilla.org/webdev/2014/05/21/site-launch-affiliates-2-0/.

We just launched a redesigned website for Firefox Affiliates — check it out!

New Affiliates web site!

The Affiliates website is a portal for almost 100,000 Mozilla supporters. Affiliates believe in Mozilla’s cause and want to show their support by placing an affiliate link on their website. Here’s mine:

If you use Adblock Plus you probably see nothing here. And that’s a shame.

The original Affiliates website launched in 2011. Its branding recalls an earlier era in Mozilla style. I will miss those fuzzy monsters, but (for now at least) I know I can still find them on Mozilla.org’s 404 page. And seriously, after three years, the site needed more than a brand refresh. As part of this launch we…

Image from the original front page.

The Affiliates 1.0 front page included fuzzy monsters.

  • Upgraded to the latest version of Playdoh
  • Removed lots of old code and subsystems no longer in use
  • Reconsidered and redesigned the entire user experience
  • Updated the pages to a beautiful take on Mozilla’s Sandstone theme
  • Added an affiliate leaderboard
  • Added user profiles and a personalized dashboard
  • Added space for localized news and announcements
  • Much more!

If you’re already a Firefox Affiliate, we* hope you enjoy these improvements. And if you’re not, why not sign up now? Being an affiliate is an easy way to support the efforts of a non-profit that strives every day to build the web the world needs.

We’d like to hear from you. Please file a bug if you find one or reach out in the #affiliates channel on irc.mozilla.org to say “hi”. And keep your eye out for more new features — there’s another batch of Affiliates Awesome just around the corner!

* The Affiliates 2.0 team included dozens of people spanning the globe — too many to list here. This site redesign was a collective effort of Mozilla’s amazing affiliates, volunteers, localizers, designers, copywriters, engineers, quality assurers, contractors,  and many others. Thank you all.

A new Mozillians.org signup process

I previously wrote about some issues with the Mozillians.org authorization system. In a nutshell: The language we use to talk about signing up for (“vouching”) and accessing the platform through the API (“corporate vs. consumer”) doesn’t match our present and future needs, and also doesn’t match some of our recent practices. This disconnect has a variety of problematic ramifications. We want to fix it.

The resolution for these dual concerns is related, but we don’t need to resolve them simultaneously. Below, I describe a proposal for resolving concerns related to signing up for the platform. Many of these ideas came from williamr, jmenon, davidwboswell, giorgos, and others across Mozilla.

The problem we need to resolve is ambiguity about what it means to have an account in Mozillians.org. And, with a nod to Mozilla’s ambitious plans for community building, we need to resolve this problem in a way that makes it easy for the right people to join Mozillians.org.

Goal: Eliminate confusion about what having an account in Mozillians.org means. Make it easy for the right people to join Mozillians.org.

Those two requirements are quite complex. Opinions differ about what it means to be a Mozillian, and about how that relates to the systems that a Mozillian might join. We reached out to the community in a variety of forums to help us understand the scope of this conversation (here and here, for example). After discussing for several months, we believe the community has provided sufficient guidance for us to write code. Specifically, the community said (to use Mitchell Baker’s words),

‘[We need] to be inclusive, and provide welcome, encouragement and legitimacy to people across a range of different levels of engagement. At the same
time, we want a way to identify the set of people who are actively committed and engaged in a community of shared effort. A single “yes/no” decision — yes, you’re a Mozillian, or “no, you’re not” can’t capture all of this well.’

It’s clear that being a Mozillian is a journey. In order to support this journey, we want people who are just starting out to have access to a basic set of resources within Mozilla’s contributor ecosystem.

Mozillians.org is in a position to provide this basic level of service; for example, having an account in Mozillians.org allows Mozillians to connect with one another, lets them access certain protected resources, and makes possible a unified view of an individual’s contributions across myriad contribution pathways. Therefore, we want to build a Mozillians.org signup process that allows people to join Mozillians.org as soon as possible — at the beginning of their journey.

We want to build a Mozillians.org signup process that allows people to join Mozillians.org as soon as possible — at the beginning of their journey.

However, not just anyone can join. Mozillians do share certain characteristics and we want our signup process to capture these. The community has converged around a small set of criteria that distinguish a Mozillian. According to that consensus, in order to be a Mozillian, someone should…

  1. Be active, now or historically
  2. Self-identify with Mozilla’s mission
  3. Engage with other Mozillians in the community

We can capture all of these criteria in a signup process. In other words, we can build a harmonic coherence, building the community’s definition of Mozillian right into Mozillians.org.


Obligatory doge graphic

We’ll do this by replacing the current signup process, which depends on a vouching step, with a signup process driven entirely by invitations. Here are the specific features we propose to implement in the first iteration of this work:

  • In order to join Mozillians.org, a person must have an invitation.
  • Invites can be sent by people who already have accounts in Mozillians.org.
  • Inviting will be rate-limited (e.g. every Mozillian gets 5 invites per month).
  • The signup process will be clearly explained to logged-out users anyplace it makes sense to do so. For example, “Think you have what it takes to be a Mozillian? Great! Just find a Mozillian to invite you.”
  • The invitation process will include specific instructions including the criteria for inviting someone. For example, “Mozillians are active. Please invite people who are actively contributing.
  • All language about vouching will be replaced with language about inviting, site-wide.
  • Upon accepting an invitation, a user will be presented with the Mozilla Manifesto. Clicking “I Support Mozilla’s Mission” lets them continue to the profile creation screen.
  • The profile creation/editing screen will include links to specific information about how particular information added to Mozillians.org profiles is shared (e.g. “Information in your profile will be viewable by other members of Mozillians.org”).
  • Profiles will include an “Invited by” link to the person who invited them (people who were vouched in the prior system will be “invited by” their voucher).
  • A formal announcement of this change will be made in advance, giving all users 30 days to change or remove their accounts if they wish to.

Together, these features address the overarching goal of this effort because they clarify the makeup of our community. The new interactions and language clearly explain that Mozillians.org relies on the good judgment of each community member, and can grow organically based on the actions of any existing member.

These features also address the criteria that define a Mozillian:

  1. They specifically ask existing members to consider contribution activity when inviting new members.
  2. They require each new Mozillian to read and support the Mozilla Manifesto, self-identifying with the mission.
  3. They ensure that new members of Mozillians.org are already engaged with someone in the community.

In the future, we can imagine extending this functionality in a few ways:

  • We can allow certain API accounts to create invitations on behalf of a specific pathway. For example, when someone submits their first PR to a Mozilla repository in Github, they might get an automatic invitation to join Mozillians.org.
  • We can prompt existing Mozillians to read/agree to the Manifesto on a regular basis — perhaps annually?

We are eager to hear feedback about this proposal because we intend to start coding a new signup process in early 2014. Please reach out in the developer’s mailing list or in the comments.

A Weird Ritual

I stumbled across the short form creative brief by way of a tweet from @jmspool and I had to share it. It reminds me of something we built at dojo4 when I was CEO there, but it includes a Very Important Addition.

Technology and design work is expensive, far too expensive to do without some anticipated return (unless you work in a sector that allows you to light bricks of technology dollars afire on a hot summer day “just for the ambiance”).

When I was at dojo4, upon signing a contract with a customer, I tried to capture a couple sentences about their anticipated return on a 3″ by 5″ notecard. I pinned the notecard to a corkboard where everyone could see it (and I mean everyone: our employees, our guests, our other customers). We called the notecard the Project Compass.

The project compass was intended to be a guide, an arbiter in times of uncertainty. Whenever a question arose about project scope or direction, we could look at the project compass for clarity. A typical project compass might be “Redesign the website and add a feature allowing customers to create and manage their own profiles.”

Astute readers may notice the above compass doesn’t describe a return on investment at all. That’s quite common, unfortunately. It is HARD to achieve clarity about a project’s anticipated return. Often, a project’s sponsor has already done some initial analysis and design and is giving implementation experts the output of the initial analysis (“Redesign the website”) instead of the input (“Increase signups and improve retention”). Sometimes the sponsor can’t articulate what they hope to achieve. Just as often the implementation team can’t hear it.

At dojo4 we assumed imperfection in our project compass. Every project required a compass to move forward, but we agreed (and said out loud) that the compass might change. We even asked @anthonydimitre to draw us a classy graphic explaining exactly how this process would work:

dojo4's Project Compass, circa 2011

dojo4’s Project Compass, circa 2011

We usually dove into implementation as soon as a compass was written and pinned to the corkboard. For the minimum-viable-product startups dojo4 worked with, “implementation” was practically synonymous with “changing the compass”. But “implementation” also always meant “charging hard toward maximal features in minimal time”.

The little black “No” in the middle of the illustration above is what we envisioned happening if the project was discovered to be out of alignment with the compass. We’d look at stories and check them against the compass and change one or the other as necessary. But delivering code at breakneck pace to customers with rapidly changing goals was totally orthogonal to thoughtfully reviewing and making adjustments to paper-based project artifacts. So, our project compasses often went stale.

This is common in every kind of project everywhere. Sometimes it is a problem; sometimes not. When a project sponsor and all the project’s implementers have fantastic rapport and constant engagement, they can happily forget whatever they wrote in the brief three months ago. They’re grooving. But sometimes, the project sponsor and the implementers will carry divergent ideas of the project’s purpose all the way to launch day. I know at least a few people who’ve changed careers after pulling a week of all-nighters to deliver something that nobody wants.

That was precisely what the project compass was designed to help us avoid. But a corkboard full of stale project compasses didn’t help anything. Which is why the short form creative brief caught my eye. The document itself resembles the project compass — more verbose, still quite brief. But unlike the compass, the short form creative brief is imbued with longevity through a “weird ritual at the start of every meeting”:

One of the team members, always a different person, would read the exact same document out loud, word for word. The document, about three–quarters of a printed page, contained a tiny creative brief about the design they were working on. Reading it out loud was how they started every design meeting, whether it was a brainstorming meeting or a design review….[then] the project’s leader would turn to the group and ask the same question, “Everyone agree that this is what we’re working on today?”

Many times this exercise has no obvious impact: Everyone simply nods and the meeting moves forward. But occasionally, someone asks for clarification. They ask because they’re new to the project; or they ask because they’ve been assigned a task that doesn’t seem aligned; or they ask because they sponsored the project and no longer agree with something in the brief. When someone asks, the group discusses and updates the brief as needed.

Ritual is the perfect word for this exercise because the magic only happens if you do it religiously. You read the brief every time. You read the brief even when it feels silly to read the brief. Even — no, especially — when the meeting is about something urgent or tense. Because reading the brief puts the project’s critical facts right where they belong: At the forefront of everyone’s mind, in consensus terms freshly aligned with the effort actually underway, for the entire duration of the project.

I suspect the shape of the brief (or compass) is not nearly as important as its frequent review. Of course, it should contain enough information to explain why project participants keep meeting and working together, instead of playing pinball or hoarding shoes or visiting every county in Texas. That could be one terse sentence. The important thing is that the brief continues to explain where the group is headed, even if the group changes direction.

At Mozilla we use etherpad for planning meetings and taking notes during meetings. I have begun adding a “theme” to the top of etherpad agendas as a gentle way to remind people of the big reason we’re having yet another weekly meeting. For example, on Mozillians.org right now, the big reason we’re having yet another weekly meeting is to discuss the Curated Groups feature that we’ve been working on all quarter.

After reading up on the short form creative brief, I think I may take a moment at every meeting to speak our current theme out loud, too. Does everyone agree that this is our focus right now? Are there any questions about what it means?

Proposal: The Future of Contributor Tools

I work as a web product engineer for various web products at Mozilla, including several platforms designed to serve Mozilla’s contributor community. I team up with product stakeholders to design products and I work with implementation experts to build them. I’m responsible for achieving vision.

This role gives me a good perspective on what we say we want to do and how we do it. And I see an opportunity for us to increase the scope and ambition of both in our contributor tools efforts.

In September, I collaborated with David Boswell and Chris More on a proposal explaining the opportunity. Since then, inspired by great conversations at the 2013 Mozilla Summit, Mozillians have discussed and converged on a few foundational definitions that will inform our subsequent conversations about contributors. Simultaneously, the proposal (which has been in Google Documents until now) has slowly made its way around the organization by way of document invites.

Since there seems to be some interest in it, and since invite-only isn’t really the Mozilla way, I’m sharing the most recent version of the proposal here.

Please note: This is a proposal, it’s not a plan. If you support it, your advocacy will help! If not, your challenging questions will help, too!

Contributor Tools Program

Definition and Scope

The Contributor Tools program builds and maintains systems that connect contributors to contribution opportunities and helps keep them actively involved. These systems serve the entire project and are not specific to a given functional area or product. This includes tools that:

  • Offer people both online and offline ways to get involved with the project (such as a call-to-action on http://www.mozilla.org or an organization-wide events system)
  • Match new contributors with tasks and teams appropriate to their skills and interests (such as a task board or a tool to help contributors find bugs)
  • Provide visibility into the activities contributors are involved in (such as a contribution logger or a dashboard)
  • Recognize people for their contribution to the project (such as a badging system or a profile management system)

This does not include tools that:

  • Serve the needs of just one functional area (such as a localization workflow tool)
  • Serve as a platform for interacting with an audience other than new and active contributors (such as a product site, a blog aggregator or an affiliate marketing program)
  • Would be required by Mozilla even in the absence of a vibrant contributor community (such as a bug tracker or a customer support website)

Problems Addressed

Connecting with and relating to contributors is an effort that enjoys broad support across Mozilla. But the tools we currently depend on to connect with and relate to Mozilla’s contributors are fragmented. As a result:

  • We do not undertake tools efforts according to a unified strategy
  • We do not measure the value or impact of these efforts in any comprehensive way
  • We do not take advantage of the efficiencies or provide the cohesive experiences that shared technologies, data, processes and resources could deliver

The Contributor Tools program will address these problems by unifying various tools efforts in a single program, creating a new structure for strategy, measurement and performance.


The stakeholders for these tools include the staff and volunteers actively involved with building communities around their projects and the contributors who devote effort to furthering Mozilla’s mission. These stakeholders are represented by the Systems and Data Working Group of the Community Builders team.

The Systems and Data Working Group will meet regularly to establish decision-making structures for the program, set requirements for each system, create criteria of success for the program and advocate for and secure resources for those initiatives. In 2013 the group identified the systems required to complete Mozilla’s contributor tools suite.


The Contributor Tools program should optimally have enough resources to maintain existing systems (providing security and stability fixes but few enhancements) while undertaking one major new effort at a time (such as building a new platform or redesigning an existing platform). This would require a small team of implementation staff plus the option to bring on contractors for burst efforts.

The Web Productions team has successfully built a program similar to the Contributor Tools program to deliver continuous service and improvement on http://www.mozilla.org. That program is accountable to a group of stakeholders from around the organization who are represented by a product owner. The product owner works closely with a program manager who helps guide the efforts of a cross-functional implementation team including some dedicated staff, some shared staff, some contractors and some contributors.

Implementing a similar approach for the Contributor Tools program would mean identifying individuals to occupy all of those roles. The exact number of individuals would depend on the scope of the program’s accountability. Our initial analysis suggests that existing staff and contractors might be able to provide most or all of the resources initially needed by this program.


This program will also be able to gain additional leverage in two ways:

  1. Current community tools efforts are fragmented with teams building siloed functionality that could be extended to support the entire project (e.g. an events manager in reps.mozilla.org, contribution dashboards in support.mozilla.org). Numerous staff throughout the organization contribute, or are ready to contribute, to these fragmented efforts. Guiding their efforts with a unified strategy will allow for smarter allocation of existing resources.
  2. These tools will also serve as featured web development projects for new contributors. The program’s charter could include a mandate to maximize contributor involvement in system development.

Next Steps

The most minimal implementation of this program would require some realignment of product and engineering teams to cover the broader scope contemplated here:

  • Product teams would drive products forward based on the priorities of the Systems and Data Working Group of the Community Building team.
  • Implementation teams would shift between projects as necessary to achieve the program’s vision.

This realignment would enable the program to undertake Contributor Tools efforts according to the priorities established by a broad coalition of stakeholders.

A more ambitious program implementation might also include:

  • Adding a full-time Community Builder to the program team to maximize contributor involvement in product implementation.
  • Enlisting engineers, designers and other implementation experts from elsewhere within the organization who are already working on this effort.

These additions would enable the program to develop new features more rapidly and/or support more systems. Furthermore, the full-time Community Builder’s role could be charged with establishing a model for other web projects to use, thereby increasing project capacity across the entire organization.

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.

Refactoring the Mozillians.org authorization scheme

One of the platforms I work on at Mozilla is Mozillians.org. Mozillians.org is Mozilla’s multi-constituent identity repository (or “phonebook”, as some prefer to call it). It is a simple profile-and-group management tool that serves data via a responsive UI and a read-only REST API. It houses about 4,000 user profiles: People who contribute to Mozilla in some way, whether staff or volunteer; people who consider themselves to be Mozillians.

Screen Shot 2013-10-14 at 2.34.07 PM

The post below is an analysis of Mozillians.org’s authorization system, which I believe is broken, and a rallying call to fix it.


Mozillians.org has become a mature platform and a valuable source of information about people who contribute to Mozilla’s products and mission, and it is likely to be important to Mozilla’s ambitious contributor goals over the next decade. But Mozillians.org has outgrown the authorization paradigms it started with. Therefore, in order to prevent data safety issues and questions about product integrity, we must design and implement an authorization system that accommodates current and future data and users. We should apply this system evenly to both the UI and the API.


Mozillians.org supports two classes of user account: unvouched and vouched. Anyone in the world can create a new account; that account will be unvouched, and it has very limited rights in the system (just a step above an anonymous browser). In order to be vouched, an unvouched user must find a vouched user who will vouch for them. In practice this means asking in IRC. Once a user is vouched, they have full permission to search and browse all Mozillians.org data and can also vouch other users.

Mozillians.org also supports two classes of API consumer: Mozilla Corporation and Community. Mozilla Corporation API consumers can access almost every attribute of most users and groups in the system. Community API consumers can only access the vouched/unvouched flag of a user whose email address is already known to the consumer. As initially conceived, accessing the API as a Mozilla Corporation consumer would require the requester to be paid staff and the URL of the consuming application to be a mozilla.org URL.


Vouching has lost much of its practical meaning, since we have no shared understanding or documentation of what vouched means or when vouching is appropriate. Some users are vouched immediately upon asking for it, while others must demonstrate some record of contribution. In practice, getting vouched is unevenly applied and poorly explained. Once vouched, accounts remain vouched forever. Mozillians.org’s current membership includes users who contribute daily or monthly; users who contributed in the past, but no longer contribute; and users who have never contributed beyond creating a Mozillians.org account.

Corporation/Community API authorization has lost much of its meaning, too. The criteria for being a Corporation consumer are not clearly stated in a policy document, and the data provided to Community consumers are not rich enough to meet the needs of most Community requesters. These factors combined encourage an ad-hoc approach to API authorization (for example, this bug).

While the erosion of meaning in our authorization paradigms has advanced, so have the quality of the data we solicit and the promises we make about its protection. In the past year we added numerous fields to user profiles, and we have plans to add more. We also added per-field privacy controls to profiles, a measure intended to give individual users more confidence about sharing private identifying data. These are definitely working well in the UI, but we have not yet applied per-field privacy controls to the content of API responses.

These are data safety and product integrity risks that we must address.

By granting easy access to the platform (either by vouching or granting Corporate API access), Mozillians.org exposes personal information that might not be shared if the actual exposure was clearly understood by users of the platform. We implicitly suggest that a trust network exists, but that network has an uneven (and low) barrier to entry; we implicitly suggest that API consumers will adhere to certain standards, but we do not strictly enforce these; and we explicitly declare that certain fields will be exposed to smaller groups, but we don’t yet apply these rules in the API. These are data safety and product integrity risks that we must address.


One obvious response to the problems described above is, “Stop vouching people who aren’t obvious contributors, and stop granting Corporate API access to Community API consumers!” But that response looks backward, not forward.

Mozillians.org has incredible potential as the single source of identity information across Mozilla’s varied constituencies — staff and non-staff, technical and non-technical, contributing daily or contributing just once, Foundation and Corporation. It is perfectly positioned to serve critical data about people to applications we haven’t even dreamed of. Look no further than the MozillaIndia Leaderboard (the subject of the bug linked above), which shows the most active bugzilla.mozilla.org contributors in India by mashing up bugzilla data with Mozillians.org data.

The ClawIt doesn’t take much imagination to realize that any number of contributor tools and outreach efforts will benefit from more Mozillians with richer profiles. From simple ad-hoc mailing lists to ad-hoc group-based authorization; from mashups like the MozillaIndia leaderboard to a unified Mozilla events system; from identity unification in bugzilla.mozilla.org to Dr. Claw, the Mozilla Schwag Bot©, which automatically sends t-shirts to contributors when they achieve certain badges; from 4,000 Mozillians to 1 million Mozillians: It all depends on more inclusion and more API access, not less.

It all depends on more inclusion and more API access, not less.

This blog post marks the start of the conversation. It is accompanied by a tracking bug in bugzilla.mozilla.org and a discussion thread on the developers mailing list. I’ve turned off comments here, but would love to hear other perspectives on the mailing list.

Ultimately, we may need to replace vouched/unvouched with something else, and we will certainly need to reconsider how API users authenticate and authorize to get API data from Mozillians.org. It’s going to be a fantastic technical and organizational challenge.

What an exciting time to be a Mozillian!

Update: In response to subsequent feedback on various channels, I proposed a framework for solving this, plus a concrete solution.

Appendix A:

If you are a Mozillians.org user and are concerned about the safety of your data, please don’t delete your account! You can take some simple steps to restrict access to your profile while we work through this bigger question:

  1. If you wish, you can change what applications (if any) can access your profile through the API. Look for the “Services” section in the Edit Profile view. But beware: Services like Badges.mozilla.org, Air.mozilla.org and others may require API access to function.
  2. While API users are not currently restricted by per-field privacy rules, UI users are. You can change fields to be visible to either Public (anonymous) or Mozillian (vouched) users.
  3. Very few fields are required. You can choose what you share. As Mozillians.org’s authorization scheme evolves, please consider sharing more information. Dr. Claw, The Mozilla Schwag Bot© won’t work without your t-shirt size and address!

Appendix B:

Dr. Claw, The Mozilla Schwag Bot© was conceived during the composition of this blog post for illustration purposes. Developers needed!

Djangocon Debrief

big_shouldersLast week I went to djangocon.us, the annual conference where Django fans from around the world congregate to toast the web framework we use for most of our web applications at Mozilla (by way of Playdoh). The conference was held in Chicago, “the city of the big shoulders“. I was joined there by the creator of Django, several leaders from the Django Software Foundation, several Mozillians, and lots of excellent developers from around the hemisphere. Some highlights below:

Test Driven Development
On the first day I attended a half-day tutorial about Test-Driven Development in Django taught by Harry Percival, who’s written a book on the subject. It was excellent. In addition to giving me some practice building a Hello World application in Django, the tutorial also taught some great techniques for turning user stories into code by way of functional tests (using selenium) and unit tests (using django’s built in test runner). Key takeaways for me:

  • Test driven development is not necessarily slower than the alternative, and is also kind of fun once you get in the groove.
  • TDD helps document progress; it can significantly ease the context-switching pain of leaving a project and returning to it later.
  • Unit tests are only half of a solid TDD approach. The other half is functional testing, which happens in a simulated user environment (i.e. in Firefox).
  • Basic functional testing is straightforward to implement with selenium. Using selenium would give Mozilla developers increased ability to manage and contribute test coverage that we currently depend on an overtaxed WebQA team for. It might be worthwhile to try it on a project sometime.

A pre-release version of Harry’s TDD book is available online for free.

Client Side Frameworks
There were two presentations about client-side frameworks — Angular.js and Ember.js. These frameworks enable developers to move substantial chunks of an application’s logic onto the client device. Naturally, each speaker was confident that the framework he was presenting was the best one. Their important differences were not clear to me from the presentations, and this area of web development is positively frothing with alternatives. What was clear is that the Django community is eager to learn about and use client-side frameworks; some developers are even asking for official guidance or standardization from the DSF. We may end up using one of these frameworks on reps.mozilla.org in 2014.

DSF Updates
The president of the Django Software Foundation gave a glimpse into the next year of Django’s evolution. Because the framework is moving to an accelerated release schedule, the foundation is considering a long-term support option; this might mean that Django 1.4 will get security releases for longer than we currently expect. The DSF is eager to secure Django’s longevity; to that end they’re asking fans of the framework to promote it, they’re asking for corporate sponsors to support it, they’re looking for new code contributors to bring more modern framework features in, and they’re materially supporting local and regional events about Django.

Of course there were plenty of other talks. I got fired up about Docker, thinking about how it might make things easier for Mozilla’s contributors. And I was glad to hear about powerful core migrations, since they seem like such a fundamental framework feature.

And one of my favorite parts of any conference is exploring a new place with new people. I met folks from Argentina, France and Canada; enjoyed Chicago’s fine IPAs with freelancers and core committers; and led a very large, very hungry group of hackers on a fruitless search for a good bacon cheeseburger (not recommended).

This conference was, for me, a great opportunity to very quickly encounter the people, projects, culture and questions that make Django what it is. While organizers freely admitted that Django is not the newest, hippest web framework available, they stood by its proven capability and pragmatic utility. They also demonstrated a collaborative, creative and accepting open-source culture that distinguishes Django among web frameworks. Within the community there seems to be plenty of shared enthusiasm for keeping Django relevant for years to come.

One highlight unrelated to the conference: I jogged out to the end of Navy Pier one morning in my Mozilla Webprod t-shirt. A bicyclist approaching from behind turned to look at me and asked (with a note of wonder), “Do you really work for Mozilla? That is so cool!

I think so too.

Release management with Semantic MediaWiki

I did some wiki markup hacking today to make the release management process for Mozillians.org just a tiny bit easier.

Mozilla uses Semantic MediaWiki for its public wiki. Everyone affectionately calls this instance wikimo. Semantic MediaWiki is a powerful tool, and is kind of fun if you think adventures in extreme punctuation are fun. (I do!)

Part of my job is to communicate about web development projects to various stakeholders, and the wiki is one tool I use to accomplish that. I use it to publish project plans — it’s great for those. I also use it to keep track of meetings and product releases, and it’s kind of annoying for those.


These kinds of content — meetings and product releases — follow a familiar pattern: An ordered list of content items links to each individual item, and each individual item uses the same layout as the other items. When a new item appears, the list gets longer. Just like a blog, in fact.

But, to date, maintaining this content has meant creating a new page for a new content item, and putting the right markup into it for that content item, including a few variables, and then editing the page where the list is to add another item to the list. Like I said, it’s kind of annoying.

I’d really like to have a link, and when I click on the link I would get a form to enter my variables. Submitting the form would create the new content item, update the list, and I could move on. Enter Semantic MediaWiki’s templates, forms, and queries!

1) As soon as you start talking about variables in any content system, you also start talking about templates. Semantic MediaWiki lets you build templates for wiki content. Here’s the one I built:

This template puts some explanatory text on the page (“Features landing…”) using wiki markup, and the sky is the limit on that. But more importantly it uses wikimo’s very own bugzilla plugin to drop some bugzilla bugs into the page in a nice tabular format, and it also makes this release page known to the page that lists releases. It uses two user-defined properties to accomplish that:

  • A Milestone property, which should correspond to the values of Bugzilla’s target milestone field — in this case, it’ll be something like “2013-09-26″, because our target milestones are all ISO Thursdays.
  • A Release-list property that contains the value, “Mozillians”. This is what our list of releases will be looking for in order to list releases.

If you visit the template you’ll just see the content in the <noinclude> block. You actually have to visit a page using the template to see what it outputs.

2) Semantic MediaWiki’s templates are not form-powered without the Semantic Forms extension. It’s installed on wikimo, luckily. Here’s the form I built:

A lot of this is default content — the buttons at the bottom, for example, are pretty straightforward. So let’s talk about the critical parts:

1) The {{{info}}} tag. Its page name parameter specifies the name that any page created from this form should get. In this case, it’ll get the Milestone value from the Mozillians Release template (which we defined above). So the title of a page created using this form will be something like “2013-09-26″.

2) The {{{for template}}} tag. This specifies that submissions made to this form will fill up properties in the Mozillians Release template. It also describes the fields on the form.

If you visit the form you’ll just see the content in the <noinclude> block. You have to visit a special link to use the form.

3) You can create that special link with the {{#formlink:form}} tag. It specifies the template to use; the link text to use; and a query string parameter. Remember, when the form makes a new page it’ll just have a name like “2013-09-26″. But we actually want it to have a name like “Mozillians/Releases/2013-09-26″. We’ll send that “super_page” as a parameter in a query string to the form:

{{#formlink:form=Mozillians Release|link text=Make a new mozillians release|query string=|super_page=Mozillians/Releases}}

4) Finally, we have a link to follow to a form that uses a template to create a release. And we want to list releases. Here is the inline query code to do it:

Here’s what that dense little punctuation poem does:

  • Show all the pages that include a semantic mediawiki property called “Release-list” whose value is the name of this page (in this case, “Mozillians”). Remember the “Release-list” property in our template?
  • Show them as a list.
  • Order them with the lexically largest page name first. Since our page names are uniform strings with ISO dates at the end, this floats new releases to the top.

Putting it all together, I can now create a release page that displays all the bugs associated with a release, and have that release listed in a list of releases, in one easy step. Which, I hope, will mean our release documentation cleaves just a tad closer to the truth.

Note to anyone considering doing something similar on wikimo: You will inevitably create some test pages as you experiment with this. A friendly wikimo manager suggests that you create them in your own personal wiki namespace, which you can access at a link like this: https://wiki.mozilla.org/index.php?title=User:YOUR_USERNAME/.


In an earlier post I described a project that produced a perfectly good result, but not the result required. This is inevitable — it will happen to everyone buying or selling creative work — and it can be quite demoralizing. As someone in the business of delivering custom services or products, figuring out what people want is the most challenging, most important thing you can do. And you can do it by repeating a single mantra.

A friend once asked a capable carpenter to install a door over a hole in the drywall of her basement where some plumbing valves were accessed. After a day of work she was aghast to discover that the carpenter had bought a full-sized closet door, built a frame for it, drywalled the frame, painted it and even installed a doorknob. The work was high quality and fairly priced. But she wanted a tiny little access hatch — a foot square, maybe — not a giant closet door. She paid the carpenter’s bill, then hired another carpenter to tear the door down and put in a little access hatch.

This has probably happened to you, too. Have you ever realized when your food arrived in a restaurant that you were hungry for something different? Have you ever begrudgingly paid for a service (a haircut, say) that is acceptable, but not what you really wanted?

what a mistake

It is easy to say, “The carpenter should have known his customer wanted a little access door, not a big closet door.” And maybe he should have. But should the barber have known what haircut you had in mind? Should the server have guessed that you wanted a different entree than the one you ordered?

Surely at some point in your journey you’ve thrown away days or weeks of work after a new detail or requirement emerged at the last minute. Almost everyone has. Why didn’t you know what to produce the first time?

Well, it’s because knowing what people want when they ask for something is hard. People often don’t know what they want, or don’t know how to ask for it. Delivering what they actually want requires you to interpret many layers of motivation and establish a shared understanding of the actual desire.

Arrow on flyer layers

Some of us are born with an innate ability to understand what people want very quickly. Others learn to do so by mastering a particular domain. Occasionally a shared understanding is based on a long relationship — it is easier to anticipate your friends than it is to anticipate strangers, after all. But for most of us, on most projects, establishing a shared understanding requires hard work. The sooner we do this work on a project, the less effort we waste.

Every project has a desired outcome — it’s one of the principal characteristics of a project. But in countless projects, the stated outcome would never be enough on its own to satisfy the sponsor or customer. Consider the following common projects:

  • Redesign the website
  • Rewrite the application using Python
  • Make a a new logo

They seem quite clear, don’t they? They’re just as obvious as, “Put a door over the hole in the wall.” It’s simple: Buy a door, frame it in, do some finish work. Make some new website designs that the customer likes. Reproduce the functionality in Python. Keep drawing logos until the customer likes one. Done and done, right?

Lorde Gelo

Bah. That isn’t a list of desired outcomes, it’s a list of implementation details. Those aren’t ends, they’re means. They’re the work you — the expert — do when you’re trying to deliver the thing. But they’re definitely not the thing you’re trying to deliver.

When someone asks you to redesign their website, ask them “Why?”.  They must have something in mind, something they think will happen if you redesign their website. How can you do a good job if you don’t know what that thing is? And when they say, “To make it look more modern,” you say, “Why?” Again, they must have some reason to believe they need a modern-looking website. And when they say, “So more people will visit the site and stay longer,” you say, “Why?” “Because if more people visit the site and stay longer, I can join a better advertising network.” “Why?”

Eventually, after playing 3-year-old for long enough, you’ll have your answer: “Because advertisements on this site are how I make my money, and I’m not hitting my goals right now.” Aha! It has nothing to do with modern design. Design is just an implementation detail. The customer wants to show different advertisements and thereby increase revenues; they think they can get there with a new site design; and they’re willing to invest in that theory. Now you can actually apply your expertise to the customer’s needs. Now you’re solving the right problem.

Almost always, asking “Why?” will reveal how faulty the initial project description was, and how far off-track you might have gone if you didn’t ask. That’s when you get to demonstrate the hard-won experience of a craftsman:

The Cutler's Hands

  • “You don’t need to rebuild the application in Python. You just need to add indexes to your database.”
  • “You don’t need a new logo, you need different colors.”
  • “You don’t actually want me to install a door there. You just need to cover this hole in the wall with a little access hatch, right?”

Extracting enough information to build the right thing can take a lot of time and may require asking and answering the same question over and over. During this exercise it sometimes feels like nothing is happening at all. But what is happening means everything to your project.

Sometimes, this approach simply won’t reveal the information you need to deliver a good project. And, unfortunately, you won’t know that until you’ve already done some work. So, in another blog post I will explain how inexpensive prototypes can help. Hint: Building the wrong thing allows you to ask, “Why not?”