[Wikitech-l] MathML opt-in available

[Physikerwelt]

Dear all,
The MathML rendering option was enabled in all WMF-deployed wikis
on March 12 for logged-in users [1].

Based on the feedback from the German-speaking community, many
advanced Math users prefer the LaTeX / MathJax style rendering, which
uses a bigger font size and provides an extra bold rendering experience.
Client-side MathJax is perceived to make it easier to differentiate
text and formulae. Consequently, a client-side MathJax rendering
option will be added, allowing power users to have the same experience
as many other websites that rely on client-side MathJax for math rendering [2].

This eventually means that we no longer rely on RestBASE or Mathoid
for math rendering in MediaWiki and can use math support even without
connections to external services. This goes beyond what was promised
after the technical conference in 2019 when the shift away from the
restbase cache was announced [3,4].
MathML rendering makes use of MediaWikis' built-in cache abstraction.

For more details on the new rendering option, see
https://arxiv.org/pdf/2401.16786.pdf.

In the optimal case, we can discontinue restbase and mathoid math
rendering from version 1.42 and backport the changes to LTS versions.

Please let me know if you rely on mathoid in one way or another.

All the best
Moritz (physikerwelt)

[1]: https://phabricator.wikimedia.org/T358803
[2]: https://phabricator.wikimedia.org/T354136
[3]: 
https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/N2VGVG2HFPRNZCNNH5NMIR47UWRYAK4V/#N2VGVG2HFPRNZCNNH5NMIR47UWRYAK4V
[4]: 
https://www.mediawiki.org/w/index.php?title=RESTBase/deprecation=6045239
___
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: MediaWiki Insights - Fourth Monthly Email

[Physikerwelt]

Hi Birgit and team,


I really appreciate this effort and congratulations on the wonderful
results. After having checked the links in the mail, all my open questions
are answered except for one:


Is there a mechanism to flag tickets that need a review? From the
description in https://phabricator.wikimedia.org/project/profile/3144/
<https://goto-ng.fiz-karlsruhe.de/project/profile/3144/,DanaInfo=phabricator.wikimedia.org,SSL+>
one gets the impression that this is on halt.


All the best

Moritz (physikerwelt)




On Thu, Nov 30, 2023 at 8:52 PM Birgit Müller 
wrote:

> Hi All,
>
> Welcome to the monthly MediaWiki Insights email!
>
> Enable more people to know MediaWiki and contribute effectively
>
> In the last MW insights email
> <https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports/October_2023>
> we shared more about our approach to helping people contribute
> effectively to MediaWiki
> <https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Contributor_retention_and_growth>.
> A few interesting data points:
>
> The number of contributors to MediaWiki core who have more than > 5
> patches continued to grow: We just hit for the first time the goal of 20%
> since the start of the Foundation’s fiscal year in July, compared to the
> July-November time period last year. This is exciting to see - now it’s
> about keeping the momentum and continuing on that path.
>
> Many thanks to all the people who have contributed to MediaWiki core!
>
> The average and median time to first review for patches in MediaWiki core
> decreased significantly in the period July 1st to Nov 30 compared to the
> same time period one year earlier.
>
>
>- Average time to first review dropped from previously 16.5 days to
>4.5 days
>- Median time to first review dropped from previously 1.2 days to 0.6
>days
>
> Many thanks to all the code reviewers of MediaWiki core patches!
>
> Keep in mind that this data is only one data point. There are many factors
> that play into the experience of contributors; a helpful comment may be
> more relevant than a fast +1/-1, etc.
>
> Over the past weeks, we have been spending some time with planning
> initiatives to further support people in onboarding and contributing to
> MediaWiki:
>
>
>- We are preparing for a WMF internal MediaWiki code jam in December
>to try out a few things and focus specifically on the needs of teams.
>- One thing we wanted to test in practice at the code jam is the “MediaWiki
>Quick Install <https://phabricator.wikimedia.org/T347347>” guide. This
>has been a collaboration between the Tech Docs team and the MediaWiki
>Platform team - you can find the latest version of this experiment here:
>https://www.mediawiki.org/wiki/Local_development_quickstart
>- We discussed a possible focus project in the next quarter on
>improving first time MediaWiki (core) contributors’ experience. We’re
>exploring a few simple, small ideas that we could implement/try out in the
>next quarter (ticket follows!).
>
> Project snapshot: Analysis of MediaWiki execution timings, fixing issues
> with logging in on Mobile, progress on RESTBase deprecation and more!
>
> Performance: Piotr and Timo conducted an analysis of MediaWiki execution
> timings <https://phabricator.wikimedia.org/T350593> and identified areas
> for improvement. One of the fixes promises a 50ms improvement
> <https://phabricator.wikimedia.org/T351807>! Timo and Derick worked on
> bagOStuff improvements <https://phabricator.wikimedia.org/T336004> (cache
> layer), shipped on MW-1.42. This work aims to lower the barriers for
> contributors by making interfaces leaner and more intuitive and is reducing
> storage access cost from 10ms to ~1 ms. Thank you for your work!
>
> More highlights:
>
>
> MediaWikiIntegrationTestCase now automatically tracks what database tables
> get touched during the integration test, removing the need for developers
> to keep track (T342301 <https://phabricator.wikimedia.org/T342301>). Many
> thanks to Daimona and others for their work on this!
>
> Work towards PHP 8.2 support continues, with one helpful outcome being a
> new DynamicPropertyTestHelper feature (T326466
> <https://phabricator.wikimedia.org/T326466>). Many thanks to TK-999 and
> all reviewers!
>
> Gergö worked on solving a variety of problems with logging in on mobile
> (see https://phabricator.wikimedia.org/T257852#9347008 and below). Many
> thanks to Gergö and everyone who provided support!
>
> RESTBase sunset: Wikifeeds now calls the Parsoid endpoint in MediaWiki
> core rather than RESTBase. Many thanks to Yiannis and Daniel for their hard
> work on making this

[Wikitech-l] Re: Research on Wikimedia Production Errors

[Physikerwelt]

Thank you for your feedback. I think we have a very large and open
corpus of documented incidents. As said, the Wikidata workshop is not
a good target conference. Following the reference

[4]: <https://doi.org/10.1109/ICSE.2013.6606583>

I think a paper on that would better fit
https://conf.researchr.org/track/icse-2024/icse-2024-software-engineering-in-practice

I will continue updating the paper on Overleaf

https://www.overleaf.com/read/swswtbdyyhmg



All the best
Moritz

On Thu, Jun 8, 2023 at 7:57 PM Tyler Cipriani  wrote:
>
>
>
> On Thu, Jun 8, 2023 at 12:40 AM Physikerwelt  wrote:
>>
>> Hi all,
>>
>> is there any research on common causes of Wikimedia production errors?
>>
>> Based on recent examples, I plan to analyze and discuss how production
>> errors could be avoided. I am considering submitting a short paper on
>> that to the Wikidata workshop, with the deadline
>> Thursday, 20 July 2023
>> Website: https://wikidataworkshop.github.io/2023/
>> However, there might be better suitable venues.
>
>
> We (Release Engineering) file production-error tasks as part of the weekly 
> train and collect some data in the "train-stats" repo on GitLab[0]. 
> Additionally, Timo Tijhof's "production excellence" blog posts and emails to 
> this list may be of interest to you[1].
>
> The "train-stats" repo collects data for "software defect prediction" based 
> on the use of "FixCaches" or "BugCaches."[2] Each week, we record changes 
> that fix bugs (i.e., the change uses the git trailer `Bug: TXXX` and gets 
> backported to a currently deployed branch). The theory (per the paper linked 
> above) is that the more often a file needs a fix, the more likely it is to 
> cause future bugs. I have an extremely convoluted query to show the list of 
> commonly backported files[3].
>
> Problems with this data:
> - Many of these files are frequently touched files vs error-prone files 
> (e.g., "composer.json")
> - Looking at the count of backports for each file means newer files are less 
> likely to be represented
> - "Lower level" files may be overrepresented (although, that's probably to be 
> expected)
>
> In 2013, a case study used data like this inside Google and found it to be 
> fairly accurate at predicting future bugs[4].
>
> Also, in the case study, whenever a developer edited a file that was present 
> in their fixCache, researchers added a bot-generated note to the patch in 
> their code review tool.Their developers found this note unhelpful: developers 
> already knew these files were problematic—the warning just caused confusion.
>
> Based on that, in March 2020, we created the "Risky Change Template"[5]. My 
> thinking was: if developers already know what's risky, then they can flag it 
> in the train task for the week[6]. At the time, I hoped this would reduce the 
> total version deployment time (although I have no data on that).
>
> I hope some of this helps!
>
> – Tyler
>
> [0]: <https://gitlab.wikimedia.org/repos/releng/train-stats>
> [1]: 
> <https://phabricator.wikimedia.org/phame/post/view/296/production_excellence_46_july_august_2022/>
> [2]: 
> <https://people.csail.mit.edu/hunkim/images/3/37/Papers_kim_2007_bugcache.pdf>
> [3]: 
> <https://data.releng.team/train?sql=select%0D%0A++filename%2C%0D%0A++project%2C%0D%0A++count%28*%29+as+bug_count%0D%0Afrom%0D%0A++bug+b%0D%0A++join+bug_bug_patch+bbp+on+bbp.bug_id+%3D+b.id%0D%0A++join+bug_patch+bp+on+bp.id+%3D+bbp.bug_patch_id%0D%0A++join+bug_file+bf+on+bp.id+%3D+bf.bug_patch_id%0D%0Agroup+by%0D%0A++project%2C+filename%0D%0Aorder+by%0D%0A++bug_count+desc%3B>
> [4]: <https://doi.org/10.1109/ICSE.2013.6606583>
> [5]: <https://wikitech.wikimedia.org/wiki/Deployments/Risky_change_template>
> [6]: <https://train-blockers.toolforge.org/> (here's an example this week: 
> <https://phabricator.wikimedia.org/T337526#8901982>)
>
>>
>>
>> I am also open to collaboration on this effort. If you are interested
>> in a joint paper, drop me an email until the end of this week.
>>
>> All the best
>> Moritz
>> ___
>> 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 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: [Wiki-research-l] Research on Wikimedia Production Errors

[Physikerwelt]

Hi Nathan,

with "Wikimedia production error", I am referring to
https://phabricator.wikimedia.org/tag/wikimedia-production-error/, an
example is https://phabricator.wikimedia.org/T338381.

All the best
Moritz


On Thu, Jun 8, 2023 at 8:45 AM Nathan TeBlunthuis  wrote:

> Hi Physikerwelt, welcome, and thanks for your interest in opening a
> collaboration. I am not quite sure what you mean by a "Wikimedia
> production error". Suggest giving an example in a reply email to the list?
>
> Physikerwelt  writes:
>
> > !---|
> >   This Message Is From an Untrusted Sender
> >   You have not previously corresponded with this sender.
> >   See https://itconnect.uw.edu/email-tags for additional
> >   information.Please contact the UW-IT Service Center,
> >   h...@uw.edu 206.221.5000, for assistance.
> > |---!
> >
> > Hi all,
> >
> > is there any research on common causes of Wikimedia production errors?
> >
> > Based on recent examples, I plan to analyze and discuss how production
> > errors could be avoided. I am considering submitting a short paper on
> > that to the Wikidata workshop, with the deadline
> > Thursday, 20 July 2023
> > Website:
> https://urldefense.com/v3/__https://wikidataworkshop.github.io/2023/__;!!K-Hz7m0Vt54!hI-5XwzmLR3s7lF2lqj_eXN-Isg-Yuw-c5faZSOa-tLjRXeDuapEILUjiQuBR6TeTbA7btvHPkBlU-EuCQ$
> > However, there might be better suitable venues.
> >
> > I am also open to collaboration on this effort. If you are interested
> > in a joint paper, drop me an email until the end of this week.
> >
> > All the best
> > Moritz
> > ___
> > Wiki-research-l mailing list -- wiki-researc...@lists.wikimedia.org
> > To unsubscribe send an email to
> wiki-research-l-le...@lists.wikimedia.org
>
> --
> Nathan TeBlunthuis
> Postdoctoral Research Fellow
> University of Michigan
> School of Information
> https://teblunthuis.cc
>
___
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] Research on Wikimedia Production Errors

[Physikerwelt]

Hi all,

is there any research on common causes of Wikimedia production errors?

Based on recent examples, I plan to analyze and discuss how production
errors could be avoided. I am considering submitting a short paper on
that to the Wikidata workshop, with the deadline
Thursday, 20 July 2023
Website: https://wikidataworkshop.github.io/2023/
However, there might be better suitable venues.

I am also open to collaboration on this effort. If you are interested
in a joint paper, drop me an email until the end of this week.

All the best
Moritz
___
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: Phabricator monthly statistics - 2022-02

[Physikerwelt]

If we continue this trend, we will be done in 33 years (first order
approximation);-)

On Tue, Mar 1, 2022 at 10:33 AM Lucas Werkmeister
 wrote:
>
> The second month in a row with more closed than created tasks, nice! :)
>
> Am Di., 1. März 2022 um 01:04 Uhr schrieb :
>>
>>
>> Hi Community Metrics team,
>>
>> This is your automatic monthly Phabricator statistics mail.
>>
>> Accounts created in (2022-02): 251
>> Active Maniphest users (any activity) in (2022-02): 1078
>> Task authors in (2022-02): 516
>> Users who have closed tasks in (2022-02): 293
>>
>> Projects which had at least one task moved from one column to another on
>> their workboard in (2022-02): 295
>>
>> Tasks created in (2022-02): 2163
>> Tasks closed in (2022-02): 2285
>> Open and stalled tasks in total: 48923
>> * Only open tasks in total: 48013
>> * Only stalled tasks in total: 910
>>
>> Median age in days of open tasks by priority:
>>
>> Unbreak now: 3
>> Needs Triage: 747
>> High: 1084
>> Normal: 1624
>> Low: 2279
>> Lowest: 2349
>>
>> (How long tasks have been open, not how long they have had that priority)
>>
>> Active Differential users (any activity) in (2022-02): 6
>>
>> To see the names of the most active task authors:
>> * Go to https://wikimedia.biterg.io/
>> * Choose "Phabricator > Overview" from the top bar
>> * Adjust the time frame in the upper right corner to your needs
>> * See the author names in the "Submitters" panel
>>
>> TODO: Numbers which refer to closed tasks might not be correct, as
>> described in https://phabricator.wikimedia.org/T1003 .
>>
>> Yours sincerely,
>> Fab Rick Aytor
>>
>> (via community_metrics.sh on phab1001 at Tue 01 Mar 2022 12:00:22 AM UTC)
>> ___
>> 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/
>
>
>
> --
> Lucas Werkmeister (he/er)
> Full Stack Developer
>
> Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
> Phone: +49 (0)30 219 158 26-0
> https://wikimedia.de
>
> Imagine a world in which every single human being can freely share in the sum 
> of all knowledge. Help us to achieve our vision!
> https://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.
> ___
> 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: Goto for microoptimisation

[Physikerwelt]

Just to play the devils advocate. I want to point out some example risks
(which were of course included in the discussion in the earlier linked
literature):

a) someone will introduce

if ($x==1.5)

in the middle or

b) someone will make action1 modifying on $x which might result in $x==2

the behavior would change.

However it is likely that those mistakes will be discover during code
review, if the function is not too big and Gerrit hides the line with the
goto statement. Thus jumping many lines is more dangerous than jumping only
a few lines.

After all, I still think using goto is a good idea now until the php (8+$x)
jit compiler might do the job for us in the future.

All the best
Physikerwelt

On Sat, 14 Aug 2021, 05:16 Krinkle,  wrote:

> For the record, I merged Tim's patch
> <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/708880/> last week and
> was unaware of this email thread.
>
> My thinking was as follows:
>
> 1. The implementation does not depend on the goto statement.
>
> That is, it is not used to write overly-clever or complicated logic. If
> you remove the goto statement, the method behaves the exact same way. And
> thus the moment it ceases to serve its use (performance optimisation) it
> can be safely removed without further thought. think this is essential to
> keeping the code easy to understand and maintain. This one principle
> actually covers it all for me. The next three points are implied by this:
> 1a. This use of goto only jumps downward. Jumping backwards (up) would
> likely violate point 1, and either way would imho be too complicated to
> think about when debugging or maintaining the code in the future.
> Especially the potential for an infinite loop.
> 1b. This use of goto only jumps to a statement within the same function.
> (In fact, jumping to another file, class, or function is not supported by
> PHP in the first place. This is literally the only way it can be used.
> There is some sanity in the language after all!).
> 1c. This use of goto serves as a performance optimisation for a hot code
> path. Similarly implied by point 1: If it doesn't change behaviour and
> doesn't improve performance where it matters, we shouldn't bother using it.
>
> 2. An inline comment clearly stays it is a performance optimisation, and
> explains why it is safe, and how we know the destination is where we would
> end up regardless. (e.g. "we're inside a condition for X2, so we can skip
> to the else of X1, and no other statements would run between here and
> there").
>
> -- Timo
>
>
> On Sat, 31 Jul 2021 at 05:10, Tim Starling 
> wrote:
>
>> For performance sensitive tight loops, such as parsing and HTML
>> construction, to get the best performance it's necessary to think about
>> what PHP is doing on an opcode by opcode basis.
>>
>> Certain flow control patterns cannot be implemented efficiently in PHP
>> without using "goto". The current example in Gerrit 708880
>> <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/708880/5/includes/Html.php#545>
>> comes down to:
>>
>> if ( $x == 1 ) {
>>  action1();
>> } else {
>>  action_not_1();
>> }
>> if ( $x == 2 ) {
>>  action2();
>> } else {
>>  action_not_2();
>> }
>>
>> If $x==1 is true, we know that the $x==2 comparison is unnecessary and is
>> a waste of a couple of VM operations.
>>
>> It's not feasible to just duplicate the actions, they are not as simple
>> as portrayed here and splitting them out to a separate function would incur
>> a function call overhead exceeding the proposed benefit.
>>
>> I am proposing
>>
>> if ( $x == 1 ) {
>>  action1();
>>  goto not_2; // avoid unnecessary comparison $x == 2
>> } else {
>>  action_not_1();
>> }
>> if ( $x == 2 ) {
>>  action2();
>> } else {
>>  not_2:
>>  action_not_2();
>> }
>>
>> I'm familiar with the cultivated distaste for goto. Some people are just
>> parotting the textbook or their preferred authority, and others are scarred
>> by experience with other languages such as old BASIC dialects. But I don't
>> think either rationale really holds up to scrutiny.
>>
>> I think goto is often easier to read than workarounds for the lack of
>> goto. For example, maybe you could do the current example with break:
>>
>> do {
>>  do {
>>  if ( $x === 1 ) {
>>  action1();
>>  break;
>>  } else {
>>  action_not_1();
>>  }
>>  if ( $x === 2 ) {
>> 

[Wikitech-l] Re: Stream of recent changes diffs

[Physikerwelt]

Hi all,

thank you for your feedback.

@Roy this is a good point, I honestly did not think about it before.
However, in the back of my mind, I remembered this problem had been
solved before. There is a beta feature called visual diffs.

If you enable this feature and navigate to
https://en.wikipedia.org/w/index.php?title=User:RoySmith/sandbox=revision=1031413484=1031413445=visual

you see the text "math formula changed" this is exactly what I was
looking for. Unfortunately, I was not yet able to figure out if there
is an API to get the visual diffs. I had expected it to be in
RESTbase, but nothing there.

If I can get to that API the problem would be simple enough to start
with the implementation.

All the best
Moritz

On Thu, Jul 1, 2021 at 3:39 PM Amir Sarabadani  wrote:
>
> Note on ORES as one of its maintainers:
> ORES doesn't use recent changes for getting content and scoring edits. It 
> hits the API.
>
> HTH
>
> On Thu, Jul 1, 2021 at 3:18 PM Robin Hood  wrote:
>>
>> I’m no expert, but I believe the only way to get a diff via the API is 
>> through https://www.mediawiki.org/wiki/API:Compare. I haven’t worked with it 
>> to any great degree, though, so I’m afraid I can’t help beyond pointing you 
>> in that direction.
>>
>>
>>
>> From: Physikerwelt 
>> Sent: July 1, 2021 8:17 AM
>> To: Wikimedia developers 
>> Cc: andre.greiner-petter ; Aaron Halfaker 
>> 
>> Subject: [Wikitech-l] Stream of recent changes diffs
>>
>>
>>
>> Dear all,
>>
>>
>>
>> we have developed a tool that is (in some cases) capable of checking if 
>> formulae in -tags in the context of a wikitext fragment are likely to 
>> be correct or not. We would like to test the tool on the recent changes. From
>>
>>
>>
>> https://www.mediawiki.org/wiki/API:Recent_changes_stream
>>
>>
>>
>> we can get the stream of recent changes. However, I did not find a way to 
>> get the diff (either in HTML or Wikitext) to figure out how the content was 
>> changed. The only option I see is to request the revision text manually 
>> additionally. This would be a few unnecessary requests since most of the 
>> changes do not change -tags. I assume that others, i.e., ORES
>>
>>
>>
>> https://www.mediawiki.org/wiki/ORES,
>>
>>
>>
>> compute the diffs anyhow and wonder if there is an easier way to get the 
>> diffs from the recent changes stream without additional requests.
>>
>>
>>
>> All the best
>>
>> Physikerwelt (Moritz Schubotz)
>>
>>
>>
>>
>>
>> ___
>> 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/
>
>
>
> --
> Amir (he/him)
>
> ___
> 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] Stream of recent changes diffs

[Physikerwelt]

Dear all,

we have developed a tool that is (in some cases) capable of checking if
formulae in -tags in the context of a wikitext fragment are likely
to be correct or not. We would like to test the tool on the recent changes.
From

https://www.mediawiki.org/wiki/API:Recent_changes_stream

we can get the stream of recent changes. However, I did not find a way to
get the diff (either in HTML or Wikitext) to figure out how the content was
changed. The only option I see is to request the revision text manually
additionally. This would be a few unnecessary requests since most of the
changes do not change -tags. I assume that others, i.e., ORES

https://www.mediawiki.org/wiki/ORES,

compute the diffs anyhow and wonder if there is an easier way to get the
diffs from the recent changes stream without additional requests.

All the best
Physikerwelt (Moritz Schubotz)
___
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] [Wikitech-ambassadors] Reference Previews will become a default feature on a first group of wikis soon

[Physikerwelt]

Hi Johanna,

since 2019 the Math extension is prepared to offer popups for mathemaical
formulae as well.
Therefore I think it would be good to design the settings dialog in a way
that different kinds of popups can be selected. I could imagine that in the
future more extensions would like to offer popups.


https://phabricator.wikimedia.org/T208758

All the best
Moritz

On Wed, 17 Mar 2021, 10:16 Johanna Strodt, 
wrote:

> Hello Amir, thanks for your questions. Having discussed this back and
> forth in the team, our original plan was to deploy to a few wikis first to
> find out how many users actually don't want a shared setting. But thanks
> to, among other things, the feedback we received over the last
> announcement, we have now come to the conclusion that separate settings
> make more sense. That also means, Reference Previews won't go out of beta
> just yet, but hopefully next month.
>
> @all: If you like the idea of having Reference Previews with a separate
> setting as a default feature on your wiki, please let me know. Having a few
> more wikis for this first step would be great.
>
> Am Di., 16. März 2021 um 12:58 Uhr schrieb Amir E. Aharoni <
> amir.ahar...@mail.huji.ac.il>:
>
>> Why did you decide to do it like this despite requests from multiple
>> people to keep them separated?
>>
>> What are the advantages of unifying them, and why do you think they
>> outweigh the disadvantages?
>>
>> What kind of user reaction can make you change your mind—user complaints,
>> a certain rate of disabling the preference, something else?
>>
>> בתאריך יום ה׳, 11 במרץ 2021, 18:51, מאת Johanna Strodt ‏<
>> johanna.str...@wikimedia.de>:
>>
>>> Hello Mathieu,
>>>
>>> we have received feedback in both directions, both to have a shared
>>> setting and to have separate ones. We would like to start with a shared
>>> setting to see how users actually react.
>>>
>>> Best,
>>> Johanna
>>>
>>> Am Mi., 3. März 2021 um 23:47 Uhr schrieb Mathieu Lovato Stumpf Guntz <
>>> psychosl...@culture-libre.org>:
>>>
 What about grouping them, with specific hidden options by default?

 That is if you opt out the group, both are disabled. If you enable the
 group, you gain the possibility to unfold subcases.

 Also if at some point the list become really too long, you might
 consider an option search filter. Actually, given that we have already more
 options on several tabs than what can be displayed on a confortable desktop
 screen, I think this length limit was already crossed a long time ago.

 Cheers
 Le 03/03/2021 à 12:47, Johanna Strodt a écrit :

 Thanks, Amir!


 *What can people do if they want to see Reference Previews, but not
 Page Previews? *
 Currently, nothing. The plan is to offer both features in combination.
 As for this shared setting, we received different feedback: Some wanted a
 combined setting to keep the number of user settings small, others wanted a
 separate setting. For now, we have decided to go with a shared setting.

 *If an editor currently has the Reference Previews beta feature enabled
 and the Page Previews (Popups) feature disabled, will they get both enabled
 or both disabled after the deployment of the combined feature?*
 The Page Previews user preferences will be respected. In a scenario
 where a user has Page Previews disabled, Reference Previews will also be
 disabled.

 Best,
 Johanna


 Am Mi., 3. März 2021 um 11:31 Uhr schrieb Amir E. Aharoni <
 amir.ahar...@mail.huji.ac.il>:

>
>
> ‫בתאריך יום ד׳, 3 במרץ 2021 ב-11:44 מאת ‪Johanna Strodt‬‏ <‪
> johanna.str...@wikimedia.de‬‏>:‬
>
>> Reference Previews will be combined with Page Previews[2], a feature
>> showing previews for linked articles. Both perform essentially the same
>> function: previewing content before deciding to dig deeper, and easily
>> providing more information while reading. Because of their similarities 
>> in
>> design and behavior, both Page Previews and Reference Previews will be
>> controlled by a single user setting. This means, all users who currently
>> have Page Previews activated, will also get Reference Previews. Also, all
>> readers, anonymous contributors and new users will see Reference Previews
>> per default if they haven’t disabled Page Previews.
>>
>
> What can people do if they want to see Reference Previews, but not
> Page Previews?
>
> If an editor currently has the Reference Previews beta feature enabled
> and the Page Previews (Popups) feature disabled, will they get both 
> enabled
> or both disabled after the deployment of the combined feature?
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>


 --
 Johanna Strodt

[Wikitech-l] Are ResourceLoader modules that bad?

[Physikerwelt]

Dear all,

I am trying to understand the performance impact of adding new
ResourceLoader modules. I am currently stuck in the code review of

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Math/+/638094

as I am not convinced that it is a good idea to bundle an OOUI widget
module and a special page js snippet into one module. One thing is a
general-purpose control that is planned to be used in other contexts
whereas the other is a very specific js code only executed on one
particular special page. However, since this seems to be the critical
point in the code review, I would like to better understand the impact
of the additional resource module call.

I was looking at
https://www.mediawiki.org/wiki/File:ResourceLoader_Client_lifecycle_2020.png
and according to that overview, an additional module is just one entry
in the module registry. I was hoping that minifying and caching is
something the ResourceLoader would take care of.
Any help would be appreciated.

Thank you
physikerwelt

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

Re: [Wikitech-l] Making breaking changes without deprecation?

[Physikerwelt]

Hi Daniel,

I support your proposal.

Re: Ariel
I appreciate your argument, however, I think the deprecation policy
will be used in good faith. Fast deprecations are really helpful for
code that is not been used. If one expects that a feature is used in
hidden code probably people will not depreciate it too fast,
especially if there is a lot of visible code to refactor.

Best
Moritz (physikerwelt)

http://moritzschubotz.de | +49 1578 047 1397

On Fri, Aug 28, 2020 at 9:16 PM Daniel Kinzler  wrote:
>
> Hi Greg, thanks for your reply!
>
> Am 28.08.20 um 18:26 schrieb Greg Rundlett (freephile):
> > I like the idea of streamlining deprecation and avoiding the cost of
> > maintaining obsolete code. I also **want** to publish my code on Gerrit.
>
> Just a quick clarification: while the current policy only considers code to be
> part of the "ecosystem" if it's on gerrit, what I proposed in my mail would 
> mean
> that the Extension could be hosted anywhere, as long as it is public, and has 
> a
>  page on mediawiki.org
>
> --
> Daniel Kinzler
> Principal Software Engineer, Core Platform
> 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] Moving from Gerrit to GitLab

[Physikerwelt]

Hi all,

thank you for this well documented and clearly thought through
decision. Will there be some kind of code review que integrated to the
system or will this stay in phabricator. I mean, the best code review
system does not help if contributed code is not reviewed. I understand
that this is a serious amount of work, but probably investing
resources in doing the code review would be a good complement to the
implementation of a new code review system. For instance

 https://phabricator.wikimedia.org/project/view/4614/

is lists 41/10 incoming tasks. For me, personally that means that I
have not continued developing for several weekends since I am still
waiting for code review. In the long run this is somehow frustrating
since simple adoptions to the new API standards (developed by WMF)
take months and in the end  there is no room for new new features at
all.

All the best

pyhsikerwelt


On Mon, Jul 6, 2020 at 11:56 AM Antoine Musso  wrote:
>
> Le 06/07/2020 à 10:36, Federico Leva (Nemo) a écrit :
> >
> > (I also note that the page references something called "OKR" which was
> > not previously introduced to this list, as far as I know, including a
> > specific line which is not found in any public document. Can we link a
> > definition of what OKR means in the context of WMF, and ideally also
> > some public document containing the referenced line? I suppose it would
> > be some kind of annual or quarterly plan or something like that.)
>
> Hello Federico,
>
> OKR stands for "Objectives and Key Results", it is a management
> framework to keep track of objectives and their achievements (=
> "outcomes").  So that each department, team, individuals plan ambitious
> objectives and resulting outcomes which are assessed at the end of a period.
>
> If I remember properly the concept originates from Intel back in the
> 1980's and has later being adopted by Google which has let them grow
> dramatically. It eventually has spread to the technology scene in the US
> (LinkedIn, Uber etc).
>
> The first occurrence for us is probably the 2015 article which stated
> OKR was mean to be applied for fiscal year 2015 and onward:
> https://www.mediawiki.org/wiki/Wikimedia_Engineering/OKR
>
> Folks will correct me if needed, but I think the framework got formally
> introduced to the whole foundation for fiscal year 2019-2020.
> Previously we had annual and quarterly goals which is essentially the
> same thing: write down what is planned and commit to do it.
>
> You can read a short introduction by Google at:
> https://rework.withgoogle.com/guides/set-goals-with-okrs/steps/introduction/
>
> :)
>
> --
> 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

Re: [Wikitech-l] The end of Hooks::run(): what you need to know

[Physikerwelt]

On Mon, Jun 1, 2020 at 1:44 AM Tim Starling  wrote:
>
> Hooks::run() was soft-deprecated in Nikki Nikkhoui's HookContainer
> patch, merged on April 17. [1] And my patch to remove almost all
> instances of it in MediaWiki Core was finally merged over the weekend.
> [2] That means that everyone writing core code now needs to learn how
> to use the new hook system.
>
> HookContainer is a new service which replaces the functionality which
> was previously in static methods in the Hooks class. HookContainer
> contains a generic run() method which runs a specified hook, analogous
> to Hooks::run(). However, unlike Hooks::run(), you generally should
> not use HookContainer::run() directly. Instead, you call a proxy
> method in a hook runner class.
>
> Hook runner classes give hooks machine-readable parameter names and types.

This sounds really cool. Does this mean can read the parameter names
and types without deep learning;-)

>
>
> How to call a hook
> --
>
> In MediaWiki Core, there are two hook runner classes: HookRunner and
> ApiHookRunner. ApiHookRunner is used in the Action API, and HookRunner
> is used everywhere else.
>
> How you get an instance of HookRunner depends on where you are:
>
> * In classes that use dependency injection, a HookContainer object is
> passed in as a constructor parameter. Then the class creates a local
> HookRunner instance:
>
>   $this->hookRunner = new HookRunner( $hookContainer );
>
> * In big hierarchies like SpecialPage, there are always
> getHookRunner() and getHookContainer() methods which you can use.
>
> * Some classes use the ProtectedHookAccessor trait, which provides
> getHookRunner() and getHookContainer() methods that get their
> HookContainer from the global service locator. You can also call
> MediaWikiServices::getHookContainer() in your own code, if dependency
> injection is not feasible.
>
> * There is a convenience method for static code called
> Hooks::runner(), which returns a HookRunner instance using the global
> HookContainer.
>
> * Extensions should generally not use HookRunner, since the available
> hooks may change without deprecation. Instead, extensions should have
> their own HookRunner class which calls HookContainer::run().
>
> Once you have a HookRunner object, you call the hook by simply calling
> the relevant method.
>
>
> How to add a hook
> -
>
> * Create an interface for the hook. The interface name is always the
> hook name with "Hook" appended. The interface should contain a single
> method, which is the hook name with a prefix of "on". So for example,
> for a hook called MovePage, there will be an interface called
> MovePageHook with a method called onMovePage(). The interface will
> typically be in a "Hook" subnamespace relative to the caller namespace.
>
> * Add an "implements" clause to HookRunner.
>
> * Implement the method in HookRunner.
>
> Note that the name of the interface is currently not enforced by CI.
> Alphabetical sorting of interface names and method names in HookRunner
> is also not enforced. Please be careful to follow existing conventions.
>
>
> How to deprecate a hook
> ---
>
> Hooks were previously deprecated by passing options to Hook::run().
> They are now deprecated globally by adding the hook to an array in the
> DeprecatedHooks class.
>
>
> Using the new system in extensions
> --
>
> Extensions should create their own HookRunner classes and use them to
> call hooks. HookContainer::run() should be used instead of Hooks::run().
>
> As for handling hooks, I think it's too early for a mass migration of
> extensions to the new registration system as described in the RFC.[3]
> Extension authors who are keen to pilot the new system can give it a
> go. Make sure you add Nikki and me as reviewers.
>
> More information about the new system can be found in docs/Hooks.md
> [4]. The patch to add it should soon be merged.
>
>
> [1] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/571297
> [2] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/581225
> [3] https://phabricator.wikimedia.org/T240307
> [4]
> 
>
> -- Tim Starling
>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

Re: [Wikitech-l] Vote on the futre \omicron in Wikipedia until April 4th

[Physikerwelt]

Dear all,

there was not much engagement in this discussion, but there is a
preference for option A, thus I will implement that.

Best
physikerwelt

http://moritzschubotz.de | +49 1578 047 1397

On Sat, Mar 21, 2020 at 7:26 PM Physikerwelt  wrote:
>
> Dear all,
>
> please vote on the future of the \omicron rendering on Wikipedia, by
> replying to this email or commenting on
> https://phabricator.wikimedia.org/T245343 (preferred).
>
> Best regards
> Moritz

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

Re: [Wikitech-l] New, simple Docker development environment for MediaWiki core

[Physikerwelt]

This is great news. I was hoping for something like that for years.
I will see if I can align my provisional MediaWiki docker environment [1]
with your work.
Thanks a lot and keep on going with this great work.

Physikerwelt
[1] https://github.com/physikerwelt/mediawiki-docker


On Mon, Feb 24, 2020 at 5:44 PM Brennen Bearnes 
wrote:

> Hey all,
>
> TL;DR: `docker-compose up` gets you a Docker environment with which
> to develop.
>
> The Engineering Productivity group is happy to announce the
> availability of a new, official Docker environment for MediaWiki
> core. [0] This is a component of our work on improving developer
> productivity, as part of the Wikimedia Foundation's "Platform
> Evolution" [1] multi-year priority, looking to support faster, more
> reliable technical change for our communities. We've been exploring
> options for a year now, and we had a great deal of input,
> particularly at the TechConf 2019, where Kosta Harlan worked
> closely with us to move this forward. [2]
>
> This new environment has been built for simple experimentation,
> development, and testing of proposed changes to MediaWiki core. It
> is designed to be particularly simple and easy to use, and intended
> particularly to be a good option for newbies, be they testers,
> designers, developers, or others who have not yet invested a great
> deal of their time in setting up local environments.
>
> We intend for this environment to become the official, supported,
> and advertised entry point for small-scale development. If you find
> issues, or have suggestions for improvements, we'd love to hear
> from you. [3] We will be adjusting various bits of documentation
> over time to encourage futher use, but if you find some out-of-date
> instructions, please do fix them, or flag for us to do.
>
> We know that there are number of people who need a more complex,
> configurable, and powerful development and testing environment,
> even up to being a "Wikimedia production-like" state. This is not
> that environment; we plan to provide a more configurable and thus
> more complex, "heavy-weight" alternative for that use case in the
> future. You may wish to follow our work in Phabricator. [4]
>
> Our huge thanks to pioneering volunteer and staff colleagues who
> have provided support, testing, and advice, and who have explored
> different uses of Vagrant, Docker, and other techniques for
> providing better forms of MediaWiki testing, development, and
> hosting, which have inspired us on how to best provide this.  We
> all owe you a great debt. Thank you.
>
> Again, if you have questions, comments, or concerns, please do file
> a task so that we can help you! [3]
>
> [0] - https://www.mediawiki.org/wiki/Docker
> [1] -
>
> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Medium-term_plan_2019/Platform_evolution
> [2] - https://phabricator.wikimedia.org/T238224
> [3] - https://phabricator.wikimedia.org/tag/mediawiki-docker/
> [4] - https://phabricator.wikimedia.org/tag/local-charts/
>
> Yours,
>
> --
> Brennen Bearnes (he/him)
> WMF Release 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] Math at the Wikimedia Technical Conference 2019

[Physikerwelt]

Dear all,

a minor update on hyperlinks in formulae~[1]:
The demo on the beta cluster works quite well.
There is just one minor problem~[2], which seems to a problem within
wikibase, which will hopefully be resolved as wikibase improves
without any changes to the Math extension codebase.

As a next step, we will enable the feature by default~[3]. This will
have no impact as the qid-attribute is not set on any formulae in
production wikis currently.

While we were hoping that the change to the popup extension that André
contributed would be merged, we will need to plan more time to discuss
this change with the maintainer of the popups extension. However, a
first step was successful, and we could identify who is responsible
for the popups extension~[4].

Any feedback or suggestions are highly appreciated.

All the best
Moritz (physikerwelt)

[1]: https://phabricator.wikimedia.org/T208758
[2]: https://phabricator.wikimedia.org/T229939
[3]: https://phabricator.wikimedia.org/T239356
[4]: https://phabricator.wikimedia.org/T239357#5738927

http://moritzschubotz.de | +49 1578 047 1397

On Sat, Nov 16, 2019 at 8:00 PM Physikerwelt  wrote:
>
> Hi all,
>
> I was happy to be invited by the Wikimedia Foundation to the Wikimedia
> Technical Conference 2019 in Atlanta~[1]. At this conference, I represented
> the technical needs of the mathematical community~[2]. Apart from a lot of
> great achievements for the whole Wikimedia movement with regard to the five
> focus areas of the conference~[3], there were also several math-specific
> achievements. In this message, I will focus on those aspects:
>
> 1) Bold italic capital greek symbols are now possible. Please join me in
> thanking Petr Kadlec (aka. Mormegil) for his perennial effort to make this
> possible~[4].
>
> 2) We will - very soon - have a demo on the Wikimedia beta cluster enabling
> links from formulae to a dedicated special page that displays definitions and
> explanations regarding mathematical objects of interest, i.e., identifiers,
> symbols, terms. Thank you André Greiner-Petter for the implementation of this
> feature~[5].
>
> 3) In a session on 'Integrating contributions from other teams or volunteers`
> organized by Christoph Jauera (aka. Fisch). We derived definitive action items
> on improving the participation opportunities to the Math on wikis~[6].
>
> 4) We discussed the future of Math rendering with Petr Pchelko (WMF) which
> will simplify the setup of mathoid and eventually get rid of fallback images
> while maintaining support for MathML disabled browsers~[7].
>
> I am grateful to the Wikimedia Foundation and the organizers of the event, in
> particular, Rachel and Greg to get the chance to enjoy this well-organized
> conference with amazing people and a wonderful program.
>
> All the best
> Moritz (physikerwelt)
>
> http://moritzschubotz.de | +49 1578 047 1397
>
>
> [1]:https://www.mediawiki.org/wiki/Wikimedia_Technical_Conference/2019
> [2]:https://meta.wikimedia.org/wiki/Wikimedia_Community_User_Group_Math
> [3]:https://phabricator.wikimedia.org/T238406
> [4]:https://phabricator.wikimedia.org/T218295
> [5]:https://phabricator.wikimedia.org/T208758
> [6]:https://phabricator.wikimedia.org/T234662#5660102
> [7]:https://phabricator.wikimedia.org/T237516
>
> Some more details on item 4, from my personal, biased perspective:
>
> I started working on the Math extension in 2012 and implemented the
> main functionality
> of the new rendering method which is based on MathJax rather
> than on LaTeX in 2013 at the Wikimedia Foundations Headquarter in San
> Francisco. At that time the vision was to replace the monolithic PHP based
> framework MediaWiki, with a large number of small dynamic JavaScript modules.
> The idea was that those modules are developed as isomorphic 
> platform-independent
> components using interfaces of a management framework that takes
> care of caching and efficient execution. The long-term goal was that the
> functionality could be executed either on the client or on the server and that
> the management layer would figure out the best execution strategy based on the
> current prerequisites. In the first step, a framework based on HTTP requests 
> was
> set up to handle services such as math rendering. Mathoid the math rendering
> service was one of the first instances of this service template. From the
> retro perspective that might have been too early. Neither a convenient type 
> and
> schema description language existed, nor a way to specify rich metadata on the
> execution characteristics existed. However, a fine-grained I/O schema seems
> desirable for implementing robust and durable services. Moreover, rich
> metadata on the execution characteristics such as runtime, memory footprint,
> I/O data distributions

[Wikitech-l] Math at the Wikimedia Technical Conference 2019

[Physikerwelt]

Hi all,

I was happy to be invited by the Wikimedia Foundation to the Wikimedia
Technical Conference 2019 in Atlanta~[1]. At this conference, I represented
the technical needs of the mathematical community~[2]. Apart from a lot of
great achievements for the whole Wikimedia movement with regard to the five
focus areas of the conference~[3], there were also several math-specific
achievements. In this message, I will focus on those aspects:

1) Bold italic capital greek symbols are now possible. Please join me in
thanking Petr Kadlec (aka. Mormegil) for his perennial effort to make this
possible~[4].

2) We will - very soon - have a demo on the Wikimedia beta cluster enabling
links from formulae to a dedicated special page that displays definitions and
explanations regarding mathematical objects of interest, i.e., identifiers,
symbols, terms. Thank you André Greiner-Petter for the implementation of this
feature~[5].

3) In a session on 'Integrating contributions from other teams or volunteers`
organized by Christoph Jauera (aka. Fisch). We derived definitive action items
on improving the participation opportunities to the Math on wikis~[6].

4) We discussed the future of Math rendering with Petr Pchelko (WMF) which
will simplify the setup of mathoid and eventually get rid of fallback images
while maintaining support for MathML disabled browsers~[7].

I am grateful to the Wikimedia Foundation and the organizers of the event, in
particular, Rachel and Greg to get the chance to enjoy this well-organized
conference with amazing people and a wonderful program.

All the best
Moritz (physikerwelt)

http://moritzschubotz.de | +49 1578 047 1397


[1]:https://www.mediawiki.org/wiki/Wikimedia_Technical_Conference/2019
[2]:https://meta.wikimedia.org/wiki/Wikimedia_Community_User_Group_Math
[3]:https://phabricator.wikimedia.org/T238406
[4]:https://phabricator.wikimedia.org/T218295
[5]:https://phabricator.wikimedia.org/T208758
[6]:https://phabricator.wikimedia.org/T234662#5660102
[7]:https://phabricator.wikimedia.org/T237516

Some more details on item 4, from my personal, biased perspective:

I started working on the Math extension in 2012 and implemented the
main functionality
of the new rendering method which is based on MathJax rather
than on LaTeX in 2013 at the Wikimedia Foundations Headquarter in San
Francisco. At that time the vision was to replace the monolithic PHP based
framework MediaWiki, with a large number of small dynamic JavaScript modules.
The idea was that those modules are developed as isomorphic platform-independent
components using interfaces of a management framework that takes
care of caching and efficient execution. The long-term goal was that the
functionality could be executed either on the client or on the server and that
the management layer would figure out the best execution strategy based on the
current prerequisites. In the first step, a framework based on HTTP requests was
set up to handle services such as math rendering. Mathoid the math rendering
service was one of the first instances of this service template. From the
retro perspective that might have been too early. Neither a convenient type and
schema description language existed, nor a way to specify rich metadata on the
execution characteristics existed. However, a fine-grained I/O schema seems
desirable for implementing robust and durable services. Moreover, rich
metadata on the execution characteristics such as runtime, memory footprint,
I/O data distributions seem required to allow an execution management layer
for effective execution strategy planning. After the services went into
production schema improvement was difficult and never happened.

Today, it seems pretty certain that MediaWiki will be PHP based for the
foreseeable future. Given this situation, we did now plan to improve Math
support by making the best use of the build-in MediaWiki core functionality. We
will rely on the MediaWiki core caching functionality to continue providing an
instant user perception of math rendering and continue using a stateless
node-based math rendering service. Our hope is that by incorporating the 'new`
MathJax 3 rendering mode 'common HTML` also MathML disabled browsers will be
able to display high-quality mathematical formulae without to rely on
disturbing images. We plan to enable this rendering mode as opt-in in a first
step and thereafter have a community vote if the new imageless rendering mode
should become the default. If that won't work, we will need to
evaluate inline SVG
images that would require either SVG or JavaScript support on the client.
Given the situation that only a very small number of visitors use browsers
that neither support SVG images nor allow JavaScript this second alternative
seems to an ethical option as well.

I will update the associated ticket phabricator ticket~[7] as soon as we have
derived a more detailed plan for the implementation.

___
Wikitech-l mailing list

[Wikitech-l] Fwd: MathML Refresh

[Physikerwelt]

Hi all,

just for your information: An update about the upcoming improvement in
the MathML implementation in Firefox and the new implementation in
Chromium.

Best
physikerwelt


-- Forwarded message -
From: Frédéric Wang 
Date: Fri, Mar 15, 2019 at 11:35 AM
Subject: MathML Refresh Heads up
To: 


Hello Mozilla developers,

As some of you may know, Igalia is working on MathML support in Chromium
this year [1]. As part of that effort we joined a new MathML Refresh
Community Group [2] and one goal is to focus on a core spec for browser
implementations [3] to:
- Remove deprecated/uncommon/duplicate math features that could be
implemented by polyfills (relying on MathML core and other web
technologies).
- Add more detailed algorithms (based on TeX/OpenType/CSS layout) to
help implementation and conformance testing.
- Align MathML with CSS/HTML (parsing, layout...), introducing new web
platform features (CSS, fonts...) for math if necessary.

We expect that this effort will improve browser interoperability and
reduce complexity of current implementations.

This is just a heads up to say that some work is likely to happen to
update/remove/add MathML features. The appropriate "Intents" will be
sent later to these mailing lists.

Frédéric and Rob,

[1] https://mathml.igalia.com/
[2] https://mathml-refresh.github.io/
[3] https://mathml-refresh.github.io/mathml-core/

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

Re: [Wikitech-l] New Gerrit privilege policy

[Physikerwelt]

On Wed, Mar 13, 2019 at 5:25 AM Tim Starling  wrote:
>
> Following approval by TechCom and WMF Interim CTO Erika Bjune, I've
> moved the new Gerrit privilege policy page out of my userspace to
>
> https://www.mediawiki.org/wiki/Gerrit/Privilege_policy
>
> This is a merge of two pages: [[Gerrit/+2]] and [[Gerrit/Project
> ownership]], with some additional changes. I've now redirected both of
> those pages to the new policy page.
>
> The main changes are:
>
> * The wmde LDAP group, representing WMDE staff members, will be given
> +2 access to mediawiki/* projects, similar to the rights given to WMF
> staff members.

Great. This is the first step towards a global movement;-)

>
> * The ability of ShoutWiki and Hallo Welt! to manage access to the
> extensions they maintain is described and formalised.
>
> * The ownership model for extensions is discouraged in favour of
> individual requests on Phabricator. An extension owner was able to
> promote developers to +2 access at their own discretion.

I think this does not harm too much since many people use Microsofts
GitHub to maintain their non-WMF deployed extensions these days.


Physikerwelt

>
> * The Phabricator projects for requesting access have changed. I'm in
> the process of moving the tickets over.
>
> * The revocation policy has been expanded, better describing the
> present situation and making several minor changes.
>
> -- Tim Starling
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

[Physikerwelt]

I suggest discussing the implementation details on phabricator.
Moreover, I second Lucas point on the tone.
physikerwelt
https://www.mediawiki.org/wiki/Code_of_Conduct

physikerwelt
https://www.mediawiki.org/wiki/Code_of_Conduct

On Tue, Jan 22, 2019 at 1:43 PM Lucas Werkmeister
 wrote:
>
> Am Di., 22. Jan. 2019 um 13:25 Uhr schrieb Chad :
>
> > Dumb straw man.
> >
>
> can we avoid this tone? thanks
>
> Who said these people have too much workload?
>
>
> Um, Thiemo himself has said this? Are you going to tell him that he’s wrong
> about his own workload?
>
> The blame attribution has zero insight into how
> > busy someone is.
> >
>
> Correct, which is why it’s a bad idea to let it run loose and add people
> who are already busy enough as reviewers.
>
>
> > If it's a low-traffic repository there's likely to be fewer overall
> > contributors.
> > Fewer contributors increases the likelihood of people being qualified to
> > review--whereas a high-traffic repo is more likely to have drive-by
> > contributor less capable.
> >
>
> Well, many drive-by contributions are tree-wide: they are applied to a
> large set of repositories collectively, e. g. all Wikimedia-deployed
> extensions or even all repositories. If a repository has generally low
> traffic, then these tree-wide drive-by contributions will make up a larger
> ratio of its commits than in repositories with more repository-specific
> commits.
>
> I’m not sure if I phrased this well, but if repository A has 1000 specific
> commits and 10 drive-by commits, and repository B has 20 specific commits
> and the same 10 drive-by commits, then the drive-by commits will be ⅓ of
> all commits in repository B but less than .1% in repository A.
>
>
> > And if it's just one-line typofixing it'd be ideal to exclude those from
> > the
> > blame list--but we can't possibly know what was a one-line typofix and
> > what was a one line that saved us 50% of execution time on all pages.
> > At least not programmatically.
> >
>
> True to some extent, but then we should err on the side of not adding the
> reviewer, no? Otherwise we run the risk of overwhelming them with changes
> they’re not even qualified to review, even if they had the time.
>
>
> > Honestly, if you think "people who've edited the code in the past" are a
> > poor
> > person to ask for review then you do not understand how code review works.
> >
>
> Suggesting that Thiemo doesn’t understand how code review works is… bold,
> in my opinion, let’s put it that way. May I point out that he’s one of the
> top +2ers across all MediaWiki extensions
> <https://lists.wikimedia.org/pipermail/wikitech-l/2019-January/091340.html>?
>
> Cheers,
> Lucas
>
>
> --
> Lucas Werkmeister
> Full Stack Developer
>
> Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
> Phone: +49 (0)30 219 158 26-0
> https://wikimedia.de
>
> Imagine a world in which every single human being can freely share in the
> sum of all knowledge. Help us to achieve our vision!
> https://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.
> ___
> 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] [Engineering] Gerrit now automatically adds reviewers

[Physikerwelt]

Hi Thiemo, hi all,

given my strong support for T78768 and the connection to this change,
I would like to express my regrets to the engineers blocked by the
change in Gerrit. As typical for strike actions, it disrupts the usual
business. However, I see the positive effect that people are made
aware of the fact that the code review process needs to be improved.

While I am happy with the code review duration of the patches I submit
today, I had problems to get the (obviously bad) code I wrote in the
beginning reviewed. I guess one of the main reasons for the
improvement is that I know the reviewers in person, today.

However, visiting Hackathons and annoying WMF employees in their
offices is not something that scales. Therefore, the review process
needs to be changed. After years of discussion and only little changes
to the process, this change brings this important but not urgent topic
to the agenda, which I appreciate.

To my experience Thiemo ist one of the most predictable (=good) code
reviewers. I am more than happy that he shared his process in his
email. I think his code reviewing procedure is exemplary and should
act as a general template. Thank you Thiemo.

One last hopefully constructive point. To my experience, the most
annoying experience in waiting for CR is when multiple reviewers are
requested and no feedback is provided. My wish would be that the state
of the patch is visualized in the (Gerrit) UI. So that the submitter
of the patch knows the state of the change and can estimate how long
it might take until the patch proceeds to the next stage.

Happy coding
physikerwelt


On Fri, Jan 18, 2019 at 1:25 PM MA  wrote:
>
> Hello,
>
> I agree with what Giuseppe Lavagetto and Jaime Crespo said.
>
> In my case, I am now getting review requests from several repos I
> contributed some time in the past, but for which I'm not a qualified
> reviewer. The plugin is also adding bots to review changes such as in
> <https://gerrit.wikimedia.org/r/485174>.
>
> While I think it is certainly a good idea to help people find
> reviewers for their patches, I feel this plugin as it is now is going
> to achieve the contrary (mail blindness due to too many emails).
>
> I suggest we disable the plugin until at least Paladox's blacklist
> could be implemented and so we are given the choice to opt-out from
> it.
>
> Thank you, M.
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

Re: [Wikitech-l] Fwd: My Phabricator account has been disabled

[Physikerwelt]

Hi!

I do support the CoC. There is a trade-off between being inclusive and
enforcing a CoC (that is implicitly based on a US-German concordance
of cultural norms).

I share the vision of the Wikimedia movement and I want to contribute
towards the goals. To do that a reasonable pleasant working
environment is required. That's why I argue that we need to enforce
the CoC, even though it might be unfair for a minority. While there in
improvement potential for the yet novel CoC procedures, as outlined in
this email thread, I want to use this opportunity to thank the CoC
committee for their great work.

While I chose to donate time rather than money (to pay WMDE or WMF
employes), I still don't understand why the difference between being a
volunteer developer or staff matters to this discussion. I would love
to be enlighted why the division in staff and volunteers is
constructive.

Best
physikerwelt (Moritz Schubotz)

Disclaimer: Although I do not work for the Wikimedia Foundation,
contributions under this account often represent the actions or views
of the Foundation. For example, edits to articles or uploads of other
media are done in my individual, personal capacity but share the
intend;-).

On Thu, Aug 9, 2018 at 8:11 AM, Stas Malyshev  wrote:
> Hi!
>
> On 8/8/18 1:58 PM, bawolff wrote:
>> On Wed, Aug 8, 2018 at 8:29 PM, Amir Ladsgroup  wrote:
>> [...]
>>> 2) the duration of block which is for one week was determined and
>>> communicated in the email. You can check the email as it's public now.
>>
>> Can you be more specific? I'm not sure I see where this is public.
>
> I think it's this one:
> https://lists.wikimedia.org/pipermail/wikitech-l/2018-August/090490.html
>
> --
> 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

[Wikitech-l] Installing the MediaWiki Math extension is easier now

[Physikerwelt]

In the past, administrators of MediaWiki installations faced a
challenging installation procedure when they tried to enable rendering
of mathematical formulae. As of February 22, no configuration or
custom installation is required with the latest versions of MediaWiki
core and the Math extension, if your wiki is connected to the
internet.

This is how it’s done:
For wikis connected to the internet: Simply download the latest
versions for both of Mediawiki core [1] and the Math extension [2] and
that's it. The latest version can be obtained by selecting “master” in
the extension distributor.

For wikis not connected to the internet:
Download the latest version of Mediawiki core [1] and the Math extension [2].
Install the node module mathoid [4]. We recommend using Node version 8
LTS [5], if node.js is not installed on the server. Mathoid can be
installed to any location of your server that is accessible to the web
server. For instance, in the location of the Math extension.
After having installed and tested (e.g., by running npm test) the
mathoid installation, point your MediaWiki to this location by adding
the following config to your LocalSettings.php file:

$wgMathoidCli = ['/srv/mathoid/cli.js', '-c', '/srv/mathoid/config.dev.yaml'];

Replace /srv/mathoid with the location of your mathoid installation
and run update.php [6].

If you have any issues with the installation, please file a
phabricator ticket using the following link
https://phabricator.wikimedia.org/maniphest/task/create/?projects=MediaWiki-extensions-Math


Links and further reading:
[1] https://www.mediawiki.org/wiki/Download_from_Git
[2] Documentation of the Math extension
https://www.mediawiki.org/wiki/Extension:Math**
[3] Extension distributor
https://www.mediawiki.org/wiki/Special:ExtensionDistributor/Math
[4] Mathoid node package https://www.npmjs.com/package/mathoid
[5] Node homepage https://nodejs.org/en/
[6] How to run the database update
https://www.mediawiki.org/wiki/Manual:Update.php

Scientific Paper: Moritz Schubotz, Gabriel Wicke: Mathoid: Robust,
Scalable, Fast and Accessible Math Rendering for Wikipedia. CICM 2014:
224-235 https://arxiv.org/pdf/1404.6179.pdf

Required versions:
* For offline Math rendering MediaWiki core must include patch
https://gerrit.wikimedia.org/r/#/c/399768/
** The math extension must include patch
https://gerrit.wikimedia.org/r/#/c/372100/

--
Moritz Schubotz
Researcher

isg.uni-konstanz.de/people/moritz-schubotz
+49 1578 047 1397

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