Reflecting reality != bleeding edge

[richardbarlow]

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 know from the discussion that occurred in the pull-request that resulted in this proposal that the wording of 'latest technology' was potentially going to change. I think that as the wording stands right now that it is at odds with the 'reflecting reality' value. It is very rare in the reality of real-world engineering that one is using the 'latest' technology (of course this depends upon your interpretation of newness). In general, as an engineer, you select the most appropriate tool for the job based on many factors and quite often reliability and proven performance is a big factor. 'Latest technology' can potentially indicate a desire to direct SR to using fragile and unproven technology.

I'm not saying that there isn't a time and place to use something bleeding edge, but there has to be a good reason to do so (and if the reasoning is valid then go ahead!). I think that it would make more sense for this to be worded along the lines of incorporating up-to-date proven technology - which is effectively saying the same thing, but helps to remove ambiguity between what people consider 'latest' to mean.

[trickeydan]

up-to-date proven technology

I like this phrasing and agree that it solves the issues that the current proposal introduces. I absolutely agree that it is not a good idea to use technology that is so new it is unstable. The original point of this sentence was to encourage constant development and updating of previous projects (e.g let's not have the API on Python 2 if we can achieve that).

I am concerned about how different people would perceive when a technology is proven? However, I am also unsure how else we could word this whilst remaining concise.

[PeterJCLaw]

The original point of this sentence was to encourage constant development and updating of previous projects

Then let's say explicitly that!

Part of the challenge here is that we have limited resources (much more so than a company might) and yet still have a strong desire to deliver tools to competitors which work reliably. This almost certainly means that we're likely to bias (entirely reasonably) in favour of stable, proven technologies which perhaps aren't especially exciting to work with on their own. (I'd argue there's an excitement to be had from the requirement for the thing you're building needing to be bulletproof though)

On the other hand volunteers, currently mostly being students, are likely both to have less experience building such reliable things and to want to explore bleeding edge technologies. The choice I think we need to make is whether SR is explicitly a place which will sponsor its volunteers to explore the bleeding edge (perhaps with a desire to attract more volunteers as a result of the community that creates), or focusses entirely on building stable systems.

In the former case we need to have a way to ensure that the experiments have (and provide) value while still ensuring that what gets deployed is of a high quality and reliability. In the latter case we do still want to encourage development of our own systems and following updates from our dependent platforms.

Whichever way we go, an approach to the use of "new" stuff might be to use the concept of "innovation tokens", which I first hear about from https://mcfunley.com/choose-boring-technology.

Separately: I suggest that if we do take on the exploration of new stuff we should also encode our approach to choosing technologies for deployment (likely a copy/paste of what @richardbarlow said above, perhaps with an outline of the "innovation tokens" framework if we like that framing), so that it's clear that the aim is explicitly not to follow the latest fads.