Re: [Wikitech-l] OOUI question

2019-03-21 Thread Huji Lee
I found out that I had hardcoded the scrollable property in the wrong
place. But, interestingly, I also figured out that StackLayou's scrollable
parameter defaults to true. Isn't that in contrast with the documentation?

Anyway, setting it to false resolved that issue. Next I need to figure out
how to nest a StackLayout inside another StackLayout

On Thu, Mar 21, 2019 at 10:20 PM Huji Lee  wrote:

> Actually, can I ask for one more thing?
>
> I updated the code such that when you click on that link (which now reads
> as "تذکر"), it would open a dialog with a StackLayout in it which consists
> of two FieldLayouts, somehow, the dialog is becoming scrollable, and has
> very little height, making the contents hard to read. Looking at the
> documentations for StackLayout I see that the scrollable parameter defaults
> to false; I even went ahead and hardcoded the value as false, but the
> problem persists. Can you kindly tell me which other elements need to be
> modified for this not to occur?
>
> Thanks again,
>
> Huji
>
> On Thu, Mar 21, 2019 at 7:41 AM Huji Lee  wrote:
>
>> You are absolutely right; I really appreciate the time you took to review
>> the code!
>> Thanks,
>> Huji
>>
>> On Wed, Mar 20, 2019 at 11:25 PM Moriel Schottlender <
>> mschottlen...@wikimedia.org> wrote:
>>
>>> Hi Huji,
>>>
>>> I took a look, and it seems you're missing the command to actually open
>>> the
>>> dialog. Your code builds the dialog correctly, and then attaches the
>>> windowManager and adds the dialog to the window, but there's no command
>>> telling the manager to open the dialog on click.
>>>
>>> I tried to debug your code, so I copied it over and looked and I found
>>> that
>>> if I changed this, it worked:
>>>
>>> $(mw.util.addPortletLink( 'p-cactions', '#', 'تذکر', 'ca-warn',
>>> 'فرستادن سریع یک پیام یا تذکر مبتنی بر الگو', '*')).click(function(e)
>>> {
>>>   mw.loader.using(['oojs-ui-core', 'oojs-ui-widgets',
>>> 'oojs-ui-windows', 'mediawiki.api'])
>>> .then(UMOptions.createWindow)
>>> .then( function () {
>>> windowManager.openWindow( UM );
>>> } );
>>>
>>> (notice the second 'then')
>>> Basically, I tell the code that on click, after it is certain to have
>>> created the dialog, it should open it :)
>>>
>>> See documentation here:
>>> https://www.mediawiki.org/wiki/OOUI/Windows/Dialogs
>>>
>>> I hope this helps!
>>>
>>> Moriel
>>>
>>> On Wed, Mar 20, 2019 at 7:22 PM Huji Lee  wrote:
>>>
>>> > Hi everyone!
>>> >
>>> > I am pretty sure I am missing something obvious here, but I cannot
>>> spot it
>>> > and I would appreciate a fresh set of eyes looking at it.
>>> >
>>> > The script at https://fa.wikipedia.org/wiki/User:Huji/UserMessages.js
>>> is
>>> > the backbone of a OOUI-based tool. I have made quite a few of a these
>>> tools
>>> > in the past with no problem. For now, this tool is only supposed to do
>>> two
>>> > things: add a link to the "More" dropdown on the top of the page (only
>>> if
>>> > it is a user talk page), and open a OOUI dialog once the link is
>>> clicked.
>>> >
>>> > The first part works and I have verified that the *createWindow*
>>> method is
>>> > called when you click the link, but the dialog is not shown. Can
>>> someone
>>> > kindly look at my code and tell me what I am missing?
>>> >
>>> > Thanks,
>>> >
>>> > Huji
>>> > ___
>>> > Wikitech-l mailing list
>>> > Wikitech-l@lists.wikimedia.org
>>> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>>
>>>
>>>
>>> --
>>> Moriel Schottlender (she/her)
>>> Senior Software Engineer
>>> Tech Lead | Community Tech and Anti Harassment Tools
>>> Wikimedia Foundation https://wikimediafoundation.org/
>>> ___
>>> Wikitech-l mailing list
>>> Wikitech-l@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OOUI question

2019-03-21 Thread Huji Lee
Actually, can I ask for one more thing?

I updated the code such that when you click on that link (which now reads
as "تذکر"), it would open a dialog with a StackLayout in it which consists
of two FieldLayouts, somehow, the dialog is becoming scrollable, and has
very little height, making the contents hard to read. Looking at the
documentations for StackLayout I see that the scrollable parameter defaults
to false; I even went ahead and hardcoded the value as false, but the
problem persists. Can you kindly tell me which other elements need to be
modified for this not to occur?

Thanks again,

Huji

On Thu, Mar 21, 2019 at 7:41 AM Huji Lee  wrote:

> You are absolutely right; I really appreciate the time you took to review
> the code!
> Thanks,
> Huji
>
> On Wed, Mar 20, 2019 at 11:25 PM Moriel Schottlender <
> mschottlen...@wikimedia.org> wrote:
>
>> Hi Huji,
>>
>> I took a look, and it seems you're missing the command to actually open
>> the
>> dialog. Your code builds the dialog correctly, and then attaches the
>> windowManager and adds the dialog to the window, but there's no command
>> telling the manager to open the dialog on click.
>>
>> I tried to debug your code, so I copied it over and looked and I found
>> that
>> if I changed this, it worked:
>>
>> $(mw.util.addPortletLink( 'p-cactions', '#', 'تذکر', 'ca-warn',
>> 'فرستادن سریع یک پیام یا تذکر مبتنی بر الگو', '*')).click(function(e)
>> {
>>   mw.loader.using(['oojs-ui-core', 'oojs-ui-widgets',
>> 'oojs-ui-windows', 'mediawiki.api'])
>> .then(UMOptions.createWindow)
>> .then( function () {
>> windowManager.openWindow( UM );
>> } );
>>
>> (notice the second 'then')
>> Basically, I tell the code that on click, after it is certain to have
>> created the dialog, it should open it :)
>>
>> See documentation here:
>> https://www.mediawiki.org/wiki/OOUI/Windows/Dialogs
>>
>> I hope this helps!
>>
>> Moriel
>>
>> On Wed, Mar 20, 2019 at 7:22 PM Huji Lee  wrote:
>>
>> > Hi everyone!
>> >
>> > I am pretty sure I am missing something obvious here, but I cannot spot
>> it
>> > and I would appreciate a fresh set of eyes looking at it.
>> >
>> > The script at https://fa.wikipedia.org/wiki/User:Huji/UserMessages.js
>> is
>> > the backbone of a OOUI-based tool. I have made quite a few of a these
>> tools
>> > in the past with no problem. For now, this tool is only supposed to do
>> two
>> > things: add a link to the "More" dropdown on the top of the page (only
>> if
>> > it is a user talk page), and open a OOUI dialog once the link is
>> clicked.
>> >
>> > The first part works and I have verified that the *createWindow* method
>> is
>> > called when you click the link, but the dialog is not shown. Can someone
>> > kindly look at my code and tell me what I am missing?
>> >
>> > Thanks,
>> >
>> > Huji
>> > ___
>> > Wikitech-l mailing list
>> > Wikitech-l@lists.wikimedia.org
>> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>>
>>
>> --
>> Moriel Schottlender (she/her)
>> Senior Software Engineer
>> Tech Lead | Community Tech and Anti Harassment Tools
>> Wikimedia Foundation https://wikimediafoundation.org/
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Security Notification: A quick update on ongoing attempts to disrupt Wikimedia services

2019-03-21 Thread David Sharpe


Hello,

Over the past several days an individual has continued to attempt disruption of 
Wikimedia Services. The Wikimedia Foundation’s incident response processes are 
activated and countermeasures are in place. There have been a few times where 
brief service outages affecting Gerrit and Phabricator were necessary. We are 
working around the clock to safeguard all systems.

We are putting a series of countermeasures and protections in place to limit 
the potential impact of similar activity going forward. We aren’t at liberty to 
provide more detail right now without putting our efforts at risk, but will 
update you again when we can.

Please report any suspicious activity to secur...@wikimedia.org 
.  

Thank you!



Respectfully,

David Sharpe
Senior Information Security Analyst
Wikimedia Foundation



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

Re: [Wikitech-l] Question to WMF: Backlog on bugs

2019-03-21 Thread Pine W
On Wed, Mar 20, 2019, 3:32 PM Nick Wilson (Quiddity) 
wrote:

> Pine,
> please see the exact (quite precise) definition of
> https://en.wiktionary.org/wiki/technical_debt
> https://en.wikipedia.org/wiki/Technical_debt
> https://martinfowler.com/bliki/TechnicalDebt.html
> I.e. Technical debt is Not at all equivalent to "bugs". The topic is a
> tangential one. Software can work perfectly fine for end-users even if it
> has a lot of "technical debt", it is just a pain for developers to change
> anything in it or connected to it because the code has complex issues (it's
> a mess, or imperfectly architected at a higher-level, or "icky", or other
> factors). It is not possible to measure, and is somewhat subjective in
> nature.
>

Thanks for correcting me regarding the definition. That helps. (One of
these days I will probably write something that will reveal a deep
ignorance of a Wikimedia topic, and I'm sure that I will hear about it.
Making errors is one way to learn, although it is a way that I often make
an effort to avoid.)


> Overall this thread is going in circles, and I recommend dropping it here.
> There are several good suggestions above if anyone wants to put effort into
> actual solutions.
>

It sounds like we have different perspectives. However, get the impression
that people are getting tired of the this topic, so I'll move on.


Pine
( https://meta.wikimedia.org/wiki/User:Pine )
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Wikimedia production excellence (February 2019)

2019-03-21 Thread Krinkle
📘 Read on Phabricator at
https://phabricator.wikimedia.org/phame/live/1/post/141/
---

How’d we do in our strive for operational excellence? Read on to find out!

- Month in numbers.
- Current problems.
- Highlighted stories.

## 📊 *Month in numbers*

* 7 documented incidents. [1]
* 30 new Wikimedia-prod-error tasks created. [2] (17 new in Jan, and 18 in
Dec.)
* 27 Wikimedia-prod-error tasks closed. [3] (16 closed in Jan, and 20 in
Dec.)

There are in total 177 open Wikimedia-prod-error tasks today. (188 in Feb,
172 in Jan, and 165 in Dec.)

## 📉  *Current problems*

There’s been an increase in how many application errors are reported each
week. And, we’ve also managed to mostly keep up with those each week, so
that’s great!

But, it does appear that most weeks we accumulated one or two unresolved
errors, which is starting to add up. I believe this is mainly because they
were reported a day after the branch went out. That is, if the same issues
had been reported 24 hours earlier in a given week, then they might’ve
blocked the train as a regression.

→  https://phabricator.wikimedia.org/tag/wikimedia-production-error/

Below is breakdown of unresolved prod errors since last quarter. (I’ve
omitted the last three weeks.)

By month:

  - February: 5 reports (1.33-wmf.16, 1.33-wmf.17, 1.33-wmf.18).
  - January: 3 reports (1.33-wmf.13, 1.33-wmf.14).
  - December 2018: 5 reports (1.33-wmf.9).
  - November 2018: 3 reports (1.33-wmf.2).
  - October 2018: 1 report (1.32-wmf.26).
  - September 2018: 2 reports (1.32-wmf.20).

By steward and software component:

Core Platform:
* Parser: https://phabricator.wikimedia.org/T216664.
* Revision backend: https://phabricator.wikimedia.org/T214035,
https://phabricator.wikimedia.org/T212428.

Growth:
* Echo: https://phabricator.wikimedia.org/T217079.
* Flow: https://phabricator.wikimedia.org/T212742,
https://phabricator.wikimedia.org/T204793.
* Page deletion: https://phabricator.wikimedia.org/T203913.

Wikidata:
* Wikibase: https://phabricator.wikimedia.org/T217329,
https://phabricator.wikimedia.org/T215380,
https://phabricator.wikimedia.org/T213483.
* WikibaseLexeme: https://phabricator.wikimedia.org/T207479,
https://phabricator.wikimedia.org/T200906.
* WikibaseQualityConstraints: https://phabricator.wikimedia.org/T212282.

Performance:
* Lib-rdmbs: https://phabricator.wikimedia.org/T212284.

Multimedia:
* MediaWiki uploading: https://phabricator.wikimedia.org/T208539.

Fundraising-Tech:
* CentralNotice: https://phabricator.wikimedia.org/T209741.

(Nobody - pending code ownership process):
* ImageMap extension: https://phabricator.wikimedia.org/T217087.
* Nuke extension: https://phabricator.wikimedia.org/T212690.

## *️⃣ *Fixed exposed fatal error on Special:Contributions*

Previously, a link to Special:Contributions could pass invalid options to a
part of MediaWiki that doesn’t allow invalid options. Why would anything
allow invalid options? Let’s find out.

Think about software as an onion. Software tends to have an outer layer
where everything is allowed. If this layer finds illegal user input, it has
to respond somehow. For example, by informing the user. In this outer
layer, illegal input is not a problem in the software. It is a normal thing
to see as we interact with the user. This outer layer responds directly to
a user, is translated, and can do things like “view recent changes”, “view
user contributions” or “rename a page”.

Internally, such action is divided into many smaller tasks (or functions).
For example, a function might be “get talk namespace for given subject
namespace”. This would answer “Talk:” to “(Article)”, and “Wikipedia_talk:”
to “Wikipedia:”. When searching for edits on My Contributions with
“Associated namespaces” ticked, this function is used. It is also used by
Move Page if renaming a page together with its talk page. And it’s used on
Recent Changes and View History, for all those little “talk” links next to
each page title and username.

If one of your edits is for a page that has no discussion namespace, what
should MediaWiki do? Show no edits? Skip that edit and tell the user “1
edit was hidden”? Show normally, but without a talk link? That decision is
made by the outer layer for a feature, when it catches the internal
exception. Alternatively, it can sometimes avoid an exception by asking a
different question first – a question that cannot fail. Such as “Does
namespace X have a talk space?”, instead of “What is the talk space for X?”.

When a program doesn’t catch or avoid an exception, a fatal error occurs.
Thanks to D3r1ck01 for fixing this fatal error. –
https://phabricator.wikimedia.org/T150324


💡*ProTip*: If the Jenkins build is failing for a project and you suspect
it’s unrelated to the project itself, be sure to report it to Phabricator
under “Shared Build Failure”, or use
https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?project=shared-build-failure
.


## 🎉 *Thanks!*

Thank you to everyone who has helped by reporting,

Re: [Wikitech-l] OOUI question

2019-03-21 Thread Huji Lee
You are absolutely right; I really appreciate the time you took to review
the code!
Thanks,
Huji

On Wed, Mar 20, 2019 at 11:25 PM Moriel Schottlender <
mschottlen...@wikimedia.org> wrote:

> Hi Huji,
>
> I took a look, and it seems you're missing the command to actually open the
> dialog. Your code builds the dialog correctly, and then attaches the
> windowManager and adds the dialog to the window, but there's no command
> telling the manager to open the dialog on click.
>
> I tried to debug your code, so I copied it over and looked and I found that
> if I changed this, it worked:
>
> $(mw.util.addPortletLink( 'p-cactions', '#', 'تذکر', 'ca-warn',
> 'فرستادن سریع یک پیام یا تذکر مبتنی بر الگو', '*')).click(function(e)
> {
>   mw.loader.using(['oojs-ui-core', 'oojs-ui-widgets',
> 'oojs-ui-windows', 'mediawiki.api'])
> .then(UMOptions.createWindow)
> .then( function () {
> windowManager.openWindow( UM );
> } );
>
> (notice the second 'then')
> Basically, I tell the code that on click, after it is certain to have
> created the dialog, it should open it :)
>
> See documentation here:
> https://www.mediawiki.org/wiki/OOUI/Windows/Dialogs
>
> I hope this helps!
>
> Moriel
>
> On Wed, Mar 20, 2019 at 7:22 PM Huji Lee  wrote:
>
> > Hi everyone!
> >
> > I am pretty sure I am missing something obvious here, but I cannot spot
> it
> > and I would appreciate a fresh set of eyes looking at it.
> >
> > The script at https://fa.wikipedia.org/wiki/User:Huji/UserMessages.js is
> > the backbone of a OOUI-based tool. I have made quite a few of a these
> tools
> > in the past with no problem. For now, this tool is only supposed to do
> two
> > things: add a link to the "More" dropdown on the top of the page (only if
> > it is a user talk page), and open a OOUI dialog once the link is clicked.
> >
> > The first part works and I have verified that the *createWindow* method
> is
> > called when you click the link, but the dialog is not shown. Can someone
> > kindly look at my code and tell me what I am missing?
> >
> > Thanks,
> >
> > Huji
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
> --
> Moriel Schottlender (she/her)
> Senior Software Engineer
> Tech Lead | Community Tech and Anti Harassment Tools
> Wikimedia Foundation https://wikimediafoundation.org/
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [Development Metrics] Github Git activity indexed on wikimedia.biterg.io

2019-03-21 Thread Andre Klapper
For those who like statistics:

I've made https://wikimedia.biterg.io index the Git activity in nearly
all Wikimedia Github repositories which are canonical on Github (means:
not mirrored from Wikimedia Git/Gerrit) and are not upstream forks.

The six exceptions not indexed are repositories which I could not sort
out due to confusing differences in commit logs:
* https://github.com/wikimedia/mediawiki-services-eventstreams vs 
https://gerrit.wikimedia.org/g/mediawiki/services/eventstreams
* https://github.com/wikimedia/jmx_exporter vs 
https://gerrit.wikimedia.org/g/operations/debs/prometheus-jmx-exporter
* https://github.com/wikimedia/webpagetest vs 
https://gerrit.wikimedia.org/g/performance/WebPageTest
* https://github.com/wikimedia/operations-debs-python-confluent-kafka vs 
https://gerrit.wikimedia.org/g/operations/debs/python-confluent-kafka
* https://github.com/wikimedia/operations-debs-mcrouter vs 
https://gerrit.wikimedia.org/g/operations/debs/mcrouter
* https://github.com/wikimedia/cassandra-metrics-collector vs 
https://gerrit.wikimedia.org/g/operations/software/cassandra-metrics-collector

Note that is about Git activity only. 
This is not (yet) about data on PRs and issues on Github (see.

For more info, see https://www.mediawiki.org/wiki/Community_metrics

Cheers,
andre
-- 
Andre Klapper | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/



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