global-karma.md

Changeset is received via osm-metronome -> dynamosm

dynamosm-validation takes the changeset and:

• updates the scoreboards
• cross-updates the scoreboards

Report

{
  "reason": "User account is less than 10 days old",
  // computer-readable id, used for batch changes like if we want to remove a rule
  "reason_id": "qa/NEW_ACCOUNT",
  "karma": -0.1,
  "source": "user/200350",
  "target": "changeset/4242",
  "report_id": "521421"
}

Comment

{
  "reason": "User account is less than 10 days old",
  "reason_id": "human/COMMENT",
  "karma": 0.1,
  "message": "This is a perfectly valid edit",
  "target": "changeset/4242",
  "report_id": "521422"
}

DynamoDB

Changeset table

PRIMARY   | SECONDARY | SECONDARY   |           |       |
changeset | user      | reason_id   | report_id | karma | message 
---------------------------------------------------------------------------------------
4242      | 200350    | qa/NEW_ACCOUNT | 521421    | -0.1  | 
4242      | 200350    | human/COMMENT  | 521422    |    0  | This is a perfectly valid edit

Changeset rollup table

PRIMARY   | SECONDARY | SECONDARY   |
changeset | user      | karma       |
------------------------------------
4242      | 200350    | -0.1        |

Feature table

PRIMARY   | SECONDARY | SECONDARY | SECONDARY      |           |       |
feature   | user      | changeset | reason_id      | report_id | karma |
------------------------------------------------------------------------
324242    | 200350    | 4242      | qa/SELF_INTERSECT | 521425    | -0.4  |

Reason table

PRIMARY        | SECONDARY      |       |         |
reason_id      | target         | karma | success |
---------------------------------------------------
qa/SELF_INTERSECT | feature/324242 | -0.4  | false   |

scratchpad.md

For maximum query flexibility, you can create up to 5 global secondary indexes per table.

changeset (hash)	id (range)	user (GSI hash)	karma	reason	message
4242	changeset:4242	200350	-0.1
4242	feature:34242	200350	-0.4	qa/SELF_INTERSECT
4242	comment:1	200350	-0.1	qa/NEW_ACCOUNT
4242	comment:2	200350	0	human/COMMENT	this is a perfectly valid edit

... more brainstorming ...

In a table like this you can gather all the information about a single changeset with a query on changeset id. You can get features or comments related to a changeset using a query for a changeset id + id STARTSWITH 'feature'. A GSI with hash user and range id would let you look up everything performed by a particular user.

Matthew's working on a DB schema right now.

Some questions that have been coming up:

How do we choose numbers for vibes?: we might accidentally under or over-value a certain kind of checker and create false positives.

Let's make all reporters worth 1 initially. The weights will show themselves and we'll avoid wasting time bikeshedding them.

What if a positive vibe outweighs a valid bad vibe and we miss an important change?

Let's not include any positive reporters on the first pass.