sir-lancebot
sir-lancebot copied to clipboard
python-discord
Improved Issue-linking Logic
Description
When users link to a github issue on discord via repo#num (e.g. sir-lancebot#999), we currently (as of #998) display a purple tick all the time if it's a closed issue.
Instead, we should display a purple tick only when it has a linked PR which has been merged, and otherwise a red tick (the tick from before #998).
Reasoning
This change will allow users to easily see whether an issue was closed due to "not going to be implemented" / "duplicate" etc. or whether it was closed since it has been implemented by a PR.
Proposed Implementation
I'm not too sure about exact implementation details, but it should just be a case of using data provided by the GitHub API.
Additional Details
I spoke to @ChrisLovering about this yesterday and they seemed in favour, but wanted me to create an issue first to get some more feedback as to whether we'd like this & implementation etc.
Would you like to implement this yourself?
- [x] I'd like to implement this feature myself
- [ ] Anyone can implement this feature
GitHub itself doesn't provide this distinction (a closed issue is just a closed issue), so I'm not how this would be implemented in a practically useful way.
For example, one way of doing it would be checking for linked pull requests as you say. However, that brings the question: should we also check if the linked pull requests was merged or closed without merging? This also doesn't take into account issues closed by just a commit, or issues closed without any PRs needed (e.g. actioned items in meta or organisation repos), or just closed manually without linking what closed it specifically.
Another option would be to for e.g. an "approved" label, but that would have to be specific to a particular repo and would require consistent usage of labels which may not always happen.
GitHub itself doesn't provide this distinction (a closed issue is just a closed issue), so I'm not how this would be implemented in a practically useful way.
For example, one way of doing it would be checking for linked pull requests as you say. However, that brings the question: should we also check if the linked pull requests was merged or closed without merging? This also doesn't take into account issues closed by just a commit, or issues closed without any PRs needed (e.g. actioned items in meta or organisation repos), or just closed manually without linking what closed it specifically.
Another option would be to for e.g. an "approved" label, but that would have to be specific to a particular repo and would require consistent usage of labels which may not always happen.
Yes, I was gonna mention the same points. Mostly, because as mentioned there are closed issues with no PR linked to it, but still.. they have been resolved, and closed manually. If someone is curious about an issue, they could just click on the link sent by the bot and check it directly on GitHub.
Hence, there is no efficient way to correctly implement this, and ensure that it never shows false results at the same time.
Making the difference between closed resolved and unresolved is part of the GitHub roadmap and has not been implemented yet https://github.com/github/roadmap/issues/289
GitHub API now provides information on whether the issue was closed as resolved or not planned via the state_reason key.
See example: https://api.github.com/repos/python-discord/bot/issues/2875
Rather than checking for a linked PR which could complicate implementation, we could maybe check for this instead and display either a purple closed icon or github's gray closed icon.
Yeah, since that exists now it's definitely the way to go. Marked as approved