Minor cleanup

[geekytime]

Check out the commit comments for this one.

[geekytime]

This probably sounds weird, but I mostly prefer to use the GitHub Flow, so I'm not used to other people merging my PRs if I'm a contributor. I prefer GitHub flow because it gives the creator of the pull request a little bit more control over their code. If you review and thumbs-up my PR instead of just merging it, it gives me a chance to make last-minute changes, merge things in a specific order, etc.

What kind of GitHub workflow are we using? Would you guys be open to using GitHub Flow? Then we can merge once our own branches once we have a :+1: from another contributor.

@lloeki, @H3Chief - what are your thoughts?

[LongLiveCHIEF]

Sorry about that.

Github Flow is my preferred also. With these open source projects, I'm just so used to merging pulls from contributors who don't have access to merge that I tend to merge PR's from fork's out of sheer habit.

[lloeki]

I'm used to a variant of GitHub flow with the following changes:

• rebase before merge, preventing some bad merge scenarios
• since we use GitLab, prefixing WIP: or [WIP] prevents the merge straight in the UI, indicating the requester wants to release the lock himself. Conversely, if there's no WIP, then it's a go ahead for collaborators. This can also be formally implemented here with a "wait" (or "can-merge" depending on the desired default) label.
• only master (or the occasional stable minor/patch branches when SemVer mandates history branching) is ever deployed in production or built and published on a lib repo. No package building from a topic branch, ever.