This section covers the contributor experience for the Windows Terminal repository: the open development model, issue workflow, the specification process, build configurations, CI pipeline, testing, and release engineering. For a deep dive into the build system and test execution, see Building and Testing. For the release engineering workflow and historical roadmaps, see Release Process and Roadmaps.
The team conducts all development in public on GitHub. This includes filing bugs, designing features in specification documents, reviewing pull requests, and triaging issues. A bot engine (documented in doc/bot.md) automates label-driven operations: closing stale issues, merging branches, and notifying parties when follow-up is needed.
Issues are triaged several times per week. Response to requests for information is required to keep issues open — the bot will close stale items after reminders go unanswered.
Security issues must not be reported via GitHub issues. Use the Microsoft Security Response Center (MSRC) as described in SECURITY.md
The primary communication channel is GitHub Issues. Before filing a new issue, search existing open and closed issues.
| Channel | When to Use |
|---|---|
| GitHub Issues | Bugs, feature requests, questions |
| GitHub Discussions / PR comments | Design feedback on open work |
| Twitter / Mastodon | Informal questions to individual team members |
When filing an issue, complete the template fully. Include OS build, tooling versions, and detailed repro steps. Do not post "+1" comments; use emoji reactions on the original issue instead.
Sources: CONTRIBUTING.md30-98 README.md322-340
You can configure your environment either automatically (via WinGet) or manually.
Variants for VS 2022 Enterprise and Professional editions are in the .config directory.
| Requirement | Minimum Version |
|---|---|
| Windows | 10 2004 (build 19041) |
| Developer Mode | Must be enabled in Settings |
| PowerShell | 7.0+ |
| Windows SDK | 10.0.22621.0 |
| Visual Studio | 2022 (v143 toolset) |
| VS Workloads | Desktop Development with C++, UWP Development |
| VS Components | C++ (v143) Universal Windows Platform Tools |
| .NET Framework Targeting Pack | Required for test projects |
The target platform version (WindowsTargetPlatformVersion) is set to 10.0.22621.0 and the minimum version (WindowsTargetPlatformMinVersion) is 10.0.18362.0, both declared in src/common.build.pre.props78-80
Sources: README.md342-375 src/common.build.pre.props77-80
The following diagram maps the contributor steps to the tools and repository locations involved.
Diagram: Contribution Workflow (Natural Language → Code Entities)
Sources: CONTRIBUTING.md100-175 README.md376-430 doc/TAEF.md1-65
Issues are categorized by label to indicate their nature and expected contributor effort.
| Label | Meaning | Spec Required? |
|---|---|---|
Issue-Bug | Existing functionality broken | No |
Issue-Task | New, small, well-scoped feature | No |
Issue-Feature | Larger feature requiring design | Yes |
Help Wanted | Open for community contribution | Depends |
good first issue | Lower-complexity entry point | No |
Starting points for new contributors:
Help Wanted + good first issue labelsSources: CONTRIBUTING.md100-142
Features labeled Issue-Feature require a specification document before development begins. Specs are stored under doc/specs/ named using the pattern #<issue-id> - <description>.md.
Specs are authored and reviewed via pull request using the same fork-and-branch model as code. Required content includes: problem statement, solution design, UI/UX considerations, accessibility, security, compatibility, and performance impact.
Once approved, the associated issue receives a Help Wanted label and development may begin.
Sources: CONTRIBUTING.md118-143
The solution file is OpenConsole.slnx. All projects import shared MSBuild property sheets to control output layout, compiler flags, and dependency management.
| Property Sheet | Role |
|---|---|
src/common.build.pre.props | Output directories, project configurations, compiler settings, vcpkg integration |
src/common.build.post.props | HybridCRT linking, C++ targets import, PCH cleanup, feature flag generation |
src/wap-common.build.pre.props | WAP (Windows Application Packaging) project settings |
Build configurations defined in src/common.build.pre.props26-75:
| Configuration | Description |
|---|---|
Debug | Debug libs, fast-link PDB, optimizations disabled |
Release | Full optimization, WPO, HybridCRT |
AuditMode | Release + PREfast static analysis via StaticAnalysis.ruleset |
Fuzzing | Address sanitizer + coverage instrumentation, static CRT |
Platforms: Win32 (x86), x64, ARM64
For full details on MSBuild configurations, HybridCRT, vcpkg integration, and NuGet management, see Building and Testing.
Sources: src/common.build.pre.props1-302 src/common.build.post.props1-119 README.md376-411
The CI pipeline is defined in build/pipelines/ci.yml It runs on pushes and PRs targeting main and feature/* branches.
Diagram: CI Pipeline Stages (ci.yml → Stage Names)
Key pipeline behaviors:
doc/*, samples/*, and tools/* path changes do not trigger the pipeline..appxrecipe-described dependencies to _testDeps before running te.exe.Audit_x64 stage is parameterized and can be disabled (auditMode: false).bin\<Platform>\<Configuration>\ as controlled by OutDir in common.build.pre.props.Sources: build/pipelines/ci.yml1-110 src/common.build.pre.props6-11
The project uses TAEF (Test Authoring and Execution Framework) as its test runner. The te.exe binary is provided by the Microsoft.Taef NuGet package.
Running tests via PowerShell:
Running tests via Cmd (after razzle.cmd):
Diagram: Test Execution Flow (Script → te.exe)
Tests can be debugged by attaching to the PID printed when using the /waitForDebugger flag on te.exe. For full TAEF usage and test project structure, see Building and Testing.
Sources: doc/TAEF.md1-65 build/scripts/Run-Tests.ps11-63
Reference documents for code style and organization:
| Document | Topic |
|---|---|
| doc/STYLE.md | C++ style conventions |
| doc/ORGANIZATION.md | Project and file organization |
| doc/EXCEPTIONS.md | Exception handling in legacy code |
| doc/WIL.md | WIL smart pointers and macros |
The compiler enforces warnings-as-errors at Warning Level 4, with specific exceptions listed in src/common.build.pre.props117-140 C++20 (stdcpp20) and C17 (stdc17) are the language standards in use.
Static analysis is run in AuditMode using src/StaticAnalysis.ruleset which includes the CppCoreCheck ruleset.
Sources: README.md412-430 src/common.build.pre.props113-165 src/StaticAnalysis.ruleset1-18
Windows Terminal ships two channels:
| Channel | Description |
|---|---|
| Canary | Nightly builds from main; least stable |
| Preview | New features land here first |
| Stable | Features promoted from Preview after bake time |
The release cadence shifted from 6-week milestones (v1.x era) to a roughly quarterly cycle (2023+). Features enter Preview, remain there for at least one release cycle, then graduate to Stable.
For the full release engineering workflow — including ServicingPipeline.ps1, changelog generation, and GitHub ProjectV2 milestone management — see Release Process and Roadmaps.
Sources: doc/roadmap-2023.md1-57 doc/roadmap-2022.md1-50 README.md158-178
To debug in Visual Studio:
CascadiaPackage in Solution Explorer → Properties → Debug.F5.x64 or x86 (not Any CPU).
WindowsTerminal.execannot be launched directly. It must be deployed via theCascadiaPackageMSIX project. See GitHub issues #926 and #4043 for context.
Sources: README.md396-411
Refresh this wiki
This wiki was recently refreshed. Please wait 4 days to refresh again.