administration: small grammar fixes scheduling (#793)

Signed-off-by: mickeypash <pashov.m@gmail.com>

Author: mickeypash

administration/scheduling-and-retries.md

@@ -1,14 +1,14 @@
 # Scheduling and Retries
 
-[Fluent Bit](https://fluentbit.io) has an Engine that helps to coordinate the data ingestion from input plugins and call the _Scheduler_ to decide when is time to flush the data through one or multiple output plugins. The Scheduler flush new data every a fixed time of seconds and Schedule retries when asked.
+[Fluent Bit](https://fluentbit.io) has an Engine that helps to coordinate the data ingestion from input plugins and calls the _Scheduler_ to decide when it is time to flush the data through one or multiple output plugins. The Scheduler flushes new data at a fixed time of seconds and the _Scheduler_ retries when asked.
 
-Once an output plugin gets call to flush some data, after processing that data it can notify the Engine three possible return statuses:
+Once an output plugin gets called to flush some data, after processing that data it can notify the Engine three possible return statuses:
 
 * OK
 * Retry
 * Error
 
-If the return status was **OK**, it means it was successfully able to process and flush the data, if it returned an **Error** status, means that an unrecoverable error happened and the engine should not try to flush that data again. If a **Retry** was requested, the _Engine_ will ask the _Scheduler_ to retry to flush that data, the Scheduler will decide how many seconds to wait before that happen.
+If the return status was **OK**, it means it was successfully able to process and flush the data, if it returned an **Error** status, means that an unrecoverable error happened and the engine should not try to flush that data again. If a **Retry** was requested, the _Engine_ will ask the _Scheduler_ to retry to flush that data, the Scheduler will decide how many seconds to wait before that happens.
 
 ## Configuring Retries
 
@@ -18,11 +18,11 @@ The Scheduler provides a simple configuration option called **Retry\_Limit** whi
 | :--- | :--- | :--- |
 | Retry\_Limit | N | Integer value to set the maximum number of retries allowed. N must be >= 1 \(default: 1\) |
 | Retry\_Limit | `no_limits` or `False` | When Retry\_Limit is set to `no_limits` or`False`, means that there is not limit for the number of retries that the Scheduler can do. |
-| Retry\_Limit | no\_retries | When Retry\_Limit is set to no\_retries, means that reries are disabled and Scheduler would not try to send data to destination if it failed first time. |
+| Retry\_Limit | no\_retries | When Retry\_Limit is set to no\_retries, means that reries are disabled and Scheduler would not try to send data to the destination if it failed the first time. |
 
 ### Example
 
-The following example configure two outputs where the HTTP plugin have an unlimited number of retries and the Elasticsearch plugin have a limit of 5 times:
+The following example configures two outputs where the HTTP plugin has an unlimited number of while the Elasticsearch plugin have a limit of 5 retries:
 
 ```text
 [OUTPUT]