Up-votes instead of down-votes on RFCs

[Centril]

Currently, some RFCs get a lot of down-votes. This can be especially frustrating and discouraging for new users to the RFC process and Rust community in general. Spending a lot of time on writing an RFC only to have it down-voted a lot may be very bad for the self-esteem of the user which may cause the user to not continuing on improvements or writing an RFC in the future.

Down-votes also have somewhat of an avalanche effect - if one user has down-voted a proposal, it becomes easier to down-vote even without reading the proposal in-depth.

A more friendly and constructive way of disagreeing or showing disapproval, either of details, or the proposal in general, is for one (or several) persons to comment on what they are disagreeing with, and then other people can upvote those comments to show that they agree with that particular perspective. This method of discussion also provides context to the author allowing the author to makes changes to the proposal that are in the direction requested by the user commenting.

This costs more than habitual drive-by-downvoting, but helps the user and the RFC process more, which in turn helps the Rust community at large more.

Therefore, this is a plea for people to not down vote and instead up-vote good comments (and to not down-vote comments either). This is about self-policing and showing respect for the work and ideas of others. And not currently about enforcing a policy (i.e: “legislation”).

[eminence]

Small observation: Discourse (the platform we’re using right now) only has “Likes” – it does not have “Dislikes”

[Centril]

Right. This post refers only to https://github.com/rust-lang/rfcs

[eminence]

Yep. I was just pointing out (not very clearly), that other platforms (like Discourse) have implemented your idea.

[mbrubeck]

[scottmcm]

I’m not certain that every RFC only having s on the OP is helpful either, though. It seems that thumbs in both directions should perhaps be removed from the OP, if we go this way, moving things to particular aspects described in comments.

Personally, while I agree drive-by- is bad, I found the thumb summary in the OP useful, so long as the negative votes came with an explicit comment.

[petrochenkov]

Upvotes and downvotes are symmetric, they are agreements and disagreement, “+1” and “-1”.
There are plenty of reason to leave a “-1” without a comment - no time to explain, an explanation was already written by someone else, etc. The same is true to for "+1"s to even more degree - most of people leaving “likes” don’t explain anything.

Disagreement is also not an insult towards the author in any way, the possible self-esteem effects are self-inflicted. Accepting rejection is a useful skill in general, you can’t make other people never say “no” to you in real life, right?

If only upvotes are shown it creates an illusion of universal agreement and consensus when many "+1"s are given, which may be not true. Discourse suffers from this as well, as was previously mentioned.
To fight this effect, reactions can be turned off entirely on RFCs, but statistics of votes seems generally somewhat useful to get the knee-jerk reaction from people, which is important. I would be much less opposed to removing reactions entirely, than to removing only downvotes though.

[Centril]

Of course, disagreements are not insults and/or prejudiced against the author themselves. However, with disagreement without context, with no hint as to why the proposal was bad, there is little room for improvement. Furthermore, not everyone may have the same reason for disagreement. Some may feel the proposal is too vague, and has too few details. Others may feel it is too broad in scope and need to be more streamlined, i.e: a good proposal is in the core, but it is drowned by other things. Some may dislike the current syntax of the proposal, which the RFC-author could change for the better. One group thinks the proposal does not fit Rust, while another dislikes the core idea of the RFC. If the author is aware of why people dislike the proposal, then they may improve it.

I don’t believe a stream of up-votes and one of down-votes are symmetric. As an analogy, consider a novelist who has spent a few years writing a book they believe in - (sure, RFCs do not take years to write, but well a non-trivial amount of time) - on release, all they get is “this novel is crap” - and the novelist, whose self-esteem was not battle-hardened to begin with (a realistic scenario), never lifts the pen to write again. So, the effect of drive-by-downvoting (without given context) may be to discourage the author from writing some other RFC in the future (I may be re-iterating this point, but it’s a good point to re-iterate). People willing to do language-design, is not an inexhaustible resource, and we should treasure it. Accepting rejection in discourse is useful to learn, but not rejection without context.

I don’t, however, believe that having no time to explain why a proposal is bad is a valid reason to leave “-1” without comment. The author may have spent a great deal of time writing the proposal. At the very least, to respect their work, you should spend a little time explaining why you disagree or simply agreeing ("+1") with someone else’s comment that disagrees with context.

With respect to the illusion of universal agreement and statistics, I believe that, with a few up-voted comments of dissent at the top of the RFC-thread, it is still fairly easy to get a sense of whether or not the proposal has community approval or not. I don’t deny however that tallying may become more difficult, but I believe it is a price worth paying, while others may disagree.

To sum up: Disagreement is healthy and fine, but it should come with context.

[Centril]

There’s of course the technical problem of actually disabling votes in either way - maybe GitHub can help us there? (we have a certain weight as a community after all perhaps?)

Negative votes with an explicit comments sound OK; but I’d argue that up-voting a dissenting comment makes it easier to gauge aggregate support for certain viewpoints. +1 or -1 is perhaps too blunt an instrument? Can we have emojis for “I like the proposal but please change the syntax”?

[petrochenkov]

As an analogy, consider a novelist who has spent a few years writing a book they believe in - (sure, RFCs do not take years to write, but well a non-trivial amount of time) - on release, all they get is “this novel is crap” - and the novelist, whose self-esteem was not battle-hardened to begin with (a realistic scenario), never lifts the pen to write again.

This phenomena is so well known there’s even a play about this

[scottmcm]

Small observation: Discourse (the platform we’re using right now) only has “Likes” – it does not have “Dislikes”

I wonder if that contributes to heavily-'d RFCs, actually. The pre-RFC gets a few likes, even though there are a bunch of negative comments, so it gets turned into a full RFC, where the same negative feedback comes out as extensive 'ing.

[repax]

Removing reactions altogether would not be helpful. It would only lead to a dispiriting amount of literal “+1” replies. You do remember what github was like before, right?

[Centril]

We could probably do better than -1 and +1 or just Yay! / Nay! comments with a more directed multi-answer poll on the RFC with choices like:

• The proposal is not detailed enough
• The proposal is too broad in scope
• I don’t like the syntax proposed
• The ideas proposed do not fit Rust
• I like this RFC

This of course requires technical support for multi-answer polls by GitHub.

[withoutboats]

I can only speak for myself that I heavily discount downvotes when making decisions about RFCs (in the sense that I do my best to ignore them). If you disagree you should leave a comment. If someone else has already made the counterpoint you would have made, upvote that comment. Downvotes are not useful & are antagonistic.

[lacourc]

Would it be an option to teach RFC writers, that downvotes are not inherently bad?

If I had written an RFC, after reading this thread I would be more confident to trying to improve my RFC instead of abandoning it.

I also like the idea of the poll.

[JoeyAcc]

I see an issue with this. If something has already gotten negative feedback, and a new would-be voter comes along, I’d say a simple downvote on the OP will do better in terms of getting an overview rather than repeating the argument. Now, the option has been raised of just upvoting the negative feedback. This doesn’t scale. To see why, imagine the more heavily discussed RFC’s. Who (outside of the core team) actually reads each and every one of those fully? Finding the correct item in the first place can take a burdensome amount of time. Personally for me, the more traffic there is, the more I need to ignore, basically speed-reading or even skipping over the (to me!) unimportant parts.

Put differently: discoverability is much higher when connecting +1/-1 with the OP…

[Centril]

If something has already gotten negative feedback, and a new would-be voter comes along,

RFCs aren’t popularity contests… The responsible team should evaluate not how liked/disliked a particular proposal is, but rather, how well motivated it is and if there are serious concerns or not.

I’d say a simple downvote on the OP will do better in terms of getting an overview rather than repeating the argument.

What argument? The problem is that a downvote is devoid of arguments entirely, while an upvote on a comment that explains a concern or discusses an alternative is a sign that someone agrees with that particular argument.

Who (outside of the core team) actually reads each and every one of those fully? Finding the correct item in the first place can take a burdensome amount of time.

I assume that the responsible teams (lang, libs, …) read enough of comments to see if there are consequential concerns brought up once it is time to evaluate an RFC during PFCP.

[JoeyAcc]

RFCs aren’t popularity contests… The responsible team should evaluate not how liked/disliked a particular proposal is, but rather, how well motivated it is and if there are serious concerns or not.

No they’re not. But you’re missing my point, which is that it’s useless to repeat the same feedback twice. The fact that it comes from 2 different people is irrelevant. Repeating the feedback would just cloud the discussion in question without actually adding any information.

What argument?

Argument as in “a reason not to implement an RFC”. Both up and downvotes in pretty much every post except the topmost few are less likely to be seen. This is what I mean by discoverability: It’s not immediately obvious that a remark a user wants to make 1. has been made and 2. Given that the remark was made, it’s not obvious where it is for all except the most trivially short of discussions.

The problem is that a downvote is devoid of arguments entirely, while an upvote on a comment that explains a concern or discusses an alternative is a sign that someone agrees with that particular argument.

Whatever goes for upvotes also holds for downvotes, i.e. one conveys precisely the same amount of information as the other. Just with a flipped “scalar value”. If you don’t want people to be able simply convey disagreement without actually motivating it, why should they be able to express agreement without the same kind of motivation? People err both ways, and that should be accounted for. To simply disallow downvotes is to recreate Facebook: a meaningless echochamber of “me-too!”.

 I assume that the responsible teams (lang, libs, …) read enough of comments to see if there are consequential concerns brought up once it is time to evaluate an RFC during PFCP.

Perhaps I should have chosen a different term here than “core team”. What I meant was “the people most busy developing Rust”, typically employed by Mozilla.

[Centril]

it’s useless to repeat the same feedback twice

I never said feedback should be repeated. You should instead agree with other people who have already provided your feedback instead of repeating.

Argument as in “a reason not to implement an RFC”

A downvote does not carry a reason at all, and that is the problem.

It’s not immediately obvious that a remark a user wants to make 1. has been made and 2. Given that the remark was made, it’s not obvious where it is for all except the most trivially short of discussions.

It doesn’t have to be immediately obvious that a remark has been made. People should spend the time at least skimming the thread before repeating what others have said.

Whatever goes for upvotes also holds for downvotes, i.e. one conveys precisely the same amount of information as the other.

You are discounting the harm it does to people who write RFCs only to seemingly get their ideas bashed without any motivation as to why it is a bad idea. Therefore, upvotes and downvotes are not each others “mirrors”.

why should they be able to express agreement without the same kind of motivation

That seems like a different conversation “Should we disable up votes?” that we can have.

What I meant was “the people most busy developing Rust”, typically employed by Mozilla.

Eventually, it is a specific team that has to decide whether to close/merge/postpone an RFC, and they’ve signed up to spend some time on RFCs.

[notriddle]

Whatever goes for upvotes also holds for downvotes, i.e. one conveys precisely the same amount of information as the other.

Except that an RFC already includes a bunch of self-justification in its text, so in many cases, if someone wants the RFC to be accepted, their reasons for wanting it merged are already there.

The same isn’t usually true for dislikes.

Should "down-voting" be core functionality in discourse?