[ISSUE] [RFC] Move package requests elsewhere

[ISSUE] [RFC] Move package requests elsewhere

[0x5c]

[-- Attachment #1: Type: text/plain, Size: 2876 bytes --]

New issue by 0x5c on void-packages repository

https://github.com/void-linux/void-packages/issues/36700

Description:
As things are put in place to cut down the backlog by removing stale issues (https://github.com/void-linux/void-packages/pull/36399), interest has been shown for excluding package requests from that process (https://github.com/void-linux/void-packages/pull/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 https://github.com/void-linux/void-packages/pull/36411)

### Github Discussions
Github discussions are [already documented by github](https://docs.github.com/en/discussions), 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 :)

Re: [RFC] Move package requests elsewhere

[mjyut]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

New comment by mjyut on void-packages repository

https://github.com/void-linux/void-packages/issues/36700#issuecomment-1100844632

Comment:
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-package-request`) .
Perhaps the only content in that new repository is the `README.md`.
Then [transfer](https://docs.github.com/en/issues/tracking-your-work-with-issues/transferring-an-issue-to-another-repository) 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.

Re: [RFC] Move package requests elsewhere

[mjyut]

[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]

New comment by mjyut on void-packages repository

https://github.com/void-linux/void-packages/issues/36700#issuecomment-1100844632

Comment:
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-package-request`) .
Perhaps the only content in that new repository is the `README.md`.
Then [transfer](https://docs.github.com/en/issues/tracking-your-work-with-issues/transferring-an-issue-to-another-repository) 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.

```sh
#!/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"
```

Re: [RFC] Move package requests elsewhere

[Duncaen]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/36700#issuecomment-1100913209

Comment:
Is there any value to "cleaning" the backlog from requests? This would just spread thing 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.

Re: [RFC] Move package requests elsewhere

[Duncaen]

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/36700#issuecomment-1100913209

Comment:
Is there any value to "cleaning" the backlog from requests? This would just spread thing 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 and we can assign and reference them easily, including people without write access.

Re: [RFC] Move package requests elsewhere

[Duncaen]

[-- Attachment #1: Type: text/plain, Size: 541 bytes --]

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/36700#issuecomment-1100913209

Comment:
Is there any value to "cleaning" the backlog from requests? This would just spread thing 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.

Re: [RFC] Move package requests elsewhere

[Duncaen]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/36700#issuecomment-1100913209

Comment:
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.

Re: [RFC] Move package requests elsewhere

[mjyut]

[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]

New comment by mjyut on void-packages repository

https://github.com/void-linux/void-packages/issues/36700#issuecomment-1100844632

Comment:
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](https://docs.github.com/en/issues/tracking-your-work-with-issues/transferring-an-issue-to-another-repository) 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.

```sh
#!/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"
```

Re: [RFC] Move package requests elsewhere

[mjyut]

[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]

New comment by mjyut on void-packages repository

https://github.com/void-linux/void-packages/issues/36700#issuecomment-1100844632

Comment:
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](https://docs.github.com/en/issues/tracking-your-work-with-issues/transferring-an-issue-to-another-repository) 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.

```sh
#!/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"
```

Re: [RFC] Move package requests elsewhere

[0x5c]

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]

New comment by 0x5c on void-packages repository

https://github.com/void-linux/void-packages/issues/36700#issuecomment-1103293129

Comment:
> 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.

Re: [RFC] Move package requests elsewhere

[prez]

[-- Attachment #1: Type: text/plain, Size: 595 bytes --]

New comment by prez on void-packages repository

https://github.com/void-linux/void-packages/issues/36700#issuecomment-1103823446

Comment:
>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.

Re: [RFC] Move package requests elsewhere

[0x5c]

[-- Attachment #1: Type: text/plain, Size: 1395 bytes --]

New comment by 0x5c on void-packages repository

https://github.com/void-linux/void-packages/issues/36700#issuecomment-1105732175

Comment:
> >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. 

Re: [RFC] Move package requests elsewhere

[Duncaen]

[-- Attachment #1: Type: text/plain, Size: 293 bytes --]

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/36700#issuecomment-1105734419

Comment:
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.

Re: [RFC] Move package requests elsewhere

[github-actions]

[-- Attachment #1: Type: text/plain, Size: 293 bytes --]

New comment by github-actions[bot] on void-packages repository

https://github.com/void-linux/void-packages/issues/36700#issuecomment-1190958786

Comment:
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.

Re: [ISSUE] [CLOSED] [RFC] Move package requests elsewhere

[github-actions]

[-- Attachment #1: Type: text/plain, Size: 2879 bytes --]

Closed issue by 0x5c on void-packages repository

https://github.com/void-linux/void-packages/issues/36700

Description:
As things are put in place to cut down the backlog by removing stale issues (https://github.com/void-linux/void-packages/pull/36399), interest has been shown for excluding package requests from that process (https://github.com/void-linux/void-packages/pull/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 https://github.com/void-linux/void-packages/pull/36411)

### Github Discussions
Github discussions are [already documented by github](https://docs.github.com/en/discussions), 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 :)