Various grammar fixes in documentation. Remove references to legacy u…

…i in docs.

docs/changelog.rst

@@ -786,7 +786,7 @@ Identical to previous version, but now built & deployed to Pypi using Travis.
 * Added sequential task support - https://github.com/locustio/locust/pull/827
 * Added support for user-defined wait_function - https://github.com/locustio/locust/pull/785
 * By default, Locust no longer resets the statistics when the hatching is complete.
-  Therefore :code:`--no-reset-stats` has been deprecated (since it's now the default behaviour),
+  Therefore :code:`--no-reset-stats` has been deprecated (since it's now the default behavior),
   and instead a new :code:`--reset-stats` option has been added.
 * Dropped support for Python 3.3
 * Updated documentation
@@ -1007,7 +1007,7 @@ Other changes
     Anyone who is currently using existing locust scripts and want to upgrade to 0.6
     should read through these changes.
 
-:py:class:`SubLocust <locust.core.SubLocust>` replaced by :py:class:`TaskSet <locust.core.TaskSet>` and :py:class:`Locust <locust.core.Locust>` class behaviour changed
+:py:class:`SubLocust <locust.core.SubLocust>` replaced by :py:class:`TaskSet <locust.core.TaskSet>` and :py:class:`Locust <locust.core.Locust>` class behavior changed
 -----------------------------------------------------------------------------------------------------------------------------------------------------------------------
 
 :py:class:`Locust <locust.core.Locust>` classes does no longer control task scheduling and execution.

docs/configuration.rst

@@ -161,7 +161,7 @@ Running Locust with User class UI picker
 ========================================
 
 You can select which Shape class and which User classes to run in the WebUI when running locust with the ``--class-picker`` flag.
-No selection uses all of the available User classes.
+No selection uses all the available User classes.
 
 Example:
 

docs/increase-performance.rst

@@ -17,7 +17,7 @@ In a *best case* scenario (doing small requests inside a ``while True``-loop) a
 
 The relative improvement may be even bigger with bigger request payloads, but it may also be smaller if your test is doing CPU intensive things not related to requests.
 
-Of course, in reality you should run :ref:`one locust process per CPU core <running-distributed>`.
+Of course, in reality, you should run :ref:`one locust process per CPU core <running-distributed>`.
 
 .. note::
 
@@ -83,7 +83,7 @@ FastHttpUser provides a ``rest`` method for testing REST/JSON HTTP interfaces. I
                 elif resp.js["bar"] != 42:
                     resp.failure(f"'bar' had an unexpected value: {resp.js['bar']}")
 
-For a complete example, see `rest.py <https://github.com/locustio/locust/blob/master/examples/rest.py>`_. That also shows how you can use inheritance to provide behaviours specific to your REST API that are common to multiple requests/testplans.
+For a complete example, see `rest.py <https://github.com/locustio/locust/blob/master/examples/rest.py>`_. That also shows how you can use inheritance to provide behaviors specific to your REST API that are common to multiple requests/testplans.
 
 .. note::
 
@@ -93,7 +93,7 @@ For a complete example, see `rest.py <https://github.com/locustio/locust/blob/ma
 Connection Handling
 ===================
 
-By default a User will reuse the same TCP/HTTP connection (unless it breaks somehow). To more realistically simulate new browsers connecting to your application this connection can be manually closed.
+By default, a User will reuse the same TCP/HTTP connection (unless it breaks somehow). To more realistically simulate new browsers connecting to your application this connection can be manually closed.
 
 .. code-block:: python
 

docs/quickstart.rst

@@ -18,7 +18,7 @@ A Locust test is essentially just a Python program making requests to the system
 
 This user will make an HTTP request to ``/hello``, then to ``/world``, and then repeat. For a full explanation and a more realistic example see :ref:`writing-a-locustfile`.
 
-Change ``/hello`` and ``/world`` to some actual paths on the web site/service you want to test, put the code in a file named ``locustfile.py`` in your current directory and then run ``locust``:
+Change ``/hello`` and ``/world`` to some actual paths on the website/service you want to test, put the code in a file named ``locustfile.py`` in your current directory and then run ``locust``:
 
 .. code-block:: console
     :substitutions:
@@ -36,7 +36,7 @@ Open http://localhost:8089
 
 | Provide the host name of your server and try it out!
 
-The following screenshots show what it might look like when running this test using 50 concurrent users, with a ramp up rate of 1 users/s
+The following screenshots show what it might look like when running this test using 50 concurrent users, with a ramp up rate of 1 user/s
 
 .. image:: images/webui-running-statistics.png
 
@@ -56,11 +56,7 @@ The following screenshots show what it might look like when running this test us
 
     If your response times are *not* increasing then add even more users until you find the service's breaking point, or celebrate that your service is already performant enough for your expected load.
 
-    If you need some help digging into server side problems, or you're having trouble generating enough load to saturate your system, have a look at the `Locust FAQ  <https://github.com/locustio/locust/wiki/FAQ#increase-my-request-raterps>`_.
-
-.. note::
-
-    Things looking a little different? We've updated the UI! If for whatever reason you need to use the old version, you can always revert back to it using the ``--legacy-ui`` flag.
+    If you need some help digging into server side problems, or you're having trouble generating enough load to saturate your system, take a look at the `Locust FAQ  <https://github.com/locustio/locust/wiki/FAQ#increase-my-request-raterps>`_.
 
 Direct command line usage / headless
 ====================================

docs/testing-other-systems.rst

@@ -10,9 +10,9 @@ Locust only comes with built-in support for HTTP/HTTPS but it can be extended to
 
     It is important that the protocol libraries you use can be `monkey-patched <https://www.gevent.org/intro.html#monkey-patching>`_ by gevent. 
 
-    Almost any libraries that are pure Python (using the Python ``socket`` module or some other standard library function like ``subprocess``) should work fine out of the box - but if they do their I/O calls in C, gevent will be unable to patch it. This will block the whole Locust/Python process (in practice limiting you to running a single User per worker process).
+    Almost any libraries that are pure Python (using the Python ``socket`` module or some other standard library function like ``subprocess``) should work fine out of the box - but if they do their I/O calls from compiled code C, gevent will be unable to patch it. This will block the whole Locust/Python process (in practice limiting you to running a single User per worker process).
 
-    Some C libraries allow for other workarounds. For example, if you want to use psycopg2 to performance test PostgreSQL, you can use `psycogreen <https://github.com/psycopg/psycogreen/>`_. If you are willing to get your hands dirty, you may also be able to patch a library yourself, but that is beyond the scope of this documentation.
+    Some C libraries allow for other workarounds. For example, if you want to use psycopg2 to performance test PostgreSQL, you can use `psycogreen <https://github.com/psycopg/psycogreen/>`_. If you are willing to get your hands dirty, you may be able to patch a library yourself, but that is beyond the scope of this documentation.
 
 XML-RPC
 =======

docs/what-is-locust.rst

@@ -2,7 +2,7 @@
 What is Locust?
 ===============================
 
-Locust is an open source performance/load testing tool for HTTP and other protocols. Its developer friendly approach lets you to define your tests in regular Python code.
+Locust is an open source performance/load testing tool for HTTP and other protocols. Its developer friendly approach lets you define your tests in regular Python code.
 
 Locust tests can be run from command line or using its web-based UI. Throughput, response times and errors can be viewed in real time and/or exported for later analysis.
 
@@ -21,7 +21,7 @@ Features
 
 * **Write test scenarios in plain old Python**
 
- If you want your users to loop, perform some conditional behaviour or do some calculations, you just use the regular programming constructs provided by Python.
+ If you want your users to loop, perform some conditional behavior or do some calculations, you just use the regular programming constructs provided by Python.
  Locust runs every user inside its own greenlet (a lightweight process/coroutine). This enables you to write your tests like normal (blocking) Python code instead of having to use callbacks or some other mechanism.
  Because your scenarios are "just python" you can use your regular IDE, and version control your tests as regular code (as opposed to some other tools that use XML or binary formats)
 
@@ -37,7 +37,7 @@ Features
 
 * **Can test any system**
 
- Even though Locust primarily works with web sites/services, it can be used to test almost any system or protocol. Just :ref:`write a client <testing-other-systems>` 
+ Even though Locust primarily works with websites/services, it can be used to test almost any system or protocol. Just :ref:`write a client <testing-other-systems>` 
  for what you want to test, or `explore some created by the community <https://github.com/SvenskaSpel/locust-plugins#users>`_.
 
 * **Hackable**
@@ -47,12 +47,12 @@ Features
 Name & background
 =================
 
-Locust was born out of a frustration with existing solutions. No existing load testing tool was well equipped to generate realistic 
+Locust was born out of a frustration with existing solutions. No existing load testing tool was well-equipped to generate realistic 
 load against a dynamic website where most pages had different content for different users. Existing tools used clunky interfaces or 
 verbose configuration files to declare the tests. In Locust we took a different approach. Instead of configuration formats or UIs 
-you'd get a python framework that would let you define the behaviour of your users using Python code. 
+you'd get a python framework that would let you define the behavior of your users using Python code. 
 
-Locust takes its name from the `grasshopper species <https://en.wikipedia.org/wiki/Locust>`_, known for their swarming behaviour. 
+Locust takes its name from the `grasshopper species <https://en.wikipedia.org/wiki/Locust>`_, known for their swarming behavior. 
 
 :ref:`history`
 

docs/writing-a-locustfile.rst

@@ -204,8 +204,8 @@ user classes to use from the same locustfile by passing them as command line arg
 
     $ locust -f locust_file.py WebUser MobileUser
 
-If you wish to simulate more users of a certain type you can set a weight attribute on those
-classes. Say for example, web users are three times more likely than mobile users:
+If you wish to simulate more users of a certain type than another you can set a weight attribute on those
+classes. The code below will make Locust spawn 3 times as many WebUsers as MobileUsers:
 
 .. code-block:: python
 
@@ -217,9 +217,9 @@ classes. Say for example, web users are three times more likely than mobile user
         weight = 1
         ...
 
-Also you can set the :py:attr:`fixed_count <locust.User.fixed_count>` attribute.
-In this case the weight attribute will be ignored and the exact count users will be spawned.
-These users are spawned first. In the example below, only one instance of AdminUser
+Also, you can set the :py:attr:`fixed_count <locust.User.fixed_count>` attribute.
+In this case, the weight attribute will be ignored and only that exact number users will be spawned.
+These users are spawned before any regular, weighted ones. In the example below, only one instance of AdminUser
 will be spawned, to make some specific work with more accurate control
 of request count independently of total user count.
 
@@ -249,7 +249,7 @@ tasks attribute
 ---------------
 
 A User class can have tasks declared as methods under it using the :py:func:`@task <locust.task>` decorator, but one can also
-specify tasks using the *tasks* attribute which is described in more details :ref:`below <tasks-attribute>`.
+specify tasks using the *tasks* attribute, which is described in more details :ref:`below <tasks-attribute>`.
 
 environment attribute
 ---------------------
@@ -281,12 +281,9 @@ Tasks
 =====
 
 When a load test is started, an instance of a User class will be created for each simulated user
-and they will start running within their own green thread. When these users run they pick tasks that
+and they will start running within their own greenlet. When these users run they pick tasks that
 they execute, sleep for awhile, and then pick a new task and so on.
 
-The tasks are normal python callables and - if we were load-testing an auction website - they could do
-stuff like "loading the start page", "searching for some product", "making a bid", etc.
-
 @task decorator
 ---------------
 
@@ -617,7 +614,7 @@ Using :ref:`catch_response <catch-response>` and accessing `request_meta <https:
 HTTP Proxy settings
 -------------------
 To improve performance, we configure requests to not look for HTTP proxy settings in the environment by setting
-requests.Session's trust_env attribute to ``False``. If you don't want this you can manually set
+requests.Session's trust_env attribute to ``False``. If you don't want this, you can manually set
 ``locust_instance.client.trust_env`` to ``True``. For further details, refer to the
 `documentation of requests <https://requests.readthedocs.io/en/master/api/#requests.Session.trust_env>`_.
 
@@ -644,7 +641,7 @@ For more configuration options, refer to the
 
 TaskSets
 ================================
-TaskSets is a way to structure tests of hierarchical web sites/systems. You can :ref:`read more about it here <tasksets>`.
+TaskSets is a way to structure tests of hierarchical websites/systems. You can :ref:`read more about it here <tasksets>`.
 
 Examples
 ========
@@ -660,7 +657,7 @@ in any Python program. The current working directory is automatically added to p
 so any python file/module/packages that resides in the working directory can be imported using the
 python ``import`` statement.
 
-For small tests, keeping all of the test code in a single ``locustfile.py`` should work fine, but for
+For small tests, keeping all the test code in a single ``locustfile.py`` should work fine, but for
 larger test suites, you'll probably want to split the code into multiple files and directories.
 
 How you structure the test source code is of course entirely up to you, but we recommend that you