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.
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. 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. On Mon, Nov 4, 2013 at 5:04 PM, Mike Connor <[email protected]> wrote: > > > On 2013-11-04 4:20 PM, Fred Wenzel wrote: > >> I like the proposal, largely. >> >> One question I have is around the endorsement by one employee, one >> volunteer. I do like that, because the simple fact of getting hired by >> MoCo does not make you a trusted Mozilla contributor -- though ideally >> the people hiring you are trusted, and thus take the risk of extending >> their trust to you by hiring you seriously, giving the new hire an >> assumption of trust that they hopefully fulfill soon after. >> >> So, what will it take for a new employee to get to that point of being >> a trusted Mozillian? How long do we assume that'll take? And what >> practical implications does the state prior to that (person is on >> payroll, but not a trusted Mozillian) have? >> > > I think we've had a pretty substantial go-round on employment-related > vouching for commit access (which is as big or bigger of an issue), and > we've long since concluded that trying to gate inclusion based on > employment status is a highly flawed process. This was best exemplified by > the fact that Christian Biesinger was (by procedural necessity) the SR > voucher of record for the vast majority of commit access requests over a > few years. If a Mozillian is trusted to the extent that two others will > put their rep on the line for that individual, that's enough for me. > > Dirkjan raised a question of an endorsement limit. I'm not sure that's > necessary here for the same reason: vouching is placing your ability to > vouch on the line. If you are making good decisions, there's no reason to > limit you from doing so. If you're making bad decisions, we shouldn't slow > you down, we should simply take that power out of your hands. > > > So in order to make the trusted group really useful for some of the use >> cases, do we need to include employees by default, but to remain on the >> list when your employment status ends, you'll have to also be endorsed >> at that time? >> > > Again, I think we've crossed this bridge with commit access. Employment > doesn't grant commit access, ending employment doesn't revoke it. There's > obviously a case where if something goes really badly there would have to > be a revocation of access on practical grounds, but that's rarely been the > case. > > That said, I think there's a very real question about revocation in cases > where trust has been broken. I think it's clear that if we're going to use > the "trusted" bit to share important information with Mozillians in > private, we have to be able to revoke that trust. Mike Hoye cited the > Thunderbird announcement as an example. I don't know who was behind that, > but if we did, I would expect that individual to lose their trusted status > as a natural consequence. > > Even thornier is the case where an individual commits a breach in a > non-public way, which for legal/ethical reasons we can't disclose publicly. > How can we revoke trust in this case? > > > I'd like to find a sufficient answer to this point to ensure the >> proposed system will actually be useful and not go unused in favor of >> employees-all for fear of missing important people when announcing >> things. >> > > Ultimately I think we'll end up posting important information to both > groups, since it's all but certain that not all employees will self-select > into the community. That's not ideal from a purist sense, but it often > takes time for outsiders to fully commit even though they've been hired. > > -- Mike > > _______________________________________________ > governance mailing list > [email protected] > https://lists.mozilla.org/listinfo/governance > _______________________________________________ governance mailing list [email protected] https://lists.mozilla.org/listinfo/governance
