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

[Alex Ezell]

Hi y'all,
Do we use levels for any of these error log outputs? That is, are they
classified on output as High, Medium, Low, Info, or something like that?

Or do we have to triage each of them as we examine them?

I was just thinking if they were somehow leveled, we could use measurements
of the number of each type and set targets for lowering the number of those
kinds of logs. That would potentially help visualize and prioritize the
work. It might be easier to say something like that, "Let's have a goal to
produce 10% less High errors in the next two months," than to have a more
nebulous approach that seems to require Tyler or someone from his team to
highlight tasks that are especially impactful.

I'm mostly ignorant of exactly how these processes work now so if I'm
telling y'all something you already know, forgive me. I was mostly thinking
out loud about how we could start to approach the work more systematically.

Alex Ezell (he/him)
Senior Engineering Manager
Wikimedia Foundation


On Tue, Sep 15, 2020 at 10:36 AM Tyler Cipriani 
wrote:

> On Tue, Sep 15, 2020 at 5:24 AM Derk-Jan Hartman
>  wrote:
> >
> > In particular I count 13 frontend problems with the old TMH kaltura
> player.
> > There is clearly no intent to fix those (volunteer or employee), as the
> > Kaltura player has been unmaintained for 8 years.
> > The choices as far as I can tell are to ignore them, undeploy a/v
> playback
> > or to direct C-level management to get the audio and video stuff
> together.
>
> The tasks that I mentioned in my original message are, likewise, tasks
> that I'm not sure belong to any team or any particular person.
>
> I have been using the phab tag/milestone "Release Engineering
> (Logspam)" to ensure that we don't lose track of tasks that are:
>
> 1. problems in production
> 2. tagged in phabricator with a team or component (in contrast to
> problems with unknown components/team tags)
> 3. no longer resourced or maintained in a discernible way
>
> Feel free to apply that tag if those 3 conditions apply to these
> tasks. Tracking these will make it easier to raise awareness later.
>
> Thanks!
> -- Tyler
>
> ___
> 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] Cryptographic puzzles as mitigation for DDoS

[Alex Monk]

I was under the (possibly mistaken) impression that the attacker was just
flooding the network with traffic?

On Sat, 7 Sep 2019, 12:25 John Erling Blad,  wrote:

> There are several papers about how to stop DDoS by using cryptographic
> puzzles.[1] The core idea is to give the abuser some algorithmic work he
> has to solve, thereby forcing him to waste processing power, and then to
> slow him down to a manageable level.[2] That only work if you are the
> target, and not some intermediary are targeted.
>
> Could it be a solution for the WMF servers?
>
> [1] http://d-scholarship.pitt.edu/24944/1/mehmud_abliz_dissertation.pdf
> (just a random pick)
> [2]
>
> https://searchsecurity.techtarget.com/answer/TLS-protocol-Can-a-client-puzzle-improve-security
> (about
> TLS, but can also be done at the application level)
> ___
> 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] Seeking feedback on the initial design of the Contraband tool

[Alex Ezell]

Hi Rammanoj,
This looks like a cool project. It will be great to see activity across the
various platforms. The interface designs you have look very clean and
functional.

Could you explain the meaning of the name, Contraband? That word has a
generally negative connotation in US English so I'm curious how it fits the
project.

On Tue, Jun 11, 2019 at 3:21 PM Rammanoj Potla 
wrote:

> Hello folks,
>
> I am Rammanoj, a Google Summer of Code 2019 student for Wikimedia. As part
> of the program, I am developing a tool to track developer activity on three
> different platforms: Gerrit, Phabricator and Github. Potential users of
> this tool will be event organizers, especially scholarship committee
> reviewers who need developer contribution statistics while reviewing
> applications for Wikimedia events and juggle between different platforms
> like Github, Gerrit, Phabricator to view developer activity for deciding on
> an applicant.
>
> As a first step, I’ve developed some mockups that explain the proposed
> workflow of the tool: https://meta.wikimedia.org/wiki/Contraband#Mockups.
> It would be helpful if you could provide me with feedback to continue
> further and develop the tool. Please leave your feedback/comments/questions
> on the talk page: https://meta.wikimedia.org/wiki/Talk:Contraband.
>
> You can also keep an eye on the technical updates on Phabricator:
> https://phabricator.wikimedia.org/T220254.
>
> Thanks & Regards,
>
> Rammanoj
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Alex Ezell
Engineering Manager
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Pending (false positive?) translations on Gerrit to Toolforge tools

[Alex Monk]

Working link to l10n-bot's dashboard:
https://gerrit.wikimedia.org/r/#/dashboard/137

On Sun, 28 Apr 2019 at 13:12, Amir E. Aharoni 
wrote:

> I'm still not able to open the link
> https://gerrit.wikimedia.org/r/dashboard/l10n-...@translatewiki.net, but I
> am able to open this for example:
> https://gerrit.wikimedia.org/r/#/q/project:labs/tools/crosswatch
>
> And it indeed looks like there are a few stuck patches from L10n-bot.
>
> This is not supposed to happen. They are supposed to be automatically
> merged.
>
> Looks like a continuous integration (CI) bug somewhere, but I'm not sure
> where exactly. Can you please report a Phabricator ticket with the
> translatewiki tag, and with a list of all the tools that are failing?
>
> --
> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> http://aharoni.wordpress.com
> ‪“We're living in pieces,
> I want to live in peace.” – T. Moore‬
>
>
> ‫בתאריך יום א׳, 28 באפר׳ 2019 ב-15:03 מאת ‪Derick Alangi‬‏ <‪
> alangider...@gmail.com‬‏>:‬
>
> > Hi,
> >
> > The link works for me. But let me get a list of the tools copied over
> here;
> >
> > - …/tools/crosswatch
> > - …/tools/commons-mass-description
> > <
> >
> https://gerrit.wikimedia.org/r/q/project:labs%252Ftools%252Fcommons-mass-description+status:open
> > >
> > - …/tools/weapon-of-mass-description
> > - …/tools/map-of-monuments
> > <
> >
> https://gerrit.wikimedia.org/r/q/project:labs%252Ftools%252Fmap-of-monuments+status:open
> > >
> > - wikimedia/portals
> > - wikimedia/wikimania-scholarships
> > - …/tools/commons-mass-description
> > - …/tools/weapon-of-mass-description
> >
> > Again, for benefit of doubt, here is the link @Amir:
> > https://gerrit.wikimedia.org/r/dashboard/l10n-...@translatewiki.net, it
> > should work or you can just check the dashboard of l10n-bot on Gerrit.
> > Thanks
> >
> > *--*
> > *https://www.mediawiki.org/wiki/User:X-Savitar>>*
> >
> >
> > On Sun, Apr 28, 2019 at 12:37 PM Amir E. Aharoni <
> > amir.ahar...@mail.huji.ac.il> wrote:
> >
> > > ‫בתאריך יום א׳, 28 באפר׳ 2019 ב-12:16 מאת ‪Derick Alangi‬‏ <‪
> > > alangider...@gmail.com‬‏>:‬
> > >
> > > > Hi,
> > > >
> > > > Looking at
> > > > https://gerrit.wikimedia.org/r/dashboard/l10n-...@translatewiki.net,
> > > there
> > > > are pending translations to Toolforge tools which are failing due to
> > > false
> > > > positives?
> > >
> > >
> > > The link doesn't work for me.
> > >
> > > Which tools are you talking about?
> > > ___
> > > Wikitech-l mailing list
> > > Wikitech-l@lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Dynamically setting the content of a LayoutPanel in OOUI

[Alex Monk]

I haven't dealt with OOUI for a couple of years but maybe you could pass a
jQuery object to the $content parameter, store it yourself, then modify
that later?

On Sun, 24 Mar 2019 at 14:14, Huji Lee  wrote:

> In the script I am working on,[1] I have a PanelLayout that is defined like
> this:
>
> this.previewResult = new OO.ui.PanelLayout({
>   expanded: true,
>   padded: true,
>   framed: true,
>   $content: ''
> });
>
> Later on, I would like to modify the content of this; specifically, I want
> to use MW API to retrieve the parsed output of some short wikitext. For
> now, however, I just want to try out the concept by replacing the content
> with a simple  tag.
>
> Evidently, this line of code does not do the trick:
>
> dialog.previewResult.$content = 'Something';
>
>
> That is, it does update the value of the $content property for the OOUI
> object, but that does not result in the object getting re-rendered. None of
> the setter functions for OO.ui.PanelLayout seem to do the trick either.
>
> What is the correct way to do this? If PanelLayout is not the right object
> type for this purpose, what is?
> ___
> 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] Question to WMF: Backlog on bugs

[Alex Monk]

On Fri, 8 Mar 2019 at 18:04, Strainu  wrote:

> Several things:
> * the bug backlog has been steadily increasing in all phabricator reports I
> have seen (I don't read them all, so some decreases might have occurred
> occasionally, but the trend is there)
> * feature development is prioritized over bug fixes (read: once a feature
> goes into maintenance, good luck getting a fix without bribing someone)
> * [snip]
>
> I'm sure there are legitimate reasons for these problems, the question is
> what can be done to improve the situation
>

Also should be on the list: Sometimes bugs have a known fix that isn't
being rolled out, in favour of a larger more fundamental restructuring
(demanding even more resources).
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Javascript function does not work

[Alex Monk]

Is the jquery.ui.dialog module loaded in RL?
Where is this failing and where is it fine?

‪On Fri, 8 Feb 2019 at 14:47, ‫יגאל חיטרון‬‎ 
wrote:‬

> Hi. Some script stopped working. Looks like the function
>
> $( '' ).dialog( ... ) // 1 parameter
>
> does not work any more. But it still works on different wiki. Was there
> some breaking change? Thank you.
> Igal (User:IKhitron)
> ___
> 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] Old tiles.wfmlabs.org maps services need maintainers to keep them alive after december 18th

[Alex Monk]

You'll basically need to create a wikitech account (if you don't already
have one) and convince one of the existing project admins (listed at
https://tools.wmflabs.org/openstack-browser/project/maps) to add you.
Please use Puppet instead of manually setting up servers by hand.

On Thu, 13 Dec 2018 at 20:21, Alexander Vassilevski <
alexan...@vassilevski.com> wrote:

> I have some free time this December and I could manually create the new
> vm's and replicate the configs/installs by hand on newly created Ubuntu 18
> vm's ( after figuring out how the old ones are installed and configured and
> if given access, of course .. ).
>
>
> Keep in mind that I'm new to wikimedia and don't know much about the
> infrastructure or procedures, so what do I need to do to be given access
> and volunteer to do this?
>
>
> alexan...@vassilevski.com
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, 13 December 2018 12:09, Johan Jönsson 
> wrote:
>
> > On Thu, Dec 13, 2018 at 9:36 AM Johan Jönsson jjons...@wikimedia.org
> > wrote:
> >
> > > On Thu, Dec 13, 2018 at 9:24 AM Derk-Jan Hartman <
> > > d.j.hartman+wmf...@gmail.com> wrote:
> > >
> > > > Yeah might be wise to at least reach out to en.wp and de.wp. Or
> maybe Tech
> > > > News even ?
> > >
> > > "Hey folks, this might not work in the future" could be reason enough
> to
> > > include it in Tech News, yes.
> >
> > Included inhttps://meta.wikimedia.org/wiki/Tech/News/2018/51 which is
> > going out to the wikis on Monday.
> >
> > //Johan Jönsson
> >
> >
> ---
> >
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Maps-l] Old tiles.wfmlabs.org maps services need maintainers to keep them alive after december 18th

[Alex Monk]

I don't think WMF should be hiring contractors purely for the purpose of
supporting individual tools which are not in production.

On Thu, 13 Dec 2018 at 15:46, Pine W  wrote:

> Hi DJ,
>
> Out of curiosity, what all would be involved in the OS change?
>
> The bike layers could be a nontrivial loss for some folks.
>
> If no regular WMF staff are available for the OS changes and ongoing
> maintenance, and if the use of bike lanes (or other features) is
> significant in the opinion of the community, then I think that WMF
> contractor time should be an option for the changes and maintenance,
> although I would like to know how much that would cost before supporting
> that option, along with how strongly bike lanes (and other features
> supported by these servers) are wanted by the community. If the community
> has no strong feelings regarding the loss of these features and the
> contactor time would cost $30,000 in the first year then maybe the loss of
> these features is acceptable, but if there is significant community desire
> to maintain these features and the contractor time would cost $1,000 in the
> first year then I would probably support spending the money for contractor
> time for at least one year of additional service while WMF tries to recruit
> volunteers for future years. In the context of a $100 million annual
> budget, I am fairly confident that WMF could find $1,000 for an additional
> year of service.
>
>
> On Wed, Dec 12, 2018, 5:39 AM Derk-Jan Hartman <
> d.j.hartman+wmf...@gmail.com>
> wrote:
>
> > This is just another small reminder that, because the servers which host
> > tiles.wmflabs.org and wma.wmflabs.org (wikiminiatlas)  and overpass-wiki
> > run on a version of the OS (Ubuntu Trusty) that is no longer supported
> > (and hasn't been available for new instances since november 2017).
> >
> > These services need maintainers and support by community members in order
> > to keep them alive after dec 18th (after which wmflabs will phase out
> those
> > versions) and before the EOL of early 2019 of the OS. Unfortunately it
> > seems no one is stepping up so far to convert these machines.
> >
> > This issue is tracked at https://phabricator.wikimedia.org/T204506
> > As I was curious, I looked around on the tile server a bit and used what
> I
> > could find to update
> > https://wikitech.wikimedia.org/wiki/OSM_Tileserver#Technology_stack
> > This is all the information that I could gather, but i'm FAR from sure if
> > that is complete information and if I would break anything with a rebuild
> > basing myself on that info, so any information on missing elements etc.
> > would be appreciated. I've not gotten around to looking at wikiminiatlas.
> >
> > If the services are not rebuild then likely they will just disappear at
> > some point for all layer variants. This includes the mapnik, black and
> > white, hill shading, hike bike layers. As I have no idea how many users
> of
> > these services there are, it is hard to say what the effect of that would
> > be.
> >
> > DJ
> > ___
> > Maps-l mailing list
> > map...@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/maps-l
> >
> --
>
> Pine
> ( https://meta.wikimedia.org/wiki/User:Pine )
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Book scans from Tuebingen Digital Library to Wikimedia Commons

[Shiju Alex]

>
> Have you seen https://commons.wikimedia.org/wiki/Commons:Batch_uploading
> the help you need than wikitech-l would be.

? I think the folks at commons are more likely to be able to give you


Thank you. I was not aware about this option. Let me try this.

Shiju Alex



On Mon, Dec 3, 2018 at 1:55 PM bawolff  wrote:

> Have you seen https://commons.wikimedia.org/wiki/Commons:Batch_uploading
> ? I think the folks at commons are more likely to be able to give you
> the help you need than wikitech-l would be.
>
> --
> Brian
>
> On Mon, Dec 3, 2018 at 5:22 AM Shiju Alex 
> wrote:
> >
> > >
> > > Google Drive will do OCR on Malayalam, Kannada, and Telugu. Google
> Vision
> > > API (which is usable from a Wikisource gadget
> > > <https://wikisource.org/wiki/Wikisource:Google_OCR> built by Sam
> Wilson)
> > > will do OCR on Tamil. I can't vouch for these being "good", but they do
> > > exist.
> >
> >
> > The request in this post is not for creating an OCR for any language
> > script; but to migrate certain Public Domain book scans from Tuebingen
> > digital library to Wikimedia Commons.
> >
> > Also there is another task of migrating *already proofread Unicode text*
> to
> > Wikisource. But to take up the Unicode migration first the scans need to
> be
> > in Commons.
> >
> > I am making this request only because of the huge amount of pages that we
> > need to handle. If it was just few hundreds of pages volunteers would
> have
> > manually done it.
> >
> >
> > Shiju
> >
> >
> > On Mon, Dec 3, 2018 at 10:01 AM Ryan Kaldari 
> wrote:
> >
> > > >There is no good OCR for languages like Malayalam.
> > >
> > > Google Drive will do OCR on Malayalam, Kannada, and Telugu. Google
> Vision
> > > API (which is usable from a Wikisource gadget
> > > <https://wikisource.org/wiki/Wikisource:Google_OCR> built by Sam
> Wilson)
> > > will do OCR on Tamil. I can't vouch for these being "good", but they do
> > > exist.
> > >
> > > On Sun, Dec 2, 2018 at 2:54 AM Shiju Alex 
> > > wrote:
> > >
> > > > Hi
> > > >
> > > > Here are the answers
> > > >
> > > > What does "converted to Unicode" mean? Converted from what exactly?
> Do
> > > > > you maybe mean "converted via OCR (Optical character recognition)
> from
> > > > > images in file formats (JPG, PNG, images in a PDF) which don't
> allow
> > > > > marking text to a file format which allows marking text in those
> files?
> > > >
> > > >
> > > > There is no good OCR for languages like Malayalam. So each scanned
> image
> > > is
> > > > manually typed and proofread  For example, See the 7th page of this
> book
> > > > <
> http://idb.ub.uni-tuebingen.de/opendigi/CiXIV125b#p=7=transcript>.
> > > > You
> > > > can see the scan image on the right and the transcribed text for that
> > > page
> > > > on the left in the *Transcript *tab.  This is done for 136 books, and
> > > total
> > > > pages on these books are close to 25,700 pages.
> > > >
> > > > What would you want the script to do exactly? Pull the files from the
> > > > > Tuebingen Digital Library and then mass-upload these files to
> Commons?
> > > >
> > > >
> > > > Yes, this is what is required. Unicode migration we will handle
> > > separately.
> > > >
> > > >
> > > > Shiju Alex
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Sun, Dec 2, 2018 at 4:07 PM Andre Klapper  >
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Great! Some questions below for better understanding what's wanted:
> > > > >
> > > > > On Sun, 2018-12-02 at 15:22 +0530, Shiju Alex wrote:
> > > > > > Recently Tuebingen University
> > > > > > <https://uni-tuebingen.de/en/university.html> (with
> > > > > > the support from German Research Foundation) ran a project titled
> > > > > *Gundert
> > > > > > Legacy project* to di

Re: [Wikitech-l] Book scans from Tuebingen Digital Library to Wikimedia Commons

[Shiju Alex]

>
> Google Drive will do OCR on Malayalam, Kannada, and Telugu. Google Vision
> API (which is usable from a Wikisource gadget
> <https://wikisource.org/wiki/Wikisource:Google_OCR> built by Sam Wilson)
> will do OCR on Tamil. I can't vouch for these being "good", but they do
> exist.


The request in this post is not for creating an OCR for any language
script; but to migrate certain Public Domain book scans from Tuebingen
digital library to Wikimedia Commons.

Also there is another task of migrating *already proofread Unicode text* to
Wikisource. But to take up the Unicode migration first the scans need to be
in Commons.

I am making this request only because of the huge amount of pages that we
need to handle. If it was just few hundreds of pages volunteers would have
manually done it.


Shiju


On Mon, Dec 3, 2018 at 10:01 AM Ryan Kaldari  wrote:

> >There is no good OCR for languages like Malayalam.
>
> Google Drive will do OCR on Malayalam, Kannada, and Telugu. Google Vision
> API (which is usable from a Wikisource gadget
> <https://wikisource.org/wiki/Wikisource:Google_OCR> built by Sam Wilson)
> will do OCR on Tamil. I can't vouch for these being "good", but they do
> exist.
>
> On Sun, Dec 2, 2018 at 2:54 AM Shiju Alex 
> wrote:
>
> > Hi
> >
> > Here are the answers
> >
> > What does "converted to Unicode" mean? Converted from what exactly? Do
> > > you maybe mean "converted via OCR (Optical character recognition) from
> > > images in file formats (JPG, PNG, images in a PDF) which don't allow
> > > marking text to a file format which allows marking text in those files?
> >
> >
> > There is no good OCR for languages like Malayalam. So each scanned image
> is
> > manually typed and proofread  For example, See the 7th page of this book
> > <http://idb.ub.uni-tuebingen.de/opendigi/CiXIV125b#p=7=transcript>.
> > You
> > can see the scan image on the right and the transcribed text for that
> page
> > on the left in the *Transcript *tab.  This is done for 136 books, and
> total
> > pages on these books are close to 25,700 pages.
> >
> > What would you want the script to do exactly? Pull the files from the
> > > Tuebingen Digital Library and then mass-upload these files to Commons?
> >
> >
> > Yes, this is what is required. Unicode migration we will handle
> separately.
> >
> >
> > Shiju Alex
> >
> >
> >
> >
> >
> > >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Sun, Dec 2, 2018 at 4:07 PM Andre Klapper 
> > wrote:
> >
> > > Hi,
> > >
> > > Great! Some questions below for better understanding what's wanted:
> > >
> > > On Sun, 2018-12-02 at 15:22 +0530, Shiju Alex wrote:
> > > > Recently Tuebingen University
> > > > <https://uni-tuebingen.de/en/university.html> (with
> > > > the support from German Research Foundation) ran a project titled
> > > *Gundert
> > > > Legacy project* to digitize close to 137,000 pages from *850 public
> > > domain
> > > > books*.
> > > >
> > > > All these public domain books are in the South Indian languages
> > > *Malayalam,
> > > > Kannada, Tamil, Tulu, and Telugu*. In this 293 books are in
> Malayalam,
> > > 187
> > > > in Kannada, 25 in Tamil, 4 in Telugu and Tulu.
> > > >
> > > > Also there was  a separate sub-project which was run as part of this
> > > > project to convert 136 titles in Malayalam to Malayalam Unicode. The
> > > number
> > > > of pages that were converted to Unicode is close to *25,700* pages
> .The
> > > > Unicode conversion project was ran only for Malayalam. For the other
> > > > languages it is just the scanning of books
> > >
> > > What does "converted to Unicode" mean? Converted from what exactly? Do
> > > you maybe mean "converted via OCR (Optical character recognition) from
> > > images in file formats (JPG, PNG, images in a PDF) which don't allow
> > > marking text to a file format which allows marking text in those files?
> > >
> > > > The project is complete now and the results of the project is
> available
> > > in
> > > > the Hermman Gundert Portal
> https://www.gundert-portal.de/?language=en
> > > which
> > > > was released on Nov 20. A news report is available here.
> > > > <
> > >
> >
> https://timesofindia.indiatim

Re: [Wikitech-l] Book scans from Tuebingen Digital Library to Wikimedia Commons

[Shiju Alex]

Hi

Here are the answers

What does "converted to Unicode" mean? Converted from what exactly? Do
> you maybe mean "converted via OCR (Optical character recognition) from
> images in file formats (JPG, PNG, images in a PDF) which don't allow
> marking text to a file format which allows marking text in those files?


There is no good OCR for languages like Malayalam. So each scanned image is
manually typed and proofread  For example, See the 7th page of this book
<http://idb.ub.uni-tuebingen.de/opendigi/CiXIV125b#p=7=transcript>. You
can see the scan image on the right and the transcribed text for that page
on the left in the *Transcript *tab.  This is done for 136 books, and total
pages on these books are close to 25,700 pages.

What would you want the script to do exactly? Pull the files from the
> Tuebingen Digital Library and then mass-upload these files to Commons?


Yes, this is what is required. Unicode migration we will handle separately.


Shiju Alex





>









On Sun, Dec 2, 2018 at 4:07 PM Andre Klapper  wrote:

> Hi,
>
> Great! Some questions below for better understanding what's wanted:
>
> On Sun, 2018-12-02 at 15:22 +0530, Shiju Alex wrote:
> > Recently Tuebingen University
> > <https://uni-tuebingen.de/en/university.html> (with
> > the support from German Research Foundation) ran a project titled
> *Gundert
> > Legacy project* to digitize close to 137,000 pages from *850 public
> domain
> > books*.
> >
> > All these public domain books are in the South Indian languages
> *Malayalam,
> > Kannada, Tamil, Tulu, and Telugu*. In this 293 books are in Malayalam,
> 187
> > in Kannada, 25 in Tamil, 4 in Telugu and Tulu.
> >
> > Also there was  a separate sub-project which was run as part of this
> > project to convert 136 titles in Malayalam to Malayalam Unicode. The
> number
> > of pages that were converted to Unicode is close to *25,700* pages .The
> > Unicode conversion project was ran only for Malayalam. For the other
> > languages it is just the scanning of books
>
> What does "converted to Unicode" mean? Converted from what exactly? Do
> you maybe mean "converted via OCR (Optical character recognition) from
> images in file formats (JPG, PNG, images in a PDF) which don't allow
> marking text to a file format which allows marking text in those files?
>
> > The project is complete now and the results of the project is available
> in
> > the Hermman Gundert Portal https://www.gundert-portal.de/?language=en
> which
> > was released on Nov 20. A news report is available here.
> > <
> https://timesofindia.indiatimes.com/city/kochi/german-scholars-malayalam-mission-all-set-to-get-a-digital-makeover/articleshow/66633108.cms
> >
> >
> > To view the books in each language you can navigate through the various
> > links in the portal. For example, malayalam books are available here:
> > https://www.gundert-portal.de/?page=malayalam
> >
> > Now we need to upload these scans to Wikimedia Commons and Unicode text
> to
> > Malayalam Wikisource (25,700 Unicode converted pages)
> >
> > The first priority is for the scans that are converted to Unicode. Is it
> > possible to write a script to migrate the scans from Tuebingen Digital
> > library to Wikimedia Commons? (I can share the exact details of books
> > converted to Unicode if needed)
>
> What would you want the script to do exactly? Pull the files from the
> Tuebingen Digital Library and then mass-upload these files to Commons?
> OCR (identify letters in pure images and converting those letters to
> text which could be marked and copied)? Something else?
>
> To convert image files available on Wikimedia Commons to recognized
> text, see https://tools.wmflabs.org/ws-google-ocr/ for example. There
> is also https://phabricator.wikimedia.org/T120788 for more info/tools.
>
> > All the digitized files are heavy and the size ranges from 100 MB to 1.5
> GB
> > depending on the number of pages in the books. So manually managing this
> is
> > going to be a big challenge.
> >
> > Can some one help with this?
>
> 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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Book scans from Tuebingen Digital Library to Wikimedia Commons

[Shiju Alex]

Hello,

Recently Tuebingen University
<https://uni-tuebingen.de/en/university.html> (with
the support from German Research Foundation) ran a project titled *Gundert
Legacy project* to digitize close to 137,000 pages from *850 public domain
books*.

All these public domain books are in the South Indian languages *Malayalam,
Kannada, Tamil, Tulu, and Telugu*. In this 293 books are in Malayalam, 187
in Kannada, 25 in Tamil, 4 in Telugu and Tulu.

Also there was  a separate sub-project which was run as part of this
project to convert 136 titles in Malayalam to Malayalam Unicode. The number
of pages that were converted to Unicode is close to *25,700* pages.The
Unicode conversion project was ran only for Malayalam. For the other
languages it is just the scanning of books

The project is complete now and the results of the project is available in
the Hermman Gundert Portal https://www.gundert-portal.de/?language=en which
was released on Nov 20. A news report is available here.
<https://timesofindia.indiatimes.com/city/kochi/german-scholars-malayalam-mission-all-set-to-get-a-digital-makeover/articleshow/66633108.cms>

To view the books in each language you can navigate through the various
links in the portal. For example, malayalam books are available here:
https://www.gundert-portal.de/?page=malayalam

Now we need to upload these scans to Wikimedia Commons and Unicode text to
Malayalam Wikisource (25,700 Unicode converted pages)

The first priority is for the scans that are converted to Unicode. Is it
possible to write a script to migrate the scans from Tuebingen Digital
library to Wikimedia Commons? (I can share the exact details of books
converted to Unicode if needed)

All the digitized files are heavy and the size ranges from 100 MB to 1.5 GB
depending on the number of pages in the books. So manually managing this is
going to be a big challenge.

Can some one help with this?

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

Re: [Wikitech-l] Deployment-prep (aka 'Beta') services will be unreliable this week

[Alex Monk]

Also:
* Puppet is disabled on deployment-mediawiki-07 for unknown reasons
https://phabricator.wikimedia.org/T208101#4770736
* Confusion about the status of deployment-redis*, they seem completely
broken but have important references?
https://phabricator.wikimedia.org/T210301

On Fri, 23 Nov 2018 at 17:15, Alex Monk  wrote:

> For the record this is largely complete with a few known remaining
> problems:
> * MediaWiki does not recognise the new cache instance due to missing
> config change, the patch is ready but requires a deployer, this does cause
> problems for things like account creations:
> https://phabricator.wikimedia.org/T210296
> * Restbase service is offline, causing VE to not work:
> https://phabricator.wikimedia.org/T208101#4768886
> * Zotero instance is stuck in the old region as the instance is so old the
> base image has gone missing (Ubuntu Trusty). This instance was already on
> its way out though.
> * Old cache instance is still receiving traffic despite having no DNS
> records pointing at it: https://phabricator.wikimedia.org/T210214
>
> On Mon, 19 Nov 2018 at 18:11, Andrew Bogott  wrote:
>
>> Due to a lucky arrangement of schedules, we are going to move the
>> deployment-prep project to the new Cloud region this week, starting in a
>> few minutes. *This includes all of the infrastructure behind the
>> beta.wmflabs.org site.*
>>
>> Various people will be standing by to troubleshoot the outages that
>> result, but for the most part if you see bad behaviors you should
>> disregard or work around them for the time being.
>>
>> Once everything is moved and semi-stable I will send a followup email,
>> at which point the deployment-prep team will once again become
>> interested in bug reports :)
>>
>> Sorry for the short notice!  With a little luck this should be mostly
>> painless.
>>
>> -Andrew
>>
>> ___
>> 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] Deployment-prep (aka 'Beta') services will be unreliable this week

[Alex Monk]

For the record this is largely complete with a few known remaining problems:
* MediaWiki does not recognise the new cache instance due to missing config
change, the patch is ready but requires a deployer, this does cause
problems for things like account creations:
https://phabricator.wikimedia.org/T210296
* Restbase service is offline, causing VE to not work:
https://phabricator.wikimedia.org/T208101#4768886
* Zotero instance is stuck in the old region as the instance is so old the
base image has gone missing (Ubuntu Trusty). This instance was already on
its way out though.
* Old cache instance is still receiving traffic despite having no DNS
records pointing at it: https://phabricator.wikimedia.org/T210214

On Mon, 19 Nov 2018 at 18:11, Andrew Bogott  wrote:

> Due to a lucky arrangement of schedules, we are going to move the
> deployment-prep project to the new Cloud region this week, starting in a
> few minutes. *This includes all of the infrastructure behind the
> beta.wmflabs.org site.*
>
> Various people will be standing by to troubleshoot the outages that
> result, but for the most part if you see bad behaviors you should
> disregard or work around them for the time being.
>
> Once everything is moved and semi-stable I will send a followup email,
> at which point the deployment-prep team will once again become
> interested in bug reports :)
>
> Sorry for the short notice!  With a little luck this should be mostly
> painless.
>
> -Andrew
>
> ___
> 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] Changes to User Blocking

[Alex Ezell]

Hi all,
I'm Alex Ezell and I'm the Engineering Manager for the Anti-Harassment
Tools team at the WMF. I have some details about user blocking that I'd
like to share.

*tl:dr;*
On a wiki with the new Partial Blocks enabled (currently only testwiki), if
the code is checking User::isBlocked() to determine edit rights, it should
instead check User::isBlockedFrom( Title ). The code could also check
isBlocked()
&& $block->isSitewide(). If it doesn’t, the code may block users that
shouldn’t be blocked.

*More details:*
Recently, the Anti-Harassment Tools team merged code to enable a new
feature called Partial Blocks. This feature lets admins block users from
editing particular pages instead of only being able to block users from the
entire site. It is currently enabled on testwiki.

This means that there are now multiple types of blocks (and more to come in
the future, ie namespace blocks). The specific new types are “partial” as
opposed to “sitewide” and some non-editing types of blocks (send email,
edit talk page, etc.) Previously, a developer could assume that if a user
was “blocked” that meant the user couldn’t do much of anything because that
was a “sitewide” block and the only kind of block. Now, there are more
cases to be concerned about.

Specifically, we’ve seen some extensions using User::isBlocked() and then
assuming that a user can’t edit the particular page that the extension
might be concerned with. User::isBlockedFrom( Title ) with a Title object
will be the more correct way to check because of the possibility that a
user might not be blocked from that particular page. If the code isn’t
concerned with editing, it would be appropriate to use User::isAllowed()
which will determine blocked status by way of User::getRights().

There is also a new method Block::isSitewide() which can help a developer
determine if the block is “sitewide” or some other type. This is useful if
the code doesn’t care about anything but the “sitewide” block type.

We believe that keeping User::isBlocked() in its current state is the safer
way to proceed because in cases where it’s being used incorrectly it would
result in over-enforcing blocks rather than under-enforcing them. A user
who is partially blocked might be treated like a sitewide block by an
extension. That seems safer to us than potentially allowing a user more
freedom than an admin intended with a partial block.

We found at least one extension using User::getRights() in a way that would
over-enforce on a partially blocked user. We created a patch to change how
User::getRights() works
<https://gerrit.wikimedia.org/r/c/mediawiki/core/+/471210>. In addition to
checking that a block exists, it will also ensure that the block is a
sitewide block. This will spare the partially blocked user from being
blocked in these cases.

In summary, all MediaWiki code (especially extension code) that is
concerned with checking user blocks should be aware of the distinction
between User::isBlocked() and User::isBlockedFrom( Title ) and use the
appropriate method for the kind of blocking the code is concerned with.
Additionally, using the helper method Block::isSitewide() is handy for
certain usages.

Alex Ezell
Engineering Manager, Anti-Harassment Tools Team (WMF)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

[Alex Monk]

I agree, tasks should not be declined in such a way when tagged with
component(s).

On Tue, 2 Oct 2018 at 17:31, Amir E. Aharoni 
wrote:

> Hi,
>
> I sometimes see WMF developers and product managers marking tasks as
> "Declined" with comments such as these:
> * "No resources for it in (team name)"
> * "We won't have the resources to work on this anytime soon."
> * "I do not plan to work on this any time soon."
>
> Can we perhaps agree that the "Declined" status shouldn't be used like
> this?
>
> "Declined" should be valid when:
> * The component is no longer maintained (this is often done as
> mass-declining).
> * A product manager, a developer, or any other sensible stakeholder thinks
> that doing the task as proposed is a bad idea. There are also variants of
> this:
> * The person who filed the tasks misunderstood what the software component
> is supposed to do and had wrong expectations.
> * The person who filed the tasks identified a real problem, but another
> task proposes a better solution.
>
> It's quite possible that some people will disagree with the decision to
> mark a particular task as "Declined", but the reasons above are legitimate
> explanations.
>
> However, if the task suggests a valid idea, but the reason for declining is
> that a team or a person doesn't plan to work on it because of lack of
> resources or different near-term priorities, it's quite problematic to mark
> it as Declined.
>
> It's possible to reopen tasks, of course, but nevertheless "Declined" gives
> a somewhat permanent feeling, and may cause good ideas to get lost.
>
> So can we perhaps decide that such tasks should just remain Open? Maybe
> with a Lowest priority, maybe in something like a "Freezer" or "Long term"
> or "Volunteer needed" column on a project workboard, but nevertheless Open?
>
> --
> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> http://aharoni.wordpress.com
> ‪“We're living in pieces,
> I want to live in peace.” – T. Moore‬
> ___
> 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] Translations on hold until further notice

[Alex Monk]

Since this is clearly a request to developers, I suggest posting a link to
the relevant ticket(s).

Alex

On Wed, 26 Sep 2018 at 23:20, Greg Grossmeier  wrote:

> tl;dr: Please refrain from adding new strings that require translations
> to MediaWiki and deployed extensions until further notice.
>
> Due to changes we are making in the way our translation systems process
> data we will be temporarily disabling the auto deployment of newly
> translated content until further notice.  The goal of these changes will
> be to improve the evaluation of content submitted to our translation
> services.
>
> This means developers should not merge new translatable strings into
> MediaWiki Core nor Wikimedia deployed extensions until we re-enable the
> system. This is to prevent longer term issues where local wiki admins
> overwrite a string and thus prevent updates from new and improved
> translations.
>
> We apologize for any inconvenience this delay in service may cause and
> will alert you as soon as this maintenance is completed.
>
> Greg Grossmeier
>
> --
> | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
> | Release Team ManagerA18D 1138 8E47 FAC8 1C7D |
> ___
> Engineering mailing list
> engineer...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/engineering
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Overriding MW core messages via extension

[Alex Monk]

Yeah but it's not pretty - take a look at the first function in
https://github.com/wikimedia/mediawiki-extensions-WikimediaMessages/blob/master/WikimediaMessages.hooks.php


On Thu, 6 Sep 2018, 21:34 James Montalvo,  wrote:

> Is it possible to override messages part of MediaWiki core via an
> extension. I tried adding to an extension's en.json file and that didn't
> seem to work, but am wondering if there's another way.
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Can WMF help CodeMirror with funding?

[Alex Ezell]

Hi all,
I'm the Engineering Manager for the Community Tech team at the Wikimedia
Foundation. Our team did some of the integration work for CodeMirror and
MediaWiki. We are excited about the forthcoming work on CodeMirror and how
it will make working with wikitext in our wikitext editors even easier,
especially on mobile.

We are in contact with the CodeMirror developers and discussing ways we can
help with this new effort. We value the features that CodeMirror brings to
MediaWiki and we value the open source work that the CodeMirror team does.
We don't yet know what form this support will take. There are several
options and we want to ensure we are helping the CodeMirror team in an
impactful way.

I anticipate that you'll hear more about this in the near future.

Alex Ezell
Engineering Manager
Wikimedia Foundation



On Fri, Aug 31, 2018 at 8:49 AM Andre Klapper 
wrote:

> Hi,
>
> On Fri, 2018-08-31 at 17:35 +0300, Saint Johann wrote:
> > Saw this announcement today that CodeMirror is being rewritten with
> > accessibility improvements and mobile support and its developers need
> > funding for it:
> > https://codemirror.net/6/
> >
> > Is there some possibility that WMF could donate to their project?
> > Wikimedia projects use CodeMirror by default as a wiki text syntax
> > highlighter and I have no doubt that this has already helped many people
> > in their work, so supporting this development seems natural for the
> > movement.
>
> please see https://meta.wikimedia.org/wiki/Grants:Project
>
> Thanks,
> 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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Datacenter switchover and switchback

[Alex Monk]

Wiki creation relies on experienced deployers and ops, I would expect they
all know.

On Thu, 30 Aug 2018, 16:49 Pine W,  wrote:

> A couple of additional points came to mind.
>
> 1. Blocking the creation of new wikis sounds like it could be a big deal.
> I know little about the process for getting new wikis approved and
> launched, but I hope that the folks who are regularly involved in these
> processes have been advised of the situation.
>
> 2. In my previous email I may have revealed my level of ignorance about
> the deployment train. Hopefully I didn't come across as presuming to "sound
> smart" about that subject. I know that I am in the presence of experts on
> that subject.
>
> Regards,
>
> Pine
> ( https://meta.wikimedia.org/wiki/User:Pine )
>
>
>
>  Original message From: Pine W 
> Date: 8/30/18  7:57 AM  (GMT-08:00) To: Wikimedia developers <
> wikitech-l@lists.wikimedia.org> Subject: Re: [Wikitech-l] Datacenter
> switchover and switchback
> +1 to DJ's question about timing. Also, one might wish to be mindful of
> the number of recent trains that were supposed to be boring but involved
> interesting surprises; this makes me wonder whether trains that one thinks
> will be boring are actually OK in this circumstance even if they turn out
> to be "interesting".
>
> Pine
> ( https://meta.wikimedia.org/wiki/User:Pine )
>
>
>
>  Original message From: Derk-Jan Hartman <
> d.j.hartman+wmf...@gmail.com> Date: 8/30/18  2:54 AM  (GMT-08:00) To:
> Wikimedia developers  Subject: Re:
> [Wikitech-l] Datacenter switchover and switchback
> While I think these regular switches are a very good idea, from an outside
> perspective I do have to question a process that puts a significant plug in
> the velocity of various teams working on major projects (esp. in a time of
> year that could probably be seen as one of the most productive). What are
> plans to reduce the disruption of this exercise in the future ?
>
> DJ
>
> On Thu, Aug 30, 2018 at 8:38 AM Jaime Crespo 
> wrote:
>
> > Let me explain the rationale of the bellow request for clarification:
> >
> > On Wed, Aug 29, 2018 at 11:30 PM MA  wrote:
> >
> > > Hello:
> > >
> > > >For the duration of the switchover (1 month), deployers are kindly
> > > >requested to refrain from large db schema changes and avoid deploying
> > > >any kind of new feature that requires creation of tables.
> > > >There will be a train freeze in the week of Sept 10th and Oct 8th.
> >
> >
> > During the failover, some schema changes will be finalized on the current
> > active datacenter (plus some major server and network maintenance may be
> > done)- our request is mostly to refrain from quickly enabling those large
> > new unlocked features (e.g. the ongoing comment refactoring, actor/user
> > refactoring, Multi Content Revision, JADE, major wikidata or structured
> > comons structure changes, new extensions not ever deployed to the
> cluster,
> > etc.) at the same time than the ongoing maintenance to reduce variables
> of
> > things that can go bad- enabling those features may be unblocked during
> the
> > switchover time, but we ask you to hold until being back on the current
> > active datacenter. Basically, ask yourself if you are enabling a large
> new
> > core feature or want to start a heavy-write maintenance script and there
> is
> > a chance you will need DBA/system support. Sadly, we had some instances
> of
> > this happening last year and we want to explicitly discourage this during
> > these 2 weeks.
> >
> > In own my opinion, enabling existing features on smaller projects (size
> > here is in amount of server resources, not that they are less important)
> is
> > equivalent to a swat change, and I am not against it happening. I would
> ask
> > contributors to use their best judgement on every case, and ask people on
> > the #DBA tag on phabricator or add me as reviewers on gerrit if in doubt.
> > My plea is to not enable major structural changes during that time may
> > affect thousands of edits per minute. Swat-like changes and "boring" :-)
> > trains are ok.
> >
> > For new wiki creations I would prefer if those were delayed but CC #DBA s
> > on the phabricator task to check with us.
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

[Alex Monk]

It's probably also worth noting that that is not the standard imposed by
the quoted CoC line.

On Tue, 14 Aug 2018, 20:49 Isarra Yos,  wrote:

> Expecting every single comment to specifically move things forward
> seems... a bit excessive, frankly. Not everyone is going to have the
> vocabulary to properly express themselves, let alone the skill to fully
> explain exactly what the issues are, why they are, how to move forward,
> or whatever. And even then, I would argue that having input that isn't
> directly doing any of this can still be useful to indicating to others
> that can that such might indeed be in order, that there is indeed
> sufficient interest to merit the effort, or sufficient confusion that
> there might be more issue than immediately met the eye.
>
> A wtf from one person can help to get others involved to actually
> clarify, or ask followup questions, or what have you. It's not off topic.
>
> -I
>
> On 14/08/18 19:41, Amir Ladsgroup wrote:
> > Hey Petr,
> > We have discussed this before in the thread and I and several other
> people
> > said it's a straw man.
> >
> > The problem is not the WTF or "What the fuck" and as I said before the
> mere
> > use of profanity is not forbidden by the CoC. What's forbidden is
> "Harming
> > the discussion or community with methods such as sustained disruption,
> > interruption, or blocking of community collaboration (i.e. trolling).".
> > [1]  When someone does something in phabricator and you *just* comment
> > "WTF", you're not moving the discussion forward, you're not adding any
> > value, you're not saying what exactly is wrong or try to reach a
> consensus.
> > Compare this with later comments made, for example:
> > https://phabricator.wikimedia.org/T200742#4502463
> >
> > I hope all of this helps for understanding what's wrong here.
> >
> > [1]: https://www.mediawiki.org/wiki/Code_of_Conduct
> > Best
> >
> > On Tue, Aug 14, 2018 at 9:29 PM Petr Bena  wrote:
> >
> >> I am OK if people who are attacking others are somehow informed that
> >> this is not acceptable and taught how to properly behave, and if they
> >> continue that, maybe some "preventive" actions could be taken, but is
> >> that what really happened?
> >>
> >> The comment by MZMcBride was censored, so almost nobody can really see
> >> what it was and from almost all mails mentioning the content here it
> >> appears he said "what the fuck" or WTF. I can't really think of any
> >> language construct where this is so offensive it merits instant ban +
> >> removal of content.
> >>
> >> I don't think we need /any/ language policy in a bug tracker. If
> >> someone says "this bug sucks old donkey's " it may sounds a bit
> >> silly, but there isn't really any harm done. If you say "Jimbo, you
> >> are a f retard, and all your code stinks" then that's a problem,
> >> but I have serious doubts that's what happened. And the problem is not
> >> a language, but personal attack itself.
> >>
> >> If someone is causing problems LET THEM KNOW and talk to them. Banning
> >> someone instantly is worst possible thing you can do. You may think
> >> our community is large enough already so that we can set up this kind
> >> of strict and annoying policies and rules, but I guarantee you, it's
> >> not. We have so many open bugs in phabricator that every user could
> >> take hundreds of them... We don't need to drive active developers away
> >> by giving them bans that are hardly justified.
> >>
> >> P.S. if someone saying "WTF" is really giving you creeps, I seriously
> >> recommend you to try to develop a bit thicker skin, even if we build
> >> an "Utopia" as someone mentioned here, it's gonna be practical for
> >> interactions in real world, which is not always friendly and nice. And
> >> randomly banning people just for saying WTF, with some cryptic
> >> explanation, seems more 1984 style Dystopia to me...
> >>
> >> On Tue, Aug 14, 2018 at 4:08 PM, David Barratt 
> >> wrote:
>  Again, this isn't enwiki, but there would be a large mob gathering at
> >> the
>  administrators' doorstep on enwiki for a block without that context
> and
>  backstory.
> 
> >>> That seems like really toxic behavior.
> >>>
> >>> On Tue, Aug 14, 2018 at 6:27 AM George Herbert <
> george.herb...@gmail.com
> >>>
> >>> wrote:
> >>>
>  I keep seeing "abusers" and I still haven't seen the evidence of the
>  alleged long term abuse pattern.
> 
>  Again, this isn't enwiki, but there would be a large mob gathering at
> >> the
>  administrators' doorstep on enwiki for a block without that context
> and
>  backstory.  That's not exactly the standard here, but ... would
> someone
>  just answer the question?  What happened leading up to this to justify
> >> the
>  block?  If it's that well known, you can document it.
> 
>  On Tue, Aug 14, 2018 at 12:18 AM, Adam Wight 
> >> wrote:
> > Hi Petr,
> >
> > Nobody is language policing, this is about preventing abusive
> 

Re: [Wikitech-l] Making two factor auth less annoying

[Alex Monk]

Yeah I wrote some code that got U2F support working through inside the
OATHAuth extension, though I don't think it ever got to Gerrit.

On Tue, 14 Aug 2018, 10:31 Simon Walker,  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 12/08/18 17:47, Petr Bena wrote:
> > Right now there are only two options for two factor
> > authentication:
> >
> > * Don't use two-factor authentication (insecure) * Use two factor
> > authentication (annoying as hell)
>
> Has any thought been given to supporting alternate methods of 2FA,
> such as the FIDO Universal Second Factor (U2F)?
>
> These reduce the time taken to authenticate the second factor to a
> couple of seconds (plug in, press one button), versus the smartphone
> TOTP apps (unlock phone, open app, find right code in list, type it in).
>
> I'm aware there's a cost to the tokens, and I'm not suggesting there
> be a requirement on them, just an optional alternate for those who
> either already own one or are willing to spend around £10.
>
> GitHub and Google both support U2F as an alternate to TOTP, and either
> method can be used when the second factor is required.
>
>
> Cheers,
>
> Simon
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJbcqFdAAoJELPtp5HPJmI8+gYH/0LPkSS9Uz+yI5Cj5MdbKBR+
> OKesFIbFnNWR6DmBC8CteIItuCqAlopDQ4+GhTpcp3LTIDFE+tIJuDJWpX1l+Smg
> GW0MQ6fj8ZUXETaFZeuEYKVBM6eD1t9c349H6Lv9zJEIUkvHlKq5rOgDijzMiVQa
> aYNBzOrFovdFgbRqh6BfJqNnZJ1CH5cZcAANndzBuv3AzGel/iTxSHzZ36ypmXAu
> wvbc8pJ9hWbVPPUwX8RIOmYKTUsfmLCzgySJMyMnkUJgRWB0h2ox1U3bszUZQzvD
> uLUZMR8Hv6/oIB6fHr6NWbMDVCg13a10pHNak7fSrlE7h1WKIOwe12Ixw8muYJQ=
> =y0jr
> -END PGP SIGNATURE-
>
> ___
> 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] My Phabricator account has been disabled

[Alex Monk]

Given the nature of the email it should be (treated as) comprehensive.

And in the absence (thus far) of the text being denied by the author, and
the recipient/forwarder being a known Wikimedian, I'm inclined to believe
that really was what was written.

Otherwise we would have almost no means to review decisions of the
committee.

On Wed, 8 Aug 2018, 16:36 Isarra Yos,  wrote:

> This is actually a rather good point, and one I would argue also shows
> why we need more transparency from the CoC committee in the first place
> - lacking that, all the community at large can really go on is what the
> accused provides, which does no favours toward the effectiveness of any
> actions taken, especially if said actions really were justified.
>
> -I
>
> On 08/08/18 15:26, Lucas Werkmeister wrote:
> > Can we please avoid jumping to conclusions like “Ladsgroup [was]
> enforcing
> > the CoC out of their personal feelings” or that this was an “immediate
> > escalation”, when the only information we have in this thread is a quoted
> > email that the author probably never intended to be a comprehensive
> summary
> > of the situation in the first place, and which was only relayed to this
> > list through a non-neutral party?
> >
> > Cheers,
> > Lucas
> >
> > Am Mi., 8. Aug. 2018 um 16:45 Uhr schrieb Dan Garry <
> dga...@wikimedia.org>:
> >
> >> On 8 August 2018 at 14:29, Alex Monk  wrote:
> >>
> >>> Are you trying to ban people discussing CoC committee decisions
> publicly?
> >>> Not that it even looks like he wrote grievances.
> >>
> >> Hardly. I have absolutely nothing to do with the administration of this
> >> list, nor the authority to set what is discussed on this list, nor any
> >> involvement in the Code of Conduct, all of which you are well aware.
> >>
> >> Dan
> >>
> >> --
> >> Dan Garry
> >> Lead Product Manager, Editing
> >> Wikimedia Foundation
> >> ___
> >> Wikitech-l mailing list
> >> Wikitech-l@lists.wikimedia.org
> >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> >
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

[Alex Monk]

Are you trying to ban people discussing CoC committee decisions publicly?
Not that it even looks like he wrote grievances.

On Wed, 8 Aug 2018, 14:23 Dan Garry,  wrote:

> On 8 August 2018 at 13:53, MZMcBride  wrote:
> >
> > Ah, I found the e-mail: […]
> >
>
> This mailing list is not an appropriate forum for airing your grievances
> with the way the Code of Conduct Committee has handled this matter.
>
> Dan
>
> --
> Dan Garry
> Lead Product Manager, Editing
> 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] My Phabricator account has been disabled

[Alex Monk]

So are we supposed to be careful about using 'wtf' now?

On Wed, 8 Aug 2018, 13:53 MZMcBride,  wrote:

> Amir Ladsgroup wrote:
> >I disabled the account and now I disabled it again. It's part of a CoC
> >ban. We sent the user an email using the "Email to user" functionality
> >from mediawiki.org the moment I enforced the ban.
> >
> >We rather not to discuss details of cases publicly but I feel this
> >clarification is very much needed.
>
> Ah, I found the e-mail:
>
> > Subject: Temporarily ban from phabricator
> >
> > Hello,
> >
> > We received reports about your comments in phabricator. While we
> >encourage criticism and productive comments to improve the software,
> >comments like "What the fuck" do not contribute to the discussion and
> >turns the discussion from respectful criticism to folks swearing at other
> >folks.
> >
> >
> > We asked you to stop making such comments that do not contribute to the
> >discussion. We have no choice to issue a temporarily ban from
> >phabricator. We hope you notice this type of behaviour is not welcome in
> >our technical spaces.
> >
> > Please read Code of conduct in depth:
> >https://www.mediawiki.org/wiki/Code_of_Conduct
> >
> > Best
> >
> > This email was sent by TechConductCommittee to MZMcBride by the "Email
> >this user" function at MediaWiki. If you reply to this email, your email
> >will be sent directly to the original sender, revealing your email
> >address to them.
>
> This is re: .
>
> Greg Varnum created a mess, inappropriately closed a valid bug, and
> removed its parent task because he didn't want to even acknowledge the
> bug. I expressed exasperation with his actions, particularly gaslighting
> volunteers (cf.
>  >
> ), and Greg then removed himself as the task assignee and hasn't responded
> on either the task or the wikimedia-l mailing list since. And there's
> still German text prominently and confusingly at the top of
> . Amazing.
>
> MZMcBride
>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

[Alex Monk]

If there isn't any logging of this stuff how do we know it's your anti
vandalism bot and not a rogue admin?

On Wed, 8 Aug 2018, 01:17 Mukunda Modell,  wrote:

> I think you were a victim of a false-positive with the anti-vandalism tech
> that's been recently deployed in phabricator.
> Unfortunately there isn't a log entry to verify that fact because the
> logging function hasn't been deployed yet.
>
> Regardless, I've re-enabled your account.
>
> I apologize for the inconvenience, I'll make some adjustments to the filter
> to hopefully prevent more false positives.
>
> On Tue, Aug 7, 2018 at 6:28 PM MZMcBride  wrote:
>
> > Hi.
> >
> > My Phabricator account has been disabled. I don't seem to have any e-mail
> > about this action, so I'm mostly just curious who did it and why. If
> > there's a log entry somewhere, that would be nice, but I don't know how
> > transparent Phabricator or its admins are. I suppose it would also be
> nice
> > to know if the person ever plans on undoing this unexplained disablement.
> >
> > I have over 56,000 unread e-mails in my "Phabricator" folder, so if I've
> > overlooked an explanatory e-mail, please let me know!
> >
> > In the meantime, I guess I'll just, uhh, log out to view Phabricator.
> >
> > MZMcBride
> >
> >
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for removal without deprecation of MagicWord::clearCache

[Alex Winkler]

So to give my perspective as an "outsider":

My day to day job is to write MediaWiki extensions for a wiki-farm 
called Liquipedia. We are mostly hopping LTS version, so even 
deprecation for two versions doesn't necessarily mean much to us here. 
Generally I just install a new MediaWiki version on dev and then test 
all of our extensions thewre until they work, without bothering the live 
version of our wikis.


The talk here seems to be mostly about people that "blindly" upgrade 
their wiki, and I agree there will always be issues with those, no 
matter the deprecation method. If you don't update to every version, you 
might never see a deprecation notice, as the next version you are 
upgrading to is not necessarily the next version of MediaWiki released, 
and if you are updating to every version you might still not be able to 
fx your own extensions or you might not even check for deprecation 
notices (mind they only show up with the right dev params).


I totally agree on directly removing functions that have been 
functionless for years like the one we had recently that didn't work 
since sometime 2009 or so, no question about that, but I'm not so sure 
about working functions.


There is a lot of consideration going into writing MediaWiki extensions, 
and there might be good reasons to not host a MediaWiki extension on 
Wikimedia git repositories. I have seen very specialized MediaWiki 
extensions that would not work without outside code (especially 
extensions allowing login with outside userdatabases and extensions 
querying certain internal APIs come to mind), so I don't think using 
only Wikimedia hosted repositories is a good indication. Generally I 
think deprecation periods that are supposed to actually be helpful 
should always pass at least one LTS release, as those reach a bigger 
audience.


Deprecation wise, I personally feel like it only makes a difference if 
deprecations always survive the next LTS release, as most less regular 
wiki owners are likely to jump LTS versions. If there is no waiting for 
LTS releases, then deprecation is somewhat pointless in my point of 
view, since these policies are mostly in place for third party wikis.


I hope this point of view is helpful to you, if there are any further 
questions regarding our own workflow, feel free to ask and I'll try to 
answer to the best of my ability.


Alex "FO-nTTaX" Winkler

Head of Liquipedia Development
https://liquipedia.net/ - https://www.teamliquid.com/

Am 31.07.2018 um 14:53 schrieb Aryeh Gregor:

On Tue, Jul 31, 2018 at 3:46 PM, Stephan Gambke  wrote:

I agree that there is a trade-off to be done.
I disagree about expecting code to be put where it is visible to core
developers. I do appreciate that you go and look for where the
functionality that you are working on is used outside core. But
ultimately MW is publishing a public interface and it is unreasonable
to expect all consumers of that interface to "register" and publish
their code as well.

We don't, but if they don't publish it we have to guess at what will
or won't break it, which means there's a higher chance that we will
break it.


The difference is that in that case the test would have run through,
throwing just a notice and the call to the deprecated function could
have been removed another day.

Hard-deprecation fails the test completely, right?


Of course, if they did not want to deal
with breakages, that maintainer should not have pulled MW master in
the first place and should have just worked on whatever MW version
they left off of a few months ago when they last worked on their
extension.

Correct, we do not and should not go out of our way to make life easy
for people running unstable MediaWiki.  It's not meant for production
unless you're following development closely and are prepared to deal
with breakage.


True. I don't know how other people do it, but I usually only scan the
release notes for big changes and otherwise rely on deprecation notes
to pop up. Doing otherwise would require me to maintain a register of
all MW core functions called from my extensions and cross-checking it
by hand.

Indeed, but as soon as you see the error message, it's easy to check
the release notes/history to figure out what to do.
Deprecation/removal notices there should say what the replacement is
as clearly as possible.  (If they don't, that's a separate problem.)

___
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] Additional European-appropriate MediaWiki train window starting week of July 9th (also SWAT change)

[Alex Monk]

Well yes, but so will the rest of the world that uses DST.

On Wed, 11 Jul 2018, 21:04 Brad Jorsch (Anomie), 
wrote:

> My point was that if CA and Europe accepts those proposals then the rest
> of the US that still uses DST would have the problem that things would move
> around when DST starts or ends, so it just moves the problem around instead
> of really getting rid of it.
>
> On Wed, Jul 11, 2018 at 4:01 PM, Alex Monk  wrote:
>
>> As long as these get pinned to SF time what the rest of the US does with
>> regards to DST is irrelevant. If California drops DST then it no longer
>> affects deployments pinned to SF time.
>>
>> On Wed, 11 Jul 2018, 19:42 Brad Jorsch (Anomie), 
>> wrote:
>>
>>> On Wed, Jul 11, 2018 at 12:19 PM, Kunal Mehta 
>>> wrote:
>>>
>>>> (un)relatedly:
>>>> * EU survey to remove summertime/DST:
>>>> <
>>>> https://ec.europa.eu/eusurvey/runner/2018-summertime-arrangements?surve
>>>> ylanguage=EN
>>>> <https://ec.europa.eu/eusurvey/runner/2018-summertime-arrangements?surveylanguage=EN>
>>>> >
>>>> * California Proposition 7 (2018) to institute a permanent DST:
>>>> <
>>>> https://ballotpedia.org/California_Proposition_7,_Permanent_Daylight_Sa
>>>> ving_Time_Measure_(2018
>>>> <https://ballotpedia.org/California_Proposition_7,_Permanent_Daylight_Saving_Time_Measure_(2018>
>>>> )>
>>>>
>>>> Hopefully we can get rid of this problem at the root cause as well :)
>>>>
>>>
>>> You forgot about most of the rest of the US ;)
>>>
>>>
>>> --
>>> Brad Jorsch (Anomie)
>>> Senior Software Engineer
>>> Wikimedia Foundation
>>> ___
>>> Engineering mailing list
>>> engineer...@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/engineering
>>>
>>
>
>
> --
> 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] [Engineering] Additional European-appropriate MediaWiki train window starting week of July 9th (also SWAT change)

[Alex Monk]

As long as these get pinned to SF time what the rest of the US does with
regards to DST is irrelevant. If California drops DST then it no longer
affects deployments pinned to SF time.

On Wed, 11 Jul 2018, 19:42 Brad Jorsch (Anomie), 
wrote:

> On Wed, Jul 11, 2018 at 12:19 PM, Kunal Mehta 
> wrote:
>
>> (un)relatedly:
>> * EU survey to remove summertime/DST:
>> > ylanguage=EN
>> 
>> >
>> * California Proposition 7 (2018) to institute a permanent DST:
>> > ving_Time_Measure_(2018
>> 
>> )>
>>
>> Hopefully we can get rid of this problem at the root cause as well :)
>>
>
> You forgot about most of the rest of the US ;)
>
>
> --
> Brad Jorsch (Anomie)
> Senior Software Engineer
> Wikimedia Foundation
> ___
> Engineering mailing list
> engineer...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/engineering
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Phabricator spam - account approval requirement enabled

[Alex Monk]

Yes, though careful because CommunityTechBot shows up as a subscriber to
lots of tasks now which are getting comments from other people, so it
appears on the Cc list at the bottom of each email notification.

On 2 July 2018 at 19:06, Ed Sanders  wrote:

> +100
>
> Also a tip for those of you wanting to clear up the resulting email spam:
> you can temporarily turn off "conversation mode" in Gmail's settings, then
> search for messages from CommunityTechBot or the spammer, and delete all
> these emails without having to delete the threads they belong too.
>
> On Mon, 2 Jul 2018 at 18:18, Joel Aufrecht 
> wrote:
>
>> Thank you Leon for this heroic effort, and thanks to everyone who helped
>> in this cleanup.
>>
>> On Mon, Jul 2, 2018, 9:58 AM Leon Ziemba 
>> wrote:
>>
>>> The bot has now completed it's run. If you see any outstanding tasks
>>> that need to be repaired, please give me the task IDs.
>>>
>>> The bot ran for roughly 36 hours, repairing at least 4,000 tasks
>>> (perhaps many more).
>>>
>>> There were some issues with the bot that may still affect your tasks:
>>> * The triage level was not restored, or was put in "Needs triage". This
>>> was fixed around 16:00 UTC on July 1. Hundreds of tasks were affected.
>>> * For most of the bot's run, it was subject to a newly imposed rate
>>> limiting. If the rate limit was hit in the middle of repairing a task, the
>>> bot may not have fixed everything. Many tasks were affected. This issue was
>>> fixed around 15:00 UTC on July 1.
>>> * For some tasks, the vandal removed tags as well adding some. The bot
>>> did not properly restore the removed tags until around 12:00 UTC on July 2.
>>> The number of tasks affected by this is estimated to be low.
>>> * Some tasks have "custom fields" that were vandalized, which the bot
>>> did not restore. An example is the "due date" on
>>> https://phabricator.wikimedia.org/T193593. The number of tasks affected
>>> by this should be very low.
>>>
>>> If you notice any tasks where the bot didn't fix everything, and you
>>> don't want to fix it yourself, just give me the task IDs and I can re-run
>>> the bot on those.
>>>
>>> Thanks to Andre, Mukunda, and everyone else to helped with this effort.
>>>
>>> ~Leon
>>>
>>> On Sun, Jul 1, 2018 at 8:49 PM Mukunda Modell 
>>> wrote:
>>>
 Hi Leon. I can't thank you enough for your efforts to help clean things
 up in Phabricator.  I can, however, help make the bot more effective. See
 below for responses inline.

 On Sun, Jul 1, 2018 at 10:47 AM Leon Ziemba 
 wrote:

> An update... the bot went to sleep as instructed a few hours after I
> went to sleep. Bot is now back up and running, with some ~4,500 tasks 
> still
> to fix.
>
> A few problems:
> * The new "rate limiting" of the API is rather rigorous. Release
> engineering tried to whitelist the bot but we had no luck. So, it will 
> take
> some time to go through everything.
>

 I'm still looking into why the bot hits the rate limit. I'm sure I can
 come up with a way to get it whitelisted.


> * If the bot hits the rate limit while editing a task, all other
> changes it was going to make to that task didn't happen. Hence you may see
> only some corrections on some tasks.
> * The priority level is now being set to "Needs triage". This is
> because the Conduit API gives me numbers for the priority level, and the
> edit API wants a string (?!?). I don't know what numbers are for what
> priorities, so "Needs triage" it is. Older versions of the script left the
> priority level unchanged, so either way you may wish to review the
> priorities of your tasks. If you know what the priority number to string
> mapping is, please tell me :)
>
>
 If you would like to alter the bot to restore the correct priority,
 this should help; The priority levels are configured as follows:

 {
   "10": {
 "color": "sky",
 "keywords": [
   "lowest"
 ],
 "name": "Lowest",
 "short": "Lowest"
   },
   "25": {
 "color": "yellow",
 "keywords": [
   "low"
 ],
 "name": "Low",
 "short": "Low"
   },
   "50": {
 "color": "orange",
 "keywords": [
   "normal"
 ],
 "name": "Normal",
 "short": "Normal"
   },
   "80": {
 "color": "red",
 "keywords": [
   "high"
 ],
 "name": "High",
 "short": "High"
   },
   "90": {
 "color": "violet",
 "keywords": [
   "triage"
 ],
 "name": "Needs Triage",
 "short": "Triage"
   },
   "100": {
 "color": "pink",
 "keywords": [
   "unbreak"
 ],
 "name": "Unbreak Now!",
 "short": "Unbreak!"
   }
 }



 Cheers,
>
> ~Leon
>
> 

Re: [Wikitech-l] Extension registration dependencies towards skins

[Alex Winkler]

Hi Florian,

that would work for me as well, I'm just not sure on the procedures in 
the MediaWiki community. If just fixing it like that works for everyone, 
then I'm more than happy with it going through like this.


Alex "FO-nTTaX" Winkler

Head of Liquipedia Development
https://liquipedia.net/ - https://www.teamliquid.com/

Am 15.06.2018 um 17:43 schrieb Florian Schmidt:

Hi Alex!

Thanks for your e-mail and for bringing this up to the list :) This actually seems to be 
a bug to me, as the key should be skins (as stated in the schema as well as in the 
function doc block), however, it is named "skin", which is false. As such, I 
would bring in another option (apart from what you already suggested): Fix it :) As a 
bug, and as the schema is actually correct, all extensions using the depend on skins 
functionality of extension registration will either fail to use the extension.json as an 
exception is thrown during processing the registration file, or otherwise will fail the 
validation (validateRegistrationFile.php),[1] which should be the base check for each 
extension developer to see if the extension matches standard.

My suggestion is:
* Open a bug for it (see -> https://phabricator.wikimedia.org/T197478)
* Fix the bug in master
* Backport the fix to the supported releases and let the fix roll out with the 
next minor release (if the release manager agrees)

Is that ok for you, too? :)

Best,
Florian

-Ursprüngliche Nachricht-
Von: Wikitech-l  Im Auftrag von Alex 
Winkler
Gesendet: Freitag, 15. Juni 2018 16:42
An: wikitech-l@lists.wikimedia.org
Betreff: [Wikitech-l] Extension registration dependencies towards skins

Hello together,

I'm currently working on upgrading some wikis to Mediawiki 1.31, and I've been 
reading the manual on extension dependencies. It is clearly stated at
https://www.mediawiki.org/wiki/Manual:Extension_registration#Requirements_(dependencies)
that skins can be required with the key "skins", however looking at git and the change in 
gerrit, the key is actually implemented as "skin"
https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/250060/33/includes/registration/VersionChecker.php.
The change in itself is inconsistent, as it adds both documentation and actual 
code which are not compatible to each other.

I've been wondering if it is just the documentation being wrong or the key 
being typo'd ever since 1.29, considering the extensions dependency key is 
inplural I'd tend to think the key is typo'd ever since 1.29.

Question would then be how to resolve this. The best way would probably be to deprecate the "skin" 
key and implement "skins" as a key, and remove "skin" with the next major release (1.32), 
as I don't think the actual behaviour should be changed mid-release.

--
Alex "FO-nTTaX" Winkler

Head of Liquipedia Development
https://liquipedia.net/ - https://www.teamliquid.com/


___
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] Extension registration dependencies towards skins

[Alex Winkler]

Hello together,

I'm currently working on upgrading some wikis to Mediawiki 1.31, and 
I've been reading the manual on extension dependencies. It is clearly 
stated at 
https://www.mediawiki.org/wiki/Manual:Extension_registration#Requirements_(dependencies) 
that skins can be required with the key "skins", however looking at git 
and the change in gerrit, the key is actually implemented as "skin" 
https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/250060/33/includes/registration/VersionChecker.php. 
The change in itself is inconsistent, as it adds both documentation and 
actual code which are not compatible to each other.


I've been wondering if it is just the documentation being wrong or the 
key being typo'd ever since 1.29, considering the extensions dependency 
key is inplural I'd tend to think the key is typo'd ever since 1.29.


Question would then be how to resolve this. The best way would probably 
be to deprecate the "skin" key and implement "skins" as a key, and 
remove "skin" with the next major release (1.32), as I don't think the 
actual behaviour should be changed mid-release.


--
Alex "FO-nTTaX" Winkler

Head of Liquipedia Development
https://liquipedia.net/ - https://www.teamliquid.com/


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

Re: [Wikitech-l] Gerrit as a shared community space

[Alex Monk]

And that's fine and good and should continue, but doesn't mean it's a
shared ownership model. As I was saying before with the analogy, global
users make uncontroversial edits using their rights but aren't supposed to
use their global rights to involve themselves in controversies.

On 9 June 2018 at 19:06, Kunal Mehta  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi,
>
> CoC.md business aside, I agree with the main thing you've said.
> Specifically:
>
> On 06/09/2018 08:58 AM, Brion Vibber wrote:
> > I think we should though clarify that code repositories on gerrit
> > and diffusion are not owned by any one person, but are technical
> > community spaces held in common for the benefit of the Wikimedia
> > movement. And yes, that means sometimes your favorite project will
> > get documentation commits you personally didn't like.
>
> 100% agreed. We[1] do a lot of maintenance work across mediawiki/*
> repositories, whether it be rote cleanup, CI fixes, fixing deprecated
> things, etc. I'd like to think that 98% of the things we do in this
> area are uncontroversial, and to be honest, boring.
>
> I think it's important that we retain this shared ownership model.
>
> [1] Where "we" are people who are not the main maintainer nor the
> original author of the repository.
>
> - -- Legoktm
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEE+h6fmkHn9DUCyl1jUvyOe+23/KIFAlscFz0ACgkQUvyOe+23
> /KKkPw//aaqo7s4zAlrNVUYbv/q3+uu1811/8OfeKm2AliM/1vfsNQOMJNAaWWzS
> cHxSfjH95BsCpdrJUZQHh7LviBqbaB6Soa73p8k86JEykyaNIN93fvzOx5U+hFLG
> vNHthcxoXB9BcDzUK7MJv+sR2CraIlFWu1Wm3RBxdQTu/Qf1V4+we6aPbcCMn28p
> akStbaM+7k3YSnp+ZiC0vnfUnWzkFL7XjN0fzW2NCyOwwxDk1Lma5mzY33gzjAWw
> x6W1heilHW52wH/FcyWLIjbA4lQIL9u35WJKmMkgaCuSxjL+nw5+LNf0WICB7Qud
> B6YdC7GndTpm5sBQ7804s5O+Se/ltWbhJGeoyP164MsHocG+jCmrEscCLeK+p/w1
> ryl104EYrSmYqtvH8A6q1aa154TIjVWSHusQrjkEXBCzXopdljMnTwn2Y+UcJDTp
> fz7cDoTKMhmghSISyzLn7rsgG7/a6Ma7aZ72IFWIXC7epnvo6eMFTV34ACPy8afE
> azTC0Es5XCGDd4xxa/ItPhUF8OpMehwJ7/3Vu7SSsCKgXrUzBPoEGs2OE+4kC2pG
> AyGqilT8hRlXKKHElIjvxR/CmxXk3l4mwg3DL6gOIAcVKRhyQjPlsUqL3LUQL+H7
> dgbr0mOq/8BpBTjTxo7VOuXOyYwn9XiKfvBQAwIFWQa4sgkzK/I=
> =ACa6
> -END PGP SIGNATURE-
>
> ___
> 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] Gerrit as a shared community space

[Alex Monk]

On 9 June 2018 at 18:14, Brion Vibber  wrote:

> On Sat, Jun 9, 2018 at 10:00 AM Alex Monk  wrote:
>
> > This is outrageous. Not only are you blatantly misrepresenting what
> various
> > people are saying in the other thread and their intentions,
>
>
> Perhaps. I've tried to go by the plain readings of position statements and
> I could have made a mistake?
>

 For example where you said "IMHO specifically because some people are
trying to avoid being bound by it or protesting its existence by looking
for loopholes to avoid it", which is not at all what that thread is about
as has been made very clear in that thread.

On 9 June 2018 at 18:14, Brion Vibber  wrote:

> you are now
> > suggesting that repository owners do not in fact get to decide what goes
> in
> > their repository and what does not, as if this has been the case all
> along.
>
>
> Yes I'm definitely explicitly saying that. Same applies to pages on
> Wikipedia: you don't get to own them and veto others' clarifications. And
> sometimes an admit makes an edit stick that you don't like.

This is a bad analogy. Repository owners *are* essentially the admins, and
in this case get content control. The people involving themselves are more
akin to global users like stewards trying to override local admin actions,
and in this case they're not really supposed to have such control of
content. Like with on-wiki stuff, it's not really so bad when a global user
comes and does uncontroversial cleanup, but global permissions are not for
the purpose of involving oneself in local controversy.

On 9 June 2018 at 18:14, Brion Vibber  wrote:

> > It is incredibly ironic how against the spirit of the CoC this all is.
>

>
> Can you clarify?
>

Making Wikimedia technical spaces less welcoming to outsiders.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit as a shared community space

[Alex Monk]

This is outrageous. Not only are you blatantly misrepresenting what various
people are saying in the other thread and their intentions, you are now
suggesting that repository owners do not in fact get to decide what goes in
their repository and what does not, as if this has been the case all along.
It is incredibly ironic how against the spirit of the CoC this all is.

On 9 June 2018 at 16:58, Brion Vibber  wrote:

> Recent threads have demonstrated there seems to be some disconnect about
> what is expected about maintainership and ownership of repositories.
>
> This has spilled over into talk about the code of conduct, IMHO
> specifically because some people are trying to avoid being bound by it or
> protesting its existence by looking for loopholes to avoid it. Which I
> think is a shame, but I don't expect much constructive talk to come out of
> that thread.
>
> I think we should though clarify that code repositories on gerrit and
> diffusion are not owned by any one person, but are technical community
> spaces held in common for the benefit of the Wikimedia movement. And yes,
> that means sometimes your favorite project will get documentation commits
> you personally didn't like.
>
> If this has been unclear, it should be made clear. If that means some
> people host their self-maintained code outside of Wikimedia technical
> spaces, then that is their decision and I respect it.
>
> If some kind of official kerfluffle is needed to decide this, let's talk
> about how to do that.
>
> -- brion
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Can/should my extensions be deleted from the Wikimedia Git repository?

[Alex Monk]

On Fri, 8 Jun 2018, 17:08 Chris Koerner,  wrote:

> > You probably meant just "README". This is an interesting comparison. So,
> if
> > an extension lacks a README file, and that extension's maintainer refuses
> > to put one in, should the extension be deleted from the Wikimedia
> > repository?
>
> Let's back away from the ledge of deleting stuff. I'm not arguing for that
> here.
>
> What I'm trying to get across (text lacks subtly) is that the
> community is asking for you to include this file.


Where? So far it's been a few individuals.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Can/should my extensions be deleted from the Wikimedia Git repository?

[Alex Monk]

I think Gerrit admin permissions were abused to remove the review

On Fri, 8 Jun 2018, 11:57 Nischay Nahata,  wrote:

> It did sound like a threat given that no policy has been framed around
> this, but I am glad to know that it was not your intent.
>
> Also, its strange that someone can just remove someone else's code review
> just like that on gerrit, add their own review and merge a patch.
>
>
> Regards,
> Nischay Nahata
>
>
> On Fri, Jun 8, 2018 at 3:46 PM Antoine Musso  wrote:
>
> > On 08/06/2018 06:33, Nischay Nahata wrote:
> > >  I think that advertising the COC might still have been in "good
> faith",
> > > though it should have been done with a mail to the project owners.
> > >
> > > But what I find very objecting is the way the two developers have
> > > communicated on the gerrit thread. Both Antoine and Chad (both senior
> > devs
> > > that we used to look up to) behaved in a rather dictatorish manner
> which
> > is
> > > not even seen around profit making companies. Neither cared to explain
> > and
> > > discuss on the issue, while Yaron was trying his best to.
> >
> > Hello,
> >
> > I disagree with the dictatorship manner, or I would just have force
> > merged my own patch. I was more waiting for feedback from the repository
> > owner and engage in a conversation.
> >
> > I don't have an opinion about the CODE_OF_CONDUCT.md beside that it has
> > been added on all mediawiki repositories hosted on Gerrit and that it
> > became the de factor standard on GitHub.  I just happened to notice the
> > file was missing and for sack of consistency proposed a change to
> > restore it.
> >
> >
> > About my comment on Gerrit:
> >
> > | Well then can we just archive this repository please?
> >
> > I was reacting to Yaron comment about development happening somewhere
> else:
> > | @Ladsgroup - not all of the development of this software is done on
> > gerrit.wikimedia.org (actually, very little of it is).
> >
> > With the hasty conclusion on my side that: if the development is not on
> > Gerrit and Yaron doesn't want the COC.md file, he should be free to move
> > to a different hosting place.
> >
> > In restrospective, I got how that could sound as a threat to arbitrarily
> > delete the repository.  *Yaron I apologize*, that never has been my
> intent.
> >
> > One sure thing, I am quite happy the topic get raised to wikitech-l
> > which has a much larger audience than a single Gerrit change.  We will
> > see what the outcome happens to be.
> >
> > cheers,
> >
> > --
> > Antoine Musso
> >
> >
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Phabricator monthly statistics - 2018-03

[Alex Monk]

I thought it was pretty unambiguous already...

On Sun, 1 Apr 2018, 15:14 יגאל חיטרון,  wrote:

> I see, thank you. But maybe you should change it from Differential to
> *Differential* or something, for the next one that will confuse.
> Igal
>
>
> On Apr 1, 2018 04:23, "James Hare"  wrote:
>
> 19 Differential users seems believable to me, since as far as I know we
> don't use Differential that much. (Differential is the code review tool
> within Phabricator.)
>
>
>
> 
> James Hare
> Associate Product Manager
> Wikimedia Foundation
> https://wikimediafoundation.org
>
> On Sat, Mar 31, 2018 at 5:10 PM, יגאל חיטרון  wrote:
>
> > Hello and thank you. But only 19 users? Are you sure?
> > Igal (User:IKhitron)
> >
> >
> > On Apr 1, 2018 03:00,  wrote:
> >
> > >
> > > Hi Community Metrics team,
> > >
> > > This is your automatic monthly Phabricator statistics mail.
> > >
> > > Accounts created in (2018-03): 426
> > > Active Maniphest users (any activity) in (2018-03): 975
> > > Task authors in (2018-03): 560
> > > Users who have closed tasks in (2018-03): 278
> > >
> > > Projects which had at least one task moved from one column to another
> on
> > > their workboard in (2018-03): 281
> > >
> > > Tasks created in (2018-03): 2586
> > > Tasks closed in (2018-03): 2140
> > > Open and stalled tasks in total: 38023
> > >
> > > Median age in days of open tasks by priority:
> > >
> > > Unbreak now: 76
> > > Needs Triage: 388
> > > High: 653
> > > Normal: 900
> > > Low: 1167
> > > Lowest: 1113
> > >
> > > (How long tasks have been open, not how long they have had that
> priority)
> > >
> > > Active Differential users (any activity) in (2018-03): 19
> > >
> > > 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 Sun Apr  1 00:00:26 UTC 2018)
> > >
> > > ___
> > > Wikitech-l mailing list
> > > Wikitech-l@lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

[Alex Monk]

On Sat, 17 Mar 2018, 18:16 Chico Venancio, <chicocvenan...@gmail.com> wrote:

> Alex Monk wrote:
> I don't think the communities actually want js injected without code-review
> that much. They (we) do want to have easy access to gadget and scripts
> though.
> Attempting to impose any procedure that messes with that access and/or does
> not give the communities final say in what is used will probably have a
> serious backlash. But if we could have a reasonable code-review that does
> not mean communities will not have access to gadgets and scripts, it will
> probably pass with most of the communities not caring.
>

I'm not convinced that a solution acceptable to everyone exists. A code
review system requiring approval of changes to more dangerous pages would
probably have to allow local sysops to approve (for communities to accept
it), but I don't see a code review system being useful unless the reviewers
are chosen for technical skill and knowledge of Wikimedia coding
conventions.
And even if the large wikis were happy to have such a criteria, it's
relatively easy for us to talk about that in English and German, but I
think a lot of wikis in more obscure languages won't have enough people
fitting that criteria.

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

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

[Alex Monk]

d. Of all the places you're likely to run into trouble,
> Wikimedia
> > > wikis are, in many ways, some of the safest. Given all of this code,
> your
> > > computer, as well as mine, are vulnerable to dozens of very real
> attacks
> > > at any time. And yet we soldier on without too much panic or worry.
> > >
> > > >Has this sort of thing happened before?
> > >
> > > Salon.com recently prompted users with ad blocking software installed
> to
> > > voluntarily mine cryptocurrency: <https://arstechnica.com/?p=1259653>.
> > > This situation on fa.wikipedia.org was obviously involuntary. I don't
> > know
> > > of any similar incidents. We have had wiki administrators inadvertently
> > > inject scripts with privacy issues, such as Google Analytics. These
> > > scripts have generally been promptly removed when noticed. On the other
> > > hand, pages such as <https://status.wikimedia.org/> have been loading
> > the
> > > same problematic scripts (Google Analytics and JavaScript from
> > > ajax.googleapis.com) for years and nobody seems to have cared enough
> > yet.
> > >
> > > >Can we be sure there isn't a gadget, interface page that has this sort
> > of
> > > >code lurking inside? Do we have any detection measures in place?
> > >
> > > A much surer bet is that at least some gadgets and other site-wide
> > > JavaScript have privacy issues and potentially security issues. It
> would
> > > be shocking if, across the hundreds of Wikimedia wikis, none of them
> did.
> > >
> > > I think in the past Timo and maybe Alex Monk have done some surveying
> of
> > > public Wikimedia wikis using a browser or browser emulator to check if
> > > there are network requests being made to non-Wikimedia domains. As
> Lucas
> > > noted in this thread already, there are also tasks such as
> > > <https://phabricator.wikimedia.org/T135963> that could be worked on,
> if
> > > there's sufficient interest.
> > >
> > > MZMcBride
> > >
> > >
> > >
> > > ___
> > > Wikitech-l mailing list
> > > Wikitech-l@lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] News about TLS 1.3

[Alex Monk]

I read the Cloudflare section on middleboxes and I wonder if it was really
a good idea for them to go making changes to allow for existing boxes to do
that. They are not legitimate parties to a TLS connection and browsers and
websites should not have to change how they communicate to deal with their
nonsense. They should just break.

On Wed, 7 Mar 2018, 05:05 Pine W,  wrote:

> I'm no expert on TLS 1.3, but I thought that other folks on Wikitech-l
> might be interested in the industry news about the subject. The relevant
> WMF Phabricator task is https://phabricator.wikimedia.org/T170567.
>
> Articles:
>
> * "An Overview of TLS 1.3 – Faster and More Secure":
> https://kinsta.com/blog/tls-1-3/
>
> * "Why TLS 1.3 isn't in browsers yet":
> https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet/
>
> * "Big banks want to weaken the internet’s underlying security protocol":
> https://www.cyberscoop.com/tls-1-3-weakness-financial-industry-ietf/. WMF
> employees who do advocacy work might be interested in this article, which
> is why I'm sending this email to WMF Legal.
>
> Regards,
>
> Pine
> ( https://meta.wikimedia.org/wiki/User:Pine )
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikidata vandalism dashboard (for Wikipedians)

[Alex Monk]

Sorry, hit the wrong button with the previous email. I got an error when I
tried this with language code 'En' (my phone wanted that) instead of 'en'.

On 29 Jan 2018 22:00, "Alex Monk" <kren...@gmail.com> wrote:

>
> On 29 Jan 2018 18:51, "Eran Rosenthal" <eranro...@gmail.com> wrote:
>
>> Good idea, and thanks for sharing.
>>
>> Ideas for improvement:
>> 1. Missing reference - the list by itself is not sufficient to determine
>> whether some edit is bad or not, as there is no reference (Qid is not
>> meaningful).
>> It would be nice to have another column with "reference" value to
>> compare - either different language (en or fallback lang) or prev value
>> 2. " /* wbsetlabel-add:1|he */ " or " /* wbsetlabel-set:1|he */" should be
>> formatted to human readable format/removed/replaced with icon.
>> 3. (dreaming) How awful would it be to move it to mediawiki itself (e.g
>> implement ChangesListStringOptionsFilterGroup /
>> ChangesListStringOptionsFilter [T176515
>> <https://phabricator.wikimedia.org/T176515>])
>> doing regex queries on non indexed summary column of recent changes?
>>
>> On Mon, Jan 29, 2018 at 6:48 PM, Dayllan Maza <dm...@wikimedia.org>
>> wrote:
>>
>> > This is great. Thank you for sharing
>> >
>> > On Mon, Jan 29, 2018 at 7:07 AM Amir Ladsgroup <ladsgr...@gmail.com>
>> > wrote:
>> >
>> > > It's tracked in: https://github.com/Ladsgroup/
>> > Vandalism-dashboard/issues/2
>> > >
>> > > On Sun, Jan 28, 2018 at 11:26 PM Magnus Manske <
>> > > magnusman...@googlemail.com>
>> > > wrote:
>> > >
>> > > > Quick note: Looks great, but "Changes in descriptions" is always on,
>> > even
>> > > > after clicked off...
>> > > >
>> > > > On Sun, Jan 28, 2018 at 5:54 PM Amir Ladsgroup <ladsgr...@gmail.com
>> >
>> > > > wrote:
>> > > >
>> > > > > Hello,
>> > > > > People usually ask me how they can patrol edits that affect their
>> > > > Wikipedia
>> > > > > or their language. The proper way to do so is by using watchlist
>> and
>> > > > > recentchanges (with "Show Wikidata edits" option enabled) in
>> > Wikipedias
>> > > > but
>> > > > > sometimes it shows too many unrelated changes.
>> > > > >
>> > > > > Also, it would be good to patrol edits for languages you know
>> because
>> > > the
>> > > > > descriptions are being shown and editable in the Wikipedia app
>> making
>> > > it
>> > > > > vulnerable to vandalism (so many vandalism in this area goes
>> > unnoticed
>> > > > for
>> > > > > a while and sometimes gets fixed by another reader which is
>> > > suboptimal).
>> > > > >
>> > > > > So Lucas [1] and I had a pet project to allow you see unpatrolled
>> > edits
>> > > > > related to a language in Wikidata. It has some basic integration
>> with
>> > > > ORES
>> > > > > and if you see a good edit and mark it as patrolled it goes away
>> from
>> > > > this
>> > > > > list. What I do usually is to check this page twice a day for
>> Persian
>> > > > > langauge which given the size of it, that's enough.
>> > > > >
>> > > > > It's in https://tools.wmflabs.org/wdvd/index.php the source code
>> is
>> > in
>> > > > > https://github.com/Ladsgroup/Vandalism-dashboard and you can
>> report
>> > > > > issues/bug/feature requests in
>> > > > > https://github.com/Ladsgroup/Vandalism-dashboard/issues
>> > > > >
>> > > > > Please spread the word and any feedback about this tool is very
>> > welcome
>> > > > :)
>> > > > >
>> > > > > [1]: <https://www.wikidata.org/wiki/User:Lucas_Werkmeister_(WMDE)
>> >
>> > > > > https://www.wikidata.org/wiki/User:Lucas_Werkmeister_(WMDE)
>> > > > >
>> > > > > <https://www.wikidata.org/wiki/User:Lucas_Werkmeister_(WMDE)>
>> > > > > Best
>> > > > > ___
>> > > > > Wikitech-l mailing list
>> > > > > Wikitech-l@lists.wikimedia.org
>> > > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>> > > > ___
>> > > > Wikitech-l mailing list
>> > > > Wikitech-l@lists.wikimedia.org
>> > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>> > > ___
>> > > Wikitech-l mailing list
>> > > Wikitech-l@lists.wikimedia.org
>> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>> > ___
>> > Wikitech-l mailing list
>> > Wikitech-l@lists.wikimedia.org
>> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>> >
>> ___
>> 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] Wikidata vandalism dashboard (for Wikipedians)

[Alex Monk]

On 29 Jan 2018 18:51, "Eran Rosenthal"  wrote:

> Good idea, and thanks for sharing.
>
> Ideas for improvement:
> 1. Missing reference - the list by itself is not sufficient to determine
> whether some edit is bad or not, as there is no reference (Qid is not
> meaningful).
> It would be nice to have another column with "reference" value to
> compare - either different language (en or fallback lang) or prev value
> 2. " /* wbsetlabel-add:1|he */ " or " /* wbsetlabel-set:1|he */" should be
> formatted to human readable format/removed/replaced with icon.
> 3. (dreaming) How awful would it be to move it to mediawiki itself (e.g
> implement ChangesListStringOptionsFilterGroup /
> ChangesListStringOptionsFilter [T176515
> ])
> doing regex queries on non indexed summary column of recent changes?
>
> On Mon, Jan 29, 2018 at 6:48 PM, Dayllan Maza  wrote:
>
> > This is great. Thank you for sharing
> >
> > On Mon, Jan 29, 2018 at 7:07 AM Amir Ladsgroup 
> > wrote:
> >
> > > It's tracked in: https://github.com/Ladsgroup/
> > Vandalism-dashboard/issues/2
> > >
> > > On Sun, Jan 28, 2018 at 11:26 PM Magnus Manske <
> > > magnusman...@googlemail.com>
> > > wrote:
> > >
> > > > Quick note: Looks great, but "Changes in descriptions" is always on,
> > even
> > > > after clicked off...
> > > >
> > > > On Sun, Jan 28, 2018 at 5:54 PM Amir Ladsgroup 
> > > > wrote:
> > > >
> > > > > Hello,
> > > > > People usually ask me how they can patrol edits that affect their
> > > > Wikipedia
> > > > > or their language. The proper way to do so is by using watchlist
> and
> > > > > recentchanges (with "Show Wikidata edits" option enabled) in
> > Wikipedias
> > > > but
> > > > > sometimes it shows too many unrelated changes.
> > > > >
> > > > > Also, it would be good to patrol edits for languages you know
> because
> > > the
> > > > > descriptions are being shown and editable in the Wikipedia app
> making
> > > it
> > > > > vulnerable to vandalism (so many vandalism in this area goes
> > unnoticed
> > > > for
> > > > > a while and sometimes gets fixed by another reader which is
> > > suboptimal).
> > > > >
> > > > > So Lucas [1] and I had a pet project to allow you see unpatrolled
> > edits
> > > > > related to a language in Wikidata. It has some basic integration
> with
> > > > ORES
> > > > > and if you see a good edit and mark it as patrolled it goes away
> from
> > > > this
> > > > > list. What I do usually is to check this page twice a day for
> Persian
> > > > > langauge which given the size of it, that's enough.
> > > > >
> > > > > It's in https://tools.wmflabs.org/wdvd/index.php the source code
> is
> > in
> > > > > https://github.com/Ladsgroup/Vandalism-dashboard and you can
> report
> > > > > issues/bug/feature requests in
> > > > > https://github.com/Ladsgroup/Vandalism-dashboard/issues
> > > > >
> > > > > Please spread the word and any feedback about this tool is very
> > welcome
> > > > :)
> > > > >
> > > > > [1]: 
> > > > > https://www.wikidata.org/wiki/User:Lucas_Werkmeister_(WMDE)
> > > > >
> > > > > 
> > > > > Best
> > > > > ___
> > > > > Wikitech-l mailing list
> > > > > Wikitech-l@lists.wikimedia.org
> > > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > > > ___
> > > > Wikitech-l mailing list
> > > > Wikitech-l@lists.wikimedia.org
> > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > > ___
> > > Wikitech-l mailing list
> > > Wikitech-l@lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> ___
> 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] HHVM vs. Zend divergence

[Alex Monk]

On 19 Sep 2017 5:40 pm, "C. Scott Ananian"  wrote:

I'm suggesting to proceed cautiously and have a proper
discussion of all the factors involved instead of over-simplifying this to
"community" vs "facebook".

For example, the top-line github stats are:
hhvm: 504 contributors (24,192 commits)
php-src: 496 contributors (104,566 commits)

HHVM seems to have a larger community of contributors despite a much
shorter active life.

By a difference of 8 contributors?

But note that the PHP github mirror has been broken since Jul 29 (!).

I'm not convinced an exclamation mark in brackets is required here.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] SkinOOUIThemes

[Alex Winkler]

Well, i would like to style selects with jquery chosen which is also 
part of the MediaWiki distribution, and that just doesn't seem to be 
possible. Ideally i would like to just not use OOJS at all for what it's 
worth. Basically this loads a ton of code that i then have to overwrite 
again, and the fastest code is the code i never load.


Cheers


On 18.07.2017 20:23, Bartosz Dziewoński wrote:
Currently it is not possible to use a custom theme without hacking 
core a little bit. I've actually worked on implementing this, and a 
lot of work went through [1], but the important patches are still 
waiting for review [2] (they're low priority mostly because not that 
many people are asking for the feature). See T100896 [3] for more.


Using OOjs UI widgets with no styles at all is not necessarily a good 
idea – we still need *some* styling for basic things, like having the 
contents of dropdown lists actually hide while they are not open, etc.
OOjs UI includes a theme called "Blank" which kind of does that, but 
MediaWiki doesn't currently make it available. I'm not sure if it is 
actually complete enough to be used in practice.


[1] 
https://gerrit.wikimedia.org/r/#/q/status:merged+topic:custom-ooui-themes
[2] 
https://gerrit.wikimedia.org/r/#/q/status:open+topic:custom-ooui-themes

[3] https://phabricator.wikimedia.org/T100896




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

[Wikitech-l] SkinOOUIThemes

[Alex Winkler]

Hello,

I've been looking at this parameter in skin.json and its implementation 
seems a bit weird to me (or I might just not understand it properly). My 
original goal was to flat out disable OOJS-UI since the default themes 
(WikimediaUI and Apex) do not really look good on dark skins, and even 
on light skins are only implemented on half the pages (and don't look at 
extensions that are not deployed on Wikipedia). Since just flat out 
disabling doesn't seem to be possible as special pages enable it 
directly, my next goal was to create a custom class for a OOJS-UI theme 
that basically doesn't apply any styles. to do that I added


"SkinOOUIThemes": {
"liquiflow": "Blank"
}

to my skins skin.json and loaded a class

However now the wiki tries to load a style from 
"$IP/resources/lib/oojs-ui/oojs-ui-core-blank.css" and this seems to be 
not customizable. Am i doing this wrong or is this implementation just 
not possible? Adding a CSS file right there seems like a core hack which 
i want to avoid, ideally I'd like to not even load a CSS file in the 
first place.



Cheers

Alex


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

Re: [Wikitech-l] [Huggle] Fwd: EventStreams launch and RCStream deprecation

[Alex Monk]

https://wikitech.wikimedia.org/wiki/EventStreams#Python seems to work if
you fix the obvious missing apostrophe and do `pip install sseclient`. The
CLI version below also appears to work, and this seems much nicer to me
than RCStream.

On 25 February 2017 at 21:25, Petr Bena  wrote:

> Hello,
>
> Thanks for the info, this means that we need to switch from RCStream, is
> there any working example code, preferably written in Python or any other
> sane terminal friendly language (eg. not html or JS) that is capable of
> connecting to this stream and obtaining at least identicat information from
> it as we did in case of RCStream?
>
> P.S. I can't help myself but I really have to rant now because I hate how
> much MW devs love to deprecate stuff and break compatibilty so often just
> for trivial reasons. I am really glad that instead of using RCStream
> directly I created that XmlRcs proxy in past, it's gonna save me massive
> amount of work, because no, I am not gonna deprecate XmlRcs [1].
>
> P.S. 2.0: Do you really have a date for decommission of a working service
> already even though the replacement is still in early-cradle pre-alpha
> phase? Is this really the best approach?
>
> 1: https://wikitech.wikimedia.org/wiki/XmlRcs
>
> On Thu, 23 Feb 2017 at 22:11, Andrew Otto  wrote:
>
>> Hi everyone!
>>
>> Wikimedia is releasing a new service: EventStreams
>> [1].  This service
>> allows us to publish arbitrary streams of JSON event data to the
>> public.  (Pt: we’re looking for cool new uses
>> [2]
>> to put on an upcoming blog post.)
>>
>>
>> Initially, the only stream available will be good ol’ RecentChanges
>> .  This event stream
>> overlaps functionality already provided by irc.wikimedia.org and RCStream
>> .  However, this new
>> service has advantages over these (now deprecated) services.
>>
>>
>>1.
>>
>>We can expose more than just RecentChanges.
>>2.
>>
>>Events are delivered over streaming HTTP (chunked transfer) instead
>>of IRC or socket.io.  This requires less client side code and fewer
>>special routing cases on the server side.
>>3.
>>
>>Streams can be resumed from the past.  By using EventSource, a
>>disconnected client will automatically resume the stream from where it 
>> left
>>off, as long as it resumes within one week.  In the future, we would like
>>to allow users to specify historical timestamps from which they would like
>>to begin consuming, if this proves safe and tractable.
>>
>>
>> I did say deprecated!  Okay okay, we may never be able to fully deprecate
>> irc.wikimedia.org.  It’s used by too many (probably sentient by now)
>> bots out there.  We do plan to obsolete RCStream, and to turn it off in a
>> reasonable amount of time.  The deadline iis July 7th, 2017.  All
>> services that rely on RCStream should migrate to the HTTP based
>> EventStreams service by this date.  We are committed to assisting you in
>> this transition, so let us know how we can help.
>>
>> Unfortunately, unlike RCStream, EventStreams does not have server side
>> event filtering (e.g. by wiki) quite yet.  How and if this should be done
>> is still under discussion .
>>
>> The RecentChanges data you are used to remains the same, and is available
>> at https://stream.wikimedia.org/v2/stream/recentchange. However, we may
>> have something different for you, if you find it useful. We have been
>> internally producing new Mediawiki specific events
>> 
>> [3] for a while now, and could expose these via EventStreams as well.
>>
>> Take a look at these events, and tell us what you think.  Would you find
>> them useful?  How would you like to subscribe to them?  Individually as
>> separate streams, or would you like to be able to compose multiple event
>> types into a single stream via an API?  These things are all possible.
>>
>> I asked for a lot of feedback in the above paragraphs.  Let’s try and
>> centralize this discussion over on the mediawiki.org EventStreams talk
>> page [4].   In
>> summary, the questions are:
>>
>>
>>-
>>
>>What RCStream clients do you maintain, and how can we help you
>>migrate to EventStreams?
>>
>>-
>>
>>Is server side filtering, by wiki or arbitrary event field, useful to
>>you? 
>>-
>>
>>Would you like to consume streams other than RecentChanges?
>>  (Currently
>>available events are described the 

Re: [Wikitech-l] Integrating Parsoid & RESTbase into a secure MediaWiki Install

[Alex Monk]

You can get a trusted cert for your home server. Look into LetsEncrypt.

On 22 Feb 2017 3:15 pm, "John P. New"  wrote:

> Thanks to a couple of members of this list I was able to get Visual Editor
> working on my WikiMedia install.
>
> Now I would like to run the wiki under SSL. Of course, as soon as I do, my
> browser complains of mixed content from the RESTbase server and won't load
> VE at all.
>
> I am running MediaWiki 1.28 on a shared host, which means no access to
> node.js. So in order to run Parsoid and RESTbase I have installed both on
> my home server. As such, I have no way of getting a trusted SSL certificate
> for it; the most I could do is a self-signed certificate, which I am sure
> will cause as many browser complaints as the current mixed-content does.
>
> My question is, what is the likelihood of getting this configuration to
> work under SSL?
>
> John
>
> ___
> 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] VisualEditor discards changes made in Wikitext editor

[Alex Monk]

One of the things that should probably be noted is that, if I recall
correctly, this was the feature that required the addition of the
wgVisualEditorFullRestbaseURL configuration - previously there was just
wgVisualEditorRestbaseURL. You'll need to set up RB and point that config
var at it.

On 20 February 2017 at 21:02, John P. New  wrote:

> On February 20, 2017 08:34:35 PM James Forrester wrote:
> > On Mon, 20 Feb 2017 at 10:42 John P. New  wrote:
> >
> > > I've set up MW 1.28 with VE/parsoid and everything is working well
> > >
> > > However, when I edit in (any) wikitext editor and try to switch to VE,
> I
> > > am presented with a dialog with only 2 choices: "Cancel" or "Discard my
> > > changes and switch". Diving into the code I found I could change
> > > ve.init.MWVESwitchConfirmDialog.js (line 58) from
> > >   modes: [ 'restbase' ]
> > > to
> > >   modes: [ 'restbase', 'simple' ]
> > >
> > > that adds "Switch" to the dialog box, but when this option is chosen,
> any
> > > changes made in the wikitext editor are lost.
> > >
> > > Is this a mis-configuration on my part or is switching from edited
> > > wikitext to VE not supported? Do I need a RESTbase server to implement
> this
> > > functionality?
> > >
> >
> > RESTbase provides the switching-with-changes ability, yes. There's a
> reason
> > VE doesn't offer switching-with-changes without it. :-) In general,
> > fiddling with the code inside an extension is always going to break.
> >
> > J.
> >
> Thanks for the clarification.
>
> Should this be noted in the setup instructions for Visual Editor? It would
> have saved me a lot of head-scratching and investigation time.
>
> And yes, I realize messing with the code will break things, but it was my
> way of finding out that I might need a RESTbase server and to point to
> where my problem was. :-)
>
> John
>
>
>
> ___
> 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] +2 request for yurik in mediawiki and maps-dev

[Alex Monk]

Update: I demanded an explanation for Yurik's removal, nobody would give a
good one, I revoked ops' administrative rights, and now I've been removed
as a gerrit administrator with ops re-added.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] +2 request for yurik in mediawiki and maps-dev

[Alex Monk]

On 26 January 2017 at 16:03, Quim Gil  wrote:

> Can we
> resolve this thread with this title as well, please?
>
We could rename the thread.

On 26 January 2017 at 16:03, Quim Gil  wrote:

> The cause for the removal was simple: standard procedure for off-boarding
> Wikimedia Foundation employees.
>

Our +2 policy does not allow for that to happen in this way as the 'you
have no intent to continue contributing' part does not appear to have been
satisfied - and even if it were, the rights were granted as a volunteer. In
any case you are not the person who removed the rights, we need to hear
from Brandon.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] +2 request for yurik in mediawiki and maps-dev

[Alex Monk]

Yes, they're announced on wikitech-l:
https://lists.gt.net/wiki/wikitech/335950
If you go back through one of the pages linked in that email to the date it
was sent, you find the relevant vote too:
https://www.mediawiki.org/w/index.php?title=Gerrit/Project_ownership=648776#Yurik_for_Core_.2B2
Even without that, the audit log shows the user was added to the group a)
by Sumanah, and b) before it was announced that Yurik had joined the
foundation.

On 25 January 2017 at 21:43, Gergo Tisza  wrote:

> On Wed, Jan 25, 2017 at 1:24 PM, Brian Wolff  wrote:
>
> > There's not exactly a whole lot of precedent here. Presumably, bblack did
> > it as part of an off boarding procedure. Eventhough I disagree with this
> > action, I dont think its an unreasonable action, especially given the
> lack
> > of precedent.
>
>
> More pragmatically, was there any easy way for him to find out how the +2
> was granted? Not sure if we record those decisions anywhere (other than
> phab tickets which are not easy to find).
> ___
> 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] +2 request for yurik in mediawiki and maps-dev

[Alex Monk]

On 25 January 2017 at 21:24, Brian Wolff  wrote:
>
> Presumably, bblack did
> it as part of an off boarding procedure. Eventhough I disagree with this
> action, I dont think its an unreasonable action, especially given the lack
> of precedent. I dont see any need for him to come and explain himself.


That's what I'm concerned about. Yurik's rights were granted via a vote of
developers and therefore I have decide to require an explanation.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] +2 request for yurik in mediawiki and maps-dev

[Alex Monk]

On 25 January 2017 at 21:00, Kevin Smith  wrote:

> We are talking about exactly the same situation: Someone was a productive
> volunteer, then staff, then no longer staff. 99+% of the time, they should
> retain their rights, or get them back shortly after leaving. But there may
> be cases where someone would be disgruntled, and if rights are automatic in
> all cases, such a person could do damage. I'm just suggesting that there
> should be a quick and simple check to be sure that's not the case. Being
> without rights for a couple days doesn't seem like a small price to pay for
> the safety of the project.
>

If they were added as a volunteer that means they passed a vote to be
there, we're not going to start adding such extra checks and requirements.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] +2 request for yurik in mediawiki and maps-dev

[Alex Monk]

On 25 January 2017 at 19:48, Kevin Smith  wrote:

> I support restoring the rights in this case, but I'm not sure it should be
> automatic in all cases. If having +2 rights is relatively harmless and
> reversible, then an automatic (but announced) restoration of the rights
> should be fine.
>
> The issue is that someone who leaves the foundation could do so under
> unfriendly terms, possibly affecting their ability to do good work. I know
> we don't want to think that a previously productive volunteer could later
> cause problems, but it is possible.
>
> That's why I think there should be some form of check, so we have
> confidence that this person still has good intentions. For example, their
> manager and/or someone from Talent & Culture could be consulted, or trusted
> people who still have close contact with the person so know their state of
> mind. It could be quick and lightweight, in almost all cases, but skipping
> that step entirely seems risky to me. Unless, as I said, having +2 really
> isn't a big deal.
>
>
>
>
> Kevin Smith
> Agile Coach, Wikimedia Foundation
>

You don't appear to be a developer. Even if you were, Brian said 'similar
situation' - i.e., where someone had been granted rights before becoming
WMF staff.

The audit log shows that Brandon Black removed Yurik's rights on January
17th at 10:36 PM. Brandon, you need to explain why you did this.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] COMPLETELY SOLVED Re: VisualEditor in 1.28 - fails after upgrade from 1.27

[Alex Monk]

On 22 December 2016 at 16:03, Daniel Barrett <d...@cimpress.com> wrote:

> I was able to diagnose this by watching the network traffic between
> MediaWiki and parsoid
> using Chrome’s developer tools (the "Network" tab). There it was... the
> error message
> "Call to undefined function curl_init()."
>
> I’m going to file a bug report that the user-visible error message in this
> case can
> perhaps be Improved. Currently the message is just a JavaScript alert that
> says:
>
>   examplewiki.com replied: "http"
>
Yeah, that's a bit broken and should show that the error code was 500 -
https://phabricator.wikimedia.org/T152429
In addition to that (which is much more general), for this specific
dependency, we could also have the VE API code check whether the function
exists, and if not throw a particular error that can be shown nicely by the
client. A bug report for that would be good, thanks.

-- 
Alex Monk
VisualEditor/Editing team
https://wikimediafoundation.org/wiki/User:Alex_Monk_(WMF)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Deployments: upcoming holidays and their impact

[Alex Monk]

Although this is theoretically a deployment freeze week, in reality
l10nupdate is still running:
 !log l10nupdate@tin scap sync-l10n completed (1.29.0-wmf.6)
(duration: 07m 54s)

On 7 December 2016 at 17:39, Chad <innocentkil...@gmail.com> wrote:

> On Wed, Dec 7, 2016 at 9:22 AM Alex Monk <am...@wikimedia.org> wrote:
>
> > Are we also going to be disabling l10nupdate then? That's surely more
> risky
> > than syncing beta's files (which aren't even loaded by production
> apaches)
> >
> >
> Sounds like a plan!
>
> -Chad
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Alex Monk
VisualEditor/Editing team
https://wikimediafoundation.org/wiki/User:Krenair_(WMF)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Offering internationalized programming facilities within WM enviroment

[Alex Monk]

See also https://phabricator.wikimedia.org/T150417

On 21 December 2016 at 21:42, Gergo Tisza  wrote:

> I sympathize with the goal but accessibility benefits would be far
> outweighed by maintaince costs. We regularly use grep to find code which is
> about to be deprecated; wikis copy gadgets from each other; more
> experienced developers are sometimes asked to help a wiki where the local
> maintainers have less experience. We have a whole global user group for
> people who go from wiki to wiki and fix things.
>
> And that's not even taking into account the implementation costs, which
> would probably be massive if it includes stuff like localizing
> Lua/Javascript language keywords. The Wikimedia community collectively has
> a lot of experience with web development but not a whole lot of experience
> with programming language compiler development.
> ___
> 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] VisualEditor in 1.28 - fails after upgrade from 1.27

[Alex Monk]

On 19 December 2016 at 14:48, Daniel Barrett  wrote:

> Maybe it was this ticket in September?
>
> https://phabricator.wikimedia.org/T146686


Yes, that looks like it. Try applying the core EditPage and VE patches.

On 19 December 2016 at 14:54, Niklas Laxström 
wrote:

> Maybe related: having both SemanticMediaWiki and Visual Editor
> installed will still reliably trigger this error.
>
> This was filed as https://phabricator.wikimedia.org/T134562 (which
> imho should be reopened).
>

I don't know about new versions of SMW, but wikitech seems fine.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] VisualEditor in 1.28 - fails after upgrade from 1.27

[Alex Monk]

I feel like that sessions error was something we fixed months ago but can't
find details right now. Certainly not the first time I've seen it...

On 19 Dec 2016 3:31 pm, "Brad Jorsch (Anomie)" 
wrote:

> On Mon, Dec 19, 2016 at 8:20 AM, Daniel Barrett  wrote:
>
> > Here you go:
> >
> >
> > BadMethodCallException from line 845 of <...>/w/includes/session/
> SessionManager.php:
> > Sessions are disabled for this entry point
> >
> >
> > load.php?debug=false=en=startup=scripts=vector:4
> > [43d736c07dd76d73cf26db20] /w/load.php?debug=false=
> > en=startup=scripts=vector   BadMethodCallException
> from
> > line 845 of <...>/w/includes/session/SessionManager.php: Sessions are
> > disabled for this entry point
> >
>
> Ok, that's a start. Can you get the rest of the stack trace for the
> exception so we can figure out how that's getting called?
>
> --
> Brad Jorsch (Anomie)
> Senior Software Engineer
> Wikimedia Foundation
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] VisualEditor in 1.28 - fails after upgrade from 1.27

[Alex Monk]

Thanks Andre. Yeah, I'll need more than that to help.

On 19 Dec 2016 10:10 am, "Andre Klapper"  wrote:

> On Mon, 2016-12-19 at 02:05 +, Daniel Barrett wrote:
> > /*
> > [37fc66f00dced89747fd4433] 2016-12-18 23:40:16: Fatal exception of
> > type "BadMethodCallException"
> > */
>
> See https://www.mediawiki.org/wiki/Manual:How_to_debug#PHP_errors for
> how to enable $wgShowExceptionDetails .
>
> Cheers,
> andre
> --
> Andre Klapper | Wikimedia Bugwrangler
> http://blogs.gnome.org/aklapper/
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] VisualEditor in 1.28 - fails after upgrade from 1.27

[Alex Monk]

What are the details of this BadMethodCallException?

On 18 December 2016 at 23:46, Daniel Barrett <d...@cimpress.com> wrote:

> Forgot to mention:
>
> - MediaWiki 1.28.0 is the official release,
> - I did upgrade VisualEditor to the "1.28" release downloaded via
> ExtensionManager.
> - The BadMethodCallException occurs on every page load, not just when
> trying to run VisualEditor.
>
> DanB
> 
> From: Daniel Barrett
> Sent: Sunday, December 18, 2016 6:31:16 PM
> To: Wikimedia developers
> Subject: VisualEditor in 1.28 - fails after upgrade from 1.27
>
> After updating my wiki from 1.27.1 to 1.28.0, VisualEditor has stopped
> working. I click the Edit tab, and the page content fades slightly in color
> as if VisualEditor were about to load. But then the editor tools don't
> appear, and Chrome displays a dialog box:
>
>  example.com responded:  "http"  [OK] [Cancel]
>
> There are no PHP errors in the Apache error log, and no errors in the
> parsoid log file (looks like a normal parsoid access). However, Chrome
> developer tools show a JavaScript error: BadMethodCallException. If I
> remove VisualEditor from LocalSettings.php, the error vanishes.
>
> The only extension I am running is VisualEditor; otherwise it's a vanilla
> MediaWiki that requires users to be logged into read (a private wiki). The
> same LocalSettings.php files works perfectly in MW 1.27.1.
>
> Has anything significantly changed in VisualEditor that I need to
> configure it differently?
>
> LocalSettings.php has:
>
> # visual editor
> $wgDefaultUserOptions['visualeditor-enable'] = 1;
> $wgDefaultUserOptions['visualeditor-enable-experimental'] = 1;
>
> $wgVirtualRestConfig['modules']['parsoid'] = array(
>'url' => 'http://localhost:8142',
>'prefix' => 'example.com'
> );
>
> $wgSessionsInObjectCache = true;  /* Using memcached */
> $wgVirtualRestConfig['modules']['parsoid']['forwardCookies'] = true;
>
> The parsoid settings file has:
>
> parsoidConfig.setMwApi({ prefix: 'example.com', uri: '
> http://dev.example.com/w/api.php' });
> parsoidConfig.useSelser = true;
>
> Thank you for any insights!
> DanB
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Alex Monk
VisualEditor/Editing team
https://wikimediafoundation.org/wiki/User:Krenair_(WMF)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Deployments: upcoming holidays and their impact

[Alex Monk]

Are we also going to be disabling l10nupdate then? That's surely more risky
than syncing beta's files (which aren't even loaded by production apaches)

On 7 December 2016 at 17:20, Chad <innocentkil...@gmail.com> wrote:

> On Wed, Dec 7, 2016 at 12:52 AM Legoktm <legoktm.wikipe...@gmail.com>
> wrote:
>
> > On 12/06/2016 03:32 PM, Greg Grossmeier wrote:
> > > Reminder: This next week (Dec 12th) is the last normal week before the
> > > end of year holiday season deploy freeze goes into effect. Plan
> > > accordingly.
> >
> > Does the freeze also affect the beta cluster? Or just production?
> >
> >
> Considering it's best practice to fully sync config changes to production,
> even if they're no-ops intended for beta I would say yes
>
> -Chad
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Alex Monk
VisualEditor/Editing team
https://wikimediafoundation.org/wiki/User:Krenair_(WMF)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Update on WMF account compromises

[Alex Monk]

The 'phabricator model' is far from perfectly fitting our needs though:
https://secure.phabricator.com/maniphest/query/qWbzSK1NVwb0/

On 17 Nov 2016 1:07 pm, "Vi to"  wrote:

That's obvious, anybody knows only bag inspectors are allowed to inspect
wallets.

Coming back to be serious, imho, Wikimedia should apply the "phabricator
model" to a 2FA open source app: collaborating in development and making it
perfectly fit with our needs

Vito

2016-11-17 13:06 GMT+01:00 Dmitry Brant :

> Don't give your wallet to anyone claiming to be a Wallet Inspector.
>
> On Nov 17, 2016 4:48 AM, "Vi to"  wrote:
>
> So are you telling me that tool "test if your credit card was cloned" is a
> fraud? But its test included my ccv2 too! :p
>
> Vito
>
> 2016-11-17 9:33 GMT+01:00 Chad :
>
> > On Thu, Nov 17, 2016 at 12:18 AM Antoine Musso 
> wrote:
> >
> > > Le 16/11/2016 à 19:19, Pine W a écrit :
> > > >
> > > > (0) Consider testing your password strength with a tool like
> > > > http://www.testyourpassword.com/; be sure that the tool you use does
> > not
> > > > send your chosen password over the Internet and instead tests it
> > locally.
> > >
> > > By using an online testing tool, you are effectively breaking the very
> > > first rule:
> > >
> > >  DO NOT GIVE OUT YOUR PASSWORD.  EVER.
> > >
> > > Using that site is exactly like sharing your password with a random
> > > stranger in the world.  Even if you trusted that website, and audited
> > > the code at a given point in time, you have no guarantee the site
> hasn't
> > > changed or that it is not collecting passwords.
> > >
> > >
> > Not to mention, it's plain-old-insecure HTTP, so of course anyone and
> > their mother's uncle could be sniffing the traffic ;-)
> >
> > Same rule goes for a "generate a random password" site. Don't use
> > them.
> >
> > -Chad
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l 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] New puppetmaster in deployment-prep

[Alex Monk]

Hi all,

Just so everyone using the deployment-prep instances are aware:
deployment-puppetmaster has been retired in favour of
deployment-puppetmaster02, which runs role::puppetmaster::standalone, which
should behave much closer to how production puppetmasters and the labs
default puppetmaster work.

Details are in https://phabricator.wikimedia.org/T149620

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

Re: [Wikitech-l] Automatic gerrit authentication and retrieval of reviews

[Alex Monk]

Me and Bryan have been discussing this. There might be a hacky way to map
SUL accounts to LDAP accounts - Phabricator allows users to login via LDAP
as you'd expect, but it also allows OAuth against Wikimedia SUL accounts.
Therefore the mapping can exist there, where users have set it up.
You'd probably have to:
* Use https://phabricator.wikimedia.org/conduit/method/user.mediawikiquery/
to get a Phabricator account from a Wikimedia SUL username
* Scrape their Phabricator userpage to find their LDAP name, as I don't
believe Phabricator provides this via the API (but I could be wrong)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Automatic gerrit authentication and retrieval of reviews

[Alex Monk]

On 21 October 2016 at 10:13, Strainu  wrote:

> 1. Gerrit does not seem to support oauth authentication. I vaguely
> remember that the gerrit account used to be linked to the mw.org
> account. Is there any way I could use the mw.org auth to retrieve the
> gerrit account and/or authenticate to gerrit with it? The gerrit
> uploader seems to only use the mw account to put the username in the
> committer field and then uploads the change as itself.


Gerrit uses LDAP authentication, which is controlled by
wikitech.wikimedia.org and matches accounts there. This is separate to
Wikimedia SUL which controls accounts on wikis like mediawiki.org.
See https://phabricator.wikimedia.org/T148048 and the bottom of
https://meta.wikimedia.org/wiki/Community_Tech/Tool_Labs_support/Tool_Labs_vision#Project_roadmap
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] ParserAfterParse not called by VisualEditor?

[Alex Monk]

On 9 October 2016 at 01:37, James HK  wrote:

> > VE's edits should be (indirectly) going through the action=edit API.
>
> I'm not sure this answer is very helpful. I wonder about this as well
> whether edits initiated by VE/NWE will actually end-up being processed
> by the standard hooks available or not
>

It means yes, all VE edits should be going through the normal API edit
processing code used by thousands of scripts, bots and external clients
every day. I expect it works roughly the same as the UI edit processing
code - if not, that's more likely a bug with ApiEditPage than with the
VisualEditor extension.
https://phabricator.wikimedia.org/diffusion/EVED/browse/master/ApiVisualEditorEdit.php;HEAD$17-57
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] ParserAfterParse not called by VisualEditor?

[Alex Monk]

VE's edits should be (indirectly) going through the action=edit API.

On 8 October 2016 at 20:56, Stephan Gambke <s7ep...@gmail.com> wrote:

> Hi.
>
> I have an extension that hooks into ParserAfterParse to modify the
> generated HTML (Lingo). The problem is, that apparently this hook is never
> called when a page is edited using Visual Editor, which means my extension
> does not get to modify the page's HTML content until it is purged
> (action=purge) or edited using the old editor.
>
> Is this intentional or is it a VE bug?
> Does anybody have any advice on how I could work around this? E.g. an
> alternative hook I should use?
>
> Cheers
> Stephan
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Alex Monk
VisualEditor/Editing team
https://wikimediafoundation.org/wiki/User:Krenair_(WMF)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] REMINDER: No deploys next week (week of Sept 26th)

[Alex Brollo]

Hurra! 
Alex

2016-09-20 19:09 GMT+02:00 Greg Grossmeier <g...@wikimedia.org>:

> Due to the Wikimedia Technical Operations Team having their team offsite
> that week and generally being less than normally available there will be
> no non-emergency deploys the week of September 26th (aka: next week).
>
> See also:
> https://wikitech.wikimedia.org/wiki/Deployments#Week_of_September_26th
>
> Normal schedule will resume the following week.
>
> Teaser: The week of October 17th will be a "no train deploys" weeks as
> the Wikimedia Release Engineering Team will be at their offsite that
> week. I'll send a reminder about this as well closer to that date.
>
> Best,
>
> Greg
>
> --
> | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
> | Release Team ManagerA18D 1138 8E47 FAC8 1C7D |
>
> ___
> 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] Gerrit members can't add members anymore?

[Alex Monk]

Making the group self-owned is not necessarily wanted in all cases.

On 16 September 2016 at 11:53, Florian Schmidt <
florian.schmidt.wel...@t-online.de> wrote:

>
>
> Thanks for the Info Krenair!
>
>
>
> However, as I requested the project, I would assume, that I'm also the
> project admin :P Adding the project requester as a project admin should
> probably be a step in the gerrit project creation process, shouldn't it? :)
>
>
>
>
>
>
>
>
>
> -Original-Nachricht-
>
> Betreff: Re: [Wikitech-l] Gerrit members can't add members anymore?
>
> Datum: 2016-09-16T12:22:45+0200
>
> Von: "Alex Monk" <kren...@gmail.com>
>
> An: "Florian Schmidt" <florian.schmidt.wel...@t-online.de>, "Wikimedia
> developers" <wikitech-l@lists.wikimedia.org>
>
>
>
>
>
>
> Gerrit groups each have an 'Owners' field that specifies which group can
> administrate it. In some cases this points to the group itself, but
> extension-GoogleLogin is owned by the gerrit administrators.
> Users can requested to be added by us, see https://www.mediawiki.org/
> wiki/Gerrit/Project_ownership
>
> On 16 September 2016 at 07:45, Florian Schmidt <florian.schmidt.welzow@t-
> online.de> wrote:
>
>> Hi all together,
>>
>> maybe I'm mistaken, but iirc, some time ago, as a member of a specific
>> gerrit group (e.g. extension-GoogleLogin), I was able to add members to
>> this specific group by myself. Does I remember correctly? If so, currently
>> I'm not able to do this anymore. Was something changed or is this an
>> error?
>>
>> Best,
>> Florian
>>
>> ___
>> 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] Gerrit members can't add members anymore?

[Alex Monk]

Gerrit groups each have an 'Owners' field that specifies which group can
administrate it. In some cases this points to the group itself, but
extension-GoogleLogin is owned by the gerrit administrators.
Users can requested to be added by us, see
https://www.mediawiki.org/wiki/Gerrit/Project_ownership

On 16 September 2016 at 07:45, Florian Schmidt <
florian.schmidt.wel...@t-online.de> wrote:

> Hi all together,
>
> maybe I'm mistaken, but iirc, some time ago, as a member of a specific
> gerrit group (e.g. extension-GoogleLogin), I was able to add members to
> this specific group by myself. Does I remember correctly? If so, currently
> I'm not able to do this anymore. Was something changed or is this an error?
>
> Best,
> Florian
> 
> ___
> 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] Finding namespaces

[Alex Monk]

On 31 August 2016 at 12:18, Bináris  wrote:

> How can I find out from witihn a wiki, what namespaces itt uses?
>
Special:AllPages has a dropdown with each namespace.

On 31 August 2016 at 12:18, Bináris  wrote:

> Additional question: where can I see available aliases as a user?
>

https://meta.wikimedia.org/w/api.php?action=query=siteinfo=namespacealiases
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] deployment-prep using valid certs for HTTPS

[Alex Monk]

Hi all,

With some help from Brandon, I've changed deployment-prep to use Let's
Encrypt instead of the self-signed cert I added last year (to get HTTPS
working - albeit improperly-signed - instead of nothing, and nginx/puppet
working on the Varnish instances again).
It should now behave much more like production - TLS redirects are enabled
in Varnish, and you shouldn't have to ignore cert warnings to use it now.
Details for HTTPS in deployment-prep are spread out over various tickets,
but the main one now is https://phabricator.wikimedia.org/T50501
The puppetisation still needs some work, but it's cherry-picked on
deployment-puppetmaster and seems to be working reliably.

Pages with images may need to be null-edited to make MediaWiki generate
HTTPS URLs for them so browsers don't block the images.
Please let me know if you find any beta.wmflabs.org domains that aren't
covered by the cert or aren't redirecting HTTP to HTTPS in Varnish.

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

Re: [Wikitech-l] "basic" usergroup

[Alex Monk]

https://gerrit.wikimedia.org/r/#/c/301735/ got merged, backported and
deployed around 4AM this morning, so this is now resolved.

On 29 July 2016 at 03:06, Alex Monk <a...@wikimedia.org> wrote:

> (re-sending, apparently mailman didn't like my previous emails)
> Looks like it was this: https://gerrit.wikimedia.org/r/213314
> This appears to be an accident. During a migration of configuration code
> to a new system, a 'basic' 'GrantPermissions' line was put into the new
> file under 'GroupPermissions' instead.
>
>
> On 29 July 2016 at 02:48, Brian M <xaosfluxw...@gmail.com> wrote:
>
>> Possibly related to https://gerrit.wikimedia.org/r/293806 ?
>>
>> On Thu, Jul 28, 2016 at 9:33 PM, MZMcBride <z...@mzmcbride.com> wrote:
>>
>> > Brian M wrote:
>> > >Some people asking around about a new group that appears to have been
>> > >globally rolled out to WMF wiki's; default name "basic" with only
>> > >permission "torunblocked" - can anyone point me to this change?
>> >
>> > Possibly related from early 2016: <
>> https://gerrit.wikimedia.org/r/259062>.
>> > Specifically:
>> > <
>> https://gerrit.wikimedia.org/r/#/c/259062/9/includes/DefaultSettings.php
>> > >.
>> >
>> > Cross-referencing the on-wiki discussion:
>> > <https://en.wikipedia.org/w/index.php?oldid=732017821#footer>.
>> >
>> > Then new questions arise. What suddenly(?) changed to expose this user
>> > group? And why isn't the "highvolume" user group similarly exposed?
>> >
>> > MZMcBride
>> >
>> >
>> >
>> > ___
>> > Wikitech-l mailing list
>> > Wikitech-l@lists.wikimedia.org
>> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] "basic" usergroup

[Alex Monk]

(re-sending, apparently mailman didn't like my previous emails)
Looks like it was this: https://gerrit.wikimedia.org/r/213314
This appears to be an accident. During a migration of configuration code to
a new system, a 'basic' 'GrantPermissions' line was put into the new file
under 'GroupPermissions' instead.


On 29 July 2016 at 02:48, Brian M  wrote:

> Possibly related to https://gerrit.wikimedia.org/r/293806 ?
>
> On Thu, Jul 28, 2016 at 9:33 PM, MZMcBride  wrote:
>
> > Brian M wrote:
> > >Some people asking around about a new group that appears to have been
> > >globally rolled out to WMF wiki's; default name "basic" with only
> > >permission "torunblocked" - can anyone point me to this change?
> >
> > Possibly related from early 2016:  >.
> > Specifically:
> > <
> https://gerrit.wikimedia.org/r/#/c/259062/9/includes/DefaultSettings.php
> > >.
> >
> > Cross-referencing the on-wiki discussion:
> > .
> >
> > Then new questions arise. What suddenly(?) changed to expose this user
> > group? And why isn't the "highvolume" user group similarly exposed?
> >
> > MZMcBride
> >
> >
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Parsoid Exception HTTP 500

[Alex Monk]

I would check your parsoid localsettings.js config file... There should be
a setInterwiki call in there pointing to your MediaWiki api.php. The
parsoid server needs to be able to fetch that URL.

On 28 July 2016 at 12:42, Julian Loferer  wrote:

> Hello,
>
> i have a problem. If i start my parsoid server it initialize the 4 workers
> and get ready on the ip. But if i try to click on the edit Button in the
> wikipage i get two exceptions. One at the wikipage: Error at loading data
> from the server: 500: docserver-http: HTTP 500.
> And the other at the console of the parsoid service:
> [warning/api/econnrefused][localhost/v3/page/html/Main_Page/3] Failed API
> request,
> {"error":{"code":"ECONNREFUSED","errno":"ECONNREFUSED","syscall":"connect"},"retries-remaining":0}
>
> So im helpless with that kind of exceptions and also searched on google
> but didnt find the right solution so what can i do for?
>
> ___
> 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] [Ops] Canary Deploys for MediaWiki

[Alex Monk]

If the intermediate state throws notices/errors, wouldn't it be a better
idea to sync-file in the correct order to prevent such notices/errors?

On 25 July 2016 at 21:54, Roan Kattouw  wrote:

> Note to deployers: when syncing certain config changes (e.g. adding a new
> variable) that touch both InitialiseSettings and CommonSettings, you will
> now need to use sync-dir wmf-config, because individual sync-files will
> likely fail if the intermediate state throws notices/errors.
>
> (It was a good idea to do this before, but it'll be more strongly enforced
> now.)
>
> On Jul 25, 2016 12:35, "Tyler Cipriani"  wrote:
>
>> tl;dr: Scap will deploy to canary servers and check for error-log spikes
>> in the next version (to be released Soon™).
>>
>> In light of recent incidents[0] which have created outages accompanied by
>> large, easily detectable, error-rate spikes, a patch has recently landed in
>> Scap[1] that will:
>>
>>1. Push changes to a set of canary servers[2] before syncing to proxy
>> servers
>>2. Wait a configurable length of time (currently 20 seconds[3]) for
>> any errors to have time to make themselves known
>>3. Query Logstash (using a script written by Gabriel Wicke[4]) to
>> determine if the error rate has increased over a configurable threshold
>> (currently 10-fold[5])
>>
>> Big thanks to the folks that helped in this effort: Gabriel Wicke,
>> Filippo Giunchedi and Giuseppe Lavagetto, Bryan Davis and Erik Bernhardson
>> (for their mad Logstash skillz)!
>>
>> It is noteworthy, that in instances where expedience is required—we're in
>> the middle of an outage and who cares what Logstash has to say—the
>> `--force` flag can be added to skip canary checks all together (i.e. `scap
>> sync-file --force wmf-config/InitialiseSettings 'Panic!!'`).
>>
>> The RelEng team's eventual goal is still to move MediaWiki deployments to
>> the more robust and resillient Scap3 deployment framework. There is some
>> high-priority work that has to happen before the Scap3 move. In the
>> interim, we are taking steps (like this one) to respond to incidents and
>> keep deployments safe.
>>
>> Hopefully, this work and the error-rate alert work from Ori last week[6]
>> will allow everyone to be more conscientious and more keenly aware of
>> deployments that cause large aberrations in the rate of errors.
>>
>> <3,
>> Your Friendly Neighborhood Release Engineering Team
>>
>> [0].
>> https://wikitech.wikimedia.org/wiki/Incident_documentation/20160601-MediaWiki
>> is the recent example I could find, but there have been others.
>> [1]. https://phabricator.wikimedia.org/D248
>> [2]. https://gerrit.wikimedia.org/r/#/c/294742/
>> [3]. https://github.com/wikimedia/scap/blob/master/scap/config.py#L19
>> [4]. https://gerrit.wikimedia.org/r/#/c/292505/
>> [5]. https://github.com/wikimedia/scap/blob/master/scap/config.py#L18
>> [6]. https://gerrit.wikimedia.org/r/#/c/300327/
>>
>> ___
>> Ops mailing list
>> o...@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/ops
>>
>
> ___
> Ops mailing list
> o...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/ops
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Phabricator monthly statistics - 2016-05

[Alex Monk]

On 1 June 2016 at 02:19, Bartosz Dziewoński <matma@gmail.com> wrote:

> On 2016-06-01 02:24, Alex Monk wrote:
>
>> Here are the numbers that I'd like to draw people's attentions to:
>> Tasks created in (2016-05): 2572
>> Tasks closed in (2016-05): 2275
>> That's a difference of 297 tasks...
>> Difference (2016-05): 297
>> Difference (2016-04): 243
>> Difference (2016-03): 454
>> Difference (2016-02): 238
>> Difference (2016-01): 418
>> These difference should really be negative, but right now it looks like
>> we're slowly accumulating more and more bugs...
>>
>
> We are, and we've always been. If you go through the same data from the
> time of Bugzilla, I don't think you'll find a single month where the count
> decreased. I don't remember any myself.
>

I don't know about months as we used to get the data in weeks, but here are
the first two weeks in my inbox:
https://lists.wikimedia.org/pipermail/wikitech-l/2012-February/058189.html
https://lists.wikimedia.org/pipermail/wikitech-l/2012-February/058356.html
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Phabricator monthly statistics - 2016-05

[Alex Monk]

If you look back through all the previous monthly statistics emails,
account creations regularly go above 300 per month. Phabricator account
creations are done through first MediaWiki logins via OAuth or LDAP, yes.

Here are the numbers that I'd like to draw people's attentions to:
Tasks created in (2016-05): 2572
Tasks closed in (2016-05): 2275
That's a difference of 297 tasks...
Difference (2016-05): 297
Difference (2016-04): 243
Difference (2016-03): 454
Difference (2016-02): 238
Difference (2016-01): 418
These difference should really be negative, but right now it looks like
we're slowly accumulating more and more bugs...

On 1 June 2016 at 01:05, Pine W  wrote:

> I'm impressed by how many new accounts were created; 256 in a single month.
> I'd be interested to know what typically prompts people to create accounts.
> Also, does the 256 number include people who use their MediaWiki
> credentials to log into Phabricator for the first time?
>
> Just curious,
> Pine
>
> On Tue, May 31, 2016 at 5:00 PM,  wrote:
>
> >
> > Hi Community Metrics team,
> >
> > This is your automatic monthly Phabricator statistics mail.
> >
> > Accounts created in (2016-05): 256
> > Active users (any activity) in (2016-05): 861
> > Task authors in (2016-05): 484
> > Users who have closed tasks in (2016-05): 260
> >
> > Projects which had at least one task moved from one column to another on
> > their workboard in (2016-05): 0
> >
> > Tasks created in (2016-05): 2572
> > Tasks closed in (2016-05): 2275
> > Open and stalled tasks in total: 30026
> >
> > Median age in days of open tasks by priority:
> >
> > Unbreak now: 19
> > Needs Triage: 170
> > High: 280
> > Normal: 433
> > Low: 743
> > Lowest: 555
> >
> > (How long tasks have been open, not how long they have had that priority)
> >
> > 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 iridium at Wed Jun  1 00:00:10 UTC 2016)
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Best practice for WIP patches to help code review office hours

[Alex Monk]

On 12 May 2016 at 22:26, Jon Robson  wrote:

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

I think you can only -2 if you have the rights necessary to +2?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikitech-ambassadors] Tech News (2016, week 12)

[Alex Monk]

Reminder: The IRC breaking change is happening tomorrow!

On 21 March 2016 at 16:07, Johan Jönsson  wrote:

> Hi,
>
> The latest technical newsletter is now available at <
> https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News/2016/12>.
> Below is the English version.
>
> You can help write the next newsletter: whenever you see information about
> Wikimedia technology that you think should be distributed more broadly, you
> can add it to the next newsletter at <
> https://meta.wikimedia.org/wiki/Tech/News/Next>.
>
> More information on how to contribute is available at <
> https://meta.wikimedia.org/wiki/Tech/News#contribute>. You can also
> contact me directly.
>
> As always, feedback (on- or off-list) is appreciated and encouraged.
>
> —
>
> Other languages:
> čeština  • ‎
> Deutsch  • ‎
> Ελληνικά  • ‎
> English • ‎español
>  • ‎français
>  • ‎עברית
>  • ‎italiano
>  • ‎日本語
>  • ‎Ripoarisch
>  • ‎norsk bokmål
>  • ‎português
>  • ‎русский
>  • ‎svenska
>  • ‎українська
>  • ‎Tiếng Việt
>  • ‎中文
> 
>
> Latest *tech news
> * from the
> Wikimedia technical community. Please tell other users about these changes.
> Not all changes will affect you. Translations
>  are
> available.
>
> *Problems*
>
>- Wikimedia has a new backup data center in Dallas. The Wikimedia
>Technology department planned to test it this week. This will take place
>the week of April 18 instead. You can read more about the server work
>. There will
>be more notifications and updates about this.
>- In Firefox, the visual editor would sometimes just jump down to the
>bottom of the page when you double-clicked on a table cell. This has now
>been fixed. [1] 
>
> *Changes this week*
>
>- It will now be easier to list IP addresses that don't have to solve
>CAPTCHAs . [2]
>
>- You will now be able to mark Echo notifications as unread. [3]
>
>- [image: Octicons-sync.svg] The new version
> of MediaWiki
>will be on test wikis and MediaWiki.org from 21 March. It will be on
>non-Wikipedia wikis and some Wikipedias from 22 March. It will be on all
>wikis from 23 March (calendar
>).
>
> *Meetings*
>
>- [image: Octicons-sync.svg] You can join the next meeting with the
>VisualEditor team. During the meeting, you can tell developers which bugs
>you think are the most important. The meeting will be on 22 March at
>19:00 (UTC)
>
> .
>See how to join
>.
>
> *Future changes*
>
>- [image: Octicons-tools.svg] URLs in the recent changes IRC feed will
>no longer be rewritten to unencrypted HTTP. This could be a breaking change
>for bots dependent on the IRC feed. This will happen on May 2. [4]
>
>
> *Tech news
>  prepared
> by tech ambassadors
>  and
> posted by bot
> 
>  • Contribute
>  • 
> Translate
>  • Get
> help  • Give feedback
>  • Subscribe or unsubscribe
> 

Re: [Wikitech-l] Docs, use of, and admin privileges for wikimedia github project?

[Alex Monk]

On 27 April 2016 at 01:15, Bryan Davis  wrote:

> The Wikimedia GitHub project gives me two things in one place that I
> don't get elsewhere:
> * Find a repo based on some partial name I remember it probably has
> using the "Find a repository..." filtering at
> https://github.com/wikimedia/

https://gerrit.wikimedia.org/r/#/admin/projects/?filter= lets you do this
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Security patch

[Alex Monk]

It's not an extension that gets bundled with MediaWiki releases.

On 26 April 2016 at 19:52, Ryan Lane  wrote:

> Any chance that Wikimedia Foundation can actually do proper releases of
> this extension, rather than sending people a link to a phabricator page
> that has a link to a gerrit change buried in the comments?
>
> This seems like a pretty poor way to do a security release to third parties
> that may be relying on this.
>
> On Tue, Apr 26, 2016 at 11:44 AM, Jon Robson 
> wrote:
>
> > A security vulnerability has been discovered in MediaWiki setups which
> > use MobileFrontend.
> >
> > Revisions who's visibility had been alerted were showing up in parts
> > of the mobile UI.
> >
> > All projects in the Wikimedia cluster have been since patched but if
> > you use this extension please be sure to apply the fix.
> >
> > Patch file and issue are documented on
> > https://phabricator.wikimedia.org/T133700
> >
> > Note there is some follow-up work to do which is tracked in:
> > https://phabricator.wikimedia.org/T133722
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l 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] Docs, use of, and admin privileges for wikimedia github project?

[Alex Monk]

On 25 April 2016 at 17:01, Chris Steipp  wrote:

> Correct, all admins should have two-factor setup. I believe everyone who is
> an admin there has +2 in gerrit, and a reason to have the rights in Github.
> I'd propose those 3 things as a minimal standard, since I don't think we
> ever defined one


I don't think everyone with admin there at the moment meets those criteria.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Microsoft Edge browser testing notes

[Alex Monk]

On 15 April 2016 at 23:02, Brion Vibber  wrote:

> * There's a new public issue tracker for Edge
> 
> which is much easier to use than Microsoft Connect
>

Seems they closed all the old Connect bugs and didn't bother copying old
comments, or authorship of the old tasks. Issues "Reported by 0 people",
etc. :(
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] scheduled downtime for bast1001 tomorrow 1800 UTC

[Alex Monk]

It may also want the old key removed for the IP, done in the same way:
ssh-keygen -f "/home/yourusername/.ssh/known_hosts" -R 208.80.154.149

On 13 April 2016 at 19:04, Daniel Zahn  wrote:

> bast1001 is back, now on Debian jessie, and you can use it again.
>
> All users have been created by puppet and i rsynced /home dirs back from a
> temp.
> backup location, so all your old files are back.
>
> If you get an error "Host key verification failed.", remove the old
> key with something like:
>
>   ssh-keygen -f "/home/yourusername/.ssh/known_hosts" -R
> bast1001.wikimedia.org
>
> and accept the new keys, which have these fingerprints:
>
> https://phabricator.wikimedia.org/T123721#2204201
>
>
> +-+-+-+
> | Cipher  | Algo| Fingerprint |
> +-+-+-+
> | RSA | MD5 | 74:9a:74:e2:3b:ec:5d:fd:d4:45:8c:84:11:c8:9a:4e |
> | RSA | SHA-256 | rLmcE2r1JRrHrsOZIGZ3YHNJUzf4IOyTEg9wuCpDJjM=|
> +-+-+-+
> | DSA | MD5 | 45:f4:34:3a:c1:34:66:ef:a8:45:ad:ff:30:c4:d7:b2 |
> | DSA | SHA-256 | GlqVy4JESiO/j7ELqXyhIbl5oZGmWO8tgroavpPOX/s=|
> +-+-+-+
> | ECDSA   | MD5 | 9f:2b:ab:10:de:52:13:87:34:4c:20:52:be:0f:91:c3 |
> | ECDSA   | SHA-256 | uJjbBNi8661vAbuk6i9N5lc65AxT31nLEAO87/vJgcE=|
> +-+-+-+
> | ED25519 | MD5 | 8d:e2:1f:1b:4f:76:89:91:c1:99:dd:d5:a9:d9:0d:47 |
> | ED25519 | SHA-256 | cyZDMw0Oon1OJrNWD0xY+CETCaAZlyIBazYL1vtb1TE=|
> +-+-+-+
>
>
>
>
> On Tue, Apr 12, 2016 at 5:41 PM, Daniel Zahn  wrote:
> >
> > Hi,
> >
> > tomorrow at 1800 UTC (10am PST) i would like to upgrade bast1001 and
> > schedule some downtime.  I anticipate about an hour.
> >
> > Data from home dirs has already been rsynced elsewhere (and is in
> Bacula).
> >
> > Please switch to bast3001 or bast2001 during this period (or permanently
> if they are closer for you anyways).
> >
> >
> > --
> > Daniel Zahn 
> > Operations Engineer
>
>
>
>
> --
> Daniel Zahn 
> Operations Engineer
>
> ___
> 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] Phabricator was down for a short time today (April 4th)

[Alex Monk]

Yeah... It also still mentions mchenry. I marked it as outdated.

On 4 April 2016 at 19:24, Vituzzu <vituzzu.w...@gmail.com> wrote:

> Uhm, tech still lists OTRS on iodine, which seems to be decommissioned. I
> had a look at
> http://ganglia.wikimedia.org/latest/?r=year===cpu_report=Miscellaneous+eqiad=iridium.eqiad.wmnet=m==false=2=medium_group=NOGROUPS
> and...well fairly busy but still "packable", though I'll let more
> experienced people think about it ;)
>
> Vito
>
>
> Il 04/04/2016 20:11, Alex Monk ha scritto:
>
>> Actually I believe OTRS was moved into the ganeti VM cluster a couple of
>> months ago.
>>
>> I'm not sure whether Phabricator is considered a not-so-resource-consuming
>> service...
>>
>> On 4 April 2016 at 19:01, Vituzzu <vituzzu.w...@gmail.com> wrote:
>>
>> Why not a small virtualised cluster for these not-so-resource-consuming
>>> services like OTRS, phab, etc?
>>>
>>> /me runs away before writing the world-which-shouldn't be written
>>>
>>> Vito
>>>
>>> Il 04/04/2016 19:57, Greg Grossmeier ha scritto:
>>>
>>> Apologies for not sending out this announcement before hand.
>>>>
>>>> Short summary: The machine that Phabricator is hosted on rebooted itself
>>>> last night due to high temperatures. It ended up just shutting itself
>>>> down.
>>>>
>>>> Today we needed our DataCenter Technician to reapply the thermal paste
>>>> in an attempt to remedy the issue. That took less than 10 minutes but it
>>>> happened during the middle of the day.
>>>>
>>>> Full details: https://phabricator.wikimedia.org/T131742
>>>>
>>>> And yes, we are requesting a backup machine so issues like this won't
>>>> have as much of an impact on you (our users):
>>>> https://phabricator.wikimedia.org/T131775
>>>>
>>>> Best,
>>>>
>>>> Greg
>>>>
>>>>
>>>> ___
>>> Wikitech-l mailing list
>>> Wikitech-l@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>>
>>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Phabricator was down for a short time today (April 4th)

[Alex Monk]

Actually I believe OTRS was moved into the ganeti VM cluster a couple of
months ago.

I'm not sure whether Phabricator is considered a not-so-resource-consuming
service...

On 4 April 2016 at 19:01, Vituzzu  wrote:

> Why not a small virtualised cluster for these not-so-resource-consuming
> services like OTRS, phab, etc?
>
> /me runs away before writing the world-which-shouldn't be written
>
> Vito
>
> Il 04/04/2016 19:57, Greg Grossmeier ha scritto:
>
>> Apologies for not sending out this announcement before hand.
>>
>> Short summary: The machine that Phabricator is hosted on rebooted itself
>> last night due to high temperatures. It ended up just shutting itself
>> down.
>>
>> Today we needed our DataCenter Technician to reapply the thermal paste
>> in an attempt to remedy the issue. That took less than 10 minutes but it
>> happened during the middle of the day.
>>
>> Full details: https://phabricator.wikimedia.org/T131742
>>
>> And yes, we are requesting a backup machine so issues like this won't
>> have as much of an impact on you (our users):
>> https://phabricator.wikimedia.org/T131775
>>
>> Best,
>>
>> Greg
>>
>>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] How to find pages using the Score extension?

[Alex Monk]

quarry is under wmflabs.org, not wikimedia.org, as it's in labs :)

On 16 March 2016 at 00:12, Brian Wolff  wrote:

> On Tuesday, March 15, 2016, Daniel Mietchen <
> daniel.mietc...@googlemail.com>
> wrote:
> > Hi,
> >
> > I want to get an idea how many times the Score extension is invoked
> > but could find no way to go about that, nor to get a list of pages
> > using  or variants thereof on a per-wiki or per-category basis.
> >
> > Any pointers?
> >
> > Thanks,
> > d.
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> Try https://en.wikipedia.org/wiki/Special:PagesWithProp?propname=score (to
> truly get good stats, aggregated by categories, etc, you'd probably need to
> use quarry.wikimedia.org and do sql. Whether score is used on a page is
> stored in page_properities table)
>
> --
> bawolff
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] pt.wikimedia.org - database naming

[Alex Monk]

It's not clear to me either. No, and I don't feel like I should make this
(irreversible) decision. Sorry.

On 3 March 2016 at 20:15, Waldir Pimenta <wal...@email.com> wrote:

> Well, the conversation stalled in a way that made it unclear (to me at
> least) who can decide what option to choose (rename the db, if that's at
> all viable, or start a new wiki using pt2wikimedia, if that's acceptable,
> or something else). Is there anything we from Wikimedia Portugal can do or
> say to help move this forward?
>
> On Thu, Mar 3, 2016 at 2:16 PM, Alex Monk <kren...@gmail.com> wrote:
>
> > I'm not sure what you're expecting, Alchimista. I haven't received any
> > extra emails on the subject beyond those from the Phabricator task and
> > those on this list.
> >
> > On 3 March 2016 at 11:34, Alchimista <alchimist...@gmail.com> wrote:
> >
> > > Any update on this?
> > >
> > > 2016-02-24 18:39 GMT+00:00 Legoktm <legoktm.wikipe...@gmail.com>:
> > >
> > > > Hi,
> > > >
> > > > On 02/24/2016 06:18 AM, Antoine Musso wrote:
> > > > > Given most of the useful data/history has been exported, I would
> > > suggest
> > > > > to rename on WMF cluster the ptwikimedia DB to something like
> > > > > ptwikimedia_old or even just archive a dump of it and drop it.
> > > > >
> > > > > Then create a new ptwikimedia and import the external db there.
> > > >
> > > > I think reusing the "ptwikimedia" db name would be ideal. My only
> > > > concern with doing so is that it might be in databases somewhere,
> but I
> > > > checked CentralAuth and there are no ptwikimedia entries, so at least
> > > > that will be fine.
> > > >
> > > > -- Legoktm
> > > >
> > > > ___
> > > > Wikitech-l mailing list
> > > > Wikitech-l@lists.wikimedia.org
> > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > > >
> > >
> > >
> > >
> > > --
> > > Alchimista
> > > http://pt.wikipedia.org/wiki/Utilizador:Alchimista
> > > ___
> > > Wikitech-l mailing list
> > > Wikitech-l@lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] pt.wikimedia.org - database naming

[Alex Monk]

I'm not sure what you're expecting, Alchimista. I haven't received any
extra emails on the subject beyond those from the Phabricator task and
those on this list.

On 3 March 2016 at 11:34, Alchimista  wrote:

> Any update on this?
>
> 2016-02-24 18:39 GMT+00:00 Legoktm :
>
> > Hi,
> >
> > On 02/24/2016 06:18 AM, Antoine Musso wrote:
> > > Given most of the useful data/history has been exported, I would
> suggest
> > > to rename on WMF cluster the ptwikimedia DB to something like
> > > ptwikimedia_old or even just archive a dump of it and drop it.
> > >
> > > Then create a new ptwikimedia and import the external db there.
> >
> > I think reusing the "ptwikimedia" db name would be ideal. My only
> > concern with doing so is that it might be in databases somewhere, but I
> > checked CentralAuth and there are no ptwikimedia entries, so at least
> > that will be fine.
> >
> > -- Legoktm
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
>
>
>
> --
> Alchimista
> http://pt.wikipedia.org/wiki/Utilizador:Alchimista
> ___
> 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] Everything is a wiki page

[Alex Monk]

Thanks Nemo. Maybe we should tag this {{Development guideline}}?

On 2 March 2016 at 11:16, Federico Leva (Nemo)  wrote:

> I started https://www.mediawiki.org/wiki/Everything_is_a_wiki_page
>
> This is a very simple concept which, however, I find is often neglected.
> Some extension developers are conscious about what they do, but there is a
> lot of needless self-inflicted pain that we could do without.
>
> Nemo
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] pt.wikimedia.org - database naming

[Alex Monk]

Hi all,

A request has come up (https://phabricator.wikimedia.org/T126832) to
re-create pt.wikimedia.org on the wikimedia cluster. Unfortunately it was
previously hosted there and so the 'ptwikimedia' database name is already
taken.
Since database renaming does not really appear to be an option, does anyone
have any objections to using 'pt2wikimedia' (or similar, suggestions
welcome) instead for the new wiki? I know this doesn't fit the existing
pattern so I'm unsure about just going ahead without asking for input from
a wider audience.

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

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

[Alex Monk]

PRO from me, for all the reasons mentioned by legoktm

On 12 February 2016 at 19:26, Legoktm  wrote:

> Hi,
>
> On 02/12/2016 07:27 AM, Daniel Kinzler wrote:
> > Now that we target PHP 5.5, some people are itching to make use of some
> new
> > language features, like the new array syntax, e.g.
> > .
> >
> > Mass changes like this, or similar changes relating to coding style,
> tend to
> > lead to controversy. I want to make sure we have a discussion about this
> here,
> > to avoid having the argument over and over on any such patch.
> >
> > Please give a quick PRO or CON response as a basis for discussion.
> >
> > In essence, the discussion boils down to two conflicting positions:
> >
> > PRO: do mass migration to the new syntax, style, or whatever, as soon as
> > possible. This way, the codebase is in a consistent form, and that form
> is the
> > one we agreed is the best for readability. Doing changes like this is
> > gratifying, because it's low hanging fruit: it's easy to do, and has
> large
> > visible impact (well ok, visible in the source).
>
> I'll offer an alternative, which is to convert all of them at once using
> PHPCS and then enforce that all new patches use [] arrays. You then only
> have one commit which changes everything, not hundreds you have to go
> through while git blaming or looking in git log.
>
> > CON: don't do mass migration to new syntax, only start using new styles
> and
> > features when touching the respective bit of code anyway. The argument
> is here
> > that touching many lines of code, even if it's just for whitespace
> changes,
> > causes merge conflicts when doing backports and when rebasing patches.
> E.g. if
> > we touch half the files in the codebase to change to the new array
> syntax, who
> > is going to manually rebase the couple of hundred patches we have open?
>
> There's no need to do it manually. Just tell people to run the phpcs
> autofixer before they rebase, and the result should be identical to
> what's already there. And we can have PHPCS run in the other direction
> for backports ([] -> array()).
>
> But if we don't do that, people are going to start converting things
> manually whenever they work on the code, and you'll still end up with
> hundreds of open patches needing rebase, except it can't be done
> automatically anymore.
>
> > My personal vote is CON. No rebase hell please! Changing to the syntax
> doesn't
> > buy us anything.
>
> Consistency buys us a lot. New developers won't be confused on whether
> to use [] or array(). It makes entry easier for people coming from other
> languages where [] is used for lists.
>
> I think you're going to end up in rebase hell regardless, so we should
> rip off the bandaid quickly and get it over with, and use the automated
> tools we have to our advantage.
>
> So, if we're voting, I'm PRO.
>
> -- Legoktm
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Labs-l] New [[Main Page]] for Wikitech

[Alex Monk]

Nice. What is needed to get other labs projects listed on the front page
like tools?

On 29 January 2016 at 05:55, Bryan Davis  wrote:

> I've been working on a little redesign project for the Main Page on
> wikitech [0] and three key sub pages it points to since 2016-01-01 in
> my User space. Tonight I decided that although it is far from perfect
> it is better enough. I hope that some of you like it better than the
> old page and that none of you hate it with a fiery passion that
> compels you to revert it rather than helping me make it better.
>
> [0]: https://wikitech.wikimedia.org/wiki/Main_Page
>
> Bryan
> --
> Bryan Davis  Wikimedia Foundation
> [[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
> irc: bd808v:415.839.6885 x6855
>
> ___
> Labs-l mailing list
> lab...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/labs-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[Alex Monk]

On 28 January 2016 at 18:53, Rob Lanphier  wrote:

> This is especially true given that ArchComm really has absolutely no say
> > in resourcing and a given feature may not have secured funding (people,
> > hardware etc.)
> >
>
> Awwwyou're mail was so great, and then you ended with this!  Are you
> saying that the only real power in this world belongs to people with
> control of the money?


He wouldn't be the only one who thinks this. I've seen other people with
similar concerns about whether ArbComm is really in control or whether WMF
management is, because it's WMF management that actually gets to decide
what the paid Wikimedia developers (probably the majority of active
developers at this point) work on. I'm inclined to agree with them.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[Alex Monk]

(I did, of course, mean Ar*ch*Comm there, yes. Thanks to those of you who
pointed it out.)

On 28 January 2016 at 19:07, Alex Monk <kren...@gmail.com> wrote:

> On 28 January 2016 at 18:53, Rob Lanphier <ro...@wikimedia.org> wrote:
>
>> This is especially true given that ArchComm really has absolutely no say
>> > in resourcing and a given feature may not have secured funding (people,
>> > hardware etc.)
>> >
>>
>> Awwwyou're mail was so great, and then you ended with this!  Are you
>> saying that the only real power in this world belongs to people with
>> control of the money?
>
>
> He wouldn't be the only one who thinks this. I've seen other people with
> similar concerns about whether ArbComm is really in control or whether WMF
> management is, because it's WMF management that actually gets to decide
> what the paid Wikimedia developers (probably the majority of active
> developers at this point) work on. I'm inclined to agree with them.
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Close test2wiki?

[Alex Monk]

+1 from me for closing it. Do people have important things there, or can it
be 'deleted'?

On 27 January 2016 at 22:01, Chad  wrote:

> On Wed, Jan 27, 2016 at 2:00 PM James Forrester 
> wrote:
>
> > On 27 January 2016 at 13:57, Ori Livneh  wrote:
> >
> > > The setup of test2.wikipedia.org is no longer meaningfully different
> > from
> > > test.wikipedia.org. Is there a good reason for keeping test2?
> > >
> >
> > ​I'd be happy for it to be closed.​
> >
> >
> It was only setup ever so we could write/test het deploy.
>
> It became way less useful after we stopped serving test(1)
> from NFS.
>
> Close it.
>
> -Chad
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l