Hello Domen,

Is there a policy in place when it comes to telemetry in nixpkgs ?

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/should-commercial-actors-ship-telemetry-in-nixpkgs/60279/1

I find it objectionable that Domen with a clear conflict of interest reverted this PR, and he shouldn't be allowed to make changes to telemetry of this package in the future.

you should always ask the end user if they agree with any telemetry.

I think that it's alright to have telemetry by default.
Many apps in nixpkgs do it anyways, and not that we are some sort of security-oriented distro.
There were several cases when packages were modified or retracted on request of an author.

But apparently, when an author of an open-source tool wants to have telemetry enabled by default in a package he maintains, it's some sort of a crime.

I do not understand this nonsensical 👎 spam by community on Domen.
If you don't like devenv — just go ahead, create devenv-notrack packaging, and maintain it, or something.

Or better off, create an issue in devenv repo, giving Domen insight on how everybody hates AI and doesn't want their data collected. (I think it is only collected when you use AI features..?)

Or try pitching for a checkbox "Do not track in console" on NixOS installation (As Firefox did) (And devenv supports https://consoledonottrack.com/).

I think that it's alright to have telemetry by default.

That’s your personal preference, which is fine, but it’s not the point of discussion here.

Many apps in nixpkgs do it anyways, and not that we are some sort of security-oriented distro. There were several cases when packages were modified or retracted on request of an author.

If some packages are doing it, then that’s a mistake that should be addressed, not a justification to allow more of it.

But apparently, when an author of an open-source tool wants to have telemetry enabled by default in a package he maintains, it's some sort of a crime.

No one is calling it a crime, but you. We’re all human, and mistakes happen. Most of us here are trying to find a reasonable solution. Let’s avoid misrepresenting each other's arguments.

I do not understand this nonsensical 👎 spam by community on Domen. If you don't like devenv — just go ahead, create devenv-notrack packaging, and maintain it, or something.
Or better off, create an issue in devenv repo, giving Domen insight on how everybody hates AI and doesn't want their data collected. (I think it is only collected when you use AI features..?)

Again, this isn’t about AI or data collection in general. The concern is about telemetry being enabled by default. Personally, I don’t have strong opinions on what devenv does or not. What matters to me is that users should have a choice when using nixpkgs.

Or try pitching for a checkbox "Do not track in console" on NixOS installation (As Firefox did) (And devenv supports https://consoledonottrack.com/).

That sounds like a reasonable potential solution. Maybe that’s something we could explore in the future.

That’s your personal preference, which is fine, but it’s not the point of discussion here.

Whether you like it or not, not providing data is also a preference.

If some packages are doing it, then that’s a mistake that should be addressed, not a justification to allow more of it.

This is not an official Nixpkgs policy — yet. You can, of course, propose it — and I will support it. Probably we will even come up with some sort of marked as telemetry-enabled, or even just steal the list of unwanted features from Fdroid.

No one is calling it a crime, but you. We’re all human, and mistakes happen.

I don't see how this is a search for a reasonable solution. All I can see is 40 downvotes on a long time contributor for reverting a change on a package he code-owns and develops.

The concern is about telemetry being enabled by default.

Well, then the solution lies in governance, and not in putting pressure on Domen for reverting a change to his package?

There were several cases when packages were modified or retracted on request of an author.

There were also several cases where the upstream was explicitly told that we do not agree with what they say and their requests were refused.

However, as a package maintainer in Nixpkgs, with overall contribution track record far exceeding just the packages with own upstream involvement, Domen Kozar is clearly in the right to quick-revert a change to a package where waiting to maintainer reaction did not happen at all.

Even if we later get a policy that switching off telemetry is like fixing bugs and supposed to be accepted, not waiting for maintainer's technical review on whether it is done correctly would still need a strong and clearly articulated reasons.

(I would be moderately in favour of a policy that explicitly says that switching off telemetry is a should-be-accepted improvement, subject to quality review, and with opt-in to telemetry also being a should-be-accepted improvement on top; but not strongly enough to write an RFC on that)

blah blah

Yes, sure.

The concern is about telemetry being enabled by default.

Well, then the solution lies in governance, and not in putting pressure on Domen for reverting a change to his package?

There's no pressure on him. This PR showed that the "do not track" issue is not (yet) handled in nixpkgs and needs some adjustments.

blah blah

Not nice.

There's no pressure on him.

I have outlined what I've considered pressure, and there's literally a quantifiable amount of it.

This PR showed that the "do not track" issue is not (yet) handled in nixpkgs and needs some adjustments.

Yes.