Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update CONTRIBUTING.md #191

Merged
merged 2 commits into from Dec 24, 2017
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
67 changes: 33 additions & 34 deletions CONTRIBUTING.md
@@ -1,54 +1,53 @@

# Contributing
# Contribution Guide
___

Bug reports and pull requests very much welcomed.
Firstly, thanks for wanting to help with the development of DAOSTACK. All contributions, code or documents, should come from a forked version of the respective repository. Then the proposed changes must be submitted via a pull request to the master branch. All pull requests must be reviewed by the maintainers of the repository in question. Once a pull request has been reviewed & approved; you should merge and rebase, and then delete the branch.
GitHub [keywords](https://help.github.com/articles/closing-issues-using-keywords/) should be used when closing pull requests and issues.

Please make sure test pass before submitting a PR.
If you wish to submit more substantial changes or additions, please see the feature contributions section below.

We try to follow the style guidelines from http://solidity.readthedocs.io/en/develop/style-guide.html

The development id done on unix based systems.
## Git Practice

# Testing
Branches should be named with a brief semantic title.
Commit messages should be capitalised and follow these rules:
```
Short (50 chars or less) summary of changes

These contracts are tested using the truffle framework
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.

## Installation
Further paragraphs come after blank lines.

Make sure you have a recent version of [node.js](https://nodejs.org/) (7.6 and above) and [yarn](https://yarnpkg.com) package manager.
- Bullet points are okay, too

Installation of dependencies. After cloning the repository run:
- Typically a hyphen or asterisk is used for the bullet, preceded by a
single space, with blank lines in between, but conventions vary here

yarn
Issue: #1, #2
```
A properly formed Git commit subject line should always be able to complete the following sentence:

If applied, this commit will _Your subject line here_

## Run tests
**Please refer to [this guide](https://chris.beams.io/posts/git-commit/) for additional information.**

To run the test locally use a local blockchain using testrpc, just run:

testrpc
## Feature Contributions

On a second terminal, run the tests:
For the submission of more substantial changes or additions, an issue should be opened outlining what is being proposed for implementation. The title of the issue should be descriptive and brief, follow the same rules as a commit message, as outlined above. The body of the issue should detail the reasoning for the need of the work to be carried out and the desired outcome.

yarn run test

## Code Formatting and Commentary

# Style
### Javascript
All Javascript must be formatted with [ESLint](http://eslint.org/) using the DAOSTACK [configuration](https://github.com/daostack/daostack/blob/master/.eslintrc.json).

For solidity, we are following the style guide here: http://solidity.readthedocs.io/en/develop/style-guide.html

A Solidity linter (solium is installed, which can be run with:

yarn run solium

Code should survive Javascript linting as well:

yarn run lint

# Breakpoints

if you run tests with:

node debug ./node_modules/truffle/build/cli.bundled.js test

it is possible to use `debugger` statemetns and inspect the state
### Solidity
All Solidity files must follow the style guide found [here](http://solidity.readthedocs.io/en/develop/style-guide.html).
All Solidity code must pass [solium](https://github.com/duaraghav8/Solium) linter check using DAOSTACK [configuration](https://github.com/daostack/daostack/blob/master/.soliumrc.json).