Skip to content

Conversation

chiaramooney
Copy link

@chiaramooney chiaramooney commented Aug 8, 2025

Description

Update CONTRIBUTING.md to reflect current state of contributing to the WinUI repo.
Delete duplicate docs:

  • docs/contribution_workflow.md (content now included in CONTRIBUTING.md)
  • docs/SECURITY.md (content already contained in ./SECURITY.md)
  • src/*.md
  • src/LICENSE

Motivation and Context

Docs should be simplified, clear, and up-to-date.

How Has This Been Tested?

N/A

Screenshots (if appropriate):

N/A

@microsoft-github-policy-service microsoft-github-policy-service bot added the needs-triage Issue needs to be triaged by the area owners label Aug 8, 2025
@michael-hawker
Copy link
Collaborator

@codendone @azchohfi are the docs in the src folder coming from the repo sync? How should we handle those? In the internal repo can we just remove them since we have them in the root of this repo?

@codendone
Copy link
Contributor

@michael-hawker Nope, these can simply be merged like normal.

@codendone
Copy link
Contributor

@michael-hawker @chiaramooney Oops, correction, the src/ files are mirrored from the internal repo. I thought those were excluded from mirroring, but they aren't, so they'll be overwritten (or added back) on the next mirror. The root and docs/ files are fine.

@chiaramooney
Copy link
Author

chiaramooney commented Aug 14, 2025

@codendone @michael-hawker Makes sense! I'll remove the src/ files from being deleted in this PR. Is there a good spot I could file an issue for removing those docs from the source being mirrored? Would that be on the GitHub repo or in ADO?

CONTRIBUTING.md Outdated
Comment on lines 111 to 114
1. Create an issue for your work.
- You can skip this step for trivial changes or if there is an existing issue for the bug/feature.
- If your change adds or changes public APIs or UI, first follow the [New Feature or API Process](docs/feature_proposal_process.md).
- 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this part is WIP, but I don't this guidance is up to date.

Suggested change
1. Create an issue for your work.
- You can skip this step for trivial changes or if there is an existing issue for the bug/feature.
- If your change adds or changes public APIs or UI, first follow the [New Feature or API Process](docs/feature_proposal_process.md).
- 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.
1. Have an issue tracking what you want to fix.
- If one doesn't already exist, open an issue. But before investing time on a contribution make sure the issue has been triaged and your fix has a chance of being merged.
- If your change adds or changes public APIs or UI, first follow the [New Feature or API Process](docs/feature_proposal_process.md).
- Comment on the issue to indicate your intent to work on it.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, there's a lot of old guidance scattered everywhere, so there's a few different steps in flight to try and get this up-to-date. Part of it too is whether we document how things work now, or more how we want things to work - and then move towards aligning to that as the OSS plan moves forward.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These steps were taken from the original https://github.com/microsoft/microsoft-ui-xaml/blob/main/docs/contribution_workflow.md. As of right now, there isn't a steady cadence of issues being triaged and the repo isn't ready for code contributions, so all of this guidance is speculative.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would delete the entire section and add something later during Phase 3.

@beth-panx beth-panx removed the needs-triage Issue needs to be triaged by the area owners label Aug 15, 2025
CONTRIBUTING.md Outdated
Comment on lines 111 to 114
1. Create an issue for your work.
- You can skip this step for trivial changes or if there is an existing issue for the bug/feature.
- If your change adds or changes public APIs or UI, first follow the [New Feature or API Process](docs/feature_proposal_process.md).
- 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would delete the entire section and add something later during Phase 3.

CONTRIBUTING.md Outdated
Comment on lines 36 to 50
Your feedback is most effective when it is a constructive call to action on the team, and is clear and detailed – especially on the "why" so that we can make sure whatever it is that we arrive at together appropriately focuses on your goal and your intended outcome from start to finish.

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).
**Examples of constructively phrased feedback:**

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.
Instead of:

### Code contribution process
- The state of the platform is disappointing. I am not going to consider WinUI until my trust has been earned.

For details see:
Try this:
- Deprecation of past frameworks has left me burned. The following would go a long way in earning my trust because my company is trying to launch an app next year and will need it supported for at least 5 more: 
- OSS
- High-confidence 5-year roadmap
- Guaranteed support timeline

* [Setup and build environment](docs/developer_guide.md#Prerequisites)
* [Source code structure](docs/source_code_structure.md)
* [Contribution workflow](docs/contribution_workflow.md)
* [Coding style and conventions](docs/code_style_and_conventions.md)
This feedback provides clear actionable items that the WinUI team can take into consideration and address.
Copy link
Contributor

@riverar riverar Aug 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't know what the team would consider a call to action and the example here is outdated and not something you want to encourage folks to submit. (I would delete all this text...) Consider changing the example at least to be more bug focused.

Copy link
Contributor

@codendone codendone left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need a couple small fixes.

CONTRIBUTING.md Outdated
- [help wanted](https://github.com/orgs/microsoft/projects/1868/views/12)

Another great way to help is by up-voting and commenting on feature proposals:
- [feature request](https://github.com/Microsoft/microsoft-ui-xaml/labels/feature%20request)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"feature request"

It looks like there isn't a "feature request" label currently. There is "feature proposal". Is the intent to add and change to "feature request" or is a fix needed here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like that is a pre-existing issue, so that could be fixed later.

@chiaramooney
Copy link
Author

Note commit db9d0ef removes Feeback Section from document. Addressing offline feedback on document.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants