## Introduction
The goal of the DMPRoadmap project is to provide the community with a reliable and stable platform for managing data management plans. This means that all development efforts should adhere to some basic tenets to ensure that the system remains stable and provides functionality for the community as a whole.

These guidelines are an attempt to ensure that we are able to provide the community with a reliable system, stable APIs, a clear roadmap, and a predictable release schedule. 

A contribution consists of any work that is voluntarily submitted to the project. This includes bug fixes, enhancements and documentation that is intended as an improvement to the DMP Roadmap system.

### Let us know that you'll be working on the issue!

If you would like to contribute a feature or bug fix, let us know by commenting on the ticket. We can track the ticket and ensure that no one else is working on it at the same time.

### Forking the repository

If you would like to contribute to the project and have not yet forked the codebase, click on the 'Fork' button in the upper right hand corner of this page. This will create a copy of the DMPRoadmap repository for you to work with.

Once the fork has been created, clone the repository onto your machine. See Github's (documentation on cloning)[https://help.github.com/articles/cloning-a-repository/].

On your local machine, add a remote that points to the original DMPRoadmap codebase. This will allow you to pull down the latest changes and sync up your forked repository

Run the following from your local clone of the repository to setup a remote that will allow you to pull down the latest changes from DMPRoadmap. Then pull down the development branch:
```bash
git remote add upstream https://github.com/DMPRoadmap/roadmap.git
git fetch development
```

### Pulling down the latest changes from DMPRoadmap into your fork

If you've already forked the project, you should make sure you pull down the latest changes before working on yoour feature, bug fix or translations.


### Create a new feature/bug fix/translations branch 

You should always base your new branch off of the development branch. We keep this branch up to date with the latest release. Checkout the development branch, sync it with DMPRoadmap and then push the latest up to your own fork:

```bash
git checkout development
git pull upstream development
git push origin development
git checkout -b [my-branch]
```

The name of the branch is up to you. Once your branch has been created you can start making changes. 

Please refer to the pull request checklists below to make sure you've included everything we require in your PR!

### Rebase your commits

This is only necessary if you have made more than one git commit on your feature branch.

When you are finished making changes, we ask that all contributors squash their commits into a single git commit. This helps us keep the git history clean and makes it easier to revert any changes if necessary.

_Note that if this is your first time rebasing a branch we recommend making a backup of the branch first since a rebase creates the potential for you to lose your changes if its done incorrectly: `git checkout -b [feature branch]-bak && git checkout [feature branch]`_

To rebase your feature branch you should follow this example:
  
First locate the last commit that occurred before your changes were made in the feature branch by using `git log`. Here is an of a recent bug fix branch:
```bash
commit c74a4ecdb37c0d4396e97db019f35d8a5000d069 (HEAD -> issue1603)
Author: John Doe 
Date:   Fri Jun 15 13:33:27 2018 -0700

    added isActiveTab for profile and reference pages

commit 2b003da459cc5d605dda534898ea4bf89b4f2172
Author: John Doe 
Date:   Fri Jun 15 13:26:40 2018 -0700

    fixed issue with active tabs

commit bd9b31d8ca1dcee5e82639dfd9b41a4e2618e2bc (upstream/development, development)
Merge: f4d058df 7ca739e3
Author: Another Developer 
Date:   Fri Jun 14 09:20:41 2018 +0100

    Merge pull request #1610 from CDLUC3/issue1333
```

In the git log above, the developer has made two commits ('fixed issue with active tabs' and 'added isActiveTab for profile and reference pages'). Before they contribute this bug fix back to the core codebase they need to squash those 2 commits into one. To do that, they should copy the last commit id for the commit that happened before they started making changes. In this case they would copy 'bd9b31d8ca1dcee5e82639dfd9b41a4e2618e2bc' from the 'Merge pull request #1610 from CDLUC3/issue1333' commit.

Once you've identified the correct commit id run the rebase command with the '-i' flag: ` git rebase -i bd9b31d8ca1dcee5e82639dfd9b41a4e2618e2bc`

This will open an editor window that will ask you to pick/squash your commits. You should always 'pick' the first one in the list and 'squash' all others. So in our example:
```bash
pick 2b003da4 fixed issue with active tabs
pick c74a4ecd added isActiveTab for profile and reference pages