Add a doc on guidelines for contributing a new dialect to the MLIR core repo

Closes tensorflow/mlir#263

PiperOrigin-RevId: 284760931

diff --git a/mlir/g3doc/DeveloperGuide.md b/mlir/g3doc/DeveloperGuide.md
index a4ba9ec..7450099 100644 (file)
--- a/mlir/g3doc/DeveloperGuide.md
+++ b/mlir/g3doc/DeveloperGuide.md
@@ -51,3 +51,57 @@ pipeline.
 ## Testing guidelines
 
 See here for the [testing guide](TestingGuide.md).
+
+## Guidelines on contributing a new dialect (or important components)
+
+To contribute a dialect (or a major component in MLIR), it is usual to write an
+overview "RFC" (it can be just a few informal paragraphs) and send it to the
+MLIR mailing list. When accepting a new component to MLIR, the community is also
+accepting the burden of maintaining it. The following points should be
+considered when evaluating whether a dialect is a good fit for the core MLIR
+repository:
+
+*   What is the overall goal of the dialect? What is the first implementation
+    milestone?
+*   How does it fit into the MLIR dialect ecosystem?
+    *   Connection: how does it connect to the existing dialects in a
+        compilation pipeline(s)?
+    *   Consolidation: is there already a dialect with a similar goal or
+        matching abstractions; if so, can it be improved instead of adding a new
+        one?
+    *   Reuse: how does it generalize to similar but slightly different
+        use-cases?
+*   What is the community of users that it is serving?
+*   Who are the future contributors/maintainers beyond those who propose the
+    dialect?
+
+On a practical aspect, we will expect the code to follow the other sections of
+this document, with an emphasis on the documentation alongside the source code.
+
+It is prefered to upstream your dialects/components in small incremental patches
+that can be individually reviewed. That is, after the initial RFC has been
+agreed on, we encourage dialects to be built progressively by faster iterations
+in-tree; as long as it is clear they evolve towards their milestones and goals.
+
+We have seen the following broad categories of dialects:
+
+*   Edge dialects that model a representation external to MLIR. Examples include
+    LLVM, SPIR-V dialects, TensorFlow, XLA/HLO, ... Such dialects may be a
+    better fit for the project that contains the original representation instead
+    of being added to the MLIR repository. In particular, because MLIR will not
+    take an external dependency on another project.
+*   Structured Abstraction dialects that generalize common features of several
+    other dialects or introduce a programming model. Generalization is sometimes
+    demonstrated by having several dialects lower to or originate from a new
+    dialect. While additional abstractions may be useful, they should be traded
+    off against the additional complexity of the dialect ecosystem. Examples of
+    abstraction dialects include the GPU and Loop dialects.
+*   Transformation dialects that serve as input/output for program
+    transformations. These dialects are commonly introduced to materialize
+    transformation pre- and post-conditions in the IR, while conditions can be
+    obtained through analysis or through operation semantics. Examples include
+    Affine and Linalg dialects.
+
+While it can be useful to frame the goals of a proposal, this categorization is
+not exhaustive or absolute, and the community is open to discussing any new
+dialect beyond this taxonomy.