Skip to content

Latest commit

 

History

History
62 lines (46 loc) · 2.59 KB

CONTRIBUTING.md

File metadata and controls

62 lines (46 loc) · 2.59 KB
Raw

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