[Wikitech-l] Re: Frontend stable policy: Making it official

[Jon Robson]

Hey all
A month has passed since my last e-mail and while I received lots of
feedback (mainly relating to the structure and readability of the document)
there were no concerns about making this official and I have thus made the
page official.

If you work on extensions or MediaWiki core, please read through the
changes outlined below, and have a look at the policy page at
<https://www.mediawiki.org/wiki/Stable_interface_policy/frontend>.

Given the substantial edits to the page itself to change structure and
readability (but not meaning) please review the open topics on the talk
page: <https://www.mediawiki.org/wiki/Talk:Stable_interface_policy/frontend>
This document is intended to be a living document that evolves with our
shared needs over time, so this should not be seen as a perfect finalized
document.

I hope this helps provide Wikimedia sites with a healthier ecosystem,
particularly for gadget developers. Thanks to all those who have engaged in
this process over the last two years [1] and special thanks to Amir
Sarabandi for help relating to its roll-out.

Jon

[1] Note: In my original email I mistakenly said that we had been working
on it for 3 years.


On Fri, Aug 11, 2023 at 4:28 PM Jon Robson  wrote:

> Dear fellow developers! If you don't work on gadgets or Wikimedia code,
> feel free to ignore this email!
>
> For some time we've had the Stable interface policy which has been super
> helpful for backend-development. I would love us to have an equivalent for
> frontend code.
>
> For the past 3 years we have been building one with feedback and
> suggestions from gadget developers, WMF staff and Wikimedia volunteers. The
> current draft can be found at:
>
> https://www.mediawiki.org/wiki/User:Jdlrobson/Stable_interface_policy/frontend
>
> I would like to make this policy official so that we can get the benefits
> of having a document and continue to evolve it in a more official capacity.
>
> If anyone wants to veto this, I'd like to hear from you on the talk page
> or by a reply to this email (either privately or publicly). When making a
> veto please make that explicit and include the text you find problematic
> and details about why.
>
> If there is no active veto after one month, this policy will be made
> official and moved to
> https://www.mediawiki.org/wiki/Stable_interface_policy/frontend.
>
> Thanks in advance for all your help with this important matter!
>
> Jon Robson
> PS. This note has also been sent to tech news.
>
>
> ___
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Frontend stable policy: Making it official

[Jon Robson]

Dear fellow developers! If you don't work on gadgets or Wikimedia code,
feel free to ignore this email!

For some time we've had the Stable interface policy which has been super
helpful for backend-development. I would love us to have an equivalent for
frontend code.

For the past 3 years we have been building one with feedback and
suggestions from gadget developers, WMF staff and Wikimedia volunteers. The
current draft can be found at:
https://www.mediawiki.org/wiki/User:Jdlrobson/Stable_interface_policy/frontend

I would like to make this policy official so that we can get the benefits
of having a document and continue to evolve it in a more official capacity.

If anyone wants to veto this, I'd like to hear from you on the talk page or
by a reply to this email (either privately or publicly). When making a veto
please make that explicit and include the text you find problematic and
details about why.

If there is no active veto after one month, this policy will be made
official and moved to
https://www.mediawiki.org/wiki/Stable_interface_policy/frontend.

Thanks in advance for all your help with this important matter!

Jon Robson
PS. This note has also been sent to tech news.
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] All modules should load on both mobile and desktop target

[Jon Robson]

{If you do not work on MediaWiki extensions or skins on Gerrit you can
safely ignore this email.}

If you are seeing this error in CI you will need to update your
ResourceModule definitions inside skin.json or extension.json to remove any
targets key in objects. If your code needs to be restricted to the Minerva
skin or all mobile skins please see
https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_for_extension_developers#Target_system
for information.

This effectively marks the beginning of the end of the MobileFrontend
target system which has served us well for the last decade but has become
more of a nuisance as our codebases have matured meaning many new features
have not been enabled on the mobile site either intentionally or
accidentally.  For more information around motivation at
https://phabricator.wikimedia.org/T127268. A test failure will now be
triggered for code trying to limit where code is loaded using this
mechanism.

If you are a developer with ResourceLoader module definitions that define
targets: [mobile,desktop] you can and should safely remove those.

Note, targets (for now) will continue to work in gadgets but may not in
future. Please join the conversation at
https://phabricator.wikimedia.org/T328610

Thanks for reading! Please feel free to reply with any questions.
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: ODP: PSA: ResourceLoader modules now default to mobile and desktop in 1.40

[Jon Robson]

Hi Marcin thanks for the question!

For now gadgets will still work as before. However on the long term please
see https://phabricator.wikimedia.org/T328610 where we are starting to make
preparations for changing that in future!

On Wed, Feb 1, 2023, 2:29 AM Marcin Szwarc  wrote:

> Hi,
>
>
>
> Does this change affect on-wiki gadgets as well? They do have an option to
> specify the target in the definition (and it’s „desktop” by default).
>
>
>
> User:Msz2001
>
>
>
>
>
> *Od: *Jon Robson 
> *Wysłano: *środa, 1 lutego 2023 00:47
> *Do: *Wikimedia developers 
> *Temat: *[Wikitech-l] PSA: ResourceLoader modules now default to mobile
> and desktop in 1.40
>
>
>
> TLDR: Any ResourceLoader module will now run on mobile or desktop site by
> default. Previously they would only load on the desktop site.
>
>
>
> Hopefully this goes without disruption, but to be safe, if you maintain
> code used in Wikimedia production, please:
>
> 1) check your experiences over the course of this week in mobile/desktop
> site for JS errors/obvious UI errors (the former will be detected and
> monitored via logstash)
> 2) check that your repository doesn't fail the core
> testUnsatisfiableDependencies PHPUnit test. 3) Please check out the
> following Phabricator tickets to see if you are impacted on the long term
> [4][5].
>
>
>
> # Background
>
>
>
> Back in the early days of MobileFrontend, most of the JavaScript we had
> was not mobile friendly. To avoid this we created an allow-list system,
> where JavaScript was disabled by default and extensions/skins had to
> explicitly enable it by adding a "targets" property to their
> ResourceLoaderModule definition.
>
>
>
> This was meant as a short term solution, but as with many things,
> attention got pulled elsewhere, and almost ten years later it was still
> there.
>
>
>
> There have been many complaints about this over those years. Mainly:
>
> 1) It means we have split the ResourceLoader cache further
>
> 2) It's not intuitive - new code was getting shipped to desktop only
> experiences by default.
>
> It also featured on the Developer Wishlist of 2017 at #34 [1].
>
> 3) Many older features don't work for community members for no credible
> reason.
>
>
>
> # Recent developments
>
>
>
> As one of the few remaining people responsible for doing this in the first
> time, I felt obliged to spend some time over December trying to pay off
> this technical debt. I audited code that was being removed by the targets
> system [2] and made the target explicit. Where modules were problematic on
> mobile, we marked them in such a way that it was clear that they should
> only run in a certain mode. This was only possible thanks to attention from
> Amir, Santosh, Thiemo, Lucas W, Tpt, Sohom D, Bartosz - thank you all.
>
>
> Today, Roan merged a change that makes ResourceLoader modules default to
> the desktop AND mobile sites. This should be a harmless change, but may be
> unintentionally triggering failures in testUnsatisfiableDependencies tests
> as it seems some extension/skins are not included in the MediaWiki core
> PHPUnit test run. If you encounter this issue, the fix is relatively simple
> - you must define targets explicitly (see this example [6] and apologies in
> advance for any annoyance this may cause)
>
>
>
> # For action
>
>
>
> Please take extra care with your code that you test on both mobile/desktop
> sites and at mobile/desktop breakpoints. It's still possible to ship code
> to mobile/desktop and see these guidelines [3] if you need to do that or
> reply to this email with any questions you have.
>
>
>
> # Next steps
>
>
>
> This change will help with limiting the targets system to existing known
> cases. This has been a long term request of the performance team. Please
> see the follow up tickets to see if there is any action from you at your
> leisure [4][5].
>
>
>
> [1] https://www.mediawiki.org/wiki/Developer_Wishlist/2017/results
>
> [2] in https://phabricator.wikimedia.org/T324723
>
> [3]
> https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_for_extension_developers#Target_system
>
> [4] https://phabricator.wikimedia.org/T328497
>
> [5] https://phabricator.wikimedia.org/T328498
>
> [6]
> https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PropertySuggester/+/885432/
>
>
>
>
> ___
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] PSA: ResourceLoader modules now default to mobile and desktop in 1.40

[Jon Robson]

TLDR: Any ResourceLoader module will now run on mobile or desktop site by
default. Previously they would only load on the desktop site.

Hopefully this goes without disruption, but to be safe, if you maintain
code used in Wikimedia production, please:
1) check your experiences over the course of this week in mobile/desktop
site for JS errors/obvious UI errors (the former will be detected and
monitored via logstash)
2) check that your repository doesn't fail the core
testUnsatisfiableDependencies PHPUnit test. 3) Please check out the
following Phabricator tickets to see if you are impacted on the long term
[4][5].

# Background

Back in the early days of MobileFrontend, most of the JavaScript we had was
not mobile friendly. To avoid this we created an allow-list system, where
JavaScript was disabled by default and extensions/skins had to explicitly
enable it by adding a "targets" property to their ResourceLoaderModule
definition.

This was meant as a short term solution, but as with many things, attention
got pulled elsewhere, and almost ten years later it was still there.

There have been many complaints about this over those years. Mainly:
1) It means we have split the ResourceLoader cache further
2) It's not intuitive - new code was getting shipped to desktop only
experiences by default.
It also featured on the Developer Wishlist of 2017 at #34 [1].
3) Many older features don't work for community members for no credible
reason.

# Recent developments

As one of the few remaining people responsible for doing this in the first
time, I felt obliged to spend some time over December trying to pay off
this technical debt. I audited code that was being removed by the targets
system [2] and made the target explicit. Where modules were problematic on
mobile, we marked them in such a way that it was clear that they should
only run in a certain mode. This was only possible thanks to attention from
Amir, Santosh, Thiemo, Lucas W, Tpt, Sohom D, Bartosz - thank you all.

Today, Roan merged a change that makes ResourceLoader modules default to
the desktop AND mobile sites. This should be a harmless change, but may be
unintentionally triggering failures in testUnsatisfiableDependencies tests
as it seems some extension/skins are not included in the MediaWiki core
PHPUnit test run. If you encounter this issue, the fix is relatively simple
- you must define targets explicitly (see this example [6] and apologies in
advance for any annoyance this may cause)

# For action

Please take extra care with your code that you test on both mobile/desktop
sites and at mobile/desktop breakpoints. It's still possible to ship code
to mobile/desktop and see these guidelines [3] if you need to do that or
reply to this email with any questions you have.

# Next steps

This change will help with limiting the targets system to existing known
cases. This has been a long term request of the performance team. Please
see the follow up tickets to see if there is any action from you at your
leisure [4][5].

[1] https://www.mediawiki.org/wiki/Developer_Wishlist/2017/results
[2] in https://phabricator.wikimedia.org/T324723
[3]
https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_for_extension_developers#Target_system
[4] https://phabricator.wikimedia.org/T328497
[5] https://phabricator.wikimedia.org/T328498
[6]
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PropertySuggester/+/885432/
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: Feedback needed: Draft gadget/user script policy

[Jon Robson]

Hey all
Thank you to everyone who has provided feedback on this important topic.
The deadline for feedback has passed, but the document is a wiki page so
feedback is always welcome and this document should continue to evolve.

I am hoping to formalize this document over the next three months and work
with WMF staff to get this over the finish line. You can subscribe to
https://phabricator.wikimedia.org/T311891 if you are interested in keeping
track of developments here.

Hope everyone has a great weekend
Jon

On Wed, May 18, 2022 at 9:05 AM Jon Robson  wrote:

> [If you don't write gadgets, user scripts or work on MediaWiki code feel
> free to ignore this message]
>
> Hey all!
>
> Given the hackathon this weekend, now seemed like a good idea to talk
> about us having a policy for code we write for gadget and user scripts
> developers and as gadget and user script developers. TDLR: I am proposing a
> policy to guide developers and authors of these kinds of scripts. I would
> like people to read through my first draft
> <https://www.mediawiki.org/wiki/User:Jdlrobson/Extension:Gadget/Policy#Policy_(draft)>
> [1] and give me feedback on the talk page. Please feel free to share on
> wiki.
>
>
> *What is being proposed*
>
> A policy page that would be editable on wiki and linked to from the
> editing interfaces on gadgets, to guide both parties on how to write code
> that's sustainable and less prone to breakage.
>
> *Why is this needed?*
>
> Despite gadgets and user scripts (which will be referred from now on as
> wiki-based code) being a key component of MediaWiki projects, up until now
> frontend APIs (e.g. how wiki-based code should interact with source control
> provided code) have been ill-defined leading to misunderstandings between
> engineers and wiki-based code developers when wiki-based code break. This
> also leads to code rot, where developers do not feel empowered to make
> changes as it's unclear how their changes will impact wiki-based code
> developers. On top of this, when wiki-based code breaks it's not clear who
> can and will fix them.
>
> To solve this a policy I have been pushing for some time to make the
> contract between MediaWiki developers and wiki-based code developers
> explicit and less confusing.
>
> I hope on the long run a policy would restore trust and good faith between
> the two parties.
>
> *How can you help?*
>
> To contribute to the policy please use the discussion page to raise
> concerns, suggestions, removals or additions.
>
> *What's the deadline?*
>
> I'd like to have all feedback gathered by 30th May 2022
> [1]
> https://www.mediawiki.org/wiki/User:Jdlrobson/Extension:Gadget/Policy#Policy_(draft)
>
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Feedback needed: Draft gadget/user script policy

[Jon Robson]

[If you don't write gadgets, user scripts or work on MediaWiki code feel
free to ignore this message]

Hey all!

Given the hackathon this weekend, now seemed like a good idea to talk about
us having a policy for code we write for gadget and user scripts developers
and as gadget and user script developers. TDLR: I am proposing a policy to
guide developers and authors of these kinds of scripts. I would like people
to read through my first draft

[1] and give me feedback on the talk page. Please feel free to share on
wiki.


*What is being proposed*

A policy page that would be editable on wiki and linked to from the editing
interfaces on gadgets, to guide both parties on how to write code that's
sustainable and less prone to breakage.

*Why is this needed?*

Despite gadgets and user scripts (which will be referred from now on as
wiki-based code) being a key component of MediaWiki projects, up until now
frontend APIs (e.g. how wiki-based code should interact with source control
provided code) have been ill-defined leading to misunderstandings between
engineers and wiki-based code developers when wiki-based code break. This
also leads to code rot, where developers do not feel empowered to make
changes as it's unclear how their changes will impact wiki-based code
developers. On top of this, when wiki-based code breaks it's not clear who
can and will fix them.

To solve this a policy I have been pushing for some time to make the
contract between MediaWiki developers and wiki-based code developers
explicit and less confusing.

I hope on the long run a policy would restore trust and good faith between
the two parties.

*How can you help?*

To contribute to the policy please use the discussion page to raise
concerns, suggestions, removals or additions.

*What's the deadline?*

I'd like to have all feedback gathered by 30th May 2022
[1]
https://www.mediawiki.org/wiki/User:Jdlrobson/Extension:Gadget/Policy#Policy_(draft)
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Policy for on wiki JavaScript

[Jon Robson]

Despite the importance of on-wiki code (gadgets, site scripts and user
scripts) to our projects, there are no guidelines on how to write code in
skins, extensions in a way that supports these users.

The lack of guidelines historically has created unnecessary conflict
between editors and Wikimedia developers. For example, the common task of
changing a class name can cause havoc with certain gadgets that depend on
associated styles.

Another significant pain point, is now that we are tracking JavaScript
errors across our projects, broken gadgets have become more of a problem,
as they make it harder for us to find and triage errors in existing user
workflows.

I have spoken to various developers across MediaWiki extensions and it
seems pretty clear to me that a policy would be helpful for establishing
expected norms.

I've begun drafting a policy based on the discussions I've been having with
Wikimedia engineers on:
 https://www.mediawiki.org/wiki/User:Jdlrobson/Extension:Gadget/Policy and
am inviting *Wikimedia developers who build skins or extensions, and gadget
developers* to engage in the existing talk page topics and bring up new
topics. You can also reply directly to me, either personally or publically
if you have any feedback you want me to consider.

Thanks in advance for your participation in this process.
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: Minerva Neue skin will be bundled with MediaWiki 1.38

[Jon Robson]

Thanks for asking. I've started
https://www.mediawiki.org/wiki/Skin:Minerva_Neue#I_maintain_an_extension,_how_can_I_integrate_with_Minerva
?
I encourage any further questions on the talk page to make sure that has
the appropriate information.

On the subject of menus specifically, we're currently working towards hard
deprecating both MobileMenu and PersonalUrls hooks in favor of
https://www.mediawiki.org/wiki/Manual:Hooks/SkinTemplateNavigation::Universal
to centralize menu modification. Please note, if you are writing new code,
to use SkinTemplateNavigation::Universal (it supports PersonalUrls since
1.36 and I am hoping it will provide an alternative to MobileMenu in 1.38
or 1.39)


On Fri, Jan 7, 2022 at 11:56 PM Gergő Tisza  wrote:

> On Fri, Jan 7, 2022 at 12:09 PM Jon Robson  wrote:
>
>> The implication of this is that extension developers should be making
>> sure their code compatible with MinervaNeue.
>>
>
> Is there a tutorial on what should be done to ensure compatibility?
> (One thing that comes to mind is supporting the MobileMenu hook as an
> alternative to PersonalUrls.)
> ___
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Minerva Neue skin will be bundled with MediaWiki 1.38

[Jon Robson]

If you are not an extension developer, you can safely ignore this message.

I am excited to announce that the Minerva Neue skin will be bundled with
MediaWiki in 1.38 per https://phabricator.wikimedia.org/T191743

The Minerva Neue skin powers the mobile site of Wikimedia projects, so it
makes sense to include this skin for 3rd party MediaWiki instances that
want a responsive but simplified experience.

The implication of this is that extension developers should be making sure
their code compatible with MinervaNeue.

Note, that Minerva Neue operates in two modes (a desktop or mobile mode)
depending on whether MobileFrontend is installed, however, MobileFrontend
is still not part of the MediaWiki bundle so this mode doesn't need to be
tested at this point.

You can tell if you are in Minerva desktop mode by testing in an incognito
window and verifying that you see a more (ellipsis) dropdown in the toolbar.
e.g. Test on https://en.wikipedia.org/wiki/Minerva?useskin=minerva NOT
https://en.m.wikipedia.org/wiki/Minerva?useskin=minerva

if you have any questions or concerns please feel free to reply to this
e-mail or the Phabricator ticket.

Thanks for reading!
Jon
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Removal of $wgUseCategoryBrowser configuration flag

[Jon Robson]

MediaWiki has an experimental configuration flag $wgUseCategoryBrowser that
alters the appearance of categories. If you don't use this flag or are not
aware of it you can safely ignore this message.

We plan to remove  this configuration flag and associated code in MediaWiki
1.38 without deprecation warnings given its experimental nature:
https://phabricator.wikimedia.org/T298553

If needed an extension can provide the same functionality, so if anyone
needs this functionality please let us know by replying to this email or
the Phabricator ticket to help guide us better.

Thanks for reading
Jon
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] MediaWiki skins (another call to action)

[Jon Robson]

Exactly a year ago today, we had 55 usable skins for MediaWiki [1]. Now, we
have a much more healthy 79.  There are >= 23 skins that used to work with
MediaWiki that no longer do. This week 5 skins were added thanks to
https://www.mediawiki.org/wiki/Skin:Bluelib being added to MediaWiki.org !
All usable skins are all showcased on https://skins.wmflabs.org

I believe that the more skins MediaWiki supports, the more vibrant our
ecosystem can be for developers and end-users. I dream of a world where not
every MediaWiki instance looks like an instance of Wikipedia.

In 2022, the work being done on
https://mediawiki.org/wiki/Desktop_improvements will see the number of
usable skins rise to at least 80 skins and I am personally exploring a
script that converts WordPress themes [2] into MediaWiki skins that should
add another 10 skins at least (Feel free to message me offline if you want
to talk more about this ).

However, there is still much work to be done if we want to have a healthy
skin ecosystem!

* 13 of these 79 skins are throwing deprecation warnings, meaning they may
break in future MediaWiki versions [3]. Please help get those patched!
* Fix an unstable skin! We have 9 skins that do not work on the current
MediaWiki master. Can you help fix one of them? [4]
* Make a new skin! Skin development has changed a lot in the last 2 years.
It is more constrained and does not require knowledge of PHP. Take our
documentation [5] for a spin and see if you can create one and let us know
where the documentation can be improved and the limitations that you ran
into with the platform while building them [6]. Check out the online skin
builder tool if you haven't already. [7]
* Improve the mediawiki.org documentation! Add screenshots, add links,
translate a skin.. anything that might help someone use a skin.
* Write a patch to help improve the core skin architecture where a patch is
welcome [8]

Wishing everyone a happy holiday and happy skin-building.

[1]
https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/message/BUH4UIX4EJB4ACEN3OQTZODPFSLGBQH5/
<https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/message/BUH4UIX4EJB4ACEN3OQTZODPFSLGBQH5/>
[2] https://wordpress.org/themes/
[3] https://www.mediawiki.org/wiki/Category:Skins_using_deprecated_features
[4] https://mediawiki.org/wiki/Category:Unstable_skins
[5] https://www.mediawiki.org/wiki/Manual:How_to_make_a_MediaWiki_skin
[6] https://phabricator.wikimedia.org/project/board/4795
[7] https://skins.wmflabs.org/#/add
[8]
https://phabricator.wikimedia.org/project/board/4795/?filter=bGQ_G2ii8IJ7

On Sat, Dec 18, 2021 at 4:11 PM Jon Robson  wrote:

> Only skins now that cannot  be previewerd
>
> Check out https://github.com/Steffo99/mediawiki-skins-Bluelib
>
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Invite to explore code ownership in MediaWiki core

[Jon Robson]

The most recent developer satisfaction survey supports the claim that
volunteers find it hard to get code reviews. The hypothesis is that by
having clearer ownership around code, there should be clearer
accountability, and it should be clearer what code lacks ownership that
probably should.

This also applies to Wikimedia staff.  It's often not clear when needing to
make changes to core, who is the best person to talk to about that code,
and who should be responsible/accountable/consulted/informed about any
changes to the code.

I am involved in the development of the Desktop improvements project [1]
and when we began the work there was no recognized owner for a lot of the
skin code in core. Since then my team has taken the role of maintainer and
it has allowed us to drive a lot of changes. I'm seeing new skins pop up
and we have started hearing from skin engineers, so I feel this has been a
positive thing. However, as we've navigated other parts of the codebase,
we've had to ask a lot of questions such as "Who maintains the legacy
parser? Are they open to changes there, or should that code be considered
frozen?"; "Who should we talk to about changes relating to the JavaScript
of the watchstar?"

What with the proposed move to Gitlab, I  have been very interested in the
code owners file documented on their site [2]

I hypothesize that identifying code owners and getting Wikimedia
engineering to agree to some basic expectations around code ownership might
go a long way to helping set expectations around who to talk to about
making changes, and actually getting those changes carried to completion.

The experiment of adding an OWNERS file to MediaWiki core seems like a
cheap one, given if we find it does nothing the file can easily be removed.

If you are interested in helping me explore this, feel free to join the
conversation on https://gerrit.wikimedia.org/r/c/mediawiki/core/+/745946

Wishing everyone a happy holiday
Jon

[1] mediawiki.org/wiki/Desktop_improvements
[2] https://docs.gitlab.com/ee/user/project/code_owners.html
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: Fwd: Re: Code coverage for JavaScript testing?

[Jon Robson]

I recommend using Jest  for unit
testing with code coverage.

In various Vue.js extensions including NearbyPages
 we use Jest
which is recommended by the Vue.js migration team.

An alternative approach is to use QUnit. In MobileFrontend and Popups we
use a command line version of QUnit. It’s not tied to Webpack in any way
despite the title (it would work with packageFiles these days). (
https://mediawiki.org/wiki/User:Jdlrobson/Developing_with_Webpack_and_ResourceLoader#Writing_unit_tests_and_getting_code_coverage_reports
)

When using command line unit testing you'll need to use
@wikimedia/mw-node-qunit  for
providing a mock MediaWiki environment. Despite the name this library can
be used with Jest (see NearbyPages for an example).

Hope this is helpful!

On Wed, Oct 27, 2021 at 7:51 AM planetenxin  wrote:

>
> Hi Greg,
>
> actually I'm more interested in creating the coverage reports on a local
> dev box in the context of extension development / local CI (checking the
> coverage of newly created JS tests). I did find info about running JS tests
> but little to nothing about coverage. Maybe I missed something.
>
> /Alexander
>
> Am 27.10.2021 um 01:37 schrieb Greg Grossmeier:
> > On Tue, Oct 26, 2021 at 2:31 AM planetenxin  planeten...@web.de>> wrote:
> >
> > Is there a generic approach, how to get some coverage reports for
> the JavaScript parts of MW and MW extensions?
> >
> >
> > Is https://doc.wikimedia.org/cover/ 
> helpful in your case?
> >
> > --
> > | Greg Grossmeier  GPG: B2FA 27B1 F7EB D327 6B8E |
> > | Dir. Engineering Productivity A18D 1138 8E47 FAC8 1C7D |
> ___
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: Why does the train start on Tuesday?

[Jon Robson]

Thanks all for the interesting discussion.
I think the  most immediate actionable here is expanding group 1 wikis, so
I'm looking into that here https://phabricator.wikimedia.org/T286664.
Ideally, it's my belief that 2 top ten wikis that are not English would
give us the visibility of problems with UI changes that we need.

Some thoughts that come to mind:
* What if group 0 and 1 were merged? How would that impact the train? From
the data for the last 153 trains it seems those usually capture the
majority of our issues. It wouldn't help capturing issues in group 2, but
it would give more of a buffer to fix them.
* What if group 0 happened after the security window on a Monday? Would
that be too stressful/not feasible for those involved?

For me, regarding backporting on Fridays, ideally, as an engineer I
appreciate a buffer going into the weekend to reduce any anxiety around my
work having incapacitated our editors in some way. Deploying code on
Friday's only increases that anxiety in some cases.



On Tue, Jun 22, 2021 at 3:09 PM Jon Robson  wrote:

> Thanks for all the input so far.
>
> On Tue, Jun 22, 2021 at 2:41 PM Amir Sarabadani 
> wrote:
>
>> Jon, I think you're misunderstanding the point of the "No Deployment on
>> Friday" policy.
>>
>
> I don't think I'm misunderstanding the policy? I'm talking explicitly
> about high priority issues UI regressions, not unbreak now (ie. site is
> still functional but styled incorrectly e.g. imagine a link is the wrong
> color). I've used Friday deployments historically, but only for really
> really bad issues.
>
> To give an example, if an icon is visually overlapping text I don't
> consider that an UBN, I consider that unfortunate. If the icon overlap is
> on the edit icon and that's not clickable, definitely UBN and I'm happy to
> go the extra lengths to get a Friday patch out.
>
> I understand the Friday is a buffer, but it's not a great buffer,
> particularly now at the Wikimedia foundation most people observe "Silent
> Fridays", and many people in teams that are involved in decision making
> work in different timezones. Side note what constitutes a UBN UI regression
> is being discussed on the talk page [1].
>
> > Regarding Catalan and Hebrew Wikipedia, the other Amir said it well, I
> don't think I have much to add beside the fact that I have personally seen
> them finding major issues before they hit all Wikipedia languages many
> times, more than I can count.
>
> Apologies if I didn't make myself clear, but it seems I didn't given both
> Amir's comments. I am very happy that we have these, and my question was *not
> *why do we have them, but rather* why do we only have 2*. I want more of
> them and every time I've asked why we don't have more, I've been told it's
> a community decision and that seems odd to me.
>
>
> [1] https://wikitech.wikimedia.org/wiki/Talk:Deployments/Holding_the_train
>
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: Why does the train start on Tuesday?

[Jon Robson]

Thanks for all the input so far.

On Tue, Jun 22, 2021 at 2:41 PM Amir Sarabadani  wrote:

> Jon, I think you're misunderstanding the point of the "No Deployment on
> Friday" policy.
>

I don't think I'm misunderstanding the policy? I'm talking explicitly about
high priority issues UI regressions, not unbreak now (ie. site is still
functional but styled incorrectly e.g. imagine a link is the wrong color).
I've used Friday deployments historically, but only for really really bad
issues.

To give an example, if an icon is visually overlapping text I don't
consider that an UBN, I consider that unfortunate. If the icon overlap is
on the edit icon and that's not clickable, definitely UBN and I'm happy to
go the extra lengths to get a Friday patch out.

I understand the Friday is a buffer, but it's not a great buffer,
particularly now at the Wikimedia foundation most people observe "Silent
Fridays", and many people in teams that are involved in decision making
work in different timezones. Side note what constitutes a UBN UI regression
is being discussed on the talk page [1].

> Regarding Catalan and Hebrew Wikipedia, the other Amir said it well, I
don't think I have much to add beside the fact that I have personally seen
them finding major issues before they hit all Wikipedia languages many
times, more than I can count.

Apologies if I didn't make myself clear, but it seems I didn't given both
Amir's comments. I am very happy that we have these, and my question was *not
*why do we have them, but rather* why do we only have 2*. I want more of
them and every time I've asked why we don't have more, I've been told it's
a community decision and that seems odd to me.


[1] https://wikitech.wikimedia.org/wiki/Talk:Deployments/Holding_the_train
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Why does the train start on Tuesday?

[Jon Robson]

Hi all

A few questions to provoke discussion/share knowledge better:
* Why does the train run Tue,Wed, Thur rather than Mon,Tue,Wed
* Why do we only have 2 group 1 Wikipedia's (Catalan and Hebrew)
* Should there be a backport window Friday mornings for certain changes?

Longer spiel:

A few weeks ago a change I made led to a small but noticeable UI
regression. The site was perfectly usable, but looked noticeably off. It
was in a more obscure part of the UI so we missed it during QA/code review.

Late Wednesday a ticket was reported against Wikimedia commons, but I only
became aware of it late Thursday when the regression rolled out to English
Wikipedia. A village pump discussion was started and several duplicate
tickets were created. While the site could still be used it didn't look
great and upset the experience of many editors.

Once aware of the problem, the issue was easy to fix. A patch was written
on Friday.

I understand Friday backports are possible, but my team tend to use them as
a last resort in fear of creating more work for my fellow maintainers over
weekend periods. As a result, given the site was still usable, the fix
wasn't backported until the first available backport window on Monday. This
is unfortunately a regular pattern, particularly for small UI regressions.

We addressed the issue on Monday, but I got feedback from several users
that this particular issue took too long to get backported. I mentioned the
no Friday deploy policy. One user asked me why we don't run the train
Monday-Wednesday and to be honest I wasn't sure. I couldn't find anything
on https://wikitech.wikimedia.org/wiki/Deployments/Train.

My team tries to avoid big changes on Mondays as Monday merged patches are
more likely to have issues since they don't always get the time to go
through QA during the week by our dedicated QA engineer.

So... Why don't we run the train Monday-Wednesday? Having a Thursday buffer
during which we can more comfortably backport any issues not caught in
testing, particularly UI bugs would be extremely helpful to my team and I
don't think we'd lose much by losing the Monday to rush last-minute changes.

Assuming there are good reasons for Tuesday-Thursday train, I think there
is another problem with our deploy process which is the size of group 1.
Given the complexity of our interfaces (several skins, gadgets, multiple
special pages, user preferences, gadgets, multiple extensions, and
different user rights), generally, many obscure UI bugs get missed in QA by
people who don't use the software every day and have a clear mental model
of how it looks and behaves. My team mostly works on visible user interface
changes and we rely heavily on Catalan and Hebrew Wikipedia users - our
only group 1 wikis to notice errors with UI before they go out to a wider
audience. Given the size of those audiences, that often doesn't work, and
it's often group 2 wikis that make us aware of issues. If we are going to
keep the existing train of Tue-Thur, I think it's essential we have at
least one larger Wikipedia in our group 1 deploy to give us better
protection against UI regressions living over the weekend. My understanding
is for some reason this is not a decision release engineering can make, but
one that requires an on-wiki RFC by the editors themselves. Is that
correct? While I can understand the reluctance of editors to experience
bugs, I'd argue that it's better to have a bug for a day than to have it
for an entire weekend, and definitely something we need to think more
deeply about.
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

Re: [Wikitech-l] Where are all the skins? (a call to action)

[Jon Robson]

Thanks for all the feedback. I've been making various changes/bug fixes to
the tool and we are up to 64 skins now!

 I'm seeing quite a few skins on
https://github.com/search?l=JSON=ValidSkinNames=Code that are
unaccounted for on mediawiki.org so if anyone wants to join me in
essentially what is a documentation drive please go ahead and start testing
skins and letting others know about them!

On the longer term, my hope is that knowing about the skins people are
building will help us understand the skin ecosystem, upstream common
patterns, and make it healthier.

I hope everybody has a great holiday period and happy editing! [1]

[1]
https://www.mediawiki.org/w/index.php?namespace=106=1==filter=Special%3ARecentChanges




On Mon, Dec 21, 2020, 3:37 PM Jon Robson  wrote:

> tldr: If you have built skins or use skins that are not listed on
> MediaWiki.org, please list them [4] and check that they work with current
> MediaWiki.org. If you have always wanted to build a skin try the new tool
> and give me feedback on how you get on! [3].
>
> Longer version:
> As part of my involvement in the desktop improvements project  [1] I with
> the help of many others have been trying to simplify the development of
> skins.
>
> As part of this, much-needed maintenance has occurred in MediaWiki core
> with the intention of making skin development easier.
>
> As a personal goal, I wanted to prototype a tool to showcase the skins
> available in the ecosystem, and finally with the downtime of the holiday
> period (no deploys!) I've finally done that. It allows showcasing [2] and
> building skins [3].
>
> While building this tool I was surprised to find that excluding forks of
> skins, there are only __55 skins__ listed on MediaWiki.org. Out of those,
> only 38 have been kept up to date.
>
> I can't believe that given the age of this project there are only 38
> usable skins and I am writing to you in the hope that:
>
> 1) You know of others that can be added to MediaWiki.org in the "Skin"
> namespace [4] Note, any edits to MediaWiki.org will automatically get
> picked up by the tool and listed.
> 2) If you build skins for closed source wikis, please consider publishing
> them over the holiday period if you can!
> 3) If you have fix skins that do not work with latest MediaWiki so I can
> showcase them on the new tool.
> 4) If you are inspired to make a new skin, possibly trying out the starter
> kit tool I have created [3] which will construct a working zip file that
> can be added to your local mediawiki and eventually github/gerrit and give
> me feedback via Phabricator/email/github what can be improved.
>
> **
>
> [1] https://www.mediawiki.org/wiki/Desktop_improvements
> [2] https://skins.wmflabs.org/?
> [3] https://skins.wmflabs.org/?#/add
> [4]
>
> https://www.mediawiki.org/w/index.php?action=edit=Template%3ASkin%2FSample=Skin%3ANewSkin%20=1
> ___
> 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] Where are all the skins? (a call to action)

[Jon Robson]

tldr: If you have built skins or use skins that are not listed on
MediaWiki.org, please list them [4] and check that they work with current
MediaWiki.org. If you have always wanted to build a skin try the new tool
and give me feedback on how you get on! [3].

Longer version:
As part of my involvement in the desktop improvements project  [1] I with
the help of many others have been trying to simplify the development of
skins.

As part of this, much-needed maintenance has occurred in MediaWiki core
with the intention of making skin development easier.

As a personal goal, I wanted to prototype a tool to showcase the skins
available in the ecosystem, and finally with the downtime of the holiday
period (no deploys!) I've finally done that. It allows showcasing [2] and
building skins [3].

While building this tool I was surprised to find that excluding forks of
skins, there are only __55 skins__ listed on MediaWiki.org. Out of those,
only 38 have been kept up to date.

I can't believe that given the age of this project there are only 38 usable
skins and I am writing to you in the hope that:

1) You know of others that can be added to MediaWiki.org in the "Skin"
namespace [4] Note, any edits to MediaWiki.org will automatically get
picked up by the tool and listed.
2) If you build skins for closed source wikis, please consider publishing
them over the holiday period if you can!
3) If you have fix skins that do not work with latest MediaWiki so I can
showcase them on the new tool.
4) If you are inspired to make a new skin, possibly trying out the starter
kit tool I have created [3] which will construct a working zip file that
can be added to your local mediawiki and eventually github/gerrit and give
me feedback via Phabricator/email/github what can be improved.

**

[1] https://www.mediawiki.org/wiki/Desktop_improvements
[2] https://skins.wmflabs.org/?
[3] https://skins.wmflabs.org/?#/add
[4]
https://www.mediawiki.org/w/index.php?action=edit=Template%3ASkin%2FSample=Skin%3ANewSkin%20=1
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l]  Wikimedia production errors help

[Jon Robson]

Id be careful about using numbers in triage right now. The numbers are a
little misleading as the error logging is only enabled on smaller wikis.
Also if an error results in data loss but only impacts a small amount of
people I would say that's worse than a benign error that occurs for lots.

We rolled out to Spanish, German and Japanese wikipedia yesterday so these
numbers will start becoming more useful, but English Wikipedia will
severely skew these numbers when we finally enable it.

On Tue, Sep 22, 2020, 9:59 AM Ed Sanders  wrote:

> Speaking specifically about the new JavaScript error logging, and
> specifically to Alex's point about triaging these tasks, it would be very
> helpful if the reports included some indication of how often the error is
> occurring.
>
> For example, VisualEditor is loaded several hundred thousands times per
> day. If an error has occurred 4 times in the last 30 days (based on a
> recent example) then it is probably very low priority.
>
> On Thu, 17 Sep 2020 at 16:40, C. Scott Ananian 
> wrote:
>
> > ACN -- for what it's worth, I've been working for the foundation for a
> > while now, and I can report from the inside that the trend is definitely
> in
> > a positive direction.  There is a lot more internal focus on addressing
> > code debt and giving maintenance a fair spot at the table.  (In fact, my
> > entire team is now sitting inside 'maintenance' now, apparently; we used
> to
> > be 'platform evolution'.)  This email thread is one visible aspect of
> that
> > focus on code quality, not just features.
> >
> > That said, the one aspect which hasn't improved much in my time at the
> > foundation has been the tendency of teams to work in silos.  This thread
> > also seems to be a symptom of that: a bunch of production issues are
> being
> > dropped on the floor ('not resolved in over a month') because they are
> > falling between the silos and nobody knows who is best able to fix them.
> > There are knowledge/expertise gaps among the silos as well: someone
> > qualified to fix a DB issue might be at sea trying to track down a front
> > end bug, and vice-versa---a number of generalists in the org could
> > technically tackle a bug no matter where it lies, but it will take them
> > much longer to grok an unfamiliar codebase than it would for someone more
> > familiar with that silo.  So bug triage is an increasingly technical task
> > in its own right.
> >
> > This thread, as I read it sitting inside the org, isn't so much asking
> for
> > more attention to be paid to maintenance -- we're winning that battle,
> > internally -- as it is a plea for those folks on the edges of their silos
> > to keep an eye out for these things which are currently falling between
> > them and help with the triage.
> >   --scott, speaking only for myself and my view here
> >
> >
> >
> > On Wed, Sep 16, 2020 at 11:25 PM AntiCompositeNumber <
> > anticompositenum...@gmail.com> wrote:
> >
> > > There is an impression among many community members, myself included,
> > > that Foundation development generally prioritizes new features over
> > > fixing existing problems. Foundation teams will sprint for a few
> > > months to put together a minimum viable product, release it, then move
> > > on to the new hotness, leaving user requests, bugfixes, and the like
> > > behind. It often seems that the only way to get a bug fixed is to get
> > > a volunteer developer to look at it. This is likely unintentional, but
> > > it happens nonetheless.
> > >
> > > Putting a higher priority within the Foundation on cleaning up old
> > > toys before taking out new ones is necessary for the long-term
> > > stability of the projects.
> > >
> > > ACN
> > >
> > > On Wed, Sep 16, 2020 at 9:05 PM Dan Andreescu <
> dandree...@wikimedia.org>
> > > wrote:
> > > >
> > > > >
> > > > > For example, of the 30 odd backend errors reported in June, 14 were
> > > still
> > > > > open a month later in July [1], and 12 were still open – three
> months
> > > later
> > > > > – in September. The majority of these haven't even yet been
> triaged,
> > > > > assigned assigned or otherwise acknowledged. And meanwhile we've
> got
> > > more
> > > > > (non-JavaScript) stuff from July, August and September adding
> > > pressure. We
> > > > > have to do better.
> > > > >
> > > > > -- Timo
> > > > >
> > > >
> > > > This feels like it needs some higher level coordination.  Like
> perhaps
> > > > managers getting together and deciding production issues are a
> priority
> > > and
> > > > diverting resources dynamically to address them.  Building an awesome
> > new
> > > > feature will have a lot less impact if the users are hurting from
> > growing
> > > > disrepair.  It seems to me like if individual contributors and
> > > maintainers
> > > > could have solved this problem, they would have by now.  I'm a little
> > > > worried that the only viable solution right now seems like heroes
> > > stepping
> > > > up to fix these bugs.
> > > >
> > > > 

[Wikitech-l] Requesting +2 rights for Mediawiki Group for Ammarpad

[Jon Robson]

Per our policy [1], I'd like to inform you that I have nominated Ammarpad
for +2
rights for mediawiki/*. [2]

- Jon

[1]
https://www.mediawiki.org/wiki/Gerrit/Privilege_policy#Requesting_Gerrit_privileges
[2] https://phabricator.wikimedia.org/T258986
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki 1.35 Branch Cut and Release

[Jon Robson]

On Mon, Jul 6, 2020 at 11:11 AM Evan Prodromou 
wrote:

> Hey, all. This is the roughly 1-week "pencils down" warning for the
> upcoming MediaWiki 1.35 release branch cut.
>
> The branch cut is scheduled to be made on 14 July 2020 at 02:00 UTC.
>
> (That's late on 13 July in the Americas and parts of the Pacific. Timezones
> are like magic, aren't they?)
>
> After that point, new features won't be merged into 1.35; the master branch
> will become part of the 1.36 release.
>
> If you have tickets that are tagged for `mw-1.35-release`, please finish
> them, untag them, or reach out to get them resolved.*
>

I've been tagging patches for review with 1.35 to keep track of my own.
Please tag any patches that you are needing review. I'm happy to take a
look and would welcome help with reviewing my own!

https://gerrit.wikimedia.org/r/q/hashtag:%221.35%22+(status:open%20OR%20status:merged)


> After the branch cut, bug fixes will be manually ported, but feature
> changes won't.
>
> Thanks for your work on and interest in MediaWiki.
>
> -Evan
>
> * See https://phabricator.wikimedia.org/tag/mw-1.35-release/ for details.
>
>
>
>
> On Tue, Jun 2, 2020 at 8:58 AM Cindy Cicalese 
> wrote:
>
> > On March 30, we announced that we were temporarily pushing back the
> release
> > of MediaWiki 1.35 due to uncertainty resulting from the COVID-19
> pandemic.
> > We are now ready to begin the process of moving forward with the release.
> >
> > The first step is cutting the release branch, REL1_35, which will occur
> on
> > Monday, July 13.
> >
> > We will then be in "pencils down" mode: developers will stop targeting
> > MediaWiki 1.35 for new features. Instead, any new features would continue
> > to be applied to master and would target MediaWiki 1.36 or later. The
> only
> > work that would continue towards MediaWIki 1.35 would be blockers -
> > critical bug fixes or features close to completion that need to make it
> > into the release. This would happen by merging those patches into master
> > and then backporting them to the REL1_35 branch.
> >
> > We anticipate that MediaWiki 1.35 will be released at the beginning of
> > August.
> >
> > We appreciate your patience in these difficult times. Wishing you safety
> > and health,
> >
> > Cindy
> > ___
> > 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] Skins: Deprecation of various hooks and introducing SkinMustache

[Jon Robson]

Hello,

TLDR: The following hooks are deprecated in 1.35:
SkinTemplateBuildNavUrlsNav_urlsAfterPermalink,
SkinTemplatePreventOtherActiveTabs, SkinTemplateTabAction,
BaseTemplateAfterPortlet, SkinTemplateToolboxEnd, BaseTemplateToolbox,
 SkinTemplateOutputPageBeforeExe.

The longer version:
As part of the desktop improvements project
 we've been making some
exciting changes in MediaWiki's skin architecture. This has involved
migrating away from the BaseTemplate PHP class to Mustache as the render
engine for Vector. In 1.36, the Vector skin plans to use the new SkinMustache
class

and do away with the BaseTemplate class. This meant that we had to
deprecate various BaseTemplate hooks, providing more suitable generic
alternatives in the shared Skin.php layer. We also took the opportunity to
reduce the number of active hooks that operate in the skin layer for
developer sanity.

From now on it is intended that any skin modifications are done *prior *to
rendering. The renderer whether it is BaseTemplate or SkinMustache will
simply render the data that's been provided.

As a result of this I have various changes to report!

The *SidebarBeforeOutput

*hook now can be used to modify the toolbox and languages portals.
Previously these sidebar menus had their own bespoke hooks.

The SkinTemplateBuildNavUrlsNav_urlsAfterPermalink hook

is deprecated and can be replaced with the new and improved
SidebarBeforeOutput hook.

The SkinTemplatePreventOtherActiveTabs and SkinTemplateTabAction hooks
were seldom used and replaced
with SkinTemplateNavigation::Universal .

All BaseTemplate hooks should now be considered deprecated per T253809
.

   - BaseTemplateAfterPortlet
   
   is replaced with the template-rendering agnostic SkinAfterPortlet
   
   - SkinTemplateToolboxEnd
   is
   replaced with the new and improved version of SidebarBeforeOutput
   - BaseTemplateToolbox
    is
   replaced  with the new and improved version of SidebarBeforeOutput


Finally a big one:
The SkinTemplateOutputPageBeforeExec hook is now deprecated
. Previously this hook could do a
lot of things and often in ways that were hard to reason with. For example,
previously this hook was used alongside other hooks to add items to the
footer and to override skin internals to display portals that were normally
hidden. We looked through all the use cases for this hook and are confident
we've caught the most confident use cases. Migration depends on what it was
previously used for but are documented on mediawiki.org
.
It's possible there are other use cases, we missed and if so we plan to
cover those during the 1.36 release.

If you are an extension developer and have any questions about migration
please feel free to ping me on the associated Phabricator ticket or hook
talk page, we will be happy to improve the documentation and help you find
the right way to upgrade your code.

As we go into 1.36 we plan to make changes that simplify MediaWiki skin
development and make the ecosystem friendlier to frontend developers and
make skins easier to maintain. In fact, in future, it will be possible to
write skins without a single line of PHP. If you are excited or intrigued
by these changes and want to get involved in the conversations I urge you
to subscribe to our board.


I'm particularly interested in hearing from developers who are keen to make
skins in the new ecosystem. Your input and creativity would be much
appreciated. Feel free to drop me a private mail or engage in open
conversations.

In addition to all the extension developers who helped review changes to
their hook contracts, I would like to especially thank the following people
for getting us to this landmark: Ammarpad, Timo, Volker and Mainframe98.
I'd like to give a specific shout out for Ammarpad who has been a huge
driving force here, preventing various bugs from occurring and swiftly
responding to many of the unexpected regressions that we encountered during
this work. We couldn't have done this without you!

Thanks for reading!
Jon
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org

[Wikitech-l] [3rd parties] FYI Minerva no longer depends on MobileFrontend

[Jon Robson]

Minerva has been available as a desktop skin available on
Special:Preferences for some time, however it has had a hard dependency on
the MobileFrontend extension due to its history - originally being part of
the MobileFrontend extension.

Thanks to much of the work inside Advanced Mobile Contributions

the Minerva skin now has a soft dependency on MobileFrontend and will not
run MobileFrontend code if its not installed.

When operating in this mode, Minerva will operate in a simplified mode that
operates similar to the other skins Vector and Timeless. It will use jQuery
autocomplete for search and the watchstar code that lives in core. Features
such as reference popups, red link confirmation and overlays for talk and
languages will fall back to links.

The code for this change rolls out this week. The new code should only be
triggered on instances where MobileFrontend is not installed so should not
impact any wikis e.g. Wikimedia production.

This mode will not be enabled in any Wikimedia wikis, but my hope is that
it will help improve the skin architecture going into the Desktop
improvements project
which will be targeting the Vector experience.

My hope is this project will allow us to apply the lessons we have learned
in Minerva to more generalised solutions that work on traditional skins as
well and will encourage editors to improve the many  templates that are not
compatible with skins like Minerva and Timeless when they operate in
responsive mode (some of which are slowly being collected in
https://en.wikipedia.org/wiki/Category:Templates_that_are_not_mobile_friendly
).

You can help this effort by installing Minerva on your local wikis and/or
using Minerva as a desktop skin on production wikis where it's available
and reporting bugs as and when you find them. If you haven't used Minerva
skin on desktop in some time, I urge you to give a try. You will likely be
surprised by what you find.

If you are actively developing Wikimedia extensions but do not test
regularly with MobileFrontend, please do add Minerva as one of your test
skins, however please note that MobileFrontend does alter behaviour of all
skins (Vector for example ships additional responsive styles), so testing
on Minerva without MobileFrontend is not a sufficient substitute for
testing on Wikimedia's production wikis.

You can read more about the work that got us here at
https://phabricator.wikimedia.org/T171000

Thanks for your time!
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Mobile site now using Mustache.js

[Jon Robson]

For historic reasons the mobile site was built using client side templates
using a templating library called Hogan.js. This caused problems with
development as engineers wanting to build client side experiences using
templates would have to use different template languages for desktop and
mobile experiences or ship two both Mustache and Hogan to end users.

We've recently been simplifying and cleaning up the codebase, reducing
technical debt [1] and as part of this effort have switched templates
inside Minerva and MobileFrontend from Hogan to Mustache [2, 3] to bring
them in line with the rest of the platform.

The Mustache library is smaller than Hogan and appears to be better
maintained. It also has a PHP implementation which is used across MediaWiki
inside cores and skins.

Longer term we are reconsidering the use of templates in our part of the
tech stack but if you are developing extensions or skins that operate in an
environment using a separate mobile skin you can safely and are encouraged
to make use of Mustache to share code that needs to run in both PHP and JS.

[1]
https://medium.com/freely-sharing-the-sum-of-all-knowledge/how-we-tackled-technical-debt-at-wikipedia-d52030065e2c
[2] https://gerrit.wikimedia.org/r/#/c/506340/
[3] https://phabricator.wikimedia.org/T220620
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Life hack: Working with production content in your local wiki

[Jon Robson]

As an experiment (and be bold etc), I've enabled this for the mobile domain
on the enwiki beta cluster [1]. If you hit any problems with these please
let me know on the ticket [2] and I or somebody else can revert the
associated config change.

What this means, is live content from production wikis will now appear on
mobile beta cluster pages which do not have a beta cluster version. For
example, https://en.m.wikipedia.beta.wmflabs.org/wiki/Spain shows content
from the beta cluster, but
https://en.m.wikipedia.beta.wmflabs.org/wiki/Singapore shows content from
English Wikipedia. In the case of the latter a 404 response code is sent,
to ensure these pages do not get indexed by search engines. This means that
it shouldn't interfere with any browser tests (Minerva beta cluster tests
are still passing [3])

This is beneficial for testing out real world content within the context of
a skin e.g. timeless, vector or minerva. We have many frontend bugs that
were difficult to test before this technique. My team has been using this
on labs [4] for many months now and it's been pretty indefensible to us, so
my thinking is it will be useful to others working with skins.

If it's useful, in future this technique can be used for desktop and other
projects on the beta cluster e.g. wikivoyage BC [5] - just let me know!

In the unlikely event this breaks any kind of testing you are trying to do,
please point your frustrations at me via the ticket [2] and I'll roll this
experiment back immediately and you would have given me valuable insights
into ways to improve this tool!

[1] https://en.m.wikipedia.beta.wmflabs.org
[2] https://phabricator.wikimedia.org/T207508
[3]
https://integration.wikimedia.org/ci/view/Reading-Web/job/selenium-MinervaNeue/
[4] https://reading-web-staging.wmflabs.org
[5] https://en.wikivoyage.beta.wmflabs.org/

On Mon, Feb 5, 2018 at 10:57 AM Jon Robson  wrote:

> I've been meaning to document this for a while.
> If you're finding yourself visiting Special:Export/Import often for the
> purpose of MediaWiki development there is a much better way to get content
>  into your local wiki for testing purposes.
>
> This short video explains how MobileFrontend extension provides tooling to
> help you debug live on-wiki content via $wgMFContentProviderClass [1]
> https://youtu.be/uRQzjN0hBlY
>
> Hope it saves someone lots of time!
>
> [1]
> https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/README.md#wgmfcontentproviderclass
> --
> Jon Robson
> Senior Software Engineer
>
-- 
Jon Robson
Senior Software Engineer
twitter: @jdlrobson
linkedin: https://www.linkedin.com/in/jorobson/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimedia production excellence (November 2018)

[Jon Robson]

tor.wikimedia.org/T156293



Note this is not a mobilefrontend issue but an issue with the MassMessage
extension - it impacts desktop too

See
https://www.mediawiki.org/w/index.php?title=User%3AQuiddity%2Fdemomodel=revision=2234116=2234115

>
> * ProofreadPage: Unable to edit certain pages on Wikisource. –
> https://phabricator.wikimedia.org/T176196
> * Translate: Some Special:Translate urls fatal. –
> https://phabricator.wikimedia.org/T204833
> * Wikibase: Clicking “undo” for some revisions fatals with a
> PatcherException. – https://phabricator.wikimedia.org/T97146
>
> Public user requests resulting in fatals can (and have) caused alerts to
> fire that notify SRE of wikis potentially being less available or down.
>
> *ProTip*: Cross-reference one workboard with another via “Open Tasks” >
> “Advanced Filter” and enter Tag(s) to apply as a filter.
>
> ##  *Thank you*
>
> Thank you to everyone who helped by reporting or investigating problems in
> Wikimedia production; and for implementing or reviewing their solutions.
> Including: tstarling, thiemowmde, thcipriani, Tgr, Steinsplitter, Quiddity,
> pmiazga, Nikerabbit, Mvolz, Lucas_Werkmeister_WMDE, kostajh, jrbs, JJMC89,
> Jdforrester-WMF, hashar, Gilles, Daimona, Ciencia_Al_Poder, Catrope,
> BPirkle, Barkeep49, Anomie, and Aklapper.
>
> Thanks!
>
> Until next time,
>
> – Timo Tijhof
>
> ---
>
> Footnotes:
>
> [1] Incidents. –
>
> https://wikitech.wikimedia.org/wiki/Special:AllPages?from=Incident+documentation%2F20181101=Incident+documentation%2F20181131=0
>
> [2] Tasks closed. –
> https://phabricator.wikimedia.org/maniphest/query/.PkyGL4Rz_4i/#R
>
> [3] Tasks opened. –
> https://phabricator.wikimedia.org/maniphest/query/WsqbAxlHPLwk/#R
>
> [4] Partial blocks. –
>
> https://meta.wikimedia.org/wiki/Community_health_initiative/Per-user_page,_namespace,_and_upload_blocking
>
> [5] Bug report about page deletion, 2007. –
> https://phabricator.wikimedia.org/T13402
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- 
Jon Robson
twitter: @jdlrobson
linkedin: https://www.linkedin.com/in/jorobson/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] problematic use of "Declined" in Phabricator

[Jon Robson]

Just one note about "needs-volunteer".
If the staff maintaining an extension don't have time to work on a problem,
they may also not have time to review any changes relating to it.

If you do use this tag, I see this as an indication you are willing to take
time to review any contributions relating to that task and do so until the
task is seen to completion.

There is nothing I hate more than seeing volunteers submit patches to help
the project and not getting any code review. Our volunteers are important.


On Wed, 3 Oct 2018 at 05:15 Derk-Jan Hartman 
wrote:

> Another side effect of closing a ticket with Declined, is that it doesn't
> show up in search (because it's closed and closed tickets are omitted by
> default). But if the problem or desire for the feature still exists, it is
> likely to be reported again by users via a new ticket and other people then
> have to go duplicate hunting. So that creates more duplicates to weed
> through.
>
> And when I work on something, I often take a look at boards and see if
> there is anything else in the same area that might need work, or I use the
> tickets to get a feeling of the direction that people want us to go. When
> declined is mixed with "we can't work on this right now", that makes it a
> lot harder to do that as well.
>
> So i think Stalled is better. The problem with that can be that such
> tickets show up in workboards, which can create a lot of load in the
> browser if there are a lot of tickets. If we would tag all of such tickets
> with something like 'need-volunteer', a team could customise their work
> board filter to exclude all tickets with that tag. Or simply exclude the
> entire status, but then you cannot effectively use it within the team
> either. We do have to make that need-volunteer tag somewhat better defined
> in the bug lifecycle and the tag's description in that case. That tag
> started out more as an "opportunities for volunteers". Alternative is a new
> "no-resourcing" tag. or something.
>
> DJ
>
> On Wed, Oct 3, 2018 at 1:03 PM Amir Sarabadani 
> wrote:
>
> > My two cents:
> > I would personally make those type of tickets as "stalled", "stalled"
> > basically for me means blocked and these type of tasks are blocked on
> human
> > resources, some miracles might happen and we might end up having enough
> > resources to unblock it but until that day it's stalled IMO.
> >
> > OTOH there are tickets that we don't have resources to work on it and we
> > never will, imagine a ticket with title "Rewrite mediawiki", it sounds
> good
> > as lots of part of it is old but we will never have such resource to do
> it.
> > IMO, we should call it declined on grounds of not having resources. Same
> > goes for "Every user should have a personal private wiki": We don't have
> > hardware resources for that and probably never will.
> >
> > Best
> >
> > On Wed, Oct 3, 2018 at 7:27 AM Pine W  wrote:
> >
> > > I'm grateful for this largely civil and productive discussion. I'd like
> > to
> > > suggest that the multiple sub-topics being discussed here might be
> easier
> > > to follow if the entire discussion is moved to a wiki talk page, such
> as
> > on
> > > MediaWiki.org. I am not attempting to halt discussion or to tell people
> > to
> > > stop writing to the mailing list; moving to a wiki talk page is just a
> > > suggestion.
> > >
> > > Thanks,
> > >
> > > Pine
> > > ( https://meta.wikimedia.org/wiki/User:Pine )
> > > ___
> > > 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

-- 
Jon Robson
twitter: @jdlrobson
linkedin: https://www.linkedin.com/in/jorobson/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] problematic use of "Declined" in Phabricator

[Jon Robson]

We could also create a global tag called freezer / room101 () to help
developers to do this filtering. It would also allow us to get a high level
overview of under resourced projects which i suspect would be helpful with
planning and finding stewards for certain projects.

Without such a tag projects are forced to create their own
tags/milestones/columns to manage these tasks (my team has done just this)

On Tue, Oct 2, 2018, 12:05 PM Pine W  wrote:

> I agree with this approach, and also with moving tasks to a "freezer".
>
> I support depreciating the use of "needs volunteer (developer)".
>
> Pine
> ( https://meta.wikimedia.org/wiki/User:Pine )
>  Original message From: James Hare 
> Date: 10/2/18  11:41 AM  (GMT-08:00) To: Wikimedia developers <
> wikitech-l@lists.wikimedia.org> Subject: Re: [Wikitech-l] problematic use
> of "Declined" in Phabricator
> On Tue, Oct 2, 2018 at 11:32 AM Stas Malyshev 
> wrote:
>
> > Realizing this, I think we need some mode of explicitly saying "we do
> > not have any means to do it now or in near-term future, but we don't
> > reject it completely and if we ever have resources or ways to do this,
> > we might revisit this".
> >
> > We kinda sorta have this with "Stalled" status and "Need volunteer" tag,
> > but we might want to get this status more prominent and distinguish
> > "TODO" items outside of any planning cycle and the ones that are part of
> > the ongoing development. And document it in the lifecycle document.
> >
>
> I have found that setting the priority to "lowest" is the closest thing we
> have to "this is a valid task but we are not going to invest paid time into
> it."
>
> 
> James Hare
> Associate Product Manager
> Wikimedia Foundation
> https://wikimediafoundation.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

-- 
Jon Robson
twitter: @jdlrobson
linkedin: https://www.linkedin.com/in/jorobson/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Production Excellence: September 2018

[Jon Robson]

uild pages without connecting to the primary (which can be far
> away).
>
> Kosta addressed the warning by improving the code that saves the calculated
> information. Instead of saving it immediately, an instruction is now sent
> via a job queue, after the page view is ready. This job queue then
> calculates and saves the information to the master database. The master
> synchronises it to replicas, and then page views can use it.
>
> – https://phabricator.wikimedia.org/T199699 /
> https://gerrit.wikimedia.org/r/455870
>
> ## *️⃣ Tomorrow, may be sooner than you think
>
> After developers submit code to Gerrit, they eagerly await the result from
> Jenkins, an automated test runner. It sometimes incorrectly reported a
> problem with the MergeHistory feature. The code assumed that the tests
> would finish by "tomorrow".
>
> It might be safe to assume our tests will not take one day to finish.
> Unfortunately, the programming utility "strtotime", does not interpret
> "tomorrow" as "this time tomorrow". Instead, it means "the start of
> tomorrow". In other words, the next strike of midnight! The tests use UTC
> as the neutral timezone.
>
> Every day in the 15 minutes before 5 PM in San Francisco (which is midnight
> UTC), code submitted to Code Review, could have mysteriously failing tests.
>
> – Continue at https://gerrit.wikimedia.org/r/452873
>
> ## *️⃣ Continuous Whac-A-Mole
>
> In August, developers started to notice rare and mysterious failures from
> Jenkins. No obvious cause or solution was known at that time.
>
> Later that month, Dan Duvall (Release Engineering team) started exploring
> ways to run our tests faster. Before, we had many small virtual servers,
> where each server runs only one test at a time. The idea: Have a smaller
> group of much larger virtual servers where each server could run many tests
> at the same time. We hope that during busier times this will better share
> the resources between tests. And, during less busy times, allow a single
> test to use more resources.
>
> As implementation of this idea began, the mysterious test failures became
> commonplace. "No space left on device", was a common error. The test
> servers had their hard disk full. This was surprising. The new (larger)
> servers seemed to have enough space to accommodate the number of tests it
> ran at the same time. Together with Antoine Musso and Tyler Cipriani, they
> identified and resolved two problems:
> 1) Some automated tests did not clean up after themselves.
> 2) The test-templates were stored on the "root disk" (the hard drive for
> the operating system), instead of the hard drive with space reserved for
> tests. This root disk is quite small, and is the same size on small servers
> and large servers.
>
> – https://phabricator.wikimedia.org/T202160 /
> https://phabricator.wikimedia.org/T202457
>
> ##  Thanks!
>
> Thank you to everyone who has helped report, investigate, or resolve
> production errors. Including:
>
> Tpt
> Ankry
> Daimona
> Legoktm
> Volker_E
> Pchelolo
> Dan Duvall
> Gilles Dubuc
> Daniel Kinzler
> Umherirrender
> Greg Grossmeier
> Gergő Tisza (Tgr)
> Sam Reed (Reedy)
> Giuseppe Lavagetto
> Brad Jorsch (Anomie)
> Tim Starling (tstarling)
> Kosta Harlan (kostajh)
> Jaime Crespo (jcrespo)
> Antoine Musso (hashar)
> Roan Kattouw (Catrope)
> Adam WMDE (Addshore)
> Stephane Bisson (SBisson)
> Niklas Laxström (Nikerabbit)
> Thiemo Kreuz (thiemowmde)
> Subramanya Sastry (ssastry)
> This, that and the other (TTO)
> Manuel Aróstegui (Marostegui)
> Bartosz Dziewoński (matmarex)
> James D. Forrester (Jdforrester-WMF)
>
> Thanks!
>
> Until next time,
>
> – Timo Tijhof
> 
>
> Further reading:
>
> * August 2018 edition. –
> https://lists.wikimedia.org/pipermail/wikitech-l/2018-August/090594.html
> * July 2018 edition. –
> https://lists.wikimedia.org/pipermail/wikitech-l/2018-July/090363.html
>
> Footnotes:
>
> [1] Incidents. –
>
> https://wikitech.wikimedia.org/wiki/Special:AllPages?from=Incident+documentation%2F20180809=Incident+documentation%2F20180922=0
>
> [2] Tasks closed. –
> https://phabricator.wikimedia.org/maniphest/query/wOuWkMNsZheu/#R
> [3] Tasks opened. –
> https://phabricator.wikimedia.org/maniphest/query/6HpdI76rfuDg/#R
> [4] Quiz on Wikiversity. –
>
> https://en.wikiversity.org/wiki/How_things_work_college_course/Conceptual_physics_wikiquizzes/Velocity_and_acceleration
>
> [5] Operate multiple datacenters. –
>
> https://www.mediawiki.org/wiki/Requests_for_comment/Master-slave_datacenter_strategy_for_MediaWiki
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- 
Jon Robson
twitter: @jdlrobson
linkedin: https://www.linkedin.com/in/jorobson/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Sensitive IRC bots - be careful out there!

[Jon Robson]

Just a quick update: My ban was removed and was because I @ed too many
people. Was surprised the number was so low but take care during any SWAT
windows :)

On Thu, Aug 16, 2018 at 4:14 PM Jon Robson  wrote:

> I just got banned from Freenode server for @ing a few people during a SWAT
> deploy. Be careful everyone! It's a dangerous world out there!
>
> I've taken the advice and emailed kline but in the meantime, you may want
> to be careful who/how many people you @.
>
> Will let you know when I know more and apologies if you can't get hold of
> me in the mean time!
> Jon
>
> Replay of the event:
>  Jdlrobson and nray: A patch you scheduled for Evening SWAT
> (Max 6 patches) is about to be deployed. Please be around during the
> process. Note: If you break AND fix the wikis, you will be rewarded with a
> sticker.
> 4:03 PM  Jon Robson \o
> 4:03 PM  Nicholas Ray \o
> 4:05 PM  Jon Robson mark: twentyafterfour RoanKattouw
> thcipriani Niharika any of you able to swat right now?
> 4:05 PM ⇐ You were killed by Sigyn (sigyn@freenode/utility-bot/sigyn):
> (Spam is off topic on freenode.)
> 4:05 PM ⇐ jdlrobson quit (sid92657@gateway/web/
> irccloud.com/x-maentctwgksrmedg) Killed (Sigyn (Spam is off topic on
> freenode.))
> Check your host, port and ssl settingsDisconnected: You are banned from
> this server- Please do not spam users or channels on freenode. If in error,
> please contact kl...@freenode.net. (2018/8/16 23.03)
> <https://www.irccloud.com/irc/freenode/channel/wikimedia-operations>
> --
> Jon Robson
> Senior Software Engineer
> twitter: @jdlrobson
> linkedin: https://www.linkedin.com/in/jorobson/
>
-- 
Jon Robson
Senior Software Engineer
twitter: @jdlrobson
linkedin: https://www.linkedin.com/in/jorobson/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Sensitive IRC bots - be careful out there!

[Jon Robson]

I just got banned from Freenode server for @ing a few people during a SWAT
deploy. Be careful everyone! It's a dangerous world out there!

I've taken the advice and emailed kline but in the meantime, you may want
to be careful who/how many people you @.

Will let you know when I know more and apologies if you can't get hold of
me in the mean time!
Jon

Replay of the event:
 Jdlrobson and nray: A patch you scheduled for Evening SWAT (Max
6 patches) is about to be deployed. Please be around during the process.
Note: If you break AND fix the wikis, you will be rewarded with a sticker.
4:03 PM  Jon Robson \o
4:03 PM  Nicholas Ray \o
4:05 PM  Jon Robson mark: twentyafterfour RoanKattouw thcipriani
Niharika any of you able to swat right now?
4:05 PM ⇐ You were killed by Sigyn (sigyn@freenode/utility-bot/sigyn):
(Spam is off topic on freenode.)
4:05 PM ⇐ jdlrobson quit (sid92657@gateway/web/
irccloud.com/x-maentctwgksrmedg) Killed (Sigyn (Spam is off topic on
freenode.))
Check your host, port and ssl settingsDisconnected: You are banned from
this server- Please do not spam users or channels on freenode. If in error,
please contact kl...@freenode.net. (2018/8/16 23.03)
<https://www.irccloud.com/irc/freenode/channel/wikimedia-operations>
-- 
Jon Robson
Senior Software Engineer
twitter: @jdlrobson
linkedin: https://www.linkedin.com/in/jorobson/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikidata-tech] Normalization of change tag schema

[Jon Robson]



On Tue, Jul 31, 2018, 3:42 AM Derk-Jan Hartman 
wrote:

> That is an impressive difference !
>
> On Mon, Jul 30, 2018 at 6:22 PM Amir Sarabadani <
> amir.sarabad...@wikimedia.de> wrote:
>
> > And this is the load on vslow database nodes on s7:
> >
> >
> https://grafana.wikimedia.org/dashboard/db/mysql?panelId=3=1=1532794373712=1532967173714=eqiad%20prometheus%2Fops=db1090=13317
> >
> > You can see similar drops on other sections from exactly the moment it
> got
> > deployed:
> > s1:
> >
> >
> https://grafana.wikimedia.org/dashboard/db/mysql?panelId=3=1=1531757700702=1532967300702=eqiad%20prometheus%2Fops=db1106=9104
> > s2
> > <
> https://grafana.wikimedia.org/dashboard/db/mysql?panelId=3=1=1531757700702=1532967300702=eqiad%20prometheus%2Fops=db1106=9104s2
> >
> > :
> >
> >
> https://grafana.wikimedia.org/dashboard/db/mysql?panelId=3=1=1532794561870=1532967361872=eqiad%20prometheus%2Fops=db1090=13312
> >
> > Best
> >
> > On Mon, 30 Jul 2018 at 13:13, Amir Sarabadani <
> > amir.sarabad...@wikimedia.de>
> > wrote:
> >
> > > Hey,
> > > Using the new table as backend of Special:Tags (and similar APIs) is
> now
> > > enabled everywhere. Contact me if there's any issues with that.
> > >
> > > Best
> > >
> > > On Wed, 25 Jul 2018 at 19:17, Amir Sarabadani <
> > > amir.sarabad...@wikimedia.de> wrote:
> > >
> > >> Hello,
> > >> One update regarding this.
> > >> We enabled using the new table for Special:Tags in several large wikis
> > >> which caused a massive improvement in the performance of the page. For
> > >> example loading Special:Tags on Wikidata used to take around a minute
> > and
> > >> now it takes less than a second. English Wikipedia is down from ten
> > seconds
> > >> to less than one and so on.
> > >>
> > >> There is a lot of work needs to be done and maintenance scripts is
> being
> > >> ran to backpopulate the ct_tag_id column in change_tag table (If you
> > want
> > >> to follow the progress, see https://phabricator.wikimedia.org/T193873
> )
> > >> and then we need start reading from the new table in mediawiki and
> > finally
> > >> we can drop ct_tag column entirely. If you want to help in review,
> > writing
> > >> code or anything, just let me know.
> > >>
> > >> Best
> > >>
> > >> On Wed, 27 Jun 2018 at 15:15, Léa Lacroix 
> > >> wrote:
> > >>
> > >>> Hello all,
> > >>>
> > >>> Our team is refactoring some code around the change tags on Recent
> > >>> Changes. This can impact people using the database on ToolForge.
> > >>>
> > >>> Currently, the tags are stored in the table change_tag in the column
> > >>> ct_tag.
> > >>>
> > >>> In the next days, we will add a column ct_tag_id with a unique
> > >>> identifier for these tags. A new table change_tag_def that will store
> > >>> the tag id, the message, and more information like how many times
> this
> > tag
> > >>> is used on the local wiki.
> > >>>
> > >>> On the long term, we plan to drop the column ct_tag since the tag
> will
> > >>> be identified with ct_tag_id.
> > >>>
> > >>> This change will happen on:
> > >>> - French Wikipedia: Monday July 2nd
> > >>> - All other wikis: from July 9th
> > >>>
> > >>> If there is any problem (trouble with saving edits, slow down of
> recent
> > >>> changes…) please  create a subtask of T185355
> > >>>  or contact Ladsgroup
> > >>> .
> > >>>
> > >>> Cheers,
> > >>> --
> > >>> Léa Lacroix
> > >>> Project Manager Community Communication for Wikidata
> > >>>
> > >>> Wikimedia Deutschland e.V.
> > >>> Tempelhofer Ufer 23-24
> > >>> 10963 Berlin
> > >>> www.wikimedia.de
> > >>>
> > >>> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.
> V.
> > >>>
> > >>> Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
> > >>> unter der Nummer 23855 Nz. Als gemeinnützig ane
> rkannt
> durch das
> > Finanzamt
> > >>> für Körperschaften I Berlin, Steuernummer 27/029/42207.
> > >>> ___
> > >>> Wikidata-tech mailing list
> > >>> wikidata-t...@lists.wikimedia.org
> > >>> https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
> > >>>
> > >>
> > >>
> > >> --
> > >> Amir Sarabadani
> > >> Software Engineer
> > >>
> > >> Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
> > >> Tel. (030) 219 158 26-0
> > >> http://wikimedia.de
> > >>
> > >> Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen
> > >> Wissens frei teilhabe
> n
> kann. Helfen Sie uns dabei!
> > >> http://spenden.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/029/42207.
> > >>
> 

Re: [Wikitech-l] Mobile MonoBook

[Jon Robson]

Showing the navbox (a 1000px table) on a mobile device (320px) is a
difficult problem and not skin specific as Brad quite rightly points out,
but a template problem.

Minerva shows navboxes on desktop resolutions - you can see for yourself:
https://en.wikipedia.org/wiki/San_Francisco?useskin=minerva (they are at
the bottom of the page). It only hides them on mobile.

I've added Isarra's Monobook patch to our staging environment so you can
explore how it behaves with real world content on a real device:
http://reading-web-staging.wmflabs.org/wiki/San_Francisco?useskin=monobook

Here's a screenshot of Navboxes:
https://imgur.com/a/0I3YP
They appear pretty much the same on any skin on a mobile device - because
they are defined in a wiki page template - not in the skin. I'm not sure
how Isarra plans to handle them, but I don't think there are many options
so I think we should assume good faith in whatever she chooses to do.

The fundamental problem is a lot of our content is designed for desktop
presentation and needs serious thought on how it can be adapted for mobile.


On Wed, 4 Apr 2018 at 13:52 Strainu  wrote:

> 2018-04-04 23:41 GMT+03:00 Brad Jorsch (Anomie) :
> > On Wed, Apr 4, 2018 at 3:18 PM, Strainu  wrote:
> >
> >> Skipping navboxes is a decision that was taken by the WMF team
> >> responsible for the mobile site (whatever it was called at the time)
> >> and can be solved cleanly only at the skin level, but I don't expect
> >> this to happen as long as it will break the mobile site.
> >>
> >> Your proposal would be the ideal argument for reversing the current
> >> "solution", yes, but realistically, it's not going to happen
> >> throughout the hundreds of wikis that implemented navboxes.
> >>
> >
> > Here we're talking about Isarra's very interesting project to make the
> > Monobook skin responsive, not whatever decisions WMF's mobile teams may
> > have made in the past for their mobile-only skin. She is not obligated to
> > follow their lead just because they led, and I'd recommend she doesn't in
> > this case.
>
> Maybe I wasn't clear, but that's exactly what I meant as well: I'm
> very curious to see how *Mobile MonoBook* handles that particular
> issue. I most certainly hope Isarra *doesn't* follow Minerva's
> (mis)behavior. If the solution is acceptable, perhaps it can then be
> adapted to Minerva. However, I haven't found any navboxes in the demo
> wiki.
>
> Strainu
>
> >
> > Note that's my personal recommendation and not any sort of official WMF
> > position. I likely won't even be involved in the code review for her
> patch.
> >
> >
> > --
> > Brad Jorsch (Anomie)
> > Senior Software 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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] What ways are there to include user-edited JavaScript in a wiki page? (threat model: crypto miners)

[Jon Robson]

It has always made me a little uneasy that there are wiki pages where
JavaScript could potentially be injected into my page without my approval.
To be honest if I had the option I would disable all site and user scripts
for my account.

Has this sort of thing happened before?

Can we be sure there isn't a gadget, interface page that has this sort of
code lurking inside? Do we have any detection measures in place?

Even if every edit to these pages is watched I suspect it would be very
easy for the same attack to be done in a more sophisticated way e.g.
disguising the code as a base64 image for example

On Wed, 14 Mar 2018 at 07:42 Brian Wolff  wrote:

> On Wednesday, March 14, 2018, David Gerard  wrote:
> > What ways are there to include user-edited JavaScript in a wiki page?
> >
> > I ask because someone put this revision in (which is now deleted):
> >
> >
>
> https://fa.wikipedia.org/w/index.php?title=%D9%85%D8%AF%DB%8C%D8%A7%D9%88%DB%8C%DA%A9%DB%8C:Common.js=next=22367460=en
> >
> > You can't see it now, but it was someone including a JavaScript
> > cryptocurrency miner in common.js!
> >
> > Obviously this is not going to be a common thing, and common.js is
> > closely watched. (The above edit was reverted in 7 minutes, and the
> > user banned.)
> >
> > But what are the ways to get user-edited JavaScript running on a
> > MediaWiki, outside one's own personal usage? And what permissions are
> > needed? I ask with threats like this in mind.
> >
> >
> > - d.
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> You need editinterface, edituserjs, or some of the centralnotice related
> rights (or the steward related rights to give yourself these rights).
>
> Any method that does not involve editinterface or a related right that is
> normally restricted to administrator (or higher group) should be considered
> a serious security issue in mediawiki and reported immediately.
>
> --
> Brian Wolff
> ___
> 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] Guidance for third party support and release notes

[Jon Robson]

I made a breaking change last year when I moved Minerva out of
MobileFrontend. I anticipated disruption so made sure it broke in an
obvious way (otherwise many mobile sites would start using the Vector skin
for their mobile web experience and this might be harder for sysadmins to
detect) and had instructions on how to fix it. We use semvar so I bumped
the version to show it was a breaking change and I updated mediawiki.org with
lots of docs.

What I didn't realise is lots of 3rd parties do not check their server logs
when updating and do not necessarily know what semvar means.

I'm getting feedback [1] from impacted third parties that they check the
release notes and the update script, but as far as I'm aware extensions and
skins cannot update these in any way. Is my understanding correct? If not,
is there a way we could make them do so? Either via hook or convention
(e.g. identical file name in repo)?

Do we have any guidelines for breaking changes in extensions and skins on
mediawiki.org ?

[1] https://phabricator.wikimedia.org/T172640
-- 
Jon Robson
Senior Software Engineer
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Life hack: Working with production content in your local wiki

[Jon Robson]

I've been meaning to document this for a while.
If you're finding yourself visiting Special:Export/Import often for the
purpose of MediaWiki development there is a much better way to get content
 into your local wiki for testing purposes.

This short video explains how MobileFrontend extension provides tooling to
help you debug live on-wiki content via $wgMFContentProviderClass [1]
https://youtu.be/uRQzjN0hBlY

Hope it saves someone lots of time!

[1]
https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/README.md#wgmfcontentproviderclass
-- 
Jon Robson
Senior Software Engineer
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Sunsetting Trending Edits Service before the holiday

[Jon Robson]

Since there is some confusion on the thread, I would like to clarify that I
am using EventStreams in the labs version. There is no way too use Kafka
outside production and no way to replay historical events (which was what
made this so much better in production).

(code for this is mostly in
*https://github.com/jdlrobson/wikitrender/blob/master/index.js
<https://github.com/jdlrobson/wikitrender/blob/master/index.js> *for those
interested)

On Tue, 12 Dec 2017 at 13:33 Andrew Otto <o...@wikimedia.org> wrote:

> > This is a little inferior to the production version as it is unable to
> use
> production kafka and if it has any outages it will lose data.
>
> ​EventStreams isn’t as good as using Kafka, but an outage shouldn’t be a
> reason to lose data.  Store the Last-Event-ID
> <https://wikitech.wikimedia.org/wiki/EventStreams#Format> that
> EventStreams
> gives you, and you can use it when the service starts back up to start from
> where you left off.
>
> ​>  and maybe, as others have mentioned, a good reason to get production
> Kafka events flowing into Cloud VPS backed projects.
>
> Def not opposed to a Kafka cluster in Cloud mirroring from Prod. :)
>
> BTW, this is a wee relevant:
> https://wikitech.wikimedia.org/wiki/User:Ottomata/Stream_Data_Platform
>
> This is a draft! I’m shopping this around as a program for next FY.  We
> will see!
>
>
>
>
>
>
> On Tue, Dec 12, 2017 at 4:16 PM, Gergo Tisza <gti...@wikimedia.org> wrote:
>
> > On Tue, Dec 12, 2017 at 12:12 PM, Jon Robson <jdlrob...@gmail.com>
> wrote:
> >
> > > This is a little inferior to the production version as it is unable to
> > use
> > > production kafka and if it has any outages it will lose data.
> > >
> >
> > Hopefully that gets fixed soon, Cloud VPS / Toolforge is the foundation
> for
> > out volunteer tool developer community who really shouldn't be treated as
> > second-class citizens.
> >
> > Other than that, moving to the Cloud is not a bad thing for an
> experimental
> > project IMO. It makes it easier to experiment with minimal risk, and it
> > makes it easy to add co-collaborators to your project without having to
> get
> > prod access for them.
> >
> > I'm hoping to get this onto IFTTT <https://ifttt.com/wikipedia> with
> help
> > > from Stephen Laporte in my volunteer time, as I think this feature is a
> > > pretty powerful one which has failed to find its use case in the wiki
> > > world. As Kaldari points out it's incredibly good at detecting edit
> wars
> > > and I personally have learned a lot about what our editors see as
> > important
> > > and notable in the world (our editors really seem to like wrestling). I
> > > think there are ample and exciting things people could build on top of
> > this
> > > api.
> > >
> >
> > Yeah a "give me push notifications about ongoing edit wars" tool for
> admins
> > sounds really cool. Although you'd probably want to look at revert trends
> > (or both edit and revert trends) for that.
> > ___
> > 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] Sunsetting Trending Edits Service before the holiday

[Jon Robson]

(Volunteer hat on)

I'm a little sad we didn't find a place for this in the Wikipedia apps or
web products, but I plan to maintain a labs instance going forward:
https://wikipedia-trending.wmflabs.org/
And a web presentation with a push notification feature (which notified be
this morning of the death of Ed Lee
<https://trending.wmflabs.org/en.wikipedia/Ed%20Lee%20(politician)>):
https://trending.wmflabs.org/

This is a little inferior to the production version as it is unable to use
production kafka and if it has any outages it will lose data.

I'm hoping to get this onto IFTTT <https://ifttt.com/wikipedia> with help
from Stephen Laporte in my volunteer time, as I think this feature is a
pretty powerful one which has failed to find its use case in the wiki
world. As Kaldari points out it's incredibly good at detecting edit wars
and I personally have learned a lot about what our editors see as important
and notable in the world (our editors really seem to like wrestling). I
think there are ample and exciting things people could build on top of this
api.

The gadget script is crude (as there is no way to install a service worker
via a user script) but will continue to work if you want to try it (but
Firefox only) -  I just updated it to use the new endpoint.

I will continue to explore trending's place in the Wikimedia universe :)


On Tue, 12 Dec 2017 at 10:43 Ryan Kaldari <rkald...@wikimedia.org> wrote:

> One interesting thing that I noticed about the trending edits API is that
> it was fairly useful in identifying articles that were under attack by
> vandals or experiencing an edit war. A lot of times a vandal will just sit
> on an article and keep reverting back to the vandalized version until an
> admin shows up, which can sometimes take a while. If you tweak the
> parameters passed to the API, you can almost get it to show nothing but
> edit wars (high number of edits, low number of editors).
>
> This makes me think that this API is actually useful, it's just targeted to
> the wrong use case. If we built something similar, but that just looked for
> high numbers of revert/undos (rather than edits), and combined it with
> something like Jon Robson's trending edits user script (
> https://en.wikipedia.org/wiki/User:Jdlrobson/Gadget-trending-edits.js), we
> could create a really powerful tool for Wikipedia administrators to
> identify problems without having to wait for them to be reported at AN/I or
> AIV.
>
> On Tue, Dec 12, 2017 at 7:25 AM, Corey Floyd <cfl...@wikimedia.org> wrote:
>
> > Just a reminder that this is happening this Thursday. Please update any
> > tools you have before then. Thanks!
> >
> >
> > On Fri, Dec 1, 2017 at 3:30 PM Corey Floyd <cfl...@wikimedia.org> wrote:
> >
> > > Hi all,
> > >
> > > The experimental Trending Service[1] will be sunset on December 14th,
> > 2017.
> > >
> > > We initially deployed this service to evaluate some real time features
> in
> > > the mobile apps centered on delivering more timely information to
> users.
> > > After some research [2], we found that it did not perform well with
> users
> > > in that use case.
> > >
> > > At this point there are no further plans to integrate the service into
> > our
> > > products and so we are going to sunset the service to reduce the
> > > maintenance burden for some of our teams.
> > >
> > > We are going to do this more quickly than we would for a full stable
> > > production API as the usage of the end point is extremely low and
> mostly
> > > from our own internal projects. If you this adversely affects any of
> your
> > > work or you have any other concerns, please let the myself or the
> Reading
> > > Infrastructure team know.
> > >
> > > Thanks to all the teams involved with developing, deploying,
> researching
> > > and maintaining this service.
> > >
> > > P.S. This service was based off of prototypes Jon Robson had developed
> > for
> > > detecting trending articles. He will be continuing his work in this
> > area. I
> > > encourage you to reach out to him if you were interested in this
> project.
> > >
> > > [1] https://en.wikipedia.org/api/rest_v1/#!/Feed/trendingEdits
> > > [2]
> > > https://meta.wikimedia.org/wiki/Research:Comparing_most_
> > read_and_trending_edits_for_Top_Articles_feature
> > >
> > >
> > >
> > > --
> > > Corey Floyd
> > > Engineering Manager
> > > Readers
> > > Wikimedia Foundation
> > > cfl...@wikimedia.org
> > >
> > --
> > Corey Floyd

Re: [Wikitech-l] Recommending Firefox to users using legacy browsers?

[Jon Robson]

The best way we can invest in Firefox is via open web technology such as
push notifications imo.

On Thu, 31 Aug 2017 at 16:51 Max Semenik  wrote:

> +1 to that. Additionally, the proposed method wouldn't even work because we
> blacklist crappy browsers from receiving JS.
>
> On Thu, Aug 31, 2017 at 1:37 PM, bawolff  wrote:
>
> > On Thu, Aug 31, 2017 at 8:14 PM, Legoktm 
> > wrote:
> > > Hello,
> > >
> > > This was something that came up during "The Big Open" at Wikimania,
> when
> > > Katherine Maher talked with Ryan Merkley (CEO of Creative Commons) and
> > > Mark Surman (ED of Mozilla Foundation). One of the themes mentioned was
> > > that our projects need to work together and support each other.
> > >
> > > In that vein, I'm interested in what people think about promoting
> > > Firefox to users who are using legacy browsers that we don't support at
> > > Grade A (or some other criteria). As part of the "drop IE8 on XP"
> > > project[1] we're already promoting Firefox as the alternative option. I
> > > was imagining it could be a small and unobtrusive bubble
> > > notification[2], similar to those that Google pushes Chrome on people
> > with.
> > >
> > > If users use modern browsers, they're going to have better security
> > > support, and most likely a better experience browsing Wikimedia sites
> > > too. We'd be improving the web by reducing legacy browsers, and
> allowing
> > > us to move forward with newer technology sooner (ideally).
> > >
> > > And we'd be supporting a project that is ideologically aligned with us:
> > > Mozilla.
> > >
> > > Thoughts, opinions?
> > >
> > > [1] https://phabricator.wikimedia.org/T147199
> > > [2] https://www.mediawiki.org/wiki/Bubble_notifications
> > >
> > > Thanks,
> > > -- Legoktm
> > >
> > > ___
> > > Wikitech-l mailing list
> > > Wikitech-l@lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> > I'm concerned this would be seen as an inapropriate bias.
> >
> > Suggesting Firefox for IE8 on XP makes sense because it is basically
> > the only option for that platform that is reasonably secure and not
> > super obscure. Promoting firefox is general for legacy browsers seems
> > like a slippery slope to me.
> >
> > Additionally, I think this is more a political than a technical
> > decision, and one that would require consultation with the general
> > Wikimedia community (e.g. Meta RFC).
> >
> > --
> > Brian
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
>
>
>
> --
> 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] Update to web print styles

[Jon Robson]

On Wed, Aug 30, 2017, 10:16 AM Bartosz Dziewoński 
wrote:

> On Mon, Aug 28, 2017 at 10:18 PM, Isarra Yos  wrote:
>
> > Are these changes in core, or in the skins themselves (Vector and
> > Minerva)? In other words, will printing from other deployed skins such as
> > MonoBook also see improvement, or is it up to the maintainers of each
> other
> > skin to independently apply similar changes?
> >
>
> As far as I know, the big features are only in Vector, but core styles have
> also received a few tweaks.
>

Yep that's right. They are also feature flagged. There are also some in
MediaWiki:Print.css

Most of the styles in Vector could be applied to all skins if that's useful
provided they can be overridden  (via getDefaultModules ) but that's not a
priority right now whole we get these tested  and easily done later on.

Minerva doesn't need these styles for instance.




>
> https://gerrit.wikimedia.org/r/#/q/message:print+(project:mediawiki/core+OR+project:mediawiki/skins/Vector)+is:merged
>
>
> --
> Matma Rex
> ___
> 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 CI failed due to lack of tidy.so [solved]

[Jon Robson]

Thank you for shedding light on this!


On Tue, 27 Jun 2017 at 12:44 zppix e  wrote:

> Thanks. Was wondering what went wrong.
>
> Zppix
> Volunteer developer for WMF
> enwp.org/User:Zppix
>
> On Jun 27, 2017 1:55 PM, "Antoine Musso"  wrote:
>
> > Hello,
> >
> > Jenkins jobs relying on HHVM had troubles today exiting with:
> >
> >   /usr/lib/x86_64-linux-gnu/hhvm/extensions/20150212/tidy.so:
> >   cannot open shared object file: No such file or directory
> >
> > The root cause is installing libtidy-dev ends up uninstall the HHVM tidy
> > extension (hhvm-tidy).
> >
> > The issue occurred between 16:20 UTC and 18:45 UTC.  To the best of my
> > knowledge it is fully solved.
> >
> > Sorry for the inconvenience :(
> >
> >
> > Ref:
> > https://phabricator.wikimedia.org/T169004
> > Follow up task:
> > https://phabricator.wikimedia.org/T169008
> >
> > --
> > 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

Re: [Wikitech-l] How does a build process look like for a mediawiki extension repository?

[Jon Robson]

 For PHP deps we've got composer dependency installation for extensions, so
> it seems like there's an opportunity to do other build steps in this
> stage...

Definitely. If we can hook into the existing composer build step that seems
like it would make the most sense e.g. post-update post-install

What's the best wiki page to get an overview of how deployment to the beta
cluster/production works? I'd like to tinker with these and see if I can
get one of those steps running npm jobs.



On Thu, 15 Jun 2017 at 03:01 Joaquin Oltra Hernandez <
jhernan...@wikimedia.org> wrote:

> Thanks for the comprehensive responses.
>
>
>
>
>
>
>
>
>
>
>
> *I can certainly stillsee the possible benefit of having a full fledged
> build step for core,skins, and extensions. It is something that should be
> thought about abit before diving right into an implementation though. One
> thing toconsider is if what would be best is a packaging step that leads to
> atarball or similar artifact that can be dropped into a runtimeenvironment
> for MediaWiki or if instead it would be better to have aunified post-deploy
> build step that operates across MediaWiki core andthe entire collection of
> optional extensions and skins deployed tocreate a particular wiki.*
>
> Totally agree, it is something that needs careful consideration. Even if
> the choice is to have a per-extension packaging step that produces a
> deployable, it would be great to have shared conventions across repos to
> run it (something like a *scripts/build{.sh,.bat}* that internally performs
> the specific build steps of the project.
>
> If that exists, then we can build into core the build step that coordinates
> those sub-build steps where needed.
>
>
>
>
>
>
> *One of the awesome features of working on a PHP codebase is the quickcycle
> of making a change and seeing it live in your test environment.Today that
> is mostly a matter of saving an edit and hitting refresh ina browser. It
> would be sad to lose that, so the build system that isdevised should also
> provide a path that allows a git clone to be aviable wiki.*
>
> That is indeed nice, but it is already the case of many extensions and
> repos that have build steps for frontend code (see grunt and makefiles in
> extensions), it is just that we run them adhoc in developer's machines and
> use git's master as the deploy tarball.
>
> This means that the deploy tarball has built assets that depend on who
> built and committed something, and whatever tools they had on their local
> system (node, npm, grunt and node_modules libraries), instead of in a
> reproducible place like our CI machines.
>
> For whatever reason, the reality is the front-end world has moved to node
> based tooling and build steps, so all the great tools that are well
> maintained are run in a build step (unless you run node.js on your server
> and plug it in there). That's why many projects use grunt and tools from
> npm for linting, optimizing images, and other tasks.
>
> I think that coming up with a standard build process would allow us to do
> away with the adhoc way of building things into the repository on master,
> and allow us to painlessly introduce some very interesting improvements to
> front-end tooling.
>
>
> On Thu, Jun 8, 2017 at 6:07 PM David Barratt 
> wrote:
>
> > Symfony is going to start recommending the use of `make` starting with
> > version 4, so it might be something worth exploring:
> > http://fabien.potencier.org/symfony4-best-practices.html#makefile
> >
> > (I have no opinion on the matter)
> >
> > On Wed, Jun 7, 2017 at 5:48 PM, Bryan Davis  wrote:
> >
> > > On Wed, Jun 7, 2017 at 2:29 PM, Brion Vibber 
> > > wrote:
> > > > On Wed, Jun 7, 2017 at 10:18 AM, Joaquin Oltra Hernandez <
> > > > jhernan...@wikimedia.org> wrote:
> > > >
> > > >> *Context*
> > > >>
> > > >> We'd like to have a build script/process for an extension so that I
> > can
> > > >> perform certain commands to install dependencies and perform
> > > optimizations
> > > >> on the extension sources. For example, on front-end sources.
> > > >>
> > > >> Some examples could be:
> > > >>
> > > >>- Installing libraries from bower or npm and bundling them into
> the
> > > >>resources folder
> > > >>- Applying post processing steps to CSS with something like post
> > css
> > > >>- Optimizing images
> > > >>
> > > >> We are aware of other projects that have build processes for
> building
> > > >> deployables, but not extensions.
> > > >> Such projects have different ways of dealing with this. A common way
> > is
> > > >> having a repository called /deploy and in there you pull
> from
> > > >>  and run the build scripts, and that is the repository that
> > > gets
> > > >> deployed.
> > > >>
> > > >> *Current system*
> > > >>
> > > >> The current way we usually do this (if we do) is run those build
> > > >> scripts/jobs on the developers machines and commit them into the git
> > > 

Re: [Wikitech-l] Fwd: Notes on Mediawiki Hackathon 2017, Vienna, Austria

[Jon Robson]

Very neat. Thanks for taking the time to share and for attending! I hope
others share their experiences as well!

On Mon, 22 May 2017, 11:48 am Jaime Crespo,  wrote:

> On Mon, May 22, 2017 at 3:39 AM, Shrinivasan T 
> wrote:
> > Hi friends,
> > Will fix few issues and host it on a server soon. Till then try
> > installing in your local computers and try it out.
>
> That is really cool! Remember you have available hosting resources at
> the Wikimedia infrastructure if you want them:
> https://wikitech.wikimedia.org/wiki/Help:Cloud_Services_Introduction
>
> ___
> 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] Results of the Developer Wishlist are in

[Jon Robson]

Would it be possible to also get these ranked such that they exclude WMF
staff?

I'd be interested to see how the priorities change. I'm interested
specifically in what pain points newcomers to our code might experience.

On Tue, 14 Feb 2017, 11:45 p.m. Quim Gil,  wrote:

> On Wed, Feb 15, 2017 at 3:32 AM, Gergo Tisza  wrote:
>
> > Hi all,
> >
> > voting for the Developer Wishlist [1] has ended. Thanks to everyone who
> > participated! And extra thanks to everyone who helped. [2] You can find
> the
> > the results, with links to the full proposals, at:
> >
> > https://www.mediawiki.org/wiki/User:Community_Tech_bot/
> > WishlistSurvey/Votes
> >
> > As you might have read on the wishlist page, this is a
> primarily-volunteer
> > run experiment. It can only be successful with your help! [3] If you can
> > afford the time, please look through the highly-voted propsals and see if
> > you can find something you would be interested to work on. I also invite
> > everyone to participate in these three follow-up tasks:
> >
> > https://phabricator.wikimedia.org/T158148 - promote wishlist proposals
> > https://phabricator.wikimedia.org/T158149 - find owners for the top10
> > proposals
> > https://phabricator.wikimedia.org/T158150 - post-mortem
> >
> >
> > thanks
> > Gergő
> >
>
> Thank *you* very much, Gergő! The first wish of the Developer Wishlist was
> to have a Developer Wishlist in the first place. You proposed, promoted,
> engaged with others, and worked a damn lot. You made it!
>
> Now it's the turn for the rest of us. I am going to ask the Foundation's
> technical management to have this wishlist in mind in the annual plan
> discussion that are happening right now. I will discuss with my team which
> wishes we could / should commit to.
>
>
>
> >
> >
> > [1] https://www.mediawiki.org/wiki/Developer_Wishlist
> > [2] Including, but not limited to: Srishti Sethi who handled most of the
> > communications; Quim Gil and James Forrester who helped a lot with the
> > planning; Leon Ziemba who ran the survey maintenance bot; Jeph Paul and
> > Jonathan Morgan who wrote the original version of the voting button
> gadget;
> > all the people working on the Community Wishlist from which I stole the
> > idea and most of the process/design.
> > [3] https://i.imgflip.com/1jnzy6.jpg
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
>
> --
> Quim Gil
> Engineering Community Manager @ Wikimedia Foundation
> http://www.mediawiki.org/wiki/User:Qgil
> ___
> 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] MVVM/Single-State solution for our UIs?

[Jon Robson]

I think at this point Mediawiki's frontend stack and its dependencies on RL
and supporting user gadgets don't lend itself well to frameworks like React
or Vue.  With regards to moving away from jQuery UI your path of least
resistance inside MediaWiki feels like it might be to use a library such as
Redux for managing your state and OOjs UI for rendering the UI components.

Frameworks by definition provide you with rules and constraints to prevent
you from writing code in bad ways leading you to easier to work with code.
The MediaWiki ecosystem doesn't do well with constraints - it's about
experimenting.

That aside, I'm curious if you have considered a different approach. One
big issue we commonly see in the reading web team in working with
MobileFrontend and our apps team who depend on our APIs is that the lines
of model and view get blurred frequently. There are certain things our API
doesn't do and that we workaround in PHP code - the only place we can do
this. I was a little worried about this, so as a side project I explored
how difficult it was to render the existing mobile site without MediaWiki's
PHP layer.  I built a progressive web app (PWA) using React (just a
personal preference but any framework could be used to do the same). The
result is deployed on labs: https://trending.wmflabs.org
and the code on Github: https://github.com/jdlrobson/weekipedia

At first, this may seem like a lot of work but it wasn't. I reused Mediawiki
 code where possible (packaging up into npm libraries) and what I found was
feature development became extremely easy the more that I implemented as
reuse was extremely useful within the framework.

The React web app now has feature parity with the mobile site - it looks th
esame, you can login support via OAuth (thanks to the awesome work from Gergő
Tisza and co), there's i18n support
,
you can edit you can view history/diffs etc etc... we've been using it
for user testing. Since things got so easy I even got carried away and
built features I've wanted forever ;-) [1]:

If I exclude the time I spent improving Mediawiki REST APIs to support this
app I reckon building this took about a month of work (and that wasn't even
full time). Yes, the solution had many trade-offs... My app cannot run
gadgets or CSS/JS from the Mediawiki namespace and certain pages which
require additional JavaScript e.g. maps/pages with math do not load that Js
- but I see those problems as easily solvable and I value the benefits I
experienced through working within a well-documented framework...

So I'm curious... for something like Wikidata which is so different from
standard Mediawiki instances =(the rendering and editing experiences are
fundamentally different) what's stopping you from adding a layer on top of
the stack and using Mediawiki as a black box for storage and API... at
least as an alternative editing experience?

Having complete APIs and enabling our future and present community members
to be able to build things like this easily should be our goal as engineers.

It's worth pointing out that Chrome has plans to allow developers to
package web apps as installable APKs (see
https://joreteg.com/blog/installing-web-apps-for-real). What this means is
with a bit of configuration I could update my PWA to override all visits to
Wikimedia domains and steal traffic. I think when this happens lots of
developers will be jumping on this opportunity. This is great for
distributing our knowledge, not so good about keeping a unified experience
for all our visitors. I'd rather we were ahead of that trend rather than
lagging behind.

Happy to chat more if you find this conversation interesting. I've covered
a lot here... :)
[1] e.g.
* infinite random -  https://trending.wmflabs.org/en/wiki/Special:Random
* the trending work turned into a REST API that we're still experimenting
with and offline support.
* cross-wiki search -
https://trending.wmflabs.org/en.wikiquote/Special:Search/San%20Francisco


On Tue, 31 Jan 2017, 5:06 a.m. Jan Drewniak, 
wrote:

Certainly a topic for the front-end standards group, but to give my two
cents:

Many of these new JS libraries, such as React, have some very heavy
dependancies.
React requires JSX which needs to be transpiled into JS, ES6 Class syntax
which needs to be transpiled into ES5, which requires Babel and probably a
task runner like Grunt or Gulp (or webpack), which of course require Node
and NPM... so already you've built a very heavy dependancy chain which
itself needs to be maintained (ex: Gulp 4 is coming with breaking changes)
and all this needs to be integrated into MediaWiki which has its own way of
doing things.

None of that sounds like fun to me, so however you proceed I would
certainly aim to avoid all that .


On Tue, Jan 31, 2017 at 11:13 AM, Derk-Jan Hartman <
d.j.hartman+wmf...@gmail.com> wrote:

Re: [Wikitech-l] I want to write an extension, let us consult its syntax and API

[Jon Robson]

Are you familiar with the Popups extension?
https://www.mediawiki.org/wiki/Extension:Popups
I wonder if with some adjustments this could be made to meet your needs?


On Mon, 26 Dec 2016 at 19:14 Victor Porton  wrote:

> I want a small popup to be displayed when I hover over a link to a
> certain namespace.
>
> Note that the popup has nothing to do with the page to which it links.
>
> So for example, I want a link to A:X and when I hover the mouse over it
> I want to display B:X in a small popup (where A and B are namespaces).
>
> Note that B:X is a short page, it should be displayed in the popup
> completely (not just its announce or description).
>
> Note also that I need the popup to be "stable" enough, so that I could
> move the mouse (without the tooltip disappearing) and click a link in
> the tooltip.
>
> ---
>
> I am considering to write a new extension for this myself. But first I
> want to consult its syntax and API.
>
> For me personally the best mode of functionality is the following:
>
> In LocalSettings.php write an associative array mapping of namespaces:
> A=>B, etc. Then make popups for ALL links to objects in A (on every
> page which links to namespace A).
>
> However, other users may want different API and syntax, for example:
>
> [[A:X|X]]
>
> Please discuss with me which APIs and syntaxes should be available.
>
> --
> Victor Porton - http://portonvictor.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] Mobile JavaScript

[Jon Robson]

That's correct. I should not mobile.css exists for the css equivalent and
is a little more popular:
 https://en.wikipedia.org/wiki/MediaWiki:Mobile.css

On Thu, 13 Oct 2016 at 20:54 Denny Vrandečić <vrande...@gmail.com> wrote:

> Thanks Dmitry and Jon! That's the info I was looking for.
>
> Since both https://en.wikipedia.org/wiki/MediaWiki:Mobile.js and
> https://en.wikipedia.org/wiki/MediaWiki:Minerva.js are empty, does that
> mean English Wikipedia has no local JavaScript? Nice!
>
> Cheers,
> Denny
>
>
> On Thu, Oct 13, 2016 at 6:48 PM Jon Robson <jdlrob...@gmail.com> wrote:
>
> > The web runs MediaWiki:mobile.js or MediaWiki:minerva.js (skin) but not
> > MediaWiki:Common.js
> > It's my regret that we created MediaWiki:mobile.js to make this more
> > confusing ...  so I'd advise using minerva.js ... :) Similar
> > User:Name/minerva.js will work for a user.
> >
> >
> > On Thu, 13 Oct 2016 at 17:20 Dmitry Brant <dbr...@wikimedia.org> wrote:
> >
> > > Hi Denny,
> > >
> > > Speaking for the apps, we do not load any JavaScript, except for a few
> > > packaged scripts used for app-specific features (e.g. collapsing
> > > infoboxes).
> > >
> > >
> > > -Dmitry
> > >
> > > On Thu, Oct 13, 2016 at 7:30 PM, Denny Vrandečić <vrande...@gmail.com>
> > > wrote:
> > >
> > > > Two stupid questions, I couldn't find the answer on MediaWiki.org:
> > > >
> > > > 1) is MediaWiki:common.js being loaded on the mobile web view? Or any
> > > other
> > > > js? What about User:Name/common.js?
> > > >
> > > > 2) same question but for the Wikipedia app. Does the app run any js?
> > > > ___
> > > > Wikitech-l mailing list
> > > > Wikitech-l@lists.wikimedia.org
> > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > >
> > >
> > >
> > >
> > > --
> > > Dmitry Brant
> > > Senior Software Engineer / Product Owner (Android)
> > > Wikimedia Foundation
> > > https://www.mediawiki.org/wiki/Wikimedia_mobile_engineering
> > > ___
> > > 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] Mobile JavaScript

[Jon Robson]

The web runs MediaWiki:mobile.js or MediaWiki:minerva.js (skin) but not
MediaWiki:Common.js
It's my regret that we created MediaWiki:mobile.js to make this more
confusing ...  so I'd advise using minerva.js ... :) Similar
User:Name/minerva.js will work for a user.


On Thu, 13 Oct 2016 at 17:20 Dmitry Brant  wrote:

> Hi Denny,
>
> Speaking for the apps, we do not load any JavaScript, except for a few
> packaged scripts used for app-specific features (e.g. collapsing
> infoboxes).
>
>
> -Dmitry
>
> On Thu, Oct 13, 2016 at 7:30 PM, Denny Vrandečić 
> wrote:
>
> > Two stupid questions, I couldn't find the answer on MediaWiki.org:
> >
> > 1) is MediaWiki:common.js being loaded on the mobile web view? Or any
> other
> > js? What about User:Name/common.js?
> >
> > 2) same question but for the Wikipedia app. Does the app run any js?
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
>
> --
> Dmitry Brant
> Senior Software Engineer / Product Owner (Android)
> Wikimedia Foundation
> https://www.mediawiki.org/wiki/Wikimedia_mobile_engineering
> ___
> 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] Feature Requests: Suggeted new features

[Jon Robson]

Hi Aaron
*Summaries - popup summaries for pages*
sounds a little like the project my team is working on -
https://www.mediawiki.org/wiki/Extension:Popups

It would be awesome to have your assistance in testing/coding (if you're
that way inclined).

If you are interested in this project please come say hi in
#wikimedia-mobile on IRC or join the conversation here:
https://www.mediawiki.org/wiki/Talk:Beta_Features/Hovercards

On Sun, 9 Oct 2016 at 17:24 Aaron Gray  wrote:

> Hi MZ & Andre,
>
>
>
> Had a look at the phabricator project manager but there does not really
>
> seem to be an overview of projects jut an alphabetical list with only the
>
> first 25 or so projects showing. I tried doing searches on summary,
>
> category and classification. But no joy.
>
>
>
> I looked at the MediaWiki source code and found that Categories do what my
>
> categories "bread crumbs" idea does but is a name clash. Really what I was
>
> trying to express was *classification* anyway and these n classification
>
> category in Wikipedia so that could be used as a base then things like the
>
> animal kingdom, biology, physics, etc, can be subcateories or classified
>
> under the classification category. So it jut needs bread crumbs implemented
>
> as an extension that uses the classification category and fits in with a
>
> {{classification ...}} markdown syntax extension.
>
>
>
> So anyway I am open to any guidance.
>
>
>
> Regards,
>
>
>
> Aaron
>
>
>
> On 9 October 2016 at 17:46, MZMcBride  wrote:
>
>
>
> > Hi Aaron,
>
> >
>
> > You probably want to file these ideas in Phabricator Maniphest:
>
> > . Some of these ideas may already
> exist
>
> > as Maniphest tasks. Phabricator lets interested users subscribe to the
>
> > ideas in order to receive targeted e-mail notifications, provide
> feedback,
>
> > and it gives us a centralized place to track progress, blockers to
>
> > implementation, and more. I'm glad to see you're excited to contribute.
>
> >
>
> > 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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Recently proposed patchsets by new contributors awaiting code review

[Jon Robson]

Andre,
Thanks for these e-mails. It really helps having an overview of where we
can help. I really appreciate them.

Would you be also open to flagging some of our oldest patches as part of
this mail (I think you are right to keep the number of patches low - a long
list can be overwhelming)?

I just ran a Gerrit query and found these old patches that had no merge
conflicts. I'd love to get us to a point where at least core's patchsets
are weeks old rather than months. It seems these e-mails could be a good
mechanism for reaching the right people.

Some old patches:
Added custom label for links in category pages
https://gerrit.wikimedia.org/r/#/c/104905/

Add category name in ID property for extension row in Special:Version page
https://gerrit.wikimedia.org/r/#/c/275836/2



On Thu, 22 Sep 2016 at 06:49 Andre Klapper  wrote:

> Your help is welcome to provide feedback and guidance:
>
> == in "mediawiki/tools/mwdumper": ==
>
> since 2016-09-08:
> Major refactoring
> https://gerrit.wikimedia.org/r/#/c/309314/
>
> Thanks in advance for your reviews.
>
>
> Of last weeks' 5 listed patches, 4 got merged & 1 got reviewed. Thanks
> to Amire80, Daniel, FlorianSW, Jdlrobson, MatmaRex, Smalyshev, Tjones!
>
> andre
> --
> Andre Klapper | Wikimedia Bugwrangler
> http://blogs.gnome.org/aklapper/
>
> ___
> 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] 25 VectorBeta and CPBbeta open tasks need cleanup, please

[Jon Robson]

After checking all these tasks, it seems all these tasks can be
declined as this project is no longer maintained.


On Mon, Aug 15, 2016 at 7:36 PM, Danny B. <wikipedia.dann...@email.cz> wrote:
> Hello.
>
> https://phabricator.wikimedia.org/tag/mediawiki-extensions-vectorbeta/
> contains 21 open tasks of which
>
> * 13 are not tagged with any other open project
> * 3 are not tagged by anything but yellow tags (= no projects, teams, goals,
> releases...)
> * 1 is tagged Wikimedia-General-or-Unknown
>
> https://phabricator.wikimedia.org/tag/compact-personal-bar-beta/ contains 21
> open tasks of which
>
> * 11 are not tagged with any other open project
> * 3 are not tagged by anything but yellow tags (= no projects, teams, goals,
> releases...)
> * 1 is tagged Wikimedia-General-or-Unknown
>
> (17 of these tasks are tagged with both of these archived projects, so the
> real total of tasks in both projects is 25.)
>
> Because I don't know details about these two projects and their archiving, I
> would like to ask whoever relevant to perform some cleanup, which means one
> or both of following actions:
>
> * tag the task with any open project (except for generic "Wikimedia-General-
> or-Unknown" or "MediaWiki-General-or-Unknown: or such), team, goal or
> release
> * close the task with appropriate resolution
>
>
> Thank you for helping to keep Phabricator swept.
>
>
> Kind regards
>
>
> Danny B.
> ___________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Jon Robson
* http://jdlrobson.com
* https://www.facebook.com/jonrobson
* @rakugojon

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

Re: [Wikitech-l] [WikimediaMobile] Redlinks in Android app

[Jon Robson]

Please also note the parent bug and rfc which blocks that. I've cced
wikitech in case anyone has an update.

https://phabricator.wikimedia.org/T39902
On 3 Aug 2016 5:14 a.m., "Stephen Niedzielski" 
wrote:

> Hello! Thank you for the report! This issue is currently being tracked
> here[0]. We had hoped to fix this properly but maybe we should consider a
> temporary change in the client to handle this more gracefully.
>
> [0] https://phabricator.wikimedia.org/T119266
>
> On Wed, Aug 3, 2016 at 4:21 AM, Andy Mabbett 
> wrote:
>
>> The Android Wikipedia app shows Wikipedia's red links as blue links,
>> then returns a user-unfriendly 404 error page, with the somewhat
>> dishonest text "an unknown error occurred".
>>
>> Alternative, and better, behaviours would be one of (in no particular
>> order):
>>
>> * Show a red link; behave like desktop Wikipedia
>>
>> * Show a red link; when the link is selected, show a customised 404
>> page, which advises users how start a new article
>>
>> * Show red text, but make it non linking (i.e. "unclickable")
>>
>> * Remove the link and colour-styling, and render ordinary text
>>
>> * Fix the erorr page so it says "Sorry, that page does not exist",
>> with a link to a guide to starting a new article
>>
>> --
>> Andy Mabbett
>> @pigsonthewing
>> http://pigsonthewing.org.uk
>>
>> ___
>> Mobile-l mailing list
>> mobil...@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-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] BetaFeatures grafana dashboard

[Jon Robson]

Thank you

On Fri, Jul 29, 2016 at 10:21 AM, Greg Grossmeier <g...@wikimedia.org> wrote:
> 
>> On Fri, Jul 29, 2016 at 3:54 AM, Addshore <addshorew...@gmail.com> wrote:
>> >
>> > Recently WMDE started rolling out the RevisionSlider beta feature to a
>> > handful of wikis.
>> >
>> > We wanted to track how many people were using the feature as well as how
>> > many people were enabling / disabling it per day.
>> >
>> > Getting this data for all beta features is no more difficult than getting
>> > it for the RevisonSlider only.
>> > Thus we now have this dashboard, Enjoy!
>> >
>> > https://grafana.wikimedia.org/dashboard/db/betafeatures
>> >
>> > Any comments / suggestions are very welcome.
>>
>> Thanks for working on this kind of data collection and visualization Adam.
>
> +1, thanks!
>
> --
> | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
> | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Jon Robson
* http://jdlrobson.com
* https://www.facebook.com/jonrobson
* @rakugojon

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

Re: [Wikitech-l] Crediting the work of our community members

[Jon Robson]

Yes!
And thank you Brion for such a thoughtful well-thought out reply!

On Tue, Jul 5, 2016 at 11:17 AM, Rob Lanphier <ro...@wikimedia.org> wrote:
> On Tue, Jul 5, 2016 at 10:33 AM, Brion Vibber <bvib...@wikimedia.org> wrote:
>> On Mon, Jul 4, 2016 at 9:06 AM, Jon Robson <jdlrob...@gmail.com> wrote:
>>> I've created the following 2 actionable tasks:
>>> https://phabricator.wikimedia.org/T139300
>>> https://phabricator.wikimedia.org/T139301
>>>
>>> I hope we can reach a decision somewhat promptly with this.
>>
>> Jon, I like both of these.
> [...]
>> These should probably both go through our ArchCom RfC process, which we're
>> trying to get more involvement in both from WMFers and others.
>
> That sounds like a good idea.  Jon, are you amenable to that?  If so,
> one of us should add the #ArchCom-RFC project tag to one or both of
> these.
>
> 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] Crediting the work of our community members

[Jon Robson]

Sorry I dropped the ball on this.
I've created the following 2 actionable tasks:
https://phabricator.wikimedia.org/T139300
https://phabricator.wikimedia.org/T139301

I hope we can reach a decision somewhat promptly with this.
Jon


On Tue, Jun 7, 2016 at 8:14 PM, Scott MacLeod <helia...@gmail.com> wrote:
> Rob and Wikimedians,
>
> To further credit the work of Wikimedia community members, could we explore
> using the Douglas Adams' SQID example (which Markus shared with the
> Wikidata list recently ... [Wikidata] SQID evolved again: references
> http://tools.wmflabs.org/sqid/#/view?id=Q42 ) ... and build upon this
> incorporating the Wikipedia user pages (and your above examples) a
> Wikipedia crediting process anticipating/planning for all 11 billion people
> (an estimate from Swedish statistician Hans Rosling and many others) in all
> 8,000 languages. (CC World University and school is planning in parallel to
> be in all 8,000 languages and plan for all people on earth by 2100, as well
> as seek to build in Bitcoin and Blockchain in conjunction with developing
> best STEM CC OpenCourseWare centric law schools in all countries' main
> languages, even as WUaS develops CC university degrees accrediting  on CC
> MIT OCW in 7 languages and CC Yale OYC).
>
> This would potentially lead to further planning for integrating
> Wikidata/Wikibase via SQID with Wikitech/Wikimedia/Wikipedia community
> members' contributions and in many languages.
>
> Cheers, Scott
>
>
>
> On Tue, Jun 7, 2016 at 11:14 AM, Rob Lanphier <ro...@wikimedia.org> wrote:
>
>> On Tue, Jun 7, 2016 at 9:19 AM, Andre Klapper <aklap...@wikimedia.org>
>> wrote:
>> > Is there a Phabricator task [associated with MediaWiki CREDITS file
>> membership] so this topic does not get forgotten?
>>
>> Not that I'm aware of.  It's easy to get lost looking through the
>> various attempts to objectively characterize contributions (he says,
>> just emerging from the fog of doing so himself).  Here's a few places
>> a person could go:
>> * <https://korma.wmflabs.org/browser/scm.html>
>> * <https://www.openhub.net/p/mediawiki/contributors>
>> * <https://github.com/wikimedia/mediawiki/graphs/contributors>
>> * <http://koti.kapsi.fi/~federico/crstats/core.txt>
>>
>> ...and that's hardly comprehensive.  The "productivity of mediawiki
>> developers" thread from April[1] probably has some other sources I've
>> missed.  If I were to spend more time on this, I would start looking
>> for the Phab tickets associated with the stats on Korma.
>>
>> I concur with Jon that we should endeavor to move to a more objective
>> (and ideally, more automated) mechanism for acknowledgement, so that
>> we don't have to rely on contributors confidently declaring that they
>> deserve acknowledgement.
>>
>> Rob
>> [1]
>> http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/86127
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
>
>
> --
>
> - Scott MacLeod - Founder & President
> - 415 480 4577
> - http://scottmacleod.com
> - Please donate to tax-exempt 501 (c) (3)
> - World University and School
> - via PayPal, or credit card, here -
> - http://worlduniversityandschool.org
> - or send checks to
> - PO Box 442, (86 Ridgecrest Road), Canyon, CA 94516
> - World University and School - like Wikipedia with best STEM-centric
> OpenCourseWare - incorporated as a nonprofit university and school in
> California, and is a U.S. 501 (c) (3) tax-exempt educational organization.
> ___
> 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] Crediting the work of our community members

[Jon Robson]

"I came across a patch from a user who was keen to move himself from
"Patch contributors" to "Developers" in the MediaWiki  CREDITS file
[1]. It had been sitting there for over a year. He doesn't seem to
have been active since. I don't know what to do with it. It made me
think.

Do we have it documented anywhere how we use this credits file and why
we feel the need to distinguish between Developers and Patch
Contributors? It seems like a recipe for disaster in my opinion as it
can only lead to hurt feelings due to contributors feeling unfairly
treated. https://www.mediawiki.org/wiki/Special:Version/Credits leads
with 'We would like to recognize the following persons for their
contribution to MediaWiki." - if someone is not in that list are they
not as important?

If we keep these files we should probably explain the rules to what
adding names looks like within these files and what the process to
adding your name is (can I add myself? Is there a process like getting
+2?)

To take another extreme, we might consider abandoning such a file in
favour of something automatically generated. Things like
https://github.com/wikimedia/mediawiki/graphs/contributors do a far
better job at allowing people to see who contributed to a tool and
making people feel like their work is rewarded.

On a slightly related note, can we abandon the practice of putting
names inside files themselves? I see this practice in JavaScript and
PHP files throughout core (grep for @author). As Team Geek [2] (great
read btw) says "unlike other collaborative pieces of creative work...
software keeps changing even after it's "done". So while listing
contributors credits at the end of a movie is a safe and static thing,
attempting to add and remove names from a source file is a
never-ending exercise in insanity". For similar reasons this practice
gives an impression of ownership of a file/code review
responsibilities (which are not always true) and risks hurt feelings.

[1] https://github.com/wikimedia/mediawiki/blob/master/CREDITS
[2] 
http://www.amazon.com/gp/search?index=books=qs=9781449302443

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

Re: [Wikitech-l] I'd love to contribue. Can anyone help me get started?

[Jon Robson]

Likewise if you want to help us do exciting stuff on wikipedia mobile web
give me a shout on my email or via irc (irc.freenode.org #wikimedia-mobile)
On 18 May 2016 3:40 p.m., "Brian Wolff"  wrote:

> On Wednesday, May 18, 2016, Ty Landercasper 
> wrote:
> > I'm a self employed programmer who's taking a bit of time off
> from his
> > current project as a way to gain some fresh perspective and I thought I'd
> > use that free time to help out a community I really appreciate. Wikipedia
> is
> > one of the best things the internet has to offer and it has certainly
> helped
> > me out a bunch of times, so it seemed like the place to volunteer.
> >
> > My problem is that is that I haven't done any sort of
> collaborative
> > opensource project before, (the closest I've come to opensource is
> writing
> > the compare plugin for Notepad++), and I'm not entirely sure what the
> best
> > way to go about it is.
> >
> > I was wondering if someone there is willing to play the role of
> onboarding
> > manager. You know, show me the ropes, assign some good relevant tasks to
> get
> > a feel for things, the standard stuff. I'd really appreciate it, and I
> know
> > I can contribute a lot to the community once I get on my feet.
> >
> >
> > As for my skill set, while I don't have a lot of experience with
> PHP, I do
> > have a lot of experience with just about everything else. I've done game
> > development, mobile development, web development and even some good old
> > fashioned desktop development, (not that anyone still uses desktop apps).
> I
> > have no doubt that I can pick up the language quickly enough and I'm sure
> > Google (the great teacher of all things) will help me figure out the
> rest.
> >
> > I'm attaching my resume, so that you can get a feel for my
> experience.
> > (Plus it just seems like the thing to do in this situation.)
> >
> > I'm looking forward to getting started!
> > Ty Landercasper
> > t...@ibudesigns.com
> >
> >
> > RESUME:
> >
> > OBJECTIVE:
> > I'm one of those programmers who got into it for the love of
> programming
> > and it shows. I've programmed on everything from the TI-83 to the Xbox
> 360,
> > and if there's a skill I don't have than all I need is an excuse to learn
> it
> > and I will. I turned a hobby project into a business that supported me
> for
> > several years so I've learned a lot about how to make an amazing product
> > that succeeds even in the ruthless market that is the app store, as well
> as
> > the softer skills that you need to run a business.
> >
> > I'm looking for a good home. A start up or a startup like environment
> where
> > there's more work than time and everyone has to wear multiple hats, and
> > figure out how to get things done and even what can be done, because
> those
> > are the environments that I thrive in.
> >
> > COMPUTER SKILLS:
> > Visual Studio, C#,C++, Java, C, Visual Basic
> > 4+ years iPhone, Android, Blackberry, Windows Mobile development
> > Unity, Flash, Actionscript 2.0, ActionScript 3.0, Flex framework,
> Silverlight
> > ASP.NET, AJAX, HTML, DHTML, CSS, Javascript, JSP
> > Thirteen years experience with .NET
> >
> >
> >
> > EXPERIENCE:
> > Owner Pixelality, Seattle, WA (7/14 to present)
> > Created The Virtual Window a device that keeps track of your head
> and turns
> > your TV into a realistic window!
> > https://www.youtube.com/watch?v=DlEwnG-9O8A
> > Used Kinect and Wii-mote based tracking
> > Modified Unreal Engine to support Off-axis projection
> > Used computer vision code to anaylize a video stream and find the
> head.
> >
> >
> >
> > Owner SupportStream, Seattle, WA (4/15 to present)
> > https://supportstream.solutions/Supportee
> > Funding model that allows people to donate a dollar a month to
> their
> > favorite charities, artists or other things they care about.
> > Created Marketing campaign that will eventually be used to drive
> donators
> > to help their favorite causes : https://supportstream.solutions/
> > ASP.NET backend.
> > Paypal integration for payments. Went through the application
> process for
> > advanced functionality.
> > Cross-Site scripting with iframes
> > Used JQuery for animations and popups.
> > Custom designed logo and various CSS changes
> >
> >
> >
> > Contractor Big Finish Games (not Big Fish), Salt Lake City, UT (12/13 to
> 3/14)
> > Programmed puzzles for the continuation of my all time favorite
> video game!
> > Scripted both 2D and 3D puzzles using Unity and C#
> >
> >
> >
> > Owner Comic Reader Mobi, Seattle, WA (4/09 to present)
> > http://comicreader.mobi
> > Software allows fullsized comics to be read on small screens
> > Several unique and intuitive UI features to make using the
> program easier.
> > (Clicking on 

Re: [Wikitech-l] Reviving SVG client-side rendering task

[Jon Robson]

Thanks for starting this conversation Brion!

On mobile we are constantly tackling the trade offs between data
shipped (cost for end user) and quality. Hopefully we'll have a better
solution for this by the end of the quarter which will allow us to
reconsider srcset usage. That said relying on srcset to render SVGs
well seems like a hack to me and thus I'd rather we fixed the problem
at the source.

A few thoughts
* The ResourceLoaderImage module is being used widely to generate SVG
icons with png fallbacks. I'd be interested in seeing if we can use
this in some way for optimising SVGs and removing meta data.
* I wonder if there is an opportunity here to use BetaFeatures and
mobile beta to get a sense of performance impact of these changes?
This would allow people to opt in and for us to crowdsource feedback
in a safe enviroment.

Jon


On Wed, May 11, 2016 at 11:12 AM, Brion Vibber  wrote:
> On Wed, May 11, 2016 at 11:10 AM, Chris Steipp 
> wrote:
>
>> On Thu, May 5, 2016 at 6:49 AM, Brion Vibber 
>> wrote:
>>
>> >
>> > And then there are long term goals of taking more advantage of SVGs
>> dynamic
>> > nature -- making things animated or interactive. That's a much bigger
>> > question and has implementation and security issues!
>>
>>
>> Sorry for the late response (and if this is covered in one of the linked
>> bugs), but getting back to this-- are you envisioning SVG's inlined into
>> the html?
>
>
> Maybe someday that might be interesting for interactive bits, but not in
> the short term.
>
>
>> Or would they be served from a domain like upload.wm.o, like we
>> currently use for uploaded images?
>>
>
> Yes for now.
>
> -- 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] Best practice for WIP patches to help code review office hours

[Jon Robson]

.
On 12 May 2016 4:18 p.m., "Stas Malyshev"  wrote:
>
> Hi!
>
> > No, -2 is restricted to project owners and thus not an op-
> > tion for the vast majority of contributors.  For that pur-
> > pose, I proposed a Gerrit label "WIP"
> > (cf.
http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/84068
).
>
> This looks like a nice solution.

Seconded. What's stopping us from adopting? It seems in that thread nothing
happened.

Greg - is this something we can do?

>
> --
> 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] Best practice for WIP patches to help code review office hours

[Jon Robson]

I didn't know you could search message. Thanks. Even so.. the crux of
what I'm asking for is a reliable way to filter these out. Even with
the search you gave me I see "DONOTSUBMIT" in certain messages :)


On Thu, May 12, 2016 at 2:29 PM, James Forrester
<jforres...@wikimedia.org> wrote:
> On 12 May 2016 at 14:26, Jon Robson <jdlrob...@gmail.com> wrote:
>
>> Gerrit is commonly used as a place to share works in progress early.
>>
>> This is great, but it has an unfortunate side effect of making it
>> harder for would-be reviewers to find patches that need reviewing
>> using this query:
>>
>> https://gerrit.wikimedia.org/r/#/q/(NOT+label:Verified%253D-1)+AND+(label:Code-Review%253D0+OR+NOT+(label:Code-Review%253D-1+OR+label:Code-Review%253D-2)),n,z
>>
>> Could I ask that as a norm, if you post a WIP patch that you also self -2
>> it?
>>
>
> I disagree with this suggestion. The convention to date is having "WIP" or
> "DONTMERGE" in the git commit title. What's wrong with that?
>
>
>
>> I'd love to get us to a place where
>>
>> https://gerrit.wikimedia.org/r/#/q/(NOT+label:Verified%253D-1)+AND+(label:Code-Review%253D0+OR+NOT+(label:Code-Review%253D-1+OR+label:Code-Review%253D-2)),n,z
>> is manageable that code gets merged left right and center :)
>>
>
> Use
> https://gerrit.wikimedia.org/r/#/q/(NOT+message:WIP)+AND+(NOT+message:DONTMERGE)+AND+(NOT+label:Verified%253D-1)+AND+(label:Code-Review%253D0+OR+NOT+(label:Code-Review%253D-1+OR+label:Code-Review%253D-2))+age:24w,n,z
>  instead.
>
> J.
> --
> James D. Forrester
> Lead Product Manager, Editing
> Wikimedia Foundation, Inc.
>
> jforres...@wikimedia.org | @jdforrester
> ___
> 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] Best practice for WIP patches to help code review office hours

[Jon Robson]

Gerrit is commonly used as a place to share works in progress early.

This is great, but it has an unfortunate side effect of making it
harder for would-be reviewers to find patches that need reviewing
using this query:
https://gerrit.wikimedia.org/r/#/q/(NOT+label:Verified%253D-1)+AND+(label:Code-Review%253D0+OR+NOT+(label:Code-Review%253D-1+OR+label:Code-Review%253D-2)),n,z

Could I ask that as a norm, if you post a WIP patch that you also self -2 it?

In addition to this, if a patch is open for longer than several months
you may want to abandon it - it's much more useful to link to an
abandoned patchset in a phabricator task which has all the context for
someone who might be able to solve the problem it tries to solve.

I'd love to get us to a place where
https://gerrit.wikimedia.org/r/#/q/(NOT+label:Verified%253D-1)+AND+(label:Code-Review%253D0+OR+NOT+(label:Code-Review%253D-1+OR+label:Code-Review%253D-2)),n,z
is manageable that code gets merged left right and center :)

Warm regards,
Jon

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

[Wikitech-l] PyWikibot reviewers needed!

[Jon Robson]

I'm keen for us give attention to people who have open patchsets that
they are looking for review. We had the first code review office hours
today and I hope in the long term during this hour we can work on
reviewing patchsets from this search:
https://gerrit.wikimedia.org/r/#/q/(+label:Code-Review%253D0+OR+NOT+(label:Code-Review%253D-1+OR+label:Code-Review%253D-2)+),n,z

Pywikibot has 145 open patches on Gerrit.
You can see them all here:
https://gerrit.wikimedia.org/r/#/q/status:open+project:pywikibot/core+(+label:Code-Review%253D0+OR+NOT+(label:Code-Review%253D-1+OR+label:Code-Review%253D-2)+),n,z

Can someone who is familiar with this codebase commit to helping
getting all these reviewed?

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

Re: [Wikitech-l] Thursday: Get your patch reviewed during "Code Review office hours"

[Jon Robson]

Thanks for setting this up  Mukunda!

On Sun, May 8, 2016 at 8:48 PM, Mukunda Modell  wrote:
> Starting Thursday May 12th, 13:00 PDT ( 20:00 GMT ) we will be having the
> first weekly Code Review office hours on freenode IRC in the
> #wikimedia-codereview channel.
>
> Event details: https://phabricator.wikimedia.org/E179
> Background: https://phabricator.wikimedia.org/T128371
>
> Thanks to everyone who's been helping to organize this. We would welcome
> people to submit your patches for review as well as reviewers who can spare
> a few minutes to provide feedback and hopefully merge some patches!
>
> If you can't make it during the scheduled time period then please feel free
> to suggest other times that would be better for you. I intend to set up one
> or two other weekly time slots, at least one of which should be at a time
> that's more convenient for people in Europe and Asia.
>
> Looking forward to seeing you in #wikimedia-codereview
>
> __
>  Mukunda Modell,
>  Release 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] ResourceLoader addModuleStyles() issues

[Jon Robson]

Okay great! :)
I got lost in the details. Lets make it so!

On Mon, May 9, 2016 at 6:50 AM, Krinkle <krinklem...@gmail.com> wrote:
> On Sun, May 8, 2016 at 5:47 PM, Jon Robson <jrob...@wikimedia.org> wrote:
>
>> Apologies if I'm missing something that makes this so complicated but
>> could we not simply throw an error/warning if you use addModuleStyles
>> on a module with scripts set
>
>
>
> That's exactly what I'm proposing we do.
> https://phabricator.wikimedia.org/T92459
>
>
> -- Timo
> ___
> 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] ResourceLoader addModuleStyles() issues

[Jon Robson]

Apologies if I'm missing something that makes this so complicated but
could we not simply throw an error/warning if you use addModuleStyles
on a module with scripts set and leave this problem to the engineer to
solve?

e.g. force
'a.lib' => [
'styles' => [ 'a.css' ]
'scripts' => ['a.js']
]

to become
'a.styles' => [
'styles' => [ 'a.css' ]
]
'a.lib' => [
'dependencies' => ['a.styles'],
'scripts' => ['a.js']
]

This will obviously require lots of fixes in extensions using the old
method but we've been here before when we enforced style modules
having to set a position.


On Wed, May 4, 2016 at 9:44 AM, Brion Vibber  wrote:
> On Wed, May 4, 2016 at 8:23 AM, Brad Jorsch (Anomie) 
> wrote:
>
>> On Wed, May 4, 2016 at 6:34 AM, Krinkle  wrote:
>> > [1] If one would allow page style modules to have dependencies and
>> resolve
>> > them server-side in the HTML output, this would cause corruption when the
>> > relationship between two modules changes as existing pages would have the
>> > old relationship cached but do get the latest content from the server.
>> > Adding versions wouldn't help since the server can't feasibly have access
>> > to previous versions (too many page/skin/language combinations).
>> >
>>
>> But don't we have the corruption anyway? Say page Foo has a page style
>> module 'foo', so it calls addModuleStyles( [ 'foo' ] ). Then module 'foo'
>> is changed so it also needs 'bar', so page Foo now has to call
>> addModuleStyles( [ 'foo', 'bar' ] ). What is avoided there that isn't
>> avoided when addModuleStyles( [ 'foo' ] ) is smart enough to internally see
>> that 'foo' depends on 'bar' and act as if it were passed [ 'foo', 'bar' ]?
>> Or what case am I missing?
>>
>> On the other hand, dependencies avoid the case where the developer
>> modifying 'foo' doesn't realize that he has to search for everything
>> everywhere that passes 'foo' to addModuleStyles() and manually add 'bar' to
>> each one.
>>
>
> H... wait, does load.php not resolve dependencies server-side when
> producing concatenated CSS output? That would seem to break the
> transitional model I proposed if so.
>
> Ah, fun. :)
>
> -- 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] 2016-05-04 Scrum of Scrums meeting notes

[Jon Robson]

Yes. Thanks. I think I've done my bit. Let me know if there is
anything else you need from me.

On Thu, May 5, 2016 at 9:58 AM, Željko Filipin <zfili...@wikimedia.org> wrote:
> On Thu, May 5, 2016 at 5:52 PM, Jon Robson <jrob...@wikimedia.org> wrote:
>
>> Can you clarify what you need help with here? Is it merging
>> patches/updating empty columns on that table/other?
>>
>> Which tests are failing?
>>
>
> Tests fail all the time. See this task for some history:
>
> https://phabricator.wikimedia.org/T94150
>
> Sometimes a job is broken for more than a month. I would like to avoid
> that. I need one or more people to be owners of Selenium tests for each
> repository, so when something is broken, they fix it.
>
> Did I answer your question?
>
> Željko
> ___
> 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

Re: [Wikitech-l] 2016-05-04 Scrum of Scrums meeting notes

[Jon Robson]

On 5 May 2016 9:24 a.m., "Grace Gellerman"  wrote:
>
> https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-05-04
>
> = 2016-05-04 =
>
> == Technology ==
>
>
> === Release Engineering ===
>
>
> For all:
>
>
>  * T128190 - Migration of browsertests* Jenkins jobs to selenium* jobs

Hi Zeljko,
Can you clarify what you need help with here? Is it merging
patches/updating empty columns on that table/other?

Which tests are failing?
Jon

>
> ** The migration of browsertests* to selenium* is almost complete,
however,
> Željko needs people to claim their failing browser tests. See the task for
> more information.
>
> *** The task has a table, but it's not clear what you want people to do
> (are you just asking about the rows with missing "contact from
> browsertests.yaml" fields)?
>
>
> For operations:
>
>
> * T126594 - Disable HHVM fcgi server on CI slaves
>
> * Need help from ops to review and merge these two patches (we dont need
> HHVM running as a daemon on CI boxes):
>
> ** https://gerrit.wikimedia.org/r/#/c/269946/
>
> ** https://gerrit.wikimedia.org/r/#/c/269947/
>
>
> * https://phabricator.wikimedia.org/T133911 - Bump quota of Nodepool
> instances (contintcloud tenant)
>
> ** More instances needed. Clarified with Chase last week: pending Andrew.
> No urgency.
>
>
> * Two related tasks, each have patches that are needed to streamline the
> scap3 migration:
>
> ** T133211 - Automate the generation deployment keys (keyholder-managed
ssh
> keys)
>
> *** https://gerrit.wikimedia.org/r/#/c/284418/
>
> ** T132747 - scap::target shouldn't allow users to redefine the user's key
>
> *** https://gerrit.wikimedia.org/r/#/c/285519/
>
>
> === Security ===
>
> * Reviews:
>
> ** json-schema done, AuthManger done (no more comments, a few minor things
> before all patches are +1'ed)
>
> ** Starting on T129584 this week
>
> * Starting work on AuthService next week (heads up to Services, we'll
> probably be scheduling a few meetings with you) (Marko: ack && yay!)
>
> * Ops: ping again on T128819
>
>
> === Services ===
>
> (Marko cannot attend today, sorry)
>
> * RESTBase
>
> ** working on storing all auth checks locally (now we are calling the MW
> API every time)
>
> * EventBus / Change propagation
>
> ** started using it in production for the summary endpoint today
>
> ** more dependency updates to follow soon
>
> * Cassandra move to 2.2.6 soon
>
> ** first up: maps cluster
>
> * use Scap3 -
> https://lists.wikimedia.org/pipermail/wikitech-l/2016-April/085299.html
>
>
> === Technical Operations
>
> * '''Blocking''':
>
> ** none
>
> * '''Blocked''':
>
> ** none
>
> * '''Updates''':
>
> ** May 15 (Chrome SPDY removal deadline). Getting HTTP/2 working fully
> deployed till then
>
> ** started using letsencrypt for various small services
>
>
> == Product ==
>
> === Reading ===
>
> * Most of Reading engineering is at an offsite today, I believe.
>
>
>  Reading Infrastructure 
>
> * AuthManager core patches are just waiting for security +1s. Work is
> ongoing on extensions; CentralAuth, LdapAuthentication, ConfirmEdit could
> use reviews if anyone is interested.
>
>
> === Editing ===
>
>  Collaboration 
>
> * '''Blocking''':
>
> ** External store work.  External Store deployed everywhere on Beta with
no
> complications.  Work on this continues.  We now need to set up a second
> External Store on Beta for Flow, to test the migration.
>
> * '''Blocked''':
>
> ** Work on Flow dumps continuing on the ops side.
> https://phabricator.wikimedia.org/T119511 and
> https://phabricator.wikimedia.org/T89398 .
>
> * '''Updates''':
>
> ** Continuing notification work on:
>
> *** Cross-wiki notifications coming by default on May 12th!
>
> *** Echo email formatter
>
> *** Work continues on the new Echo MVC architecture
>
>
>  Parsing 
>
> * We got our first visual diff test run comparing Tidy with HTML5depurate.
> Results @ http://mw-expt-tests.wmflabs.org/ ... Making notes @
> https://www.mediawiki.org/wiki/Parsing/Replacing_Tidy ... We will use this
> as the basis for figuring out what things might break if we replace Tidy
> today and what needs fixing and where.
>
> * Scott has been working with Ops to get OCG kinks ironed out.
>
>
>  Language 
>
> * '''Blocking''':
>
> ** Apertium->Jessie. Yet to finalize plan and proceed.
>
> * '''Blocked''':
>
> * '''Updates''':
>
> ** cxserver service will be migrated to scap3 deployment soon.
>
> ** Translate (twn, meta,..) now using Apertium MT from cxserver.
>
>
> == Discovery ==
>
> * '''Blocking''': none
>
> * '''Blocked''': none
>
> * Preparing for ElasticSearch 2.0 migration
>
> * Results for A/B test on portal language link location published:
>
https://commons.wikimedia.org/wiki/File:Wikipedia_Portal_Test_of_Language_Detection_and_Primary_Link_Resorting.pdf
>
> * TextCat A/B test launching soon
>
> * Portal A/B test adding descriptions to project links to start this week
>
> * WDQS redeployed, some performance issues
>
> * Graphs have 

Re: [Wikitech-l] Gerrit be nice to me Chrome extension on Chrome web store

[Jon Robson]

I have now fixed this problem. Please don't ask me to what measures I
resorted to :)


On 21 Apr 2016 2:17 p.m., "Marko Obrovac" <mobro...@wikimedia.org> wrote:

> On 21 April 2016 at 14:10, Jon Robson <jdlrob...@gmail.com> wrote:
>
> > Due to popular demand I've put my Gerrit extension in the Chrome web
> > store. It makes a few subtle improvements to the Gerrit UI to make it
> > easier to navigate. Feel free to try it out and if it gets popular
> > I'll commit to getting these changes upstreamed to Gerrit ;-)
> >
> >
> >
> https://chrome.google.com/webstore/detail/gerrit-be-nice-to-me/oafiggfcmbkeopoihflmjkhlligaefcd
>
>
> Click, installed! Nice! Thnx for sharing.
>
> Q: the description says it colours positive reviews in green. I've got a
> couple of PS' that are +1'ed, but they do not appear as green :/
>
> Cheers,
> Marko
>
>
> >
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
>
> --
> Marko Obrovac, PhD
> Senior Services 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] Security patch

[Jon Robson]

We did push for a new release process in MobileFrontend some time ago:
https://phabricator.wikimedia.org/T104317

This wasn't popular and failed. See:
http://www.gossamer-threads.com/lists/wiki/wikitech/673454?page=last


On Tue, Apr 26, 2016 at 12:17 PM, bawolff  wrote:
> On Tue, Apr 26, 2016 at 3:08 PM, Ryan Lane  wrote:
>> On Tue, Apr 26, 2016 at 12:01 PM, Alex Monk  wrote:
>>
>>> It's not an extension that gets bundled with MediaWiki releases.
>>>
>>>
>> That doesn't mean third parties aren't using it. When I say a release of
>> the extension, I mean give it a version number, increase the version
>> number, tag it in git, then tell people "ensure you are using version x or
>> greater of MobileFrontend".
>>
>> This is a pretty normal process that Wikimedia does well for other things.
>> I have a feeling this isn't going through a normal process...
>>
>
> I'm pretty sure that doing git tags in extensions for new versions is
> not normal procedure.
>
> I can't recall any extension ever doing that (Unless you mean the
> REL1_26 type tags).
>
> Which is not to say that I necessarily disagree with doing that
> procedure, I just think its unfair to call that the normal procedure,
> where I don't think that procedure has ever been used for extensions.
>
> Regardless of what procedures are decided as good practice for
> extensions, formalizing the procedures security releases of
> non-bundled extensions that are maintained by WMF would probably be a
> good idea.
>
> --
> -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

[Wikitech-l] Security patch

[Jon Robson]

A security vulnerability has been discovered in MediaWiki setups which
use MobileFrontend.

Revisions who's visibility had been alerted were showing up in parts
of the mobile UI.

All projects in the Wikimedia cluster have been since patched but if
you use this extension please be sure to apply the fix.

Patch file and issue are documented on https://phabricator.wikimedia.org/T133700

Note there is some follow-up work to do which is tracked in:
https://phabricator.wikimedia.org/T133722

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

[Wikitech-l] Gerrit be nice to me Chrome extension on Chrome web store

[Jon Robson]

Due to popular demand I've put my Gerrit extension in the Chrome web
store. It makes a few subtle improvements to the Gerrit UI to make it
easier to navigate. Feel free to try it out and if it gets popular
I'll commit to getting these changes upstreamed to Gerrit ;-)

https://chrome.google.com/webstore/detail/gerrit-be-nice-to-me/oafiggfcmbkeopoihflmjkhlligaefcd

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

[Wikitech-l] MediaWiki hash fragment Router

[Jon Robson]

There is clearly a need for a generic solution to hash fragment
routing in MediaWiki.

So far I've seen needs in MultimediaViewer, Kartographer,
MobileFrontend, Gather and potential needs in VisualEditor. There are
probably other bespoke solutions in other extensions too.

It would be great to take a minute and standardise on something (we
can always change it later).

I invite your discussion here:
https://phabricator.wikimedia.org/T114007
and your thoughts on my straw man proposal:
https://gerrit.wikimedia.org/r/#/c/260950/4

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

Re: [Wikitech-l] tags are a usability nightmare for editing on mediawiki.org

[Jon Robson]

On Mon, Apr 11, 2016 at 4:29 PM, Niklas Laxström
<niklas.laxst...@gmail.com> wrote:
> 2016-04-05 8:51 GMT+03:00 Jon Robson <jrob...@wikimedia.org>:
>> Special:Translate doesn't work [1] and the current plan is to make it
>> redirect to desktop which is disappointing and I'd guess loses us lots of
>> potential editors (myself included).
>
> When we developed the new interface for Special:Translate (aka TUX) we
> did some testing that it works on tablets. Is there way to mark it
> suitable for tablets alone because we have not designed it for smart
> phones?

It depends on what libraries it uses and whether those are mobile
friendly. Best thing to do is create a Phabricator task and tag
"reading web" and we can start exploring that. Definitely happy to
help (https://phabricator.wikimedia.org/T102922#1466929).

Personally, I'd love the reading web team to collaborate with the
languages team more - maybe that's something we can try to convince
the powers that be to set aside time for as a future quarterly goal.

>
> And what can we do for the rest? Let them too access TUX acknowledging
> it will be heavy and clunky? Would it make sense to generate minimal
> non-JavaScript version for all the rest using which they can get the
> job done if they are desperate but without all the advanced features
> of the regular TUX UI?
>
> Or in short, I am wondering whether "mobile support" is all or
> nothing, or whether there is some middle way where we can have some
> quick wins if the alternative is to have no support at all?

All good questions and I'm not sure of the answer. Amir did a super
interesting hack using Whatsapp and translate wiki at the hackathon in
Jerusalem. If porting the existing translate interface to mobile
proves too cumbersome we might want to explore and test some small
lightweight translating tools.

I'm happy to have a 1-on-1 on you or brainstorm some ideas on a wiki
page or spending some time hacking on something with you from the
mobile angle... whatever makes sense.

>
>
>> To take a more concrete example of impact on mobile - we've made the mobile
>> skin play nicely with language interwiki links (we've even dedicated this
>> entire quarter to improving language switching on mobile web [2] ). On the
>> other hand, the languages tag does not work the same way as an interwiki
>> link. It does it's own thing which is sadly suffering from usability issues
>> on mobile [3].
>
> This is technical debt. After over a year long push on Content
> Translation, the Language team is now dedicating some time to address
> high priority bugs in Translate and Universal Language Selector.

Awesome! Let me know how I can support you with this.

>There
> is some related work happening such as the "compact interlanguage
> links out of beta" and a soon 2 year old patch in Translate to improve
> the display of the language list [1]. It would be useful to look at
> the big picture here but there likely isn't enough time beyond fixing
> the most obvious for now.
>
> [1] https://gerrit.wikimedia.org/r/#/c/149585/
>
>> I hope my views on this are a little clearer to you now and apologies for
>> putting you on the defensive if I did.
>
> Thanks for the explanation, because it was not obvious to me what are
> the pain points from your point of view. For the usability issues you
> listed, they do affect desktop users as well, but I do appreciate that
> they are more severe on mobile. For performance, is that only about
> the unsuitable output from  tag or is there more to it?

Yup the performance angle is secondary but that's pretty much it. I'm
also concerned about future performance issues with having to load
additional JS code to support it.

>
>
>> I'd love to see our new language switcher compatible with the output of the
>> translate tag and the translation mechanisms available on mobile phones, so
>> readers can view translations and edit seamlessly around our projects.
>
> This is helpful and I will consider it when prioritizing work. I am
> not well aware of your current priorities [2], but if you think this
> is important, would you consider helping us on this issue?

Of course. It would be interesting to explore if there's ways we can
link the new language overlay with content translation. I'm fairly
confident that there are people that would be willing to translate
content on mobile!

>
> [2] I am having hard time navigating through outdated pages on
> mediawiki.org. Is this the place to look:
> https://www.mediawiki.org/wiki/Reading/Web/Projects ?

Yup https://www.mediawiki.org/wiki/Reading/Web
>
>   -Niklas
>
> ___
> 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] Wikipedia in Pig Latin

[Jon Robson]

+1. Where can I +2 this?

On Tue, Apr 5, 2016 at 5:00 PM, Daniel Kinzler  wrote:
> Am 01.04.2016 um 19:08 schrieb C. Scott Ananian:
>> On a somewhat serious note, I'm a big fan of enabling pig Latin as a
>> language variant in enwiki.
>
> Yes, please! I have been using a patch that Liangent wrote a few years ago, 
> but
> which never got merged, for exactly this purpose. Piglatin may just be a fun
> easter egg for a production site, but it's a very useful tool for development
> and testing.
>
> -- 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] productivity of mediawiki developers

[Jon Robson]

I think a review is valuable no matter what the score... with the
possible exception of -2 which I fear is probably a bit too aggressive
and unnecessary in our ecosystem for which reason the reading web team
agreed to avoid the use of -2 except to stop merges in progress that
were not ready. I review with score 0 quite a lot for instance.


On Tue, Apr 5, 2016 at 3:59 PM, Federico Leva (Nemo)  wrote:
>> I, for example, value better good -1 code reviews
>
> Same here. There are statistics for -1 too, two clicks away from the link I
> provided in the previous message.
> https://www.mediawiki.org/wiki/Gerrit/Reports/Code_review_activity
>
> Nemo
>
>
> ___
> 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] tags are a usability nightmare for editing on mediawiki.org

[Jon Robson]

On Sun, Apr 3, 2016 at 10:48 PM, Niklas Laxström <niklas.laxst...@gmail.com>
wrote:

> 2016-04-03 11:29 GMT+03:00 Jon Robson <jdlrob...@gmail.com>:
> > The Translate tag has always seemed like a hack that I've never quite
> > understood.
>
> I am happy to direct to our documentation [1] anyone who asks, or
> explain if the documentation is not sufficient.
>
> The word hack can have both positive and negative meanings and it is
> unclear what do you mean with it here.
>

FWIW I didn't mean this in a negative way. Hack is always a neutral word in
my vocabulary :-). Possibly a more descriptive term would have been
"oddity". I've personally had to push changes in MobileFrontend that felt
wrong, but were necessary due to the environmental constraints I worked in.
(Side note: In return have to put up with insulting comments such as
"MobileFrontend is an abonimation" from people that haven't taken the time
to understand why things are done the way they are). I've ignored those
people and still consider the work I've done as useful and important, just
as I value the work everyone has put into our language support.

The least I can do is elaborate on my brevity earlier (sent via mobile
during hackathon :-)) I think Subbu has covered very well my feelings
around this so I don't have much to add to what he's said.

My original concern however was not around the documentation,  but how we
have 2 mechanisms for doing languages - create a separate site or use the
translate tag. It wasn't clear to me which predates the other and why that
decision was made. The advantage of a separate site is that it is the
simplest possible way to translate.. through no effort whatsoever an editor
can translate an article on a mobile device for example by navigating to
their project and clicking the edit button. On the other hand
Special:Translate doesn't work [1] and the current plan is to make it
redirect to desktop which is disappointing and I'd guess loses us lots of
potential editors (myself included).



>
> > The translate tag causes lots of issues on mobile (impacting usability
> and
> > performance) due to not playing well with the rest of the language
> > ecosystem.
>
> I was under the impression that mobile does not work with the wikitext
> directly. Translate tags never appear in the parsed wikitext output.
> Can you please point me to the tasks in Phabricator where these are
> explained? I am especially curious about the part about "rest of the
> language ecosystem" because having worked on many parts of it, I don't
> feel the same way.
>
> [1] https://www.mediawiki.org/wiki/Help:Extension:Translate


When we experimented with the first versions of the editor, we found that
edits significantly increased when we loaded sections rather than the
entire article - so less wikitext leads to greater number of edits. The
translate tag makes the wikitext more confusing and bloats it when
translations exist, but I've not investigated so this would need more
investigation.

To take a more concrete example of impact on mobile - we've made the mobile
skin play nicely with language interwiki links (we've even dedicated this
entire quarter to improving language switching on mobile web [2] ). On the
other hand, the languages tag does not work the same way as an interwiki
link. It does it's own thing which is sadly suffering from usability issues
on mobile [3].

The point being that when we don't consolidate systems that do similar
things, we are losing opportunities to benefit from things elsewhere or
waste engineer time fixing 2 identical problems.

The main issues I have are more from an architecture perspective. I would
expect a function along the lines of
ArticlePage->getLanguages() to exist and be agnostic to where languages
come from - translate tag or interwiki link for consumers such as skins and
apps.

I hope my views on this are a little clearer to you now and apologies for
putting you on the defensive if I did.

I'd love to see our new language switcher compatible with the output of the
translate tag and the translation mechanisms available on mobile phones, so
readers can view translations and edit seamlessly around our projects.




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

[1] https://phabricator.wikimedia.org/T102922
[2] https://phabricator.wikimedia.org/T121919
[3] https://phabricator.wikimedia.org/T106361
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [WikimediaMobile] The future of Related Pages feature

[Jon Robson]

1) The related articles are editable via the {{RelatedArticles}} magic
word. They have been since day one of launch.

2) There is a great conversation around how this feature could serve as a
see also replacement here:https://www.mediawiki.org/w/

index.php

?title=Topic:

Syte4nkfr13nlfw4

=history


3) it's a beta feature and as far as I'm aware there are no plans to push
this to all users without community buy in.

4) in general I think beta features are a great way to have conversations
about how we can make the wiki better. I think this is generating good
conversations - especially around the PageImages extension and the
usefulness of see also and the exposure of the more like API.
On 4 Apr 2016 9:53 a.m., "John Mark Vandenberg"  wrote:

> This feature appears to be an automated edition of the "See also" section
> on English Wikipedia. Having both Related Articles and See also feels like
> a usability issue.
>
> Has there been any discussions on the wikis about this overlap?
> On 24 Mar 2016 05:18, "Moushira Elamrawy"  wrote:
>
>> Hello everyone,
>>
>> Related pages feature has been in beta for over two months now,  the
>> future of the feature depends on our discussions.  While we currently don't
>> have a clear process for deciding collaboratively on an all languages
>> product, Alsee and the reading team have put together this document on meta
>> [0], as a request for comment, seeking comments and ideas on modifications
>> required, and how to further test the feature.  In fact, we are not sure if
>> an rfc is the best strategy to move forward with product decisions, but
>> lets see how the discussion evolves, and we might explore the need for a
>> different process, as we move on with this one.
>>
>> We managed to translate a brief introduction about the topic, please feel
>> free to fully translate the document and/or further promote the discussion
>> on your wiki.  We are trying hard to avoid having an English centric
>> discussion for a feature that could be available across all language
>> projects, and while we don't have a clear solution for this, we are trying
>> this method as an experiment, where at least our communities can leave
>> comments in their preferred language if they aren't comfortable writing in
>> English but they can understand it.
>>
>> Please check the page, help with translation or promotion in your
>> Wikipedia, and most importantly, comment on how you think it can evolve. :)
>>
>> Lets see how this works!
>>
>>
>> All the best,
>> M
>>
>> [0] https://meta.wikimedia.org/wiki/Requests_for_comment/Related_Pages
>>
>> ___
>> Mobile-l mailing list
>> mobil...@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-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] tags are a usability nightmare for editing on mediawiki.org

[Jon Robson]

I'm not too aware of the history, but is there good reason we do not have
en.mediawiki.org etc?
The Translate tag has always seemed like a hack that I've never quite
understood.
The translate tag causes lots of issues on mobile (impacting usability and
performance) due to not playing well with the rest of the language
ecosystem.



On Sun, Apr 3, 2016 at 11:00 AM, Isarra Yos <zhoris...@gmail.com> wrote:

> Is there any way to just flag pages to not get translated? These tags are
> basically the main reason I've given up on documenting any of my
> extensions/skins.
>
>
> On 01/04/16 16:31, Brion Vibber wrote:
>
>> Lots of pages on mediawiki.org are pretty much uneditable because they're
>> strewn with  spanning multiple paragraphs that make
>> VisualEditor
>> completely unusable and the source editor very difficult to use.
>>
>> I'm trying to update documentation, and I'm seriously thinking of regexing
>> out all the  stuff so I can actually edit the wiki pages.
>>
>> This is probably not a good thing.
>>
>>
>> https://phabricator.wikimedia.org/T131516
>>
>> -- 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
>



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

Re: [Wikitech-l] Improving Wikimedia's Code Review process

[Jon Robson]

We have two swat windows every day. It's magical... I post a request for a
deploy on a Wiki page and someone deploys it.

Could we try a similar thing with code review. Code review window (maximum
1 patch per person) and have a group of +2ers look at a maximum set of
patches?

It would need a few more rules than that and a bit of tweaking but seems
like a good experiment. I'd sign up to help it if it was a maximum 2
windows for me a week.
On 16 Mar 2016 12:50 p.m., "Daniel Kinzler"  wrote:

> There will be an RFC meeting tonight about this:
> https://phabricator.wikimedia.org/E148
>
> One thing that I don't remember coming up during the summit is:
>
> Can we perhaps get all the people with +1 rights to use them and actually
> review
> stuff? So that people with +2 rights can look at things that already have
> a +1,
> and can thus avoid getting swamped with lots of patches with lots of low
> grade
> issues?
>
> Where would this idea fit into the zoo of tickets we have on the subject?
>
> Am 15.03.2016 um 17:11 schrieb Andre Klapper:
> > Hey everybody!
> >
> > At the Wikimedia Developer Summit there was a session about "Making
> > Code Review not suck" [1].
> > The outcome are Phabricator (sub)tasks of the task "Define potential
> > actions to reduce code review queues and waiting times" in
> >   https://phabricator.wikimedia.org/T101686
> >
> > The following potential actions items have been identified:
> >
> > * https://phabricator.wikimedia.org/T129842 :
> >   Decide whether to have a "Code Review" committee / working group
> > * https://phabricator.wikimedia.org/T129067 :
> >   Agree on and document a structured, standardized approach for
> >   reviewing code contributions
> > * https://phabricator.wikimedia.org/T129068 :
> >   Improve code contribution guidelines for patch authors
> > * https://phabricator.wikimedia.org/T128370 :
> >   Update ownership list on [[mw:Developers/Maintainers]]
> > * https://phabricator.wikimedia.org/T128371 :
> >   Set up Code Review office hours
> > * https://phabricator.wikimedia.org/T128372 :
> >   Document use of Owners in Phabricator and advertise it
> > * https://phabricator.wikimedia.org/T115852 :
> >   Fix unclear maintenance
> > responsibilities for some parts of MediaWiki
> >   core repository
> >
> > Discussion on each of those proposals is welcomed in the corresponding
> > tasks!
> >
> > Thanks,
> > andre
> >
> > [1] https://phabricator.wikimedia.org/T114419
> >
>
>
> ___
> 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] limited presence

[Jon Robson]

Sorry to hear that DJ.
Rest up and wishing you a speedy recovery.


On Wed, Mar 2, 2016 at 10:10 AM, Brion Vibber <bvib...@wikimedia.org> wrote:
> Be well. :)
>
> -- brion
>
> On Wed, Mar 2, 2016 at 10:08 AM, Derk-Jan Hartman <
> d.j.hartman+wmf...@gmail.com> wrote:
>
>> Hi all,
>>
>> ive had a small accident with skiing. ill be fine, but because of it my
>> participation will be low for some while and though i am reading along with
>> some things, any answers will like be terse, and code will be none.
>>
>> DJ
>>
>> ___
>> 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



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

Re: [Wikitech-l] Today's RFC meeting on IRC: Standardise on how to access/register JavaScript interfaces

[Jon Robson]

Thanks for the reminder :)


On Wed, Feb 24, 2016 at 1:11 PM, Roan Kattouw <roan.katt...@gmail.com> wrote:
> My apologies for the short notice. Normally we announce these more than one
> hour in advance, but I forgot.
>
> In today's RFC meeting, we will discuss the following RFC:
>
> * Standardise on how to access/register JavaScript interfaces
> <https://phabricator.wikimedia.org/T108655>
> <https://phabricator.wikimedia.org/E144
> <https://phabricator.wikimedia.org/E140>>
>
> The meeting will be on the IRC channel #wikimedia-office on
> chat.freenode.net at the following time:
>
> * UTC: Wednesday 22:00
> * US PST: Wednesday 14:00
> * Europe CET: Wednesday 23:00
> * Australia AEDT: Thursday 09:00
>
> Roan
> ___
> 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

Re: [Wikitech-l] Mass migration to new syntax - PRO or CON?

[Jon Robson]

FYI for future reference Phabricator has a great poll feature that may be
useful for these kind of votes:
https://phabricator.wikimedia.org/vote/


On Tue, Feb 16, 2016 at 1:52 PM, Legoktm 
wrote:

> On 02/12/2016 07:27 AM, Daniel Kinzler wrote:
> > Please give a quick PRO or CON response as a basis for discussion.
>
> No one has responded in a few days, and the current count is 13-5-2, so
> I'm going to find a time to do the mass migration when there aren't that
> many people making core changes and do this today or tomorrow.
>
> -- Legoktm
>
> ___
> 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] Mass migration to new syntax - PRO or CON?

[Jon Robson]

On Fri, Feb 12, 2016 at 9:14 AM, Chad  wrote:

> On Fri, Feb 12, 2016 at 7:27 AM Daniel Kinzler 
> wrote:
>
> > CON: don't do mass migration to new syntax, only start using new styles
> and
> > features when touching the respective bit of code anyway. The argument is
> > here
> > that touching many lines of code, even if it's just for whitespace
> changes,
> > causes merge conflicts when doing backports and when rebasing patches.
> > E.g. if
> > we touch half the files in the codebase to change to the new array
> syntax,
> > who
> > is going to manually rebase the couple of hundred patches we have open?
> >
> >
> > As can be seen on the proposed patch I linked, several of the long term
> > developers oppose mass changes like this. A quick round of feedback in
> the
> > architecture committee draws a similar picture. However, perhaps there
> are
> > compelling arguments for doing the mass migration that we haven't heard
> > yet. So
> > please give a quick PRO or CON, optionally with some rationale.
> >
> > My personal vote is CON. No rebase hell please! Changing to the syntax
> > doesn't
> > buy us anything.
> >
> >
> CON, for all the reasons you mentioned. Also: style only changes are pain
> when you're
> trying to annotate/blame a particular line of code.
>
> ESPECIALLY for something so silly as array formatting which gains us
> *absolutely nothing*
>

Agree on many levels.
Please, let's focus on solving problems and improving how our code works
rather than how our code looks.

>
> -Chad
> ___
> 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] Mass migration to new syntax - PRO or CON?

[Jon Robson]

On Fri, Feb 12, 2016 at 10:26 AM, Stas Malyshev 
wrote:

> Hi!
>
> > PRO. These syntax changes were implemented in PHP at the cost of breaking
> > backward-compatibility, which tells you that people understood their
> value
>
> Wait, are we talking about the same thing? New array syntax does not
> break BC. Or you mean that if we use new array syntax, we'd break BC
> with older PHP versions? I'm not sure I understand your argument here.
>

I'm also a little puzzled. I thought it was a given we are embracing and
modernizing newer PHP versions.

The question as I understood it, is should we touch every piece of our
codebase in one big mega patch or update it gradually as and when we visit
bits of the codebase (I get the impression the latter isn't happening due
to a desire to have mega patches).


>
> --
> 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] Mass migration to new syntax - PRO or CON?

[Jon Robson]

On 12 Feb 2016 12:44 p.m., "Chad"  wrote:
>
> On Fri, Feb 12, 2016 at 9:14 AM Chad  wrote:
>
> > On Fri, Feb 12, 2016 at 7:27 AM Daniel Kinzler 
> > wrote:
> >
> >> CON: don't do mass migration to new syntax, only start using new styles
> >> and
> >> features when touching the respective bit of code anyway. The argument
is
> >> here
> >> that touching many lines of code, even if it's just for whitespace
> >> changes,
> >> causes merge conflicts when doing backports and when rebasing patches.
> >> E.g. if
> >> we touch half the files in the codebase to change to the new array
> >> syntax, who
> >> is going to manually rebase the couple of hundred patches we have open?
> >>
> >>
> >> As can be seen on the proposed patch I linked, several of the long term
> >> developers oppose mass changes like this. A quick round of feedback in
the
> >> architecture committee draws a similar picture. However, perhaps there
are
> >> compelling arguments for doing the mass migration that we haven't heard
> >> yet. So
> >> please give a quick PRO or CON, optionally with some rationale.
> >>
> >> My personal vote is CON. No rebase hell please! Changing to the syntax
> >> doesn't
> >> buy us anything.
> >>
> >>
> > CON, for all the reasons you mentioned. Also: style only changes are
pain
> > when you're
> > trying to annotate/blame a particular line of code.
> >
> > ESPECIALLY for something so silly as array formatting which gains us
> > *absolutely nothing*
> >
> > -Chad
> >
>
> I change my vote to PRO.
>
> Mainly because people are gonna do it anyway...
>
> Last thoughts on the thread, I got bigger fish to fry than array syntax
> sugar :D

PRO for me too. If we do this with automated tools we avoid the human
error. You have me convinced.

>
> -Chad
> ___
> 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] MobileFrontend+Wikibase security patch

[Jon Robson]

A security vulnerability has been discovered in MediaWiki setups which
use both Wikibase and MobileFrontend.

All projects in the Wikimedia cluster have been since patched but if
you use these two extensions please be sure to apply the fix.

Patch file and issue are documented on https://phabricator.wikimedia.org/T125684

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

Re: [Wikitech-l] restarting of stream.wikimedia.org backend servers in ~ 48hours

[Jon Robson]

Thanks for letting me know!


On Mon, Feb 1, 2016 at 12:29 PM, Daniel Zahn <dz...@wikimedia.org> wrote:
> Hello,
>
> to anyone who is a client of stream.wikimedia.org
> (https://wikitech.wikimedia.org/wiki/RCStream), so people who run tools
> relying on the RC stream.
>
> In about 48 hours, on February 3rd at 20:00 UTC, we will have to reboot
> the backend servers of the stream.wm.org service, rcs1001 and 1002.
>
> This service is loadbalanced and we will only reboot the 2 servers one at a
> time,
> so there should be no service downtime.
>
> But nevertheless your clients will get disconnected and may need your
> intervention to reconnect.
>
> Please be prepared to do so if your client will not automatically reconnect.
>
> I will send another mail once this has happened.
>
> Best regards,
>
> Daniel
>
> --
> Daniel Zahn <dz...@wikimedia.org>
> Operations Engineer
> ___
> 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] INFO: Reading web release process update

[Jon Robson]

As you may be aware, the reading team was unhappy with its current release
process and shared its rationale

for a different release process. This resulted in an experiment on Gather,
QuickSurveys, Cards and RelatedArticles where the team developed on the dev
branch by default. When the team was happy that the dev branch was stable,
it would tag a release and merge to master. The idea was to minimise the
deployment of incomplete features and SWAT deploys.

This process saw mixed success. Although we felt more comfortable and in
control of the code we shipped due to more time for designers and product
owners to input into our process it was clear there was an impedance
mismatch with the expectations in the MediaWiki developer community and for
a small team of 5, we were unable to keep up with the periodic releases of
extensions we were not actively maintaining.

As a result we are abandoning this experiment and going back to
the Mediawiki Way™ of releasing and merging directly to master.

When we work on new features, we will be more mindful of +2, marking the
initial commit of a chain of commits that requires sign off from a designer
and product owner with a -2.

We think this will be a better approach for everyone. Our only remaining
question is when and if to do release number bumps in future. We'll be back
with an answer about that shortly... ideas welcomed.

Thank you for your patience while we experimented and let us know if there
is anything else of interest to you in this experiment we have run.

Notes from post-mortem are on wiki

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

Re: [Wikitech-l] Video: Loading Barack Obama on 2G from Spain on a Nexus 5

[Jon Robson]

On Wed, Jan 20, 2016 at 1:28 AM, Peter Hedenskog 
wrote:

> I like videos because it's so easy for non technical people to understand
> the value of performance. For me it has been a really good way to show and
> explain performance changes and what it looks like for the user.
>

Linked to this, for those who might question or not understand performance
work, people may want to compare the existing mobile experience on
http://en.m.wikipedia.org/wiki/Barack_Obama with
http://future-wikipedia.wmflabs.org/wiki/Barack_Obama and
http://reading-web-research.wmflabs.org/wiki/Wikipedia on a real 2G
connection.

I'd be interested if anyone hasn't got time to record their experience to
document it as our load times vary around the world depending on how far
you are from a data centre among other reasons.


>
> Picking a representative connection is hard and the good thing is I think
> we don't need to. Connections in the real world vary so much: You could
> have 3G but a really bad connection to the nearest station because there's
> a lot of other phones connected etc. We have tests running with real
> connections 2G/3G from Bangalore and LTE in San Francisco, you can check it
> out how it looks here:
>
> https://grafana.wikimedia.org/dashboard/db/mobile-webpagetest?panelId=30
> I really like that graph because it shows how much variances you can have
> on the same connection type from the same location. Check out how it looks
> like in Bangalore.
>
> When we throttle the connection for WebPageTest (or other tools) we don't
> get that type of variations, we just use hard coded values for a specific
> connection. And that's good, because it makes it possible for us to measure
> improvements so that when we do fixes, we can easily see if it makes it
> better or worse. Picking a slow connection like 2G is good because then it
> is easier to spot what impact we get from our changes.
>
> I like automated testing with real devices, we have automatic tests up and
> running with a Iphone 6, Ipad Mini and Motorola G (using the ones provided
> in WebPageTest) and it looks like this:
>
> https://grafana.wikimedia.org/dashboard/db/mobile-webpagetest?panelId=28
>
> You can click on the each row in the table to only show one graph, that
> makes it easier to see what numbers we have. Click
> on Dulles_iPhone6_iPhone_6_iOS_9.render and you can see that the start
> rendering time (when something is first showed on the screen) is pretty
> stable for the Iphone 6 but if you
> choose Dulles_iPhone6_iPhone_6_iOS_9.SpeedIndex (SpeedIndex is a way of
> calculate when content within the viewport is visible for the end user)
> vary a lot. The thing is that we only have limited access to automated
> tests with real phones (we don't have anything setup for ourselves). So we
> use it now to just get a feeling of what it looks like on real devices.
>
> Most IMPORTANT: When we measure performance it is important that we always
> do it exactly the same way, so we try to limit the changes to as few as
> possible (=our code change). Using WebPageTest I think it's ok to use
> Mobile 2G Fast, emulating mobile using Chrome. When we run the automated
> tests in Jenkins we test each URL 5 times, it seems to be pretty stable.
> Our tests will not give us the same numbers as the users gets, but it will
> give us constant numbers so that we can see that the changes we do impact
> the site. When we push these changes to production we can hopefully pick
> them up with our RUM metrics.
>
> One last thing: We will not pickup things as CPU usage faking real devices
> but to do that, I think we need to look at another tool than WebPageTest to
> do that correctly. Do we have one already?
>
> On Mon, Jan 18, 2016 at 1:20 PM, Federico Leva (Nemo) 
> wrote:
>
> > I'm allergic to videos as replacement of data, but does your video
> > substantially differ from what tests give us, e.g.
> > http://www.webpagetest.org/video/view.php?id=160118_YK_HKT.1.0 ?
> >
> > It's easy to test multiple speeds (some tests still pending):
> >
> http://www.webpagetest.org/video/compare.php?tests=160118_AZ_JH3,160118_VB_JGH,160118_X6_HM1,160118_KC_HM0,160118_YK_HKT,160118_2W_HKD
> >
> > Some of the tests show significant CPU usage after the "everything and a
> > kitchen sink" ResourceLoader phase in which some stuff for CentralNotice,
> > Gather etc. etc. is loaded.
> >
> > Mainly, the issue is to pick representative connections. There is some
> > official data, some of which based on actual tests by probes, although
> it's
> > limited:
> > *
> >
> https://ec.europa.eu/digital-agenda/en/news/quality-broadband-services-eu
> > (no mobile)
> > *
> >
> https://ec.europa.eu/digital-agenda/en/news/use-commercial-mobile-networks-and-equipment-mission-critical-high-speed-broadband
> > (needs some parsing!)
> >
> > Nemo
> >
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > 

[Wikitech-l] Modern module loading needing code review

[Jon Robson]

As part of the work of the frontend standards group
https://gerrit.wikimedia.org/r/#/c/260071/ adds require and
module.exports to MediaWiki ResourceLoader. This will make it easier
to share code outside MediaWiki and with nodejs systems as well as
discouraging the overloading of the mediawiki variable.

I'm looking for code review at the moment. If you are familiar with
ResourceLoader's internals I'd appreciate your input.

See https://phabricator.wikimedia.org/T108655 for further background

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

Re: [Wikitech-l] Fwd: Your speaking schedule at FOSDEM

[Jon Robson]

Good luck Matt! Glad to hear you'll be the sharing your experience of
conversions with the wider FOSS community.

I look forward to seeing the streamed version!
On 15 Jan 2016 2:17 p.m., "Matthew Flaschen" 
wrote:

> I will be presenting at FOSDEM on the LiquidThreads to Flow conversion, at
> 2016-01-30, 16:00 Belgium time:
>
>
> http://www.timeanddate.com/worldclock/fixedtime.html?msg=FOSDEM+LiquidThreads+to+Flow+talk+by+Matt+Flaschen%2C+Livestreamed=20160130T15
>
> It will be live-streamed at
> https://live.fosdem.org/watch.php?room=H.2215%20(Ferrer) (from what I can
> tell in advance).
>
> Thanks,
>
> Matt Flaschen
>
>  Forwarded Message 
> Subject: Your speaking schedule at FOSDEM
> Date: Fri, 15 Jan 2016 22:13:33 +0100 (CET)
> From: FOSDEM Programme Team 
> Reply-To: speak...@fosdem.org
> Organization: FOSDEM - https://fosdem.org/
> To: Matt Flaschen 
> CC: speak...@fosdem.org
>
> Dear speaker,
>
> Thank you for agreeing to speak at FOSDEM!
>
> Our programme is now complete:
>   https://fosdem.org/2016/schedule/
>
> This is your schedule:
>
>
> ..
> | day| time | room| title  |
>
> ++--+-+--+
> | 2016-01-30 | 16:00:00 | H.2215 (Ferrer) | Converting LiquidThreads to
> Flow |
>
> '+--+-+--'
>
> .-.
> | links   |
> +-+
> | https://fosdem.org/2016/schedule/event/flow |
> '-'
>
> Please check these links carefully.  If you already created an account at:
>   https://fosdem.org/submit
> you can login and update the information if need be.
>
> In particular, please upload a photograph if you have not already done
> so and enter or update your biography.
>
> Changes take a few minutes to reach the website - the time it was last
> updated appears at the bottom of this page:
>   https://fosdem.org/2016/schedule/events/
>
> If you find yourself unable to attend, please let your room's organiser
> know this as soon as possible.
>
> FOSDEM intends to record and stream the entire conference live - that's
> over 300 hours of content!  The recordings will be published under the
> same licence as all FOSDEM content (CC-BY).  You are agreeing to this by
> taking part in the event.
>
> Any slide decks you present should be uploaded by about half-an-hour
> before the start of your talk so that people watching the live stream
> can follow them locally if their video resolution leaves slide content
> indistinct.  (Our system does not hold back publication, so if you don't
> want people to see them too far in advance, don't upload them yet.)
>
> Projectors work at 1024x768 but expect slides (and any demonstrations)
> to be scaled down to 720x576 for the video, so try to make them
> readable at this lower resolution if you can.
>
> Please don't forget to bring a VGA adaptor if you hope to present from a
> laptop that only has a different type of output connector!  We also
> recommend bringing a spare copy of any slides on a USB stick.
>
> As usual, we aim to provide free high-quality wireless network
> connectivity throughout the event.
>
> Best wishes,
>
> The FOSDEM Programme Team
>
>
>
> ___
> 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] Video: Loading Barack Obama on 2G from Spain on a Nexus 5

[Jon Robson]

To be clear Joaquin is asking people to record their experiences on 2G
connections of loading the Barack Obama article it is not about displaying
video. It would also be interesting for people to try the experience on
their desktop browser using 2g and record those experiences as many people
around the world connect to our desktop site on 2g.

We can and should do better.
On 12 Jan 2016 7:58 a.m., "Bernardo Sulzbach" 
wrote:

> Brian, you seem off. Do you know that we are talking about loading the
> Obama page, right?
>
> ___
> 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] BetaFeatures and the wmgBetaFeaturesWhitelist

[Jon Robson]

So I enabled a beta feature today that is part of reading web's
quarterly goals (read more about read more here if interested [1])

When enabled it showed up in desktop beta features (yey) but the
JavaScript module wasn't loading...

Investigating I discovered that BetaFeatures::isEnabled consults a
config variable called wgBetaFeaturesWhitelist

This makes the feature return false if the feature is not in
wgBetaFeaturesWhitelist

Apparently however you make the feature show up in the
GetBetaFeaturePreferences hook - so the whitelist doesn't actually
apply to things we show to users (which I would say would be more
important...) [2]

The whitelist also asks when enabling to check with James Forrester and Greg
 and to note a date 6 months after the last major change. According to
these comments all the listed beta features have passed their expiry
dates.

Will they live here forever - or is it time to talk about beta features?

[1] https://www.mediawiki.org/wiki/Reading/Web/Projects/Read_more
[1] https://phabricator.wikimedia.org/T121182

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

Re: [Wikitech-l] Who owns (or should own) OOjs UI?

[Jon Robson]

This might be a good discussion for the dev summit?

I talked to Moriel about this a couple of days ago. I too am a bit
concerned and feel like this needs a dedicated team, preferably
without a product to manage and mediate/prioritise requests against it
as otherwise the library will be biased towards a single product
rather than all our products.

Ideally, I feel that we need a team determining how it evolves and its
architecture. A big rewrite to split out OOjs UI into
components/making it support mobile /adding a new component to OOjs UI
is not something that should be done in an ad-hoc nature - it should
be done by people with a vision of what this library needs to grow
into, the problem it is solving and knowledge of its history and
mistakes of the past - guardians as such - ensuring that the library
is the best it can be.

I worry about its success if arranged in a cross-functional skunkworks team.

On Wed, Dec 9, 2015 at 1:58 PM, Brad Jorsch (Anomie)
 wrote:
> On Wed, Dec 9, 2015 at 3:40 PM, James Forrester 
> wrote:
>
>> Short-cut answer to the title question: Me.
>>
>
> I'm glad to hear that you are accepting responsibility for OOjs UI
> development! Do you have a timeline on a fix for T113681, or a page that
> indicates what higher-priority development you and your team are working on
> in the near future?
>
>
>> > If OOjs UI is the thing that we're supposed to be using in the future for
>> > our UI stuff, it's very concerning that further development is blocked on
>> > T113681
>>
>> "Further development" is not blocked on this task. A few things that some
>> people want to do are.
>
>
> Let's not chop logic here. If "a few things that some people want to do"
> cannot be done due to T113681, then T113681 is indeed blocking some further
> development even if other further development isn't blocked. This email
> thread isn't even about
> T113681 specifically, it's about that there are no development resources
> for fixing things in OOjs UI unless someone is willing to do it as a
> skunkworks project, and OOjs UI isn't yet a finished product where we might
> be able to justify that.
>
> I'm disappointed that you don't think that the fact that "some things
> people want to do" are blocked and no development resources are available
> to remedy the situation is cause for concern. When the situation was
> brought up in today's Scrum of Scrums, the consensus was that it is indeed
> concerning.
>
>
>> Please do not exaggerate for effect to try to get your way. I'm sorry that
>> we disagree as to whether your patch belongs in the library in its current
>> form.
>>
>
> Since you brought it up, let's look at my patch. There are two concrete
> blockers that have been raised on my patch. Neither of them actually have
> to do with the form of the patch itself.
>
> The long-standing blocker has been disagreement over how the widget can be
> internationalized in the context of OOjs UI: The Language and translatewiki
> faction wants OOjs UI developers to integrate cldrjs, while the OOjs UI
> developers are unwilling to make any decision as to whether cldrjs is the
> way to go or translatewiki will just have to deal with providing
> translations for month and weekday names as they do for everything else.
> The closest we have to a decision is really a cop-out: "shove it into
> MediaWiki even though it doesn't belong there, because MediaWiki already
> happens to have most of the needed i18n strings and we can't make any
> decision here".
>
> In last week's Scrum of Scrums, you brought up T113681 as a new blocker:
> OOjs UI is already too large, so we can't add new stuff until someone
> reworks it to be able to load individual components. MatmaRex then stated
> that no one owns or maintains OOjs UI to the extent that we can expect T113681
> to be solved any time soon, which brought the lack of maintainership in
> OOjs UI into clear view.
>
> MatmaRex also raised some other objections (disagreement with Design's
> design, non-use of moment.js despite moment.js not gaining us anything,
> doubt that anyone actually needs  despite evidence
> to the contrary), but no one else has agreed with those and he hasn't
> deigned to respond to attempts at further discussion in Gerrit.
>
> If you have objections to the actual form of my patch, as opposed to lack
> of a willingness to make any decision on the i18n issue or any progress on
> the form of OOjs UI as a whole, you should raise them in Gerrit instead of
> continuing to sit on them. Although I wonder why you haven't done so
> already.
>
>
> --
> Brad Jorsch (Anomie)
> Senior Software 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

[Wikitech-l] Mozilla Service workers cookbook

[Jon Robson]

If anyone is keen to learn more about service workers here is a great resource:
https://serviceworke.rs/

I expect Service Workers to play a big part in the future of Wikipedia
especially in the performance field (you may also find my blog post -
https://jonrobson.me.uk/lazy-images-with-service-worker/ - of
interest)

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

Re: [Wikitech-l] CI and cross repository dependencies

[Jon Robson]

This is great. Just tried it out on
https://gerrit.wikimedia.org/r/#/c/238992/ and hopefully it will soon
be passing. This should hopefully help bubble up important dependent
patches that might be overlooked if developers are not watching
certain repositories and simply ignoring patches to Jenkins -2ing
which can be for a variety of reasons :)

Now I just need to get out of the habit of writing "Dependency:" in
favour of "Depends-On:" :)


On Thu, Nov 19, 2015 at 2:51 PM, Brian Gerstle <bgers...@wikimedia.org> wrote:
>>
>> Jenkins as a huge collections of independent shell scripts
>> that are waiting to be executed with appropriate parameters.
>
>
> Right that made me wonder... but then you said:
>
> OpenStack has a spec to get rid of Jenkins entirely and instead have
>> Zuul create an Ansible play book to run on a machine.  But really that
>> is another topic.
>
>
> Makes sense that we should drop Jenkins if we're not leveraging it's
> features.
>
> Congrats again on contributing back to the OSS community!
>
> On Thu, Nov 19, 2015 at 2:27 PM, Antoine Musso <hashar+...@free.fr> wrote:
>
>> Le 19/11/2015 18:51, Brian Gerstle a écrit :
>> > Nice work!
>> >
>> > Is this at all related to upstream/downstream Jenkins jobs?
>>
>> The Zuul system does not rely at all on Jenkins upstream/downstream. One
>> can think of Jenkins as a huge collections of independent shell scripts
>> that are waiting to be executed with appropriate parameters.
>>
>> OpenStack has a spec to get rid of Jenkins entirely and instead have
>> Zuul create an Ansible play book to run on a machine.  But really that
>> is another topic.
>>
>>
>> To elaborate a bit more:
>>
>> Gerrit does support dependencies between changes, but only in the same
>> repository and branch. You can see that in the Gerrit web interface, and
>> Gerrit will refuse to merge a change for which the parent is not merged
>> yet.
>>
>> Zuul does the same but independently from Gerrit. It is merely filling
>> the gap of Gerrit lacks of cross repositories dependencies.
>>
>> When a change is voted +2, it is enqueued in 'gate-and-submit'.  Zuul
>> immediately verify whether the dependencies are either merged or ahead
>> in the queue, else it will reject the change and report back in Gerrit.
>>
>> So if you have change A and change B depending on A. You +2 A then B and
>> the queue is:
>>
>>  A <-- B (depend on A)
>>
>> A is processed (no dependency)
>> For B, Zuul find the dependency A ahead and thus it is processed.
>>
>> If A fails the tests, B tests are automatically cancelled and the change
>> dequeued.  Zuul knows B depends on A.
>>
>> Assuming all changes are merged by Zuul (via CR+2), Zuul dependency
>> comes on top of Gerrit and nicely enforce dependencies.
>>
>>
>>
>> --
>> Antoine "hashar" Musso
>>
>>
>> ___________
>> 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



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

Re: [Wikitech-l] CI and cross repository dependencies

[Jon Robson]

This doesn't seem to work for https://gerrit.wikimedia.org/r/#/c/238992/
Any ideas why? Is it because the Gather patch is on a different branch
or because I'm not using the commit message right?


On Wed, Dec 2, 2015 at 2:36 PM, Marko Obrovac <mobro...@wikimedia.org> wrote:
> Thanks a ton, Antoine, for this! It has just made our lives sooo much
> easier for properly testing https://gerrit.wikimedia.org/r/#/c/254086/ :)
>
> On 2 December 2015 at 18:44, Jon Robson <jdlrob...@gmail.com> wrote:
>
>> This is great. Just tried it out on
>> https://gerrit.wikimedia.org/r/#/c/238992/ and hopefully it will soon
>> be passing. This should hopefully help bubble up important dependent
>> patches that might be overlooked if developers are not watching
>> certain repositories and simply ignoring patches to Jenkins -2ing
>> which can be for a variety of reasons :)
>>
>> Now I just need to get out of the habit of writing "Dependency:" in
>> favour of "Depends-On:" :)
>>
>
> True. My favourite line was:
>
> Note: depends on 
>
> In my case, I just need to drop "note:" and change the casing :P
>
> Cheers,
> Marko
>
>
>>
>> On Thu, Nov 19, 2015 at 2:51 PM, Brian Gerstle <bgers...@wikimedia.org>
>> wrote:
>> >>
>> >> Jenkins as a huge collections of independent shell scripts
>> >> that are waiting to be executed with appropriate parameters.
>> >
>> >
>> > Right that made me wonder... but then you said:
>> >
>> > OpenStack has a spec to get rid of Jenkins entirely and instead have
>> >> Zuul create an Ansible play book to run on a machine.  But really that
>> >> is another topic.
>> >
>> >
>> > Makes sense that we should drop Jenkins if we're not leveraging it's
>> > features.
>> >
>> > Congrats again on contributing back to the OSS community!
>> >
>> > On Thu, Nov 19, 2015 at 2:27 PM, Antoine Musso <hashar+...@free.fr>
>> wrote:
>> >
>> >> Le 19/11/2015 18:51, Brian Gerstle a écrit :
>> >> > Nice work!
>> >> >
>> >> > Is this at all related to upstream/downstream Jenkins jobs?
>> >>
>> >> The Zuul system does not rely at all on Jenkins upstream/downstream. One
>> >> can think of Jenkins as a huge collections of independent shell scripts
>> >> that are waiting to be executed with appropriate parameters.
>> >>
>> >> OpenStack has a spec to get rid of Jenkins entirely and instead have
>> >> Zuul create an Ansible play book to run on a machine.  But really that
>> >> is another topic.
>> >>
>> >>
>> >> To elaborate a bit more:
>> >>
>> >> Gerrit does support dependencies between changes, but only in the same
>> >> repository and branch. You can see that in the Gerrit web interface, and
>> >> Gerrit will refuse to merge a change for which the parent is not merged
>> >> yet.
>> >>
>> >> Zuul does the same but independently from Gerrit. It is merely filling
>> >> the gap of Gerrit lacks of cross repositories dependencies.
>> >>
>> >> When a change is voted +2, it is enqueued in 'gate-and-submit'.  Zuul
>> >> immediately verify whether the dependencies are either merged or ahead
>> >> in the queue, else it will reject the change and report back in Gerrit.
>> >>
>> >> So if you have change A and change B depending on A. You +2 A then B and
>> >> the queue is:
>> >>
>> >>  A <-- B (depend on A)
>> >>
>> >> A is processed (no dependency)
>> >> For B, Zuul find the dependency A ahead and thus it is processed.
>> >>
>> >> If A fails the tests, B tests are automatically cancelled and the change
>> >> dequeued.  Zuul knows B depends on A.
>> >>
>> >> Assuming all changes are merged by Zuul (via CR+2), Zuul dependency
>> >> comes on top of Gerrit and nicely enforce dependencies.
>> >>
>> >>
>> >>
>> >> --
>> >> Antoine "hashar" Musso
>> >>
>> >>
>> >> ___
>> >> 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
>>
>>
>>
>> --
>> 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
>>
>
>
>
> --
> Marko Obrovac, PhD
> Senior Services Engineer
> Wikimedia Foundation
> ___
> 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

Re: [Wikitech-l] [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

[Jon Robson]

On 17 Nov 2015 12:28 a.m., "Brad Jorsch (Anomie)" <bjor...@wikimedia.org>
wrote:
>
> On Sun, Nov 15, 2015 at 4:47 AM, Jon Robson <jdlrob...@gmail.com> wrote:
>
> > Why not? Whats wrong with a fixed width centered site?
>
>
>  Because reading
> text like this
> is really annoying
> when you have
> gigantic amounts
> of wasted
> whitespace on
> either side.
> (And it's even
> worse if someone
> decides that
> contrast is bad
> too...)

If you're annoyed by this yoh should probably upgrade your browser to one
that support media queries.

Wikipedia is not that special that it cant follow the various examples on
the web, meet its mission by ensuring older browsers can tender our content
and focus its energy on the majority of our development time on the people
who can upgrade their browsers

If this point is lost on everyone I give up.

>
> (apologies to people using non-HTML mail readers, you may be missing the
> point of this reply-by-example)
> ___
> 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] [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

[Jon Robson]

On 15 Nov 2015 2:31 p.m., "Isarra Yos" <zhoris...@gmail.com> wrote:
>
> I agree that it's important to move away from desktop-first, but
switching to mobile-first isn't the answer either. For

Why not? Whats wrong with a fixed width centered site? Old phones do not
have media query support nor do they have ability to support conditional
statements.

complex products (discussion boards, skins, anything that could benefit
from a lot of space), there are going mobile-specific styles same as any
other resolution - do ANY as the 'main', and you're having to undo and
override those styles on every other one, which results in unnecessarily
complicated and large code, which just makes it all that much harder to
maintain and work with.
>
> As an example, this is an important part of why it's been so hard to make
Vector properly responsive - so many of

This will never happen. True mobile development is a lot more than moving
around styles. For example the current responsive vector skin that exists
in an experimental state sits at the bottom of the page which is a dead
zone. I'm yet to see any good examples of this done well.

the desktop styles needed to be overridden in order for any mobile design
to be applied. (This would have applied in either direction because its
desktop and mobile layouts are so completely different.) But suppose that
same step had been replaced with instead separating out the desktop styles
into a separate stylesheet for a similar amount of effort, and with each as
separate, independent stylesheets - code for both desktop and mobile would
be made cleaner, and far easier to iterate upon.

You want a responsive skin though. What you are describing is not one. A
responsive site uses the same stylesheet for both desktop and mobile.

(People wanted me to iterate on what's there now and I couldn't even figure
out where to begin. Not that I'm that good at CSS in the first place, but
that code is scary.)
>
> What we need to do is get better at distinguishing and leveraging the
common styles, and using common variables and mixins, because this is how
you make consistent overall styles and also simplify the overall thing.
Then build these into something that works for each platform.
>
> And if we're going to support stupid broken things, we need to explicitly
support them with some sort of fallback that doesn't require a lot of
manual rejigging. I'm not sure IE8, as an ancient desktop browser, getting
mobile styles is really any better than an ancient mobile browser getting
desktop styles.

Why not? Other experts in the field far more qualified than myself think so.
For example
https://stuffandnonsense.co.uk/blog/about/the-guardians-take-on-mobile-first-responsive-web-design-and-ie8
There are countless more if you Google.

>
>
> On 14/11/15 22:39, Jon Robson wrote:
>>
>> The solution to this is to do true mobile first development e.g. wrap
your
>> desktop and tablet styles in media queries. Rendering a mobile site in
IE8
>> is an acceptable trade off and ensures the content remains readable which
>> is the most important thing here.
>>
>> We (Wikimedia devs) still build desktop first in all our major projects
and
>> we really need to shift away from this. We can't simply build for desktop
>> and then adapt it to work on mobile which seems to be a common
>> misconception by anyone who hasn't built things for mobile. This approach
>> is costly as we end up rebuilding things we've already built to make them
>> work on mobile. We used to have a mobile department that pretty much did
>> this as a full time job but now that has gone we really need to adopt
this
>> tried and tested approach.
>> On 13 Nov 2015 2:20 a.m., "Isarra Yos" <zhoris...@gmail.com> wrote:
>>
>>> Perhaps I should clarify why this is a problem. In fully responsive
skins,
>>> you generally have separate stylesheets for desktop, mobile, really big
>>> desktop, whatever in order to keep the CSS rules simple and not
redundant
>>> (to avoid having mobile overriding desktop rules or visa versa, you just
>>> only send the mobile styles to mobile, the desktop to desktop). You do
this
>>> by setting maximum and minimum screen sizes in the @media queries, but
the
>>> problem is, IE8 does not support this, and will not load a stylesheet at
>>> all if these sizes are set. So you need to give it the desktop styles
some
>>> other way, without the @media size rules present.
>>>
>>> While it is possible to simply add CSS to the page header using
>>> outputPage, probably bypassing RL and all that entirely, this only works
>>> with CSS, not LESS, because all the LESS magic is happening within RL.
So
>>> without RL, that means you need to render your desktop styleshe