{"action":"created","issue":{"url":"https://api.github.com/repos/neovim/neovim/issues/2122","labels_url":"https://api.github.com/repos/neovim/neovim/issues/2122/labels{/name}","comments_url":"https://api.github.com/repos/neovim/neovim/issues/2122/comments","events_url":"https://api.github.com/repos/neovim/neovim/issues/2122/events","html_url":"https://github.com/neovim/neovim/issues/2122","id":60379767,"number":2122,"title":"A call to arms: Reviewers wanted.","user":{"login":"elmart","id":135757,"avatar_url":"https://avatars.githubusercontent.com/u/135757?v=3","gravatar_id":"","url":"https://api.github.com/users/elmart","html_url":"https://github.com/elmart","followers_url":"https://api.github.com/users/elmart/followers","following_url":"https://api.github.com/users/elmart/following{/other_user}","gists_url":"https://api.github.com/users/elmart/gists{/gist_id}","starred_url":"https://api.github.com/users/elmart/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/elmart/subscriptions","organizations_url":"https://api.github.com/users/elmart/orgs","repos_url":"https://api.github.com/users/elmart/repos","events_url":"https://api.github.com/users/elmart/events{/privacy}","received_events_url":"https://api.github.com/users/elmart/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/neovim/neovim/labels/project%20management","name":"project management","color":"d4c5f9"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":6,"created_at":"2015-03-09T17:30:26Z","updated_at":"2015-03-09T21:08:25Z","closed_at":null,"body":"## The problem\r\n\r\nIt's been for some time now that a disturbing thought has been coming to my mind: Though neovim project is in good health, I feel that, somehow, we're losing traction.\r\n\r\nDont' get me wrong. We've achieved phenomenal progress, and have a steady contribution pace. But what I mean by \"loosing traction\" is that I think our pace could be much higher, if we were able to handle it. In other words, I feel there are a lot of potential contributors that get pissed-off because of their first PR's taking too much time before getting reviewed/merged. A quick turnaround time on good PR's is essential to keep people engaged.\r\n\r\nBTW, this is by no means a complain on @justinmk's work. On the contrary, I can only praise his impressive dedication and the amount of work he's been able to cope with. It's really difficult to find the time to do what he does, at a sustained pace, and for so long.\r\n\r\nHaving more people merging code, or trying to cope with PR's in a more FIFO way, as it's been suggested in #2056, could help, but, IMO, that's not the real bottleneck. The crux of the problem, to my understanding, is reviewing. To state it clearly: **We need more reviewers**. Less time put by people on doing their own things, and more time dedicated to review others'.\r\n\r\nNow, why people isn't already reviewing more? To my understanding, there could be several reasons:\r\n- (1) It's more fun to do your own thing than to review others'.\r\n- (2) Good reviewing often requires not only a good knowledge of C, but also a fair understanding of the project status/direction.\r\n- (3) Review work doesn't get visible/rewarded/recognized.\r\n\r\nThere's little we can do about (1), apart from appealing to people's good citizenship and altruism, for the sake of project's success.\r\nAs of (2), I'd say many PR's don't require a project-wide vision. And also, if reviewing was somehow done more attractive, many people would quickly get to a good understanding by reading others' reviews for a little while.\r\nThus, we reach (3), for which something can indeed be done, IMO.\r\n\r\nProblem is that good, thorough reviewing takes a lot of effort. Often, longer than it takes to make the changes themselves. But that effort is reflected nowhere. It has no public visibility. After corrections have been incorporated into original commits, even comments often dissappear due to rebasing, if people comment on commits instead of diffs. There are people out there doing an incredible review work (@oni-link comes first to my mind), who are altruistic enough not to care much about that. But, let's admit it: many others probably care, and there's nothing wrong about that. It's perfectly understandable that many people find frustrating putting so much effort on something that, very often, will leave no trace.\r\n\r\nI find this situation a major pitfall of open-source development in general, and of GitHub workflow in particular. In fact, I wrote to GitHub's staff some time ago, asking for some way to publicly reward reviewers. They kindly responded it was an interesting suggestion, but it won't probably land soon. So, can we do something about that in the meantime?\r\n\r\n## A possible improvement?\r\n\r\nI think we could try a **simple approach to make reviewing more attractive: Let's credit reviewers by setting them as authors of review commits**. I mean, instead of integrating corrections into original commits, let's add separated review commits, setting the author to the actual reviewer, instead of the PR's owner. You can easily do that with `git commit --author=<...>`. Final PR could reorder those review commits to follow original commit, but maintain them as separated commits. That would increase reviewer's commit count, and would push him up in the contributor list, which, IMO, is a fair recognition for his work.\r\n\r\nI would also make some nuances to that:\r\n- doing it only for semantic corrections, not for styling corrections, as a way to discourage superficial, style-only reviews.\r\n- doing it only once per ammended-commit/reviewer combination.\r\n\r\nThose are details that should be developed by the community. But the general approach, I think it could work. It would add some noise to the commit log (also some more faithful accountability for changes), but in exchange for that, we could get more people engaged in reviewing, thus boosting project's output, and what is more important, keeping contributors happier.\r\n\r\nWhat do you guys think of this?\r\n\r\nP.S. I had been thinking all this for a while, but it was #2056 to push me to write this. I think a separated thread is in order, though, not to hijack that PR."},"comment":{"url":"https://api.github.com/repos/neovim/neovim/issues/comments/77942989","html_url":"https://github.com/neovim/neovim/issues/2122#issuecomment-77942989","issue_url":"https://api.github.com/repos/neovim/neovim/issues/2122","id":77942989,"user":{"login":"tarruda","id":842846,"avatar_url":"https://avatars.githubusercontent.com/u/842846?v=3","gravatar_id":"","url":"https://api.github.com/users/tarruda","html_url":"https://github.com/tarruda","followers_url":"https://api.github.com/users/tarruda/followers","following_url":"https://api.github.com/users/tarruda/following{/other_user}","gists_url":"https://api.github.com/users/tarruda/gists{/gist_id}","starred_url":"https://api.github.com/users/tarruda/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tarruda/subscriptions","organizations_url":"https://api.github.com/users/tarruda/orgs","repos_url":"https://api.github.com/users/tarruda/repos","events_url":"https://api.github.com/users/tarruda/events{/privacy}","received_events_url":"https://api.github.com/users/tarruda/received_events","type":"User","site_admin":false},"created_at":"2015-03-09T21:08:25Z","updated_at":"2015-03-09T21:08:25Z","body":"> If there was some very thorough documentation about:\r\n\r\nI will take an afternoon this weekend to document the code structure"}}