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
 FAQ: Contributing code
 ======================
 ======================
 
 
+.. _new-contributors-faq:
+
 How can I get started contributing code to Django?
 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
 potential to affect many people will generally get priority over those that
 are edge cases.
 are edge cases.
 
 
-Another reason that bugs might be ignored for while is if the bug is a symptom
+Another reason that a bug might be ignored for a while is if the bug is a
-of a larger problem. While we can spend time writing, testing and applying
+symptom of a larger problem. While we can spend time writing, testing and
-lots of little patches, sometimes the right solution is to rebuild. If a
+applying lots of little patches, sometimes the right solution is to rebuild. If
-rebuild or refactor of a particular component has been proposed or is
+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
 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
 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
 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
 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
 limited time we have available, we will always err on the side of making 10
 people happy rather than making a single person happy.
 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 the very first tests for that feature, not that you get a pass from
   writing tests altogether.
   writing tests altogether.
 
 
-.. _easy pickings: https://code.djangoproject.com/query?status=!closed&easy=1
+* **Be patient**
-
-.. _new-contributors-faq:
 
 
-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
+  Keeping your patch up to date is important. Review the ticket on Trac to
-   I do to get it committed?**
+  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
+  Remember that Django has an 8 month release cycle, so there's plenty of time
-   (except the Django fellow), and sometimes folks just don't have time. The
+  for your patch to be reviewed.
-   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.
 
 
-2. **I'm sure my ticket is absolutely 100% perfect, can I mark it as RFC
+  Finally, a well-timed reminder can help. See :ref:`contributing code FAQ
-   myself?**
+  <new-contributors-faq>` for ideas here.
 
 
-   Short answer: No. It's always better to get another set of eyes on a
+.. _easy pickings: https://code.djangoproject.com/query?status=!closed&easy=1
-   ticket. If you're having trouble getting that second set of eyes, see
-   question 1, above.

+ 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
 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
 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
 commit-ready patch. A committer now needs to give the patch a final
-review prior to being committed. See the
+review prior to being committed.
-:ref:`New contributors' FAQ<new-contributors-faq>` for "My ticket has been in
+
-RFC forever! What should I do?"
+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
 Someday/Maybe
 -------------
 -------------