Inside windows-dev-docs, the source behind Microsoft's Windows app documentation

A content pipeline rather than a library anyone can install

windows-dev-docs is not a buildable package. Its stated purpose is conceptual and overview content for developing Windows apps, its primary language is listed as C#, and it publishes no GitHub releases. What you actually get when you clone it is a directory of source files for documentation, plus the publishing configuration that turns those files into pages on the live Microsoft documentation site.

That distinction matters for adoption. There is no version to pin, no dependency manifest to resolve and no install step that produces an artifact on your machine. The only executable surface is the tooling used to author and publish the content. People who arrive expecting a sample project, a NuGet package or a reusable SDK will find that none of those exist here.

The repository does carry the usual signals of a serious working project, though. There is a SECURITY.md for reporting problems, a ThirdPartyNotices file, a CONTRIBUTING.md, a .github directory, and a .gitignore. The default branch is not master but docs, which tells you immediately that the layout has been reorganized around the publishing pipeline rather than around a software product.

The rename from windows-uwp still leaks into every clone

The README opens with a rename notice, and it is worth reading before you pull. The repository was previously called windows-uwp, and the team renamed it because the new name better describes the content source files it holds. Any clone you made before that rename still points at the old address, so the first practical task for a returning contributor is repointing the remote.

The README gives the exact two step procedure. You check what your remote currently is, then you set the new URL.

git remote -v

A stale clone answers with the old address:

origin  https://github.com/MicrosoftDocs/windows-uwp.git (fetch)
origin  https://github.com/MicrosoftDocs/windows-uwp.git (push)

Then you run the single command that fixes it:

git remote set-url origin https://github.com/MicrosoftDocs/windows-dev-docs.git

The README also offers a blunt alternative: delete the local copy and reclone it if you have no active work you fear losing. There is no third option mentioned for merging an old clone with the renamed repository, so if you do have local commits, you are on your own.

The directory list reads like a map of Windows app topics

The top level of the repository shows content areas rather than software modules. Alongside the configuration files you would expect in a docs repository, you find directories named uwp/, terminal/, WSL/, windows-apps-src/, hub/, landing/ and tools/. The uwp/ directory preserves the older Universal Windows Platform naming even though the repository itself was renamed, and terminal/ and WSL/ sit next to it as separate content areas.

Two of these entries deserve attention. windows-apps-src/ is the directory that most closely matches the repository description, since it is the likely home for source files about building Windows apps. tools/ suggests that helper scripts live in the repository rather than in a separate automation project, and auto-publish.yml at the root implies that publishing runs as a pipeline rather than by hand.

The tools/ directory being inside the same repository is the kind of detail that is easy to miss and hard to guess. If you contribute a new content area, you may also be expected to add or adjust a helper script in tools/, and the pull request would then touch both prose and pipeline code. The README does not spell out which scripts are required for which contribution type, so anyone planning a structural change needs to read the tooling before assuming the content files are the only thing that matters.

Open Publishing configuration decides what the reader sees

Four files at the root explain how content becomes live documentation, and they are the closest thing this repository has to architecture. .openpublishing.publish.config.json is the standard Open Publishing configuration that names the publishing pipeline. .openpublishing.redirection.json holds redirect rules for pages that moved. .whatsnew.json records what is new, and .localization-config drives the translation pipeline for localized versions of the same pages.

Read together, those four files describe a flow that starts with an author editing a content file, passes through the publishing pipeline defined in the publish configuration, and ends at the live site with localized variants produced from the same source. The redirect file exists because Microsoft reorganizes its documentation often, and a URL that used to resolve has to keep resolving after a move.

The practical consequence for an outside contributor is that a page is not finished when the prose is right. A new or moved page can require an entry in the redirection file, and any change to a shared concept may affect the localized versions that the localization configuration drives. None of this is documented in the README. The README concentrates on the rename, the legal notices and the privacy link, so the pipeline rules have to be learned from the configuration files themselves or from the contribution guide.

Two licenses, and the gap between them

The repository carries two license files and applies them to different things. Microsoft and contributors license the documentation and other content under the Creative Commons Attribution 4.0 International Public License, held in the LICENSE file, while code in the repository is licensed under the MIT License, held in LICENSE-CODE. The README makes this split explicit in its legal notices.

For an engineer reusing text, the CC-BY-4.0 terms require attribution to the source when you copy prose into your own documentation. For an engineer reusing a script from tools/ or an example from windows-apps-src/, the MIT terms are the more permissive and familiar grant. Checking which file covers the snippet you are about to copy is the practical step here, and the repository makes it easy because the two licenses are separate files rather than one merged notice.

The README is equally clear about what the licenses do not give you. The licenses grant no rights to use Microsoft names, logos or trademarks, and they reserve all other rights whether under copyrights, patents or trademarks. The trademark guidelines are pointed to separately, and the README notes that Microsoft, Windows, Microsoft Azure and other referenced products may be trademarks or registered trademarks. Reproducing a diagram from these pages therefore carries obligations that neither license file addresses, so treat prose reuse and brand reuse as two separate questions.

Where this repository is the wrong tool

The clearest case for choosing something else is a developer who wants working code to copy. The repository publishes conceptual and overview content, it has no releases, and the README says nothing about sample applications you can run. If your goal is to see a Windows app work end to end, the official developer samples and the Windows SDK serve that purpose, and neither of them lives in this repository.

A second mismatch is timing. The rename notice describes an ongoing restructuring of the source directories to align with the live documentation structure, with a target date of September 16, 2022. That date is written in the past relative to the current state of the repository, and the top level still contains both a uwp/ directory and a windows-apps-src/ directory, so the layout you read today may not match the layout a future change assumes. Anyone writing scripts that assume a fixed path inside the repo should check the path first.

A third case is offline or air gapped use. Because the pages are published to a live documentation site and localized through a pipeline, a snapshot of this repository gives you source files and configuration, not a rendered, searchable copy of the finished guides.

What a first contribution actually involves

The practical workflow is short. Clone the repository on the docs branch, confirm the remote points at windows-dev-docs, edit the content file that covers your topic, and open a pull request. The .github directory and CONTRIBUTING.md are where the house rules live, and the README does not summarize them, so read both before the first commit rather than after a rejected one.

Because the content is published rather than built, the review bar is about accuracy and consistency of the guidance. A change that alters wording across several pages can touch the localized variants that .localization-config produces, and a change that moves a page has to be paired with a redirection rule in .openpublishing.redirection.json. Failing to do the second one breaks inbound links that search engines and older articles still carry.

The last push on this repository was on 2026-10-19, which tells you the pipeline is still being worked on, and there are no GitHub releases, so there is no upgrade step to track. Follow the rename steps and the redirection rule and your change travels the same path the Microsoft content team uses.

Editorial conclusion

Adopt windows-dev-docs if you intend to correct or extend Microsoft's Windows app documentation, and you are comfortable editing Markdown-style content in a pipeline repository. Do not treat it as an SDK or a sample application, because no package is built from it and no releases exist. Before your first contribution, confirm that the topic you plan to change still lives under the branch and directory names you expect, check CONTRIBUTING.md for the required pull request shape, and remember that a clone made before the rename points at the old windows-uwp URL until you run git remote set-url.

Frequently asked questions

Official sources

1. Issues
2. License: CC-BY-4.0
3. MicrosoftDocs/windows-dev-docs on GitHub
4. README