Update PULL_REQUEST_TEMPLATE.md
Small changes inline
# Standard GPflow pull request
-At first, thank you very much for spending time on contibuting to GPflow.\
+At first, thank you very much for spending time on contributing to GPflow.\
This template exists to help us to grasp your work without asking very common and questions. The template helps you to get thorough feedback as well.
@@ -12,11 +12,11 @@ This template exists to help us to grasp your work without asking very common an
### Title
-Squeeze it. Be creative. There is no necessity in any marks like [BUG], {feature} and cetera. We have github labels for that.
+Squeeze it. Be creative. There is no necessity for any marks like [BUG], {feature} and cetera. We have github labels for that.
### Description
-Describe your contribution via writing down context and reasons. Make it clear either it is a **bug fix**, **feature** or **enhancement**. Do not make your it very wordy, keep it short and simple.
+Describe your contribution by writing down the context and reasons. Make it clear whether it is a **bug fix**, **feature** or **enhancement**. Do not make it very wordy, keep it short and simple.
* Bad example: `This is a bug-fix found at #111.`
* Bad example: `Add new SuperMagic optimizer.`
@@ -25,14 +25,14 @@ Describe your contribution via writing down context and reasons. Make it clear e
### Minimal working example
-No matter how good description is, the best thing you can do for making reviewer's life much easier is to add a minimal working example. Ideally, it should be a short code snippet with relevant comments. Once, MWE becomes big (> 50 lines), you should consider [gist](https://gist.github.com) instead.
+No matter how good the description is, the best thing you can do for making a reviewer's life much easier is to add a minimal working example (MWE). Ideally, it should be a short code snippet with relevant comments. If a MWE is big (> 50 lines), you should consider [gist](https://gist.github.com) instead.
* If your PR is a *bug* related fix, then your MWE must disclose the bug using synthetic example or "real" one.
-* When you propose new *feature*, the MWE must show different use cases and clear up benefits from it.
+* When you propose a new *feature*, the MWE must show different use cases and demonstrate its benefits.
## Code quality requirements
-For details, look at [contributing.md](../contributing.md) code quality requirements section. Nevertheless, *Main* points listed here:
+For details, look at the code quality requirements section in [contributing.md](../contributing.md). The *main* points are repeated here:
* _New feature's_ code must be accompanied with [detailed](../contributing.md) docstrings.
* _New features_ must be covered with tests.
