Perhaps add something more specific about creating and deploying bots similar to miss-islington that can provide automation related to CPython-specific workflow.

There is also a Preview tab, very useful for non-trivial formatting.

It also supports votes, but I'm not sure that it's an advantage :-D

I like these features too. Will add these in my next iteration :) Thanks.

One can embed links in bpo messages, and they are clickable.

The specific type of quoting being talked about here is this one #681 (comment) which bpo does not support. Again, you have to click away to get to the code.

After seeing yours and Zach's proper examples, and trying it for myself, I agree that link + quote of complete lines (typical for code) is easier. But it is pretty easy on bpo. So I would agree with "copy paste source code lines more easily."

Copying partial or complete sentences from docs, with extraneous material before and after the desired quote removed, as it typical for doc issues, requires a separate copy paste on either tracker.

...current web standards, including accessibility.

Perhaps rename section to "Why GitHub over other third party git services"

You should mention somewhere "commercial" or "vendor lock-in" and explain why you consider that it's not a blocker issue. I'm sure that the question will arise.

The repo exports that Ernest (has set up? is setting up?) are definitely worth mentioning.

Ah, they're already mentioned later on in a slightly different context. Still, that's the key point for addressing any lock-in concerns: there are PSF hosted data backups, and the only thing that gets potentially tricky is tracking identity following a future migration away from GitHub, and the CLA signing process can cover that.

Perhaps combine with the prior section.

Using Github to track issues has its own learning curve, do you mean its less steep than other bug trackers?

I meant that since we (existing Python core devs, The PSF, and contributors to Python) have been using GitHub for everything else, there is less learning to do, than if we're to use a different issue tracker.

I think this is really only a concern with the roundup fork, which might not even be necessary anymore. The python-dev repo which hosts our custom plugins for roundup should be able to migrate to git without issue.

Since GitHub is popular, there are also a lot of existing tooling around GitHub. I don't think that it's the case for Roundup. GitHub also has builtin webhooks and a wide choice of "services". Enabling a service is just 2 clicks.

❤️

This is a separate issue and does not belong here. If possible, it should be done independently of issue migration, and discussion requires a different group of people.

This would be a great time to start a thread with PSF legal on this. On the technical side, there are already great projects to handle this like http://clabot.github.io/

I was thinking that this itself might require a separate PEP 😅

Replace 'each issues' with 'issue' or 'each issue'. As I said above, losing these fields is a big loss.

Reviewing and changing the the options is something we have done periodically in the past and could do again independently of this issue.

This list was once much smaller. We could discuss on committers list whether the added options are really useful.

IMHO components will be useful on pull requests are well. We already have "type-doc" label for example. It helps when someone wants to review all documentation PRs for example.

But the opportunity can potentially be taken to trim the component list

I'm for trimming it :) but perhaps we'll need more discussions with other core devs.

Another thread for committers list. I want to keep Idle, Tkinter, Windows, MacOS. We can ask whether anyone still want 2to3, Argument clinis, asyncio, ctypes, and some others.

By using custom labels on GitHub, priority, components, and other bpo fields can be set on issue creation/updating (i.e priority: high, components: asyncio, components: ctypes). For example, adopting a naming convention for labels is a common practice in other open source projects hosted on GitHub.

Ditto: when a PR has no associated bug, priority might be useful on PRs as well. But when a PR has an associated bug, the priority would be redundant and may become inconsistent if only updated on one side :-/

Honestly, I think "release blocker" and "deferred blocker" are the only actually useful priority levels we currently have, and those will always be associated with issues rather than PRs.

We need a field to specify the Python version that should be fixed, like the Python Versions field on bpo.

I think we can use the existing backport labels for that - just set them on the issue to indicate which labels the PR should get.

Yeah I plan to use the existing "needs backport to:" labels. These can be attached to the issue, and later automatically applied to the PR.

Those could be shorted to 'Backport to: x.y'

Hmm, this is a lot of labels. Have you given thought or experimented to see how well the Github interface handles this many labels?

I haven't seen any mention of limit of labels on GitHub anywhere. These are labels created but in really not all of them will be applied to the issue/PR.
In coala we've been working with 65 labels, and we also use bots to automatically categorize PRs.

Aah perfect, you already have a project that has a lot of labels 👍

Please elaborate. How do you qualify that a bug is triagged or not?

See "create issue template" below.

If the issue does not have at least one of type-, component, priority-, needs backport to- labels, then bot will apply needs triage label.

I think there is an other issue, currently, there are 2 lists, the contributors and the members. do you think you will add a new list for the 'triage' ? on bpo, my bpo account can change the associated component of an issue, could I do the same here?

I think it could be helpful to utilize GitHub's multiple issue templates (more info here). I found this to be really helpful on other OSS projects to keep general usage bugs out of the issue tracker by redirecting them elsewhere.

IMO, Babel does this really well (and has great emoji usage too).

a core developer to properly label the issue, and what happens for the bpo accounts with the 'triage' flag? as mine.

What about the existing files, which are typically patch files? Create a comment to embed them in? Or put a link to the original in?

No, No, No.

Closing bpo issues is a separate topic from and irrelevant to creating a usable GH cpython issue tracker. It can and has been done without this PEP. More could be done, but not so blindly as you propose. Doing so is a separate discussion, which I won't continue here.

Implementing this PEP is unaffected by bpo issue closures. The main affect of closure is limiting bpo search results. Bpo issue closures do not belong on this PEP and should be removed. Please don't repeat Chris Angelico's mistake of piggybacking a separate proposal onto his main proposal of assignment expressions.

I'm assuming your good intention, but I think your last sentence is unnecessary.

Move bpo to be an archival, read only project

It was not practical to use hg and git simultaneously. In my view, and some others, apparently, github was not fully ready to use when the switch was made. I would say not until Miss Islington started doing backports. (They still take more time than on hg, but the difference is tolerable.) The result was that many people stopped patching python for various periods.

It would be practical to have both issue trackers in use for a short time. So I think disabling bpo should wait until the new system has been used and approved by people other than the creators. Unlike with the repository, testing can be done with real issues for cpython PRs.

So I think approval of this PEP should be provisional, subject to final acceptance review, which would then signal 'stop using bpo'. At that point, shut off new registrations and issues, (which could be discourage earlier), and new comments. 'Readonly' should mean that search still works, and that issues can still be closed instead of transferred.

An alternative is to keep bpo: have bpo and GH.

No. Because then we need to support two different workflows and further complicate our life.

To minimize the burden of maintaining two issue reporting/commenting workflows, one for GitHub and one for bpo, the following constraints will be made to bpo when GitHub is used for issues:

• Disable new user registration to bpo.
• Disable new issue creation on bpo.
• Lock comments on existing bpo issues. Additional comments would be done on GitHub with a link to the archival bpo issue.