From b1e1aadba1c6341b42454e6406d8b591f5cd7a71 Mon Sep 17 00:00:00 2001 From: Alejandro Santander Date: Tue, 16 Jan 2018 19:11:30 -0300 Subject: [PATCH] Simplified and updated CONTRIBUTING.md, small update to README.md --- CONTRIBUTING.md | 119 +++++++++++++++--------------------------------- README.md | 1 + 2 files changed, 37 insertions(+), 83 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 389c02c26..166fb9e71 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,109 +1,62 @@ -Contributing to Zeppelin +Contributing to Open Zeppelin ======= -## Design Guidelines +We really appreciate and value contributions to Open Zeppelin. Please take 5' to review the items listed below to make sure that your contributions are merged as soon as possible. -These are some global design goals in Zeppelin. +## Contribution guidelines -### D0 - Security in Depth -We strive to provide secure, tested, audited code. To achieve this, we need to match intention with function. Thus, documentation, code clarity, community review and security discussions are fundamental. +Smart contracts manage value and are highly vulnerable to errors and attacks. We have very strict guidelines, please make sure to review them: ["Contribution guidelines wiki entry"](https://github.com/OpenZeppelin/zeppelin-solidity/wiki/Contrbuting-guidelines). -### D1 - Simple and Modular -Simpler code means easier audits, and better understanding of what each component does. We look for small files, small contracts, and small functions. If you can separate a contract into two independent functionalities you should probably do it. +## Branching -### D2 - Naming Matters +When it comes to branching, we follow the "git-flow" method. Please see ["Git flow wiki entry"](https://github.com/OpenZeppelin/zeppelin-solidity/wiki/Git-flow). -We take our time with picking names. Code is going to be written once, and read hundreds of times. Renaming for clarity is encouraged. +*IMPORTANT* This means that our main development branch is `development`, not `master`. -### D3 - Tests +## Creating Pull Requests (PRs) -Write tests for all your code. We encourage Test Driven Development so we know when our code is right. Even though not all code in the repository is tested at the moment, we aim to test every line of code in the future. +As a contributor, you are expected to fork this repository, work on your own fork and then submit pull requests. The pull requests will be reviewed and eventually merged into the main repo. See ["Fork-a-Repo"](https://help.github.com/articles/fork-a-repo/) for how this works. -### D4 - Check preconditions and post-conditions +*IMPORTANT* Please use `rebase` instead of `merge`. -A very important way to prevent vulnerabilities is to catch a contract’s inconsistent state as early as possible. This is why we want functions to check pre- and post-conditions for executing its logic. When writing code, ask yourself what you are expecting to be true before and after the function runs, and express it in code. +## A typical workflow -### D5 - Code Consistency +1) Make sure your fork is up to date with the main repository: -Consistency on the way classes are used is paramount to an easier understanding of the library. The codebase should be as unified as possible. Read existing code and get inspired before you write your own. Follow the style guidelines. Don’t hesitate to ask for help on how to best write a specific piece of code. - -### D6 - Regular Audits -Following good programming practices is a way to reduce the risk of vulnerabilities, but professional code audits are still needed. We will perform regular code audits on major releases, and hire security professionals to provide independent review. - -## Style Guidelines - -The design guidelines have quite a high abstraction level. These style guidelines are more concrete and easier to apply, and also more opinionated. - -### General - -#### G0 - Default to Solidity's official style guide. - -Follow the official Solidity style guide: https://solidity.readthedocs.io/en/latest/style-guide.html - -#### G1 - No Magic Constants - -Avoid constants in the code as much as possible. Magic strings are also magic constants. - -#### G2 - Code that Fails Early - -We ask our code to fail as soon as possible when an unexpected input was provided or unexpected state was found. - -#### G3 - Internal Amounts Must be Signed Integers and Represent the Smallest Units. - -Avoid representation errors by always dealing with weis when handling ether. GUIs can convert to more human-friendly representations. Use Signed Integers (int) to prevent underflow problems. - - -### Testing - -#### T1 - Tests Must be Written Elegantly - -Style guidelines are not relaxed for tests. Tests are a good way to show how to use the library, and maintaining them is extremely necessary. - -Don't write long tests, write helper functions to make them be as short and concise as possible (they should take just a few lines each), and use good variable names. - -#### T2 - Tests Must not be Random - -Inputs for tests should not be generated randomly. Accounts used to create test contracts are an exception, those can be random. Also, the type and structure of outputs should be checked. - - -### Documentation - -TODO - -## Pull Request Workflow +``` +cd my-zeppelin-solidity-fork +git fetch upstream +git checkout development +git pull --rebase upstream development +``` -Our workflow is based on GitHub's pull requests. We use feature branches, prepended with: `test`, `feature`, `fix`, `refactor`, or `remove` according to the change the branch introduces. Some examples for such branches are: -```sh -git checkout -b test/some-module -git checkout -b feature/some-new-stuff -git checkout -b fix/some-bug -git checkout -b remove/some-file +2) Branch out from `development` into `fix/some-bug-#123`: +(Postfixing #123 will associate your PR with the issue #123 and make everyone's life easier =D) +``` +git checkout -b fix/some-bug-#123 ``` -If your branch is planned to fix an open issue, postfix your branch name with the issue number like `fix/some-bug-#123`. +3) Make your changes, add your files, commit and push to your fork. -We expect pull requests to be rebased to the master branch before merging: -```sh -git remote add zep git@github.com:OpenZeppelin/zeppelin-solidity.git -git pull --rebase zep master +``` +git add -A +git commit "Fix some bug #123" +git push origin fix/some-bug-#123 ``` -Note that we require rebasing your branch instead of merging it, for commit readability reasons. +4) Go to [github.com/OpenZeppelin/zeppelin-solidity](https://github.com/OpenZeppelin/zeppelin-solidity) in your web browser and issue a new pull request. -After that, you can push the changes to your fork, by doing: -```sh -git push origin your_branch_name -git push origin feature/some-new-stuff -git push origin fix/some-bug -``` +*IMPORTANT* Read the PR template very carefully and make sure to follow all the instructions. These instructions +refer to some very important conditions that your PR must meet in order to be accepted, such as making sure that all tests pass, JS linting tests pass, solidity linting tests pass, etc. + +5) Maintainers will review your code and possibly ask for changes before your code is pulled in to the main repository. We'll check that all tests pass, review the coding style, and check for general code correctness. If everything is OK, we'll merge your pull request and your code will be part of Open Zeppelin. -Finally go to [github.com/OpenZeppelin/zeppelin-solidity](https://github.com/OpenZeppelin/zeppelin-solidity) in your web browser and issue a new pull request. +*IMPORTANT* It is not uncommon for almost finished PRs to stay unmerged for a long time, so, considering the effort you put in your code, please pay attention to the maintainer's feedback since its a necessary to keep up with the standards Open Zeppelin attains to. -Main contributors will review your code and possibly ask for changes before your code is pulled in to the main repository. We'll check that all tests pass, review the coding style, and check for general code correctness. If everything is OK, we'll merge your pull request and your code will be part of Zeppelin. +## All set! -If you have any questions feel free to post them to -[github.com/OpenZeppelin/zeppelin-solidity/issues](https://github.com/OpenZeppelin/zeppelin-solidity/issues). +If you have any questions feel free to post them to github.com/OpenZeppelin/zeppelin-solidity/issues. -Finally, if you're looking to collaborate and want to find easy tasks to start, [look at the issues we marked as easy](https://github.com/OpenZeppelin/zeppelin-solidity/labels/easy). +Finally, if you're looking to collaborate and want to find easy tasks to start, look at the issues we marked as ["Good first issue"](https://github.com/OpenZeppelin/zeppelin-solidity/labels/good%20first%20issue). Thanks for your time and code! diff --git a/README.md b/README.md index 0cae1a745..31cbb8558 100644 --- a/README.md +++ b/README.md @@ -56,6 +56,7 @@ Interested in contributing to OpenZeppelin? - Framework proposal and roadmap: https://medium.com/zeppelin-blog/zeppelin-framework-proposal-and-development-roadmap-fdfa9a3a32ab#.iain47pak - Issue tracker: https://github.com/OpenZeppelin/zeppelin-solidity/issues - Contribution guidelines: https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/CONTRIBUTING.md +- Wiki: https://github.com/OpenZeppelin/zeppelin-solidity/wiki ## Collaborating organizations and audits by OpenZeppelin - [Golem](https://golem.network/)