[clang] [libunwind] [llvm] Replace documentation mentions of IRC with Discord (PR #114276)
via cfe-commits
cfe-commits at lists.llvm.org
Wed Oct 30 10:25:35 PDT 2024
llvmbot wrote:
<!--LLVM PR SUMMARY COMMENT-->
@llvm/pr-subscribers-clang
Author: Aaron Ballman (AaronBallman)
<details>
<summary>Changes</summary>
This does not touch code owners or credits files that list IRC handles, that can be done separately if we want to make that change.
See https://discourse.llvm.org/t/rfc-remove-irc-as-a-recommended-communication-channel/82808/3 for the RFC.
---
Patch is 147.25 KiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/114276.diff
9 Files Affected:
- (modified) clang/www/OpenProjects.html (+2-2)
- (modified) libunwind/docs/index.rst (+1-1)
- (modified) llvm/docs/CodeOfConduct.rst (+6-6)
- (modified) llvm/docs/CodeReview.rst (+2-2)
- (modified) llvm/docs/Contributing.rst (+1-1)
- (modified) llvm/docs/DeveloperPolicy.rst (+1388-1388)
- (modified) llvm/docs/GettingInvolved.rst (+8-18)
- (modified) llvm/docs/ResponseGuide.rst (+2-3)
- (modified) llvm/docs/_templates/indexsidebar.html (+1-1)
``````````diff
diff --git a/clang/www/OpenProjects.html b/clang/www/OpenProjects.html
index 5d0b7aaccd89d2..d48b3bebe76110 100755
--- a/clang/www/OpenProjects.html
+++ b/clang/www/OpenProjects.html
@@ -160,8 +160,8 @@ <h1>Open Clang Projects</h1>
<p>If you hit a bug with Clang, it is very useful for us if you reduce the code
that demonstrates the problem down to something small. There are many ways to
do this; ask on <a href="https://discourse.llvm.org/c/clang">Discourse</a>,
-<a href="https://discord.com/channels/636084430946959380/636725486533345280">Discord</a>,
-or <a href="https://llvm.org/docs/GettingInvolved.html#irc"IRC</a> for advice.</p>
+<a href="https://discord.com/channels/636084430946959380/636725486533345280">Discord</a>
+for advice.</p>
</div>
</body>
diff --git a/libunwind/docs/index.rst b/libunwind/docs/index.rst
index e1283e7acfcc2a..03542464011461 100644
--- a/libunwind/docs/index.rst
+++ b/libunwind/docs/index.rst
@@ -78,7 +78,7 @@ and `Getting started with LLVM <https://llvm.org/docs/GettingStarted.html>`__.
If you think you've found a bug in libunwind, please report it using
the `LLVM bug tracker`_. If you're not sure, you
-can ask for support on the `Runtimes forum`_ or on IRC.
+can ask for support on the `Runtimes forum`_ or on Discord.
Please use the tag "libunwind" for new threads.
**Patches**
diff --git a/llvm/docs/CodeOfConduct.rst b/llvm/docs/CodeOfConduct.rst
index f8fff8bac52a5e..d5afd5481f7c7a 100644
--- a/llvm/docs/CodeOfConduct.rst
+++ b/llvm/docs/CodeOfConduct.rst
@@ -24,12 +24,12 @@ the spirit in which it's intended - a guide to make it easier to communicate
and participate in the community.
This code of conduct applies to all spaces managed by the LLVM project or The
-LLVM Foundation. This includes IRC channels, mailing lists, bug trackers, LLVM
-events such as the developer meetings and socials, and any other forums created
-by the project that the community uses for communication. It applies to all of
-your communication and conduct in these spaces, including emails, chats, things
-you say, slides, videos, posters, signs, or even t-shirts you display in these
-spaces.
+LLVM Foundation. This includes Discord channels, mailing lists, bug trackers,
+LLVM events such as the developer meetings and socials, and any other forums
+created by the project that the community uses for communication. It applies to
+all of your communication and conduct in these spaces, including emails, chats,
+things you say, slides, videos, posters, signs, or even t-shirts you display in
+these spaces.
In rare cases, violations of this code outside of these spaces may affect a
person’s ability to participate within these spaces. Important examples
diff --git a/llvm/docs/CodeReview.rst b/llvm/docs/CodeReview.rst
index 56798ae4faf0c4..a49d130bba4f6b 100644
--- a/llvm/docs/CodeReview.rst
+++ b/llvm/docs/CodeReview.rst
@@ -248,8 +248,8 @@ larger features. Common ways to speed up review times for your patches are:
get this patch landed and ping it every couple of days. If it is
not urgent, the common courtesy ping rate is one week. Remember that you're
asking for valuable time from other professional developers.
-* Ask for help on IRC. Developers on IRC will be able to either help you
- directly, or tell you who might be a good reviewer.
+* Ask for help on Discord. Developers on Discord will be able to either help
+ you directly, or tell you who might be a good reviewer.
* Split your patch into multiple smaller patches that build on each other. The
smaller your patch is, the higher the probability that somebody will take a quick
look at it. When doing this, it is helpful to add "[N/M]" (for 1 <= N <= M) to
diff --git a/llvm/docs/Contributing.rst b/llvm/docs/Contributing.rst
index 17477d1c044d76..2f8ce7b7a1055e 100644
--- a/llvm/docs/Contributing.rst
+++ b/llvm/docs/Contributing.rst
@@ -6,7 +6,7 @@ Contributing to LLVM
Thank you for your interest in contributing to LLVM! There are multiple ways to
contribute, and we appreciate all contributions. In case you have questions,
you can either use the `Forum`_ or, for a more interactive chat, go to our
-`Discord server`_ or the IRC #llvm channel on `irc.oftc.net`_.
+`Discord server`_.
If you want to contribute code, please familiarize yourself with the :doc:`DeveloperPolicy`.
diff --git a/llvm/docs/DeveloperPolicy.rst b/llvm/docs/DeveloperPolicy.rst
index 0ecf1423e60371..ffaece9fb12bbf 100644
--- a/llvm/docs/DeveloperPolicy.rst
+++ b/llvm/docs/DeveloperPolicy.rst
@@ -1,1388 +1,1388 @@
-.. _developer_policy:
-
-=====================
-LLVM Developer Policy
-=====================
-
-.. contents::
- :local:
-
-Introduction
-============
-
-This document contains the LLVM Developer Policy which defines the project's
-policy towards developers and their contributions. The intent of this policy is
-to eliminate miscommunication, rework, and confusion that might arise from the
-distributed nature of LLVM's development. By stating the policy in clear terms,
-we hope each developer can know ahead of time what to expect when making LLVM
-contributions. This policy covers all llvm.org subprojects, including Clang,
-LLDB, libc++, etc.
-
-This policy is also designed to accomplish the following objectives:
-
-#. Attract both users and developers to the LLVM project.
-
-#. Make life as simple and easy for contributors as possible.
-
-#. Keep the top of tree as stable as possible.
-
-#. Establish awareness of the project's :ref:`copyright, license, and patent
- policies <copyright-license-patents>` with contributors to the project.
-
-This policy is aimed at frequent contributors to LLVM. People interested in
-contributing one-off patches can do so in an informal way by sending them to the
-`llvm-commits mailing list
-<http://lists.llvm.org/mailman/listinfo/llvm-commits>`_ and engaging another
-developer to see it through the process.
-
-Developer Policies
-==================
-
-This section contains policies that pertain to frequent LLVM developers. We
-always welcome `one-off patches`_ from people who do not routinely contribute to
-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 the `LLVM Discourse forums`_ and subscribing
-to the categories of interest for notifications.
-
-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.
-
-Contibutions to the project are made through :ref:`GitHub Pull Requests <github-reviews>`.
-You can subscribe to notification for areas of the codebase by joining
-one of the `pr-subscribers-* <https://github.com/orgs/llvm/teams?query=pr-subscribers>`_
-GitHub teams. This `mapping <https://github.com/llvm/llvm-project/blob/main/.github/new-prs-labeler.yml>`_
-indicates which team is associated with a particular paths in the repository.
-
-You can also subscribe to the "commits" mailing list for a 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>`_.
-
-Missing features and bugs are tracked through our `GitHub issue tracker <https://github.com/llvm/llvm-project/issues>`_
-and assigned labels. We recommend that active developers monitor incoming issues.
-You can subscribe for notification for specific components by joining
-one of the `issue-subscribers-* <https://github.com/orgs/llvm/teams?query=issue-subscribers>`_
-teams.
-You may also subscribe to the `llvm-bugs
-<http://lists.llvm.org/mailman/listinfo/llvm-bugs>`_ email list to keep track
-of bugs and enhancements occurring in the entire project. 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 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
------------------------------
-
-When making a patch for review, the goal is to make it as easy for the reviewer
-to read it as possible. As such, we recommend that you:
-
-#. Make your patch against git main, not a branch, and not an old version
- of LLVM. This makes it easy to apply the patch. For information on how to
- clone from git, please see the :ref:`Getting Started Guide <sources>`.
-
-#. Similarly, patches should be submitted soon after they are generated. Old
- patches may not apply correctly if the underlying code changes between the
- time the patch was created and the time it is applied.
-
-#. Once you have created your patch, create a
- :ref:`GitHub Pull Request <github-reviews>` for
- it (or commit it directly if applicable).
-
-When submitting patches, please do not add confidentiality or non-disclosure
-notices to the patches themselves. These notices conflict with the LLVM
-licensing terms and may result in your contribution being excluded.
-
-The LLVM project uses email to communicate to contributors outside of the
-GitHub platform about their past contributions. Primarily, our buildbot
-infrastructure uses emails to contact contributors about build and test
-failures. Therefore, the LLVM community requires contributors to have a public
-email address associated with their GitHub commits, so please ensure that "Keep
-my email addresses private" is disabled in your
-`account settings <https://github.com/settings/emails>`_.
-
-.. _code review:
-
-Code Reviews
-------------
-
-LLVM has a code-review policy. Code review is one way to increase the quality of
-software. Please see :doc:`CodeReview` for more information on LLVM's code-review
-process.
-
-.. _breaking:
-
-Making Potentially Breaking Changes
------------------------------------
-
-Please help notify users and vendors of potential disruptions when upgrading to
-a newer version of a tool. For example, deprecating a feature that is expected
-to be removed in the future, removing an already-deprecated feature, upgrading a
-diagnostic from a warning to an error, switching important default behavior, or
-any other potentially disruptive situation thought to be worth raising
-awareness of. For such changes, the following should be done:
-
-.. warning::
-
- Phabricator is deprecated is available in read-only mode,
- for new code contributions use :ref:`GitHub Pull Requests <github-reviews>`.
- This section contains old information that needs to be updated.
-
-* When performing the code review for the change, please add any applicable
- "vendors" group to the review for their awareness. The purpose of these
- groups is to give vendors early notice that potentially disruptive changes
- are being considered but have not yet been accepted. Vendors can give early
- testing feedback on the changes to alert us to unacceptable breakages. The
- current list of vendor groups is:
-
- * `Clang vendors <https://reviews.llvm.org/project/members/113/>`_
- * `libc++ vendors <https://reviews.llvm.org/project/members/109/>`_
-
- People interested in joining the vendors group can do so by clicking the
- "Join Project" link on the vendor's "Members" page in Phabricator.
-
-* When committing the change to the repository, add appropriate information
- about the potentially breaking changes to the ``Potentially Breaking Changes``
- section of the project's release notes. The release note should have
- information about what the change is, what is potentially disruptive about
- it, as well as any code examples, links, and motivation that is appropriate
- to share with users. This helps users to learn about potential issues with
- upgrading to that release.
-
-* After the change has been committed to the repository, the potentially
- disruptive changes described in the release notes should be posted to the
- `Announcements <https://discourse.llvm.org/c/announce/>`_ channel on
- Discourse. The post should be tagged with the ``potentially-breaking`` label
- and a label specific to the project (such as ``clang``, ``llvm``, etc). This
- is another mechanism by which we can give pre-release notice to users about
- potentially disruptive changes. It is a lower-traffic alternative to the
- joining "vendors" group. To automatically be notified of new announcements
- with the ``potentially-breaking`` label, go to your user preferences page in
- Discourse, and add the label to one of the watch categories under
- ``Notifications->Tags``.
-
-.. _maintainers:
-
-Maintainers
------------
-
-The LLVM Project aims to evolve features quickly while continually being in a
-release-ready state. In order to accomplish this, the project needs volunteers
-willing to do the less glamorous work to ensure we produce robust, high-quality
-products.
-
-Maintainers are those volunteers; they are regular contributors who volunteer
-to take on additional community responsibilities beyond code contributions.
-Community members can find active and inactive maintainers for a project in the
-``Maintainers.rst`` file at the root directory of the individual project.
-
-Maintainers are volunteering to take on the following shared responsibilities
-within an area of a project:
-
- * ensure that commits receive high-quality review, either by the maintainer
- or by someone else,
- * help to confirm and comment on issues,
- * mediate code review disagreements through collaboration with other
- maintainers (and other reviewers) to come to a consensus on how best to
- proceed with disputed changes,
- * actively engage with relevant RFCs,
- * aid release managers with backporting and other release-related
- activities,
- * be a point of contact for contributors who need help (answering questions
- on Discord/Discourse/IRC or holding office hours).
-
-Each top-level project in the monorepo will specify one or more
-lead maintainers who are responsible for ensuring community needs are
-met for that project. This role is like any other maintainer role,
-except the responsibilities span the project rather than a limited area
-within the project. If you cannot reach a maintainer or don't know which
-maintainer to reach out to, a lead maintainer is always a good choice
-to reach out to. If a project has no active lead maintainers, it may be a
-reasonable candidate for removal from the monorepo. A discussion should be
-started on Discourse to find a new, active lead maintainer or whether the
-project should be discontinued.
-
-All contributors with commit access to the LLVM Project are eligible to be a
-maintainer. However, we are looking for people who can commit to:
-
- * engaging in their responsibilities the majority of the days in a month,
- * ensuring that they, and the community members they interact with, abide by
- the LLVM Community Code of Conduct, and
- * performing these duties for at least three months.
-
-We recognize that priorities shift, job changes happen, burnout is real,
-extended vacations are a blessing, and people's lives are generally complex.
-Therefore, we want as little friction as possible for someone to become a
-maintainer or to step down as a maintainer.
-
-*To become a new maintainer*, you can volunteer yourself by posting a PR which
-adds yourself to the area(s) you are volunteering for. Alternatively, an
-existing maintainer can nominate you by posting a PR, but the nominee must
-explicitly accept the PR so that it's clear they agree to volunteer within the
-proposed area(s). The PR will be accepted so long as at least one maintainer in
-the same project vouches for their ability to perform the responsibilities and
-there are no explicit objections raised by the community.
-
-*To step down as a maintainer*, you can move your name to the "inactive
-maintainers" section of the ``Maintainers.rst`` file for the project, or remove
-your name entirely; no PR review is necessary. Additionally, any maintainer who
-has not been actively performing their responsibilities over an extended period
-of time can be moved to the "inactive maintainers" section by another active
-maintainer within that project with agreement from one other active maintainer
-within that project. If there is only one active maintainer for a project,
-please post on Discourse to solicit wider community feedback about the removal
-and future direction for the project. However, please discuss the situation
-with the inactive maintainer before such removal to avoid accidental
-miscommunications. If the inactive maintainer is unreachable, no discussion
-with them is required. Stepping down or being removed as a maintainer is normal
-and does not prevent someone from resuming their activities as a maintainer in
-the future.
-
-*To resume activities as a maintainer*, you can post a PR moving your name from
-the "inactive maintainers" section of the ``Maintainers.rst`` file to the
-active maintainers list. Because the volunteer was already previously accepted,
-they will be re-accepted so long as at least one maintainer in the same project
-approves the PR and there are no explicit objections raised by the community.
-
-.. _include a testcase:
-
-Test Cases
-----------
-
-Developers are required to create test cases for any bugs fixed and any new
-features added. Some tips for getting your testcase approved:
-
-* All feature and regression test cases are added to the ``llvm/test``
- directory. The appropriate sub-directory should be selected (see the
- :doc:`Testing Guide <TestingGuide>` for details).
-
-* Test cases should be written in :doc:`LLVM assembly language <LangRef>`.
-
-* Test cases, especially for regressions, should be reduced as much as possible,
- by :doc:`bugpoint <Bugpoint>` or manually. It is unacceptable to place an
- entire failing program into ``llvm/test`` as this creates a *time-to-test*
- burden on all developers. Please keep them short.
-
-* Avoid adding links to resources that are not available to the entire
- community, such as links to private bug trackers, internal corporate
- documentation, etc. Instead, add sufficient comments to the test to provide
- the context behind such links.
-
-Note that llvm/test and clang/test are designed for regression and small feature
-tests only. More extensive test cases (e.g., entire applications, benchmarks,
-etc) should be added to the ``llvm-test`` test suite. The llvm-test suite is
-for coverage (correctness, performance, etc) testing, not feature or regression
-testing.
-
-Release Notes
--------------
-
-Many projects in LLVM communicate important changes to users through release
-notes, typically found in ``docs/ReleaseNotes.rst`` for the project. Changes to
-a project that are user-facing, or that users may wish to know about, should be
-added to the project's release notes at the author's or code reviewer's
-discretion, preferably as part of the commit landing the changes. Examples of
-changes that would typically warrant adding a release note (this list is not
-exhaustive):
-
-* Adding, removing, or modifying command-line options.
-* Adding, removing, or regrouping a diagnostic.
-* Fixing a bug that potentially has significant user-facing impact (please link
- to the issue fixed in the bug database).
-* Adding or removing optimizations that have widespread impact or enables new
- programming paradigms.
-* Modifying a C stable API.
-* Notifying users about a potentially disruptive change expected to be made in
- a future release, such as removal of a deprecated feature. In this case, the
- release note should be added to a ``Potentially Breaking Changes`` section of
- the notes with sufficient information and examples to demonstrate the
- potential disruption. Additionally, any new entries to this section should be
- announced in the `Announcements <https://discourse.llvm.org/c/announce/>`_
- channel on Discourse. See :ref:`breaking` for more details.
-
-Code reviewers are encouraged to request a release note if they think one is
-warranted when performing a code revi...
[truncated]
``````````
</details>
https://github.com/llvm/llvm-project/pull/114276
More information about the cfe-commits
mailing list