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

Hey Edy, Thanks for your point of view on this. I understand that you're feeling like I'm attacking you or applying pressure, I think this is a reasonable feeling because what I'm asking is something that has not been asked before. Please though be very careful to read my words only exactly as they are. You refer to pressure which I applied offline but if you look at the exact words I said, I was asking "when will it be reviewed?", because I have to plan around a deadline. I fully understand your mistaking that for a mix of words intended to make you work quickly, we all mix these up, it's part of being human. The sad result of this is you feel you've complied to pressure and I only needed the answer to a question so I could plan. On the topic of quality, I understand your position but please also understand mine, I personally maintain a significant size software project, I know there are things which are unacceptable. I also know a lot of things which could be better but I will accept them anyway (often with a suggestion to improve for next time). I feel a little bit insulted that my judgement is not considered good enough for your extension, or that I am not trusted to clean up if I make a mess and things actually break.

What this all boils down to in the end is I am against a deadline with 3 choices: 1. Fork your extension and re-package it into the WebIDE 2. Lose the SyntaxHighlighting feature in order to ship 3. Make a PR and hope for the best, possibly v0.12 of WebIDE will not be releasable. I hate 1 and 2, I want so much to do 3 but I need some assurance that you will understand my situation and be willing to share the decision making about acceptable quality level. Is this something we can do ? Caleb On 17/12/15 17:35, Eduard Moraru wrote: > Hi Caleb, > > On Thu, Dec 17, 2015 at 3:51 PM, Caleb James DeLisle wrote: > >> also be available to the application, on release. If we desynchronize >>> them, the application will most likely be left behind. >>> >> >> I interpret your words to mean: we want to keep them merged in order to >> conscript any contributors (meaning us) into doing additional maintanence. >> >> Let me be clear. >> We have until Christmas to work on this and after that we will be done. >> If we are held up because you want to block us until we do other things, I >> feel that we are being abused and extorted for work. >> More concretely, if this involves any kind of discussion or back-and-forth >> which lasts until Christmas, we will simply miss our objective and not >> solve our objectives. >> >> >> * We can split this into 2 extensions as we discussed, I am willing to >> proceed with the same repository/JIRA. >> * We can test the result and verify that there are no changes to the >> frontend version for the user. >> * We cannot do this within the given time requirement as long as there is >> NO BIKESHEDDING. >> ** An example of bikeshedding is here: >> https://github.com/xwiki-contrib/wiki-editor-devtools/pull/3 >> ** What makes it bikeshedding is the fact that the complaints are about >> process or "a better way to do it", not code which is seriously dangerous >> to accept. >> >> >> I want to collaborate on this, what I don't want is to be in a gatekeeper >> relationship in 1 week and then fail at my objective because of that. >> Please let me know if this is ok for you. >> >> >> Thanks, >> Caleb >> >> > 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/#… > >> >> >> >> On 17/12/15 09:25, vincent(a)massol.net wrote: >> >>> I agree with Edy that it’s better to release them together: * Simplifies >>> a lot the matrix compatibility tests * Ensure they’re in sync * Simplify >>> release processes >>> >>> Thanks -Vincent On 16 Dec 2015 at 19:01:38, Eduard Moraru ( >>> enygma2002(a)gmail.com) wrote: >>> >>> Hi Caleb, >>> >>> (just saw your reply) >>> >>> On Wed, Dec 16, 2015 at 6:19 PM, Caleb James DeLisle >>> wrote: >>> >>> They're going to have distinct release cycles >>>> >>> >>> >>> This is exactly what I hope to avoid by not separating the code from the >>> application. This way, whatever improvements you bring to the code, will >>> also be available to the application, on release. If we desynchronize them, >>> the application will most likely be left behind. >>> >>> Also, it will give you a way be constantly reminded that the code module >>> is used by other projects as well, and should remain generic enough and, at >>> the same time, it will not bring any overload since the application itself >>> is extremely basic to maintain. >>> >>> Thanks, Eduard >>> >>> >>> so I think the least ugly thing to do is have 2 projects. >>>> >>>> Thanks, Caleb >>>> >>>> >>> >>>> >>>> On 16/12/15 17:12, vincent(a)massol.net wrote: >>>> >>>> >>>>> >>>>> On 16 Dec 2015 at 16:56:57, Yann Flory (yann.flory(a)xwiki.com(mailto: >>>>> yann.flory(a)xwiki.com)) wrote: >>>>> >>>>> Hello devs, >>>>> >>>>>> >>>>>> In order to be able to use the CodeMirror editor in other extensions, >>>>>> we'd like to split the Syntax Highlighting application in two parts (Cf >>>>>> http://jira.xwiki.org/browse/WIKIEDITOR-37) A new extension, Syntax >>>>>> Highlighting UI Module, would be created and it would provides the ability >>>>>> to transform a given textarea into a CodeMirror editor. The current >>>>>> extension would keep the part which detect all textareas in 'edit' mode and >>>>>> transform them into CodeMirror editors (with a dependency on >>>>>> the new extension). If this is accepted, we'll need a new Jira project >>>>>> for the module. >>>>>> >>>>>> >>>>> Note: We create a jira project per repo, I don’t think we need 2 jira >>>>> projects. We could have 2 jira “components” though. >>>>> >>>>> Thanks -Vincent >>>>>