Fixed #34579 -- Added Django Forum to contributing guides.

Co-authored-by: Mariusz Felisiak <felisiak.mariusz@gmail.com>

docs/internals/contributing/bugs-and-features.txt

@@ -20,11 +20,11 @@ Otherwise, before reporting a bug or requesting a new feature on the
   |django-users| list or the `#django`_ IRC channel for that.
 
 * Don't reopen issues that have been marked "wontfix" without finding consensus
-  to do so on |django-developers|.
+  to do so on the `Django Forum`_ or |django-developers| list.
 
 * Don't use the ticket tracker for lengthy discussions, because they're
   likely to get lost. If a particular ticket is controversial, please move the
-  discussion to |django-developers|.
+  discussion to the `Django Forum`_ or |django-developers| list.
 
 .. _reporting-bugs:
 
@@ -94,11 +94,10 @@ part of that. Here are some tips on how to make a request most effectively:
   suggest that you develop it independently. Then, if your project gathers
   sufficient community support, we may consider it for inclusion in Django.
 
-* First request the feature on the |django-developers| list, not in the
-  ticket tracker. It'll get read more closely if it's on the mailing list.
-  This is even more important for large-scale feature requests. We like to
-  discuss any big changes to Django's core on the mailing list before
-  actually working on them.
+* First request the feature on the `Django Forum`_ or |django-developers| list,
+  not in the ticket tracker. It'll get read more closely if it's on the mailing
+  list. This is even more important for large-scale feature requests. We like
+  to discuss any big changes to Django's core before actually working on them.
 
 * Describe clearly and concisely what the missing feature is and how you'd
   like to see it implemented. Include example code (non-functional is OK)
@@ -109,8 +108,7 @@ part of that. Here are some tips on how to make a request most effectively:
   achieving the same thing.
 
 If there's a consensus agreement on the feature, then it's appropriate to
-create a ticket. Include a link to the discussion on |django-developers| in the
-ticket description.
+create a ticket. Include a link to the discussion in the ticket description.
 
 As with most open-source projects, code talks. If you are willing to write the
 code for the feature yourself or, even better, if you've already written it,
@@ -160,8 +158,9 @@ Since this process allows any steering council member to veto a proposal, a
 convert that "-1" into at least a "+0".
 
 Votes on technical matters should be announced and held in public on the
-|django-developers| mailing list or on the Django Forum.
+|django-developers| mailing list or on the `Django Forum`_.
 
 .. _searching: https://code.djangoproject.com/search
 .. _custom queries: https://code.djangoproject.com/query
 .. _#django: https://web.libera.chat/#django
+.. _Django Forum: https://forum.djangoproject.com/

docs/internals/contributing/committing-code.txt

@@ -109,14 +109,14 @@ Django's Git repository:
   discuss the situation with the team.
 
 * For any medium-to-big changes, where "medium-to-big" is according to
-  your judgment, please bring things up on the |django-developers|
-  mailing list before making the change.
+  your judgment, please bring things up on the `Django Forum`_ or
+  |django-developers| mailing list before making the change.
 
-  If you bring something up on |django-developers| and nobody responds,
-  please don't take that to mean your idea is great and should be
-  implemented immediately because nobody contested it. Everyone doesn't always
-  have a lot of time to read mailing list discussions immediately, so you may
-  have to wait a couple of days before getting a response.
+  If you bring something up and nobody responds, please don't take that
+  to mean your idea is great and should be implemented immediately because
+  nobody contested it. Everyone doesn't always have a lot of time to read
+  mailing list discussions immediately, so you may have to wait a couple of
+  days before getting a response.
 
 * Write detailed commit messages in the past tense, not present tense.
 
@@ -227,15 +227,15 @@ When a mistaken commit is discovered, please follow these guidelines:
 
 * If the original author can't be reached (within a reasonable amount
   of time -- a day or so) and the problem is severe -- crashing bug,
-  major test failures, etc. -- then ask for objections on the
-  |django-developers| mailing list then revert if there are none.
+  major test failures, etc. -- then ask for objections on the `Django Forum`_
+  or |django-developers| mailing list then revert if there are none.
 
 * If the problem is small (a feature commit after feature freeze,
   say), wait it out.
 
 * If there's a disagreement between the merger and the reverter-to-be then try
-  to work it out on the |django-developers| mailing list. If an agreement can't
-  be reached then it should be put to a vote.
+  to work it out on the `Django Forum`_ or |django-developers| mailing list. If
+  an agreement can't be reached then it should be put to a vote.
 
 * If the commit introduced a confirmed, disclosed security
   vulnerability then the commit may be reverted immediately without
@@ -249,3 +249,4 @@ When a mistaken commit is discovered, please follow these guidelines:
   do a reverse push: ``git push upstream :feature_antigravity``.
 
 .. _ticket tracker: https://code.djangoproject.com/
+.. _Django Forum: https://forum.djangoproject.com/

docs/internals/contributing/triaging-tickets.txt

@@ -308,11 +308,12 @@ A ticket can be resolved in a number of ways:
 * wontfix
       Used when someone decides that the request isn't appropriate for
       consideration in Django. Sometimes a ticket is closed as "wontfix" with a
-      request for the reporter to start a discussion on the |django-developers|
-      mailing list if they feel differently from the rationale provided by the
-      person who closed the ticket. Other times, a mailing list discussion
-      precedes the decision to close a ticket. Always use the mailing list to
-      get a consensus before reopening tickets closed as "wontfix".
+      request for the reporter to start a discussion on the `Django Forum`_ or
+      |django-developers| mailing list if they feel differently from the
+      rationale provided by the person who closed the ticket. Other times, a
+      discussion precedes the decision to close a ticket. Always use the forum
+      or mailing list to get a consensus before reopening tickets closed as
+      "wontfix".
 
 * duplicate
       Used when another ticket covers the same issue. By closing duplicate
@@ -332,7 +333,7 @@ If you believe that the ticket was closed in error -- because you're
 still having the issue, or it's popped up somewhere else, or the triagers have
 made a mistake -- please reopen the ticket and provide further information.
 Again, please do not reopen tickets that have been marked as "wontfix" and
-bring the issue to |django-developers| instead.
+bring the issue to the `Django Forum`_ or |django-developers| instead.
 
 .. _how-can-i-help-with-triaging:
 
@@ -353,7 +354,7 @@ Then, you can help out by:
 
 * Closing "Unreviewed" tickets as "needsinfo" when the description is too
   sparse to be actionable, or when they're feature requests requiring a
-  discussion on |django-developers|.
+  discussion on the `Django Forum`_ or |django-developers|.
 
 * Correcting the "Needs tests", "Needs documentation", or "Has patch"
   flags for tickets where they are incorrectly set.
@@ -371,7 +372,7 @@ Then, you can help out by:
   reports about a particular part of Django, it may indicate we should
   consider refactoring that part of the code. If a trend is emerging,
   you should raise it for discussion (referencing the relevant tickets)
-  on |django-developers|.
+  on the `Django Forum`_ or |django-developers|.
 
 * Verify if patches submitted by other users are correct. If they are correct
   and also contain appropriate documentation and tests then move them to the
@@ -397,18 +398,19 @@ the ticket database:
   checkin", but you should get at minimum one other community member to
   review a patch that you submit.
 
-* Please **don't** reverse a decision without posting a message to
-  |django-developers| to find consensus.
+* Please **don't** reverse a decision without posting a message to the
+  `Django Forum`_ or |django-developers| to find consensus.
 
 * If you're unsure if you should be making a change, don't make the
   change but instead leave a comment with your concerns on the ticket,
-  or post a message to |django-developers|. It's okay to be unsure,
-  but your input is still valuable.
+  or post a message to the `Django Forum`_ or |django-developers|. It's okay to
+  be unsure, but your input is still valuable.
 
 .. _Trac: https://code.djangoproject.com/
 .. _`easy pickings`: https://code.djangoproject.com/query?status=!closed&easy=1
 .. _`creating an account on Trac`: https://www.djangoproject.com/accounts/register/
 .. _password reset page: https://www.djangoproject.com/accounts/password/reset/
+.. _Django Forum: https://forum.djangoproject.com/
 
 Bisecting a regression
 ======================

docs/internals/contributing/writing-code/submitting-patches.txt

@@ -147,11 +147,13 @@ A "non-trivial" patch is one that is more than a small bug fix. It's a patch
 that introduces Django functionality and makes some sort of design decision.
 
 If you provide a non-trivial patch, include evidence that alternatives have
-been discussed on |django-developers|.
+been discussed on the `Django Forum`_ or |django-developers| list.
 
 If you're not sure whether your patch should be considered non-trivial, ask on
 the ticket for opinions.
 
+.. _Django Forum: https://forum.djangoproject.com/
+
 .. _deprecating-a-feature:
 
 Deprecating a feature

docs/internals/howto-release-django.txt

@@ -402,8 +402,8 @@ Now you're ready to actually put the release out there. To do this:
    __ https://github.com/django/djangoproject.com/blob/main/djangoproject/static/robots.docs.txt
 
 #. Post the release announcement to the |django-announce|, |django-developers|,
-   and |django-users| mailing lists. This should include a link to the
-   announcement blog post.
+   |django-users| mailing lists, and the Django Forum. This should include a
+   link to the announcement blog post.
 
 #. If this is a security release, send a separate email to
    oss-security@lists.openwall.com. Provide a descriptive subject, for example,

docs/intro/contributing.txt

@@ -41,11 +41,13 @@ so that it can be of use to the widest audience.
 .. admonition:: Where to get help:
 
     If you're having trouble going through this tutorial, please post a message
-    to |django-developers| or drop by `#django-dev on irc.libera.chat`__ to
-    chat with other Django users who might be able to help.
+    on the `Django Forum`_, |django-developers|, or drop by
+    `#django-dev on irc.libera.chat`__ to chat with other Django users who
+    might be able to help.
 
 __ https://diveinto.org/python3/table-of-contents.html
 __ https://web.libera.chat/#django-dev
+.. _Django Forum: https://forum.djangoproject.com/
 
 What does this tutorial cover?
 ------------------------------