Feedback Wanted: Issue Forms beta and Issue Templates #63402
Replies: 62 comments 45 replies
-
Hello, I'm very happy that GitHub plans to improve issue forms. One main missing element is a preview to render and validate syntax when you are creating a form 1 2. Some input field types can be really useful:
Proposalbody:
- type: url
# ... body:
- type: tags
# ... body:
- type: file
# ... And custom validation (ex: regex) can be a good thing 5. Proposalbody:
- type: input
# ...
validations:
regexp: '[a-z]+'
# ... Some textarea can contain large content (ex: logs, code examples, ...), and being able to wrap them into Proposalbody:
- type: textarea
# ...
attributes:
label: A text area
placeholder: "Foo"
render: yml
details: true
# ... A very important element for me is conditional sections: being able to show/hide a form item based on a previous choice 7 8. Proposal - type: dropdown
id: section1
attributes:
# ...
options:
- A
- B
- C
- D
# ...
- type: checkboxes
id: section2
attributes:
options:
- label: Foo
id: item1
# ...
- type: input
depend-on:
id: section1
values:
- B
- D
attributes:
description: Bar
# ...
- type: input
depend-on:
id: section2.item1
values:
- true
attributes:
description: Foo
# ... In the same scope, a user-editable "other" field in dropdown can simplify the use of form 9. Proposal - type: dropdown
attributes:
# ...
others: true
options:
- A
- B
- C
- D
# ... Also being able to add details/descriptions to dropdown items can help users to understand the items. Proposal - type: dropdown
attributes:
# ...
options:
- value: A
description: This is the value A
- value: B
description: This is the value B
- value: C
description: This is the value C
- value: D
description: This is the value D
# ... The forms are very useful for issues, but they can also be really useful for pull requests 10. Bonus: gets issue form data via API to facilitate automation 11. Not sure if you expect this kind of feedback. Footnotes |
Beta Was this translation helpful? Give feedback.
-
Definitely some kind of rich web UI (WYSIWYG) to create/edit/preview[1] issue forms would be immensely useful. Similar to setting up issue templates, there could be an option to set up issue forms in a visual manner. Like, click "Add" and pick the control from a drop down list (e.g. "Text Area"); drag the controls to reorder, and have all the configurable options to the side (description, placeholder, value). Sort of like a form designer (MS Access, Visual Basic) which saves a perfect YAML! Nothing's wrong with the current documentation on the side (which I just discovered if I use the web UI, did not know that! I admit I haven't used this feature much). Being quite visual and eager to see what the user interacts with (and test input/output), the current YAML approach seems a little daunting to set up for many repositories, so the issue template wins for now. It could open doors to this suggestion whereby having a design view would make it easier to visualise logic for something like conditional fields. +1 for a URL and file ("drag and drop here!") inputs. |
Beta Was this translation helpful? Give feedback.
-
It doesn't seem like the Edit: Also, it doesn't seem like the issue with |
Beta Was this translation helpful? Give feedback.
-
Thanks for the happy improvements on GitHub Issues and Projects! As indicated in this article, I would like to use the new configuration of the issue template that sets a project as default, but I can't do this with the configuration below. For example, our project's project URL is below.
Then I set the
Can you tell me some correct examples? |
Beta Was this translation helpful? Give feedback.
-
It'd be great if not only can you set the default project, but also other fields such as status and values for custom fields. |
Beta Was this translation helpful? Give feedback.
-
Hello, Thanks for the improvements to the issue forms ! As I have been using the forms in a private repo, there is a functionality which would be really useful : the ability to modify some issues metadata dynamically from the form. In particular, modifying labels and affected milestones from a checkbox or a dropdown would help my team tremendously. Something which may (roughly) look like this :
Even though you can set the labels in the sidebar, it can be useful to set them in distinct form sections. For instance, I could have a dropdown dedicated to components labels and a dropdown dedicated to priority (setting labels like P1, P2, P3, etc). It is faster to navigate the dropdown list than searching through the labels manually. EDIT : I also saw this proposal to give access to tags within the forms, this would also be a very practical field to have access to. |
Beta Was this translation helpful? Give feedback.
-
Thank you for the issue forms feature, it is really great so far! The most important things I'm missing right now are:
I elaborated on the first point already in a comment on the linked discussion. As for the second point, here are some details. I maintain a bunch of libraries, and lots of them use the same issue forms to report bugs, suggest features or doc improvements, etc. Most of them only differ in the repo name that is mentioned in some field labels or descriptions. I would love it if I could define an issue form template with inputs (like a GitHub action) in some repo, and then reference this issue form template from for other repositories in their For example, I could have an issue form template like this in some repo called
inputs:
repo_name:
required: true
template:
name: Bug report
description: File a bug report
labels: ["bug"]
body:
- type: markdown
attributes:
value: Thanks for taking the time to fill out this bug report!
- type: input
id: version
attributes:
label: Version of {{ inputs.repo_name }}
description: In which version of {{ inputs.repo_name }} did you experience the issue?
validations:
required: true
- type: textarea
id: what-happened
attributes:
label: What happened?
placeholder: Incorrect behaviour, error message, stacktrace...
description: Please describe what you see and what you expected to happen instead
validations:
required: true And then from all repositories that want to use it, something like this (syntax borrowed from GitHub Actions):
blank_issues_enabled: true
forms:
- uses: joffrey-bion/my-templates/bug_report_template.yml@v3
with:
repo_name: this-repo
contact_links:
- name: Ask a question
about: For general usage questions, please use GitHub Discussions
url: https://github.com/joffrey-bion/krossbow/discussions |
Beta Was this translation helpful? Give feedback.
-
Does the new |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
when I'm creating an issue in GitHub Projects, would be great if I could use a form template from the repository the issue is created in instead of having to click into the repository to add an issue from there. |
Beta Was this translation helpful? Give feedback.
-
The issue forms are working much better for us than the issue templates! It's great to be able to provide instructional text to folks without having to use HTML comments.
Overall I'm happy with the experience. While a visual form builder would be nice, I don't have a problem using the yml directly. I just run my file through a yml validator. The GitHub plugin for VS Code that can do validation on GitHub Actions is pretty useful, and maybe it can be enhanced to validate issue forms as well? |
Beta Was this translation helpful? Give feedback.
-
Started using this recently and so far it's been a very smooth workflow, the only things I'd like to see in the near future are:
|
Beta Was this translation helpful? Give feedback.
-
I just found out about issue forms this week and have been learning and experimenting with the added features for our repositories! Here is my feedback so far: 1. Form validation accessThe validations keys for each of the existing input field types (
PLEASE enable this feature for private repositories too! Limiting the option to set a field as required for only public repositories seems counter intuitive to many of us. Private repositories need form validation just as much as a public repository would. 2. Post-commit error messagesTrying to get past all the errors was tedious once I was past the more helpful Body[i]: required key type is missing error messages because I had no line, column or character references. Getting a Checkboxes must have unique labels error when I have many to check and the body:
- type: checkboxes
id: operating-systems
attributes:
label: Which operating systems have you used? # <-- field label
description: You may select more than one.
options:
- label: macOS # <-- options label
- label: Windows
- label: Linux
validations:
required: true # <--- good feature for public and private repositories 3. Feature request: Table/Matrix input typeI work in consumer electronics testing and we frequently have multiple physical products to record test results and issues for at the same time. Single line Something like this:
As the documentation and features evolve, please consider these improvements! Thank you for the awesome new way to template! |
Beta Was this translation helpful? Give feedback.
-
Bug: the |
Beta Was this translation helpful? Give feedback.
-
I've implemented issue forms for two projects so far. The biggest ask that I have (other than a way to visually preview the yaml on GitHub and ensure it validates / a visual issue form creator) would be more control over who can see certain forms and their items. Being able to restrict forms and fields to org members would be quite helpful! In leu of this being implemented, users have come up with hacky honor-based systems of restricting who can open issues which are lovely but not exactly the best user experience for all involved. ;) |
Beta Was this translation helpful? Give feedback.
-
Extra input type for forms for only attache files
|
Beta Was this translation helpful? Give feedback.
-
I love the issue forms, they've been great. But lately, when using a todo-list, the contents are reset when submitting and I have to A) remember what I just wrote and B) edit the initial comment and re-add the check-boxes. This could be specific to use Ctrl+Enter to submit, I will see if this happens when I mouse click to submit. |
Beta Was this translation helpful? Give feedback.
-
Hello, everyone. I'm really appreciate the Issue Form function, which could help us to let user fill the issue template. Now I have some feedback, or feature requests, about it: 1. Input GroupsNow we have two kinds of text input components: input for signle line and textarea for multiple lines. But sometimes we needs "multiple single lines" input, such as environment information:
Currently, we could use So it will be much better if we have an input group for issue form, which combines several 2. Remove Input if EmptyNow if one input is not required and empty, the finial result will be just a 3. About Top-level configuration optionsThere is some conflicts between the front matter of Issue Templates and the Top-level configuration of Issue Form:
I think it is better to align them. Thanks a lot for providing the issue form function and reading this. |
Beta Was this translation helpful? Give feedback.
-
I would like to have more control over the output of an issue template, as well as conditional output. For example, we have a section of input fields that are not always relevant. We always get the the following output:
I'd like to be able to make the section optional with a checkbox, hiding the controls and outputting nothing when not checked. I'd also like some control over what is being output. Perhaps some sort of template where I can say something like this: - type: textarea
id: confidentiality
attributes:
label: Confidentiality
description: Only authorized persons have the right to access information
placeholder: 'Example: I can see the assets of another customer.'
template: |
### ${label}
${body} Or perhaps even a global template where we simply refer to all field by their id. If that template also supported conditional checks it would allow us to create literally anything we want. |
Beta Was this translation helpful? Give feedback.
-
Anyone else having issues with the validation not working? I have set: But the fields are not showing up as required. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
How can the form templates be used in PRs? Documentation doesn't mention that. |
Beta Was this translation helpful? Give feedback.
-
Love issue templates but would love them even more if there was an option to make the |
Beta Was this translation helpful? Give feedback.
-
loving issue-forms as well, but I would like to be able to disable the markdown renderer for The string that users fill into our
(this currently does not validate) |
Beta Was this translation helpful? Give feedback.
-
I would enjoy having a date input field type so that can be filled in in the expected format (YYYY-MM-DD for example) |
Beta Was this translation helpful? Give feedback.
-
Love issue forms! I'm using them in an org context and want to have the ability for forms to create issues in specific repositories, i.e. in the nflverse project it would be great to have an org level form chooser where data-specific issues are opened in nflverse/nflverse-data, R issues opened in nflverse/nflreadr, python issues in nflverse/nfldatapy etc. |
Beta Was this translation helpful? Give feedback.
-
Love the template and flexibility, Would love the possibility of the submitted issue rendering based on the template used for creation with all markdown and fields layout with readonly value. An amazing addition would be to allow us the option to edit the submitted issue using the existing template. This will enhance the UX of issues and make it more coherent and fleshed out when viewed after submission as it was intended on submission. |
Beta Was this translation helpful? Give feedback.
-
What is the rationale for not allowing |
Beta Was this translation helpful? Give feedback.
-
Not sure if this is the right thread to post this, but there's a bug which was introduced with the addition of the new GitHub issues beta. We have set up issue forms for a long time now, but after applying to the new GitHub issues beta and receiving access, the We have textarea inputs in our various issue forms for users to paste debug log. The textarea's I would appreciate if someone from the GitHub team(s) responsible for issue forms could have a look at this. |
Beta Was this translation helpful? Give feedback.
-
When will regex validation support be added for text fields? |
Beta Was this translation helpful? Give feedback.
-
📢 Calling all issue management aficionados! We're embarking on a mission to improve GitHub issue forms and templates, and would love to hear from you!
💡 Share your creative ideas and experiences in crafting issue forms and templates that have made issue triaging a breeze. What fields, labels, or instructions have you include to ensure comprehensive and clear issue reporting? Are there any features missing that would help optimize this process? We're looking to help maintainers and admins set up the perfect balance between gathering necessary information and keeping the issue creation user-friendly.
🔍 Imagine you have a magic wand to create the ultimate GitHub issue form/template creation and management experience. What tools have you used in the past that made this a breeze? What features would help you manage and track issues across repositories, organizations and projects?
🐞 Run into any bugs with issue forms and templates? Let us know!
🤝 Let's collaborate and design a streamlined, intuitive, and impactful Join the discussion below and let the magic of collaboration begin! ✨
Beta Was this translation helpful? Give feedback.
All reactions