Maintainer's guide

See the Contributing.md for Vimium's design goals.

Process for handling tickets and pull requests

PRs should be code reviewed. For small PRs, it's often faster to just merge the PR and then fix up the code, rather than leaving comments.
Not every new feature PR should be merged in. A new feature has a cost -- it may make Vimium's feature set more bloated, or it may significantly increase the complexity of the code. See the contributors guide for some merge/no-merge heuristics. It's okay for some PRs to live on forks.
If a bug isn't well-described or you think it's relatively unimportant, just close it. Having lots of github issues open makes it much harder to find the signal in the noise.
If a question or unfixable bug gets filed more than once, add a FAQ entry for it so it's less likely to appear again.

This process is currently only done by Phil, Ilya or Steve.

Ensure debug logging is not enabled in lib/utils.js
Increment the version number in manifest.json. If the major and/or minor version number changes, then users will be notified about the new release; otherwise they will not. 1.45 and 1.45.0 are taken to be identical, so for patch releases start with 1.45.1.
Update the Changelog in README.md

You can see a summary of commits since the last version: git log --oneline v1.45..
Push your commits
Create a git tag for this newly released version
```
 git tag -a v1.45 -m "v1.45 release"
```
Push the new tag to the appropriate remote
```
 git push origin v1.45
```
Run ./make.js package
Take the distributable found in dist and upload it here
Upload to the Firefox addons store here.
Celebrate