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
