It’s no secret that there is a MoCo-internal meeting, currently held once a month. Gary Kovacs (MoCo CEO) explains it as being a place to discuss things which are not relevant to the wider community, like office configuration. This month, the topic of the Thunderbird leak did come up, and Mitchell said that a) we should try and help the person who did this understand how harmful it was, and b) we need to continue to try and find ways to safely share, to a group wider than “employees”, information which shouldn’t (yet) be made public. For a), see my previous blog post, actually posted just before the meeting. Here are some thoughts on b).
The leaked email was sent to everyone in the Mozilla Community Directory (Phonebook) who is “vouched”. What exact responsibility you are taking on when you vouch for someone isn’t clearly defined (that I can find), but the Contributor Engagement team is very keen that anyone who is a new or even a potential contributor to Mozilla creates a profile there as soon as possible. And if one of the purposes of the Phonebook is to get metrics about the size and interests of the whole community, that makes good sense.
When I designed the predecessor project to the phonebook, Domesday, it had a system of user tags, some of which had to be bestowed on people – you couldn’t award them to yourself. One tag I envisaged was called “trusted” – a group narrower than “having an account and being a community member” but certainly wider than “employee”. There were heated arguments during the design phase about whether such a thing was even necessary.
I think this incident proves that it is. It’s not possible for one “vouched” marking to both serve as “member of the community” and “trusted member of the community”. Phonebook needs to grow the technical ability, and Mozilla needs to grow the social processes, to mark people as trusted, with a mechanism for the person who incorporates them into the trusted community to be known and held accountable for their conduct. And no free passes – start with Mitchell and Brendan as trust roots, and employees need to find someone who will publicly put trust in them, just like everyone else. (The free pass for employees was, IMO, a significant and unnecessary inequality in the Mozillians vouching implementation.)
Trustworthiness is not something that can be programmatically determined, and it is not related to project activity or long service. This is a human problem. We need a mechanism to identify who is trusted and who is not, because only then will we be safely able to distribute stuff that shouldn’t be public wider than “MoCo-only”, and break down the employee/volunteer barrier.
(Some may want to argue that the category of “stuff which shouldn’t be public” shouldn’t exist at all within any part of Mozilla. I think a little thought will reveal that this can’t be so; there are plenty of legal, diplomatic, and partner-related things where publication would damage Mozilla’s interests. Not to mention, on occasion, people’s real opinions of industry developments.)
This reminds me of the old Advogato trust metrics, maybe with a different granularity.
>Some may want to argue that the category of “stuff which shouldn’t be public” shouldn’t exist at all within any part of Mozilla
There is a difference between “stuff which shouldn’t be public” and “stuff that should be shared with a generic ‘trusted’ pool of contributors, but not with the whole community”.
You provided examples falling into the former category (things like dealing with partners, NDA-covered information, etc.), but not of the latter.
In particular, neither the “internal” Thunderbird announcement, nor any of the discussion I’ve seen after the leak explains why it couldn’t be handled like any other change: post a proposal to a public mailing list, discuss, come to a decision, announce it. (Note: I’m not arguing that leaking the memo was OK.)
Or, to put in another way, given that this couldn’t be discussed in public for whatever reasons, why there was a need to share it with a pool of ‘trusted’ contributors before the announcement?
I guess my point is that the ‘trusted’ bit shouldn’t be generic, it should be related to a particular activity, like ‘signed NDA with X’, ‘trusted to handle legal discussions of Y’.
(Bonus openness points for making the list of private lists publicly available with a short description!)
You can’t usually have “have a discussion in public” and “announce” be separate steps, particularly for a decision of that magnitude. We don’t currently have very good formalized ways of “bubbling out” this kind of information – the existing tools we have (MoCo-only forums, mozillians mailing list, newsgroups) are rather crude and each have their flaws (for mozillians, it’s clearly the one-way nature of the list, and perhaps too large of an audience to be useful for this kind of thing).
I was formulating my comments while reading, and the result was that it seems we should ask, “What information exists that we want to share with non-employees that we want a wider public not to see?” and “Why?”
Your addendum tries to pre-emptively deal with this, but Nickolay’s right in that there are separate classes of things here, where you give rationale for one class, and that class seems to need the least explicit rationale, since, as you say, it’s largely self-evident.
I still think these questions are good to ask. Perhaps if this sort of toolset used to keep things in check goes into practice, it should be extended for self-awareness: “So there are some things we want less public [assuming some rationale is given for the class of things that aren’t self-evident]. Has our use of the restricted labels recently made it so that our instincts now are to reach for them first, even for things that we wouldn’t have in the past?”
Surely that depends on the discussion. If you’ve gone into the discussion with an open mind, then there’s nothing to make public at the point of the discussion. However if you’ve gone into the discussion to bring everyone round to a predefined opinion, then of course, it’s quite possible for someone to “jump the gun” and leak “Mozilla plotting to kill off Thunderbird”.
* Please note: I don’t think the leak was big or clever and in fact only found out about it after the hoorah. When I got the email, I simply made it apart of my days to the refresh the planet several times.
I’m not sure if it’s so much the information that needs to be “semi-private”, or rather the discussion. People want to be able to discuss controversial ideas, without having the whole IT world link to the discussion and pile on.
Over the weekend, I was convinced that the Thunderbird announcement was a huge strategic error, as it was widely interpreted as the demise of Thunderbird, and yet there was insufficient warning for the community to get organized prior to the announcement. Yet today I am seeing that the shock of the announcement itself is help to motivate a community of contributors that is starting to gel around Thunderbird, so maybe a shock announcement wasn’t so bad after all.
But concerning restricted discussion forums, I’ve never seen that work, as if the topic is sensitive then nobody will use it except the person who controls the list, as people want to know everyone who will receive a sensitive message before they send it. JB used a small private email to pre-announce these changes to a few selected key non-employees, and I think that was appropriate. Not everything (particularly human interactions) can be automated and systematized.
Good questions.
As Kadir says below, people want to be able to discuss controversial ideas (e.g. “I think we should change our stance and ship H.264”) or express their true opinions (“Browser Maker X’s current ad campaign is really weaselly”) without it appearing on the front page of TechCrunch. A lot of the sort of thing currently goes on between just the employees. And it’s precisely this sort of candid discussion which builds relationships and community between the participants. And so the result is that the employees feel closer together, and people not in that category feel further away.
Has our use of the restricted labels recently made it so that our instincts now are to reach for them first, even for things that we wouldn’t have in the past?”
We would need to keep an eye on it; but the fact is that this type of discussion is already restricted – to employees only. I’m not sure it can be eliminated, but what we can do is make it not an employee/volunteer thing, which would be a big improvement.
Unfortunately some of this is self-reinforcing. If influential MoCo people don’t express opinions in public which they don’t then turn into project decisions, then whenever they express an opinion, it’s defacto a news story.
It’s tough for many people to express an opinion and be turned around in a private employment setting. It’s even harder when that makes ‘news’. However, in my experience, it’s an inevitable part of truly open projects.
You’re never going to persuade ‘tabloid’ news not to run a not-fully-formed thought from someone important, but I’m optimistic that reputable new sources could learn to understand the process.
Is there a particular reason this has to be delimited by employment status? I’d in fact be happier if there was a mailing list, much like security@, where the existence of the list is known but the membership is private; the key point would be that it isn’t based of employment, since that naturally makes non-employees feel left out for no reason. In fact, drivers@ is already this list, isn’t it?
(Note that this doesn’t solve the problem of people-in-the-list needing to convince the rest of the world this is a good idea – it just takes away the extra strife caused by employment.)
If it’s for non-driver-like discussion: what makes it impossible for _that_ mail to be forwarded outside MoCo, anyway?
“Is there a particular reason this has to be delimited by employment status?”
Only for the reason that we are discussing – that there is currently no way of enumerating and recognizing trusted non-employed Mozillians.
For me, it’s really all about the appearance of an extra privilege – non-employees have to earn their trust, but employees get blanket access on day one. To me that goes against the whole meritocracy thing that’s been waved around. Sure, all it does it hurt people’s feelings, nothing actually concretely damaging… except for community management. It’s not even something you need to be doing; it’s just an artificial barrier for people like me to feel engaged.
Pingback: More Evidence of the Need for a “Trusted Mozillians” Forum | Hacking for Christ
Hi gerv,
Thanks for the explanation. I appreciate your continued efforts on keeping Mozilla open, thank you!
Trust “easy” way: people that signs a legal contract with mozilla (legal responsability)
Trust models: http://www.pgpi.org/doc/pgpintro/#p20