Please note that while this repository is public, at the moment no contributions from outside contributors are accepted. This project is a TU Delft course project (TI3806) and the course rules disallow this. As such, for now this documents merely acts as an internal set of guidelines.
- Make it clear in the issue tracker what you are working on.
- Keep the sprint backlog up to date.
- Be descriptive in your pull request description: what is it for, why is it done this way, etc, or which user story.
- Do not make cosmetic changes to unrelated files or sections in the same pull request. This creates noise, making reviews harder to do.
When submitting pull requests (commonly referred to as "PRs"), include one of the following tags prepended to the title:
[WIP]- Work In Progress: the PR will change, so while there is no immediate need for review, the submitter still might appreciate it.[RFC]- Request For Comment: the PR needs reviewing and/or comments.[RDY]- Ready: the PR has been reviewed by at least one other person and has no outstanding issues.
Please keep your tags up to date.
- Do not work on your PR on the master branch, use a feature branch instead.
- Rebase your feature branch onto (upstream) master before opening the PR.
- Keep up to date with changes in (upstream) master so your PR is easy to merge.
- Try to actively tidy your history: combine related
commits with interactive rebasing, separate monolithic commits, etc. If your
PR is still
[WIP], feel free to force-push to your feature branch to tidy your history. Please read how to use rebase, to see how to squash or otherwise edit your commits.
Before making a pull request, please rebase on upstream master (see above) and
provide a clean history (see above). Please also make sure to run mvn test,
to see if there are any outstanding issues (Checkstyle (see below), PMD, FindBugs, etc).
All PRs are expected to have (unit) tests to go with them. If no tests are provided, PRs will not be merged unless there is a viable reason. PRs will also not be merged if the Travis continuous integration build fails.
For new code, run Checkstyle to detect style errors. It's not perfect, so some warnings may be false positives/negatives. Maven is set up to fail on every style error. Should Checkstyle report too much false positives/negatives, please edit Checkstyle's configuration. To have Checkstyle ignore certain cases, see this stackoverflow question.
The purpose of these guidelines is to make reviews easier and make the history logs more valuable.
- Try to keep the first line under 72 characters.
- If necessary, include further description after a blank line.
- Don't make the description too verbose by including obvious things, but don't spare clarifications for anything that may be not so obvious. Some commit messages are pages long, and that's fine if there's no better place for those comments to live.
- Recommended: Prefix logically-related commits with a consistent
identifier in each commit message. For already used identifiers, see the
commit history for the respective file(s) you're editing.
For example:
<ClassName>: fix all the issues
- Use the imperative voice: "Fix bug" rather than "Fixed bug" or "Fixes bug."
You may find it easier to instead use an interactive program for code reviews,
such as tig.
Kindly taken and modified from neovim.