.github/ISSUE_TEMPLATE: add bug report and package request issue forms

[classabbyamp]

Co-authored-by: @0x5c

This PR replaces the existing markdown-based issue template with two new Github issue forms, one for bug reports and one for package requests.

These ensure that the relevant information is asked for and the required information is provided. They also automagically tag issues with the bug and request tags. If preferred, new bug reports could be also be marked with a second unconfirmed or needs triage label, applied by the form.

Issues that do not fall under these types (like RFCs) can still be opened by clicking the "open a blank issue" button on the template chooser:

This can be limited to maintainers by changing blank_issues_enabled to false in .github/ISSUE_TEMPLATE/config.yml if desired.

config.yml can also be used to add additional arbitrary links in the template chooser. Here's an example config.yml and resulting template chooser in another project.

Testing the changes

• I tested the changes in this PR: YES
  A preview of the rendered templates can be seen here

[paper42]

I think it would be nice to have a checkbox for electron applications that would add the electron tag and maybe an option (and a new tag) for proprietary software.

[paper42]

I don't like that we have a lot of static text in the request issue template. The whole "Quality Requirements" section could be replaced with a link to Contributing.md.

[classabbyamp]

I think it would be nice to have a checkbox for electron applications that would add the electron tag and maybe an option (and a new tag) for proprietary software.

Those could definitely be included as checkboxes, but it's beyond the scope of issue forms to dynamically add tags like that. The new issue automation can probably do such a thing, but that would require a much larger change (migrating to the new issues/projects entirely). Using a bot that looks for the checkbox/text is another option, which could fit in well with the bot @0x5c has been hacking at that tries to autotag PRs based on changeset contents etc.

I don't like that we have a lot of static text in the request issue template. The whole "Quality Requirements" section could be replaced with a link to Contributing.md.

Should've been a bit more clear there, the explanatory text does not get included in the final issue, it's just for the person filling out the form to read while the form is being filled.

[Chocimier]

Demoed at https://github.com/Chocimier/void-packages-org/issues, anybody feel free to play with.

We could use it, with some remarks:

• free-form issue is too hard to find, consider making it a third template
• checkboxes re-introduce tasks we have just got rid of
• mandatory checkboxes are dumb on their own anyway
• in bug report: there is no need for update of package section
• in bug report: system info should not be mandatory, sometimes it's obvious it doesn't matter
• in bug report: Bug description section should keep it's current name, Actual behavior
• in package request: there should be a field to provide homepage

[0x5c]

I think it would be nice to have a checkbox for electron applications that would add the electron tag and maybe an option (and a new tag) for proprietary software.

As Abby said, that's not directly possible. However, using a bot that looks for a specific variant of a magic string seems prone to breakage.

[0x5c]

• checkboxes re-introduce tasks we have just got rid of

This is behaviour we did not expect, as it was different at some point in the past (simply using text instead of markdown checkboxes). We'll do some tests to see what can be done about that, y/n dropdowns are likely to do the trick

• mandatory checkboxes are dumb on their own anyway

The goal is to limit what can be requested (only released software, which is void's policy on new packages) and limit duplicates reports (which are extra work and are likely to create obsolete reports)

• in bug report: there is no need for update of package section

You're likely to have someone who considers old, but otherwise functioning, versions of packages to be "bugs". That text can be removed but it's not gonna be a meaningful change since it's not rendered in the final issue anyways.

• in bug report: system info should not be mandatory, sometimes it's obvious it doesn't matter

I wonder if it's more obvious to maintainers than to bug reporters, and I suspect that without it being provided, the case it's needed would only be discovered beyond the point the reporter has gone AWOL

• in bug report: Bug description section should keep it's current name, Actual behavior
• in package request: there should be a field to provide homepage

Consider those fixed

[classabbyamp]

Updated to address most of the issues raised, I think. @Chocimier if you want to update your live version, go ahead. The links in the original comment should still work for previewing.

[classabbyamp]

free-form issue is too hard to find, consider making it a third template

We've found a way to make this work without adding a template:

A freeform/blank template is not possible when using issue forms, and a freeform issue form is not really possible (it would have to be a single multi-line input and would add a weird title to the body of the issue). This solution also makes the button to create a blank issue less prominent than the bright green ones for bugs and requests.

The latest updates are available for live preview here: https://github.com/classabbyamp/void-packages-test/issues/new/choose
(note that the current link for freeform issues is pointed to the actual void-packages repo, as it will be after merging. It also currently shows the old issue template since this PR hasn't been merged)

[Chocimier]

Remarks from paper42 to replace quality requirement with link and to not tag are right. Otherwise quite fine for me.

[0x5c]

Remarks from paper42 to replace quality requirement with link and to not tag are right. Otherwise quite fine for me.

That text had to be edited to make it more comprehensible to package requesters, since the manual's wording is heavily intended for those who are writing a template, and mentions things like If you believe you have an exception, start a PR and make an argument for why that particular piece of software, while not meeting any of the following requirements, is a good candidate for the Void packages system., which seems fairly nonconstructive in the context of a package request.

[Chocimier]

edited to make it more comprehensible

I see no meaningful rewording, but if any is needed, please send PR changing proper documentation. Maintaining many copies of same text is not sustainable.

[classabbyamp]

Updated (link goes to quality requirements section).

[classabbyamp]

latest version of this is live here. Any critiques?

[Chocimier]

Quality requirements already say different things here and in contributing.md, can we get rid of the copy?

[classabbyamp]

can we get rid of the copy?

done (assuming you meant manual.md, contributing doesn't list quality requirements)

[Chocimier]

"is this new" checkbox should go first to avoid wasting reporter's time