Merge branch 'main' into user/hmishra/merge-main-into-winui3main-3

.github/CODEOWNERS

@@ -1,4 +1,2 @@
-# DISABLED: Turned this off since it's currently generating very noisy notifications to the team and reviewers can't
-# tell the difference between being explicitly added as a reviewer versus by way of this group.
-# Add the code reviews team to all PRs in the repo.
-# * @Microsoft/microsoft-ui-xaml-codereviews
+# Default reviewers for all PRs
+* @microsoft/tm-winui

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,41 +1,52 @@
-<!--- Provide a general summary of your changes in the Title above -->
+## Fixes
 
-## Fixes #####
-<!-- Add the relevant issue number after the word 'Fixes' mentioned above. -->
-<!-- PRs without assigned issues will be closed unless minor changes to documentation/typos. -->
+<!-- Link the issue this PR addresses. Use "Fixes #xxx" or "Closes #xxx" so GitHub auto-closes it on merge. -->
+<!-- PRs without a linked issue may be closed unless they are minor documentation/typo fixes. -->
+
+Fixes #
 
 ## PR Type
-<!-- Please try to limit your pull request to one type, submit multiple pull requests if needed -->
 
-Please check the type of change your PR introduces:
+<!-- Check the type of change. Limit each PR to one type when possible. -->
 
 - [ ] Bugfix
 - [ ] Feature
 - [ ] Code style update (formatting, renaming)
-- [ ] Refactoring (no functional changes, no api changes)
+- [ ] Refactoring (no functional changes, no API changes)
 - [ ] Build related changes
 - [ ] Documentation content changes
 - [ ] Other (please describe):
 
 ## Description
-<!--- Describe your changes in detail -->
+
+<!-- Describe your changes in detail. -->
 
 ### Current Behavior
-<!-- How does this work currently atop the latest stable release? -->
+<!-- How does this work today? -->
 
 ### New Behavior
-<!-- How will it work now with this fix? -->
+<!-- How will it work after this PR? -->
 
-### Motivation and Context
-<!--- Why is this change required? What problem does it solve? -->
-<!--- If it fixes an open issue, please link to the issue here. -->
-<!--- Use the syntax "Closes #xxx" or "Fixes #xxx" so that GitHub will close the issue once the PR is complete. -->
+## Customer Impact
+
+<!-- How does this change affect end users? Is it user-facing or infra changes? -->
+
+## Regression Potential
+
+<!-- Could this change cause regressions? What areas might be affected? -->
+
+- [ ] Low risk — isolated change, limited scope
+- [ ] Medium risk — touches shared components or public APIs
+- [ ] High risk — architectural or breaking API change
 
 ## How Has This Been Tested?
-<!--- Please describe how you tested your changes and check off the boxes below. -->
+
+<!-- Describe how you validated your changes. -->
 
 - [ ] I have performed a self-review of my own code
 - [ ] I have added tests to cover my changes
+- [ ] Existing tests pass locally
 
-## Screenshots (if appropriate):
-<!--- If you are making visual changes to a Control or adding a new Control, please include screenshots showing the result. -->
+## Screenshots (if appropriate)
+
+<!-- If you are making visual changes, include before/after screenshots. -->

.github/workflows/docs.yml

@@ -27,5 +27,6 @@ jobs:
 
       # Runs a single command using the runners shell
       - name: Check links
-        run: npx unbroken
+        run: npx --yes unbroken
         working-directory: docs
+        timeout-minutes: 10

CONTRIBUTING.md

@@ -23,6 +23,27 @@ Another great way to help is by voting and commenting on feature proposals:
 
 * [feature request](https://github.com/Microsoft/microsoft-ui-xaml/labels/feature%20request)
 
+## Getting started
+
+1. **Fork** the repository on GitHub
+2. **Clone** your fork locally
+3. **Create a branch** for your changes (`git checkout -b my-feature`)
+4. **Build** the project — see [Getting Started](GettingStarted.md) for build prerequisites and instructions
+5. **Make your changes** and add tests where appropriate
+6. **Push** your branch to your fork and open a **Pull Request** against `main`
+
+> **Note:** If you are using the GitHub CLI, you can use the `build` and `bt-build` skills to build the project and run build tests directly from the command line.
+
+### PR requirements
+
+All PRs targeting `main` or release branches require:
+- At least **2 approvals** from the WinUI team
+- All **review conversations resolved**
+- **CLA signed** (a bot will prompt you on your first PR)
+- **PR build passing** (triggered automatically)
+
+PRs are merged using **squash merge** by default.
+
 ## Code contribution guidelines
 
 ### Proposing new public APIs or UI
@@ -33,7 +54,7 @@ You don't need to follow that process for bug fixes or other small changes.
 
 ### Contribution bar
 
-The WinUI team accepts code changes that improve WinUI or fix bugs, as long as they follow the processes outlined below and broadly align with our [roadmap](docs/roadmap.md).
+The WinUI team accepts code changes that improve WinUI or fix bugs, as long as they follow the processes outlined below and broadly align with our roadmap.
 
 While we strive to accept all community contributions that meet the guidelines outlined here, please note that we may not merge changes that have narrowly-defined benefits due to compatibility risks and maintenance costs. We may also revert changes if they are found to be breaking.
 
@@ -41,10 +62,8 @@ While we strive to accept all community contributions that meet the guidelines o
 
 For details see:
 
-* [Setup and build environment](docs/developer_guide.md#Prerequisites)
-* [Source code structure](docs/source_code_structure.md)
+* [Getting Started — build prerequisites and instructions](GettingStarted.md)
 * [Contribution workflow](docs/external/contribution_workflow.md)
-* [Coding style and conventions](docs/code_style_and_conventions.md)
 
 ### Contributor License Agreement
 
@@ -63,15 +82,15 @@ file in the repository, as needed.
 
 ## Documentation and usage samples
 
-You can also read and contribute to the WinUI documentation here:  
-https://docs.microsoft.com/uwp/toolkits/winui
+You can also read and contribute to the WinUI documentation here:
+https://learn.microsoft.com/windows/apps/winui/
 
-You can find usage examples of the controls available in WinUI in the WinUI 3 Gallery app:  
- https://github.com/Microsoft/WinUI-Gallery/  
+You can find usage examples of the controls available in WinUI in the WinUI 3 Gallery app:
+https://github.com/Microsoft/WinUI-Gallery/
 
- Which can also be installed from the Microsoft Store:  
- https://apps.microsoft.com/detail/9p3jfpwwdzrc
- 
- ## API spec discussions
+Which can also be installed from the Microsoft Store:
+https://apps.microsoft.com/detail/9p3jfpwwdzrc
 
-Before new features are added to WinUI, we always perform a thorough API review and spec discussion. This can range from a single new API to an entire new control featuring dozens of new APIs. Joining such a spec discussion is a great opportunity for developers to help ensuring that new WinUI APIs will look and feel natural. In addition, spec discussions are the follow-up to feature proposals and will go into much finer details than the initial proposal. As such, taking part in these discussions gives developers the chance to be involved in the complete development process of new WinUI features - from their initial high-level inception right down to specific implementation/behavior details. These discussions take place in the WInUI repository, i.e. this repository.
+## API spec discussions
+
+Before new features are added to WinUI, we always perform a thorough API review and spec discussion. This can range from a single new API to an entire new control featuring dozens of new APIs. Joining such a spec discussion is a great opportunity for developers to help ensuring that new WinUI APIs will look and feel natural. In addition, spec discussions are the follow-up to feature proposals and will go into much finer details than the initial proposal. As such, taking part in these discussions gives developers the chance to be involved in the complete development process of new WinUI features - from their initial high-level inception right down to specific implementation/behavior details. These discussions take place in the WinUI repository, i.e. this repository.

docs/.unbroken_exclusions

@@ -0,0 +1,7 @@
+# Azure DevOps URLs return HTTP 203 (non-authoritative) to unauthenticated clients;
+# unbroken only accepts 200, so it retries 5 times and reports failure.
+URL not found https://dev.azure.com/ms/microsoft-ui-xaml/_build?definitionId=21 while parsing external/contribution_workflow.md after 5 retries
+URL not found https://dev.azure.com/ms/microsoft-ui-xaml/_build?definitionId=20 while parsing external/contribution_workflow.md after 5 retries
+
+# Microsoft Store returns HTTP 403 to non-browser user agents
+URL not found https://www.microsoft.com/store/p/windbg/9pgjgd53tn86 while parsing external/debugging_crashes.md (HTTP 403)

docs/external/contribution_handling.md

@@ -6,7 +6,7 @@ The WinUI repo is intended as a place for the WinUI team to gather community fee
 
 Feature requests and bugs are tracked as GitHub issues.
 
-For reporting security issues please see the [Security Policy](SECURITY.md).
+For reporting security issues please see the [Security Policy](../../SECURITY.md).
 
 For all other bugs and general issues please [file a new issue](https://github.com/Microsoft/microsoft-ui-xaml/issues/new/choose) using the Bug Report template.
 

docs/external/contribution_workflow.md

@@ -99,7 +99,7 @@ define them here:
 
 #### [WinUI-Public-MUX-CI](https://dev.azure.com/ms/microsoft-ui-xaml/_build?definitionId=20)
 
-This pipeline extends [WinUI-Public-MUX-PR](https://dev.azure.com/ms/microsoft-ui-xaml/_build?definitionId=21) 
+This pipeline extends WinUI-Public-MUX-PR
 to validate more platforms, adding Debug and ARM. It is run after your changes are merged to 
 main.
 

docs/external/debugging_crashes.md

@@ -19,14 +19,14 @@ This type of crash might manifest as a crash in your app, usually with a functio
 
 ### Using WinDbg
 
-In [WinDbg](https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools), use `.dump /ma <filename>` to save a full memory dump to the specified file when the crash happens.
+In [WinDbg](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools), use `.dump /ma <filename>` to save a full memory dump to the specified file when the crash happens.
 * If the crash happens sometime after app launch, then you can launch the app, attach to the app with WinDbg, and then do the repro steps to hit the crash.
 * If the crash happens on launch, then [WinDbg Preview](https://www.microsoft.com/store/p/windbg/9pgjgd53tn86) is recommended, since it contains a "Launch app package" option in
 "Start Debugging" which can launch and debug UWP and packaged apps from launch.
 
 ### Other options
 
-Another option is to set some regkeys to tell Windows to keep some crash dumps locally (see https://docs.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps).
+Another option is to set some regkeys to tell Windows to keep some crash dumps locally (see https://learn.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps).
 For example, running these commands in an administrative command prompt will set regkeys to tell Windows to save full (type=2) dumps into `C:\dumps`:
 
     reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpFolder /d "C:\dumps"
@@ -53,12 +53,9 @@ But if it is a stowed exception crash, which has exception code: 0xc000027b, the
 
 Stowed exception crashes save away a possible error, which gets used later if no one handles the exception.
 XAML sometimes decides the error is fatal immediately, in which case the direct crash stack may be good, but more frequently the stack has unwound before it was determined to be fatal.
-This channel9 talk describes stowed exceptions in more detail: https://channel9.msdn.com/Shows/Inside/C000027B?term=stowed%20exception&lang-en=true.
-
 For stowed exception crashes, you can get more info on the crash by loading a crash dump in WinDbg and then using !pde.dse to dump the stowed exceptions.
-The !pde debugger extension is available [here](https://onedrive.live.com/?authkey=%21AJeSzeiu8SQ7T4w&id=DAE128BD454CF957%217152&cid=DAE128BD454CF957) in the PDE*.zip.
-(It is linked off the channel9 page above.)
-Put the appropiate x64 or x86 dll in that zip in the winext directory of a WinDbg install, and then "!pde.dse" should work on stowed exception crash dumps.
+The PDE debugger extension is included in modern versions of [WinDbg](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools).
+Load it with `.load pde` and then run `!pde.dse` to dump stowed exception information.
 
 Frequently there will be multiple stowed exceptions, with some at the end which got handled/ignored.
 Most commonly, the first stowed exception is the interesting one.

docs/external/feature_proposal_process.md

@@ -37,7 +37,7 @@ We'll keep the issue open for community discussion until the team owner decides
 Note that if an issue isn't a high priority or has many open questions then it might stay open for a long time.
 
 4. **Owner Review**  
-The WinUI team will review the proposal and either approve or close the issue based on whether it broadly aligns with the [WinUI roadmap](roadmap.md) and [contribution guidelines](../../CONTRIBUTING.md).
+The WinUI team will review the proposal and either approve or close the issue based on whether it broadly aligns with the [WinUI roadmap](https://github.com/microsoft/WindowsAppSDK/blob/main/docs/roadmap.md) and [contribution guidelines](../../CONTRIBUTING.md).
 
 5. **API Review**  
 If the feature adds new APIs then we'll start an API review in the [WinUI API review repo](https://github.com/microsoft/microsoft-ui-xaml-specs). All new public APIs must be reviewed before merging.  
@@ -51,10 +51,10 @@ Our contribution guidelines can be found [here](../../CONTRIBUTING.md).
 Once a feature is complete and tested according to the [contribution guidelines](../../CONTRIBUTING.md) you can send us a PR to merge it to main.  
 
 8. **Documentation and sample updates**  
-We will update the [documentation on docs.microsoft.com](https://docs.microsoft.com/windows/uwp) and if applicable add a sample to the [Xaml Controls Gallery](https://github.com/Microsoft/Xaml-Controls-Gallery) app.  
+We will update the [documentation on docs.microsoft.com](https://learn.microsoft.com/windows/uwp) and if applicable add a sample to the [WinUI 3 Gallery](https://github.com/microsoft/WinUI-Gallery) app.
 Feel free to also contribute to docs and samples!  
 Once the docs and samples are updated we'll close the issue.
 
 9. **Binaries**  
-We periodically produce signed prerelease binaries from the main branch which are published to [NuGet](https://www.nuget.org/profiles/winui): see the [Roadmap](roadmap.md) for info on build frequency.   
+We periodically produce signed prerelease binaries from the main branch which are published to [NuGet](https://www.nuget.org/profiles/winui): see the [Windows App SDK Roadmap](https://github.com/microsoft/WindowsAppSDK/blob/main/docs/roadmap.md) for info on build frequency.
 After the feature has been sufficiently validated as part of a prerelease package we will include it in the next stable binary release on NuGet.

docs/external/triage.md

@@ -67,7 +67,7 @@ We also need to monitor:
 
 1. New and re-opened issues get `needs-triage` label added
 1. `needs-triage` label is added whenever `team-...` labels change so that the new team sees the status change on the issue.
-1. If `feature proposal` is added or removed it gets added/removed from the [feature tracking project board](https://github.com/microsoft/microsoft-ui-xaml/projects/4) accordingly.
+1. If `feature proposal` is added or removed it gets added/removed from the feature tracking project board accordingly.
 1. If `declined` is added, bot adds a friendly message and closes.
 1. Tags issues/PR with release announcement.
 1. When moving into `Front Burner` column, gets added to the `API review` board.