Skip to content

Latest commit

 

History

History
115 lines (91 loc) · 5.33 KB

CONTRIBUTING.md

File metadata and controls

115 lines (91 loc) · 5.33 KB
Raw

Contributing to renamer.nvim

Getting started

If you want to help but don't know where to start, here are some low-risk/isolated tasks:

Reporting problems

  • Search existing issues (including closed!)
  • Update Neovim and renamer.nvim to the latest version to see if your problem persists.
  • Bisect (git) renamer.nvim's source code to find the cause of a regression, if you can. This is extremely helpful.
  • Check the Neovim logs (:edit $NVIM_LOG_FILE).

Developer guidelines

Pull requests (PRs)

  • To avoid duplicate work, create a draft pull request.
  • Your PR must include test coverage, in the sense that there are tests which cover its changes.
  • Avoid cosmetic changes to unrelated files in the same commit.
  • Use a Gitflow branch instead of the master branch.
  • Use a rebase workflow for all PRs.
    • Before submitting for review, ensure your branch is rebased with the base and passes all of the required actions.
    • After addressing review comments, you should rebase and force-push.

Stages: Draft and Ready for review

Pull requests have two stages: Draft and Ready for review.

  1. Create a Draft PR while you are not requesting feedback as you are still working on the PR.
    • You can skip this if your PR is ready for review.
  2. Change your PR to ready when the PR is ready for review.
    • You can convert back to Draft at any time.

Do not add labels like [RFC] or [WIP] in the title to indicate the state of your PR: this just adds noise. Non-Draft PRs are assumed to be open for comments; if you want feedback from specific people, @-mention them in a comment.

Commit messages

Follow the Conventional Commits guidelines to make reviews easier and to make the VCS/git logs more valuable. The general structure of a commit message is:

<type>([optional scope]): <description>

[optional body]

[optional, Related issue: GH-XX]
Signed-off-by: Name Surname <email-address>
  • Prefix the commit subject with one of these types:
    • build, ci, docs, feat, fix, perf, refactor, revert, test, vim-patch, chore
    • You can ignore this for "fixup" commits or any commits you expect to be squashed.
  • Append optional scope to type such as (defaults), (makefile), (setup), …
  • Description shouldn't start with a capital letter or end in a period.
  • Use the imperative voice: "Fix bug" rather than "Fixed bug" or "Fixes bug."
  • Try to keep the first line under 72 characters.
  • A blank line must follow the subject.
  • Breaking API changes must be indicated by
    1. ! after the type/scope, and
    2. a BREAKING CHANGE footer describing the change. Example: 
      refactor(provider)!: drop support for Python 2

BREAKING CHANGE: refactor to use Python 3 features since Python 2 is no
longer supported.
  • If your pull request is related to an issue, add the Related issue: GH-XX footer, where XX is the number of that issue.
  • Sign off your commits. This can be done by either writing the footer as above, or by using the -s flag for the git commit command.

Automated builds (CI)

Each pull request must pass the automated builds on GitHub Actions.

  • If any tests fail, the build will fail. See lua/tests/README.md#running-tests to run tests locally. Passing locally doesn't guarantee passing the CI build, because of the different compilers and platforms tested against.
  • The commit lint build checks modified lines and their immediate neighbors, to encourage incrementally updating the legacy style to meet the project's style.
  • There is also a style check job, that needs to pass in order for a pull request to be accepted and merged.