Task list: Support lists across multiple repositories, or a streamlined issue transfer flow

[zackkrida]

My use case involves managing issues for multiple child repos in a single parent repository:

• https://github.com/WordPress/openverse
  • https://github.com/WordPress/openverse-frontend
  • https://github.com/WordPress/openverse-catalog
  • https://github.com/WordPress/openverse-api

If I want to use the new task list to create issues in the child repos from a meta/tracking issue in the parent repo, I have to:

• Create the issue using the new task list button
• Transfer the issue
• Go edit the task list

It would be great to simplify this in some way!

[gr2m]

I have a similar use case here: octokit/octokit.js#2127

I personally don't mind that I have to manually transfer the issue after I created it, but I consider the 3rd "Go edit the task list" step a bug, I'd have expected that the references in the task lists would be updated automatically.

[zackkrida]

The behavior you've described would be perfectly reasonable to me as well.

[gr2m]

I'd have expected that the references in the task lists would be updated automatically.

that seems to have been fixed now, thank you 👍🏼

[kaveenr]

+1 for this. We're using a parent repo as a project tracker and backlink dependencies to the "story" task on the parent repo.

[JoshAntBrown]

We're doing something very similar too

[arwidt]

+1 for this. We have a separate repo to keep the backlog of issues then we transfer the issues to correct repos when we start working on them. The edit step of the tasklist feels a bit broken.

[ghost]

+1 for managing it would be useful to have something other than "issue" (technical). maybe "story" where you can easily add a task list and track task across multiple repositories

[WardenDrew]

Related discussions:

• Allow creating issues from task lists in a different repo #5325
• [Task Lists]: Make it easier to add new tasks with issues in other repositories #5824

[WardenDrew]

Edit 2022.Oct.04: This behaviour is now fixed!

I'd add that tracked issues that are in the same repo as the tracking issue, when closed, properly update the checkbox state on the tracking issue.

However when the tracked issue is in a different repository, the checkbox state is not updated on the tracking issue and must be manually checked, which can be cumbersome if a tracked issue is tracked by multiple tracking issues.

[ghost]

Hey @WardenDrew, is there any update on this issue tracking from external repo?

[WardenDrew]

@nitish-suptho I can confirm that from testing right now, this is now fixed. Closing an issue in another repository also checks the checkbox for any places the issue is tracked at, including other repositories!

[ghost]

I'm still not getting the tracked badge. I'm not sure if something is wrong by my end.

[easlinger]

I’m still not getting the auto-check, though the badge works

[zachpoblete]

If I want to use the new task list to create issues in the child repos from a meta/tracking issue in the parent repo, I have to:

• Create the issue using the new task list button
• Transfer the issue
• Go edit the task list

An additional problem with this approach is that transfering an issue creates a gap in the issue/PR numbering. For example, if you create issue #1 in original-repo and transfer it to target-repo, the issues tab in original-repo will now be blank, but when you create a new issue in original-repo, it will be issue #2.

The transfered issue will also now have an extra transfer message like "[user] transferred this issue from [repo]".

For a cleaner way to manage issues from another repo (but not any faster):

1. Create the issue in target-repo; say it's issue #1.
2. Add this to the tasklist in original-repo

- [ ] owner/target-repo#1

owner is just the owner of target-repo. (See: Autolinked references and URLs - Issues and pull requests)

This new task will reference issue #1 in target-repo and when you close the issue from target-repo, it will also mark the task as done in original-repo. Notably, there will be no added gap to the issue/PR numbering and no extra transfer message.

Edit: I'm also experiencing the problem where even if I close the issue from target-repo, GitHub doesn't automatically complete the task. Oh well, this approach is still cleaner.