#586 Vote on issue
Opened 3 years ago by pingou. Modified a year ago

As per https://github.com/dear-github/dear-github issues might be spammed with +1/-1 (apparently more often +1), so having a proper vote system and filtering on issues might be an idea.


We can adopt something like gitlab has buttons to upvote or downvote issues!

Idea: what if we made a third-party app that aggregated issues from pagure, github, bugzilla, trac, etc.. (like bugwarrior does) and then provided a voting interface on top of all of those.

Then, we could prioritize work based on popularity of the ticket -- independent of whether it is a packaging task or a development task.

Make sense, that will solve a lot of problems.

I am leaning towards just having the ability to have a +1 to issues (not allowing the -1)

If someone has an issue with an issue, just allowing them to -1 it doenst really help, they really need to explain. :)

Issue #1713 was marked as a dupe of this one. Copying my summary there:

In the general case, it would be useful for people to be able to indicate tickets that affect them and that they would want looked at sooner.

Also in special cases like the FESCo ticket tracker, it would be handy if we could vote on Change Proposals in an easily trackable way rather than leaving a comment like "+1".

I am leaning towards just having the ability to have a +1 to issues (not allowing the -1)
If someone has an issue with an issue, just allowing them to -1 it doenst really help, they really need to explain. :)

Well, the secondary FESCo use I just described would require the -1. Basically, when tickets are procedural, a -1 would indicate that the person is opposed to the described action.

Ideally, we'd also be able to set certain tickets (or entire repositories) as being votable only by the group owners of those tickets.

I hate to necro this, but the packaging committee would also really love to have some in-ticket voting system. (We'd need the ability to -1 as well.) I'm sure it could be done via some bot that watches comments, but full integration would also be nice if possible. Given the age of this ticket, though, I'm not sure that's in the cards.

So who wants to work on a voting bot with me?

@tibbs I'm worried that a bot that tries to parse the comment field would be subject to a lot of ambiguity. But I agree that it would be really helpful feature to have. I see it as being more valuable to groups that use tickets as a voting mechanism (e.g. Council, FESCo) than as a way prioritize work on an issue.

Right, direct built-in functionality would certainly be less subject to ambiguity, but far, far less expedient unless a Pagure developer is willing to have a crack at it. You do see plenty of people layering various bots on top of github, for example, but then they have zero chance to actually add anything directly to github.

I'd have a look at doing it within pagure as I have basic familiarity with the code and a little experience working on that kind of thing, but I would really have to have an outline from a developer as to the preferred way to implement something like this. Otherwise it could be a lot of work wasted doing something which wouldn't be accepted.

The pagure version in git has "reactions" (see ticket #812 and PR #3246 ), maybe we could build on the top of it?

Login to comment on this ticket.

Metadata