Consider how to handle repo/issue transfer requests

[galargh]

No description provided.

[lidel]

In my experience, the needs are:

• Ability to move Issues between repositories within the same org
  • Example https://github.com/ipfs/ipfs-desktop/issues/1954 → Pinning to Pinata disabled due to "Rate limit exceeded" ipfs/ipfs-webui#1900
• Ability to move Repositories between Orgs
  • We usually use it for removing archived repos from the main Org and moving to ipfs-inactive/ so maybe a different way of solving this is
    • Example: https://github.com/ipfs/blog → https://github.com/ipfs-inactive/blog

Solution to both could be a bot that executes transfer when the staff comments:

• @bot-name !move-issue <destination-org/destination-repo-name> (no confirmation, execute the move)
• @bot-name !move-repo <destination-org>[/<optional-destination-name] (require confirmation via @bot-name !transfer-repo-confirm or something

[galargh]

Nice, thanks for adding this information to the issue. The comment command set you proposed seems very reasonable as well.

In the meantime, I found one case which might be a good indicator that a bot like that should live next to the terraform management setup. Here it is:

1. Transfer a repository to a new organisation.
2. Try to refresh terraform config.
   This leaves terraform confused and unable to fix itself without human intervention. If a transfer bot was next to the terraform config, I'm sure we could script around it.

[galargh]

Brain dump

I think this could work something like this.

Let's say I want the bot to do something. I would create a GitHub issue in the github-mgmt repository. The bot - a GitHub Action triggered by changes to GitHub issues - would pick it up and check if I can perform such an action OR if someone that can perform such an action "approved" the issue. If either is true, the bot would move the issue from B to C and close the GitHub issue in github-mgmt.

There are some open questions in this workflow.

Where should the actual command text be placed?

The options would be:

• the title
• the comments

I think either the title or description (the first comment) are good options. Either of the two might be a good answer too. Allowing to put the commands not only in the title but also in description gives the users ability to create more human friendly issue titles which is a nice feature.

I think parsing all the comments might be an overkill and it could be abused to issue bot commands that are unrelated to the original issue.

What syntax to use for bot commands?

We do need to be able to extract a command name and parameters. Maybe something similar to what GitHub Actions use for commands could work here? So something along the lines:

::transfer-issue #11 https://github.com/multiformats/github-mgmt::
or
::transfer-issue #11 protocol/github-mgmt-template::

Do we need named parameters? Maybe?

URLs might be a pretty user friendly way of defining the resources both for those requesting the command and those approving.

How to check if the command can be executed?

This could be different for different commands. Maybe for transferring issues it would be enough to be a member of the source organisation? Or have write access to the source repo? This has to be decided but I think the main point I want to make is that we might need different level of permission checks in the bot.

We should first check if the person who created the issue has enough permissions. If not, we should check if it is "approved" and if it is check if the approver has enough permissions.

It might also be a good idea to have a way of always requiring an approval for some commands - as in, even if the person making the request has enough permissions, wait for someone else to ok it.

How to approve an issue?

There's no native way to approve issues as there is for pull requests. I think we could use either reactions, labels or comments for that.

TODO

• create a GitHub Action triggered on https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issues and/or https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment
• extract command and inputs from the issue
• check if command sender can execute the command / check if command approver can execute the command
• execute the command

Notes

• all this is going to need using a github token as it is done in sync workflow for example: https://github.com/protocol/github-mgmt-template/blob/master/.github/workflows/sync.yml#L100
• we can use gh api command in the workflow to communicate with either REST or GraphQL API
• gh api --paginate returns all the pages at once (at least for the REST API)
• we can avoid a lot of api calls by reading stuff from event payloads, see https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#issues and https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#issue_comment
• sender might be a useful field in the event payloads
• ...