PEP 581/588 RFC: Collecting feedback about GitHub Issues
Mariatta opened this issue · 29 comments
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:
- what features do they find lacking from GitHub issues, or
- what are the things you can do in b.p.o but not in GitHub, or
- 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.
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.
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.
Ability to define saved searches, shared and private.
Ability to receive all new bug reports, without automatically receiving the full firehose of every update to everything.
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).
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.
In b.p.o. it is easy to mark duplicated issues. It is not critical, but is convenient.
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.
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.)
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.
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.
"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.)
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.
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.
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. 😉
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.
If it was me, I'd consider the lack of dependencies a deal-breaker (and I have considered it a deal-breaker in other projects where a move to github issues was proposed).
In bpo when an issue number is referenced in comment it's hyperlinked but there is nothing added to the UI. Sometimes I link to the PR discussion if a library is affected and this ends up as a reference in the original PR UI. This can clutter the UI for popular issues like time.clock removal, collection.abc deprecation etc. It's also little hard to find references from other issues in CPython itself since there is no visual difference between CPython and third party library reference.
Moving these references to a separate UI or an option to hide them would be good.
Sample PR removing time.clock :
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. 😉
I think it would be highly useful to include the stdlib module name in the title as a convention. This would significantly help experts with finding relevant issues/PRs and avoid creating an excessive number of labels. It's frequently not clear based on the title alone.
Raymond raised the issue of searching for past feature requests before raising new ones on the python-committers list.
One thing that I think is hugely valuable on b.p.o is that anyone can triage bugs, without having to ask for permission or wait to be granted triaging permissions.
I haven't seen anyone abuse that ability (although I do recall one person who was a bit overzealous about closing old issues) and it's a good way for newcomers to dip their toe into CPython development. Any community member can close issues that are obvious duplicates or misunderstandings (like the reoccurring floating point arithmetic quote-unquote bugs).
@stevendaprano wrote:
One thing that I think is hugely valuable on b.p.o is that anyone can triage bugs, without having to ask for permission or wait to be granted triaging permissions.
This isn't quite true. There is some limited triage ability available to standard Users (possibly more to the opener of an issue), but several fields are not editable to those without the Developer role, including closure. Title, type, components, versions, and nosy are the only fields editable by standard Users.
However, we do have full control over who gets which permissions.
but several fields are not editable to those without the Developer role, including closure.
Adding to this, the consensus seemed rather clear that GitHub triagers should not be able to close PRs and to close issues with caution. If it's already limited for triagers, I don't think it would be appropriate to allow closure from community members. But, I do think it would be quite helpful if GitHub provided an easier way to add labels without having to assign permissions, particularly the purely informational ones.
Also, it may be worth mentioning that anyone can apply to be member of the GitHub triage team through opening an issue/application on the core-workflow repo, and it only requires approval from one core developer. Once a community member has had some experience with reviewing PRs, they can apply to become a member of the triage team and will likely be accepted if their reviews were helpful. That's how I joined the team last month.
There's a slight splinter of comments at https://mail.python.org/archives/list/python-committers@python.org/thread/IFSHRRBKRP56NOVI4DDWNWKAUK53C5SK/ (although people have been asked to try and bring their ideas here so people can 👍 them).
Perhaps add a "has PR" or "in progress" label when a PR is created for the issue.
I think it would be especially worth asking GitHub if they can add the functionality to directly attach a PR to an issue, and store the data of attached PRs in their v4 API so that we can query issues for those with or without PRs attached to them. This would allow us to easily automate the process of adding a label (unless they provide a way to search for it, similar to labels or status). A decent location for attaching PRs to issues might be in the right side column, where the existing "Assignees" and "Labels" areas are located. This might be called "Attached PRs" or "Patches".
At the moment, I believe we are limited to simply linking the PR within a comment, but there's no way to definitively tell that it's intended as a resolution for the issue. It's not uncommon to link PRs simply as a reference.
directly attach a PR to an issue
But bpo doesn't limit this to a single PR, does it? There could be competing fixes or multiple fixes required to address the issue completely.
Also, I'm not entirely clear on your use case. Typically including "Fixes #NNNNN" in the description of the PR serves my primary use case for relationships between issues and PRs. When do you query bpo issues for the presence/absence of a PR? If that's a common query we could perchance implement a bot that looks for "Fixes #NNNNN" and adds a label "has patch". (But I've lived for years without it in projects that use GitHub, e.g. mypy, so I'm not sure it's that important.)
But bpo doesn't limit this to a single PR, does it? There could be competing fixes or multiple fixes required to address the issue completely.
Similar to how to it's possible to add multiple labels or multiple reviewers to a PR, it should be possible to attach multiple PRs to a single issue. Is there a reason why you think this might not be possible or was it just my choice of wording which implied that? If it was the latter, "directly attach PRs to an issue" is more what I meant. That's why I suggested the name "Attached PRs".
When do you query bpo issues for the presence/absence of a PR?
I do this pretty frequently on bpo when looking for issues to work on in an area that I'm interested in. For example, asyncio issues that need a patch or documentation issues that need a patch. Depending on their level of experience, I sometimes recommend this process to newer contributors if they want to contribute a PR to particular area they have experience and interest in. I'm curious if others do the same.
If that's a common query we could perchance implement a bot that looks for "Fixes #NNNNN" and adds a label "has patch".
That could certainly work as well, good idea.
It's not 100% necessary by any means, but I've definitely grown accustomed to having it on bpo. It can be significantly more time consuming to simply look through open issues. Usually when I'm looking for PRs to review, I do so directly through GitHub (since there are many minor/smaller PRs that don't have associated issues).
When do you query bpo issues for the presence/absence of a PR? If that's a common query we could perchance implement a bot that looks for "Fixes #NNNNN" and adds a label "has patch".
A contributor looking for issues to work on might want to filter for issues without PR yet. So if we can add "has PR" or "in progress" when there is PR for an issue, I think that's good enough.
So if we can add "has PR" or "in progress" when there is PR for an issue, I think that's good enough.
Yeah that's probably adequate, the automation for adding the label would be convenient though. This could help bring attention to the issue for reviewers if the label was added as soon as a PR was opened for the issue, using something like @gvanrossum mentioned with looking for a Fixes #NNNNN comment.
Do you think the label should be removed if all of the associated PRs are closed (without being merged)? We wouldn't have to add this functionality to the bot if it would add too much additional work, that can probably be done manually by the core dev who closes the PR or a triager that notices the label is there when all of the associated PRs are closed.