How to contribute

We are glad you are reading this, because we need volunteer developers to help this project come to fruition.

If you don't have anything you are working on we have a list of newbie friendly issues you can help out with.

If you haven't already, come find us on our mailing list. We want you working on things you're excited about.

Harvey, like most other open source projects, has a Code of Conduct that it expects its contributors and core team members to adhere to.

Here are some important resources:

Our mailing list is where the development discussion happens.
Man Pages are where you can documentation from head of the repository.
The Issue Tracker is our day-to-day project management space.

Testing

We make use Travis-CI and make sure we can build your pull-requests before we can accept your contributions.

Submitting a patch

Harvey uses Github Pull Requests to accept contributions.

Clone the repository: git clone https://github.com/Harvey-OS/harvey.git. It is also possible to use git instead of https if you have an SSH public key stored on Github: git clone git@github.com:Harvey-OS/harvey.git. This makes submitting contributions easier. For the rest of this manual we assume to use https.
Check out a feature branch for your work on by executing: git checkout -b feature-name. For example, @keedon selected the branch name statscrash for issue #70.
Make changes
Commit with a descriptive message:
```
$ git commit -m "A brief summary of the commit
>
> A paragraph describing what changed and its impact."
```
For a representative example, look at @keedon's commit message for issue #70 mentioned above. You can also use graphical git tools such as git gui if you like.
Fork the repo (only once).

Add the repo as a remote (every time you clone the repository)

git remote add yourname https://github.com/yourusername/harvey.git

where "yourname" is your github login name.

git remote -v should look like this:

$ git remote -v
yourname https://github.com/yourname/harvey.git (fetch)
yourname https://github.com/yourname/harvey.git (push)
origin https://github.com/Harvey-OS/harvey.git (fetch)
origin https://github.com/Harvey-OS/harvey.git (push)

Push your branch to your forked repository: git push yourname feature-name
Create a pull request by going to https://github.com/yourname/harvey/pull/new/feature-name or clicking the PR button
Add details of what you have worked on and your motivation. When you send a pull request, we greatly appreciate if you include emu output and additional tests: we can always use more test coverage. Please follow our coding conventions and make sure all of your commits are atomic in the sense of having one feature per commit.

Iterating on your work

A Github pull request or a Gerrit CL roughly serve the same purpose: they are feedback loops for people to give feedback and for you to iterate on your work in response to that feedback, so be ready to repeat steps!
When iterating on your work continue committing to the same branch and push the changes up to your fork. Github will track the changes and update the pull request accordingly.
Most of the time, when you are ready to submit your pull request, someone else will have merged something to master, at which point your branch will have been outdated, GitHub provides a convenient way of updating your branch right from your pull request.
When you click that button, GitHub will update your branch, at which point you will have to git pull yourname feature-name and update your local repo before committing more changes.
If your changes conflict with something that was merged into the branch, you will have to resolve the changes manually before submitting the changes.

Keeping up to date with the master branch

If you're working in a branch that is outdated with respect to the master branch, just do a git pull --rebase. This will put your changes after the pull. In the case that there would be conflicts, you will have to solve them manually, but they are marked with something like ">>>>>HEAD" and git will tell you about which files are in conflict.

More information

Coding conventions

If you read the code you should get a hang of it but a loose listing of our Style-Guide exists, we recommend you check it out.

We have also automated the process via clang-format so before you submit a change please format your diff.

How to clang-format a diff

Adopted from Open Government Contribution Guidelines

CONTRIBUTING.md 6.6 KB Verlauf Originalformat