summaryrefslogtreecommitdiff
path: root/docs/internals/contributing/writing-code/submitting-patches.txt
diff options
context:
space:
mode:
authorTobias Kunze <r@rixx.de>2019-06-17 16:54:55 +0200
committerMariusz Felisiak <felisiak.mariusz@gmail.com>2019-09-06 13:27:46 +0200
commit4a954cfd11a5d034491f87fcbc920eb97a302bb3 (patch)
tree1c92caae5d8a9b33c51ddd74b4b2061248f3915f /docs/internals/contributing/writing-code/submitting-patches.txt
parentaddabc492bdc0191ac95d59ec34b56b34086ebb9 (diff)
Fixed #30573 -- Rephrased documentation to avoid words that minimise the involved difficulty.
This patch does not remove all occurrences of the words in question. Rather, I went through all of the occurrences of the words listed below, and judged if they a) suggested the reader had some kind of knowledge/experience, and b) if they added anything of value (including tone of voice, etc). I left most of the words alone. I looked at the following words: - simply/simple - easy/easier/easiest - obvious - just - merely - straightforward - ridiculous Thanks to Carlton Gibson for guidance on how to approach this issue, and to Tim Bell for providing the idea. But the enormous lion's share of thanks go to Adam Johnson for his patient and helpful review.
Diffstat (limited to 'docs/internals/contributing/writing-code/submitting-patches.txt')
-rw-r--r--docs/internals/contributing/writing-code/submitting-patches.txt13
1 files changed, 6 insertions, 7 deletions
diff --git a/docs/internals/contributing/writing-code/submitting-patches.txt b/docs/internals/contributing/writing-code/submitting-patches.txt
index 5bfff59b52..d70bc428d1 100644
--- a/docs/internals/contributing/writing-code/submitting-patches.txt
+++ b/docs/internals/contributing/writing-code/submitting-patches.txt
@@ -85,10 +85,9 @@ Which tickets should be claimed?
Of course, going through the steps of claiming tickets is overkill in some
cases.
-In the case of small changes, such as typos in the documentation or
-small bugs that will only take a few minutes to fix, you don't need to jump
-through the hoops of claiming tickets. Just submit your patch and be done with
-it.
+In the case of small changes, such as typos in the documentation or small bugs
+that will only take a few minutes to fix, you don't need to jump through the
+hoops of claiming tickets. Submit your patch directly and you're done!
Of course, it is *always* acceptable, regardless whether someone has claimed it
or not, to submit patches to a ticket if you happen to have a patch ready.
@@ -145,14 +144,14 @@ Regardless of the way you submit your work, follow these steps.
Non-trivial patches
===================
-A "non-trivial" patch is one that is more than a simple bug fix. It's a patch
+A "non-trivial" patch is one that is more than a small bug fix. It's a patch
that introduces Django functionality and makes some sort of design decision.
If you provide a non-trivial patch, include evidence that alternatives have
been discussed on |django-developers|.
-If you're not sure whether your patch should be considered non-trivial, just
-ask.
+If you're not sure whether your patch should be considered non-trivial, ask on
+the ticket for opinions.
.. _deprecating-a-feature: