Initial thoughts on WG process

[harisood]

Initial thoughts to flesh out tomorrow

[harisood]

Thoughts as they arise:

• Something about who specifically should be consulted about this working group, or its outputs? Mb something along the lines of 'register here to be consulted on whether the outputs should be endorsed by the UK TRE Community or not' or smth
• Could the live website info include: summary, relevant background info, ongoing work, key resources, how to get involved
• Different roles within working groups (e.g. participating member, interested member). Do we want to define these responsibilities? I'm tempted to only define responsibilities for the chair at this stage - see here

[harisood]

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
• Fill in empty links (there are many!)

[JimMadge]

On the outcomes: reject, share, endorse it reads a bit like the WG itself doesn't have a say on this.

I could imagine a WG where the output is only ever intended to be shared, a review for example, rather than a policy/process which needs to be adopted.

Maybe a lighter-weight system would be the steering group only looks into approving the outputs if it is specifically requested?

[manics]

If there are any more formatting issues we can add pre-commit/prettier later 😄
https://github.com/uk-tre/website/blob/8b00a7e20fd25cad398675f651336f6f7063b72e/.pre-commit-config.yaml#L8-L12

[Davsarper]

Overall a great start, I think it reflects previous discussions and the aproach we are taking. I would emphasize the role of the community to make discussions happen, even more so when there is no yet agreement

[Davsarper]

I think we may need to do more than recommend, updates and contribution mechanisms should be mandatory. And recommend that if any pushback/dissenting opinions exist in the community then special attention is put to include them

[JimMadge]

Thoughts from community WG meeting that I don't want to forget,

It might be helpful to have a question which prompts WG proposals to think about how much resource they need. That will help the panel decide if it sounds realistic or if UK TRE can support that work (financially, with people time, with infrastructure etc.).

It would also be helpful to have a complementary paragraph briefly explaining what support a WG can expect. "Why host your WG here". Things we could do quite easily,

• Attention of our community! Many TRE experts keen to work collaboratively.
• Space on community site
• Promotion through our communication channels
• Presentations/breakout rooms at UK TRE meetings

[JimMadge]

We should add some brief text to explain the different roles of the panel and community in reviewing WG proposals. This might be,

• Panel makes go/no go decision.
• Community review is for shaping WG, refining the proposed work. The community do not themselves approve or reject a WG.

What about the instance where community feedback is very (or universally) negative, what happens?
To keep this lightweight it may be better to let the panel react to this rather than adding more formal steps/voting to the process.

[manics]

I agree with Jim on not being too proscriptive about the steps for making the decision. Maybe we could say "the steering group will make a final decision on the WG taking into account all feedback, and will provide clear reasons for the decision"?

[harisood]

Ok have just done a refactor! Capturing some thoughts from comments here:

I could imagine a WG where the output is only ever intended to be shared, a review for example, rather than a policy/process which needs to be adopted.
Maybe a lighter-weight system would be the steering group only looks into approving the outputs if it is specifically requested?

@JimMadge good nuance, not sure if we need it now tho - and can deal with it on an output-by-output basis?

I think we may need to do more than recommend, updates and contribution mechanisms should be mandatory. And recommend that if any pushback/dissenting opinions exist in the community then special attention is put to include them

@Davsarper I left a comment on this but may now be lost. Like the idea but not sure where this would go - and also if a group is doing this (ignoring dissenting views) this will become apparent in the Steering Group review?

@JimMadge have included resource thoughts on charter, and benefits on the WG page (thank you for both great suggestions!). Also hopefully the distinction between community review and SG approval/rejection is now clear.

[Davsarper]

where this would go -

I think it can live here, in the charter or in the document on the outcome review process

and also if a group is doing this (ignoring dissenting views) this will become apparent in the Steering Group review?

Yes, but why make it harder for the SG to trace if that has happened or not and instead ask that it is done (for example compare first proposed version of WG charter or output with community reviewed one). Or at least have it as a step.

Overall I think this will be necessary to comply with our principles and will happen one way or another, if it is confusing leave out but if we see the chance to make it explicit I would. And I like it included in official gov documents just to ensure that it is read

[harisood]

Thanks for all the comments and suggestions! I've addressed them all in the latest commits. Final approval and we can merge this!

@manics, talking to @Davsarper we realised that a lot of this stuff can live permanently on the website repo (once it's ready), and not much info actually needs to live on this repo. WDYT?

[Davsarper]

Suggested change

	2. The Charter is reviewed by the [Steering Group]() to ensure it:
	2. The Charter is reviewed by the [Steering Group](governance/steering group/steering_group.md) to ensure it:

[Davsarper]

I didn't remember I had already made this point haha, I actually think this is a good place to include rather than have a separate document on best practices or recommendations on making a succesful output. This is the document all WGs will go through (or the charter), if not here then in the output approval process? I think it is worth formally mentioning that part of the community review is including (or at elast considering) its recommendations

[Davsarper]

Suggested change

	- Share ideas for WGs widely with the community and incorporate feedback into their charter before submission

[manics]

Have we defined what it means to "endorse" something?

[Davsarper]

I tried adding clear steps for endorsement, addittional to only approving and requiring community review (of the endorsement).

[Davsarper]

Suggested change

	### Endorsing Working Group outputs
	### Sharing Working Group outputs

[Davsarper]

Suggested change

	The decision to endorse a Working Group output will be more rigorous, and therefore likely take longer, than the decision to approve outputs for distribution.
	The decision to endorse a Working Group output will be more rigorous, and therefore likely take longer, than the decision to approve outputs for distribution.
	To be endorsed an output will need to have been sufficiently discussed and have clear and wide support, the SG will make explicitly clear why it considers the discussion and support to be enough.
	The SG will announce when an output is being endorsed, the output will then
	1. Be presented at a Quarterly Event by the WG
	2. Its endorsment be open for community review for a period of 7 days in line with the [Consensus, Review and Objection Management]() process. During this period the focus will be on reviewing endorsement, not content.
	3. Be ratified for endorsement by the SG, or decide to only approve

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