ALE Development Philosophy

This page exists to explain the general development philosophy of ALE, especially on GitHub. The page should serve to eliminate confusion over how ALE issues, pull requests, changes to the code, and so on should be handled.

General Tips

1. Have fun!

Issues

1. Issues should stay open until they are either resolved, superseded, or deemed invalid. There's no harm in having a large issue count for users.
2. Bug reports should be expected to written in clear English that everyone can reasonably understand, with enough information for identifying and fixing the bugs.
3. Requests for new features don't have to have any fixed format. Some descriptive prose is just fine.

Pull Requests

1. Typically any pull requests with code should include accompanying tests.
   1. Some Vim code cannot be tested, so some reasonable exceptions can be made.
2. New linters or fixers should include updates to documentation to describe new supported tools both on GitHub and in the Vim documentation.
   1. New options for linters or fixers should be included in the documentation, and described in a clear, and preferably brief English.
   2. Linters and languages in headings and tables should be sorted roughly alphabetically.

Important Principles for ALE Code

1. Prefer defaults that the majority of users will prefer.
   1. If users prefer not being told about correctly identified mistakes in their code, go against the majority and report mistakes by default.
2. Never enable anything by default that can modify files on someone's computer, within reason.
3. Never introduce any breaking changes ever, unless users have been previously warned about them.
   1. Appreciate that a "breaking change" is hard to define.
4. If a function isn't documented, it isn't public.
   1. If a function isn't public, it can be changed at any time.
   2. Very few functions should be public.
5. Do not define any functions in the global scope, except functions that are autoload functions.
6. Do not introduce any keybinds other than <Plug> mappings and keybinds for windows controlled by ALE.
7. Typically if code isn't needed, it shouldn't be loaded. Manage autoload files carefully.
8. Never introduce a new feature without a good reason, but add important features many people do need.