Description
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
tofalse
to disable auto-close, as per @pdanpdan's recommendation.
- We will set
- 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 toapp/
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
- Issue labeling based on the path (apply
- 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.
- A user opens an issue asking for IE11 support, a human tags the issue with
- 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.
- Reply with specific answers depending on the labels(configurable), an example scenario: