message: Add a doc on guidelines for contributing a new dialect to the MLIR core repo
  Closes
diff: @@ -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.
  