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"
"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.
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.
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 https://jira.atlassian.com/issues/?jql=project%20%3D%20jra%20and%20resolution%20is%20empty%20and%20text%20~%20voting to start with
You cannot vote an issue if its in Resolved or Closed State.
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.
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot