Questions we get all the time, "How do suggestions work?", "Why hasn't this been implemented?", "Why are you so bad?". There's a thread, but perhaps it's time to write a post, and keep people updated?
Step 1: Suggestions
The first step is that people post their suggestions, in the suggestions forum. Surprising, I know.
These stick around until:
A. They have been open for about a week. AND
B. They have had like 10 votes.
If they have enough support (50% I think), it gets moved into the "Staff Review" section, if it doesn't, it gets denied.
Step 2: Waiting for Staff Review
Here suggestions sit until staff get around to posting review threads.
From the review manager, we can send polls to development, moderation, administration and business. We need to fill in a quick description for the suggestion, and any development advice we have.
This is also the place where we check for if a suggestion is feasible and possible. If it is, a staff review is posted internally, if not, it's denied.
Step 3: Staff Review
Every votes. And leaves reasons. Except when they don't :<
The default length of these polls are three days, but can be extended.
If it passes, the internal thread is moved for development, and the external thread is moved to "approved. If it doesn't pass, the reasons are posted publicly and the thread is moved to denied. The internal thread is then moved to the archive.
Step 4: Additional Planning
Here, suggestions are mixed with ongoing plans (MESKA, new skills, optimisation etc) to form full plans. This was done by the content team, but is generally handled by development. This can be simply adding suggestions together to make larger updates, or more in-depth planning through working groups.
In this step, new updates may make old suggestions irrelevant, and so suggestions are sometimes denied months after because they're no longer relevant.
Step 5: Development
Then, developers are matched to updates. Some developers work on local servers (such as Burnett). Others work on beta directly (myself). The developers work to build the update, sometimes referring back to update plans or working groups, speaking to the community input, developers or administrators to get input into the new plans.
Now, why does this take so long to do? We don't have many developers, some developers are better at particular things. Some prefer other things. Some are looking to expand skill sets. Some need more support. Overall, we get more suggestions than we can implement, so the backlog increases.
Step 6: Debugging
Debugging takes several phases. Stage 1 is merging everything onto beta. Beta has several differences to live. Seperate databases, often has newer code being tested, but generally if code works on beta, it should work on live.
Stage 2 comes after that, where code is merged live and tested again on the staging server. This is a copy of live, same DB, same code, it even logs to the same files. It's as close as being live as we can get, without rebooting the live server.
Stage 3 is when everything is live. We can't catch everything, so we rely on bug reports from the community, you catch what we miss, and do things we don't think of.
Secret Step 7: Balance
While we strive to keep things as balanced as we can on release, we might get things too good or too bad, so we change values. Contraband gets buffed and nerfed. Timers changed from 5 minutes per cycle to 1 minute and is now on 2 minutes. Wood values have been changed maybe 6 times since they were made sellable. Weapon damage and fire rates are changed to improve the meta and make each weapon viable. This can also be prompted through suggestions. Sometimes data says stuff is balanced, but the community thinks otherwise, so it can be easier to just rebalance stuff than to explain the data.
So hopefully that explains how we do suggestions, why they can take so long and how they're chosen to be worked on.
