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

Latest commit

 

History

History
62 lines (46 loc) · 2.85 KB

CONTRIBUTING.md

File metadata and controls

62 lines (46 loc) · 2.85 KB

Contributing

We <3 contributors!

This document describes guidelines for contributing as well as the process of assuring the security of all contracts. They are meant to make life easier for us, but also to help you understand how stuff gets into the master branch.

Prepare

Before working with the contracts you need to install all the dependencies. You can do this with

$ yarn install

Compile

To compile the contracts just run:

$ yarn run compile

Deploying contracts

Start by creating a file called seed containing a 12 word seed and put in in the main folder of this repo. Make sure that the first address generated by this seed has funds on the network you want to deploy on. Contracts can then be deployed by running:

$ yarn run deploy-<network name>

where:

network name
mainnet
rinkeby
kovan
ropsten
infuranet
local

All of the above uses infura to send the deployment transactions, with exeception of local which uses localhost:8545.

After contracts have been deployed to all relevant networks, make sure to generate the artifact index by running the following two commands:

$ yarn build-artifact-index
$ yarn generate-readme

These commands make sure that the artifacts a user gets are correct and that the readme has the latest addresses for contracts.

Diagrams

Diagrams are made with PlantUML.

Making a pull request

Once you have made changes that you want to get into, you need to create a pull request. We follow git flow, so make sure to name your branch in the format of feature/description-of-your-feature or hotfix/description-of-your-fix. Also make sure that your pull request is against the develop branch and not master.

Review process

The contracts in this repo are an essential part of the uport ecosystem. Therefore it is very important that they are properly reviewed to minimize the risk of potential bugs and exploits.

Merging into develop

A pull request being merged into develop needs to be reviewed by at least two members of the uport team.

Merging into master

A pull request being merged into master needs to be reviewed by a security team that is external to the uport team. To prepare for this make a branch from develop called release/<semver-number> and make neccesary preparations. Then make a pull request to master. The develop branch has been reviewed by the uport team and should generally be in a good state. The external review team audits the newly created branch. If there are changes needed they are made in this branch. Once the external team are happy with the state of the contracts make sure that contracts are deployed on the relevant networks. The release branch can then be merged into master, and also develop.

Relevant networks

Right now the networks we want the contracts deployed on are rinkeby, kovan, ropsten and mainnet.