[Wikitech-l] Invitation: Tech Debt SIG - Session C - IRC only @ Wed Oct 4, 2017 09:00 - 09:50 (PDT) (wikitech-l@lists.wikimedia.org)

[jbranaa]

You have been invited to the following event.

Title: Tech Debt SIG - Session C - IRC only
Wiki page:

https://www.mediawiki.org/wiki/Technical_Debt_SIG

Hello All,

This is Technical Debt SIG session C - IRC only

Logistics will be sent out by early next week.

Feel free to take a look at the notes from prior sessions.  They are  
available at:


https://www.mediawiki.org/wiki/Technical_Debt_SIG

Cheers,

JR
When: Wed Oct 4, 2017 09:00 – 09:50 Pacific Time
Video call: https://plus.google.com/hangouts/_/wikimedia.org/jbranaa  


Calendar: wikitech-l@lists.wikimedia.org
Who:
* jbra...@wikimedia.org - organizer
* Kunal Mehta
* tech-all
* wikitech-l@lists.wikimedia.org
* Product

Event details:  
https://www.google.com/calendar/event?action=VIEW=MWFpc2FnNG5qYTY4YnYyc25maGlqbzkzb28gd2lraXRlY2gtbEBsaXN0cy53aWtpbWVkaWEub3Jn=MjEjamJyYW5hYUB3aWtpbWVkaWEub3JnNjZlZDc1OTE2NTg0MzkzYmVjN2ViZjRiMzFhMDJiMmYzNmQ2MGE3MQ=America/Los_Angeles=en


Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account  
wikitech-l@lists.wikimedia.org because you are an attendee of this event.


To stop receiving future updates for this event, decline this event.  
Alternatively you can sign up for a Google account at  
https://www.google.com/calendar/ and control your notification settings for  
your entire calendar.


Forwarding this invitation could allow any recipient to modify your RSVP  
response. Learn more at  
https://support.google.com/calendar/answer/37135#forwarding

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

[Wikitech-l] Regarding Project: Grant - Automatic suggestion of topics to drafts

[Sumit Asthana]

Hi all,

This is a general notification regarding the project "Automatic
suggestion of topics to drafts" which aims to develop a model to
automatically predict WikiProject based topics to new drafts on
English Wikipedia.

Anyone who's interested in it or would like to do a review or add
thoughts, feel free to look at the project page and leave comments.

-With Warm Regards
Sumit Asthana

[0] - 
https://meta.wikimedia.org/wiki/Grants:Project/Sumit/Automatic_suggestion_of_topics_to_drafts

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

Re: [Wikitech-l] Be bold with code changes

[Tom Bishop, Wenlin Institute]

Thanks to Brian for the thoughtful response, even though it's discouraging! 
Maybe this is the video referred to:

https://www.youtube.com/watch?v=RfJDDn--8lY

It's linked to these notes:

https://phabricator.wikimedia.org/T114419

There are suggestions that each part of the code should be "owned" by a 
particular individual or group, who would have an obligation to accept or 
reject patches in a timely fashion.

Maybe a group of "evaluators" should each be called on to evaluate each patch 
on multiple dimensions (security, correctness, style, efficiency, ...), and 
then there should be an algorithm for converting those evaluations into a 
decision to accept or reject the patch within some time limit. That way nobody 
has to take all the blame. There could be a veto power. The algorithm could 
evolve over time. Evaluators could get credit for making evaluations. Each 
evaluator could skip some evaluations, or answer "didn't have time to study" on 
some dimensions. A consistent lack of time might render someone unsuitable for 
the role of evaluator. A rejected patch would at least get a list of reasons, 
such as "too few evaluators had time to study it" or "too many evaluators 
labeled it as an unacceptable security risk".

Tom

> On Sep 21, 2017, at 7:21 PM, Brian Wolff  wrote:
> 
> Code review latency is a complicated issue which a lot has been said about.
> It was a subject of a session at the last 2 dev summits (im not sure if the
> last one was recorded, but there is definitely a video of the session from
> the dev summit two years ago, on commons). It was an issue i used to care
> very much about when it highly affected me, but now that my role shifted so
> im less affected, i notice it much less and thus tend to forget about it
> (unfortunately). My personal opinion is it is a structural problem of both
> the wikimedia foundation and the mediawiki community, and it wont change
> unless deep changes are made in our processes and expectations.
> 
> In any case, as far as (4) goes, id hope that is already the case. I
> usually just do a quick glance and rapid approve if the change does not
> involve code changes. If you are aware of any trivial (non code changes)
> that are languishing in review, please mention them on #mediawiki or
> #wikimedia-dev and they should be taken care of right away.
> 
> --
> bawolff
> 
> On Thursday, September 21, 2017, Tom Bishop, Wenlin Institute <
> tan...@wenlin.com> wrote:
>> Wikipedia is the greatest encyclopedia in the world, due in large part to
> its openness, including its "be bold" policy:
>> 
>>https://en.wikipedia.org/wiki/Wikipedia:Be_bold
>> 
>> The MediaWiki code is also great, and has a lot of room for improvement,
> which will happen faster if code changes are treated more like wiki content
> changes. While anyone can edit Wikipedia content, only a relatively small
> group has authorization to approve MediaWiki code changes. This difference
> may be partly justified, supposing that code changes can do more harm than
> content changes. Still, there appears to be a problematic bottleneck.
> Efforts to improve the code are wasted when users submit patches that just
> sit and rot without being approved or rejected. I've seen this: a bug is
> found and reported; a patch is submitted; nothing happens for a year and a
> half; the patch gets out of date, then gets updated and submitted by
> another programmer; several months later nothing has happened. Unless this
> is a rare exception, problems like it seem bound to result in a lot of
> wasted effort, and in programmers deciding not to risk wasting further
> effort.
>> 
>> Maybe the authorized group is too small and can't keep up with the
> patches. Maybe the group is too cautious, either to authorize or reject
> patches, or to invite more people to join it.
>> 
>> How about a policy to be bolder with code changes? Possible ways: (1)
> enlarge the authorized group; (2) encourage the group to approve more
> changes; (3) enable more kinds of approval, such as "I haven't had time to
> test this patch or study it very carefully, but at least I've read it and
> I'm fairly sure it's not malicious or a security risk"; (4) be especially
> quick to approve patches that only change comments or variable names,
> without affecting code execution, since their potential harm is minimal,
> analogous to editing wiki content.
>> 
>> Understandably, nobody wants to be blamed for letting someone into the
> authorized group who turns out to have bad judgment. If the group
> nevertheless really needs to be enlarged, how can it become bolder about
> letting people in? Similarly, nobody wants to be blamed for approving a
> patch that turns out to cause a new bug, especially if the penalty for one
> such mistake might outweigh the rewards for approving many beneficial
> patches. How about increasing the rewards and decreasing the penalties?
> What signs of appreciation do the gatekeepers 

[Wikitech-l] Disabling Messaging Fallbacks for Language Analysis

[Trey Jones]

SUMMARY: The Search Platform team (formerly part of Discovery) is planning
to fix a long-standing search bug on many wiki projects by disabling the
code in CirrusSearch that re-uses the “fallback” languages (which are
specified for user interface or system messages) for the language analysis
modules (which are used to index words in search). Deployment is planned to
start the week of October 9, 2017.

Messaging fallbacks specify what language to show a message in when there
is no message available in the language of a given wiki. A language
analysis module is language-specific software that processes text to
improve searching—so that, for example, searching for a given word will
find related forms of that word, like "hope, hopes, hoping, hoped" or
"resume, resumé, résumé" on English-language wikis.

Fallback languages for system messages make sense for historical and
cultural reasons—a reader of the Chechen Wikipedia is more likely to
understand a user interface or system message in Russian than in French,
Greek, Hindi, Italian, or Japanese—but the fallbacks don't necessarily make
any linguistic sense. Chechen and Russian, for example, are from unrelated
language families; while the languages have undoubtedly influenced one
another, their grammars are completed different.

We will deploy the software change that disables using messaging fallbacks
for language analysis fallbacks in about two weeks (targeting the week of
October 9, 2017), with any cross-language analysis exceptions explicitly
configured in a new manner. Changes will not immediately happen to all
affected wikis because each wiki in each language will need to be
re-indexed, which is a separate process that takes time. There may also be
other delays caused by Elasticsearch upgrades or other changes that need
immediate attention.

You can also track progress of the tasks on Phabricator[1] or read more,
see examples, and get the full list of languages affected on MediaWiki.[2]

[1] https://phabricator.wikimedia.org/T147959

[2]
https://www.mediawiki.org/wiki/Wikimedia_Discovery/Disabling_Messaging_Fallbacks_for_Language_Analysis

Trey Jones
Sr. Software Engineer, Search Platform
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Is there a way to gather contextual clues about the specific template call which led to a scribunto module execution?

[Brad Jorsch (Anomie)]

On Tue, Sep 26, 2017 at 4:01 AM, mathieu stumpf guntz <
psychosl...@culture-libre.org> wrote:

> Here is what I mean with a simple use case
>
> ```
>
> == Section 1 ==
>
> Some text.
>
> Hello, we are in {{section}}, leading paragraph is
> {{paragraph|1|{{section.
>
>
> == Section 2 ==
>
> Some other text.
>
> Hello, we are in {{section}}, leading paragraph is
> {{paragraph|1|{{section.
>
> ```
>
> And each call should generate respectively something like
>
>Hello, we are in Section 1, leading paragraph is "Some text.".
>
>Hello, we are in Section 2, leading paragraph is "Some other text.".
>
> So, basically the idea is to let the module infers parameters from the
> calling context, rather than
> always make them explicit.
>

No, there is no simple way to do this.[2] Doing so would probably be a
violation of T67258.[1]

[1]: https://phabricator.wikimedia.org/T67258
[2]: There's a completely insane way to do something like it in some
limited cases, but per w:en:WP:BEANS

I think I'll not go into details.

-- 
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] Looking for advice for structuring data module with redundant entries

[Brad Jorsch (Anomie)]

On Tue, Sep 26, 2017 at 3:25 AM, mathieu stumpf guntz <
psychosl...@culture-libre.org> wrote:

> So in Lua, as far as I can say, there is no way to express directly
> something like `a = {b=1, c=a.b}`.
>

Well, if your data is read-only you could do `a = { b = 1 }; a.c = a.b`.


> Moreover, `a.c = 2` should lead to a state where `a.b == a.c and a.b == 2`
>

For that you'll probably want to use a metatable[1] with __index and
__newindex methods that map them both to the same key.

I note that neither metatables nor function accessors will work for data
modules loaded with mw.loadData(), but since assignment doesn't work with
them either that doesn't really matter.

[1]:
https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual#Metatables


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Tomorrow: Weekly Technical Advice IRC Meeting

[Michael Schönitzer]

Sorry for cross-posting!

Reminder: Technical Advice IRC meeting again **tomorrow 3-4 pm UTC** on
#wikimedia-tech.

The Technical Advice IRC meeting is open for all volunteer developers,
topics and questions. This can be anything from "how to get started" over
"who would be the best contact for X" to specific questions on your project.

If you know already what you would like to discuss or ask, please add your
topic to the next meeting: https://www.mediawiki
.org/wiki/Technical_Advice_IRC_Meeting

This meeting is an offer by WMDE’s tech team. Hosts of todays meeting are:
@addshore & @CFisch_WMDE.


Hope to see you there!
Michi (for WMDE’s tech team)

-- 
Michael F. Schönitzer



Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
http://wikimedia.de

Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen
Wissens frei teilhaben kann. Helfen Sie uns dabei!
http://spenden.wikimedia.de/

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Question Pertaining to the "stats.grok.se" Page Containing Pre-2015 Page-View Data

[Andrew Otto]

That thread links to
https://meta.wikimedia.org/wiki/Community_Tech/Pageview_stats_tool, which
has some good info about the history and status.

On Mon, Sep 25, 2017 at 5:22 PM, Toby Negrin  wrote:

> Hi Karl, Daniel --
>
> Erik doesn't support stats.grok.se.
>
> There's some information on the reliability of stats.grok.se and
> alternatives on this thread on the analytics list:
>
> https://lists.wikimedia.org/pipermail/analytics/2017-August/005978.html
>
> good luck!
>
> -Toby
>
> On Mon, Sep 25, 2017 at 2:10 PM, Daniel Zahn  wrote:
>
> > Karl, you should probably ask Erik Zachte about grok.se
> >
> > https://www.wired.com/2013/12/erik-zachte-wikistats/
> >
> > https://en.wikipedia.org/wiki/User:Erik_Zachte
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Is there a way to gather contextual clues about the specific template call which led to a scribunto module execution?

[mathieu stumpf guntz]

Here is what I mean with a simple use case

```

== Section 1 ==

Some text.

Hello, we are in {{section}}, leading paragraph is 
{{paragraph|1|{{section.



== Section 2 ==

Some other text.

Hello, we are in {{section}}, leading paragraph is 
{{paragraph|1|{{section.


```

And each call should generate respectively something like

   Hello, we are in Section 1, leading paragraph is "Some text.".

   Hello, we are in Section 2, leading paragraph is "Some other text.".

So, basically the idea is to let the module infers parameters from the 
calling context, rather than

always make them explicit.

I didn't find in the manual anything that appeared relevant to me for 
such a use case.


I'm also welcoming any suggestion to make things in a totally other way. :)

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

[Wikitech-l] Looking for advice for structuring data module with redundant entries

[mathieu stumpf guntz]

Hi,

So in Lua, as far as I can say, there is no way to express directly 
something like `a = {b=1, c=a.b}`.
Instead one might use functions, and call the table with the instance 
method call operator (colon), like

`a = {b=1, c=function(s) return s.b end}; a.b == a:c() -- true`.

A first minor problem is that it introduces asymmetry in form. A 
solution which would allow to call equally

`a.b` and `a.c` would be more interesting for this use case.

Moreover, `a.c = 2` should lead to a state where `a.b == a.c and a.b == 2`

More context: the goal is to store lexicological informations in data 
modules.
Entries might share one or more descriptive material. The important 
point which lead to this consideration
is that the data module should be modifiable from outside the module, 
without requiring huge integrity

constraint at each description change.

But maybe I'm not taking the simplest approach here, so feel free to 
suggest totally different solution.


Kind regards

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