Commenting should be how people down vote. You should have to explain why it's not a good idea. Then if others agree with you, your comment will get up voted. Just as my comment is a downvote of github's downvote.

The context of this feature is that users were using comments to react without providing substance. The primary motivation is to reduce the visual clutter of non-substantive comments.

While we can agree about what users should do, users not behaving as we think they should is the whole point here. Removing the -1 reaction won't encourage people to articulate their concerns. Nor will it discourage people from writing comments that explain why something is not a good idea. It simply provides a mechanism for people to register disagreement that is less obtrusive than the mechanism they would otherwise use. A cavalcade of -1's as comments obscures and thereby prevents substantive discussion.

What users wanted was a way to gauge what features are more important, so maintainers could prioritize the important issues to the community. All asked for was to be able to up vote _issues_, and be able to sort. [1]

Instead we got reactions, and it completely missed the mark. They've made it easier to be passive aggressive. Also it lingers on your post, instead of having the unconstructive comment stand on it's own. How does one respond to a down vote, make another comment saying "... hmm?"? It's weird.

[1] https://github.com/isaacs/github/issues/9

It's naive to think that users will prefer the discreet way of expressing disapproval. They want to be loud.

Facebook and Twitter provide strong evidence that people will use reactions. I see no reason to expect that user behavior will differ when they want to express negativity. Facebook's decision to not provide this feature has long been rooted on the pretense that people will use it. That is the basis of this thread: that people will use it instead of commenting.

Also, it's really easy to disagree with what I wrote without suggesting I am naive.

> Also, it's really easy to disagree with what I wrote without suggesting I am naive.

Hence proving the commenters point about negative comments :-/

Users are also lazy (I know I am). Give them a two-click way to do something, and they'll use it over a click, emoji-hunt-and-type, and click.

I agree with how you want to conduct the PR or RFC process, where it's annoying if people are being negative without providing an alternative. I do however agree with the parent where there are plenty of times when a simple yes/no vote is what you really want. The comments are there for people to provide alternatives still, removing the -1 would just be removing flexibility for a very common case.

Then such a vote should be opt-in - that is, it should only be possible on posts where the writer has explicitly chosen to make this a possibility. That would solve the issue.

While adding another piece of state and another UI control to an interface that, AIUI, did not require any changes to support this feature, which would have delayed shipping and getting this functionality into the hands of their end-users.

But making an opt-in, allow-negative-feedback control is not feedback I think they'd be wise to listen to. Users can edit issues. I'm finding it exhausting just to think through the implications of either allowing editing of the flag, or deciding that users have to get it right the first time. I can't imagine I'd find it easier to use - in fact I am sure I would be intimidated, plain and simple, by the fear of who-knows-what happening if I did the wrong thing.

(...but then, that's the most git-like thing I can imagine doing! something-like-a-VCS that you can build entire new companies' worth of brand-new development practices around and still be utterly impenetrable without first unlearning 30 years of perfectly functional version-control experience and collective wisdom. I can't express how glad I am that I don't make things for developers. Truth is, most user bases are a joy to work with. Developers... insist on dysfunction, it's non-negotiable. I think it's part of the whole, "we still don't know how to do good software engineering" schtick. It wouldn't matter if it were a solved problem to the point of a mathematical proof, nobody would allow it anywhere near their mysterious uncharted edge-blurring code artisanship. We really, really suck, both professionally, and at being adults. For the most part, anyway.)

Perhaps it's because developers always look for edge cases, whereas "normal users" look for comfort -- or ease-of-use.

Internally when voting (informally) on things we do +1, +0, -0, and -1. Super helpful to be able to ask for everyone's opinion while they can also express the strength of their opinion.

Feel like that would be very useful

C++ standardization votes on a 5-point scale: Strong For, For, Neutral, Against, Strong Against. I think it's important to be able to express the lack of an opinion, although I guess you could do that on a 4-point scale by abstaining.

I've often wondered why the "two thumbs up" isn't really used anywhere that I've seen. It is a logical progression that gives more precision to the reaction.

For what it's worth, the "thumbs down" emoji is named ":-1:".

+0 and -0 are equal..

I believe the implied meaning is:

+0 -> support from the sidelines (like for a change that doesn't directly affect you)/something that's not urgent but would be nice

-0 -> disagree from the sidelines/disagree with the solution but can't think of a better one

I would enjoy it if they used +ε and -ε for that, although +0 and -0 is probably clearer.

like that idea! Dunno how many people have epsilon easily accessible on their keyboards though.

Those terms for code-review voting are (almost certainly) from Apache, which treats them differently. From http://www.apache.org/foundation/voting.html :

+0: 'I don't feel strongly about it, but I'm okay with this.'

-0: 'I won't get in the way, but I'd rather we didn't do this.'

(These votes are strings, not numbers, though they closely resemble numbers. See also the existence of a "++1" vote.)

Arithmetically true, but they have different IEEE 754 floating point representations.

Also, my inner mathematician understands that function limits can tend towards zero from above, or from below.

Zero ain't always just a big fat zero.

Sounds like a pre-optimization. You can get the same level of information with two comments and vote exclusively with +1's, but without the general negative aspects of what's mentioned above.

Right, if you're asking every single issue poster ever to remember to post two comments specifically for voting, versus just posting their issue itself.

Not every issue needs an up/down vote. But with the addition of -1, all issues and _all comments_ on those feature requests now have one. Which takes us back to the negative consequences outlined in this thread.

Maybe it would be better to make real user polls then? Or how about just making the downvote optional when creating the issue/PR? I think in general, down voting serves more bad than good on nearly any medium.

But the reality is, on larger projects voting doesn't help, won't work, etc.

I guess for the 90% it's ok. It'd be nice to be able to turn off.

Also, it helps in taking the community point of view. Right now, if a newbie submits a PR, one of the project maintainer might just diss him and claim his PR to be irrelevant. But if there are already some 10 likes, the latter might give a second thought and might look at it from a different perspective.

on facebook they say "like if you want A and share if you want B" obviously this is a 'viral marketing' ploy, but something similar would be simple for github

just write:

thumbs up if you want A smile if you want B

problem solved

Or they could just have a thumbs-down button, and expect a higher level of discourse than Facebook.

Or they could have trigger warnings for thumbs downs like tumblr. Best of all worlds.