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 untriaged issues (sorted by age)
- Newest incoming issues
- Busy untriaged 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.
- Stack Overflow.
- 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.
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
triage/duplicate
. - 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
triage/needs-information
.
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.
We use two labels help wanted and good first issue to identify issues that have been specially curated for new contributors.
The 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.
-
Solution Explained
The recommended solution is clearly described in the issue.
-
Provides Context
If background knowledge is required, this should be explicitly mentioned and a list of suggested readings included.
-
Gives Examples
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
help wanted
task!
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-evidence
label 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.
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 logcat?
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.
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/backlog
label 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.
@[NAME] please open a new issue and fill out the issue template so that we're better able to help you.
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.