Apologies if this is not enough of a coding question - please refer me to the right Stack Exchange platform if there is one more relevant for this question.
I had a problem with yarn / webpack with a create-react-app and I was not the first one - the issue has been reproduced and discussed before on GitHub.
Is there a way for me to favorite this issue, or, in any other way follow progress on this issue, while not getting in the way of the discussion (since it seems they covered everything I was struggling with already)?
There's already a comment which suggests kind of the right solution.
But the feature actually has a different name on GitHub, and I think calling it "watch" is confusing for people who aren't that familiar with GitHub's UI.
(there's a big "Watch" button on the top of the issue, but it's on top of all pages of the repo, and it's for watching the whole repo, not this particular issue!)
It's actually called Notifications, and it's down on the issue's right sidebar:
After clicking it, it shows that you are now "following" this issue:
Related
I saw people add many graphs, analytics, badges and many more things in their github profile. But how do they do this? See the attached picture and tell me about the process please.someone's github profile
you seem to be new here to Stackoverflow. Stackoverflow is a site where programmers help one another solve problems or issues that they are having with their code, environment, etc. Generally a question such as this would be closed, well at least from my experience. When asking a question you should probably ask something related to code or an issue (never ask how to do something with no existing code because people don't like that, coming from experience). Really only ask a question if there's an issue and a solution.
Back to your question, you can get all that stuff in that screenshot under stats here and you can add the tech stack stuff with any old github readme badge like this one. Just add what they tell you to your profiles markdown file, if you don't know how to do that look here.
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
A user posted a comment to an existing issue on one of my GitHub repos and his comment should really have been added as a new issue. There is now a whole mini-thread that is misplaced. Is there any way to move these comments to a different issue? I've seen a number of questions on moving issues amongst GitHub repos, etc, but haven't been able to find anything on moving comments.
You can "Reference in new issue" clicking on the "..." button of the comments, then create a new issue with these comments and continue on it.
It's not perfect but it could help moving the discussion elsewhere.
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.
It would be really great to have a Github issue be in an intermediary "Resolved" state before I close the issue.
Right now, I have a "Resolved" label and I manually select the issue and change it's label on the web after I commit. Is there a way I can do this from the commit message?
I am sure this is a common problem. How do you guys solve this?
I have never used Github API but can this be done using the API If I were to do this myself?
Since September 14, 2016 you could manage your states with projects. See image below:
Reference and source: GitHub - A whole new GitHub Universe: announcing new tools, forums, and features.
I know it's not like a new state like "needs verification" because you can't like #NevikRehnel said in his answer. But you could make a column named "open", "needs verification" and "closed" and all the issues can you list in correct column.
No, Github issues only support two states (open and closed). Any other "states" must be realized via labels, as you are already doing right now.
And as of right now, there is no way to apply labels from commit messages.
You can always request such features from Github support of course, and they might be implemented at some point.
You can manage this problem using this method : Adding and reassigning github issues via commit message.
A simple ruby script will run on each commit, and check the commit message looking for ~myLabel and =assignedMember to update correctly the issue.