[xwiki-devs] [Contrib] Jira project for a new Syntax Highlighting Module
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. Thanks, Yann
On 16 Dec 2015 at 16:56:57, Yann Flory ([email protected](mailto:[email protected])) 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
They're going to have distinct release cycles so I think the least ugly thing to do is have 2 projects. Thanks, Caleb On 16/12/15 17:12, [email protected] wrote:
On 16 Dec 2015 at 16:56:57, Yann Flory ([email protected](mailto:[email protected])) 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Caleb, (just saw your reply) On Wed, Dec 16, 2015 at 6:19 PM, Caleb James DeLisle <[email protected]> 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, [email protected] wrote:
On 16 Dec 2015 at 16:56:57, Yann Flory ([email protected](mailto: [email protected])) 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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 ([email protected]) wrote: Hi Caleb, (just saw your reply) On Wed, Dec 16, 2015 at 6:19 PM, Caleb James DeLisle <[email protected]> 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, [email protected] wrote:
On 16 Dec 2015 at 16:56:57, Yann Flory ([email protected](mailto: [email protected])) 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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 On 17/12/15 09:25, [email protected] 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 ([email protected]) wrote:
Hi Caleb,
(just saw your reply)
On Wed, Dec 16, 2015 at 6:19 PM, Caleb James DeLisle <[email protected]> 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, [email protected] wrote:
On 16 Dec 2015 at 16:56:57, Yann Flory ([email protected](mailto: [email protected])) 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Also note that we’ve discussed in the past about moving the autocompletion and syntax highlighting modules into xwiki-platform as they can be considered core modules. I’ll send a proposal about this as I feel these modules should be maintained and developed in the core, for the same reason that AWM should be in the core: the core should provide good developer tools by default. Thanks -Vincent On 17 Dec 2015 at 14:53:16, Caleb James DeLisle ([email protected]) 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 On 17/12/15 09:25, [email protected] 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 ([email protected]) wrote:
Hi Caleb,
(just saw your reply)
On Wed, Dec 16, 2015 at 6:19 PM, Caleb James DeLisle <[email protected]> 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, [email protected] wrote:
On 16 Dec 2015 at 16:56:57, Yann Flory ([email protected](mailto: [email protected])) 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Vincent, In the light of the discussion about speed versus quality that is in progress on these modules, I feel that it would make only things worse for speed if these modules go in the core. If would mean that the modules would only evolve with the core releases. I don't see how this would help people writing extensions be efficient when they need patches in the underlying modules. I've seen this issue with other core modules where as an extension developer you still have to work around a bug or a lacking feature because the fix or improvement needed will only come in the next major release. I would suggest we move things into the core only when we consider them highly stable. Ludo On Dec 17, 2015 15:00, "[email protected]" <[email protected]> wrote:
Also note that we’ve discussed in the past about moving the autocompletion and syntax highlighting modules into xwiki-platform as they can be considered core modules.
I’ll send a proposal about this as I feel these modules should be maintained and developed in the core, for the same reason that AWM should be in the core: the core should provide good developer tools by default.
Thanks -Vincent
On 17 Dec 2015 at 14:53:16, Caleb James DeLisle ([email protected]) 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
On 17/12/15 09:25, [email protected] 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 ( [email protected]) wrote:
Hi Caleb,
(just saw your reply)
On Wed, Dec 16, 2015 at 6:19 PM, Caleb James DeLisle <[email protected]> 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, [email protected] wrote:
On 16 Dec 2015 at 16:56:57, Yann Flory ([email protected](mailto:
[email protected])) 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Caleb, On Thu, Dec 17, 2015 at 3:51 PM, Caleb James DeLisle <[email protected]> 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, [email protected] 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 ( [email protected]) wrote:
Hi Caleb,
(just saw your reply)
On Wed, Dec 16, 2015 at 6:19 PM, Caleb James DeLisle <[email protected]> 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, [email protected] wrote:
On 16 Dec 2015 at 16:56:57, Yann Flory ([email protected](mailto: [email protected])) 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list
[email protected] http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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 <[email protected]> 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, [email protected] 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 ( [email protected]) wrote:
Hi Caleb,
(just saw your reply)
On Wed, Dec 16, 2015 at 6:19 PM, Caleb James DeLisle <[email protected]> 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, [email protected] wrote:
On 16 Dec 2015 at 16:56:57, Yann Flory ([email protected](mailto: [email protected])) 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list
[email protected] http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Caleb and Edy, On 18 Dec 2015 at 09:02:17, Caleb James DeLisle ([email protected](mailto:[email protected])) wrote:
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.
Just on this point, if someone should feel insulted it’s Yann I guess :) As I mentioned in a previous email, I’d really like if Yann could tell us how he’d like to proceed (since he’s the one coding and doing the PRs afterall) and if there’s anything that bothers him with the way his PRs have been handled (and that we should improve). Regarding yourself Caleb, we (other core committers) obviously trust you a lot, this is why you’re a core committer :) More generally: Could everyone please stop feeling insulted and could we work together in a nice way, using nice words to each others? :) We’re all in the same boat after all and we’re all driving to making the XWiki ecosystem better. Let’s work better together :) (private joke intended). And Merry Christmas to all! Thanks -Vincent
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, [email protected] 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 ( [email protected]) 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, [email protected] wrote:
On 16 Dec 2015 at 16:56:57, Yann Flory ([email protected](mailto: [email protected])) 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
Hi all, First, I'm sorry Edy if I'm not able to produce the quality level you expect. I wanted initially to have only one issue fixed in that PR but I pushed two new commits in my fork and I didn't realized it was on the same branch, and so GitHub automatically updated the PR. It was not intended. I'm not sure though that it was necessary to have 4 or 5 comments about that in the PR. I'd like to contribute following the best practices but, as Caleb explained, we have deadlines and we have to be sure it will allow us to release the new version in time (meaning we'd like to agree on the acceptable quality level). Otherwise, we'll have to remove some features of the Web IDE. Finally, from my point of view, I know it isn't true but it's a bit strange to make a proposal about moving it into xwiki-platform and work on the extension yourself, in this thread while we are trying to contribute and make some changes. Thanks, Yann <https://www.avast.com/?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Cet e-mail a été envoyé depuis un ordinateur protégé par Avast. www.avast.com <https://www.avast.com/?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Fri, Dec 18, 2015 at 9:36 AM, [email protected] <[email protected]> wrote:
Hi Caleb and Edy,
On 18 Dec 2015 at 09:02:17, Caleb James DeLisle ([email protected](mailto: [email protected])) wrote:
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.
Just on this point, if someone should feel insulted it’s Yann I guess :) As I mentioned in a previous email, I’d really like if Yann could tell us how he’d like to proceed (since he’s the one coding and doing the PRs afterall) and if there’s anything that bothers him with the way his PRs have been handled (and that we should improve).
Regarding yourself Caleb, we (other core committers) obviously trust you a lot, this is why you’re a core committer :)
More generally: Could everyone please stop feeling insulted and could we work together in a nice way, using nice words to each others? :) We’re all in the same boat after all and we’re all driving to making the XWiki ecosystem better. Let’s work better together :) (private joke intended).
And Merry Christmas to all!
Thanks -Vincent
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, [email protected] 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 ( [email protected]) 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, [email protected] wrote:
> > On 16 Dec 2015 at 16:56:57, Yann Flory ([email protected]
(mailto:
> [email protected])) 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 >
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Yann, On 18 Dec 2015 at 11:45:25, Yann Flory ([email protected](mailto:[email protected])) wrote:
Hi all,
First, I'm sorry Edy if I'm not able to produce the quality level you expect. I wanted initially to have only one issue fixed in that PR but I pushed two new commits in my fork and I didn't realized it was on the same branch, and so GitHub automatically updated the PR. It was not intended. I'm not sure though that it was necessary to have 4 or 5 comments about that in the PR.
I'd like to contribute following the best practices but, as Caleb explained, we have deadlines and we have to be sure it will allow us to release the new version in time (meaning we'd like to agree on the acceptable quality level). Otherwise, we'll have to remove some features of the Web IDE.
Finally, from my point of view, I know it isn't true but it's a bit strange to make a proposal about moving it into xwiki-platform and work on the extension yourself, in this thread while we are trying to contribute and make some changes.
<answering just this point because I was the one who did that> I put it in a different thread. They’re related topics but with very different timelines (yours is now, the move is several weeks/months away probably). The reason I started the other thread now was precisely because this thread was talking about deciding where to locate code and I wanted to give the visibility that the idea was to move that extension in platform (it has always been the goal), since if this is approved if removes the burden of having to find a new location and it makes more sense for now to contribute the new module inside the same repo/jira. The other reason was actually to help you :) When code is in xwiki-platform it means that the XWiki Core devs are supporting it (right now the syntax highlighting and autocompletion extensions are not supported, they were coded a few times during hackathons in people's free time). Since the WebIDE is a user of those extensions, the WebIDE will benefit from having supported extensions in the future. Regarding contributing, I don’t think that doing a PR in xwiki-contrib or in xwiki-platform will change that much. Hope this makes it clear. I’m sorry that you viewed it negatively when my reason was actually the opposite… More globally I’m sorry that we were not able to handle this all more constructively. Thanks -Vincent
Thanks,
Yann
Cet e-mail a été envoyé depuis un ordinateur protégé par Avast. www.avast.com
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Fri, Dec 18, 2015 at 9:36 AM, [email protected] wrote:
Hi Caleb and Edy,
On 18 Dec 2015 at 09:02:17, Caleb James DeLisle ([email protected](mailto: [email protected])) wrote:
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.
Just on this point, if someone should feel insulted it’s Yann I guess :) As I mentioned in a previous email, I’d really like if Yann could tell us how he’d like to proceed (since he’s the one coding and doing the PRs afterall) and if there’s anything that bothers him with the way his PRs have been handled (and that we should improve).
Regarding yourself Caleb, we (other core committers) obviously trust you a lot, this is why you’re a core committer :)
More generally: Could everyone please stop feeling insulted and could we work together in a nice way, using nice words to each others? :) We’re all in the same boat after all and we’re all driving to making the XWiki ecosystem better. Let’s work better together :) (private joke intended).
And Merry Christmas to all!
Thanks -Vincent
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, [email protected] 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 ( [email protected]) 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, [email protected] wrote: > > >> >> On 16 Dec 2015 at 16:56:57, Yann Flory ([email protected] (mailto: >> [email protected])) 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
So I'm not responding directly to this mail but I wanted to post an update, as it were, for those paying attention. As you see I wrote a bunch of things which I was feeling about the process by which contributors get code merged into parts of XWiki. After that I had a nice conversation with Edy about these feelings and how things work and how things could maybe work better and maybe the pressures which he experiences as a committer. I wear three hats, I'm a committer, a contributor and a user. Maybe as a user I (and we) push too hard for committers to ship a bug-free release every time and this feeds a nervousness about accepting contributions. I'm not much for Christmas but a little understanding is a gift that keeps on giving. Now Edy was very graceious and decided to accept all of our pull requests. Not only that, he volunteered that Yann and I should be in charge of his repository while he is gone on holidays, a token of trust which I mean to care for seriously. Now I want to be vigilant against the narrative that this was some kind of a negotiation or a battle that we "won". What Edy and I talked about, and what I want more than this one particular deadline, is that we the users, the contributors and the committers all have a little more understanding for one another. One might say we are defined by how often we invoke The Rules toward one another. Thanks, Caleb On 18/12/15 13:28, [email protected] wrote:
Hi Yann,
On 18 Dec 2015 at 11:45:25, Yann Flory ([email protected](mailto:[email protected])) wrote:
Hi all,
First, I'm sorry Edy if I'm not able to produce the quality level you expect. I wanted initially to have only one issue fixed in that PR but I pushed two new commits in my fork and I didn't realized it was on the same branch, and so GitHub automatically updated the PR. It was not intended. I'm not sure though that it was necessary to have 4 or 5 comments about that in the PR.
I'd like to contribute following the best practices but, as Caleb explained, we have deadlines and we have to be sure it will allow us to release the new version in time (meaning we'd like to agree on the acceptable quality level). Otherwise, we'll have to remove some features of the Web IDE.
Finally, from my point of view, I know it isn't true but it's a bit strange to make a proposal about moving it into xwiki-platform and work on the extension yourself, in this thread while we are trying to contribute and make some changes.
<answering just this point because I was the one who did that>
I put it in a different thread. They’re related topics but with very different timelines (yours is now, the move is several weeks/months away probably).
The reason I started the other thread now was precisely because this thread was talking about deciding where to locate code and I wanted to give the visibility that the idea was to move that extension in platform (it has always been the goal), since if this is approved if removes the burden of having to find a new location and it makes more sense for now to contribute the new module inside the same repo/jira.
The other reason was actually to help you :) When code is in xwiki-platform it means that the XWiki Core devs are supporting it (right now the syntax highlighting and autocompletion extensions are not supported, they were coded a few times during hackathons in people's free time). Since the WebIDE is a user of those extensions, the WebIDE will benefit from having supported extensions in the future.
Regarding contributing, I don’t think that doing a PR in xwiki-contrib or in xwiki-platform will change that much.
Hope this makes it clear. I’m sorry that you viewed it negatively when my reason was actually the opposite… More globally I’m sorry that we were not able to handle this all more constructively.
Thanks -Vincent
Thanks,
Yann
Cet e-mail a été envoyé depuis un ordinateur protégé par Avast. www.avast.com
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Fri, Dec 18, 2015 at 9:36 AM, [email protected] wrote:
Hi Caleb and Edy,
On 18 Dec 2015 at 09:02:17, Caleb James DeLisle ([email protected](mailto: [email protected])) wrote:
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.
Just on this point, if someone should feel insulted it’s Yann I guess :) As I mentioned in a previous email, I’d really like if Yann could tell us how he’d like to proceed (since he’s the one coding and doing the PRs afterall) and if there’s anything that bothers him with the way his PRs have been handled (and that we should improve).
Regarding yourself Caleb, we (other core committers) obviously trust you a lot, this is why you’re a core committer :)
More generally: Could everyone please stop feeling insulted and could we work together in a nice way, using nice words to each others? :) We’re all in the same boat after all and we’re all driving to making the XWiki ecosystem better. Let’s work better together :) (private joke intended).
And Merry Christmas to all!
Thanks -Vincent
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, [email protected] 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 ( > [email protected]) 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, [email protected] wrote: >> >> >>> >>> On 16 Dec 2015 at 16:56:57, Yann Flory ([email protected] (mailto: >>> [email protected])) 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
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Caleb, On 17 Dec 2015 at 14:53:13, Caleb James DeLisle ([email protected](mailto:[email protected])) 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.
I’ve already explained why it makes sense to keep them together for me: * This allows to release them together and thus ensure they’re compatible. If you don’t do this you need to test multiple combinations of versions and keep a compatibility matrix, which is a pain. We’ve been there in the past if you remember and it was a nightmare. This is for example why we release all modules together for commons, rendering, platform and enterprise. So if by maintenance you mean ensuring that the syntax highlighting and autocompletion apps continue to work the yes you’re right, that’s the idea! It seems fair to ensure that changing the library used by those 2 apps shouldn’t introduce breakages in them. Don’t you think so? [snip]
* 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.
Cool
* 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’m not going to comment more on this as it won’t make us progress.
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.
If by gatekeeper you mean being responsible for all future maintenance of this module, then rest assured that it won’t happen. We’ve been wanting to bring this repository into platform from day one (when Edy and I started it in a hackathon session a few years ago). So the goal is for us to maintain it in some not too long future hopefully. Unfortunately our roadmap so far has not really been very keen for this module but I have the feeling that its importance is going to rise :) Thanks for helping, -Vincent PS: I think it would be nice to hear from Yann too since he’s the developer of this work and it would be interesting to hear his POV and work with him and understand if he has any issue with this.
Thanks, Caleb
On 17/12/15 09:25, [email protected] 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 ([email protected]) 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, [email protected] wrote:
On 16 Dec 2015 at 16:56:57, Yann Flory ([email protected](mailto: [email protected])) 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
Hi Yann, As I`ve explained it to Caleb, in a private chat, you don`t need to create a new extension (repo + jira project) for that. Just create a new maven "-ui-code" submodule and have the -ui module depend on it. From other 3rd party extensions, you can depend on this -ui-code module and require it as an AMD module to use it as needed. The directory layout for the syntax highlighting maven module should look somethin like this: editor-tool-highlighting - editor-tool-highlighting-ui - editor-tool-highlighting-ui-code I`ve created 2 components in the current jira project since they were missing: http://jira.xwiki.org/browse/WIKIEDITOR#selectedTab=com.atlassian.jira.plugi... If you like and consider it necessary, we could create a 3rd component, "Syntax Highlighting Code". WDYT? Thanks, Eduard On Wed, Dec 16, 2015 at 6:12 PM, [email protected] <[email protected]> wrote:
On 16 Dec 2015 at 16:56:57, Yann Flory ([email protected](mailto: [email protected])) 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (5)
-
Caleb James DeLisle -
Eduard Moraru -
Ludovic Dubost -
vincent＠massol.net -
Yann Flory