doc: issue template: remove reviewers-wanted label on new issues

[nodiscc]

• this label has no practical use on issues
• the only practical use of this label is on pull requests, where the Github "native" reviewed/not reviewed status is clearly visible from the main PR list/page anyway

[nodiscc]

After this, I would like to remove the reviewers wanted label altogether from the project.

Then in a second time, I would like to enable Require approvals on Merge Request with at least 1 approval - this can be bypassed, with a warning.

But it can only be enabled when Require a pull request before merging is enabled, which breaks out automated metadata update workflow - I tried: https://github.com/awesome-selfhosted/awesome-selfhosted-data/actions/runs/26181393264/job/77025185079

remote: - Changes must be made through a pull request.        
To https://github.com/awesome-selfhosted/awesome-selfhosted-data
 ! [remote rejected] master -> master (protected branch hook declined)

This would also allow enabling Dismiss stale pull request approvals when new commits are pushed protect against PR submitters sneakily editing their PR between the approval and the merge.

[kokomo123]

I agree with the label now being redundant from issues, given that only (we) the maintainers only have weight over PRs for the list and issues. it also makes more sense, as we dont have to add the label everytime. It's just going to suck if we are going to lose our metadata updates :/
i guess we could get the bot to fetch, and then we approve like once a month, once a week, etc. but that's another headache ill wait for others to comment on.
Also approvals, yep. that makes sense.
Same with dismiss stale pull request approvals, I like that feature, would help me out entirely.

[kokomo123]

LGTM, no issues here for now per comments above.

[nodiscc]

it can only be enabled when Require a pull request before merging is enabled, which breaks out automated metadata update workflow

It's just going to suck if we are going to lose our metadata updates :/

I will definitely not change this setting if it breaks the fully automated update. I was just mentioning it for later - I will check if there is a proper solution before touching anything.

[kokomo123]

Ahhh--gotcha, thank you for clarifying

[Rabenherz112]

After this, I would like to remove the reviewers wanted label altogether from the project.

I assume this is related to the AI discussion I have seen, but just so I understand it, why? I personally liked it, since it was always a good indicator of when something was actually ready to be merged (not against removing it, just want to understand the reasoning)

This would also allow enabling Dismiss stale pull request approvals when new commits are pushed

That would be a neat feature. Regarding the issue that it breaks the update workflow, I think this can be worked around by using a GitHub App, as they should be able to be added to the "Bypass" section. I haven't tested it, but a quick check of the GitHub Docs suggests it's possible:

permissions:
  contents: write
  
steps:
  - uses: actions/create-github-app-token@v3.2.0
    id: app-token
    with:
      app-id: ${{ secrets.BOT_APP_ID }}
      private-key: ${{ secrets.BOT_APP_PRIVATE_KEY }}
      
  - uses: actions/checkout@v6
    with:
      token: ${{ steps.app-token.outputs.token }}
      persist-credentials: false # Not sure if we need this? The offical docs had it

  [Do our shenanigans]
  
  - name: commit and push changes
    run: |
      git config user.name awesome-selfhosted-bot
      git config user.email github-actions@github.com
      git add software/ tags/ platforms/ licenses*.yml
      git diff-index --quiet HEAD || git commit -m "[bot] update projects metadata"
      git push

PS: Congrats kokomo, well earned

[Rabenherz112]

this label has no practical use on issues

Agreed

[nodiscc]

since it was always a good indicator of when something was actually ready to be merged

There is already a "native" github indicator when a PR is approved

Regarding the issue that it breaks the update workflow, I think this can be worked around by using a GitHub App

Yes this was my conclusion as well. It's a bit more complex but I think I will do this