Allow voting for same issue every n days
Problem to solve
Voting on issues allows to track urgency and desirability of issues. However, the current votes
- don't reflect on the up-to-dateness of the desirability. Old issues might still have a relatively high vote count but the product might have moved in an entirely different direction.
- are close to meaningless in small teams (1-50), because after a while, all issues will have roughly the same vote count but from different users. I don't know the stats but this might also be true for large teams with not much user fluctuation.
- are close to meaningless in an issue tracker with lots of issues: old and forgotten issues will have the same vote count as relatively new issues which are relevant for todays product
- don't allow a user who deals with customers to cast a vote for every outside request for this feature.
Further details
Imagine that the whole team liked an issue and voted it up. Now it stays around for a longer time and nobody cares anymore. It still has (and forever will have) the highest possible vote. This proposal could reduce this problem.
The UX could be similar to this:
Proposal
By resetting the vote lock every n
days (this should be configurable as gitlab-wide variable with the default -1 == no unlock == at most one vote per user and issue), a user can add additional n
days (if they actively click again). This allows to communicate that an issue is still relevant: if it continuously receives votes from the team, it must be more relevant than an issue voted up once and then forever forgotten.
The same mechanism could be used for teams which are driven by customer requests: An account manager should be able to cast multiple votes on the same issue - one vote for every customer request. How the team deals with the multi-voting is entirely up to them. For this, the n
could be set to 0, meaning that the lock is immediately released.
You could even use this for live bug-monitoring: Whenever a team member encounters a specific bug or they are again frustrated because of a missing feature, they directly vote it up again. For such scenarios, n
could be set to e.g. 1 day.
What does success look like, and how can we measure that?
Issues which have been around long time more accurately reflect if they are still desirable or if they are out-of-date