Maintainer's guide

Maintainer's guide

Vimium design goals

The core UX goal is to make it easy to navigate the web using just the keyboard. This is an incredibly powerful workflow improvement for people when they first start using Vimium, and it makes them feel awesome. Somewhat surprisingly, Vimium is applicable to a huge, broad population of people, not just existing Vim users.

An important secondary UX goal is to make Vimium approachable and Chrome-like. Many of Vimium's users have never used Vim before (every 5th review in the app store says as much), and most people have been using browsers for a long time and have strong workflow habits. So it's important that Vimium feels like a powerful-but-natural extension to Chrome, and not something foreign.

In this way, Vimium shines. It's approachable today because:

1. It's simple to understand (even if you're not very familiar with Vim). The Vimium video shows you all you need to know to start using Vimium and feel awesome.
2. The core feature set works in almost all cases in Chrome and on all sites, so users can just trust Vimium to work.
3. Requires no configuration before it's useful.
4. Doesn't drastically change the way Chrome looks or behaves. You can transition into using Vimium piecemeal; you don't need to jump all-in from the start.
5. The core feature and documentation aren't overwhelming. This is easy to degrade as we evolve Vimium, so it requires active effort to maintain this feel.
6. The code is relatively simple and easy to jump into, so we get lots of pull requests.

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.