1 files changed, 16 insertions, 16 deletions
diff --git a/docs/faq/contributing.txt b/docs/faq/contributing.txt
index 769cddc488..71a6a7a476 100644
--- a/docs/faq/contributing.txt
+++ b/docs/faq/contributing.txt
@@ -10,8 +10,8 @@ How can I get started contributing code to Django?
 Thanks for asking! We've written an entire document devoted to this question.
 It's titled :doc:`Contributing to Django </internals/contributing/index>`.
 
-I submitted a bug fix in the ticket system several weeks ago. Why are you ignoring my patch?
-============================================================================================
+I submitted a bug fix several weeks ago. Why are you ignoring my contribution?
+==============================================================================
 
 Don't worry: We're not ignoring you!
 
@@ -34,21 +34,21 @@ that area of the code, to understand the problem and verify the fix:
   database, are those instructions clear enough even for someone not
   familiar with it?
 
-* If there are several patches attached to the ticket, is it clear what
-  each one does, which ones can be ignored and which matter?
+* If there are several branches linked to the ticket, is it clear what each one
+  does, which ones can be ignored and which matter?
 
-* Does the patch include a unit test? If not, is there a very clear
+* Does the change include a unit test? If not, is there a very clear
   explanation why not? A test expresses succinctly what the problem is,
-  and shows that the patch actually fixes it.
+  and shows that the branch actually fixes it.
 
-If your patch stands no chance of inclusion in Django, we won't ignore it --
-we'll just close the ticket. So if your ticket is still open, it doesn't mean
+If your contribution is not suitable for inclusion in Django, we won't ignore
+it -- we'll close the ticket. So if your ticket is still open, it doesn't mean
 we're ignoring you; it just means we haven't had time to look at it yet.
 
-When and how might I remind the team of a patch I care about?
-=============================================================
+When and how might I remind the team of a change I care about?
+==============================================================
 
-A polite, well-timed message to the mailing list is one way to get attention.
+A polite, well-timed message in the forum/branch is one way to get attention.
 To determine the right time, you need to keep an eye on the schedule. If you
 post your message right before a release deadline, you're not likely to get the
 sort of attention you require.
@@ -68,11 +68,11 @@ issue over and over again. This sort of behavior will not gain you any
 additional attention -- certainly not the attention that you need in order to
 get your issue addressed.
 
-But I've reminded you several times and you keep ignoring my patch!
-===================================================================
+But I've reminded you several times and you keep ignoring my contribution!
+==========================================================================
 
-Seriously - we're not ignoring you. If your patch stands no chance of
-inclusion in Django, we'll close the ticket. For all the other tickets, we
+Seriously - we're not ignoring you. If your contribution is not suitable for
+inclusion in Django, we will close the ticket. For all the other tickets, we
 need to prioritize our efforts, which means that some tickets will be
 addressed before others.
 
@@ -83,7 +83,7 @@ are edge cases.
 
 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
+applying lots of little changes, 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