User- and project roles

[dirkroorda]

Users of pure3d come in various roles:

• guest: unauthenticated user
• user: authenticated, normal user
• admin: administrative users

All users, except guests, can also have specific roles with respect to a concrete project on Pure3d:

• initiator: user that initiated the project and invites editors and reviewers
• editor: invited user that can contribute to the project
• reviewer: invited user that can review the project before it is published.

Task: provide more details about these roles.

Think of these questions:

• What are suitable names of these roles, do we need more roles?
• Can any user start a project, or do they have to consult an admin first? Or can they start projects freely, but need to consult an admin before publishing?
• Can initiators promote editors to initiators (in case of handing over tasks from one user to another)
• Can an admin kick out a user?

[dirkroorda]

@cpapadopoulos84 and Susan, can we assign this issue to you?

[CPapadopoulos84]

@dirkroorda

We think of the following roles: Super Admin: Some form of sys admin, e.g., the equivalent of Dirk and Vic

Admin: Those in charge of the infrastructure, e.g., myself and Susan

Initiator: We would prefer a nomenclature that is closer to scholarly editing – therefore we propose instead of initiator to use ‘Editor’

Editor: What you describe as an editor, would be a ‘Sub-editor’

Reviewer: We also think that a reviewer role would be useful. But we have the following thoughts: Reviewers will need to get access to the unpublished version. If the system has the capacity to facilitate the review within the system (e.g., commenting next to an annotation, apparatus etc., similar to GDoc/Word comments), then it would be worth making this a distinctive role with distinctive rights. However, given the various constraints most probably this is not something that we want to do.
Given the above, how are reviewers going to review? They could get access to a pushed version to the front-end that they can only access in a secure way (e.g., via password protection since this is not yet published). But the actual review will take place outside the system (e.g. via a form). Even if we don't currently implement a reviewer role it may be worth integrating the role in our planning for future iterations of the project.

There should be some editorial process to start a project. E.g., a short proposal or Intention to Submit etc. This is a way to also prevent people from just opening an account and not doing anything with it. There will be a tutorial about how to do it (eg. video tutorial etc.). Administrators should become aware that there is a new proposal/project intention (e.g. email comes to the admin).

Initiators (Editors) should promote sub-editors to initiators (editor) (in case of handing over tasks from one user to another) Admin: Kicking out a user > yes, this should be possible

[dirkroorda]

Thanks @CPapadopoulos84 . We will adopt the terms for the roles as you have stated them above. We also will make a distinction between how these roles are identified in the software, and how they appear to the user. In software we will use fixed, acronymic terms in lowercase ascii, on the interface we will use your terms. That gives the opportunity to work with translated terms as well.

About reviewing: doing the review within the system might not be worth it, as you say above. I can confirm that from experience (DARIAH contribution tool). It will cause a quite complex layer of software to be added, and probably not a quite satisfactory one.

It is quite easy to give reviewers read-only access to a selected unpublished project. They can be invited in the same way as editors invite subeditors. Without any code overhead. With that in place you facilitate reviewing before publishing. Without that role, you could invite reviewers as sub-editors, but then they have too much power.

The process of starting a project:

You could still give free permission to initiate projects to all authenticated users, and implement measures to weed out inactive projects later on: e.g. projects without activity in 6 months get frozen, and deleted after one year. Maybe it is just me, but as an editor I would like to be able to experiment a bit in private before declaring my intent to create a project.

But suppose you do want to have a say in the starting of a project, then it could go as follows:

An authenticated user is directed to send a request to an admin for starting a new project. The admin rejects or approves. Approving causes a new project to be created with the requesting user in the role of editor.

We could do it like this:

every user can access a form on pure3d to request a project. There will be a few fields to fill in, like motivation, name, or whatever.

admins will have access to a list of project requests and can answer with a button yes or no.

We can have the system send emails when these actions occur. So the admins have two ways of noticing what is going on:(a) go to the pure3d website and look at the request list; (b) read email