Multiple ideas for Pull requests and issue forms

[Andre601]

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

• This idea would work best with Add Pull request Template chooser similar to Issue Template chooser #4620 being implemented too, as it would be most powerful that way.

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 dropdown

Idea

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 and dropdown types could benefit from a limit 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 the limit option have been selected.
Alternatively could the limit option support something like a min-max syntax (i.e. limit: 1-5) where a form would become submittable once the min amount is reached?

Example

  # Checkboxes example
  - type: checkboxes
    attributes:
      limit: 1 # Only allow 1 selection
      label: Size (Breaking?)
      description: |-
        Please select the size of the change and if it is breaking.
        
        - Large: More than 1000 changes
        - Medium: 500 - 1000 changes
        - Small: Less than 500 changes
      options:
        - label: Large (Breaking)
          required: true
        - label: Medium (Breaking)
          required: true
        - label: Small (Breaking)
          required: true
        - label: Large (Not breaking)
          required: true
        - label: Medium (Not breaking)
          required: true
        - label: Small (Not breaking)
          required: true

  # Dropdown example
  - type: dropdown
    attributes:
      limit: 1 # Only allow 1 selection
      label: Size
      description: |-
        Please select the size of the change and if it is breaking.
        
        - Large: More than 1000 changes
        - Medium: 500 - 1000 changes
        - Small: Less than 500 changes
      options:
        - Large (Breaking)
        - Medium (Breaking)
        - Small (Breaking)
        - Large (Not breaking)
        - Medium (Not breaking)
        - Small (Not breaking)

---

Idea 3: Option for checkboxes and dropdown to set labels

Notes

• This idea would probably require changes to the syntax of the dropdown, by having a similar syntax to checkboxes in the "options" list.
  Perhaps the current syntax could be kept for the most basic setup?
• The labeling option would probably cause confusion due to the fact of label being already used.
  Perhaps having label renamed to title (for the attributes setting) or name (for the options list) respectively could avoid this?

Idea

The checkboxes and dropdown 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

  # Checkboxes example
  - type: checkboxes
    attributes:
      limit: 1 # Only allow 1 selection
      label: Size (Breaking?)
      description: |-
        Please select the size of the change and if it is breaking.
        
        - Large: More than 1000 changes
        - Medium: 500 - 1000 changes
        - Small: Less than 500 changes
      options:
        - label: Large (Breaking)
          required: true
          labels:
            - 'PR Size: Large'
            - 'PR Type: Breaking'
        - label: Medium (Breaking)
          required: true
          labels:
            - 'PR Size: Medium'
            - 'PR Type: Breaking'
        - label: Small (Breaking)
          required: true
          labels:
            - 'PR Size: Small'
            - 'PR Type: Breaking'
        - label: Large (Not breaking)
          required: true
          labels:
            - 'PR Size: Large'
            - 'PR Type: Not Breaking'
        - label: Medium (Not breaking)
          required: true
          labels:
            - 'PR Size: Medium'
            - 'PR Type: Not Breaking'
        - label: Small (Not breaking)
          required: true
          labels:
            - 'PR Size: Small'
            - 'PR Type: Not Breaking'

  # Dropdown example
  - type: dropdown
    attributes:
      limit: 1 # Only allow 1 selection
      label: Size
      description: |-
        Please select the size of the change and if it is breaking.
        
        - Large: More than 1000 changes
        - Medium: 500 - 1000 changes
        - Small: Less than 500 changes
      options:
        - label: Large (Breaking)
          labels:
            - 'PR Size: Large'
            - 'PR Type: Breaking'
        - label: Medium (Breaking)
          labels:
            - 'PR Size: Medium'
            - 'PR Type: Breaking'
        - label: Small (Breaking)
          labels:
            - 'PR Size: Small'
            - 'PR Type: Breaking'
        - label: Large (Not breaking)
          labels:
            - 'PR Size: Large'
            - 'PR Type: Not Breaking'
        - label: Medium (Not breaking)
          labels:
            - 'PR Size: Medium'
            - 'PR Type: Not Breaking'
        - label: Small (Not breaking)
          labels:
            - 'PR Size: Small'
            - 'PR Type: Not Breaking'

[Elliria]

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.

[Andre601]

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.

[Elliria]

GitHub does offer pull-request forms and offers a support document for creating them. They also suffer from this issue, though.

[Andre601]

That is a template, not a form. And yes, there is a difference between those. See issue templates and issue forms for an example.

But to make it clear: The PR template is just inserting markdown into the text field and maybe also pre-set the title and labels.
A PR form would be completely different in structure as shown in my post above.