Where to Contribute
You can help us by logging any issues you find, as well as 'thumbs-upping' any issues relevant to you. As a small team, prioritization is critical, so knowing which issues are impactful for many users can help us with that prioritization.
Check out the full issues list for ideas of where to start. Note that just because an issue exists does not mean we will accept a PR for it.
There are several reason we may not accept a pull request, like:
- Performance - Onivim 2 is lightweight and fast. Changes should not introduce performance regressions.
- User Experience - The UX should be smooth, polished, consistent, and not cluttered.
- Architectural - Maintainers must approve any architectural impact or change.
- Maintenance Burden - If a PR would incur a maintenance burden on the maintainers, it will be rejected.
In addition, Onivim 2 is built on Revery - any work or improvements there will directly improve Onivim 2, as well!
Submitting a Pull Request
Before we can accept a pull request from you, you'll need to sign a a Contributor License Agreement (CLA). It is an automated process and you'll be guided through it the first time you open a PR.
To enable us to quickly review and accept your pull requests, follow these guidelines:
- Always create one pull request per issue and link the issue in the pull request. Never merge multiple requests into one.
- Keep code changes as small as possible. Break large PRs or features into smaller, incremental PRs where possible.
- Make our maintainer's life easy and keep changes as simple as possible.
- Avoid pure formatting changes for code that has not been otherwise modified.
- Include tests whenever possible.
- Include benchmarks whenever possible.
To avoid duplicate work, if you decide to start working on an issue, please leave a comment on the issue.
The following conventions are used to determine the priority level of log messages, based on the conventions suggested by @dbuenzli/logs:
- Error if it WILL cause unexpected behaviour
- Warn if it MIGHT cause unexpected behaviour, but also might not, i.e. it's suspicious, but not a definite problem.
- Info if it is both understandable AND actionable by the end-user
- Debug otherwise
- Trace if the output is overwhelming or just excessively detailed. Namespace filtering is expected at this level
We recommend this scheme for naming branches:
type is one of:
bugfix- a change that fixes a bug
feature- a change that adds new functionality
doc- a change that modifies the documentation
refactoring- a code change that does not fix a bug or change a feature
dependency- a change to bring in a new dependency
area corresponds to our Area Labels
description is just a short, hyphen-delimited blurb to very briefly describe the change.
We strictly enforce a Code of Conduct and have a zero-tolerance policy towards infractions. Be considerate to others, and try to be courteous and professional at all times.