Thanks for taking the time to contribute! 👍
The following is a set of guidelines for contributing to the CosmWasm bindings for the Provenance Blockchain, which are hosted in the Provenance Organization on GitHub. These are guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.
What is all this malarke...I just have a question!!!
What should I know before I get started?
This project and everyone participating in it is governed by the Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to [email protected].
NOTE: Please don't file an issue to ask a question. You'll get faster results by using the resources below.
Currently, we have a Slack team you can join:
-
Join the Provenance Slack Team
- Even though Slack is a chat service, sometimes it takes several hours for community members to respond — please be patient!
- Start with the
#general
channel for questions/discussions, or to find a more specific channel.
The design of provwasm
was based on the
wasmd integration guide.
In the future, when we make a significant decision in how we maintain the project and what we can or cannot support, we will document it. For now, if you have a question around how we do things, please ask a question in Slack.
This package provides bindings that enable CosmWasm smart contracts to interact — encode handler messages or query keepers — with custom modules in the Provenance Blockchain.
This package
provides mocks that enable unit testing of CosmWasm smart contracts that interact with custom
modules in the Provenance Blockchain. The functionality provided here should NOT be used directly
in the instantiate
, execute
, or query
functions of smart contracts (ie only use them in tests).
Bugs are tracked as GitHub issues.
Before creating bug reports, perform a cursory search to see if the problem has already been reported. If it has and the issue is still open, add a comment to the existing issue instead of opening a new one.
After you've determined it is a new bug, create an issue and provide the following information:
- Use a clear and descriptive title for the issue to identify the problem.
- Describe the exact steps which reproduce the problem in as many details as possible. When listing steps, don't just say what you did, but explain how you did it.
- Describe the behavior you observed after following the steps and point out what exactly is the problem with that behavior. Explain which behavior you expected to see instead and why.
- Provide specific examples to demonstrate the steps. Include links to files or GitHub projects, or copy/pasteable snippets, which you use in those examples. When providing snippets in the issue, use markdown.
Like bugs, enhancements are tracked as GitHub issues.
Before suggesting an enhancement, perform a cursory search to see if the feature has already been requested. If it has and the issue is still open, add a comment to the existing issue instead of opening a new one.
After you've determined it is a new feature, create an issue and provide the following information:
- Use a clear and descriptive title for the issue to identify the suggestion.
- Provide a step-by-step description of the suggested enhancement in as many details as possible.
- Provide specific examples to demonstrate the steps. Include copy/pasteable markdown snippets which you use in those examples.
- Describe the current behavior and explain which behavior you expected to see instead and why.
- If possible, include screenshots which help you demonstrate your point.
- Explain why this enhancement would be useful to most smart contract users.
The process described here has several goals:
- Maintain or improve code quality.
- Fix problems that are important to smart contract developers.
- Engage the community in working toward the best possible API.
- Enable a sustainable system for
provwasm
maintainers to review contributions.
Please follow these steps to have your contribution considered:
- Format and lint all code.
- Follow the Rust Styleguide.
- Include unit tests.
- Update integration test contracts (add a contract for new module integrations).
- If necessary, update the tutorial.
- Verify correct operation against the Provenance Blockchain.
- Add a link to close the referenced issue (PRs without an issue will be rejected).
Optional:
Before you submit a PR, we suggest you run the GitHub actions locally against your branch by using our act image.
- Limit the first line to 72 characters or less.
- Use the present tense ("Add feature" not "Added feature").
- Reference issues liberally after the first line.
Whenever possible, use the standards set by the Rust API Guidelines.
The contributing document from the Atom editor project was used as a template for this document.