Merge pull request #45 from sigp/contributors_guide

Add CONTRIBUTING.md

CONTRIBUTING.md

@@ -0,0 +1,121 @@
+# Contributors Guide
+
+Lighthouse is an open-source Ethereum 2.0 client. We we're community driven and
+welcome all contribution. We aim to provide a constructive, respectful and fun
+environment for collaboration.
+
+We are active contributors to the [Ethereum 2.0 specification](https://github.com/ethereum/eth2.0-specs) and attend all [Eth
+2.0 implementers calls](https://github.com/ethereum/eth2.0-pm).
+
+This guide is geared towards beginners. If you're an open-source veteran feel
+free to just skim this document and get straight into crushing issues.
+
+## Why Contribute
+
+There are many reasons you might contribute to Lighthouse. For example, you may
+wish to:
+
+- contribute to the Ethereum ecosystem.
+- establish yourself as a layer-1 Ethereum developer.
+- work in the amazing Rust programming language.
+- learn how to participate in open-source projects.
+- expand your software development skills.
+- flex your skills in a public forum to expand your career
+  opportunities (or simply for the fun of it).
+- grow your network by working with core Ethereum developers.
+
+## How to Contribute
+
+Regardless of the reason, the process to begin contributing is very much the
+same. We operate like a typical open-source project operating on GitHub: the
+repository [Issues](https://github.com/sigp/lighthouse/issues) is where we
+track what needs to be done and [Pull
+Requests](https://github.com/sigp/lighthouse/pulls) is where code gets
+reviewed. We use [gitter](https://gitter.im/sigp/lighthouse) to chat
+informally.
+
+### General Work-Flow
+
+We recommend the following work-flow for contributors:
+
+1. **Find an issue** to work on, either because it's interesting or suitable to
+   your skill-set. Use comments to communicate your intentions and ask
+questions.
+2. **Work in a feature branch** of your personal fork
+   (github.com/YOUR_NAME/lighthouse) of the main repository
+   (github.com/sigp/lighthouse).
+3. Once you feel you have addressed the issue, **create a pull-request** to merge
+   your changes in to the main repository.
+4. Wait for the repository maintainers to **review your changes** to ensure the
+   issue is addressed satisfactorily. Optionally, mention your PR on
+[gitter](https://gitter.im/sigp/lighthouse).
+5. If the issue is addressed the repository maintainers will **merge your
+   pull-request** and you'll be an official contributor!
+
+Generally, you find an issue you'd like to work on and announce your intentions
+to start work in a comment on the issue. Then, do your work on a separate
+branch (a "feature branch") in your own fork of the main repository.  Once
+you're happy and you think the issue has been addressed, create a pull request
+into the main repository.
+
+### First-time Set-up
+
+First time contributors can get their git environment up and running with these
+steps:
+
+1. [Create a
+   fork](https://help.github.com/articles/fork-a-repo/#fork-an-example-repository)
+and [clone
+it](https://help.github.com/articles/fork-a-repo/#step-2-create-a-local-clone-of-your-fork)
+to your local machine.
+2. [Add an _"upstream"_
+   branch](https://help.github.com/articles/fork-a-repo/#step-3-configure-git-to-sync-your-fork-with-the-original-spoon-knife-repository)
+that tracks github.com/sigp/lighthouse using `$ git remote add upstream
+https://github.com/sigp/lighthouse.git` (pro-tip: [use SSH](https://help.github.com/articles/connecting-to-github-with-ssh/) instead of HTTPS).
+3. Create a new feature branch with `$ git checkout -b your_feature_name`. The
+   name of your branch isn't critical but it should be short and instructive.
+E.g., if you're fixing a bug with serialization, you could name your branch
+`fix_serialization_bug`.
+4. Commit your changes and push them to your fork with `$ git push origin
+   your_feature_name`.
+5. Go to your fork on github.com and use the web interface to create a pull
+   request into the sigp/lighthouse repo.
+
+From there, the repository maintainers will review the PR and either accept it
+or provide some constructive feedback.
+
+There's great
+[guide](https://akrabat.com/the-beginners-guide-to-contributing-to-a-github-project/)
+by Rob Allen that provides much more detail on each of these steps, if you're
+having trouble. As always, jump on [gitter](https://gitter.im/sigp/lighthouse)
+if you get stuck.
+
+
+## FAQs
+
+### I don't think I have anything to add
+
+There's lots to be done and there's all sorts of tasks. You can do anything
+from correcting typos through to writing core consensus code. If you reach out,
+we'll include you.
+
+### I'm not sure my Rust is good enough
+
+We're open to developers of all levels. If you create a PR and your code
+doesn't meet our standards, we'll help you fix it and we'll share the reasoning
+with you. Contributing to open-source is a great way to learn.
+
+### I'm not sure I know enough about Ethereum 2.0
+
+No problems, there's plenty of tasks that don't require extensive Ethereum
+knowledge. You can learn about Ethereum as you go.
+
+### I'm afraid of making a mistake and looking silly
+
+Don't be. We're all about personal development and constructive feedback. If you
+make a mistake and learn from it, everyone wins.
+
+### I don't like the way you do things
+
+Please, make an issue and explain why. We're open to constructive criticism and
+will happily change our ways.