summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorCarlton Gibson <carlton.gibson@noumenal.es>2021-04-14 20:23:21 +0200
committerCarlton Gibson <carlton.gibson@noumenal.es>2021-04-15 17:16:22 +0200
commit99ea737a0fbc5c628f21389be9d563ad0ea05348 (patch)
tree8de595053689e6c7e547dc7382a2eff649262da5
parent539d005aa5fb496f0a648a2385465eca06c604e9 (diff)
[3.2.x] Fixed #32652 -- Fixed links to new contributors FAQ.
Backport of e3e2276e6fe6fd77e4fbdeeb2a287288d31de3bb from main
-rw-r--r--docs/faq/contributing.txt16
-rw-r--r--docs/internals/contributing/new-contributors.txt29
-rw-r--r--docs/internals/contributing/triaging-tickets.txt8
3 files changed, 29 insertions, 24 deletions
diff --git a/docs/faq/contributing.txt b/docs/faq/contributing.txt
index 8d8eb2ded7..a65066307f 100644
--- a/docs/faq/contributing.txt
+++ b/docs/faq/contributing.txt
@@ -2,6 +2,8 @@
FAQ: Contributing code
======================
+.. _new-contributors-faq:
+
How can I get started contributing code to Django?
==================================================
@@ -79,10 +81,10 @@ people that will likely be affected by a given bug. Bugs that have the
potential to affect many people will generally get priority over those that
are edge cases.
-Another reason that bugs might be ignored for while is if the bug is a symptom
-of a larger problem. While we can spend time writing, testing and applying
-lots of little patches, sometimes the right solution is to rebuild. If a
-rebuild or refactor of a particular component has been proposed or is
+Another reason that a bug might be ignored for a while is if the bug is a
+symptom of a larger problem. While we can spend time writing, testing and
+applying lots of little patches, sometimes the right solution is to rebuild. If
+a rebuild or refactor of a particular component has been proposed or is
underway, you may find that bugs affecting that component will not get as much
attention. Again, this is a matter of prioritizing scarce resources. By
concentrating on the rebuild, we can close all the little bugs at once, and
@@ -97,3 +99,9 @@ entire community, instead of prioritizing the impact on one particular user.
This doesn't mean that we think your problem is unimportant -- just that in the
limited time we have available, we will always err on the side of making 10
people happy rather than making a single person happy.
+
+I'm sure my ticket is absolutely 100% perfect, can I mark it as "Ready For Checkin" myself?
+===========================================================================================
+
+Sorry, no. It's always better to get another set of eyes on a ticket. If
+you're having trouble getting that second set of eyes, see questions above.
diff --git a/docs/internals/contributing/new-contributors.txt b/docs/internals/contributing/new-contributors.txt
index 29502cc782..8457f41941 100644
--- a/docs/internals/contributing/new-contributors.txt
+++ b/docs/internals/contributing/new-contributors.txt
@@ -138,25 +138,20 @@ some advice to make your work on Django more useful and rewarding.
writing the very first tests for that feature, not that you get a pass from
writing tests altogether.
-.. _easy pickings: https://code.djangoproject.com/query?status=!closed&easy=1
-
-.. _new-contributors-faq:
+* **Be patient**
-FAQ
-===
+ It's not always easy for your ticket or your patch to be reviewed quickly.
+ This isn't personal. There are a lot of tickets and pull requests to get
+ through.
-1. **This ticket I care about has been ignored for days/weeks/months! What can
- I do to get it committed?**
+ Keeping your patch up to date is important. Review the ticket on Trac to
+ ensure that the *Needs tests*, *Needs documentation*, and *Patch needs
+ improvement* flags are unchecked once you've addressed all review comments.
- First off, it's not personal. Django is entirely developed by volunteers
- (except the Django fellow), and sometimes folks just don't have time. The
- best thing to do is to send a gentle reminder to the |django-developers|
- mailing list asking for review on the ticket, or to bring it up in the
- ``#django-dev`` IRC channel.
+ Remember that Django has an 8 month release cycle, so there's plenty of time
+ for your patch to be reviewed.
-2. **I'm sure my ticket is absolutely 100% perfect, can I mark it as RFC
- myself?**
+ Finally, a well-timed reminder can help. See :ref:`contributing code FAQ
+ <new-contributors-faq>` for ideas here.
- Short answer: No. It's always better to get another set of eyes on a
- ticket. If you're having trouble getting that second set of eyes, see
- question 1, above.
+.. _easy pickings: https://code.djangoproject.com/query?status=!closed&easy=1
diff --git a/docs/internals/contributing/triaging-tickets.txt b/docs/internals/contributing/triaging-tickets.txt
index 8341ee0e3c..3bd02044d3 100644
--- a/docs/internals/contributing/triaging-tickets.txt
+++ b/docs/internals/contributing/triaging-tickets.txt
@@ -143,9 +143,11 @@ Ready For Checkin
The ticket was reviewed by any member of the community other than the person
who supplied the patch and found to meet all the requirements for a
commit-ready patch. A committer now needs to give the patch a final
-review prior to being committed. See the
-:ref:`New contributors' FAQ<new-contributors-faq>` for "My ticket has been in
-RFC forever! What should I do?"
+review prior to being committed.
+
+There are a lot of pull requests. It can take a while for your patch to get
+reviewed. See the :ref:`contributing code FAQ<new-contributors-faq>` for some
+ideas here.
Someday/Maybe
-------------