From e3e2276e6fe6fd77e4fbdeeb2a287288d31de3bb Mon Sep 17 00:00:00 2001 From: Carlton Gibson Date: Wed, 14 Apr 2021 20:23:21 +0200 Subject: [PATCH] Fixed #32652 -- Fixed links to new contributors FAQ. --- docs/faq/contributing.txt | 16 ++++++-- .../contributing/new-contributors.txt | 37 ++++++++----------- .../contributing/triaging-tickets.txt | 8 ++-- 3 files changed, 33 insertions(+), 28 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. +* **Be patient** + + 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. + + 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. + + Remember that Django has an 8 month release cycle, so there's plenty of time + for your patch to be reviewed. + + Finally, a well-timed reminder can help. See :ref:`contributing code FAQ + ` for ideas here. + .. _easy pickings: https://code.djangoproject.com/query?status=!closed&easy=1 - -.. _new-contributors-faq: - -FAQ -=== - -1. **This ticket I care about has been ignored for days/weeks/months! What can - I do to get it committed?** - - 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. - -2. **I'm sure my ticket is absolutely 100% perfect, can I mark it as RFC - myself?** - - 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. 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` 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` for some +ideas here. Someday/Maybe -------------