Mozillians/Domesday Configurations

From MozillaWiki
Jump to: navigation, search

Note: This is currently a draft and not finalized yet. Please share your feedback.


This page gives information specific to the Mozilla deployment of Domesday, to be called "Mozillians".

Special Tags

Anyone can get an account in the Mozilla Community Directory. However, the Directory will allow people to have one or more of three special states, implemented as tags in Domesday. Two of those tags control information access in Domesday; the other is for community kudos and respect.

Mozillian

The mozillian tag indicates active community members. This is a mark of community kudos and respect. Here's David's explanation of how it might work. (Note that this is given as an example of a mechanism, not a policy; it does not mean that only people who would get invited to a Summit would get tagged as Mozillians in the Directory.)

We looked closely at how community members were identified and approved for being invited to the last Summit as a model to follow for tagging someone as a "Mozillian".

Short version
  • The Summit invitation process is a good model to follow and a web of trust approach seems like it will work for the phone book.
Long version
  • People were identified for the Summit with a web of trust approach. For example, Asa asked Gandalf for a list of active l10n community members and in some cases Gandalf asked for a list from others when he didn't know people in a certain locale. By all accounts this generated a solid list of people for the Summit.
  • We think a slightly modified process can work on the phonebook for identifying who should be designated as an official Mozillian. In general, if someone is already in the system as a Mozillian, we trust their judgement about who else should be considered an official Mozillian.
  • We can mitigate potential abuse of this system a few ways (for example, if someone vouches for a friend who hasn't done any work in the community):
    • The person who vouches for someone should be shown on that person's profile. If there is ever a need to, we can then go back to the person who vouched and ask for more information about why they thought this person should be considered a Mozillian.
    • People can only vouch for someone when they both have one of the same tags (for example, both people have the l10n tag). Each project area is going to have a different set of criteria for defining activity and vouchers should be connected to that area. This could have a side benefit of being an incentive for people to add useful data to their profiles so we can count number of people in certain project areas.
    • To get the system started we should invite the list of people invited to the Summit to create a profile on the site and not require that they be vouched for -- in effect they've already been vouched for separately and there wouldn't be anyone already in the system with the same tags to perform the vouching.
    • If people enter a profile without any tags we can have an automated response that encourages them to add this data if they are active or if they aren't we can welcome them to the community and help them start to get involved.
    • Longer term, we should look into automating systems that would bring in data from other systems. This would allow to do several things including automatically vouching people (for instance, if the system sees that they've committed X lines of code to certain repositories) and flagging people who were erroneously vouched for (for instance, if no data about this person showed up at all). We could also create individual stats dashboards for each profile.

Vouchers vs. Invitations

There have been discussions about approving profiles through either a voucher or an invitation system. I think these are essentially the same and should both be used. The main difference is just when in the process the approval happens.

For invitations, an existing Mozillian is pre-approving someone's profile by sending them an invite to the system. In this case, they fill out their data and set their privacy preferences and they are done.

For vouchers, someone fills out their data, sets their privacy preferences and then asks an existing Mozillian to approve them.

Ideally the system would allow for both processes to work. An invitation only system would not allow people to self select themselves as a Mozillian and would become too inclusive. Invitations are a great way to help with the discovery of this system since one person can invite whole groups of people in to the system.

Trusted

The trusted tag indicates active core community members. Being tagged as trusted means you have access to information in the directory which is marked by its owner as available only to Trusted community members.

The exact way it gets enabled remains to be decided - but that's OK, because what the process is should be a community-wide decision anyway. Roughly speaking, though, you get this tag when enough people in the community have worked with you to have a good feeling about letting you know their personal data, and Mozilla trusts you e.g. to not reveal sensitive discussions. A good way to bootstrap the list might be with the list of Summit invitees, but unlike "Mozillians", it would not have a model where anyone so tagged could vouch for anyone else to join. I'd anticipate that, when we reach a steady state, the number of Trusted people in the Mozilla community would be somewhere between 1000 and 4000.

The aim is that Trusted people should be happy to share things like "address" and "phone number" and other personal details with all others in the "Trusted" group.

(Trustedness may one day become, for example, the basis for access to a set of non-public discussion forums. In this way we hope to dissolve barriers between paid and unpaid contributors to Mozilla.)

Community Contributor Team

The communityteam tag indicates members of the Community Contributor Team. Being tagged this way means you have access to information in the directory which is marked by its owner as available only to that team.

We anticipate that, by default, such information will only be a user's postal address and T-shirt size. And the set of people with this tag will be quite small.