diff options
Diffstat (limited to 'docs/internals/contributing/writing-code')
3 files changed, 15 insertions, 16 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: diff --git a/docs/internals/contributing/writing-code/unit-tests.txt b/docs/internals/contributing/writing-code/unit-tests.txt index 291c50852c..a4c7ea09b0 100644 --- a/docs/internals/contributing/writing-code/unit-tests.txt +++ b/docs/internals/contributing/writing-code/unit-tests.txt @@ -45,10 +45,10 @@ test dependencies. If you don't have an optional dependency installed, the tests that require it will be skipped. Running the tests requires a Django settings module that defines the databases -to use. To make it easy to get started, Django provides and uses a sample -settings module that uses the SQLite database. See -:ref:`running-unit-tests-settings` to learn how to use a different settings -module to run the tests with a different database. +to use. To help you get started, Django provides and uses a sample settings +module that uses the SQLite database. See :ref:`running-unit-tests-settings` to +learn how to use a different settings module to run the tests with a different +database. Having problems? See :ref:`troubleshooting-unit-tests` for some common issues. @@ -199,7 +199,7 @@ internationalization, type: How do you find out the names of individual tests? Look in ``tests/`` — each directory name there is the name of a test. -If you just want to run a particular class of tests, you can specify a list of +If you want to run only a particular class of tests, you can specify a list of paths to individual test classes. For example, to run the ``TranslationTests`` of the ``i18n`` module, type: diff --git a/docs/internals/contributing/writing-code/working-with-git.txt b/docs/internals/contributing/writing-code/working-with-git.txt index 60ba1345a4..639f7719b8 100644 --- a/docs/internals/contributing/writing-code/working-with-git.txt +++ b/docs/internals/contributing/writing-code/working-with-git.txt @@ -98,7 +98,7 @@ necessary:: Publishing work --------------- -You can publish your work on GitHub just by doing:: +You can publish your work on GitHub by running:: git push origin ticket_xxxxx @@ -186,9 +186,9 @@ the changes:: git push -f origin ticket_xxxxx Note that this will rewrite history of ticket_xxxxx - if you check the commit -hashes before and after the operation at GitHub you will notice that the -commit hashes do not match anymore. This is acceptable, as the branch is merely -a topic branch, and nobody should be basing their work on it. +hashes before and after the operation at GitHub you will notice that the commit +hashes do not match anymore. This is acceptable, as the branch is a topic +branch, and nobody should be basing their work on it. After upstream has changed -------------------------- |