Thanks for your interest in contributing to the Lilypad Network! Welcome, we are happy to have you. 🐸 💚
This guide will help you get started with contributing to the Lilypad network. There are many ways to get contribute in the network, including contacting us about bugs on Discord, opening or triaging issues, or submitting a pull request to address an issue.
No contribution is too small and all contributions are valued.
We expect contributors to abide by our Code of Conduct. Violations of the code of conduct can be reported to the Lilypad team at [email protected].
We accept bug reports in the Lilypad Discord #i-need-help channel (https://discord.com/channels/1212897693450641498/1230231823674642513). For Resource Providers and Job creators, please use the ticketing format here (https://docs.lilypad.tech/lilypad/hardware-providers/troubleshooting#dont-see-your-issue-below) to ensure a smooth exchange of info. If you have a well-defined, reproducible issue we invite you to open an issue as described below.
Pull requests are how changes are made to code and docs in the Lilypad Network.
Pull requests of any size are greatly appreciated. To stay aligned with our team, we request that contributors first open an issue describing proposed, non-trivial change to get feedback and a check whether the work is likely to be merged.
We encourage the community to review any PR on any repo in the Lilypad GitHub organization (https://github.com/Lilypad-Tech)!
Note: any pull request created for an issue that already has someone else assigned will be closed without review.
We require conventional commits (https://www.conventionalcommits.org/en/v1.0.0/) for all changes submitted in a pull request. Conventional commits help us to assess the impact of changes we merge into the code base.
Please use one of the following conventional commit types in your commit messages:
fix - code changes linked to a known issue
feat - new feature
refactor - code refactoring
perf - performance improvements
hotfix - code changes fixing code changes that introduced an issue
revert - backwards remove of previous changes
chore - changes not related to a fix or feature that don't modify source code
docs - documentation only changes
test - add missing tests or correct existing tests
build - changes that affect the build system or external dependencies
Opening a pull request on GitHub will present you with a pull request template. Please do your best to fill out the details, but feel free to skip parts if you're not sure how to answer.
Pull requests should document how to test new features or bug fixes. If we are unable to test the pull request, we may request additional context.
Pull request titles should follow the conventional commit format. We automatically create releases based on the pull request title. Pull requests with feat:, fix:, or refactor: titles will create a release.
Please test tooling that is added to this repo. When possible, provide details in the PR that can help others recreate the test that was run.
In most cases, do not squash commits while your pull request is under review. We use a squash and merge strategy when merging pull requests, and we may edit the individual commit messages squashed into the final commit message. The commit history of your initial pull request will remain intact on the pull request page.
PR review from members of the community are greatly encouraged and will assist the team in the final assessment of the PR. Reviews and feedback must 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 land, explain what those are.
Reviews that are dismissive or disrespectful of the contributor or any other reviewers are strictly counter to the Code of Conduct.
If a Pull Request appears to be abandoned or has not seen any activity, please first check with the contributor to see if they intend to continue the work before asking if they would like you to take over the work. In this scenario, it is courteous to give the original contributor credit for work that has been already completed (use the Author: or Co-authored-by: metadata tags in the commit to attribute with name and email)
Developer tooling, projects using Lilypad, and anything awesome is eligible to earn Lilybit_ rewards once they have been resolved with an associated pull request.
This contribution guide was adapted from the Tokio contributing guide (https://github.com/tokio-rs/tokio/blob/master/CONTRIBUTING.md).