Quick start instructions for reporting issues

[Nazarah]

User Story

Along side APInfs' guideline for contributing to the repository, we should have a default template to help people outside APInf to have a quick start in reporting issues or feature request. Users can always have the time to read through the contribution guideline. However, on specifying a a bug-like behavior, people might want to report it as soon as possible. It wold be always in our hand to decide whether to consider this as bug or existing feature.

Examples:

Here is an example from Automattc/mongoose repository:

An example from ckan/ckan repository

Also a guideline from GitHub

[bajiat]

Where do these projects keep the template?

[Nazarah]

@bajiat Here is the instruction of creating and storing an issue template

In the list of files on the Main page of an repository, a markdown file (e.g. named as issue_template) needs to be created.
In the body of the file, the instructions for adding an issue in the repository can be added.

[brylie]

Thanks for suggesting this. What details would be useful for our issue template to contain? What types of issues do we anticipate people opening?

[Nazarah]

Possible issues can be one of the followings:

1. Feature request - Something a user feels should be included in APInf. This may require giving use cases defending the purpose of the feature request
2. Bug - Here are two user flows.
   a. User may genuinely find a behavior that is breaking the UI or functionality of APInf.
   b. User may find the flow of action of an APInf feature as a bug. This can also be an usability issue.

In any case, APInf development team would have the final rights to decide whether or not to consider to implement a requested feature, put it in icebox for future implementation or suggesting the issue reporter an alternative approach to achieve is work goal using existing APInf features.

For bugs and usability issue, the same approach can be taken. If a seeming bug is normal action flow of APInf feature, some explanation can be given on why this behavior is adopted. We can also add a label for the such bug as won't fix.

Most importantly reported of an issue should be reached with swift feedback from our side. It

[Nazarah]

For requesting a feature @bajiat and I can come with an instruction

For reporting a bug, the user should give the following information

1. Reproduction steps
2. Results
3. Screenshots of UI/log files (preferably in GIF or PNG)
4. Expected Behavior (from user's POV)
5. Environment information - OS, Browser, APInf instance (nightly, staging or production)

[brylie]

Another common type of issue might be support request, e.g. where the user is having a bit of trouble that might not imply a bug or feature. I have opened a lot of support requests in various projects, and am grateful when I get a helpful response.

What details would our template include for each of the issue types?

• feature
• bug
• support

[Nazarah]

@brylie I'll write down instruction drafts for each of the above issue types. I'll proofread the draft for bugs and features with @bajiat and the support request with you. Assigning the task to myself.

[brylie]

Cool beans.

The end goal is basically to have a single issue template, since Github only allows one.

It would be nice if we could use a template for each issue type, to make it as easy as possible for the person submitting the issue.