New revision/edit rights model

Background

This discussion page is aimed to replace Deck branching when forking a deck and Realize edit rights discussions. Those discussions, as well as others, have resulted in the current implementation of the revisioning model in SlideWiki. Since the information is a bit scattered, this page will also serve as the description of the current and future development for deck/slide content revisioning and edit rights.

The main decisions that came out of the original discussions are two:

1. When forking a deck, instead of creating a new revision, we now create a copy of the deck that links to the original ( decision was made in Re: Deck branching when forking a deck )
2. When a user wants to contribute to a deck, the way to do so is by joining the editors group of the deck, or forking the deck in order to suggest changes to the editors

There were other decisions involved, however those two were the reason the two tasks had to be handled jointly. The deck revisions were used in order to provide a way for people to contribute, and the result was problematic, hence the discussions and the new revisioning model. In the new revisioning model, a major feature is the Deck change log, without it it wouldn't be complete. Also, with those two decisions, deck revisions became somewhat orphaned, as we no longer needed them either for branching/forking a deck, or for allowing people to contribute to a deck. So the idea was to repurpose the deck revisions model in order to make them actual revisions.

While developing the new edit rights and revisioning models, some issues came up that we had to resolve in a timely manner. Further decisions were made regarding the following:

1. Managing edit rights for decks and subdecks: the decision was to maintain the editors list in the deck at the root of the deck tree, and any subdecks added would be kept in-sync with that root deck. (Re: Realize edit rights)
2. Managing propagation of edit rights due to attaching subdecks from other deck trees: in order to keep the implementation simple, a decision was made in Re: Realize edit rights after a proposal by Abi James. The idea is that if we want to bring an external deck to our deck, we will attach a copy (a fork) of the original deck instead of that deck directly. That way we keep the edit rights separate (as those are implemented on the root deck tree level alone)

Current state of revisioning

With the new implementation, deck revisions became actual revisions of the content, i.e. past states of the deck editing process. So a deck revision should not be considered another version of the deck, rather a point in time when the deck had a specific state. That state includes any information in the deck metadata (title, description, etc), as well as the actual structure of the deck, i.e. its content items. A deck revision is created only by an editor of the deck, and it always is a stable, not changing view of the deck's past. Every deck revision except the latest one are read-only, and no-one, not even the deck owner, can edit them. If we want to revert to a past state, the revisioning system will create a new revision for the deck and fill its metadata and content items with whatever state the deck was at in the revision we revert to. This new revert policy does not apply to slides, as those can be switched to any revision, past or future, in their respective decks.

Conceptually, the idea of alternate versions of the deck is replaced with the deck forks. So if we want to consider a different take on a deck by a user unrelated to the original deck, the deck forks are what we should consider. Deck forking is not strictly part of content revisioning, it is more related to more general ideas about deck relationships. We currently have deck forks (alternate versions?) and we want deck translations in the future. However we need to handle those aspects of the deck service in tandem as the deck service evolves.

One aspect of the new revisioning model relates to nested decks (subdecks). Under the new model, creating a new revision effectively "freezes" the current one by making it read-only, and promotes the new revision as the one that is editable. When a deck has subdecks, we need to recreate a new revision for them as well, even though they might not have any changes at all since the last time we created a revision for them, i.e. their current and previous revisions are identical. The reason we need to do this is because we need the parent deck revision to be read-only. Consider this example: 

1. we create deck 200
2. we add subdeck 201 under it
3. both decks are at revision 1
4. we create a new revision for deck 200, without creating one for deck 201
5. so now, both deck revisions 200-1 and 200-2 point to deck 201-1
6. 200-1 should be read-only, that means that whenever in the future the platform asks for deck 200 at revision 1, it should never change
7. both revisions 200-2 and 201-1 are editable (both are latest), so one is authorized to edit deck tree under 200-2 and a slide under deck 201-1
8. if someone visits deck 200 at revision 1, the subdeck 201 is not the same as it was before step 4, as a slide was just added!

Since we need to provide read-only states for all past deck revisions, including their subdecks, creating a new deck revision must always be performed recursively for all its subdecks.

The same holds for reverting a deck to a previous revision. In the new implementation, a deck revert action is just like a create new deck revision:

• in both cases a new deck revision is created
• when creating a new deck revision, its contents are taken from the current latest revision
• whereas when reverting a deck to an older revision, its contents are taken from that older revision

Because the two processes are almost identical, and for the revert action to be reversible we also need to apply any deck reverts recursively to the subdecks. We have an even stronger need for that, as we can't simply change the subdeck revision a deck points to, as that would again expose an older subdeck revision to the latest revision of the parent deck. Then we would have a conflict since the parent deck would be editable, and the subdeck would be read-only.

Action items

We should complete this action items list with whatever else we might need to change in the platform mainly now that we have quite a different revisioning/forking/edit rights model.

• Define workflow for alerting deck owners of deck forks, suggested changes and edit rights requests
• Identify pages or workflows in the platform that should be brought up-to-date with the new revisioning process
• Define the layout and features of the views where deck owners merge new changes into their deck(s) - merging the deck structure is nice but also merging slide content would be perfect
• Adopt also decisions about licences (deck licence, multimedia files licences) - Perhaps new views are needed