We welcome contributions to this project and to Hyperledger Fabric projects in general. There is always plenty to do!
If you have any questions about the project or how to contribute, you can use:
- The GitHub repository Discussions.
- The
#fabric-client-apischannel on Hyperledger Discord (invite link). - The Fabric mailing list.
Here are a few guidelines to help you contribute successfully...
Issues are tracked in the GitHub repository Issues. Please do not use issues to ask questions.
If you find a bug which we don't already know about, you can help us by creating a new issue describing the problem. Please include as much detail as possible to help us track down the cause.
If you have a proposal for new functionality, either for the community to consider or that you would like to contribute yourself, please first raise an issue describing this functionality. Make the title something reasonably short but descriptive, and include a user story description of the enhancement, followed by any supporting information. For example, issue #198. The "So that" statement provides useful context about the motivation for the enhancement, and helps in determining whether any changes successfully satisfy the requirement.
Make sure you have the support of the maintainers and community before investing a lot of effort in project enhancements.
If you want to begin contributing code, looking through our open issues is a good way to start. Try looking for issues with help wanted or good first issue tags first, or ask us on Discord if you're unsure which issue to choose.
Code changes should include code, tests and documentation. This includes scenario tests. For larger enhancements, it may be appropriate to deliver language implementations and scenario tests in separate pull requests.
Commits must include a Signed-off-by trailer, as produced by git commit --signoff.
When creating a pull request, include a reference to the issue that it contributes to or fixes, as described in the GitHub documentation. Pull requests should generally contain a single commit with a commit message that describes the change, and any supporting explanation of the implementation or reasons for the change. If the pull request review requires changes to be made, these can be delivered as additional commits.
It is helpful to create work-in-progress pull requests as draft, and only mark them as ready for review when you feel the change is complete.
Go code uses testify for assertions, and gomock for mock implementations. The standard errors package is used; not any third-party error packages.
Consider recommendations from these resources:
Node code is written only in TypeScript, and uses Jest as the testing framework.
ESLint is used to apply linting checks. Consider using an editor integration to avoid linting failures.
Prettier is used to apply consistent code formatting. Consider using an editor integration to help match Prettier's formatting.
Java code uses JUnit as the test runner, AssertJ for assertions, and Mockito for mock implementations. Checkstyle is used to apply both linting checks and consistent code formatting.
Consider recommendations from these resources:
- Effective Java by Joshua Bloch.
Scenario tests use Cucumber as the testing framework. The same set of test features are run against all language implementations of the API to ensure consistent functionality and behavior.
Please review the project code of conduct before contributing.
Should you have any questions or concerns, please reach out to one of the project's maintainers.
See the Hyperledger Fabric contributors guide for more details, including other Hyperledger Fabric projects you may wish to contribute to.
