Should the release manager be a role that encompasses the whole instance or per release?

[andrewpatto]

The instance will have two types of users - those who are looking for access to data, and those managing the releases..

For the users accessing data - the answer I think is clear that they will only see 'releases' that they are involved with.

For those managing releases - what level of granularity is needed for their permissions?

[andrewpatto]

@MVidgen @sarahcasauria @MatildaAHaas - maybe use this conversation as a test of whether github works for us?

[andrewpatto]

We could easily have the concept that people managing releases are 'associated' with a dataset.. but then get to interesting world where an application/release spans datasets involving different manager (which is not really a path I want to go down)

[MVidgen]

After our meeting, I was also wondering about a scenario where there is a data curator within a team that compiles the release but does not have the authority to approve the release. In this scenario, you would need something similar to read/write/execute options for the users with a group associated with the dataset. The data manager (or possibly other users of equal authority) would need to be able to see the data curator’s work (i.e. release list).

This group permission and oversight is something I would bump up the list of topics for discussion (if it has not been discussed already). People go on holidays or leave jobs, etc. Having a group permission system would help with the continuity of data release. That said, if it is a bridge too far in this first instance, it would be understandable to leave it out.

I think the question regarding the multiple data owners for a single dataset would be easier to justify leaving this feature out. I imagine this gets complicated and prone to bottlenecks when one of the approvers is unreliable or difficult to access.

Is it easier to include these options for both of these scenarios now or could retrofitting later be done?

[andrewpatto]

Thanks for the comments.

Its definitely possible to retrofit - so I'm not worried about getting it 100% right from the start. That said, obviously the more the current state is aligned with where we want to end up the better..

If we think there is a use case for splitting the ability to 'create releases', 'edit releases', 'approve releases' (i.e a curator v manager split) - then that's certainly a model I can start with?

Do you think that a single user might have different levels of curator v manager depending on the release? At the moment - the model is that at the manager/curator end - their permissions are across all releases in the instance. So it would not be possible to have someone be a curator of one release, but a manager of another. (this is just the very early role model so totally up for changing it if we have a use case)

[MVidgen]

Yes, I can see a scenario where a user may have different permissions depending on the dataset. Imagine a central data manager for an Institute. They might have authorisation approval for old datasets where the researcher has moved on, but need PI's approval to release other datasets.

[andrewpatto]

Keep in mind we need to think about Elsa being downstream from an approval process (be it a REMS or Redcap or some sort of email chain). I am envisaging the data admins in Elsa being those empowered/delegated with the power to "make things happen" - but not necessarily to have in any way been the actual decision makers for release..

Is their governance reasons why this might be problematic? Is it easy to handle to governance distinction between those deciding and those in practice empowered to make the data release happen? (the venn diagram between PIs and those will say the right AWS credentials being small)

Or should we be thinking about a model that still might require the 'data owner' to login and be the final button press for the release (is it realistic that this would then happen?)