after it is accepted?

This is very platform dependent - would be good if the doc pointed this out and gave links to the Phabricator user documentation, e.g.

https://secure.phabricator.com/book/phabricator/article/arcanist_quick_start/

and the "Installing Arcanist" section in

https://secure.phabricator.com/book/phabricator/article/arcanist/

SSH key -> SSH public key

There are some prerequisite tools for linting that are needed depending on what files are being modified.

Known to me are clang-format-3.8 and autopep8 .

Seems like this section duplicates a lot from docs/developer-notes, including some notes in this outstanding review: https://reviews.bitcoinabc.org/D720 Is this file intended to replace developer-notes?

Good point, I didn't notice D720.

We should avoid duplication.

This will be confusing for a lot of developers. I do not normally work this way, and it's forcing me to rethink how I go about manipulating the code. Although, I think it's for the better. We should discuss in depth what we mean, and how it improves quality. It's sort of a measure-twice cut-once type deal.

I want to encourage people to reach out for a 1-on-1 review so things move quickly

FWIW, The single quotes are extraneous.

FYI I just pushed D720, so feel free to rebase and move that content if you think it fits better in CONTRIBUTING.md

I'm trying got capture how Amaury wants people to work in the project.

I won't land the diff unless he is happy with this part

Sometime, you want to replace one subsystem by another implementation, in which case it is not possible to do things incrementally. In such case, you keep both implementation in the codebase at once for a while (this is more or less what's happening for cashaddr right now).

https://www.gamasutra.com/view/news/128325/Opinion_Parallel_Implementations.php

master without a capital M

Ideally, we'd like to fix what broke rather than revert. But if fixing takes too long => revert. The important point here is not to revert, but to keep master green as much as possible.

git commit --am

does wonders.

For what it's worth, we have this policy at LinkedIn. Smaller diffs (usually) influence the following:

• Easier, more digestible chunks that can be reviewed by reviewers in a single sitting. This makes it more likely to get quicker reviews, especially if you require reviews from multiple people.
• Less likely to run into large merge conflicts.
• Having one or more test changes/additions per diff encourages code coverage* (*This doesn't apply to all diffs, such as refactors that display the same behavior and are covered by existing tests)
• Writing code in small chunks can influence how you design your changes from a higher level. Personally, I've found it to be much easier to pivot and make design changes as you get reviews on small changes. For example, if you know you'll be working on a large change, committing skeleton code with /*TODO: <some short description*/ where appropriate can make your design intentions clear without wasting your time on the implementation details. This is especially effective when the design hasn't been agreed on or is not well understood.

Just my two cents.