Update references to the mailing list to reference Discourse. Also update references to LLVM Bugzilla as we have moved to GitHub issues.

[lattner]

This looks really great to me, thank you for updating this!

llvm/docs/DeveloperPolicy.rst

 LLVM, but we expect more from frequent contributors to keep the system as
 efficient as possible for everyone.  Frequent LLVM contributors are expected to
 meet the following requirements in order for LLVM to maintain a high standard of
 quality.
 
 Stay Informed
 -------------
 
-Developers should stay informed by reading at least the "dev" mailing list for
-the projects you are interested in, such as `llvm-dev
-<http://lists.llvm.org/mailman/listinfo/llvm-dev>`_ for LLVM, `cfe-dev
-<http://lists.llvm.org/mailman/listinfo/cfe-dev>`_ for Clang, or `lldb-dev
-<http://lists.llvm.org/mailman/listinfo/lldb-dev>`_ for LLDB.  If you are
-doing anything more than just casual work on LLVM, it is suggested that you also
+Developers should stay informed by reading the `LLVM Discourse forums`_. 
+If you are doing anything more than just casual work on LLVM, it is suggested that you also
 subscribe to the "commits" mailing list for the subproject you're interested in,
 such as `llvm-commits
 <http://lists.llvm.org/mailman/listinfo/llvm-commits>`_, `cfe-commits
 <http://lists.llvm.org/mailman/listinfo/cfe-commits>`_, or `lldb-commits
 <http://lists.llvm.org/mailman/listinfo/lldb-commits>`_.  Reading the
 "commits" list and paying attention to changes being made by others is a good
 way to see what other people are interested in and watching the flow of the
 project as a whole.
 
-We recommend that active developers register an email account with `LLVM
-Bugzilla <https://bugs.llvm.org/>`_ and preferably subscribe to the `llvm-bugs
+We recommend that active developers monitor incoming issues to our `GitHub issue tracker <https://github.com/llvm/llvm-project/issues>`_ and preferably subscribe to the `llvm-bugs
 <http://lists.llvm.org/mailman/listinfo/llvm-bugs>`_ email list to keep track
 of bugs and enhancements occurring in LLVM.  We really appreciate people who are
 proactive at catching incoming bugs in their components and dealing with them
 promptly.
 
-Please be aware that all public LLVM mailing lists are public and archived, and
+Please be aware that all public LLVM mailing lists and discourse forums are public and archived, and
 that notices of confidentiality or non-disclosure cannot be respected.
 
 .. _patch:
 .. _one-off patches:
 
 Making and Submitting a Patch
 -----------------------------
 
* The changes should not cause any correctness regressions in the ``llvm-test``
   suite and must not cause any major performance regressions.
 
 * The change set should not cause performance or correctness regressions for the
   LLVM tools.
 
 * The changes should not cause performance or correctness regressions in code
   compiled by LLVM on all applicable targets.
 
-* You are expected to address any `Bugzilla bugs <https://bugs.llvm.org/>`_ that
+* You are expected to address any `GitHub Issues <https://github.com/llvm/llvm-project/issues>`_ that
   result from your change.
 
 We prefer for this to be handled before submission but understand that it isn't
 possible to test all of this for every submission.  Our build bots and nightly
 testing infrastructure normally finds these problems.  A good rule of thumb is
 to check the nightly testers for regressions the day after your change.  Build
 bots will directly email you if a group of commits that included yours caused a
 failure.  You are expected to check the build bot messages to see if they are

 
 * The body, if it exists, should be separated from the title by an empty line.
 
 * The body should be concise, but explanatory, including a complete
   reasoning.  Unless it is required to understand the change, examples,
   code snippets and gory details should be left to bug comments, web
   review or the mailing list.
 
-* If the patch fixes a bug in bugzilla, please include the PR# in the message.
+* If the patch fixes a bug in GitHub Issues, please include the PR# in the message.
 
 * Text formatting and spelling should follow the same rules as documentation
   and in-code comments, ex. capitalization, full stop, etc.
 
 * If the commit is a bug fix on top of another recently committed patch, or a
   revert or reapply of a patch, include the git commit hash of the prior
   related commit. This could be as simple as "Revert commit NNNN because it
   caused PR#".

 to do so.
 
 .. _discuss the change/gather consensus:
 
 Making a Major Change
 ---------------------
 
 When a developer begins a major new project with the aim of contributing it back
-to LLVM, they should inform the community with an email to the `llvm-dev
-<http://lists.llvm.org/mailman/listinfo/llvm-dev>`_ email list, to the extent
+to LLVM, they should inform the community with a post to the `LLVM Discourse forums`_, to the extent
 possible. The reason for this is to:
 
 #. keep the community informed about future changes to LLVM,
 
 #. avoid duplication of effort by preventing multiple parties working on the
    same thing and not knowing about it, and
 
 #. ensure that any technical issues around the proposed work are discussed and
* Release stability: We won't break the C API on the release branch with patches
   next release.
 
 * Testing: Patches to the C API are expected to come with tests just like any
   other patch.
 
 * Including new things into the API: If an LLVM subcomponent has a C API already
   included, then expanding that C API is acceptable. Adding C API for
   subcomponents that don't currently have one needs to be discussed on the
-  mailing list for design and maintainability feedback prior to implementation.
+  `LLVM Discourse forums`_ for design and maintainability feedback prior to implementation.
 
 * Documentation: Any changes to the C API are required to be documented in the
   release notes so that it's clear to external users who do not follow the
   project how the C API is changing and evolving.
 
 .. _toolchain:
 
 Updating Toolchain Requirements
 -------------------------------
 
 We intend to require newer toolchains as time goes by. This means LLVM's
 codebase can use newer versions of C++ as they get standardized. Requiring newer
 toolchains to build LLVM can be painful for those building LLVM; therefore, it
 will only be done through the following process:
 
   * It is a general goal to support LLVM and GCC versions from the last 3 years
     at a minimum. This time-based guideline is not strict: we may support much
     older compilers, or decide to support fewer versions.
 
-  * An RFC is sent to the `llvm-dev mailing list`_
+  * An RFC is sent to the `LLVM Discourse forums`_
 
     - Detail upsides of the version increase (e.g. which newer C++ language or
       library features LLVM should use; avoid miscompiles in particular compiler
       versions, etc).
     - Detail downsides on important platforms (e.g. Ubuntu LTS status).
 
   * Once the RFC reaches consensus, update the CMake toolchain version checks as
     well as the :doc:`getting started<GettingStarted>` guide.  This provides a
     softer transition path for developers compiling LLVM, because the
     error can be turned into a warning using a CMake flag. This is an important
     step: LLVM still doesn't have code which requires the new toolchains, but it
-    soon will. If you compile LLVM but don't read the mailing list, we should
+    soon will. If you compile LLVM but don't read the forums, we should
     tell you!
 
   * Ensure that at least one LLVM release has had this soft-error. Not all
     developers compile LLVM top-of-tree. These release-bound developers should
     also be told about upcoming changes.
 
   * Turn the soft-error into a hard-error after said LLVM release has branched.
 
   * Update the :doc:`coding standards<CodingStandards>` to allow the new
     features we've explicitly approved in the RFC.
 
   * Start using the new features in LLVM's codebase.
 
 Here's a `sample RFC
-<http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html>`_ and the
+<https://discourse.llvm.org/t/rfc-migrating-past-c-11/50943>`_ and the
 `corresponding change <https://reviews.llvm.org/D57264>`_.
 
 .. _ci-usage:
 
 Working with the CI system
 --------------------------
 
 The main continuous integration (CI) tool for the LLVM project is the

 have a general :doc:`support policy<SupportPolicy>` for introducing major new
 components into the LLVM world, depending on the degree of detail and
 responsibility required. *Core* projects need a higher degree of scrutiny
 than *peripheral* projects, and the latter may have additional differences.
 
 However, this is really only intended to cover common cases
 that we have seen arise: different situations are different, and we are open
 to discussing unusual cases as well - just start an RFC thread on the
-`llvm-dev mailing list`_.
+`LLVM Discourse forums`_.
 
 Adding a New Target
 -------------------
 
 LLVM is very receptive to new targets, even experimental ones, but a number of
 problems can appear when adding new large portions of code, and back-ends are
 normally added in bulk. New targets need the same level of support as other
 *core* parts of the compiler, so they are covered in the *core tier* of our

 status, but also markers to define bit-rot, and will be used to clean up the
 tree from unmaintained targets.
 
 Those wishing to add a new target to LLVM must follow the procedure below:
 
 1. Read this section and make sure your target follows all requirements. For
    minor issues, your community will be responsible for making all necessary
    adjustments soon after the initial merge.
-2. Send a request for comment (RFC) to the llvm-dev@ mailing list, describing
+2. Send a request for comment (RFC) to the `LLVM Discourse forums`_ describing
    your target and how it follows all the requirements and what work has been
    done and will need to be done to accommodate the official target requirements.
    Make sure to expose any and all controversial issues, changes needed in the
    base code, table gen, etc.
 3. Once the response is positive, the LLVM community can start reviewing the
    actual patches (but they can be prepared before, to support the RFC). Create
    a sequence of N patches, numbered '1/N' to 'N/N' (make sure N is an actual
    number, not the letter 'N'), that completes the basic structure of the target.
 4. The initial patch should add documentation, code owners and triple support in
    clang and LLVM. The following patches add TableGen infrastructure to describe
    the target and lower instructions to assembly. The final patch must show that
    the target can lower correctly with extensive LIT tests (IR to MIR, MIR to
    ASM, etc).
 5. Some patches may be approved before others, but only after *all* patches are
    approved that the whole set can be merged in one go. This is to guarantee
    that all changes are good as a single block.
 6. After the initial merge, the target community can stop numbering patches and
    start working asynchronously on the target to complete support. They should
    still seek review from those who helped them in the initial phase, to make
    sure the progress is still consistent.
 7. Once all official requirements have been fulfilled (as above), the code owner
    should request the target to be enabled by default by sending another RFC to
-   the llvm-dev@ mailing list.
+   the `LLVM Discourse forums`_.
 
 Adding an Established Project To the LLVM Monorepo
 --------------------------------------------------
 
 The `LLVM monorepo <https://github.com/llvm/llvm-project>`_ is the centerpoint
 of development in the LLVM world, and has all of the primary LLVM components,
 including the LLVM optimizer and code generators, Clang, LLDB, etc.  `Monorepos
 in general <https://en.wikipedia.org/wiki/Monorepo>`_ are great because they
* Should have CI to catch breakage within the project itself or due to
    underlying LLVM dependencies.
  * Should have code free of issues the community finds contentious, or be on a
    clear path to resolving them.
  * Must be proposed through the LLVM RFC process, and have its addition approved
    by the LLVM community - this ultimately mediates the resolution of the
    "should" concerns above.
 
 If you have a project that you think would make sense to add to the LLVM
-monorepo, please start an RFC thread on the `llvm-dev mailing list`_ to kick off
+monorepo, please start an RFC topic on the `LLVM Discourse forums`_ to kick off
 the discussion.  This process can take some time and iteration - please don’t
 be discouraged or intimidated by that!
 
 If you have an earlier stage project that you think is aligned with LLVM, please
 see the "Incubating New Projects" section.
 
 Incubating New Projects
 -----------------------

  * A new repository in the LLVM Github Organization - but not the LLVM monorepo.
  * New mailing list, discourse forum, and/or discord chat hosted with other LLVM
    forums.
  * Other infrastructure integration can be discussed on a case-by-case basis.
 
 Graduation to the mono-repo would follow existing processes and standards for
 becoming a first-class part of the monorepo.  Similarly, an incubating project
 may be eventually retired, but no process has been established for that yet.  If
-and when this comes up, please start an RFC discussion on llvm-dev.
+and when this comes up, please start an RFC discussion on the `LLVM Discourse forums`_.
 
 This process is very new - please expect the details to change, it is always
-safe to ask on the `llvm-dev mailing list`_ about this.
+safe to ask on the `LLVM Discourse forums`_ about this.
 
 Suggested disclaimer for the project README and the main project web page:
 
 ::
 
    This project is participating in the LLVM Incubator process: as such, it is
    not part of any official LLVM release.  While incubation status is not
    necessarily a reflection of the completeness or stability of the code, it

 
 In certain circumstances, code licensed under other licenses can be added
 to the codebase.  However, this may only be done with approval of the LLVM
 Foundation Board of Directors, and contributors should plan for the approval
 process to take at least 4-6 weeks.  If you would like to contribute code
 under a different license, please create a Phabricator review with the code
 you want to contribute and email [e-mail] requesting a review.
 
-If you have questions or comments about these topics, please contact the
-`LLVM Developer's Mailing List <mailto:[e-mail]>`_.  However,
+If you have questions or comments about these topics, please ask on the
+`LLVM Discourse forums`_.  However,
 please realize that most compiler developers are not lawyers, and therefore you
 will not be getting official legal advice.
 
 Copyright
 ---------
 
 The LLVM project does not collect copyright assignments, which means that the
 copyright for the code in the project is held by the respective contributors.

 you agree that any contributions to these libraries be licensed under both
 licenses.  We feel that this is important for runtime libraries, because they
 are implicitly linked into applications and therefore should not subject those
 applications to the binary redistribution clause. This also means that it is ok
 to move code from (e.g.)  libc++ to the LLVM core without concern, but that code
 cannot be moved from the LLVM core to libc++ without the copyright owner's
 permission.
 
-.. _llvm-dev mailing list: http://lists.llvm.org/mailman/listinfo/llvm-dev
+.. _LLVM Discourse forums: https://discourse.llvm.org