PEP 581/588 RFC: Collecting feedback about GitHub Issues

[Mariatta]

PEP 581: Using GitHub Issues has been accepted by the steering council, but PEP 588: GitHub Issues Migration plan is still in progress.

I'd like to hear from core developers as well as heavy b.p.o users, the following:

1. what features do they find lacking from GitHub issues, or
2. what are the things you can do in b.p.o but not in GitHub, or
3. Other workflow that will be blocked if we were to switch to GitHub today

By understanding your needs, we can be better prepared for the migration, and we can start looking for solutions.
In addition, I received tip that the GitHub team is very motivated to help us, and if we can give them some of our most wanted features, they might be able to accommodate us. But first we need to tell them what we need. They're not promising anything, but I'd like to at least try and give them these suggestions.

Action item: Leave your comment

Please post your suggestions as a comment on this issue, One feature request/idea/suggestion per comment. Please only leave comment about the actual idea/feature request/suggestion. You can give your +1 by reacting 👍 to the comment

I suggest the following template, but feel free to be creative

# Summary: 
I need the ability to do ... in GitHub

# Details:
in b.p.o I was able to do ..., but GitHub doesn't allow this. 
This is very important because ...
(as a core developer|release manager|triager|contributor|..)...
 it allows me to ....

# possible solution (optional)
We can (build this bot|use a GitHub App|....) 

Action item: Vote

If you see a comment that you agree with, if it is something you also wish to see, you can react to it with 👍

Deadline

It would be great if you can leave your comment before October 1, 2019, but this is not a hard deadline. I'm actually going to be out-of-open-source from now(ish) and throughout September, so I won't be doing anything about these comments until after October 1.

[Mariatta]

Summary

I need to be able to view issues that already have pull requests attached to it.

Details

In b.p.o, we can see issues that already have pull requests, by seeing the GitHub icon.
This helps contributors looking for issues to work on, they will look for issues without PR.
Reviewers and core devs can use it to find issues that needs review.

possible solution

Perhaps add a "has PR" or "in progress" label when a PR is created for the issue.

[pitrou]

I'd like Github to remember viewing settings. In particular, I'd like issues to always be sorted by "most recently updated" every time I come back to the issues page.

[merwok]

Ability to define saved searches, shared and private.

[zware]

Ability to receive all new bug reports, without automatically receiving the full firehose of every update to everything.

[serhiy-storchaka]

In b.p.o. you can attach files to the issue. Logs, screenshots, scripts, test data, patches (not all patches are worth creating a PR).

[serhiy-storchaka]

In b.p.o. you can make some issues to be dependent of other issues. The issue can not be closed until all dependencies are closed.

It would be good also if some PR be blocked until other issues be closed.

[serhiy-storchaka]

In b.p.o. it is easy to mark duplicated issues. It is not critical, but is convenient.

[serhiy-storchaka]

In b.p.o. there are several classification categories: type, components, versions. On GitHub you need to select labels from a single large list. Statuses are implemented as labels too (some of them are only used by bots). On other hand, Projects and Milestones are not used. Can at least category labels and status labels be split on different lists?

And can unused Projects and Milestones be removed? I often click on Projects when try to assign a label.

[shoyer]

In b.p.o. you can attach files to the issue. Logs, screenshots, scripts, test data, patches (not all patches are worth creating a PR).

GitHub already supports attaching files in comments via drag and drop for a variety of common filetypes: https://help.github.com/en/articles/file-attachments-on-issues-and-pull-requests

(It looks like they only support .txt for text files, but they could probably add support for other extensions used for patches if that's important.)

[pitrou]

A bit similar to what @serhiy-storchaka wrote above, but I'd like issue type and/or category to be displayed in separate columns. It would be more readable IMHO than having them hang at the end of the issue title.

[zooba]

Ability to receive all new bug reports, without automatically receiving the full firehose of every update to everything.

How many times can I vote for this one? :)

I already miss pings on PRs because of the firehose, which has directly caused potential contributors to give up on CPython in frustration. I can only imagine this will get worse when issue updates are also there unless the "new/relevant" issues can be filtered easily.

[zooba]

"Tag owners", so that I get automatically notified when a specific tag is added.

(This one may have to be a github request, but given they added code owners, I can't see a similar file listing tag owners being out of scope.)

[zooba]

And given tag owners, the ability for the reporter to add certain tags (such as those that identify their OS or Python version), regardless of their permissions.

[serhiy-storchaka]

Ability to define saved searches, shared and private.

Earlier at least I was able to use the history of searching queues saved by browser, but since GitHub merged searches "In this repository" and "In GitHub" the history no longer work.

[brettcannon]

We could have a combination of tags and convention for nosy'ing people, e.g. stdlib modules in the title like [importlib] and then tags like OS-Windows for stuff that's more structured and doesn't have 100+ potential values. 😉