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

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

Re: [Wikitech-l] Scope of ArchCom

[Alex Monk]

On 28 January 2016 at 02:15, Legoktm  wrote:

> Hi,
>
> On 01/27/2016 12:46 PM, Matthew Flaschen wrote:
> > On 01/25/2016 03:16 PM, Rob Lanphier wrote:
> >> In the short-term, I believe a non-Wikimedia focused subgroup of ArchCom
> >> may make sense.  The declining MediaWiki use outside of Wikimedia has
> >> been
> >> a longstanding problem for us, but not the biggest problem.
> >
> > Are there stats that show a decline?  Just curious.
>
> These aren't exactly stats, but I think the Google Trends graph of
> "MediaWiki" vs. "Confluence" shows a relevant picture:
> <
> https://www.google.com/trends/explore#q=mediawiki%2C%20confluence=q=Etc%2FGMT-11
> >
>

Perhaps relevant, but that's not at all a complete picture of MediaWiki's
use. MediaWiki is linked to at the bottom of every Wikipedia page, and a
lot of interested users are going to be able to remember the domain name
without going through Google. Download traffic (direct from mw.o, but also
through OS package managers) would be a more useful indication.
___
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 25 January 2016 at 20:16, Rob Lanphier  wrote:

> So: forks welcome!  Any takers?

At this point I'm not sure any non-Wikimedia MediaWiki contributors have
the resources to do so. I think WMF employs most of the main MW developers,
and probably does >50% of the development.

On 25 January 2016 at 20:16, Rob Lanphier  wrote:

> The reason why I'm delineating it as a subgroup is not a power grab, but an
> essential step toward building the trust required for long term viability
> of a MediaWiki(?) Foundation to be viable.  The fact that the people
> working on the "MediaWiki Foundation" are still(!) using the name
> "MediaWiki" represents a failure of imagination among all of us.

On 25 January 2016 at 20:16, Rob Lanphier  wrote:

> Yes, I used the word "fork".  I believe Wikimedia Foundation would love it
> if MediaWiki forked, and we were "forced" to switch to the fork.

As it stands, Wikimedia Foundation is the only trusted upstream for the

MediaWiki codebase.  I believe WMF should jealously guard the "MediaWiki"

trademark, if for no other reason than to force someone to come up with a

different name.  "MediaWiki" and "Wikimedia" are too similar, and there are

not good reasons for us to license that trademark to anyone else.  WMF

doesn't have a patent on the alphabet; come up with your own damn name  ;-)


So Wikimedia would keep the MediaWiki trademark and no longer have to worry
about supporting 'third parties', and presumably most of the MW code
actively being developed by Wikimedia would no longer be expected to run
outside of WMF production/beta cluster/developer's laptops? I assume you'd
merge MediaWiki.org into wikitech.wikimedia.org and copy the
non-Wikimedia-specific stuff to be imported into a new (non-WMF-hosted)
wiki for the fork, controlled by the maintainers of the fork.

I'm picturing a situation whereby a (probably unlikely to be successful)
fork is made, MediaWiki core (now entirely a Wikimedia thing) is changed to
depend on various things such as external services (probably with various
WMF-specific requirements/expectations), the fork never really takes off,
and we're left with MediaWiki that no longer supports anyone but Wikimedia.
That seems like quite a risk.

I like the idea of MediaWiki being a proper independent upstream, not just
a fork that's set up to get 'third parties' out of the largest MW
contributor's hair and then left to diverge significantly (to the point
where WMF couldn't simply migrate on the normal deployment branching
schedule) and/or die.

 On 25 January 2016 at 20:16, Rob Lanphier  wrote:

> If we should be pressuring anyone
> to make non-Wikimedia use of MediaWiki viable, it shouldn't be WMF, someone
> from Wikia should step up. :-P
>
I'm not sure anyone is pressuring WMF into putting resources into
developing new things only 'third parties' need. Non-Wikimedia use of
MediaWiki is already viable, and just like all other contributors,
Wikimedia is expected to keep MW core reasonably generic enough such that
it can be used by others, which seems to cause certain people within
Wikimedia to want to get rid of everyone else so they can do their own
thing.
Didn't Wikia fork long ago?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Proposal regarding the future of X-Wikimedia-Debug and testwiki

[Alex Monk]

Trying again from a different address

On 26 January 2016 at 01:04, Alex Monk <am...@wikimedia.org> wrote:

> Forwarding to wikitech-l since this is not really specific to staff, but
> all shell users.
>
> On 25 January 2016 at 20:39, Ori Livneh <o...@wikimedia.org> wrote:
>
>> The X-Wikimedia-Debug header, for those of you who don't know, is an HTTP
>> request header that you can set on your requests (either manually, or by
>> using the Chrome[1] or Firefox[2] extensions). Requests bearing this header
>> are always treated as cache misses by Varnish, and they are always routed
>> to the same backend, mw1017.
>>
>> In addition to handling X-Wikimedia-Debug requests, mw1017 is also
>> configured as the sole application server backend for all requests to
>> test.wikimedia.org. This was set up before X-Wikimedia-Debug existed,
>> and as a debugging tool it is (IMO) inferior to it, because
>> X-Wikimedia-Debug allows you to test code changes against any production
>> wiki.
>>
>> What I've seen happen before is developers (like me -- I've done this
>> before) live-hack code on mw1017 to debug some issue that is only showing
>> up in production. This can cause testwiki to break, which annoys developers
>> and editors who use testwiki for testing things like Lua modules or editing
>> functionality on mobile apps.
>>
>> To reduce contention for mw1017, I propose that we do the following:
>>
>> 1) Keep testwiki, but don't special-case it in Varnish
>> (in other words, have testwiki requests go to the standard app server
>> pool)
>>
>> 2) Reserve mw1017 exclusively for X-Wikimedia-Debug requests
>>
>> 3) Add a service alias (appservers-debug.svc.eqiad.wmnet) for mw1017 and
>> update the varnish backend config to use that, rather than hard-code mw1017
>> in VCL.
>>
>> Thoughts?
>>
>>  [1]:
>> https://chrome.google.com/webstore/detail/wikimediadebug/binmakecefompkjggiklgjenddjoifbb?hl=en-US
>>  [2]:
>> https://addons.mozilla.org/en-US/firefox/addon/wikimedia-debug-header/
>>
>>
>> ___
>> Engineering mailing list
>> engineer...@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/engineering
>>
>>
> --
> 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] Scope of ArchCom

[Alex Monk]

To clarify - are you saying this is the actual current scope of ArchCom, or
are you advocating for a change in scope?

On 22 January 2016 at 22:03, Rob Lanphier  wrote:

> ArchCom is the mechanism we hope to ensure
> we build and deploy increasingly excellent software on the Wikimedia
> production cluster in a consensus-oriented manner.  MediaWiki is at the
> center of this, but ArchCom's responsibility doesn't end with MediaWiki.
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Ifexists across wikis

[Alex Monk]

I don't think there is a way to get a database name from an interwiki
prefix.

Also, whether a page is known or not does not just depend on a simple
database lookup. Extensions can add arbitrary rules about which titles
should be considered known or not. EducationProgram, GlobalUserPage, and
WikimediaIncubator all do this.

On 6 December 2015 at 16:26, Lars Aronsson  wrote:

> If I write a [[link]] it will be blue if the page exists and red otherwise.
> But if I write [[:sw:link]] that will be an external or cross-wiki link,
> that is never red, as if it were impossible to know whether that page
> existed in Swahili Wikipedia.
>
> But determining the existence of a page is just a quick database table
> lookup, and all databases run on WMF's servers, so it shouldn't be more
> expensive to look up a cross-wiki link, as long as it is one of WMF's
> wikis.
>
> In Wiktionary, it is common to link to entries in foreign languages both
> on the local wiki and to the native wiki for that language. For example,
> in English Wikitionary the entry for "blue" links to the Swahili word
> "bluu"
> both on en.wiktionary and on sw.wiktionary, using the template
> {{t+|sw|bluu}}.
>
> https://en.wiktionary.org/wiki/blue#Translations
>
> But since the Afrikaans translation "blou" doesn't have an entry on the
> Afrikaans Wiktionary, another template is used: {{t|af|blou}}. And it is
> a pain to know which one of these two templates to use. If it was possible
> in {{#ifexists}} to determine the existence of a page in another wiki,
> only one template would be needed, and the bot job to change to the right
> template would not be needed.
>
> #ifexist already works across namespaces (well, of course), so is there any
> good reason it shouldn't work across wikis?
>
> Oddly, the documentation says #ifexist is an "expensive" parser function.
> That doesn't make much sense to me. It's as if red/blue links were
> expensive, and most of our list pages should be banned.
> https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23ifexist
>
>
> --
>   Lars Aronsson (l...@aronsson.se)
>   Aronsson Datateknik - http://aronsson.se
>
>
>
> ___
> 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] PHP 7.0.0 Released

[Alex Monk]

Wasn't newphp actually a keyword imported from Bugzilla into Phabricator as
a tag?

On 4 December 2015 at 00:37, MZMcBride  wrote:

> Ricordisamoa wrote:
> >The PHP development team announces
> > the immediate
> >availability of PHP 7.0.0.
> >The newphp  project has
> >been created in Phabricator to track incompatibility issues.
>
> Regarding the Phabricator tag, it looks to have been created in November
> 2014, if I'm reading its history correctly.
>
> The tag description says "Tag for issues involving changes in upcoming/not
> yet released PHP versions" and PHP 7.0.0 is now neither, right?
>
> In general, it seems a bit silly/shortsighted to use "new" in a name. A
> more specific project name such as #php7 might be better.
>
> 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] Code of Conduct: Intro, Principles, and Unacceptable behavior sections

[Alex Monk]

On 5 September 2015 at 23:19, David Gerard  wrote:
>
> > I don’t feel safe because there is a code of conduct. But I tell you one
> thing that makes me feel unsafe – men who will endlessly, vociferously
> argue against them. Maybe a code of conduct isn’t meaningful. But at this
> point, refusing to listen, refusing to have one. Well, that is.


This quote seems a bit sexist to me.

Actually, I wonder whether the current draft of the code of conduct would
allow you to send it here or not.

On 6 September 2015 at 01:42, Risker  wrote:

> On 5 September 2015 at 19:11, MZMcBride  wrote:
> 
>
> > It seems weird to me that the
> > push (perhaps a movement, who knows) to implement codes of conduct has
> > become so enmeshed with the ultra-liberal feminist movement.
> >
>
> Really?
> https://en.wikipedia.org/wiki/Code_of_the_United_States_Fighting_Force


How is this relevant to what MZMcBride said?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] renaming Wikimedia domains

[Alex Monk]

On 26 August 2015 at 15:13, Jaime Crespo jcre...@wikimedia.org wrote:

 AFAIK It requires a patch, that is proposed (by Reedy,
 I think), but not implemented.

I'm not convinced that patch is needed. We already have $staticMappings in
multiversion which should allow the new domain to be pointed to the old
databases.


 DB dependencies on FlowDB, external storage and X1 plugins, plus some names
 inside the rows.

AFAIK these do not need to be changed. For example, www.mediawiki.org's
database name is mediawikiwiki, not wwwmediawiki. The same is true on x1,
the external storage clusters, and (for example) in localuser.lu_wiki in
the centralauth DB. It already has a domain name which does not match the
database name.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] renaming Wikimedia domains

[Alex Monk]

On 26 August 2015 at 10:35, Jaime Crespo jcre...@wikimedia.org wrote:

 Due to internal (and growing) complexity of the mediawiki software, and WMF
 installation (regarding numerous plugins and services/servers), this is a
 non trivial task. It also involves many moving pieces and many people-
 network admins (dns), general operations (load control/downtime), dbas
 (import/export), services, deployment engineers and developers (mediawiki
 configuration changes, patches).

 What's worse, is that it would almost certainly create downtime for the
 wikis involved (not being able to edit) -specially given that it is not a
 common operation-, and some of them are smaller communities, and I would be
 worried be to annoy or discourage editing on those wikis (when we want the
 opposite!).


I'm not sure why database changes would be involved in a domain-only
change? It should be simple enough to get the new domain set up in DNS and
apache config, tell multiversion how to map it to the old DB name (there's
an array in setSiteInfoForWiki that does this bit), and once it's all
working swap wgServer and related variables over to the new domain.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] renaming Wikimedia domains

[Alex Monk]

On 27 August 2015 at 04:57, Brian Wolff bawo...@gmail.com wrote:

 If we can serve from two different
 domains, surely we could serve from two domains, delete 1, and then
 just serve from the new domain.

That's my plan with https://gerrit.wikimedia.org/r/#/c/233972/ - I've added
it to the puppet SWAT window later today. When ops have approved it, it
should just be a case of me setting up MediaWiki to use the correct
database name, and then wgServer etc. can be changed and the old domain can
be redirected.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Code of conduct

[Alex Monk]

It looks like Communicate about technology in public where possible.
Private means of communication do exist, but prefer to use public places
unless an exception is appropriate. has been removed and Publication of
non-harassing private communication. has been added as a form of
harassment...

On 18 August 2015 at 01:10, Matthew Flaschen mflasc...@wikimedia.org
wrote:

 On 08/06/2015 08:17 PM, Matthew Flaschen wrote:

 Please participate at
 https://www.mediawiki.org/wiki/Code_of_conduct_for_technical_spaces/Draft
 .


 The draft has now been rebased onto Contributor Covenant (a widely used
 Code of Conduct), per a discussion on our talk page.

 Now is a good time to help refine the draft to make sure previously
 discussed issues are still addressed, and Wikimedia-specific questions are
 answered.


 Thanks,

 Matt Flaschen


 ___
 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] VE plugin related questions

[Alex Monk]

The save button should be enabled if your model is marked as having been
modified - see ve.dm.Surface.prototype.hasBeenModified in
VisualEditor/VisualEditor.git - it is at least partially based on the undo
stack, so these two problems are almost certainly linked.
I think you should be using transactions in some way to have that work
properly, Ed would know the details.

On 17 July 2015 at 08:33, Nischay Nahata nischay...@gmail.com wrote:

 Hi all,

 I have been working on a small VE plugin that provides the functionality of
 adding SMW annotations. I am mostly done with the script but need to
 understand some minor coding practices for VE plugins to complete it. Would
 appreciate some help on these questions.

 When the script makes some changes to the document model, sometimes the
 Save button stays greyed out. Is there a way I should trigger the save
 button to become active? Or maybe I am doing something in the wrong way.

 The undo doesn't seem to automatically work for my code, what's the best
 way to develop that functionality?

 I have a couple more doubts, but these are the major ones right now.
 Here's my code if needed, its a mess right now and needs lot of
 refactoring, etc

 https://en.wikipedia.org/wiki/User:Nischayn22/veSMW.js

 Thanks and regards,
 Nischay Nahata
 ___
 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 tag for bugs in local projects

[Alex Monk]

A single gadgets project that just tracks an issue with any MediaWiki
gadget out there is just going to create a completely useless mess. I think
that to track an issue with a gadget in Phabricator, there should be at
least one associated project for the specific gadget (i.e., not just a tag
or community-wishlist type thing), and these gadget projects should need to
be created at the request of/with the knowledge of the actual gadget
maintainer (otherwise it's going to be pretty pointless).

On 16 July 2015 at 00:21, Pine W wiki.p...@gmail.com wrote:

 Perhaps Engineering Community as well? Unlike Community Tech, CE has a
 manager and therefore perhaps more ability to address this sooner. Any
 comments, Quim?

 Thanks!
 Pine
 On Jul 15, 2015 10:16 PM, Jon Robson jdlrob...@gmail.com wrote:

  I'm encountering a similar problem now -
  https://phabricator.wikimedia.org/T99361
 
  On phabricator should there be a gadgets project? Community project?
 
  I hit this issue all the time and to me is the biggest flaw with the
  fact editors can introduce code. Templates/gadgets for me are hard to
  debug, as it's hard for me to first locate the code, to understand it
  (since it's not hosted in the same way as our other code and is
  typically written very differently) and then to identify who owns it
  and who I can discuss fixing with.
 
  This would be a great problem for the new community dev team to think
  about imo.
 
  On Thu, Jul 16, 2015 at 12:27 PM, Amir E. Aharoni
  amir.ahar...@mail.huji.ac.il wrote:
   Hi,
  
   In the past it happened to me a few times that I opened bugs about
   something wrong that happened on a Wikimedia site, and it was closed as
   invalid because the issue was not in MediaWiki code, but in a local
  gadget,
   style or template on that project.
  
   The bugs were actually fixed, but I'd like to question the invalid
   closure.
  
   They were real bugs in real products. The fact that the software is not
  in
   Gerrit doesn't mean that they don't affect the product de facto. Just
 for
   the sake of example, if a bug in a local Gadget affects the Flow
  extension,
   for example, I find it perfectly valid to add tag the Flow tag to it.
  Core
   and extension developers should be curious about how what they
 developed
   behaves in the wild.
  
   I do wonder what other tags are there to add to such a bug? I'm going
 to
   open one now.
  
   (P.S. Yes, this raises an issue of whether non-Wikimedia sites should
   count. I say - yes, and it shouldn't be limited unless it gets
 seriously
   out of hand. But a URL with reproduction instructions must always be
   provided.)
  
   --
   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
 
 
 
  --
  Jon Robson
  * http://jonrobson.me.uk
  * https://www.facebook.com/jonrobson
  * @rakugojon
 
  ___
  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] VE stopped working on 1.25 after import update of wiki db (1.23-1.25)

[Alex Monk]

Do you run `git submodule update --init` after checking out REL1_25 of VE?
What is in your browser's developer console when you try to load VE?

On 10 July 2015 at 21:51, Daren Welsh darenwe...@gmail.com wrote:

 We have an existing wiki using MW 1.23. We are working on a build script to
 generate a wiki using MW 1.25. Eventually the script will also automate the
 database import and update, but for now I'm still learning the steps.

 I built a VM with 1.25 and VE using some scripts that we are building[1].
 VE seemed to be happily working. Then I imported our 1.23 SQL database and
 files (/images). I ran update.php and runJobs.php. Now it seems VE hangs at
 about the 75% point of the blue progress bar after clicking Edit. Note
 that I am still able to edit source.

 I know this is not enough to get a full answer, but I'm hoping you can help
 me find some more resources to try. For example, are there any significant
 changes between the REL1_25 branch of Parsoid and HEAD? I see the branch on
 Gerrit, but I couldn't see that branch in git for a checkout.

 Thanks,

 Daren

 [1] https://github.com/enterprisemediawiki/Meza1


 --
 __
 http://enterprisemediawiki.org
 http://mixcloud.com/darenwelsh
 http://www.beatportfolio.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