[postfuturist]

"automatic merging" upon consensus -- had to laugh at this idea, the ratio of merge requests that would merge cleanly, automatically is low. Generally they have to be rebased against the exact branch they are to be merged against with human intervention to rectify not only merge conflicts and broken tests but possible interaction issues with recent changes on master branch. In any case, arbitrary changes can (and sometimes should) be made to bring the branch in line with the main code. So branch merges that were "voted in" still need human intervention to merge. Should that then be re-voted on, given that merges and conflict-resolved rebases/merges can include arbitrary changes? Obviously, but what if more changes go into the target branch while folks are getting around to ratifying the rebased merge branch? There still needs to be trusted "merge officers" or whatever who can and will clean up, test, and merge popular branches which were voted on. You can't get around that.

[saidajigumi]

As the maintainer of an an alternately alive/not-really-alive github-based project, a problem with changes being voted in is that many submitted PRs are of fairly low quality.

Just because an idea is needed by the consumers of a project doesn't mean that any given implementation will be satisfactory. Many voters will tend to be uncritical and/or have different standards. E.g. did the submitted change include tests? Did it pass existing tests? Did it implement a feature that was actually needed (e.g. did it solve a "docs" bug via a "code" patch)? Bikeshedding over existing functionality? The list goes on.

I'll also note that GitHub's great CI integration support (used by Travis CI, the Jenkins GitHub plugin, etc.) can significantly aid the proposals in TFA. E.g. a PR that doesn't pass CI would automatically be ineligible for merging.