Edit

How to Contribute

Where to Contribute

Logging Issues

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.

Pull Requests

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.

To improve the chances to get a pull request merged, you should select an issue that is labeled with bug or help wanted.

In addition, Onivim 2 is built on Revery - any work or improvements there will directly improve Onivim 2, as well!

Changelog Generation

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>(<scope>): <subject>

where 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 fix(vim/#123).

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.

Some examples:

  • 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>
```

Text inside <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!

Commit Message

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>)

where type and 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.

Log levels

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

Branch Naming

We recommend this scheme for naming branches: <type>/<scope>/<description>

where type and scope are as defined in the Pull Request title section above

description is a short, hyphen-delimited blurb to very briefly describe the change.

Some examples:

  • fix/vim/gd-crash
  • feat/exthost/go-to-definition
  • refactor/editor-component/remove-duplication

Discussion Etiquette

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.

← Building from SourceStyle Guide →