Fedora Telemetry Proposal v2.0

Last year, there was a Change Proposal for Fedora to add Opt-Out telemetry .

Today, version 2.0 of that proposal is out.
I’ve only skimmed through it, but it appears waaaaay more well thought out and reasonable this time. Also more EU-Legal :stuck_out_tongue:

I originally posted this as a reply to this thread (sorry to anyone I might have randomly nudged with a notification), but I figured it wasn’t as directly relevant to the Original Topic of that thread (rather just relevant with latter comments in it) so I deleted it and created a new one for the news.

1 Like

someday, for context, I have to understand how the various rhel/fedora committees operate. I have absolutely no frame of reference for this.
Does the “Proposal Committee” (is there a proposal committee?) meet once a year? What’s the process of getting a proposal before the Proposal Committee? Signatures or something? How many do they get a year? How many do they throw in the trash? How many do they accept? And what if a proposal gets accepted? Off to another committee?

Didn’t Josh do it this way when he got Budgie to be an official Spin, instead of an auxiliary repo package? My point is I wonder what the acceptance rate is? I mean Josh was from the outside. The Day guy proposing the opt-in thing is a Fedora employee.
So the process appears democratic at least.

I need some kind of understanding of rhel bureaucracy & hierarchy then I could make sense of this… Must do my research for sure.

A starting point: https://docs.fedoraproject.org/en-US/program_management/


thank you, reading it now

1 Like

boy all that stuff is a fine line, isn’t it? He says all the want to do is “collect data on which apps are used” which seems legit but check out the 5 categories they seem to go way beyond the quote…
…this goes to the Idea Committee, btw.

edit: I mean this seems like personally identifiable info even w/out the ip address–which they are going to get anyway==then purge that metadata from the data collection. in the wrong hands, however, seems an over-reach.

The link @pebcak offered is nice.
I’d say the tl;dr to most of your questions is probably mostly understanding FESCo

In terms of “how many”, I don’t think there’s a limit (number) to how many can be accepted/rejected. The “owners” of a Change Proposal essentially by submitting the proposal commit to do the required work for it - meaning it’s not merely a “suggestion” but rather an act of volunteering work of sorts - so the assumption is that if a proposal is submitted, someone has planned ahead for the work that would need to be done and deemed the proposal doable by the time of the Fedora Release Target.

Depends how they group and aggregate the data to be fair.
If they keep the records “as-received”, then yeah its probably problematic.

If its liked his quoted words, I agree, it’s fair to see what apps are the most popular and what need to be deprecated because of neglect. It’s smart way to allocate resources and may free up brain power and make good decisions about package management/curation.

But my camera brand? the brands of all my peripherals? # of workspaces used? how often certain windows get opened? HDD/SSD size & brand? memory monitoring? log access: sys crashes, app crashes?
that really smells off-putting.

So, this is exactly why this v2.0 is an absolute success of the community… All of that was “opt-out, enabled by default” in the original proposal (linked on the original post). With this revision, if you don’t want to take part in that, you would have to do nothing, or to be on the safer side simply dnf erase <related_mechanism_packages>

1 Like