It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Why cant I vote on an issue I reported?

This question is in reference to Atlassian Documentation: Watching and Voting on an Issue

Ask your question here...

5 answers

Well I guess its just have to do with basic sense of things.

Obviously you do think the issue is important so that's why you asked about it, if other people think it's important, similarly they can vote on it.

If you'd be allowed to vote on your issues, it'd be like "self liking your pictures on facebook"

If we could +1 individual lines, I'd hit that for "like self liking your own pictures on facebook"

That's exactly it, I had this conversation a few times in the past, and it really is "if you reported it then we can assume that you want something done, and have hence voted for it"

some people use the Vote for other things and report (we can use it in JQL) ... and strange you cannot vote for your issue, why such limitation ? 

Again - if you reported it then we can assume that you want something done, and have hence voted for it

"you do think the issue is important so that's why you asked about it" => not for me or for my colleagues. Sometimes you raise an issue because you've found a bug, but it's not something really blocking or very important. But sometimes you raise issues that are important for your work, and it would really be nice to be able to vote for it, in order to indicate that yes, it's important for you.

Like curtJepp likes this

I agree with @Pierre-Emmanuel Larrouturou. Sometimes I raise issues that came about in a meeting, but for which I'm not interested in voting. My implicit vote should not be counted.

Or as Pierre says, sometimes a bug is spotted that doesn't really affect what I'm working on, but nonetheless want it captured so it can be tackled/voted on as needed. Again, my vote should not be implicit

But that would be dual voting.  You've already raised it, and that's your vote.

To make multiple votes actually useful, you'd need a different voting system.  Pool votes for example - across the system, you'd get 20 votes.  When you've voted 20 times, you can't any more, until an issue you have voted on is closed, then you get those votes back. 

Note - I'm not saying the vote system should not change, I think it's weak, just that the simple current system, voting for your own stuff is unfair and pretty pointless.

The problem with an implied vote is that the reporter cannot refute the implication.

This is the same result if you would add an actual vote to every issue from the reporter that could not be removed.  It's no longer implied, it's real, but it's still meaningless because every single issue will have one of these reporter votes.

My opinion is that there is no value to a piece of data that is the same on every single issue.


The way we use voting is to help prioritize a large list of tickets by a select group of users.

These tickets have a variety of reporters, some of whom are in the voting group, and some who are not.  Let's assume there are 5 people in the voting group.

On a ticket reported by someone in the reporting group, the max number of votes you can have is 4, because the reporter cannot vote.  

On a ticket that is reported by someone not in the voting group, the max vote is 5.

Now how do I write a query to find me the top voted items?  Is it 4 votes at the top, or 5?  If it's 4, then I need to check if the reporter is in the voting group and then consider it a 5.  Not practical at all.

Like # people like this

I know that, but as I said, the voting system is very simplistic.  It assumes an implied vote, which is fairer than voting twice in this system. 

But, your reports work fine within that system - when something has 5 votes, it's got 5 on top of the implied one.

But it's not a good voting system.

There is no voting twice, that's the whole point.  You can't count the implied vote.  There are a million reasons to create tickets, and the fact that a ticket exists doesn't imply that the reporter wants it done.  At least not for all organizations.

The user should be able to choose whether or not the reporter can vote or not.  If you choose to treat the fact that an issue was reported as an implied vote, then it's simply a matter of process, just tell your reporters not to vote.

It is indeed a very simple system, which is why I don't understand why there is this arbitrary rule that limits the reporter from voting.

JIRA is exceptional at staying out of your way, if you want to organize things by component / label / project / issue type / sprint / status / priority or any combination of those things, you can.  And you can adjust your boards accordingly to accommodate your organizational flavour of the day.  It's a very complex system that is handled extremely well by putting the power into the hands of the user.

The contrast with the voting system is surprising, as it is literally a binary operation, you've voted or you haven't, and that's where Atlassian has decided to put in a rule that limits / dictates your workflow.

Removing the limitation won't hurt anybody's workflow, instead it will allow each organization to determine what works best for them, like in the rest of JIRA.

I think you are completely missing my point.

An implied vote is the best option given a flat single vote system like this.  I raised it, therefore I wanted it.  Why should I then have to vote on it?

Neither implied or explicit voting works for everyone, definitely.

But there's no point in talking about it. 

They've got a stack of issues raised about improved voting systems.  If they do chose to do something about the voting system, it won't be a minor tweak like this that makes it harder for the majority to understand (people understand "I raised it, that's my vote"), it will be a proper re-write.

I understand your point, I just have a different opinion, just like the others in this thread who would prefer to see that limitation disappear.
And we all know what they say about opinions, they're like belly-buttons, everyone has one. =)

Where would I find that stack of issues about improved voting systems?  I'm interested to see what suggestions are in play.

I don't think our opinions differ that much.  Only really that "implied voting" is what most people expect from a flat voting system like the one that's there.  I think we both totally agree this system is inflexible and not really that useful!

Have a look through to start with

like "self liking your pictures on facebook"

Actually, this works against restricting the reporter from voting on an issue because JIRA is making me like my pictures. I can't not be counted as a voter for the issue.

I agree with the others. When I log an issue, while it's possible I would vote for the issue, it's not a given.

I should be allowed to like my favourite pictures, not have to like them all.

I don't think you have understood the analogy.

People who (genuinely) like their own pictures on Facebook are seen as "losers".  We already know you like it, because you posted it. 

Ask your kids what they think of self-liking (but bear in mind, you are going to be laughed at)

I don't think Jira should make assumptions on functionality. They should listen to the users.  They have taken a slick capability and limited it based on an assumption that if you report it then you obviously like the idea. Not true! Perhaps you imported a bunch of nonsense for other folks and would like to be part of the voting exercise. Well YOU CAN'T be because Jira made an assumption that you love everything you enter.  For example, our leaders gathered in Atlanta and came away with a lot of items they would like to either start or stop doing.  I imported all of the information and now we want to vote to prioritize the list. Guess who doesn't get to vote... this girl!  Hum... 

Agree. Voting is useless to us as way to triage backlog because of this. Provide per-project option to allow. Simple. Make people happy. Move on.

You cannot vote an issue if its in Resolved or Closed State.

  • Please check if you see Add vote under More Dropdown as shown below

image2016-3-29 18:5:37.png


  • Also, To manage Voters, you need to have that configured on Permission scheme to manage Voters list



0 votes
Steven Behnke Community Leader Mar 29, 2016

JIRA started life as a public-facing Bug tracker, bug reports imply one vote. Additional votes allowed for further weighting. 

Watchers is a really simple field in reality – It is a multi-user select field at heart. The view on the issue is the quantity of voters + a vote button not protected by edit permissions. It's view in the navigator is the count only.

Tl;dr That's just the way that JIRA works.

Atlassian is becoming more and more slower and too big to be able to stay agile like they used to... sad isn’ It?

we have been waiting for this since many years now.

may be good to start looking for another tool ?

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted in Jira

Demo Den Ep. 7: New Jira Cloud Reports

Learn how to use two new reports for next-gen projects in Jira Cloud:  Cumulative flow diagram and Sprint burndown chart. Ivan Teong, Product Manager, Jira Software, demos the Cumulative ...

303 views 1 3
Join discussion

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you