Yeah, that makes sense. Good thinking about the draft PR, it allows reviewing from the main repo instead of from my fork.
I think I would also include the base TelemetrySubscriber in the first PR, as a counterpart to TelemetryPublisher. It’s basically a lightweight, managed logging.Handler, abstracting away logging calls. Without it, telemetry users will probably just end up reimplementing what that class already does. We might as well keep it under one roof from the get-go.
So, with logger.info(f"--- Global Matching Step {self.matching_steps} ---"), if I understand, you want me to move that line into a handler, and have the variable value come from an event schema, is that correct? If so, in which file would you prefer I define the handler / subscriber? In my WIP branch, I stuffed all of 'em inside frameworks/telemetry, but perhaps we should establish a better baseline convention.
For the config, I assume you probably want something in a similar vein as “New Logging Configuration Options”? I will most likely add a setLevel method to TelemetryPublisher, to be used in a similar fashion as the logger.setLevel in MontyExperiment.