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...'

[manics]

To begin with, to keep things unambiguous we could say it's mandatory, but we provide tech support for WGs to setup the public infrastructure they need? In that sense the main UKTRE shared resources would be signposting on the website, Slack channels if the WG wants them, and access to discussion the mailing list (which everyone has anyway). We can then work on the process for endorsing a WG output of UK TRE later, after we've got some examples.

[harisood]

PR live here: #54

[harisood]

Can we add a doc on 'what you can/can't expect from UK TRE Community'

[Davsarper]

16 Jan notes

(most conversation in the PR)

• Will we ensure that the work is also not done outside the community? or only within? The first
• IETF WG structurefor ref: https://www.ietf.org/how/wgs/
• Add what support WGs can expect from the Community/SG
• Difficulty of GH/PRs to be read and understood
• What does endorsement actually mean/entail? We will clarify as we go, but it does not need to mean more than members of the community can get behind what is said. A bit of a gold stars but sometimes you do not need more. For now we will add a note that it is in development
• Let the community feedback and shape but most often than not, every WG should go ahead if they do not overlap and are within remit

[harisood]

GD Working Groups Charter template: https://docs.google.com/document/d/1yt4tdmxzXHV73sKZx8EcUsboA8UURYDCFgAdjyCXAUw/edit#heading=h.y3eynwbxjkb4

GD Working Groups Process template: https://docs.google.com/document/d/1_Sc3Zz2OosIkwy5QzSw4I35Tdw-56gDo0i8Z4_b4B8s/edit#heading=h.hzko9ywcr2lh

[KirstieJane]

A great idea from Yensi Flores Bueso in her recent keynote talk: working groups should be time bounded - by default they end after 2 years.

This really helps to manage the cognitive load / spread of initiatives if there are working groups that aren't really making active progress. Asking if folks want to fold their working group will generally result in a "no we love our working group" but a default "come in boat number 12 your time is up" feels less painful.

Working groups that are making great progress can apply to extend for another 2 years (and again and again if they hit a great cadence!)

Here are the governance documents that Yensi shared: https://coara.eu/coalition/governance. They don't have an open license on them but I think we could get permission to reuse 😄

[Davsarper]

Interesting from https://www.ietf.org/how/wgs/

The general rule on how Working Groups make decisions is that the Working Group has to come to "rough consensus", meaning that a very large majority of those who care must agree, and that those in the minority have had a chance to explain why and their points have been addressed, even if they were not agreed with. It is up to the chairs to decide when the Working Group has reached rough consensus;

[Davsarper]

As well as this, could be inspiration on how to put forward an output for community hosting/endorsement

When a Working Group document is ready to progress beyond the Working Group, the chairs will assign a "shepherd" to take over the final process. The role of the document shepherd is described in RFC 4858: Document Shepherding from Working Group Last Call to Publication. A chair who knows the history of the document within the Working Group, often does the shepherd write-up.

[manics]

The idea of a shepherd is used by

• Python https://peps.python.org/pep-0001/#start-with-an-idea-for-python
• Jupyter https://jupyter.org/enhancement-proposals/jupyter-enhancement-proposal-guidelines/jupyter-enhancement-proposal-guidelines.html

Is this something we should add to the doc now? Or can we try it out on an informal basis, see how it works, and then write it up to use in future?

[Davsarper]

I would go to the latter, we are small enough to do without I think. De facto sheperds will be WG proponents/acive people, but I like the concept of someone putting it all clearly somewhere and bringing it to the rest of the Comm for discussion

[Davsarper]

I added in the PR but will also put here for visibility, I created a gdoc for the Steering Group and Diagram. Very very draft (just thoughts) but all comments welcome https://docs.google.com/document/d/1idAxXpAVWeiPZkpT6_z5OOKog6LHtvyHnOiF0fhIdaw/edit?usp=sharing
Outdated, right link to SG document is https://docs.google.com/document/d/1t4_dTdJEQHZuuF_l915bo_P-lCv0jRHuHvHCus26a8w/edit#heading=h.e9lbbh3jy6hx

[Davsarper]

Gov writing discussion

(discussion arose in #60|)

• • WG chairs should be part and parcel of the governance model. If there are few of them yet, we could invite proto-WGs (people in our community who have been involved in different aspects but have not yet gone for it) and other people in the community that need to be part of this conversation
• Involving everyone is important, but it should not hold the work. People may have low involvement in still vague processes
• The participation has to be open to everyone, and then people who contribute can. This group should be about facilitating.
• Summary (governance writing process): cannot create without making participation possible, have to put together our draft proposals so the discussion is based on something (which are already open). Because it will have to happen in April, basically we will get to it with a first proposal already

[Davsarper]

This and all governance documents need time allocated and accountability, they need to get done. @harisood and @Davsarper will co-work on them this week. For feedback and actions enxt

[harisood]

Initial diagram:

[rmbaxter67]

On ‘Steering Group reject, approve or endorse’ step: I’m not at all clear what we might mean by reject or approve here. If a WG produces a piece of work, I think all we could expect the SG to do, post community review, is either endorse it or not. Endorsing it gives it “RFC” status, or equiv – a badge, a home on the website, etc. – whereas not endorsing is just that. No badge, no prominence, WG wraps up, piece of work is whatever it is. Pop it on Figshare and move on.

[harisood]

Some detail is in the text: https://docs.google.com/document/d/1_Sc3Zz2OosIkwy5QzSw4I35Tdw-56gDo0i8Z4_b4B8s/edit

The idea being the resources would in general still be available on the site (as a signposting function), but some would have a special badge if endorsed. Reject comes from 'the community does not want to be associated with these outputs'.

It should be a quick and easy decision for the SG depending on what the community has said!

The idea for WG closure (some simple template email j saying 'please close this group' is so people know the group officially no longer exists and can't be joined - as opposed to, say, the WG saying 'ooooh now we've done this we're gonna work on this other output'

[harisood]

This PR has now been updated - once links/diagrams go in it might be good to go! Link here: #54

[manics]

I think we need to define what endorse means, beyond a "special badge". For example, does endorsing an output mean:

• it's the formal position of UK TRE?
• it's a notable piece of work that people should take notice of but UK TRE remains neutral on what it means?

Otherwise I think a binary accept/reject is easier for now, and encourage WGs and UK TRE members to promote the outputs themselves.

[Davsarper]

Google doc for charter is here https://docs.google.com/document/d/1yt4tdmxzXHV73sKZx8EcUsboA8UURYDCFgAdjyCXAUw/edit#heading=h.y3eynwbxjkb4 (I was struggling to find the link)

[Davsarper]

I have copied the latest proposed version (inclusive of my suggestions) to the g doc and that is where we point people in the community to make changes and there is conversation happening.

[manics]

• Todo: Check if on new website

[Davsarper]

Done here https://uk-tre.github.io/hugo-website/about/governance/working-groups/

Outstanding discussion: Endorsing outputs, therefore not included in this version