Document how to test open pull requests

[chrisinajar]

Create documentation in the docs folder containing everything related to getting other people's pull requests onto your local for testing. Additionally, instruct people to use the tACK / utACK paradigm. An ACK is an approval of the pull request, t vs ut implies if they personally tested it or not.

An example of when utACK is useful would be a simple PR that just changes some KV. Testers can review the changes in the source tab and leave utACK (this is something I do occasionally).

A review of a pull request should always result in either tACK, utACK, or changes requested.

[chrisinajar]

the magic git commands are

git remote add username [email protected]:username/oaa.git

once for each new remote, once added you can test any number of PR's from them with

git fetch username
git checkout -b feature_name username/feature_name

[fcalife]

Minor gripe: some kv's don't work at all - I'd argue unless you're experienced enough to know those, testing is still necessary

[chrisinajar]

a utACK is rarely enough, but is always better than nothing.

[warpdragon]

hahaha this