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!
We use a script to generate the change log based on metadata picked up from the commit message, and pull request title and body. For the changelog to be generated successfully it's therefore important that these follow the exact format explained below.
Pull Request Title
Pull request titles should have the following format:
type can be one of
- feat: A new feature
- fix: A bug fix
- refactor: A code change that neither fixes a bug nor adds a feature
- perf: A code change that improves performance
- test: Adding missing or correcting existing tests
- docs: Documentation only changes
- chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
scope is optional, but "encouraged". It is typically one of the "area" issue labels or the name of a feature project. Supplementary information, like associated issues, can be added to the scope following a
/. For example, a PR that fixes issue
#123 regarding vim could have the type and scope
subject should contain a succinct description of the change:
- use the imperative, present tense: "change" not "changed" nor "changes"
- don't capitalize first letter
- no dot (.) at the end
Do NOT add temporary tags, like
[WIP], to the title. Instead use GitHub's draft function and/or labels.
feat(scm): add support for multiple providers
fix(vim/#123): get_op_type error when using gcc
refactor(editor): remove duplication
chore(ci): fix build failure on CentOS VM
Attribution: Adapted from Angular's commit guidelines
Pull Request Body
More details can be provided in a
changelog code block in the body of the pull request if a longer description is needed or if there are beaking changes:
```changelog Detailed description of the change Can span multiple lines <breaking>This change breaks my brain</breaking> ```
<breaking> tags will be listed in the changelog as separate items so that they can be emphasized. ALL breaking changes MUST be listed in this way. If in doubt, list it anyway. We'll remove it later in the process if it's considered insignificant.
The rest of the text will become the overall description of the change and can include anything considered text content in XML. Use predefined entities in place of characters with special meaning in XML. And please do still try to be brief!
Note: this section is relevant only to maintainers who merge PRs. Contributors can safely ignore this.
Commits messages pushed to
master should have the following format:
<type>(<scope>): <subject> (#<PR number>)
scope is as described above. This is usually what Github generates automatically when squashing a PR, assuming the PR title was formatted correctly.
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:
scope are as defined in the Pull Request title section above
description is 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.