Update docs

- Add description for `url_format` setup option.
- Format code snippets in docs.
  - Indent at 2 spaces
  - Use double quotes
  - Elide parentheses for single table arguments
- Rewrite the section on bootstrapping.
- Update CONTRIBUTING to mention the issue template.
- Update the descriptions of package options.

CONTRIBUTING.md

@@ -4,27 +4,28 @@ Paq is small because my own needs as a Nvim user are pretty simple.
 Before asking for a feature request, consider if using another package manager
 which implements that feature would be better for you.
 
+## Ask questions
 
-## Issues
+For questions, there are no restrictions. Ask away.
+Open a bare issue and write the question in the title. e.g. `Can Paq do foo?`
 
-For bugs, write the title as an statement:
+
+## File Bugs
+
+Paq has an issue template for [reporting bugs](https://github.com/savq/paq-nvim/issues/new/choose).
+Follow the instructions in the template and
+make sure to write the title as an statement:
 `Paq isn't doing foo` or `Paq does bar instead of foo`.
-In the body, be sure to include the steps necessary to reproduce the issue,
-and a minimal working example.
 
-For feature requests, write the title as an imperative:
-`Do foo instead of bar` or `Add foo`.
-This makes it easier to match them to their (possible) corresponding PR.
-In the body, try to nail down the scope of the feature, what it should do
-and what it shouldn't do.
-Make sure the feature doesn't already exist or is explicitly declared as something
-out of scope in the documentation.
 
-For questions, there are no restrictions. Ask away. Just write the title a
-question: `Can Paq do foo?`
+## Develop features
 
+Before sending a PR, open an bare issue to discuss the feature.
+Write the issue title as an imperative: `Do foo instead of bar` or `Add foo`,
+this makes it easier to match it to a (possible) corresponding PR.
 
-## Development
+In the body, try to nail down the scope of the feature, what it should do and what it shouldn't do.
+Make sure the feature doesn't already exist or is explicitly declared as something out of scope in the documentation.
 
 Once an issue has been discussed, a PR with the necessary changes can be opened.
 
@@ -33,4 +34,5 @@ Once an issue has been discussed, a PR with the necessary changes can be opened.
 - Follow general git etiquette. Write meaningful commit messages.
 - Changes should only affect code related to the issue, avoid cosmetic changes.
 - Use [StyLua](https://github.com/JohnnyMorganz/StyLua) for code formatting.
-- Use [luacheck](https://github.com/mpeterv/luacheck) for linting.
+  This repository includes a [`stylua.toml`](./.stylua.toml) file.
+

README.md

@@ -42,23 +42,21 @@ In your init.lua, `require` the `"paq"` module with a list of packages, like:
 
 ```lua
 require "paq" {
-    "savq/paq-nvim";                  -- Let Paq manage itself
+    "savq/paq-nvim", -- Let Paq manage itself
 
-    "neovim/nvim-lspconfig";          -- Mind the semi-colons
+    "neovim/nvim-lspconfig",
 
-    "hrsh7th/nvim-cmp";
+    { "lervag/vimtex", opt = true }, -- Use braces when passing options
 
-    {"lervag/vimtex", opt=true};      -- Use braces when passing options
-
-    {"nvim-treesitter/nvim-treesitter", run=function() vim.cmd "TSUpdate" end};
+    { 'nvim-treesitter/nvim-treesitter', run = function() vim.cmd 'TSUpdate' end },
 }
 ```
 
 Then, source your configuration (using `:source %` or `:luafile %`) and run `:PaqInstall`.
 
 
 **NOTICE:**
-Calling the `paq` function per package is deprecated. Users should now pass a list to the `'paq'` module instead.
+Calling the `paq` function per package is deprecated. Users should now pass a list to the `"paq"` module instead.
 
 
 ## Commands