Create working groups governance doc

[harisood]

Summary

Create working groups governance doc

Detail

Create doc that outlines/summarises how working groups work. This can be modelled off RDA and other groups. It should include:

• Our definition of what a working group is
• Working group expectations
• What is required to form a working group
• How long working groups last for
• How to integrate outputs/updates back into the community

What else?
Additional documents that are needed to complete this document

Tasks that need doing before this is merged:

• Link to a document on the Steering Group
• Link to a document on the Newcastle Commitment
• Create an issue template for charter review on this repo
• Create a diagram summarising this process
• Create a working groups closure form

Who can help

No response

[rmbaxter67]

Would encourage us very strongly to align with the DARE UK processes. These are modelled on the RDA too.

[Davsarper]

This should include what we are discussion on 5 dec meeting, where does someone with an idea for a WG (with the duration, resources, cost, priority figured out) go? Write to CMWG, open an issues in the board (under ideas)...?

[Davsarper]

9 Jan

How do we work with WGs? What does the Community endorses and what not? How do we balance initiative and helping things being done with community oversight?

• Some open community review on any work is crucial, discussion needs to happen (or be available for discussion at least)
• DARE UK has some templates available, but to what extent does the UK TRE Community want to OK or not OK content?
  • We are finding out this balance, but on matters where members do feel strongly we do need to decide as a community
  • What is endorsement and what is just community review
• Next step here might be to propose a gov model, and see from there. If we just say come and do some work we risk the community being led exclusively by those with more time/resources. A very informal process has that risk
• There will be points where members come from different perspectives and disagree. How can this community ensure a healthy and productive discussion?
  • How can we also more collaboratively put together WGs, their titles, content. In general more collaboratively defined
  • An example from Jupyter Initial Documentation working group charter jupyter/governance#198
• In the interest of fairness we do need a process for setting up WGs
• Newsletter and better comms will also improve collaboration and making people aware of what is going on and being discussed
• Two different kinds of endorsement
  • Setting up WGs: mostly check relevance, does it fit with our remit? does it overlaps with soemthing already happening? Other than this, let people do the work
  • The outputs of a WGs: is it appropiatte? does it contravene any principles?

Summary:

• Allowing people to do this collaborative work is what we are here for,
• but they need to be framed more as a question to be explored than starting from a set position (so the community can discuss),
• CMWG role is to make sure the discussion is properly communicated to give the opportunty to participate
• As much about transparency as about a process: even without time to participate the creation of a WG should include community review, discussions and outputs from WGs should also be available for review even without the time to fully engage (?)

[harisood]

• There can be a difference between a) having a place for resources to live and b) the UK TRE Community explicitly endorsing specific resources.
• We are signposting to work going on in the space, we can figure out what it means for us as a community to specifically endorse things

[JimMadge]

• There can be a difference between a) having a place for resources to live and b) the UK TRE Community explicitly endorsing specific resources.

• We are signposting to work going on in the space, we can figure out what it means for us as a community to specifically endorse things

There is value (maybe the biggest part of the value) in UK TRE being a convening space for working groups.
I think the separation between hosting a working group and endorsing the output is a good one.

Perhaps the default should be only hosting, no endorsement.
If there is an output that has a statement to be endorsed or rules/processes to be adopted that might be better addressed by some sort of vote/discussion after the output is made. Maybe something like RfCs or PEPs.

How many working group outputs do we expect to be looking for community buy in? (It might not actually be that many)

[harisood]

PR opened for this with initial thoughts here: #54

Will flesh out tomorrow and share a version with the CMWG

[manics]

If there is an output that has a statement to be endorsed or rules/processes to be adopted that might be better addressed by some sort of vote/discussion after the output is made. Maybe something like RfCs or PEPs.

The Zarr project are currently defining an RFC style process. Zarr is a technical specification but I think we can still learn from what they're going through in addition to the Jupyter processes linked earlier ome/ngff#222

Related to this, I think we should try and avoid hosting outputs by default, and instead encourage WGs to host their own outputs. For example, creating their own GitHub organisation instead of putting everything in the UK-TRE GitHub org, publishing outputs to Zenodo instead of hosting them on the UK-TRE website, etc. This emphasises that (at least for now) UK-TRE is mostly about signposting, with the additional benefit that WGs can govern themselves and how they want to manage privileged access to their resources.

[harisood]

encourage

How strongly? We could go anywhere from 'ideally groups would do this' to 'if you want to host on UK TRE, fill in form justifying reason...'