Re: [xwiki-devs] [Contrib] Jira project for a new Syntax Highlighting Module

Hi Caleb, On Thu, Dec 17, 2015 at 3:51 PM, Caleb James DeLisle <cjd(a)cjdns.fr> wrote: I am sorry you feel that way. Let me start of by saying that I, personally, felt insulted by your attitude. On the particular case of https://github.com/xwiki-contrib/wiki-editor-devtools/pull/3 , after your continuous pressure in an offline discussion, I dropped whatever I was working on at the time and made time to review the PR that you have mentioned. As mentioned in the review, there were 3 issues jammed into one single PR, there were individual aspects to fix for each issue and yes, there was code that was seriously dangerous to accept, as it would destabilize the feature and introduce bugs (like the disabling of the editor approach). If all you saw from that review was "bikeshedding", then perhaps I waisted my time. Of course I understand the frustration of going back and forward in a PR review. However, you must also understand that the same frustration applies to the reviewer as well. Out of curiosity, I did a Google search on the topic of how others use PRs (as project owners) and came up with this interesting study[1]. Scanning through it reveals that others have the same issues in finding the time to review PRs, that they value greatly the quality of the contribution and maintaining the quality of the project's code after the contribution is accepted. Other interesting facts can be observed in that report, but what I get from it is that it's not trivial to maintain a project and bashing someone for taking the time to help you is plain rude. Another thing I don`t understand is why you consider this to be an unilateral thing, i.e. the fault/job of the maintainer. There are numerous guides (ex. [2] - just read the headings) in how to do contributions/Pull Requests. They all boil down to a simple principle: The more you complicate the life of the reviewer (with a messy PR), the longer it will take for that PR to be applied (back and forward discussions on things that need to be fixed). Going down the rabbit hole, I also noticed this interesting article[3] on how GitHub's "Merge Pull Request" button is considered "harmful". It discusses exactly this friction/frustration that rises from back and forwards discussions on a PR until the quality of the contribution reaches an acceptable level. The way GitHub drives the contribution flow is that the contributor is the one responsible for ensuring that his contribution respects the guidelines and policies of the project and that the quality is good; the reviewer is simply a referee that gives the green light when all is good. The article seems to suggests that the reviewer goes beyond the referee status and also starts fixing the (code/style/documentation/etc.) problems of the contribution, finally applying it, thus giving credit to the contributor. It is an interesting approach and, as far as I can understand from your message, is something that you would like very much, unfortunately I don`t see it as being realistic, since a project's maintainers can usually be counted on one hard and the workload required for such an approach does not leave room for other things in the life/day-job of the maintainer. The "abuse", "extortion", "conscription" and "additional maintenance" you were mentioning above would only be shifted on the shoulders of the project maintainer because of the lack of quality in the contribution he has just blindly accepted. You have to understand that nobody is trying to sabotage your schedules and that any problem can be resolved by discussing it, not by giving ultimatums. Thanks, Eduard ---------- [1] http://gousios.gr/blog/How-do-project-owners-use-pull-requests-on-Github/ [2] http://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/ [3] http://blog.spreedly.com/2014/06/24/merge-pull-request-considered-harmful/#…