Project:Data Dictionary/Proposals

Mod Testing

Form:SystemSpecs
- Template:SystemSpecs
  - cpuspeed | CPUSpeed [Number]
  - cpucore | CPUCore [Number(list)]
  - gpumodel | GPUModel [String[list)]
  - gpuvram | GPUVram [String(list)]
  - multigpu | MultiGPU [Number(list)]
  - ssd | SSD [Boolean]
  - arch | OSArchitecture [Number(list)]
  - dlc | DLC [String(list-multi select)]

Form:ModTest
- Template:ModTest
  - newGame | NewGame [Boolean]
  - loadSave | CanLoadSave [Boolean]
  - loadSaveName | LoadSaveName [String(list)]
  - uninstall | CleanUninstall [Boolean]
  - errors | HasErrors [Boolean]
  - ctd | HasCTD [Boolean]
  - bloat | SaveGameBloat [Boolean]

Form:Performance
- Template:Performance
  - fps | FPSImpact [Number]
  - vram | VRAMImpact [Number]

ModAttributes: Some of the attributes for this template should be associated with the Mod page itself.

Propose that we add to Template:ModTest:

RunningDawnguard (Boolean) - Indicates that the test box is running Dawnguard
RunningHearthfire (Boolean) - Indicates that the test box is running Hearthfire
RunningDragonborn (Boolean) - Indicates that the test box is running Dragonborn

RE Template:ModAttributes:

@s4n, should the internal objects of the Documentation property be converted to property "string" values of that property? Could you re-create that one as you see fit?
Should we add the QualityImpact property to the end of this?

We should rename Template:PerformanceImpact to Template:PerformanceData and use the previous name to hold the performance result (i.e., "impact")

RE Template:SystemSpecs & Template PerformanceData:

How can we set these to evaluate to the SystemType and PerformanceImpact Properties, respectively? These can either evaluate directly in a 1:1 or in aggregate as a query result of the "average" of these respective templates ...

~z929669

Talk 21:00, November 27, 2012 (UTC)

* Yes to the Documentation properties. There should only be three (the ones currently designated as sub properties) all of type boolean.

* Per the talk last night, SystemSpecs will be queried for the user entering PerformanceData and subsequently stored on the report page for that PerformanceData. Beyond this, we'll need a query that can pull results from the PerformanceData entered and process accordingly. Still not sure on how we're going to do that.

Stoppingby4now (talk) 23:42, November 27, 2012 (UTC)

*Agree with adding the Running DLC properties, also, I didn't add QualityImpact to either list as I wasn't sure if we were going to move it at the time. As I said on the forums, where the QualityImpact goes depends on whether we want to empirically collect that info per-tester or if we just want to leave that as one of the attribute items to be fleshed out in discussion.

*What's the difference between PerformanceImpact and PerformanceData, or am I not understanding what you said? Doesn't all that info belong together?

*It seems Semantic Result Forms provides quite a few ways of presenting data usefully, especially the charts and data visualizations sections.

*In response to Stopping's forum post: don't we want PerformanceData and ModTest on the same report, thus the same form?

~Farlo

Talk 06:08, November 28, 2012 (UTC)

* Re: Performance data. No, that should be a separate form. The main ModTest form will be tied to a single page(ticket) that represents the mod being tested. There should then be a link to the form for adding performance data. If you included it in the same form, management could become far too much to manage effectively depending on how often performance data is submitted.

* Added list at the top as a starting point. Collapsed some things, expanded others. Discuss.

* In the list above, collapsed the DLC's to a single property. No need to keep adding these when we can make it multi-select and not have to worry about updating the form/template every time a new DLC comes out.

Stoppingby4now (talk) 06:17, November 28, 2012 (UTC)

* PerformanceImpact = Low, Med, High (or just low/high) and PerformanceData holds specific FPS values. This is just an idea to aggregate results based on pre-defined commonalities or thresholds. Think of it like a frequency histogram (you have to create buckets for small-mid overall n sizes, else you just get a bunch of 1s for each FPS/VRAM combo). Otherwise, this may be accomplished by the query though, so I defer to Stopping on that (thinking about it further, this seems more useful, but I am not sure of the trade offs).

* Agree with the idea of keeping Performance results separate from test results ... same goes for anything we are interested in collecting in aggregate.

* Also agree with the new org above. I suggest that we use consistent field/property names though (unless we use some consistent differentiator (e.g., lower vs upper case).

* I also like the idea of adding some if not all of the mod attributes to the mod pages (in the info box?)

~z929669

Talk 07:17, November 28, 2012 (UTC)

* Alright, I'm a little confused. I thought each user was submitting their test results as far as whether the mod gives them CTDs, has errors, etc. individually but your explanation seems to imply that each mod/version only gets one ticket for this information. If that's the case, how are we going to determine the status of those properties between different machines with different results? If one tester does a test, doesn't get CTDs, and submits the report reflecting that, but then another tester does encounter CTDs, how are we going to handle that? I thought we were collecting this information per user/test and then compiling the results to see if we can find a correlation between certain system specs and certain errors. If we're leaving this kind of analysis/discussion/troubleshooting to a talk page/forum thread then that defeats a lot of the purpose in collecting the information semantically and it's not much better than bickering in the forums until we get enough yays/nays either way.

* I like the changes to SystemSpecs, that should give us a lot more detailed info. I'm just curious, but how would we query based on DLC with the consolidated property; is it as easy as "if this property contains the sub-string "Dawnguard" somewhere in it"?

* At least for the basic/attribute stuff, that'll definitely show up on the mod page, the question is whether we want to display some kind of generalization of the test/performance results as well. If we do, then that involves creating some rough guidelines so those aren't declared entirely subjectively.

~Farlo

Talk 07:38, November 28, 2012 (UTC)