Jon, I know you mean well, and that you are passionate about solving this problem, but I do not believe this is the right approach. I've communicated that in another thread with a smaller group, and you did not respond to me. Now you are changing key details in the proposal, but the extension code is the same, which makes me feel a bit confused.
In a post to a smaller internal group yesterday, you said: We hold core to higher standards. We question everything > that goes in there thus it will take you 2 days-1 month to do > something compared to 1 day in your own extension, so naturally people > will do it in their own extension. > When we put stuff into core we ask things such as: > 1) Is it a complete solution? > 2) Is it stable? > 3) Is it clear how to use it (for example if core doesn't use a bit of > mediawiki ui it begs the question to an outside observer why it is > there) > 4) Does it break anything? > 5) Does it meet mediawiki's coding conventions? I challenged this approach, suggesting that all code we, as paid software engineering professionals, write should live up to these standards. Today you say: We hold the code [in Mantle] to exactly the same high standards that we > hold core to, we are just able to more freely experiment and iterate. So what is going on? You want to base two burgeoning projects on code that is free to change frequently so that you can experiment and iterate, but may or may not be doing so in a way that lives up to the standards of MediaWiki core. You also say: I also hope overtime it could be used to share other aspects of > missing frontend code architecture across extensions. > But also say: Mantle is only a short term measure. The hope is that all the code > that goes here will eventually go into core. So, again, what is going on? Is this meant to be a short term measure for sharing a few specific features while they not yet appropriate for core, or is this a long term measure that code should be moved through as needed? *The point I made in the other thread bears repeating.* <snip> > If the motivation of having Mantle is to move more quickly, I am firmly against it. We are paid, as professional software engineers, to write code that provides complete solutions, is stable, is clear how to use, doesn't break anything and meets MediaWiki's coding conventions. We all fall short of this frequently, but should consider that a failure and learn from our mistakes. What is being suggested is that such irresponsible programming practices be permitted within a special code "purgatory" which has no standards and which everything depends on which means it will inevitably be deployed everywhere. We shouldn't be coming up with ways to bypass, even if only temporarily, the standards that have been fought so hard to establish within MediaWiki. We should instead be looking for ways to make it easier to code to these standards; like increasing the use of continuous integration, facilitating mentorship and improving review tools. We should be looking to raise our standards, both in code quality and code reusability. The standards we establish shouldn't be treated as a limiting factor, but rather a call to action. More of our code should be general purpose libraries that can be shared outside of MediaWiki. Good practices are discovered when half-measure solutions fall apart under the strain of a sufficiently complex problem. We have no short of sufficiently complex problems, and an abundance of wisdom that's been poured into our coding conventions and standards for acceptance. I'm hoping we can not loose sight of that every time we run low on patience. </snip> - Trevor On Thu, Jul 3, 2014 at 9:09 AM, Jon Robson <jrob...@wikimedia.org> wrote: > == The problem == > MediaWiki has a huge UI standardisation problem. We use different > libraries, different css styles and class names, some of which do the > same thing. > > Recently the teams working on Flow and MobileFrontend noticed they > were doing various things in a similar fashion. We were both using > client side templates, we had various bits of JavaScript that were > similar, and many styles that we could potentially be sharing. > > == The motivation == > The Flow team has recently decided to use Handlebars [1] templating > language and the mobile team has been heavily using Hogan [2] > templating language for over a year now. Both of us are actively > involved in the templating RFC [3] however neither of us want to be > blocked by that RFC. Despite these different templating language > choices and the knowledge that we will one day need to standardise on > just one templating language, we both had a need to pass templates > from the server to the client via ResourceLoader. Mobile has been > doing this for a year, and rather than another big project like Flow > reinventing the wheel, we decided it was time to share code. > > We attempted to put the code straight into core, but Krinkle quite > rightly pointed out that a templating RL language solution without a > templating language packaged with it would be confusing and not useful > to the majority of developers outside the Flow/mobile bubble. So > instead, Mantle [4] was born. > > == Mantle == > The purpose of Mantle is to wrap additional infrastructure code that > core is missing, and iterate on that code quickly to get it to a state > where it is as generic as possible. > > As a result of Flow and mobile's collaboration the template code from > mobile supports multiple languages which is great for 3rd party users > who might want to write code using a different template language) and > it now has eyes from both the mobile and Flow teams on it, so it > should become stronger now it has 2 use cases. We're hoping to add > support for Knockoff which Gabriel has been working on in the near > future to experiment with that. > > We are waiting on a standard template language before upstreaming this > code to core and going through another round of review amongst our > developer peers. > > Currently Flow depends on Mantle, and there is a patch in gerrit to > move MobileFrontend to using it [5] > > == The future == > Mantle is only a short term measure. The hope is that all the code > that goes here will eventually go into core. We hold the code here to > exactly the same high standards that we hold core to, we are just able > to more freely experiment and iterate. I hope Mantle doesn't exist in > a year and instead we have a healthy frontend architecture that Mantle > has helped grow. > > In the meantime however mobile and Flow will use it to at least > standardise on a few things between our codebases with the goal to > make Flow as mobile friendly as possible. We don't want to ship two > bits of code, one from MobileFrontend and one from Flow, to a mobile > Flow page that do exactly the same thing. > > I also hope overtime it could be used to share other aspects of > missing frontend code architecture across extensions. For example, it > could potentially be used to rapidly develop new components for > MediaWiki UI [6] that are not quite stable enough to be placed in > core and made available to all. > > If you're interested in sharing and collaborating on frontend code > with Flow and mobile feel, or client side templates in general free to > grab me off list and on irc (@jdlrobson). We don't do enough of this > :-) > > Jon > > [1] http://handlebarsjs.com/ > [2] http://twitter.github.io/hogan.js/ > [3] > https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library > [4] https://www.mediawiki.org/wiki/Extension:Mantle > [5] https://gerrit.wikimedia.org/r/129335 > [6] > https://git.wikimedia.org/tree/mediawiki%2Fcore.git/49f86a90520e6618c1e3044e3f29d5edeefc0657/resources%2Fsrc%2Fmediawiki.ui > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
