Thanks for your help contributing to the Party Protocol!
We value contributions of any level.
There are multiple opportunities to contribute at any level - whether you're just getting started or the most seasoned expert, we can use your help.
This should be a guide to help walk you through our development process.
Please feel free to ask questions on our Discussions board. Additionally, our Discord channel #developer-chat is available for any questions or concerns you may have that are not covered here.
There are plenty of ways you could contribute, but here are just a few ways you could get started:
- Contributing code
- Reviewing code
- Writing documentation
- Adding tests
- Submitting issues
- Building an integration
- Discussing new features
Remember that anybody can participate in any stage of contribution. We urge you to participate in areas that interest you most and where you believe you could have the most impact.
This cycle of development encapsulates our process:
- Open an issue with a stated motivation and suggested solution OR pick up existing issues. Every contribution should begin with an issue.
- If you are contributing code and are new to the codebase or a beginner to Solidity, we highly recommend you start here on existing issues we've labeled with "good first issue".
- Remember that following up and responding to discussions in your opened issue is just as if not more important than opening up the issue itself.
- Open a PR with nice commits.
- Ideally, each commit focuses on a single thing and is easy to cherry pick. It has concise and clear commit messages. Additional context too wordy to be contained in the message is instead included in either the description of the commit or the description of the pull request it is in.
- Discuss and engage with reviewers in review session loops.
- We treat promptness of response as a tremendous courtesy to your reviewers and fellow contributors.
- Merge when approved by a maintainer.
- Open followup issues and pull requests, if any.
- Repeat.
Although this process should feel simple and natural to follow, doing so consistently end-to-end is very impressive and will not go unnoticed.
When filing a new bug report on the Issues page, you will be presented with a basic form to fill out. Here are the steps to creating a bug report:
-
Go to the "Issues" page of the repo to submit a new issue.
-
Create an issue using the "Bug Report" form template.
-
Fill out the bug report form. Do not worry if you cannot answer in full detail, just fill in what you can. Contributors will ask follow-up questions if something is unclear.
-
Go to the "Issues" page of the repo to submit a new issue.
-
Create an issue using the "Feature request" form template.
-
Fill out the feature request form. Do your best to explain what the new feature is and, if applicable, what problems it solves. Providing additional context (eg. screenshots, resources) is helpful to other contributors and reviewers, but not necessary.
Issues are resolved with pull requests. Pull requests are the way concrete changes are made to the code, documentation, and dependencies of Party Protocol.
Even tiny pull requests, like fixing typos or tweaking confusing code/documentation, are greatly appreciated. Before making a large change, it is usually a good idea to first open an issue describing the change to solicit feedback and guidance. This will increase the likelihood of the PR getting merged.
Before pushing your changes, please make sure all tests pass. If it is a new feature, always include at minimum unit tests ensuring your code does what you expect it to do. Remember that test are not just a way of ensuring your code works but is documentation to us reading your code about what it is supposed to do and proof that you have fully thought things through.
Last but not least, please check first before opening a pull request that it is not a duplicate of an active or closed pull request. To be extra sure, we also encourage you to check in the #developer-chat Discord channel to check if someone is already working on or thinking of working on the same thing as you. And if they are, don't be discouraged. Perhaps you could help each other.
When reviewing a pull request, the primary goal is to improve the protocol and for the person submitting the request to succeed. All contributors who choose to review and provide feedback on pull requests have a responsibility to both the project and the individual contributing. Reviews and feedback should be helpful, insightful, and geared towards improving the contribution as opposed to simply blocking it. If there are reasons why you feel the PR should not be merged, explain what those are. Do not expect to be able to block a PR from advancing simply because you say "no" without explaining. Be open to having your mind changed. Be open to working with the contributor to make the pull request better.
Be conscious that how you communicate requests and reviews in your feedback matters. In some cases, even more than what you communicate. Yes, your feedback may be driving a particular change that makes the Party Protocol better. But the individual implementing your suggestion may just not want anything to do with PartyDAO ever again.
If a pull request appears to be abandoned or stalled, it is polite to first check with the contributor to see if they intend to continue the work before checking if they would mind if you took it over. When doing so, please give the original contributor credit for the work they started, either by preserving their name and e-mail address in the commit log, or including them in the "Author:" or "Co-authored-by:" metadata tag in the commits.
Interested in spending your full time working on the Party Protocol? Learn more about PartyDAO on the Contributors page.
Please let us know on the Discussions board or in Discord if there is anything we should have included that would be helpful and any questions you may still have after reading.