Contribution Guide
Vueform is open to the community and contributions of all kinds! 💚
There is a range of different ways you might be able to contribute to the Vueform ecosystem.
Learn how to contribute by reading on.
Triage Issues and Help Out in Discussions
Check out the issues board and discussions for Vueform. Helping other users, sharing workarounds, creating reproductions, or even poking into a bug a little bit and sharing your findings makes a huge difference.
Creating an Issue
Thank you for taking the time to create an issue! 💚
Reporting bugs: Check out our guide for some things to do before opening an issue.
Feature requests: Check that there is not an existing issue or discussion covering the scope of the feature you have in mind. If the feature is to another part of the Vueform ecosystem (such as a multiselect), please consider raising a feature request there first. If the feature you have in mind is general or the API is not entirely clear, consider opening a discussion in the Ideas section to discuss with the community first.
We'll do our best to follow issue decision making flowchart (created by Nuxt team) when responding to issues.
Send a Pull Request
We always welcome pull requests! 💚
Before You Start
Before you fix a bug, we recommend that you check whether there's an issue that describes it, as it's possible it's a documentation issue or that there is some context that would be helpful to know.
If you're working on a feature, then we ask that you open a feature request issue first to discuss with the maintainers whether the feature is desired - and the design of those features. This helps save time for both the maintainers and the contributors and means that features can be shipped faster. The issue should be confirmed by a framework team member before building out a feature in a pull request.
Commit Conventions
We use Conventional Commits for commit messages. Please read the guide through if you aren't familiar with it already.
Making the Pull Request
If you don't know how to send a pull request, we recommend reading the guide.
When sending a pull request, make sure your PR's title also follows the Commit Convention.
If your PR fixes or resolves existing issues, please make sure you mention them in the PR description.
It's ok to have multiple commits in a single PR; you don't need to rebase or force push for your changes.
We do not add any commit hooks to allow for quick commits. But before you make a pull request, you should ensure that any test scripts are passing.
In general, please also make sure that there are no unrelated changes in a PR. For example, if your editor has made any changes to whitespace or formatting elsewhere in a file that you edited, please revert these so it is more obvious what your PR changes. And please avoid including multiple unrelated features or fixes in a single PR. If it is possible to separate them, it is better to have multiple PRs to review and merge separately. In general, a PR should do one thing only.
Once You've Made a Pull Request
Once you've made a pull request, we'll do our best to review it promptly.
If we assign it to a maintainer, then that means that person will take special care to review it and implement any changes that may be required.
If we request changes on a PR, please ignore the red text! It doesn't mean we think it's a bad PR - it's just a way of easily telling the status of a list of pull requests at a glance.
If we mark a PR as 'pending', that means we likely have another task to do in reviewing the PR - it's an internal note-to-self, and not necessarily a reflection on whether the PR is a good idea or not. We will do our best to explain via a comment the reason for the pending status.
We'll do our best to follow the PR decision making flowchart (created by Nuxt team) when responding and reviewing to pull requests.
Based on: Nuxt / Contribution
