Guidelines for issue triage
Speed up issue management.
The detailed list of labels can be found at https://github.com/unoplatform/uno/labels.
While working on triaging issues, you may not have the privilege to assign a specific label and in that case add a comment in the issue with your findings.
Here are a few predetermined searches on issues for convenience:
- Longest un-triaged issues (sorted by age)
- Newest incoming issues
- Busy un-triaged issues (sorted by number of comments)
- Issues that need more attention
These guidelines serves as a primary document for triaging incoming issues to Uno. Maintainers and contributors are encouraged to either use these guidelines, or use this as a starting point if necessary.
Security related matters should be disclosed in private as per our policy on GitHub. If a security matter is raised as an issue, please capture the relevant information, delete the GitHub issue and follow up via email. This tool can be used to find (almost) any GitHub user's email address.
These issues should be directed to our support structures (see below) and then closed but before doing so consider why the support request was raised.
Is something unclear? Do we need to improve our documentation or samples?
Community support requests should be directed to:
- Our documentation and troubleshooting guide.
- GitHub Discussions
- The Discord Channel #uno-platform
- On Twitter using the #unoplatform hashtag.
Organizations that want a deeper level of support beyond community support, should be directed to contact unoplatform to discuss obtaining professional support.
Validate if the issue is a bug
Confirm if the problem is a bug by reproducing it. If a test case has not been supplied, ask the reporter to supply one. You may need to contact the issue reporter in the following cases:
- Do a quick duplicate search to see if the issue has been reported already. If a duplicate is found, let the issue reporter know it by marking it duplicate. Label such issues as
- If you can not reproduce the issue, label it as a
triage/not-reproducible. Contact the issue reporter with your findings and close the issue if both the parties agree that it could not be reproduced.
- If you need more information to further work on the issue, let the reporter know it by adding an issue comment followed by label
In all cases, if you do not get a response in 20 days then close the issue with an appropriate comment.
Issues that are identified as a support request, duplicate, not-reproducible or lacks enough information from reporter should be closed using the following guidelines explained in this file. Also, any issues that can not be resolved because of any particular reason should be closed. These issues should have one or more of following self-readable labels:
triage/duplicate: Indicates an issue is a duplicate of other open issue.
triage/not-reproducible: Indicates an issue can not be reproduced as described.
triage/needs-information: Indicates an issue needs more information in order to work on it.
Help Wanted issues
We use two labels help wanted and good first issue to identify issues that have been specially curated for new contributors.
good first issue label is a subset of
help wanted label, indicating that members have committed to providing extra assistance for new contributors. All
good first issue items also have the
help wanted label.
Items marked with the
good first issue label are intended for first-time
contributors. It indicates that members will keep an eye out for these pull
requests and shepherd them through our processes.
New contributors should not be left to find an approver, ping for reviews or identify that their build failed due to a flake.
This makes new contributors feel welcome, valued, and assures them that they will have an extra level of help with their first contribution.
After a contributor has successfully completed 1-2
good first issue's, they should be ready to move on to
help wanted items, saving remaining
good first issue's for other new contributors.
These items need to ensure that they follow the guidelines for
help wanted labels (above) in addition to meeting the following criteria:
No Barrier to Entry
The task is something that a new contributor can tackle without advanced setup, or domain knowledge.
The recommended solution is clearly described in the issue.
If background knowledge is required, this should be explicitly mentioned and a list of suggested readings included.
Link to examples of similar implementations so new contributors have a reference guide for their changes.
Identifies Relevant Code
The relevant code and tests to be changed should be linked in the issue.
Ready to Test
There should be existing tests that can be modified, or existing test cases fit to be copied. If the area of code doesn't have tests, before labelling the issue, add a test fixture. This prep often makes a great
When commenting on an issue or pull request, there's a feature in GitHub where you can add a saved reply that you've already set up. The saved reply can be the entire comment or if you want to customize it, you can add or delete content. Below you'll find some suggestions that maintainers and contributors can use as a starting point.
Thanks for reporting this!
This has already been fixed in [INSERT URL OF PR HERE]. It should be available in version [VERSION NUMBER HERE].
Closing this out due to inactivity. @[NAME] if you're able to provide the requested information we're happy to revisit the issue.
Thanks for taking the time to contribute!
We noticed that this is a duplicate of [ISSUE URL]. Please follow that issue for further updates.
Thanks for the suggestion!
This idea is interesting for the future, but this is beyond the scope of our current roadmap.
I've added the
priority/awaiting-more-evidencelabel to this issue and will keep it open until there's more evidence. If you believe this to be incorrectly prioritized, please do let us know and we will evaluate your counter-proposal. If you want to contribute the implementation, please tell the maintainers that you are willing to send in a pull-request and we'll do everything we can to bring you up to speed with becoming a contributor.
needs information or reproduction (android)
Thanks for the report!
Specific things I'd like to learn about are what Android API level you are using and if you are testing in a simulator or on a device.
Could you please provide a test case that reproduces the issue and provide logs from
Thanks for reaching out!
We require the template to be filled out when submitting all issues. We do this so that we can be certain we have all the information we need to address your submission efficiently. This allows the maintainers to spend more time fixing bugs, implementing enhancements, and reviewing and merging pull requests.
Thanks for understanding and meeting us halfway!
Thank you for your issue!
We haven't gotten a response to our questions in our comment [insert URL here]. With only the information that is currently in the issue, we don't have enough information to take action. I'm going to close this but don't hesitate to reach out if you have or find the answers we need, we'll be happy to reopen the issue.
not a priority
Thanks for the suggestion @[NAME]!
This would be good to have, but we may not have anyone available to work on it right now or in the immediate future.
I've added the
priority/backloglabel to this issue and community contributions would be most welcome in the meantime. If you want to contribute the implementation, please tell the maintainers that you are willing to send in a pull-request and we'll do everything we can to bring you up to speed with becoming a contributor.
open a new issue
@[NAME] please open a new issue and fill out the issue template so that we're better able to help you.
send in a pull-request
This would be good to have and we'd love it if you or someone from the community could contribute the implementation. Please let us know if you want to send in the PR and we'll do everything we can to bring you up to speed with becoming a contributor.
- This document was based off the Kubernetes community sig guidelines.