summaryrefslogtreecommitdiff
path: root/docs/internals
diff options
context:
space:
mode:
authorMohit Singh Sinsniwal <mohit.sinsniwal@gmail.com>2023-05-20 04:55:41 +0530
committerMariusz Felisiak <felisiak.mariusz@gmail.com>2023-05-22 20:21:18 +0200
commit89f10a80d7e681cd0cccf22d932e380f51bd3524 (patch)
tree6733a337882e549556c8211459b9ec5c1ad38058 /docs/internals
parentf8172f45fc83af2315aefed77ee34b5654f5c347 (diff)
Fixed #34579 -- Added Django Forum to contributing guides.
Co-authored-by: Mariusz Felisiak <felisiak.mariusz@gmail.com>
Diffstat (limited to 'docs/internals')
-rw-r--r--docs/internals/contributing/bugs-and-features.txt19
-rw-r--r--docs/internals/contributing/committing-code.txt23
-rw-r--r--docs/internals/contributing/triaging-tickets.txt26
-rw-r--r--docs/internals/contributing/writing-code/submitting-patches.txt4
-rw-r--r--docs/internals/howto-release-django.txt4
5 files changed, 40 insertions, 36 deletions
diff --git a/docs/internals/contributing/bugs-and-features.txt b/docs/internals/contributing/bugs-and-features.txt
index 2e5ca8de34..b6b3265ba6 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 f5be86238e..91c6d21beb 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 c660c34e91..7473405007 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 59c17ce9a3..be031f1f68 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 4c86265ab3..4b63f6ec82 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,