Granular Role System for Citizen Science or working with Student Assistants

[kadewe]

When working on a project with a couple of people, we need to have a granular role system.

Consider this use case:
We are doing a citizen science project.
We are integrating citizens in our research project.
They should be able to access a certain SET of DOCUMENTS and do CODING only.
Therefore they log in and only see the CODING TAB and the ASSIGNED DOCUMENTS in the SET, nothing else.
Or a Student research assistant only gets to see the documents s/he should CODE. Or just see the ANALYSIS TAB to do some analysis but not CODING or PREPARING.

So a PROJECT has MEMBERS which have PROJECT-SPECIFIC-RIGHTS (such as which TAB to see, which SET to work on, which ANALYIS TOOLS to use) and even maybe DOCUMENT-SPECIFIC-RIGHTS.

[kadewe]

and also reviewers should be able to just view the whole project including the project log. I really would like to get a realistic release plan for role management. I would like to write down a list of roles and their rights and then we should discuss, what to implement in what release.

[kadewe]

I mentioned this thread to a colleague and she pointed out (very rightfully), that we need to support ANONYMOUS REVIEW ACCESS for double blind reviews. Therefore, we have to add an option to only show PSEUDONYMS (like in Google docs) instead of real names.

[jankapunkt]

This raises the question in regards to GDPR and personal data in interviews. A reviewer could be considered a "third party" and while we can show pseudonyms and other integrity mechanisms (hashes, sums etc.) we cannot make sure (in an automated way) that the author scrubbed the interviews appropriately.

[alessandrobelli]

There are a lot of variables to define:

1. where is the access? Coding/analytics page?
2. so far there are no notes, what the reviewer should be able to do?
3. should the public access be limited by time or amount of accesses?
4. password protected access?
5. we need to be clear that if the url is public, we are not responsible for the privacy of the shared project.

The public url is rather easy to do, but we need to create barriers

[kadewe]

well, the idea is for a first version, just to be able to enable a reviewer account for each project., which can be shared with a reviewer. this reviewer account has a password and it can only read, not edit - but maybe add notes. this could be used e.g. for friendly reviews.

for double blind peer review the names of the project members need to be Anonymized.

but the data has to be anonymized for review so i agree that this is a 2.x version feature to be discussed further on

[anouarg88]

Hi! 😄 I was just thinking whether I should open a discussion related to this, but I think it fits here more nicely:

I really enjoy working with OpenQDA so far. To me, its advantage lies mainly in the capability to collaborate and share data with colleagues. I feel that being able to allow temporary (password protected) access to documents without registration would be a useful addition.

For example, if I want to share an interview transcript during a presentation, it is kind of inconvenient to ask everyone to sign up and send me their e-mail addresses so I can assign them to the collaboration list for the project. If I could just share a link and a password during the presentation, that would make it much easier. 🌻 So for this particular use-case, I guess the permissions would not be linked to the users, but set up by the project owner while creating a share link.

Another difficulty with the collaborative coding in group sessions right now is that you automatically see everyone else's codes (or maybe I haven't figured out how to set this up right yet?). Instead of everyone working on the same codebook, I think the default option for the presentation/group coding scenario should be for every user to have their own separate codebook and coded document that could be submitted/shared/compared after each person is finished coding. In addition, there does not seem to be a way to limit a codebook to single documents within a project (or alternatively, to re-import an existing team for a new project). Maybe teams should not be linked to single projects? For a "work-group project", where users share different bits of their own data from different contexts, a shared codebook does not necessarily make sense.

These are just some things that came to mind while trying out OpenQDA with some friends and colleagues. Thank you to everyone for putting so much effort into this wonderful project! Have a good week!

[kadewe]

Thanks for the insightful feedback. You are absolutely right, we need to model access rights to cover different usage scenarios.
I like the idea of giving document-based access for the scenario described by you – for auditing reasons and data protection rights it would be still important to have at least some kind of email-confirmation, like providing a link for a document or a project to access, then people can register AND are automatically included in the project. but you are right, allowing total anonymous access to OpenQDA could be also important for citizen science projects, were you give access to a couple of people in a working group while respecting their anonymity.
I guess that we will have to do a systematic analysis of all the scenarios to cover, and then start with the most easy ones.
Also thanks for the insights into using codebooks.
Right now we are working on inter- and intra-rater reliability analysis, as this is most requested and most often used in publications.