Browse Source

Fixed #32652 -- Fixed links to new contributors FAQ.

Carlton Gibson 4 years ago
parent
commit
e3e2276e6f

+ 12 - 4
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.

+ 12 - 17
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

+ 5 - 3
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
 -------------