Working groups

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, the Research Data Alliance (RDA), the W3C, the IETF 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:

• The establishment of the WG
• The dissemintation 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 that are signposted to through the Community (dissemination)

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.
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 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.
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, and the community is notified of its creation.

Sharing 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 via an Issue on the UK TRE GitHub 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 2 possible final outcomes. Clear justification for the decision will be provided alongside the final outcome to the Working Group by the Steering Group.

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

The Steering Group approves the outputs.

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 carry out further work.

Closing a Working Group

All working groups will have a lifespan of 2 years, after which time they will be considered closed (unless explicitly extended by the Working Group chairs and agreed by the Steering Group (insert link).

If a Working Group wishes to close before the 2 year mark, the following process must be followed:

1. The Working group alerts the Steering Group, confirming its termination.
2. The Steering Group reviews this, 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 approved, used and accepted by the community. In order to maximise the chance of community usage 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

Outstanding discussion & objections

The above is the current live and used process. Any ongoing discussions about amendments to this process will be linked here!

• Endorsing WG outputs