Add a SUPPORT.MD

[JonDouglas]

There is no link out to the support policy of .NET from the dotnet/runtime repo that I could find. A quick addition of a SUPPORT.MD may be beneficial here so when people file issues, they can see the "Support" link on the sidebar in addition to a location somewhere on the README.md:

https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/adding-support-resources-to-your-project

Contents of the file can say something like:

## .NET Official Support Policy 

For detailed support policies related to the various technologies within the .NET platform, please refer to the [.NET Support Policy](https://dotnet.microsoft.com/en-us/platform/support/policy).

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

[jkotas]

cc @richlander

[jkotas]

[.NET Support Policy](https://dotnet.microsoft.com/en-us/platform/support/policy

This link is specific to Microsoft distribution. Should it rather be a link to https://github.com/dotnet/core/blob/main/support.md that covers the different distributions (including the Microsoft one)?

[richlander]

Related: https://github.dev/dotnet/core/pull/9364

I've been revising our support statements for several years now. I started with a sort of "proprietary mindset" where I/we elevated Microsoft above everything else. That both made sense and did not at the time. Over time, I made Microsoft and other folks like RH and Canonical kindof the same but documented them separately. Now, the doc leads with community support and then documents all the organizations that provide commercial support, all in alpha order. I'm much happier with this.

[terrajobst]

I'm not opposed to having a SUPPORT.md in the repos, but it feels strange to me to use the repo as the primary mode to point people to the support policy.

For the runtime/setup it makes more sense to go from the download location (which is dot.net) and for OOBs (mostly NuGet) it would make more sense to come from the package.

The repo isn't a useful unit for the customer as some artifacts span multiple repos and repos often produce multiple artifacts. For example, dotnet/runtime produces the .NET runtime but also many of our OOBs which will have different support statements and lifecycles (runtime is STS/LTS, OOBs are usually "tip only" or unsupported).

[richlander]

We worked together to update our policy on packages a few months ago: https://github.com/dotnet/core/blob/main/release-policies.md#end-of-support. It would be good to start with validating this support statement. It would be good to validate the whole file, actually.

[JonDouglas]

I don't have any strong opinions here / much more to add. I just noticed there was a missing link to get to a support policy of some kind and figured this mechanism might be beneficial in this repo (and other .NET repos) alongside adding it to the READMEs where it makes sense.

There seems to be three major support pages and I'm curious if we should try to consolidate them, so it is easier to link to a single policy and update it over time:

https://learn.microsoft.com/en-us/dotnet/core/releases-and-support
https://github.com/dotnet/core/blob/main/support.md & https://github.com/dotnet/core/blob/main/release-policies.md
https://dotnet.microsoft.com/en-us/platform/support/policy

The GitHub policy seems to include a lot more prescription/best practices, but the dotnet page seems to be more official / searchable. I don't have a strong opinion on what the link should be, just that there should be a link!

I do also believe that .NET packages could incorporate their support policy in their package READMEs which could link to an anchor section of a centralized policy regarding "tip only" or unsupported. Similar to what we did last year w/ many library READMEs i.e. https://github.com/dotnet/runtime/blob/main/src/libraries/Microsoft.Extensions.Configuration.Binder/src/PACKAGE.md

[richlander]

A step towards consolidation could be good. We have multiple docs to accommodate the difference between project vs product and instruction vs policy. Also, docs users probably prefer to stay in docs, for example.

Microsoft pages can certainly link to GitHub for detailed information as the GH pages are the source of truth, whereas GH to MS should be done sparingly. A proposal (should one want to make one) on streamlining MS properties should be best made on their trackers.

If repos want to add a support.md, it should probably link to: https://github.com/dotnet/core/blob/main/support.md