63 lines
2.6 KiB
Markdown
63 lines
2.6 KiB
Markdown
|
# Contributing to Neo-tree
|
||
|
|
|
||
|
|
Contributions are welcome! To keep everything clean and tidy, please follow the
|
||
|
|
guidelines below.
|
||
|
|
|
||
|
|
## Code Style
|
||
|
|
|
||
|
|
This is open for debate, but here is the current style choices being observed:
|
||
|
|
|
||
|
|
- snake_case for all variables and functions
|
||
|
|
- unless it is a class, then use PascalCase
|
||
|
|
- other OOP things, like method names should use camelCase
|
||
|
|
- BUT we don't currently have any OOP parts and I don't think we want any
|
||
|
|
|
||
|
|
I prefer `local name = function()` over `local function name()`, just to be
|
||
|
|
consistent with the `M.name = function()` exports.
|
||
|
|
|
||
|
|
### StyLua
|
||
|
|
|
||
|
|
We use (StyLua)[https://github.com/JohnnyMorganz/StyLua] to enforce consistency
|
||
|
|
in code. You should install it on your local machine. PRs will be checked with
|
||
|
|
this tool.
|
||
|
|
|
||
|
|
## Commit Messages
|
||
|
|
|
||
|
|
We use **semantic**, aka **conventional** commit messages. The official guide
|
||
|
|
can be found here: https://www.conventionalcommits.org/en/v1.0.0/
|
||
|
|
|
||
|
|
You can also just take a look at the commit history to get the idea. The
|
||
|
|
optional scope for this project would usually be the source, i.e.
|
||
|
|
`feat(filesystem): add awesome feature that does xyz`.
|
||
|
|
|
||
|
|
## Branching
|
||
|
|
|
||
|
|
The default branch is set to `main` and all Pull Requests should target this
|
||
|
|
branch. After a short testing period, it will be merged to the current release
|
||
|
|
branch.
|
||
|
|
|
||
|
|
This project requires a **linear history**. I don't trust merge commits.
|
||
|
|
This means you will have to rebase your branch on main before the pull request
|
||
|
|
can be merged. This can get a bit annoying in a busy repository, but I think it
|
||
|
|
is worth the effort.
|
||
|
|
|
||
|
|
## Documentation
|
||
|
|
|
||
|
|
All new features should be documented in the commit they were added in. The
|
||
|
|
current strategy is to maintain:
|
||
|
|
|
||
|
|
- Config Options: added to [defaults](lua/neo-tree/defaults.lua) and described
|
||
|
|
in comments. This is the bare minimum documentation for an option.
|
||
|
|
- The README contains "back of the box" high level overview of features. It is
|
||
|
|
meant for people trying to decide if they want to install this plugin or not.
|
||
|
|
It should include references to the help file for more information:
|
||
|
|
`:h neo-tree-setup`
|
||
|
|
- Whether something should be mentioned in the README or just in the help file
|
||
|
|
is a completely subjective judement call that is made on a case by case basis
|
||
|
|
based on how many people are likely to be interested in that information.
|
||
|
|
- The vim help file [doc/neo-tree.txt](doc/neo-tree.txt) is the definitive
|
||
|
|
reference and should contain all information needed to configure and use the
|
||
|
|
plugin.
|
||
|
|
- OUR DOCUMENTATION IS NOT GOOD ENOUGH! Consider the current level of documentation
|
||
|
|
the bare minumum and not the ideal. More documentation would be greatly appreciated.
|