Forgo two-step merges for this repo.

[mikeal]

I can see why it might be a good idea to have two people check out each commit in some other repos but this one is incredibly low risk.

I'm thinking that optimizing for writes is the best course of action. Backing something out is incredibly easy if something bad gets merged so it isn't like there is much risk in having each collaborator merge without a second ok'ing it.

[hackygolucky]

The +1 approach does seem a tad silly for this. It certainly slows down our ability to have a fresh delivery of events. I was using the workflow I am used to elsewhere, but I'm always up for improvements.

[mikeal]

yeah, i'm writing a piece on this pretty soon actually :)

in many ways contribution psychology hasn't kept up with where our tools are.

[hackygolucky]

Can't wait to read it! I'm still trying to figure out my opinions on when/where is appropriate for collaborative workflows that can end up inviting WAY more bike-shedding than ends up being necessary.

I appreciate others' opinions. What I haven't quite learned is that they -aren't- always necessary.

[junosuarez]

In the mean time, let me +1 this for all non-code contributions in knode.

Sometimes a speculative pull request is opened, where the contributor is just making a set of commits available to spur a discussion or get feedback, but not necessarily indicating that it is already ready to merge. In this case, whoever opens the PR should indicate it as such, and the committers should make sure everything's copacetic before merging.

[gergelyke]

@jden how about the [WIP] tag in the name of the PR?