Contributions to Aquavium.nvim are welcome. This page covers everything you need to know before opening an issue, submitting a pull request, or pushing commits.
Development policies
All contributors are asked to follow these three principles:
- Strive for normal operation on the latest Neovim. Make your best effort to ensure changes work correctly on the current stable release.
- Exercise maximum caution to prevent catastrophic effects. This includes data loss and similarly destructive outcomes. If a bug report describes catastrophic behavior, fix it as quickly as possible.
- Always show respect for inspiration sources and integration targets. Strictly adhere to their terms of use, licenses, and guidelines to prevent any damage to their image. If the creators of such works point out any issues, immediately strive to improve and resolve them.
Issues and discussions
Issues accept feature proposals, bug reports, and feature ideas. If you can implement or resolve the feature or bug yourself, please indicate it in your issue.
Discussions are primarily for questions. Feature ideas are also welcome there.
Pull requests
For minor pull requests — such as typo fixes or small improvements — you can open a PR directly without creating an issue first.
- Medium to large-scale feature additions (for example, features that require new config options, or changes that add new menus)
- Major UI refreshes
Commit message format
Commit messages in this repository follow this format (effective from 2026/01/10):
<type> (<scope>): <subject> (#<Issue Number>)
<more info>
Type
Use one of the following types:
| Type | When to use |
|---|
feat | Addition of new features |
fix | Bug fixes |
docs | Documentation changes (e.g., README.md) |
style | Code style changes such as indentation or whitespace (no behavior change) |
refactor | Internal code restructuring with no change to external behavior |
chore | Auxiliary tools, development environment changes (e.g., .gitignore) |
ci | Changes to workflows such as GitHub Actions |
typo | Typo corrections |
revert | Commits using git revert |
Scope (optional)
An element indicating the specific file or feature area where changes were made. You can omit it.
Examples: README.md, colors, highlights
Issue number (recommended)
Include the related issue number if one exists. Omit it if there is none.
Subject
The main description of your change.
More info (optional)
A longer explanation of the change. Omit if not needed.
Examples
feat: Add q keymap as exit (#36)
fix: wrong variable in conditional check
Branch naming
Name your branches using the following format:
<type>/<subject>-#<Issue Number>
- Use the same
<type> values as commit messages.
- Use
- in place of spaces in the subject.
- Include the issue number if one exists.
Examples
feat/Add-q-keymap-as-exit-#36
fix/cant-skip-config-when-edit-target
Git workflow
All feature, fix, and docs branches merge directly into main:
feat/xxxx ──┐
fix/xxxx ──┼──► main
docs/xxxx ──┘
main. 