Update `pull_request_template.md` because:

- It's a kind idea to hide the tips. However, it's easier to include
them in the commit message by mistake when you cannot see them. Check
`git log | grep 'Please check the following:'`. So don't hide it, expose
it and help fix it.
- "for backports" is much clearer than "for bug fixes". I saw someone
post a PR to a release branch because they believed it was the right way
for a bugfix.
- "Allow edits by maintainers", or we have to ask the contributor to
update the branch and they could be confused.
- Remind the contributor that the words could be included in the commit
message, to avoid some words like "Hello", "Sorry". If they really need
them, they can separate them with a line, like:

```markdown
Close #xxxx
Because ... Then ... Finally ...
---
Hello, this is my first time opening a pull request. Sorry for any mistakes.
```
And the merger should be careful, check and delete the extra content
before merging.

---------

Co-authored-by: techknowlogick <techknowlogick@gitea.io>

* Reorder bug-report.yaml

* Add bug label on bug-report.yaml

* Add feature label on feature-request.yaml

* Reorder ui.bug-report.yaml

* Apply suggestions

Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: zeripath <art27@cantab.net>

It is ridiculous how few of our bug reporter are giving us DEBUG level logs.
This has to change and I think the proforma is not making it clear enough that
they have to give us these logs.

This PR changes the issue proformas to tell people to give us these logs.

Signed-off-by: Andrew Thornton <art27@cantab.net>

* `git` -> `Git`
* `Github` and `github` -> `GitHub`
* `crowdin` -> `Crowdin`
* `git-lfs` -> `Git LFS`
* `githooks`, `git hooks`, `git-hooks` -> `Git Hooks`
* `discord` -> `Discord`
* `2fa` -> `2FA`
* `gitlab` and `Gitlab` -> `GitLab`
* `web hook` -> `webhook`
* `linux` -> `Linux`
* `sqlite` -> `SQLite`
* `MYSQL` and `mysql` -> `MySQL`
* rename refs to `master` branch -> `main`
* Fix English grammar

Co-authored-by: John Olheiser <john.olheiser@gmail.com>

There was a typo `systemm` here. I opted to just remove the superfluos word altogether.

* Create issue template using new format

This issue template has been based off of the current issue creation workflow defined in the ISSUE_TEMPLATE.md file
This commit allows for that issue template (which is a legacy method of creating an issue) to be deleted

* Delete old issue template file

This commit deletes the old issue template file, as it is both legacy and replaced by ISSUE_TEMPLATE/issue.yaml

* Adjust file upload and remove code of conduct checkbox

* Block blank issue creation

* Update feedback

Removed most requirements
Updated prompt to include instruction to state whether using try.gitea.io
Added default value to Gitea version

* Create Feature Request issue form

* Update and rename issue.yaml to bug-report.yaml

* Enable blank issue creation

Co-authored-by: a1012112796 <1012112796@qq.com>

* Update config.yaml

* Remove default & placeholder from Gitea version

* Create issue template in .gitea directory

* Add relevant bug report message to feature request

* Adjust name to remove banner

There is a banner that tells you to create a config.yml when you already have a config.yaml
Renaming the file stops this from occurring.

* Add UI bug report form

* Remove unnecessary question

Co-authored-by: a1012112796 <1012112796@qq.com>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: Lauris BH <lauris@nix.lv>

Branch name
- master -> main

* chore: are you using Gitea behind CloudFlare

since more often than not CF appears to serve stale cache and cause
troubles, I'd argue it might be helpful to ask about it in this here
issue template

* implement suggestion: change question to comment

* as per @techknowlogick's suggestion

* chore: edit comment

* implement @mrsdizzie's suggestion
* as the comment grows, rather span multiple lines
* Gitea --> gitea to match case used in the rest of the template

Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>

* Add bountysource to Sponsors link

* Add badge to readme

* config lock bot

* Update .github/lock.yml

Signed-off-by: Andrew Thornton <art27@cantab.net>

Co-authored-by: techknowlogick <techknowlogick@gitea.io>

Almost every use of "Not relevant" I see is the opposite -- it is relevant to have an example on try.gitea.io and often we can't do anything until the user provides one. Remove the not-relevant option so people have to decide yes/no if they are going to attempt to reproduce it which will hopefully encourage them to do so in simple cases. 

For actual not-relevant issues No should be a fine answer as well as it would be clear to us when you can't reproduce an example there.

Hopefully this will encourage more examples when people file issues which would lead to quicker fixes.

* Improve stale nessage

* Update .github/stale.yml

Co-authored-by: guillep2k <18600385+guillep2k@users.noreply.github.com>

This need an option to be enabled on repo : https://help.github.com/en/articles/displaying-a-sponsor-button-in-your-repository

Like the comment that is posted.

Ex: #4749 is closed after 2 weeks and not 2 months

For `UI`-bugs we usually require a Screenshot to debug it 😉

* Update example install url from try.gogs.io to try.gitea.io

* Ask if issue can be reproduced on try.gitea.io

* Link try.gitea.io to the README

The CONTRIBUTING.md from root dir will be used by github