Yesterday, GitHub announced that repository admins can now transfer issues from one repository to another better fitting repository, to help those issues find their home. This project by GitHub is currently is in public beta version.
Nat Friedman, CEO of GitHub, in his tweet said, “We've just shipped the ability to transfer an issue from one repo to another. This is one of the most-requested GitHub features. Feels good!”
When the user transfers an issue, the comments, assignees, and issue timeline events are retained. The issue's labels, projects, and milestones are not retained, although users can see past activity in the issue's timeline.
People or teams who are mentioned in the issue will receive a notification letting them know that the issue has been transferred to a new repository. The original URL redirects to the new issue's URL. People who don't have read permissions in the new repository will see a banner letting them know that the issue has been transferred to a new repository that they can't access.
People with an owner or team maintainer roles can manage repository access with teams. Each team can have different repository access permissions.
There are three types of repository permissions, i.e. Read, Write, and Admin, available for people or teams collaborating on repositories that belong to an organization.
To transfer an open issue to another repository, the user needs to have admin permissions on the repository the issue is in and the repository where the issue is to be transferred.
If the issue is being transferred from a repository that's owned by an organization, you are a member of, you must transfer it to another repository within your organization.
To know more about the repository permission levels visit GitHubHelp blog post.
5. In "Choose a repository," select the repository you want to transfer the issue to.
6. Click Transfer issue.
GitHub Business Cloud is now FedRAMP authorized
GitHub updates developers and policymakers on EU copyright Directive at Brussels
GitHub October 21st outage RCA: How prioritizing ‘data integrity’ launched a series of unfortunate events that led to a day-long outage