Hire a professional project manager

Having a professional project manager to handle the migration, similar to howthe Warehouse project was managed, would help ensure the success of this project.

Create a playground CPython issue tracker on GitHub

We should create a playground issue tracker on GitHub where we can experimentand test out the new workflow.

Backup of GitHub data

This effort has been started and is being tracked as an issue incore-workflow[1]. We’re using GitHub’s Migrations API[2] todownload GitHub data for CPython on a daily basis. The archives willbe dropped in a S3 bucket.

Thanks to Ee Durbin for working on this.

Update the CLA host

At the moment, the CLA is hosted within bpo. It needs to be updated such thatsigning the CLA does not require a bpo account, and it should be hosted outsideof the bpo.

The current CLA process itself is not ideal. Currently, contributors todevguide, peps, and core-workflow need to sign a CLA, and it requires a bpoaccount. A bpo account should not be required for those projects.

There is an ongoing effort to start using our own instance of CLAassistant instead of the current CLA process in place. Discussionabout this has been started incore-workflow mailing listas well as onDiscourse.

This effortis currently stalledbecause cla-assistant does not yet support CLA signed on behalf of organization.

Create “Python Triage” team on GitHub

The bug triagers on bpo are valuable to the core Python workflow, and wedefinitely would need even more help with triaging issues on GitHub.

It has beenproposed on Discoursefor us to create a “bug triage” team on GitHub to help with closingissues, notifying the appropriate parties, as well as applying labelsto issues and pull requests.

The new Triage role on GitHub is currently in beta, and the Python organizationhas been granted access to this role, and we can begin taking advantage of it.

The “Python Triage” team has been created. A description and expectations of thetriage rolehave been added to Devguide.

Progress of this project can betracked in“Adding Triagers” project board.

Create labels for issue triage

In bpo, we currently have the following fields for each issue:

Types:behavior,crash,compileerror,resourceusage,security,performance,enhancement.

Components:2to3,ArgumentClinic,asyncio,Build,Cross-build,ctypes, …

Priority:releaseblocker,deferredblocker,critical,high,normal,low

We will create the corresponding labels:

type-behavior,type-crash,type-compileerror,type-resourceusage,...components-2to3,components-argumentclinic,components-asyncio,...priority-releaseblocker,priority-deferredblocker,priority-critical,...

In addition, we’ll create aneedstriage label.

The final “labels” to be created can be decided at a later time whenit is time to start switching to GitHub issues.

A test repository containing all possible labels and color schema has beencreated by Carol Willing and can be reviewed athttps://github.com/willingc/test-581/labels.

Create issue templates

We will create an issue template and add the following headers:

---Type:behavior|crash|compileerror|resourceusage(chooseone)Components:2to3|ArgumentClinic|asyncio|Build|...(canselectmorethanone)Priority:releaseblocker|deferredblocker|critical|...Needsbackportto:2.7|3.6|3.7---

The idea is to allow the issue creator to help us triage the issue.The above values are pre-filled in the template. The issue creator will removetexts that do not apply to their issue.

Based on the above headers, bedevere-bot can apply the necessarylabels to the issue. If the issue creator did not supply the aboveheaders, the bot will apply theneedstriage label. At that point,it will require a core developer to properly label the issue.

We can also take advantage of GitHub’s multiple issue templatefeature, and the ability to automatically set issue assignee andlabels by using issue templates.

Updates to bedevere

Bedevere-bot will need to be updated to recognize the issue headers describedabove and apply the proper labels.

Bedevere-bot can also copy over the labels to pull requests that correspond tothe issue.

Update the devguide

Devguide should be updated with information about the new workflow of using GitHubissues. It can be done as a separate branch, and it should be done ahead of themigration, not after.

Add a button in bpo to migrate the issue to GitHub

This will require the bpo to be updated. But I believe the effort needed forthis is much less than a complete overhaul.

We will create a button in bpo, that will copy over the issue descriptionand associated comments into a GitHub issue.

We need to add a new status: “moved” with the url of the GitHub issue.

We should not be moving all open issues to GitHub. Only when someoneis interested in continuing work or discussion about the issue, thatthe issue should be “moved” to GitHub.

Migrated issues

When an issue is marked as “moved”, this issue should be in read-only mode. bposhould forbid the edition of the issue.

Make bpo read-only

This should be the final step. Once we start using GitHub issues, make bporead-only, instead of shutting it down.Do not accept new registrations. Do not allow comments or issues to be created.

Mapping between issues from bpo and GitHub

Usually when we reference an issue from bpo, we use bpo-XYZ but withGitHub, we will have a new reference with this formathttps://github.com/python/cpython/issue/XYZ.

Because we will migrate the issues from bpo to GitHub, we need to have a newfield on bpo for the reference to the issues on GitHub, and the same thing onGitHub for the ‘eventual’ reference from bpo.

For GitHub, we need to addorigin:https://bugs.python.org/issueXYZ.For bpo, add a new fieldmovedto:https://github.com/python/cpython/issue/XYZ.

Nosy-ing the expert

A current functionality in bpo is to automatically nosy people who are listedas an expert of certain area. Several Python core developers have expressed thatthey prefer not having to subscribe to everything on GitHub, but only getting notifiedfor issues related to their area of interest and expertise.

To help with this situation, we can develop a bot that can notify peoplewhenever an issue has been categorized using labels. For example, when an issuewas labeled witharea-windows, the windows experts can be notified.The notification can be in the form of email notification, or @-mention on GitHub.

A GitHub account should not be a requirement

Back when moving the CPython codebase from Mercurial to GitHub wasbeing discussed[3][4], it was brought up that we still needed toallow uploading of patches on bpo, and that a GitHub account shouldnot be a requirement in order to contribute to Python.

If bpo is made read-only, we’ll need to come up with a different solution toallow people to contribute when they don’t have a GitHub account.

One solution is to create a new “python-issues” mailing list, similar to thedocs@python.org[5] mailing list, to allow people to submit their issuesthere.

Related to this, since the migration to GitHub in 2017, I recall onecase[6] where there was a contributor, who submitted a patch toMercurial and refused to create a GitHub account. Because of this, ourbot was unable to detect whether they had signed the CLA. Anotherperson had volunteered to upload their patch to GitHub. But it wasstill required that both people sign the CLA.

That particular situation was complicated. It took up five coredevelopers’ time to investigate and manually check the CLA, causingconfusion.

Trim off the “Components” list

Is the current “components” list still making sense and relevant?Can the list be shortened?

Priority list

Is the current “priority” list useful? Alyssa Coghlan noted that perhaps onlyreleaseblocker anddeferredblocker are useful.