|
1 | 1 | # Contributing to the Windows UI Library |
| 2 | +Welcome to the Windows UI Library (WinUI) repository. The WinUI repo is intended as a place for the WinUI team to gather community feedback, discuss issues with the community, and provide insight into bug fixes that the team is working on before updates are released. We welcome your input and contributions to all aspects of WinUI, including bug reports, doc updates, feature proposals, and API spec discussions. |
2 | 3 |
|
3 | | -We welcome your input and contributions to all aspects of WinUI, including bug reports, doc updates, feature proposals, and API spec discussions. |
| 4 | +This document contains general guidance. More specific guidance is included in the documents linked below and within the repository’s [Wiki](https://github.com/microsoft/microsoft-ui-xaml/wiki) pages. |
4 | 5 |
|
5 | | -This document contains general guidance. More specific guidance is included in the documents linked below. |
| 6 | +Note this repository is not ready for open source collaboration at this time; this work is currently in progress. You can track the WinUI team’s progress towards open source collaboration in the [Phased Rollout to Open Source Collaboration](https://github.com/microsoft/microsoft-ui-xaml/discussions/10700) discussion. |
6 | 7 |
|
7 | 8 | Note that all community interactions must abide by the [Code of Conduct](CODE_OF_CONDUCT.md). |
8 | 9 |
|
9 | | -## How we work with contributions |
| 10 | +## Documentation and Samples |
| 11 | +The [WinUI](https://aka.ms/winui3) documentation is a great resource for learning more about WinUI development. Within these docs, you can find information on how to create new WinUI applications, the full set of WinUI APIs and controls, and more. |
10 | 12 |
|
11 | | -For reporting security issues please see the [Security Policy](docs/SECURITY.md). |
| 13 | +You’re welcome to propose changes to our documentation through the same link. |
12 | 14 |
|
13 | | -Contributions from the community in the form of feature requests and bugs are handled according to our [contribution handling](docs/contribution_handling.md) guidelines. |
| 15 | +You can find usage examples of the controls available in WinUI in the [WinUI 3 Gallery app](https://apps.microsoft.com/detail/9p3jfpwwdzrc). The source code for WinUI3 Gallery is available on GitHub at [microsoft/WinUI-Gallery]( https://github.com/Microsoft/WinUI-Gallery/). |
14 | 16 |
|
15 | | -## New contributors |
| 17 | +## Filing New Issues |
| 18 | +If you have a general question on how to use WinUI and are not sure it’s a bug, ask in the [Q&A](https://github.com/microsoft/microsoft-ui-xaml/discussions/categories/q-a) discussion forum. |
16 | 19 |
|
17 | | -We mark the most straightforward issues with labels. These issues are the place to start if you are interested in contributing but new to the codebase. |
| 20 | +If you have an idea or feature request, post in the [Ideas](https://github.com/microsoft/microsoft-ui-xaml/discussions/categories/ideas) discussion forum. |
18 | 21 |
|
19 | | -* [good first issues](https://github.com/Microsoft/microsoft-ui-xaml/labels/good%20first%20issue) |
20 | | -* [help wanted](https://github.com/Microsoft/microsoft-ui-xaml/labels/help%20wanted) |
| 22 | +If you have an issue which you think is a bug, please follow the [Bug Report](https://github.com/microsoft/microsoft-ui-xaml/issues/new?template=bug_report.yaml) issue template and provide a stand-alone minimal repo project. |
21 | 23 |
|
22 | | -Another great way to help is by voting and commenting on feature proposals: |
| 24 | +If you are reporting a security issue, please see the [Security Policy](SECURITY.md). |
23 | 25 |
|
24 | | -* [feature request](https://github.com/Microsoft/microsoft-ui-xaml/labels/feature%20request) |
| 26 | +For more information on how issues are handled from the community, see our [contribution handling](docs/contribution_handling.md) guidelines. |
25 | 27 |
|
26 | | -## Code contribution guidelines |
| 28 | +### Proposing New Public APIs or UI |
| 29 | +Please follow the [New Feature or API Process](docs/feature_proposal_process.md) before adding, removing, or changing public APIs or UI. Note: The WinUI team will only accept feature proposals for WinUI3. |
27 | 30 |
|
28 | | -### Proposing new public APIs or UI |
| 31 | +All new public APIs, new UI, or breaking changes to existing features must go through that process before submitting code changes. |
29 | 32 |
|
30 | | -Please follow the [New Feature or API Process](docs/feature_proposal_process.md) before adding, removing, or changing public APIs or UI. |
31 | | -All new public APIs, new UI, or breaking changes to existing features **must** go through that process before submitting code changes. |
32 | | -You don't need to follow that process for bug fixes or other small changes. |
| 33 | +## Code Contribution Guidelines |
| 34 | +Note this repository is not ready for open source collaboration at this time; this work is currently in progress. You can track the WinUI team’s progress towards open source collaboration in the [Phased Rollout to Open Source Collaboration](https://github.com/microsoft/microsoft-ui-xaml/discussions/10700) discussion. |
33 | 35 |
|
34 | | -### Contribution bar |
| 36 | +WinUI will be taking a phased approach to opening up the repo: |
| 37 | +**Phase 1: Increased Mirror Frequency** |
| 38 | +After the WASDK 1.8 release (end of August), we’ll begin more frequent mirroring of internal commits to GitHub to increase transparency and show progress. |
| 39 | +**Phase 2: 3rd Party Devs Build Locally** |
| 40 | +External developers will be able to clone and build the repo locally, with documentation to guide setup and dependencies. |
| 41 | +**Phase 3: 3rd Party Devs Contribute & Run Tests** |
| 42 | +Contributors will be able to submit PRs and run tests locally. We’re working to untangle private dependencies and make test infrastructure publicly accessible. |
| 43 | +**Phase 4: GitHub as Center of Gravity** |
| 44 | +GitHub becomes the primary place for development, issue tracking, and community engagement. Internal mirrors will be phased out. |
35 | 45 |
|
36 | | -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). |
| 46 | +### [WIP] New Contributors |
| 47 | +Contributions from the community are greatly appreciated. We mark the most straightforward issues with labels. These issues are the best place to start if you are interested in contributing but are new to the codebase. |
37 | 48 |
|
38 | | -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. |
| 49 | +- [good first issues](https://github.com/Microsoft/microsoft-ui-xaml/labels/good first issue) |
| 50 | +- [help wanted](https://github.com/orgs/microsoft/projects/1868/views/12) |
39 | 51 |
|
40 | | -### Code contribution process |
| 52 | +Another great way to help is by up-voting and commenting on feature proposals: |
| 53 | +- [feature request](https://github.com/Microsoft/microsoft-ui-xaml/labels/feature request) |
41 | 54 |
|
42 | | -For details see: |
| 55 | +### [WIP] Code Contribution Process |
| 56 | +We use and recommend the following workflow: |
| 57 | +1. Create an issue for your work. |
| 58 | + - You can skip this step for trivial changes or if there is an existing issue for the bug/feature. |
| 59 | + - If your change adds or changes public APIs or UI, first follow the [New Feature or API Process](docs/feature_proposal_process.md). |
| 60 | + - Clearly state that you are going to take on implementing it, if that's the case. You can request that the issue be assigned to you. Note: The issue filer and the implementer don't have to be the same person. |
| 61 | +1. Create a personal fork of the repository on GitHub (if you don't already have one). |
| 62 | +1. Create a branch off of main (git checkout -b mybranch). |
| 63 | + - Name the branch so that it clearly communicates your intentions (i.e. /user/janedoe/fix-datepicker). |
| 64 | + - Branches are useful since they isolate your changes from incoming changes from upstream. They also enable you to create multiple PRs from the same fork. |
| 65 | +1. Make and commit your changes. |
| 66 | + - Please follow our [Commit Messages](#commit-messages) guidance. |
| 67 | +1. Add new tests corresponding to your change, if applicable. |
| 68 | +1. Build the repository with your changes. |
| 69 | + - Make sure that the builds are clean. |
| 70 | + - Make sure that the tests are all passing, including your new tests. |
| 71 | +1. Create a pull request (PR) against this repository's main branch. |
| 72 | + - Push your changes to your fork on GitHub (if you haven't already). |
| 73 | + - Note: It is okay for your PR to include a large number of commits. Once your change is accepted, you will be asked to squash your commits into one or some appropriately small number of commits before your PR is merged. |
| 74 | + - Note: It is okay to create your PR as "[WIP]" before the implementation is done. This can be useful if you'd like to start the feedback process while you're still working on the implementation. State that this is the case in the initial PR comment. |
43 | 75 |
|
44 | | -* [Setup and build environment](docs/developer_guide.md#Prerequisites) |
45 | | -* [Source code structure](docs/source_code_structure.md) |
46 | | -* [Contribution workflow](docs/contribution_workflow.md) |
47 | | -* [Coding style and conventions](docs/code_style_and_conventions.md) |
| 76 | +### Contribution Bar |
| 77 | +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). |
48 | 78 |
|
49 | | -### Contributor License Agreement |
| 79 | +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. |
50 | 80 |
|
| 81 | +### Contributor License Agreement |
51 | 82 | Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com. |
52 | 83 |
|
53 | 84 | When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA. |
54 | 85 |
|
55 | 86 | ### Copying files from other projects |
56 | | - |
57 | 87 | The following rules must be followed for PRs that include files from another project: |
| 88 | +- The license of the file is [permissive](https://en.wikipedia.org/wiki/Permissive_free_software_licence). |
| 89 | +- The license of the file is left intact. |
| 90 | +- The contribution is correctly attributed in the [3rd party notices](https://github.com/dotnet/coreclr/blob/master/THIRD-PARTY-NOTICES.TXT) file in the repository, as needed. |
| 91 | + |
| 92 | +## Commit Messages |
| 93 | +Please format commit messages as follows (based on [A Note About Git Commit Messages](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)): |
| 94 | + |
| 95 | +``` |
| 96 | +Summarize change in 50 characters or less |
| 97 | +
|
| 98 | +Provide more detail after the first line. Leave one blank line below the |
| 99 | +summary and wrap all lines at 72 characters or less. |
| 100 | +
|
| 101 | +If the change fixes an issue, leave another blank line after the final |
| 102 | +paragraph and indicate which issue is fixed in the specific format below. |
| 103 | +
|
| 104 | +Fix #42 |
| 105 | +``` |
| 106 | + |
| 107 | +## Checks |
| 108 | +Each pull request to main must pass the following checks: [WinUI-Public-MUX-PR](https://dev.azure.com/ms/microsoft-ui-xaml/_build?definitionId=21) |
58 | 109 |
|
59 | | -* The license of the file is [permissive](https://en.wikipedia.org/wiki/Permissive_free_software_licence). |
60 | | -* The license of the file is left intact. |
61 | | -* The contribution is correctly attributed in the [3rd party notices](https://github.com/dotnet/coreclr/blob/master/THIRD-PARTY-NOTICES.TXT) |
62 | | -file in the repository, as needed. |
| 110 | +This pipeline builds your change and runs automated tests. These tests should match what you're able to run with local automated testing using Test Explorer. It also creates a NuGet package to match your change. |
63 | 111 |
|
64 | | -## Documentation and usage samples |
| 112 | +The license/cla check confirms that you have completed the [CLA](https://cla.microsoft.com/). |
65 | 113 |
|
66 | | -You can also read and contribute to the WinUI documentation here: |
67 | | -https://docs.microsoft.com/uwp/toolkits/winui |
| 114 | +Pull requests from a fork will not automatically trigger all of these checks. A member of the WinUI team can trigger the Azure Pipeline checks by commenting /azp run on the PR. The Azure Pipelines bot will then trigger the build. |
68 | 115 |
|
69 | | -You can find usage examples of the controls available in WinUI in the WinUI 3 Gallery app: |
70 | | - https://github.com/Microsoft/WinUI-Gallery/ |
| 116 | +In order to have PRs automatically merge once all checks have passed (including optional checks), maintainers can apply the [auto merge](https://github.com/Microsoft/microsoft-ui-xaml/labels/auto merge) label. It will take effect after an 8 hour delay. |
71 | 117 |
|
72 | | - Which can also be installed from the Microsoft Store: |
73 | | - https://apps.microsoft.com/detail/9p3jfpwwdzrc |
74 | | - |
75 | | - ## API spec discussions |
| 118 | +### Other Pipelines |
| 119 | +Unlike the above checks these are not required for all PRs, but you may see them on some PRs: [WinUI-Public-MUX-CI](https://dev.azure.com/ms/microsoft-ui-xaml/_build?definitionId=20) |
76 | 120 |
|
77 | | -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. |
| 121 | +This pipeline extends [WinUI-Public-MUX-PR](https://dev.azure.com/ms/microsoft-ui-xaml/_build?definitionId=21) to validate more platforms, adding Debug and ARM. It is run after your changes are merged to main. |
| 122 | +s |
0 commit comments