Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
47 lines (30 loc) · 2.46 KB

CONTRIBUTING.md

File metadata and controls

47 lines (30 loc) · 2.46 KB

How to Contribute

Thanks for taking the time to contribute to Primitive!

Join our discord to collaborate.

Resources

  • FAQ answers commonly asked questions
  • RMM Primer is a beginner-friendly guide to RMMs and Primitive
  • Whitepaper dives into the details
  • Our latest research on permissionless derivatives can be found here

Testing

We are strong believers of test-driven development here. If you propose new code, please write the corrosponding tests.

Submitting Changes

Open a pull request with a clear list of what you've done (read more about pull requests). When you send a pull request, we will love you forever if you include examples. We can always use more test coverage. Please follow our coding conventions below and make sure all of your commits are atomic (one feature per commit).

Always write a clear log message for your commits. One-line messages are fine for small changes, but bigger changes should look like this:

$ git commit -m "A brief summary of the commit
>
> A paragraph describing what changed and its impact."

Coding Conventions

Start reading our code and you'll get the hang of it. We optimize for readability:

  • We ALWAYS put spaces after list items and method parameters ([1, 2, 3], not [1,2,3]), around operators (x += 1, not x+=1) and around hash arrows.
  • This is open source software. Consider the people who will read your code, and make it look nice for them. It's sort of like driving a car: Perhaps you love doing donuts when you're alone, but with passengers the goal is to make the ride as smooth as possible.

Clean code

We believe in agile development methodologies and clean code. If you would like to learn more about what we consider to be clean code you are welcome to check out the book here. Some general guidlines we encurage are :

  • Functions should be small and do one thing.
  • Functions should have a single level of abstraction.
  • Functions should have descriptive names.
  • One pull request per one issue.
  • Issues should be small and do one thing.
  • Issues should be well documented before worked on.

Thanks, The Primitive Team