Community data correction process

[maxachis]

Context

• Related to "report an issue with this source" feature data-sources-app#714

Matt from OpenPoliceData suggested that we may want a form for indicating when URLs and data are incorrect and need changing. This would require two components:

• An endpoint where users can submit information on incorrect URLs or Agencies.
• A frontend component that would allow users to send information to this endpoint.

The worse, current version is that people can comment in discord or make a github issue or send an email about incorrect data and someone with sufficient permissions uses the API or retool interface to make changes to the database. This works for now because it's rare.

The better, long-term version is a fully-formed process by which we can do community-managed branch-and-merge type changes to the database

[maxachis]

@josh-chamberlain Alternatively, we can just a form that leads to an email being sent to a PDAP account -- how do we want to approach this?

[josh-chamberlain]

@maxachis I think we should consider handling this with labeling, and develop some basic logic which causes something like a "change suggestion" to be a type of label which can be accepted. On the front end, you'd be labeling / approving only the relevant metadata in a low-number-of-clicks type workflow minimally different from the current one.

If we got an email, that would mean someone from PDAP would need to use the API or retool interface to edit the data source's metadata—not the most sustainable, relies upon split permission structure at a time when we would like to do community managed data.

Your thoughts?

[maxachis]

@josh-chamberlain So if I'm understanding this correctly, a few questions:

1. Where would a change suggestion exist? Would it appear on the data source's page?
2. Can anonymous users make these suggestions?
3. You say minimally different from the current workflow. One idea would be that we present the annotation view, but with the current options filled in, and the user simply has to indicate where their corrections differ from the current annotation.
4. If we want this to also be mostly automated, we'd need to figure out when we'd consider a data source to have enough change suggestions to warrant it -- but then what about the possibility of a "silent majority" which thinks it's fine? How do we handle that?

[josh-chamberlain]

1. Where would a change suggestion exist? Would it appear on the data source's page?

Yes, data source detail would be a good vector for creating these suggestions.

2. Can anonymous users make these suggestions?

I think not.

3. You say minimally different from the current workflow. One idea would be that we present the annotation view, but with the current options filled in, and the user simply has to indicate where their corrections differ from the current annotation.

For approval, yes—we'd present the annotation view, with only the newly suggested annotation filled in. I was thinking the source manager's labeling workflow would be close to what we need on the back end as well, with a bit more logic. However, one wrinkle is that data source detail has more metadata than what we currently label; we might need an "extended optional metadata" panel. Sounds like a bit of a headache. Something to work out later...I would really not like to reinvent the "metadata change suggestion and approval" wheel, and think it would be easier to sync changes back and forth with dolthub using the API than figure it out ourselves.

4. If we want this to also be mostly automated, we'd need to figure out when we'd consider a data source to have enough change suggestions to warrant it -- but then what about the possibility of a "silent majority" which thinks it's fine? How do we handle that?

Changes like this would go into a queue. There would be a labeling option for "I think this is fine / reject changes". Probably there would be petty wikipedia-like squabbles.