Kwenta is a dApp enabling derivatives trading with infinite liquidity - powered by the Synthetix protocol. We're community driven and welcome all contributions. We aim to provide a constructive, respectful and fun environment for collaboration.
If you wish to help out, please first join the Kwenta devDAO on our Discord #community-dev
channel. For more information, see devDAO below.
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.
There are many reasons you might contribute to Kwenta. For example, you may wish to:
- contribute to the Ethereum ecosystem.
- establish yourself as an Ethereum developer.
- work on cutting-edge technology.
- 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 fellow Ethereum developers.
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 Discord to chat and distribute tickets to community members.
The devDAO has been created specifically to foster open community development and reward community developers. It is an essential piece in our collaborative effort to fully decentralize Kwenta.
Be welcome to join the Kwenta devDAO on our Discord #community-dev
channel.
This is where discussions take place, new tickets will be announced by the community PM and assigned to the respective community members and roles on a first come, first served base.
There are different roles depending on the severity of a ticket. As a new community member, you should watch out for bounty hunter tickets are work your way up from there.
We recommend the following work-flow for contributors:
- Find an open ticket to work on in our Discord, either because it's interesting or suitable to your skill set. Use the
#community-dev channel
to communicate your intentions and ask questions. - Work in a feature branch of your personal fork (github.com/YOUR_NAME/kwenta) of the main repository (github.com/kwenta/kwenta).
- Once you feel you have addressed the issue, create a pull-request to merge your changes into the main repository. In case of any doubts, don't hesitate to contact the community PM or ask away in the channel.
- Wait for a CC or auditor to review your changes to ensure the issue is addressed satisfactorily. Optionally, mention your PR on Discord.
- If the issue is addressed the repository maintainers will merge your pull-request and you'll be an official contributor!
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 the Kwenta repository using
$ git remote add upstream https://github.com/kwenta/kwenta.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 branchfix/serialization_bug
. - Make sure you sign your commits. See the relevant doc.
- 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 Kwenta repository.
From there, the CCs or auditors will review the PR and either accept it or provide some constructive feedback.
If you have any questions along the way, the community PM will be there to guide and assist you!
There's a great guide by Rob Allen that provides much more detail on each of these steps, if you're having trouble. As always, jump on Discord if you get stuck.
There's lots to be done and there's all sorts of tasks. You can do anything from correcting typos to writing core dApp code. If you reach out, we'll include you.
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.
No problems, there's plenty of tasks that don't require extensive Ethereum knowledge. You can learn about Ethereum as you go.
Don't be. We're all about personal development and constructive feedback. If you make a mistake and learn from it, everyone wins.
Please, make an issue and explain why. We're open to constructive criticism and will happily change our ways.