CONTRIBUTING.md

Contributing to NeutronVim

Welcome to the NeutronVim contributing guide. We are excited about the prospect of you joining our community!

There are many opportunities to contributing to the project at any level. Every contribution is highly valued and no contribution is too small.

You do not need to write code to contribute to this project. Documentation, demos, and feature design advancements are a key part of this project's growth.

One of the best ways to begin contributing in a meaningful way is by helping find bugs and filing issues for them.

Getting Started

Wait I'm still doing this...

Setting up development tools

For editing Lua files

1. Formatter: stylua.
2. Linter: luacheck.

(Optional)

Install pre-commit which will run all linters and formatters for you as a pre-commit-hook.

Code Conventions

All lua code is formatted with Stylua.

# configurations are already stored in .stylua.toml
stylua -c .

Pull Requests (PRs)

• To avoid duplicate work, create a draft pull request.
• Your PR must pass all the automated-ci-tests.
• Use a git-feature-branch instead of the master/rolling branch.
• Use a rebase-workflow.
• Title the PR the same way as commit headers

Commit Messages

• Commit header is limited to 72 characters.
• Commit body and footer is limited to 100 characters per line.

Commit header format:

<type>(<scope>?): <summary>
  │       │           │
  │       │           └─> Present tense.     'add something...'(O) vs 'added something...'(X)
  │       │               Imperative mood.   'move cursor to...'(O) vs 'moves cursor to...'(X)
  │       │               Not capitalized.
  │       │               No period at the end.
  │       │
  │       └─> Commit Scope is optional, but strongly recommended.
  │           Use lower case.
  │           'plugin', 'file', or 'directory' name is suggested, but not limited.
  │
  └─> Commit Type: build|ci|docs|feat|fix|perf|refactor|test

Commit Type Guideline

• build: changes that affect the build system or external dependencies (example scopes: npm, pip, rg)
• ci: changes to CI configuration files and scripts (example scopes: format, lint, issue_templates)
• docs: changes to the documentation only
• feat: new feature for the user
• fix: bug fix
• perf: performance improvement
• refactor: code change that neither fixes a bug nor adds a feature
• test: adding missing tests or correcting existing tests
• chore: all the rest, including version bump for plugins

Real world examples:

feat(quickfix): add 'q' binding to quit quickfix window when focused

fix(installer): add missing "HOME" variable

Branch Naming

Name your branches meaningfully.

ex) (feature|bugfix|hotfix)/what-my-pr-does

Communication

Members of the community have multiple ways to collaborate on the project. We encourage you to join the community: I'll do this soon