# What should our logging format be? **URL:** \ **Category:** Development & Maintenance\ **Created:** [February 24, 2020, 8:16pm UTC](https://forum.opencyphal.org/t/what-should-our-logging-format-be/764 "2020-02-24T20:16:55Z")\ **Posts on this page:** 1\ **Showing post:** 6
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [February 25, 2020, 7:04am UTC](https://forum.opencyphal.org/t/what-should-our-logging-format-be/764/6 "2020-02-25T07:04:02Z")
It does seem very sensible and relevant. Except for “Message Scheduling for complex busses”, of course. I would have declined to contribute only if it were about time-triggered communication, but message scheduling does not necessarily imply TT. Asynchronous message scheduling exists and it does not require TT: ![image](https://forum.opencyphal.org/uploads/default/original/1X/ac2e9c2c49ab48f2853884b65d67dfcc72432af2.jpeg) But, what I meant when I said about posting here is that if we are ready to share a bit of UAVCAN wisdom with the world, we should make a forum thread or a dozen and let them sit for a while. Collect questions and criticism, etc. Kind of what I attempted to do here: [Idempotent interfaces and deterministic data loss mitigation](https://forum.opencyphal.org/t/idempotent-interfaces-and-deterministic-data-loss-mitigation/643), or maybe even here: [RTOS CAN API requirements](https://forum.opencyphal.org/t/rtos-can-api-requirements/706). Then, having a critical mass of such items accumulated, we could squeeze them all into an e-book, slap a cat pic on top, and ship it ![image](https://forum.opencyphal.org/uploads/default/original/1X/8f533976896600804aef58bf352eaaee0914a7f9.png). --- _[View the full topic](https://forum.opencyphal.org/t/what-should-our-logging-format-be/764)._