We are extremely excited to introduce a new system for handling DB requests!

From now on, we'd like to ask everyone to post their DB requests in the new public issue tracker. This replaces the old DB request threads.

If you're not familiar with GitHub, don't worry. We've provided guidance that should help you get started, and will continue to update those materials as questions come in.

Why Move to GitHub?

As a rule of thumb, if a team is spending more time wrestling with their systems than working...it's probably time to replace the systems.

The DB threads were especially problematic because they required each request to be manually copied into our internal trackers. This obviously ate up large chunks of time.

Worse, with no way to guide submissions, we found a large number of the requests we were spending so much time to copy, sort, and triage were lacking critical information. In fact, of the 2,500 "open" issues clamoring for attention in our internal tracker, we estimated that less than 1/3 were actionable. And because we were tracking issues off-site, we had no way of following up with clarifying questions -- or even to let reporters know when their requests had been handled.

We wanted to do better.

At first (inspired partly by this post) we considered several forum-based solutions. However, we determined that merely expanding the forums would not address our biggest problems with the legacy system.

GitHub offered an alternative with numerous advantages:

* It was a platform we were already using
* We could easily coordinate across our internal and public trackers (no more manual copying!)
* We could create "issue forms" and templates to guide submissions
* We could use labels and milestones to categorize and prioritize work
* We could automate labelling (and more!) to handle basic sorting, triage, etc.
* Requests were "threaded," letting us communicate directly with reporters per-issue
* People could easily track the status of their requests (or any issue they were interested in)
* Community members could contribute to others' requests with comments, research, etc.

GitHub's focus on open-source development also offered some tantalizing possibilities for community collaboration. For example, the ongoing Review and Editing of Unit Descriptions could be handled as a branch on this (or a separate) repository, allowing users to make additions and edits before submitting a pull request for review by the project managers. But that's getting ahead of things!

In Conclusion

Changing long-running systems -- even flawed ones -- is disruptive and can be controversial. We hope you can see why we feel the advantages we stand to gain outweigh any short-term disruption.

Although we don't see ourselves ever returning to the old method, this replacement should still be considered a beta program. There will inevitably be growing pains. We'd welcome any feedback, and ask for your patience as we make changes accordingly.

We look forward to your contributions on the new tracker!

_____________________________

Ethan "Pygmalion" Hermanson
Database Manager, Command Development Team

Sounds good.

Now the question I'm cringing at asking..

Have you migrated over all the old stuff or should we resubmit?

Thanks!

Mike

Awesome! Great move guys!

Are the suggestions that have been posted up to now would need to be reposted on Github ?


PS: the template feature is so comforting to have.

May I suggest that the "Affected DBID(s)" field's placeholder mention an ID number, such as #1305 ? It may help to remind that platforms have a unique ID besides their name, which could be subjected to modification.

Seems to be logical on all fronts.
Thanks.

Roger that!

Dumb question: This new system is for both new unit requests and corrections to existing units in both the DB3000 and CWDB?

ORIGINAL: CV60
Dumb question: This new system is for both new unit requests and corrections to existing units in both the DB3000 and CWDB?

Yes its for both DBs, and for new additions and updates.

In fact, of the 2,500 "open" issues clamoring for attention in our internal tracker, we estimated that less than 1/3 were actionable.
And because we were tracking issues off-site, we had no way of following up with clarifying questions -- or even to let reporters know when their requests had been handled.

What will be the policy regarding the 2/3 of the 2500 issues that where not actionable?
Will they be put up on the github page with a request for additional info? Or are they lost?

I just looked at the github site, and at present, there are only 18 issues posted..?

Or is the rest coming?

One suggestion on actionable v. non-actionable issues: would it be possible to have a public tracker where the adjudication is made? The reason I suggest this is that a user may make a request for a correction, and submit evidence. If, in the opinion of the database managers, the evidence is insufficient, if that is noted then if more evidence is submitted it may be possible to change the ruling.

ORIGINAL: BDukes

Have you migrated over all the old stuff or should we resubmit?

ORIGINAL: ClaudeJ

Are the suggestions that have been posted up to now would need to be reposted on Github ?

ORIGINAL: Blast33

What will be the policy regarding the 2/3 of the 2500 issues that where not actionable?
Will they be put up on the github page with a request for additional info? Or are they lost?

I just looked at the github site, and at present, there are only 18 issues posted..?

Or is the rest coming?

I knew I was forgetting something in the FAQs...

We're not planning to copy over entries from our old private tracker. However, those issues aren't "lost," per se: we still occasionally drop in on the old tracker, and even if issues are missing information, we'll probably still handle them eventually as part of a national review / platform deep dive.

With that said, you can resubmit if you like, and posting issues to the GitHub definitely makes them much more likely to be handled.

I'd recommend resubmitting if:

* You want to track the status of an old request
* You're concerned that you didn't submit enough information the first time
* You feel your issue was extremely important/relevant and needs to be handled ASAP

ORIGINAL: CV60

One suggestion on actionable v. non-actionable issues: would it be possible to have a public tracker where the adjudication is made? The reason I suggest this is that a user may make a request for a correction, and submit evidence. If, in the opinion of the database managers, the evidence is insufficient, if that is noted then if more evidence is submitted it may be possible to change the ruling.

I really like this idea. That's exactly the process we had in mind for handling incomplete submissions in the new tracker.

As for applying it retroactively to the old system, though...the old tracker is beyond saving at this point. Trust me.

It would be a LOT of work to set it up in a way that facilitated the system you describe, and even if that worked, we'd have to do a ton of retroactive copying, sorting, triage, etc. It would throw a major wrench into development, potentially for months. I think it's better for us just to bite the bullet, have anyone interested in resubmitting their issue do so, and move on with the new system.

ORIGINAL: ClaudeJ

May I suggest that the "Affected DBID(s)" field's placeholder mention an ID number, such as #1305 ? It may help to remind that platforms have a unique ID besides their name, which could be subjected to modification.

Good idea. Just made the change for the Update Request and Bug Report templates.

sounds great
thx for the work
regards GJ

Okay, I've made a re-submission to see how the DB works. Here's a couple of suggestions:
1) Include a specific data entry for the evidence, OR specifically request the evidence behind the request. Right now, when making corrections, there is no specific field for the evidence. Submitters may then begin to get sloppy and not provide the evidence
2) In some cases, I use books for the evidence (Conways, or Jane's for example) For more obscure books which the database managers may not have, I actually scan the page. Is there a way to actually attach files for images/evidence?
3) In some cases, corrections apply to the same unit in both DB3K and CWDB. Include an option to cover both databases, so a user doesn't have to enter the same info 2 times (once for DB3K and once for CWDB)
4) Make a sticky to the GitHub page and a clear description of the sticky on the forum so new users can quickly find where to make submissions

[EDIT]: I see that I made a mistake, in that a bug report is not the same as an Update report. The Bug report does not include a request for evidence, where as an update report does. Possible clarify the wording on this, possibly changing "Update" to "Update/Corrections", so that it is clear that an update includes fixing incorrect information in the database. Also, put the "Bug" report to the bottom of the list, as only a very small percentage of users are actually going to ever make a bug report

Looks and sounds good. Will do when I get the urge to make a DB request.

ORIGINAL: CV60

Okay, I've made a re-submission to see how the DB works. Here's a couple of suggestions:
1) Include a specific data entry for the evidence, OR specifically request the evidence behind the request. Right now, when making corrections, there is no specific field for the evidence. Submitters may then begin to get sloppy and not provide the evidence
2) In some cases, I use books for the evidence (Conways, or Jane's for example) For more obscure books which the database managers may not have, I actually scan the page. Is there a way to actually attach files for images/evidence?
3) In some cases, corrections apply to the same unit in both DB3K and CWDB. Include an option to cover both databases, so a user doesn't have to enter the same info 2 times (once for DB3K and once for CWDB)
4) Make a sticky to the GitHub page and a clear description of the sticky on the forum so new users can quickly find where to make submissions

[EDIT]: I see that I made a mistake, in that a bug report is not the same as an Update report. The Bug report does not include a request for evidence, where as an update report does. Possible clarify the wording on this, possibly changing "Update" to "Update/Corrections", so that it is clear that an update includes fixing incorrect information in the database. Also, put the "Bug" report to the bottom of the list, as only a very small percentage of users are actually going to ever make a bug report

Re:

2. You can attach images, files, etc. to any Markdown text box (including the Sources box) by drag/dropping, selecting, or pasting.

3. Done. Good idea. Also updated the autolabeler to account for this.

4. This post is currently stickied. Once we've tested the new system a little bit more and had a chance to fix any obvious mistakes (like not accounting for requests spanning both CWDB and DB3K) we're going to plaster links to the GitHub on Steam, etc. and potentially even provide a way for players to open it straight from the in-game DB viewer.

Edit/5. Again, excellent ideas. Done. Reordered the template list, renamed the update request, and relegated the bug report to the bottom.

Great work Ethan.

At some point, could you write a little something about which data entry actually have an impact on gameplay and which one is more abstracted/informative ?

That is so, no to waste everybody's time with suggestions such as, for example, aircraft and ship's Category (eg. an AGI set as Surface Combatant, a SAR aircraft set as Area Surveillance), Height or displacement.

Also, what would be the most efficient way for you guys to receive a "thematic" suggestions about a handful of platforms, such a paratrooper loadouts for a dozen of different transport aircraft :
- an issue per platform ?
- an issue with all of them at once ?


PS:
As for importing a pic on Github, it's that easy :

Goodmorning,
I like all the text of others to help me out before I start to mess stuff up.
I hope it is not already in here and I just misread but a small Q before starting:
What if multiple sources give different data? Do I weight to source to the DB and give only one ref or can I give all data with corresponding sources and the DB manager decide the trustworthy of that source.
regards GJ

I'll note that some of these questions would be better asked on the dedicated tracker Discussions page, which while admittedly lonelier than these forums will allow people to see the question/answer in the future even if they're coming from a different source (Steam, in-game, etc.)

ORIGINAL: ClaudeJ

At some point, could you write a little something about which data entry actually have an impact on gameplay and which one is more abstracted/informative ?

That is so, no to waste everybody's time with suggestions such as, for example, aircraft and ship's Category (eg. an AGI set as Surface Combatant, a SAR aircraft set as Area Surveillance), Height or displacement.

Also, what would be the most efficient way for you guys to receive a "thematic" suggestions about a handful of platforms, such a paratrooper loadouts for a dozen of different transport aircraft :
- an issue per platform ?
- an issue with all of them at once ?

For the most part, I've included only data that really affects gameplay on the issue forms. As for the rest, while they certainly vary in the degree to which they matter -- I think most people would probably agree that having the wrong range on a radar is more "impactful" than miscategorizing an aircraft -- they all have a role to play, and we welcome contributions of any kind. You'd certainly not be wasting anybody's time with the example you gave. For example, that misclassification could affect missions with triggers that depend on certain ship types entering an area, etc.

Re: "thematic" suggestions, you have a couple options. In the particular case you mentioned I'd probably just submit a standard loadout request and elaborate on the different variations in the Users and Weapons Carried sections (or the comments). In theory -- for really big thematic requests -- you could use a blank template, but if you can make one of the existing formats work, that'd be best.

ORIGINAL: Parel803

What if multiple sources give different data? Do I weight to source to the DB and give only one ref or can I give all data with corresponding sources and the DB manager decide the trustworthy of that source.

Oho, that's the best part of DB research!

I would make a call based on source trustworthiness, etc. and pick the number you feel is most reliable -- but also indicate that sources disagree and provide an explanation / links to contrasting sources in the comments/sources section. If nothing else, it demonstrates that you're aware of the other numbers and have made a conscious decision not to trust them (which will avoid cases of us thinking "Oh, this newer, etc. source disagrees, he probably just didn't see it...")

Worst case scenario we override your decision, but you'll at least have a chance to make your case.

Thx and understood
regards GJ

For what it's worth, I just received an email confirmation that the info I had posted on the new tracker on Saturday had been changed in the database. That responsiveness is very nice, and is very much appreciated. For the member of the team doing the database: Would you recommend that player resubmit requests that are more than X number of months old in the old system? In other words, how should we handle old requests in the old system that are either unadressed or we are uncertain if they have been addressed?

I've had a good experience with it. Its a good move.

Mike