[llvm] [docs] Strengthen our quality standards and connect AI contribution policy to it (PR #154441)

[Reid Kleckner via llvm-commits]

================
@@ -293,57 +293,63 @@ warranted when performing a code review.
 Quality
 -------
 
-The minimum quality standards that any change must satisfy before being
-committed to the main development branch are:
-
-#. Code must adhere to the `LLVM Coding Standards <CodingStandards.html>`_.
-
-#. Code must compile cleanly (no errors, no warnings) on at least one platform.
+Sending patches, PRs, RFCs, comments, etc to LLVM, is not free -- it takes a lot
+of maintainer time and energy to review those contributions. Our quality bar can
+be summarized with the **golden rule** that a contribution should be worth more
+to the project than the time it takes to review it.
+
+However, this rule is held in balance with our goal to make the LLVM project
+welcoming and open to aspiring compiler engineers who are willing to invest time
+and effort to learn and grow, because growing our contributor base and
+potentially recruiting new maintainers helps sustain the project over the long
+term.
+
+Contributors who repeatedly make low-value contributions according to the
+standards of our maintainers will be asked to increase the quality of their
+contributions or cease contributing. As a community, we encourage maintainers to
+invest effort in reviewing work from new contributors. We label PRs from
+first-time contributors to set maintainer expectations on quality. However, we
+expect to see a growth pattern in the quality of a contributor's work over time.
+Maintainers can use their discretion and push back against burdensome
+contributions and ask contributors to meet their quality bar. In addition to the
+minimum guidelines outlined in thie section, maintainers can set their own
+quality standards using their considerable domain expertise.
+
+The following is a checklist of some of the minimum quality standards that any
+change must satisfy before being reviewed in detail or committed to the main
+development branch:
 
 #. Bug fixes and new features should `include a testcase`_ so we know if the
    fix/feature ever regresses in the future.
 
-#. Code must pass the ``llvm/test`` test suite.
+#. The code should compile cleanly on all supported platforms.
 
-#. The code must not cause regressions on a reasonable subset of llvm-test,
-   where "reasonable" depends on the contributor's judgement and the scope of
-   the change (more invasive changes require more testing). A reasonable subset
-   might be something like "``llvm-test/MultiSource/Benchmarks``".
+#. Code must pass the relevant regression test suites on all supported
----------------
rnk wrote:

> LLVM doesn't really have a good concept of what a "supported platform" is.

I guess I think we should define LLVM-wide project support tiers similar to what [Rust](https://doc.rust-lang.org/beta/rustc/platform-support.html) and [libc++](https://libcxx.llvm.org/#platform-and-compiler-support) have, but until we have those, I agree, it's more helpful to rephrase this in terms of passing premerge build & test, and then the policy becomes evergreen, defined by our CI config.

https://github.com/llvm/llvm-project/pull/154441