GDPR Policy
# Data retention
This policy defines how long personal information will be kept by Student Robotics.
This policy covers all personal information with a sensitive nature in the possession or control of Student Robotics, regardless of how the information is held.
This policy is subject to change, and will be superseded by any obligation of Student Robotics to comply with regulation, litigation, or law enforcement.
Data may persist in a backup for 1 additional year in all situations.
| Situation | What is stored | Duration | Justification |
| -------------------------------------- | ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Competitor contact information | Personal information | 6 years after final participation in Student Robotics | To understand who was involved in the event a concern is later reported. |
| Volunteer/Member contact information | Personal and sensitive information | 4 years after final participation in Student Robotics, or 6 years after an event they attended, whichever is longer. At the end of which the information will be reduced to name, date of birth/age, and Student Robotics e-mail address which will persist for 100 years from the record's creation date. | To understand who was involved in the event a concern is later reported.
Preservation of basic information is to enable easy re-integration in Student Robotics.
|
| Incident involving personal injury | Personal and sensitive information | 4 years after incident or 4 years after victim turns 18, whichever is later | Fight a case – Limitation act 1980 |
| Incident not involving personal injury | Personal information | 7 years after incident | Fight a case – Limitation act 1980 |
| Safeguarding incident - perpetrator | Personal and sensitive information | 100 years after case closure. In the event of the allegation being disproved, the record will be updated to state as such, and will be preserved for a further 1 year, or until 4 years after the event, whichever is later. | Required for providing evidence to relevant authorities. |
| Safeguarding incident - victim | Personal and sensitive information | 7 years after last communication with alleged victim or their family | Required for providing evidence to relevant authorities |
# Internal structure
The Student Robotics Competition Programme is the main activity of Student Robotics and is how it currently meets its charitable objective set out in its [constitution](https://github.com/srobo/ops-manual/tree/d76377192d4c94c4bd4298f0f3954f5d342af24b/resources/constitution.pdf). It consists of an annual programme, aligned with the academic year, where teams of 16-19 year-olds (generally in sixth form) take part in an reasonably open-ended engineering challenge to construct autonomous robots.
This section details the organisation of volunteer teams that deliver this programme.
The teams are as follows:
* [Competition team](/master/internal-structure/competition-team) responsible for the planning, management and delivery of the competition programme for a given annual cycle.
* [Fundraising team](/master/internal-structure/fundraising-team) responsible for seeking new sponsors and managing the relationship with sponsors.
* [Infrastructure team](/master/internal-structure/infrastructure-team) responsible for maintaining the software services that support the competition programme.
* [Kit team](/master/internal-structure/kit-team) responsible for developing the robotics kit and providing and supporting kits to allow teams to compete in the competition programme.
* [Marketing team](/master/internal-structure/marketing-team) responsible for promoting the organisation to attract new teams, sponsors and volunteers.
* [Volunteer onboarding team](https://github.com/srobo/ops-manual/blob/links_fixing/internal-structure/volunteer-onboarding-team.md) responsible for inducting and supporting new volunteers.
# Team structure and operation
Each team is a group of volunteers that work together to deliver the team's purpose.
Each team is led by a committee: a group of three people who are ultimately responsible for ensuring that the work of the team is carried out in the manner expected by the Trustees, coherent with the values of Student Robotics. Each committee is accountable to the Trustees and its responsibilities are defined in the list of [common responsibilities](/master/internal-structure/common-responsibilities).
Volunteers apply to join a team through its committee. Volunteers can apply to join a team at any time and the committee should not unreasonably restrict membership of the team.
The competition team and its committee operates on an 12-month cycle running from early July to the end of June the following year. All other committees operate on a 24-month cycle running from early July in year one to the end of June in year three. The process for formation and dissolution of committees is [explained here](/master/internal-structure/committee-formation).
## Team meetings and documentation
A committee is responsible for organising and running team meetings. These will be published in the SR Google calendar and should be open for any volunteer to attend. It is up to each committee to determine how minutes are taken, the format of the minutes, and where they are stored but this information must be shared with team members and should be accessible to all of the team. Key decisions must be recorded in the decision log which is shared across the organisation.
## Allocation of work
A committee is responsible for making sure that work is allocated fairly and that the workload of each team member is monitored. Volunteers must have the opportunity to say "no" to work that they feel unable to do and to alert the committee if they are struggling with their workload. The committee must do their best to make sure that the team has sufficient volunteers to carry out the work of the team.
## Budget and financial records
A budget will be made available to support the work of each team. One named member of each committee must act as the team treasurer and the responsibility for the budget will be delegated to this committee member. The team treasurer will be able to approve spending within the allocated budget and must ensure that all expenditure is authorised in advance of being incurred and that appropriate records are kept.
# Competition team
## Purpose
The Competition Team is responsible for defining and delivering the SR Competition Programme ('the competition programme') for a single competition cycle.
The competition programme includes, but is not limited to:
* Working with the [marketing team ](/master/internal-structure/marketing-team)to recruit teams from schools and colleges
* Determining a fair method for selecting teams if over subscribed
* Communicating with school/college team supervisors throughout
* Liaising with the [kit team](/master/internal-structure/kit-team) to agree the number of teams and number of locations that can be supported
* Devising a challenge
* Organising and running Kickstart
* Organising and running Tech days
* Organising and running the Competition final
* Training sufficient volunteers to support planned events
* Health and Safety and Safeguarding at events
* Gathering metrics throughout the competition cycle
[The way that the team is structured and operates](/master/internal-structure/team-operations) is consistent with all of the other SR teams.
# Fundraising team
## Purpose
The Fundraising and Sponsorship Team is responsible for securing funding for the current and future competition cycles.
This includes, but is not limited to:
* Identifying and reaching out to potential sponsors
* Maintaining a record of contacts and communications
* Managing the relationship with sponsors
* Ensuring all perks due to sponsors are supplied in a timely manner
* Working with the marketing team to review the effectiveness of sponsorship and fundraising material
* Working closely with the Trustees on all matters relating to sponsors
[The way that the team is structured and operates](/master/internal-structure/team-operations) is consistent with all of the other SR teams.
# Infrastructure team
## Purpose
The Infrastructure Team is responsible for providing and maintaining the computing infrastructure required for the other teams to operate.
This includes, but is not limited to:
* Setting up and maintaining servers to support SR operations including the deployment of the public facing web site
* Setting up and maintaining the organisation's domains (studentrobotics.org and srobo.org)
* Maintaining the security of the infrastructure and related services
* Setting up and maintaining the structure of GitHub organisations and permissions
* Setting up and maintaining G-Suite accounts for SR volunteers, teams and committees
* Providing support and guidance with regards to best-practices to other teams or volunteers on infrastructure and services where possible
* Maintaining a list of core services (i.e. services central to Student Robotics operation)
* Maintaining a list of team services (i.e. services maintained especially for and in collaboration with another team)
* Ensuring continuous/enduring access to SR services
The infrastructure team is **not** responsible for content beyond ensuring it does not break other functionality
[The way that the team is structured and operates](/master/internal-structure/team-operations) is consistent with all of the other SR teams.
# Kit team
## Purpose
The Kit Team is tasked with developing and maintaining the SR Kit, and to provide a Kit Service to enable the SR Competition Programme.
The Kit is defined as the hardware and software (including software services) that are provided to school teams to enable them to take part in the annual robotics competition.
The Kit Service includes, but is not limited to:
* Provision of sufficient working kit to meet the needs of the [Competition Team](/master/internal-structure/competition-team)
* Delivery of kit to event location(s) as agreed with Competition Team
* Checking kit out to teams at events
* Shipping kits to teams that cannot attend an event
* Collecting and holding disclaimer forms for kit issued
* Dealing with any kit problems and issuing replacement parts as needed throughout the competition cycle
* Providing technical documentation for competitors and for volunteers
* Providing technical support to competitors and volunteers (both remote and in-person at events)
* Recovering and checking kit following a competition cycle
* Dealing with requests for late return of kit
* Chasing any missing kit including kit not returned
* Storing the kit safely
* Maintaining an inventory of the kit
The team is also responsible for:
* Communicating a strategic vision for the kit
* Developing kit for future competitions
* Ensuring that kit is deployed only for the purposes of delivering the Student Robotics Competition Programme or as directed by the Trustees
[The way that the team is structured and operates](/master/internal-structure/team-operations) is consistent with all of the other SR teams.
# Marketing team
## Purpose
The marketing team are responsible for attracting new sponsors, competitor teams and volunteers. Their work includes, but is not limited to:
* managing website content
* making effective use of social media channels
* producing and procuring marketing materials
* managing SR brand assets
* writing the annual report
[The way that the team is structured and operates](/master/internal-structure/team-operations) is consistent with all of the other SR teams.
# Volunteer onboarding team
# Committee formation and dissolution
### Committee cycles
The **competition team** and its committee operates on an 12-month cycle running from the beginning of July to the end of June the following year. All **other committees** operate on a 24-month cycle running from the beginning of July in year one to the end of June two years later.
### Dissolution
At the end of the term of office, each committee is invited to meet with the Trustees to review the progress made. This serves as a useful event for both the committee, to reflect on their achievements, and the Trustees, to gather as much information as possible to feed into the new cycle. It is expected that the committee will get the views of the wider team before the meeting. After the review meeting, the team and its committee is stood down.
The dissolution of the team allows other volunteers a chance to stand for the committee. This is healthy for the organisation and ensures that it is not over-dependent on a small set of volunteers. There should be no expectation that committee members will be reappointed at the end of their term of office and nothing should be read into the fact that one or more members are not reappointed. The trustees will always take the long term view.
### Eligibility
All registered volunteers are invited to express an interest in a place on a committee. Committee members are selected from applicants who have relevant skills and experience. Preference is given to volunteers who have actively participated in the work of the relevant team.
### Registration of Interest
Approximately three weeks before the new committee is to be formed, eligible volunteers (including previous members of the committee) are invited to express an interest in being part of the next committee.
### Supporting information
The Trustees discuss their expectations for the coming cycle (based on feedback from the previous cycle) and decide on the direction in which they would like the work of the teams to be taken and where they would like the new committee to focus their efforts. For example, it may be the case that the Trustees would like to increase the number of kits available, expand the number of female participants, or they may want a focus on increasing volunteer engagement. This information is communicated to applicants who will be invited to provide additional information in support of their application.
### Formation
Each committee is formed, following a meeting of the Trustees. Prior to this, applications from all eligible applicants are carefully considered and meetings with individual applicants may be held. The Trustees select a set of volunteers that they feel are most able to take on the responsibilities of the committee and will work well together. The trustees will seek to give volunteers the opportunity to work in new areas and to acquire new skills so long as the stability of the organisation is maintained.
### Insufficient applications
The ideal size of a committee is three members. This allows a spread of responsibilities and for effective debate. If there are insufficient suitable applicants, the Trustees appoint a smaller committee and work with that committee to find suitable candidates for the unfilled position(s).
### Resignation of a committee member
If a committee member wishes to resign part-way through their term of office they email the Trustees. The Trustees work with the individual to see if there is any further help and support that they can provide to allow the volunteer to continue in their role. If there is no option for the individual to continue, the Trustees work with the rest of the committee to find a suitable candidate for the role.
# Common responsibilities
A committee is a group of three people who are ultimately responsible for ensuring that the work of the team is carried out in the manner expected by the Trustees, coherent with the values of Student Robotics. Each committee is accountable to the Trustees.
A committee will focus on management of time, resources and volunteers within the team. It will ensure the team has an appropriate balance of relevant skills and will provide support and guidance to team members to allow them to be as effective as possible in delivering the work of the team.
All committees have the following responsibilities:
* Organising and running team meetings
* Maintaining a log of decisions made
* Managing the work of the team
* Inter-team communications
* Reporting on progress to the Trustees
* Preparing and managing a budget for team expenditure
* Managing relationships within the team
* Ensuring projects are run in line with the values of SR
* Documenting processes/tools
* Managing and tracking assets
* Supporting the recruitment and induction of volunteers
* Raising any concerns with the Trustees
* Ensuring a clean handover to a new committee
## Organising and running team meetings
Each team should have regular meetings and the date and time of upcoming meetings must be added to the organisation calendar.
## Maintaining a log of decisions made
All important decisions made by the committee must be logged in a shared spreadsheet (stored in the organisation shared drive), listing the following details:
* Date
* Decision
* Reasoning
* Who was present
* Proportion of vote
## Managing the work of the team
Committees should should maintain a record of team members and work to understand the contribution that each member can make to the work of the team, taking into account the individual's experience, abilities and desired workload. They should make sure that work is allocated fairly and check that volunteers are not overloaded and can cope with their allocated tasks. Teams can be divided into smaller self-organising subgroups if this works for the team, but the committee must maintain overall responsibility.
## Inter-team communications
Committees are responsible for ensuring they communicate adequately with the other teams. Many teams will be reliant on the other teams for information to allow them to work effectively. Any break down in communications must be reported to the trustees.
## Reporting on progress to the trustees
Committees should ensure that their team is appropriately represented at the monthly meeting with the Trustees and provide an update on the work of the team (in the document that is surfaced ahead of the meeting).
## Preparing and managing a budget for team expenditure
Committees are responsible for drawing up a budget for the following year within the overall framework provided by the Trustees. The budget must be submitted to the Trustees for approval when requested. Committees must also follow the requirements defined in the [Money Matters](/master/about-the-charity/money-matters) section to play their part in the sound financial management of the organisation.
## Managing relationships within the team
Committees should work hard to build relationships and try to tackle any issues that may arise within the team. If any intractable issues arise, these must be reported to the trustees at the earliest opportunity.
## Ensuring projects are run in line with the values of SR
The mission statement articulates the values of SR and all projects, whatever size, must be be consistent with these values.
## Documenting processes/tools
Committees must ensure that their team maintains documentation on what it does and how it operates. This documentation must be available to all volunteers and must be held in a form that is accessible and easy to understand.
## Managing and tracking assets
SR is a small charity and our assets are of great value to the organisation. These assets include physical assets (e.g: kits) and digital ones (e.g: trademark, social media accounts, software licenses). Committees should make their best efforts to take care of their assets and to know the whereabouts of the assets that belong to, or are managed by, their team.
## Supporting the recruitment and induction of volunteers
All teams should take an active role in supporting the search for new volunteers and helping with their induction. Committees should make sure that volunteers who express and interest in joining their teams are made welcome and understand how to get involved with the work of the team.
## Raising any concerns with the Trustees
Committees are responsible for ensuring that any concerns raised within their team, or any issues observed within the wider organisation, are reported to the Trustees.
## Ensuring a clean handover to a new committee
Committees are responsible for ensuring a clean handover to a new committee at the end of their term of office.
# Miscellaneous
## Licensing
This work (the operations manual) is licensed under the [Creative Commons Attribution-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-sa/4.0/). The authors of this work are: Rich Barlow, Diane Dowling, Thomas Scarsbrook.
## Making Changes to this Document
The source of this document can be found here: . It is maintained by the Trustees of the charity. It is important to note that the information contained within the 'master' branch of the repository has not been released and therefore is not authoritative. New releases of the operations manual must be approved by the Trustees via one of the decision making procedures defined in clause 17 of the [constitution](https://github.com/srobo/ops-manual/tree/d76377192d4c94c4bd4298f0f3954f5d342af24b/resources/constitution.pdf).
Releases of the operations manual are denoted with both a tag and branch of the form 'v#', where # is a number. The latest release is the one with the largest number and will be set as the GitBook 'primary' version. The requirement for a branch as well as a tag with the same name is an unfortunate requirement of how the GitBook platform operates; if a tag and branch of the same name ever differ in terms of the commit that they refer to, the tag takes precedence (if you happen to notice an anomaly of this form, please inform the [trustees](mailto:trustees@studentrobotics.org)).
To make a release of this document the following steps must be taken:
1. Ensure that the [Change Log](/master/miscellaneous/change-log) is up to date with all modifications made since the previous release.
2. Ensure that the Trustees have approved the release of the new version and it has been recorded in the Trustees' decisions.
3. Set the version number and date for the new version in the Change Log.
4. Create a new version via the GitBook editing interface. This version must have a human-readable name of the form 'Version #' and a 'path' of 'v#' (the 'path' setting in the GitBook interface is what becomes the branch name in the git repository).
5. Set the newly created version as the primary version, such that it is the version presented to a reader when visiting .
6. Create a tag with the same name as the branch just created. This tag must point to the same commit as the current head of the branch. The tag can be created either using the normal git CLI tools or the GitHub web interface.
# Release versioning
The Operations Manual attempts to follow Semantic Versioning 2.0.0 (). Since Semantic Versioning is designed for use with code, it is necessary to clarify what is considered the 'public API' and is helpful to give some examples of changes that will result in the major, minor or patch fields are incremented.
## The Operations Manual Public API
The Operations Manual is the means for the Trustees to define what Student Robotics is, what it stands for and how it operates. There are, in effect, two parts to the 'public API' of the Operations Manual:
* The organisation's interface to the world (the definition of what SR is and what it stands for)
* The Trustee's interface to the rest of the organisation (the structure within the organisation and the interface between those structures and the Trustees)
## Examples of Changes
### Major (X.y.z) Version Increment
* Adding a new organisation value
* Renaming the Core Team to the Competition Programme Committee and redefining its size and scope
* Reducing the period of the Core Team/Competition Programme Committee to 10 months
* Changing the procedure for a team/committee to report to the Trustees
* Re-writing the safeguarding policy such that all Student Robotics volunteers must re-read and understand it
### Minor (x.Y.z) Version Increment
* Adding a new team/committee (e.g. Kit Team)
* Changing the process for releasing a new version of the Operations Manual
* A Trustee changes (added or removed)
* Clarifying wording of things
### Patch (x.y.Z) Version Increment
* Fixing a typo that doesn't change the intended meaning
* Formatting changes
# Change log
All notable changes to the Operations Manual will be documented on this page.
The format is based on [Keep a Changelog v1.0.0](https://keepachangelog.com/en/1.0.0/), and this project adheres to [Semantic Versioning v2.0.0](https://semver.org/spec/v2.0.0.html) (see the [Release Versioning](/master/miscellaneous/release-versioning) page for details of what this means).
Each release of the Operations Manual has an entry on this page. Within this entry changes are broken down into 'Added', 'Changed', 'Removed' and 'Minor Fix'. The first three categories cover modifications that affect the function of the document, whereas the last one includes modifications that do not, for example corrections to typos and formatting. Each entry also includes the date on which it took effect.
## Version 9.0.1 (2023-10-25)
### Changed
* Add the GDPR pages to the summary
## Version 9.0.0 (2023-10-10)
### Added
* Governance page
* Volunteer onboarding team
* Team organisation and structure page
* GDPR policy
### Changed
* Small tweaks to safeguarding
* Moved information about Trustees and Members to new governance page
* Simplified all team pages to link to new team organisation and structure page
* Updated all team pages to reflect current responsibilities
* Updated committee formation and dissolution page to reflect current practice
* Updated money matters page to reflect current practice
* Updated volunteers page to add volunteers must be 18+ and updated information held to reflect current practice
* Updated table of contents with new pages
## Version 8.0.0 (2022-03-01)
## Version 7.0.0 (2021-12-12)
### Added
* Infrastructure Team
* Marketing Team
* Fundraising Team
* Team common responsibilities
### Changed
* Details of Trustees
* Teams overview
## Version 6.1.0 (2019-09-19)
### Added
* [Kit Team](https://github.com/srobo/ops-manual/blob/links_fixing/annual-robotics-competition/kit-team.md) page
### Changed
* Details of Trustees
* Name of Competition Programme Team to Competition Team
* Updated layout and headings on Competition Team pages to align with Kit Team pages
* Removed FAQs from Competition Team pages
* Changed other pages to reflect the fact that there are now two key Teams
* Removed 'emergency contact details' from data stored about volunteers
* Recorded use of GSuite to manage organisation
## Version 6.0.0 (2019-06-25)
### Added
* [Release Versioning page](/master/miscellaneous/release-versioning) that specifies that the Operations Manual follows Semantic Versioning v.2.0.0 from now on
* Note to [Change Log page](/master/miscellaneous/change-log) that clarifies its adherence to Keep a Changelog v1.0.0
### Changed
* Latest hosted version is now available at
* Use British English spelling 'programme' for the Competition Programme
* Rename 'Core Team' to Competition Programme Committee
* Rewrite the old 'Core Team' page to 'Competition Programme Team' and rewrite the majority of its contents to describe the new structure
## Version 5 (2018-11-29)
### **Added**
* Paragraph referencing code of conduct for volunteers
### **Removed**
* Paragraph explicitly restricting volunteers meeting or contact young people
## Version 4 (2018-08-30)
### Added
* Change Log page to document modifications between releases.
* Instructions in the [Making Changes](/master/miscellaneous#making-changes-to-this-document) section to ensure that the Trustees have approved the release of a new Operations Manual, the decision to release is recorded, the Change Log is updated with the modifications made and the new version number and date of release is entered into the Change Log.
* Clarification to [Safeguarding](https://github.com/srobo/ops-manual/blob/links_fixing/about-the-charity/safeguarding.md) that it is only young people who are participating in Student Robotics activities that volunteers must not meet outside of the supervised environment.
* Examples of who 'those who participate in our community' are in [Purpose](/master/about-the-charity/code-of-conduct#1-purpose) section of Code of Conduct.
* Instructions to [Reporting Guidelines](/master/about-the-charity/code-of-conduct#6-reporting-guidelines) in Code of Conduct detailing what information to include in a report, how the report is handled and how corner cases, such as the person being accused being one of the people who normally deals with reports, are dealt with.
* Clarification to [Core Team's Expectations of the Trustees](https://github.com/srobo/ops-manual/tree/d9e76a35317e628b18897f068a9332d47488e80d/annual-robotics-competition/core-team.md#core-teams-expectations-of-the-trustees) number 6 that only Trustees have direct access to volunteer dataset and that the Core Team will have to work with the Trustees to make use of it.
* Clarification to [Budgeting Requirements](https://github.com/srobo/ops-manual/blob/links_fixing/annual-robotics-competition/money-matters.md#budgeting-requirements) number 5 to remove ambiguity around what the '£1000' is referring to.
### Changed
* Only store geographical region, instead of full postal address, in [volunteer register](https://github.com/srobo/ops-manual/blob/links_fixing/annual-robotics-competition/volunteers.md).
* Soften 'expected' to 'will ideally' in Core Team [Defining Features](https://github.com/srobo/ops-manual/tree/d9e76a35317e628b18897f068a9332d47488e80d/annual-robotics-competition/core-team.md#defining-features) section.
* Make Core Team [Defining Feature](https://github.com/srobo/ops-manual/tree/d9e76a35317e628b18897f068a9332d47488e80d/annual-robotics-competition/core-team.md#defining-features) number 2 more all-encompassing.
* Shift dates of Core Team convening and disbanding one month earlier in the year (now convene in June and disband in May). This is to better align with the school year.
* Expect Core Team to run a Competition Program, rather than an explicit annual robotics competition, in [Trustees' Expectations of the Core Team](https://github.com/srobo/ops-manual/tree/d9e76a35317e628b18897f068a9332d47488e80d/annual-robotics-competition/core-team.md#trustees-expectations-of-the-core-team) number 4.
### Removed
* Pre-selection of 10 people to invite to the meeting to form the Core Team in the [Core Team Formation](https://github.com/srobo/ops-manual/tree/d9e76a35317e628b18897f068a9332d47488e80d/annual-robotics-competition/core-team.md#formation) section.
* Sentence explaining why more than eight people are invited to the meeting to form the Core Team in the [Core Team Formation](https://github.com/srobo/ops-manual/tree/d9e76a35317e628b18897f068a9332d47488e80d/annual-robotics-competition/core-team.md#formation) section.
* Explicit list of volunteer details recorded from [Core Team's Expectations of the Trustees](https://github.com/srobo/ops-manual/tree/d9e76a35317e628b18897f068a9332d47488e80d/annual-robotics-competition/core-team.md#core-teams-expectations-of-the-trustees) number 6. (This information is already defined on the [Volunteers](https://github.com/srobo/ops-manual/blob/links_fixing/annual-robotics-competition/volunteers.md) page).
* Reference to not giving refunds to paid events from [Consequences of Unacceptable Behaviour](/master/about-the-charity/code-of-conduct#5-consequences-of-unacceptable-behaviour) section of Code of Conduct. We don't run paid events, so it isn't relevant.
### Minor Fix
* Make release procedure in [Making Changes to this Document](/master/miscellaneous#making-changes-to-this-document) section into a numbered list.
* Make points under [Trustees' Expectations of the Core Team](https://github.com/srobo/ops-manual/tree/d9e76a35317e628b18897f068a9332d47488e80d/annual-robotics-competition/core-team.md#trustees-expectations-of-the-core-team) number 8 (be self-organising) into a numbered list.
* Expand 'SR' into 'Student Robotics' in [Safeguarding](https://github.com/srobo/ops-manual/blob/links_fixing/about-the-charity/safeguarding.md).
* Reference Trustees' email address in a more readable manner in [Safeguarding](https://github.com/srobo/ops-manual/blob/links_fixing/about-the-charity/safeguarding.md) and [Code of Conduct](/master/about-the-charity/code-of-conduct).
## Version 3 (2018-07-09)
The whole Operations Manual has been completely rewritten and bears little resemblance to Version 2, therefore it would not be sensible to try and enumerate all of the changes. Version 3 effectively represents a completely new direction for the Operations Manual and should be viewed as a completely new work.
# Introduction
This manual serves as the primary means for the Student Robotics Trustees to define what Student Robotics is, what it stands for and how it operates. It is not intended as a detailed prescriptive manual of how each activity within the organisation is carried out, but rather as a means to set the foundations upon which the organisation is built.
The latest version is always available to read at . The source of this document is available at . Please note that information contained on the 'master' branch of the repository (the 'In Development' version of the GitBook) has not yet been released and is therefore not authoritative.
# About the Charity
Student Robotics is a charity, registered on 18th August 2015 in England and Wales, with registration number 1163168. The charity is an association charitable incorporated organisation (CIO), with a [constitution](https://github.com/srobo/ops-manual/tree/d76377192d4c94c4bd4298f0f3954f5d342af24b/resources/constitution.pdf) as its governing document. It is headed by the Trustees who share ultimate responsibility for governing the charity and directing how it is managed and run. The Trustees can always be contacted via email at the following address: .
## Meet the Trustees
### David Massey
David is a retired teacher from Hills Road Sixth Form College, teaching physics and electronics A-level. He has been involved in sixth form robotics competitions since 2001 and has taken part in Student Robotics since 2012. He became a Trustee in January 2018.
### Diane Dowling
Diane works for the Raspberry Pi Foundation. She was previously Head of Computer Science at a Collyer's Sixth Form College in Horsham and has been involved in Student Robotics as a team Leader since 2013. Diane became a Trustee in January 2018.
### Thomas Scarsbrook
Thomas, more commonly known as "Scarzy", is an electronics consultant based in Surrey. He started volunteering for Student Robotics when he joined Southampton Uni in 2009, and became a trustee in November 2020.
## Postal Address
The postal address of Student Robotics is shown below. All Trustees have access to mail sent to this address, access is through a web platform.
```
Student Robotics
Lytchett House
13 Freeland Park
Wareham Road
Lytchett Matravers
Poole
Dorset
BH16 6FA
```
# Vision, Mission and Values
## Our Vision
We want to foster a world where engineering and artificial intelligence is accessible to young people.
## Our Mission
To bring the excitement of engineering and the challenge of coding to young people through robotics.
## Our Values
### Accessible
Engineering is for everyone. We believe that anyone should have the opportunity to build and program robots and we are committed to maintaining a diverse set of teams and volunteers. We do not expect participants to be skilled robot builders; we will provide challenges for all abilities and participants will never need any prior experience. We will never charge young people to enter the events that we run.
### Autonomous
Remote control sucks. Programming is everywhere in modern engineering and we want everyone to to be able drive the future. AI is where it’s at and should be at the heart of a robot’s design.
### Open by Default
Sharing is good. Running Student Robotics in the open makes us more resilient, more accessible and more exciting. Unless there is a very good reason not to, all software is open source, all conversations are open, and all documents are public.
### Encourage Creativity
Real life is limitless and so are we (almost!) Engineering in the real world is all about solving problems in new and novel ways. We want to encourage creative and ingenious solutions to problems, so we strive to keep constraints to a minimum.
### Reflect Reality
Engineering is everywhere. There are millions of engineers working in thousands of teams across hundreds of disciplines world-wide solving ever more complex problems. We present a challenge that aims to mirror this and expose people to a broad spectrum of engineering and computer science. Teamwork and communication is key.
# Volunteers
## Volunteers
Student Robotics would not be able to deliver on its mission without its volunteers. They invest vast quantities of time and effort to make Student Robotics the success that it is. Within Student Robotics a volunteer is defined as an individual who has registered as such.
The register of volunteers is maintained, by the Trustees, on the Google GSuite organisation for Student Robotics and reviewed every 18 months. If a volunteer indicates that they are no longer interested in being a volunteer when the register is reviewed, or does not respond during the review, their personal account will be suspended and, after 3 months, deleted. The following information, as a minimum, is recorded for each volunteer:
* Name (first name and surname)
* Email (alternative email to that issued by SR)
* Mobile Phone Number
* Geographical Location (i.e. City/Town)
Each volunteer is required to abide by the [code of conduct ](/version-8.0.0/about-the-charity/code-of-conduct)and to observe [safe guarding policy](https://github.com/srobo/ops-manual/blob/safeguarding/about-the-charity/safeguarding.md).
## Members
Volunteers may choose to become a "Member" of the charity. This has no impact on their ability to volunteer for Student Robotics, but creates an opportunity for them to have more of a say in the general running of the charity. The role of a member is defined in the [constitution](https://github.com/srobo/ops-manual/blob/safeguarding/resources/constitution.pdf). Members must be approved by the trustees.
If a volunteer wishes to become a member of the charity, they should e-mail the trustees with the following details:
* Name (first name and surname)
* Email (alternative email to that issued by SR)
* Home address
## Trustees
All volunteers are overseen by the Trustees. The role of the trustees is defined in the [constitution](https://github.com/srobo/ops-manual/blob/safeguarding/resources/constitution.pdf).
# Code of Conduct
## Code of Conduct
### 1. Purpose
A primary goal of Student Robotics is to be inclusive to the largest number of contributors, with the most varied and diverse backgrounds possible. As such, we are committed to providing a friendly, safe and welcoming environment for all, regardless of gender, sexual orientation, ability, ethnicity, socioeconomic status, and religion (or lack thereof).
This code of conduct outlines our expectations for all those who participate in our community, including, but not limited to, volunteers, competitors and team leaders. It further outlines the consequences for unacceptable behaviour.
We invite all those who participate in Student Robotics to help us create safe and positive experiences for everyone.
### 2. Open Source Citizenship
A supplemental goal of this Code of Conduct is to increase open source citizenship by encouraging participants to recognize and strengthen the relationships between our actions and their effects on our community.
Communities mirror the societies in which they exist and positive action is essential to counteract the many forms of inequality and abuses of power that exist in society.
If you see someone who is making an extra effort to ensure our community is welcoming, friendly, and encourages all participants to contribute to the fullest extent, we want to know.
### 3. Expected Behaviour
The following behaviours are expected and requested of all community members:
* Participate in an authentic and active way. In doing so, you contribute to the health and longevity of this community.
* Exercise consideration and respect in your speech and actions.
* Attempt collaboration before conflict.
* Refrain from demeaning, discriminatory, or harassing behaviour and speech.
* Be mindful of your surroundings and of your fellow participants. Alert community leaders if you notice a dangerous situation, someone in distress, or violations of this Code of Conduct, even if they seem inconsequential.
* Remember that community event venues may be shared with members of the public; please be respectful to all patrons of these locations.
### 4. Unacceptable Behaviour
The following behaviours are considered harassment and are unacceptable within our community:
* Violence, threats of violence or violent language directed against another person.
* Sexist, racist, homophobic, transphobic, ableist or otherwise discriminatory jokes and language.
* Posting or displaying sexually explicit or violent material.
* Posting or threatening to post other people’s personally identifying information ("doxing").
* Personal insults, particularly those related to gender, sexual orientation, race, religion, or disability.
* Inappropriate photography or recording.
* Inappropriate physical contact. You should have someone’s consent before touching them.
* Unwelcome sexual attention. This includes, sexualized comments or jokes; inappropriate touching, groping, and unwelcomed sexual advances.
* Deliberate intimidation, stalking or following (online or in person).
* Advocating for, or encouraging, any of the above behaviour.
* Sustained disruption of community events, including talks and presentations.
### 5. Consequences of Unacceptable Behaviour
Unacceptable behaviour from any community member, including sponsors and those with decision-making authority, will not be tolerated.
Anyone asked to stop unacceptable behaviour is expected to comply immediately.
If a community member engages in unacceptable behaviour, the community organizers may take any action they deem appropriate, up to and including a temporary ban or permanent expulsion from the community without warning.
### 6. Reporting Guidelines
If you are subject to or witness unacceptable behaviour, or have any other concerns, please notify a community organizer as soon as possible via . All reports will be handled with discretion. In your report please include:
* Your contact information.
* Names (real, nicknames, or pseudonyms) of any individuals involved. If there are additional witnesses, please include them as well. Your account of what occurred, and if you believe the incident is ongoing. If there is a publicly available record (e.g. a mailing list archive, public IRC logger or GitHub discussion), please include a link.
* Any additional information that may be helpful.
After filing a report, a representative will contact you personally, review the incident, follow up with any additional questions, and make a decision as to how to respond. If the person who is harassing you is part of the response team, they will recuse themselves from handling your incident. If the complaint originates from a member of the response team, it will be handled by a different member of the response team. We will respect confidentiality requests for the purpose of protecting victims of abuse.
Additionally, community organizers are available to help community members engage with local law enforcement or to otherwise help those experiencing unacceptable behaviour feel safe. In the context of in-person events, organizers will also provide escorts as desired by the person experiencing distress.
### 7. Addressing Grievances
If you feel you have been falsely or unfairly accused of violating this Code of Conduct, you should notify the Student Robotics Trustees with a concise description of your grievance. Your grievance will be handled in accordance with our existing governing policies.
### 8. Scope
We expect all community participants (contributors, paid or otherwise; sponsors; and other guests) to abide by this Code of Conduct in all community venues–online and in-person–as well as in all one-on-one communications pertaining to community business.
This code of conduct and its related procedures also applies to unacceptable behaviour occurring outside the scope of community activities when such behaviour has the potential to adversely affect the safety and well-being of community members.
### 9. Contact info
### 10. License and attribution
This Code of Conduct is distributed under a [Creative Commons Attribution-ShareAlike license](http://creativecommons.org/licenses/by-sa/3.0/).
Portions of text derived from the [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Geek Feminism Anti-Harassment Policy](http://geekfeminism.wikia.com/wiki/Conference_anti-harassment/Policy).
Retrieved on November 22, 2016 from
# Safeguarding
## Introduction
Safeguarding means protecting children and vulnerable adults from abuse and maltreatment and taking action to enable all children and vulnerable adults to have the best outcomes.
Student Robotics takes safeguarding very seriously. Everyone who volunteers with Student Robotics has a responsibility for the welfare of the young people who participate in our events. Most of these young people are below the age of 18, so are children in the eyes of the law. Competitors over the age of 18 may still need safeguarding, for example, a competitor may have a learning disability which would classify them as a vulnerable young adult. For consistency, all competitors should be categorised as children for the context of safeguarding. It is important that every young person has the opportunity to participate in competitions and other events in an environment where they feel safe.
It is a requirement that all young people that a Student Robotics volunteer is working with must be supervised by a responsible adult; this will either be a parent or a teacher who will have overall responsibility for that young person. However, we must also put in place procedures to ensure that any safeguarding concerns are identified and dealt with. This policy lays down the procedures that must be followed to protect the young people we work with.
## Key Points
* All volunteers must read and understand this policy
* Student Robotics will appoint a safeguarding lead with overall responsibility for safeguarding
* All in-person events will have a designated Safeguarding Officer in attendance at the event
* All safeguarding concerns must be reported to the designated Safeguarding Officer or Safeguarding Lead
* All volunteers must undertake basic safeguarding training on a recurring basis
* Volunteers must avoid being in 1-to-1 situations with young people, including contact online via e-mail, social media, etc.
* Volunteers must act within appropriate boundaries, even in difficult situations.
* If a volunteer is in an existing relationship with a competitor this must be flagged up to the safeguarding lead
## Safeguarding Lead
One of the trustees is designated as safeguarding lead and has overall responsibility for safeguarding. The Safeguarding Lead is responsible for:
* Making sure that the safeguarding policy is up to date
* Making sure that all volunteers receive basic training
* Making sure that all volunteers understand how to report safeguarding concerns
* Making sure that every event has a named Safeguarding Officer
* Dealing with safeguarding concerns
* Maintaining records of any safeguarding issues
* Notifying the relevant external agencies about any relevant safeguarding issues
The current Safeguarding Lead is: Thomas Scarsbrook ("Scarzy") They can be contacted at:
## Safeguarding Officers
A Safeguarding Officer will be appointed for every event. The Safeguarding Officer is responsible for:
* Receiving additional training on how to handle safeguarding concerns
* Being present at their designated event to provide onsite safeguarding support
* Dealing with safeguarding concerns at the event
* Reporting all safeguarding concerns for the event
If the event runs at multiple locations then a different safeguarding officer will be appointed for each location. All locations will be provided with a list of contact details for the Safeguarding Lead and all current Safeguarding Officers. In the event that the appointed Safeguarding Officer is unable to handle an issue these details can be used to seek additional support.
If the event occurs at a single location or across multiple days then a standby Safeguarding Officer will be appointed to pick up responsibilities if the primary officer is unavailable.
## 1-to-1 situations
A 1-to-1 situation is one where a volunteer is alone with a young person. These situations should be avoided, both for the protection of the young person and also to protect the volunteer, should an action be misinterpreted or an allegation made. If a volunteer finds themselves in an unexpected 1-to-1 situation, they should always immediately request the company of another responsible adult and report the situation to the designated Safeguarding Officer or to the Safeguarding Lead.
## On-line forums, messaging services and social media
It is important that all on-line communications between volunteers and young people are carried out over official Student Robotics channels that are open to everyone in the organisation. Private communication channels are not to be used. Responsibility for ensuring that communications are appropriate and good-spirited is the responsibility of all volunteers. Any inappropriate language or behaviour must be challenged immediately and any concerns must be reported as a safeguarding issue (and will be dealt with by the Safeguarding Lead).
## Relationships
Personal relationships between volunteers and young people are not appropriate, either as a friendship or a partner. Even if everyone is of a sufficiently legal age, the fact volunteers are in a position of trust makes them inappropriate.
Many of our volunteers are young and it is possible that they may be in an existing relationship with a young person who participates in one of our events. If a volunteer is in this situation, they must alert the Safeguarding Lead, and specific guidance on appropriate conduct will be given. In all instances, we would expect the volunteer to avoid 1-to-1 contact with the young person during the course of an event and for there to be no personal communication using official communication channels.
## Safeguarding incidents
It is impossible to list all possible incidents. Safeguarding training will cover situations that may arise such as:
* Young people arriving at an event without a responsible adult
* Inappropriate contact between an adult and a young person
* Bullying or harassment of young people
## Disclosure
This occurs when a young person tells a volunteer something that is of concern. This is an unlikely situation, but it could happen.
Safeguarding training will cover the “do’s and dont’s” of dealing with discloures. The key points are:
* Allow them to speak without interruption
* Don’t prompt or ask leading questions; listen carefully and ask for clarification if things are unclear
* Accept what is said, be understanding and reassuring. Do not give your opinion
* Afterwards write down what you have been told, using the exact words if possible including the date, time, place and people present
* Don’t promise to keep anything secret - you must tell the young person that you will need to pass the information on to the Safeguarding Lead
* If there is immediate danger seek help from the designated Safeguarding Officer, the Safeguarding Lead, or the emergency services
## Reporting incidents
All safeguarding incidents and concerns must be reported as soon as possible to the designated Safeguarding Officer at an event or to the Safeguarding Lead. If the concern relates to the Safeguarding Lead, it should be reported to the other trustees.
Reports must be made on the official Student Robotics safeguarding incident form which will ask for the following information:
* Your contact details
* Names (real, nicknames, or pseudonyms) of any individuals involved. If there are additional witnesses, please include them as well.
* Your account of what happened, and if you believe the incident is ongoing.
* Any available record of what occurred.
* Any additional information that may be helpful.
Details should be as accurate as possible, word for word if possible.
Should a concern need immediate attention, it must be raised in person with the designated Safeguarding Officer, the Safeguarding Lead, or by alerting the trustees. If you are unable to get hold of someone, you should seek advice from a team-leader who should be trained in safeguarding procedures, or in extremis; the emergency services.
## Protecting volunteers/young people
The safety of all involved in Student Robotics events is of prime importance to Student Robotics. As such, Student Robotics will always act to support anyone involved in a safeguarding incident, be it the young people involved, the person who reported the concern, or the volunteer involved.
# DBS
Disclosure and Barring Service (DBS) checks, formerly known as CRB checks, are where a person's records are checked to identify past criminal activity, which may present issues for another role. DBS checks are a vital part of the safeguarding process.
## Types of check
There are various levels of DBS check, and different roles may require different levels of check. For most roles within Student Robotics, a DBS check is not required. However volunteers in roles with greater exposure to young people may be required to undergo a DBS check. Volunteers will be notified by the Safeguarding Lead if a role they are undertaking requires a DBS check.
## DBS Checks from other roles
If you have a DBS check for another organisation, it may or may not be possible to consider it for use with Student Robotics. Please contact the Safeguarding Lead to see if this applies.
# Money Matters
A crucial aspect of running a charity is good money management. The Trustees are ultimately responsible for fund raising and deciding how the charity spends its money. The financial year starts on 1 August and the Trustees draw up an annual budget to allow the charity to fulfil its charitable purpose(s). One of the Trustees acts in the role of treasurer to the charity and maintains the definitive financial records which are submitted to external accountants at year end to prepare the statement for the annual report.
The task of detailed budgeting for each team's activities is delegated to their committees. The Trustees impart a great degree of financial freedom to committees and, in exchange, the committees take responsibility for ensuring that money is well managed. Each committee must have a named person to act in the role of team treasurer. To help minimise risk for everyone involved, certain requirements are placed upon the committees, related to money, and these are detailed below.
## Budgeting Requirements - Committees
1. Each committee must draw up a budget for the programme that they are looking to deliver and seek approval for the budget from the Trustees.
2. The Trustees must approve a budget before any spending is committed or incurred.
3. The budget(s) must not be publicly available. This is to avoid suppliers being able to know exactly how much the charity has to spend on a given service/product.
4. All spending must be made within the most recently approved budget. It is the responsibility of each team treasurer to liaise with the Trustees to get a budget approved and to gain approval for any modifications to a previously approved budget.
5. The Trustees must approve any reallocation of funds between budget lines where the amount being reallocated is greater than £1000. The committees are free to reallocate funds between budget lines below this threshold.
6. The budget maintained by the committees must include, as a minimum, the following information for each budget line.
* Short name
* Description (ideally with some information as to how the amount was determined)
* Amount
7. It is advised that a 10% contingency is allocated to each budget line to allow for unforeseen changes in cost.
8. Each committee must define and operate a system of authorising spends against lines in an approved budget. Volunteers must never spend their own money expecting reimbursement without explicit prior agreement from the team treasurer.
9. Only the Trustees have access to the SR bank account. Therefore, all reimbursement claims must go via the Trustees. It is the responsibility of each team treasurer to ensure that evidence of purchase/expenditure (receipt/invoice) and a record of the spend against specific budget line(s) is recorded for each transaction. This information must not be made public for the same reason as the budget not being made public (it is also likely to include personal information such as addresses). The Trustees may request access to this information at any time.
# Robotics Competition
The Student Robotics Competition Programme is the main activity of Student Robotics and is how it currently meets its charitable objective set out in its [constitution](https://github.com/srobo/ops-manual/tree/d76377192d4c94c4bd4298f0f3954f5d342af24b/resources/constitution.pdf). It consists of an annual programme, aligned with the academic year, where teams of 16-19 year-olds (generally in sixth form) take part in an reasonably open-ended engineering challenge to construct autonomous robots.
The teams are divided into 2 categories:
* Events
* Services
“Events” teams are responsible for stuff that directly impacts the current competition cycle. Their term of office is 11 months to cover a competition year.
“Services” teams are responsible for stuff that either entirely or largely spans multiple competition cycles. Their term of office lasts for 24 months.
This division of teams is to aid understanding of remits of the different teams.
The principle teams are as follows:
Events teams:
* [Competition team](/version-8.0.0/annual-robotics-competition/competition-team)
* [Marketing team](https://github.com/srobo/ops-manual/blob/safeguarding/annual-robotics-competition/marketing-team.md)
Services teams:
* [Kit team](/version-8.0.0/annual-robotics-competition/kit-team)
* [Infrastructure team](https://github.com/srobo/ops-manual/blob/safeguarding/annual-robotics-competition/infrastructure-team.md)
* [Fundraising team](https://github.com/srobo/ops-manual/blob/safeguarding/annual-robotics-competition/fundraising-team.md)
The planning, management and delivery of the competition programme is the remit of the Competition Team and it is up to the Competition Team Committee to define the programme for a given annual cycle.
A competition programme requires teams to participate and volunteers to help run it, it is the responsibility of the Marketing team to source these teams and volunteers.
Delivery of the competition programme isn't possible without a kit to run the competition around, providing this kit is the responsibility of the Kit Team.
SR uses a number of software services to provide the competition programme, for example the website servers, SR accounts, and GitHub. The Infrastructure Team is responsible for maintaining these.
All the teams require funding to operate, it is the responsibility of the Fundraising Team to source funding to support the other teams.
# Common Responsibilites
All teams have the following responsibilites:
* Supporting the recruitment of volunteers for across the organisation
* Budgeting
* Ensuring adequate communication with the other teams
* Documenting their processes/tools
* Raising any concerns to the trustees
* Maintaining decision log from meetings
* Seeking guidance from the trustees
* Reporting to the trustees on progress
* Ensuring a clean handover with future committees
## Recruiting volunteers
SR wouldn't exist without its volunteers. All teams should take an active role in supporting the search for and induction of new volunteers.
## Budgetting
The team committee is responsible for drawing up a budget for the following year within the overall budget provided by the Trustees. They must submit the budget to the Trustees within two months of the formation of the committee. This budget does not need to be extremely detailed; 8-10 budget lines is expected. They must also do the following:
* Keep financial records (in a form to be agreed with the trustees).
* Submit final accounts (at the end of the competition cycle).
* Understand and follow the requirements defined in the Money Matters section (this defines how budgeting works in more detail).
## Inter-team communication
The committee is responsible for ensuring they communicate adequately with the other teams. Many teams will be reliant on the other teams for information about what is required, or what can be provided.
## Documenting processes/tools
The team must maintain documentation on what it does and how it operates. This documentation must be available to all in SR.
## Raising concerns to the Trustees
The committee is responsible for ensuring that any concerns raised within their team are raised to the Trustees. If a concern can be handled within the team then a brief summary will suffice, anything that cannot be resolved within the team must be raised to the Trustees ASAP.
## Maintaining a decision log
All important decisions made by the team should be logged in a document, listing the following details:
* Date
* Decision
* Reasoning
* Who was present
* Proportion of vote
This document is stored in the organisation shared drive.
## Seeking guidance from the Trustees
The team committee is responsible for seeking guidance from the Trustees as to the direction they should take for the coming year.
## Reporting to Trustees
The team committee is responsible for ensuring that the committee provides regular updates to the Trustees to keep them in-the-loop with the progress of delivering the competition programme. This is accomplished by arranging for online (Google Hangouts/Meet) calls at least once every month.
## Handover
The team committee is responsible for ensuring that there is a clean handover to future committees at the end of their term of office. This does not preclude volunteers being on the committee for consecutive terms.
# Committee Membership
Events teams and Services teams operate slightly differently in terms of the terms of office and committee operation.
## Events teams
### Formation and Dissolution
Events teams (and their respective committees) operate on a 11-month cycle running from early July to early June the following year. The one month gap provides a much-needed break for members of the team. This gap also provides a definitive start of a new cycle and creates an opportunity for new volunteers to get involved starting afresh with the rest of the team.
### Registration of Interest
Approximately three weeks before the new team is to be formed, all registered SR volunteers are invited to express an interest in being part of the next committee or team. Previous members of the committee and/or team are welcome to register interest.
### Formation
The committee is formed at a meeting with the Trustees. If more than 3 volunteers register an interest in being on the committee they will all be invited to the formation meeting, however only 3 of them will be allowed to become committee members. If more than 10 volunteers register an interest in being on the committee then the Trustees select a short-list of 10 volunteers to invite to the formation meeting, based on the skills and experience they could bring to the committee. Any volunteers who register an interest in being on the committee but are not selected are contacted if vacancies appear on the committee during the 11-month period.
At the meeting, the Trustees discuss their expectations for the approaching year (based on feedback from the previous year’s cycle) and clarify any concerns about roles and responsibilities. Each year, the Trustees provide guidance as to the direction in which they would like the approaching year to be taken and where they would like the committee to focus their efforts. For example, it may be the case that the Trustees would like to expand the number of school teams, or they may want the committee to focus on increasing volunteer engagement. After discussing these points, and answering any questions, the Trustees leave the meeting, allowing a short time for discussion. On return, they ask for a show of hands of people who would like to join the committee. If more than 3 people indicate a desire to join the committee at this stage, the Trustees select the 3 people that they feel are most able to take on the responsibilities of the committee.
### The First Few Weeks
After the formation meeting has concluded, the newly formed committee fulfil their collective responsibilities. The Trustees encourage the committee to identify any management, coaching or team building training they may need to discharge their responsibilities effectively.
### Dissolution
At the end of the term of office, the committee is invited to meet with the Trustees to review the progress made. This serves as a useful event for both the committee, to reflect on their achievements, and the Trustees, to gather as much information as possible to feed into future competitions. It is expected that the committee will get the views of the wider team before the meeting. After the review meeting, the team and its committee is effectively disbanded.
## Services teams
### Joining the committee
Volunteers join the committee by application to the Trustees. The committee will operate on a continuous/rolling timeline. Each member has a maximum term of two years, after which they are automatically retired from the committee. Before the conclusion of the two year term the member may apply to the Trustees to extend their term for a further two years, without a gap in membership.
### Registration of Interest
All registered SR volunteers are able to express an interest in being part of the committee at any time during the current committees term of office. The Trustees may choose to directly invite all registered SR volunteers to express an interest in being part of the committee or team in advance of filling a role. Previous members of the committee and/or team are welcome to register interest.
### Yearly updates
Once a year, around early July, the committee will meet with the Trustees. At the meeting, the Trustees discuss their expectations for the approaching year and clarify any concerns about roles or responsibilities. Each year, the Trustees provide guidance as to the direction in which they would like the approaching year to be taken and where they would like the committee to focus their efforts. For example, it may be the case that the Trustees would like to expand the number of kits available, or they may want the committee to focus on increasing team support.
## Common
### Resignation of a Committee Member
If a committee member wishes to resign part-way through their term of office they email the Trustees. The Trustees work with the individual to see if there is any further help and support that they can provide to allow the volunteer to continue in their role. If there is no option for the individual to continue, the Trustees work with the rest of the committee to find a volunteer to become a replacement committee member. Volunteers that indicated a desire to be on the committee at the start of the cycle, but were not selected due to the size restrictions, are considered first, followed by those who registered an interest at other points during the term of office.
# Competition Team
## Purpose
The Competition Team is an Events team responsible for defining and delivering the SR Competition Programme ('the competition programme') for a single competition cycle (11 months).
The SR Competition Programme includes, but is not limited to:
* Recruiting teams from schools and colleges
* Determining a fair method for selecting teams if over subscribed
* Communicating with school/college team leaders throughout
* Liaising with Kit Team to agree the number of teams and number of locations that can be supported
* Devising a challenge
* Training sufficient volunteers
* Organising and running Kickstart
* Organising and running Tech days
* Organising and running the Competition final
* Health and Safety and Safeguarding at events
* Gathering metrics throughout the competition cycle
## Structure and Operation
The Competition Team is a group of volunteers who work together, and closely with other teams within SR, to define and deliver the competition programme. The team is lead by a committee that is responsible for fulfilling the aims of the team.
The team (and its committee) operates on an 11-month cycle (see [Formation and Dissolution](/version-8.0.0/annual-robotics-competition/committee-membership)).
Volunteers apply through the Competition Team Committee to join the team. The committee will ensure the team has an appropriate balance of relevant skills. Volunteers will be encouraged to apply at the start of each competition cycle but can apply at any stage of the competition cycle. The committee should not unreasonably restrict membership of the team.
## The Competition Team Committee
The Committee is a group of 3 people who are ultimately responsible for ensuring that the competition programme is delivered to the standard expected by the Trustees, coherent with the values of Student Robotics. The committee is accountable to the Trustees.
The committee will focus on management of time, resources and volunteers within the team. Delivering a competition is a huge undertaking and can require a significant investment of time and effort from volunteers and this workload must be carefully managed. The committee will provide support and guidance to team members to allow them to be as effective as possible in delivering the competition. The Trustees will provide support, guidance and training as necessary to allow the committee to be as effective as possible in managing the team.
## Roles and Responsibilities
In addition to the [common responsibilities](/version-8.0.0/annual-robotics-competition/common-responsibilities), the competition team has the following responsibilities:
### Collective Responsibilities
The committee takes on the following collective responsibilities at the start of the competition cycle, and within 4 weeks of the formation meeting.
1. **Recruitment of a team.** The Trustees will provide the committee with details of volunteers who registered an interest in being on the team during the Registration of Interest phase. The committee can also reach out again to all volunteers.
2. **High level planning session.** It is expected that the committee will produce a high level plan, that will take the form of no more than two A4 pages and will include time and resource estimates (both volunteers and assets) for running the next competition programme.
3. **Division of Responsibilities.** The committee must divide up the individual responsibilities between them. Each responsibility must be taken by a single committee member (although each committee member can take on multiple responsibilities).
Throughout the competition cycle, all committee members are expected to work together effectively to deliver the competition programme on time and within budget. They should communicate effectively with the team and with other SR teams that are involved in supporting the competition programme. They should maintain documentation of processes and anything else that they feel relevant relating to their responsibilities to help both current and future volunteers This documentation should be licensed under the [Creative Commons Attribution-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-sa/4.0/).
### Individual Responsibilities/Roles
As well as the collective responsibilities defined above, the following responsibilities must be divided up among the committee members. Each responsibility listed below **must be taken by a single member** and it is expected (in fact, necessary) for some members to take on more than one of the responsibilities.
1. **Event management.** This committee member is responsible for overall management and delivery of the various events throughout the competition programme (Kickstart, Tech Days, Competition). This is a large responsibility and the committee member taking this on should not take on any of the other individual responsibilities.
2. **Competitor team management.** This committee member is responsible for the management of teams taking part in the competition programme. They are expected to ensure that a sufficient quantity of school teams are signed-up to take part in the competition and that the teams that compete receive an adequate level of communication to allow them to get the most out of taking part in the competition programme. In particular they should ensure that sufficient notice is given to school teams to give them time to make the necessary preparations (schools usually require notice many months in advance of a major event).
3. **Volunteer management.** This committee member is responsible for the management of two groups of volunteers: members of the team and other volunteers who are helping out at an event.
* In the case of team members they should ensure that all team members are given an opportunity to contribute towards delivering the competition programme and that they are guided to areas within the team that require more effort. They should handle requests from volunteers looking to join the team and also counsel team members looking to leave the team.
* In the case of volunteers helping out at events they should ensure that all volunteers are given visibility of event volunteering opportunities and that they receive adequate documentation, training and support for the roles that they fill at the events.
1. **Safeguarding and welfare.** This committee member is responsible for ensuring that the Student Robotics [safeguarding policy](https://github.com/srobo/ops-manual/blob/safeguarding/about-the-charity/safeguarding.md) is abided by throughout the 11-month period and at events. They are also responsible for ensuring that all volunteers working on the competition programme (either in the team or as event volunteers) are not overworked and that the level of responsibility being taken on by any individual is kept at an acceptable level.
2. **Gathering metrics.** This volunteer is responsible for ensuring that metrics are collected throughout the 11-month period. They should work with the Trustees early on to define a list of metrics to be gathered (e.g. number of school teams, average number of competitors per school team, average competitor to mentor face time per week, etc). It is of critical importance that SR gathers metrics to be able to optimise and improve the competition programme and to report to new and existing sponsors to prove the effectiveness of the competition programme.
The committee is free to define other roles as it sees fit. It is also free (and strongly encouraged) to form sub-teams within the team to handle certain aspects of the competition programme. For example, the committee member responsible for Competitor team management should form a sub-team made up of volunteers who are primarily focused on the activities of managing school teams.
### Accountability
The Competition Team is accountable to the Trustees. The committee member responsible for reporting to the Trustees will speak in person with the Trustees at least once every month to report on progress and to highlight any areas of concern.
Minutes of meetings should be made available to the general public although access to any sensitive commercial data, may be restricted to the Trustees.
### Budget
A budget will be made available to run the competition programme. The responsibility for this budget will be delegated to an individual committee member.
# Marketing Team
## Purpose
The marketing team are an Events team responsible for attracting new teams and volunteers into SR. They will be looking at attracting teams for both the current and, in later months, the following competition cycle.
They are responsible for managing:
* Website content
* Social media
* Team (competitor) recruitment & relationship management for current and following competition cycle
## Structure and Operation
The Marketing Team is a group of volunteers who work together, and closely with other teams within SR, to attract competitors and volunteers into SR. The team is lead by a committee that is responsible for fulfilling the aims of the team.
The team (and its committee) operates on an 11-month cycle (see [Formation and Dissolution](/version-8.0.0/annual-robotics-competition/committee-membership)).
Volunteers apply through the Marketing Team Committee to join the team. The committee will ensure the team has an appropriate balance of relevant skills. Volunteers will be encouraged to apply at the start of each competition cycle but can apply at any stage of the competition cycle. The committee should not unreasonably restrict membership of the team.
## The Committee
The Committee is a group of 3 people who are ultimately responsible for ensuring that the teams are sourced in the manner expected by the Trustees, coherent with the values of Student Robotics. The committee is accountable to the Trustees.
The committee will focus on management of time, resources and volunteers within the team. The committee will provide support and guidance to team members to allow them to be as effective as possible in delivering the infrastructure services. The Trustees will provide support, guidance and training as necessary to allow the committee to be as effective as possible in managing the team.
## Roles and Responsibilities
In addition to the [common responsibilities](/version-8.0.0/annual-robotics-competition/common-responsibilities), the marketing team has the following responsibilities:
* Website content
* Social media
* Attracting teams
* Maintaining on-going relationships with teams
* Attracting volunteers
## Accountability
The Marketing Team is accountable to the Trustees. The committee member responsible for reporting to the Trustees will speak in person with the Trustees at least once every month to report on progress and to highlight any areas of concern.
Minutes of meetings should be made available to the general public, although access to any sensitive commercial data may be restricted to the Trustees.
## Budget
A budget will be made available to aid finding teams and volunteers. The responsibility for this budget will be delegated to an individual committee member.
# Kit Team
## Purpose
The Kit Team is a Services team tasked with developing and maintaining the SR Kit, and to provide a Kit Service to enable the SR Competition Programme.
The Kit is defined as the hardware and software (including software services) that are provided to school teams to enable them to take part in the annual robotics competition.
The Kit Service includes, but is not limited to:
* Provision of sufficient working kit to meet the needs of the Competition Team
* Delivery of kit to Kickstart location(s) as agreed with Competiton Team
* Checking kit out to teams at Kickstart events
* Shipping kits to teams that cannot attend a Kickstart event
* Collecting and holding disclaimer forms for kit issued
* Dealing with any kit problems and issuing replacement parts as needed throughout the competition cycle
* Providing technical documentation for competitors and for volunteers
* Providing technical support to competitors and volunteers (both remote and in-person at events)
* Recovering and checking kit following a competition cycle
* Dealing with requests for late return of kit
* Chasing any missing kit including kit not returned
* Storing the kit safely
* Maintaining an inventory of the kit
* Developing kit for future competitions
## Structure and Operation
The Kit Team is a group of volunteers that work together to provide a Kit Service. The team is lead by a committee that is responsible for fulfilling the aims of the team.
The Kit Team is separate from the Competition Team. However, it is expected that Kit Team volunteers will have previously volunteered with the Competition Team and that volunteers from both teams will be available to help run the annual competition.
Volunteers apply through the Kit Team Committee to join the team. The committee will ensure the team has an appropriate balance of relevant skills. The committee should not unreasonably restrict membership of the team.
## The Kit Team Committee
The Kit Team Committee is a group of 3 people who develop and clearly communicate a strategic vision, coherent with the values of Student Robotics, for the Kit. The committee ensures that resources are always used in the best interests of the charity and is accountable to the Trustees, The committee delegates responsibilities and resources to the rest of the team.
## Roles and Responsibilities
In addition to the [common responsibilities](https://github.com/srobo/ops-manual/blob/safeguarding/annual-robotics-competition/common-responsibilities.md), the kit team has the following responsibilities:
### Collective responsibilities
* Communicating a strategic vision for the kit.
* Ensuring that resources are deployed only for the purposes of delivering the Student Robotics Competition Programme or as directed by the Trustees.
* Maintaining a record of team members, with their abilities and desired workload.
* The management, tracking and distribution of assets within the team.
* The management of the workload of members of the team.
* Ensuring projects are open source, open to contribution from external parties, and inviting to work on by volunteers.
* Assigning and managing projects/maintenance to team members, this may be assigned to self organising subgroups of individuals.
* Maintain documentation of processes and anything else that they feel relevant relating to their responsibilities to help both current and future volunteers This documentation should be licensed under the [Creative Commons Attribution-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-sa/4.0/).
## Accountability
The Kit Team is accountable to the Trustees. A report will be delivered by the committee member responsible for reporting to the Trustees, every 4 months, to update them on the work of the team and the state of the kit.
Minutes of meetings should be made available to the general public, although access to any sensitive commercial data may be restricted to the Trustees.
## Budget
A budget will be made available to allow the kit to be stored safely and maintained in good working order.
Specific budgeting for development projects will be managed on a case by case basis, applying for budget from the Trustees in each of these cases.
A "Development Pot" line should be requested, and will be made available to cover low-cost resources used in the development process.
# Infrastructure Team
## Purpose
The Infrastructure Team is a Services team responsible for providing and maintaining the computing infrastructure required for the other teams to operate.
This includes, but is not limited to:
* Setting up and maintaining servers to support SR operations including the deployment of the public facing web site
* Setting up and maintaining the organisation's domains (studentrobotics.org and srobo.org)
* Maintaining the security of the infrastructure and related services
* Setting up and maintaining the structure of GitHub organisations and permissions
* Setting up and maintaining G-Suite accounts for SR volunteers
* Providing support and guidance with regards to best-practices to other teams or volunteers on infrastructure and services where possible
* The infrastructure team is not responsible for content beyond ensuring it does not break other functionality
## Structure and Operation
The Infrastructure Team is a group of volunteers who work together, and closely with other teams within SR, to provide infrastructure services enabling the other teams to operate. The team is lead by a committee that is responsible for fulfilling the aims of the team.
The team operates continuously with committee members having a 24-month term of office (see [Formation and Dissolution](/version-8.0.0/annual-robotics-competition/committee-membership)).
Volunteers apply through the Infrastucture Team Committee to join the team. The committee will ensure the team has an appropriate balance of relevant skills. Volunteers will be encouraged to apply at the start of each competition cycle but can apply at any time. The committee should not unreasonably restrict membership of the team.
## The Committee
The Committee is a group of 3 people who are ultimately responsible for ensuring that the infrastructure is delivered to the standard expected by the Trustees, coherent with the values of Student Robotics. The committee is accountable to the Trustees.
The committee will focus on management of time, resources and volunteers within the team. The committee will provide support and guidance to team members to allow them to be as effective as possible in delivering the infrastructure services. The Trustees will provide support, guidance and training as necessary to allow the committee to be as effective as possible in managing the team.
## Roles and Responsibilities
In addition to the [common responsibilities](/version-8.0.0/annual-robotics-competition/common-responsibilities), the infrastructure team has the following responsibilities:
* Maintaining a list of core services (i.e. services central to Student Robotics operation)
* Maintaining a list of team services (i.e. services maintained especially for and in collaboration with another team)
* Ensuring continuous/enduring access to SR services
## Accountability
The Infrastructure Team is accountable to the Trustees. The committee member responsible for reporting to the Trustees will speak in person with the Trustees at least once every month to report on progress and to highlight any areas of concern.
Minutes of meetings should be made available to the general public although access to any sensitive commercial data, may be restricted to the Trustees.
## Budget
A budget will be made available to purchase infrastructure services. The responsibility for this budget will be delegated to an individual committee member.
# Fundraising Team
## Purpose
The Fundraising Team is a Services team responsible for sourcing funding for the current and following SR Competition cycle.
This includes, but is not limited to:
* Secure funding for the current and future competition year
* Sourcing Sponsorship
* Fundraising
* Industry links & relationship management
## Structure and Operation
The Fundraising Team is a group of volunteers who work together, and closely with other teams within SR, to ensure there is sufficient funding for the teams to operate. The team is lead by a committee that is responsible for fulfilling the aims of the team.
The team operates continuously (see [Formation and Dissolution](/version-8.0.0/annual-robotics-competition/committee-membership)).
Volunteers apply through the Fundraising Team Committee to join the team. The committee will ensure the team has an appropriate balance of relevant skills. Volunteers will be encouraged to apply at the start of each competition cycle but can apply at any time. The committee should not unreasonably restrict membership of the team.
## The Committee
Unlike the other teams, the Fundraising Team committee is the Trustees. This is due to most sponsor applications requiring Trustee involvement anyway, and any decisions around sponsor suitability have to be made at Trustee level, so a separate committee would not be able to make any meaningful decisions.
## Roles and Responsibilities
In addition to the [common responsibilities](/version-8.0.0/annual-robotics-competition/common-responsibilities), the team has the following responsibilities:
### Collective responsibilities
* Contact sponsors to arrange funding
* Ensuring all perks due to sponsors are appropriately supplied
* Maintaining links with sponsors
## Accountability
The Fundraising Team is accountable to the Trustees. The Fundraising Team will make a report the Trustees at least once every month to report on progress and to highlight any areas of concern.
Due to their commerially sensitive nature, minutes of meetings will not automatically be made available to the general public. Release of this information requires approval of the Trustees.
## Budget
A budget will be made available to aid in sourcing funding. The responsibility for this budget will be delegated to an individual committee member.
# Miscellaneous
## Licensing
This work (the operations manual) is licensed under the [Creative Commons Attribution-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-sa/4.0/). The authors of this work are: Rich Barlow, Diane Dowling, Thomas Scarsbrook.
## Making Changes to this Document
The source of this document can be found here: . It is maintained by the Trustees of the charity. It is important to note that the information contained within the 'master' branch of the repository has not been released and therefore is not authoritative. New releases of the operations manual must be approved by the Trustees via one of the decision making procedures defined in clause 17 of the [constitution](https://github.com/srobo/ops-manual/tree/d76377192d4c94c4bd4298f0f3954f5d342af24b/resources/constitution.pdf).
Releases of the operations manual are denoted with both a tag and branch of the form 'v#', where # is a number. The latest release is the one with the largest number and will be set as the GitBook 'primary' version. The requirement for a branch as well as a tag with the same name is an unfortunate requirement of how the GitBook platform operates; if a tag and branch of the same name ever differ in terms of the commit that they refer to, the tag takes precedence (if you happen to notice an anomaly of this form, please inform the [trustees](mailto:trustees@studentrobotics.org)).
To make a release of this document the following steps must be taken:
1. Ensure that the [Change Log](/version-8.0.0/miscellaneous/change-log) is up to date with all modifications made since the previous release.
2. Ensure that the Trustees have approved the release of the new version and it has been recorded in the Trustees' decisions.
3. Set the version number and date for the new version in the Change Log.
4. Create a new version via the GitBook editing interface. This version must have a human-readable name of the form 'Version #' and a 'path' of 'v#' (the 'path' setting in the GitBook interface is what becomes the branch name in the git repository).
5. Set the newly created version as the primary version, such that it is the version presented to a reader when visiting .
6. Create a tag with the same name as the branch just created. This tag must point to the same commit as the current head of the branch. The tag can be created either using the normal git CLI tools or the GitHub web interface.
# Release Versioning
The Operations Manual attempts to follow Semantic Versioning 2.0.0 (). Since Semantic Versioning is designed for use with code, it is necessary to clarify what is considered the 'public API' and is helpful to give some examples of changes that will result in the major, minor or patch fields are incremented.
## The Operations Manual Public API
The Operations Manual is the means for the Trustees to define what Student Robotics is, what it stands for and how it operates. There are, in effect, two parts to the 'public API' of the Operations Manual:
* The organisation's interface to the world (the definition of what SR is and what it stands for)
* The Trustee's interface to the rest of the organisation (the structure within the organisation and the interface between those structures and the Trustees)
## Examples of Changes
### Major (X.y.z) Version Increment
* Adding a new organisation value
* Renaming the Core Team to the Competition Programme Committee and redefining its size and scope
* Reducing the period of the Core Team/Competition Programme Committee to 10 months
* Changing the procedure for a team/committee to report to the Trustees
* Re-writing the safeguarding policy such that all Student Robotics volunteers must re-read and understand it
### Minor (x.Y.z) Version Increment
* Adding a new team/committee (e.g. Kit Team)
* Changing the process for releasing a new version of the Operations Manual
* A Trustee changes (added or removed)
* Clarifying wording of things
### Patch (x.y.Z) Version Increment
* Fixing a typo that doesn't change the intended meaning
* Formatting changes
# Change Log
All notable changes to the Operations Manual will be documented on this page.
The format is based on [Keep a Changelog v1.0.0](https://keepachangelog.com/en/1.0.0/), and this project adheres to [Semantic Versioning v2.0.0](https://semver.org/spec/v2.0.0.html) (see the [Release Versioning](/version-8.0.0/miscellaneous/release-versioning) page for details of what this means).
Each release of the Operations Manual has an entry on this page. Within this entry changes are broken down into 'Added', 'Changed', 'Removed' and 'Minor Fix'. The first three categories cover modifications that affect the function of the document, whereas the last one includes modifications that do not, for example corrections to typos and formatting. Each entry also includes the date on which it took effect.
## Version 7.0.0 (2021-12-12)
### Added
* Infrastructure Team
* Marketing Team
* Fundraising Team
* Team common responsibilities
### Changed
* Details of Trustees
* Teams overview
### Removed
## Version 6.1.0 (2019-09-19)
### Added
* [Kit Team](/version-8.0.0/annual-robotics-competition/kit-team) page
### Changed
* Details of Trustees
* Name of Competition Programme Team to Competition Team
* Updated layout and headings on Competition Team pages to align with Kit Team pages
* Removed FAQs from Competition Team pages
* Changed other pages to reflect the fact that there are now two key Teams
* Removed 'emergency contact details' from data stored about volunteers
* Recorded use of GSuite to manage organisation
## Version 6.0.0 (2019-06-25)
### Added
* [Release Versioning page](/version-8.0.0/miscellaneous/release-versioning) that specifies that the Operations Manual follows Semantic Versioning v.2.0.0 from now on
* Note to [Change Log page](/version-8.0.0/miscellaneous/change-log) that clarifies its adherence to Keep a Changelog v1.0.0
### Changed
* Latest hosted version is now available at
* Use British English spelling 'programme' for the Competition Programme
* Rename 'Core Team' to Competition Programme Committee
* Rewrite the old 'Core Team' page to 'Competition Programme Team' and rewrite the majority of its contents to describe the new structure
## Version 5 (2018-11-29)
### **Added**
* Paragraph referencing code of conduct for volunteers
### **Removed**
* Paragraph explicitly restricting volunteers meeting or contact young people
## Version 4 (2018-08-30)
### Added
* Change Log page to document modifications between releases.
* Instructions in the [Making Changes](/version-8.0.0/miscellaneous#making-changes-to-this-document) section to ensure that the Trustees have approved the release of a new Operations Manual, the decision to release is recorded, the Change Log is updated with the modifications made and the new version number and date of release is entered into the Change Log.
* Clarification to [Safeguarding](https://github.com/srobo/ops-manual/blob/safeguarding/about-the-charity/safeguarding.md) that it is only young people who are participating in Student Robotics activities that volunteers must not meet outside of the supervised environment.
* Examples of who 'those who participate in our community' are in [Purpose](/version-8.0.0/about-the-charity/code-of-conduct#1-purpose) section of Code of Conduct.
* Instructions to [Reporting Guidelines](/version-8.0.0/about-the-charity/code-of-conduct#6-reporting-guidelines) in Code of Conduct detailing what information to include in a report, how the report is handled and how corner cases, such as the person being accused being one of the people who normally deals with reports, are dealt with.
* Clarification to [Core Team's Expectations of the Trustees](https://github.com/srobo/ops-manual/tree/d9e76a35317e628b18897f068a9332d47488e80d/annual-robotics-competition/core-team.md#core-teams-expectations-of-the-trustees) number 6 that only Trustees have direct access to volunteer dataset and that the Core Team will have to work with the Trustees to make use of it.
* Clarification to [Budgeting Requirements](https://github.com/srobo/ops-manual/blob/safeguarding/annual-robotics-competition/money-matters.md#budgeting-requirements) number 5 to remove ambiguity around what the '£1000' is referring to.
### Changed
* Only store geographical region, instead of full postal address, in [volunteer register](https://github.com/srobo/ops-manual/blob/safeguarding/annual-robotics-competition/volunteers.md).
* Soften 'expected' to 'will ideally' in Core Team [Defining Features](https://github.com/srobo/ops-manual/tree/d9e76a35317e628b18897f068a9332d47488e80d/annual-robotics-competition/core-team.md#defining-features) section.
* Make Core Team [Defining Feature](https://github.com/srobo/ops-manual/tree/d9e76a35317e628b18897f068a9332d47488e80d/annual-robotics-competition/core-team.md#defining-features) number 2 more all-encompassing.
* Shift dates of Core Team convening and disbanding one month earlier in the year (now convene in June and disband in May). This is to better align with the school year.
* Expect Core Team to run a Competition Program, rather than an explicit annual robotics competition, in [Trustees' Expectations of the Core Team](https://github.com/srobo/ops-manual/tree/d9e76a35317e628b18897f068a9332d47488e80d/annual-robotics-competition/core-team.md#trustees-expectations-of-the-core-team) number 4.
### Removed
* Pre-selection of 10 people to invite to the meeting to form the Core Team in the [Core Team Formation](https://github.com/srobo/ops-manual/tree/d9e76a35317e628b18897f068a9332d47488e80d/annual-robotics-competition/core-team.md#formation) section.
* Sentence explaining why more than eight people are invited to the meeting to form the Core Team in the [Core Team Formation](https://github.com/srobo/ops-manual/tree/d9e76a35317e628b18897f068a9332d47488e80d/annual-robotics-competition/core-team.md#formation) section.
* Explicit list of volunteer details recorded from [Core Team's Expectations of the Trustees](https://github.com/srobo/ops-manual/tree/d9e76a35317e628b18897f068a9332d47488e80d/annual-robotics-competition/core-team.md#core-teams-expectations-of-the-trustees) number 6. (This information is already defined on the [Volunteers](https://github.com/srobo/ops-manual/blob/safeguarding/annual-robotics-competition/volunteers.md) page).
* Reference to not giving refunds to paid events from [Consequences of Unacceptable Behaviour](/version-8.0.0/about-the-charity/code-of-conduct#5-consequences-of-unacceptable-behaviour) section of Code of Conduct. We don't run paid events, so it isn't relevant.
### Minor Fix
* Make release procedure in [Making Changes to this Document](/version-8.0.0/miscellaneous#making-changes-to-this-document) section into a numbered list.
* Make points under [Trustees' Expectations of the Core Team](https://github.com/srobo/ops-manual/tree/d9e76a35317e628b18897f068a9332d47488e80d/annual-robotics-competition/core-team.md#trustees-expectations-of-the-core-team) number 8 (be self-organising) into a numbered list.
* Expand 'SR' into 'Student Robotics' in [Safeguarding](https://github.com/srobo/ops-manual/blob/safeguarding/about-the-charity/safeguarding.md).
* Reference Trustees' email address in a more readable manner in [Safeguarding](https://github.com/srobo/ops-manual/blob/safeguarding/about-the-charity/safeguarding.md) and [Code of Conduct](/version-8.0.0/about-the-charity/code-of-conduct).
## Version 3 (2018-07-09)
The whole Operations Manual has been completely rewritten and bears little resemblance to Version 2, therefore it would not be sensible to try and enumerate all of the changes. Version 3 effectively represents a completely new direction for the Operations Manual and should be viewed as a completely new work.
---
[Next Page](/llms-full.txt/1)