On Mon, Nov 4, 2013 at 6:01 PM, Mike Connor <[email protected]> wrote:
> On 2013-11-04 5:29 PM, Majken Connor wrote: > >> In the Thunderbird case, I know other long-time Mozillians who agreed >> with the leaker. Given our values we will always run a high risk that a >> core contributor will think something should be public. The solution to >> this sort of thing is to better communicate what is private and why it is >> private and when it will be public and have a functional process for >> objecting when something is raised privately. >> > > I'm not sure anyone knows what the motivations were for the leaker. It was > going to be public in 72 hours, so it's not like there was much of a moral > argument against secrecy. If the argument is that we shouldn't share with > community ahead of public, I guess I can't really agree with that. > > In your opinion there isn't much of a moral argument, or at least from the perspective you've used to consider this. Be careful to speak for yourself. Openness is very important to Mozilla and there will be people who feel very strongly that we should either be able to do it in the open or we shouldn't. The moral argument is against creating another "in" group but this time dividing volunteers against each other. In my work with Reps I have seen how this type of distinction matters a lot and makes much more of a difference in some communities. > > While we're talking about one kind of abuse - betraying the trust - we >> should also talk about the opposite type of abuse - misusing the trust. >> When something is shared only with this group it should be carefully >> justified each time. >> > > I suspect that the more we have to do to justify sharing information with > Mozillians the less likely it will be that people will share outside of > employees. The goal of having a trusted group is to make it easier to > include larger groups in information sharing. It would be a high-quality > problem for us to give advance notice of too many things to our trusted > community members. > > It can also happen the other way around, and in fact this has happened in Reps. People will default to the most closed circle that they feel information is appropriate for to avoid making a mistake. I am not interested in helping Mozilla shift to being pseudo-open. I would choose that we do things in the open or we don't do them at all. Process and information make a huge difference. It's also not that hard to handle once an effective policy is drawn up. I'm not sure anyone would complain that having clear understandable guidelines on when to use that group would be bad. How do you propose we hold people accountable then? Accountability was a key value in the culture pulse, as was openness. We shouldn't be hiring people that aren't interested in being accountable to Mozilla's core values, we shouldn't be supporting habits or behaviours that are counter to them. > > Reps sign NDAs, maybe we can have some sort of formal agreement in this >> case as well that touches on the appropriate use of this trusted >> communication group. >> > > Legal overhead is a pain for commit access, I'd like to avoid that unless > we intend to share broadly without subsequent public disclosure. Given > that NDAs are typically constrained to employees only (and changing that > would be extremely hard with most partners), I can't see that being common > enough to do any of this. > > -- Mike > Well, Reps aren't employees. You can see the agreement Reps sign by finding the link "Mozilla Reps Agreement" here - https://wiki.mozilla.org/ReMo/SOPs/Mentoring/Orientation I also didn't suggest an NDA specifically. It could be like Terms of Service you agree to when applying to be in the group, or rules that you acknowledge you are aware of and pledge to follow. The most fun issues to moderate are always the ones when someone claims they didn't know they were breaking the rules. _______________________________________________ governance mailing list [email protected] https://lists.mozilla.org/listinfo/governance
