diff --git a/content/about/governance/index.md b/content/about/governance/_index.md
similarity index 80%
rename from content/about/governance/index.md
rename to content/about/governance/_index.md
index d5e4ef8..2d45865 100644
--- a/content/about/governance/index.md
+++ b/content/about/governance/_index.md
@@ -2,9 +2,7 @@
title: "Governance"
description: "Our governing documents, decision making processes, template charters and more"
draft: false
-url: about/governance
+layout: governance/index
tags:
- about
---
-
-# Governance
diff --git a/content/about/governance/consensus-review-objection.md b/content/about/governance/consensus-review-objection.md
new file mode 100644
index 0000000..7eba731
--- /dev/null
+++ b/content/about/governance/consensus-review-objection.md
@@ -0,0 +1,99 @@
+---
+title: "Consensus, Review and Objection Management "
+description: "The process for how consensus is approached for community decisions, review of community initiatives, and how objections are managed."
+draft: false
+tags:
+- governance
+---
+
+# Consensus, Review and Objection Management
+
+This file lays out the process for how consensus is approached for community decisions, review of community initiatives, and how objections are managed.
+
+## Consensus
+Decisions within the community are primarily driven by [lazy consensus](https://communityrule.info/modules/lazy_consensus/).
+In essence, this means unless objections are raised within the community to the initiative in question within a defined time period, it will be approved.
+
+New issues may be raised for consideration in any forum (e.g. email, GitHub, Slack, etc.).
+
+Conversations about community initiatives ([Working Groups]({{< relref "../../groups/" >}}), [outputs and resources]({{< relref "../../community_resources/" >}}), [events]({{< relref "../../events/" >}})) will be logged openly within our [GitHub organisation](https://github.com/uk-tre), within issues.
+This period is known as **‘community review’**.
+
+Any discussion about the initiative should be recorded here, including:
+- Approvals and objections
+- Updates
+- Summaries of meetings about the initiative
+
+Discussions will remain open for a defined set of days (usually 14 or 28).
+Within this time period the community should aim to reach consensus, and to resolve any objections that are raised, in an open, deliberative manner.
+
+## Official Review
+
+### Decision making
+
+When an initiative is ready for official review, it is submitted to the [Steering Group]({{< relref "./steering-group" >}}).
+
+The [Steering Group]({{< relref "./steering-group" >}}) will use the discussion related to the initiative from the community review to inform the decision they make.
+The decisions they can make depending on the initiative are laid out below:
+
+---
+| Initiative | Possible decision |
+| ---------- | ----------------- |
+| Working group creation | Reject; Approve |
+| Working group outputs | Reject; Approve; |
+| Governance document amendment, creation or removal | Reject; Approve |
+| Official UK TRE Community Event | Reject; Approve |
+---
+The [Steering Group]({{< relref "./steering-group" >}}) will publish their decision openly, including rationale for their decision, in a report.
+
+By default, the [Steering Group]({{< relref "./steering-group" >}}) should not reject anything that:
+- Aligns with community principles
+- Is not being covered elsewhere in the community
+- Has no outstanding objections
+
+### Outstanding objections and review period
+
+Even if the initiative may have outstanding objections, the [Steering Group]({{< relref "./steering-group" >}}) may still approve it.
+In this instance, the [Steering Group]({{< relref "./steering-group" >}}) will maintain any outstanding objections from the community review, and publish them in their report.
+
+The [Steering Group]({{< relref "./steering-group" >}}) will also create a ‘review period’ for their decision.
+This period represents the amount of time the decision will remain in place before being re-opened for open community review, in minimum periods of 3 months (e.g. 3, 6, 9, 12, 15, 18, or 24 months).
+
+For instance, if a working group’s output is approved with a review period of 12 months, it will mean the output is officially approved as of now, and in 12 months time an open community review will take place to decide whether to continue approving it.
+
+The review period will be set by the [Steering Group]({{< relref "./steering-group" >}}), and will be influenced by certain factors, including:
+- The extent of consensus reached during community review
+- The number, strength and popularity of outstanding objections
+- The content and implications of the initiative
+
+## Raising a new objection
+If a community member wants to raise a new objection to a community initiative outside the period for open community review, they may raise a new objection using the process below.
+
+### 1. Open an issue
+
+Open an issue on the [community management repo](https://github.com/uk-tre/community-management) using the ‘objection’ template.
+
+This includes:
+- **Decision being objected**: The specific decision made within the community being objected
+- **Linked Issues/PRs**: Link to any issues, documents or other information useful for context
+- **Detail**: The detail the member(s) raising the issue want to discuss
+- **Action requested**: Specific, actionable items the member(s) raising the issue want to see taken
+
+### 2. Validation
+The [Community Management Working Group]({{< relref "../../groups/current/community_management" >}}) will validate the issue to make sure it:
+- Aligns with community principles
+- Represents a new issue not currently being addressed in the community
+
+### 3. Community discussion
+Once approved, the issue will be open for community discussion for a period of 28 days.
+
+### 4. Objection added to relevant initiative
+If unresolved at the end of the 28 day period, the [Steering Group]({{< relref "./steering-group" >}}) will add the objection as an outstanding objection to the relevant report, and amend the review period if required.
+
+---
+
+## Outstanding discussion & objections
+
+The above is the current live and used process. Any ongoing discussions about amendments to this process will be linked here!
+
+- [Discussion on whether to 'endorse' community outputs](https://github.com/uk-tre/community-management/issues/89)
\ No newline at end of file
diff --git a/content/about/governance/events-management.md b/content/about/governance/events-management.md
new file mode 100644
index 0000000..ac21fca
--- /dev/null
+++ b/content/about/governance/events-management.md
@@ -0,0 +1,118 @@
+---
+title: "Events Management"
+description: "How events are managed, run and communicated within the community"
+draft: false
+tags:
+- governance
+---
+
+# Events management
+
+## Overview
+
+There are three main categories of event within the community:
+
+- **Official UK TRE Community Events**: These are events being put on by the [Community Management Working Group]({{< relref "../../groups/current/community_management" >}}), and include all quarterly meetings, [Community Management Working Group]({{< relref "../../groups/current/community_management" >}}) meetings, Town Halls and any additional ad hoc community events.
+- **Working group events**: These are events being run by [Working Groups]({{< relref "../../groups/" >}}). They include their regular open meetings, as well as any ad hoc events they put on.
+- **Other TRE events**: These are any other events we are aware of within the TRE landscape that we signpost people towards.
+
+Events calendar
+
+We have an events calendar set up in TeamUp. This is available on our [events page]({{< relref "../../events" >}}).
+
+This is a comprehensive calendar containing all events we are aware of within the TRE Community, along with instructions on how to subscribe.
+
+If you’d like to add an event to this calendar, please read through the process in ‘Other TRE Events’ below.
+
+## Official UK TRE Community Events
+
+### Quarterly meetings
+
+Our quarterly meetings take place in March, June, September, and December.
+
+Currently March, June and December are fully online, half-day meetings.
+Our September meeting is a full day hybrid event based at a location within the UK.
+
+All meetings are free to attend, and anyone can sign up!
+
+#### Meeting structure
+
+The quarterly meetings follow broadly the same structure, with an additional session at the September meetings:
+
+##### Keynote
+
+The meetings start with a keynote session followed by an elongated Q&A.
+
+The keynote is decided by, and invited by, the [Community Management Working Group]({{< relref "../../groups/current/community_management" >}}), with input from the community.
+
+##### Community updates (online meetings) / Lightning Talks (hybrid meeting)
+
+In online meetings, there is a window where any members of the community can share informal, quick updates on work they are doing, outputs, initiatives and more.
+
+All active [Working Groups]({{< relref "../../groups/" >}}) are required to give an update during community updates.
+
+At the all-day hybrid meeting, instead of informal community updates there is a full session of lightning talks.
+Teams or individuals have 5 minutes to present their work to the rest of the community, with a focus on calls to action and ways to collaborate.
+
+All active [Working Groups]({{< relref "../../groups/" >}}) are required to give an update during lightning talks.
+
+##### Breakout sessions
+
+Breakout sessions are opportunities for attendees to join smaller groups and work on a particular problem.
+There are two main types of breakout sessions:
+- **Workshops**: These are planned sessions, where a member/team can bring an issue they are currently working on to the community to brainstorm possible solutions with other members of the community.
+- **Discussions**: These are more informal sessions where members come together to openly discuss a particular topic within the TRE space.
+
+#### Registering and suggesting sessions
+
+All quarterly meetings are open invite and free to attend.
+
+Registration for meetings are live one at a time.
+Links to register are live on our [website](/), as well as shared on our [mailing list](https://www.jiscmail.ac.uk/cgi-bin/wa-jisc.exe?SUBED1=UK-TRE-COMM&A=1) and [Slack channel](https://join.slack.com/t/uktrecommunity/shared_invite/zt-26r7jz25d-J5iV0XoqyLepEiKk4XpJVg).
+
+When you register, you are prompted to share details on sessions you would like to run.
+
+Further to this, members of the [Community Management Working Group]({{< relref "../../groups/current/community_management" >}}) may reach out to you to suggest sessions you could run at the meeting - these suggestions will be based on community interest and your expertise!
+
+All suggested sessions are reviewed by the [Community Management Working Group]({{< relref "../../groups/current/community_management" >}}), who then decide the final agenda.
+This is communicated with everybody who suggested a session, and justification will be provided to anyone who has suggested a session that does not make it onto the final agenda.
+
+If members are unsatisfied with any decision that is made about proposed sessions, they can reach out to the [Community Management Working Group]({{< relref "../../groups/current/community_management" >}}), and if required raise an [Objection]({{< relref "/consensus-review-objection" >}}).
+
+Members who suggested a session that is added to the final agenda may be needed to provide additional information for the event.
+
+## Working Group Events
+
+All [Working Groups]({{< relref "../../groups/" >}}) are required to have one regular meeting which is open for anybody from the community to join.
+This will be advertised both on the [events calendar]({{< relref "../../events" >}}) and [Working Group page]({{< relref "../../groups/" >}}).
+
+Additionally, [Working Groups]({{< relref "../../groups/" >}}) may wish to add ad hoc events to the calendar.
+To do so they can fill in the Event requests form (see below).
+
+## Other TRE Events
+Events that are not officially run by any working group can also be added to the calendar!
+
+To do so, members must follow the below process.
+
+### 1. Fill in the events request form
+The form can be found here: https://forms.gle/2J6DG8TKWkbQmCFZ9
+
+If your event already has a registration page, you can simply link to this page and submit.
+
+If it doesn’t already have a registration page, you’ll need to provide details of your event in the next section.
+
+### 2. Review
+
+Responses will be reviewed by the [Community Management Working Group]({{< relref "../../groups/current/community_management" >}}).
+
+If approved, the event will be added to the [events calendar]({{< relref "../../events" >}}) and included in upcoming events announcements to the community.
+
+If not approved, the [Community Management Working Group]({{< relref "../../groups/current/community_management" >}}) will provide reasons to the named member on the form.
+Members can then amend their form and resubmit, or if required, seek further clarification from the [Community Management Working Group]({{< relref "../../groups/current/community_management" >}}).
+If required, members can raise an [Objection]({{< relref "/consensus-review-objection" >}}).
+
+---
+
+## Outstanding discussion & objections
+
+The above is the current live and used process. Any ongoing discussions about amendments to this process will be linked here!
\ No newline at end of file
diff --git a/content/about/governance/governance-amendments.md b/content/about/governance/governance-amendments.md
new file mode 100644
index 0000000..9856e1b
--- /dev/null
+++ b/content/about/governance/governance-amendments.md
@@ -0,0 +1,93 @@
+---
+title: "Governance Document Management"
+description: "The process for creating, amending or removing key governance docs from the UK TRE Community"
+draft: false
+tags:
+- governance
+---
+
+# Governance Document Management
+
+This file lays out the process for creating, amending or removing key governance docs from the UK TRE Community.
+
+The aim for this document is to make it transparent and easy for any member of the community to propose changes to the governance infrastructure of the community, keeping it dynamic, representative and decentralised!
+
+## Process
+
+### 1. Suggesting
+
+Open an issue on the [community management GitHub repository](https://github.com/uk-tre/community-management) using the ‘Governance document’ issue template, or submit [this Google Form](https://forms.gle/eVvq6rvv3oDvVnjq6).
+
+If you use the Google Form, the [Community Management Working Group]({{< relref "../../groups/current/community_management" >}}) will create a GitHub issue related to what you submit.
+
+You must provide:
+- **Name**: The name of the document you want to create, amend or remove
+- **Type of change**: Whether you want to create a new document, amend a pre-existing document, or remove a pre-existing document
+- **Size of change**: Whether your change is `editorial` (does not change the underlying meaning or content of the document) or `substantial` (changes the underlying meaning or content of the document. Any suggestion to create or remove a document is by default a `substantial` change. Distinctions between editorial and substantial changes are loosely based on the [W3C Classes of Changes](https://www.w3.org/2023/Process-20231103/#correction-classes).
+- **Detail**: Any detail about the change you want to make
+- **Link**: A link to an open version of the document. If you are suggesting creating or amending a document, this should also have permissions for anyone to add comments/suggestions.
+
+If you are submitting a GitHub issue, you must also:
+- Assign the issue the label `governance`
+- Add the issue to the Project board `TRE Community - project board`
+
+### 2. Agreed upon
+
+The [Community Management Working Group]({{< relref "../../groups/current/community_management" >}}) will discuss the proposal to:
+- Ensure it doesn’t overlap with our [Community Principles]({{< relref "./newcastle-commitment" >}})
+- Ensure it doesn’t conflict with pre-existing proposals
+ - This may include finalised initiatives, which may state that the specific Governance Document is currently closed for review
+
+The [Community Management Working Group]({{< relref "../../groups/current/community_management" >}}) may either:
+- Reject the proposal, citing reasons
+- Ask for amendments to proposal
+- Accept the proposal
+
+If the proposer is dissatisfied with the reasons for rejection, and cannot resolve these with the [Community Management Working Group]({{< relref "../../groups/current/community_management" >}}), they can submit an [Objections]({{< relref "./consensus-review-objection" >}})
+
+### 3. Drafted
+
+Once accepted, the proposer works to draft the new or updated document.
+
+This process must be done openly, allowing community members to comment on, suggest and review changes.
+
+If you are suggesting removing a document, this step does not apply.
+
+### 4. Open for review
+
+Once drafted, the proposer alerts the [Community Management Working Group]({{< relref "../../groups/current/community_management" >}}).
+
+They will review the document (to ensure it complies with our [Community Principles]({{< relref "./newcastle-commitment" >}})), and open it for official review.
+The proposal will also be circulated with the community.
+
+For `editorial` changes, the review period will remain open for 14 days, or whilst there are still outstanding objections, whichever is later.
+
+For `substantial` changes, the review period will remain open for 28 days, or whilst there are still outstanding objections, whichever is later.
+
+During this period, the document can be updated and amended as required.
+
+### 5. Finalised
+
+When the document has closed for review, the proposer can submit it for finalisation.
+
+The proposer will submit the document to the [Steering Group]({{< relref "./steering-group" >}}). The [Steering Group]({{< relref "./steering-group" >}}) will consider all community feedback and come to one of two conclusions:
+- Reject the proposed change, providing reasons
+- Accept the proposed change
+
+If the [Steering Group]({{< relref "./steering-group" >}}) rejects the proposed document, the proposer can either close their suggestion, or return to step 3.
+
+### 7. Tagged/released
+
+If approved, the [Community Management Working Group]({{< relref "../../groups/current/community_management" >}}) adds the document to the [community management GitHub repository](https://github.com/uk-tre/community-management) and to the [UK TRE Community website]({{< relref "../governance" >}}).
+
+## Other notes
+
+### Appeal
+If at any stage the proposer is unsatisfied with the reasons provided for objection, they can raise an [Objection]({{< relref "./consensus-review-objection" >}}).
+Any appeals they raise will follow this process.
+
+---
+
+## Outstanding discussion & objections
+
+The above is the current live and used process. Any ongoing discussions about amendments to this process will be linked here!
\ No newline at end of file
diff --git a/content/about/governance/newcastle-commitment.md b/content/about/governance/newcastle-commitment.md
new file mode 100644
index 0000000..79f08e0
--- /dev/null
+++ b/content/about/governance/newcastle-commitment.md
@@ -0,0 +1,65 @@
+---
+title: "The Newcastle Commitment"
+description: "The core principles and actions to which all members commit"
+draft: false
+url: about/governance/newcastle-commitment
+tags:
+- governance
+---
+
+# The Newcastle Commitment to Open Collaboration for Trusted Research Infrastructure
+
+_Tuesday 5th December 2022_
+
+Data saves lives.
+Those working for public good have a responsibility to use personal data, including linked patient and social data at scale, to better understand and thereby improve society, health and wellbeing.
+
+Infrastructure for trusted research includes the secure environments where analysis takes place, called Trusted Research Environments (TREs), the governance processes that manage activity in these environments as well as the technology that underpins those governance processes.
+
+Those of us maintaining these infrastructures must ensure we protect this personal data, to prevent harm to individuals and maintain wider public trust for using such data in research.
+While no system can guarantee absolute security, we must ensure we handle data appropriately and securely, following local regulatory and legal frameworks and minimising the risk of data being inappropriately shared.
+
+Further, there is an additional obligation on these groups to work together.
+It is unsafe to work alone.
+Working together provides efficiency and interoperability, but more importantly, it will result in more secure, robust and capable infrastructure and more robust research outcomes.
+
+There are several challenges facing those building and maintaining trusted research infrastructure:
+
+- **Trustworthiness and transparency:**
+ Currently the information shared publicly about the policies, processes and systems used to protect sensitive data is limited and insufficient to verify that the data is being appropriately protected.
+ Validating that the systems used to protect sensitive data are appropriate is difficult when neither the design nor the deployed systems are independently auditable against broadly accepted and agreed standards.
+
+- **Accessibility and usability:**
+ Many organisations do not have the resources to independently develop trustworthy and usable policies, processes and systems.
+ Environments can be extremely cumbersome to gain access to and use, raising barriers to access to data-driven research methodologies, or encouraging researchers to work outside secure environments, risking data breach.
+
+- **Effectiveness and efficiency:**
+ Currently many organisations are independently developing their own policies, processes and systems to work safely with sensitive data.
+ Much of this work involves independently solving the same problems repeatedly.
+
+An open, collaborative and community driven development model meets these three challenges in a way that no other approach can.
+
+- Applying open, collaborative approaches to information governance process and policy development as well as to technology development means these can be co-designed and co-engineered, with technologists, policy communities, professionals and data subjects working together.
+- Open policies, processes and systems are transparent and verifiable.
+- Modern open source collaboration tools are uniquely scalable, both for code and for other artefacts: a global community can work together, at the same time, to add capability.
+- System infrastructure designs can be fully described in software code, an approach known as Infrastructure-as-Code (IaC), which renders the designs fully auditable and decouples design from deployment for particular institutions or purposes.
+- Open software is less likely to have security flaws, as it can be reviewed by a global community of developers and security professionals.
+- Each time a capability is added to the shared infrastructure, every site - university, research institute or hospital - can benefit with little additional effort.
+
+As people who regularly design, develop and operate the policies, processes and systems which enable working safely with sensitive data, we commit:
+
+- To openly share the policies and processes we use to work safely with sensitive data, working together to more closely align these under a common framework.
+- To collaboratively develop the systems to support these policies and processes.
+- Wherever practicable to standardise common approaches, formats and features which are platform agnostic.
+- To work closely with a wide range of stakeholders, including the public and interested parties, to develop usable, effective and scalable solutions that support their needs and meet their concerns.
+- To collaboratively design and develop TREs and other technology to support information governance using open, IaC approaches.
+- Wherever practicable, to add ideas for new capabilities and features to existing open projects rather than creating new ones.
+- To design our projects to be extensible and our communities to be easy and welcoming for others to contribute to.
+- To be active stewards of these open projects, welcoming contributions of all kinds from the wider community.
+- To actively share, review and revise this declaration on an ongoing basis
+
+---
+
+## Outstanding discussion & objections
+
+The above is the current live and used commitment. Any ongoing discussions about amendments to this process will be linked here!
\ No newline at end of file
diff --git a/content/about/governance/resources.md b/content/about/governance/resources.md
new file mode 100644
index 0000000..64cdd6e
--- /dev/null
+++ b/content/about/governance/resources.md
@@ -0,0 +1,21 @@
+---
+title: "Resource management"
+description: "How to submit resouces to the UK TRE Community"
+draft: false
+tags:
+- governance
+---
+
+# Resource management
+
+We expect a lot of resources within the community to be created through [Working Groups]({{< relref "../../groups/" >}}).
+
+However, we are aware that many members and teams may create resources outside of formally defined working groups, which may be of benefit for the community.
+
+If you have a resource you would like to submit to the [resource hub]({{< relref "../../community_resources/" >}}), please follow the [Working Group outputs process]({{< relref "./working-groups" >}}).
+
+---
+
+## Outstanding discussion & objections
+
+The above is the current live and used process. Any ongoing discussions about amendments to this process will be linked here!
\ No newline at end of file
diff --git a/content/about/governance/roles-and-membership.md b/content/about/governance/roles-and-membership.md
new file mode 100644
index 0000000..6d817e5
--- /dev/null
+++ b/content/about/governance/roles-and-membership.md
@@ -0,0 +1,59 @@
+---
+title: "Roles and membership"
+description: "The different roles and membership options for the community, both for individuals and organisations"
+draft: false
+tags:
+- governance
+---
+
+# Roles and Membership
+
+This document describes the different roles and responsibilities within the community.
+
+## Member
+
+Anyone is able to join the community by signing up for our [mailing list](https://www.jiscmail.ac.uk/cgi-bin/wa-jisc.exe?SUBED1=UK-TRE-COMM&A=1).
+
+All members commit to abide by our:
+- [Code of Conduct](https://github.com/uk-tre/.github/blob/main/CODE_OF_CONDUCT.md)
+- [Community Principles]({{< relref "./newcastle-commitment" >}})
+
+When you sign up for the mailing list, you will be contacted by a member of the [Community Management Working Group]({{< relref "../../groups/current/community_management" >}}) via email with the above documents.
+Additionally anyone will be able to request to be sent these documents via a form on the website.
+
+By joining the mailing list, you are agreeing to these documents.
+If you explicitly do not want to agree to these documents you can alert a member of the [Steering Group]({{< relref "./steering-group" >}}) with your decision.
+Subscribers of the mailing list that do not agree to these documents may remain subscribers and take part in all community events, but they will not be able to take part in community decisions.
+
+You will also be given the option to be added to a public list of our participating members on our [website]({{< relref "../people" >}}) - this is optional and up to you, though we’d love to add you to show how big our community is!
+
+To leave the community, you can simply unsubscribe from the mailing list. If you would like any additional action to be taken (for instance, having your name removed from the website), get in touch at [uktrecommunity@gmail.com](mailto:uktrecommunity@gmail.com)
+
+## Affiliated Organisation
+
+We’re always looking for organisations to be officially associated with the community!
+
+To become an affiliated organisation, please reach out to a member of the [Steering Group]({{< relref "./steering-group" >}}) or email us at [uktrecommunity@gmail.com](mailto:uktrecommunity@gmail.com).
+
+We ask affiliated organisations to agree to:
+- Abide by our [Code of Conduct]((https://github.com/uk-tre/.github/blob/main/CODE_OF_CONDUCT.md))
+- Abide by our [Community Principles]({{< relref "./newcastle-commitment" >}})
+- Send at least one representative to each of our [quarterly community meetings]({{< relref "./events-management" >}})
+- Have at least one representative participate in at least one [Working Group]({{< relref "../../groups/" >}})
+
+Affiliated organisations will be displayed on our [website](/), and invited to run sessions at our [quarterly community meetings]({{< relref "./events-management" >}}).
+
+Affiliated organisations can remove their affiliation upon written request to any member of the [Steering Group]({{< relref "./steering-group" >}}) or via email at [uktrecommunity@gmail.com](mailto:uktrecommunity@gmail.com).
+
+## Steering Group Member
+
+Please see the [Steering Group]({{< relref "./steering-group" >}}) page.
+
+## Working Group Lead
+Please see the [Working Group]({{< relref "./working-groups" >}}) page
+
+---
+
+## Outstanding discussion & objections
+
+The above is the current live and used process. Any ongoing discussions about amendments to this process will be linked here!
\ No newline at end of file
diff --git a/content/about/governance/steering-group.md b/content/about/governance/steering-group.md
new file mode 100644
index 0000000..f9809de
--- /dev/null
+++ b/content/about/governance/steering-group.md
@@ -0,0 +1,123 @@
+---
+title: "Steering Group"
+description: "The roles, responsibilities and decision making process within the community Steering Group"
+draft: false
+tags:
+- governance
+---
+
+# Steering Group
+
+For the UK TRE Community, the Steering Group is the body through which community decisions are ratified, transforming discussions into strategic direction and actionable initiatives.
+The group may offer advice, monitor progress, allocate resources, and address challenges to ensure successful outcomes and effective implementation of plans.
+
+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, the role of the Steering Group is crucial to ensure fair representation of ideas and perspectives.
+
+This document lays out the responsibilities of the Steering Group, as well as how members can join and leave their position.
+
+## Responsibilities
+
+### Official review
+
+The Steering Group is primarily responsible for using community feedback to make an official decision on community endeavours.
+
+This includes but is not limited to:
+- [Working Group outputs]({{< relref "./working-groups" >}})
+- [Governance document amendments]({{< relref "./governance-amendments" >}})
+- [Community events]({{< relref "./events-management" >}})
+- [Community resources]({{< relref "./resources" >}})
+- [Objections]({{< relref "./consensus-review-objection" >}})
+
+When performing their role, the Steering Group will predominantly meet online.
+The notes from the meeting will be made openly available, as will any decisions that are made.
+
+The Steering Group will make decisions based on Community Consensus by considering the existing discussion relating to an initiative, and [Community Principles]({{< relref "./newcastle-commitment" >}}).
+
+For details on how these decisions are made, please see the [Consensus, Review and Objection Management]({{< relref "./consensus-review-objection" >}}) process document.
+
+## Structure
+
+The Steering Group is made up of a minimum of 3 and maximum of 7 members of the community, and members within the Steering Group are referred to as co-chairs.
+
+The initial Steering Group has been set up with co-founders/early members of the community in order to get the community up and running.
+
+Formal election of Steering Group members take place during September - see details for the process below.
+
+Decisions within the Steering Group are made deliberatively, and, where required, by majority vote.
+
+### Current members
+
+All co-chairs of the Steering Group share equal status and decision making authority. They are listed below alphabetically by last name:
+
+- Madalyn Hardaker, KCL
+- Simon Li, Health Informatics Centre
+- David Sarmiento Perez, The Alan Turing Institute
+- Balint Stewart, DARE UK
+
+### Membership
+
+#### How to get elected
+
+Anyone wishing to be elected to the Steering Group must be a member of the UK TRE community.
+See the Membership and Roles document for more details.
+
+Members must submit their intention to run for a Steering Group position by the time of the September quarterly meeting.
+They can do this by contacting any current member of the Steering Group, or by writing to [uktrecommunity@gmail.com](mailto:uktrecommunity@gmail.com).
+
+At the September meeting, all members running for election are announced.
+At the meeting, they will give a short speech on why they should be elected.
+This meeting will be hybrid with candidates able to participate either in person or online.
+Speeches will be made available on GitHub and the UK TRE Community webpage.
+Candidates who cannot attend the meeting in-person can deliver their speech online, or ask another community member to give their speech for them by proxy.
+
+If there are less than 3 members running for the position, applications will remain open until at least 3 members are running.
+
+If there are between 3 and 7 members running, a vote will be taken on the day with the majority vote determining the outcome.
+
+Members can vote:
+- **For** the member joining the Steering Group
+- **Against** the member joining the Steering Group
+- **Abstain**
+
+If there are over 7 members running, vote will be taken by [Ranked-choice voting](https://ballotpedia.org/Ranked-choice_voting_(RCV)).
+This will be facilitated by the [Community Management Working Group]({{< relref "../../groups/current/community_management" >}}).
+This vote will take place on the day, with announcements made within 1 week of the vote being taken.
+
+Non-anonymised votes will be collected and processed by the [Community Management Working Group]({{< relref "../../groups/current/community_management" >}}), who will check the voting process followed our [Community Principles]({{< relref "./newcastle-commitment" >}}).
+Anonymised breakdowns of the votes will be published on the community website.
+
+Elected members will serve a term of 1 year, starting from October 1st each year.
+Current members may run for another term.
+
+As part of being elected, members will need to ensure they are available for up to 3 months after their term ends (up to January 1st) to answer questions and provide reasonable support to new chairs.
+
+#### How to step down
+
+If there are more than 3 co-chairs within the Steering Group, any member within the group can step down by formally writing to all other Steering Group members.
+Once confirmed, the [Community Management Working Group]({{< relref "../../groups/current/community_management" >}}) will communicate this with the rest of the community, and update relevant documents and references.
+
+If there are 3 or less members within the Steering Group, members of the Steering Group and the UK TRE Community will have to nominate potential replacements.
+Once the nomination(s) have been made, a vote will be held for the vacant position(s), asynchronously and online.
+The vote will be open for a period of 7 days.
+
+If the total members of the Steering Group including incumbent members and nominated replacements is less than 7, for each nominated member, members of the community can vote:
+- **For** the member joining the Steering Group
+- **Against** the member joining the Steering Group
+- **Abstain**
+
+With the majority vote determining the outcome.
+
+If the total is over 7, votes will be taken by Ranked-choice voting.
+
+The [Community Management Working Group]({{< relref "../../groups/current/community_management" >}}) will circulate results of the vote with the community.
+Successfully elected replacement members will start their term immediately, and this term will run until September 30th.
+
+---
+
+## Outstanding discussion & objections
+
+The above is the current live and used process. Any ongoing discussions about amendments to this process will be linked here!
+
+- [Encouraging members to not run indefinitely for the Steering Group](https://github.com/uk-tre/community-management/issues/90)
+- [Allowing chairs to pick additional chairs, if we have less than 3](https://github.com/uk-tre/community-management/issues/91)
+- [Process for how to remove a chair](https://github.com/uk-tre/community-management/issues/92)
\ No newline at end of file
diff --git a/content/about/governance/working-groups.md b/content/about/governance/working-groups.md
new file mode 100644
index 0000000..9d503a9
--- /dev/null
+++ b/content/about/governance/working-groups.md
@@ -0,0 +1,91 @@
+---
+title: "Working groups"
+description: "How to set up and run a Working Group, and how outputs are managed"
+draft: false
+tags:
+- governance
+---
+
+# Working groups
+
+For the UK TRE Community, a [Working Group (WG)]({{< relref "../../groups/" >}}) 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](https://join.slack.com/t/uktrecommunity/shared_invite/zt-26r7jz25d-J5iV0XoqyLepEiKk4XpJVg), [mailing list](https://www.jiscmail.ac.uk/cgi-bin/wa-jisc.exe?SUBED1=UK-TRE-COMM&A=1), website and newsletter
+- Dedicated presentation opportunities and breakout rooms at our quarterly meetings
+- Additional support from the [Community Management Working Group]({{< relref "../../groups/current/community_management" >}}) 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](https://docs.google.com/document/d/1yt4tdmxzXHV73sKZx8EcUsboA8UURYDCFgAdjyCXAUw/edit?usp=sharing).
+2. The Charter is reviewed by the [Community Management Working Group]({{< relref "../../groups/current/community_management" >}}) to ensure it:
+ - Aligns with [Community Principles]({{< relref "./newcastle-commitment" >}})
+ - Represents new work being undertaken in the community
+3. If the Charter is rejected by the [Community Management Working Group]({{< relref "../../groups/current/community_management" >}}), 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]({{< relref "../../groups/current/community_management" >}}), 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) for a period of at least 14 days.
+5. After the review period, the [Steering Group]({{< relref "./steering-group" >}}) will either formally reject or approve the WG creation, in line with the [Consensus, Review and Objection Management Process]({{< relref "./consensus-review-objection" >}}).
+6. If the WG is rejected, any outstanding objections requiring review are collated by the [Steering Group]({{< relref "./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]({{< relref "../../groups/current/community_management" >}})
+2. The draft outputs are reviewed by the [Community Management Working Group]({{< relref "../../groups/current/community_management" >}}) to ensure it:
+ - Aligns with [Community Principles]({{< relref "./newcastle-commitment" >}})
+3. If approved by the [Community Management Working Group]({{< relref "../../groups/current/community_management" >}}), the draft outputs are made available for community review via an Issue on the [UK TRE GitHub](https://github.com/uk-tre) 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]({{< relref "./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]({{< relref "./steering-group" >}}).
+
+#### Rejection
+
+The [Steering Group]({{< relref "./steering-group" >}}) rejects the draft outputs of the WG.
+
+The [Steering Group]({{< relref "./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]({{< relref "./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]({{< relref "./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]({{< relref "./steering-group" >}}), confirming its termination.
+2. The [Steering Group]({{< relref "./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](https://github.com/uk-tre/community-management/issues/95)
\ No newline at end of file
diff --git a/layouts/_default/governance/index.html b/layouts/_default/governance/index.html
new file mode 100644
index 0000000..e1578d9
--- /dev/null
+++ b/layouts/_default/governance/index.html
@@ -0,0 +1,32 @@
+{{ define "main" }}
+
+
+