This is something I’ve heard from you on multiple occasions: Perhaps you could go the next step and help make this actionable? If there are things in MLIR that really don’t follow the policy, then can you bring them up (specifically) with the goal of making the code better and without making personal judgments, rather than leaving it as a vague critique?
FWIW, I looked through all of the developer policies and couldn’t find anything about ‘code standards’ as a requirement. There is significant mention of a ‘active communities’ and ‘nightly builds that don’t break’ and ‘promptly fixing bugs’ and ‘aligned with the needs of a compiler’… In particular “stability” is discussed primarily in terms of “not breaking the tests/nighlty builds”, and not in terms of “stuff never changes”. Maybe I’m missing something, or you perhaps have additional standards in mind and this is what you want to discuss?
I personally think that there "either* needs to be space for experimentation (such as within the scope of peripheral code, and not compiled by default features or experimental backends/dialects) OR there needs to be an effective process by which experimentation can happen outside and later be merged as larger projects. Without one of these options, then only incremental changes can/will happen. Clearly we need to balance stability and change, in order to enable real world ‘products’ while allowing continued to evolution and growth.