Git Merging and pull requests

[MattReimer]

I noticed a few pull request piling up on so I thought I'd write a formal sort of discussion topic around it for @Riverscapes/developers etc.

Code reviews on this repo are super important because everything on master branch is being used by the whole system: All 3 QRAves, the warehouse and the automation processes. Code that we merge here gets immediately deployed to people's machines and we should all take that pretty seriously (looking at you MSWindows update!!!).

TL;DR: If we break it here we break all of Riverscapes... well potentially, hyperbole is fun)

I don't want things languishing and getting backed up though so maybe we can establish some sort of convention to get pull requests approved fast.

Matt's pull request rule suggestions for a happy life:

1. Pull requests should always have at least one reviewer
2. Reviewers should not be the person who wrote the code or made the commit.
3. If you're a reviewer NEVER just blanket approve anything. Take yourself off as a reviewer and/or leave a note if you don't have time to look at it.
4. I might consider pushing through a pull request without a review (except by me, of course) under the following conditions:
   1. It's a super small or obvious change.
   2. It has nothing to do with program or project XMLs
   3. It affects a tiny or experimental corner of the system (like a symbology file for a less-used or beta-level project).
   4. Please @ mention me in the pull request and tell me why you want me to push it through.

For now this really only applies to RiverscapesXML and . riverscapes-tools. Do as you like on your own repos but as we start moving our tools into production this might start applying to more places.

This is all designed to keep quality high and prevent system-level breakages but it's ultimately for you guys so let me know if you're annoyed about any of it and we can definitely adapt.

[joewheaton]

@Riverscapes/riverscape-project-curators you guys should read this!