Guidelines for issue triage

Purpose

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:

Scope

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

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.

Support requests

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:

Organizations that want a deeper level of support beyond community support should be directed to contact Uno Platform 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 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.

Closing issues

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.

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!

Quick Replies

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.

already fixed

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 inactive

Closing this out due to inactivity. @[NAME] if you're able to provide the requested information we're happy to revisit the issue.

duplicate

Thanks for taking the time to contribute!

We noticed that this is a duplicate of [ISSUE URL]. Please follow that issue for further updates.

future proposal

Thanks for the suggestion!

This idea is interesting for the future, but this is beyond the scope of our current roadmap.

We 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 logcat?

needs template

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!

no response

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 help wanted 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.

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.

Acknowledgements