What are next steps for PEP 581?

[Mariatta]

Hi, I wrote PEP 581 just shortly after PEP 572’s acceptance and before Guido’s retirement as BDFL, so it’s been somewhat languishing.

Now that we have steering council in place, I’d like to pick this up again.

I’d like to know what would be the process of discussion for PEP 581?

Several things I would like to discuss are:

1. How to handle bug triage permission.

There are several ideas, but not sure which ones we like the best. I’ve chatted about this during last year’s core sprint, which I’ve summarized in my blog

My preferred solution is to create a “bug triage” team in GitHub, that gives them write access to the repo. The write access will allow them to add labels and close issues.
However we will add branch protection, so only core developers can merge pull requests. Personally I like this option the best. But we probably should “clean up” inactive bug triagers.

Another idea, since miss-islington can automerge now, we can also make the restriction such that only miss-islington and release managers can do the merge. One benefit is nobody need to remember to replace # to GH- anymore! But perhaps this is too big of a change.

2. How do we want to handle people who do not have access to GitHub?

I have some ideas here: PEP 581 - Using GitHub Issues
Wanted to know what do we think of those ideas?

3. “Components” list in bpo.

Are all of these still relevant?

4. “Priority” list

Are all of these still relevant?

[brettcannon]

@Mariatta

I’d like to know what would be the process of discussion for PEP 581?

Good question! I have no idea.

I think starting this topic is probably the closest you can come right now as the steering council doesn’t know how we will proceed going forward.

@Mariatta

My preferred solution is to create a “bug triage” team in GitHub, that gives them write access to the repo. The write access will allow them to add labels and close issues.
However we will add branch protection, so only core developers can merge pull requests. Personally I like this option the best. But we probably should “clean up” inactive bug triagers.

That’s a nice solution!

@Mariatta

3. “Components” list in bpo.

Are all of these still relevant?

I know the docs team use this as nosing the Documentation team automatically. But I also think a bot can do this by looking at what files are in a PR.

@Mariatta

4. “Priority” list

Are all of these still relevant?

I think only Release Blocker and Deferred Blocker are consistently used and those can obviously be labels without issue.

[steve.dower]

@brettcannon

I know the docs team use this as nosing the Documentation team automatically. But I also think a bot can do this by looking at what files are in a PR.

The Windows team also use it, and for a bug there’s no files in the PR (and honestly, I’d prefer to find out about PRs via the bug than independently). Unless anyone is allowed to add tags, we might benefit from a user-specified category that a bot can turn into a tag (on create, so we can remove it when it’s incorrect). Presumably we’d need the bot to notify people about their relevant new issues (possibly just by subscribing them, I’m not specifying the mechanism here, just the result).