|
| 1 | +# Issue Guide |
| 2 | + |
| 3 | +This page outlines how WPF team thinks about and handles issues. |
| 4 | +For us, issues on GitHub represent actionable work that should be done at some future point. |
| 5 | +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. |
| 6 | + |
| 7 | +We will keep issues open even if the WPF team internally has no plans to address them in an upcoming release, as long as we believe they are in line with our direction. |
| 8 | + |
| 9 | + |
| 10 | + |
| 11 | +## How to file issues |
| 12 | + |
| 13 | +You can help us streamline our response time to your feedback and ideas by filing high-quality reports. |
| 14 | + |
| 15 | +### High-quality bugs |
| 16 | + |
| 17 | +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. |
| 18 | + |
| 19 | +* Include a minimal repro in your bug if at all possible (chop off dependencies, remove as much code as possible). If it is not possible, say why. |
| 20 | + * 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 small repros are easier for us to reproduce/investigate and therefore have higher chance to be addressed quickly. |
| 21 | +* Include callstacks, symptom description, or what is the difference between actual and expected behavior. |
| 22 | + |
| 23 | +### High-quality features and API suggestions |
| 24 | + |
| 25 | +Provide clear description of your suggestion. Explain scenarios in which it would be helpful and why (motivation). |
| 26 | +Ideally, assume that the reader has minimal knowledge and experience with writing apps/libraries that would benefit from the feature. |
| 27 | + |
| 28 | +For API suggestions, check [API review process](https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/api-review-process.md), especially [example of good API proposals](https://github.com/dotnet/corefx/issues/271). |
| 29 | + |
| 30 | + |
| 31 | + |
| 32 | +## Labels |
| 33 | + |
| 34 | +We use GitHub [labels](https://github.com/dotnet/wpf/labels) on our issues in order to classify them. We have the following categories per issue: |
| 35 | + |
| 36 | +* **Issue Type**: These labels classify the type of issue. We use the following types: |
| 37 | + * [api-suggestion](https://github.com/dotnet/wpf/labels/api-suggestion): Issues which would add new APIs (see [API Review process](https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/api-review-process.md) for details). |
| 38 | + * Note: WPF API process is not finalized yet. We may need to add additional UI-specific steps to it (e.g. accessibility review). Expect finalized API review process post-3.0 when we will be ready to take new APIs. |
| 39 | + * [bug](https://github.com/dotnet/wpf/labels/bug), [enhancement](https://github.com/dotnet/wpf/labels/enhancement), [test-bug](https://github.com/dotnet/wpf/labels/test-bug), [test-enhancement](https://github.com/dotnet/wpf/labels/test-enhancement), [question](https://github.com/dotnet/wpf/labels/question), [documentation](https://github.com/dotnet/wpf/labels/documentation): See [label description](https://github.com/dotnet/wpf/labels) for details. |
| 40 | +* **Other**: |
| 41 | + * [up-for-grabs](https://github.com/dotnet/wpf/labels/up-for-grabs): Smaller sections of work which we believe are well scoped. These sorts of issues are a good place to start if you are new. Anyone is free to work on these issues. |
| 42 | + * [needs-more-info](https://github.com/dotnet/wpf/labels/needs-more-info): Issues which need more information to be actionable. Usually this will be because we can't reproduce a reported bug. We'll close these issues after a little bit if we haven't gotten actionable information, but we welcome folks who have acquired more information to reopen the issue. |
| 43 | + * [tenet-compatibility](https://github.com/dotnet/wpf/labels/tenet-compatibility): Incompatibility between relesed versions or with WPF for .NET Framework. |
| 44 | + |
| 45 | + |
| 46 | + |
| 47 | +## Milestones |
| 48 | + |
| 49 | +We use [milestones](https://github.com/dotnet/wpf/milestones) to prioritize work for each upcoming release. |
| 50 | + |
| 51 | +* **3.0** milestone work is focused on parity with WPF for .NET Framework. We do not plan to take contributions or address issues that are not unique to WPF on .NET Core in 3.0 release. For example: |
| 52 | + * Bugs which are present on both WPF platforms (for .NET Core and .NET Framework) will be put into **Future** milestone and will be reviewed and prioritized after 3.0 final release. |
| 53 | + * Requests for new APIs and features will be put into **Future** milestone and will be reviewed and prioritized after 3.0 final release. |
| 54 | +* **Future** milestone tracks all potential future work (which may or may not happen). When we are done with 3.0 release, we will move some of these issues into the next immediate milestone. |
| 55 | + * Please do not start discussions about next post-3.0 milestone until we are close to final 3.0 release. If you want to express your opinion on prioritization, please [upvote first post of the issue](#upvotes-on-issues) instead. |
| 56 | + |
| 57 | + |
| 58 | + |
| 59 | +## Assignee |
| 60 | + |
| 61 | +We assign each issue to assignee, when the assignee is ready to pick up the work and start working on it. |
| 62 | +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. |
| 63 | +If the issue is already assigned to someone, please coordinate with the assignee before you start working on it. |
| 64 | + |
| 65 | + |
| 66 | + |
| 67 | +## Upvotes on issues |
| 68 | + |
| 69 | +Upvotes on first post of each issue are useful hint for our prioritization. |
| 70 | +We can [sort issues by number of upvotes](https://github.com/dotnet/wpf/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc) and we will review the top list on regular basis. |
| 71 | + |
| 72 | + |
| 73 | + |
| 74 | +## Escalations |
| 75 | + |
| 76 | +If you think some issue or PR is not getting the right attention, or if you notice some [Code of Conduct](https://dotnetfoundation.org/code-of-conduct) violation we might miss, |
| 77 | +you can escalate to WPF team by tagging some of us (e.g. [@fabiant3](https://github.com/fabiant3), [@karelz](https://github.com/karelz)). Please do not overuse it. |
| 78 | + |
| 79 | + |
| 80 | + |
| 81 | +## Triage rules |
| 82 | + |
| 83 | +Guidance for triaging issues for WPF team members: |
| 84 | + |
| 85 | +1. Issue has no **Assignee**, unless someone is working on the issue at the moment. |
| 86 | +1. Use **up-for-grabs** as much as possible, ideally with a quick note about next steps / complexity of the issue. |
| 87 | +1. Set milestone to **Future**, unless you can 95%-commit you can fund the issue in specific milestone. |
| 88 | +1. Each issue has exactly one "*issue type*" label (**bug**, **enhancement**, **api-suggestion**, **test-bug**, **test-enhancement**, **question**, **documentation**, etc.). |
| 89 | +1. Don't be afraid to say no, or close issues - just explain why and be polite. |
| 90 | +1. Don't be afraid to be wrong - just be flexible when new information appears. |
| 91 | + |
| 92 | +Feel free to use other labels if it helps your triage efforts (e.g. **needs-more-info**, **design-discussion**, **tenet-compatibility**, etc.). |
| 93 | + |
| 94 | +### Motivation for triage rules |
| 95 | + |
| 96 | +1. Issue has no **Assignee**, unless someone is working on the issue at the moment. |
| 97 | + * Motivation: Observation is that contributors are less likely to grab assigned issues, no matter what the repo rules say. |
| 98 | +1. Use **up-for-grabs** as much as possible, ideally with a quick note about next steps / complexity of the issue. |
| 99 | + * Note: Per http://up-for-grabs.net, such issues should be no longer than few nights' worth of work. They should be actionable (i.e. no mysterious CI failures that can't be tested in the open). |
| 100 | +1. Set milestone to **Future**, unless you can 95%-commit you can fund the issue in specific milestone. |
| 101 | + * Motivation: Helps communicate desire/timeline to community. Can spark further priority/impact discussion. |
| 102 | +1. Each issue has exactly one "*issue type*" label (**bug**, **enhancement**, **api-suggestion**, **test-bug**, **test-enhancement**, **question**, **documentation**, etc.). |
| 103 | + * 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'. |
| 104 | +1. Don't be afraid to say no, or close issues - just explain why and be polite. |
| 105 | +1. Don't be afraid to be wrong - just be flexible when new information appears. |
| 106 | + |
| 107 | +### PR guidance |
| 108 | + |
| 109 | +1. Dont't set any labels on PRs. They are superfluous and not needed (exceptions: **NO MERGE**). |
| 110 | + * Motivation: All the important info (*issue type* label, API approval label, etc.) is already captured on the associated issue. |
| 111 | +1. Push PRs forward, don't let them go stale (response every 5+ days, ideally no PRs older than 2 weeks). |
| 112 | +1. Close stuck or long-term blocked PRs (e.g. due to missing API approval, etc.) and reopen them once they are unstuck. |
| 113 | + * 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. |
| 114 | +1. Link PR to related issue via [auto-closing](https://help.github.com/articles/closing-issues-via-commit-messages/) (add "Fixes #12345" into your PR description). |
0 commit comments