Re: [Wikitech-l] +2 nomination for Jakob in mediawiki/*

[Kunal Mehta]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I've closed the request as successful. Congrats Jakob!

- -- Legoktm

On 05/20/2018 10:47 AM, Addshore wrote:
> Hi,
> 
> I've filed <*https://phabricator.wikimedia.org/T195220 
> *>, nominating Jakob for
> +2 in mediawiki/ repos.
> 
> -- Addshore ___ 
> Wikitech-l mailing list Wikitech-l@lists.wikimedia.org 
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE+h6fmkHn9DUCyl1jUvyOe+23/KIFAlsV0nAACgkQUvyOe+23
/KLzpw/8CJ1rMcyMuz3/3/FQr1+ciympNe+sJIo7niKKI2XcMyvDb4wY4cpTaBS9
8Wlgtbju1VLTG0d6oCxHWrVHW3SezDRK2jgrOzbrXgEb5QcKc/8RYuvZdsMpTWHQ
9I+qvraIiSCeK0SYJjz/+PkglQa+wejwoZFrvkXdFWtHtbfhkaIXdoJo+UhjK/el
ICEUKgTDjM2FP6b0NQ75YpG+V6gFZNZTDNJmAwcnTH28GPS3Oi9hhfAw5SpOVQE/
YCqA9x/0MKaerw7wgKzIx87px28dJHLFs8B/QwF3mB9EYjYwvU9zP+r85fbAJ2Lf
uYXLBUCOLOWGeKR7w0XxCb7yTVfsC7G17gYW/nNjR/QsgDUseTy8jkICp3moEc45
ZW6kdKKz/aKmyqkgYEpCptwTnW2AZg/DNdfLUE+qY7h45UCQwTO1uuso8go2CuIp
QoFhcK7Jg/Rb2OgmU1FpjAXWVubJElZSLB2cfOxmXt1x3u5kX9+iIQcGTKiYkQBR
xPgnyqcA1iyMXogaNrSfvhXX6mZsrJ56yBWawdImc8gNYGXezn9oIProhaleobzW
JuuwxDrcwkEi86R0gKMcGmAl29Jd+95vThG14npFfeCNlqaAFocQS3cRTYq1jQZw
2EoS4Wj42EQCzDm6xy+YDrvJTYZYARk/KLg1WchUkr78wML6bVg=
=2T7R
-END PGP SIGNATURE-

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

Re: [Wikitech-l] RFC discussion: the future of rev_parent_id

[Brad Jorsch (Anomie)]

On Mon, Jun 4, 2018 at 3:22 PM, Brian Wolff  wrote:

> I dont view the parent as what revision came first but what revision was
> edited to make this revision (i.e. where the current revision was "forked"
> off from)
>

Although that implies that an automatically-resolved edit conflict should
have a "parent" as the revision that was edited rather than the current
revision, again different from the current behavior (and both of the
options Daniel discusses in the task).

It similarly implies that an edit starting with an old revision should
record that old revision as the "parent" instead of the current revision,
again different from the current behavior. And maybe the same for rollbacks
and at least some undos.


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

Re: [Wikitech-l] RFC discussion: the future of rev_parent_id

[Leon Ziemba]

> > Excellent, thank you! It would be particularly interesting to know what
> > assumptions you make about the semantics of rev_parent_id. E.g. there
> are three
> > revisions, A, B, and C, and revision B gets romoved - what should
> revision C's
> > parent be?
> >
> > Similarly, when revision X gets imported and inserted between A and B,
> what
> > should revision B's parent be?
>
> I think in such a case, revision C's parent should benull or 0. Similarly
> for revision X.
>
> I dont view the parent as what revision came first but what revision was
> edited to make this revision (i.e. where the current revision was "forked"
> off from)
>

Yep, that was my thinking. I was going to save it for the IRC discussion,
but since I can say this quickly: I use rev_parent_id to find the literal
*previous* revision (revision that was "forked", as Brian says), for the
purposes of immediate revert detection and for the diff size. I also do
this for the subsequent revision, all with a single query (FROM revision
then two JOINs on revision). If I can get this information just as easily
by other means, my use case is satisfied.

Also quick side note, I hope it's obvious that viewing diff sizes on
revision histories and contribution pages is essential. Indeed it's
sometimes wrong, so obviously it'd be great if that could somehow be fixed
:) I'm sure you smart people have some great ideas. Looking forward to the
IRC discussion.

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

Re: [Wikitech-l] RFC discussion: the future of rev_parent_id

[Brian Wolff]

On Monday, June 4, 2018, Daniel Kinzler  wrote:
> Am 04.06.2018 um 20:54 schrieb Leon Ziemba:
>>> ... the size differences shown on the history and contributions pages,
>> which is the only thing that rev_parent_id is used for
>>
>> This may be true in MediaWiki but not so much for external tools. I just
>> wanted to preemptively say this. I'll be joining the IRC discussion to
>> share more :)
>
> Excellent, thank you! It would be particularly interesting to know what
> assumptions you make about the semantics of rev_parent_id. E.g. there are
three
> revisions, A, B, and C, and revision B gets romoved - what should
revision C's
> parent be?
>
> Similarly, when revision X gets imported and inserted between A and B,
what
> should revision B's parent be?
>
> --
> Daniel Kinzler
> Principal Platform Engineer
>
> Wikimedia Deutschland
> Gesellschaft zur Förderung Freien Wissens e.V.
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I think in such a case, revision C's parent should benull or 0. Similarly
for revision X.

I dont view the parent as what revision came first but what revision was
edited to make this revision (i.e. where the current revision was "forked"
off from)
--
Brian
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] RFC discussion: the future of rev_parent_id

[Daniel Kinzler]

Am 04.06.2018 um 20:58 schrieb James Hare:
> To add to Leon's use case, I would argue that it may be one use case but
> it's a pretty visible one to active contributors who are familiar with the
> history page. It may be worth clarifying whether this is a backend change
> that would keep the feature intact or if this change would result in a
> change to Wikimedia projects' user experience.

First of all, the purpose of this discussion is mainly to explore the problem
and the options we have. We don't expect to approve any action just yet. Perhaps
I should have made this clear in my original mail.

The intention is to keep the feature - but since the behavior of the feature is
inconsistent (e.g. the size difference shown does not always correspond to the
linked diff) and changed over time (due to bugs in the undeletion code, for
instance), one important question is what the expected behavior actually is.

-- 
Daniel Kinzler
Principal Platform Engineer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

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

Re: [Wikitech-l] RFC discussion: the future of rev_parent_id

[Daniel Kinzler]

Am 04.06.2018 um 20:54 schrieb Leon Ziemba:
>> ... the size differences shown on the history and contributions pages,
> which is the only thing that rev_parent_id is used for
> 
> This may be true in MediaWiki but not so much for external tools. I just
> wanted to preemptively say this. I'll be joining the IRC discussion to
> share more :)

Excellent, thank you! It would be particularly interesting to know what
assumptions you make about the semantics of rev_parent_id. E.g. there are three
revisions, A, B, and C, and revision B gets romoved - what should revision C's
parent be?

Similarly, when revision X gets imported and inserted between A and B, what
should revision B's parent be?

-- 
Daniel Kinzler
Principal Platform Engineer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

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

Re: [Wikitech-l] RFC discussion: the future of rev_parent_id

[James Hare]

On Mon, Jun 4, 2018 at 11:54 AM, Leon Ziemba 
wrote:

> > ... the size differences shown on the history and contributions pages,
> which is the only thing that rev_parent_id is used for
>
> This may be true in MediaWiki but not so much for external tools. I just
> wanted to preemptively say this. I'll be joining the IRC discussion to
> share more :)
>
> ~Leon
>

To add to Leon's use case, I would argue that it may be one use case but
it's a pretty visible one to active contributors who are familiar with the
history page. It may be worth clarifying whether this is a backend change
that would keep the feature intact or if this change would result in a
change to Wikimedia projects' user experience.


>
> On Mon, Jun 4, 2018 at 2:23 PM Daniel Kinzler  >
> wrote:
>
> > As mentioned in the TechCom radar email last week, there will be a public
> > IRC
> > discussion on  the future of rev_parent_id on Wednesday, 2018-06-06 in
> the
> > #wikimedia-office channel at 2pm PST(22:00 UTC, 23:00 CET).
> >
> > The RFCs original title was "Use ar_page_id to determine the parent IDs
> for
> > undeleted revisions" .
> > However, the
> > discussion has drifted quite a bit, and is now touching on questions
> > around the
> > size differences shown on the history and contributions pages, which is
> > the only
> > thing that rev_parent_id is used for. Perhaps we should have filed a
> > separate
> > ticket, but at this point, that would just have meant splitting the
> > conversation, and creating more confusion...
> >
> > Anyway, in preparation of the RFC discussion, here are again the main
> > question
> > that need answering:
> >
> > * Can we do without rev_parent_id entirely?  Can we live without the size
> > info
> > on Special:Contributions, or can we query it cheaply enough?
> >
> > * Do we want to record the original "edit as intended", and if yes,
> where?
> >
> > * On a side note, what's the best way to detect a page's first revision,
> > and do
> > we still need that if we have the page creation log (and recentchanges).
> >
> > I have tried to summarize the discussion so far, with the available
> > options and
> > considerations, at .
> >
> > --
> > Daniel Kinzler
> > Principal Platform Engineer
> >
> > Wikimedia Deutschland
> > Gesellschaft zur Förderung Freien Wissens e.V.
> >
> > ___
> > 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] RFC discussion: the future of rev_parent_id

[Leon Ziemba]

> ... the size differences shown on the history and contributions pages,
which is the only thing that rev_parent_id is used for

This may be true in MediaWiki but not so much for external tools. I just
wanted to preemptively say this. I'll be joining the IRC discussion to
share more :)

~Leon

On Mon, Jun 4, 2018 at 2:23 PM Daniel Kinzler 
wrote:

> As mentioned in the TechCom radar email last week, there will be a public
> IRC
> discussion on  the future of rev_parent_id on Wednesday, 2018-06-06 in the
> #wikimedia-office channel at 2pm PST(22:00 UTC, 23:00 CET).
>
> The RFCs original title was "Use ar_page_id to determine the parent IDs for
> undeleted revisions" .
> However, the
> discussion has drifted quite a bit, and is now touching on questions
> around the
> size differences shown on the history and contributions pages, which is
> the only
> thing that rev_parent_id is used for. Perhaps we should have filed a
> separate
> ticket, but at this point, that would just have meant splitting the
> conversation, and creating more confusion...
>
> Anyway, in preparation of the RFC discussion, here are again the main
> question
> that need answering:
>
> * Can we do without rev_parent_id entirely?  Can we live without the size
> info
> on Special:Contributions, or can we query it cheaply enough?
>
> * Do we want to record the original "edit as intended", and if yes, where?
>
> * On a side note, what's the best way to detect a page's first revision,
> and do
> we still need that if we have the page creation log (and recentchanges).
>
> I have tried to summarize the discussion so far, with the available
> options and
> considerations, at .
>
> --
> Daniel Kinzler
> Principal Platform Engineer
>
> Wikimedia Deutschland
> Gesellschaft zur Förderung Freien Wissens e.V.
>
> ___
> 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] Readers Monthly update for May 2018

[Chris Koerner]

Hello again,
This is the monthly update from the Readers team at the Wikimedia
Foundation for May 2018.

==Discussions==

=== Apps===
* iOS and Android teams both published incremental updates to address
issues with new Reading Lists. [0]

=== Web ===
* Continuing work on the mobile page issues project [1]
* Preparing for the deployment of our new PDF renderer [2]
* Team was way at offsite and hackathon - discussing plans for next year

=== Reading Infrastructure ===
* Published Wikipedia Reading List browser extensions for Chrome and
Firefox.[3] Safari extension to follow hopefully soon, but dealing
with a cookie issue when "keep me logged in" is not used.
* Updated various APIs (action=mobileview, /page/summary,
/page/mobile-sections) to provide locally overwritten descriptions vs.
the centrally stored ones in Wikidata. [4] [5] These were follow-ups
to T192838. [6]

=== New Readers ===
* New Reader updates can be found at Meta. [7]

[0] https://www.mediawiki.org/wiki/Wikimedia_Apps/Synced_Reading_Lists
[1] https://www.mediawiki.org/wiki/Reading/Web/Projects/Mobile_Page_Issues
[2] https://phabricator.wikimedia.org/T181084
[3] 
https://www.mediawiki.org/w/index.php?title=Wikimedia_Apps/Reading_list_browser_extension
[4] https://phabricator.wikimedia.org/T192837
[5] https://phabricator.wikimedia.org/T191869
[6] https://phabricator.wikimedia.org/T192838
[7] https://meta.wikimedia.org/wiki/New_Readers/Updates
---

Subscribe to receive theses updates as on-wiki notifications or opt-in email.

https://www.mediawiki.org/wiki/Newsletter:Readers_Monthly

The archive of all past updates can be found on MediaWiki.org:

https://www.mediawiki.org/wiki/Reading/Status_updates

Yours,
Chris Koerner
Community Liaison
Wikimedia Foundation

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

[Wikitech-l] RFC discussion: the future of rev_parent_id

[Daniel Kinzler]

As mentioned in the TechCom radar email last week, there will be a public IRC
discussion on  the future of rev_parent_id on Wednesday, 2018-06-06 in the
#wikimedia-office channel at 2pm PST(22:00 UTC, 23:00 CET).

The RFCs original title was "Use ar_page_id to determine the parent IDs for
undeleted revisions" . However, the
discussion has drifted quite a bit, and is now touching on questions around the
size differences shown on the history and contributions pages, which is the only
thing that rev_parent_id is used for. Perhaps we should have filed a separate
ticket, but at this point, that would just have meant splitting the
conversation, and creating more confusion...

Anyway, in preparation of the RFC discussion, here are again the main question
that need answering:

* Can we do without rev_parent_id entirely?  Can we live without the size info
on Special:Contributions, or can we query it cheaply enough?

* Do we want to record the original "edit as intended", and if yes, where?

* On a side note, what's the best way to detect a page's first revision, and do
we still need that if we have the page creation log (and recentchanges).

I have tried to summarize the discussion so far, with the available options and
considerations, at .

-- 
Daniel Kinzler
Principal Platform Engineer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

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

[Wikitech-l] Discovery Weekly Update for the week starting 2018-05-28

[Chris Koerner]

Hello,
We're back! Here is our post Hackathon update this week from the
Search Platform team.

As always, feedback and questions welcome.

== Discussions ==

=== Search ===
* Erik worked on evaluating and building out features provided by
`query_explorer` functionality of learning-to-rank plugin, there is
lots of good info in the ticket [0]
* David worked on allowing searches with "all:" keyword to also work
on non-English projects, and not only with its translations
("searchall") [1]
* David increased the cirrus indices to have more shards for
enwiki_general, viwiki_general and wikidatawiki_content [2]
* David reverted an earlier patch that had depreciated the global
namespace handling of the prefix keyword; the new patch was deployed —
prefix and associated InputBox forms should work as before. [3]
* Trey and Gehel deployed the updated search/extra plugin and
search/extra-analysis-slovak plugin with Slovak Stemmer [4] and will
be available after a re-indexing [5]
* Stas enabled deep category support on all wikis (except private) [6]
* Stas reindexed wikidata to enable support for searching for string &
external ID property values [7], [8]
* Stas implemented basic text indexing for Lexemes [9]

[0] https://phabricator.wikimedia.org/T187148#4086754
[1] https://phabricator.wikimedia.org/T165110
[2] https://phabricator.wikimedia.org/T192064
[3] https://phabricator.wikimedia.org/T193392
[4] https://phabricator.wikimedia.org/T191543
[5] https://phabricator.wikimedia.org/T191545
[6] https://phabricator.wikimedia.org/T194260
[7] https://phabricator.wikimedia.org/T163642
[8] https://phabricator.wikimedia.org/T99899
[9] https://phabricator.wikimedia.org/T195912
---

Subscribe to receive on-wiki (or opt-in email) notifications of the
Discovery weekly update.

https://www.mediawiki.org/wiki/Newsletter:Discovery_Weekly

The archive of all past updates can be found on MediaWiki.org:

https://www.mediawiki.org/wiki/Discovery/Status_updates

Interested in getting involved? See tasks marked as "Easy" or
"Volunteer needed" in Phabricator.

[1] https://phabricator.wikimedia.org/maniphest/query/qW51XhCCd8.7/#R
[2] https://phabricator.wikimedia.org/maniphest/query/5KEPuEJh9TPS/#R

Yours,
Chris Koerner
Community Liaison
Wikimedia Foundation

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

Re: [Wikitech-l] function drawmap not defined when loading external js with resourceLoader

[Bartosz Dziewoński]

Scripts loaded via ResourceLoader are not executed in global scope, so 
your variables/functions will not be global.


To make them global, you have to explicitly attach them to the `window` 
object – add this at the end of your external_script.js:


window.drawmap = drawmap;

--
Bartosz Dziewoński

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

[Wikitech-l] Call for Nominations: TechCom is looking for new members

[Daniel Kinzler]

Dear all,

We, the Wikimedia Technical Committee (TechCom), are looking for two new members
to broaden the committee’s area of expertise. If you can think of anyone
(including yourself) who may be a good addition to TechCom, please read on, here
or on the wiki [2].

TechCom is the guardian of the integrity, consistency, stability, and
performance of all software supporting the Wikimedia projects. It acts as the
senior advisor and the convergence point of all decisions related to technical
work that is strategic, cross-cutting, and/or hard to undo [1].

Traditionally, TechCom members have mainly been experts for MediaWiki core. We
have been slowly growing the committee to get a broader perspective, and now
want to try harder to cover our blind spots by starting this nomination process.

Some areas of expertise that we hope new members would bring to the table
include: internationalization, deployment and releases, mobiles apps, security,
performance, and analytics. We are also interested in expertise in areas at the
fringes of TechCom’s scope, such as privacy, interaction design, and bug 
wrangling.

Of course, we will not be able to cover all these areas perfectly with the
addition of just two people and we will likely expand the size of the committee
further in the future. For now however, we want to be careful to not to grow the
committee too quickly, so that we have time to adjust existing processes to a
larger group.

TechCom members are expected to be available at least 4 hours per week for
committee work. This includes meetings, administrative work, and technical work
[1], and also taking care of the RFC process [4]. As we evolve the committee to
become more proactive, we also expect to spend more time drafting and discussing
guidelines and policies.

You can find the list of current members on the TechCom page [3]. If you would
like to join, or want to nominate somebody else, please send an email to
 by June 18 with “Nomination for ” in the subject
line. The email should contain an overview of the nominee’s skill set and
experience as well as a short pitch explaining why this person would be a good
addition to TechCom.

Nominations are now open until June 18, 2018; and we will review the submissions
and vet the potential new members over the following weeks. We hope that we can
announce new members before the end of July.


Daniel Kinzler,
Chair of the Wikimedia Technical Committee


[1] https://www.mediawiki.org/wiki/Wikimedia_Technical_Committee/Charter
[2]
https://www.mediawiki.org/wiki/Wikimedia_Technical_Committee/Call_for_Nominations
[3] https://www.mediawiki.org/wiki/Wikimedia_Technical_Committee
[4] https://www.mediawiki.org/wiki/Requests_for_comment/Process

-- 
Daniel Kinzler
Principal Platform Engineer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

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

[Wikitech-l] function drawmap not defined when loading external js with resourceLoader

[Tom Schulze]

Hello everyone,

I have created a public gist 
 
with a minimal working example. I am trying to put JavaScript Code from 
a Widget to an external JS file and load it dynamically with the 
ResourceLoader. However, the developer console returns the following 
error: jQuery.Deferred exception: drawmap is not defined when I am 
accessing the function defined in the external script. Checking the 
state in the developer console with 
'mw.loader.getState("ext.iswiki.display_project_map")' returns: "ready".


When the Resource Loader debug mode is enabled in LocalSettings.php the 
function is found and called.


What am I doing wrong?

Kind regards,

Tom

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