Thanks for taking this initiative Renato! While this doesn’t completely alleviate my concerns with the addition of the Bazel build system, I think this proposal is valuable in and of itself. It’s worthwhile to have documented policies so that community members who are not in the in-group can point to a violation and state that it’s wrong without needing to have an excess level of clout or coalition to lend their words weight. I’ve suggested a few changes inline below, but I think this is largely reasonable.
I think talk of committing the Bazel build system to the repo should be tabled until we can ratify this policy, and then it should be re-proposed in terms of how it fits in with this policy. If Bazel is accepted into the repository in conformance with an existing policy that can be enforced, my misgivings would be lessened.
*** Tier 1: the core compiler, which must work at all times.
- Front-ends, back-ends, middle-ends, libraries, core APIs, official projects and tools.
- The CMake build infrastructure.
- Builds on all first class citizen combinations of targets x OSs. 
- have noisy green bots
- revert on failure policy
*** Tier 2: side projects that integrate with the compiler and that should work at all times.
- Experimental targets, infrastructure and APIs, non-default cmd-line options
- Alternative build systems (ex. GN, Bazel)
I would suggest: that it must have a subcommunity that cares about it
It must not:
- Break or hinder tier 1
- Increase validation noise beyond its scope
- Have green buildbots, handled by the sub-community that cares about it
- Have notifications only to those interested when things break (avoid bitrot)
Sub-communities that care about it must fix issues in them, but the rest of the community has no obligations to support it. Lack of maintenance could be subject to removal.
I would suggest: that lack of maintenance will be cause for removal. Perhaps a timetable should be stated? (“if it’s red for more than 1 month, it is subject to removal?”)
*** Tier 3: miscellaneous accessories
- Helper scripts, editor files, debugger scripts, etc.
- Whatever is detached enough that bit rot is irrelevant
It sounds to me like the basic difference between tier 2 and 3 is that tier 2 needs to have a (quiet) build bot, and tier 3 does not need a build bot? If so, we should state the requirement for a public build bot under tier 2.