Auto-magically & retroactively have posts that are only ±1, &c, converted to reactions & hidden/deleted

[TPS]

To fix issues like #18 recently not loading because of death by 1300 (❕:bangbang:❗) :+1: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, :100:, +∞, :shipit:{?}, 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!) :godmode: 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! ↓

[TPS]

:+1::heart:

[TPS]

If this is ever implemented, the intermediate post should evaporate & convert to reactions on original post. 😜

[TPS]

Response from GitHub:

Thanks for reaching out. Yes it might be nice to go back and clean up all the +1 comments etc. and convert them into reactions.

I can't make any promises, but I have definitely added it to the feature request list and will share it with the team for consideration.

Regards, Daniel @danayel GitHub Support

[TPS]

@sergei-ivanov I'm honored by your support! :bow:

[TPS]

Another issue that would benefit enormously from this is #215! 😵

[The-Compiler]

I think there are two different issues:

• converting existing +1 into reactions (what this issue is about)
• preventing new +1 - either by introducing some UI change to nudge users to use reactions instead, or by not permitting posts containing exactly +1 at all.

[TPS]

@The-Compiler I suppose 1 could split this into 2 (i.e., pt.1="retroactively" & pt.2="auto-magically"), but neither part is particularly satisfactory on its own, & I think the same backend implementation could handle both more easily than just 1-or-the-other.

[TPS]

From @radek-holy:

@TPS, as you can see, there are people who intentionally use comments instead of reactions. They have their reasons. So I believe that if GitHub starts to convert these comments into reactions, they will start write such comments that would not fit the GitHub's regexp since their goal is to post a comment (and to express support), not just to express support. So, my question was more about those emails that are intended to work around this issue regardless of their content…

I'll reply here as not to spam #283: Practically, such non-content support 👍s are spam on the channel for everyone else who's subscribed (so is inherently selfish), & causes other problems as detailed above. I'd rather have those folks put the effort into a useful response/comment, xor just minimally react, not the degenerate-hybrid spam. Besides, all this conversion is to be @ the repo admins' discretion, as mentioned above.

[Kubo2]

Response from GitHub:

Thanks for getting in touch! It isn't possible to convert emoji comments to reactions at this time. We've added your idea and rationale to our internal Feature Request List so the team can see it. It might be something we support in the future, but we can't promise when it will happen.

All the best, GitHub Staff

[TPS]

Hey, @Mottie, if you want a really good challenge, userscript this! :bow:

[Mottie]

I don't think it's possible.

From looking at the reactions API, you can create a reaction, but it will only be your reaction; there is no way that I can see to add more than one thumbs up to the top issue. Also, you would need to have authorization to edit or delete "+1" comments from the thread.

I really wish there was some way to add a webhook or service integration where when someone only posts a "+1" or equivalent, it automatically adds it as a reaction to the OP in their name and deletes the comment. It wouldn't solve this issue of converting retroactive "+1s", but it may stop people from their current bad habits.

[TPS]

I didn't mean as an actual implementation of the whole functionality, but merely what 1 sees: Something like (on top post) "862 👍s removed & should be added here" or some such, but less tacky wording. 😜

[Mottie]

The GitHub issue comments userscript will hide "+1" comments - it also hides stuff like "+1!!!", "++1", "+9999", "+1 please", ":+1:" (including a wall of +1's), ":100:", etc. It won't hide the comment if there is more text than that.

I just updated the userscript to include a count of how many comments were hidden. So, it won't count comments that have a "+1" with an explanation...

In #215, the userscript initially hides 112 comments, but after you click "view more" - and check & uncheck the "Hide +1s" option (I still need to fix this) - it shows that a total of 197 comments are hidden.

This is probably the best I can offer at this time .

[TPS]

@Mottie The only addition I can think of that's possible, perhaps: add, e.g., those 197 👍s, to the top-post's 👍-count or as an additional "& scraped: 197 :+1:" box in that line. Still, you :metal:!

[Mottie]

Ok, latest update will now add a little extra comment to the top post

If there isn't a +1 reaction, it adds a comment to the post

I ended up tweaking the code a little so the hidden +1 count may be a little different. Also, it automatically updates after more comments are loaded using the "View more" button.

Note: A comment may be hidden if someone posts one or even a bunch of random emoji like :skull: (no text), and that will end up getting counted as a +1.

[TPS]

@Mottie You, sir, deserve my deepest respect. :bow:

Browsing #18 (even after "View More) is _such_ a joy! But is the max # of scraped reactions 256?


[Mottie]

Oh weird... I guess the thumbs up button can have different values. That's why the "256 (from hidden comments)" isn't inside the button. I'll fix that when I get some time today.

The 256 is because when you hit the "1560 more items not shown View more" button, it only adds 200 more comments... scroll down and you'll find a "1360 more items not shown View more" button...

[Mottie]

Ok, the userscript has been updated again... it now makes sure that repeat +1-ers only get one vote.

[marcelmfs]

+1

[TPS]

C'mon, @marcelmfs, you can do better than that❗

[marcelmfs]

I thought that the +1 post would be automatically converted to :+1: reaction, as per the title of the issue. Consider it a failed test case. :D

[TPS]

@marcelmfs Only if you yourself had already convinced @GitHub to implement it.… 😜 & my official test case is second post, above.

[arshaw]

I've created an alternative UI for browsing and ranking Github Issues. See my newly created project:

ghi-scoreboard (Github project) example scoreboard (fullcalendar) blog announcement

One of its features is the ability to use these lame +1 comments for ranking purposes (albeit aggregated on the server-side, periodically). If you set aggregateComments:true, can you sort by plusComments (+1 or 👍 within a comment) or plusScore, which combines comments with real reactions.

Hope it comes in handy for some of you.

[TPS]

Seriously nice work, @arshaw! I really appreciate the work you put into it, & truly hope @GitHub takes notice!

[asbjornu]

Can't the subscribe button just count as a vote?

[TPS]

@asbjornu Not really.… E.g., I'm actually subscribed to more issues than I've 👍ed, even some I've 👎ed, because I want to be notified on updates, whether or not I've any reaction (some because I'm indecisive, but others are interesting w/o my having any reaction), or because I don't have enough standing in the project such that my reaction is relevant to the devs.

[asbjornu]

@TPS, good point. But my experience from other issue trackers tells me that being able to up and downvote issues is something that are integral to the business domain of issue tracking and that it would make a lot of sense for GitHub to implement it. The possibility to react with emoji to comments is a step in the right direction, but does not give everything up and downvoting gives in other systems such as Trello, Jira, YouTrack, UserVoice, etc.

[TPS]

@Mottie GitHub issue comments userscript seems not to work at all for me anymore, but I'm not sure if because it's from my side, or something @GitHub. Is it still functional for you? :cry:

[Mottie]

It's working for me in this issue... hiding 2 +1s in the popup but only showing +1 from hidden comments in the first.

[TPS]

It must be my setup, then. Thanks, @Mottie.

[Mithgol]

Remember that a “+1” comment is not only a reaction, but also a (somewhat “greater” and “more powerful”) alternative to the “Subscribe” button. The following alternatives are currently available:

• hit the “Subscribe” button to receive notifications in a longer https://github.com/notifications list,
• write a “+1” comment to receive notifications in a shorter https://github.com/notifications/participating list.

[TPS]

@Mithgol As mentioned, earlier, all those reasons are particularly selfish. If 1 wants to actually participate, let'em do so! If 1 doesn't, don't! But don't pervert the tools for 1's own ends to the detriment of others!

[TPS]

@Mottie I see ":+1: 1 (from hidden comments)" on this issue, though https://github.com/isaacs/github/issues/640#issuecomment-207202008 & https://github.com/isaacs/github/issues/640#issuecomment-225580472 should be 2, right? Both comments are properly disappeared, though.

[Mottie]

Internally, the code keeps a list of the names of all commenters, so duplicate posts with a +1 are ignored.

[TPS]

Yes, but the 2 :+1: posts are from myself & @marcelmfs. Are you saying @marcelmfs both posted & :+1:ed the original post?

[Mottie]

Your original post (the first one) has a +1, thumbs up, 100... and all that stuff that counts as a +1 by the algorithm. So the second post is considered a duplicate.

[dessant]

I've made a GitHub App that deletes +1 comments, and encourages people to use reactions instead. :tada:

https://probot.github.io/apps/reaction/

[TPS]

@dessant Fantastic! Now only if @GitHub / @Microsoft would install this globally!

A suggestion/clarification: Does that "Edit Issues" permission allow to accomplish the rest of this RFE, adding the reaction meant by the now-deleted post?

[dessant]

@TPS, the permission is used to edit/delete comments. GitHub Apps cannot submit reactions, that is reserved to OAuth Apps, though those need to be installed individually by the user.

There is no clear way to solve this ourselves at the org level, short of creating a fake reaction bar at the bottom of the issue body that imitates the real one and increments reaction counts there. That would still be a muddy solution, because you cannot guess the intentions of the user, did they react to a recent comment with a +1, or are they agreeing with the goals of the entire issue? You would see otherwise misguided issues that received a reasonable comment along the way appear to have the support of the community.

A sensible approach would be to educate users, show a warning about the consequences of a +1 comment when they are about to submit the post, and suggest the use of reactions instead. I agree this could be implemented globally by GitHub.

[yakov116]

https://github.com/sindresorhus/refined-github/pull/1526 was somewhat implemented here

[lukehefson]

Hello all! I'm a PM at GitHub and I just wanted to leave a note here to say that we shipped something that should hopefully help with this: https://blog.github.com/changelog/2018-09-24-hiding-repeat-comments/

I know that this solution doesn't absolutely address the title above – so I don't expect it to close this issue out – but I hope that it goes some way to help 🧡.

I'd love to know your feedback. How can we iterate to make this better? For the slightly different problem of stopping people from posting "just +1" posts in the first place – we're currently investigating what we can do there too!

[TPS]

@lukehefson Thanks very much for your attention! :bow: This is indeed a very welcome stopgap toward implementing my (😜) issue, & it works beautifully. A couple RFC/Es:

• Could it work across duplicates that aren't consecutive?
• Could / does it work to suppress the e-mail/notifications of such comments?

OT: I created a PushBullet channel @ https://www.pushbullet.com/channel?tag=githubchangelog to (try to) keep track of all the great work y'all're doing. ☺

[marcelmfs]

+1 👍

[TPS]

@JayFoxRox, @KenOrb, @ArzTe: I noticed that y'all expressed some concerns (via reactions on OP, above), but haven't otherwise detailed via comments. I'd like to explicitly invite y'all to do so, especially since we've @GitHub's 👀 via @lukehefson!

@marcelmfs C'mon, again? Haven't we been through this already⁉️ 😝

[kenorb]

Some new feature has been implemented, by grouping multiple "+1" posts, but I can't find the article about it.

[kenorb]

+1

[kenorb]

+1

[agos]

@TPS thanks to this thread I can confirm that it does not suppress email notifications 😞

[mspiegel]

To provide another perspective, in other cases it is a good thing that email notification is always sent. For example, if you have a GitHub integration that sends some kind of automated message by posting a comment on the pull request, then it's good that the emails are sent on each message.

Of course, this doesn't reduce the email spam for the +1s.