Contribute/Trusted

This is a proposal for a social mechanism (informally known as the 'Family Responsibility system') to create a trusted subgroup of Mozillians. Possible privileges for such a group include:

• Gaining access to and the ability to discuss sensitive non-public Mozilla information
• Being an easy alternative to "MoCo employees" that people can go to with non-public stuff
• Getting an @mozilla.org email address

However, only one use case is needed for this mechanism to be deployed; if e.g. we go a different way for @mozilla.org email, this mechanism is still required.

This page is focussed on the social means for creating such a group. How we technically create a forum for such discussion, and access to it, is an implementation detail (but access control would probably involve mozillians.org).

My core contention is that such a group needs to be an encoding of existing trust relationships, with a high bar, and we need to work out how to do that with minimum administrative overhead and maximum fidelity.

The Plan

We seed the group with, say, twenty or so people whose status as Mozillians is beyond doubt. (It doesn't really matter which 20.) We then say that anyone else can be admitted to the group if they are endorsed (I won't say "vouched", as it leads to mixup with the mozillians.org mechanism) by X existing members (proposed X: 2). And within the first N months (proposed N: 12), if that person is found to have broken a confidence or otherwise behaved in a way which leads to loss of privileges or access, the X people who vouched for them also lose those privileges, for a period of M months (proposed M: 3). Hence, 'Family Responsibility' - "if you let us down, the shame falls on you and your parents".

This makes endorsing someone as 'trusted' an action with real downsides. This is intentional, because it is the only way to ensure that endorsements will be carefully considered, and people only endorse people they actively trust. Compare this with mozillians.org vouching. If I vouch for someone in mozillians.org and they later act highly inappropriately, nothing bad happens to me. There's no downside to me simply vouching for anyone who asks, which makes it very easy to get vouched for. In order to build a real web of trust, we need to change that. If I put something at risk by endorsing someone, then I will only endorse people who I trust already - i.e. the group becomes an encoding of existing trust relationships, which is the aim.

Who Can Endorse?

It is important that people are trusted across the entire Mozilla community. It would be wrong for a new volunteer no-one had ever heard of outside one tiny micro-community to arm-twist two of his mates into endorsing him, and it would be wrong for an employee who had no community profile or interaction history to simply get endorsed by his manager and a co-worker. So I propose that one of the endorsers needs to be an employee, and the other a volunteer. (Assuming X = 2).

This has some advantages; however, a disadvantage is that if the set does not necessarily include all employees, then it might not do a good job of meeting the "easy alternative to MoCo employees" use case, and therefore some things may end up still being shared only inside MoCo which don't need to be.

Probation Time

It was suggested that there should be a time period before people could vouch for new members. The upside is that it gives people a chance to absorb community norms, and prevents a quick degradation of the trust model if there is a single breach. The downside is that it would significantly delay rollout during the bootstrapping period. So I propose that we start with no bootstrapping period, but introduce one after a period of time.

Auto-Expiry

It was suggested that trusted status could auto-expire every year, renewable with an email click. This has the advantage of encouraging people to regularly consider whether they are still an active core Mozillian. However, some privileges (e.g. an @mozilla.org email address) may not expire - that's TBD. So perhaps it's better if trusted status does not auto-expire, but some privileges (e.g. forum access) do, separately.