GitHub issues + pull request templates

[nullsystem]

• NOTE: This was first done via GitHub's settings and some template to create the issues template. That's why the branch is within the main repo and why the issues markdown formatting is different to the PR's one (which doesn't have a template to create a template).
• Add issues template giving an option between bug report or feature request
• Structured especially for bug report so it can be followed through
• Altered slightly from GitHub's given default to fit a bit more for NT;RE
• resolves #350
• Issues reporting are both YAML files to leverage form feature. PR will be kept as markdown since it'd rather it be more free-formed.

[kassibuss]

LGTM Edit: Didnt noticce it was draft

[nullsystem]

Actually, should the bug reports be turned into using the "issue forms" yaml format instead? It does seem to give more controls, probably an advantage with the URL linking and put in build info + OS at specific places. Not a fan of the yaml format though.

[Rainyan]

Actually, should the bug reports be turned into using the "issue forms" yaml format instead? It does seem to give more controls, probably an advantage with the URL linking and put in build info + OS at specific places. Not a fan of the yaml format though.

YAML comes up more prominently when looking for GitHub docs as to how to do this stuff. Might be a good idea.

[blaberry]

I mentioned it earlier, but one of the issues with issues not created through the projects view is that we lose the bounty tracking by default, though we could probably fix this relatively easily with some auto-tagging.

Apologies for the surface level insight, I might have some time later today to give a more in depth review.

On Sun, 9 Jun 2024, 03:32 Rain, @.***> wrote:

Actually, should the bug reports be turned into using the "issue forms" yaml format instead? It does seem to give more controls, probably an advantage with the URL linking and put in build info + OS at specific places. Not a fan of the yaml format though.

YAML comes up more prominently when looking for GitHub docs as to how to do this stuff. Might be a good idea.

— Reply to this email directly, view it on GitHub https://github.com/NeotokyoRebuild/neo/pull/351#issuecomment-2156260348, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABV3LDTEZV6JK4NDDM4CU7LZGOWBPAVCNFSM6AAAAABJAKWBGCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJWGI3DAMZUHA . You are receiving this because your review was requested.Message ID: @.***>

[nullsystem]

I mentioned it earlier, but one of the issues with issues not created through the projects view is that we lose the bounty tracking by default, though we could probably fix this relatively easily with some auto-tagging. Apologies for the surface level insight, I might have some time later today to give a more in depth review.

@blaberry It seems like creating an issue through projects is able to use the templates anyway. Clicking on "+" -> Create a new issue -> Above "Add a title" currently it says "Blank issue in NeotokyoRebuild/neo" but with templates put in it'll be some template instead. Even then if an issue is created through the standard issue, it can be added to the projects stuff anyway.

EDIT: Actually it does seem like templates supports auto-adding to projects anyway.

[blaberry]

Yeah using the templates for project-created issues is a great thing, I was only concerned about the opposite flow, ie how do we make sure issues don't get lost by not being assigned a project/milestone. But if we can add them to the bounty project by default then all good by me.

[nullsystem]

So regarding the URL, I'm wondering if it's a GitHub's bug but the URL GET parameters seemed to overridden the defaults set in the template. However these parameters can be set back anyway. Ending URL with: /issues/new?template=bug_report.yml&build=20240609_abc123&labels=bug&title=[BUG]&projects=NeoTokyoRebuild/1 for example will fill the build input box with 20240609_abc123, put in "bug" label, prefix title with "[BUG]", and auto-add it to the project board/list.

If someone just go through the normal issue creation workflow (via Issues page, not project board), these defaults parameters (bug label, project board auto-add, etc..) will be applied as expected. In which in this case creating an issue from the Project section isn't a necessity anymore to add it to Project board.

It seems like the markdown somehow doesn't recognize the projects section and can't auto-add to project, so will also change the feature request to YAML/form format also.

[Rainyan]

One thing worth clarifying for the title wording is whether we want:

• State of things currently:
  • "Recon class spawns with smoke grenades"
• The desired state of things:
  • "Recon class doesn't spawn with smoke grenades"

as having many issues using both styles could get confusing.

It seems most of our existing issues follow the latter, although I could see "Thing X is broken" being what people reporting bugs would naturally gravitate towards.

But maybe it's not that big of a deal(?)

[nullsystem]

@Rainyan I kind of think bugs titles as "State of things currently" and features/changes titles as "The desired state of things". Either not a big deal or give a guideline for bugs title to be consistent.

Not taking Qt's bug reports as a guideline, but the general gist over there: https://bugreports.qt.io/browse/QTBUG-126211?jql=project%20%3D%20QTBUG Are kinda like that bug vs features/changes split also Other projects like EX: raddebugger or Hyprland points to that direction also

[nullsystem]

@blaberry https://github.com/NeotokyoRebuild/neo/blob/0466cdce4b24f7133ba538ad94a473113dfcb0d0/.github/ISSUE_TEMPLATE/feature_request.yml

There is a problem with this template

YAML syntax error: (): could not find expected ':' while scanning a simple key at line 40 column 7. Learn more about this error.