I don't think the contributor's guide at present is very easy to read, and it should contain a bit more on certain matters. (At the moment it is mostly focused on technical how-tos.) The main additional things to get across are:

• what belongs in scikit-learn, and what doesn't (and if something doesn't, where can it go)? (This may belong on a separate page)
• more ways to contribute
• what makes a good code contribution
• the pull request process

This needs to be a concise-as-possible one-stop shop for the hundreds of requests to contribute.

I would like to see the guidelines have a shape like the following:

Scikit-learn's scope

This may belong in the contributor's guide, or may belong elsewhere in the documentation (a new "About the project", or in the FAQ). In any case it should be referenced from the contributor's guide.

• well-established algorithms (and occasionally, recent variants of well-established algorithms), to be mostly usable out of the box; in distinction to pylearn2 et al.
• specifically for ML problems whose targets have minimal structure: i.e. binary, regression, multiclass, multilabel and multitask problems from more-or-less flat feature vectors. These all involve (sometimes spare) arrays as input and targets.

Ways to contribute

This is already mostly there, but needs some reordering. It needs to begin with an emphasis on how overtasked the core developer group is, and how important it is to help complete existing highlights a contributor's competence, leading way for larger contributions.

• reporting bugs
• easy issues and how to adopt an issue
• finding and adopting a stagnant pull request (PR): perhaps look for old WIPs
• new features (see scope and discussion of contributions below first; suggest following mailing list)
• documentation
• examples
• testing and improving consistency
• reviewing (an extremely valuable contribution after showing you are familiar with what makes a good contribution)
• spreading the word

How to contribute

• the pull request process: perhaps adopting an issue; WIP status; MRG status; MRG+1; MRG+2; adding to what's new. Refinement and rebasing along the way.
• the ideal code contribution: well-written (clear and reasonably efficient) code consistent with the project's style; tests that ensure it works; understandable, complete docstrings; narrative documentation in the User Guide; examples that highlight interesting features of the algorithm, how to inspect its model, and how to interpret its hyperparameters.
• code management (i.e. git)
• coding guidelines
• API design
• documentation guidelines