Consider using ChannelFinder results to look for naming convention violations

[wbadgett]

Consider using ChannelFinder results to look for naming convention violations -- detect PV names that don't follow our naming convention and produce a concise report on a web page, say.

[crispd]

Another good thought for us to come back to.

Since I'm looking at this now, I'll just plant a quick thought for later.

Some EPICS support packages come with a lot of PVs that assume some convention of their own, or which are so numerous/unique that our convention won't provide enough guidance on them. In addition, it may be easier to pull future community updates for certain modules if we are mindful about how/where we prioritize our standards over those that may be used in upstream version provided by the EPICS community.

All this to say, we should absolutely try to enforce/encourage as much naming conformance as possible, but we should seriously consider improving the guidance which the existing convention is providing.

1. Who is the point of contact to confirm new additions or changes to the provided naming convention
2. The naming convention should be more accessible; so that there's no excuse for not using it, and so that more people are able to reference it when they think they've found some PV that's improperly named
3. The signal names that are most important to standardize are those that end up being used for alarms, in controls pages, and the archiver. If SMEs aren't even using some PV, maybe it simply serves some intermediary logical purpose BETWEEN some PV(s) that people are actually interfacing with... It may be good to provide some sort of guidance on how (or to what extent) our convention can be flexible in these cases.

i.e. an IOC developer might use an intermediary calc record that helps translate a retrieved device value to something more useful to an end user. At MSU, the IOCs for some current supplies for beamline magnets would read the current, then there'd be a PV that references data for the magnet to convert amps to an estimated field gradient, and the user would see the field gradient on their display. The user may care about the first one, reading Amps, and the last which reads Tesla/meter, but the intermediary one is merely supportive. In situations like these, where a given intermediary PV is clearly playing THE supportive role for another which people do care about, we would have it use the same PV name as the last--but preceded by a leading underscore. This was a really simple way to indicate that it is a PV that's merely supportive and not to be used in pages/alarms/archiver/etc. C.Roehrig has told me that ANL did something quite similar. (This is just one example relating to convention flexibility)

[wbadgett]

1. This is Pierrick
2. Pierrick, could you please point us to your naming convention description?