Merge branch 'dev'

CONTRIBUTING.md

@@ -1,3 +1,5 @@
+# Contributing to Vimwiki
+
 # Filing a bug
 
 Before filing a bug or starting to write a patch, check the latest development version from
@@ -15,7 +17,14 @@ Make sure to update `doc/vimwiki.txt` with the following information:
 1. Update the changelog to include information on the new feature the PR introduces or the bug it
    is fixing.
 2. Add a help section to describe any new features or options.
-2. If you are a first time contributor add your name to the list of contributors.
+3. If you are a first time contributor add your name to the list of contributors.
+
+**Testing:** Vimwiki uses [vader](https://github.com/junegunn/vader.vim) for unit tests and
+[vint](https://github.com/Kuniwak/vint) for linting. Any new PRs must add new tests and pass all
+linter checks. See the [test README](test/README.md) for more info.
+
+- In addition to the included tests, there are more example wikis that can be used for testing
+  [here](https://github.com/vimwiki/testwikis).
 
 # More info and advice for (aspiring) core developers
 
@@ -30,17 +39,17 @@ Make sure to update `doc/vimwiki.txt` with the following information:
 
 ## Git branching model
 
-- there are two branches with eternal lifetime:
-    - `dev`: This is where the main development happens. Tasks which are done in one or only a few
-      commits go here directly. Always try to keep this branch in a working state, that is, if the
-      task you work on requires multiple commits, make sure intermediate commits don't make Vimwiki
-      unusable (or at least push these commits at one go).
-    - `master`: This branch is for released states only. Whenever a reasonable set of changes has
-      piled up in the `dev` branch, a [release is done](#Preparing a release). After a release,
-      `dev` has been merged into `master` and `master` got exactly one additional commit in which
-      the version number in `plugin/vimwiki.vim` is updated. Apart from these commits and the merge
-      commit from `dev`, nothing happens on `master`. Never should `master` merge into `dev`. When
-      the users ask, we should recommend this branch for them to use.
+- There are two branches with eternal lifetime:
+    1. `dev`: This is where the main development happens. Tasks which are done in one or only a few
+       commits go here directly. Always try to keep this branch in a working state, that is, if the
+       task you work on requires multiple commits, make sure intermediate commits don't make
+       Vimwiki unusable (or at least push these commits at one go).
+    2. `master`: This branch is for released states only. Whenever a reasonable set of changes has
+       piled up in the `dev` branch, a [release is done](#preparing-a-release). After a release,
+       `dev` has been merged into `master` and `master` got exactly one additional commit in which
+       the version number in `plugin/vimwiki.vim` is updated. Apart from these commits and the
+       merge commit from `dev`, nothing happens on `master`. Never should `master` merge into
+       `dev`. When the users ask, we should recommend this branch for them to use.
 - Larger changes which require multiple commits are done in feature branches. They are based on
   `dev` and merge into `dev` when the work is done.
 
@@ -55,9 +64,9 @@ Make sure to update `doc/vimwiki.txt` with the following information:
 7. Update the version number at the top of plugin/vimwiki.vim.
 8. Set a tag with the version number in Git: `git tag vX.Y`
 9. `git push --tags`
-10. In GitHub, go to _Releases_ -> _Draft a new release_ -> choose  the tag, convert the changelog from the
-    doc to markdown and post it there. Make plans to build an automatic converter and immediately
-    forget this plan.
+10. In GitHub, go to _Releases_ -> _Draft a new release_ -> choose  the tag, convert the changelog
+    from the doc to markdown and post it there. Make plans to build an automatic converter and
+    immediately forget this plan.
 11. Tell the world.
 
-%% vim:tw=99
+<!-- vim:tw=99 -->