I do appreciate when tools/libraries take the time to explain the problem and how they differ from their competition. Especially in cases like this, where it's an underlying architecture difference.
The various Rake servers (Puma, Unicorn, etc.) have also done a great job of this.
This seems like a good way of creating stand up reports that no one will read, except maybe management.
I've always thought of stand ups as a self-management tool and a short period of forced communication.
Wikipedia says "the structure of the meeting is meant to promote follow-up conversation, as well as to identify issues before they become too problematic" which having it as an asynchronous discussion seems to prevent.
I dont suppose you have a tool that does this? I've been pondering building one, but I'd rather just skip to the part where I can start complaining about my service :p
Yeah, this is pretty much the behavior that I want to see from open source maintainers: make decisions and build conventions but be open to having your mind convinced of alternatives.
I use atmos/heaven for a similar functionality. It's nice because it ensures that the master branch on Github has gone through out automated tests and that whoever is deploying is deploying exactly the code from Github and not some strange variant locally.