I think we might be closer to consensus than it seems. I note that I see no one objecting to the existence of the module, but the potential implementation.
As I understand it, bsmedberg's module will split the responsibilities between Legal/Privacy group, and the module. I understand that somewhere this is a draft of what this split between approval(Legal/Privacy group) and implementation (Data Collection Module) might look like. The module (owner/peers) are responsible for reviewing patches and ensuring they meet our established privacy policies in practice. Privacy/Legal's role is to set the wider direction & policies about what we should do, in a sense as the 'product managers' of the Data Collection Module. One of the module peers/owner responsibility is to know when a proposed patch falls outside of implementation correctness & concerns and into the product-policy side. We expect existing modules owner to consult the product folks when needed. I also understand that module owners may designate a specific reviewer for bugs that is a not module peer if that's the best person for review. So we wouldn't need to name peers immediately, just the owner. We can then follow the ramp-up to full peership that most modules follow (for a good reason). (For those not familiar with that, one usually does a large number of reviews in a module, looked over/backed by by the other peers and the owner, before peership is conferred.) Before we argue too much about who should be a peer, let's get the module established, and get things moving. I suspect the work that results will teach us about what we need in peers and how many we might need. Until then, the module owner, as the ultimately responsible party, will be expected to determine who is best for a particular review. With respect to metrics, I also imagine that Jon Jensen can hold the module owner accountable for a number of things, and that will be very helpful for the metrics team. -- Allison ----- Original Message ----- From: "Laura Thomson" <[email protected]> Cc: "Taras Glek" <[email protected]>, [email protected], "Brendan Colloran" <[email protected]>, "Benjamin Smedberg" <[email protected]>, "Mike Connor" <[email protected]>, [email protected], [email protected] Sent: Monday, August 18, 2014 2:24:56 PM Subject: Re: New governance module proposal: Firefox Data Collection As an aside, I pinged Benjamin to suggest that someone from crash-stats should probably be a peer on this, since FHR, Telemetry and crash-stats are the three big data collection pieces. He had some arguments against that, which I'll let him explain. Given the conversations around data at the moment, I'd suggest more peers rather than less is likely to be a Good Thing. -Laura ----- Original Message ----- From: "Brendan Colloran" <[email protected]> To: "Mike Connor" <[email protected]> Cc: [email protected], "Taras Glek" <[email protected]>, [email protected], [email protected], "Benjamin Smedberg" <[email protected]> Sent: Monday, August 18, 2014 4:34:31 PM Subject: Re: New governance module proposal: Firefox Data Collection Please note that John Jensen is away on vacation for the next two weeks. He will surely have thoughts on this proposal. For my part, I tend to agree with mconnor that decoupling the approval and implementation processes seems like the right way to avoid conflicts of interest. While I agree that having clearer ownership and accountability around data collection and data quality would be very helpful, I think Mike's concerns are justified. -Brendan Colloran ----- Original Message ----- > From: "Mike Connor" <[email protected]> > To: [email protected], "Benjamin Smedberg" > <[email protected]> > Cc: [email protected], [email protected], "Taras Glek" > <[email protected]> > Sent: Sunday, August 17, 2014 10:32:55 PM > Subject: Re: New governance module proposal: Firefox Data Collection > > So, my initial take here is that I’m concerned about this from an oversight > and governance standpoint. In general, I try to lean toward checks and > balances, especially around anything with a privacy aspect. If the person > responsible for delivering answers based on data is also the person acting > as gatekeeper for which data we collect, that feels like an inherent > conflict of interest on a structural basis. Adding peers doesn’t really > solve this problem for me, since I believe an owner should be able to make > decisions within their sphere without needing a committee. Where there are > conflicting mandates, splitting those mandates and requiring > discussion/negotiation is the best solution I can imagine for that. > > Were I constructing this from scratch, I would separate the technical and > approval pieces, and have separate owners for each who have to work together > to keep things in balance. I agree that the overall problem needs clear > ownership, but I want to make sure we’re finding the right compromises, and > compromises are always difficult to find in one’s own head. > > Having suggest that, I’d go further and suggest that Mozilla, as an > organization, should have a consistent policy and application of that policy > across products, but the technical requirements and implementation details > are, by necessity, going to differ significantly, so we might have one > gatekeeper group for the org, with technical leaders for each project/group. > > I’m not going to nominate people, since I think we should decide what form of > oversight we want, and then pick the right people to fill those roles (at > least as much as possible). > > — Mike > > On Aug 15, 2014, at 3:43 PM, Benjamin Smedberg <[email protected]> wrote: > > > For a while, there hasn't been a clear decision-maker about data collection > > practices within Firefox. This includes lack of clarity about who needs to > > approve changes to Firefox Health Report, as well as uncertainty about > > what privacy review means and who can "do" a privacy review. To clarify > > this and streamline the decision-making process, I am proposing to own a > > policy module for this: > > > > Policy Module: Firefox Data Collection > > Description: Firefox Data Collection is responsible for the data that > > Firefox sends back to Mozilla. This includes reviewing both data quality > > and privacy, and approving new types of pings and measurements. This > > encompasses measurements included in the current Firefox Health Report, > > Telemetry, and crash-stats, as well as other data that Firefox sends back > > such as update and blocklist pings. > > Owner: Benjamin Smedberg > > Peers: Taras Glek > > More information about decision-making: > > https://wiki.mozilla.org/Firefox/Data_Collection > > > > I'm specifically limiting this to Firefox; it does not include Firefox OS. > > I think Firefox OS should have a clear decision-maker about its product > > data collection, but I am not that person. > > > > I am open to suggestions/nominations for additional peers. > > > > --BDS > > > > Followup to the governance list, please. > > > > _______________________________________________ > > fhr-dev mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/fhr-dev > > _______________________________________________ > fhr-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/fhr-dev > _______________________________________________ fhr-dev mailing list [email protected] https://mail.mozilla.org/listinfo/fhr-dev _______________________________________________ dev-privacy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-privacy _______________________________________________ governance mailing list [email protected] https://lists.mozilla.org/listinfo/governance
