Student Robotics Dev Team Proposal

This document aims to solve the important issue of development by outlining the formation of a number of smaller sub-groups within Student Robotics:

• The Development Coordination Team.
• A number of project groups.

The Development Coordination team

The Development Coordination team (a.k.a. the Dev Team) is a group of volunteers that are chosen annually in a similar fashion to the formation of the Core Team, although they may be responsible for projects beyond the annual timescale.

The goals of the Dev Team are to ensure the long-term longevity of Student Robotics by organising projects that enhance the experience for SR’s competitors and volunteers in line with its values, and enable SR’s long term growth. Additionally they will aim to fulfill the values of Student Robotics, in particular our goal of reflecting reality by incorporating the latest technology whenever feasible.

Project Groups

A project group is a smaller group of one or more self-selected volunteers who have a particular interest in working on something together. The project group should report progress regularly to the Dev Team. The Dev Team oversees the various project groups to ensure that they are on track and aligned with the goals of the charity. Project groups are responsible for maintaining projects that they have.

Formation of a Project Group

A group of volunteers decides that they would like to work on a project. They communicate their ideas to the Dev Team and the Dev Team will decide whether the project is beneficial to the organisation. A schedule for the project will be discussed between the Dev Team and the project group. A project group may apply to the Dev Team for budget for specific purchases for their project, given sufficient justification. The Dev Team should also keep in mind the future needs of project groups when planning their budget.

Alternatively, the Dev Team may identify the need for a project within the organisation and will find interested volunteers to form a group to do the project.

Budgeting

The Dev Team is allocated a budget, to be agreed with the Trustees. The scope of this budget is to cover costs incurred for development activities only, and not the cost of deploying any completed projects which would be arranged between the Trustees and Core Team.

For the purposes of budgetary accountability, the Dev Team will select a Chair and Treasurer. (How the budget is managed is between the Dev Team and the Trustees.) In practice, unlike the Core Team budget which is fairly detailed (e.g. £x on Kickstart, £y on Competition, £z on other) and is approved in advance, Dev Team purchasing will be defined at a higher level (maybe some “infrastructure” budget for a dev server and some dev tools but not £a for Project A, £b for Project B. Unlike the Core Team, this will not be a rolling budget, but a “pot” that gets topped up in each accounting period to allow for projects to be budgeted over multiple years.

Accountability

1. Much like Core Team, minutes and reports from the Dev Team, and its various sub-groups will be available to view by the general public. Sensitive data, such as budgeting, may be exempt from this.
2. The Dev Team will submit regular progress reports to the Trustees.
3. As well as regular volunteers, the Dev Team may contain trustees and members of the Core Team, however volunteers should bear in mind any potential conflicts of interest that may arise as a result of this.
4. Members of the Dev Team should abstain from financial decisions where they are directly involved with the project group of concern. In an event when all members of the Dev Team have to abstain, the decision should be passed to the Core Team and then Trustees.
5. The Dev Team is responsible for the oversight of the various project groups within Student Robotics. The project groups should report their progress regularly to the Dev Team.

Relationship to the Core Team

• The Dev Team is independent from the Core Team, but will work closely with them in certain situations.
• The Core Team will also communicate priorities for projects to be completed by the next competition cycle. In the event of a Kit Deployment, the Core Team is responsible for ensuring budgeting, manufacture, deployment and testing is completed. The project group will likely be the ones completing these tasks.

Getting Things Done

For new projects, there is a process to follow to ensure they receive sufficient review and testing before they are implemented. This is shown in the examples below.

For each project group it is recommended that a “Project” is opened and actively maintained with high-level progress updates in the srobo GitHub organisation - even the “nice to haves” - if there are good ideas being worked on which get parked here, at least there will be some documentation to pick up on.

Examples of what may be in scope for SR2020: Python 3, new brain board, new IDE.

Examples

Project of significant impact: New brain board

• A group of volunteers decide they’d like to work on finding a new single board computer which can serve as the brain board, and port/upgrade software to work on it.
• New / Updated ticket in srobo/dev-tasks.
• The volunteers develop a brief specification, including information like:
  • Functional requirements (e.g. compatible with the rest of the kit, can be powered from Power Board, runs our API, camera isn’t made slower, form factor)
  • Scope (e.g. excludes any changes to modular kit or API, independent of Python 3 project)
  • Deliverables (e.g. Board, Software, Documentation for students and volunteers)
  • Acceptance Criteria (e.g. is demonstrated to run a defined piece of software on a test robot without fault, with a certain response time for libkoki markers, etc.)
• The Dev Team may also define some limits, such as:
  • Cut-off date for deployment at SR2020
  • Cost per unit limit
  • Evidence shown that more than one board has been considered
• The Dev Team may consult the Core Team or Trustees to assist them with requirements. For example, in the case of a Project that would have a high implementation cost, the Dev Team would need to communicate the feasibility of it with the Trustees.
• This specification is presented to and ratified by the Dev Team (either on the Dev Team mailing list or at a Dev Team meeting). Any sensitive information, such as a budget, will need to be privately discussed by the Dev Team and project group.
• Development work happens.
• If changes to the specification are needed, these can be discussed with the Dev Team.
• Development reaches a point where the project group is happy the work is done and is shippable.
• Dev Team reviews the equipment against the agreed specification and decides whether to recommend it to the Core Team.
• The process is now passed onto the Core Team who are responsible for deciding when and how to deploy it (e.g for SR 2020).
  • If it meets the needs of the competition, it is the Core Team’s responsibility to ensure new kit is purchased, tested and deployed (although it’s likely to be the project group who do this).
  • If it doesn’t, the Core Team must decide whether to proceed anyway at risk, or to continue with the existing kit and pause expansion.

Project of minor impact: Addition to the API (e.g. making an “R.ruggeduinos[0].PWM()” )

As this is notionally a simpler thing, but still in scope as it impacts the competition cycle, the process can be simpler.

• Developer wants to add the feature and is pointed in the direction of the appropriate project group by the Dev Team, or creates one if it does not exist.
• The project group determines that there is no need for a specification due to minor impact.
  • A change of minor impact does not have significant cost or change to the working of the competition.
  • The Dev Team may determine that a project is of minor impact and require a specification.
• Developer updates/opens a new ticket on the appropriate GitHub Project, adding to the relevant repo also if one exists.
• The project group will define testing and documentation requirements.
• Developer submits a pull request.
• The project group checks it meets the requirements and approves or rejects.
• The Dev Team will review the new version and decides whether to recommend it to the Core Team.
• Software may be continuously developed throughout the competition, but it only deployed at the discretion of the Core Team. The Core Team may choose to not upgrade software or equipment if it is not deemed beneficial.
• When deploying, the Core Team will update the kit to use the latest stable version of the software.