Triaging Enhancements and Automation

[yusufkandemir]

RFC (Request for Comments) Template

Type of RFC

• Method

Other

• Start Date: 2021-09-08 (YYYY-MM-DD)
• Target Major Version: N/A
• Reference Issues: (there are no issues, yet)

Does this introduce a breaking change?

• N/A

Proposed RFC

Request Management Flow (bugs, feature requests, etc.)

Issue Template Changes

See the test repo: https://github.com/yusufkandemir/github-issue-form-test

Issue Forms

GitHub has a new feature called Issue Forms, which allow creating forms with validation and stuff for creating an issue, which is very useful since a lot of users don't fill in the template as we want to be. I converted our issue template to a form and made some extra changes to improve the quality and prepare for some future plans to work with bots, like automatically labeling or assigning people, looking at the selected options, etc.

You can check the test repo to see how created issues look like, and try to create new issues to experience how it feels like to create new issues with the form

Issue Template Chooser

GitHub has a thing called Issue Template Chooser, it allows choosing different templates between bug reports, feature requests, etc. when creating an issue. We are currently using it on our repo for issue and feature requests for Qv1 and Qv2 respectively. It is configurable, so I have gone ahead and disabled the creation of blank issues, and added extra entries explaining and redirecting to our other channels like GitHub Discussions and Quasar Discord Server.

Please ignore the plain Bug report entry, it's for testing purposes

Updates to Feature Request Flow

We will get rid of the Feature Request type when creating new issues, and we will redirect users to use the Ideas/Proposals section in Discussions instead. After a post gets enough interaction, has enough information to get implemented, and gets approved by our staff, we will convert the discussion to an issue. Then we or someone else can create a PR referencing that issue.

Bots and Automation

I made some thinking and research, inspected a lot of bots, and selected these bots among them to be useful for Quasar:

• Stale: Close stale Issues and Pull Requests
  • We will set daysUntilClose to false to disable auto-close, as per @pdanpdan's recommendation.
• No Response: Close issues where the author hasn't responded to a request for more information
• Welcome: Welcomes new users
  • Could be useful for increasing interactivity and encouraging new contributors
• Release Drafter: Drafts your next release notes as pull requests are merged into master.
• Prosebot: Probot App to help you write better on GitHub.
  • Spelling, prose, etc. checking. It will be especially useful for reviewing documentation changes
• Boring Cyborg: Add labels on PRs based on the FilePaths & Welcome First time users & much more
  • Issue labeling based on the path (apply area/app label when changes are made to app/ folder for example
  • Welcoming and encouraging new contributors (we can use this instead of the welcome bot)
  • Verifies commits and PR titles to match regex (optional)
  • Checks if PR is up to date with the branch
• Ranger: A sidekick for repo maintainers. It reduces the burden of repository maintenance by automating common tasks.
  • Reply with specific answers depending on the labels(configurable), an example scenario:
    • A user opens an issue asking for IE11 support, a human tags the issue with no-ie11, then the bot automatically comments as "IE11 support is not considered, please go see this issue for more information and closes the issue")
    • We can find better use-cases.
    • We can use it to reply to questions and help requests to redirect users to other suitable channels.
  • It can automatically close issues when marked as duplicate, wontfix, etc.
  • Can label the issue/PRs of GitHub sponsors, we can use this to prioritize issues of sponsors.
    • But it applies the same tags to all sponsors.
    • So, we can create our own bot for this feature to check for different labels for different tiers, if needed.
    • I think this approach may result in a good impact on potential sponsors that are seeking direct benefits.

[rstoenescu]

@yusufkandemir

https://github.com/yusufkandemir/github-issue-form-test looks awesome!!!
Please do PR using Form Issues to our main repo.

Great stuff!!

[Evertvdw]

@yusufkandemir Looks great! Maybe an addition, would it be possible to let users select the relevant components when creating an issue and give that issue a label? That way we could quickly categorize issues by component for testing purposes, see where we need to focus on with unit testing and such.

[IlCallo]

would it be possible to let users select the relevant components when creating an issue and give that issue a label

@Evertvdw unluckily, there's a max number of labels for each repo, and we already hit it, so this isn't feasible

[yusufkandemir]

@IlCallo that only applies for Discussions. For Issues/PRs, I don't think there is a limit. I saw some repositories with almost 400 labels before, e.g. https://github.com/prisma/prisma/labels.

However, I found it will be bad for UX and management because of the following reasons:

• GitHub Issue Forms don't allow filtering/auto-completion on select fields, which makes it harder for users to find the components they are looking for.
• You can't limit the number of options that can be selected, which means there can be users who may intentionally or unintentionally abuse this. Considering the number of components we have, the outcome will not be fun.
• You can't show the fields conditionally, which makes the form longer with every field we add. This means the form becomes to look more distracting and overwhelming.

So, if we think of having a label for each component, we can create them and manually label issues when we see fit. But, especially for short-lived issues, we may easily forget to label them, especially since the issue title usually has the component name. But, that's my opinion. Please let me know if you think creating a new form field now is still worth it despite the disadvantages above. If not, we can manually label the issues, wait until GitHub Issue Forms brings those features, or scrap the idea.

[rstoenescu]

Can this be closed?

[IlCallo]

AFAIK the whole automations/bots section haven't been implemented yet, we just added issue forms and a not much else
If you green-light that section (or some points of that section) as you did for issue forms, we can work on adding those too and lift up some issues management hassle

[rstoenescu]

Green light. Yes!