Merge pull request #24 from uk-tre/17/governance-docs

Upload governance docs

content/about/governance/index.md → 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

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)

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!

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!