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:❗) 👍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! ↓

[TPS]

👍❤️

[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! 🙇

[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! 🙇

[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 👍" box in that line. Still, you 🤘!

[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 💀 (no text), and that will end up getting counted as a +1.

[TPS]

@Mottie You, sir, deserve my deepest respect. 🙇

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...

[TPS]

@Mottie I see ":+1: 1 (from hidden comments)" on this issue, though #640 (comment) & #640 (comment) 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 👍 posts are from myself & @marcelmfs. Are you saying @marcelmfs both posted & 👍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. 🎉

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]

refined-github/refined-github#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! 🙇 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. ☺

[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.

[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.