Multiple ideas for Pull requests and issue forms #11058
Replies: 3 comments 1 reply
-
I thought I'd add that the only current way to make multiple-choice check-boxes required is to make each choice (all of the check-boxes) required, which forces the user to check all of the boxes before the issue can be submitted. That's no longer multiple choice. I'd love a way to make it so that a user must check at least one box (one or more boxes) in a multiple-choice checkbox entry before the issue can be submitted. |
Beta Was this translation helpful? Give feedback.
-
I want to come back to this and just add, that forgejo - a fork of gitea - has Pull request forms as a feature (Gitea afaik implemented it, so it should have that too) and it's a really cool feature to have and use, so GitHub not yet offering it is just sad. |
Beta Was this translation helpful? Give feedback.
-
GitHub does offer pull-request forms and offers a support document for creating them. They also suffer from this issue, though. |
Beta Was this translation helpful? Give feedback.
-
Foreword
This Discussion contains several suggestions combined into one.
The reason why is that they all are based off each other and would fit various categories, which is why I selected the "General Feedback" one instead.
If wished can I create separate discussions, which would link to this main one and explain the respective idea.
Idea 1: Pull request forms
Notes
Idea
Pull requests should receive the option to also set a Form similar to issues.
This could allow a more structured way of providing pull requests without the fear of having empty ones or ones with garbage/spam in them (Or it would at least limit/reduce it).
The Pull request forms would be virtually the same as issue forms in terms of configuration and overall structure.
I can actually imagine that PR forms could use the same system behind the issue forms without any real need to change stuff around, which could help with maintainability on GitHub's end.
Idea 2:
limit
option for checkboxes and dropdownIdea
Right now is the
dropdown
type the only one having an option to limit how many options you can select and there it is pretty much a "on/off" option where you can select multiple or only one.The
checkboxes
anddropdown
types could benefit from alimit
setting. This option would allow you to set a max limit for how many you can select and by default (when not set) would be unlimited.This could be useful for Pull requests (Assuming Idea 1 is added) where f.e. a
Enhancement
PR could have a section to set, if the change is breaking or not, based on "ticking" the corresponding checkbox for it.Regarding the
required
option available in checkboxes: This could still be set and would make the form submittable as soon as the total amount of options allowed by thelimit
option have been selected.Alternatively could the
limit
option support something like amin-max
syntax (i.e.limit: 1-5
) where a form would become submittable once the min amount is reached?Example
Idea 3: Option for checkboxes and dropdown to set labels
Notes
Perhaps the current syntax could be kept for the most basic setup?
label
being already used.Perhaps having
label
renamed totitle
(for the attributes setting) orname
(for the options list) respectively could avoid this?Idea
The
checkboxes
anddropdown
types should receive an option to set labels based on what options have been selected.This could in combination with the previous ideas allow Pull requests and issues to have labels set to "categorize" them.
As an example, selecting "Breaking" in the checkboxes type would apply the "PR Type: Breaking" label to it (Se example).
Example
Beta Was this translation helpful? Give feedback.
All reactions