When reading someone's code I need to ask an author why he/she code that way, not another or ask for clarfication of piece of code for better understanding or suggest an alternative solution for consideration without making pull request. There fore it would useful communication in the context of the code line, so please, allow commenting on any code in repository.

Basically this

but for Gists, too.

Would be nice to be able to upload .webm's as easy as the other media, like pngs and gifs into a comment area.

I'd like to leave a comment about the current state of the code on a given branch.

It seems that as of 2014-06-13, to leave a comment on a given line in a given blob view, I have to navigate to Blame and then to the commit that introduced the line, where I can comment on the added line in the commit view.

My comment will trigger notifications to repository watchers, to people I mention, and presumably to the commit's author, but the GitHub website doesn't surface the comment anywhere other than on that old commit. My guess is that it's unlikely that many people will find it.

I could create an Issue instead, but issues connote a need for resolution, whereas I'm merely trying to create a greater opportunity for valuable action via starting a conversation.

Instead, I'd like to comment directly from the blob view to start a conversation about a given area of the code. I'd like those conversations to be easily retrievable via search and browsing.

I'm imagining something like Google Docs's commenting, where I can comment on a particular part of a document, a conversation can follow, and eventually one of the participants can Resolve the conversation.

Maybe "Conversations" should become Issues or have a similar but separate browsable and searchable index.

I am able to modify another persons comment since I have full permissions on the repo.
I find this weird. Agreed a person with full ownership should be able to moderate caustic comments (delete/ freeze)… But not be able to modify it.
Could you please fix this ? Thanks.

To fix issues like #18 recently not loading because of death by 1300 (❕:bangbang:❗) 👍s (& then having to be refiled in #604 to work-around), GitHub should now automatically & retroactively find all posts everywhere that consist solely of +1 (👍, +100, 💯, +∞, {?}, multi-/mega-👍s, & related should count, too — bonus points for "me, too" & equivalents), -1 (& related), &/or all other supplied reactions, convert them to reactions on the top/previous non-reaction-only post (repo owner's choice), & then hide/delete from view or thread outright. (Also, if any, reactions on said extraneous posts should be outright ignored!) It'd instantly solve such subscription-spamming (does anyone sane need e-mail notification on these posts?!), as well.

To give credit where due, @eddiemonge proposed this way back in April 23, 2015 & @andreynering on March 30, 2016!

↓ Don't just react & don't +1/👍-only post: Contact GitHub supporting this, also, & report back! ↓

First off, let me mention that I use a Github Enterprise instance where I work more often than Github proper, so if this is fixed already and I just need to wait for Enterprise to be updated, I'll close this issue.

I can find no method for enabling notifications, specifically email, when a comment or pull request description is edited.

The most egregious oversight is when someone edits to add an @mention, and that person does not receive an email.

I feel that notifications on edits should be the default. A method for opting out of this notification type may not even be necessary given the infrequency of which editing should normally occur.

The web interface allows for creating attachments with a drag and drop and then embedding the URL in the comment. However, there is no way to do the same through the API.

One example where this would be useful is with the Eclipse IDE and its EGit/Mylyn tooling where an issue can be accessed in Eclipse and where it would be possible to attach a "Mylyn context" to a comment to capture the working context (in the IDE, i.e. which files are open, where to focus, etc.) that is related to the comment or issue. This is a very nice feature but without the ability to attach these context files the contexts can't be shared with other users. See https://wiki.eclipse.org/Mylyn/User_Guide#Task-Focused_Interface for more details.

Excerpt from my mail to support@github.com

I'd like to raise a feature request: save drafts of comments during the time they're written (as StackOverflow does with posts, BTW).

I have often encountered the unfortunate scenario that I accidentally closed my browser tab and thereby lost my comment! This is especially an annoying problem with very long comments which were time-consuming to write.

Saving the data into browser's localStorage would suffice in many, if not all, cases in my opinion.

Even if one correctly quotes @name in a commit message, it does not prevent the person mentioned from being pinged. In many languages, @something is valid syntax, so this means that commit messages that include code using that syntax end up pinging the poor unfortunate souls who have user names that match common @something constructs.

If standard markdown quoting rules were used to determine whether a mention in a commit message were quoted or not, this would no longer be an issue. Alternatively, GitHub could simply stop considering @name syntax in commit messages to be mentions at all and just treat commit messages as plain text. Either approach would be preferable to the current state where commit messages are neither treated as plain text, because mentions work, nor as markdown, because quoting doesn't.

Particularly detailed or controversial issues, such as those here, can accrue a lot of comments. This will make conversations much easier to follow and triangulate valuable contributions.

In addition to chronological.

Sample URL #9

Analogous to #600 but for comments.

Stack Overflow style get the best answer first.

Likely implies #605

Since the introduction of GitHub reactions, users can show their support or disagreement of posts by simply adding a reaction, and they no longer need to add a comment of their own. This improvement is great as it helps keep discussions focused, by decreasing the amount of frivolous comments.

Too often, however, comment threads are still flooded with comments that look like the following:
+1
-1
👍
👎

These comments are simply worthless and annoying:

• They disrupt the flow of the conversation.
• They cause useful comments to be overlooked, as you need to scroll through endless amounts of useless comments to pick out the few that actually add something of importance.
• Each time a users posts such a comment, everyone who is subscribed to the thread is spammed with a worthless email. I know I've personally started ignoring GitHub emails more, since more often than not, opening the email is just a waste of time. I've also encountered numerous users on different posts, who wanted to stay updated on an issue, yet unsubscribed, just to stop the annoying flood of emails.

This is especially an issue on popular issue requests that have hundreds of subscribers. Every time someone leaves a comment like this, instead of just using the reaction buttons, hundreds of users are bothered with an email that doesn't add anything to the conversation.

If you need an example, just look at the following issue discussion thread, where the number of useless comments amounts to several hundred: #253
If you want to get a feel of what I am referring to, just subscribe to any of the popular threads in this repo, and watch the flood of useless "+1" emails creep into your inbox.

I am therefore adding a feature request to blacklist all comments that should really just be a reaction. If a user attempts to post a comment with just a reaction, their post should be blocked, and they should instead be prompted with a message like:

+1, -1, 👍, 👎 are not allowed as comments. Use reactions instead!

Bonus points if the following comments were also blacklisted:
+2
+1000
+9999
+WhateverRandomNumberSomeoneUses

GitHub has very poor support for helping drive discussions to completion. All it really supports currently is marking an individual comment (not a multi-comment discussion) on a PR as resolved by hiding it, as described in #251 (comment).

In contrast, GitLab and Gerrit both offer way more, e.g.:

• Marking a whole conversation as resolved (GitLab and Gerrit)
• Showing an overview of all discussions, and how many / which ones are resolved (GitLab and Gerrit)
• Navigating quickly to a discussion (GitLab and Gerrit)
• Converting a single unresolved discussion to a new issue (GitLab only)
• Converting all unresolved discussions to a new issue (GitLab only)
• Threaded discussions (GitLab only)

and GitLab even offers extra features for tracking discussions on commits outside a merge request, on images, and the ability to lock discussions.

Another issue is that when a push to a PR changes a diff hunk, GitHub automatically marks all comments on that hunk as outdated. For example, if a file in the PR is renamed, all discussion on that hunk immediately becomes outdated even though it may not be resolved, and even worse, on a force-push those discussions might vanish forever. In Gerrit, old discussions are guaranteed to be preserved and clearly visible in the old patch sets, and in GitLab there is a configurable option for this behaviour.

Here is a feature request (hopefully not a dupe?). I wonder whether GitHub might consider it.

PROBLEM

The following frustration happens to me often, even multiple times per week: I encounter a bug with some GitHub-hosted repo whose code I've installed. I Google the issue, and I find a GitHub Issue reflecting the problem. Great! But... the GitHub Issue thread is 200 comments long. There's a lot of noise. And, toward the bottom, I find that the maintainer has marked the issue as "closed." Ok, great, but... How do I actually fix it on my end? I read back through the entire confusing thread. Alice reports she fixed the problem with monkey patch; Bob reports that upgrading another package worked for him; Cate says that you must set an env var someplace, but that works only on a specific version of Windows. As a kind of salt in the wound, the maintainer then adds a cryptic remark that users encountering the issue "use the workaround above until the next version can be released." But which workaround, for which system, on which version of this software? The impact of this is hours wasted.

IMPROVEMENT:

1. When a maintainer is marking a GitHub Issue as "closed," prompt them to explicitly state how users can obtain the fix: "Hey! We see you're closing this issue. Would you mind writing a short, concise explanation of how users who depend on your repo can resolve this issue? It could be as simple as 'Upgrade this lib to 1.2.3'... If you've already written this in another comment, please click the 'green checkmark' to flag that comment for people who are looking for it."

2. When they enter the information, the solution gets lifted to the top of the issue thread with a big green checkmark next to it so users can find it (without having to wade through a bunch of tangential comments). Think of how StackOverflow elevates the accepted solution to the top.

One might say, "We can't force maintainers to do this," and that's certainly true. But, I believe that if even 1 out of every 4 developers played along with this -- and I think a larger proportion than that would do so -- it would make a big impact on many, many developers' productivity (and happiness).

• Issue opens with a question
• Below the question is a "promoted" answer that is designated as the Approved Solution
• The original ordering of all responses should stay in tact, so that everyone can see where and when the Approved Solution originally appeared.
• Consider making the "Approved Solution" a simple link, with the same text across all repositories. IE: you don't actually duplicate the solution in a box below the question, you simply link to the Approved Solution. It might look like this:
  • "There is a response to this issue that has been marked as a Solution."

You could even go crazy and give both the repo owner and the person asking the Issue permission to mark it as approved. Like this:

• "There is a response to this issue that has been marked as a Solution."
  • The owner of this repo marked this response as the solution
  • The person that opened the issued marked this other response as the solution

When there are a certain number of commits/comments on a PR, a lot of them will end up hidden.
There are cases where you create a PR but some of the code will have to be changed for when the PR can be merged and code put live (hard coded release dates that needs to be references in code to prevent or to specifically run certain code etc)

If you add a comment referencing the code that needs to be changed, this comment could potentially end up hidden and get missed.

Some way to either pin unresolved comments to prevent them being hidden, or a way for PR authors to add "needs to be resolved" items/comments would be a nice addition that would prevent these scenarios.

[I've emailed GitHub with this feedback and awaiting a reply, will update with their response if/when I get one]

Why?

Usually the most "upvoted" ( 👍 or 🎉 reactions) comments include the most useful information (e.g. cause of issue and temporary fix) for users who are experiencing the issue and are looking for a fix.

What?

Having a link to the "top" comments in issues would be handy. It would allow users to quickly navigate to the top comments.

How?

The top comments could be listed above the initial first comment.

The comments could be listed with for example a small snippet of the beginning of the comment and the amount of positive reactions it has. Thus the list of top comments would not take much screen space (one line for each top comment) but the users should usually be able to see what the nature of the comment is (e.g. is it a fix to the issue).

PS. I'll probably be adding in some mock-ups for the look of how the links could be done before sending in the suggestion to GitHub. Any feedback/ideas/suggestions would be greatly appreciated!

I think there's often a line between what is an Issue and what should be an open discussion about a code base. The Wiki is great, and Issues is great, but a place almost like a forum, but behaving the same way as Issues, could separate the concerns of real "issues". I think the Issues # should reflect actual issues that need addressing.

The Discussion tab could behave in pretty much the same manner, allowing references of Pull Requests and Issues, but add a few nuances like Pinned Discussions. It could also be a place for Open Source maintainers to ask questions of their users like: "Ideas for Version 3.0" etc that shouldn't fall under Issues.

Some of the bigger open source communities end up creating separate repos for this to avoid clutter in Issues.

I'm sure this has been discussed (But not in a Discussion Tab!) at some point and this is a little off the cuff, so please add some ideas/thoughts/etc.

It would be useful to be able to have the issue comment API have an option to return the most recent comments first similar to https://developer.github.com/v3/issues/comments/#list-comments-in-a-repository where a request can ask for specific sorting.

Use case: When performing automatic notification comments on PRs, would like to throttle certain notifications so if an event is occurring that is impacting a particular PR and a notification has already been posted, to skip posting it a second time unless some time limit since the last notification of the same issue has expired. This is useful for the users watching that PR to not keep receiving the same message multiple times unless something has changed since the first notification or sufficient time has passed that it is useful to post the same notification again.

When querying the issue comments API https://developer.github.com/v3/issues/comments/#list-comments-on-an-issue discovered that generally have to make multiple requests in order to get the most recent comments because usually there are a sufficiently large number of comments made on many PRs that result in multiple pages of results being read.

Often we want the most recent comments rather than starting from the first, and while https://developer.github.com/v3/guides/traversing-with-pagination/ provides a way to iterate through all the comments, it generally results in having to perform more queries than should be necessary.

The current minimum at the moment would be 2 assuming jumping to the last page with the second query before iterating any earlier pages in between, while supporting providing sorting similar to the querying of issue comments on the repo would reduce this on average as the most frequent occurrence would be within the last page of results

In long comment threads, it's useful to refer someone in the thread to refer to a specific comment.

Comment numbers are a common way to do this, e.g. Fred, see Jack's comment #3 in this thread.

The only thing that seems to prevent this is having comment numbers to refer to in the header of each comment.

Unless I'm missing something obvious, it /seems/ hard to refer to specific comments; date/times can't be used because 'recent' comments show the times as relative strings ("2 days ago") that change as time progresses. Comment numbering, just like issue numbering, seems like it'd be good for this, and easy to add, as internally github can surely assign unique numbers to each comment (even if deleted).

When a notification comes from discussions section, the API doesn't populate the link correctly and it's null when we receive it.

Confirmed by @codebytere at gitify-app/gitify#501

I feel like it'd be nice to be able to chat with people through GitHub. Especially in open source projects, it could be helpful to have built-in chat for public support and feedback.

Oh it's so painful when writing a long detailed code review comment and then accidentally hitting escape and finding out it's gone forever. Cache that text and put a little "Draft" marker on the page when somebody closes the comment form by accident.

If I reply to a thread as a single comment review, GitHub will show that reply comment when the full thread is viewed, but it will not show it in the pull request's timeline.

This is troublesome in a large pull request, where the full thread may not be visible (e.g. due to lazy loading).

If the thread reply comment is part of a multiple comment review, it does appear at the bottom of the pull request's timeline, as expected.

When I am viewing a comment in a review in a pull request's timeline, I can (most of the time) click the comment's permalink to jump to the full thread. Specifically, this seems to jump me to the same comment but as part of the original thread.

For example: OliverJAsh/github-pr-test#2 (review). If you click the comment permalink for "Test thread reply comment", it will jump to the full thread.

However, if the full thread hasn't been loaded (e.g. in a large pull request where GitHub activates lazy loading in the pull request timeline), the comment permalink will do nothing.

The user is then left with two options, in order to find the full thread in which a comment belongs:

1. Click all "Load more" and then click the comment permalink
2. Click the file diff permalink, directly above the comment, and then (from the diff) find the thread.

Both of these are far from ideal.

Suggestions: make comment permalinks reliably jump to full threads (e.g. by lazy loading the full thread and then jumping).

It's similar to #266 but this issue is about disallowing deleting other users' comments while #266 is about disallowing editing their comments.

IMO #266 is a bigger priority but this issue is important as well.

IMO when a user posted a rude comment:

• another user should ask him about deleting or updating the comment (by Slack/email if possible, otherwise just by another comment)
• if the comment author doesn't remove or update his abusive comment within let's say 24 hours, the organization owner can ban him
• if the comment was exceptionally offensive, somebody can even report that to the GitHub admins

Per GFM's spec: https://github.github.com/gfm/#soft-line-breaks

I would expect

hello
world

to produce "hello world" on one line without a line break.

But in fact:

hello
world

This shows up as two separate lines.

CommonMark has the same in their spec, along with demo links: http://spec.commonmark.org/0.28/#soft-line-breaks

Also with screenshots:

When posting the link to some commit on the issue (like here) it would be useful that the link to the current issue (discussing this commit) would have back-references from the commit it-self.

In other words, it would be useful to know which issues are referencing the specific commit on the specific commit page.

For example on the commit page I would like to see something like:

Originally from: #388

I found myself switching between Write and Preview way too often as I commenting. I hope @github would add an option to bring Preview right below Write just like StackOverflow's editing box.

I am only talking about comments on

• issues
• commit pages and line comment for commits

I don't think this would be helpful for online editing README.md or those Markup files, because their source codes usually are longer the screen height in editor.

The comments usually short, at least, mine were short enough to be within my screen size with Markdown code.

A switch option next to Preview would be nice, you click and Preview is gone and a live preview is brought below editing area, click again, it's back as before and you can switch to Preview tab.

Proposed for GitLab at: http://feedback.gitlab.com/forums/176466-deprecated-feedback-forum/suggestions/5799911-preview-as-you-type-for-markdown-blob-file-edit , now possibly moved to: https://gitlab.com/gitlab-org/gitlab-ce/issues/1928

This is the thread: cirosantilli/china-dictatorship#42

Someone commented there 5 hours ago so it seems that I'm the only one who can't comment anymore: cirosantilli/china-dictatorship#42 (comment)

The comment box says: "You can't perform this action at this time."

I'm not sure what is the reason for that, but this should never happen since that is my own repository.

Two possible theories I have:

• I transferred that issue from another repo recently, and archived the original repo, and there is a bug with that. But I also transferred other issues, and I can comment on them.
• the OP has blocked me after opening the issue. But I seem to be able to create issues on OPs repositories so does not look like it (didn't actually create issues, but "Submit new issue" button does show normally in OPs repo). And even if that is the case, this is a bad implementation, I should always be able to comment on my own repos no matter what.

But maybe it's just some silly setting that I changed and forgot about it ;-)

The conversation is not locked by me.

Ticket ID: 153482

Edit: 1: I had to block OP after reporting this issue because they started to misbehave by editing the title: cirosantilli/china-dictatorship#42 (comment)

We will now find out if blocking an user prevents them from further mutilating their posts.

I recommend the following website behavior:

• if I block an user, prevent them from making further edits on their posts in my repositories. They may have done useful things in the past, and are now vandalizing their own posts
• if someone blocks me, it only prevents me from commenting on threads in repositories they own. On my repos, and other people's repos, it should not. Mods of third party repos should mod their own repos.

After blocking the user the "Submit new issue" is greyed out on their repos, which makes sense.

Edit 2 GitHub replied ACKing that this is a bug:

Thanks for reaching out and apologies for the inconvenience. This is the result of a bug on our end. We are currently working to resolve it.

1. The context. After participating in several long running PRs in an environment where early code reviews are encouraged (i.e., code is sent for review as early as possible, even before testing it), I have come up with a pattern that helps me improve my review efficiency. Once I go through the entire change and leave my review feedback, I don't want to go through the full review again for incremental changes, so I find it more efficient to click on each of the newer commits and review incremental changes.

2. The problem with the above pattern. As I am going through the commits in chronological order, from oldest to newest, I sometimes I end up commenting on an issue that has already been addressed in a later commit. In such cases, the comment shows up DoE (i.e., outdated), so unless the author pays attention to every email notification, there is a good chance for it to be overlooked. To avoid this, I open two views of the PR, one where I am reviewing the commits chronologically and another where I have the cumulative view. When I find an issue in an individual commit, I switch to the other tab to double check it is still not addressed and switch back to leave the comment. This is not only laborious, it is also error prone, as I occasionally forget to double check.

3. Proposed solution. When a comment is being left on individual commits in a PR (i.e., right after clicking on the + button), github should check if the line has been outdated by a later commit in the PR and give a warning.

Great that we've finally got the basics of resolvable comments. One immediate improvement would be to have the act of resolving a comment be something you can 'draft', and send together in a batch with other comments/resolutions.

E.g., say someone comments: "Hey, I think you should do X instead because....". I comment (in a draft) "Actually I think this is fine as-is because...." and mark the comment as resolved. However, the original commenter will see that I've resolved the comment, but without any explanation as to why.

Now that we have a comment edit history: https://blog.github.com/changelog/2018-05-24-comment-edit-history/ when I click on the past revisions, it only shows a popup, but no URL change.

Also provide a way to link to a specific revision of the comment.

In Pull-Requests when a line changes any comment is auto-dismissed. But the line change is not a good indicator if the comment has been addressed or not.

See tail of conversation here: https://gist.github.com/xaviershay/8773810

Allowing the reviewer to decide if a comment has been fulfilled or not would be better. Even nicer would be an emoji based indicator of resolved (+1 ?).

When we add comments as part of an unsubmitted review, they show a pending status, which naturally implies that we could edit them as much as we like, and finally submit the review when satisfied with all the comments.
But, contrary to that, after submitting a review, those comments which we edited after saving them, show an edited status just like standalone comments would have.
I understand that this review functionality works like a draft (stage comments without actually committing them), but shouldn't we not display the edit history (in this case the last edited time) for such comments when they're finally committed (as in the review is submitted)?

It used to be the case that comments made by collaborators on issues and pull requests received a label or badge that indicated they were collaborators similar to owners/members. However, this appears to have been removed. This occurred at the same time owners were renamed to members so may have been a regression that slipped into that change.

I have raised this with GitHub Support via email and recommend anyone interested in this does the same. Currently, they are looking into it.

Here is a good example: OnePlusOSS/android_kernel_oneplus_msm8994#1

This issue has plenty of references to commits which has nothing to do with the issue and only confuse people.

Why this is happening?

Because it has some lines like:

[   82.235260] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[   82.243681] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.0.0-rc2 #39
[   17.289985] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 6286.808750] CPU: 3 PID: 1304 Comm: bnx2fc_l2_threa Not tainted 3.10.0-121.el7.x86_64 #1
invalid opcode: 0000 [#1] SMP
[    8.536416] Oops: 0000 [#1] PREEMPT PREEMPT
[    8.537863] CPU: 0 PID: 1 Comm: swapper Not tainted 3.15.0-rc6-00151-ga5c075c #1

which has #1 in it.

So my proposal is to look for the issue references either in the first or the last line of the commit message.

And I'm not sure if this should be a bug or a feature.

When commenting on an issue, after a comment is successfully posted, the "Write" textarea is automatically focused.

Restoring the focus doesn't have a real upside as there aren't many situations where you'd post twice in a row.

It has the downside of hijacking the backspace "go back" functionality, forcing a click outside of the textarea, a tab or whatever before hitting backspace to return to the issues list (which is pretty common)

Hi!

I am not sure I am writing this to the right place. My problem, when I start to write a long comment, and leave the tab for 20-30 mins (e.g. to read more about the topic, or find references, or just watch a tv show in another tab), my text disappears without any trace when I switch back to the tab of the draft. Is this behavior intentional?

Another possible cause of the issue, that I write multiple comments parallel sometimes. So I am not sure why, but I lose long drafts because of this issue. I don't have time to make experiments to find out the exact cause. Maybe later.

notes:

This happened at least twice in the last few days, so I think this is a real problem and not just my brain is playing memory games with me. :-)

I use to write about possible improvements and their implementation details to the issues tracker. This is probably not recommended because it floods the followers with notifications, but since nobody follows the repo I am currently developing, it is not a big problem. So that's why I write a lot of long comments recently.