From: Melbourne, Australia
Hi. I'm the developer who's responsible for DB3k updates. Paul (Sirius) looks after the CWDB.
Great questions, I'll answer them individually.
1. What is the best format for requesting changes? Is there a certain format that is preferred?
2. What is the best format for making new unit requests? Is there a certain format that is preferred?
No particular format for either. What is important is that you're specific about what you want changed (or added) and why. Put as much detail in your request as possible, and format it so it's easy to read. It's easier for me if you have a post for each platform that needs changing or adding, rather than combining them into a wall of text in a single post covering 50 platforms with 100 changes.
References are also important. And I need to be able to verify them. If it's a book a scan of the page you're referring to along with a bibliography/citation would be best. Web sources need to be credible. Photos are great, but only if they're able to clearly portray what you want.
3. What information do you guys require for new unit requests? Just the name? The "visible" parameters that can be seen in the database? Or more? Also, what information do you guys "want" for new unit requests (ideally)?
An ideal unit request has all the data that I need to add it, without having to do heaps of independent research, and is easily verifiable. A great place to start would be to cover all the points in the DB Viewer. There is other stuff that needs to be taken into consideration but generally if I have a lot of the points covered in the DB Viewer I can manage the rest on my own.
4. There are certain cases where some units have to be "changed fundamentally". For example, the Tu-95M apparently is a conventional bomber, while the Tu-95MA is the nuclear capable basic production version. So should I request for the Tu-95M to have all nuclear weapons be removed and request a new unit called the Tu-95MA? Or should I request for the Tu-95M to be renamed Tu-95MA, and request a new unit called the Tu-95M that does not have nuclear weapons.
With this particular example it's probably enough to explain what the problem is and I'll decide how to approach it. It's a human looking at these issues, not an algorithm, so if you run up against something you're not sure about we can work together to get the solution.
5. What is your stance on hypothetical loadouts? For example, the Tu-95M in the game currently has access to the Tsar Bomba. This would have been a pretty impractical weapon. Even for large population centers like London and Paris it would still be overkill. It was, however, briefly under consideration for small scale production (it would have not been usable against the US, but would technically work in Europe). Therefore it could be included as a "hypothetical loadout". Is the unit marked as hypothetical as well? Regardless, if I am to request a hypothetical loadout, which is exclusively hypothetical (the unit itself that carries it is not changed in any way) do I request a new unit or do I just request it as a new loadout for the "regular" unit?
Loadouts can be marked as hypothetical without affecting the associated unit. Just request it as a new loadout for the existing unit.
On hypothetical in general; it is a fine balance between adding cool hypotheticals and adding real platforms and loadouts. Rule of cool definitely appliies, but when it comes down to it hypotheticals will always take a back seat to real life additions.
6. What is your stance on the naming conventions of certain units and weapons? For example, the Tsar Bomba is currently named "AN.206 Nuclear Bomb [Tsar Bomba]". I think this should be changed to "RDS-220 50mt Nuclear Bomb [Tsar Bomba]" or something similar to that, as the "RDS" designation is more well known for Soviet nuclear bombs in general. Also, the yield would be nice to see when selecting the loadout as opposed to having to separately open the database. Is a request like this reasonable?
The database currently has over 68,000 individual records and there have been multiple people who've had input to it over its 20+ year lifespan. There's bound to be some variation in naming conventions, and while in a perfect world it'd all be uniform, in this world renaming takes quite a low priority so long as things are not wildly different and they are easily distinguishable.
If you are going to ask for bulk renaming, present it in the following format:
Record Type; DBID; Name; Year In Service; Year out of Service; Country; Service; Comments
Aircraft; 999; Example Aircraft; 1985; 0; Armenia; Air Force; 14x, low availability rates
Note that for years in and out of service '0' indicates ongoing or unknown.
7. What is your stance on removing loadouts? For example, the 350kt bomb the Tu-4A has is completely unhistorical and thus it should be removed and replaced with the correct loadouts. This could mess up existing scenarios as far as I know however. Is this type of request acceptable?
Removing stuff is tricky. Best to explain what you want and why, I'll work out how to implement it without breaking stuff.
8. How many requests do you "accept"? That is, for example, there a number of interesting Tu-16 variants, that saw service in some capacity, and thus in order to make a fully accurate order of battle for a certain scenario, they could be included. However, realistically, it is unlikely people will make such a scenario immediately, and, even though they did see service, it was in much more limited numbers compared to the "premier" Tu-16 variants. So should these be requested later when I do make the scenario? Or should I make one set of requests that are more "priority", fixes to existing Tu-16s in the game and missing major Tu-16 variants, and then make a set of requests that are more "low priority", things like Tu-16 variants that were produced in smaller numbers but are the nonetheless interesting and could be important to scenarios.
On average there are 10 posts per week on the DB3k request thread, and most of them are multi-headed requests in that they are asking for multiple changes. DB updates can take upwards of 8 hours each of dev time accounting for verifying, data input, validation, and testing; not to mention some of the admin tasks like logging in our issue tracker and creating changelogs etc.
Since this is a Sisyphean task we have to prioritise. Unfortunately it's not possible to give strict priorities because there's a lot of 'gestalt' in determining priority of requests. In general however, the priorities are along the lines of:
1. Game breakers; problems with existing platforms that make them not work at all in their current state
2. New and notable platforms
3. Corrections to existing platforms that don't cause game breaking problems
4. Scenario designer requests for platforms for particular scenarios
5. The rest
Even with that short description there is quite a bit of variability; with the qualification that 1 will always be first priority, the rest can sometimes shuffle around depending on circumstance. Hopefully it gives you an idea of priorities though.
9. What is your stance on hypothetical requests? Are there limits to what you accept? For example, there was a seriously designed Tu-4 interceptor variant. Tests with the missiles were even conducted before it was cancelled. Would something like this be acceptable (it would be interesting to see it in action)? Also, would hypothetical units be requested as part of a "low priority" series of requests? Or do you only accept hypothetical requests on a "case by case" (that is, when people need them for scenarios) basis as opposed to having them all requested simply because they could have existed?
If it 'adds something' to the game then it's likely to be added. If it's just hypothetical for the sake of it then it's going to be at the bottom of the pile. The problem with hypotheticals is that they're endless; we could add Spitfires armed with Harpoons to the DB but does it actually make the DB more useful or interesting to have that?
This obviously is subjective but while there is no limit to hypothetical platforms, real ones will always take priority.
10. What is your stance on renaming hypothetical units? For example, the anti-submarine warfare variant of the Tu-91 carrier based strike aircraft in the game is called "Tu-91, Anti-Submarine Warfare" or something similar. However, had the Tu-91 ASW variant been built, it may have been designated "Tu-91PLO". PLO was the suffix often applied to ASW variants of aircraft that were not purpose built for ASW work. Would this sort of request be acceptable, despite not being technically historical?
This is low priority, but if it's quick and easy to do I may just do it to get it off the list.
On the other hand who can say for sure what a hypothetical unit ahould be called, and is the change an improvement or just a subjective whim?
I know this is alot of questions but it would be nice to have this cleared up, in order to avoid causing problems for the database managers. Also, I would like to make efficient requests, not providing too much info, not providing too little, and not making requests that will be automatically rejected anyways, and also, making requests that are as easy to understand as possible, not making them in a messy manner.
More info is always better than less, however an unformatted wall of information just makes it harder to pick out what's important. As mentioned above, a bullet list of data points from the DB viewer would be the best place to start.
All requests are added to the issue tracker and will in theory be looked at; the closest thing to an 'automatic rejection' is a request that is unclear or unreferenced, or worse, delivered in an abusive manner. Thankfully these are not common.
I suppose a good analogy is visiting the hospital. If you show up to the emergency department with a severed arm, you are going to get seen right away. However if you come in with a cold, you will eventually get seen but the more people that come in with severe injuries and illnesses while you're waiting, the longer you will wait. In the C:MANO context if you report a game breaker we'd aim to have that fixed ASAP, however if you want an esoteric platform added that is not likely to see widespread use then expect to see other more useful changes happen first.