Mozilla Contributor Directory/Vision

This is a vision for the management of the personal data of contributors to the Mozilla project.

A Unified Personal Data Store

Many Mozilla groups have a need to store, retrieve and manage personal data about Mozilla contributors (as distinct from users). It has been suggested that we have a single central store for such information.

Contributor Goals and Benefits

• Not having to enter that personal data in multiple different systems
• Single place where they can find out about other contributors and their interests
• Easier to form more meaningful relationships
• Greater certainty of being included in group activities
• Easier to have your data removed from our systems

Mozilla Goals and Benefits

• Better idea of the size and interests of the community
• Improved communication with specific interest groups
• Better community 'feel'
• Only one lot of code to audit for security and privacy
• Single personal data repository available to many different clients/front ends
• Better able to fulfill our privacy policies

The alternative to a single store is that we will continue to have several silos of user data which either cannot talk to each other, or which have to be connected in an N² combinatorial problem. This problem will only get worse with the advent of Join, ReMo and other new initiatives to grow our contributor base. The goals and benefits above will continue to elude us.

Mozilla Values

The way we go about this project should reflect the principles and values in the Mozilla manifesto:

• Enrich people's lives (principle 3)
• Strong privacy protections (principle 4)
• User empowerment and control (principle 5)
• Open standards and protocols (principle 6)
• Open source software (principle 7)
• Transparency of management processes (principle 8)
• Excellence in implementation (principle 10)

Values and This Project

So how do we apply those values to our problem? Specifically, I think this means the project should:

1. Be driven as much by the benefit to the individual user as to the Mozilla organization. We don't want this project to be driven by the need for community metrics - that is not respecting of people. It's also counter-productive - people will not add their data unless it benefits them.
2. Give granular access control over data items. The project should be a showcase for how our privacy principles can be put into practice in social software, and how we can make privacy easy to manage, without surprising side effects and without the ability to change the ground under people's feet.
3. Be open source, reusable software and use open protocols. It makes very little sense for an organization which believes in open source software to use closed source. And we should build it to be reusable by other communities which have a similar requirement.
4. Be governed by community consensus. If there are privacy levels, and procedures for acquiring an additional level of trust or access, how that works should be defined by community consensus, not by a handed-down decision.
5. Rather than solving problems, make it possible for people to solve their own problems. There are currently lots of different parts of Mozilla who need this function, and I'm sure there are requirements as yet unknown. So the best way to build the system is one which does not attempt to meet every existing requirement, but provides hooks and facilities for each group to implement their specific application on top of the system. We need APIs that many systems can use.

Domesday and 'Mozillians'

The current proposal for writing the Domesday software, and 'Mozillians' as an implementation/deployment of that software, is one embodiment of these principles - although one could imagine others. If Domesday as currently planned turns out not to be the right path, I hope discussion of the principles above will prove illuminating in working out where we should be going instead.

Domesday reflects the above principles in the following ways:

Enrich people's lives

• Community members can find out about each other - the JSON API allows clients to be written for internal project systems and tools (e.g. Hgweb, Bugzilla, Thunderbird) and so people can be identified and information about them retrieved.
• A single store means that people who are in it, and tag themselves correctly, are less likely to get accidentally left out of some new project.
• Stronger and more rewarding relationships will develop between people who know each other better.

Strong privacy protections

• Every data item is optional.
• Each data item has an individual privacy setting.
• We are developing a UI where privacy is a first-class citizen, not an afterthought.
• Directory software is designed for the storage of personal data, and the security of OpenLDAP's ACL system protects a great deal of personal data today.

User empowerment and control

• A user can see, and with the exception of another user's personal tags on them, change all or remove information stored about themselves in the directory.
• Users can use personal tags to create their own defined subsets of users, and can (personally or in code) attribute any meaning to those tags that they like. This makes it possible for external software written by other contributors to use the service as a personal data storage system and not have to implement their own. This is very empowering.

Open standards and protocols

• LDAP is an open standard defined in RFCs.
• JSON is an open standard defined in an RFC.

We may also later choose to implement up-and-coming standards like XRD, so we can be a WebFinger endpoint.

Open source software

• All prerequisites are OSI-approved open source software.
• All code written will follow the Mozilla license policy.

Transparency of management processes

• The number of privacy levels, and how users get access to higher levels, will be a community decision.
• There is no hidden "super user" access for some Mozillians - it is clear exactly who has access to what.

Excellence in implementation

• The plan is to use the Mozilla webdev team's best practice framework, Playdoh.

History and Status

There have been several attempts at creating a community directory for Mozilla; previous ones have foundered on unclear ownership, no one part of the company having enough at stake to make a go of it, and - perhaps caused by the former - scope creep, as those involved tried to get more parts of the company involved.

Our hope for Domesday is to avoid scope creep by providing a store and an API such that additional requirements can be served by other applications rather than made part of Domesday itself.

The status of Domesday is that Gerv is writing a demonstrable initial version in time for the All Hands on the 4th of April. This will have many of the UI features of the full version, but no access control.

Relationship to other systems

Domesday is designed to "help other people solve their own problems". So if another group wants to keep track of its people, they can do so using the tags system - either self-tagging ("Tag yourself with "qa" if you do QA") or bless-tagging ("Email Axel to be tagged correctly when you join an l10n team"). And, assuming the user makes the information is accessible to them, a group could search for and email everyone with a particular tag.

This is by contrast with the approach of trying to write a system which implements all the functions required by a variety of different groups within Mozilla. Attempting this was one of the significant causes of the failure of previous community directory projects.

Single Signon

Domesday as envisaged is not a single signon system (concern about scope creep) but it could be used by other systems as the basis of one. If you have a particular tag, "foobar-access", then you could allow access to your system only to people with that tag.

Also, given that the system is LDAP-backed and uses standard LDAP objectclasses, it would be much easier to use it as the basis of such a system (e.g. using existing LDAP support in products like Bugzilla) than it would be if we were to write an entirely bespoke system.