re test plan - the idea is to explain how you tested it. For this diff, I think you'd say something like

• configured a new flowbot setup, sent some test messages and it worked!
• was unable to test campfire

...and if you really want to be a superstar, you could explain how you configured the flowbot setup, what test messages you sent exactly, etc.

The test plan becomes more useful if the product can be interacted with several ways, as it clearly delineates how it was tested and how it was not tested. Reviewers can then suggest additional test coverage they want to see. The test plan is also often helpful for reviewers who have no idea what the feature does - the test plan should kind of delineate how the new code was tested and thus what it actually does.

Writing the test plan is also often helpful as you may discover things you didn't test but really should now that you have to explain what you did. I personally find that it also gives me the fortitude to re-do all the testing after I make a small change; you really want your own test plan to pass.

@btrahan -- thanks so much. I didn't think this would get insta-merged; Should I go back and update the revision details in the web UI, even though the commit message will forever contain my derpishness?

nah, no need to update. Thanks for the contribution btw!

My pleasure.

So I guess my resume will now say "Core Contributor | phabricator"

;-)