Issue template form

[redstonedesigner]

This pull request removes the old file, located at .github/issue_template.md (this is a legacy method of defining issue templates).
The new method of creating an issue template also allows for forms to be created when users are submitting an issue. When creating the issue template, I have used the current issue template as closely as possible.
This pull request also disables blank issue creation, meaning that all new issues must use the form(s) configured to submit an issue.

This form can be tested by going to https://github.com/redstonedesigner/gitea-issue-form-testing and creating a new issue.

[delvh]

Well done 👍

[redstonedesigner]

Thank you for the feedback @delvh - I believe I have addressed your comments in my most recent commit. The test repository has also been updated with the latest version of this template.

Please let me know if you have any further input.

[redstonedesigner]

Just had a thought - Would there be any further issue types that would require more specific information or additional information?

With the new issue template system, it is possible to customise the experience for the user depending on the type of error they are experiencing. It is also possible to use labels in the templates, which would be added depending on the form that's submitted.

[delvh]

Yes, while that is definitely possible and should be implemented sometime, I think that's beyond the scope of this PR.
Unless of course you do want to do it now.

[redstonedesigner]

If we're changing the workflow for creating issues in this PR, I feel like it might be worth making all the changes in this PR to avoid multiple PRs for a similar issue.
I'm happy to do it now, just let me know what other issue forms you would like added and I can get them configured.

[delvh]

Well okay, then I would first recommend a second template for Feature Requests.
This would be pretty basic and most likely only contain one or two sections: a) the description of this feature (this can be required) and b) an area to show optional screenshots (i.e. of the GitHub implementation or a proposed design)

[redstonedesigner]

I've gone ahead and put the feature request form onto the testing repository as well as this PR.

[delvh]

👍

[a1012112796]

How to provide link to try.gitea.io ?

[redstonedesigner]

How to provide link to try.gitea.io ?

You're prompted to include it in the Description field, which is below the Logs field.

[codecov-commenter]

Codecov Report

Merging #16349 (0557cfe) into main (45ebcb0) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main   #16349      +/-   ##
==========================================
- Coverage   45.22%   45.22%   -0.01%     
==========================================
  Files         766      766              
  Lines       86716    86716              
==========================================
- Hits        39217    39214       -3     
- Misses      41148    41151       +3     
  Partials     6351     6351              

Impacted Files	Coverage Δ
models/gpg_key_common.go	59.67% <0.00%> (-4.84%)	⬇️
modules/queue/queue_channel.go	91.66% <0.00%> (-3.34%)	⬇️
modules/queue/workerpool.go	48.09% <0.00%> (-0.39%)	⬇️
modules/queue/queue_disk_channel.go	62.72% <0.00%> (+1.77%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 45ebcb0...0557cfe. Read the comment docs.

[delvh]

Also, it might be nice to setup the following in the config.yml:

contact_links:
  - name: Security issues
    url/mail: [email protected]
    about: If your issue is security related, please write a mail to [email protected] instead of opening an issue

Or something similar, so that the user does not even get the idea to open a public security related issue.
However, I do not know whether GitHub supports mail addresses here, or whether they get problematic. You'll have to try whether that can actually be done, or whether that is yet impossible.

[redstonedesigner]

Also, it might be nice to setup the following in the config.yml:

contact_links:
  - name: Security issues
    url/mail: [email protected]
    about: If your issue is security related, please write a mail to [email protected] instead of opening an issue

Or something similar, so that the user does not even get the idea to open a public security related issue.
However, I do not know whether GitHub supports mail addresses here, or whether they get problematic. You'll have to try whether that can actually be done, or whether that is yet impossible.

I would have to use url: mailto:[email protected], which I believe might be problematic in terms of rendering. I will give it a go on the testing repository and determine how it works.

[redstonedesigner]

It appears there's a URL parser that validates that the URL is indeed a web URL (e.g. prefixed with https://).

As a result, I don't believe that what you're suggesting is possible.

[delvh]

That's a pity. This approach would have been much more intuitive than hiding that information inside the bug report as a comment… Who knows, maybe one day GitHub will add this as well?

[redstonedesigner]

It is less than ideal. However I'm hoping that by positioning the email address at the very top of the bug report form should get their attention.

[redstonedesigner]

Does anyone have any further input on this?