Skip to content

Merge moniker docsets into a single docset #2065

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
adegeo opened this issue Apr 8, 2025 · 2 comments
Open

Merge moniker docsets into a single docset #2065

adegeo opened this issue Apr 8, 2025 · 2 comments

Comments

@adegeo
Copy link
Contributor

adegeo commented Apr 8, 2025

Right now we have the .NET Framework version of WPF and WinForms contained in one directory, and the .NET version in another. Redirects are filed between the projects to allow people to swap between the technologies.

The content in .NET Framework is generally good enough to help someone working in .NET. The docs aren't presented this way, though. When a user is viewing something on .NET Framework, and decides to use the moniker switcher to change to .NET 9, if that article doesn't exist, the user is brought back to the same article in .NET Framework with a little banner at the top that says the page doesn't exist. This is confusing.

I propose that we merge the experiences back together and...

  • Keep the new getting started articles for .NET and get rid of the old ones.
  • Rework the TOCs, deleting old .NET Framework articles where there is a conflict.
  • When things need to be called out for .NET Framework and .NET, do so. Tabbed content can help.
  • Look at migrating the overview pages to become the root landing pages for sections (get rid of the link farms)
  • Old walkthroughs need to be moved to an archived section and called out on top, until they're migrated.
  • Screenshots and Visual Studio instructions should always present VS2022.

One other thing to note is writing style. Microsoft's writing style isn't as formal as it was 10-15 years ago when the .NET Framework content was written. New articles are straight to the point and use a more relaxed style. Articles in the content set will greatly differ after the merge.

One thing I'm not sure of is reporting. Currently this docset uses two services: dotnet-desktop and dotnet-framework. These were used to differentiate the new content from the old, where the focus was .NET and the older content lived under a different SLA. I propose these two services remain. As content is copy-edited and rewritten for .NET it moves from one service to the other. Eventually the .NET Framework service area would be trimmed down. Content rewritten in the new style can still talk about .NET Framework, but by moving to the dotnet-desktop service area, it indicates that it's fresh and follows the latest style guide.

@KlausLoeffelmann @merriemcgaw @MelonWang1 @Tanya-Solyanik

Related issues (which I'll close and use this one to track)
#2015
#1915

Tagging others who've commented
@BPowell76 @Prologh @siimaus


Associated WorkItem - 419052

@KlausLoeffelmann
Copy link
Member

Fully support this and would offer to help where time allows, certainly with reviewing!

@dotnetrepoman dotnetrepoman bot added the 🗺️ mapQUEST Only used as a way to mark an issue as updated. RepoMan should instantly remove it. label Apr 8, 2025
@dotnet-policy-service dotnet-policy-service bot removed the 🗺️ mapQUEST Only used as a way to mark an issue as updated. RepoMan should instantly remove it. label Apr 8, 2025
@adegeo adegeo self-assigned this Apr 8, 2025
@adegeo adegeo added the 🗺️ reQUEST Trigger label to import an issue into Quest label Apr 8, 2025
@merriemcgaw
Copy link
Member

Count me in!

@sequestor sequestor bot added 📌 seQUESTered Label to indicate an item has been imported. and removed 🗺️ reQUEST Trigger label to import an issue into Quest labels Apr 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: 🔖 Ready
Development

No branches or pull requests

3 participants