Background
SWIK-740 (service) and SWIK-741 (frontend) are tickets for the implementation.
While implementing and discussing it, we noticed it is very complex and depends on the deck revision/fork handling.
User group discussion: Groups of Users
Deck branching/forking discussion: Deck branching when forking a deck
In detail it is really complex. With this complexity there were three versions of the deck edit rights.
The first does not fit in the project goals (open course ware) and the second one could not be realized until start of april.
Thus we came up with version 1.1 which is a tradeoff - could be implemented until april but has just the necessary features/options for the users.
Atm version 1.1 is discussed - how and not if.
Version 1:
Having public, restricted and private decks. Each editor of a deck has her/his own revision of the deck. A public deck could be edited by everyone, a restricted deck just by the owner and by authorized users. These restrictions could only be changed by the deck owner.
Here the removal of illegal/corrupt content is not easy and there is much metadata of each deck revision needed to handle edit rights and deletion.
Revisions are created when a public deck is changed by a (could be anyone) user and when a restricted deck is changed by the owner (owner could also save to current revision) of the deck or an authorized user. Its not already defined how a revision of a restricted deck created by an authorized user should be handled when this user updates it (save versus save as new revision). I am not aware of the code which handles the route "/deck/needsNewRevision" - please decide by yourself how to change the code.
Just the owner of a deck is able to change the edit rights. Thus no authorized user is able to do this. Also each revision of a deck have to link to / save the origin edit rights. A change of these rights have to be pass to all revisions. It should be possible to revoke edit rights for a user for all revisions (which are children of the revision where the edit rights were added)
The handling of translation is not decided yet.
Private and restricted decks are not part of search results.
Version 2:
The owner of a deck is the only person who is able to change the deck and other people could provide change requests.
That means that if the non owner changes the deck it is forked. Then specific changes/parts of the deck could be proposed as changes to the owner of the original deck.
Also the forked deck could get change requests from the origin deck or their owners.
For this we need a kind of a merge tool in the frontend (should work with the change log as proposed in Deck branching when forking a deck ).
With this proposal we have also a contributor list because the change log contains the author.
Deleting is no problem here: If there is a reason to delete a deck we could delete the deck without destroying other decks and stuff. If a deck is corrupt/illegal then we delete it and mark all forks of it as possible corrupt/illegal. This is technical possible if each fork contains metadata about the forking history (origin, fork1, fork2, ...) which shouldn't be a problem.
For the trial partners it could be helpful if a deck has a progress attribute with the values draft, open for requests and fine for now plus the deck has the option to be hidden for search results.
Summarized its compliant with the old SlideWiki: a change gives a user three options: perform minor edit, apply for membership and create a new revision/copy.
Version 1.1:
Definition is ongoing - See Kostis comment from the Feb 24, 2017.
Revisioning terminology
We need to have clear and easy to understands terms for users. "Branch" and "fork" are not in common usage within UIs but "version" is. "Revision" has a number of meanings and so is confusing. We need terminology for:
- when there is a minor change to a slide of deck as currently displayed in the history tab.
- when a new "revision" of the deck is created so that the owner changes
Action items
- Who should be able to fork a restricted/private deck?
- Should it be possible to branch(revision) a restricted deck? By Whom?
- Who is allowed to change the edit rights?
- Should this workflow just appear in the frontend or also in the service/API?
- Does edit rights works together with the current forking approach (creating a revision)?