Issue template form #16349
No reviewers
Labels
No Label
backport/done
backport/v1.0
backport/v1.1
backport/v1.10
backport/v1.11
backport/v1.12
backport/v1.13
backport/v1.14
backport/v1.15
backport/v1.2
backport/v1.3
backport/v1.4
backport/v1.5
backport/v1.6
backport/v1.7
backport/v1.8
backport/v1.9
bounty
changelog
dependencies
frontport/done
frontport/main
good first issue
Hacktoberfest
hacktoberfest-accepted
in progress
kind/api
kind/breaking
kind/bug
kind/build
kind/deployment
kind/deprecated
kind/docs
kind/enhancement
kind/feature
kind/lint
kind/misc
kind/moderation
kind/package
kind/proposal
kind/question
kind/refactor
kind/regression
kind/security
kind/summary
kind/testing
kind/translation
kind/ui
kind/upstream-related
kind/usability
kind/ux
lgtm/done
lgtm/need 1
lgtm/need 2
performance/bigrepo
performance/cpu
performance/memory
performance/speed
priority/critical
priority/low
priority/maybe
priority/medium
proposal/rejected
reviewed/confirmed
reviewed/duplicate
reviewed/fixed
reviewed/invalid
reviewed/not-a-bug
reviewed/wontfix
skip-changelog
stale
status/blocked
status/needs-feedback
status/wip
theme/2fa
theme/authentication
theme/avatar
theme/backup-restore
theme/docker
theme/federation
theme/issues
theme/kanban
theme/markdown
theme/migration
theme/mobile
theme/pr
theme/signing
theme/sqlite
theme/timetracker
theme/webhook
theme/wiki
No Milestone
No project
No Assignees
4 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: lunny/gitea#16349
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "issue-template-form"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
Well done 👍
I don't think the git version should be required.
Until now, most of the issues I opened could be managed without knowing the git version. Additionally, doing it that way disables sending bugs present on try.gitea.io as I have no idea what git version is running there.
I'd also say that the OS is not required, at least for issues that deal with the frontend.
Also not always required. What should I say about try.gitea.io?
Once again: try.gitea.io. Should not be required.
Also, not required for pure frontend issues.
Okay, here it is a little different. I can see why you would require it here.
Yes, here it can be required.
Is there maybe a way so that the placeholder will also be used as default?
Because currently, it is only displayed when no text is present.
GitHub still requires you to fill that field before you can submit the issue.
As far as I am aware, try.gitea.io is a testing environment only. There is a section below regarding using try.gitea.io to test things that you find on your own installations.
This is more checking wheter they are using https://gitea.com, another hosted environment or their own self hosted variation.
I can remove the required flag from this input, however I bleieve that it would be valuable information for users to provide in terms of where they are using Gitea.
I can indeed specify a default value, however this would need to be updated every release.
I see your point there, in my next commit this will be patched.
Agreed. I'll disable the requirement in my next commit.
Yeah, I know.
But the comfort of try.gitea.com is exactly that the latest features can already be tested. And sometimes, there are bugs in these new features. Then, you can refer to try.gitea.com for these bugs.
That's what I mean by that.
To the best of my knowledge, try.gitea.io is a testing environment only and should only be used for reproducing bugs and trying out gitea.
I think that this would be valuable information for contributors and collaborators to have, so instead of disabling the requirement I might add something that prompts the person to write if they are using try.gitea.io .
Thoughts?
Removed in next commit.
But the placeholder not?
Okay, sounds fine.
Since I am most likely affected the most by this (I'd say that I am the person with the highest count of issues opened from testing on try.gitea.com) that sounds reasonable.
Yeah, I can support that.
👍
The placeholder could also be updated, however I consider placeholders as example values and not the value that a user should enter.
👍
Then this issue type would most likely be
Bug Report
, or something similar…Should now be resolved in the latest commit. I also changed the file name and description to be more in line with a bug report.
Suggest enable it.
If this were to be enabled, people would have the ability to create blank issues without providing any formatting or guidance at all.
Sometimes it's usefull, such as create a summary or a vote.
I don't think we should have a default value. And maybe not a placeholder either. I fear users will leave the default value unchanged, without confirming they are actually using that version.
Okay, I can live with both. I would have liked it, but I can also see your concern…
I removed the placeholder and default version in my recent commit.
@ -0,0 +4,4 @@
- type: markdown
attributes:
value: |
NOTE: If your issue is a security concern, please send an email to security@gitea.io instead of opening a public issue.
Should this still be here now that we have it already on the new issue landing page with the config.yaml?
Maybe an extra reminder here is not that bad.
@ -0,0 +9,4 @@
attributes:
value: |
1. Please speak English, this is the language all maintainers can speak and write.
2. Please ask questions or configuration/deploy problems on our Discord
Should this still be here now that we have it already on the new issue landing page with the config.yaml?
@ -0,0 +12,4 @@
2. Please ask questions or configuration/deploy problems on our Discord
server (https://discord.gg/gitea) or forum (https://discourse.gitea.io).
3. Please take a moment to check that your issue doesn't already exist.
4. Make sure it's not mentioned in the FAQ (https://docs.gitea.io/en-us/faq)
Should this still be here now that we have it already on the new issue landing page with the config.yaml?
@ -0,0 +86,4 @@
id: screenshots
attributes:
label: Screenshots
description: If this issue involves the Web Interface, please provide a screenshot or multiple screenshots
Should we add an input field asking for the browser version for issues that involve the web interface?
@ -0,0 +1,23 @@
name: Feature Request
description: Got an idea for a feature that Gitea doesn't have currently? Submit your idea here!
body:
We should also add some notes here about using the English language, and about checking first that the feature hasn't already been requested.
@ -0,0 +4,4 @@
- type: markdown
attributes:
value: |
NOTE: If your issue is a security concern, please send an email to security@gitea.io instead of opening a public issue.
Too many reminders is never a bad thing if it stops security vulnerabilities being made public.
Ideally, it will make people reporting bugs think more than once, and that's if they even read far enough down.
@ -0,0 +86,4 @@
id: screenshots
attributes:
label: Screenshots
description: If this issue involves the Web Interface, please provide a screenshot or multiple screenshots
Now that I think about it, it might not be a bad idea to completely separate issues involving web interface bugs from the rest of the bugs…
The report requirements might differ too much.
Thanks for this PR :)
Rather than removing this file, could you instead move it to the
.gitea
directory (which doesn't yet exist), so that when we move to gitea.com if issue templates don't yet exist as a feature in Gitea then we still have this as a fallback@ -0,0 +9,4 @@
attributes:
value: |
1. Please speak English, this is the language all maintainers can speak and write.
2. Please ask questions or configuration/deploy problems on our Discord
Always useful to have this information in multiple locations. It also keeps it on the page where they are submitting the form.
@ -0,0 +12,4 @@
2. Please ask questions or configuration/deploy problems on our Discord
server (https://discord.gg/gitea) or forum (https://discourse.gitea.io).
3. Please take a moment to check that your issue doesn't already exist.
4. Make sure it's not mentioned in the FAQ (https://docs.gitea.io/en-us/faq)
Again, keeps it present and current so that they can see it. It never hurts to remind them multiple times.
@ -0,0 +1,23 @@
name: Feature Request
description: Got an idea for a feature that Gitea doesn't have currently? Submit your idea here!
body:
We don't have much space here, but I could add a markdown system similar to the bug report to the feature template.
I can definitely do that. I wasn't aware that there is a
.gitea
directory, and I will add the file accordingly.@ -0,0 +1,23 @@
name: Feature Request
description: Got an idea for a feature that Gitea doesn't have currently? Submit your idea here!
body:
I've gone ahead and added a message to the top of the feature request template.
@ -0,0 +86,4 @@
id: screenshots
attributes:
label: Screenshots
description: If this issue involves the Web Interface, please provide a screenshot or multiple screenshots
If we would like to do that, I can definitely create a new form.
@ -0,0 +86,4 @@
id: screenshots
attributes:
label: Screenshots
description: If this issue involves the Web Interface, please provide a screenshot or multiple screenshots
This has been added in the most recent commit and has also been added to the testing repository - https://github.com/redstonedesigner/gitea-issue-form-testing