Add code of conduct and coding standards - #19
Conversation
| ## 7. Maintain a Positive Community | ||
| This project exists to learn, build, and have fun. Help keep it welcoming and friendly. | ||
|
|
||
| ## 8. Create Memes |
|
|
||
| ## 9. Logging & Observability | ||
| 1. Use the contextual logging macros (`info!(ctx => ...)`, etc.) with a required `LogContext`, unless intentionally using "default". | ||
| 2. Configure logging per context using strings like ecs = debug and follow consistent log-level semantics. |
There was a problem hiding this comment.
This is unclear to me - what do you mean by ecs = debug?
There was a problem hiding this comment.
Yeah, there is extremaly useful configurable logging system implemented in the engine but not documented anywhere properly. This line refers to it. I will document it.
| 1. Use the contextual logging macros (`info!(ctx => ...)`, etc.) with a required `LogContext`, unless intentionally using "default". | ||
| 2. Configure logging per context using strings like ecs = debug and follow consistent log-level semantics. | ||
| 3. Keep log messages clear and descriptive, avoiding abbreviations. | ||
| 4. Use the project's Timer utility when measuring execution time for functions, subsystems, or critical paths. |
There was a problem hiding this comment.
| 4. Use the project's Timer utility when measuring execution time for functions, subsystems, or critical paths. | |
| 4. Use the project's `Timer` utility when measuring execution time for functions, subsystems, or critical paths. |
There was a problem hiding this comment.
Same here, timer system has to be documented
| 2. Request feedback early for architectural changes. | ||
| 3. Review for correctness, clarity, and idiomatic usage. | ||
|
|
||
| ## 11. Version Control |
There was a problem hiding this comment.
Here I would also be more specific - should we follow kernel guidelines? Use conventional commits? I would be for the latter as we enter a stage of bigger maturity of the project and once it is very mature it would make the commit bisection/triage easier when the commits are more self-descriptive.
Also what is our policy regarding commit squashing and merging/rebasing?
There was a problem hiding this comment.
Can you propose something? I'm not that experienced in this
There was a problem hiding this comment.
In my opinion conventional commits are easy enough because one can see which part of the engine we are touching. Ideally it follows the folder/project structure. The website describes it quite nicely:
featfor a new featurefixfor a bugfixBREAKING CHANGEor prepending the commit name with!(although I would use something else here as!is easy to ommit.- I used others in past like
docsorinfrato specify either documentation or infrastructure (in this case toolchain/core compilator/libs changes) we could also useci
Lastly I would expect to have, for example, such commitsfeat(zapping): Add zapping system that periodically flabbergast doodahs.Or we could do it by splitting per-system or subproject - but IMO that is too coarse-grained.
What do you think?
3 participants
No description provided.