Document guidance for deciding at which layer a piece of logic should go

[olliesilvester]

As discussed with @DominicOram , it would be nice to have a flowchart-style set of rules to decide whether a piece of logic should go into EPICS, ophyd-async, or Bluesky

Something like this:

• If the logic only affects one device, is simple, won't change often, and/or is useful for scientists to be able to run outside of bluesky, it should go in EPICS

• If it only affects one device, and the logic is complicated, and it may need occasional changes and enhancements, it should go in ophyd-async. For this statement, where we have composite ophyd-async devices, we can treat the top level device and everything beneath it as 'one device'

• If it affects multiple devices, and/or if the logic is tied to the experiment where changes are required often, it should go in Bluesky.

Tagging a few people who may have thoughts: @callumforrester @abbiemery @coretl

Acceptance Criteria

• A set of rules to determine where logic should go is agreed upon and documented

[callumforrester]

I like this, my only question is how strict to make it? Do we want a prescriptive flowchart, a set of approximate guidelines, or somewhere in-between?

[DominicOram]

Approximate guidelines I think is fine. We're never going to be able to police something that's very strict

[coretl]

Other random thoughts on the topic:

• Things the science team are likely to want to read/edit are better placed in bluesky than EPICS
• ophyd-async must remain facility agnostic, no DLS EPICS naming conventions or EPICS support modules that are not on GitHub
• We may prototype in dodal and push to ophyd-async when it has been made more generic

[DominicOram]

I think where you say ophyd-async in the above do you actually mean dodal @olliesilvester?

[olliesilvester]

Yeah, I really mean creating the devices using the ophyd-async library, rather than putting it into the repo