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 and attend all Eth 2.0 implementers calls.

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 is where we track what needs to be done and Pull Requests is where code gets reviewed. We use gitter to chat informally.

General Work-Flow

We recommend the following work-flow for contributors:

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.
Work in a feature branch of your personal fork (github.com/YOUR_NAME/lighthouse) of the main repository (github.com/sigp/lighthouse).
Once you feel you have addressed the issue, create a pull-request to merge your changes in to the main repository.
Wait for the repository maintainers to review your changes to ensure the issue is addressed satisfactorily. Optionally, mention your PR on gitter.
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:

Create a fork and clone it to your local machine.
Add an "upstream" branch that tracks github.com/sigp/lighthouse using $ git remote add upstream https://github.com/sigp/lighthouse.git (pro-tip: use SSH instead of HTTPS).
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.
Commit your changes and push them to your fork with $ git push origin your_feature_name.
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 by Rob Allen that provides much more detail on each of these steps, if you're having trouble. As always, jump on gitter 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.

5.1 KiB Raw Blame History