On 06/11/13 17:32, David Bruant wrote: > No, they're not. As described, they're "privileges". They're > consequences of the solution being chosen, but the problem isn't > anywhere described. > Why do we need to build a trusted subgroup of Mozillians to gain access > and discuss sensitive non-public Mozilla information?
Because there is such information and it's already discussed, but the "trusted subgroup" is /de facto/ defined as "employees". However, this split widens the division between employees and volunteers and is community-corrosive. I would much prefer that e.g. discussions about ideas to deal with EME were able to happen with a larger group than just employees. > Why do we need to build a trusted subgroup of Mozillians as an easy > alternative to MoCo employees that people can go to with non-public stuffs? > Why do we need this new subgroup to get an @mozilla.org address? My assertion is that an @mozilla.org address is something we want to be careful about handing out because it means someone is, in some way, representing or is trusted to speak by the Mozilla community - at least, that's how people will interpret it. I think that the model proposed here is a good way of defining a set of people who might be trustworthy enough not to abuse the privilege. You can dispute that link, of course, as David Ascher has. Which is fine. I am happy to admit that the discussions use case is my primary driver; if we end up going a different way with email addresses, then we go a different way. > What does the creation of this group create that wasn't possible before? > What is the problem we want to solve? Why is this new subgroup a > solution? What are the other possible solutions? If we want to have discussions among a group larger than employees and smaller than the general public, then we need some mechanism for defining that group. This is my proposal, along with its rationale (i.e. I think it encodes existing trust relationships quite well). Other proposals are very welcome. > I feel like a solution is being rushed and implementation details are > being discussed almost up to bikeshed while the problem hasn't been > clearly stated. I don't see anyone rushing here. This discussion is very much ongoing. > In my experience, such a group and the related privileges haven't been > needed. Maybe it's just me. But your experience wouldn't show the need, because by definition as a non-employee you don't get to hear about any of the things that a larger group might discuss, so you aren't aware they exist. :-) > It might be more appropriate to create "focus groups" in a case-by-case > basis. > For instance, create an EME focus group with the relevant employees and > community members. And it'll be different than the business model focus > group, etc. Someone can certainly propose the alternative that someone with something to discuss should construct their own trusted group. However, my assertion is that a) this is possible today, and lots of people just default to "employees" because it's safe and easy - defining your own group takes work, and if it goes wrong, you get it in the nexk. Also b): we want to be as open as possible; allowing people who are trusted but not directly involved at the moment to read and observe what's going on mirrors, in the slightly-more-closed realm, how people get involved in stuff in the open realm. Gerv _______________________________________________ governance mailing list [email protected] https://lists.mozilla.org/listinfo/governance
