GitHub issue templates

[Atreya Shankar]

Currently, we do not use an issue template. This issue proposes the introduction of an issue template which lists certain tasks that should be completed before filing an issue. These could include:

1. Ticking a box the user checked for similar issues and could not find any
2. Listing downgrade version
3. Running bash -x on the downgrade command that was running into errors, if any

PS: Would it be useful for us to have a downgrade --version CLI option, such that users could easily check the version without having to go through pacman? I personally like the idea and think this could be another issue worth opening.

[Pat Brisbin]

👍 for --version.

[Atreya Shankar]

Hi Patrick (hope it's alright by first name basis). To get the ball rolling, I was thinking we could start with this issue.

Regarding the issue template, I realized I am unable to create a template directly because of access restrictions. As per this article, I think only you as the owner are able to edit the templates.

Below are templates I would propose for bug reports and feature requests (sourced and adapted from: https://github.com/stevemao/github-issue-templates/tree/master/checklist2).

Edit: Check the raw version to see markdown comments beneath sections; they provide additional instructions.

Perhaps we could include an additional template for miscellaneous issues (eg. questions, documentation typos, etc.). WDYT?

1. Bug report

### Checklist

* [ ] Did you search the issues/pull-requests for possible duplicates?
* [ ] Are you running the latest `downgrade` release from the [AUR](https://aur.archlinux.org/packages/downgrade/)?

### Environment

* OS and kernel:
<!-- paste the output of `uname -a` -->

* Downgrade version:
<!-- paste the output of `pacman -Qi downgrade` -->

### Description

<!--- Describe the bug you have encountered -->

### Steps to Reproduce

1. First Step
2. Second Step
3. And so on...

### Expected behavior

<!--- What did you expect to happen -->

### Actual behavior

<!--- What actually happened -->

### Command trace

<!--- If relevant, prepend `bash -x` before the erroneous downgrade command (eg. `bash -x downgrade problematic-package` and paste the produced command trace here -->
<!--- If irrelevant, simply delete this section -->

2. Feature request

### Checklist

* [ ] Did you search the issues/pull-requests for possible duplicates?
* [ ] Are you running the latest `downgrade` release from the [AUR](https://aur.archlinux.org/packages/downgrade/)?

### Background

<!--- Provide a short background describing the problem you are facing -->

### Requested feature

<!--- Provide information on the suggested feature(s) which could help address this problem -->

[Atreya Shankar]

Regarding the inclusion of the --version option, I was thinking of the following flow.

1. Upon detection of the --version option, execute pacman -Qm, which will output foreign packages with respective versions. For example:

$ pacman -Qm

aur-release-git 1.0.0-1
clingo 5.4.0-2
cram 0.7-1
downgrade 8.1.1-1
glxinfo 8.4.0-1
...

2. Use sed to grab the downgrade version
3. Output downgrade version and exit zero

WDYT?

[Pat Brisbin]

What if we didn't build --version at all, and just had the Issue Template ask for pacman -Qi downgrade?

Using pacman's version comes with the downside that you might be running a dowgrade installed some other way. I'm OK with that downside, but probably only if we didn't implement our own --version that tried to do it. If we just asked users to supply pacman's version information, they can say if they're installed in some other way. If we build it as --version the user wouldn't know that's happening and we might be supplying the wrong information, or throwing an error, etc, etc.

So IMO we either build a real --version or we just ask the users to give us pacman details. I don't feel strongly which though.

WDYT?

[Atreya Shankar]

Ah that is true, seems more efficient to not build a separate --version and just do as you mentioned with the issue template.

[Atreya Shankar]

PS: Updated the templates with the raw text instead so you can also copy the markdown comments. Not sure whether the user should provide the output of pacman -Qi downgrade (verbose) or pacman -Q downgrade (less verbose; one-liner). I don't have a strong preference so you can decide that.