-1 or the thumbs down reaction, I think is a mistake. They aren't usually that constructive, because most of the time they are used as retaliation against a specific user, instead of constructive criticism. If someone downvotes you, you tend to downvote them. At the least, it should be a privilege to down vote, like SO and HN do. http://stackoverflow.com/help/privileges/vote-down
Agreed 100% for Facebook or even Hacker News, however on GitHub it would be really useful for voting.
If you ask "Should we add this feature?", it's hard to understand what favorites mean if you don't have an anchor. Does 10 thumbs-up mean unanimous support, or is it just a small minority? It'd be nice to say "Oh, 10 upvotes... but there's 90 downvotes, so we won't do it."
FB and Hacker News are a marketplace of relatively-inconsequential ideas and thoughts. However, changes discussed on GitHub Issues can potentially have an impact on your company and livelihood.
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.
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.
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.)
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.
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.
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.
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
I think that the -1 button definitely has a place on Github.
I use Github a lot for discussing future feature development, and in that context it is really valuable to see how many people think a feature is useful or not.
Github isn't primarily a social network. In a professional context it is essential that you can also express disagreement, or that you think something is a bad idea.
In a professional context it is essential that people can express disagreement provided they write exact reasons why they disagree.
You know, "+1" usually has only one meaning:
- "I agree with whatever you're saying".
"-1" has however two separate meanings:
- "I disagree with whatever you're saying because I believe that blah-blah-blah (reasons here)"
- "I disagree with whatever you're saying because fuck you that's why"
And "-1" button doesn't distinguish between those two cases.
- Agreement: "I agree with whatever you're saying"
- Contributory : "I don't agree with what you're saying, but you elaborated your point *very* well and contributed to the discussion"
- Mercy: "I don't agree with what you're saying, but the hivemind punished you for no good reason, have an upvote"
- Popularity: "I like you and will +1 anything you write"
- Thanks: "I like what you did even if this post isn't relevant"
The second and third one are very common on sites like HN, certain places on Reddit, and Stack*
Downvotes have:
- Disagreement: "I disagree with what you're saying"
- Anger: "Fuck you, have a downvote"
- Doesn't contribute: "I might agree, but you're not helping the discussion"
- Incorrect: "This isn't about agreement, your advice is wrong and/or harmful"
I like this idea, even having preset tags ala slashdot.
Always maintained that this would make Reddit a much nicer place. Implement the vote tags, and then give people the ability to sort by votes, filtering out votes for disagreement.
If somebody gives your comment a -1 without a reason, and you are of the opinion that disagreement is only valid given a precise argument - can't you just ignore the -1's?
I'm not sure why this is such an emotional topic. Maybe I just have thick skin, but some random stranger on the internet giving me a down vote is not really even going to give me a moment of pause. Let alone so much that I feel that I have to demand rationalization from every person that cares to disagree with me.
This comment is basically a down vote of github's down vote. Comments should be the down vote, because someone needs to explain why a suggestion, answer, code change, submission, etc... is not a good option. If that comment (down vote) is a good idea, it will then be up voted.
Why should you never have to explain why you're in agreement with something? What kind of culture do we have if you only have to explain why you disagree with something?
The "positive" things about the issue/pull request etc. is presumably already explained by the author.
"Issue 1234: We need this feature because reasons A, B and C."
If you don't think that A, B and C justifies the change, send a downvote and/or explain why A, B and C aren't good enough reasons.
An upvote is sufficient to say that "Yes, I agree with A, B and C. Do it."
Of course, if you agree with the change but for reasons other than A, B or C, you can leave a comment to start a discussion. It has nothing to do with culture. It's just a way to minimize the redundant "Yes, I agree with what you just said".
But there could already be a reasonable explanation for -1 vote in the thread. Are you suggesting to repeat it or write "agree with @foobar on his comment"? That's more noise.
I'm not sure this is a downvote. It's a vote in favour of a negative and unlike HN-style downvoting, is tallied separately. You can even react with both thumbs-up and thumbs-down to the same issue.
With a tallied up/downvote system a la HN you can't tell, numerically, if a score of 1 meant "only one person cared" or "hundreds cared and there was furious disagreement".
Actually I'd be interested in a "top 100 most polarising comments" feed :-)
There has to be some way to register negative feedback so that you can find out what is widely unpopular. The key is to lower the power of individual down-votes so that an idea can’t be easily trashed to the point where most visitors won’t even consider reading it. (I find myself doing this sub-consciously in review sites and app stores for instance, where once something falls to about 3 stars I don’t even want to see what the fuss is about, I just skip it.)
One thing I’ve never seen is a vote that accounts for the number of unique visitors, or the total time that visitors spend on a page, or even contributor status, before weighing feedback. An issue that isn’t immediately important to a lot of people should require some time to decide popular/unpopular status.
A page shouldn’t show up/down status to anybody* until a significant amount of feedback has been collected, either. This would prevent knee-jerk down-votes of ideas that seem unpopular to everyone based on a few early down-voters. A proposal should stand on its own, at first. After a certain time period, the page could reveal whether or not an idea has really turned out to be popular, and at that point the cost of up-vote/down-vote could change (e.g. maybe only comments are allowed at that point, and no simple clicks).
It depends on how the PR, project or comment thread interprets the -1s. If a vote has been specifically requested then the +1/-1s are super useful. Otherwise they could be safely ignored by maintainers as at most low value ambient info ... well worded constructive criticism will always carry more weight that a -1. Also, this is fundamentally different to SO/HN ... there is no ranking, the up-vote/down-vote ratio has zero effect aside from incrementing a counter - any meaning applied is subjective.
I shall respectfully disagree. Not wanting down votes is just a way of saying "I'm offended please don't offend me I can't handle down it's it makes me sad"
It's 2016, can we stop worrying about if someone disagrees with you and just accept the fact they wanted to down vote on an issue rather than say nothing or leave a comment.
It's usually the case that it's cheap to disagree. It would be more beneficial to the review process to have those with dissenting opinions lay out a logical case presenting their concerns rather than enable them to do quicker, drive-by review.
Haven't you had feedback along the lines of, "but did you take into consideration what impact the heat death of the universe will have on your design?" ?
No, it's because downvotes actively censor unpopular opinions based on the fact that they're unpopular rather than their merit. Check out reddit some time and you'll see this happen a lot.
Yeah, that's definitely the best way of handling a rating system. The one I use on my sites (the XenForo mod one) counts likes, dislikes, agrees, disagrees and all the other ratings individually and displays that count under every post.
I think thoughtful comments with advice on how to refactor is a way better indicator than giving my PRs over to the mob. Ya thumbs down or any reaction with code is a mistake.
Still not a fan of how it's done on SO. To me the best solution is not to include it at all. If you have something negative to say about a PR or Issue, it makes more sense to explain why you feel that way instead of outright saying no. The +1 makes it very clear that you're saying "this covers my use-case." What does -1 mean here, other than "I don't want this"? Because not wanting something is not a reason not to include it when everybody is using a project for a different use-case.
Disagreement should not be restricted to only those who are willing to stick their neck out and publicly disagree and state their reasons.
Imagine this scenario. Linus Torvalds posts an utterly inane pull request. Who is willing to deal with the backlash of "disagreeing with Linus". Sure, many are, but many are not.
I just want to elaborate on this a bit more: Implementing a downvote button is inviting baseless disagreement. It makes it socially acceptable to say that you disagree, without ever providing an argument or being expected to do so - this is precisely what you don't want, on what is supposed to be a constructive platform.
This will (indirectly and directly) lead to populism, where unpopular opinions get dismissed out of hand without even considering them.
Seriously, GitHub, this is rule one of designing constructive social platforms: you never ever ever implement a downvote button of any kind.
>you never ever ever implement a downvote button of any kind.
People who don't agree with something should have a way of expressing their views. Why is it acceptable to have a +1 button but not a -1 button? Why can people agree without giving any reason for their agreement but they can't disagree without giving any reason for their agreement? It's crazy that society works in this way and that people have such an irrational response to disagreement.
> People who don't agree with something should have a way of expressing their views. Why is it acceptable to have a +1 button but not a -1 button? Why can people agree without giving any reason for their agreement but they can't disagree without giving any reason for their agreement?
Because when you agree, that means the argument has already been presented - specifically, it's the argument that you are agreeing with. That is not the case for disagreement, where a counter-argument must exist, but has not been voiced yet.
Agreement and disagreement aren't superficial opposites like you're presenting them to be.
The reason why Github added these votes in the first place is so that people can give a signal of how welcome or not a certain change is to the project. If you only provide the signal for agreement but remove the signaling for disagreement and make it costly, then you'll get more people voting one way than the other. If it costs more to disagree then you're already rigging the game towards agreement.
If I left the above with no further explanation, it doesn't give you any signal as to why I disagreed with you. One the other hand, if we were having this conversation on GitHub, people who agreed with my counter-point could react with a +1, giving you a much stronger signal about what exactly the disagreement is about.
And once someone provides a valuable counter-argument, it's no longer "rigged toward agreement."
Compared to an explanation with several +1's, a drive-by -1 adds virtually nothing to the discussion because they carry so little information.
Not everyone has to give a signal on why they disagreed with you as much as people don't have to give you a signal on why they agree with you. I don't get this argument. People may agree with 2 out of 5 things in a list and vote +1 because they don't care about the 3 other things. You still don't get that feedback from a +1, just like you won't get from a -1. There shouldn't be higher standards for disagreement based on reasons because the same doesn't exist for agreement.
> Not everyone has to give a signal on why they disagreed with you
On GitHub? They absolutely do. It's a platform for collaboration, not idle chatter. If you do not wish to support your disagreement, you probably shouldn't be posting anything there to begin with.
EDIT: I've also already explained to you why 'agreement' and 'disagreement' are held to different standards. I'm not sure why you keep repeating this point.
moe is right. And what is strange is that you keep repeating yourself.
They absolutely do.
No, they absolutely don't--GitHub says so. You think they absolutely should have to, but they do not.
Here's an example: Alice posts a feature request on the issue tracker for Project Awesome saying that the project's mascot should be changed to a unicorn. Bob downvotes it. Neither person has provided an argument for their position.
According to you, Bob is required to explain why he doesn't want a unicorn mascot, but Alice doesn't have to explain why she wants one.
You are assuming that a positive argument will always be made in support of an assertion, and that therefore a negative argument must be made against it rather than merely a contrary assertion.
But it often happens that the pro side of an issue makes unsupported assertions and unreasonable claims, then the con side makes reasoned arguments, and the pro side proceeds to ignore the points raised by their opponents.
The real problem is anonymous voting. Anonymous votes are not very useful, because for all you know, the person voting doesn't even use the software in question. Voting within a team of collaborators could certainly be useful, even without substantiation, but "drive-by" votes by random Internet people are the problem.
EDIT: Ironically, this downvoting of moe's and my comments proves our points and demonstrates why anonymous downvoting is a problem. "We should only have reasoned arguments!" they say. But when reasoned arguments are presented in opposition to their claims, they merely downvote rather than making a reasoned counterargument. They do not do as they say.
And since the cost (in time and effort) of their anonymous downvote is far less than the cost of writing a rational counterargument, the level of discourse is driven further and further down as those who are willing and able to argue their positions rationally are discouraged from doing so. Why waste your time arguing with people who do so in bad faith?
If you look at product reviews, people are more likely to write a comment if they have an issue with the product than if they don't. I'm not sure how much this applies to github topics but it could possibly provide it's own bias towards negative comments.
Also, as others have mentioned, it only takes one person to write a negative comment, then others could +1 that.
Sure, but that is already the case - posting a :+1: costs much less effort than writing a counter-argument (and is already widely socially accepted, spammy-ness aside). The addition of an upvote button doesn't change this.
That's not to say that I wouldn't like that bias resolved, but it's a bias that exists precisely because of the difference between 'agreement' and 'disagreement' that I described, and I'm not sure it can be solved in a technical manner.
How does enhancing the bias solve the issue? By not adding the downvote button this bias is enhanced. By adding the downvote button this bias is diminished. It's not a perfect solution but it's better than doing nothing.
That is not the case for disagreement, where a counter-argument must exist, but has not been voiced yet.
Someone shouldn't have to expect to come up with an alternative just to voice the idea that something sucks.
This idea leaves you vulnerable to the "something must be done, this is something, therefore we do it" problem by unfairly biasing positive votes rather than negative ones. Yes, I read your rationale. I don't agree with it.
Prior to reading these arguments I would have agreed. But I suppose I have to admit that I would prefer that someone said "This feature isn't necessary - feature Y is a perfectly good substitute" or even "this feature is inappropriate according to the goals of this project" and upvote those comments, rather than downvoting the original feature/pull request without giving a reason.
I'm not nearly as adamantly opposed to a downvote button, but I can understand the argument.
The problem here is the presupposition that a positive argument has been made. People often make claims without any supporting argument. If only counterclaims were required to have supporting argument, it would be unbalanced in favor of bald assertions.
Sometimes people make silly claims or requests or demands. In such cases, one shouldn't be required to write a reasoned counterargument. A simple "nope" should suffice.
"This is why we can't have nice things." People assume the status quo is bad or wrong and that change is necessarily progress. It begins to take more effort to keep the good things that have been achieved than it does to break them and replace them with regressions. It requires more time and effort to defend them against the onslaught of unreasoned demands because of irrational bias against the status quo.
This is true not only in software but in politics and society. But for a simple example in the software world, just look at the Metro UI: it's awful for a million reasons, a regression even from Windows 95's UI--but to some people, it's change, therefore it must be progress, therefore it must be done.
The difference is when you +1, you're publically expressing agreement with what they wrote. If someone you like writes something you don't agree with, you wouldn't +1 them. If you're having a good day, you still wouldn't blindly dish out +1's because if you +1 a controversial comment, it could hurt your reputation.
Negation is different because it's entirely ambiguous. You can dish them out freely and retroactively rationalize your intention. -1's are way more susceptible to knee-jerk emotional reactions than +1's.
A relevant example. Think of the political candidate you like the most. If someone you really like asks you to +1 a persuasive argument about their competitor, would you? On the other hand, if they asked you to -1 someone, you probably would. Even if you knew very little about them.
My experience of open source projects is that people dish out +1's freely and are reluctant to -1 as it signifies conflict. +1 is arguably the more ambiguous for that reason as it can mean "I didn't read the issue but I like you and what you're saying at a glance looks non-insane" or "meh" or "I love it". You're really underestimating the ammount of politics that can factor into these things, people will +1 something that they 90% disagree with because of who's saying it, don't kid yourself otherwise.
Nobody really cares if you +1 something crazy, maybe you were just feeling agreeable that day, or you misunderstood the comment. But if you -1 sensible things you're going to get a bad reputation pretty quickly.
That's because people don't tend to write "-1", but rather disagree with a comment explaining why. GitHub is full of disagreement. We'd be in a much worse place if that was all expressed through downvotes instead of comments (unless of course, an issue is explicitly opting in to a vote).
> people will +1 something that they 90% disagree with because of who's saying it, don't kid yourself otherwise.
Ok yeah, you're right about the politics. Bad example. But in open source, I've seen much more comment-based pushback regardless of author.
And yet, you’re making this point on a platform that has down-votes. And where I have made very unpopular statements around social issues that have been down-voted for being unpopular, so I appreciate how points that I know to be reasonable can be downvoted for being unpopular.
Nevertheless, some people find them useful.
I don’t think it’s 100% clear-cut that you should never ever implement downvotes. I’d say that downvotes need to be implemented in conjunction with a bunch of other features and active moderation policies to work well. I don’t know if HN has done so, or if GitHub has done so. But... I wouldn’t dismiss them out of hand.
(FWIW, I follow this policy: I either downvote, or reply, but never both. In this case, I disagree with you, but think the conversation is useful, so I reply. Other comments might be wildly off-topic or deeply non-constructive, and those I down-vote. But to each their own.)
FWIW unlike HN, downvoting has no negative consequences to the comment on GitHub. It's useful on HN to effectively remove the off-topic and deeply non-constructive comments. But on GitHub, it serves no such function. We're going to end up with the many abuses of -1's and none of the benefits.
As for "I don’t think it’s 100% clear-cut that you should never ever implement downvotes," perhaps. There's still probably better ways to flag inappropriate comments though. Like a flag button. Downvotes are far too general and ambiguous in comparison.
> (FWIW, I follow this policy: I either downvote, or reply, but never both. In this case, I disagree with you, but think the conversation is useful, so I reply. Other comments might be wildly off-topic or deeply non-constructive, and those I down-vote. But to each their own.)
Thank you for that insight, never thought about it that way (alas, I'm not allowed to downvote). That approach seems very reasonable.
Reminds me of the rule in programming with exceptions, either handle and log or rethrow.
> And yet, you’re making this point on a platform that has down-votes.
Yes. And if I was a HN developer, which I am not, I would immediately remove that functionality - but even then, my argument doesn't really apply here, because HN isn't really meant to be a constructive platform to begin with.
> I don’t think it’s 100% clear-cut that you should never ever implement downvotes.
For constructive platforms: absolutely, 100%. It's well understood what kind of behaviour is driven by the availability of a semi-anonymous "disagree" button. There's not really any gray area here.
> Other comments might be wildly off-topic or deeply non-constructive, and those I down-vote. But to each their own.
On a constructive platform, that is a matter for moderation, not opinion. The problem of downvotes is that it combines the two, even though they are fundamentally different concepts.
That idea works in theory, but in practice it makes comments a popularity contest. Eventually, people with minority opinions figure out that their ideas are unpopular and leave or stop commenting. The end result is monoculture. A great illustration of this phenomenon is Reddit's politics subreddit. In theory, it is a place to discuss American politics. In practice, its discussion is almost entirely centered around a single candidate from one party. The downvote button windowed the community and then winnowed it again until a political atom remained.
I don't think HN is monocultural, at least to a pathological extent. There's quite a bit of debate here. The overwhelming majority of grayed out comments are baseless, off-topic, or unnecessarily inflammatory, from my perspective. I think that's because there's a norm to agree with an upvote, disagree with a non-vote, and reserve downvotes for unproductive commentary. People seem to upvote unfairly gray comments regardless of their personal agreement.
If that was the case, then this would be accomplished constructively by people upvoting a strong argument rather than downvoting an argument they have a disagreement with but either a lack of will or ability to articulate the reason they disagree.
I disagree with the last one. As someone who's been involved with quite a few forums and social sites, the down button tends to get abused a lot less than you'd think. Heck, the most popular plugin for XenForo ratings goes further and lets people mark replies as dumb, old or 'drama queen'. Those don't seem to get abused too much either, surprisingly enough.
But I guess it's a size and topic thing. If your site has a mature userbase, a limited topic or is mostly a pretty tight knit community, adding a downvote button tends to be a decent enough thing to do. Same if you have to acquire the privilege to use it.
Popularity and constructivity are two entirely different things. As mentioned by another post, StackExchange introduces a 'counter-weight' - Reddit is widely perceived as "not constructive at all", and is thus not relevant to my argument.
It's not ironic. Votes here are used to push the best content to the top. On Github you're not looking for the best content you're collaboratively building software so the tools should be designed to foster collaboration.
> On Github you're not looking for the best content
That seems like an odd assertion. Are you looking for the worst content then, or...? I can see an argument that voting would not highlight the best content, at least in some cases; I don't understand an argument that we aren't looking for the best content.
Conversely, HNews is intended as a constructive platform. Should the tools we use here not be designed to foster collaboration and constructive debate?
Disclaimer: I'm skeptical of voting both here and on Github. But I feel like the argument that the differences between the platforms are major and fundamental needs a lot more fleshing out.
This comment is now getting downvoted. To be clear, so people stop downvoting this comment, this parent comment was initially downvoted to -1, it obviously isn't anymore.
No they don't, because they're giving an actual argument. They're probably not again disagreement, but against mass disagreement without requiring to substantiate that disagreement.
A missing feature here is sorting issues by public support. An example is FontAwesome, which explicitly asks users to leave a +1 comment on issues they support. You can then get a pretty good idea of the most desired features by sorting the issues by most commented.
Agreed -- this is the first thing I looked for. My guess is that this feature is probably next on their TODO list. There's not much point in sorting by +1s before there are many +1s accumulated, anyways.
Perhaps it follows the Hollywood model. There are lots of features in development, staff-shipped, in discussion, in the backlog, or whatever. Then there is some external stimulus (Facebook launched reactions!) and the feature gets quickly tailored and green-lighted.
So there is a quick reaction, but work on the idea may have been hidden from the public for a long time.
Version 3.4.0 of Octicons [0] came out on January 22, 2016. It added "smiley" icon, which was used in this feature today. That's 8 days after the dear github letter. 7 weeks before today.
That's a bit suspicious, really. A feature like "Reactions to a comment" doesn't take two years to implement, even with all the scaling considerations. And people have been complaining about that for at least two years.
This makes me think Github doesn't get it. Emoji comments are often used because there is no better way to interact with an issue/PR. What we need are better issue management tools. Polls, voting, triage tools, etc. Instead we got an easier way to post emojis. Feels more like a "look we have reactions like slack!!!" gimmick rather than a properly designed response to user requests for features.
I wonder if this is too featureful? What is the difference between +1, heart, and hooray? Having just a +1 and -1 is unambiguous and probably covers the vast amount of use cases? Perhaps not, but I'd be very interested to know the reasoning between being choosing between "unambiguous" and expressive.
Internally at GitHub over the past few weeks I have been using the heart reaction to express appreciation. For example, if someone is very helpful or empathetic I let them know I appreciate it with a heart.
People have been using emoji comments to express not only reactions but also for voting. Even if you were to add voting features (which reaction emojis can be used for) you'd probably still get unbearable amounts of zero-value comments comprising of a single emoji, "+1" or gifs.
This is probably an attempt to break that "user habit" by providing a tempting alternative to the type of person who spams comments in issues.
Additionally, by using emojis for voting maintainers get slightly richer data about how users feel about something. A user story with 1000 thumbsups might fall lower in the backlog than a user story with 1000 hearts.
I think it is definitely the end of +1 era, folks! Thanks Github to listen to the community feature requests. You should allow more icons like Slack is doing currently.
Can you downvote replies in threads that are locked? Can collaborators delete these reactions like we would with comments?
> Have feedback on this post? Let know on Twitter.
Not everyone uses Twitter. It would be awesome to give feedback using the one account I'm guaranteed to have: a GitHub account. Otherwise I have to ask my question on HN...
I think people will still write +1 comments because they won't notice this new feature, at least initially. It'd be nice if Github just converted "+1" comments into reactions.
Awesome move by GitHub. ZenHub[1] will be phasing out our +1 button now that it's no longer needed – feels good to focus. We're excited to use this reactions data as part of our reporting suite, please keep the improvements coming!
My apologies if i missed a comment, but I'm surprised how few people support "giving it a go" and then deciding if it's good or bad.
There's a multitude of user approaches, lots of people very touchy about their way of doing things (some extra so as this relates to their profession)
Whilst not wishing to appear a fanboy, clearly Github have put a decent amount of thought into this, they've got a fairly good track record and they're responsive. If it's poor, they'll reassess it.
Am I missing something or is there still no way to +1 issues? All I see are ways to react to comments. Whenever I feel the urge to "+1" something it's for the issue, not a specific comment. Can someone explain how to add a reaction to an issue?
This is due to inconsistency from Github on the labeling of the issue text. That issue has no comments - the header shows "lostthetrail opened this issue 7 hours ago · 0 comments". The first "comment" you see is meant to be the original issue text, not a comment.
And yet... the header for that text says "lostthetrail commented 7 hours ago". Github repurposed the commenting system to stand in for the issue text itself. Side effect of a lazy implementation.
tldr; The first "comment" isn't a comment. It's the issue itself, and is where you add your reaction for the issue.
Ah yes, following in the steps of Gitlab which has had this for a while, the thumbs up / down and voting types are useful, everything is a distraction IMO
"So go ahead…:+1: or :tada: to your :heart:s content."
Or please don't. Part of the problem with the +1s is that they add noise. How are reactions going to cut down on the noise? Telling people to go ahead a +1 an issue (increase noise) is the opposite of what the "Dear Github" maintainers want.
Many projects do not use +1 or any other voting scheme to illicit priority from the general public. +1 comments and reactions provide little value. I have seen Github issues where people +1 already closed issues because they do not bother reading.
It reduces noise because a reaction is not a reply: it doesn't notify the issue author of a response and takes a lot less space visually, letting discussions about an issue take place without being intermixed with a bunch of :+1:.
Reactions let you know the impact an issue may be having. I suppose it may not be good for every project, but dismissing it as "providing little value" seems a bit too much considering it was among the most often asked features by maintainers...
I like the idea of adding more expressiveness, pictorially capturing sometimes fleeting moments of emotion or accurately representing an emotional state that can occur.
Do they capture the necessary expressiveness for the context? Facebook's reactions cover more emotions, but FB is trying to support reaction to anything that can be posted.
Considering that it's Github, how about things relevant to software engineering, like: agree, disagree, support, insightful, obsolete, misleading. I can't imagine it being helpful to know that someone felt "heart" about an issue comment.
I recently wrote a post about Facebook Reactions and if it would be effective at helping quantify sentiment. (http://minimaxir.com/2016/02/facebook-reactions/) The tl;dr is that I believe that Reactions are redundant outside of positive/negative classification.
GitHub actually has both +1 and -1, which satisfies me. But there's not much productive purpose with a smile/heart/tada other than to be quirky. (The thinking_face is neutral and adds nothing in this aspect)
Yeah, as I asked below: Will this be a meaningful form of communication and is the language (subset of images) sufficient? Can small changes like this perhaps change how PRs, Comments, etc are treated? Will it be productive, a distraction, or a NOOP?
I think GitHub wanted an option to express "I don't understand this," and decided :confused: was a better fit. Which makes sense, because :thinking_face: could mean "I'm considering this" or "Interesting point," which is not, I think, what that option is meant to convey.
I think the point is: Will this be a meaningful form of communication and is the language (subset of images) sufficient? Can small changes like this perhaps change how PRs, Comments, etc are treated? Will it be productive, a distraction, or a NOOP? Would you use this feature or have you used a feature like this?
This is a welcome addition. I've run into bugs in projects before and wanted to "+1" a thread, but it always felt like spamming the maintainers.
It'd be cool if they added a way to search through your list of reactions. This would allow you to effectively comment on an issue in an OS project, while simultaneously bookmarking it, so that you can go back and commit a fix when you have a free moment.
In that scenario, I just subscribe to the issue, so at least I get notified if something changes. But of course there is no way to list the issues you're subscribing to.
First* Slack, then Facebook, and now GitHub. Looks like reactions are replacing (or expanding on..) the unary like/upvote/heart expression for tech products.
*Or at least the first time I've seen them used as an important feature.
Is there a way to sort by "reactions"?
Otherwise I think this feature is useless..
I would have preferred having more detailed issues rather than ugly Emojis.
While I applaud finally adding the vote up (and even vote down) features, this feature look a bit overdesigned.
I don't really get how I should "love" an issue, or "this issue makes me happy".
Or the relevance of a "thinking face".
The ui would be simpler with only 1 or 2 icons.
At least there's no "this issue makes me sad/angry" buttons.
Speaking about new features -- what I'd like to see is the ability to remove items from my public profile / activities list. Often I make mistakes. Often I do stuff I don't want the public to see, and I'd rather not have to email GitHub support asking them to remove them manually all the time.
Well, I think a voting pool is more practical than manually counting upvote/downvote of every comment. I don't know how often the maintainers will come back and see how an issue is going and see which comments are popular. Also, sorting comments is not fun because of duplicated contents.
The great thing about adding emoji Reactions to all our social media posts is that now AIs can finally learn human emotion. I'm sure Google is already training theirs on how different keywords make people feel.
I don't think these necessarily cover all of the responses that can be made, but I think it is a great start to getting simple feedback like this. Like other users mentioned, it would be awesome to be able to sort or perform some kind of action based on the quantify of the reactions.
I wonder if they will allow for repository owners to select which reactions they will allow? I think that would help with the limited selection but still allow owners to select what they consider useful to them.
Interesting cultural bias. Why are people not questioning unsubstantiated up-votes, but feel down-voters shouldn't be let of the hook without a full argumentation?
Upvote is already backed by the arguments the upvoted post contains. Downvote is not backed by those arguments. They are not symmetrical at all and there is no bias.
It'd be nice if they added a little warning whenever submitting a comment that was only a '+1' or '-1' otherwise the discoverability is gonna take a while, maybe? Also a option to convert those comments into reactions for repository owners.
Awesome! Just a niptick, I think the reaction action should be near where the interface is. So either change the icon to make a reaction to bottom left, or change where it's shown to the right (where milestone, tags, etc are).
Looks like hacker news filters out emojis. My thumbs up pun has been ruined.
In all seriousness - thank god. Hopefully it won't take Google Code issue tracker like levels of effort to get people to "please star the issue if it is important to you rather than commenting with +1".
I can just imagine this being abused by less socially aware on the autism spectrum disorder, I definitely think it's wrong and toxic to add mechanisms which support non constructive criticisms or praise that leads to emoticon circle jerks.
