dotnet
Add basic guidelines for telemetry usage for tooling authors
If a component is shipped in the .NET SDK, then any telemetry it sends should be included in the documented data points, right? That should also probably be mentioned in this doc.
This is more about random MSBuild SDKs and NuGet Packages - I had some internal teams reach out to me about how to integrate their telemetry with the SDK and we explicitly do not want that kind of integrated telemetry, but I didn't have a doc to point to. I'd expect other teams to have their own telemetry declarations that they need to stay on top of.
Thanks for the notes Yanni - applied them, I'll merge this once the builds finish
@baronfel Anyone forking and building this repo would automatically end up with the MS privacy policy links, etc. Do we need to clarify that someone that forks, builds and redistribute their own copy of the SDK should not only change the telemetry model, but probably also replace the privacy policy links with their own. We should probably also check whether it's possible to add additional policies, e.g. if some adds a new SDK or tools that are governed by a more specific policy than our general one. We've had really specialized EULAs before that were extremely specific and I wonder if that's true for privacy policies too.
@joeloff maybe? It seems like that would be part of a greater "build your own SDK" checklist, and that list would be better served being located at the place where the SDK constructions actually happen - e.g dotnet/source-build or dotnet/dotnet. What do you think?
@joeloff maybe? It seems like that would be part of a greater "build your own SDK" checklist, and that list would be better served being located at the place where the SDK constructions actually happen - e.g dotnet/source-build or dotnet/dotnet. What do you think?
Yes, a more central place would make sense for that case.