diff --git a/docs/internals/contributing/bugs-and-features.txt b/docs/internals/contributing/bugs-and-features.txt index 2e5ca8de340..b6b3265ba6b 100644 --- a/docs/internals/contributing/bugs-and-features.txt +++ b/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/ diff --git a/docs/internals/contributing/committing-code.txt b/docs/internals/contributing/committing-code.txt index f5be86238e3..91c6d21beb5 100644 --- a/docs/internals/contributing/committing-code.txt +++ b/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/ diff --git a/docs/internals/contributing/triaging-tickets.txt b/docs/internals/contributing/triaging-tickets.txt index c660c34e917..74734050077 100644 --- a/docs/internals/contributing/triaging-tickets.txt +++ b/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 ====================== diff --git a/docs/internals/contributing/writing-code/submitting-patches.txt b/docs/internals/contributing/writing-code/submitting-patches.txt index 59c17ce9a38..be031f1f68c 100644 --- a/docs/internals/contributing/writing-code/submitting-patches.txt +++ b/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 diff --git a/docs/internals/howto-release-django.txt b/docs/internals/howto-release-django.txt index 4c86265ab38..4b63f6ec82b 100644 --- a/docs/internals/howto-release-django.txt +++ b/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, diff --git a/docs/intro/contributing.txt b/docs/intro/contributing.txt index c8601cb14d2..c9b5734569c 100644 --- a/docs/intro/contributing.txt +++ b/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? ------------------------------