Nuke unwanted reactions

[Centril]

Depends on #209.

This PR bans the use of the 👎 and 😕 emojis on issues, PRs and comments on the RFCs repo and the rust-lang/rust repos.

This is based on going through all open issues and their comments every N minutes for the reactions we don't like and removing them. Due to the number of comments, it might hit the rate limit.

I haven't tested this against a live repo, so please go through the code :)

Relevant GitHub API is documented here: https://developer.github.com/v3/reactions/

---

See discussion on internals re. why we want to do this: https://internals.rust-lang.org/t/up-votes-instead-of-down-votes-on-rfcs/6309

[ishitatsuyuki]

If you're going to GET a lot, conditional requests with caching can help as they doesn't get counted toward rate limit.

[SimonSapin]

This PR is at least missing something important in its description:

Why?

I think that "reactions" are an useful substitute to low-content comments. (And the amount of comment is already an hindrance in some RFCs.)

[Centril]

@SimonSapin The rationale is discussed at https://internals.rust-lang.org/t/up-votes-instead-of-down-votes-on-rfcs/6309.

My experience is that 👎 reactions don't particularly substitute for low content comments; they get made anyway. Instead, 👎 acts as a sort of a cheap and easy way to drive-by down-"vote" an RFC without giving context and explaining anything and gives a false impression that the reaction actually is a vote (which it isn't).

This PR implements the less "passive aggressive" version of the idea in Niko's comment here.

[Centril]

Some investigation re. conditional requests:

It seems that the If-None-Match header (using ETag) is sensitive to new reactions on issues, but not for comments. The end point here is: https://api.github.com/repos/:org/:repo/issues.

However, the end points:

• https://api.github.com/repos/:org/:repo/comments
• https://api.github.com/repos/:org/:repo/issues
• https://api.github.com/repos/:org/:repo/issues/:issue
  are not sensitive to new reactions on comments.

Therefore, you will need to at least go through each open issue and get the comments.
The end point:

• https://api.github.com/repos/:org/:repo/issues/:issue/comments
  is sensitive wrt. ETag for reactions.

The end points:

• https://api.github.com/repos/:org/:repo/issues/:issue/reactions
• https://api.github.com/repos/:org/:repo/issues/comments/:comment/reactions

are always sensitive wrt. ETag for reactions.

Since we have all the comments saved, we could also save the ETag for the reactions endpoints (per reaction) and simply go through all the comments in the database for all open issues. That way, most comments will always get a 304 and you don't have to fetch the list of comments either.

We can do the same for issues, save the ETag for each issue in the database and conditionally fetch the reactions pages for all open issues in the database.

[Centril]

Just noticed a bug here. If the issue does not have an unwanted reaction, then the reactions for the comments won't be processed at all.

[Pzixel]

If you ban negative reactions then you have to ban positive ones as well. Becuase othervise you just make a bias in favor or any feature that gets an RFC thus making community opinion even less valuabe than it is today.

To be honest, I see this proposal as a try to implement RFCs that community dislikes. Just ban their dislikes and you will face just pack of guys that have time and ability to write a comprehensive answer. Compare it to multiple guys that have a right to upvote an issue and here we see the bias in favor of RFC creator.

I don't believe that it's how process should go.

[Centril]

I don't think this is the right place to litigate whether this change should be done or not. I'd prefer to focus on the technical aspects of how rfcbot should operate here.

However, for now, I'll address your points, but please move further discussion elsewhere.

If you ban negative reactions then you have to ban positive ones as well.

This would still need to be done via some mechanism that this PR provides. In fact, removing 👍 is just a matter of changing the configuration in rfcbot.toml, so this PR would enable that subsequent change if we want.

Becuase othervise you just make a bias in favor or any feature that gets an RFC
To be honest, I see this proposal as a try to implement RFCs that community dislikes. Just ban their dislikes and you will face just pack of guys that have a time and ability to write a comprehensive answer. Compare it to multiple guys that have a right to upvote an issue and here we see a bias in favor of RFC creator.

Comprehensive and technical answers should be given in opposition to RFCs. Just writing a comment with "I don't like this" is not valuable, and neither is repeating what someone has already said. If you don't have the time to write your own comprehensive answer, then agree with someone who did by marking their comment with 👍. Just marking an RFC with 👎 gives no context and no chance for the author to respond. From that reaction, it is unclear whether the one who reacted disliked some minor detail, something more profound, if it is something fixable, and so on. Perhaps they did not like the syntax but the semantics were fine? Meanwhile, an RFC is already expected to contain its own technical arguments.

Further, 👍 can both mean "I agree with this" and "Thanks for all the work you've put through, even if I don't fully agree with the proposal as-is".

The way you've portrayed the RFC process is not actually how it works. It is not a popularity contest, so 👍 and 👎 are not to be taken into consideration. And they really are not taken into much account during a (language) team meeting. What happens instead is that the team members discuss the technical aspects of the RFC without consideration of popularity and some arguments and then they postpone a decision until some other time, or they postpone/merge/close the RFC.

[dpogretskiy]

It was clearly stated, that this PR is meant to shut unwanted reactions down, especially when you are an RFC author. That is not technical aspect of how rfcbot operates, determining which reaction are wanted or not. Not everyone has enough free time to read through all comments, that clearly means they are not allowed to express any ideas or thoughts. Sure.

Further, +1 can both mean "I agree with this" and "Thanks for all the work you've put through, even if I don't fully agree with the proposal as-is".

This is not valuable either. -1 can both mean "I don't agree with this" and "Thanks for all the work you've put through, even if i don't agree with the proposal at all"

If someone comes to express any thoughts on RFC's it clearly means that they care about language, and they are free to express their thoughts in any form they feel suitable. Every bit of feedback is valuable. If you'll just come policing emojis all over the place, more than that, in such a silent manner, don't expect anything good to happen to the community.

To me all those -1 are technical enough. They are showing that some RFC's solve illusory problems.

[aturon]

Process note: a PR like this represents a significant policy change that needs an RFC and ultimately consensus from the Core Team -- the previous internals thread is not sufficient. As such, I'm going to close out this PR, and also lock it to avoid further heated discussion.

@Centril thanks for doing the implementation work; I'd be happy to talk with you about an RFC separately.

[anp]

Thanks @aturon for handling this.

To everyone in this thread: we all lose when discussions become like this. I've added an official CoC and moderation policy to this repository, and I intend to enforce them very strictly.

If you're reading this thinking "wow that response is disproportional" I'd like you to consider some responses to things said in this thread:

If you ban negative reactions then you have to ban positive ones as well.

OK. These reactions have caused a bunch of issues on RFCs. They can be demoralizing, and drive-by up/down reactions do nothing to improve the quality of decisions made. Not that this is my decision (as Aaron mentioned, needs an RFC), but it's certainly not something that should be dismissed out of hand.

To be honest, I see this proposal as a try to implement RFCs that community dislikes.

Statements like this one are not welcome here. This is an argument made in very bad faith. The RFC process doesn't work if we all assume that everyone involved has poor intent. In reality, the vast majority of people involved in the RFC process have great intent and are kind, thoughtful human beings. I am not saying that this PR as proposed was a perfect idea (and I think Aaron was right to refer the decision to the RFC process), but this kind of statement is either woefully misinformed or willfully negligent and either way it's unacceptable.

Just ban their dislikes and you will face just pack of guys that have time and ability to write a comprehensive answer.

Two things. One, the RFC process would be SO. MUCH. BETTER. if every conversation consisted entirely of well-written and researched responses. Up/down votes are really not a useful signal at all. Second, please refrain from using gendered language when talking about general participation in the Rust community -- it's a place for people of all kinds. Not just guys.

It was clearly stated, that this PR is meant to shut unwanted reactions down...

In order to improve the quality of the conversations around RFCs and to focus on actual, concrete arguments against accepting an RFC.

...especially when you are an RFC author.

This motivation is not listed in the PR description, and as such this is also a bad faith assumption. Making criticisms about people rather than process/ideas is not acceptable here. Please consider how you would like your public actions to be interpreted and whether you would expect to be given the benefit of the doubt if you did something that people disagreed with.

If someone comes to express any thoughts on RFC's it clearly means that they care about language, and they are free to express their thoughts in any form they feel suitable.

No. This community is built on the ideal (among others) that not all feedback is constructive, and that as a community we must be intentional and careful about how we interact in order to reach good decisions and move forward together. AFAIK the RFC process does not have a notion of guaranteed input.

Every bit of feedback is valuable. If you'll just come policing emojis all
over the place, more than that, in such a silent manner, don't expect anything good to happen to the community.

Not every bit of feedback is valuable. If instead of writing this response I were to say "this thread is horrible and I want nothing to do with it nor the people who've replied to it" with no further explanation, would that be actionable feedback? It might be true. It might even be helpful for some of the people involved to know that I did not want to interact with them. But would a blanket criticism about all statements and all people involved serve to do anything other than escalate an already tense situation and to make me feel a little bit better? No. It would accomplish nothing valuable and it would be without value. It would be actively harmful and that kind of feedback is not welcome.

If not all feedback is valuable to the process, then the community needs to have conversations about what kind of feedback is valuable. In the past, this has resulted in the RFC process itself. The internals thread linked by the author of this PR is another example of trying to have a conversation about what kinds of input and feedback are valuable. You could have written a post focused only on why this kind of feedback is valuable rather than making unkind, easily refuted blanket statements.

[unquoted criticism of the PR author, pointing to an RFC they proposed]

This is extremely unprofessional and well outside the bounds of acceptable behavior described by the Rust CoC (and now the CoC on this repository). I've chosen to block the author of this comment on my personal GitHub account. If they want to continue this conversation, they can email me directly at [email protected].

[unquoted accusations about self-esteem motivations for this PR]

This is extremely unprofessional and well outside the bounds of acceptable behavior described by the Rust CoC (and now the CoC on this repository). I've chosen to block the author of this comment on my personal GitHub account. If they want to continue this conversation, they can email me directly at [email protected].