Changes specification

Sporiff

As part of the ongoing planning for API v2, I've noticed that we really need to nail down how changes to items in Funkwhale should be handled. After a brief discussion about this in the dev room, I've written up a draft spec for changes that needs some eyes on it.

https://pad.funkwhale.audio/UOAWJ_ysRPqkmax_0Io_Bg

gcrk

I like it!
The only question left for me is if we want to allow reverts of changes or not. If yes, we need some additional mechanics to actually make Changes revertable. However, I am not sure if thats required.

Sporiff

gcrk

The only question left for me is if we want to allow reverts of changes or not. If yes, we need some additional mechanics to actually make Changes revertable. However, I am not sure if thats required.

In my opinion, reverting a change should be treated as another change. We could think of this a bit like git revert commits, where we log all changes in sequence.

User A suggests a change to Album A
Admin A approves the suggestion and the change is applied to Album A
User B takes issue to the change and submits a new change that reverts the change made to Album A
Admin A looks at the change and decides to apply it, thereby returning Album A to the point it was at before

In this workflow, all history is kept in a simple append-only format that can be easily followed, and reasons can be left for each approval.

gcrk

@Sporiff Even if a revert is another change, we still need to store the state before the change in order to properly revert it. This increases the complexity a lot, because we cannot only log when and by whom the current value was set, we also need to snapshot the data in order to revert.

So the question here is if thats worth it, do we really need this feature? People can quite easily submit another change by hand, so we can only log the metadata of the change.

Sporiff

gcrk So the question here is if thats worth it, do we really need this feature? People can quite easily submit another change by hand, so we can only log the metadata of the change.

I think this is the point I was trying to make. As long as the submitting user can see the change they want to revert, they can quite easily submit a new change that undoes it. I don't think having an entire mechanism for rollback is necessary if there's a visible history, personally.

gcrk

Sporiff As long as the submitting user can see the change they want to revert

Depends on how detailed this needs to be. I think its easy to show something like:

@sporiff@tanukitunes.com changed the title of the Album to "New Title"

Its way more complex to show a full diff as we know it from git

Sporiff

gcrk Depends on how detailed this needs to be. I think its easy to show something like:

I would suggest it doesn't need to be much more complex than what you've suggested here. I suspect most people will only be making minor edits, and most users are't familiar with a git-like diff format. Really, they should only see each change in sequence, and even then they should probably only be shown the most recent change in the frontend unless they're a mod/admin.