Skip to content
This repository has been archived by the owner on Sep 5, 2020. It is now read-only.

Latest commit

 

History

History
69 lines (57 loc) · 2.31 KB

CONTRIBUTING.md

File metadata and controls

69 lines (57 loc) · 2.31 KB

Contributing

First and foremost, we appreciate your interest in this project. This document contains essential information, should you want to contribute.

Development discussion

For bugs, new features or improvements, open a new issue.

Which Branch?

Pull requests should always be done against the master branch.

Coding Style

This project follows the PSR-2 coding style guide and the PSR-4 autoloader standard.

PHPDoc

The following is a valid documentation block example:

/**
 * Index Occurrences.
 *
 * @param Index                $request
 * @param OccurrenceFilter     $filter
 * @param OccurrenceRepository $occurrenceRepository
 *
 * @throws \InvalidArgumentException
 * @throws \OutOfBoundsException
 * @throws \RuntimeException
 *
 * @return \Illuminate\Http\JsonResponse
 */
public function index(Index $request, OccurrenceFilter $filter, OccurrenceRepository $occurrenceRepository): JsonResponse
{
    // ...
}

Committing to git

Each commit MUST have a proper message describing the work that has been done. This is called Semantic Commit Messages.

Here's what a commit message should look like:

feat(Occurrences): implement API client to fetch occurrence data
^--^ ^---------^   ^-------------------------------------------^
|    |             |
|    |             +-> Description of the work in the present tense.
|    |
|    +---------------> Scope of the work.
|
+--------------------> Type: chore, docs, feat, fix, hack, refactor, style, or test.

Here are some tags to use:

feat(): add beta sequence
fix(): remove broken confirmation message
refact(): share logic between 4d3d3d3 and flarhgunnstow
docs(): explain hat wobble
chore(): add Oyster build script
style(): convert tabs to spaces
test(): ensure Tayne retains clothing

Branching strategy

We will be using the branch-per-issue workflow.

This means, that for each open issue, we'll create a corresponding git branch.

For instance, issue #123 should have a corresponding feat/ShortTaskDescription-WEB-123 branch, which MUST branch off the latest code in master.