Skip to content

Make Resources/Instructions optional in all six blank issue forms #189

Description

@ale210

Overview

We need to make the Resources/Instructions field optional in all six blank issue forms, because marking it required forces writers to type "N/A" on issues that genuinely have no external resource. GitHub renders an unanswered optional field as _No response_, so nothing is lost by relaxing it.

Filed on devops as one cross-repo ticket — three small PRs, one assignee — the same way #174 and #187 were handled. The field is worded identically in all three repos, so this is one decision applied six times, not three separate calls.

Action Items

In each file below, the resources-instructions field ends with required: true. In every one of the six files that is the last line of the file, which makes it easy to find even if the line numbers have drifted.

  • hackforla/devops — set required: false in .github/ISSUE_TEMPLATE/blank-issue-form.yml (line 34 when written) and .github/ISSUE_TEMPLATE/blank-issue-form-d.yml (line 43)
  • hackforla/devops-security — set required: false in .github/ISSUE_TEMPLATE/blank-issue-form-with-no-dependency.yml (line 26) and .github/ISSUE_TEMPLATE/blank-issue-form-with-dependency.yml (line 34)
  • hackforla/incubator — set required: false in the two files of the same names (lines 26 and 34)

Change only the required: value. Leave the field's label:, description: and — in devops — its placeholder: exactly as they are; the guidance is still wanted, it just should not block submission.

Keep the pairs identical. devops-security and incubator hold byte-identical copies of these two files, and that is a rule rather than a coincidence — the two repos should still diff clean afterwards.

Coordination with #187. #187 is open against the same four devops-security/incubator files. The two sets of edits are on different lines (#187 touches the Dependency field near the top and the Overview field; this touches the final line), so they should not conflict, but do not work them in parallel in the same branch. Whichever lands second should rebase and re-check that the four files are still identical across the two repos.

Verify after the PRs merge. GitHub renders issue templates from the default branch only, so this is not observable from a branch.

  • After each repo's PR merges, open that repo's /issues/new/choose, start each blank form, fill in only Overview and Action Items, and confirm it submits successfully with Resources left empty
  • Confirm the submitted issue shows _No response_ under the Resources heading rather than an empty section
  • Close the test issues afterwards and delete their board cards — the forms auto-add to board 73, so each test will leave one behind

Resources/Instructions

Scope note. This is only the Resources/Instructions field. The wider question of whether all three repos converge on one identical pair of forms — including whether the two forms collapse into one, and whether an acceptance-criteria field is added — is a separate open decision and is not settled here.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    Status
    Prioritized Backlog

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions