# RCM wiki draft - benefits of working open

2023-09-11

Contents:
[TOC]

Relevant links:
* [rcm co-working day issue allocating the tasks](https://github.com/alan-turing-institute/open-research-community-management/issues/269)
* [Issue for this content](https://github.com/alan-turing-institute/open-research-community-management/issues/264)

## Summary of motivation
* RCMs are often on the front line of navigating our community members (and teams) concerns about developing and working open. We also are in a position to help our projects design for effective use of the available infrastructure to work "as open as possible, as closed as necessary". In the following we capture some specific instances we have encountered and share the pathways and practices which were developed to navigate the complexity of ==nudging a team tpwards open working==.
* Not clear yet how much of this should go directly into TTW, but perhaps RCM wiki is a place to develop first then generalise.

Other points discussed:

* The technical infrastructure we have available to us makes things complicated - not just a separation of access levels, but also infrastructure.
* Distributed across platforms - what is where?
* When things are necessarily closed, how do we show that the information (e.g. metadata) is there, but that it is not available to everyone?

==Note: who is the audience for this? Feels like I'm capturing thoughts whicih could be useful to help RCMs navigate objections? Should we name "objection handling" explicitly? Doesn't seem like the right tone.==

## Benefits of working open and different ways to achieve this as a TPS RCM using Turing infrastructure

### What is working open?
Working open means giving as much access as possible, to as broad a range of people as possible, as early as possible in your project!

For documentation or process development, this could look like publishing your working drafts in a public github repository, and developing the material in a way that captures the decision making processes made along the way to finalising a draft. The decision makeing could be captured using github issues, which provide a foundation for transparency and accountabiltiy.

==other examples, so it's not all github centric? Or is that a choice which we explicitly want to make to improve the steer to the platform==

==other example in documenting and sharing meeting notes? link to Comms process chapter?==

It is not always appropriate to work/develop openly, for example if ==...==. In these cases you should aim to build in similar mechanisms for accountability and transparency to acheive the benefits below but in the context of your immediate team.

**Remember** community building starts at home! In our role as RCMs, we should be nudging our internal teams and practices and values to be aligned with the practices and values we are aiming to cultivate in our wider communities.

### Why is is valuable as a practice (open by design)
#### Demonstrating our values
Working open in this way signals to others that our project is something they are invited to be part of - we have left an open door and given them the tools to walk through. This is aligned with our [RCM Guiding Principles](https://github.com/alan-turing-institute/open-research-community-management#rcm-teams-guiding-principles) of collaboration (break down silos by enabling knowledg) and communication (Communicate openly about your project, communities the challenges you are seeking to address and solutions that have emerged).

The transparency and accoutability this approach requires in can also be a significant contributor to building trust in the community. By working open you are allowing yourself and your project to be "vulnerable" ==more about why being vulnerable builds trust, "scitifically vulnerable", "credibility"==

#### Scaffolding for documentation

Also helps documentation and tracking

documents the process (with attribution!), to make it easier to repeat or document more fully.

#### Making all labour visible

It is easy for the many steps towards developing an output

### As open as possible, as closed as necessary (case studies)
* Examples of when things should be closed (RCM case studies)
* ==Vicky has criteria==
* ==Erini and Sophia have systems for giving secure access to materials==

*The partnership is starting to build up documentation, which will only increase once the senior research associates and funded projects have been onboarded.*

*Setting up a public GitHub repository for documentation allows us to be transparent on partnership aims and progress, can serve as an entry point for new members and those interested in joining the community and showcases our practises in an open manner which can help others who are setting up partnerships/collaborations of a similar nature*.

*However this needs to be balanced with the need to keep certain aspects of the partnership private, such as decision making and confidential information.*

*The criteria below is working on ‘as open as possible, as closed as necessary’ with ‘public’ as the default option.*

*Private: Google Drive*

* *Criteria for document to remain private:
* Contains confidential info about Roche and/or Turing
* Contains personal info e.g emails so needs to be private for GDPR*

*Examples:
Attendee feedback from SM event
JSC meeting notes*

*Public: Github repo*

*Criteria for document to be made public:
Doesn’t hit any of the private criteria*

*Examples:
Expert Panel Team Charter*

*For discussion?*

*Sprint reports from funded projects- if making public then need to make this clear from the start with the project leads*

* How we can acheive restricted access using Turing infrastructure

### Open Science Implementation Framework for RCM team