# MicrosoftDocs/terminal is the markdown behind the Windows Terminal docs > This repository is the documentation source for Windows Terminal, published at learn.microsoft.com/windows/terminal, and it contains no product code. It is a contribution workflow and a publishing pipeline, and the interesting parts are how a reader's Edit link becomes a pull request and how two different licences apply to the same tree. **MicrosoftDocs/terminal** — Documentation published at http://learn.microsoft.com/windows/terminal - Repository: https://github.com/MicrosoftDocs/terminal - Website: http://learn.microsoft.com/windows/terminal - Stars: 525 · Forks: 218 - Language: Unknown - License: CC-BY-4.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/microsoftdocs-terminal ## A documentation tree with no code in it The repository states the case in its first line. It contains the source code, primarily written in markdown, for Windows Terminal documentation, and the live content lives at the Windows Terminal documentation site on learn.microsoft.com. The primary language of the repository is listed as unknown, which is what you would expect from a tree that is prose, configuration and a small amount of tooling rather than a program. That distinction matters when you are deciding what to do with a problem. If a page describes a setting that the terminal does not have, the fix is not here. The README says to file an issue with the documentation using the feedback link at the bottom of the live page or the Issues tab, and to search existing issues first to see whether the issue is already being addressed. If the behaviour itself is wrong, the README points elsewhere entirely, to the Windows Terminal product repository for issues and pull requests. So the repository is a documentation surface, and its two audiences are people who read the docs and people who edit them. Everything else about it follows from that. ## The Edit link is the whole contribution mechanism The contribution path is described in one sentence. To contribute to these docs, you select the Edit link found on each of the live docs pages, which opens the source code file for that page. There is no clone, no branch, no local build step described, and no contribution tooling to install. That design has consequences. A correction to a typo in a settings reference can be made by someone who has never seen the repository before, because the page itself carries the route into the right file. The friction is deliberately almost zero, and the cost of that is a review queue that Microsoft moderates through its own process rather than through a project maintainer with a backlog. The README does point to the surrounding documentation system for people who need more. There is a markdown authoring reference, and a contributor guide, both on learn.microsoft.com, for the details of how the docs are written and how contributions are handled. The two paths are complementary: the Edit link gets you to the file, and those pages tell you what the file is supposed to look like and what the review process expects. The feedback loop is also two sided. Issues about the documentation go into this repository's issue tracker, and the README asks you to search existing issues first, which tells you that the tracker is expected to be read before it is written to. ## Publishing config and redirects live in the repository root The top level listing shows what a Microsoft documentation repository carries alongside its prose. There is `.openpublishing.publish.config.json`, which is the file that describes how and where the content gets published, and `.openpublishing.redirection.json`, which is the file that describes what happens to URLs that should no longer exist. There is also a `TerminalDocs/` directory holding the documentation content, a `ThirdPartyNotices.md`, a `SECURITY.md` and a `.github/` directory. The redirection file deserves attention because it encodes a real problem in documentation projects. Once a page is published at a URL, that URL ends up in bookmarks, in search results, in bug reports and in other people's writing, and Microsoft does not delete published pages. Instead, a rename leaves a redirect behind so the old link keeps working. Keeping that map current is tedious manual work, and having it in a reviewed file in the same repository as the content means the redirect and the page move can land in the same pull request. The README does not describe how either configuration file is structured, nor what triggers a publish, so anyone wanting to know how a change reaches the live site has to look at the files themselves and at the contributor guide. ## Two licences in one tree, and the split matters The repository carries two licence files, `LICENSE` and `LICENSE-CODE`, and the project as a whole is listed under CC-BY-4.0. That is the licence for the documentation content, and it is a Creative Commons attribution licence, which is the usual choice for prose that other people are expected to reuse and quote with credit. The second file, `LICENSE-CODE`, covers the code in the tree, which for a documentation repository means the scripts and configuration used to build and check the pages rather than the terminal itself. Having them separate is the correct arrangement for this kind of project, since a Creative Commons licence and a software licence impose different obligations, and folding them together would either weaken the reuse terms for the prose or impose the wrong terms on the tooling. The third file, `ThirdPartyNotices.md`, records the third party components that the documentation tooling pulls in. The README says nothing about any of these three files, so the obligation to read them is on the contributor rather than on the documentation, and the same is true of the `SECURITY.md`, which is present without a summary in the README. For an organisation reusing the pages, the practical point is that the CC-BY-4.0 grant applies to the documentation text, and the code files come with their own terms that have to be checked separately. ## A docs repository with no releases and a dated last push The maintenance picture here is different in kind from a code project, and the metadata reflects that. The repository has no GitHub releases at all, which is what you would expect for a tree whose artefacts are pages rather than binaries. There is no version to install and no changelog to read, because the published result is the site itself. The last push to the repository was on 2026-08-02, and the project is not archived. So content is still landing, and the documentation continues to be edited through the same Edit link mechanism. What there is no public record of in this repository is the pace of those changes. With no release tags and no changelog in the tree, an outside reader cannot tell from the repository alone which pages changed recently and which have sat untouched for a long time, and the live site's own history is the only place to look for that. The code of conduct is the Microsoft Open Source Code of Conduct, and the README gives both the FAQ page and a contact address for questions about it, an address at microsoft.com. That is the practical entry point for a contributor who has a question about the process rather than about a page. ## Conclusion This repository suits a technical writer or developer who wants to correct a page of the Windows Terminal documentation, and it does not suit anyone looking for the terminal emulator itself, since the product lives in the microsoft/terminal repository and this tree holds only prose and publishing configuration. Before your first contribution, read the contributor guide and the markdown authoring reference that the README links, and check the `TerminalDocs/` folder to find the file that matches the page you want to change, because the mapping from the published URL to the source file is what the Edit link resolves for you. ## FAQ ### What is the MicrosoftDocs/terminal repository? It is the source for the Windows Terminal documentation, primarily written in markdown, which is published on learn.microsoft.com/windows/terminal. It contains documentation source and publishing configuration, not the terminal application itself. ### How do I contribute a change to the Windows Terminal documentation? Select the Edit link on the live documentation page, which opens the source file for that page, and edit it there. The README also links a markdown authoring reference and a contributor guide on learn.microsoft.com, and asks contributors to search existing issues before filing a new one. ### Where do I report a bug in Windows Terminal itself? The README directs product issues and pull requests to the Windows Terminal product repository at github.com/microsoft/terminal, since this repository only holds the documentation source. ### What licence applies to the Windows Terminal documentation? The repository is listed under CC-BY-4.0, and it ships two licence files, `LICENSE` for the content and `LICENSE-CODE` for the code in the tree, plus a `ThirdPartyNotices.md`. The README does not summarise their terms, so the files themselves have to be read. ### Does the MicrosoftDocs/terminal repository publish releases? No, the repository has no GitHub releases. Its last push was on 2026-08-02 and it is not archived, so documentation changes still land through the same Edit link workflow, but there is no version history in the repository to consult. ## Sources - [Issues](https://github.com/MicrosoftDocs/terminal/issues) - [License: CC-BY-4.0](https://github.com/MicrosoftDocs/terminal/blob/main/LICENSE) - [MicrosoftDocs/terminal on GitHub](https://github.com/MicrosoftDocs/terminal) - [Project website](http://learn.microsoft.com/windows/terminal) - [README](https://github.com/MicrosoftDocs/terminal/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoftdocs-terminal