Let people know they can vote on Issues

[matthewfeickert]

Summary

In Awkward, @jpivarski has a note in the docs that

You can vote for issues by adding a "thumbs up" (:+1:) using the "smile/pick your reaction" menu on the top-right of the issue. See the prioritized list of open issues.

where he sorts by

is:issue is:open sort:reactions-+1-desc reactions:>0 

This is really clever and we should let people know they can vote in the same way.

This is the view for pyhf

Documentation Page Link

https://github.com/scikit-hep/awkward-1.0/tree/d977b04facb196a4c8584f256b36280a4e105b14#getting-help

Code of Conduct

• [X] I agree to follow the Code of Conduct

[jpivarski]

Just to let you know, this method of issue-voting hasn't been very fruitful in the past year since I first proposed it. Only a handful of issues have any thumbs-up, and the maximum number is 2. These might be independent of any explicit intention to vote.

[matthewfeickert]

Just to let you know, this method of issue-voting hasn't been very fruitful ... These might be independent of any explicit intention to vote.

Thanks for the info @jpivarski. That's good to know. Maybe if we regularly push this idea to our users it might be more useful(?).

[jpivarski]

I think the thing that would be needed is for GitHub to make issue voting a "first class citizen" in the sense of adding an explicit up/down arrow, as they do for Discussion questions. I think that could break through a psychological barrier. (Necessary but maybe not sufficient: people don't up/down-vote Discussion questions much, either, or mark them as answered, as they're encouraged to do so on StackOverflow. For the most part, GitHub Discussions are linear comments.)

Also, maybe there's just not many people looking at the Issues that are not their own. The Issue board is something you and I look at a lot, but presumably users are only interested in the thing that breaks their own workflow, not the state of the project in general. (I'm not saying that's bad—people are busy...)

[matthewfeickert]

Also, maybe there's just not many people looking at the Issues that are not their own. The Issue board is something you and I look at a lot, but presumably users are only interested in the thing that breaks their own workflow, not the state of the project in general. (I'm not saying that's bad—people are busy...)

That's true. I'm not really expecting anyone to just be reading the Issues regularly, but more just that if people come to the Issues to open one up and then see that there's one that already exists they might be more inclined to :+1: to vote rather then just leaving with no further action.

[alexander-held]

I think this idea is great in theory, and in practice would work best with a gigantic user base where the counts are not mostly going to be driven by some person telling their analysis team to all click +1, and the biggest team (or number of people with GitHub accounts) ends up at the top. As long as the number of reactions are generally low, the question is also what the person opening the issue should do: should they +1 their own issue? It feels a bit weird, but if this ordering is considered for prioritizing work, it would certainly boost visibility.

Is there a way to sort issues by recent activity (recent comments, or ideally even recently cross-links)? That could be another useful way to identify things that people keep running into, or that limit related progress.