On Github issues pages, how do you know which post contains the solution to the issue?
Take this page, for example.
The issue is closed, so we are to presume the problem is solved... yet this discussion thread (and many are much longer) seems to be mostly people talking back and forth in circles and it's very confusing to try to determine which post is intended or generally accepted to be the solution.
I was thinking it would be nice if the repo owner/representative could designate a post as what they determine to be the solution... with some kind of graphic... but I don't see that.
Ideally, if a pull request fixes an issue they would be linked by referencing the issue from the PR. For example, if a PR closes issue #123 the PR description would say closes #123 or fixes #123. You can also link them manually.
The PR would appear in the issue's "Linked Pull Requests" sidebar, and vice-versa.
For example, we can see that this PR is linked to this issue.
And from the issue we can see the linked PR.
In the issue, we can see activity on the linked PR as well as anything which mentioned it. A mention is a commit log or comment or issue or PR with something like #43878.
If the issue is closed for some other reason, ideally the person closing mentions why in a comment.
If people keep coming back to the issue and are confused, that may indicate the issue is not closed, or perhaps there is a related documentation issue.
In your example, we can see where the issue was mentioned in other issues.
And, sure enough, its referenced in issue #63056 and in PR #9 https://github.com/aws-amplify/amplify-flutter/pull/9#issuecomment-670038832. That information might help.
And we can see why the issue was closed, the change was intentional.
Unfortunately, the reason and resolution is buried in a comment. Improving the documentation may have been a better choice. That would have been done in a linked PR.
I was thinking it would be nice if the repo owner/representative could designate a post as what they determine to be the solution... with some kind of graphic... but I don't see that.
That would be nice. I don't believe Github has that feature. Posting it here is unlikely to reach Github. You could suggest it in Github Community or ask Support.
As a work around, one can make their final comment and then lock the issue so no further comments can be made. This would avoid burying the resolution. Then people would have to open a new issue if they really want to comment.
Or, one can edit the description of the issue to include a prominent reference to the resolution.
See also
Autolinked references and URLs
Linking a pull request to an issue
Related
I have this issue when I try to merge my branch to the main one for my RASA chatbot project and I want to know if there are any ways to fix this and create a pull request or should I just change my main branch to the domain-side branch
Ok so I fixed the issue by deleting the .rasa cache folder
This can occur when there are a lot of commits in your Pull Request
Unfortunately, this is a known github issue.
Thanks for writing to GitHub support and sorry for the trouble!
We have received a few similar reports regarding big pull requests. I can confirm that our team is working on fixing this problem, and I've added your report to that issue.
Unfortunately I won't be able to provide an estimated time on when this might get fixed. We know this is not ideal, but hope you understand.
Is there anything we can do to preserve our comments and alleviate this issue now and in the future?
You should be able to use our API to get a copy of the comments in this pull request:
https://developer.github.com/v3/pulls/comments/#list-comments-on-a-pull-request
https://developer.github.com/v3/pulls/reviews/#list-reviews-on-a-pull-request
If you have any question regarding using API we can definitely offer more detailed instructions.
Unfortunately I'm not sure if there's anything you can do on your part to view this pull request normally.
One thing you could try is viewing this PR in Incognito window or logged out.
I was actually able to view the PR you linked because I don't have write access to this repository, so GitHub will try to load less things for me such as edit buttons and so on. Of course this won't allow you to merge the pull request and so on, but perhaps it would help for you to look at its content?
Lastly, while we are working on consistently supporting large pull requests, you might consider keeping pull requests relatively short for now to avoid running into this again.
I hope this helps clear things up, and please let us know if you have any other questions.
Please refer to the full discussion provided here.
A year ago I have started an issue on github repository of a popular open source project. There wasn't enough data to fix it because bug was caused only by one closed source program. Recently I have stumbled upon other program that causes the bug and this one is open source. This should make it possible to fix the issue.
I have added new comment in issue providing new information, but it got no response for 10 days.
https://github.com/linuxmint/Cinnamon/issues/6253
I wonder if maintainers see comments on old issues in their notifications?
If they do did they discard it by accident or perhaps because in their experience most comments on old issues are useless?
Should I just edit last comment there slightly?
Will they see that?
Or what to do?
The good news is the project is not dead. Issues have been closed recently and PRs have been merged. Someone is watching the queue. The bad news is the project has over 800 open issues at this time which means they're probably swamped.
Open Source projects are typically run by volunteers, and that looks like a low priority issue. If you want it solved, do everything you can do reduce the work necessary to fix the problem. You've already given clear instructions on how to reproduce the problem, that's a very good start.
The single best thing you can do is submit a PR with a complete patch including tests. Be sure to conform to their developer guidelines. That project does not leave PRs open long. If you can't do a complete patch, take a stab at it and submit the PR asking for help. If you don't know where to start patching, make a comment on the issue asking for help with where to start.
Basically, do the work. If you can't do the work, show a willingness to do the work.
I posted a new issue on github for an opensource project. Shortly after posting I got a comment on the new issue saying "ya I agree and also [XYZ subject tangentially related to your ABC issue] needs to be fixed also".
On Stackexchange websites there is clear documentation specifying one topic per question: https://meta.stackexchange.com/questions/39223/one-post-with-multiple-questions-or-multiple-posts (maybe there is a better link but this is the link I found).
Where on github.com can I find something similarly authoritative to point a user to that says "it is recommended to post one topic per Github-issue"?
There isn't, and it doesn't make sense for GitHub.
Every person who owns a repo on GitHub can decide for himself how he manages the issues in his repo. Usually, you find such information somewhere in the repo. Sometimes a repo has a CONTRIBUTING.md file that details this. If it has, then it is linked when you try to open an issue. If it hasn't, look for this info in README files or in the wiki or the projects homepage.
But sometimes, you will not find it. And by that time, you start using common sense. Usually, the rule is to only discuss one issue per opened issue because that makes sense from a software development point of view. Its the only way you can label things properly, mark then done as properly, assign them to a person properly. And most importantly, it means that all info related to one issue is found at one place, making it easy to find at one glance.
Thus, virtually every contribution guidelines will state something in that direction, and when you can not find those explicitly, the general consensus and the expectancy is what I just laid out above.
Is there any documentation out there to suggest that GitHub issues are eternal? More specifically, are their URIs reliable to link to?
E.g., I want to link to a Joda-Time issue in a Javadoc to give context as to why a custom de/serializer was necessary. If the link is reliably static I'll be comfortable referencing it in code.
Yes
Git issues are completly reliable, no one can remove an issue, even repository's administrators.
A git issue will never die, the worst thing that can happen to an issue is getting locked, resulting in others not being able to comment on them, but still, it's visible to everyone.
Edit: Please note that by removing a repository, all it's issues, pull requests, wiki pages, etc. are removed. More about forks on this.
Is it possible to completely remove an issue from the GitHub issue tracker?
No, the github API only allows you to open/close/reopen issues. Here's the Issues API docs.
You can edit an existing issue (let's say if it's a duplicate) and you can change the title, description and target milestone to be something completely different. That's as close as you can get to removing the ticket, AFIK.
Update Nov 2018: You now can delete issues if you are a owner of the repository!
See "Github - remove issues entered in error"
https://docs.github.com/en/github/managing-your-work-on-github/deleting-an-issue mentions:
People with admin permissions in a repository can permanently delete an issue from a repository.
For other people (without permission), questionto42's comment shows that you can ask to GitHub support for the issue to be deleted, as illustrated here.
At May 2018, original answer:
Three 8 years later, and closing issues remains the answer (still no deletion possible).
See "The Ghost of Issues Past", where GitHub advise to check and close:
issues opened over a year ago state:open created:<2013-01-01
the ones I'm involved with involves:twp state:open created:<2013-01-01
and those not updated in the last year involves:twp state:open updated:<2013-01-01
For posterity: Deleting issues would be a bad thing, since in general they can be targets of associations on github.
But if you are willing to sacrifice the collaboration info, here is a "whack it with a sledgehammer" approach:
Clone your original repo.
Copy your issues via the Issues API.
Delete the original repo; alternatively, chose a new name for your new repo.
Re-create a new repo based on your clone.
Re-create the issues you want to keep via the Issues API.
I imagine this could potentially lose a lot of other linking information as well such as forks, pull requests, etc.
Public feature request
I wrote to GitHub in 2014-08 and https://github.com/jdennes replied by email:
Thanks for the suggestion. It's only possible to edit/clear the issue content currently. However I've added a +1 to this suggestion on our internal Feature Request List.
confirming it was not possible.
Best workaround so far
set the title to something that will never conflict with any search, e.g. a single dot ..
This may not hide the history of your blunder entirely because of the automatic undeletable "changed the title to" comments.
make the body empty
GitHub staff has the power
If something is a security issue, contact GitHub staff, they usually reply quickly, and are able to remove issues for good as can be seen at: http://archive.is/OfjVt which has issue 1 and 3 but no 2.
You can delete the entire repo if it's really important.
Possible workaround
As of 04/2019 not all issues can be deleted current work around is to edit the issue then delete the edit history, the only downside is that the issue still exist and the old title could be seen.
You could by just asking to github to ban the user that created the issue 😁
Source: https://github.com/isaacs/github/issues/253#issuecomment-290944938
Users are unable to do this, including repository owner.
But issues can be deleted by Github support. One may contact them and request deletion. It may be delayed or refused but it is an available option that can be used.
Still impossible. Another workaround to the ones suggested in the other answers is to label the issue as "deleted" (or any other label you might fancy better), to be able to filter them out if you use the github API to retrieve them. Obviously you should use that specific label only for this purpose, setting the label when you close the issue.
You can create a new repository.
Transfer (yeah it is possible) unwanted issues to the new repository.
Then delete the new repository.