Update CONTRIBUTING.md

[eugeneia]

Update CONTRIBUTING.md as per #761 (comment)

• Link to src/doc/git-workflow.md (We have an updated version in the pdf-manual branch, I think)
• Encourage contributors to bug assignees when in doubt
• Mention how to target PRs
• Mention non-obvious code formatting conventions: no tabs, three space indentation

Cc @petebristow @lukego @wingo @kbara @alexandergall @domenkozar @capr

[wingo]

lgtm!

[lukego]

Good idea!

Telling contributors to pick a target branch explicitly is new. I have been telling people to always target master with new features. Do we want to switch? (Seems reasonable to me -- and puts pressure on us to organize the branches such that people know which target to choose.) This would also allow us to close PRs more quickly, once merged to subsystem instead of once released to master, which may also be a feature these days (?).

I feel that we need to establish clear common expectations about how long things take (except when other specific guidance is given). I have tried to do this to some extent in #835. This is to calibrate the "stuck-o-meter" and know when to communicate with people.

Example:

• Get review from upstream, up to 3 working days?
• Get merge of a branch without blocking issues, up to one week?
• Time that a change lives on a subsystem branch before going upstream, up to one week?
• How long before the latest release is merged into each subsystem branch, up to one week?

These would not be hard deadlines but rather a framework for maintainers to know when they should provide guidance to contributors ("I will get to this next week", "I want to merge #xxx first", etc) and vice-versa ("I am still waiting for feedback on my latest changes", "my change seems to be stuck on your branch", etc).

This framework might allow maintainers to come up with comfortable and efficient routines. For example, maybe I sync my branch with upstream every Monday and I provide follow-up on each PR that is assigned to me on Tuesdays and Wednesdays. On weeks where the routine is disrupted I post a little note to manage contributors' expectations so that they don't worry about bugging me. (Or for however I want to organize my work that is consistent with the common expectations.)

[wingo]

Yeah I feel like we already have these expectations in place, you just have to hang around enough to understand them -- which is something of an antipattern in a way; if we recognize that we'd like review within a few days then we might as well write it down and make it easier for new contributors to help make Snabb better. Of course there's a balance; I don't mean to obligate reviewers to do things, because as we all know we get pulled away from things from time to time and don't always have the time. But usually it's just that something comes in, it's too gnarly for an immediate yes/no, and so it sits in the queue :) So +1 to a general etiquette/expectations writeup of when to expect things to happen, more or less, and when a ping is welcome.