[RFC] Move package requests elsewhere

[0x5c]

As things are put in place to cut down the backlog by removing stale issues (#36399), interest has been shown for excluding package requests from that process (#36609).

While the interest in keeping them is justified, package requests as they currently are cause more backlog in the issues and to some extent swamp the bug reports.

Someone voiced on IRC that requests shouldn't be taken via github issues in the first place, and that we should move them elsewhere. That would simply eliminate the problem of requests taking a lot of space in the backlog.
Also mentioned in IRC was the interest for the ability to vote on requests.

Current situation

Package requests are github issues with the manually applied request label. They have been excluded from stalebot's reach, and will never be closed for staleness, perpetually expanding the backlog.
They can easily be closed by PRs (like one adding the package), just like any other issue/PR.

Available options (non-exhaustive list)

All options, in-github or not, could be integrated in the new issue flow using URLs in the template chooser (see #36411)

Github Discussions

Github discussions are already documented by github, so I won't ramble on about what they are, but I'll list what would be relevant for package requests.

• Discussions are organised in categories; we'd have one for package requests
• Each discussion topic (in this case; each request) can be voted on
• Conversion between Issues and Discussions is builtin

Pros

• Easy migration path is builtin to github, using the "Convert to discussion" button in issues (would also probably be trivial to mass-convert using the API)
• Migration of existing requests will keep all the author metadata of both the requests themselves and comments. (Notifications are preserved too iirc)

Cons

• Discussions don't have a concept of "closed" (yet?), the closest being "answered" for categories in "Q&A Mode"
• There is no pre-existing mechanism to mark a discussion as "answered" on merging of a PR, but doing so using webhooks and the API should be relatively trivial)

Custom service

Pros

• Custom means tuned to the needs of void
• Can be made to not require having a github account

Cons

• Custom means it needs to be built, maintained, and hosted by void
• Spam prevention and moderation would be more critical; requests are currently "gated" behind the effort of creating a github account

Other solutions

If you know something else that could be used for requests, please chime in :)

[mjyut]

I don't understand why someone said

requests shouldn't be taken via github issues

so it's just an idea.

Create a new GItHub repository for only package request issues (e.g. void-linux/void-request) .

Perhaps the only content in that new repository is the README.md.
Then transfer the existing request issues to the new repository.

Pros:

• The existing request will be saved as is.
• If someone accidentally creates an isuue in the original package repository, it can be easily transferred by the contributors.

Below is an example of transferring issu with GitHub CLI.

#!/bin/sh

repo_from='void-linux/void-packages'
repo_to='void-linux/void-request'
limit='10'

gh issue list -S 'is:issue is:open label:request sort:created-asc' -L "$limit" -R "$repo_from" \
    |cut -f1 \
    |xargs -I {} -n 1 gh issue transfer -R "$repo_from" {} "$repo_to"

[Duncaen]

Is there any value to "cleaning" the backlog from requests? This would just spread things around different repositories or even platforms.
You can filter -label:request if you want to work through the backlog, you can reference and discuss them in the same place as all other discussion is happening. We can reference and close issues with commit messages, including people without write access.

[0x5c]

This would just spread things around different repositories or even platforms.

Discussions are a (currently disabled for the repo) feature integrated in the repository itself

We can reference and close issues with commit messages, including people without write access.

As it currently stands, there's no check (manual or automatic) in place to ensure requests actually get closed when the package is added. I wouldn't be surprised new package PRs are merged without the author realising there could be a request to close.

[prez]

As it currently stands, there's no check (manual or automatic) in place to ensure requests actually get closed when the package is added. I wouldn't be surprised new package PRs are merged without the author realising there could be a request to close.

And how does your "solution" address this?
Strongly disagree with this. Having the requests as issues in the same repository is very convenient, and like Duncaen said, you can always use filters.

[0x5c]

As it currently stands, there's no check (manual or automatic) in place to ensure requests actually get closed when the package is added. I wouldn't be surprised new package PRs are merged without the author realising there could be a request to close.

And how does your "solution" address this?
Strongly disagree with this. Having the requests as issues in the same repository is very convenient, and like Duncaen said, you can always use filters.

@prez

It doesn't address this, but it addresses the resultant problem of purely irrelevant issues piling up in the issues, which can't be filtered.
They can't be auto-removed either, since all requests got a total exemption from cleaning. Even bug, which don't tend to magically go away after some time, aren't allowed that exemption. Requests for others to do work are essentially prioritised over actual bugs.

There's no vote system either, which would allow gauging interest.

On your last point, Github discussion live inside the repository. They are merely a separate tab from the issues tab, and provide features like voting, and migration from issues (along with all the author metadata and such). You can't see the tab here because they have not been enabled on the repository.

[Duncaen]

We don't need voting, people work on the issues and bugs they want to work on, separating requests from other available work doesn't make much sense.

[github-actions]

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.