summaryrefslogtreecommitdiff
path: root/docs/internals/contributing/bugs-and-features.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/bugs-and-features.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/bugs-and-features.txt')
-rw-r--r--docs/internals/contributing/bugs-and-features.txt16
1 files changed, 8 insertions, 8 deletions
diff --git a/docs/internals/contributing/bugs-and-features.txt b/docs/internals/contributing/bugs-and-features.txt
index 858de4ad08..89c11c3a32 100644
--- a/docs/internals/contributing/bugs-and-features.txt
+++ b/docs/internals/contributing/bugs-and-features.txt
@@ -46,13 +46,13 @@ particular:
include a clear, concise description of the problem, and a set of
instructions for replicating it. Add as much debug information as you can:
code snippets, test cases, exception backtraces, screenshots, etc. A nice
- small test case is the best way to report a bug, as it gives us an easy
- way to confirm the bug quickly.
+ small test case is the best way to report a bug, as it gives us a
+ helpful way to confirm the bug quickly.
-* **Don't** post to |django-developers| just to announce that you have
- filed a bug report. All the tickets are mailed to another list,
- |django-updates|, which is tracked by developers and interested
- community members; we see them as they are filed.
+* **Don't** post to |django-developers| only to announce that you have filed a
+ bug report. All the tickets are mailed to another list, |django-updates|,
+ which is tracked by developers and interested community members; we see them
+ as they are filed.
To understand the lifecycle of your ticket once you have created it, refer to
:doc:`triaging-tickets`.
@@ -116,8 +116,8 @@ ticket description.
As with most open-source projects, code talks. If you are willing to write the
code for the feature yourself or, even better, if you've already written it,
-it's much more likely to be accepted. Just fork Django on GitHub, create a
-feature branch, and show us your work!
+it's much more likely to be accepted. Fork Django on GitHub, create a feature
+branch, and show us your work!
See also: :ref:`documenting-new-features`.