Achievements Dev DataTables

From AniDB
Revision as of 06:39, 13 February 2015 by Ommina (talk | contribs) (Created page with "[WIP] ===The Situation=== Badges (achievements) are fun, popular, and motivating. However, to date, there has been considerable resistance to adding badges to the bulk of t...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

[WIP]

The Situation

Badges (achievements) are fun, popular, and motivating. However, to date, there has been considerable resistance to adding badges to the bulk of the 'data entry' tables, out of fear that it would lead to an excessive number of poor (incomplete, or outright fictitious) records. This is a shame, as the motivating power of the badge could also be used to encourage additional inserts by users who would otherwise not bother.

The Proposal

In order to address the concerns over 'poor data', I propose to take a different approach to assigning data-entry based tags. In this revised system, instead of using a raw count of inserts, a subset of fields for the table would be required. In addition, the code would consider not only the base insert, but subsequent change requests created against it. For example, it might be determined that all characters should have a picture and a name. Thus, at runtime, only characters that have both (or, possibly, some percentage of) fields filled in would count as credit toward a badge.

The Problems

This comes with its own set of problems.

  • In order for ample time to be pass for a base record to be corrected (if necessary), considerable lag would be necessary between the record (character, for example) being created, and credit toward the badge being assigned. This time is likely to be counted in weeks. Such lag is almost certain to work against the motivating value of the badge itself.
  • As follow-up creqs would be considered, it becomes quite likely that multiple users would be involved. The decision then must be made which (if any) of the users gets credit for the entry.
    • Further, the type of creq is also a factor. While adding is easy, a change of data is not. If User-A adds a character with (perfectly acceptable) picture-1, and User-B changes the picture to (also acceptable, but better) picture-2, this should not invalidate the work of User-A. Nor can this be automatically determined: from the perspective of Badgers, both bits of data are equally good. The question then, again, becomes a question of who gets credit.

Depending how strict we want to be, the third problem may well kill the idea outright. That's fine too.

Closing note: The proposal is a work in progress, not a promise to implement. As such, I'm keeping discussion to a limited audience for now. Which is to say, I'm not posting it on the forum.

Discuss.

Yours in Chocolate Bunnies,

--ommina (talk) 07:39, 13 February 2015 (CET)