[Wikitech-l] Changes in the Contributors Team

[Trevor Parscal]

Wikimedia Developers,


With the change to a new annual plan and fiscal year, we’ve made some
changes to how the Contributors team, formerly known as the Editing
department, is organized. I believe these changes will help us better serve
our communities and make judicious use of donor funds, by making our teams
more capable of taking on large projects while maintaining production
software. I also believe these changes will better support for our staff by
helping many of them who have been wearing many hats for a long time
achieve greater focus.


The first and most significant change is that the Language and
Collaboration teams have merged to become the Global Collaboration team.
Runa Bhattacharjee, who has managed the Language team since 2014, will
manage the new combined team. Roan Kattouw, who has led and managed the
Collaboration team for the past two years, has now taken off his people
manager hat, and is now focused on being the Lead Engineer of the new team.
By merging, this new team will have the ability to incorporate engineering,
design, QA and community engagement more fluidly, meeting the specific
needs of each project and allowing team members to share their individual
expertise to a greater number of products.


Additionally, as Toby mentioned last month, the Dan Garry has joined the
team responsible for editing tools like VisualEditor, allowing James to
step away from his 5-year stint as the Product Manager for VisualEditor and
focus on leading product for Contributors. With this change comes a new
name for the VisualEditor team, which is now (back to being called) the
Editing team.


It will likely take some time for these changes to fully propagate through
all the wikis and development tools and many staff are currently in
transitional roles. If you have any questions about these changes, please
let me know and I’ll do my best to help you.


Thanks,

Trevor Parscal

-- 
- Trevor
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Please provide feedback on new discrimination and enforcement sections of Code of Conduct

[Trevor Parscal]

+1 Toby

I'd also like to express my continued support for this work. I believe in
ground-up projects, so I've always given staff space to work on them.
However, especially as the CoC becomes more mature and complete, If there's
anything more I can do to help, please let me know.

- Trevor

On Wednesday, March 16, 2016, Toby Negrin  wrote:

> Hi Matt --
>
> Thank you to you and the rest of the team for this important work. I really
> appreciate these updates and I'm looking forward to the finalized code of
> conduct.
>
> -Toby
>
> On Wednesday, March 16, 2016, Matthew Flaschen  >
> wrote:
>
> > Thanks for your participation in the recent Code of Conduct discussions.
> >
> > The "Marginalized and underrepresented groups" discussion had a lot of
> > feedback.  There was not consensus to use the exact original wording, but
> > many people expressed willingness to support a modified text.
> >
> > I've proposed such a new text, based on Neil P. Quinn's text, with a
> small
> > modification to account for discrimination required by law (e.g. age of
> > people who can sign certain contracts).
> >
> > Please participate at
> >
> https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#New_proposed_wording
> > .
> >
> > The "Enforcement issues" section received general support, but some of
> > that was conditional, or expressed preference for wording that developed
> > during the discussion.  The original wording also did not address the
> > appeals body, which was raised in the discussion.
> >
> > Please participate at
> >
> https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#Circumvention_text_new_wording
> >
> > Update regarding completed discussions:
> >
> > The "Clarification of legitimate reasons for publication of private
> > communications and identity protection" and "Definitions - trolling,
> > bad-faith reports" discussions have been closed.
> >
> > They both had support, and I've incorporated the text into the draft.
> >
> > Thanks,
> >
> > Matt
> >
> > ___
> > 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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Changes in Quarterly Planning

[Trevor Parscal]

As we approach another quarterly planning cycle, I'd like to bring my
proposal for how we can improve our quarterly planning and review process.

https://www.mediawiki.org/wiki/Wikimedia_Engineering/Goals_Proposal

Do people support implementing these changes for the Q4 planning cycle? If
you have input, could you please participate in the discussion on the talk
page by Feb 5 (next Friday)?

- Trevor
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] VisualEditor roadmap - extensibility within MediaWiki?

[Trevor Parscal]

VisualEditor is very extendable by design. You can do pretty much anything
you want with a plugin, and we've demonstrated this with many existing
plugins that provide all sorts of interesting features.

The APIs for adding features to VisualEditor, while perhaps not as well
documented as we'd like them to be, have existed for years and are now
quite stable.

We have seen extensions such as math, graph and score be integrated into
VisualEditor by developers who are relatively new to the code base.
However, direct communication with the team was still important to those
efforts.

The documentation that does exist is generated from code comments, and the
VisualEditor code base is particularly well documented. There was
a supplemental documentation effort for OOjs UI this time last year, and I
think that worked out pretty well. This may be something we can do in the
next six months, but there are not yet any concrete plans to do so.

Ed Sanders is a good person to be in touch with, along with others on the
VosualEditor team, who are easily reached on IRC. See the MediaWiki page on
VisialEditor for details.

- Trevor

On Thursday, January 21, 2016, Daniel Barrett  wrote:

> I was looking through the VisualEditor roadmap (
> https://www.mediawiki.org/wiki/VisualEditor/Roadmap) and did not notice
> anything about third-party MediaWiki extensions for the editor.   Did I
> miss it?
>
> I do see plans for "non-Mediawiki" extensions (under "Release for
> third-party non-MediaWiki users"), and also for Mediawiki admins to
> "easily install and use VisualEditor" (under "Release for third-party
> MediaWiki users"), but nothing about extending it within MediaWiki. For
> example, adding a button or menu item to insert a particular parser tag.
>
> Is this by design?
>
> I did notice "Non-template transclusions" on the roadmap, which looks like
> a way to insert parser tags & parser functions if you already know their
> name (the way template transclusions work right now). That will be a big
> help. However, for (say) inserting a given parser tag, it would be great if
> we could easily add a button or menu item for it.
>
> Thank you very much for any info.
> DanB
>
>
> ___
> 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

Re: [Wikitech-l] Sharing JS code between NodeJS and browser

[Trevor Parscal]

ResourceLoader is happy to ring files to the client from anywhere below the
base path you set when creating a file module. If that base path js the
root of the extension then you can just put the shared js code in a folder
accessible by both node.js and ResoriceLoader, maybe a /lib folder or
something.

Be careful when doing this with NPM modules, as their contents are subject
to change, and only their index file is configured and trying to
automatically know the paths and inclusion order is more of a mad science
than an art. Your best bet would be hard-coding and using very specific
versions in your package.json to protect from unexpected changes dues to
subtle NPM module version differences.

As for needing some $.extend, URL parsing and reconstructing, and logging.
I'm assuming you mean taking client code to the server where jQuery and
common browser functionally might not be present. There are many NPM
modules that provide shims for these things, including full-on server-side
jQuery. Usually the differences are subtle if any. Members of the Paraoid
team are very familiar with this space and are probably good people to talk
to about this.

- Trevor

On Friday, December 18, 2015, Yuri Astrakhan 
wrote:

> For JS gurus - what is the best way to share JavaScript library code
> between the NodeJS and browser?  The shared library will need to use
> $.extend()-like functionality, URL parsing and reconstructing, and logging.
>
> How should the code be organized? What are the recommended tools to
> automate the process?
>
> Thanks!
> ___
> 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

Re: [Wikitech-l] Image editor prototype

[Trevor Parscal]

I think right now we are scratching the surface. We have some big ideas
about everything from basic adjustments to full on derivative tracking
and non-detailed destructive image editing.

While we are prototyping and proving the concept, it's all really going to
come down to what features we can pull off easily and the community will
benefit from and embrace the most. And your case appears to cover both.

- Trevor

On Tuesday, December 8, 2015, Luis Villa  wrote:

> Very cool!
>
> Totally personal thing: a task I've done several times on-wiki is rotate an
> image by <90 degrees just to make it level (e.g., 1
> <
> https://commons.wikimedia.org/w/index.php?title=File%3ACoral_Gables_FL_Biltmore04.jpg&type=revision&diff=138202095&oldid=130094742
> >,
> 2
> <
> https://commons.wikimedia.org/w/index.php?title=File:Biblioteca_malatestiana,_ingresso_03.JPG&diff=prev&oldid=119816525
> >).
> Any chance that is in the roadmap?
>
> On Tue, Dec 8, 2015 at 1:08 PM, Mark Holmquist  >
> wrote:
>
> > Hi, all!
> >
> > I'm writing to share a prototype image editor that our very own Prateek
> > (prtksxna) has been working on. We're hoping to write an extension around
> > this and provide it on-wiki as a replacement for several bots and
> off-wiki
> > tools. It's only an experiment, but honestly, our upload pipeline lacks
> an
> > editing tool, which is *so* 2003. I'm looking towards getting this
> released
> > on Commons, as a BetaFeature™, within the next few months.
> >
> > Feedback can be shared here, on GitHub in the form of issues, on IRC in
> > #wikimedia-multimedia, or via private e-mail to myself or Prateek, if you
> > prefer.
> >
> > The code is here: https://github.com/prtksxna/ImageEditor
> >
> > You can try a demo here: http://prtksxna.github.io/ImageEditor/
> >
> > And finally, there's a sneak peek at the API documentation here:
> > http://prtksxna.github.io/ImageEditor/docs/index.html
> >
> > Thanks for your eyeballs and time!
> >
> > --
> > Mark Holmquist
> > Lead Engineer, Multimedia
> > Wikimedia Foundation
> > mtrac...@member.fsf.org 
> > http://marktraceur.info
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org 
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
>
> --
> Luis Villa
> Sr. Director of Community Engagement
> Wikimedia Foundation
> *Working towards a world in which every single human being can freely share
> in the sum of all knowledge.*
> ___
> 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

Re: [Wikitech-l] MW support for Composer equivalent for JavaScript packages

[Trevor Parscal]

The flat approach to NPM is a game changer for us, and a Bower killer.

Timo? Had a lot of insight at the time, I'd like to see him be invoked in
this decision. Any thoughts Timo?

- Trevor

On Thursday, November 5, 2015, Jon Robson  wrote:

> It's been a year now, over 3-6 months. Volker can this be given a
> priority in the next frontend standards meeting. I think the lack of
> any standard is extremely damaging to the project.
>
> On Wed, Jul 22, 2015 at 4:21 PM, Bryan Davis  > wrote:
> > On Wed, Jul 22, 2015 at 12:24 PM, Daniel Werner
> > > wrote:
> >> Hey,
> >>
> >> I just wanted to check in about the status of enabling JavaScript
> package
> >> management usage in MediaWiki. I am basically talking about an
> equivalent
> >> for JS to what we have with Composer for PHP.
> >>
> >> Real-world example:
> >>   The "data-values/value-view" package[0] is defining
> >> "jquery.event.special.eachchange.js":
> >> ValueView/lib/jquery.event/jquery.event.special.eachchange.js
> >>
> >>   Now, recently I needed the same functionality in one of my
> extensions, so
> >> I just copied it over. [1]
> >>
> >> I know that this is the worst way one could do this, but as far as I can
> >> see we don't have that much of a choice right now. Here are the
> alternative
> >> options I can see:
> >>
> >> Moving "jquery.event.special.eachchange.js" out of the
> >> "data-values/value-view" package into its own "WMDE/jquery-eachchange"
> >> package...
> >>
> >> 1. ... and using it in my extension via composer.
> >>   + pro: two or more extensions or other packages requiring this package
> >> will still result in having only one MW-wide installation..
> >>   - con: requires MW specific code which is actually not related to the
> >> MW-independent package to feed the resource loader.
> >>   - con: using Composer to manage pure JavaScript packages! Uuuh, ugly!
> >>
> >> 2. ... and having a build step in other packages using the package,
> pulling
> >> the "WMDE/jquery-eachchange" somewhere into the file structure of the
> >> packages/extensions using it.
> >>   + pro: don't need to abuse composer, we can use "npm", "Bower" or any
> >> other arbitrary JS package manager here.
> >>   - con: got to tell resource loader somehow... (didn't think so much
> about
> >> that yet)
> >>   - con: if more than one extensions or other packages require this
> package
> >> we still end up with the same code twice or more often in one MW
> >> installation.
> >>
> >> 3. Combining 1 and 2: Start with 2, using a JS package manager. Then
> going
> >> to 1, creating a composer package and pulling the
> "WMDE/jquery-eachchange"
> >> package in via some build script.
> >>   + pro: The two pros from 1 + 2
> >>   + pro: ^^
> >>   - con: still got to tell resource loader somehow...
> >>   - con: Overhead; We now create two packages where the Composer one is
> >> just a bridge to the MW-world, still polluting packagist.org. Still
> kind of
> >> ugly and more effort for publishing a package and therefore potentially
> >> scaring programmers away from doing so since they've got better things
> to
> >> do than doing work that could be automated.
> >>
> >> I have not seen Approach 2 and 3 yet. Though I could imagine that the
> >> VisualEditor team has used something like that.
> >> Approach 1 is the way the "data-values/value-view" package itself is
> being
> >> handled. And that package should actually be a MW independent pure JS
> >> package but right now it contains MW specific code and uses composer for
> >> distribution!
> >> There is still another option but that had to be properly implemented:
> >>
> >> 4. Choose one native JS package manager for now and go with it (add
> support
> >> for others later perhaps). Integrate it properly with MW (resource
> loader
> >> to begin with), document how to use it and finally distribute JS code
> >> coming from the MW world but useful for other projects in a way where it
> >> can actually be used in a non-MW context.
> >>
> >> This has already been bugging me when working on Wikidata. Now I'd like
> to
> >> reuse some of the code I have written there without spending hours and
> >> hours with option 3 because there should be support for option 4 rather
> >> sooner or later.
> >> So I am wondering; Does anyone have any thoughts, any alternatives
> perhaps
> >> or is there any roadmap on anything like the option 4 that I have shown?
> >>
> >> Cheers,
> >> Daniel
> >>
> >> [0]: https://packagist.org/packages/data-values/value-view
> >> [1]:
> >>
> https://github.com/DanweDE/mediawiki-ext-UserBitcoinAddresses/blob/master/resources/vendor/jquery.event.special.eachchange.js
> >
> > Option 4 was discussed last October as part of the Librarization
> > project [0]. At the time the front end standards group wasn't ready to
> > pick a winner in the javascript packaging landscape. They did want to
> > revisit that in 3-6 months however so maybe it is time to find someone
> > to look into the various options and their pros and 

Re: [Wikitech-l] Architecture Committee expansion

[Trevor Parscal]

+1

On Thursday, October 8, 2015, Tim Starling  wrote:

> In a recent meeting of the MediaWiki Architecture Committee, it was
> agreed that Timo Tijhof (Krinkle) would be invited to join the
> committee. Timo accepted this invitation.
>
> Timo is a talented software engineer with experience in many areas,
> especially the MediaWiki core and JavaScript frontend components such
> as ResourceLoader and VisualEditor. He currently works for WMF in the
> performance team. I look forward to working with him on the
> Architecture Committee.
>
> -- Tim Starling
>
>
> ___
> 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

[Wikitech-l] Collaboration Team Update

[Trevor Parscal]

Hi (and sorry for cross-posting)

I’d first like to say that I’m excited about Danny’s new role and the
positive impact I know he will have on the relatively new Community Tech
team, and that he will be missed in the Editing group. This change now
leaves an open position, which we are in the process of hiring a new
Product Manager to fill. There’s an open position posted.[1]

The Collaboration team, meanwhile, will continue their work to provide Flow
as an opt-in Beta feature, allowing contributors to use Flow on their user
talk page. This feature is currently available on MediaWiki.org, and will
be enabled on other wikis upon request. Especially as more users enable
Flow, the team will continue supporting users of the product by promptly
triaging and resolving bugs.

This quarter, which began yesterday, The Collaboration team will be
focusing on the development of cross-wiki notifications and other Echo
improvements. They’re also continuing to advance efforts to research and
prototype solutions for advanced editor workflows. Further feature
development on Flow discussion tools will be based on an assessment
following the 'workflows' research work, and on editor feedback at the
wikis already using Flow.[2]

Please ask any questions you may have on-wiki at
https://www.mediawiki.org/wiki/Talk:Flow to reduce fragmentation.

- Trevor

[1] https://boards.greenhouse.io/wikimedia/jobs/104264?t=k7xsjm
[2] https://www.mediawiki.org/wiki/Flow/Rollout
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] RFC: Replace Tidy with HTML 5 parse/reserialize

[Trevor Parscal]

Interesting. What is the cause of the slower speed?

- Trevor

On Tuesday, August 11, 2015, Gabriel Wicke  wrote:

> On Tue, Aug 11, 2015 at 5:16 PM, Trevor Parscal  >
> wrote:
>
> > Is it possible use part of the Parsoid code to do this?
> >
>
> It is possible to do this in Parsoid (or any node service) with this line:
>
>  var sanerHTML = domino.createDocument(input).outerHTML;
>
> However, performance is about 2x worse than current tidy (116ms vs. 238ms
> for Obama), and about 4x slower than the fastest option in our tests. The
> task has a lot more benchmarks of various options.
>
> Gabriel
>
>
>
>
>
> >
> > - Trevor
> >
> > On Tuesday, August 11, 2015, Tim Starling  > wrote:
> >
> > > I'm elevating this task of mine to RFC status:
> > >
> > > https://phabricator.wikimedia.org/T89331
> > >
> > > Running the output of the MediaWiki parser through HTML Tidy always
> > > seemed like a nasty hack. The effects on wikitext syntax are arbitrary
> > > and change from version to version. When we upgrade our Linux
> > > distribution, we sometimes see changes in the HTML generated by given
> > > wikitext, which is not ideal.
> > >
> > > Parsoid took a different approach. After token-level transformations,
> > > tokens are fed into the HTML 5 parse algorithm, a complex but
> > > well-specified algorithm which generates a DOM tree from quirky input
> > > text.
> > >
> > > http://www.w3.org/TR/html5/syntax.html
> > >
> > > We can get nearly the same effect in MediaWiki by replacing the Tidy
> > > transformation stage with an HTML 5 parse followed by serialization of
> > > the DOM back to HTML. This would stabilize wikitext syntax and resolve
> > > several important syntax differences compared to Parsoid.
> > >
> > > However:
> > >
> > > * I have not been able to find any PHP implementation of this
> > > algorithm. Masterminds and Ressio do not even attempt it. Electrolinux
> > > attempts it but does not implement the error recovery parts that are
> > > of interest to us.
> > > * Writing our own would be difficult.
> > > * Even if we did write it, it would probably be too slow.
> > >
> > > So the question is: what language should we use? Since this is the
> > > standard programmer troll question, please bring popcorn.
> > >
> > > The best implementation of this algorithm is in Java: the validator.nu
> > > parser is maintained by Mozilla, and has source translation to C++,
> > > which is used by Mozilla and could potentially be used for an HHVM
> > > extension.
> > >
> > > There is also a Rust port (also written by Mozilla), and notable
> > > implementations in JavaScript and Python.
> > >
> > > For WMF, a Java service would be quite easily done, and I have
> > > prototyped it already. An HHVM extension might also be possible. A
> > > non-service fallback for small installations might be Node.js or a
> > > compiled binary from Rust or C++.
> > >
> > > -- Tim Starling
> > >
> > >
> > > ___
> > > 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
> >
>
>
>
> --
> Gabriel Wicke
> Principal Engineer, Wikimedia Foundation
> ___
> 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

Re: [Wikitech-l] RFC: Replace Tidy with HTML 5 parse/reserialize

[Trevor Parscal]

Is it possible use part of the Parsoid code to do this?

- Trevor

On Tuesday, August 11, 2015, Tim Starling  wrote:

> I'm elevating this task of mine to RFC status:
>
> https://phabricator.wikimedia.org/T89331
>
> Running the output of the MediaWiki parser through HTML Tidy always
> seemed like a nasty hack. The effects on wikitext syntax are arbitrary
> and change from version to version. When we upgrade our Linux
> distribution, we sometimes see changes in the HTML generated by given
> wikitext, which is not ideal.
>
> Parsoid took a different approach. After token-level transformations,
> tokens are fed into the HTML 5 parse algorithm, a complex but
> well-specified algorithm which generates a DOM tree from quirky input
> text.
>
> http://www.w3.org/TR/html5/syntax.html
>
> We can get nearly the same effect in MediaWiki by replacing the Tidy
> transformation stage with an HTML 5 parse followed by serialization of
> the DOM back to HTML. This would stabilize wikitext syntax and resolve
> several important syntax differences compared to Parsoid.
>
> However:
>
> * I have not been able to find any PHP implementation of this
> algorithm. Masterminds and Ressio do not even attempt it. Electrolinux
> attempts it but does not implement the error recovery parts that are
> of interest to us.
> * Writing our own would be difficult.
> * Even if we did write it, it would probably be too slow.
>
> So the question is: what language should we use? Since this is the
> standard programmer troll question, please bring popcorn.
>
> The best implementation of this algorithm is in Java: the validator.nu
> parser is maintained by Mozilla, and has source translation to C++,
> which is used by Mozilla and could potentially be used for an HHVM
> extension.
>
> There is also a Rust port (also written by Mozilla), and notable
> implementations in JavaScript and Python.
>
> For WMF, a Java service would be quite easily done, and I have
> prototyped it already. An HHVM extension might also be possible. A
> non-service fallback for small installations might be Node.js or a
> compiled binary from Rust or C++.
>
> -- Tim Starling
>
>
> ___
> 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

Re: [Wikitech-l] MediaWiki, as seen on TV

[Trevor Parscal]

Seeing ResourceLoader calls on CSI makes that whole project finally worth
it.

- Trevor

On Sun, May 24, 2015 at 10:06 PM, Steven Walling 
wrote:

> There's a pretty hilarious American police procedural TV show in 2015
> called "CSI: Cyber", featuring mostly cybercrime. Obviously they have to
> dredge up snippets of code from places for screenshots on the show.
>
> Episode 4 happened to include a tidbit from MediaWiki 1.25/wmf3. Supposedly
> the code was a hack to make your printer blow up.
>
> Original lulz and screenshots via
>
> http://moviecode.tumblr.com/post/114815574587/this-is-from-csi-cyber-s01e04-according-the-the
> ___
> 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

Re: [Wikitech-l] Multimedia team?

[Trevor Parscal]

I think the scope is multimedia contribution and curation. We will be
working with the reading and search teams to improve the presentation and
discoverability if media items.

The scalers are in between, we need them for both presentation and
contribution pipelines. For the time being I'm anticipating this landing on
the editing side.

- Trevor

On Wednesday, May 13, 2015, Brian Wolff  wrote:

> On 5/13/15, Trevor Parscal > wrote:
> > The team has some hires, and there will be some needed focus on hiring at
> > least some of them as backend/MediaWiki core engineers. This is mostly
> > because we acknowledge the sizable backlog of tasks in that area as well
> as
> > the need to make improvements in that area to support future work.
> >
> > I'll likely look to The Performance team to help with HHVM related
> > activities as well.
> >
> > - Trevor
>
> So this is probably a good time to ask. What is the scope of the
> current Multimedia team. Are they responsible for literally every
> multimedia related thing, or just stuff related to "editing" (they're
> in the "editing" department after all), or somewhere in the middle
>
> --bawolff
>
> ___
> 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

Re: [Wikitech-l] Multimedia team?

[Trevor Parscal]

The team has some hires, and there will be some needed focus on hiring at
least some of them as backend/MediaWiki core engineers. This is mostly
because we acknowledge the sizable backlog of tasks in that area as well as
the need to make improvements in that area to support future work.

I'll likely look to The Performance team to help with HHVM related
activities as well.

- Trevor

On Wednesday, May 13, 2015, Giuseppe Lavagetto 
wrote:

> While I know that doesn't sound fancy or attractive, I think the
> multimedia team should have as one of its focuses to help with
> transitioning to HHVM the imagescalers. There seem to be a few issues
> with that and some support that won't just come out of goodwill, but
> as a team commitment, would greatly help with that.
>
> Cheers,
> Giuseppe
>
> On Mon, May 11, 2015 at 4:33 PM, Brian Gerstle  > wrote:
> > I'm also curious what our audio/video storage/transcoding/playback
> roadmap
> > is.  IMO it's a pretty fundamental feature that isn't well supported in
> all
> > the clients (especially mobile).  Could probably do some interesting
> audio
> > stuff (e.g. narration in many languages) for visually impaired.
> >
> > On Mon, May 11, 2015 at 7:42 AM, Jean-Frédéric <
> jeanfrederic.w...@gmail.com >
> > wrote:
> >
> >> 2015-05-11 10:29 GMT+01:00 Antoine Musso  >:
> >>
> >> > On 11/05/15 02:18, Tim Starling wrote:
> >> >
> >> >> On 10/05/15 07:06, Brian Wolff wrote:
> >> >>
> >> >>> >People have been talking about vr for a long time. I think there is
> >> more
> >> >>> >pressing concerns (e.g. video). I suspect VR will stay in the video
> >> game
> >> >>> >realm  or gimmick realm for a while yet
> >> >>>
> >> >> Maybe VR is a gimmick, but VRML, or X3D as it is now called, could be
> >> >> a useful way to present 3D diagrams embedded in pages. Like SVG, we
> >> >> could use it with or without browser support.
> >> >>
> >> >
> >> > Hello,
> >> >
> >> > A potential use case for the encyclopedia, would be to display models
> of
> >> > chemistry molecules. An example:
> >> >
> >> >   http://wiki.jmol.org/index.php/Jmol_MediaWiki_Extension
> >> >
> >>
> >> See  and <
> >> https://phabricator.wikimedia.org/project/profile/804/>
> >>
> >> --
> >> Jean-Frédéric
> >> ___
> >> Wikitech-l mailing list
> >> Wikitech-l@lists.wikimedia.org 
> >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >>
> >
> >
> >
> > --
> > EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
> > IRC: bgerstle
> > ___
> > 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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Multimedia team?

[Trevor Parscal]

There is a Multimedia team under Editing, and it includes Mark Holmquist of
the former Multimedia team as to lead engineer. The teams roadmap is in the
works, but 3D is something that's been coming up a lot lately, so the team
should be able to at least make some plans around figuring it out pretty
soon.

- Trevor

On Saturday, May 9, 2015, Brian Wolff  wrote:

> Im told the multimedia team got undisbanded and now is part of editing
> department.
>
> People have been talking about vr for a long time. I think there is more
> pressing concerns (e.g. video). I suspect VR will stay in the video game
> realm  or gimmick realm for a while yet
>
> --bawolff
> On May 9, 2015 2:31 PM, "Pine W" >
> wrote:
> >
> > As a part of the engineering reorganization, will there be a multimedia
> > team within the readeship or power users groups? For some time I have
> been
> > hoping to get Wikipedia the ability to provide interactive
> visualizations.
> >
> > Also, this article[1] suggests that VR may see widespread adoption in the
> > next few years, and a multimedia team could capitalize on the trend.
> >
> > Pine
> >
> > [1] http://www.bbc.com/news/technology-30924022
> > ___
> > 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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] OOjs UI 0.10.0 Release

[Trevor Parscal]

Hey all,

OOjs UI 0.10.0 was released on Wednesday. It will be in MW from 1.26wmf4+.
As there are several breaking changes, please look carefully over them to
determine if they affect your code.

Breaking changes since last release:

   - [BREAKING CHANGE] ButtonWidget: remove deprecated nofollow option
   alias (C. Scott Ananian)

This was deprecated in v0.8.0, at which point it was already unused as far
as we are aware. The real config option, "noFollow" (with a capital 'F')
continues to work as before.


   - [BREAKING CHANGE] Convert ToggleWidget from a mixin to an abstract
   class (Bartosz Dziewoński)

This is only technically a breaking change; the interface and behaviour of
the widgets built on top of ToggleWidget are unchanged.


   - [BREAKING CHANGE] MenuLayout: Reimplement without inline styles
   (Bartosz Dziewoński)

Menu size can be set using CSS now. MenuLayout's CSS will override the
appropriate values with 'auto' or '0' to display the menu correctly. If
`menuPosition` is known beforehand, CSS rules corresponding to other
positions may be omitted. This was a bit of a mess (and only used by one
consumer, already fixed). The behaviour of the 'showMenu' and
'menuPosition' configuration options is unchanged.


Additional details are in the full change log. If you have any further
questions or need help dealing with deprecations, please let me know. As
always, general library documentation is available at mediawiki.org and
generated code-level documentation at doc.mediawiki.org.

- Trevor
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] "For the Sake of Simplicity"

[Trevor Parscal]

I'm a fan of removing features when the feature is not currently done well
and we aren't going to do it well anytime soon, if ever. Products with
fewer high quality features are superior in many ways to products with many
low quality features.

- Trevor

On Wednesday, April 22, 2015, Stas Malyshev  wrote:

> Hi!
>
> > This leads to an interesting marketing possibility, and one that I have
> > seen in action only a few times: the idea that a subsequent release of a
> > product might be smaller or have fewer features than the previous
> version,
> > and that this property should be considered a selling point. Perhaps the
> > market is not mature enough to accept it yet, but it remains a promising
> > and classic ideal — less is more.
>
> Apple is doing it from time to time, and is not shy about it. I'm not
> sure I personally am a big fan, but it works for many people.
>
> Another interesting take on the same topic from ESR:
> http://esr.ibiblio.org/?p=6737
>
> --
> Stas Malyshev
> smalys...@wikimedia.org 
>
> ___
> 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

Re: [Wikitech-l] VisualEditor support for table copy-and-paste from Word

[Trevor Parscal]

Pine,

I'm glad to hear VE had your back. This actually reminds me, there's a
feature we never really advertised in VisualEditor where a CSV file can be
dragged into the editor and a table is created from its contents.

Give it a try. And thank Ed Sanders for all things tables and Copy/Paste.

- Trevor

On Wednesday, April 15, 2015, Amir E. Aharoni 
wrote:

> Hear hear.
>
> The VE people's amazing wizardry deserves praise.
>
>
> --
> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> http://aharoni.wordpress.com
> ‪“We're living in pieces,
> I want to live in peace.” – T. Moore‬
>
> 2015-04-15 11:05 GMT+03:00 Pine W >:
>
> > James,
> >
> > I just want to say a public "thank you" for VE saving my sanity by doing
> > something that I didn't know was possible. I was able to copy a table
> from
> > Word onto Meta using VisualEditor, and much to my surprise it mostly
> > worked. I must have tried at least five other ways to get one of Cascadia
> > Wikimedians' annual plan tables copied from Google Docs onto Meta, all
> with
> > poor results. While VisualEditor only copied part of the formatting into
> > MediaWiki, the results were far better than anything else I had tried for
> > the past few hours. So thank you very much for supporting this
> > copy-and-paste functionality with VisualEditor.
> >
> > Pine
> >
> > *This is an Encyclopedia* 
> >
> >
> >
> >
> >
> >
> > *One gateway to the wide garden of knowledge, where lies The deep rock of
> > our past, in which we must delve The well of our future,The clear water
> we
> > must leave untainted for those who come after us,The fertile earth, in
> > which truth may grow in bright places, tended by many hands,And the broad
> > fall of sunshine, warming our first steps toward knowing how much we do
> not
> > know.*
> >
> > *—Catherine Munro*
> > ___
> > 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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] OOjs UI 0.9.0 Release

[Trevor Parscal]

OOjs UI 0.9.0 was released on Wednesday. It will be in MW from 1.25wmf21+.
As there are several breaking changes, please look carefully over them to
determine if they affect your code.

*Breaking changes since last release:*

   - [BREAKING CHANGE] Remove innerOverlay (Ed Sanders)

We've tagged this as a breaking change, but this was an internal-only
feature that we never made part of the public API. We no longer use it
since the removal of iframe support in v0.7.0.


   - [BREAKING CHANGE] TextInputWidget: Remove 'icon' and 'indicator'
   events (Bartosz Dziewoński)

Deprecated in v0.8.0, at which point they were already unused as far as we
are aware.


   - [BREAKING CHANGE] Remove deprecated LookupInputWidget (Bartosz
   Dziewoński)

Deprecated in v0.6.3, at which point they were already unused as far as we
are aware.


   - [BREAKING CHANGE] Remove deprecated GridLayout (Bartosz Dziewoński)

Deprecated in v0.7.0, at which point they were already unused as far as we
are aware.


*Deprecation changes since last major release:*

   - [DEPRECATING CHANGE] Rename setPosition to setLabelPosition (Ed
   Sanders)

This function in TextInputWidget is probably only used privately on
intialise,  so it's unlikely to be a breaking change in the real world, but
flagging here.


Additional details are in the full change log
. If you
have any further questions or need help dealing with deprecations, please
let me know. As always, general library documentation is available at
mediawiki.org  and generated code-level
documentation at doc.mediawiki.org
.

- Trevor
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] OOjs UI 0.8.0 release

[Trevor Parscal]

OOjs UI 0.8.0 has been released today. It will be in MW from 1.25wmf19+.

*Breaking changes since last release:*


   - [BREAKING CHANGE] Make default distribution provide SVG with PNG
   fallback (Bartosz Dziewoński)

We've tagged this as a breaking change, but the only breakage is renaming
the stylesheet files. This will only "break" for systems which are
responsible for importing the library. This is fixed for MediaWiki and
for VisualEditor
standalone; no other users should be affected.

As part of this change, from MediaWiki 1.25wmf19 onwards, OOjs UI will
provide raster icon fallbacks for the vector icons, which we were
previously not using.


*Deprecations since last major release:*

   - DEPRECATION: TextInputWidget: Deprecate 'icon' and 'indicator' events
   (Bartosz Dziewoński)

The functionality they expose (user clicking on the icon/indicator) is
fundamentally not accessible: the icon/indicator is not focusable (has no
tabindex), has no keyboard events, doesn't have a label associated or a
tooltip, and has no sensible way of fixing all of this. If something needs
to be clickable separately, it should probably be a separate Widget with
the appropriate mixins added.


   - DEPRECATION: ButtonWidget: Rename nofollow config option to noFollow (C.
   Scott Ananian)

We're switching this feature (added just last release) to use consistent
camel case. The old `nofollow` property still works for backward
compatibility, but it is deprecated and will be removed in the next major
release but one.


If you have any further questions or need help dealing with
deprecations, please
let me know. General library documentation is available at mediawiki.org
 and generated code-level
documentation at doc.mediawiki.org
.

- Trevor
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Boil the ocean, be silly, throw the baby out with bathwater, demolish silos, have fun

[Trevor Parscal]

We really need to just evolve Vector. It's not a sacred cow, and it's sort
of sad how little it's been changed since I made in back in 2009. How it
looks, how it works and how it responds to different devices can all be
changed incrementally, and we can do this without continued or additional
fragmentation.

I appreciate that the mobile skin (Minerva) forged ahead, but it did this
by ignoring certain problems that the desktop skin has to solve for. Now
that we've learned some things about supporting mobile, we should be
integrating that work back into our primary and existing user interface,
effectively merging them back together.

- Trevor

On Fri, Feb 13, 2015 at 2:30 PM, Risker  wrote:

> On 13 February 2015 at 17:25, Max Semenik  wrote:
>
> > On Fri, Feb 13, 2015 at 2:23 PM, Risker  wrote:
> > >
> > > Help me out here. Why does anyone care that the article was last edited
> > 13
> > > days ago by Omeganian?  And even if they do, why is that the very first
> > > thing that someone sees?
> > >
> >
> > See the part about improvements.
> >
> >
> Well, see.  It seems to me that the old-time theory of "let's just stick it
> up and fix it when we get around to it" has pretty much been deprecated in
> the last couple of years.
>
> Risker/Anne
> ___
> 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

Re: [Wikitech-l] OOjs and OOjs UI for on-wiki gadgets

[Trevor Parscal]

On Fri, Feb 13, 2015 at 12:59 AM, Ricordisamoa  wrote:

>
> the overflow of the lookup menu is now clipped by the dialog :-/
>

Could you please add a bug to phabricator with reproduction steps?

Thanks,
Trevor
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] OOjs UI 0.7.0 release

[Trevor Parscal]

*OOjs UI 0.7.0* has been released today. It will be in MW from 1.25wmf18+.

We've tried hard to avoid breaking changes when possible, but occasionally
they will happen. The last time there were breaking changes in a release
was 2014-12-16 (wmf13), 137 OOjs UI commits ago.

*Breaking changes since last release:*

   - [BREAKING CHANGE] Remove window isolation (Trevor Parscal)

Window isolation is a feature we introduced to solve certain problems in
VisualEditor a while back. It essentially places the content of a window
inside an iframe. We've since made improvements to VisualEditor to no
longer need this, and are happy to finally be able to remove this rather
problematic part of OOjs UI. We are not aware of anyone using this feature,
so it should have no effect on code in production.


We are also trying to make it easier on users of the library to stay up to
date more proactively by publicizing deprecations for at least one release
cycle before a related breaking change occurs.

*Deprecated changes since last major release:*

   - DEPRECATION: GridLayout should no longer be used, instead use
   MenuLayout (Bartosz Dziewoński)

GridLayout is a 2D proportional grid container that turned out to be
difficult to have features we didn't need and lacked many we did need. The
only uses of GridLayout have been removed, and we are planning to remove it
in an upcoming release. The shiny new MenuLayout is a much simpler
solution, providing a 2-pane split layout that is better suited to the
needs we actually have.


   - DEPRECATION: LookupInputWidget should no longer be used, instead use
   LookupElement (Bartosz Dziewoński)

In response to some feedback about using LookupInputWidget being complex
and inflexible, we've changed strategies and are now providing lookup
behavior through a mixin called LookupElement.


Also, I'd especially like to thank the volunteers and early-adopters who
contributed to this release.

   - C. Scott Ananian
   - Derk-Jan Hartman
   - Ricordisamoa
   - eranroz

If you have any further questions or need help dealing with deprecations,
please let me know. General library documentation is available at
mediawiki.org <https://www.mediawiki.org/wiki/OOjs_UI> and generated
code-level documentation at doc.mediawiki.org
<https://doc.wikimedia.org/oojs-ui/master/#!/api>.

- Trevor
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Thank you for listening (@ the Developer Summit)

[Trevor Parscal]

Today I had the *fun* job of presenting and answering questions for 2 hours
and 15 minutes straight. I didn't actually realize this would turn out to
be the marathon that it did, but I feel like it turned out better than
expected. I was especially impressed with the positive attitude that
everyone had as they challenged my viewpoints and patiently heard me out.

Thank you to those willing to spar with me from across the room over
microphones. I really value people who question authority in search for the
right answer. I felt proud today to work at a place where rigorous public
debate is still alive and well.

Also thank you to Jarred, Roan, Ed and Timo for taking some of the
questions, allowing me shut up for a bit.

- Trevor
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The future of shared hosting

[Trevor Parscal]

I challenge the very foundation of arguments based on this 95% statistic.

The 95% statistic is bogus, not because it's inaccurate, but because it's
misleading.

The number of MediaWiki instances out there is meaningless. The value we
get from 3rd party use correlates much more strongly with the number of
users, not the number of instances.

Consider the experience of using a MediaWiki instance running on a shared
host. MediaWiki doesn't actually perform well enough in this environment to
support a significant amount of usage. It's simply not possible that shared
host installs can achieve enough usage to be relevant.

- Trevor

On Fri, Jan 16, 2015 at 10:21 AM, Ryan Schmidt  wrote:

>
>
> > On Jan 16, 2015, at 11:27 AM, Ryan Lane  wrote:
> >
> >> On Fri, Jan 16, 2015 at 4:29 AM, David Gerard 
> wrote:
> >>
> >>> On 16 January 2015 at 07:38, Chad  wrote:
> >>>
> >>> These days I'm not convinced it's our job to support every possible
> >>> scale of wiki install. There's several simpler and smaller wiki
> solutions
> >>> for people who can't do more than FTP a few files to a folder.
> >>
> >>
> >> In this case the problem is leaving users and their wiki content
> >> unsupported. Because they won't move while it "works", even as it
> >> becomes a Swiss cheese of security holes. Because their content is
> >> important to them.
> >>
> >> This is the part of the mission that involves everyone else producing
> >> the sum of human knowledge. They used our software, if we're
> >> abandoning them then don't pretend there's a viable alternative for
> >> them. You know there isn't.
> > What you're forgetting is that WMF abandoned MediaWiki as an Open Source
> > project quite a while ago (at least 2 years ago). There's a separate org
> > that gets a grant from WMF to handle third party use, and it's funded
> just
> > well enough to keep the lights on.
> >
> > Take a look at the current state of MediaWiki on the internet. I'd be
> > surprised if less than 99% of the MediaWiki wikis in existence are out of
> > date. Most are probably running a version from years ago. The level of
> > effort required to upgrade MediaWiki and its extensions that don't list
> > compatibility with core versions is past the skill level of most people
> > that use the software. Even places with a dedicated ops team find
> MediaWiki
> > difficult to keep up to date. Hell, I find it difficult and I worked for
> > WMF on the ops team and have been a MediaWiki dev since 1.3.
> >
> > I don't think adding a couple more services is going to drastically alter
> > the current situation.
> >
> > - Ryan
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> This sounds like a problem we need to fix, rather than making it worse.
> I'd most wikis are not up to date then we should work on making it easier
> to keep up to date, not making it harder. Any SOA approach is sadly DOA for
> any shared host; even if the user has shell access or other means of
> launching processes (so excluding almost every free host in existence
> here), there is no guarantee that a particular environment such as node.js
> or Python is installed or at the correct version (and similarly no
> guarantee for a host to install them for you). Such a move, while possibly
> ideal for the WMF, would indeed make running on shared hosting nearly if
> not entirely impossible. The net effect is that people will keep their
> existing MW installs at their current version or even install old versions
> of the software so they can look like Wikipedia or whatnot, rife with
> unpatched security vulnerabilities. I cannot fathom that the WMF would be
> ok with leaving third-party users in such a situation.
>
> Moving advanced things into services may make sense, but it should not
> come at the expense of making the core worthless for third parties;
> sensible refactors could still be done on core while leaving it as pure
> PHP. Services, if implemented, should be entirely optional (as an example,
> Parsoid is not required to have a base working wiki. I would like to stick
> to that model for any future service as well).
>
> Regards,
> Ryan Schmidt
>
>
>
> ___
> 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

Re: [Wikitech-l] Fwd: No more Architecture Committee?

[Trevor Parscal]

It's really exciting to see people let go of unnecessary authority,
dismantle bureaucracy and resist building empires. I applaud the restraint
the committee is using here. I think it speaks volumes about who they are
as leaders.

As Brion suggests, it's important to retain the "idea of getting some active
people to talk to each other regularly and go over stuff". I look forward
to supporting grass-roots efforts to achieve just that.

- Trevor

On Fri, Jan 16, 2015 at 10:01 AM, Brion Vibber 
wrote:

> Rob, thanks for starting this discussion!
>
> We definitely should be thinking about what kind of structures make sense;
> the arch committee was a good "spike solution" which I think we've
> determined doesn't quite work as it is, but the core idea of getting some
> active people to talk to each other regularly and go over stuff is a good
> impulse we should not discard!
>
> I'm currently in the process of disentangling myself from other projects
> (we've got some awesome stuff coming up in the mobile apps!) to concentrate
> more on MediaWiki core, so ideas about modifying or adding to that
> structure are very welcome now.
>
>
> In general, I feel a sense of urgency that seems lacking in the status
> > quo.  We've made progress over the past couple of years, but it
> > doesn't feel like our progress is entirely up to the task.  We have a
> > collection of *many* instances of individual or small team excellence
> > that are sadly the mere sum of their parts.  My intuition is that we
> > lose out on multiplicative effects as we fail to engage the wider
> > group in our activities, and as we lack engineering-level
> > orchestration.  Team-level pride in fantastic work drifts into
> > project-level despair, as many excellent engineers fail to grasp how
> > to make big changes outside of their limited domains.
> >
>
> ^ This.
>
> I think it's getting time to plan more aggressively for the future and work
> towards our goals with a shared vision. That's a tall order, of course, but
> I think we can make some ideas go around...
>
> -- brion
>
>
> On Thu, Jan 15, 2015 at 8:04 PM, Rob Lanphier  wrote:
>
> > (Alright...let's try this again!)
> >
> > Hi everyone,
> >
> > The current MediaWiki Architecture Committee[1] has its roots in a
> > 2013 Amsterdam Hackathon session[2], where we had a pair of sessions
> > to try to establish our architectural guidelines[3].  It was there
> > that we agreed that it would be good to revive our then moribund
> > process for reviewing RFCs[4].  Since no one there really knew whose
> > job it was to review these things, I believe I said "how about we
> > start with everyone with 'architect' in their title at WMF?", which
> > was met with uncomfortable shrugging that I interpreted as
> > "consensus!", and no one corrected me.  Thus Brion Vibber, Mark
> > Bergsma, and Tim Starling became the founding members of the Arch
> > Committee.
> >
> > Subsequent to that meeting, I pretended to proceed as though a
> > decision was made.  However, over the past year and half since then,
> > there's been much more uncomfortable shrugging.  Even Brion, Mark, and
> > Tim have not seemed entirely comfortable with the idea.  It was widely
> > acknowledged that the group was heavily biased toward the lower parts
> > of our server software stack.  The committee agreed to add Roan
> > Kattouw and Daniel Kinzler to the group as a means of providing a
> > wider perspective, with the added bonus of adding at least one person
> > who isn't a WMF employee.
> >
> > So, here we are today.  I believe no one would dispute the credentials
> > of every member of the group.  Brion, Tim, and Mark have an extremely
> > long history with the project, being employees #1, #2, and #3 of the
> > WMF respectively, and all having contributed massively to the success
> > of Wikipedia and to MediaWiki as general purpose wiki software.  In
> > most open source projects, one of them would probably be BFDL[5].
> > Roan and Daniel are more "recent", but only in relative terms, and
> > also have very significant contributions to their name.  All have the
> > widespread respect of pretty much everyone in the MediaWiki developer
> > community.
> >
> > Additionally, I hear quite a bit of relief that the previously
> > moribund RFC process is doing much better now.  Things are moving, and
> > if you know how to work the process and aren't proposing anything too
> > wild, you can get an RFC approved pretty quickly.  The committee has
> > made a lap through the entire backlog of RFCs.
> >
> > Still, the uncomfortable shrugging continues.  The group is broader,
> > but still lacks the breadth, particularly in front end and in the
> > development of newer services such as Parsoid and RESTBase.  This
> > aspect is pretty obviously something that can be fixed.  Another
> > problem is that the scope of the group isn't clear to everyone.  Is
> > this group responsible for leading, or merely responsible for
> > reviewing big ideas from others t

Re: [Wikitech-l] The future of shared hosting

[Trevor Parscal]

95% is pretty extreme.

I have always questioned the balance being struck here, and would welcome
an adjustment of the minimum requirements to run MediaWiki. In many cases,
if we can just require shell access we can automate away the complexity for
the typical use cases.

- Trevor

On Thu, Jan 15, 2015 at 10:49 PM, Max Semenik  wrote:

> On Thu, Jan 15, 2015 at 10:38 PM, Bryan Davis  wrote:
>
> >
> > One of the bigger questions I have about the potential shift to
> > requiring services is the fate of shared hosting deployments of
> > MediaWiki. What will happen to the numerous MediaWiki installs on
> > shared hosting providers like 1and1, Dreamhost or GoDaddy when running
> > MediaWiki requires multiple node.js/java/hack/python stand alone
> > processes to function? Is the MediaWiki community making a conscious
> > decision to abandon these customers? If so should we start looking for
> > a suitable replacement that can be recommended and possibly develop
> > tools to easy the migration away from MediaWiki to another monolithic
> > wiki application? If not, how are we going to ensure that pure PHP
> > alternate implementations get equal testing and feature development if
> > they are not actively used on the Foundation's project wikis?
> >
> >
> This is not even about shared hostings: it is pretty obvious that running a
> bunch of heterogenous services is harder than just one PHP app, especially
> if you don't have dedicated ops like we at WMF do. Therefore, the question
> is: what will we gain and what will we lose by making MediaWiki unusable by
> 95% of its current user base?
>
>
> --
> Best regards,
> Max Semenik ([[User:MaxSem]])
> ___
> 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

Re: [Wikitech-l] Stance on Social Media

[Trevor Parscal]

In my opinion, we've been at odds with social media because...

   1. social media contributions are rarely the kinds of contributions we
   desire and;
   2. social media websites often operate in ways that conflict with our
   values and;
   3. social media behaviors are not often seen has helpful to our mission.

I've not yet heard a persuasive idea about how we can integrate with, or
become more similar to, social media sites that overcomes these issues. But
I do intend to remain open minded.

- Trevor

On Fri, Jan 9, 2015 at 12:07 PM, Daniel Friesen 
wrote:

> On 2015-01-09 11:59 AM, Strainu wrote:
> > 2015-01-09 21:24 GMT+02:00 Rob Moen :
> >> Currently our approach on social media is that "Social media websites
> >> aren't useful for spreading news and reaching out to potential users and
> >> contributors." [1]
> > Actually, this seems like vandalism. See [5] for (what I believe to
> > be) the original content.
> >
> > Why would we have dozens of social media accounts if we thought they
> > are useless?
> >
> > Strainu
> >
> > [5]
> https://www.mediawiki.org/w/index.php?title=Social_media&oldid=999236
> DroneOfTheWiki made 2 vandalism edits, NicoV undid one
> <
> https://www.mediawiki.org/w/index.php?title=Social_media&diff=prev&oldid=1041046
> >
> but missed the other
> <
> https://www.mediawiki.org/w/index.php?title=Social_media&diff=prev&oldid=1039082
> >.
>
> I undid the remaining vandalism edit.
>
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
>
> ___
> 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

Re: [Wikitech-l] MediaWiki Architecture Committee updates

[Trevor Parscal]

+1

Roan doesn't architect software, software architects Roan.

- Trevor

On Wed, Oct 22, 2014 at 2:56 PM, Ori Livneh  wrote:

> On Wed, Oct 22, 2014 at 1:17 PM, Brion Vibber 
> wrote:
>
> > Hey all --
> >
> > Announcement time!
> >
> > The MediaWiki Architecture Committee has added two members by provisional
> > internal consensus:
> > * Roan Kattouw, Wikimedia Foundation (visual editor & core)
> > * Daniel Kinzler, Wikimedia Deutschland
> >
>
> Congrats to both, and really -- congrats to us for having people of that
> caliber around. I think they're the right people for the job.
> ___
> 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

Re: [Wikitech-l] [WikimediaMobile] OOjs, MobileFrontend and Flow

[Trevor Parscal]

Jon, this is really awesome. I'm excited to be sharing more code.

I'll be taking a look at these patches with Roan today.

- Trevor

On Fri, Sep 12, 2014 at 11:43 AM, Tomasz Finc  wrote:

> On Fri, Sep 12, 2014 at 11:32 AM, Jon Robson 
> wrote:
> > After this is done it would be good to sit down and document ways we
> > can make better use of OOJS in mobile.
>
> Are you thinking of retooling existing features/infrastructure to use
> it first or making this a requirement for new features?
>
> This sounds like a good discussion to have during the quarterly
> planning but I certainly think we shouldn't wait that long to do it.
>
> --tomasz
>
> ___
> 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

Re: [Wikitech-l] [WikimediaMobile] The future of skins

[Trevor Parscal]

Someone in the meeting also claimed that Swig and Twig were compatible, and
that does appear to be generally true, but I think there are some
deviations.

- Trevor


On Wed, Aug 27, 2014 at 1:39 PM, Juliusz Gonera 
wrote:

> Someone in one of our meetings mentioned that Twig is a PHP
> implementation of Mustache. This doesn't seem to be the case though.
> We need a templating solution that works both on the server and the
> client.
>
> On Tue, Aug 26, 2014 at 5:21 PM, Trevor Parscal 
> wrote:
> > Thanks for summarizing the meeting Jon.
> >
> > So, let's get Twig/Swig into core then, eh? :)
> >
> > - Trevor
> >
> >
> > On Tue, Aug 26, 2014 at 3:53 PM, Jon Robson 
> wrote:
> >>
> >> Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and
> >> talked about the future of skins. Hopefully this mail summarises what
> >> we talked about and what we agreed on. Feel free to add anything, or
> >> ask any questions in the likely event that I've misinterpreted
> >> something we talked about or this is unclear :)
> >>
> >> Specifically we talked about how we are unhappy with how difficult it
> >> currently is for developers to create a skin. The skin class involves
> >> too many functions and does more than a skin should do e.g. manage
> >> classes on the body, worry about script tags and style tags.
> >>
> >> Trevor is going to create a base set of widgets, for example a list
> >> generator to generate things like a list of links to user tools. The
> >> widgets will be agnostic to how they are rendered - some may use
> >> templates, some may not.
> >>
> >> We identified the new skin system will have two long term goals:
> >> 1) We would like to get to the point where a new skin can be built by
> >> simply copying and pasting a master template and writing a new css
> >> file.
> >> 2) Should be possible for us in future to re-render an entire page via
> >> JavaScript and using the modern history push state re-render any page
> >> via the API. (Whether we'd want to do this is another consideration
> >> but we would like to have an architecture that is powerful enough to
> >> support such a thing)
> >>
> >> As next steps we agreed to do the following:
> >>
> >> 1) Trevor is going to build a watch star widget on client and server.
> >> We identified that the existing watch star code is poorly written and
> >> has resulted in MobileFrontend rewriting it. We decided to target this
> >> as it is a simple enough example that it doesn't need a template. It's
> >> small and contained enough that we hope this will allow us to share
> >> ideas and codify a lot of those. Trevor is hoping to begin working on
> >> this the week of the 2nd September.
> >>
> >> 2) We need a templating system in core. Trevor is going to do some
> >> research on server side templating systems. We hope that the
> >> templating RFC [1] can get resolved however we are getting to a point
> >> that we need one as soon as possible and do not want to be blocked by
> >> the outcome of this RFC, especially given a mustache based templating
> >> language can address all our current requirements.
> >>
> >> [1]
> >>
> https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
> >>
> >> ___
> >> Wikitech-l mailing list
> >> Wikitech-l@lists.wikimedia.org
> >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> >
> >
> > ___
> > Mobile-l mailing list
> > mobil...@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/mobile-l
> >
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The future of skins

[Trevor Parscal]

Thanks for summarizing the meeting Jon.

So, let's get Twig/Swig into core then, eh? :)

- Trevor


On Tue, Aug 26, 2014 at 3:53 PM, Jon Robson  wrote:

> Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and
> talked about the future of skins. Hopefully this mail summarises what
> we talked about and what we agreed on. Feel free to add anything, or
> ask any questions in the likely event that I've misinterpreted
> something we talked about or this is unclear :)
>
> Specifically we talked about how we are unhappy with how difficult it
> currently is for developers to create a skin. The skin class involves
> too many functions and does more than a skin should do e.g. manage
> classes on the body, worry about script tags and style tags.
>
> Trevor is going to create a base set of widgets, for example a list
> generator to generate things like a list of links to user tools. The
> widgets will be agnostic to how they are rendered - some may use
> templates, some may not.
>
> We identified the new skin system will have two long term goals:
> 1) We would like to get to the point where a new skin can be built by
> simply copying and pasting a master template and writing a new css
> file.
> 2) Should be possible for us in future to re-render an entire page via
> JavaScript and using the modern history push state re-render any page
> via the API. (Whether we'd want to do this is another consideration
> but we would like to have an architecture that is powerful enough to
> support such a thing)
>
> As next steps we agreed to do the following:
>
> 1) Trevor is going to build a watch star widget on client and server.
> We identified that the existing watch star code is poorly written and
> has resulted in MobileFrontend rewriting it. We decided to target this
> as it is a simple enough example that it doesn't need a template. It's
> small and contained enough that we hope this will allow us to share
> ideas and codify a lot of those. Trevor is hoping to begin working on
> this the week of the 2nd September.
>
> 2) We need a templating system in core. Trevor is going to do some
> research on server side templating systems. We hope that the
> templating RFC [1] can get resolved however we are getting to a point
> that we need one as soon as possible and do not want to be blocked by
> the outcome of this RFC, especially given a mustache based templating
> language can address all our current requirements.
>
> [1]
> https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
>
> ___
> 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

Re: [Wikitech-l] Template RFC

[Trevor Parscal]

On Fri, Aug 22, 2014 at 12:14 PM, S Page  wrote:

> On Fri, Aug 22, 2014 at 11:34 AM, Jon Robson  wrote:
>  > Trevor is working on a template widget for oojs which will
> > make this possible
> >
> Great, though I don't understand what this is. Is this a specific widget
> that uses a specifc template, or an "platform" widget that handles
> templating for other OOUI widgets?
>
>
It will be a generic container for template rendering.

// Create a templatevar thing = new OO.ui.TemplateWidget( 'some way of
identifying the template' );// Render the template into thing.$element
thing.render( { /* some data */ } );// Add the template to the body
$( 'body' ).append( thing.$element );// Render it again with different
data, retaining the same this.$element reference
thing.render( { /* some different data */ } );

This will also allow you to extend TemplateWidget and add methods which
either change the data and either trigger re-rendering or just surgically
tweak the DOM as needed.

- Trevor
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Winter, v. 0.6

[Trevor Parscal]

I want to suggest that we give Brandon a lot of slack here, and be as
supportive as possible.

This is a prototype of a design, which is far better than a mockup of a
design. It is not an actual implementation, but that is totally fine. I
want to see more of this kind of thing, and by being more supportive and
understanding I think we can encourage that.

- Trevor


On Mon, Jul 14, 2014 at 8:52 AM, Brandon Harris 
wrote:

>
> As I've said before, it doesn't work in IE. I've only just gained
> access to a Windows laptop and I'll see what I can do.
>
>
> On Jul 14, 2014, at 5:55 AM, Risker  wrote:
>
> > Thanks Brandon for letting us know about this.  Since it will be many
> hours
> > before I have a chance to make comments elsewhere, I'm going to let you
> > know that, using a Win7 platform and IE9, the screen is illegible.  All
> > writing is in a faint shade of grey (or blue where applicable); text
> > overlaps images and infoboxes; and there's massive whitespace to the
> right
> > of the screen.  Because of the very faint text, I can't be certain what's
> > supposed to be above the title; however, what is there looks to all be
> > crowded over to the right of the screen above the large amount of
> > whitespace.
> >
> > I'll try to grab a screenshot and send it in.
> >
> > Risker/Anne
> >
> > On 14 July 2014 01:03, Brandon Harris  wrote:
> >
> >>
> >>I have uploaded a new version of the Winter framework/prototype,
> >> v. 0.6.
> >>
> >>http://unicorn.wmflabs.org/winter/
> >>
> >>This version has significant changes over 0.5.  The entire
> >> undercarriage has been refactored into a framework to allow for anyone
> to
> >> do rapid prototyping within their own copy.  The source code has been
> >> installed into gerrit, in the form of two depots, one of which is for
> >> specialized "modules" that change the way the prototype behaves
> >> (snowflakes).
> >>
> >>Links to the source depots are available at:
> >>
> >>
> >> https://www.mediawiki.org/wiki/Winter#The_Winter_Framework
> >>
> >>This release adds in several major changes:
> >>
> >>* "Right rail" functionality, designed to surface content
> >>* Search functionality
> >>* Watchlist functionality (for testing)
> >>* A revisit to the design of the edit interface.
> >>
> >>A full changelog for version 0.6 can be found here:
> >>
> >>
> >> https://www.mediawiki.org/wiki/Winter#Version_0.6.2C_July_13.2C_2014
> >>
> >>As usual, feedback is welcomed here:
> >>
> >>https://www.mediawiki.org/wiki/Talk:Winter
> >>
> >> ---
> >> Brandon Harris, Senior Designer, Wikimedia Foundation
> >>
> >> Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
> >>
> >>
> >> ___
> >> 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
>
> ---
> Brandon Harris, Senior Designer, Wikimedia Foundation
>
> Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
>
>
> ___
> 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

Re: [Wikitech-l] Best practices for loading large, pre-minified JavaScript modules?

[Trevor Parscal]

Seems reasonable for us to consider adding a way to specify "packed" in RL
to skip additional processing of that module.

- Trevor


On Sun, Jul 13, 2014 at 6:35 PM, Krinkle  wrote:

> On 13 Jul 2014, at 19:40, Max Semenik  wrote:
>
> > You can bypass minification with &raw=true, but it would kill most of RL
> > niceties too.
> >
>
> This is incorrect. ResourceLoader "raw" does not, nor ever has, bypassed
> minification.
>
> "raw" is what bypasses the client loader framework. So instead of
> returning a combined
> script/styles/messages response to the mw.loader.implement callback, it
> returns a raw
> response for only scripts, styles or messages – whichever is specified in
> the "&only="
> parameter – without a mw.loader.implement or mw.loader.state call.
>
> This is mostly undocumented and discouraged hack that can be used to fetch
> ResourceLoader modules into a non-ResourceLoader context (e.g. Toolserver,
> old
> versions of MobileFrontend).
>
> It does not bypass minification. That's what debug=true is for.
>
> To fetch the scripts with only concatenation and not minification, you can
> use &modules=my.module.name&only=scripts&debug=true. Like all unversioned
> requests,
> this is only cached for 5 to 30 minutes (depending on mediawiki
> configuration).
>
> -- Krinkle
>
>
> ___
> 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

Re: [Wikitech-l] Mantle - coding sharing between Flow and MobileFrontend

[Trevor Parscal]

I spoke with Jon in person and I think we have reached some sort of
understanding.

The main point I think should be made public - something I communicated to
Jon in person - is that me stepping away from VisualEditor for a couple of
months to work on UI standardization and a new skinning system has been
proposed without lines of code written or detailed implementations
specified because I know that a lot of the work that needs to be done has
already been done, and the people who can help me tie it all together
already work at the same place that I do and are generally available to me
upon request.

My goal is to make things work for everyone to the greatest degree
possible. I believe fundamentally in voluntary association, and if we are
going to get people to sign on voluntarily to join forces - while it may
requires some sacrifices - it will only happen if we aren't snubbing people
and then turning around and dictating how they work.

It's unfortunate that there has been so much hostility around this issue.
Let's see that it ends now.

- Trevor


On Thu, Jul 3, 2014 at 9:58 PM, Pine W  wrote:

> Sorry Erik, I missed your post in the discussion above and just saw it as I
> was working my way back through the stack of emails. Anyway, I hope this is
> on your radar.
>
> Pine
>
>
> On Thu, Jul 3, 2014 at 9:55 PM, Pine W  wrote:
>
> > Sounds like there are some issues here that may need untangling. I'm
> > pinging Erik. He's probably aware of this but I would like to hear his
> POV.
> > Mobile is high on WMF's priority stack and it's high on my list of
> personal
> > interests.
> >
> > Pine
> >
> >
> > On Thu, Jul 3, 2014 at 1:46 PM, Ryan Kaldari 
> > wrote:
> >
> >> What you're saying, Trevor, makes sense, and I agree that we shouldn't
> >> have
> >> a "code purgatory". I won't presume to speak for Jon, but I imagine his
> >> somewhat provocative presentation of Mantle is due, at least in part, to
> >> frustration. About a year ago, the mobile web team was gung-ho to start
> >> moving parts of MobileFrontend into core. The first step in this process
> >> was to convert MobileFrontend into a skin, which we did. The second part
> >> was to move our template system into core, since most of the other parts
> >> depend on it and there's no MVC framework in core, especially not for
> >> client-side use. We put together an RfC on this,[1] and pushed it at the
> >> architecture summit. No consensus was reached on moving forward, and
> >> instead we reluctantly agreed to hold off on doing anything until
> Gabriel
> >> had a chance to implement an alternate solution for comparison. We
> >> recently
> >> tested Gabriel's implementation,[2] but are not totally satisfied with
> it
> >> or convinced that it is the best way forward (although Gabriel is still
> in
> >> the process of improving it).
> >>
> >> After having lost most of our momentum, we recently pushed to prioritize
> >> core infrastructure work during mobile web's planning for the upcoming
> >> fiscal year, and even talked about breaking off part of the mobile web
> >> team
> >> into a "skin and infrastructure team". This too was basically shut down
> in
> >> favor of continuing work on mobile features. Then after suffering both
> of
> >> these setbacks we learn that there is yet another nascent proposal for a
> >> new core UI skinning infrastructure and even though it doesn't have a
> >> single line of code yet, you have been granted 80% of your time to work
> on
> >> it (rather than working on either of other two systems that have already
> >> been started). While it's great that you have invited the mobile web
> team
> >> to participate in this effort, I hope you can understand how this entire
> >> experience has been extremely demoralizing and frustrating for the
> mobile
> >> web team. Personally, I can't blame Jon for losing patience in the
> process
> >> and (purposefully or not) causing a stink about it.
> >>
> >> That said, I hope we (the mobile web team) can put aside some of our
> >> feelings of being snubbed and outmaneuvered and work (yet again) towards
> >> reaching some sort of consensus on moving forward.
> >>
> >> 1.
> >>
> >>
> https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
> >> 2.
> >>
> >>
> https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/Knockoff_-_Tassembly/Mobile

Re: [Wikitech-l] Mantle - coding sharing between Flow and MobileFrontend

[Trevor Parscal]

Indeed, this thread is a bit silly.

If someone wants to make an extension that provides a feature, and someone
else wants to use it, there's nothing wrong with that. But why would such a
thing need proposing?

If the point of Mantle is only to provide a way to bring templates to the
client, then sell it that way. Look at the code in Mantle, and the way it's
been pitched online and in person. It includes other things too, and has
been repeatedly advertised as a general place where any code that is
experimental can be put, while also simultaneously pushing for others to
depend on it.

I have no problem with adding useful functionality to ResourceLoader, even
doing so in an extension. I have a problem with trying to develop, what Jon
himself call, a code "purgatory".

I'm happy to talk in person as well.

- Trevor


On Thu, Jul 3, 2014 at 11:23 AM, Ryan Kaldari 
wrote:

> This whole thread seems a bit silly to me. We put stuff that should be in
> core into extensions all the time (for lots of different reasons). For
> example: WikiEditor, VisualEditor, Echo, MobileFrontend, JsonConfig, etc.
> So why is Mantle such a bad idea? There's no consensus on implementing
> templating in core yet, so it seems like a pretty cool idea to have an
> extension that other extensions can utilize for that technology in the
> meantime (instead of writing separate code for the same purpose). The
> JsonConfig and EventLogging extensions are basically the same idea, right?
> I think if Jon had named the extension "TemplateDooDad" (and hadn't
> emphasized the fact that he was avoiding putting the code into core), it
> wouldn't have raised anyone's hackles.
>
> Ryan Kaldari
>
>
> On Thu, Jul 3, 2014 at 10:57 AM, Jon Robson  wrote:
>
> > Trevor,
> > That email you quote was about totally different code and a proposal
> > to put it into Mantle and is off topic for this discussion.\T
> > Trevor, please grab me in real life, so we can quell this
> > misunderstanding asap, I feel for whatever reason I am not effectively
> > communicating to you and possibly others and I would like to work out
> > why and avoid future misunderstandings. I had hoped to grab you
> > yesterday but I didn't get time because of the Flow release, hence my
> > lack of reply to that thread.
> >
> > The main problem Mantle currently solves is:
> > "... 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."
> >
> > To put it this way:
> > * it would be irresponsible to put code for 2 templating languages
> > (Hogan, Handlebars) into core
> > * it would be irresponsible to put code to serve templates with no
> > templating library whilst the RFC about templating is still
> > unresolved.
> > * it would be irresponsible for two teams to write exactly the same
> > code to serve templates to the client in 2 different extensions.
> >
> > Your own team member Timo was strongly against me putting this code in
> > core in current form and I agreed with him.
> >
> > "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"
> >
> > This particularly offends me by the way. This is a no brainer and of
> > course any code Flow or the mobile team is writing will meet coding
> > standards and be stable. I'm not going to post bad code to Wikimedia
> > servers just as I'm not going to post non-generic non-standardised
> > code to core.
> >
> > ___
> > 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
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Mantle - coding sharing between Flow and MobileFrontend

[Trevor Parscal]

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.*



> 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.


- Trevor



On Thu, Jul 3, 2014 at 9:09 AM, Jon Robson  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 so

Re: [Wikitech-l] Discontinue internet explorer 6 and 7 support

[Trevor Parscal]

I'm happy to see us talking about leaving these old browsers behind, but it
seems a few existing policies and situations may have been overlooked in
this thread thus far.

Hopefully this list of things to consider will be helpful:

   1. We are planning on moving away from jQuery UI this year as part of
   our UI standardization push
   2. We have a policy in place that any browser with 0.1% market share or
   more should be supported for reading and basic contribution
   3. We have a policy that reading and basic contribution should be
   possible without JavaScript
   4. Depending on the feature, IE 6 and 7 are already unsupported
   5. Not supporting older browsers is not always about work involved, many
   times it is not possible to bring certain features to a browser because of
   lack of support or severe bugs

- Trevor



On Sun, Jun 29, 2014 at 4:27 PM, Daniel Norton 
wrote:

> On Jun 29, 2014, at 6:12 PM, Tim Starling  wrote:
> > 
>
> Reading between the lines:
> updates are complicated.  …[M]any of the Windows operating systems are not
> direct purchases – these methods do not allow upgrade.
>
> i.e. virtually all copies of IE6 are pirated.
>
> There are also concerns in China about U.S.-government back doors into
> later versions of I.E.
>
>
> http://www.cnet.com/news/microsoft-china-clash-over-windows-8-and-charges-of-backdoor-spying/
>
> —
> Daniel
>
> ___
> 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

Re: [Wikitech-l] Adding external libraries to core (SwiftMailer)

[Trevor Parscal]

Also, please note that includes/lib is meant to be a place for external
libraries. Some of the libraries are ones we have ported or written
ourselves, but we should continue using this space as external libraries
increase in number and change in nature.

- Trevor


On Tue, May 27, 2014 at 9:12 AM, Tony Thomas <01tonytho...@gmail.com> wrote:

> That sounds great Bryan.
>
> >I think we should create a new repository in gerrit
> ("mediawiki/core/contrib"?
> waiting for that repo to show up in gerrit.
>
> On Tue, May 27, 2014 at 7:38 PM, Mark A. Hershberger 
>  wrote:
> >Thank you!  I think the more use we make of composer, the better.
>
> >I do have one concern about the tarballs we produce.
>
> >It looks like it will be necessary to pre-populate vendor with
> >composer.json dependencies like this one -- libraries that are essential
> >-- in order to make sure that a tarball installation require downloading
> >anything but the tarball itself.
>
> So, if we can have the swiftmailer repo added, this would be excellent. It
> might get worse
> otherwise, as after this shift, MW can 'only' send emails through swift. A
> hard dependency,
> as you quoted earlier.
>
> Thanks,
> Tony Thomas 
> FOSS@Amrita 
>
> *"where there is a wifi, there is a way"*
>
>
> On Tue, May 27, 2014 at 9:27 PM, Bryan Davis  wrote:
>
> > On Tue, May 27, 2014 at 2:56 AM, Tony Thomas <01tonytho...@gmail.com>
> > wrote:
> > > Hi,
> > >   We were having discussions regarding putting the new
> > > SwiftMailer[1] lib in/out of core, after the merge of the change
> > > https://gerrit.wikimedia.org/r/#/c/135290. Tyler recommends to add the
> > > installer code to the composer.json and not to add the SwiftMailer code
> > to
> > > the core. This creates the swiftmailer lib in core/vendors/swiftmailer.
> > > After discussing with Bryan (https://dpaste.de/XVkL/raw), it looks
> > > like *maintaining
> > > a separate repo* for external libraries looked like the best solution,
> so
> > > that it uses composer 'properly', and still works for wmf-deployement
> --
> > > rather than getting the whole into core. It could be thus deployed via
> > > trebuchet to the cluster and the autoloader pulled in in CommonSetings
> > > (quoting Bryan).
> > >Since the entire mail structure is being reworded to use
> > > swiftmailer, and its a crucial dependancy ( There will be no alternate
> > mail
> > > systems in UserMailer.php -- as both the SMTP and no SMTP cases are
> > handled
> > > effectively by SwiftMailer ), I think we will need to have a separate
> > repo
> > > for that. Please go through the patch-set above and comment your
> opinions
> > > on including external libraries.
> > >
> > > [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=63483
> >
> > Thanks for getting this discussion started Tony. I have "been meaning
> > to" write a very similar email regarding discussions from the Zürich
> > hackathon about my own attempt to pull third-party libraries into
> > mediawiki-core [2]. After talking to Ori, Tyler, Matt Walker and
> > others in Zürich I realized that my desire to put the libraries into
> > mediawiki-core was mostly motivated by convenience for deployment on
> > the production wiki[mp]edia cluster. For a variety of reasons, using
> > composer to download and install libraries directly on the production
> > cluster is undesirable. There is an alternative however that can be
> > clearly seen in the mediawiki/extensions/Parsoid/js/contrib.git
> > repository.
> >
> > I think we should create a new repository in gerrit
> > ("mediawiki/core/contrib"? Bikeshed as needed) where composer is used
> > to manage importing specific versions of external libraries that are
> > needed for the wiki[mp]edia cluster deployments. This repository can
> > be deployed to the production cluster using Trebuchet or scap and
> > appropriate changes can be made in operations/mediawiki-config.git to
> > ensure that the autoloader can find the external classes.
> >
> > [2]: https://gerrit.wikimedia.org/r/#/c/119939/
> >
> > Bryan
> > --
> > Bryan Davis  Wikimedia Foundation
> > [[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
> > irc: bd808v:415.839.6885 x6855
> >
> > ___
> > 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
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wmfall] [Engineering] Rob Moen takes on new role in Growth team

[Trevor Parscal]

I normally don't chime in on these threads, but I feel compelled.

Rob made a significant contribution to VisualEditor and this change is a
well deserved nod to his growth as an engineer as well as a step in the
right direction to spread knowledge around the organization.

Congrats on the new position man.

- Trevor


On Thu, May 8, 2014 at 10:24 AM, Moriel Schottlender <
mschottlen...@wikimedia.org> wrote:

> Woohoo, congrats Rob!!
> +1 to James and Roan's sentiments, and best of luck on the growth team!
>
>
> On Thu, May 8, 2014 at 7:28 AM, James Forrester 
> wrote:
>
>> On Wednesday, May 7, 2014, Terry Chay  wrote:
>>
>>> Hello everyone,
>>>
>>> I’m pleased to announce Rob Moen is moving from the VisualEditor team to
>>> the Growth team.
>>>
>>
>> Rob,
>>
>> It's been a pleasure working with you. Thank you for everything;
>> using VisualEditor is so much better because of your work. Best wishes with
>> Growth – they're lucky to get you. :-)
>>
>> J.
>>
>>
>> --
>> James D. Forrester
>> Product Manager, VisualEditor
>> Wikimedia Foundation, Inc.
>>
>> jforres...@wikimedia.org | @jdforrester
>>
>> ___
>> Engineering mailing list
>> engineer...@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/engineering
>>
>>
>
> ___
> Wmfall mailing list
> wmf...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wmfall
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OOUI and modularity

[Trevor Parscal]

We are very open to breaking it out into submodules. We should be able to
do this very quickly. In many cases, users of OOUI are only in need of a
few base classes, and we've recently done much more to divide up the style
code to make it possible to load things a la carte. I believe this is
especially important for mobile due to both the size of the entire library
and also the number of widgets in the library that are yet to be styled or
optimized for mobile. I also suspect that a large chunk of that data is the
icon stylesheet, which embeds a large number of SVG or PNG icons. I don't
know what the solution for that chunk is, but I'm sure we can figure out
something clever.

We should talk when I get back from vacation on the 13th, or if you are at
the hackathon you can try your hand at getting Roan or Timo to move forward
on this.

We acknowledge that right now is an early adoption phase for using OOUI. We
really respect and appreciate those who are brave enough to begin using it
now, and are dedicated to supporting them. Thank you for giving it a try,
and please continue to be patient as we work through the challenges
together.

- Trevor
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] VisualEditor template editing interface

[Trevor Parscal]

I don't quite understand your question, sorry. I'm talking about adding
fields to TemplateData which VisualEditor uses to build a user interface
around templates. TemplateData is defined on-wiki as a JSON blob.

- Trevor


On Tue, Apr 22, 2014 at 11:07 AM, Gerard Meijssen  wrote:

> Hoi,
> Is there a way to link such templates easily to Wikidata?
> Thanks,
>GerardM
> Op 22 apr. 2014 17:51 schreef "Trevor Parscal" :
>
> > We are introducing recommended fields which will be automatically added
> > when the template is added. We already support required fields which are
> > automatically added, but we are adding recommended fields so that
> required
> > can be reserved for actually required fields. In time, we expect required
> > will be enforced as well, but are still researching the impact of that.
> >
> > - Trevor
> >
> >
> > On Tue, Apr 22, 2014 at 8:31 AM, Yury Katkov 
> > wrote:
> >
> > > Hi everyone!
> > >
> > > I'm using VisualEditor and TemplateData to insert template calls in
> > > the wiki page. My users find it prerrty hard to understand the Add a
> > > template Dialog: you should first find a template, then add all its
> > > fields to the call and only after that place some value in each of the
> > > fields. Is it possible to automatically add all the fields to the
> > > template call once the template is selected?
> > >
> > > Cheers,
> > > -
> > > Yury Katkov
> > >
> > > ___
> > > 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
> ___
> 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

Re: [Wikitech-l] VisualEditor template editing interface

[Trevor Parscal]

We are introducing recommended fields which will be automatically added
when the template is added. We already support required fields which are
automatically added, but we are adding recommended fields so that required
can be reserved for actually required fields. In time, we expect required
will be enforced as well, but are still researching the impact of that.

- Trevor


On Tue, Apr 22, 2014 at 8:31 AM, Yury Katkov  wrote:

> Hi everyone!
>
> I'm using VisualEditor and TemplateData to insert template calls in
> the wiki page. My users find it prerrty hard to understand the Add a
> template Dialog: you should first find a template, then add all its
> fields to the call and only after that place some value in each of the
> fields. Is it possible to automatically add all the fields to the
> template call once the template is selected?
>
> Cheers,
> -
> Yury Katkov
>
> ___
> 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

Re: [Wikitech-l] Square Bounding Boxes

[Trevor Parscal]

Our goal should be to relinquish control of image sizing to the view, not
build in more or different ways to specify it in the model.

Images should be given semantic classifications, and the skin should decide
how to best display the image. Maybe it will be inline with the content,
maybe it will be in a separate column which scrolls in sync with the
content. Maybe it will be full width, floated right, a small thumbnail
which when clicked expands to full screen. Maybe multiple images will be
grouped together to make automatic galleries. Etc.

So, what we should be doing instead is deprecating the image size, type and
style properties in exchange for a new semantic system where images are
identified as primary, figure, aside, etc. (names are just examples). We
can support both for a long time, and eventually drop support for the old
properties. We could also interpret common sets of properties within
certain thresholds as equivalent to semantic names, either on the fly or as
a mass conversion change.

- Trevor


On Thu, Mar 27, 2014 at 9:39 AM, Gabriel Wicke  wrote:

> On 03/27/2014 08:32 AM, C. Scott Ananian wrote:
> > Currently mediawiki constrains image size primarily by width, which
> doesn't
> > work so well for images which are taller than they are wide.  There is no
> > way to ask for an image which has a height equal to the  "default
> thumbnail
> > size" (without explicitly specifying a size in px)!
> I support moving to square bounding boxes by default in the longer term,
> but
> am sceptical about the feasibility of doing this cleanly in the short term.
> A short-term solution based on adding more parameters that interact in
> subtle ways with other image parameters has a longer-term cost. We'll need
> to support those options for a long time, and I'm not sure that this cost
> is
> outweighed by the benefits.
>
> For now Parsoid will use the existing upright option with the appropriate
> scaling factor. The main downside of this is that the image won't adhere to
> a square bounding box when the image aspect ratio changes. While not
> optimal, I believe that this case is rare enough that we don't need to rush
> on this.
>
> Gabriel
>
> ___
> 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

Re: [Wikitech-l] Requesting advice about formSpecialPage and ResourceLoader

[Trevor Parscal]

Sorry if that was like "RTFM". If you have more specific ResourceLoader
questions, please feel free to ask.

- Trevor


On Sun, Mar 16, 2014 at 7:22 AM, Trevor Parscal wrote:

> Have you read
> http://www.mediawiki.org/wiki/ResourceLoader/Developing_with_ResourceLoaderyet?
>
> - Trevor
>
>
> On Sun, Mar 16, 2014 at 6:04 AM, Justin Folvarcik wrote:
>
>> I have a couple questions about the formSpecialPage class and how it
>> works.
>> For starters, I cannot seem to make anything happen in the onSubmit
>> callback, regardless of what I do. In addition, I'm also not certain how
>> to
>> return error messages upon failure to perform the action. What's more, I
>> made onSubmit() just return true regardless of anything, and I still could
>> not get the onSuccess() message to display.
>>
>> In a nutshell, I don't understand the submit process for this class, and
>> would like some tips on how to make sure I'm doing everything properly.
>>
>> My extension I am developing is located in my github, here:
>> http://github.com/Justin-Folvarcik/ContactUs
>>
>> Source for the class is in SpecialContactUs.php, and the js and css are
>> currently unused while I work out the rest of the technical details. If I
>> could possibly get some pointers about it, I'd appreciate it. I'm
>> basically
>> stuck, and don't know what to do next.
>>
>> One other point I'd like advice on is ResourceLoader. I know it handles
>> scripts and css, and I was told that it could be used to inject my script
>> into the articles for my extension (different from ContactUs, and still in
>> early stages of development). It's a JS based extension, and the PHP is
>> only meant to be called via AJAX calls from the JS. I'm doing the testing
>> of the JS on actual user/common.js pages currently because I don't know
>> how
>> to set my script up with MediaWiki. I tried using the $wgResourceLoader
>> but
>> couldn't produce any results, and I eventually decided it would be best to
>> ask here.
>>
>> Thanks in advance. Any help is greatly appreciated.
>>
>> --
>> 
>> Justin Folvarcik
>> *"When the power of love overcomes the love of power, the world will
>> finally know peace."*-Jimi Hendrix
>> ___
>> 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

Re: [Wikitech-l] Requesting advice about formSpecialPage and ResourceLoader

[Trevor Parscal]

Have you read
http://www.mediawiki.org/wiki/ResourceLoader/Developing_with_ResourceLoaderyet?

- Trevor


On Sun, Mar 16, 2014 at 6:04 AM, Justin Folvarcik wrote:

> I have a couple questions about the formSpecialPage class and how it works.
> For starters, I cannot seem to make anything happen in the onSubmit
> callback, regardless of what I do. In addition, I'm also not certain how to
> return error messages upon failure to perform the action. What's more, I
> made onSubmit() just return true regardless of anything, and I still could
> not get the onSuccess() message to display.
>
> In a nutshell, I don't understand the submit process for this class, and
> would like some tips on how to make sure I'm doing everything properly.
>
> My extension I am developing is located in my github, here:
> http://github.com/Justin-Folvarcik/ContactUs
>
> Source for the class is in SpecialContactUs.php, and the js and css are
> currently unused while I work out the rest of the technical details. If I
> could possibly get some pointers about it, I'd appreciate it. I'm basically
> stuck, and don't know what to do next.
>
> One other point I'd like advice on is ResourceLoader. I know it handles
> scripts and css, and I was told that it could be used to inject my script
> into the articles for my extension (different from ContactUs, and still in
> early stages of development). It's a JS based extension, and the PHP is
> only meant to be called via AJAX calls from the JS. I'm doing the testing
> of the JS on actual user/common.js pages currently because I don't know how
> to set my script up with MediaWiki. I tried using the $wgResourceLoader but
> couldn't produce any results, and I eventually decided it would be best to
> ask here.
>
> Thanks in advance. Any help is greatly appreciated.
>
> --
> 
> Justin Folvarcik
> *"When the power of love overcomes the love of power, the world will
> finally know peace."*-Jimi Hendrix
> ___
> 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

Re: [Wikitech-l] Why is Cologne Blue still in core?

[Trevor Parscal]

I'm going to start working on some RL modifications to make it possible for
skins outside of core to add skinStyles to other modules, which will help
with making non-core skins equally capable.

- Trevor


On Wed, Mar 12, 2014 at 12:00 PM, Jon Robson  wrote:

> Yes this is an orthogonal conversation. If it's that easy for a core
> change to break a skin outside core, then there are lots of
> fundamentally wrong things with our skin system, one being the fact
> that modules added with OutputPage get added to all skins even if they
> might not be compatible with them. If we want to talk about this I'd
> encourage you to start a new thread.
>
> On Wed, Mar 12, 2014 at 11:57 AM, Matthew Flaschen
>  wrote:
> > On 03/11/2014 05:21 PM, Jon Robson wrote:
> >>
> >> If people forget they exist I would say that equates to no one cares
> >> about them and no one maintains them.
> >
> >
> > Isarra was referring to skins outside of core.
> >
> > There's a difference between core developers forgetting non-core skins
> > exist, and the developers of non-core skins forgetting.
> >
> > If we had a proper skin API, people wouldn't explicitly need to think
> about
> > Foo non-core skin, but they would need to think about managing the
> changes
> > to the skin API (the same way we manage other API changes).
> >
> > Matt Flaschen
> >
> >
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
> --
> Jon Robson
> * http://jonrobson.me.uk
> * https://www.facebook.com/jonrobson
> * @rakugojon
>
> ___
> 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

Re: [Wikitech-l] Why is Cologne Blue still in core?

[Trevor Parscal]

Jon, I support your proposed action and would be glad to review.

- Trevor


On Wed, Mar 12, 2014 at 9:03 AM, Stephan Gambke  wrote:

> Is there a particular reason for making them extensions and not
> (installable) skins?
>
> Cheers,
> Stephan
> On 12 Mar 2014 16:47, "Jon Robson"  wrote:
>
> > Okay to make sure stuff comes out of this thread...
> >
> > So unless someone does this before me I am going to move CologneBlue out
> of
> > core and into SkinCologneBlue extension and Modern out of core into
> > SkinModern extension.
> >
> > If someone could rerun the data collection for skin usage I most be most
> > appreciative. Any takers?
> >
> > Then let's decide what we are going to do with this and rethink what our
> > attitude towards skin support is.
> > On 12 Mar 2014 00:15, "Antoine Musso"  wrote:
> >
> > > Le 11/03/2014 23:55, Isarra Yos a écrit :
> > > > On 11/03/14 22:45, Trevor Parscal wrote:
> > > >> By making all skins extensions it would also force us to make a few
> > new
> > > >> APIs which are needed to no longer have skin extensions be
> > second-class
> > > >> citizens.
> > > >>
> > > >> This should happen.
> > > >>
> > > >> - Trevor
> > > >
> > > > Quite so. Think hitting on some of this could be a viable gsoc
> project?
> > >
> > > I don't think so.
> > >
> > > A few weeks of unexperimented CS student is most probably not going to
> > > solve an issue we had for years and years.
> > >
> > > --
> > > Antoine "hashar" Musso
> > >
> > >
> > > ___
> > > 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
> ___
> 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

Re: [Wikitech-l] Why is Cologne Blue still in core?

[Trevor Parscal]

By making all skins extensions it would also force us to make a few new
APIs which are needed to no longer have skin extensions be second-class
citizens.

This should happen.

- Trevor


On Tue, Mar 11, 2014 at 2:38 PM, Isarra Yos  wrote:

> On 11/03/14 21:21, Jon Robson wrote:
>
>> If people forget they exist I would say that equates to no one cares
>> about them and no one maintains them.
>> If this is true, we are doing a disservice to our users by providing
>> these skins to our users.
>>
>
> Developers forget some users exist. They forget use cases exist. It
> happens. It does not invalidate them. We should not be alienating our
> users, whoever they may be, for lack of consideration.
>
> We should instead consider things first and THEN alienate them, of course.
>
>
> -I
>
> ___
> 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

Re: [Wikitech-l] Why is Cologne Blue still in core?

[Trevor Parscal]

I don't think anyone is suggesting removing or even moving Monobook. I
think we are more talking about assigning effort more proportionally to
preference of users. Cologne Blue is not the clear favorite of any group of
users that we know of.

- Trevor


On Tue, Mar 11, 2014 at 12:36 PM, Risker  wrote:

> On 11 March 2014 15:21, Jon Robson  wrote:
>
> > > It might be easier to revamp the skin system if there were fewer skins
> to
> > > port.
> >
> > Touché.
> >
> > So.. so 2 questions
> > 1) would anyone have any objections to moving it out of core and into
> > its own extension?
> > 2) would anyone have any objections for turning it off on Wikimedia wikis
> >
> > FWIW, having a single skin in core would actually be a good thing for
> > skin development. Currently writing a skin outside core is difficult -
> > I found this in the development of the mobile skin. Having a leaner
> > codebase in core would actually encourage better organisation to make
> > things. skinStyles is a great example - if your skin is not in core,
> > you can't use it.
> >
> >
>
> Speaking from a user perspective, having all of 4 skins available (really?
> 4? That's a lot?) does make a difference in differentiating which
> nearly-identical wikis one is working on, particularly if one or more of
> the wikis involved are non-public ones.  Aside from Vector and Monobook,
> though, I don't see a reason why they can't be extensions, as long as
> they're still in the preference lists.
>
> I strongly urge maintaining Monobook exactly the way that Vector is
> maintained: it's the clear favourite of the most active users, it's
> still faster after years of improving Vector, and it handles a lot of
> accessibility issues much better than Vector (particularly for the visually
> impaired, according to those editors I know who have to deal with this).
>
> Risker/Anne
> ___
> 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

Re: [Wikitech-l] Why is Cologne Blue still in core?

[Trevor Parscal]

I support moving it to an extension and enabling it on deployed sites as to
avoid an disruption in service for the users of the skin.

- Trevor


On Tue, Mar 11, 2014 at 12:21 PM, Jon Robson  wrote:

> > It might be easier to revamp the skin system if there were fewer skins to
> > port.
>
> Touché.
>
> So.. so 2 questions
> 1) would anyone have any objections to moving it out of core and into
> its own extension?
> 2) would anyone have any objections for turning it off on Wikimedia wikis
>
> FWIW, having a single skin in core would actually be a good thing for
> skin development. Currently writing a skin outside core is difficult -
> I found this in the development of the mobile skin. Having a leaner
> codebase in core would actually encourage better organisation to make
> things. skinStyles is a great example - if your skin is not in core,
> you can't use it.
>
> ___
> 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

Re: [Wikitech-l] Why is Cologne Blue still in core?

[Trevor Parscal]

It might be easier to revamp the skin system if there were fewer skins to
port.

- Trevor


On Mon, Mar 10, 2014 at 6:48 PM, MZMcBride  wrote:

> Tomasz Finc wrote:
> > On Mon, Mar 10, 2014 at 2:10 PM, Jon Robson  wrote:
> >> Why is Cologne Blue still in core?
> >
> >A good time to revist
> >
> >https://meta.wikimedia.org/wiki/Turning_off_outdated_skins
> >
> >and re-run
> >
> >https://meta.wikimedia.org/wiki/Turning_off_outdated_skins/stats
>
> Tomasz' links are relevant, but it's on the associated talk page that
> there's a hint of the real reason this happened: Cologne Blue was
> originally slated for execution, but MatmaRex (an active developer)
> stepped up and agreed to maintain it.
>
> Stats would be helpful here, though I disagree with the general premise:
> most of the old skins were fine to kill because they sucked, they weren't
> used very much, and/or they weren't maintained. However that does _not_
> mean that we should only have one or two skins. Instead, the skinning
> system should just suck a lot less: it should be easier to add or remove a
> pre-made skin, it should be easier to customize a skin (site-wide), it
> should be easier to create a new skin, it should be easier for users to
> change their skin, and any additional skins we ship with MediaWiki should
> be more attractive and should cleanly support extensions.
>
> In addition to unfairly limiting user choice, site configurability, and
> site customizability, the current skins system also encourages confusion
> between Wikipedia and non-Wikimedia wikis. In other words, if it weren't
> so dreadful to change MediaWiki's skin, there would presumably be reduced
> user confusion. As it is, almost every MediaWiki wiki looks the same.
>
> MZMcBride
>
>
>
> ___
> 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

Re: [Wikitech-l] Usability testing

[Trevor Parscal]

I just wanted to add that in the past, as many people know, we tried a few
different kinds of testing and even hired a usability testing firm to help
us. We conducted research in a lab here in SF and also did some remote
testing, compensating participants with gift cards.

We learned that lab testing is very expensive, complicated and slow. It has
its own unique filtering qualities that prevent certain kinds of people
from participating and encourage others. Participants being in a foreign
environment, using someone else's computer and being run through tasks with
a giant 2-way mirror behind their back and cameras rolling might distort
behavior a bit.

Remote testing done with a facilitator and screen-sharing (like what Steven
is talking about with Google Hangout) is still time consuming, but far
cheaper and easier than lab testing and can be done on shorter notice. It
filters out less tech-savvy people or those who use alternative or legacy
devices like phones, tablets or older computers. It's interesting that it
allows people to use a computer they are already familiar with, but it may
not be relevant to the test.

Remote testing done using usertesting.com is the cheapest and easiest, but
even further filters out less tech-savvy people.

I believe, from lots of first-hand experience and some research on the
subject, that anytime you can get at least 5 users in front of a product
and run them through well written tasks you are going to reveal about 80%
of the problems. Getting fancy with the methodology usually only affects
the final 20%.

I'm really looking forward to having a UX testing person on staff who can
facilitate more testing. I find it very valuable and would like to do more
in the future.

- Trevor


On Thu, Mar 6, 2014 at 4:06 PM, David Gerard  wrote:

> On 6 March 2014 23:47, Steven Walling  wrote:
>
> > more automated remote testing and is $35/test (this is really cheap since
> > the going US rate for an in-person test is something like a $50 Amazon
> gift
> > card).
>
>
> off-topic on off-topic: Offer swag instead. Wikipedia branded stuff is
> presently uncommon enough to *delight* people. I remember doing a
> usability test for Ubuntu and accepting some stickers and a £2 USB
> stick rather than a £40 cheque ... I could tell it was a £2 USB
> because it stopped working 6 months later.
>
> Anyway. Work the swag angle. Puzzle globes. People LOVE that stuff.
>
>
> - d.
>
> ___
> 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

Re: [Wikitech-l] Drop support for PHP 5.3

[Trevor Parscal]

So, it sounds like we will either maybe drop 5.3 after April, or my newborn
son will be riding a bicycle before we can use Traits in PHP.

Hoping for the former, willing to accept the latter.

- Trevor


On Fri, Feb 21, 2014 at 9:19 AM, AlisonW  wrote:

>
>
>
> and on my one webserver which *doesn't* run the LTS (for advance testing
> purposes, mostly) I just got caught by an increase from Apache2.2 to 2.4
> which breaks all the things*.
>
> AlisonW
>
> * well, quite a lot, anyway. Much editing of configuration files and
> temporarily making some facilities entirely unavailable while searching
> documentation to find out WTF is the way to do what I need now.
>
>
> - Original Message -
> > On 21 February 2014 01:00, Techman224  wrote:
> >
> > > Let me put this out there so there isn't confusion. The regular 6 month
> > > releases of Ubuntu are the stable releases. A LTS release is released
> > > every two years on the same cycle as regular Ubuntu releases. A LTS
> > > release is certainly more stable than regular releases, but not calling
> > > regular releases stable is a bit misleading.
> >
> >
> > For server purposes, I think we can stick to LTSes. Approximately
> > nobody runs a non-LTS Ubuntu for their web hosting. (And even less now
> > that non-LTSes are only getting a nine-month lifetime.)
> >
> >
> > - d.
> >
> > ___
> > 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
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Drop support for PHP 5.3

[Trevor Parscal]

Is that the rule then, we have to make MediaWiki work on anything Ubuntu
still supports?

Is there a rule?

- Trevor


On Thu, Feb 20, 2014 at 12:25 AM, Markus Krötzsch <
mar...@semantic-mediawiki.org> wrote:

> On 20/02/14 05:17, Jamie Thingelstad wrote:
>
>> Regarding PHP 5.3 support, I put together a quick report in WikiApiary
>> showing the versions of PHP in use across wikis.
>>
>> https://wikiapiary.com/wiki/PHP_Versions
>>
>> In short, 5.3 is the most common PHP version used by a large, large
>> majority.
>>
>> Three things to footnote in this data (and you could run additional
>> queries to get the real data for these).
>>
>> 1. WMF itself runs PHP 5.3, so that explodes the user count a lot. If
>> you excluded WMF (based on an assumption that WMF controls it so thus
>> could move to newer version easily) it lowers the active users on 5.3
>> dramatically.
>>
>> 2. A large percentage of the 5.3 install base is there because that is
>> what Ubuntu is distributing (my farm is on 5.3 for this reason). If
>> there was an easy PPA solution to move from 5.3 to 5.4 for Ubuntu 12.04
>> that would also lessen the dependency on 5.3.
>>
>
> FWIW, the next long-term support (LTS) version of Ubuntu is due on 17
> April this year. It ships with PHP 5.5. This would be the Ubuntu version
> that hosters would want to upgrade to. However, the previous LTS version
> will still be supported until April 2017, so there is no urge for people to
> upgrade.
>
> Cheers,
>
> Markus
>
>
>
>> 3. If you queried by Netblock you could identify how many of these 5.3
>> users are on Bluehost, Dreamhost or other system where they have no
>> ability to upgrade, the hosted would have to do that.
>>
>> All data (except time series edit data) for WikiApiary is stored as
>> semantic properties, so all of these things are available for #ask
>> queries.
>>
>>
>
> ___
> 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

[Wikitech-l] Drop support for PHP 5.3

[Trevor Parscal]

PHP 5.4 added a few important features[1], namely traits, shorthand array
syntax, and function array dereferencing. I've heard that 5.3 is nearing
end of life.

I propose we drop support for PHP 5.3 soon, if possible.

- Trevor

[1] http://php.net/manual/en/migration54.new-features.php
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] ResourceLoader timing

[Trevor Parscal]

Steffen,

ResourceLoader guarantees the order of module execution if there are
dependencies, such that child always comes after parent, which always comes
after grandparent in a dependency chain. Due to the concatenation of
modules in the order requested, it's unlikely that modules will be executed
in a different order each load. They would probably have to be in separate
groups, and even then because of caching this wouldn't be repeatable
without clearing the cache.

Looking at the timeline when loading the page, it appears that it is
initially drawn incorrectly, and then there is something that causes a
reflow about a second later which corrects it. Without really looking at
your code, it would appear that this reflow may be caused by CSS coming too
late, but it's odd how it appears to be the same style only with different
dimensions.

But then I look at how the header cells have their width set in pixels.
They seem to have a max width (though not in CSS) and are adjusted down
when the browser is made too small to fit the table otherwise. This is
probably being done using a resize handler, and there's the most likely
culprit. Also, this is a very simple UI, but it takes more than a second to
render, and I'm using a very new and powerful computer.

My suggestion is to set the size of the table cells in CSS using 14.2%
(about 1/7th) for each column. Then perhaps setup a simple CSS grid, based
on such percentages, for the events being overlaid on the cells. This would
work by assigning a day-of-week and week-of-month class which would
modulate the left and top position, and all events would be 1/7th width to
match the columns. By specifying as much of the layout as possible in CSS,
you will get far more efficient and responsive layout.

In conclusion, I suspect that ResourceLoader has nothing to do with your
problem, but rather the way you are laying things out is inefficient and
depends on a resize event to happen right after you are done building out
the DOM. Depending on the browser, this may or may not happen, and in the
best case it happens rather latently.

Also, be very careful with resize handlers. Debounce them when possible,
and don't use them to change layouts unless you really have no other
option. They fire at a very fast pace, at a time when the page is being
constantly reflowed, and the events can queue up easily, leaving you with a
ton of events to process, when only the latest one (hopefully the last one)
needs to be addressed (or will really be visible in most cases).

Then again, I haven't seen the actual code, so I could be totally wrong. :)

- Trevor


On Sun, Feb 9, 2014 at 9:58 AM, Steffen Beyer  wrote:

> Hi,
>
> Hopefully this is the right place to ask...?
>
> I wrote a small event calendar extension¹ utilising the FullCalendar
> jQuery plugin. Sometimes it happens that the display is garbled, see
> attachment. My current dirty fix is to rerender the calendar after a
> timeout².
>
> My theory is that the outcome depends on the order of the JS and CSS
> resources being loaded, so it depends on server and network latency. Is
> this possible? Or can I be sure that all CSS is active when I init the
> calendar? If not, is there a ResourceLoader hook I can use? Other ideas?
>
> Live Demo:
>
> https://foodhackingbase.org/wiki/Events
>
> Sincerely,
> --
> Steffen Beyer 
>
> ¹ https://github.com/improper/mediawiki-extensions-yasec
> ²
>
> https://github.com/improper/mediawiki-extensions-yasec/blob/master/resources/ext.yasec.core.js#L9
>
>
> ___
> 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

Re: [Wikitech-l] WMFs stance on non-GPL code

[Trevor Parscal]

VisualEditor is MIT licensed. It was originally GPLv2 by default as per my
contract with Wikimedia, but early on we got written permission from all
authors to change it. We did this because we wanted to ensure maximum
license compatibility for re-use in non-MediaWiki systems.

- Trevor


On Mon, Aug 26, 2013 at 12:43 PM, C. Scott Ananian
wrote:

> On Mon, Aug 26, 2013 at 3:35 PM, Derric Atzrott <
> datzr...@alizeepathology.com> wrote:
>
> > I might have to look into licenses again and make sure what I use is GPL
> > compatible.   The GPL is such a pain sometimes
> >
>
> https://fedoraproject.org/wiki/Licensing:Main is a useful guide.
>  --scott
>
> --
> (http://cscott.net)
> ___
> 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

Re: [Wikitech-l] Git migration: complete

[Trevor Parscal]

On Fri, Jul 26, 2013 at 3:43 PM, Yuvi Panda  wrote:

> On Sat, Jul 27, 2013 at 4:11 AM, Trevor Parscal 
> wrote:
> > Don't forget using git (or git compatible system) as a revision backend.
>
> That is darcs!
>
> Somehow I missed that.

Reading the page, thinking "We need this!"

- Trevor
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Git migration: complete

[Trevor Parscal]

Don't forget using git (or git compatible system) as a revision backend.

Extensions being developed on-wiki, gadgets defining their own API
extensions, JavaScript templates generating HTML DOM trees, human
sacrifice, dogs and cats living together... mass hysteria!

- Trevor

On Fri, Jul 26, 2013 at 3:12 PM, Yuvi Panda  wrote:

> On Sat, Jul 27, 2013 at 3:40 AM, C. Scott Ananian
>  wrote:
> > Who told you about the parsoid/VE team's secret plans?
> >  --scott
>
> It's too late, I know everything - including the plan to use darcs scm
> to replace the revision table and cuneiform to replace wikitext.
>
> --
> Yuvi Panda T
> http://yuvi.in/blog
>
> ___
> 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

Re: [Wikitech-l] Remove 'visualeditor-enable' from $wgHiddenPrefs

[Trevor Parscal]

I have avoided getting involved so I could stay focused on fixing bugs and
making improvements to VisualEditor.

This thread has served it's purpose; to surface various arguments about
whether the preference to disable VisualEditor should be hidden or not. The
conclusion has been reached. The preference is now available to opt out
while VisualEditor is in beta. The patch as been deployed, and we all need
to get back to work.

I would like to politely ask us to put this thread to rest so we can all
get back to our respective tasks at hand.

Thank you all for your participation, I am glad we were able to resolve
this.

- Trevor

On Thu, Jul 25, 2013 at 12:45 PM, Tyler Romeo  wrote:

> On Thu, Jul 25, 2013 at 3:23 PM, James Forrester
> wrote:
>
> > That's just flatly wrong. Removing the preference was always the
> intention
> > and had been mentioned several times.
> >
>
> See here it is again. Was is absolutely necessary to say I was "flatly
> wrong"? This thread began with mentions of the original patchset in which
> the $wgHiddenPrefs was enabled *because of the messages error* so I don't
> see how it was such a terrible conclusion to come to.
>
> I made the call about a year ago, and mentioned it in several of the
> > dozens of mailing list and on-wiki posts made about the development of
> > VisualEditor since then. Clearly my communication about it wasn't read,
> or
> > wasn't understood, by the people who subsequently complained, but I
> > wouldn't describe it as being "done silently".
>
>
> Could you maybe link to where you emailed wikitech about this, because I
> just searched my Gmail and found no such email.
>
> *-- *
> *Tyler Romeo*
> Stevens Institute of Technology, Class of 2016
> Major in Computer Science
> www.whizkidztech.com | tylerro...@gmail.com
> ___
> 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

Re: [Wikitech-l] VisualEditor - Paste Displayed Text UI

[Trevor Parscal]

I've already commented on the bug and in Gerrit, but I will also echo here.

First off, thank you for taking the time to work on VisualEditor, and even
submitting a patch directly into Gerrit. We hope to get more patches this
way.

In this particular case, the solution being offered isn't going to work out
for some UX and technical reasons.

Specifically that the contents of a link are not limited to plain text, so
editing them as such will remove all non-text content when the user was
only trying to change the link. The user already has a way to modify the
display content of the link, and if there are bugs to do with their ability
to do that, they should be resolved without introducing a secondary and
more limited editing affordance.

- Trevor

On Thu, May 16, 2013 at 8:00 AM, Jiabao Wu  wrote:

> Hi
>
> I am trying to fix bug 48489 - Can not paste new link anchor for
> VisualEditor.
> https://bugzilla.wikimedia.org/show_bug.cgi?id=48489
>
> I have been able to add the functionality to the link inspector to
> edit the displayed text.
> https://gerrit.wikimedia.org/r/#/c/64055/
>
> I have not worked on the appearance of the interface.  What user
> interface the community would like to get?
>
> Which existing widgets if any should be included when adding this
> functionality? (currently just using InputWidget.js)
>
> Cheers,
> Jiabao
>
> ___
> 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

Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia

[Trevor Parscal]

On Wed, Dec 12, 2012 at 11:32 AM, Daniel Barrett wrote:

> Will the method for hooking into VE be the same as for WikiEditor?  Or
> will extension
> developers need to support both editors in two different ways?
>

In general they are both conceptually and technically incompatible.

Here's some more detail about why:

   - Wrapping selections in wikitext doesn't really make sense in
   VisualEditor due to the nature of it's data structures[1].
   - The VisualEditor API is not complete yet, but it's designed to make it
   easy to create new extensions, but also easy to reuse parts of other
   extensions - an area in particular where WikiEditor was flawed.

- Trevor

[1]
http://www.mediawiki.org/wiki/VisualEditor/Software_design#Data_Structures
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposed new WMF browser support framework for MediaWiki

[Trevor Parscal]

Whether it be a targeted list of browsers, a list of browsers we explicitly
ignore, or something else entirely, anything that helps us balance
engineering resources is a good thing.

In 2010 I suggested a rule, which became somewhat of a policy, that WMF
won't spend time/money supporting browsers that have 0.1% market share or
less based on our own stats[1] for reading and editing Wikitext source code
in a textarea. Other kinds of features, such as extra editing features or,
in the case of my current project, using the VisualEditor can have higher
thresholds, and these thresholds will be set based on whatever the team
sees as a balance between supporting as many users as possible and making
enough progress to get things out the door at a reasonable pace.

The most important distinction here is that there are different levels of
support based on the feature being considered. This is known as
progressive enhancement, it's a very common technique, and we use it all
the time with success. Currently we depend on our jquery.client module to
black-list certain browsers with known compatibility issues. This allows
new browsers, or ones we haven't tested with yet, to not be shut out just
because we didn't explicitly give them the OK. I believe that this is an
effective way to be friendly to the future, while also resolving
known compatibility problems.

Bottom line:

   1. Doing whatever it takes to make all features work in all browsers
   means spending 90% of our money on 10% of our users.
  - Spending 90% of our money on 10% of our users is a waste of donated
  money.
  - Wasting donated money is unethical.
  - Even if it were 80% of our money for 20% of our users, it's still
  out of balance.
   2. Only spending money on engineering projects that will easily work for
   100% of our users will severely limit what we can do.
  - Severe limitations on what we can do will make our user experience
  inferior to the rest of the web.
  - An inferior user experience will reduce the number of users we have.
  - Even if this only costs us 10% of our users, we've just lost the
  same number of people, but now our software sucks.
   3. Balancing compatibility with better features will result in a better
   user experience.
  - A better user experience will increase the number of users we have.
  - This can easily offset the users we lost because they are still
  using IE 5.5 on Windows 2000.

- Trevor

[1] http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm

On Wed, Nov 21, 2012 at 12:19 PM, Gabriel Wicke wrote:

> On 11/21/2012 11:33 AM, Steven Walling wrote:
> > I was going to go on a long rant here in response to your assertion that
> we
> > shouldn't have a flashy interface, but I'll spare everyone and just say
> > that I strongly disagree.
>
> I am not opposed to having a flashy interface at all and did not assert
> anything like that.
>
> However, having flashy interfaces does not automatically mean that the
> user experience for users with older soft / hardware has to be bad. In
> many cases, it is actually pretty easy from a technical perspective to
> provide a reasonable experience for older browsers while still having
> flashy things where supported.
>
> I fear that a binary browser policy would discourage people from keeping
> this in mind, and think that we can do better than that.
>
> --
> Gabriel Wicke
> Senior Software Developer
> Wikimedia Foundation
>
> ___
> 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

Re: [Wikitech-l] Dropping "My …" prefix from toolbar labels

[Trevor Parscal]

I've supported this change for a very long time, glad to see it's on the
table.

+1

- Trevor

On Fri, Nov 2, 2012 at 11:23 PM, Ori Livneh  wrote:

> Hi,
>
> Change 31065 drops the possessive prefix from toolbar labels, per the
> outcome of the discussion on bug 41672. Unless there are strong objections,
> I am going to merge it on Monday.
>
> Isarra and MZMcBride deserve the credit for noticing this and pointing it
> out; flaws in the patch or this announcement (if any) are my own.
>
>
>   [1]: https://gerrit.wikimedia.org/r/#/c/31605
>   [2]: https://bugzilla.wikimedia.org/show_bug.cgi?id=41672
>
> --
> Ori Livneh
> o...@wikimedia.org
>
>
>
> ___
> 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

Re: [Wikitech-l] Notification bubble system

[Trevor Parscal]

On Wed, Sep 19, 2012 at 11:54 AM, Munaf Assaf  wrote:

> I wasn't clear; that's exactly what we're doing in the Agora CSS library.
>

You are adding an icon feature to me.notify in the Agora CSS library?

I know the answer is "no, we are creating icons that can be used for that
and other purposes", and that's great, it's just not what I'm suggesting
(though it it related and important).

- Trevor
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Notification bubble system

[Trevor Parscal]

Maybe I was unclear.

I'm not suggesting we make these icons so much as we make the notification
system use them by name.

As in:

mw.notify( {
// This is bad
'icon': '
http://upload.wikimedia.org/wikipedia/commons/4/32/check-icon.svg'
/* other options here */
} );

vs.

mw.notify( {
// This is good
'icon': 'check'
/* other options here */
} );

- Trevor

On Wed, Sep 19, 2012 at 11:46 AM, Munaf Assaf  wrote:

> Already in progress.
>
> http://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Icon_Set
>
> They'll eventually be in the Agora library as sprites.
>
> --
> Munaf Assaf
>
>
> On Wednesday, September 19, 2012 at 11:41 AM, Trevor Parscal wrote:
>
> > I'm glad this area is getting a lot of interest - unfortunately I haven't
> > been able to keep up on this thread but I wanted to give a suggestion
> > related to adding icons.
> >
> > It's reasonable to take an option that provides a URL to an icon image,
> but
> > we should have a common (customizable per skin and language) set of icons
> > that can be used by symbolic name, like "success", "failure",
> > "information", "error", etc.
> >
> > This helps in a few ways:
> >
> > - We can make sure they match the skin they are being used in
> > - We can internationalize them
> > - We can avoid having multiple icons for the same purpose
> > - It makes it easier to use the icon feature
> >
> > - Trevor
> >
> > On Wed, Sep 19, 2012 at 9:56 AM, Krinkle  krinklem...@gmail.com)> wrote:
> >
> > > On Sep 19, 2012, at 2:57 AM, "Helder ."  helder.w...@gmail.com)> wrote:
> > >
> > > > On Tue, Sep 18, 2012 at 9:28 PM, Jon Robson  jdlrob...@gmail.com)> wrote:
> > > > > On Commons it seems to take 5 seconds to disappear which is too
> long as
> > > >
> > > >
> > >
> > > at
> > > > > this point I'm wondering how to dismiss it.
> > > >
> > > > I think the time should depend on the length of the message.
> > > > The watchlist notification in Portuguese has ~46 words,
> > > > and if I didn't know what it was saying, that information would be
> lost.
> > > > Maybe it should allow us to see previous notifications by clicking
> > > >
> > >
> > > somewhere.
> > > >
> > > > On Tue, Sep 18, 2012 at 9:28 PM, Rob Moen  rm...@wikimedia.org)> wrote:
> > > > > Not sure if this is a known issue, but the notification is at the
> top
> > > >
> > > >
> > >
> > > of the document regardless of where you are on the page. Meaning if
> I'm at
> > > the bottom of a long article, I have to scroll up to the top to see the
> > > bubble. Should it not be relative to the scroll position?
> > > > >
> > > > > I noticed this by firing off a mw.notify('hi james') in the
> console at
> > > the bottom of a long article. This may have gone unnoticed as it seems
> > > mw.notify is only triggered by UI components at the top of the page.
> > > >
> > > > +1. This is bothering me as well.
> > > >
> > > > Helder
> > >
> > > I agree.
> > >
> > > Just for the record though, lets not forget what it was just weeks ago:
> > >
> > > * Only one message at a time, new one wiped previous one from existence
> > > unconditionally
> > > * No way to close it
> > > * Took up full width
> > > * At the top of the page (still)
> > > * Bumped down the article by the height of the message
> > >
> > > So we are making some progress here.
> > >
> > > Suggestions I saw so far in this thread:
> > > * Notification queue should follow scroll position (fixed position)
> > > * Add close button (even when they close regardless of click target, as
> > > visual clue)
> > > * Extend base framework for universal layout of messages. We already
> have
> > > title/body,
> > > to be extended with icon and buttons.
> > >
> > >
> > > One potential problem with making them appear mid-page (fixed queue) is
> > > when the
> > > bottom of the page is reached. It should then start a new column to the
> > > left.
> > > Other wise it will continue down the page where it can't be seen due
> the
> > > queue
> > > following the scroll position.
> 

Re: [Wikitech-l] Notification bubble system

[Trevor Parscal]

I'm glad this area is getting a lot of interest - unfortunately I haven't
been able to keep up on this thread but I wanted to give a suggestion
related to adding icons.

It's reasonable to take an option that provides a URL to an icon image, but
we should have a common (customizable per skin and language) set of icons
that can be used by symbolic name, like "success", "failure",
"information", "error", etc.

This helps in a few ways:

   - We can make sure they match the skin they are being used in
   - We can internationalize them
   - We can avoid having multiple icons for the same purpose
   - It makes it easier to use the icon feature

- Trevor

On Wed, Sep 19, 2012 at 9:56 AM, Krinkle  wrote:

> On Sep 19, 2012, at 2:57 AM, "Helder ."  wrote:
>
> > On Tue, Sep 18, 2012 at 9:28 PM, Jon Robson  wrote:
> >> On Commons it seems to take 5 seconds to disappear which is too long as
> at
> >> this point I'm wondering how to dismiss it.
> > I think the time should depend on the length of the message.
> > The watchlist notification in Portuguese has ~46 words,
> > and if I didn't know what it was saying, that information would be lost.
> > Maybe it should allow us to see previous notifications by clicking
> somewhere.
> >
> > On Tue, Sep 18, 2012 at 9:28 PM, Rob Moen  wrote:
> >> Not sure if this is a known issue, but the notification is at the top
> of the document regardless of where you are on the page.  Meaning if I'm at
> the bottom of a long article, I have to scroll up to the top to see the
> bubble.  Should it not be relative to the scroll position?
> >>
> >> I noticed this by firing off a mw.notify('hi james') in the console at
> the bottom of a long article.  This may have gone unnoticed as it seems
> mw.notify is only triggered by UI components at the top of the page.
> >
> > +1. This is bothering me as well.
> >
> > Helder
>
> I agree.
>
> Just for the record though, lets not forget what it was just weeks ago:
>
> * Only one message at a time, new one wiped previous one from existence
> unconditionally
> * No way to close it
> * Took up full width
> * At the top of the page (still)
> * Bumped down the article by the height of the message
>
> So we are making some progress here.
>
> Suggestions I saw so far in this thread:
> * Notification queue should follow scroll position (fixed position)
> * Add close button (even when they close regardless of click target, as
> visual clue)
> * Extend base framework for universal layout of messages. We already have
> title/body,
>   to be extended with icon and buttons.
>
>
> One potential problem with making them appear mid-page (fixed queue) is
> when the
> bottom of the page is reached. It should then start a new column to the
> left.
> Other wise it will continue down the page where it can't be seen due the
> queue
> following the scroll position.
>
> Another thing I don't like is how they move up in the queue one after
> another.
> What I like about Growl and Notification Center is that messages stay fixed
> where they first appear. And new messages are added to the bottom (or next
> column), or, when the first position is available again, it will re-use
> those
> positions again.
>
> That way users don't have to re-focus constantly and follow where which
> message
> went when dismissing some of them. This gets more important as we start to
> introduce notifications that do user interactions (sticky ones, which
> should not
> move but be sticky).
>
> However that brings another problem: Resizing the window. The spreading of
> messages over multiple columns would have to either be re-build after
> resizing
> the window.
>
>
> -- Krinkle
>
>
>
>
> ___
> 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

Re: [Wikitech-l] Initial stab at responsive images for high-density displays

[Trevor Parscal]

It's important to separate supporting retina display mobile and desktop
devices. Apple's web site uses the load both method to show off the retina
display MacBook - which is more likely to have a faster internet connection
and is a more powerful machine in general.

- Trevor

On Tue, Sep 18, 2012 at 10:17 AM, Brion Vibber  wrote:

> On Tue, Sep 18, 2012 at 10:15 AM, Martijn Hoekstra <
> martijnhoeks...@gmail.com> wrote:
>
> > Sending more data to primarily empower mobile devices sounds rather
> > counter-intuitive
> >
>
> Amount of data, and *when that data comes in*, are distinct things. One
> other change we've got brewing up for the mobile site is to delay loading
> of collapsed section content by separating it out to an API request. This
> gets you loading the initial page *immediately*, then loads up the rest.
> Same amount of data, but the page above the sections is live and visible
> and interactive before you load the other stuff.
>
> -- brion
> ___
> 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

Re: [Wikitech-l] Initial stab at responsive images for high-density displays

[Trevor Parscal]

In VisualEditor we ended up putting all CSS rules that include images in
*.icons-raster.css and *.icons-vector.css files, which are loaded
dynamically based on the window.devicePixelRatio property.

It has it's flaws, but the good thing is that it spares the device from
loading both versions. I dislike the approach we are using and am open
minded to alternatives, but any solution that makes a client load both
isn't really going to work.

- Trevor

On Tue, Sep 18, 2012 at 8:47 AM, Jon Robson  wrote:

> Awesome!
> Correct me if I'm wrong but the way this is currently written an image for
> foo.jpg will first load foo.jpg then replace the src attribute for this
> element then load the image foo-2.0.jpg ?
>
> In which case we probably need to think more abut minimising this initial
> load. I'd suggest not setting the src attribute and using a noscript tag
> repeating the same html. We might even be able to write javascript that
> parses the noscript tag and creates the new image above it...
>
> Another common trick I've seen is the browser via javascript reporting that
> they now have a 2.0x density display and then the php script serving these
> as the default in future.
>
> With regards to Daniel's email it might be worth supporting a polyfill such
> as [1]. I'm still anxious that since no browsers have implemented it there
> might be a few minor changes and I think working with an established
> library will keep us up to date.
>
> I think we should be defaulting to true. I agree with Daniel that
> experimental features never seem to enabled and don't get properly tested.
> This should be the norm. We should be bold! :)
>
> [1] https://github.com/scottjehl/picturefill
> On Tue, Sep 18, 2012 at 12:31 AM, Brion Vibber  wrote:
>
> > How to load up high-resolution imagery on high-density displays has been
> an
> > open question for a while; we've wanted this for the mobile web site
> since
> > the Nexus One and Droid brought 1.5x, and the iPhone 4 brought 2.0x
> density
> > displays to the mobile world a couple years back.
> >
> > More recently, tablets and a few laptops are bringing 1.5x and 2.0x
> density
> > displays too, such as the new Retina iPad and MacBook Pro.
> >
> > A properly responsive site should be able to detect when it's running on
> > such a display and load higher-density image assets automatically...
> >
> > Here's my first stab:
> > https://bugzilla.wikimedia.org/show_bug.cgi?id=36198#c6
> > https://gerrit.wikimedia.org/r/#/c/24115/
> >
> > * adds $wgResponsiveImages setting, defaulting to true, to enable the
> > feature
> > * adds jquery.hidpi plugin to check window.devicePixelRatio and replace
> > images with data-src-1-5 or data-src-2-0 depending on the ratio
> > * adds mediawiki.hidpi RL script to trigger hidpi loads after main images
> > load
> > * renders images from wiki image & thumb links at 1.5x and 2.0x and
> > includes data-src-1-5 and data-src-2-0 attributes with the targets
> >
> > Note that this is a work in progress. There will be places where this
> > doesn't yet work which output their imgs differently. If moving from a
> low
> > to high-DPI screen on a MacBook Pro Retina display, you won't see images
> > load until you reload.
> >
> > Confirmed basic images and thumbs in wikitext appear to work in Safari 6
> on
> > MacBook Pro Retina display. (Should work in Chrome as well).
> >
> > Same code loaded on MobileFrontend display should also work, but have not
> > yet attempted that.
> >
> >
> > Note this does *not* attempt to use native SVGs, which is another
> potential
> > tactic for improving display on high-density displays and zoomed windows.
> > This loads higher-resolution raster images, including rasterized SVGs.
> >
> >
> > There may be loads of bugs; this is midnight hacking code and I make no
> > guarantees of suitability for any purpose. ;)
> >
> > -- brion
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
>
>
>
> --
> Jon Robson
> http://jonrobson.me.uk
> @rakugojon
> ___
> 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

Re: [Wikitech-l] $( '' ) vs. $( '') in coding conventions (and methods for building DOMs with jQuery)

[Trevor Parscal]

On Thu, Aug 30, 2012 at 3:24 AM, Daniel Werner
wrote:

>
> By the way, you can also use
>
> $( '', { 'class': 'foo', 'title': 'myTitle', ... } );
>
>
Just be aware this also allows you to use things like 'html' and 'text'
which are not attributes at all, but call .html() or .text() internally.
There are also property aliases here.

In short - be aware of what the code does by reading the manual.

http://api.jquery.com/

- Trevor
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] $( '' ) vs. $( '') in coding conventions (and methods for building DOMs with jQuery)

[Trevor Parscal]

+1

Thank you for grounding this conversation in reality.

- Trevor

On Tue, Aug 28, 2012 at 12:18 PM, Krinkle  wrote:

> Okay, sorry for being away for 30 minutes while I enjoyed dinner.
>
> Someone[1] pointed me to this thread and suggested I chime in, so here I
> go.
>
>
> On Aug 28, 2012, at 2:50 AM, Daniel Friesen 
> wrote:
>
> > Either way $( '' ) is NOT something officially supported by jQuery
> [..]
> >
>
> This is simply incorrect.
> * It has been explicitly supported (whether or not
> intentionally/officiallt) by jQuery for years as can be seen in the source
> code.
> * It has been used by jQuery core and other jQuery project for years (not
> just sporadically, but pretty much everywhere, consistency).
>
> And I'm happy to announce that as of today, by popular demand, the jQuery
> team has finally updated[4] the 3-year old documentation to reflect this
> feature.
>
> Up until now the documentation for the root jQuery() function still
> reflected the situation as it was 3 years ago. Where the string always had
> to be fully valid with closing tag, with the exception of  and
>  because the native parsers in the browsers supported it that way
> (not because jQuery wanted us to).
>
> But for a while now jQuery features element creation through the native
> createElement() by passing a single  ("with optional closing tag or
> quick-closing"[2]). As such I've reverted this edit[3].
>
>
>
> On Aug 28, 2012, at 9:57 AM, Tim Starling  wrote:
>
> > Personally, I would use document.getElementById() to do that. It's
> > standard, and it's faster and more secure. More complex selectors
> > derived from user input can be replaced with jQuery.filter() etc. with
> > no loss of performance.
> >
> > -- Tim Starling
> >
>
>
> Indeed.
> Moreover, aside from the performance and security, there's another
> important factor to take into account. And that is the fact that IDs can
> contain characters that have special meaning in CSS selectors (such as
> dots).
>
> We've seen this in before when dealing with a MediaWiki heading (where the
> ID-version of the heading can (or could) contain dots). So whenever you
> have what is supposed to be an element ID in a variable, use
> document.getElementById (even if you don't care about performance or
> security).
>
>
>
>
> On Aug 28, 2012, at 6:39 AM, Chris Steipp  wrote:
>
> > On Mon, Aug 27, 2012 at 4:37 PM, Mark Holmquist 
> wrote:
> >> I also tried to get an answer about the better between $( ' >> class="a-class" />' ) and $( '' ).addClass( 'a-class' ), but
> >> apparently there's little difference. At least when creating dynamic
> >> interfaces, I'd like to have some guidance and consistency if anyone is
> >> interested in chatting about it.
> >
> > I'm going to try and put some guidelines for secure javascript code
> > together soon, but it's a much better habit to use .addClass(
> > 'a-class' ) and the other functions to add attributes.
> >
>
> I'm looking forward to that.
>
> Note that it is perfectly fine and secure to use:
>  $( '' );
>
> But when working with variables (whether from user input or not), then
> methods like addClass should be used instead. Both for security as well as
> predictability:
> $( '' ); // Bad
>
> If the variable contains any unexpected characters it can for example
> cause the jQuery object to be a collection of 2 or 3 elements instead of 1.
>
>
>
> On Aug 28, 2012, at 8:00 PM, Ryan Kaldari  wrote:
>
> > In that case, perhaps we should just say that all of the options are
> fine:
> > $( '' )
> > $( '' )
> > $( '' )
> >
>
> Indeed[5].
>
>
>
> On Aug 28, 2012, at 2:50 AM, Daniel Friesen 
> wrote:
>
> > If you don't like the XHTML-ish shortcut that jQuery provides, then our
> coding conventions should be to use `$( '' );`.
> >
>
> I agree we shouldn't use XHTML-ish shortcuts because it looks confusing:
>  $('');
>
> That works because jQuery converts  to .
> But just because jQuery allows that doesn't mean we should do it.
> I'd recommend we keep it simple and always use valid HTML syntax when
> writing HTML snippets for parsing.
>
> Either use the  syntax to create a plain element, or use fully valid
> XML/HTML syntax (with no shortcuts) for everything else.
>
>
> -- Timo
>
> [1] Well, actually, almost a dozen someones.
>
> [2] http://api.jquery.com/jQuery/?purge=1#jQuery2
>
> [3]
> https://www.mediawiki.org/w/index.php?title=Manual%3ACoding_conventions%2FJavaScript&diff=576860&oldid=576443
>
> [4]
> https://github.com/jquery/api.jquery.com/commit/ea8d2857cd23b2044948a15708a26efa28c08bf2
>
> [5]
> https://www.mediawiki.org/w/index.php?title=Manual%3ACoding_conventions%2FJavaScript&diff=576924&oldid=576860
>
> ___
> 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

Re: [Wikitech-l] $( '' ) vs. $( '') in coding conventions (and methods for building DOMs with jQuery)

[Trevor Parscal]

On Tue, Aug 28, 2012 at 11:15 AM, Daniel Friesen  wrote:

> That's an unintentional side effect. jQuery does not officially support $(
> '' ) without a closing  or />.


And yet they use it themselves internally? As I mentioned, Timo is a jQuery
maintainer and said it is supported and welcome to be used, and is adding
the regrettably lacking documentation soon.

http://i.imgur.com/h13A1.png

- Trevor
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] $( '' ) vs. $( '') in coding conventions (and methods for building DOMs with jQuery)

[Trevor Parscal]

On Tue, Aug 28, 2012 at 11:00 AM, Ryan Kaldari wrote:

> In that case, perhaps we should just say that all of the options are fine:
> $( '' )
> $( '' )
> $( '' )
> but emphasize not to use attributes in the tag creation.


Unless you are creating an input or a button. Maybe, we
should encourage people to read the jQuery documentation instead of trying
to re-document every feature ourselves.

- Trevor
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] $( '' ) vs. $( '') in coding conventions (and methods for building DOMs with jQuery)

[Trevor Parscal]

jQuery internally maps '' to document.createElement( 'tagName' ).
This is a feature, and is used throughout jQuery internally. It's not very
well documented as such, but Timo is adding it to the documentation as to
resolve the confusion around this. $( '' ) is a shortcut added to
jQuery for our convenience, and I think it's reasonable to use it.

On Tue, Aug 28, 2012 at 10:44 AM, Mark Holmquist wrote:

> In creating elements, maybe, but after creation, $.prop() is the preferred
> way to go because the DOM properties are more reliably synced with the
> actual state of the UI--apparently jQuery doesn't always properly sync the
> HTML attributes to the browser state. I'm sure Timo can explain more fully
> (and maybe more accurately).
>

We had this discussion yesterday, and addClass is more direct than prop(
'className' ) in every way and unless you mean to actually replace all
existing classes, addClass is preferred. prop is there for a reason and
it's also safe to use as escaping goes, but obviously not all attributes
are actually properties, so it's not like we should stop using attr.

- Trevor
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] $( '' ) vs. $( '') in coding conventions (and methods for building DOMs with jQuery)

[Trevor Parscal]

Rob is correct that using addClass is the preferable way to go for classes,
and attr is the preferable way to go for other attributes. They are both
are safe since they use setAttribute internally which escapes the values.

- Trevor

On Tue, Aug 28, 2012 at 10:29 AM, Rob Lanphier  wrote:

> On Mon, Aug 27, 2012 at 9:39 PM, Chris Steipp 
> wrote:
> > On Mon, Aug 27, 2012 at 4:37 PM, Mark Holmquist 
> wrote:
> >> I also tried to get an answer about the better between $( ' >> class="a-class" />' ) and $( '' ).addClass( 'a-class' ), but
> >> apparently there's little difference. At least when creating dynamic
> >> interfaces, I'd like to have some guidance and consistency if anyone is
> >> interested in chatting about it.
> >
> > I'm going to try and put some guidelines for secure javascript code
> > together soon, but it's a much better habit to use .addClass(
> > 'a-class' ) and the other functions to add attributes.
>
> To clarify this point, in that *specific* example, there's no
> appreciable difference from a security perspective.
>
> The problem comes when you move out of the land of constants, and
> start concatenating variables.  Any time you find yourself doing
> something like this:
> $( '' );
>
> ...you're way better off doing this:
> $( '' ).addClass( fooclass );
>
> Not only is it clearer, but it's more secure.  Why?  If the provenance
> of that variable is at all unclear, or if you know it comes from user
> input, I believe you're basically using the DOM to make sure that the
> string is treated as a class name rather than arbitrary HTML
> (Arbitrary HTML leads to XSS.  XSS leads to anger.  Anger leads to
> hate).  I don't know jQuery well enough to know for sure if using
> addClass is sufficient for arbitrary strings or if it's best to *also*
> escape fooclass, but it's at least more likely to be safe than
> concatenating to arbitrary HTML.
>
> If you're dealing just with a constant string, maybe it's ok to use
> either.  However, sooner or later, someone is going to want to make a
> small tweak that involves changing part of the constant to a variable,
> and there's a good chance that someone is going to be relatively
> inexperienced and will simply rely on concatenation rather than
> changing the code to use addClass.
>
> Even if addClass doesn't inherently handle the escaping for you, a lot
> of basic DOM methods do, which is what makes them appealing from a
> security perspective.  The more specific you can be, the better.
>
> Rob
>
> ___
> 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

Re: [Wikitech-l] $( '' ) vs. $( '') in coding conventions

[Trevor Parscal]

On Tue, Aug 28, 2012 at 10:06 AM, Jon Robson  wrote:

> I knew there was a good reason I use $( '' )
> One of those things I learn then forget why I'm doing it. I've apparently
> not being following styling guidelines ;-)
>

Actually you were following the guidelines, but they were changed on as of
16:24, 28 August 2012 by Dantman:

https://www.mediawiki.org/w/index.php?title=Manual%3ACoding_conventions%2FJavaScript&diff=576860&oldid=576443

Previously they looked like this:

https://www.mediawiki.org/w/index.php?title=Manual:Coding_conventions/JavaScript&diff=prev&oldid=576418

- Trevor
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] $( '' ) vs. $( '') in coding conventions

[Trevor Parscal]

On Tue, Aug 28, 2012 at 12:57 AM, Tim Starling wrote:

> Personally, I would use document.getElementById() to do that. It's
> standard, and it's faster and more secure.
>

I think your premature optimization disorder (POD) is flaring up again.
jQuery performance is something that should be understood but not obsessed
about. Is the code running in a tight loop? Is there
a perceivable performance problem? No? Move on please.

$( '' ) or $( '' ) ?

I think it's fine to choose one for consistency, but both are equally
performant[1]. and $( '' ) has the benefit of being more brief.

Creating an element with attributes can be done like:

$( '', { 'class', 'example' } );

It's important to note however that IE required that input and button tags
are created with a type (if they are going to have a specific one)

$( '', { 'class', 'example' } );

- Trevor

[1] http://en.wiktionary.org/wiki/performant
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] $( '' ) vs. $( '') in coding conventions (and methods for building DOMs with jQuery)

[Trevor Parscal]

$( '' ) is the way to go.

- Trevor

On Mon, Aug 27, 2012 at 4:37 PM, Mark Holmquist wrote:

> Hence, I think we should change our coding conventions to always use `$(
>> '' )`.
>>
>
> +1 for valid XHTML. Considering that bytes are cheap and validity is good,
> this seems like a good idea.
>
> I also tried to get an answer about the better between $( ' class="a-class" />' ) and $( '' ).addClass( 'a-class' ), but
> apparently there's little difference. At least when creating dynamic
> interfaces, I'd like to have some guidance and consistency if anyone is
> interested in chatting about it.
>
> My preference is the latter, because it avoids extensive HTML inside of
> JavaScript. But I'd be interested to hear other thoughts.
>
> --
> Mark Holmquist
> Contractor, Wikimedia Foundation
> mtrac...@member.fsf.org
> http://marktraceur.info
>
> __**_
> 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

Re: [Wikitech-l] Wikimedians are rightfully wary

[Trevor Parscal]

The idea that we are trying to attract new users at the detriment of the
existing ones is putting words in our mouths, but I do know what you mean.
The good news is that many of us are very conscious about these issues.

Here are some excerpts, for instance from the VisualEditor software design
document[1]:

   - "Visual editing should first improve the usability of the most common
   tasks. Less frequent tasks may still be performed using a source code
   editing mode."
   - "Visual editing should enhance, not degrade, the ability to inspect
   what was changed between revisions."
   - "At the very least, a visual editor should not make more work for
   administrators and editors who are reviewing edits done by others."

VisualEditor isn't alone in these beliefs, but I realize also that they are
not held widely (yet) enough either.

[1] http://www.mediawiki.org/wiki/VisualEditor/Software_design#Objectives

- Trevor

On Wed, Aug 22, 2012 at 3:11 PM, Federico Leva (Nemo) wrote:

> About colleagues vs. customers: I don't think it can be considered a
> misunderstanding by the community, it's largely due to what the WMF really
> wants.
> The WMF, as the article puts it, doesn't [necessarily] want to work better
> with the existing community (-> colleagues) by providing what's felt useful
> /for them/ to get things done; instead, it largely assumes that what's
> disliked or even plainly harmful now is actually good, if it can attract a
> new demographic of users which will like it (-> new customers).
> And more: changing the demographic by ignoring the existing one is
> sometimes the very aim of changes; community is assumed broken (it scares
> people off), consensus even more so (we can't get anything decided, we need
> "leaders" – surely not pre-emptive consensus), nobody is indispensable (we
> have a big turnover, we only need to improve "_new_ editors retention").
> And yes, this sometimes borders social experiments (eugenetics? :-) ).
> I'm not going to prove all this*; it's nasty to "the community", but
> there's also a lot of truth in it and all in good faith.
>
> Nemo
>
> (*) I could quote individual WMF developers or officers but that would be
> tough and unnecessary: it's the official strategy, just seen from a
> different perspective (by stretching it a bit perhaps).
>
>
> __**_
> 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

Re: [Wikitech-l] Wikimedians are rightfully wary

[Trevor Parscal]

On Tue, Aug 21, 2012 at 1:20 PM, S Page  wrote:

>
> (There is My preferences > Appearance > check "Exclude me from feature
> experiments"; though it's probable some artifacts will leak out, as
> happened for a few weeks in the bug he references.)
>
> As the person who implemented that preference, I can tell you that the
reason we did so was because the lab rats indeed did revolt.

Experimenting on users - perhaps it is loaded, what I take from it though
is the way we tend to not do enough testing or evaluation as to whether a
change actually accomplishes it's objective before unleashing it on our
users. There are many cases where this has failed, and in each of those
cases we have lost the trust of our users.

- Trevor
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimedians are rightfully wary

[Trevor Parscal]

Well said. Thank you for sharing.

- Trevor

On Tue, Aug 21, 2012 at 12:18 PM, Ori Livneh  wrote:

>
>
>
> On Tuesday, August 21, 2012 at 12:04 PM, Trevor Parscal wrote:
>
> > One of the most important points here is about experimenting on users;
> and
>
> > it should be taken seriously. I also believe strongly that, as the author
> > suggests, we should treat editors as colleagues rather than customers.
>
> Yes, agreed. I've articulated my view here:
>
> https://meta.wikimedia.org/w/index.php?title=Experiments&diff=4046416&oldid=4046196
>
> Ori
>
>
> ___
> 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

Re: [Wikitech-l] Wikimedians are rightfully wary

[Trevor Parscal]

That was unfortunate - I've been ridiculed (by Max) for things I've said
before as well, I feel your pain Ori.

That said however, I generally agree with this piece. I have more faith
than the author seems to have that we are on the right track to doing
better work in the future, but the points made are pretty valid. It's
difficult, but very important, to observe mistakes made in the past as to
not repeat those mistakes in the future.

One of the most important points here is about experimenting on users; and
it should be taken seriously. I also believe strongly that, as the author
suggests, we should treat editors as colleagues rather than customers.

It is true that MZ has a tendency to be dramatic, but he's holding back a
lot here to make a rational point, and I hope people don't write this off
because of Max's propensity for being offensive and complaining.

- Trevor



On Tue, Aug 21, 2012 at 11:46 AM, Ori Livneh  wrote:

>
> On Tuesday, August 21, 2012 at 10:10 AM, Tyler Romeo wrote:
> > Hey,
> >
> > Not sure if anybody has seen this article yet:
> >
> https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2012-08-20/Op-ed
> >
> > Thought it was interesting and possibly worth discussion.
> I responded on the talk page[1], taking credit for the elephants quote,
> apologizing for it, and providing a bit of context. I think the context
> changes the meaning and tone of what I wrote considerably. It sucks that it
> is used in this way -- to malign the efforts of my colleagues. Sorry.
>
>   [1]:
> http://en.wikipedia.org/w/index.php?title=Wikipedia_talk%3AWikipedia_Signpost%2F2012-08-20%2FOp-ed&action=historysubmit&diff=508490521&oldid=508490153
>
> --
> Ori Livneh
> o...@wikimedia.org
>
>
>
> ___
> 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

Re: [Wikitech-l] JavaScript mv* framework for MediaWiki?

[Trevor Parscal]

VisualEditor doesn't use a 3rd party framework, mostly because I don't
really believe in them - that's another topic though. Here are some
thoughts on this topic:

   - I suggest you create some classes (JavaScript prototypes) in a
   namespace, such as a global 'WikiData' object (which can be aliased locally
   as 'wd'). These classes can be models, views, or whatever, and instantiated
   with the new keyword.
   - What you do in that namespace is up to you, but there are some normal
   practices that should be adhered to in the MediaWiki coding style
   guidelines on mediawiki.org.
   - As far as creating re-usable views and models, that's a good idea, but
   I doubt you need the bloat and limitation of a framework to do it. You
   should always look at your problem, decide what you need now and might need
   in the future, and build around that. If a framework happens to be useful
   then that might be a good way to go, but I would be careful about using one
   at all.
   - jQuery should be used for all DOM interaction unless performance is a
   concern and then direct DOM methods are acceptable. Bringing in another
   library to modify the DOM is going to be a serious problem.
   - QUnit should be used for all unit tests.

- Trevor

On Tue, Aug 21, 2012 at 11:36 AM, Daniel Werner
wrote:

> Hi everyone,
>
> some of us at Wikidata[1] are currently thinking about the best
> approach to improve the connection between our backend (web API) and
> our JavaScript front-end. What we basically want is to make our data
> model available in the front-end in a broader span. This will allow us
> to go for more decoupled components (model/viewer) but hopefully it
> will also allow gadget developers to fetch, handle, present and store
> data with much less effort.
>
> Since there might be some existing JavaScript frameworks well suited
> for this already, it might be worth considering them for the job.
> Backbone, Spine, Knockout, Serenade or Ember are just a few names out
> of many.
> Has there been any discussion touching this area so far or is this
> even used in some wip MediaWiki project? I could for example imagine
> the Visual Editor requiring some kind of approach going this
> direction... anything?
> I think this is similar to the decision to ship MW together with
> jQuery instead of a similar library. So I guess if we would choose any
> of these frameworks, it should be a lightweight one, allowing for
> great flexibility to reuse this in MW extensions and core, not having
> to introduce another one later which would just mean more confusion
> for new developers and additional load between clients and servers.
>
> In Wikidata, the first thing we would use any of those frameworks
> would be to provide Wikidata Items[2] (or other entities) by fetching
> them via the web-API, allowing modification to those fetched objects
> and then storing all changes made back to the server via the web-API.
> Also see my draft[3] with the idea of introducing a JS prototype for
> Entity/Item as well as FetchedEntity/Item which could probably be
> implemented using one of those frameworks.
>
> This discussion should be both, talking about experience with such
> frameworks as well as dealing with the question whether it would make
> sense to introduce something of this art into core in the near future
> or not.
> Any thoughts on this would be highly appreciated!
>
> Cheers,
> Daniel W.
>
> --
> Daniel Werner
> Software Engineer
>
> Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
> Tel. (030) 219 158 26-0
>
> http://wikimedia.de
>
> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
> Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
> unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das
> Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
>
> ___
> 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

Re: [Wikitech-l] Notification bubble system

[Trevor Parscal]

I support this change, it's a great next step on the design work I put into
https://gerrit.wikimedia.org/**r/#/c/17605/<https://gerrit.wikimedia.org/r/#/c/17605/>
and
seems to be very clever in the way it handles multiple messages.

That said, it's a pretty big change to an area of code that Timo (Krinkle)
has been working on a lot, and he's just left on vacation for a week, so I
am hesitant to merge it without some more scrutiny.

So, if you feel up to scrutinizing, please do.

- Trevor

On Mon, Aug 13, 2012 at 10:18 AM, Daniel Friesen
wrote:

> A little while ago Trevor Parscal changed our jsMessage setup to be a
> floating auto-hiding notification bubble.
> https://gerrit.wikimedia.org/**r/#/c/17605/<https://gerrit.wikimedia.org/r/#/c/17605/>
>
> The end implementation felt half-baked to me. Since it just swapped text
> for notification replacement. And didn't support multiple notifications. It
> even reused the same id as the previous message which was pretty much a
> completely different concept.
>
> So I spent a night implementing a fully featured notification bubble
> system. Something that should work for watchlists, VisualEditor, and
> perhaps some other things like LQT, and perhaps anything we want to start
> making more dynamic. Same goes for anyone with a good Gadget idea that
> could use better notifications.
>
> Here's a demo video of the new notification system:
> https://www.mediawiki.org/**wiki/File:Mw-notification.ogv<https://www.mediawiki.org/wiki/File:Mw-notification.ogv>
>
>
> The changeset is 
> https://gerrit.wikimedia.org/**r/#/c/19199/<https://gerrit.wikimedia.org/r/#/c/19199/>
>
> --
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>
> __**_
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<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

Re: [Wikitech-l] gerrit tab width

[Trevor Parscal]

Sadly the length of lines is a poor measure of the nested-ness of a
program, and sufficiently complex algorithms aren't always better broken
into multiple parts, such as in cases where the loops are very tight and
the function call overhead would be costly.

- Trevor

On Wed, Aug 8, 2012 at 11:09 PM, Dmitriy Sintsov  wrote:

>
>  8 Август 2012 г. 22:43:15 пользователь bawolff (bawolff...@gmail.com)
>> написал:
>>
>>
>>
>> I use 8 :P
>>
>> (Seriously though, everything looks so crunched up with 4 space tab
>> width... Makes me claustrophobic!)
>>
>>  Tab 8 encourages to make less "structural nesting" like foreach( if (
> foreach ( if () ) ) ) in one method, because such lines would become too
> long. Instead there will be large amount of smaller functions / methods.
> But there should be the middle balance between "large method which does a
> lot" and "lots of extremly tiny methods nested calls". Perhaps Tab 4, I do
> not know.
>
> __**_
> 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

Re: [Wikitech-l] gerrit tab width

[Trevor Parscal]

I've always wondered about something:

Given the 2 rules:

   - "Lines should be broken at between 80 and 100 columns."[1]
   - "You should make no assumptions about the number of spaces per tab."[2]

I have a couple of questions:

   - What should we do if someone who uses 1 space tabs writes a 99
   character line (including the tab)?
  - If you are using more than 1 space per tab, you they are breaking
  the 100 column rule.
   - What should we do if someone who uses 8 space tabs tells you that you
   are breaking the 100 column rule?
  - If you are using less than 8 spaces per tab, than you aren't
  breaking the 100 column rule.

I get why there's no value in starting a holy war over spaces-per tab, but
this is a good example of why it's also a problem to not make a decision
one way or another.

This is not hypothetical, we have people on our team (VisualEditor) who use
8, 4 and 3 (that I know of).

- Trevor

[1] http://www.mediawiki.org/wiki/CC#Line_continuation
[2] http://www.mediawiki.org/wiki/CC#Tab_size

On Wed, Aug 8, 2012 at 11:26 AM, Adam Wight  wrote:

> On 08/08/2012 11:07 AM, Mark Holmquist wrote:
>
>> Also, "it should be 4 spaces" is a matter of opinion--everyone likes
>>> different tab widths depending on their preferences and monitor size.
>>>
>>
>> http://www.mediawiki.org/wiki/**CC#Tab_size
>>
>> "you should make no assumptions" appears to support Chad's statement.
>> However, I'm pretty sure that in reality, many people assume a width of 4.
>> I've definitely seen funky tab-plus-space indentations that support that
>> theory.
>>
>>
> I officially redact my bogus claim that it "should" be 4 spaces. However,
> we certainly shouldn't default to 8!
>
>
> (moral authority provided by:
> Cleric: And the Lord spake, saying, "First shalt thou take out the Holy
> Pin. Then shalt thou count to three, no more, no less. Three shall be the
> number thou shalt count, and the number of the counting shall be three.
> Four shalt thou not count, neither count thou two, excepting that thou then
> proceed to three. *Five is right out.* Once the number three, being the
> third number, be reached, then lobbest thou thy Holy Hand Grenade of
> Antioch towards thy foe, who, being naughty in my sight, shall snuff it.)
>
> __**_
> 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

Re: [Wikitech-l] Responsive web design

[Trevor Parscal]

I think a better answer to your question is: "nothing that's been
officially resourced at this time".

We currently have a 2-device strategy, which means we redirect some devices
to a mobile site, and the rest remain at the normal "desktop" site. The
closest thing to responsive design we have in production is the way the
Vector skin adjusts it's layout – if not subtly – if the browser is above
or below a given threshold.

Responsive design is a hot topic, and there are a lot of really exiting
projects in this area right now, but there are also some overlooked issues.
Many mobile devices are amazingly powerful, but sending the same JavaScript
and CSS payloads to all devices still results in a much heavier payload on
smaller less capable devices that in some cases may even cause them to
crash. This can be fixed using a variety of techniques, but it illustrates
how responsive design – when done right – is more than a new skin that
delivers HTML and some CSS, only for all the same extensions, user scripts
and gadgets that were designed with the desktop in mind to pile on and clog
up the "tubes" while wreaking havoc on "simplified" pages presented to
mobile users.

A good example of this problem's unclear solution is how the mobile site
does not load the same extensions, user scripts and styles and gadgets as
the desktop site; and what's more is the issue with the use of inline
styles throughout the site and how difficult it is to deal with on mobile
devices with an alternate – simplified – layout.

All this said, MediaWiki is an open source project and you shouldn't ever
feel the need to wait until something "ships". I would recommend you start
out with an existing skin, tear it down to it's simplest elements, and then
start adding CSS and modifying the HTML output until you have what you are
looking for. If you need some help, this list is a good place to be, but
also make sure and get onto irc.freenode.net #mediawiki where you might be
able to get quick answers to simpler questions.

- Trevor

On Sat, Jul 28, 2012 at 2:11 AM, John Elliot  wrote:

> I don't know who Brandon is. I'm planning on bundling MediaWiki with a
> product of mine and I'd like it to work well with smart phones and other
> mobile devices. I'm not sure that I would have the time or expertise to
> get the Athena theme done by myself and just wanted to know if it was on
> the agenda. Look forward to seeing it when it ships.
>
> On 2012-07-28 08:36, Terry Chay wrote:
> > Are you a Brandon plant trying to get us to resource Athena again? :-)
> >
> > On Jul 27, 2012, at 3:01 AM, John Elliot  wrote:
> >
> >> Are there any initiatives in the MediaWiki community for a MediaWiki
> >> theme that supports 'responsive design' [1] -- where content is properly
> >> laid out in an accessible form on all manner of devices including
> >> desktops and smart phones?
> >>
> >> [1] http://www.alistapart.com/articles/responsive-web-design/
> >>
> >>
> >> ___
> >> 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
> >
>
> ___
> 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

Re: [Wikitech-l] Stance on PHP namespaces?

[Trevor Parscal]

The namespace separator might be ugly, but it's in good company with the
rest of the syntax of PHP.

- Trevor

On Wed, May 16, 2012 at 4:48 PM, Terry Chay  wrote:

>
> On May 16, 2012, at 3:52 PM, Max Semenik wrote:
>
> > Frankly, the namespace syntax in PHP is so atrocitous that I would
> > like to never see namespaces in out code:P
>
>
> Ahh the namespace separator!
>
> https://wiki.php.net/rfc/namespaceseparator
>
> Brings back memories.
>
> Hmm, Now that you mention it maybe we should have used ":P" as the
> namespace separator. ;-)
>
> ( I miss ":)" That would have made PHP a much happier place. It already
> has a lot of money ($), now it just needs some smileys.)
> ___
> 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

Re: [Wikitech-l] Inline styles trouble on the mobile site

[Trevor Parscal]

I think you could use a multi-step process to solve this problem with the
help of the community.

   1. Detect when inline styles are used on a page and add that page to a
   list of pages that might have problems being rendered on mobile.
  1. Make a special page that displays this list and use an edit hook
  to reevaluate if a page should be on or off the list each time someone
  edits it.
  2. Possibly display a progress meter on the page
  3. This information could be surfaced when someone with sufficient
  rights to move the styles to a site style sheet loads the editor on that
  page too.
   2. Provide a guide for how to move inline styles into reusable style in
   the site CSS and how to write special mobile versions of the styles too
   (using something like MediaWiki:Mobile.css for instance)
   3. Set a reasonable timeframe for when the mobile site will begin
   scrubbing inline CSS from pages
   4. Work with the community to reach the goal - as in: don't just dump it
   on them, listen to their suggestions on what might make it easier for them
   to make the switch
   5. Turn on scrubbing

This might take time, but if it's facilitated like this, it can be
accelerated. I think our community will care a lot about mobile access
already, but reminding them of how many page views or unique users we have
on the mobile site already and inviting them to help make the mobile site
even better and more popular would probably help motivate people.

- Trevor

On Fri, Apr 20, 2012 at 11:53 AM, Brion Vibber  wrote:

> On Apr 20, 2012 11:30 AM, "Jon Robson"  wrote:
> > > Especially if this can be combined with 

Re: [Wikitech-l] Lua: return versus print

[Trevor Parscal]

+1 to all the points for using return values.

If we have to implement an output buffer in Lua, we have probably
failed. Output buffering is is messy and prone to error. It's certainly not
a good design from a usability standpoint, and it's generally messy to deal
with.

Template invocations should be the equivalent to calling a pure function.

- Trevor

On Fri, Apr 13, 2012 at 9:31 AM, Platonides  wrote:

> On 13/04/12 16:19, Gabriel Wicke wrote:
> >> Does anyone have any thoughts on return versus print generally? Are
> >> there other reasons we would choose one over the other?
> >
> > From a language perspective, I would much prefer return values instead
> > of side effects, even if those side effects could be converted into a
> > return value with a special print implementation.
>
> I'd also prefer return values. Fits better with wikitext in general.
>
>
> ___
> 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

Re: [Wikitech-l] I'd prefer that you didn't submit this

[Trevor Parscal]

No offense to those who have chimed in, but seriously, this is a silly
discussion.

Do we really have the bandwidth to be 15 messages deep on this thread?

- Trevor

On Thu, Mar 29, 2012 at 5:24 PM, Tim Starling wrote:

> On 29/03/12 00:10, Chad wrote:
> > Hi everyone,
> >
> > There's been some comments that the phrasing for a -1 vote in
> > Gerrit ("I'd prefer that you didn't submit this") is kind of personal
> > and we can do better.
> >
> > I did some testing and this is totally configurable :) It won't change
> > for old comments that were already submitted, but we can pick
> > some nicer wording going forward.
> >
> > I really don't have any good suggestions for this, so I'm opening
> > this up to the list for a bit of good old fashioned bikeshedding.
>
> I don't really want Gerrit putting words into my mouth regardless of
> how nice they sound. There will always be cases where the phrase is
> inappropriate and offputting, regardless of which one you choose.
>
> How about "Set code review score to -1"? Then a more personal message
> can be typed by the human doing the review.
>
> -- Tim Starling
>
>
> ___
> 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

Re: [Wikitech-l] Committing followups: please no --amend

[Trevor Parscal]

Good advice here, but I would just say we should mention that git --amend
is still recommended if you committed something and then realized there was
a mistake.

   - Using it to fix a typo or minor error in a commit = awesome.
   - Using it to pile up tons of changes across tons of files = not awesome.

The former makes review EASIER, the latter makes review HARDER.

- Trevor

On Mon, Mar 26, 2012 at 11:24 PM, Amir E. Aharoni <
amir.ahar...@mail.huji.ac.il> wrote:

> 2012/3/27 Tim Starling :
> > For commits with lots of files, Gerrit's diff interface is too broken
> > to be useful. It does not provide a compact overview of the change
> > which is essential for effective review.
> >
> > Luckily, there are alternatives, specifically local git clients and
> > gitweb. However, these don't work when git's change model is broken by
> > the use of git commit --amend.
> >
> > For commits with a small number of files, such changes are reviewable
> > by the use of the "patch history" table in the diff views. But when
> > there are a large number of files, it becomes difficult to find the
> > files which have changed, and if there are a lot of changed files, to
> > produce a compact combined diff.
> >
> > So if there are no objections, I'm going to change [[Git/Workflow]] to
> > restrict the recommended applications of "git commit --amend", and to
> > recommend plain "git commit" as an alternative. A plain commit seems
> > to work just fine. It gives you a separate commit to analyse with
> > Gerrit, gitweb and client-side tools, and it provides a link to the
> > original change in the "dependencies" section of the change page.
>
> It sounds similar to what i said in the thread "consecutive commits in
> Gerrit‏", so i probably support it, but i don't completely understand
> how will it work with the `git review' command, which doesn't like
> multiple commits. If the documentation will explain how to use `git
> review' with follow up commits, it will be fine.
>
> --
> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> http://aharoni.wordpress.com
> ‪“We're living in pieces,
> I want to live in peace.” – T. Moore‬
>
> ___
> 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

Re: [Wikitech-l] diff colors - more tweaking

[Trevor Parscal]

Erwin,

I changed it to from #f2f2f2 to #f3f3f3, which is the same as Vector uses
on the sidebar and footer. I know it seems subtle, but it's actually
more noticeable than you would expect due to where it falls on a monitor's
gamma curve. Any lighter and many people's monitors will render it as white.

See r113098

- Trevor

On Mon, Mar 5, 2012 at 2:31 PM, Erwin Dokter  wrote:

> On 05-03-2012 20:51, Trevor Parscal wrote:
>
>> Erwin,
>>
>> I'm happy to continue working with you on this if you have more ideas.
>> Please don't just give up because the process isn't perfect. It's our
>> responsibility together as a community to continue improving it. I'm sorry
>> if you haven't had a great experience so far with this. I am personally
>> very pleased that someone (like you) is being persistent enough to get
>> this
>> matter some attention. MediaWiki's diff view has been a blight for ages,
>> and I think we are getting really close to something solid.
>>
>
> It's just a bit frustrating. Development cycles are long, communication is
> slow and decentralized.
>
>
>  I took your input, as well as that of others, and have submitted r113071
>> which I feel is the best version yet. See
>> https://bugzilla.wikimedia.**org/show_bug.cgi?id=11374#c45<https://bugzilla.wikimedia.org/show_bug.cgi?id=11374#c45>for
>>  screenshots of
>> how this looks in a variety of scenarios.
>>
>
> That looks very nice. No more diffchange borders then. I hope it still
> meets the accesability rules. Only thing I would change is make the gray
> background slightly lighter.
>
> Is this planned to be rolled out, or are we waiting for 1.20? (In which
> case I can update the new diff gadget once the design is done.)
>
>
> --
> Erwin Dokter
>
>
> __**_
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<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

Re: [Wikitech-l] diff colors - more tweaking

[Trevor Parscal]

Erwin,

I'm happy to continue working with you on this if you have more ideas.
Please don't just give up because the process isn't perfect. It's our
responsibility together as a community to continue improving it. I'm sorry
if you haven't had a great experience so far with this. I am personally
very pleased that someone (like you) is being persistent enough to get this
matter some attention. MediaWiki's diff view has been a blight for ages,
and I think we are getting really close to something solid.

I took your input, as well as that of others, and have submitted r113071
which I feel is the best version yet. See
https://bugzilla.wikimedia.org/show_bug.cgi?id=11374#c45 for screenshots of
how this looks in a variety of scenarios.

- Trevor

On Mon, Mar 5, 2012 at 11:30 AM, Erwin Dokter  wrote:

> On 05-03-2012 20:10, Rob Lanphier wrote:
>
>> Hi Erwin,
>>
>> The change to diff blocks is an interesting idea.  Could you submit a
>> patch for this?  (either on list or in the bug)
>>
>> The different text highlighting style seems more controversial, so it
>> might be better to keep that separate.
>>
>> Rob
>>
>
> I'm not submitting any more patches until there is some consensus.
> Apparently, my last submission blew up on IRC due to 'complaints' and was
> reverted as a result. Meanwhile, my current proposal seems to be ignored by
> those involved, so I'd really like some feedback.
>
> My current diff CSS can be found in my vector.css on enwki (
> http://en.wikipedia.org/wiki/**User:Edokter/vector.css
> ).
>
>
> --
> Erwin Dokter
>
>
> __**_
> 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

Re: [Wikitech-l] diff colors

[Trevor Parscal]

As I've said eslewhere, using top/bottom borders is a problem with long
changes (not shown in his screenshot) and should be avoided. The original
design (r112836) had this flaw, and was later fixed (r112853).

The spacing issues need attention for sure, I will look at them today.

- Trevor

On Sat, Mar 3, 2012 at 8:15 PM, Steven Walling wrote:

> On Thursday, March 1, 2012, Trevor Parscal  wrote:
> > I've gone ahead and resolved bug #11374 after committing r112836.
> >
> > Screenshot of new diff styles:
> > https://bugzilla.wikimedia.org/attachment.cgi?id=10148
> >
> > Brandon and I talked about the colors and the way color-blind people will
> > perceive them - this color set provides the best cross-cultural and
> > accessible approach so far. The design also improves contrast issues and
> > draw attention to the changed portions better than any previous versions.
> >
> > - Trevor
>
> I *really* like this design. Much better than the current diff style, and
> not just for the color blind. ;-) Accentuating changed phrases more
> strongly and removing color where unnecessary makes it much easier to scan
> a diff.
>
> Just my 2 cents,
>
> Steven
> ___
> 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

Re: [Wikitech-l] diff colors - Chrome bug

[Trevor Parscal]

Adding the borders to top/bottom is not a good thing though, because long
changes result in ugly rendering with lots of parallel lines. I will look
into the padding issue.

- Trevor

On Sat, Mar 3, 2012 at 1:33 AM, Erwin Dokter  wrote:

> On 03-03-2012 09:35, Erwin Dokter wrote:
>
>> The red font color was the only conflicting style. The misalignment is
>> apparently a result of Chrome not handling the combined padding of the
>> table cell and diffchange spans that contain one or more Tabs.
>>
>
> To be more precise: any left-or right padding or border of the .diffchange
> will throw off the horizontal alignment in Chrome. The cell padding has no
> effect.
>
> This can be fixed by moving the borders to top/bottom and removing any
> left/right padding from .diffchange.
>
>
> --
> Erwin Dokter
>
>
> __**_
> 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

Re: [Wikitech-l] diff colors

[Trevor Parscal]

Erwin - what you are seeing is very strange. I tried to re-create it, but
you have other styles conflicting and causing problems. For instance, the
use of red text for the changed text is gone int he latest code. You may
also have other strange styles which may be affecting layout. Attached is
how that changeset looked on my localhost.

- Trevor
On Fri, Mar 2, 2012 at 2:59 PM, Erwin Dokter  wrote:

> On 02-03-2012 23:31, Antoine Musso wrote:
>
>> Le 01/03/12 22:38, Trevor Parscal a écrit :
>>
>>> I've gone ahead and resolved bug #11374 after committing r112836.
>>>
>>> Screenshot of new diff styles:
>>> https://bugzilla.wikimedia.**org/attachment.cgi?id=10148<https://bugzilla.wikimedia.org/attachment.cgi?id=10148>
>>>
>>> Brandon and I talked about the colors and the way color-blind people will
>>> perceive them - this color set provides the best cross-cultural and
>>> accessible approach so far. The design also improves contrast issues and
>>> draw attention to the changed portions better than any previous versions.
>>>
>>
>> I must say you rocks. This make the diff page more pleasant to use and
>> give it a modern taste.
>>
>> Thanks 8-)
>>
>
> I do have some issues. I like the general design, but spacing needs
> serious tweaking; there is too much space around the text. The outer border
> causes mis-alignment of text. And the borders for .diffchange overlaps text
> between two changes (1) (this could be solved by using top/bottom border
> only).
>
> (1) 
> http://commons.wikimedia.org/**wiki/File:Diffs-r112853.png<http://commons.wikimedia.org/wiki/File:Diffs-r112853.png>
>
> --
> Erwin Dokter
>
>
>
> __**_
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<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

Re: [Wikitech-l] diff colors

[Trevor Parscal]

It's hipster lorem ipsum.

http://hipsteripsum.me/

- Trevor

On Thu, Mar 1, 2012 at 1:43 PM, David Gerard  wrote:

> On 1 March 2012 21:38, Trevor Parscal  wrote:
>
> > Screenshot of new diff styles:
> > https://bugzilla.wikimedia.org/attachment.cgi?id=10148
>
>
> I gotta ask - where's the lorem ipsum from?
>
>
> - d.
>
> ___
> 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