There are some crucial issues with the whole voting process atm…
For excample: there is ALOT of players that want the quezian back for SN and alot of people voted for it, and the idea was accepted but seems to have stopped due to lack of votes on the race versions on the roadmap…
I cant even vote for race versions as i dont have votes left… is my vote locked on the quezian idea? and why do i need to vote 2 times for the same thing…
instead we get a galactic congress forum implemented, that 13 ppl voted on the roadmap vs 17 ppl on the quezian idea…but since the race versions only has 3 votes it wont be prioritezed? and the inital 17 votes is completly worthless? Why am i voting?
Alot of ideas are being closed and put into a bigger catogories that need new votes to be prioritzed and we cant vote since we spent our votes on the initial idea…
i just found out i can withdraw my vote from the closed idea and now i am able to vote again on the idea i allready voted for i dont think there are many players who care enough to do that
@chriss I think it also has Todo with the difficulty…some things are easier to do than others…
Also, the road map isn’t a definite thing where Pie will do everything you vote for it’s just a way for him to get feedback to see what the community would like… I forgot where he said something like that but it’s somewhere here in the forums…the good thing though is that he is listening to feedback…
With he example you used, from my personal experience, the races are in need of a over haul…
I believe that those two things go hand in hand when looking at the bigger picture of races and the overhaul that it needs…
well i truly agree with u kingray but as Pie’s time is limited.
Is it fair to give the need for race overhaul the same priority as the quezian race back for SN are these 2 thing completly dependant on eachother?
Would it be possible to do a “quick fix” so quezian was avalible for SN and “appease the masses” than we could use the next 2-3 years looking into race overhaul ?
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.
Pie i understand why you want to avoid short term fixes and imo thats the way it should be. But we are where we are, the game is open and there is bugs and things that can improved everywhere, still we play…
Than when taking into account your time is limited and there is ALOT of big overhaul’s on the to do list and the list is growing… we know alot of these things will take time to complete right? How long it will take is also difficult to say? What is short term? what is long term? Wouldnt some Technical debt be worth it in a time when the game is growing to “buy” some time to give the bigger overhauls the time they deserve to be done right?
That’s why in between larger features like Revamp Attack Formula I also work on fixes for #support:bugs and even smaller features (for example, Limited map) that while not the most voted, are lower effort and faster for bigger impact.
My time is split between the huge overhauls and also keeping the game fresh with smaller changes, exactly like you’re describing.
The Qez thing just happens to be a case where I’ve decided that the technical debt isn’t worth it. For other things, I might decide otherwise.