Good questions!
It shouldn’t be this way. I’ve logged a bug for this here: Closed voting threads don't release votes.
Because the votes mean different things.
-
Threads posted in #roadmap:ideas ask the question: “Should this be implemented?”
- Anybody can post these, and they are not guaranteed to be accepted.
-
Threads posted in #roadmap:to-do ask the question: "How should this be prioritized compared to other accepted ideas?
- Posting is restricted here, but if an idea makes it here it means it is accepted.
The votes that exist for the first question do not necessarily answer the second question. For example, you can think that an idea in #roadmap:ideas definitely should be implemented, but also think that it should not be a top priority.
This gives you more control over your influence on the roadmap, instead of just assuming that “if you think it is a good idea, you also think it should be a top priority”, which may not be the case.
If we were to combine the votes, it would actually be more restrictive, as a player might think “I like this idea in #roadmap:ideas but don’t want it to take over other things I think should come first in #roadmap:to-do. I won’t vote for it then.”.
We actually did have this problem when we only had a single ideas forum for all voting, a flaw that players rightly pointed out because they didn’t know if they were voting for acceptance or priority or both. Now it is much more clear.
Split votes = more player control.
The purpose of the vote is to show what ideas players want the most. It did that, so it is not worthless. Your vote there did exactly what it was designed to do.
Remember too, that voting in #roadmap:ideas does not guarantee an idea’s acceptance.
This is a great question!
The tricky thing is that we can do a lot of quick fixes to solve a lot of things in the short term, but quick fixes tend to be not only a waste of time, but also add additional work compared to if we didn’t do them. This is called “technical debt”:
This is why I tend to avoid short term solutions: they make the proper solution take even longer. Plus, short term solutions aren’t necessarily super fast either, and they also come with risk of bugs and yet another change later on to undo them, which itself introduces even more bug risks.
That’s not to say I’ll never do a short term change. I may, but I would need to hear a very compelling reason to, and with the Qez idea, I have yet to hear one. For that idea, we actually have 3 options:
-
Put it back how it was, which means re-adding broken code that will likely introduce bugs.
- This would be a terrible move.
-
Implement a short term fix, which is still a non-trivial amount of work that we will just undo later anyway.
- This is less bad, but still means I’d be doing the same work twice, which is inefficient.
-
Implement a long term fix via race versioning.
- This defers the idea to its technical dependency, which will also solve other problems. This is the most bang for our buck.
This is exactly why we want to avoid short term fixes. It’s an easy way to spend all our time going nowhere. Each short term fix makes additional fixes harder to make, because we have to work around the patchiness, which adds more time.
Short term fixes are deceptively expensive.