Creating a pull request

MultiBit HD is a complex project and requires a high level of experience from developers.

Acceptance criteria for code changes

We don't accept pull requests into the code unless these criteria are met:

• there is a clearly defined issue that is being addressed in its own feature branch (e.g. issue-123)
• the code in the pull request does not deviate from that issue (no unrelated commits)
• all coding standards are followed
• existing design patterns are followed
• there are unit tests for code changes
• there are functional tests (e.g. Swing FEST tests) for UI changes
• the pull request builds on Travis
• the owner of the pull request agrees that the code be released under the MIT licence and does not contain any copyrighted material that they do not own

Acceptance criteria for documentation changes

Documentation pull requests are less of a security risk than code changes so tend to be accepted much more readily. That said, the following criteria must be met:

• spelling and grammar must be correct for the language
• in general we use UK English for documentation

How to prepare a pull request

1. Add yourself to the watch list of the upstream repo.
2. Fork the project.
3. In the upstream repo pick an issue that you are interested in working on (or have been assigned if you are offering general support) and write a comment indicating that you're working on it in your downstream fork.
4. We'd recommend that you don't start work until you've been given the go-ahead by a developer unless you're happy to risk wasting your time.
5. Create a suitable feature branch matching the issue (e.g. issue-123)
6. Start work and remain very focused on making the minimum changes to fix the issue.
7. When ready use the "Create New Pull Request" to start the review process.

Code review protocol

Developers have very limited time and can be terse so don't be put off. Just make the suggested changes and re-issue the pull request. There may be a lot of back and forth before your work is accepted. Over time developers will become used to you and your pull requests will get accepted faster, but always only after a code review.

Some pull requests may require several developers to acknowledge ("ACK") a change before acceptance. For others a quick looks good to me ("LGTM") is sufficient.