Revision dd1d82af0d226f2a1e7843937472697c69a62006 authored by James Hensman on 16 October 2019, 15:31:39 UTC, committed by James Hensman on 16 October 2019, 15:31:39 UTC
1 parent a5a3e04
PULL_REQUEST_TEMPLATE.md
# Standard GPflow pull request
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 questions. The template helps you to get thorough feedback as well.
## PR content:
* [Title](#title)
* [Description](#description)
* [Minimal working example](#minimal-working-example)
### Title
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 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.`
* Good example: `Working on feature #111, we found that parameters of VGP are not instantiated properly. It causes arbitrary failures at training. The bug is fixed by adding necessary parameters to the list of trainables.`
### Minimal working example
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 explicitly showing what happened before and after.
* When you propose a new *feature*, the MWE must show different use cases and demonstrate its benefits.
## Code quality requirements
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.
* _Fixed bug_ must be proved by test suites.
* Use type annotations.
* Use `.pylintrc` for code formatting.
![swh spinner](/static/img/swh-spinner.gif)
Computing file changes ...