p31829507
/
django
mirror of https://github.com/django/django.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

[3.2.x] Fixed #32652 -- Fixed links to new contributors FAQ. 

Backport of e3e2276e6f from main
This commit is contained in:
Carlton Gibson 2021-04-14 20:23:21 +02:00
parent 539d005aa5
commit 99ea737a0f
3 changed files with 33 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
docs/faq/contributing.txt
View File

@ -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.

37
docs/internals/contributing/new-contributors.txt
View File

@ -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
<new-contributors-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.

8
docs/internals/contributing/triaging-tickets.txt
View File

@ -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
-------------