Initial thoughts on WG process

governance/steering group/steering_group.md

@@ -0,0 +1,7 @@
+# Steering group
+
+## What it is
+
+## What it does
+
+First version of content will be created here https://docs.google.com/document/d/1t4_dTdJEQHZuuF_l915bo_P-lCv0jRHuHvHCus26a8w/edit?usp=sharing then this document will be updated on GH

governance/working groups/index.md

@@ -0,0 +1,91 @@
+# Working groups
+
+## Overview
+
+For the UK TRE Community, a Working Group (WG) is a space for members to come together to work and discuss on a topic.
+
+WGs can be set up by any member of the community, and are focused on producing specific, tangible outputs within a given time period.
+They are modelled off the pre-existing concept of Working Groups found in communities like [DARE UK](https://dareuk.org.uk/dare-uk-launches-dynamic-collaborative-communities-invites-proposals-for-new-groups/), the [Research Data Alliance (RDA)](https://www.rd-alliance.org/groups/creating-and-managing-rda-groups/creating-or-joining-rda-working-group.html), the [W3C](https://www.w3.org/2017/Process-20170301/#GAGeneral), the [IETF](https://www.ietf.org/how/wgs/) and more.
+
+UK TRE Community Working Groups become part of the wider UK TRE Community ecosystem, and benefit from:
+- Having access to and engaging a community of TRE experts from across industriues keen to work collaboratively
+- Dedicated space on the [UK TRE Community website]() to share updates and outputs
+- Promotion through our communication channels, including Slack, mailing list, website and newsletter
+- Dedicated presentation opportunities and breakout rooms at our quarterly meetings
+- Additional support from the [Community Management Working Group]() where possible
+
+## Process
+
+There are two distinct processes for those creating a WG to consider:
+
+1. The establishment of the WG
+2. The community endorsement of the WG outputs
+
+As the UK TRE community's primary focus is to act as a signposting and convening body for the TRE space in the UK and beyond, we have made a conscious effort to separate out the questions of:
+
+- Work that is happening within the community (WG establishment)
+- Outputs/resources for which there is community consensus and endorsement (community endorsement)
+
+Therefore it is important to note that establishing a WG with the UK TRE community **does not** imply any outputs of the WG are endorsed by the UK TRE Community.
+
+### Establishing a Working group
+
+1. Member(s) suggesting a working group fill in the [Working Group Charter](working-group-charter.md).
+2. The Charter is reviewed by the [Community Management Working Group]() to ensure it:
+    - Aligns with [community principles]()
+    - Represents new work being undertaken in the community
+3. If the Charter is rejected by the [Community Management Working Group](), feedback is provided to the submitting member(s) on why, and the Working Group returns to step 1.
+4. If the Charter is approved by the [Community Management Working Group](), the Charter is made available for community review, and communicated with the community, via an Issue on the [UK TRE GitHub](https://github.com/uk-tre/community-management) for a period of at least 14 days.
+5. After the review period, the [Steering Group]() will either formally reject or approve the WG creation, in line with the [Consensus, Review and Objection Management Process](https://docs.google.com/document/d/1SxFnmMKcfsYaO4wjHdiBfGOgPATIsTwRKaLbyjoN1pA/edit?usp=sharing).
+6. If the WG is rejected, any outstanding objections requiring review are collated by the [Steering Group]() and shared with the Working Group proposers for updating the charter, and the Working Group returns to step 4.
+7. Once a Working Group is established, they are formally recognised on the [UK TRE Community website](https://www.uktre.org/), and the community is notified of its creation.
+
+### Endorsing Working Group outputs
+
+1. When a WG has outputs ready to share with the community, they notify the [Community Management Working Group]()
+2. The draft outputs are reviewed by the [Community Management Working Group]() to ensure it:
+    - Aligns with [community principles]()
+3. If approved by the [Community Management Working Group](), the draft outputs are made available for community review, and shared with the community, via an Issue on the [UK TRE GitHub](https://github.com/uk-tre/community-management) for a period of at least 28 days.
+4. At the end of this period, based on community input the outputs will be considered by the [Steering Group]() with 3 possible outcomes:
+
+#### Rejection
+
+The [Steering Group]() rejects the draft outputs of the WG.
+
+The [Steering Group]() will collate the reasons for rejection and share these with the WG.
+The WG can decide to either close out the working group, or amend the outputs to resolve any reasons for rejection.
+
+#### Approved for distribution
+
+The [Steering Group]() approves the outputs for distribution. 
+
+The UK TRE community will signpost to the outputs, but will not specifically endorse them.
+The WG can decide to either close out the working group, or amend the outputs to work towards endorsement.
+
+#### Approved and endorsed
+
+The [Steering Group]() approves the outputs for distribution, and explicitly endorses them.
+
+The UK TRE community will signpost to the outputs, and formally endorse them publicly.
+
+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.
+If Working Groups are happy for their outputs to simply be approved and not endorsed by the community, they should make this clear to the [Steering Group](). 
+
+The WG outputs will be tagged with a version referencing this endorsement.
+If the WG wants to amend/update these outputs, they will have to go through the endorsement process above again. 
+
+No future versions beyond the tagged version are guaranteed to be endorsed by the community.
+
+
+### Closing a Working Group
+
+1. The Working group completes the [Working Groups closure form]() confirming its termination.
+2. The [Community Mangement Working Group]() reviews this form, and when approved, lists this working group under `Historical Working Groups`.
+
+### Recommendations
+
+Outputs that have transparently engaged the community and reflect community consensus on the issue at hand are the most likely to be endorsed. In order to maximise the chance of community endorsement for Working Group outputs, we recommend all working groups:
+
+- Share regular updates with the wider community, to ensure co-creation and allow amendments to happen live, rather than at the end
+- To carefully consider the scope, and target outputs, based on community feedback. If specific suggested outputs face pushback, are there higher level outputs that are more reflective of what the community needs?
+- To carry out informal reviews of outputs with the community regularly, before requesting formal review. Special attention should be given to those with objecting views on the Working Group's proposed outputs and work

governance/working groups/working-group-charter.md

@@ -0,0 +1,49 @@
+# Working group charter template
+
+## Overview
+
+This section should summarise in one or two paragraphs the Working group proposal, for any community member to read and quickly grasp the essence of the WG.
+
+## Background
+
+This section should dive into more detail on what the WG aims to address, why it is undertaking this work, and reference any background material/pre-existing work that this proposal builds on.
+
+## Target outputs
+
+This section should contain the target outputs of the WG
+
+## Meeting mechanisms
+
+This section should include details on how, where and when the WG intends to meet
+
+## Communication mechanisms
+
+This section should outline how the WG intends to communicate progress with its members, the UK TRE Community more widely, and any other interested stakeholders.
+
+This could include individual people, organisations, community groups and more who may be interested in or impacted by the work of the WG.
+
+## Working Group roles
+
+This section should outline the different roles within the Working Group. Examples include:
+- **Chairs**: Leaders of the WG
+- **Contact**: Primary contact for the WG
+- **Participating members**: Members who are undertaking work within the Working Group
+
+## Getting involved
+
+This section should detail how interested parties can get involved with joining the WG.
+
+It should also detail expected weekly time commitment for defined roles above
+
+## Resource requirements
+
+This section should include perceived resource requirements to carry out this work.
+
+Where possible, the Community Management Working Group will support with resources - but these are as of writing very limited!
+
+## Agreement
+
+By submitting this charter, this working group agrees to:
+- [ ] Share any outputs openly under an open licence
+- [ ] Allow participation from any interested parties
+- [ ] Report on progress at each quarterly community meeting for the duration of the Working Group