Bring doc from the substrate repo

.editorconfig

@@ -0,0 +1,16 @@
+root = true
+[*]
+indent_style=tab
+indent_size=tab
+tab_width=4
+end_of_line=lf
+charset=utf-8
+trim_trailing_whitespace=true
+max_line_length=120
+insert_final_newline=true
+
+[*.yml]
+indent_style=space
+indent_size=2
+tab_width=8
+end_of_line=lf

CODE_OF_CONDUCT.md → CODE_OF_CONDUCT.adoc

@@ -1,10 +1,10 @@
-# Contributor Covenant Code of Conduct
+= Contributor Covenant Code of Conduct
 
-## Our Pledge
+== Our Pledge
 
 In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
 
-## Our Standards
+== Our Standards
 
 Examples of behavior that contributes to creating a positive environment include:
 
@@ -22,30 +22,30 @@ Examples of unacceptable behavior by participants include:
 * Publishing others' private information, such as a physical or electronic address, without explicit permission
 * Other conduct which could reasonably be considered inappropriate in a professional setting
 
-### Facilitation, Not Strongarming
+=== Facilitation, Not Strongarming
 
 We recognise that this software is merely a tool for users to create and maintain their blockchain of preference. We see that blockchains are naturally community platforms with users being the ultimate decision makers. We assert that good software will maximise user agency by facilitate user-expression on the network. As such:
 
 * This project will strive to give users as much choice as is both reasonable and possible over what protocol they adhere to; but
 * use of the project's technical forums, commenting systems, pull requests and issue trackers as a means to express individual protocol preferences is forbidden.
 
-## Our Responsibilities
+== Our Responsibilities
 
 Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
 
 Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
 
-## Scope
+== Scope
 
 This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
 
-## Enforcement
+== Enforcement
 
 Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at admin@parity.io. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
 
 Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
 
-## Attribution
+== Attribution
 
 This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
 

CONTRIBUTING.adoc

@@ -0,0 +1,50 @@
+= Contributing
+
+`Substrate` projects is a **OPENISH Open Source Project**
+
+== What?
+
+Individuals making significant and valuable contributions are given commit-access to a project to contribute as they see fit. A project is more like an open wiki than a standard guarded open source project.
+
+== Rules
+
+There are a few basic ground-rules for contributors (including the maintainer(s) of the project):
+
+. **No `--force` pushes** or modifying the Git history in any way. If you need to rebase, ensure you do it in your own repo.
+. **Non-master branches**, prefixed with a short name moniker (e.g. `gav-my-feature`) must be used for ongoing work.
+. **All modifications** must be made in a **pull-request** to solicit feedback from other contributors.
+. A pull-request *must not be merged until CI* has finished successfully.
+. Contributors should adhere to the https://github.com/paritytech/polkadot/wiki/Style-Guide[house coding style].
+
+Merging pull requests once CI is successful:
+
+. A pull request that does not alter any logic (e.g. comments, dependencies, docs) may be tagged https://github.com/paritytech/substrate/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+label%3AA2-insubstantial[`insubstantial`] and merged by its author.
+. A pull request with no large change to logic that is an urgent fix may be merged after a non-author contributor has reviewed it well.
+. All other PRs should sit for 48 hours with the https://github.com/paritytech/substrate/pulls?q=is%3Apr+is%3Aopen+label%3AA0-pleasereview[`pleasereview`] tag in order to garner feedback.
+. No PR should be merged until all reviews' comments are addressed.
+
+.Reviewing pull requests:
+When reviewing a pull request, the end-goal is to suggest useful changes to the author. Reviews should finish with approval unless there are issues that would result in:
+
+. Buggy behaviour.
+. Undue maintenance burden.
+. Breaking with house coding style.
+. Pessimisation (i.e. reduction of speed as measured in the projects benchmarks).
+. Feature reduction (i.e. it removes some aspect of functionality that a significant minority of users rely on).
+. Uselessness (i.e. it does not strictly add a feature or fix a known issue).
+
+.Reviews may not be used as an effective veto for a PR because:
+. There exists a somewhat cleaner/better/faster way of accomplishing the same feature/fix.
+. It does not fit well with some other contributors' longer-term vision for the project.
+
+== Releases
+
+Declaring formal releases remains the prerogative of the project maintainer(s).
+
+== Changes to this arrangement
+
+This is an experiment and feedback is welcome! This document may also be subject to pull-requests or changes by contributors where you believe you have something valuable to add or change.
+
+== Heritage
+
+These contributing guidelines are modified from the "OPEN Open Source Project" guidelines for the Level project: https://github.com/Level/community/blob/master/CONTRIBUTING.md

README.adoc

@@ -13,7 +13,7 @@ When we split them, we split the Polkadot code off into another repo, leaving th
 be what used to be Polkadot, along with its branches and releases.
 
 Things will be a little odd for a while. Polkadot PoC-2 remains as a branch `v0.2` in the **Substrate**
-repo. Polkadot PoC-3 *will be* in branch `v0.3` in the **Polkadot** repo. To play on the ("Krumme Lancke")
+repo. Polkadot PoC-3 *will be* in branch `v0.3` in the **Polkadot** repo. To play on the ("Krumme Lanke")
 testnet, you'll want the PoC-2 code which is in the **Substrate** repo. These instructions are up to date
 with this, but if you see "substrate" and are wondering why you need it for Polkadot, now you know.
 
@@ -118,103 +118,17 @@ You can start a development chain with:
 [source, shell]
 cargo run -- --dev
 
+include::doc/docker.adoc[]
 
-== Using Docker
+include::doc/shell-completion.adoc[]
 
-=== The easiest way
-
-The easiest/faster option is to use the latest image.
-
-
-.First run
-Let's first check the version we have. The first time you run this command, the polkadot docker image will be downloaded. This takes a bit of time and bandwidth, be patient:
-
-[source, shell]
-docker run --rm -it chevdor/polkadot:latest polkadot --version
-
-
-.Polkadot arguments
-You can also pass any argument/flag that polkadot supports:
-
-[source, shell]
-docker run --rm -it chevdor/polkadot:latest polkadot --name "PolkaDocker"
-
-
-.Run as deamon
-Once you are done experimenting and picking the best node name :) you can start polkadot as daemon, exposes the polkadot ports and mount a volume that will keep your blockchain data locally:
-
-[source, shell]
-docker run -d -p 30333:30333 -p 9933:9933 -p 9944:9944 -v /my/local/folder:/data chevdor/polkadot:latest polkadot
-
-.Docker image update
-If you have an image such as `latest` locally, docker will *not* bother downloading the very latest that may be available.
-To update:
-
-- stop and delete your containers (`docker stop ...` `docker rm ...`)
-- delete your previous image (`docker rmi chevdor/polkadot:latest`)
-- run as daemon again, the very latest image will be downloaded again
-
-=== Build your own image
-
-To get up and running with the smallest footprint on your system, you may use the Polkadot Docker image.
-You can either build it yourself (it takes a while...):
-
-[source, shell]
-----
-./docker/build.sh
-----
-
-=== Reporting issues
-
-If you run into issues with polkadot when using docker, please run the following command
-(replace the tag with the appropriate one if you do not use latest):
-
-[source, shell]
-docker run --rm -it chevdor/polkadot:latest polkadot --version
-
-This will show you the polkadot version as well as the git commit ref that was used to build your container.
-Just paste that in the issue you create.
-
-
-== Shell completion
-
-The Polkadot cli command supports shell auto-completion. For this to work, you will need to run the completion script matching you build and system.
-
-Assuming you built a release version using `cargo build --release` and use `bash` run the following:
-
-[source, shell]
-source target/release/completion-scripts/polkadot.bash
-
-You can find completion scripts for:
-- bash
-- fish
-- zsh
-- elvish
-- powershell
-
-To make this change persistent, you can proceed as follow:
-
-=== First install
-
-[source, shell]
-----
-COMPL_DIR=$HOME/.completion
-mkdir -p $COMPL_DIR
-cp -f target/release/completion-scripts/polkadot.bash $COMPL_DIR/
-echo "source $COMPL_DIR/polkadot.bash" >> $HOME/.bash_profile
-source $HOME/.bash_profile
-----
+include::doc/packages.adoc[]
 
-=== Update
+include::doc/networks/networks.adoc[leveloffset=+1]
 
-When you build a new version of Polkadot, the following will ensure you auto-completion script matches the current binary:
+include::CONTRIBUTING.adoc[leveloffset=+1]
 
-[source, shell]
+== License
 ----
-COMPL_DIR=$HOME/.completion
-mkdir -p $COMPL_DIR
-cp -f target/release/completion-scripts/polkadot.bash $COMPL_DIR/
-source $HOME/.bash_profile
+include::LICENSE[]
 ----
-
-include::doc/packages.adoc[]

doc/docker.adoc

@@ -0,0 +1,44 @@
+
+== Using Docker
+
+=== The easiest way
+
+The easiest/faster option is to use the latest image.
+
+Let´s first check the version we have. The first time you run this command, the polkadot docker image will be downloaded. This takes a bit of time and bandwidth, be patient:
+
+[source, shell]
+docker run --rm -it chevdor/polkadot:0.2.0 polkadot --version
+
+You can also pass any argument/flag that polkadot supports:
+
+[source, shell]
+docker run --rm -it chevdor/polkadot:0.2.0 polkadot --name "PolkaDocker"
+
+Once you are done experimenting and picking the best node name :) you can start polkadot as daemon, exposes the polkadot ports and mount a volume that will keep your blockchain data locally:
+
+[source, shell]
+docker run -d -p 30333:30333 -p 9933:9933 -v /my/local/folder:/data chevdor/polkadot:0.2.0 polkadot
+
+
+=== Build your own image
+
+To get up and running with the smallest footprint on your system, you may use the Polkadot Docker image.
+You can either build it yourself (it takes a while...):
+
+[source, shell]
+----
+ccd docker
+./build.sh
+----
+
+=== Reporting issues
+
+If you run into issues with polkadot when using docker, please run the following command
+(replace the tag with the appropriate one if you do not use latest):
+
+[source, shell]
+docker run --rm -it chevdor/polkadot:latest polkadot version
+
+This will show you the polkadot version as well as the git commit ref that was used to build your container.
+Just paste that in the issue you create.

doc/networks/dev.adoc

@@ -0,0 +1,9 @@
+
+=== Dev network
+
+You can run a simple single-node development "network" on your machine by running in a terminal:
+
+[source, shell]
+polkadot --dev
+
+You can muck around by cloning and building the http://github.com/paritytech/polka-ui and http://github.com/paritytech/polkadot-ui or just heading to https://polkadot.js.org/apps.

doc/networks/krummelanke.adoc

@@ -0,0 +1,4 @@
+
+=== Krumme Lanke
+
+Krumme Lanke is a testnet network used during the developement of PoC-2.

doc/networks/local.adoc

@@ -0,0 +1,16 @@
+
+=== Local Two-node Testnet
+
+If you want to see the multi-node consensus algorithm in action locally, then
+you can create a local testnet. You'll need two terminals open. In one, run:
+
+[source, shell]
+polkadot --chain=local --validator --key Alice -d /tmp/alice
+
+and in the other, run:
+
+[source, shell]
+polkadot --chain=local --validator --key Bob -d /tmp/bob --port 30334 --bootnodes '/ip4/127.0.0.1/tcp/30333/p2p/ALICE_BOOTNODE_ID_HERE'
+
+Ensure you replace `ALICE_BOOTNODE_ID_HERE` with the node ID from the output of
+the first terminal.

doc/networks/networks.adoc

@@ -0,0 +1,8 @@
+
+== Polkadot networks
+
+include::dev.adoc[]
+
+include::local.adoc[]
+
+include::krummelanke.adoc[]