This page outlines how WinForms team thinks about and handles issues. For us, issues on GitHub represent actionable work that should be done at some future point. It may be as simple as a small product or test bug or as large as the work tracking the design of a new feature.
We will keep issues open even if the WinForms team internally has no plans to address them in an upcoming release, as long as we believe they are in line with our direction.
You can help us streamline our response time to your feedback and ideas by filing high-quality reports.
If you encounter an issue using the latest .NET 5.0 SDK, please:
- Explore this repositories issues, and then
- Open a new issue if there is none.
In general, try to be specific. Get straight to the main point. Leave additional details, options, and alternatives to the end (hint: separate them visually). Don't write long bug reports, unless you have to.
- Include a minimal reproduction (repro) in your bug if at all possible (chop off dependencies, remove as much code as possible). If it is not possible, say why.
⚠️ Note: Yes, it may take some time to minimize a repro from your larger app - but that is exactly what we would do in most cases anyway. Issues with clear, concise reproduction guidelines are easier for us to investigate; such issues will have higher chance of being addressed quickly. - Include call-stacks, symptom descriptions, and differences between actual and expected behaviors.
Assume that the reader has minimal knowledge and experience with writing apps/libraries that would benefit from the feature, so try and write to that audience. Provide clear description of your suggestion, and explain scenarios in which it would be helpful and why (motivation).
Prepare code examples that showcase the need and general usefulness of the proposal. Specifically:
- Code that shows the surface area of the API.
- Code that shows real world scenarios, and how they would otherwise be handled.
- Details showing the usage/consumption of the proposed new package, and alternatives (e.g. not having this be a separate package).
Here are few example of a good API proposal:
We assign each issue to assignee, when the assignee is ready to pick up the work and start working on it. If the issue is not assigned to anyone and you want to pick it up, please say so - we will assign the issue to you. If the issue is already assigned to someone, please coordinate with the assignee before you start working on it.
Up-votes on first post of each issue are useful hint for our prioritization. We can sort issues by number of up-votes, and we will review the top list on a regular basis.
Guidance for triage of issues for Windows Forms team members:
- Issue has no Assignee, unless someone is working on the issue at the moment.
- Use up-for-grabs as much as possible, ideally with a quick note about next steps / complexity of the issue.
- Set milestone to Future, unless you can 95%-commit you can fund the issue in specific milestone.
- Each issue has exactly one "issue type" label (bug, enhancement, api-suggestion, test-bug, test-enhancement, question, documentation, etc.).
- Don't be afraid to say no, or close issues — just explain why and be polite.
- Don't be afraid to be wrong - just be flexible when new information appears.
Feel free to use other labels if it helps your triage efforts (for example, needs-more-info, design-discussion, tenet-compatibility, etc.).
-
Issue has no Assignee, unless someone is working on the issue at the moment.
- Motivation: Observation is that contributors are less likely to grab assigned issues, no matter what the repository rules say.
-
Use up-for-grabs as much as possible, ideally with a quick note about next steps / complexity of the issue.
NB: Per https://up-for-grabs.net, such issues should be no longer than few nights' worth of work. They should be actionable (that is, no mysterious CI failures that can't be tested in the open). -
Set milestone to Future, unless you can 95%-commit you can fund the issue in specific milestone.
- Motivation: Helps communicate desire/timeline to community. Can spark further priority/impact discussion.
-
Each issue has exactly one "issue type" label (bug, enhancement, api-suggestion, test-bug, test-enhancement, question, documentation, etc.).
- Don't be afraid to be wrong when deciding 'bug' vs. 'test-bug' (flip a coin if you must). The most useful values for tracking are 'api-*' vs. 'enhancement', 'question', and 'documentation'.
Each PR has to have reviewer approval from at least one Windows Forms team member who is not author of the change, before it can be merged.
-
Please don't set any labels on PRs.
- exceptions:
- NO-MERGE may be supplied by the WinForms team in order to indicate that the PR should be halted; a reason should be given in the comments
- waiting-on-testing may be supplied by the WinForms team to inform the PR author(s) that their PR is being delayed due to internal, manual testing; this action does not require action by the author(s).
- Motivation: All the important info (issue type label, API approval label, etc.) is already captured on the associated issue.
- exceptions:
-
Push PRs forward, don't let them go stale (response every 5+ days, ideally no PRs older than 2 weeks).
-
Close stuck or long-term blocked PRs (for example, due to missing API approval, etc.) and reopen them once they are unstuck.
- **Motivation: Keep only active PRs. WIP (work-in-progress) PRs should be rare and should not become stale (2+ weeks old). If a PR is stale and there is not immediate path forward, consider closing the PR until it is unblocked/unstuck.
-
Link PR to related issue via auto-closing (add "Fixes #12345" into your PR description).