Re: [Wikimedia-l] Hindi Wikisource waiting, developer needed

2019-05-08 Thread Brad Jorsch (Anomie) 
On Wed, May 8, 2019 at 10:15 AM Yann Forget  wrote:

> Hi,
>
> The Hindi Wikisource is blocked by some technical problems with no
> resolution expected shortly. The last comment in the ticket is:
>
> The issue still exists and it's impossible to make new wikis without lots
> of bandage and hacks. I'm doing this in volunteer capacity and I don't have
> time to do it anymore :(
>
> The ticket was opened on March 13th.
> The community is actively waiting.
> Some workshops are planned, but postponed because of this issue.
> So this task should be given to some developer from WMF.
>

Based on the quoted comment and date, I'm guessing the task in question is
https://phabricator.wikimedia.org/T218155.

FYI: I don't know any details about new wiki creation, I'm just posting the
task link in the hope it will help people who do to find your task.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

[Wikimedia-l] Fwd: Unblocking 79 IPs blocked as open proxies 12 years ago (T189840)

2018-03-21 Thread Brad Jorsch (Anomie) 
Forwarding, since I screwed up trying to send it to this list the first
time.

-- Forwarded message --
From: Brad Jorsch (Anomie) <bjor...@wikimedia.org>
Date: Wed, Mar 21, 2018 at 2:50 PM
Subject: Unblocking 79 IPs blocked as open proxies 12 years ago (T189840)
To: Wikimedia developers <wikitec...@lists.wikimedia.org>, MediaWiki
announcements and site admin list <mediawik...@lists.wikimedia.org>


In 2005–2006 a sysadmin blocked 79 IP addresses on all wikis as being
automatically-detected open proxies, without recording them in the block
log or attributing the block to any user account. These incomplete records
are now causing errors when MediaWiki tries to access them in various
places, see https://phabricator.wikimedia.org/T189840.

Since these are all over 12 years old, it seems reasonably likely that many
of these are no longer open proxies. Rather than trying to fix the
incomplete records, I'm just going to remove them.

Any existing blocks of these IPs that are not causing errors will not be
removed. At first glance this seems relevant mainly to enwiki, where only 5
of the IPs have incomplete records. 21 are currently blocked there with
complete records (19 since 2005 or earlier), and the other 53 are not
currently blocked there.

The list of IPs is at https://phabricator.wikimedia.org/P6876 in case
anyone wants to review them for potential reblocking.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Re: [Wikimedia-l] A fundraising banner we'd like to try in a short test

2017-11-16 Thread Brad Jorsch (Anomie) 
On Thu, Nov 16, 2017 at 3:35 AM, geni <geni...@gmail.com> wrote:

> On 14 November 2017 at 22:12, Samuel Patton <spat...@wikimedia.org> wrote:
> > If you have thoughts on this design, please share them here. There will
> be
> > more opportunities for you to weigh in if this banner variant looks
> > promising enough to keep testing.
> >
> > Regards and sincere thanks for all you do.
> >
>
>
> Covers up half the periodic table on:
>
> https://en.wikipedia.org/wiki/Periodic_table?banner=dsk_p1_
> lg_right10=US=1
>
> In fact lets just face it this thing does not like tables:
>
> https://en.wikipedia.org/wiki/Canon_EF_400mm_lens?banner=
> dsk_p1_lg_right10=US=1
>
> It overlaps longer equations (see around the Efficient methods section):
>
> https://en.wikipedia.org/wiki/Approximations_of_%CF%80?
> banner=dsk_p1_lg_right10=US=1
>
> I suspect it also breaks with lilypond but I don't have an example to hand
>

It would be more accurate to say that it overlaps content that overflows
the 'content' div, whatever the reason for the overflow. And it may lead to
overflow in more situations, since it reduces the area available to the
content div. The usual horizontal scrolling that happens for content that
overflows the content div doesn't work right with the banner in place
because the scrolling takes effect on the body element rather than the
content div. Using the close button on the banner does seem to return these
pages to the status quo.

I see the Timeless skin has a vaguely similar issue (without the banner).
That skin does apply the horizontal scrolling to the content div, but the
scrollbar is way at the bottom of the page instead of at the bottom of the
screen.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Re: [Wikimedia-l] New style banner - A heads up

2017-08-23 Thread Brad Jorsch (Anomie) 
On Wed, Aug 23, 2017 at 12:03 PM, Lodewijk <lodew...@effeietsanders.org>
wrote:

> I can see that confusing people is not what we should be aiming for :)
> Would it help sooth your mind when there is a clear distinction between
> content and banner, even if the look and feel is the same? (I can imagine
> that you could accomplish this by doing the banner at full site width, for
> example)
>

I suspect making a clear distinction and making it use the same look and
feel are opposing goals. But I'm not a very good designer, maybe you can
make it work somehow.


> but at the same time I recognize that community
> members have been asking Fundraising to make the banners less 'in your
> face' and 'ad-like' (which is by far the obvious way to make sure nobody
> gets confused about the seperation).
>

My gut feeling there is that those people will consider a full-page ad as
being "in your face" whether it looks like a traditional banner or like
content.

Personally, I'd rather have clearly demarcated ads. When ads try to blend
into content too well, I feel like the advertiser is trying to trick me.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Re: [Wikimedia-l] New style banner - A heads up

2017-08-23 Thread Brad Jorsch (Anomie) 
On Wed, Aug 23, 2017 at 11:01 AM, Joseph Seddon <jsed...@wikimedia.org>
wrote:

> New Native feel:
> https://en.wikipedia.org/wiki/Albert_Einstein?banner=B1718_
> 0823_en6C_dsk_p1_lg_dsn_native=1=US=QA
>

Personally, I really dislike banners that try to pretend to be content.
This one makes it look like the page is an article titled "To all our
readers in the U.S." rather than a page with a banner on it.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Re: [Wikimedia-l] Let's set up a Tor onion service for Wikipedia

2017-06-14 Thread Brad Jorsch (Anomie) 
On Wed, Jun 14, 2017 at 10:57 AM, Faidon Liambotis <fai...@wikimedia.org>
wrote:

> Just to mention a couple of issues: one of them is that we need MediaWiki
> to emit different URLs for e.g.  upload.wikimedia.org resources to point
> to the onion address that we will designate for media.


That part reminds me a bit of https://phabricator.wikimedia.org/T156847,
which is about outputting different addresses in links for the mobile site
versus the desktop site. The same solution might work for both onion links
and mobile site links.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Re: [Wikimedia-l] WikiJournal project

2017-03-15 Thread Brad Jorsch (Anomie) 
On Tue, Mar 14, 2017 at 10:45 PM, Felipe Schenone 
wrote:

> If we migrate the content we currently have (on Meta and
> Wikiversity) to wikijournal.org, and the project grows, and eventually
> gets
> accepted as a sister-project (as we hope), how will we merge the user
> accounts? Should we not worry about it, and we'll figure it out when the
> time comes? Or should we totally worry about it, and adopt some strategy
> about it now? What's your advice on this issue?


Note: This post is my personal view and in no way represents any official
WMF position.

My personal guess is that it would wind up being done something like how
accounts on WikiVoyage were handled: people who used the same username on
both WikiVoyage and Wikimedia wikis were able to merge those accounts,
people whose usernames weren't already in use on Wikimedia wikis were able
to claim those names, and other people had to be renamed. Or at least it
seems that's what was done based on the plan document on mediawiki.org[1]
and the process page on en.wikivoyage.org.[2]

To reduce the number of people who would need renaming should the time
come, you might start using an extension like OAuthAuthentication[3] to
authenticate against Meta, and disable any further local account creations.

[1]: https://www.mediawiki.org/wiki/Wikivoyage_migration/Accounts
[2]: https://en.wikivoyage.org/wiki/Wikivoyage:User_account_migration
[3]: https://www.mediawiki.org/wiki/Extension:OAuthAuthentication
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,

Re: [Wikimedia-l] Campaigns extension / ServerSideAccountCreation log - does anyone still use it?

2016-05-31 Thread Brad Jorsch (Anomie) 
On Thu, May 26, 2016 at 2:56 PM, Brad Jorsch (Anomie) <bjor...@wikimedia.org
> wrote:

> Question 1: Would anyone care if we kill the "loginCTA" campaign, which
> tracks when people use the link at the bottom of Special:UserLogin to get
> to the account creation page?
>
> Question 2: Would anyone care if we remove the extension entirely from
> Wikimedia wikis? Wikiapiary seems to show only one user outside of
> Wikimedia.
>

Following up on this: Since the answer to Question 2 was yes, we've done
the necessary update to Campaigns so it will continue working with
AuthManager.[1] Since no one answered Question 1, the loginCTA campaign has
been removed. It will stop showing up in 1.28.0-wmf.4, which rolls out this
week.

 [1]: https://gerrit.wikimedia.org/r/#/c/291280/


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

[Wikimedia-l] Campaigns extension / ServerSideAccountCreation log - does anyone still use it?

2016-05-26 Thread Brad Jorsch (Anomie) 
Question 1: Would anyone care if we kill the "loginCTA" campaign, which
tracks when people use the link at the bottom of Special:UserLogin to get
to the account creation page?

Question 2: Would anyone care if we remove the extension entirely from
Wikimedia wikis? Wikiapiary seems to show only one user outside of
Wikimedia.

Background: The extension needs a rewrite for AuthManager, and in
particular the "loginCTA" campaign will be a bit of a pain to keep working.
If someone is making use of the extension that's fine, but if not we may as
well not continue to spend development resources on it.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Re: [Wikimedia-l] WMF trustee Arnnon Geshuri and part in anticompetitive agreements in Google

2016-01-09 Thread Brad Jorsch (Anomie) 
ObDisclaimer: This reply consists of my own personal views and in no way
represents anything official.

I think I can leak a little useful information on this topic without fear.
;)

On Sat, Jan 9, 2016 at 3:12 AM, Anders Wennersten <m...@anderswennersten.se>
wrote:

> I also think it would be good  to remember that WMF transformation from
> the "Superprotect disaster" to a very much appreciated 2015 Community
> Wishlist Survey. To go from an "inside-out" to an "outside-in" model in
> deciding what functionality to develop is a revolution. And even if we as
> users all applaud this change, we should also respect it can be felt tough
> to adjust to if you are "inside"
>

You seem to be assuming that staff have had a negative reaction to the idea
of the Community Wishlist. From what I've seen on the internal mailing
list, staff are very supportive of this. The word "awesome" was used
several times in replies on the thread announcing it.

The closest thing to a negative comment I see wasn't very negative at all.
Paraphrased, "At first I was afraid this would be more lip-serivce, but now
I see it and you're really interested in community input."

For more positive comments you can see some of the staff replies to <
https://lists.wikimedia.org/pipermail/wikimedia-l/2015-December/080329.html>,
since that announcement was CCed to the internal list and some people used
"reply all".


> I give Lila 100% credit for this change and thank the Board for supporting
> this change (and also to have recruited Lila with this as main purpose)


IMO, you should give credit to the Community Tech team. They're the ones
who came up with the wishlist idea and did it, unless I'm totally mistaken.

You could also give some credit to the staffers who originally proposed
creating the Community Tech team. It wasn't a top-down proposal.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Re: [Wikimedia-l] Announcement about changes to the Board

2015-12-30 Thread Brad Jorsch (Anomie) 
On Dec 30, 2015 12:33 AM, "Craig Franklin" 
wrote:
> but also for why there was seemingly not any planning for how to deal
> with the fallout of that decision.

That, at least, was addressed in the text from Jimbo that you quoted:

> >  Why didn't that happen?  Because James chose to post
> > about it before we even concluded the meeting and before we had even
> > begun to discuss what an announcement should say.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,

Re: [Wikimedia-l] Community Wishlist Survey: Top 10 wishes!

2015-12-28 Thread Brad Jorsch (Anomie) 
On Mon, Dec 28, 2015 at 12:51 PM, Henning Schlottmann  wrote:

> Switching dead links to the archive is a move to a dead end, instead of
> looking for
>
> a) the new correct URL, as many links were just moved.
> b) alternative sources for the same fact.
>

An automated process can't reliably do either of those, while having the
archive link available will make it easier for human editors to do both of
those since they'll have the actual content of the dead link available
rather than just what information is preserved in the citation (URL, title,
author, maybe a short quotation).
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,

Re: [Wikimedia-l] (no subject)

2015-12-04 Thread Brad Jorsch (Anomie) 
On Fri, Dec 4, 2015 at 10:57 AM, Michael Peel <em...@mikepeel.net> wrote:

> Try when logged out - the links worked fine for me after logging out.
>

They work fine for me even when logged-in. Since it's enwiki, you might
check if you have the "Suppress display of fundraiser banners" gadget
enabled (or similar code in your user .js or .css) if it's not working for
you.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Re: [Wikimedia-l] Update from the Wikimedia Performance Team

2015-11-05 Thread Brad Jorsch (Anomie) 
On Thu, Nov 5, 2015 at 2:13 PM, Ori Livneh <o...@wikimedia.org> wrote:

> Improving future-proof maintainability by taking thumbnail code out of
> MediaWiki-Core and using a service instead to perform thumbnail operations.


How does that affect third-party use of MediaWiki where people aren't able
to (or just aren't wanting to) install bespoke services?


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Re: [Wikimedia-l] Wikimedia Commons

2015-09-01 Thread Brad Jorsch (Anomie) 
On Mon, Aug 31, 2015 at 8:55 PM, Eduardo Testart <etest...@gmail.com> wrote:

> Brad,
>
> Reported as bets as I could on:
> https://phabricator.wikimedia.org/T94562


The necessary part was the "[b7e99e43] Exception Caught" and "[97b50521]
Exception Caught". That allows me to look up the exception in the logfiles
on the server to see details as to what exactly is causing it.

Let's have further discussion in Phabricator.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Re: [Wikimedia-l] Wikimedia Commons

2015-08-31 Thread Brad Jorsch (Anomie) 
On Mon, Aug 31, 2015 at 3:05 PM, Eduardo Testart <etest...@gmail.com> wrote:

> I do not know what is creating this errors (I am uploading PDF's), but it
> would be really nice if someone could either check it up to see if it can
> be fixed


Step 1 would be for you to report the entire error message you're
receiving. In particular, the error message will begin with something like
"[0badf00d] Exception Caught:", that and the date and time you received the
error will allow people with access to the logs to look up details on the
error.

For the "url2commons" tool, you'd do best to talk with the maintainer of
that tool.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Re: [Wikimedia-l] harald bischoff advertising to make images for the wikimedia foundation and then suing users

2015-07-20 Thread Brad Jorsch (Anomie) 
***note this reply is entirely in my personal capacity and in no way
represents anything official***

On Jul 20, 2015 3:09 AM, rupert THURNER rupert.thur...@gmail.com wrote:

 the distinction because wikipedia is owned by wmf we refer
 differently to commons than anybody else needs to go away imo.

Since when has that ever been a thing? With respect to licenses such as CC,
we follow the same rules as anyone else.

If the description here is accurate, it sounds to me like this harald
bischoff should be blocked and possibly have his files deleted as
incorrectly licensed (since he apparently doesn't accept the usual
interpretation of CC BY), unless he publicly renounces the behavior of
suing reusers. But I'll leave that to Commons and dewiki to work out.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] harald bischoff advertising to make images for the wikimedia foundation and then suing users

2015-07-20 Thread Brad Jorsch (Anomie) 
***note this reply is still entirely in my personal capacity and in no way
represents anything official***
On Mon, Jul 20, 2015 at 12:09 PM, Robert Rohde raro...@gmail.com wrote:

  Since when has that ever been a thing? With respect to licenses such as
 CC,
  we follow the same rules as anyone else.
 

 Not really.  Commons actually recommends that an explicit credit line
 accompany CC BY images, which is something that Wikipedia doesn't do in
 articles.  See below.


Sigh.

I think I'll refrain from further comment on Commons' statement.


On Mon, Jul 20, 2015 at 2:39 PM, Robert Rohde raro...@gmail.com wrote:

 but in another narrative
 you are telling content creators that the few rights they are nominally
 granted by the required license (e.g. attribution) are worthless because if
 they try to enforce those rights we'll kick them out.


No, we'd just be telling them that a non-standard reading of the CC
license's requirements on attribution (namely the reading that You must
attribute the work in the manner specified by the author in the *non-binding
description* of the license means the creator is allowed to specify exactly
how and where the attribution appears,[1] rather than in any reasonable
manner, reasonable to the medium or means You are utilizing, and at
least as prominent as the credits for the other contributing authors as
the license actually says) aren't welcome.


 [1]: To the extent of magenta 24pt Comic Sans, presumably.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] What is the wikipedia http API address now?

2015-06-20 Thread Brad Jorsch (Anomie) 
On Fri, Jun 19, 2015 at 9:57 PM, Yuri y...@rawbw.com wrote:

 Now all previously http URLs redirect to https.
 https://www.mediawiki.org/wiki/API:Main_page also still mentions the old
 http address that now redirects.

 What is the new purely http API address?


I don't think there is one.

-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Global North/South

2015-06-11 Thread Brad Jorsch (Anomie) 
On Thu, Jun 11, 2015 at 3:59 PM, Yaroslav M. Blanter pute...@mccme.ru
wrote:

 Does anybody happen to know why Russia and Moldova are classified as
 Global North whereas Ukraine and Belarus are classified as Global South,
 from the WMF point of view?


For some reason this discussion made me think we need a map. So,
https://commons.wikimedia.org/wiki/File:Global_North_and_Global_South,_according_to_the_Wikimedia_Foundation.svg

Reminds me of https://xkcd.com/753/.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

[Wikimedia-l] User manipulation of change tags, coming soon to a wiki near you

2015-04-15 Thread Brad Jorsch (Anomie) 
Thanks to some hard and awesome work by This, that and the other (a.k.a
TTO), the long-requested feature of allowing users to add and remove change
tags (see T20670 https://phabricator.wikimedia.org/T20670) has been
merged and should be rolled out with 1.26wmf3.[1]

Tags defined by MediaWiki or extensions, such as HHVM, visualeditor, or
mobile edit, cannot be added or removed by this feature. Only tags
specifically activated for the purpose may be added, and only those tags or
tags that are unknown to MediaWiki beyond being on some existing revisions
may be removed.

Management of such tags is already available to users with the
'managechangetags' right (admins by default) via Special:Tags.

Tagging and untagging of individual revisions and log entries will come
with 1.26wmf3. Tags may be applied by users with the 'applychangetags'
right when making an edit,[2] and existing revisions and log entries may be
tagged and untagged by users with the 'changetags' right via an interface
much like that for revision deletion. Both of these rights are granted to
all logged-in users by default.

If the default assignment of these rights is a concern for the community of
any WMF-hosted wiki, please follow the procedure at
https://meta.wikimedia.org/wiki/Requesting_wiki_configuration_changes to
request the necessary configuration change.

For API users, the relevant modules include action=managetags, action=tag,
and action=querylist=tags.[3]



 [1]: See https://www.mediawiki.org/wiki/MediaWiki_1.26/Roadmap for the
schedule
 [2]: By default there is no UI provided on the edit screen, but gadgets
may add a 'wpChangeTags' field with a comma-separated list of tags. API
users may use the new 'tags' parameter to action=edit.
 [3]: See
http://en.wikipedia.beta.wmflabs.org/w/api.php?action=helpmodules=managetags|tag|query+tags
for help, and post questions to mediawiki-api
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api.

-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Wikipedia needs an IDE, not a WYSIWYG editor

2014-10-26 Thread Brad Jorsch (Anomie) 
On Sat, Oct 25, 2014 at 1:20 PM, Amir E. Aharoni 
amir.ahar...@mail.huji.ac.il wrote:

 the wiki syntax must go away,


{{citation needed}}


 and will go away.


{{citation needed}}
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] To Flow or not to Flow

2014-09-10 Thread Brad Jorsch (Anomie) 
this represents my personal opinion and in no way is anything official

On Wed, Sep 10, 2014 at 1:17 PM, Diego Moya dialm...@gmail.com wrote:

 The feature shouldn't be notify on all posts on the subscribed
 thread either. I don't want to be notified every time a new thread
 appears at any one of my watched pages. I have about 3000 pages in my
 watchlist, and receive around 400 updates daily only from talk pages,
 which 50 or so come from unique pages; getting all those as
 notifications would render Echo useless to me. Apparently this volume
 of data was not taken into account when designing the notification
 feature that was rolled out this week, and it is still ignored in the
 redesign proposals that I've seen at the various forums.


I wouldn't want that either. But maybe newbies would; that should probably
be studied, if notifying newbies of new conversations on their watched talk
pages is beneficial or not.

As for people like us, it seems there's already an opt-out in the form of
going to Special:Preferences and turning off flow notifications. That
could be made clearer that that's what it does, though.

I agree that the ability to select specific threads or boards for
notification without doing it for every watchlisted board/thread would be
even better. But that seems like a lower priority, since watchlists still
work.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Let's fix templates

2014-09-02 Thread Brad Jorsch (Anomie) 
note this reply is entirely in my personal capacity and in no way
represents anything official

On Tue, Sep 2, 2014 at 5:40 AM, Martijn Hoekstra martijnhoeks...@gmail.com
wrote:

 * The mobile skin obfuscates talk page access because the templates
 commonly found on talk pages makes them render horribly.
 * The mobile skin special-cases some templates (notably issue templates and
 infoboxes) because they would render horribly.


I may be wrong or out of date on this, but I believe a fair bit of this
comes from two issues:
1. Layout templates are sometimes designed with desktop widths in mind, so
they sometimes don't respond well to smaller screens.
2. The Mobile site strips inline CSS, in an attempt to overcome item #1.

On a technical level, at least #2 is meant to be addressed by
https://www.mediawiki.org/wiki/Requests_for_comment/Allow_styling_in_templates.
Then templates could have associated styles that used proper media queries.


 * Media-viewer has a tough time doing to correct thing with attribution
 and license information because parsing template-madness is hard.


IMO, the structured data for Commons initiative should have come before
MediaViewer tried to incorporate attribution and licensing, rather than
trying to fake it with parsing templates.

In defense of the MV folks, though, it seems that decision was made when MV
had a much smaller scope for the information it would include.


 * VE development has spent a large amount of time around templates, and
 it's still one of its weakest suits. Template substitution is still a
 problem, as well as templates that produce wikitext that in itself doesn't
 map cleanly to HTML tokens.


I don't think there's any way around this one, VE just needs to improve.

As much as some might like the idea of not having templates like {{hidden
top}} and {{hidden bottom}}, the alternative of passing a huge wad of
content into {{hidden}} doesn't seem like it's always workable.

* Scribunto has been developed specifically because writing and maintaining
 templates with more complicated logic is horrible, both from a
 writers/maintainers perspective as well as from a performance perspective


Scribunto isn't a problem with templates, it's the solution ;)

AFAIK, templates were originally designed as just that: plug a few
variables into a structure.

But then you realize that sometimes you want to be able to output bits of
surrounding structure only if the variable is non-empty, or you want to pad
or truncate a value, or you need to use the same variable value in a
different case or percent-encoded, or you realize that it's easier to embed
{{#switch:{{{var}}}|...}} instead of having 100 subtemplates and
transcluding one with {{example/{{{var} or having a tree of {{#if:}},
or you need to deal with formatting times and dates, so you add parser
functions.

And then people use those parser functions to start actually *programming*
in templates (like taking advantage of the padding/truncation function to
write really awesome/awful implementations of strlen, substr, and so on) to
make the user interface of the template easier to use. But doing this
programming in a language designed only for templating doesn't lead to
anything easy to write or read.

Scribunto answers this by letting people program in a language designed for
programming rather than hacking things up in a language designed for
templating. And further, Scribunto specifically doesn't support embedding
the programming code inside the templates, as allowing that would likely
make readability worse rather than better. (Yes, I know some people have
done crazy things like writing parsers in Lua so they can embed code in
template arguments. While it's a cool hack, I think actually using it would
be misguided.)
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Let's fix templates

2014-09-02 Thread Brad Jorsch (Anomie) 
This reply is still my own personal views, and in no way represents
anything official

On Tue, Sep 2, 2014 at 10:20 AM, Martijn Hoekstra martijnhoeks...@gmail.com
 wrote:

 If we have to resort to such magic to make templates do what we want,
 templates are quite simply broken; how can we explain that to a newcomer.
 To help with these templates, all you have to know about are wikitext
 templates, our own implementation of lisp, Javascript, and Lua, and you'll
 be good to go. I suspect the number of people in the world who know how to
 do that is very close to 1. Especially for usecases like this, we need
 something less complicated.


If we (TINW) actually want dialogs (which I'm not convinced of beyond a
few very special cases), trying to do it in templates with embedded code is
the wrong way to do it.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

2014-09-02 Thread Brad Jorsch (Anomie) 
On Mon, Sep 1, 2014 at 11:44 AM, Fæ fae...@gmail.com wrote:

 On 01/09/2014, Marc A. Pelletier m...@uberbox.org wrote:
 ...
  metadata.  It's not an argument against MV, it's an argument for getting
  rid of the horrid way we handle File: pages with ad-hoc workarounds.
  The *correct* solution is to fix the damn image pages, not to remove MV.
 ...

 So, can you link me to a positive proposal to do the elemental
 foundation of this, and point to a realistic (and Foundation
 supported) proposal to the community to standardize licence templates
 on Commons?


More than that, we should actually have the license data (and other stuff
like attribution and descriptions) in a Wikidata-like structure instead of
messing with parsing templates at all. The page for that is
https://commons.wikimedia.org/wiki/Commons:Structured_data. Please do
participate in that process.

That really should have been done first instead of the CommonsMetadata
extension, in my personal opinion.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Let's fix templates

2014-09-02 Thread Brad Jorsch (Anomie) 
On Tue, Sep 2, 2014 at 11:23 AM, Martijn Hoekstra martijnhoeks...@gmail.com
 wrote:

 On Tue, Sep 2, 2014 at 4:46 PM, Brad Jorsch (Anomie) 
 bjor...@wikimedia.org
 wrote:

  This reply is still my own personal views, and in no way represents
  anything official
 
  On Tue, Sep 2, 2014 at 10:20 AM, Martijn Hoekstra 
  martijnhoeks...@gmail.com
   wrote:
 
   If we have to resort to such magic to make templates do what we want,
   templates are quite simply broken; how can we explain that to a
 newcomer.
   To help with these templates, all you have to know about are wikitext
   templates, our own implementation of lisp, Javascript, and Lua, and
  you'll
   be good to go. I suspect the number of people in the world who know
 how
  to
   do that is very close to 1. Especially for usecases like this, we need
   something less complicated.
 
 
  If we (TINW) actually want dialogs (which I'm not convinced of beyond a
  few very special cases), trying to do it in templates with embedded code
 is
  the wrong way to do it.
 

 Well, that's the discussion I'm trying to open: If that's the wrong way, is
 there a right way (yet) ? I'd like to look at this from the perspective of
 what the correct way would be to make that happen.


That would take a more detailed look at what is actually trying to be
accomplished with these dialogs. For example, enwiki's Teahouse[1] has a
dialog for newbies to more easily post questions, but it's implemented as a
gadget that generates the form specific for that page. To what extent to we
have actual use cases for many differently-designed dialogs? How does the
lisp even enter into the current design?

But in general, the answer almost certainly isn't to be doing things with a
mess of complex templates with their own custom lisp dialect.

 [1]: https://en.wikipedia.org/wiki/Wikipedia:Teahouse/Questions
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Let's fix templates

2014-09-02 Thread Brad Jorsch (Anomie) 
This reply still isn't anything official, but does represent my own views
as a developer (both volunteer and staff)

On Tue, Sep 2, 2014 at 12:30 PM, pi zero wn.pi.z...@gmail.com wrote:

 Yes, there is in fact a lisp interpreter written in Lua.  It makes up for
 some other weaknesses of templates.  I expect most users not to have to
 touch that most of the time, and when they do they'll usually be able to
 just copy others' markup and make slight, obvious modifications.  It's so
 vastly handy that I've used it (you've reminded me) in some of the dialog
 templates, just because it's so much easier to do things with it.  I
 created it because it was obvious I'd need a powerful succinct way, without
 the cumbersome notational overhead of templates or Lua (or JavaScript,
 perish the thought), to specify transformations of the raw content of a
 wiki page;


Is there an actual problem with Scribunto that drove you to writing this
lisp interpreter, or is it just that you don't like the fact that Scribunto
forces you to separate Lua code from templates?

I consider this separation a good thing, as even if it is more work for the
developer it makes things much easier for everyone else to understand later.


 I do agree that templates are rather broken, although frankly the
 Foundation could --- with some deep insight --- have done things that
 would have improved them.  The current plethora of magic words is a mess,
 partly because the template call-syntax is heavy and pure
 template/magic-word usage keeps sending things back to typeless text;


The Foundation *did* do something. It's called Scribunto.


-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Let's fix templates

2014-09-02 Thread Brad Jorsch (Anomie) 
On Tue, Sep 2, 2014 at 1:35 PM, pi zero wn.pi.z...@gmail.com wrote:

 (1) It's very easy to use.

[...]

 (2) it naturally promotes incremental learning.


When it comes to your extremely complicated templates with embedded lisp,
you're losing *both* of these. It's no longer very easy to use (although it
seems you may consider cargo-cult programming to be easy to use), and
your hypothetical incremental learner is more likely to be overwhelmed
and give up rather than incrementally figure out where in some complicated
mess filled with braces and parens the actual page content is located. We
already have user studies (which I don't have the links for offhand) that
show that people see the relatively simple infobox templates in articles
and give up.

The advantage to having the complexity of Lua in modules is that the
complexity specifically is hidden from new users. Once someone gets to the
point where they're ready to make that step, they're probably motivated
enough that looking through the manual (or even better would be if someone
would write some good tutorials) isn't likely to be the barrier it would be
to a complete newbie.


 And, Lua is a high-overhead language.  You can't just write super-simple
 expressions and have them work, and build other stuff up.


Sure you can; a little boilerplate is needed, but both that and the
language itself are simple enough that someone could start from some basic
examples and experiment easily enough. And we have a console on module edit
pages that allows for direct experimentation with simple expressions.

Lisp, on the other hand, has extremely simple, unambiguous, low-overhead
 syntax.  (Even simple template calls have more syntactic overhead than lisp
 function calls.)


On the other hand, Lua's syntax and operation is similar to that of C, PHP,
JavaScript, and so on, which are likely to be familiar to users with some
sort of programming experience. While parser function syntax somewhat
resembles Lisp, I'm not sure that similarity will help with understanding
more than the surface.

I'm not also sure that Lisp's extremely simple syntax is necessarily an
advantage. While extra syntactic structure requires extra learning, it also
means that the written code is more structured which may be easier for
humans to make sense of. Again, look at the trouble people report in
understanding complicated templates.


 Of course, my primary goal was interactive pages, for building wizards,
 and it was clear to me that Lua wasn't going to help me with those anyway.


I don't see how Lisp is helping that either. If you want interactive pages,
JavaScript is the way to go. Or did you write your Lisp parser in
JavaScript too?


 Scribunto isn't an improvement to templates; it's trying to half-replace
 them with something else.  My understanding of improve templates would
 exclude a half-replacement (or full replacement), even if the
 half/full-replacement were to improve *on* templates.


Isn't your Lisp stuff also half-replacing templates with something else? Or
are you overlooking that because Lisp syntax resembles that of templates?


-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Link-parameter image usage: attribution issue

2014-08-27 Thread Brad Jorsch (Anomie) 
On Wed, Aug 27, 2014 at 5:52 AM, Bohdan Melnychuk bas...@yandex.ru wrote:

 But we can use it like [[File:Example.jpeg|link=]] or
 [[File:Example.jpeg|link=Some page]] which would suppress or substitute the
 link with another link. We can also use images via css or scripts for some
 backgrounds and so on which is not about the link-parameter but has the
 same issue in core.

 The question is how attribution requirement is being fulfilled in the
 latter case?

 What is general community consensus and WMF position upon it?


Note this reply is entirely in my personal volunteer capacity, and in no
way represents anything official

From what I've seen on enwiki, this mainly applies to images used as
navigation icons or decoration in templates.

Whenever I see an image requiring attribution or notice of license (which
basically means anything that's not public domain or CC0) that is using
the link= parameter, I'll fix it with an appropriate edit summary.
Sometimes it's possible to find or create a replacement image that's public
domain or CC0 which can be used instead of the problematic image, or
sometimes I just remove the link=. In some cases the link necessary for
attribution is supplied in some other way, e.g. by superimposing an info
icon on the image with the necessary link.

A few years back I tried to make a user script that would highlight
problematic images, but the plethora of licensing categories (particularly
on Commons) made it too difficult to keep up with. Maybe the new Structured
Data planning can make this possible.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Specifying office action in edit summary?

2014-08-23 Thread Brad Jorsch (Anomie) 
On Fri, Aug 22, 2014 at 10:53 PM, svetlana svetl...@fastmail.com.au wrote:

 An undo with appropriate edit summary would also avoid a need in
 escalating the issue - local sysops would consciously hold off their edit.
 If they went against an office action, introducing superprotect /then/
 could make sense


Note that's exactly what was tried in the dewiki situation. The first WMF
revert[1] refers to a warning on the talk page[2] that (according to Google
Translate, and Erik's later statements) seems to basically say Please
don't do this again. Otherwise we might have to remove the editability of
this page.

But the local sysop didn't hold off; according to Google Translate he
replied With threats you will achieve nothing.


 [1]:
https://de.wikipedia.org/w/index.php?title=MediaWiki:Common.jsdiff=132938232oldid=132931760
 [2]:
https://de.wikipedia.org/w/index.php?title=MediaWiki_Diskussion:Common.jsdiff=132938244oldid=132935469



-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

2014-08-12 Thread Brad Jorsch (Anomie) 
On Mon, Aug 11, 2014 at 6:54 PM, John Mark Vandenberg jay...@gmail.com
wrote:

 On Tue, Aug 12, 2014 at 3:49 AM, Brad Jorsch (Anomie)
 bjor...@wikimedia.org wrote:
  On Mon, Aug 11, 2014 at 2:01 PM, John Mark Vandenberg jay...@gmail.com
  wrote:
 
  Before this, there was no expectation that a page could be protected
  such that sysops could not alter the content of the superprotected
  page.
 
 
  This is false.

 Care to explain?


https://www.mediawiki.org/w/index.php?title=Manual:$wgRestrictionLevelsdiff=519048oldid=451673
shows that protection levels that prevent sysops from editing were
considered as far back as 3 April 2012, for example.


  Most of what MZMcBride posted there has nothing to do with actually
  breaking superprotection. Editing a page that isn't superprotected isn't
 a
  break in the protection feature itself, for example.

 Of course it is.  It isnt a 'feature' until it actually works at the
 released product level.


You appear to be confusing superprotection with something else, likely the
much larger concept of preventing JS hacks to disable MediaViewer.


-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

2014-08-11 Thread Brad Jorsch (Anomie) 
On Mon, Aug 11, 2014 at 2:01 PM, John Mark Vandenberg jay...@gmail.com
wrote:

 Before this, there was no expectation that a page could be protected
 such that sysops could not alter the content of the superprotected
 page.


This is false.


 Now, the devs/ops have attempted to introduce that capability, and the
 new functionality is very likely riddled with holes, some of which
 MZMcBride has suggested in the thread 'Options for the German
 Wikipedia'.


Most of what MZMcBride posted there has nothing to do with actually
breaking superprotection. Editing a page that isn't superprotected isn't a
break in the protection feature itself, for example. Nor is hacking
people's accounts.


-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Options for the German Wikipedia

2014-08-10 Thread Brad Jorsch (Anomie) 
*Note these are entirely my own personal opinions as a community member and
in no way at all represent anything official.*

On Mon, Aug 11, 2014 at 3:12 AM, MZMcBride z...@mzmcbride.com wrote:


 I'm interested to read others' views about options and ways forward here.


People could realize that demagoguery and warring is going to make
everything much harder that it needs to be, and decide to block the people
trying to escalate the issue so that more rational people can work out a
rational solution.

On the enwiki VPT thread about this, User:Fluffernutter suggested that we
could eliminate 90% of the drama over software deployments by topic-banning
a small number of people from the discussions. That'd probably be a much
more productive topic than trying to brainstorm ways to make the situation
worse.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

[Wikimedia-l] Internet archive and automatic retroactive robots.txt (was Re: Internet archive and strategy survey (was Re: 24 TB for User:Dispenser on Tool Labs please))

2014-07-07 Thread Brad Jorsch (Anomie) 
On Mon, Jul 7, 2014 at 5:21 AM, James Salsman jsals...@gmail.com wrote:

 Kevin Gorman wrote:

  Regarding the IA: they have a significant interest in working with the
  Wikimedia projects, a lot more experience than the Wikimedia projects
 have
  caching absolutely tremendous quantities of data, a willinness to handle
 a
  degree of legal risk that would be inappropriate for the Wikimedia
 projects
  to take on

 Because they censor things retroactively when requested by new domain
 owners' robots.txt,


Note I am replying in my personal capacity as an enwiki editor, and
nothing here at all represents the views of WMF or anyone else

This point shouldn't get lost in the various other issues of more dubious
veracity and/or applicability raised in the original message.

I've seen cases where domain ownership changes or a major corporate
restructuring results in a domain being completely reorganized or even
redirected wholesale to some other domain. And the robots.txt for the new
version of the site denies everything, likely because the new owners don't
want the redirects or other old content showing up in Google searches. But
this has the unfortunate side effect that IA removes all the old content
from public access.

I really wish that IA would reconsider their policy of *automatically*
retroactively honoring robots.txt.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Internet archive and automatic retroactive robots.txt (was Re: Internet archive and strategy survey (was Re: 24 TB for User:Dispenser on Tool Labs please))

2014-07-07 Thread Brad Jorsch (Anomie) 
On Mon, Jul 7, 2014 at 1:49 PM, Federico Leva (Nemo) nemow...@gmail.com
wrote:

 Brad Jorsch (Anomie), 07/07/2014 17:37:
  And the robots.txt for the new
  version of the site denies everything, likely because the new owners
 don't
  want the redirects or other old content showing up in Google searches.
 But
  this has the unfortunate side effect that IA removes all the old content
  from public access.

 This is not correct. If you can reproduce it, please file a bug, but
 it's not how it's supposed or said to work.
 I've pasted some links where you can find additional information like
 this at

 https://archive.org/post/1019415/retroactive-robotstxt-removal-of-past-crawls-aka-oakland-archive-policy
 (also reposting an elaborated version of my message of this morning).


Still my own personal views, in no way representing any position of WMF or
anyone else

I'm confused. You say this is not correct, but then you post a link to a
post of your own that does not refute it and that has many links to people
confirming it.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Applying the Right to Be Forgotten to Wikipedia (Was Re: Right to be forgotten)

2014-06-04 Thread Brad Jorsch (Anomie) 
(note any comments here are entirely my own personal opinion)

On Wed, Jun 4, 2014 at 11:23 AM, Mike Godwin mnemo...@gmail.com wrote:

 The ECJ said the
 right to be forgotten applies when the data aggregated appear to be
 inadequate, irrelevant or no longer relevant, or excessive in relation
 to the purpose for which they were processed and in light of the time
 that has elapsed.


That begs the question as to what is the purpose for which they were
processed. Even in this case with Google and the Spanish guy and some old
repossession: What's the purpose of Google's processing the data? To
satisfy search requests. Is the old repossession relevant to the search for
the guy's name? It depends on why someone is doing the searching, maybe it
is and maybe it isn't.

And is Google having to remove all record of the repossession from their
index, or just in connection with the guy's name? What if someone searches
for Mario Costeja González repossession, is the old repossession relevant
then? What about Mario Costeja González 1998, since the repossession
occurred in 1998? How many years until he can whine at Google that the top
results for Mario Costeja González are now all about this stupid lawsuit?

What if it had been some other Mario Costeja González (maybe one living
outside Europe) who had the repossession? Would the ECJ ruling still
require Google to remove the information based on the complaint by *this*
Mario Costeja González?
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] COI editing by WMF staff

2014-04-17 Thread Brad Jorsch (Anomie) 
On Thu, Apr 17, 2014 at 10:37 AM, Russavia russavia.wikipe...@gmail.comwrote:

 Employees and contractors of the Wikimedia Foundation shall not edit
 articles relating to the Wikimedia Foundation, broadly construed, but at
 rather directed to raise potential edits on the talk pages of affected
 articles. This directive does not apply to the reverting vandalism,
 removing copyright violations or potentially libellous materials.


Before people go too far along these lines, consider whether whatever
policy you propose would result in stupidity like my having to code
AnomieBOT with a blacklist of pages it's not allowed to do its bot work on.

There's not a sharp divide between community and staff, some of us are
both and would like to remain both.


From my purely personal perspective, I've often felt that concerns over COI
and paid editing in and of themselves are often grossly overblown. COI is a
problem when it leads to POV violations and the like, and it can be
difficult for people to respect POV and other policies when they have a
COI. But it's not *impossible* to make good edits despite a COI and raising
a fuss over COI absent any concern with the actual edits made seems like
trying to cause trouble rather than doing something productive.

For example, others are blasting Victor (whom I may have met, but if I have
it slipped my mind in the middle of all the other people I've met) for
https://en.wikipedia.org/w/index.php?title=Zack_Exleydiff=506286326oldid=504412402.
That's utterly silly: Victor took a freely-licensed photograph of someone
with an existing Wikipedia article, uploaded it to Commons, and changed the
article to use it. This is **exactly what we want people to do**. Why does
that change just because Victor works for WMF?
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] United Nation of Wikimedia

2014-04-07 Thread Brad Jorsch (Anomie) 
(Note this reply is entirely in my personal capacity, and does not in any
way represent anything at all official)

On Mon, Apr 7, 2014 at 9:39 AM, Ting Chen wing.phil...@gmx.de wrote:

 Files and contents that let's say are legal in the EU but not in the US
 should of the be able to be stored on a server located in the EU and
 distributed and operated from there. Files and contents that are legal in
 PRC and Taiwan and may violate copy right law in the US should be able to
 be stored in a server say in Taiwan or Hongkong and be distributed from
 there into the world. This approach is meanwhile technical viable and is
 used by almost all major international internet providers today.


As I recall, the problem with this suggestion is that it wouldn't actually
work that way. For material that's illegal in the US but legal in the EU,
the US branch would be sued despite the material being hosted in the EU.
And similarly, for something legal in the US but not legal in the EU, the
EU branch would be sued. The end result would be that everyone everywhere
would have to comply with the *most* restrictive laws, not the least. And
if it did work, the individual contributors would still probably have to
watch out for liability.

Or is the idea here to have Wikipedia be run by a large number of
different legal entities? I don't have any idea of how that might work to
do more than guess that the necessary legal structure (if it's even
possible) would result in something hugely complex.
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Paid editing v. paid advocacy (editing)

2014-01-10 Thread Brad Jorsch (Anomie) 
(Note these are my own personal views and in no way reflect any views of
the WMF or anyone else)

On Fri, Jan 10, 2014 at 7:34 AM, Christophe Henner 
christophe.hen...@gmail.com wrote:

 Now, the question about paid advocacy. Again, one of our core
 principle is NPOV. We don't want people to push their POV. Whether
 they're paid or not, is not relevant.

 So, to me, the paid foobar question is not the one in debate here.
 The one we're actually debating about is do we want for profit
 organization to edit Wikipedia.


I'd take this one step further: *paid* advocacy isn't necessarily the thing
we should be that much concerned about, as unpaid advocacy is just as bad
for the integrity of our content. There's no difference between someone who
inserts POV content because they're being paid to do so and someone who
inserts POV content because of their religious beliefs or personal
relationships or the like.

On the other hand, a paid advocate may perhaps be more concerning from a
community standpoint because it's likely that the paid advocate is going to
have more time and resources to devote to inserting POV content (and to
doing so in ways less likely to be caught) than most unpaid advocates.

Even more generally, even paid editing without advocacy may give a stigma
to the project even if the content really is fully NPOV. And, as mentioned
elsewhere, even paid editing without advocacy might discourage non-paid
contributions for various reasons. These reasons might be behind some of
the opposition to all paid editing.
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Increase in page views for the last 3 months

2013-12-02 Thread Brad Jorsch (Anomie) 
On Sat, Nov 30, 2013 at 6:20 PM, Christian Aistleitner
christ...@quelltextlich.at wrote:
 . No other requests to Special:MWOAuth/ , Special:OAuth/ . Should we
 already see traffic to those endpoints?

Not a whole lot, yet, and it may never really get to be *that* many.
On the other hand, maybe it will. It certainly shouldn't ever get
anywhere near the level of Special:CentralAutoLogin.

The /initiate you saw should have been followed by a call to
/authorize and then likely a call to /token, but of course those could
have missed the sampling. We've also got /verified, /identify, and
/grants in there.

Of all these, /authorize, /verified, and /grants are the only ones
that could remotely be considered a real pageview. You can see
/authorize by going to
https://tools.wmflabs.org/oauth-hello-world/enduser.php and clicking
the Make an edit button, /verified at
https://www.mediawiki.org/w/index.php?title=Special:OAuth/verifiedoauth_verifier=1234oauth_token=5678,
and /grants at https://www.mediawiki.org/wiki/Special:OAuth/grants.

-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Increase in page views for the last 3 months

2013-11-27 Thread Brad Jorsch (Anomie) 
On Wed, Nov 27, 2013 at 1:00 PM, Erik Zachte ezac...@wikimedia.org wrote:

 Special:CentralAutoLogin/createSession
 Special:CentralAutoLogin/start

You should also remove anything else beginning with Special:CentralAutoLogin/.

Maybe Special:MWOAuth/ and Special:OAuth/ too.

-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] New access to non-public information policy, re-ID requirements and data retention

2013-10-24 Thread Brad Jorsch (Anomie) 
On Thu, Oct 24, 2013 at 10:01 AM, Marc A. Pelletier m...@uberbox.org wrote:

 On 10/24/2013 09:37 AM, Risker wrote:
  Wow, Fae. Justwow.

 I think Fae was being highly ironic there.

If so, I think we just ran into Poe's law.[1]


 [1]: https://en.wikipedia.org/wiki/Poe%27s_law (of course)

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

2013-07-31 Thread Brad Jorsch (Anomie) 
On Wed, Jul 31, 2013 at 12:47 PM, Gerard Meijssen
gerard.meijs...@gmail.com wrote:
 Quality like beauty is in the eye of the beholder. One thing that I learned
 today is that the Visual Editor will have functionality that only the more
 accomplished editors will enter directly or they will use templates. With
 VE these templates are redundant.

Some, perhaps. But would you rather use a template or remember the
multiple buttons in VE and the right CSS style/class string (if that's
even possible in VE?) to do the same thing manually?

 From my perspective, the future will be with the VE and not with the
 horrible tortuous templates that require study to use. One of the reasons
 why I prefer Wikidata over Wikipedia is that Wikidata does not have
 templates and is certainly as relevant. When I notice the improvements in
 the Wikidata experience, I can only applaud the improvements made.

Wikidata also deals with discrete bits of usually-unformatted data,
rather than heavily-formatted encyclopedia articles. I'm not sure
you're comparing apples to apples there.

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)

2013-07-30 Thread Brad Jorsch (Anomie) 
On Mon, Jul 29, 2013 at 11:18 PM, Marc A. Pelletier m...@uberbox.org wrote:
 On 07/29/2013 11:10 PM, Risker wrote:
 which are used daily on hundreds of pages,
 and they serve a very important function.

 Yeah, but they are duct tape over weaknesses/flaws in wikimarkup, not a
 valuable feature.

Templates such as {{hat}} and {{hab}} don't exist so much because of
weaknesses in wikimarkup as because passing the content as a parameter
would rapidly exceed the Template argument size limit, and possibly
other parser limits. Any solution to this problem would have to take
that into account, unless the vaguely mentioned new parser doesn't
have such limits.

There's also the fact that a {{hat}}/{{hab}} pair can be clearer than
{{hidden|text= with }} 2000 lines further down in the text. Although I
suppose the comeback to that is that people using VE don't see such
things.

 This revolves back to the difficulty in trying to
 pretend a talk page in wikimarkup is a discussion medium and doing
 forum kind of things with it.

Not entirely. Templates such as {{hidden begin}} and {{hidden end}}
are used to hide long lists in a way that Flow is unlikely to
satisfactorily support. While HTML markup for multi-column lists is
trivial enough to enter directly in a page, people still like to use
templates such as {{div col}} / {{div col end}}. And it's not long ago
that {{col begin}} / {{col end}} were required to give a (hacky)
cross-browser multi-column layout. Nor does this address the
succession box templates mentioned above.

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] About the concentration of resources in SF (it was: Communication plans for community engagement

2013-07-24 Thread Brad Jorsch (Anomie) 
(note this reply represents only my personal thoughts, and is in no
way at all anything official)

On Wed, Jul 24, 2013 at 11:44 AM, Richard Symonds
richard.symo...@wikimedia.org.uk wrote:

 *We are a global movement with global projects and global goals.*


 Indeed we are! But allow me to play devil's advocate here:

- How would you run HR meetings? Is it feasible to use videoconferencing?

I don't know if HR meetings are specially problematic, but WMF has
plenty of meetings using videoconferencing. Although it is a bit
annoying sometimes, it mostly works.

- What are the additional costs involved with this approach? Are there
local taxes that would need administrating and paying? Would you need a HR
team who can handle

Don't forget the costs for office space, supplies, equipment,
utilities, support staff, and so on too. And I can't even guess
whether it might increase or decrease overall travel costs.

- Does it increase the WMF's liability if they have a permanent staff
presence in another country (eg., EU data protection laws, or UK libel
laws)?

Wouldn't surprise me.

- What are the insurance implications of staff remote-working from (say)
Ghana or India?
- If employees from one country are entitled to certain privileges by
law - eg paid paternity leave, or minimum break times - does that
automatically get extended to others around the world? If not, will it
create resentment between people who do the same job in different 
 countries?

I imagine just having to be aware of all the different laws and
requirements in all those different countries and the extra work to
comply with them all would be an issue. Probably a bigger one than
just deciding whether Fooians should also get a benefit that must be
provided to Barrians.

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe