Remit & measuring success

[jimmythompson]

Hey,

Great work on this so far. 😄

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.

I have some questions about this:

• What kind of metrics (either quantitive or qualitative) would the Dev Team measure to evaluate whether they are achieving the above goals?
• These goals provide a far wider remit than building software or hardware, and talk generally about improving the experience and long-term growth. Is this intentional, and if so, do you have any examples?

[rgilton]

It seems to me that the definition of the purpose of the Dev Team is extremely broad. I assume that the Dev Team would be responsible for the development of the following:

• Kit software, hardware, documentation and support ("kit")
• Software used at the competition event itself ("competition event software")
• Software used to run the competition programme ("competition software")

If I am right, then this seems overly broad. My feeling is that the above are reasonably separate concerns. While there are interdependencies between them, these are quite weak. Having them separate would be advantageous from simplicity, transparency, accessibility and responsibility perspectives (less for a team to manage, easier to see and get involved in a particular thing, easier to oversee, and easier to work out who is responsible for what).

So I suggest splitting the currently propoesd monolithic 'dev team' into three groups that can run reasonably independently of each other, and on different time-scales.

[PeterJCLaw]

Something to consider with regards to separating the team into parts is that we already have a situation where it's unclear to volunteers how and where they can get involved, and that's in a setup where we only have one active leadership team.

While some of that can be resolved with a good onboarding experience (something we're aware isn't working well at the moment), requiring people who have a small amount of time to give to make a choice a priori about where they contribute that is likely to result in more difficulty than needed. Having a single overarching leadership team, with a consistent set of flows and practises, ensures that it's easy for people to get involved.

I otherwise agree that clarity on the remit of the team is needed (see also #3 and #4 which touch on that) and the groupings @rgilton suggests for topics within the Dev Team seem reasonable starting points. (The IDE remains a difficult thing to classify as it's both highly coupled to the kit and a service used to run the competition programme, but I digress).