Discussion: Usage statistics and metrics

[DominicOram]

As a developer I would like to be able to easily see a number of things about my plans, plan stubs and devices:

• When was the last time this was used
• Which beamline was it used on - maybe even who used it if we have good granularity on this
• How long did it take

Acceptance Criteria

• We compile a list of requirements
• We come up with a plan of where we will implement these requirements and how
• We write relevant issues for them

Note:

• As discussed we may not get perfect statistics all the time e.g. my_plan on i03 may not be the same as my_plan on i04 or my_plan today may be very different from my_plan yesterday. This is fine, we shouldn't let perfect be the enemy of good

[callumforrester]

Additional metrics I would be interested in, some raised by in-person discussion:

• Plan error/success rate
• How often plan is run with the same set of parameters vs. different set
• Unique identifier to ensure all plans tracked uniquely. Two plans can have the same name
• Ideally also distinguish between different versions of the same plan

[Tom-Willemsen]

• Which device(s) were injected into the plan by blueapi (maybe just log name/class/prefix)?
  • e.g. the plan might be theoretically shared between two beamlines, but if only one beamline uses it in practice we should be able to tell from the prefixes of the injected devices.

[stan-dot]

connected to #363 .

[stan-dot]

suggestion - a discussion on parts that change the architecture in a major way: #133, #167, #180, #184 ,#194 #276, #258 , #257, #363, DiamondLightSource/bluesky-stomp#22, #299, #440, #380, #371

possibly most would be closed as not in scope, and if breaking changes are introduced maybe all at once would make for an easier change, leaving out only small changes and bugs, bringing us closer to 1.0