Contributing

Celo is open source and we welcome open participation. We strive to be an open an inclusive community where everyone feels welcome and empowered to contribute, which also means following some ground rules and abiding to Celo’s Code of Conduct. Thanks for your interest!

Getting started

Find an area that is of interest and you would like to help with. Look for issues that are tagged as "help wanted" and “1 hour tasks” to get started. If you’d like to dig deeper, feel free to look at other labels and TODO’s in code comments. If there’s an issue you’re interested in contributing to or taking over, assign yourself to it and add a comment with your plans to address and target timeline. If there’s already someone assigned to it, please check with them before adding yourself to the assignee list.

Tasks range from minor to major improvements. Based on your interests, skillset, and level of comfort with the code-base feel free to contribute where you see appropriate. Our only ask is that you follow the guidelines below to ensure a smooth and effective collaboration.

Participation in the Celo project is subject to the Code of Conduct.

Ground Rules

There are a few basic ground rules for contributing:

  • PRs (pull requests) are preferred to issues, especially for small changes such as typos. Issues should be used for missing features and for broad-based changes.

  • For on-going work, use your own side-branch and not the master branch.

  • For non-trivial amounts of work, we encourage you to submit PRs regularly to solicit feedback.

  • Please double check your work before submitting it. Submissions with typos, spelling, and grammatical errors may not be merged until fixed.

  • Try to remain as objective and fact-based as possible.

Submitting PRs

We encourage you to PR (pull request) your work regularly and often to solicit feedback and to ensure everyone has an idea of what you’re working on. If you’ve just started, we suggest creating a PR with “WIP” (Work In Progress) in the title and let us know when it’s ready to review in the comments.

Please make sure your PR:

  • Is assigned to one of the core team members building Celo

  • Provides a comprehensive description of the problem addressed and changes made.

  • Explains dependencies and backwards incompatible changes .

  • Contains unit and end-to-end tests and a description of how these were run.

  • Includes changes to relevant documentation.

If you are submitting an issue, please double check that there doesn’t already exist and issue for the work you have in mind.

Please make sure your issue:

  • Is created in the correct repository.

  • Has a clear detailed title such that it can’t be confused with other Celo issues.

  • Provides a comprehensive description of the current and expected behavior including, if relevant, links to external references and specific implementation guidelines.

  • Is tagged with the relevant labels.

  • Is assigned if you or someone else is already working on it.

Finding Us and Other Contributors

For code-related questions, comments, and discussions please use the Celo Forum.

Improving Celo

Celo’s Improvement Proposals (CIPs) describe standards for the Celo platform, including the core protocol specifications, SDK, and contract standards. A CIP is a design document that should provide background information, a rationale for the proposal, detailed solution including technical specifications, and, if any, a list of potential risks. The proposer is responsible for soliciting community feedback and for driving consensus.

Participation in the Celo project is subject to the Code of Conduct.

Submitting CIPs

Draft all proposals following the template below and submit to the CIPs repository via a PR (pull request).

CIP template:

  • Summary: Describe your proposal in 280 characters or less.

  • Abstract: Provide a short description of the technical issue being addressed.

  • Motivation: Clearly explain why the proposed change should be made. It should layout the current Celo protocol shortcomings it addresses and why doing so is important.

  • Specification: Define and explain in detail the technical requirements for new features and/or changes proposed.

  • Rationale: Explain the reasoning behind your approach. It should cover alternative approaches considered, related work, and trade-offs made.

  • Implementation: For all proposals going through the governance process, this section should reference the code implementing the proposed change. It’s recommended to get community feedback before writing any code.

  • Risks: Highlight any risks and concerns that may affect consensus, proof-of-stake, governance, protocol economics, the stability protocol, security, and privacy.

Finding Us and Other Contributors

For code-related questions, comments, and discussions please use the Celo Forum