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 > _______________________________________________ governance mailing list [email protected] https://lists.mozilla.org/listinfo/governance
