Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Status
IN PROGRESS
Stakeholders
Abi James Ali Khalili Marios Meimaris Stavros Maroulis Klaas Andries de Graaf 
Outcome
Due date
Owner
Kurt Junghanns 

Background

SWIK-740 (service) and SWIK-741 (frontend) are ticket 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

Current State:

  • A user can create user groups, join, leave and delete them
  • Forking a deck results in a new revision of the deck
  • Any user is able to create a new revision of a deck
  • All Deck contributors are able to update a revision

Target:

  • Give a deck a general access level: public, restricted, private
  • Access level restricted: Users and groups could be choosed, ẃhich then have edit rights for the deck revision
  • All existing decks are public
  • if a deck is private or the user is not part of the restricted set, then the user is not able to edit the deck (or the content)

We should use the current code as orientation but as this is a main feature we should concern the real life scenarios.

Deck definitions:

private deck = a deck that is not listed, branched and only the owner has editing rights. It is proposed that a private deck can be deleted (e.g if an owner abandons a deck half way through creating it).

restricted deck = a deck that is not listed. It may be a branch of a public deck

public deck = as per beta release

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)?
  • No labels