Draft of 003 - Manual People Data Tools

[jamesturk]

This one incorporates various conversations that have happened around this.

@csnardi I'd be particularly interested in if you think what is being outlined here would be something your volunteers could use more easily than the YAML.

@jessemortenson @NewAgeAirbender your thoughts on this would be great too, the people matcher could be part of this too since the same logic would be shared between that and this in terms of applying DB-stored changes to YAML

[jamesturk]

@csnardi one other thing, this doesn't yet deal with municipal data, which I know is a focus of your team as of late. Once we land something here to define the scope of municipal data I'd be glad to amend this with additional features for that, but we'll start with states which hopefully is still beneficial

[jessemortenson]

Definitely more work to create this UI vs alternatives but I think there is strong value in the long term.

One thought: might want to design the ChangeSet stuff so that multiple ChangeSets can be merged into a single PR. If each click of the save button yields a ChangeSet + PR, users would have to choose between saving their work more often (yielding more ChangeSets) and reducing the number of PRs generated. I could see users making a bunch of incremental edits even in a single use session.

I think it makes sense to at least decide on a common set of user-interface primitives to share between this UI and People Matcher UI. Deciding on whether it's React or Templates+jQuery, display tables the same way, etc..

[jamesturk]

agree, good catch.

I was sort of leaving that as an implementation detail for now since there is enough uncertainty here to not be too prescriptive. I think the 3 use cases are often separate enough that as long as the bulk-table-edit option generates one PR it won't be too overwhelming, but I agree that it'd be nice to merge ChangeSets particularly when there's a retire & replace happening, that'd logically be reviewed as one unit.

one idea: perhaps the workflow can include a manual step to submit ChangeSets, so that as a user does edits, their available-to-merge changeset page indicates which are done. the downside to that would be that we could wind up with things stuck in the ChangeSet state if a user forgets to submit as PR, or gets distracted and never comes back.

How would you feel if I added something to the proposal that this is a desired feature, but perhaps not required for v1?

[jamesturk]

And re: the matching tool. Yes, I think this should be compatible with the name-matching work that has a lot of the same needs. The only reason I didn't include that piece here is that I didn't want to necessarily block implementation of it, but on second thought I don't think including it here does that, so I'm going to update with a 4th use case, with the understanding that we might build the prototype of that use case separate from this PR and then bring them together when ready.

[chris-erickson]

This would be really great. We tend to have a lot of people in the middle ground of somewhat technical, vaguely familiar with where all this data comes from etc. We likely could also drive a lot of volunteers to do things like updating social media etc on a much more broad basis if a tool like this existed.

I also agree that building this largely for yourself is smarter than something like an AirTable. We primarily have used AirTables when we need to bridge a complex system/process with a non-technical user but this requires someone highly technical to integrate in the first place. Might as well spend that time making the tool you need/want.

It'll be important that the workflow (eventually) supports making a lot of changes in one go, knowing our volunteers.

Sounds neat!

[jamesturk]

going to merge as draft