dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.6k stars 1.03k forks source link

Respect `DO_NOT_TRACK` as standardized alternative to `DOTNET_CLI_TELEMETRY_OPTOUT` #3917

Open khellang opened 4 years ago

khellang commented 4 years ago

DO_NOT_TRACK is a proposed unified standard for opting out of telemetry for TUI/console apps. It would be nice if the dotnet CLI followed the same standard. See https://consoledonottrack.com/

fowl2 commented 3 years ago

It seems like this has been denied. https://github.com/dotnet/sdk/pull/17472#issuecomment-855087362

Extarys commented 6 months ago

A year and a half later, any update on using this? I feel like it's a standard now on many OSS.

marcpopMSFT commented 3 months ago

Coming back to this, we reviewed the original effort and it doesn't appear to have been picked up broadly so we're going to continue to hold off for now.

coopbri commented 1 week ago

I respect the concern for the lack of widespread usage. With that being said, adoption by an entity such as Microsoft would likely be a monumental step towards such public usage, and it seems to me like this would not only be a straightforward implementation in the .NET project, but a well-received publicity and marketing measure for .NET and Microsoft as a whole. Considering there are 125 upvotes at the time of writing on the OP in this issue, and the lack of other well-known console opt-out standards (please correct me if I'm wrong), I am curious what is desired by the .NET team to move this budding community effort into the SDK. I believe as a general technology community (beyond .NET), we should combine efforts to hone in on standards such as what was done in hardware with e.g. USB. Despite the claim that there is no broad adoption, there certainly is a meaningful amount of it. Perhaps there is simply a lack of marketing and awareness; I argue that the idea itself has merit.

I would be curious to hear concrete adoption hesitations. I noticed the denied PR (#17472) supports both the existing opt-out strategy (bespoke env var), as well as the standard one and simply checking for either, but I don't see clear rationale for denying it.

EDIT: Just noticed https://github.com/dotnet/sdk/pull/17472#issuecomment-1175591096 which echoes my thoughts

khellang commented 1 week ago

Considering there are 125 upvotes at the time of writing on the OP in this issue

It's the #⁠2 most upvoted issue in this repo 😅