Remove year-specific content

[Scarzy]

No description provided.

[trickeydan]

I thought we weren't allowed to remove year-specific content? I've been trying to clean up the kit section recently and the amount of very specific content to SRXXXX makes it quite difficult.

I would approve of this change.

[PeterJCLaw]

See also #59 and #47.

[PeterJCLaw]

Part of the challenge here is that we have two kinds of information in the runbook -- information which is normative "this is how this is don" and that which is informative "this is what to consider when doing this". For the former we likely want only to have the current information, though for the latter examples of past approaches and considerations are often very useful. Even for the former recording why we do things a particular way and what has been tried in the past is also useful, though likely at a slightly different mode of using the runbook.

In that light it's not clear that a strict rule one way or the other is immediately the right choice and there likely are places where having year-specific docs (including for the current year) are the right thing.

One approach considered might be to tag the whole runbook with versions like the ops-manual, however this seems unlikely to work as the runbook (by design) covers several parts of the volunteer organisation which work at different cadences (e.g: competition years likely don't work for the infrastructure team). Therefore handling versioning "inline" is likely a better fit.

Personally I think that having places where we have historic information should be fine as long as it is clearly labelled as such (and its presence provides value). An approach which might work would be to delineate at the level of files (i.e: pages in the rendered version), thus making it fairly obvious when you're reading something which is out of date.

There is separately an issue that we now have a lot of historic and just generally not useful year-specific information, including for example mentions of who is doing what, that could almost certainly be removed with no loss of value.

[trickeydan]

Given that #59 is still open, I think part of the challenge here is that the runbook is difficult to edit "casually". Thus the information that we have within it is either: a) old; or b) very deliberately added.

Perhaps a wiki for year-specific / quick notes on information + recommended practices in the runbook?

[PeterJCLaw]

#57 (closed as consensus was reached) is also relevant.

Given that #59 is still open, I think part of the challenge here is that the runbook is difficult to edit "casually". Thus the information that we have within it is either: a) old; or b) very deliberately added.

Perhaps a wiki for year-specific / quick notes on information + recommended practices in the runbook?

Exploring how to make the runbook easier to edit feels like a useful discussion/exploration to have, however perhaps not one for this issue?

[Scarzy]

Part of the challenge here is that we have two kinds of information in the runbook -- information which is normative "this is how this is don" and that which is informative "this is what to consider when doing this". For the former we likely want only to have the current information, though for the latter examples of past approaches and considerations are often very useful.

Surely the way to approach the second of these would be to have an increasing list of the things that have been considered in the past. Having separate year specific details becomes messy when each year you have to look at ALL the previous years individually to make sure you haven't missed something. This gets exponentially harder overtime and stuff is more likely to be missed.

Having had a quick flick through, all of the year specific content seems to be merely defining a specific process for a given year, and therefore is no longer applicable (the only exception I could find is https://studentrobotics.org/runbook/competition/arena/sr2017-feedback/, none of which applies to any future year in the form it is currently in). It doesn't include any detail on how any of these processes were reached, I assume this was all discussed at doings or on tickets and therefore doesn't actually provide the "this is what to consider". Changing this to on-going notes of "This has worked in the past, this hasn't" seems far more useful to achieve your stated goal.

[Scarzy]

My really big concern with all of this, is if multiple people are operating under different assumptions on what should be happening because they've looked at outdated information, could we end up with safety issues arising. This could happen equally with policies in place for handling incidents, and if different versions of kit need different approaches to deal with unexpected behaviour.

A new volunteer needs to be able to see clearly what is the current state of affairs.
Only developers need to know the history.

[WillB97]

https://studentrobotics.org/runbook/competition/arena/sr2017/#arena-construction is relevant to this year. How much else of this content has been declared year-specific because it refers to a particular venue or arena type, etc.? This information is useful as a basis when returning to a venue or using a previous design.