[Wikitech-l] Fwd: Message from the Code of Conduct Committee
Hi,
I received the message below after posting "Wikimedia Foundation Inc. is corrupt and bad. The Web team is a particularly egregious demonstration." in a comment on mediawiki.org.
I stand by my original statement and this attempt to silence criticism makes the organization look even more corrupt and bad.
MZMcBride
-- Original Message --
From: MediaWiki <w...@wikimedia.org>
To: MZMcBride <w...@mzmcbride.com>
Date: 04/19/2022 2:58 AM
Subject: Message from the Code of Conduct Committee
Dear MZMcBride,
This is an official message from the technical Code of Conduct Committee. We received a report regarding one of your recent comments at MediaWiki.org <https://www.mediawiki.org/w/index.php?title=Topic:Wt8i87odakxnhpyb_showPostId=wt8z7rf5jmodj9ds=1#flow-post-wt8z7rf5jmodj9ds>.
The Committee concluded that the comment is a blatant violation of the Code of Conduct <https://mediawiki.org/wiki/Code_of_Conduct>. While we support a free and open discourse, we cannot accept personal attacks, whether they are aimed at individuals or groups of people. Civility is necessary to maintain a healthy working environment.
For that reason, the Committee decided to **ban you** from Wikimedia technical spaces for **1 month**. The ban is effective immediately and it will expire at May 19, 2022, 06:57 UTC. Note the ban is in force in all Wikimedia technical spaces, including (but not limited to) MediaWiki.org, Phabricator, technical mailing lists such as wikitech-l or Wikimedia Gerrit. Please re-familiarize yourself with the Code of Conduct during the duration of the ban.
Sincerely,
--
Martin Urbanec
Code of Conduct Committee
--
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.
To manage email preferences for user TechConductCommittee please visit <https://www.mediawiki.org/wiki/Special:Mute/TechConductCommittee>.
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
Re: [Wikitech-l] non-obvious uses of in your language
MGChecker wrote: >> Links using the pipe-form should not have the link target inflected. >>This is important, as this is the natural escape route if inflection >>gives wrong target for whatever reason. > >This is what I think is particularly odd about linktrails: Why do links >like [[Examples|Example]]s have a linktrail? I wouldn't expect it and I >don't think anyone would, on the contrary I still remember discovering >this really weird behavior years ago. I'm not sure I understand. I would expect a link trail with "[[Examples|Example]]s" since there is a link trail with "[[Example]]s". I'm not sure why anyone would associate link trail behavior with the presence or lack of a pipe character. The defining characteristic of link trails is text being adjacent to "]]", as far as I know. Is the particular case you mention common? It seems like it would be much more common for a user to simply write "[[Examples]]" currently to achieve the same output. MZMcBride ___ 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
Brion Vibber wrote: >*nods* I think the root problem is that the phabricator task system does >double duty as both an *issue reporting system* for users and a *task >tracker* for devs. > >An issue reporting system should capture all actual problems and all >actual suggestions, and is meant to provide visibility for the devs into >the world of users. A task tracker should capture only things that are, >or are planned to be, worked on and is a work planning tool for the devs. >Secondarily if open, the task tracker provides visibility for the users >into the world of devs. > >This mixup of concerns is endemic in open source software development, >unfortunately, and leads to exactly the sorts of conflicts you mention. I agree with there being multiple use-cases for Phabricator. I don't agree that it's necessarily a problem. User feedback and bug reports often directly lead to and can directly influence developer work. Mixing the two groups is also a decent means of developing community and rapport between developers and users in a shared space. I also don't agree that a task tracker needs to only capture items to be worked on. Filters, tags, and other user interface tweaks can address the competing use-cases well enough, in my opinion, and as you note. The number of tasks in the issue tracker is somewhat immaterial, just as the English Wikipedia having over five million articles is immaterial, when you're just reading one. Another way to frame your root problem would be volunteer use versus corporate use. In my experience, it's very common for valid bugs and issues to be closed mercilessly in corporate issue trackers, as business priorities shift and staff turns over. We may need to make it clearer and more explicit that the Phabricator installation at phabricator.wikimedia.org is for all members of the Wikimedia movement. MZMcBride ___ 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
Amir Ladsgroup wrote: >[...] Did they have access to all of the user's history and reports made? Amir Ladsgroup also wrote: > [...] 2- There are cases that in the gray area but by looking at the >history of the user, the pattern is obvious. Can a user, such as myself, view his or her own "history" in this sense? It sounds like you all are compiling private dossiers about users. Is that correct? Do these records include only complaints or other parts of the user's history as well? MZMcBride ___ 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
David Barratt wrote: >> the unclear CoCC action > >Why do you feel that you need clarity on the CoCC's actions? or perhaps a >better way to ask would be: What do you gain from getting more clarity? I get the feeling you've never interacted with this group of people or similar groups within Wikimedia Foundation Inc. In my experience, you occasionally receive a vaguely threatening e-mail and when asking for details, you're told that those details are private. That is, I've been told that alleged incidents involving me cannot be discussed with me due to privacy concerns. Perhaps someone can explain how this makes sense. I agree with Bináris that being compared to a Nazi or the Eye of Sauron is often a lot more offensive than a simple "What the fuck." This "conduct committee" is a political tool and it can easily be misused or abused as such via, for example, selective reporting and selective enforcement. MZMcBride ___ 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
Gergo Tisza wrote: >- First of all, I'd like to thank the Code of Conduct committee for doing >their job. It's a hard job where they need to make difficult judgement >calls, and are criticized harshly when they make a bad judgement and >ignored at best when they make a good one (although more likely they still >get criticized harshly). It's also a necessary job, so we should be glad >that someone is willing to do it (even if imperfectly, as human beings are >bound to). It's not unlike the role of Wikipedia administrators in that >regard. Most of Wikimedia's and most of MediaWiki's existence has progressed without a group of sticklers patrolling for language (or apparently tone) that they happen to disagree with, at that time, in that context. Here's you (Gergo) using the abbreviation "WTF" in May 2018: <https://phabricator.wikimedia.org/T192896#4170798>. It's completely possible for someone to fake outrage at your Phabricator Maniphest comment, just as it's completely possible, and perhaps probable, for people to fake outrage at an expanded "What the fuck." comment. Isarra wrote: > I would put forth that the CoC, or more accurately, this heavy-handed >implementation of it, has been an abject failure that requires us all to >step back and try to look at all of this more objectively. To move >forward, we must address the issues with the CoC and its enforcement, but >to do so as a community, to come to any meaningful and informed >consensuses as such, will not be possible so long as nobody outside the >committee has any access to the stats, as no logging of actions taken is >available publicly, as the cases themselves remain largely invisible even >when they do not pertain to sensitive situations or materials. Yes to all of this. The lack of transparency regarding how many "incidents" this committee handles and what level of severity they are means that any discussion about the necessity of having this committee is incredibly difficult. Someone saying "What the fuck." on a Phabricator task is not the same as someone threatening to kill another user. Any kind of flat "this is how many complaints we received" statistic will be incredibly misleading. (Consider a "number of crimes" statistic for any city that conflates vandalism with rape.) Just how necessary is this group that has only been around for about 15 months? Is its presence doing more harm than good? Framing this group as a necessity is misguided without substantiating the claim. Having watched similar arguments used to justify expanded security theater at airports and public venues, I actually think a sudden embrace of increased, questionable bureaucracy is pernicious. Gergo Tisza wrote: >- Also, do consider that MZMcBride had the option to reach out to the CoC >committee and ask their help in understanding exactly which of his >comments were problematic and in what way, and how they could be reframed >in a constructive way. He had the same option the previous time when the >committee merely warned him for a similar infraction. That he chose not >to is hardly the committee's fault. Most of the reason I didn't see the e-mail about my account being disabled is that someone decided to use the wiki software at mediawiki.org to send an e-mail instead of sending an e-mail directly. I don't understand this practice or why it's appropriate or desirable. MZMcBride ___ 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
Adam Wight wrote: >Silencing anyone is rarely appropriate, but your behavior in this earlier >thread was gross enough that I decided against participating. In fact, I >had my own concerns about the new WMF site but you had already created a >toxic dynamic, effectively losing me (and undoubtedly others) as an ally >in that discussion. > >That seems like exactly the sort of thing the Code of Conduct exists to >prevent, so I agree with their actions in silencing you in order to make >space for other voices. The wikimedia-l mailing list is very specifically not within the purview of the mediawiki.org "Code of Conduct" or its associated committee. Your suggestion that I'm being punished for actions outside its remit is pretty dark and disturbing. This, of course, sets aside the obvious fact that disabling a Phabricator account has no effect on mailing list access. >Thank you for your energy and insights, and I hope we can work together to >root out the bad decisions and corruption, without this nonsense of having >to bail you out of Phabricator jail every few months. A simple solution would be not jailing people. :-) There's no shortage of bad decisions and corruption around Wikimedia Foundation Inc., so I imagine we'll be on the same side once more in short order. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] (no subject)
Brion Vibber wrote: >I would advise you generally to treat wikitech-l like a professional >workspace, which it is for those of us who are employees of WMF or WMDE. I think there's a big schism that you're pointing to here: why do you think it's appropriate for you or anyone else to impose your particular U.S. workplace standards on a global community of volunteers? For many users, wikitech-l, Phabricator, and other venues are specifically not workplaces, they're places for technical work on hobby projects. >If your corporate HR department would frown at you making a statement >about people's character or motivations with derogatory language, think >twice about it. Treat people with respect. Sure, treat people with respect. As a colleague of Greg Varnum, have you privately messaged him to let him know that closing valid tasks is inappropriate? Have you told him that gaslighting users into thinking that an obvious bug is an intentional design choice is unacceptable behavior? Have you discussed with Greg V. that un-assigning yourself from a task and attempting to orphan it is bad practice? Or are you simply focused on trying to shame and silence volunteers who are critical of Wikimedia Foundation Inc. employees? Regarding the word fuck generally, I've been here long enough to remember commits such as <https://github.com/wikimedia/mediawiki/commit/32936ec8>. There are also many commits and tasks that use similar language. As the English Wiktionary notes, "what the fuck" is a common interjection: <https://en.wiktionary.org/wiki/what_the_fuck#Interjection>. I do not think it's a phrase that should be commonly used on Phabricator, but at times it can be appropriate, _as your code commit from 2008 notes_, to underscore the severity of a particular issue. What Greg did was really bad and is compounded, in my opinion, by his continued silence and the lack of resolution to the issue of German text appearing on an English landing page. Saying what Greg V. did was confusing and bad, even forcefully, is not the real issue here. For what it's worth, here's Daniel using the same language in 2016: <https://phabricator.wikimedia.org/T110728#2227182>. And MatmaRex using the same language in the same year: <https://phabricator.wikimedia.org/T130478>. A quick search of Phabricator for "what the fuck", "fuck", or "wtf" shows that none of them are rare. MZMcBride ___ 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
Ryan Kaldari wrote: >It's possible to highlight abuses while still being respectful and >collegial. No one is seriously arguing that criticism should be banned (or >the word "fuck"). Are you sure about that? I think the Code of Conduct Committee _is_ arguing that it's the use of the word "fuck" that was problematic here. If I had written "Why did you do that?!" instead of "What the fuck.", do you think I would have had my Phabricator account disabled for a week? As Alex asks on this mailing list: is using the abbreviated "wtf" form now considered a formal offense in tasks and commits? I genuinely do not know. MZMcBride ___ 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
Ori Livneh wrote: >MZMcBride has a very good ear for grievances, and he knows how to use his >considerable social clout to draw attention to them, and then use words >as a kind of lightning-rod for stoking outrage and focusing it on >particular targets. I'm going to paraphrase what you're writing here: I spend some of my accumulated social capital calling out or highlighting abuses by and corruption within Wikimedia Foundation Inc. And you think that's _bad_? MZMcBride ___ 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
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: <https://phabricator.wikimedia.org/T200742>. 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. <https://lists.wikimedia.org/pipermail/wikimedia-l/2018-August/090841.html> ), 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 <https://wikimediafoundation.org/>. Amazing. MZMcBride ___ 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
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. Ah, okay. Thank you for the quick reply and remedy! I appreciate it. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] My Phabricator account has been disabled
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
Re: [Wikitech-l] FW: Warning on behalf of Code of conduct committee
Tim Starling wrote:
>On 25/06/18 07:46, MZMcBride wrote:
>> Wikimedia Foundation Inc. employees have blocked the ability of new
>>users to report bugs or file feature requests or even read the issue
>>tracker. But yes, please focus on me calling Andre a troll for resetting
>>the priority of <https://phabricator.wikimedia.org/T197550>. My single
>>comment ("andre__: Such a troll.") is clearly what contributes to an
>>unwelcoming environment for contributors, not blocking them from reading
>>the site and demanding that they be vetted first. Great work, all.
>
>MZMcBride, a few years ago, a number of people were thoroughly fed up
>with your behaviour in technical communication spaces, and there was
>serious discussion of banning you. I spoke in your favour at that time
>because, when I talked to you 1:1 about the issues, you seemed
>contrite and willing to improve yourself.
We wouldn't accept this type of unsubstantiated and unsourced bad-mouthing
on the English Wikipedia, so I'm confused why you think we would accept it
here. If "a number of people" were fed up, please provide some names and
links. I try to improve myself daily.
>I know you're passionate, and we need passionate people, but you have
>to express your views in a civil manner. There's no easy solution to
>T197550. We need to welcome newcomers but we also need to prevent
>vandalism. Phabricator doesn't offer as many tools for this as
>MediaWiki. We're all aware that it's not ideal, and while you're
>ranting about civility, smart people are trying to find better
>compromises.
Oh, come on, Tim. "Smart people" are sending threatening e-mails about an
IRC message to users behind a shared account. That's your better
compromise? I don't really care about the priority of any given task in
Phabricator Maniphest and I rarely touch the field. I do care when we
block all new users from the main entry-point to file issues or feature
requests with an awful error message in the name of "temporary" security.
For what it's worth, instead of telling new users to try an "incognito
browser window", which is a pretty obscure tactic, they could be asked to
e-mail their bug report, task comment, or feature request to whichever
Wikimedia Foundation Inc. staffer created this problem for them and that
staffer could then make the necessary changes to Phabricator Maniphest.
There are over 300 full-time employees working for Wikimedia Foundation
Inc. Surely one of them is available to handle the fallout of this hasty
decision to lock down Phabricator.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] FW: Warning on behalf of Code of conduct committee
>Hello,
>Please refrain from name calling, the CoC has received some reports about
>users being offended by you calling them trolls. While those comments
>might not have been malicious they are not constructive and do not
>contribute to a welcoming environment for contributors.
>
>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.
Wikimedia Foundation Inc. employees have blocked the ability of new users
to report bugs or file feature requests or even read the issue tracker.
But yes, please focus on me calling Andre a troll for resetting the
priority of <https://phabricator.wikimedia.org/T197550>. My single comment
("andre__: Such a troll.") is clearly what contributes to an unwelcoming
environment for contributors, not blocking them from reading the site and
demanding that they be vetted first. Great work, all.
A pseudo-focus on "civility" while you take a hard-line and skeptical view
toward outsiders. Maybe these people are auditioning for roles in the
Trump Administration. :-)
I'm mostly forwarding this garbage here so that there's some better and
more appropriate context when, in a few months, someone says "well, the
code of conduct committee has dealt with dozens of incidents! Clearly it's
necessary!" The people pushing this campaign for more bureaucracy have
repeatedly declined to provide specifics about incidents because it's
pretty obvious that nobody would take them seriously (and rightfully!) if
there were a clearer understanding of what they're actually doing.
Best!
MZMcBride
___
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?
Yaron Koren wrote: >That's how it went until two days ago, when Antoine Musso submitted a >patch for my Site Settings extension (I don't know why that one >specifically), re-adding the file. I rejected the patch, on the same >grounds as before, but another developer, Chad Horohoe, overrode me and >merged it in. That led to a discussion featuring Antoine, Chad, a few >other WMF developers, and me, which you can find here: > >https://gerrit.wikimedia.org/r/#/c/437555/ > >Some of the (unbelievable) highlights: > >- From Antoine: "Well then can we just archive this repository please?" > >- From Chad: "Yeah no that's not how it works. If it's being hosted on >gerrit.wikimedia.org, it needs a CoC file. If you object to that, you can >find hosting elsewhere." It was really inappropriate for Chad to hastily and forcefully merge this change. MZMcBride ___ 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)
David Gerard wrote: >What ways are there to include user-edited JavaScript in a wiki page? > >[...] > >You can't see it now, but it was someone including a JavaScript >cryptocurrency miner in common.js! > >Obviously this is not going to be a common thing, and common.js is >closely watched. (The above edit was reverted in 7 minutes, and the >user banned.) > >But what are the ways to get user-edited JavaScript running on a >MediaWiki, outside one's own personal usage? And what permissions are >needed? I ask with threats like this in mind. There's an old post of mine that documents some of the ways to inject site-wide JavaScript: <https://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073787.html> I believe, as Brian notes in this thread, that most methods require having the "editinterface" user right so that you can edit wiki pages in the "MediaWiki" namespace. By default, this user right is assigned to the "sysop" user group, but if you search through <https://noc.wikimedia.org/conf/InitialiseSettings.php.txt> for the string "editinterface", you can see that on specific wikis such as fawiki, this user right has been assigned to additional user groups. Jon Robson wrote: >It has always made me a little uneasy that there are wiki pages where >JavaScript could potentially be injected into my page without my approval. >To be honest if I had the option I would disable all site and user scripts >for my account. You could file a Phabricator task about this. We already specifically exempt certain pages, such as Special:UserLogin and Special:Preferences, from injecting custom JavaScript. We could potentially add a user preference to do what you're suggesting. That said, you're currently executing thousands upon thousands of lines of code on your computer that you've never read or verified. If you're a standard computer user, you visit hundreds of Web sites per year that each execute thousands of lines of untrusted scripts that you've never read or verified. 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
Re: [Wikitech-l] Gerrit login oddities
Chad wrote: >On Tue, Feb 13, 2018 at 10:27 AM Chad <innocentkil...@gmail.com> wrote: >> On Tue, Feb 13, 2018 at 7:39 AM Derk-Jan Hartman < >> d.j.hartman+wmf...@gmail.com> wrote: >> >>> Ah, this explains why i wasn't able to login... Really confusing.. >>> Can't we set a varnish/apache/nginx/whatever rule or something to >>> overwrite older now broken cookie settings ? >> >> Got a fix in the works for this. It's affecting more people than I >> initially thought! > >Just landed the fix for this. Visiting the login page should force the old >cookie to expire and let you login again :) I was too lazy to find and delete this cookie and waiting a day seems to have paid off. I tried to log in again a few hours ago and it's now working. Thanks for the fix! Joaquin Oltra Hernandez wrote: >If you have instructions for other browsers please share, I'm sure we >would all appreciate them. As a user, if you suspect cookie troubles, try using incognito mode or private browsing mode in your Web browser. These modes intentionally do not use existing cookies. Obviously it would be best if users weren't forced to debug or work around issues like this, of course. This trick can (in this case, for me, did) reduce annoyance and at least unblocked me to allow me to leave a reply in Gerrit. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Reboot of irc.wikimedia.org
Alexandros Kosiaris wrote: >This is to inform you that on Monday Feb 22nd 2018 ~10:00 UTC, the >infrastructure powering irc.wikimedia.org will be rebooted for >security upgrades. This is expected to only impact bots that are using >irc.wikimedia.org AND are not able to automatically reconnect on >connection failure. From recent experience (the equipment was rebooted >210 ago last time, with no fallout) those are very limited in number >these days. Thank you for this notice. Do you know if it's still the case that per-wiki channels on irc.wikimedia.org are not available/able to be joined until there's activity on that wiki? My memory is that reconnecting to irc.wikimedia.org has not usually been the issue (as you note), but instead it's been that there's a speaking bot account on the network that would only create a channel after there's some activity to report about that wiki. For larger wikis with lots of activity, this means the channels get created nearly instantly after a server restart. For smaller wikis with little activity, this means that the channels may not get re-created for days or even weeks. I just tested irc.wikimedia.org again and it appears that joining/creating arbitrary channels is not allowed. This makes me think that bot accounts and others would be disallowed from joining small/quiet wiki channels until those channels are re-created by by the server/rc-pmtpa, unless some kind of whitelist or workaround has been implemented. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Create aliases for sister projects wikilinks
יגאל חיטרון wrote:
>Hello, and thank you for your answer. Yes, he likes local aliases indeed.
>They can't be done for all wikis, because it's on wiki own language. About
>templates - we can create them, of course, but it's about wikilinks. Isn't
>there any where to create them, even in phabricator, as namespaces aliases
>were?
The difference between "{{wikt|foo}}" and "[[wikt:foo]]" is pretty minimal.
Wikimedia wikis are using
<https://www.mediawiki.org/wiki/Extension:Interwiki>, but with
"$wgInterwikiViewOnly = true;" set according to
<https://noc.wikimedia.org/conf/CommonSettings.php.txt>. This Interwiki
extension supports both local and global prefixes together, but Wikimedia
wikis do not currently have local interwiki prefixes enabled, it looks
like. You could file a Phabricator ticket to change this.
I imagine you'd run into two objections, though. First, some developers
don't really like interwiki prefixes, given that they're really just a
worse form of URLs. "c:" being a prefix that means
"https://commons.wikimedia.org/wiki/$1; was mostly intended as a shortcut
for inputting wikitext and there are potentially better ways to support
this functionality without using interwikis. Interwiki links are
basically a rudimentary abstraction layer or namespacing system.
Second, local interwiki prefixes would mean that when parsing pages, you'd
need to use yet another set of local rules. Yes, we already have namespace
aliases per-wiki (such as "WP:" --> "Wikipedia:" as you mention), but
local interwiki links would be another list to manage and reference when
parsing pages. Local rules like this can also make using content between
wikis more difficult, since copying and pasting can become less trivial.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Create aliases for sister projects wikilinks
יגאל חיטרון wrote:
>We just added a lot of aliases for namespaces, for example WP: for
>Wikipedia: and U: for User:. Is there a way to do the same thing for the
>sister projects? For example, adding a local name for n: or wict:.
Are you familiar with <https://meta.wikimedia.org/wiki/Interwiki_map>? It
sounds similar to what you want, except interwiki prefixes defined on that
page apply to all public Wikimedia wikis. Do you want local-only prefixes?
Would templates (i.e., {{wict|hello}} instead of [[wict:hello]]) work?
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] TechOps update
Victoria Coleman wrote: >Hi everyone. > >We are making some exciting changes in TechOps! > >[...] This is all really great news! Thanks for sharing this. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for a developer support channel
Brian Wolff wrote: >On Friday, November 17, 2017, Quim Gil <q...@wikimedia.org> wrote: >> The Technical Collaboration team proposes the creation of a developer >> support channel focusing on newcomers, as part of our Onboarding New >> Developer program. We are proposing to create a site based on Discourse >> (starting with a pilot in discourse-mediawiki.wmflabs.org) and to point >>the many existing scattered channels there. > >What does point existing channels to discouse mean exactly? Are you >planning to shutdown any existing channels? If so, which ones? Excellent questions. I'd like to know the answers as well. I raised a similar point at <https://www.mediawiki.org/wiki/Talk:Discourse>. I skimmed <https://phabricator.wikimedia.org/T155678>, looking for some answers, and I didn't find any. Quim, are you involved in MediaWiki support in places such as the #mediawiki IRC channel or the mediawiki-l mailing list? Are you involved in MediaWiki support elsewhere? I'm trying to better understand how it would be appropriate for you to seemingly suggest disrupting or shutting down these established and functioning venues. If this is not your suggestion, I'd like to understand how adding a venue will improve matters. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Simple overview image about how MW loads resources in clients
Nick Wilson (Quiddity) wrote: >If you mean https://www.mediawiki.org/wiki/Module:Bananas I would >guess "banana" was chosen as a >https://en.wikipedia.org/wiki/Placeholder_name because it's friendly >and innocuous, and is not ambiguous as "Example" might be. "Module:Bananas" on the English Wikipedia is slightly older: <https://en.wikipedia.org/wiki/Module:Bananas>. Both appear to be named after the example in the reference manual (August 2012): <https://www.mediawiki.org/w/index.php?diff=572334=568270>. mathieu stumpf guntz wrote: >The fact that banana is friendly, yeah sure, I'm not aware of any banana >who willingly assaulted someone. The fact that it is innocuous, well, >really, I think that banana is not the less sexually connoted example >one might found. Well, personally I don't really have a problem with >that, although one might argue that for gender parity it would be fair >to also use other examples. We could switch to Module: or Module:. :-) >Now, for the case of Module:Bananas, I think that Module:Fanciful would >be fine in some cases. In others cases like introduction manual, things >like "MyFirstModule" or "UsernameFirstModule" might do the trick. It >also add implicit information that camel case is the usual way to write >module names. Moreover, one might even argue that "UsernameFirstModule" >easily be dynamically generated, creating an awesome custom user >experience which foster engagement of developers and finally make the >world a really wonderful place to live in (hmm). Using CamelCase for module names may be specific to particular wikis. The English Wikipedia doesn't seem to do this as much: <https://en.wikipedia.org/wiki/Special:PrefixIndex/Module:>. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Can we drop revision hashes (rev_sha1)?
Antoine Musso wrote: >I guess Aaron Halfaker, Brion Vibber, Aaron Schulz would have some >insights about it. Yes. Brion started a thread about the use of SHA-1 in February 2017: https://lists.wikimedia.org/pipermail/wikitech-l/2017-February/087664.html https://lists.wikimedia.org/pipermail/wikitech-l/2017-February/087666.html Of note, we have <https://www.mediawiki.org/wiki/Manual:Hashing>. The use of base-36 SHA-1 instead of base-16 SHA-1 for revision.rev_sha1 has always perplexed me. It'd be nice to better(?) document that design decision. It's referenced here: https://lists.wikimedia.org/pipermail/wikitech-l/2012-September/063445.html MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wiki farm configuration
Bartosz Dziewoński wrote: >On 2017-09-11 15:41, Manuel Vacelet wrote: >>> It is recommended to use a different DB for each wiki (By setting a >>> different $wgDBname >>> <https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:$wgDBname> >>>for each wiki). However if you are limited to a single database, you can >>>use a different prefix ($wgDBprefix >>> <https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:$wgDBprefix>) >>> to separate the different installs. >> >> But it's not detailed why it's recommended. I'd like to know if there is >> any downside of using the prefix strategy (peformances, upgrades, etc) ? > >I think the only downside is that you'll have to keep the prefixes in >mind when writing your own SQL queries. Making and restoring database >backups for individual wikis will also be less convenient. Speaking generally, if there's a MediaWiki-related recommendation, it's probably based on the behavior of Wikimedia wikis such as Wikipedia. Wikimedia wikis split into one MediaWiki installation per database, though many smaller wikis share the same database host. Also, speaking generally, it's often easier to combine things that were separate than to separate things that were combined. For your particular question, I think the main considerations are how big your wiki farm is in total and how large each wiki is expected to be. In my mind, there's a pretty substantial difference between a wiki farm that has five members versus a wiki farm that has 800 members. Every MediaWiki installation consists of dozens of database tables. And, as alluded to, it's typically easier to keep databases on the same host, unless you want to go down the road of clustering and sharding. If you're expecting to have a wiki farm with five members, but one member will have 5 million articles and 4 members will have 200 articles combined, you may want to split based on that. As Bartosz notes, there shouldn't be any issues with using $wgDBprefix other than mild inconvenience if you write a lot of database queries directly, which is unlikely. $wgDBprefix may be your best option if you can only have a single database. (Though maybe, if you're limited to a single database, you want to consider a different hosting provider.) Bartosz is also correct that lots of tools work best at the database-level, though many of them also have support for the use-case/setup that you're describing. Manuel Vacelet wrote: >I've got questions around Wiki Farm setup, I'm not sure if it's the right >place to ask the question. If there is a better channel, feel free to say >so. This mailing list is a fine place. There's also mediawi...@lists.wikimedia.org if you prefer mailing lists, or many IRC channels on the freenode network. Potentially helpful channels are #mediawiki or #wikimedia-tech. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Last Call: ArchCom/TechCom Charter
Daniel Kinzler wrote: >Over the last couple of months, the Architecture Committee has been >working on a charter that defines the Committee's purpose of authority. >Thank you for your input! The final draft of the charter is now available >at: > > <https://www.mediawiki.org/wiki/Architecture_committee/Charter> > >For a final round of feedback, we are following the procedure we also use >when approving RFCs. As per yesterday's ArchCom meeting, the charter is >entering the Last Call period. If no new and pertinent concerns are >raised and remain unaddressed by July 26, the charter will be enacted as >the new basis of the committee's operation and authority. How do you reconcile these two sentences? "The WMF CTO is automatically a member." "TechCom has full discretion over adding or removing members, with the CTO having veto power. Committee membership is not tied to employment by the WMF or any other organization." I don't think the Wikimedia Foundation Inc.'s current CTO should automatically be a member of a technical committee for Wikimedia projects. And I certainly don't think the current CTO should have veto power over anything. I'm also pretty wary of this document as it seems to have been almost entirely written by Wikimedia Foundation Inc. employees. Where is the input and representation of the rest of the Wikimedia technical community outside of current Wikimedia Foundation Inc. (or Wikimedia Deutschland) employees? And then there are parts like this: "Conflicts can be escalated to the [current Wikimedia Foundation Inc.] CTO." Bleh. This page is speaking out of both sides of its mouth. It's claiming to be representative of the Wikimedia technical community, while also basically (re-?)establishing itself as a mere extension of the current bureaucracy of Wikimedia Foundation Inc. The lofty sentences such as "Within Wikimedia, technology leadership is not vested in a single individual, but in the technical community. That leadership is focused in TechCom." are counter-acted by the finer print (i.e., the actual proposed implementation of this committee). MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Global language preference
Bryan Davis wrote: >Kunal has a rough start on such a tool at ><http://tools.wmflabs.org/globalprefs/>. The source looks to be a ><https://github.com/legoktm/globalprefs>. Maybe some folks would like >to collaborate on expanding that tool to make a nicer working proof of >concept? Why? Do you really believe that setting global user preferences should require a third-party Python Flask tool that relies on JavaScript and OAuth to set a user preference on every wiki? How is duplicating a default value to hundreds of wikis, in a separate code base with its own user interface, a sane or desirable architecture? MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Global language preference
Brad Jorsch (Anomie) wrote:
>On Wed, May 10, 2017 at 3:48 AM, Yongmin H. <li...@revi.pe.kr> wrote:
>> Language is hackable via JS but settings like 'set timezone to blah
>>blah, disable VE if it's enabled, disable compact language if enabled,
>>set email to plaintext only, disable xwiki notification, ...' can't be
>>done via JS hack, which is unfortunate.
>
>It probably can, almost[1] anything you can change in Special:Preferences
>could be changed via something in your global user JS calling the action
>API's action=options.
>
>The main drawback is that it wouldn't take effect on a wiki until after
>the first time you visit a page there that loads your global user JS.
Yes, but that's not so bad. After someone deleted a ton of skin user
preferences, I added this snippet to my "global.js" subpage on Meta-Wiki,
with Legoktm's help:
/* Set skin to MonoBook */
mw.loader.using("mediawiki.user", function() {
if ( mw.user.options.get('skin') !== 'monobook' ) {
mw.loader.load("mediawiki.notify");
( new mw.Api() ).postWithToken( 'options', {
action: "options",
change: "skin=monobook"
} ).done( function() {
mw.loader.using("mediawiki.notify", function(){
mw.notify( "Skin has been changed to MonoBook. Please
refresh the page." );
} );
} );
}
} );
It works pretty well. It's certainly easier than going to
Special:Preferences on each wiki. Some links:
* https://phabricator.wikimedia.org/T16950#2185759 (April 2016)
* https://phabricator.wikimedia.org/T154956#2929966 (January 2017)
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia Github organization
Florian Schmidt wrote: >I asked hashar and he looked at the people, who are already part of the >org, and found some volunteers, so he invited me, too. However, I think >we should've at least a broader discussion, and hopefully we can create a >help page or a public policy for if, when and how a volunteer developer >can be a member of the Wikimedia org on github. Can we re-use the +2 list(s) for this? If someone has +2 access on a MediaWiki or Wikimedia Gerrit repository and they wish to be part of the Wikimedia GitHub organization, we can add them? That seems simple and straightforward enough. It doesn't answer where and how to make the request. Probably in Phabricator Maniphest somewhere? > I could, however, Open a pull request or an issue for all projects, but, > apart from the work doing this manually, this sounds like wasted time, >too, as we don't use pull requests on github and use phabricator instead >of github issues for the organization of work, that's why this is not a >solution, too. If the Wikimedia GitHub organization membership continues to expand, it might add to confusion about Wikimedia's relationship with GitHub. I know that we note in repository descriptions on GitHub to use Gerrit, but maybe we should revisit GitHub pull request integration at some point. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Introducing the MediaWiki Platform Team!
Markus Glaser wrote: >It's so great to see this happen! The formation of the platform team >clearly adds emphasis to the fact that MediaWiki is not only underlying >Wikipedia and its sister projects, but is also widely used by thousands >of sites on the internet and therefore a product of the Foundation in >itself. There are a lot of external MediaWiki maintainers have been >longing for clear leadership and a predictable roadmap for MediaWiki as a >software product for quite some time. So this is a big step ahead. > >I wish the team a good start and all the best for your work. If there's >anything the MediaWiki Stakeholders Group can do to assist you, let us >know! There's a forked thread on mediawiki-l. Copying this feature wishlist link from there, as I found it interesting: https://www.mediawiki.org/wiki/?curid=295301 Source: https://lists.wikimedia.org/pipermail/mediawiki-l/2017-April/046477.html MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Introduction
rupert THURNER wrote: >ha, how embarrassing! i used google to search "wikimedia projects >programming beginner" and google found the beginners guide for python >programmers, which is not what i wanted :) >https://wiki.python.org/moin/BeginnersGuide/Programmers . then i went >to https://www.wikipedia.org/ and i was lost as well. donation, shop, >help, and, and, and. no programming. In the footer of every Wikimedia wiki, there should be a "Developers" link that leads to <https://www.mediawiki.org/wiki/How_to_contribute>. You can see this link at <https://en.wikipedia.org/wiki/Main_Page#footer> or <https://meta.wikimedia.org/wiki/Main_Page#footer> or <https://wikimediafoundation.org/wiki/Home#footer>. Suggestions for more places to put this link or better text to make it more obvious are always welcome, of course. :-) MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ArchCom Monutes, News, and Outlook
Gabriel Wicke wrote: >Daniel Kinzler wrote: >> Next week’s RFC meeting (tentative, pending confirmation): >> * explore High - Level Mobilefrontend Requirements (JavaScript >>frameworks, Progressive Apps, and all that jazz) >> <https://docs.google.com/document/d/1id-E_KELGGA3X5H4K44I6zIX3SEgZ0sF_ >> biOY4INCqM/edit#heading=h.xs2aq4j4wzse>. >> * NOTE: we plan to experiment with having a public HANGOUT meeting, >> instead of using IRC. > >This is now confirmed. > > - What: High level mobile frontend requirements & plans > - When: March 15, 2-3pm PDT (San Francisco) > - Where: > - Stream: http://youtu.be/8W7WrTa3Py4 > - Hangout (25 active participants max): > >https://hangouts.google.com/hangouts/_/ytl/T7sMtE_gUxWZ4biKxPh5ffreSnwnrIj >1L7udZWXlKSk Which Phabricator Maniphest task is this referring to? In my opinion, MobileFrontend should not exist. I hope the plan being discussed is to finally end its development. bawolff wrote: >+1 to this being inconvenient. I don't always attend arch com >meetings, but usually do if I happen to be online during the time. If >its a hangout, it is extremely unlikely I would attend unless I was >specifically proposing an RFC. Proprietary and capped at 25 participants? No thank you. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Provisional notes for proposed revision table restructuring
Brion Vibber wrote: >We're going to have another checkin during ArchCom IRC meeting time this >Wednesday, 22:00 UTC / 2pm PST in #wikimedia-office > >Documents will be updated shortly reflecting the previous discussion & >ongoing tweaks. > >Open questions include: >* should we go straight to the MCR-ready schema or do this in two steps, >one to break up tables & prep, and another for the MCR content model? >* final model for updating archive & text Re: https://www.mediawiki.org/wiki/?curid=661038 The implementation path isn't clear to me. For a "regular" MediaWiki installation, will making these changes be a matter of simply updating MediaWiki's application code and running maintenance/update.php? For Wikimedia wikis, as far as I know update.php is never run. Are you planning to write separate maintenance scripts for this? Regarding scope, this is a lot of changes. How are all of these changes intended to be divided? Are we able to move forward with some changes (e.g., adding a comment table) without moving forward with other changes (e.g., adding a user_entry table)? Some parts of this proposal seem to be well-received and popular (yay). Other parts, particularly dealing with users, seem to be hairier and less settled. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: EventStreams launch and RCStream deprecation
Congratulations on the launch of EventStreams. Andrew Otto wrote: >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. I monitor irc.wikimedia.org and it has proven itself to be highly reliable for many years in production, which is a lot more than can be said for any of these proposed alternatives. I'm glad to hear that irc.wikimedia.org will be left alone. If people want to be nasty and call irc.wikimedia.org deprecated, I suppose that's fine, as long as it remains the functional and dependable (and completely quirky) API it continues to serve as. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [T62399] Possible alert message to show
Shanika Ediriweera wrote: >I am working on the task "When moving, warn if people try to move to >Foo:Foo:Bar (repeated namespace)" - >https://phabricator.wikimedia.org/T62399 >. > >What would be a good alert message for the users when there is repeated >namespace in title? Maybe something like this: "Please verify your new page title: Foo:Foo:Bar. 'Foo:Foo:' in a page title is usually a mistake." But the deeper issue is <https://phabricator.wikimedia.org/T50239>. The namespace drop-down menu at Special:MovePage is a misfeature. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Please review "Amendments" section of the Code of Conduct
Matthew Flaschen wrote: >This is the last section. After it's approved, the Code of Conduct will >become policy, and the Amendments section will specify how future >changes to the policy work. https://mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#Final_approval_of_CoC As noted on the talk page, my understanding is that in past discussions about approving specific sections of this draft code of conduct, you assured participants that there would be a final vote on the full and complete draft text. After these discussions were closed, you're now seeking to cancel a final vote on the code of conduct text, considering the section-level approvals to be sufficient. I don't see how this is acceptable. In my opinion, either the previously approved sections must be revisited, with the new understanding that there will be no final vote, or the final vote on the text should be held, as previously discussed and advertised. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Citation Hunt database
Takashi OTA wrote: >After importing categorylinks.sql and page.sql, downloaded from >https://dumps.wikimedia.org/jawiki/latest/jawiki-latest-category.sql.gz >https://dumps.wikimedia.org/jawiki/latest/jawiki-latest-page.sql.gz > >on to local MySQL database "jawiki_p", with the instructions shown at: >https://github.com/eggpi/citationhunt/blob/master/scripts/README.md . > >(I have done it like; >$ mysql -u root >mysql> create database jawiki_p; >mysql> use jawiki_p; >mysql> source jawiki-latest-category.sql; >mysql> source jawiki-latest-page.sql; ) > >When you run scripts/print_unsourced_pageids_from_wikipedia.py >after setting CH_LANG, it dumped an error shown below: > >(ch-venv) Mac-mini:scripts takot$ export CH_LANG=en >(ch-venv) Mac-mini:scripts takot$ echo $CH_LANG >ja >(ch-venv) Mac-mini:scripts takot$ >./print_unsourced_pageids_from_wikipedia.py > unsourced >Traceback (most recent call last): > File "./print_unsourced_pageids_from_wikipedia.py", line 40, in >print_unsourced_ids_from_wikipedia() > File "./print_unsourced_pageids_from_wikipedia.py", line 21, in >print_unsourced_ids_from_wikipedia >' OR '.join(['cl_to = %s'] * len(categories)) + ')', categories) > File >"/Users/takot/ch-venv/lib/python2.7/site-packages/MySQLdb/cursors.py", >line >205, in execute >self.errorhandler(self, exc, value) > File >"/Users/takot/ch-venv/lib/python2.7/site-packages/MySQLdb/connections.py", >line 36, in defaulterrorhandler >raise errorclass, errorvalue >_mysql_exceptions.ProgrammingError: (1146, "Table 'jawiki_p.categorylinks' >doesn't exist") I think you're confusing these two database tables: * https://www.mediawiki.org/wiki/Manual:Category_table * https://www.mediawiki.org/wiki/Manual:Categorylinks_table It looks like you loaded category, but the script is complaining about categorylinks. MZMcBride ___ 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
Antoine Musso wrote: >The staff period can have changed the state of mind of the person, even >had it been a volunteer before employment. If leaving in bad terms with >an eventual envy of retaliation against the project, then code get >screwed. > >A very basic exit interview would clarify the future ground and as Kevin >said in 99% of case it will be a non issue. But we might catch the 1% >lone wolf that will eventually cause havoc. For the price of a few >minutes interview, I think it is worth it. Lone wolf? Wow. In the history of both MediaWiki and Wikimedia development, Wikimedia Foundation staff have created significantly more havoc and disruption than volunteers. Please don't forget that. MZMcBride ___ 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
Stas Malyshev wrote: >>that step entirely seems risky to me. Unless, as I said, having +2 really >>isn't a big deal. > >+2 isn't super-big deal since all changes are public and you're not >supposed to self-+2 in any case, and anything doable by patch can also >be undone by patch. As I understand it, it's more like "this person >knows enough and known enough to get approval rights". It won't change >if somebody leaves WMF. Hi. For what it's worth, <https://www.mediawiki.org/wiki/Gerrit/%2B2> specifically emphasizes that +2 is a big deal. >If there's external reasons for +2 removal, that can happen without WMF >in the picture and I imagine there are rules for this which can be >applied. Revocation of +2 is documented at <https://www.mediawiki.org/wiki/Gerrit/%2B2#Revocation>. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] IRC meeting today (Wednesday) about "RFC: Accessing page properties from wiki pages"
Hi. I filed a request for comments (RFC) regarding accessing page properties from wiki pages. * Maniphest task: https://phabricator.wikimedia.org/T154738 * Wiki page: https://www.mediawiki.org/wiki/?curid=647378 There is an IRC meeting scheduled to discuss this RFC on Wednesday, January 25, 2017 at 22:00 UTC (2 p.m. PST, 5 p.m. EST, 11 p.m. CET) in #wikimedia-office on chat.freenode.net. All are welcome! MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ArchCom Status & Meeting Minutes, WD3
Brad Jorsch (Anomie) wrote: >On Wed, Jan 18, 2017 at 10:44 PM, Daniel Kinzler < >daniel.kinz...@wikimedia.de> wrote: >> ** Related discussion about whether new features can require services >> serparate from MediaWiki core. > >That seems like it would be a decent RFC at some point. Agreed. There are often questions of debug and maintenance support and service level for production services, from the Wikimedia (Foundation) operations team and others. Clarifying the current situation and how it can be modified in the future would be useful and alleviate some of the tensions we've had, in my opinion. The trickiness here is that some of this falls outside of the Architecture committee's purview, particularly as no member of the operations team is on the committee currently (Mark, Faidon, Alexandros, Giuseppe, et al.). In my mind, there's what MediaWiki core and its extensions can do and can require, but the relationship between MediaWiki and Wikimedia cannot be completely sidestepped. With MediaWiki as the platform, there are also questions about what wikimedia.org, mediawiki.org, wikipedia.org, and the various other Wikimedia projects are willing to host and support. RESTBase seems like a decent example of this interplay. Daniel Kinzler wrote: > We have to decide on a MO. I'm sharing this summary here to keep you >posted, and give an opportunity for input. But in the end, the committee >has to decide how it wants to operate. "You know what they call a leader with no followers? Just a guy taking a walk." >In the past, the IRC dicussion was the only way to get an RFC discussed >or approved. It depends how strictly you view requests for comments. A decent-size Gerrit changeset that gets accepted and merged in is, in some ways, an RFC, usually with one or more associated Phabricator Maniphest tasks. Sometimes with associated mailing list or on-wiki discussion. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ArchCom Status & Meeting Minutes, WD3
Daniel Kinzler wrote: >* ArchCom is considering changes to the RFC process. Discussion is >ongoing. Where is discussion ongoing? >Key points: >** More focus on discussion in Phabricator >** More leight weight process for “small” RFCs >** ArchCom to focus more on review, less ond process >** IRC meeting should not be the primary tool for discussing and >approving RFCs I don't know what primary tool means. There are benefits to both asynchronous and synchronous discussions. The IRC meetings in particular have the benefit of being scheduled and regularly recurring, which can be a good nudge for people to finish drafting a task or wiki page, to make a decision to accept or decline, to comment on a proposal, etc. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Divide XML dumps by page.page_namespace (and figure out what to do with the "pages-articles" dump)
Hi. Re: https://phabricator.wikimedia.org/T99483 This is a task proposing dividing XML dumps by the numeric page namespace ID (such as 2 for User pages). Please share your thoughts on the task. It's currently unclear whether implementing this task would result in getting rid of the "pages-articles" dump. We could keep generating it, but it costs a non-negligible amount of disk space to do so. If you regularly use the "pages-articles" XML dump format and have thoughts about keeping it as-is or changing it, please comment on the task. If someone could forward this e-mail to the xmldatadumps-l and wiki-research-l mailing lists, I would very much appreciate it. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Arbitrary Wikidata querying
Thank you for this e-mail. It was informative. Stas Malyshev wrote: >No, and there are tricky parts there. Consider >https://www.wikidata.org/wiki/Q735712. Yes, Lex Luthor held the office >of the President of the USA. In a fictional universe, of course. But the >naive query - every Wikidata item where position held includes "President >of the United States" - would return Lex Luthor as the president as >legitimate as Abraham Lincoln. In fact, there are 79 US presidents >judging by "position held" alone. So clearly, there need to be some >limits. And those limits would be on case-by-case basis. Sure, but I'm not really worried about potential false positives. I'm worried that we're building a giant write-only data store. >Right now the best way is use one of the list-maintaining bots I think. This sucks. :-( >Unless you're talking about pulling a small set of values, in which case >Lua/templates are probably the best venue. I'm not sure what small means here. We have about 46 U.S. Presidents, is that small enough? Which Lua functions and templates could I use? >We're working on it (mostly thinking right now, but correct design is >80% of the work, so...). Visualizations already have query capabilities >(mainly because they have strong caching model embedded and because >there are not too many of them and you need to create them so we can >watch the load carefully). Other pages can gain them - probably via some >kind of Lua functionality - as soon as we figure out what's the right >way to do it, hopefully somewhere within the next year (no promise, but >hopefully). Wikidata began in October 2012. I thought it might take till 2014 or even 2015 to get querying capability into a usable state, but we're now looking at potentially 2018? This really sucks. I think Wikidata may eventually have a seismic shift on wiki editing, but currently I don't see any reason to even contribute to it when it feels like putting data into a giant system that you can't really get back out. I love Magnus and I have a ton of respect for him, but I don't want anything to do with anything called Listeria. It continues to seem like querying is an afterthought for Wikidata and this continues to boggle my mind. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Arbitrary Wikidata querying
Hi. If I wanted to make a page on the English Wikipedia using wikitext called "List of United States presidents" that dynamically embeds information from <https://www.wikidata.org/wiki/Q23> and <https://www.wikidata.org/wiki/Q11806> and other similar items, is this currently possible? I consider this to be arbitrary Wikidata querying, but if that's not the correct term, please let me know what to call it. A more advanced form of this Wikidata querying would be dynamically generating a list of presidents of the United States by finding every Wikidata item where position held includes "President of the United States". Is this currently possible on-wiki or via wikitext? If either of these querying capabilities are possible, how do I do them? I don't understand how to query Wikidata in a useful way and I find this frustrating. Since 2012, we've been putting a lot of data into Wikidata, but I want to programmatically extract some of this data and use it in my Wikipedia editing. How do I do this? If these querying capabilities are not currently possible, when might they be? I understand that cache invalidation is difficult and that this will need a sensible editing user interface, but I don't care about all of that, I just want to be able to query data out of this large data store. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deploying the Linter extension to Wikimedia wikis
Legoktm wrote:
>>Does the extension distinguish between errors and warnings? Are there
>> gradations of errors? For example, deprecated syntax v. invalid syntax?
>
>Not really. Each category has a name like "obsolete-tag" or
>"bogus-image-options", and that's about it.
There's now <https://phabricator.wikimedia.org/T152822>.
Subramanya Sastry wrote:
>On 10/24/2016 08:42 AM, MZMcBride wrote:
>>Does the extension distinguish between errors and warnings? Are there
>>gradations of errors? For example, deprecated syntax v. invalid syntax?
>
>Technically, there are no errors with wikitext ... but yes, Parsoid
>knows what some of these "errors" are and they are tagged with different
>category names which can be tweaked as necessary. And, other
>deprecations can be targeted and marked up.
I'm not sure what this technically means. There are no errors with
wikitext in what sense?
If I open a tag and there's no closing tag, is that an error?
What about partial heading syntax (such as "== foo" at the start of a
line) or unclosed HTML comments ("
Re: [Wikitech-l] CREDIT in 37 minutes
Adam Baso wrote: >And the videos. Enjoy! > >YouTube: https://www.youtube.com/watch?v=W_sf-kHAQkg >WebM on Commons: >https://commons.wikimedia.org/wiki/File:CREDIT_-_December_2016.webm Wow that was fast! Can we have you all do the uploads for the upcoming Wikimedia Developer Summit? :-) MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What happened to RobLa?
Wes Moran wrote: >RobLa has departed the Foundation. While people sometimes supply a >message it is left to the individual to decide how they choose to do so. >It’s inappropriate for me or any of his other colleagues to discuss them >on his behalf. Rob has been with us for over six years, and he will be >missed. I hope we will continue to see him in a volunteer capacity. We will need to figure out what this change means for the Architecture committee: <https://www.mediawiki.org/wiki/Architecture_committee>. There are likely specific areas, such as Maniphest tasks assignments, that will need attention. And for planning purposes, it would be helpful to know if RobLa will attend the upcoming developer summit in January 2017. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deploying the Linter extension to Wikimedia wikis
Legoktm wrote: >Arlo and myself have been working on a new MediaWiki extension to expose >Parsoid's "lint errors" to users. > >[...] > >The main advantage of this over tracking categories is that we know the >location in the wikitext so it should be easier to identify the error >and fix it, as well as knowing whether the issue was caused via a >template or not. Nice. (I haven't read/skimmed any of the code yet.) How will the errors be queried? Will be there an api.php module to query on a per-error or per-page basis? Does the extension distinguish between errors and warnings? Are there gradations of errors? For example, deprecated syntax v. invalid syntax? I wonder if the name "Linter" is overly generic. This extension will only activate on wikitext, correct? It won't lint other content models/types such as JavaScript and CSS? MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Setting up a new Tomcat servlet in production?
Wikitech-l on behalf of Adam Wight wrote: >The challenges are first that it's based on a Tomcat backend [...] >which I'm not sure is precedented in our current ecosystem, and second >that the code uses Chinese variable and function names, which should >unfortunately be Anglicized by convention, AIUI. Finally, there might be >security issues around the rendered text itself, if it were misused to >mask content. > >I'm mostly asking this list for help with the question of using Tomcat in >production. I'm reminded of Hierator, which I believe never made it into production but had a clear implementation path. Some potentially interesting links: * https://www.mediawiki.org/wiki/Requests_for_comment/Hierator * https://phabricator.wikimedia.org/T89331#1537849 MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Feature Requests: Suggeted new features
Hi Aaron, You probably want to file these ideas in Phabricator Maniphest: <https://phabricator.wikimedia.org>. Some of these ideas may already exist as Maniphest tasks. Phabricator lets interested users subscribe to the ideas in order to receive targeted e-mail notifications, provide feedback, and it gives us a centralized place to track progress, blockers to implementation, and more. I'm glad to see you're excited to contribute. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia Developer Summit 2017 discussion
Wikitech-l on behalf of Rob Lanphier wrote: >On Wed, Sep 28, 2016 at 2:27 AM, Legoktm <legoktm.wikipe...@gmail.com> >wrote: >> [1] https://www.mediawiki.org/wiki/Principles > >The edit history of that page is telling. Be bold. > It may be a little naive to hope [dogfooding] will somehow make our >software better at doing the thing it was designed to do when we try to >force it to do something it wasn't designed to do. What specifically are you arguing that MediaWiki was or was not designed to do? Please, go on. >>That said, MediaWiki categories can be pretty powerful, and then >>you can combine them with templates or things like DPL. We already have >>such a system set up for RfCs on mediawiki.org, I think making a similar >>template and set of categories for summit proposals would be easy. > >That seems like a lot of work where the time and effort is better spent >elsewhere. Another teaser here. What exactly is your vision for MediaWiki? Are you really suggesting in your reply that supporting yet another markup language is more important and a higher priority than having usable categorization and tagging systems? I'm genuinely curious where you think time and effort is best spent. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Opening up MediaWiki dev summit in January?
C. Scott Ananian wrote:
>On Thu, Sep 8, 2016 at 1:57 PM, Rob Lanphier <ro...@wikimedia.org> wrote:
>>Let's say that we had to pick only one of these questions to answer
>>at WikiDev17. Which would you choose?
>
>All of them! But since no one else bit Rob's bait, let me try to give a
>pro/con for each.
I considered taking the bait. I read the questions, but my primary thought
was "man, this guy seems way overdue to submit a Gerrit patch or do
something less highfalutin."
>>* how can we better distribute the information on our websites?
>
>Pro: invites radical thought disconnected from monetary/fundraising needs!
>How can we get everyone to use our stuff? We collectively probably
>haven't thought hard about this recently.
Plenty of people have given this thought. Offline reading, printed
editions, putting Wikipedia on the Moon, Wikipedia Zero, etc. We can do
more, of course, but that's true of everything.
>> * how can we help our software development community be more inclusive
>>and productive (and attract many more people)?
>
>Pro: again, big thoughts, on a topic which deserves attention. Can drill
>down into nitty-gritty like, "why not github?" and "can we make the review
>process more friendly?" which are favorite topics for fat-chewing among
>developers.
Wikimedia-related Git repositories are on GitHub. If we want to attract
more people, that requires figuring out how to scale up the already shaky
code review process.
>>* how can we improve the quality of our software, and pay down the
>> technical debt we've accumulated over the years?
>
>Pro: again, a favorite topic of talk-over-beers among developers. One
>could imagine a whole summit devoted to going through our software stack
>component by component, identifying the cruft hidden in each, and making
>concrete plans to banish it.
>Con: this opinion might be controversial, but my impression is that we're
>actually pretty good at low-level refactoring. There are plenty of things
>we are hesitant to change (say, wikitext syntax!), but I don't get the
>feeling that the barrier is in engineering. The problem is mostly a
>management one: how can engineering communicate the time spend and value
>added by "invisible" maintenance and refactoring; how can we get
>management to allocate more dedicates resources to this? I don't think
>there's much technical debate about what to work on, if we had the
>resources to do so.
I think this problem exists in most companies/organizations. Nobody wants
to pay down technical debt; building new features is a lot more exciting.
>>* how can we make our websites better learning environments?
>
>Pro: another radical idea, and I like radical ideas. ;)
>Con: We have wikiversity for this. Yes, it has its problems. But
>wouldn't this topic be better phrased as, "how can we better support
>wikiprojects other than wikipedia?"
Yes, that's better phrasing. But it's still too vague to be useful. As I
read this question, I hear your comments about "strategy" v. "dev" echoing
around in my head. How we can better support non-Wikipedia projects might
mean setting them free/abandoning them.
>Ok, so what have we learned from this? Even if others have different
>opinions about each of Rob's proposed topics, which are the *sort* of
>things we'd like the dev summit to be about? Radical ideas? Stuff
>developers bitch over beers about? Vague umbrella topics ("make wiki
>easier to use") that we can crowd a bunch of stuff under? Something else
>entirely?
In my experience, the greatest value derived from these types of events
(summits, hackathons, unconferences, whatever other cutesy word) is having
unstructured time to explore and think and poke and discuss with people
about pet projects and other neat ideas. The structured and more formal
sessions, with their broad themes for whatever year it is, are usually
boring and ill-fitting.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Looking for WikiDev Summit main topics and volunteers
Quim Gil wrote: >Hi, this is a request from the organizers of the Wikimedia Developer >Summit 2016 (San Francisco, January 9-11). I think you mean 2017, otherwise the listed dates don't make sense. Who specifically are the organizers of the Wikimedia Developer Summit 2017? I have a question for the organizers: will the summit be open to anyone or will it be invitation-only as it has been in past years? Who decides this? Regarding main topics, I think we should make it easier to log in to Wikimedia wikis and control your identity when on-wiki. Specifically, supporting login via e-mail address, case-insensitive login, and a user-configurable "display name" field that's shown in page histories, on user pages, etc. I'm interested in volunteering to provide feedback about the upcoming summit. I've attended one or two summits in the past and I have thoughts. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to login with API?
Bináris wrote: >I found bot passwords, but they offer very limited user rights. >So the best thing is to try without API? I don't know enough about your requirements to say for sure, but in my uninformed opinion, the best thing would be to switch from Pywikibot Compat to Pywikibot core. :-) Looking at pages such as <https://www.mediawiki.org/wiki/Manual:Pywikibot/Compat/deprecation>, it seems the Compat version of Pywikibot is completely dead and no longer supported. Retrofitting Compat to support current login code doesn't sound like fun to me. I think the API documentation should probably be made a bit clearer as I think there are now two deprecated ways of logging in. We should likely make it more explicit which way applies to which versions of MediaWiki. This allows developers to have a quicker and easier understanding when determining how much compatibility code is needed in a specific tool/script/application. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Loosing the history of our projects to bitrot. Was: Acquiring list of templates including external links
Subramanya Sastry wrote: >Some user pages seem to exploit this as a feature even (unclosed div >tags). Not just some and not just seem. :-) Thank you for this detailed e-mail. John Mark Vandenberg wrote: >The main reason for a spec should be the sanity of the Wikimedia >technical user base, including WMF engineers paid by donors, who build >parsers in other languages for various reasons, including supporting >tools that account for a very large percent of the total edits to >Wikimedia and are critical in preventing abuse and assisting admins >performing critical tasks to keep the sites from falling apart. In fairness, there's a Parsing team at the Wikimedia Foundation. We all recognize that there's a problem and I think we're making decent progress toward better defined, though not necessarily saner, behavior. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] "basic" usergroup
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
Re: [Wikitech-l] How to find a repository?
Purodha Blissenbach wrote: >https://phabricator.wikimedia.org/T129442 says to belong to >Tool-Labs-tools-Pageviews but how to find the repository for it, if I >want to work on it? Gerrit does not find anything when I enter this >sring in its repository search. >Is there any tool or tutorial for this question? Maybe <https://phabricator.wikimedia.org/diffusion/ANPA/>? Though I think this is possibly the pageview API, not the Wikimedia Tool Labs tool. https://phabricator.wikimedia.org/tag/tool-labs-tools-pageviews/ gives me a 404 for some unknown reason, even though there are Maniphest tasks associated with this tag. Phabricator search is abhorrent for Diffusion repositories. Even if you manage to reach a project description page such as <https://phabricator.wikimedia.org/project/profile/2045/>, they're almost always completely useless. The issue of not being able to find repositories is not specific to this repository, of course. If I search in Phabricator for "centralnotice", the only search suggestion is the "MediaWiki-extensions-CentralNotice" component. Clicking on this suggestion takes you to its workboard (not sure why): <https://phabricator.wikimedia.org/project/view/291/>. If you go to the project description page (<https://phabricator.wikimedia.org/project/profile/291/>), it mentions the mediawiki.org documentation page, but doesn't mention or link to <https://phabricator.wikimedia.org/diffusion/ECNO/> as far as I can tell. Given how horrible Phabricator is in this area, I'd recommend using GitHub for now. You can include the string "@wikimedia" to filter results; e.g., <https://github.com/search?q=%40wikimedia%20pageview=Everything> or <https://github.com/search?q=%40wikimedia%20centralnotice=Everything>. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How widely is Flow being used?
Pine W wrote: >I believe that Flow is being used on an opt-in basis on Wikidata and >Catalan Wikipedia, and is used on user talk pages by default on MediaWiki. > >Is that correct? > >Are there any wikis other than MediaWiki where Flow is enabled on all talk >pages by default? > >Are there any wikis where Flow is widely used on an opt-in basis, even if >it's not the default? The Wikimedia wiki configuration files are published on the public Internet at <https://noc.wikimedia.org/conf/>. https://noc.wikimedia.org/conf/InitialiseSettings.php.txt has a relevant section (lightly tweaked due to line wrapping): --- 'wmgUseFlow' => [ 'default' => false, // This is computed in flow.dblist as all - "a specific list" // (nonflow.dblist) // - "all private wikis" (private.dblist) + "private wikis with Flow" // (flowprivate.dblist) 'flow' => true, ], --- You can view these database lists. In particular, <https://noc.wikimedia.org/conf/highlight.php?file=flow.dblist>. These configuration files are the canonical source of truth for what's enabled or disabled on Wikimedia wikis. There may be a nice manually updated table on mediawiki.org or meta.wikimedia.org that explains the status of Flow on various wikis. You can verify whether Flow is installed on a specific wiki by visiting the page "Special:Version" on that wiki; for example: <https://en.wikibooks.org/wiki/Special:Version> lists "Flow". This reply doesn't directly answer your questions about "opt-in" versus "all talk pages by default", but it should be a decent starting point to gather those answers as accurately as possible. For example, you can reference the "wmgFlowEnableOptInBetaFeature" configuration variable in InitialiseSettings.php.txt to see which wikis set this variable to true. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What's the "correct" content model when rev_content_model is NULL?
Daniel Kinzler wrote: >What we still need to figure out is how to solve the chicken-and-egg >situation with Multi-Content-Rev. At the moment, I'm thinking this might >work: > >* introduce content model (and format) registry in the DB, and populate > it. >* leave page and revision table as they are for now. >* introduce slots table, use the new content_model (and content_format) > table. >* stop using the content model (and format) from the page and revision > tables >* drop the content model (and format) from the page and revision tables > >Does that sound liek a good plan? Let's for a moment assume we can get >slots fully rolled out by the end of the year. I just read some chatter about slots and multiplexing(?). It seems vaguely interesting, but I don't have enough context or knowledge to understand much of the discussion currently. Is there a request for comments page or some kind of documentation that defines and explains these concepts? MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Etherpad outage
Jaime Crespo wrote: >Continue using https://etherpad.wikimedia.org as usual (but remember to >backup anything important!). The wikis should be, and generally are, the canonical source of information for our projects. One of the major advantages of using the wikis is that we then provide and distribute backups to mirrors and others. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] First image scaler based on Debian jessie
Moritz Muehlenhoff wrote:
>the first image scaler based on Debian jessie is now enabled in
>production. Despite other changes this also provides an update
>of librsvg to 2.40.16 which fixes several long-standing bugs in
>SVG rendering:
>https://phabricator.wikimedia.org/T44090
>https://phabricator.wikimedia.org/T64987
>https://phabricator.wikimedia.org/T97758
>https://phabricator.wikimedia.org/T111815
Hi.
Thank you for this e-mail.
Rob L. recently bumped <https://phabricator.wikimedia.org/T40010>
("Re-evaluate librsvg as SVG renderer on Wikimedia wikis"). I asked on
that task whether Ori's idea to install multimedia packages on all
application servers at <https://phabricator.wikimedia.org/T35186#1771760>
had been explored further. Or perhaps more directly: is there a
willingness to host and support other SVG renderers?
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] git.wikimedia.org (Gitblit) going away on June 29th, redirected to Phabricator
jay...@gmail.com wrote: >Can we have a static website at git.wikimedia.org with some dev curated >phab links to the most important projects ? We could redirect <https://git.wikimedia.org> to a page on mediawiki.org that includes a list of the most popular repositories, with links to the various options for browsing the repository (Phabricator Diffusion and GitHub, at least). I'd be opposed to yet another micro-site. I'm also fine with <https://git.wikimedia.org> just redirecting to <https://phabricator.wikimedia.org/diffusion/>, which is the current plan according to <https://phabricator.wikimedia.org/T137224>. This allows logged-in users to customize the default query. Similar to Maniphest, Diffusion will use the top-sorted custom saved or built-in query as the application's start page. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] git.wikimedia.org (Gitblit) going away on June 29th, redirected to Phabricator
Platonides wrote: >I hear this with dismay. When I wanted to view the repository online in >the past, I always ended up heading to git.wikimedia.org, since I was >unable to *find* the repository at phabricator. >At most, phabricator showed a somewhat related diffusion commit. Phabricator site search includes repositories. I agree that parts of Phabricator, including the repository index at <https://phabricator.wikimedia.org/diffusion/>, can be annoying to find currently. >Gitblit may not be the most suited software regarding technical >stability, but diffusion is far from having an acceptable UI, >I'm afraid. The Git repositories are also mirrored to GitHub, of course. Many people are already on GitHub for other projects and seem to enjoy, or at least tolerate, its user interface. I wonder if we have an index of Git mirrors. It's also possible for anyone to set up their own online Git repository browser (e.g., GitLab or Gogs) or contribute patches upstream to Phabricator Diffusion to add missing features. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Should we switch the default category collation to uca-default?
John Mark Vandenberg wrote: >Yes, of course, & a meta discussion will likely unearth many reasons to >opt-out ;) > >Does uca (or extension) do the right thing for West Frisian (fy) wrt y & >i ? > >Or, ... it would be helpful to put the list of 94 wiki somewhere easy to >consume. My count of wikis not using "uppercase" is a bit lower: 89. I started this page: <https://meta.wikimedia.org/wiki/Collation>. I agree with having a discussion on Meta-Wiki. I think this type of larger undertaking also requires close coordination with a database administrator, if it requires running maintenance/updateCollation.php. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Which Phabricator project for site issues?
Bartosz Dziewoński wrote: >You can also always file a bug without associating any project tags. >Someone will usually quickly categorize your report :) https://meta.wikimedia.org/wiki/Cunningham%27s_Law :-) I have a tendency to forget to fill out the projects/tags field when filing new Maniphest tasks. The bold red "(no projects)" IRC notification usually tips me off to my screw-up. Moving the "Tags" input above the "Description" field could help, maybe. I haven't looked at how common filing tasks without projects is in general. Phabricator is very streamlined and focused on sane user behavior for the most part, but I've found the projects/tags input in Maniphest to be one of its weaker areas. You have to know that tasks related to "transclusion" are often associated with "MediaWiki-Templates". Finding and making that association is difficult currently. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] update: wikipedia.org portal
Dan Garry wrote: >Regarding the move of the portal to a git-based system, as I explained in >great detail in my 18 comments on T110070 ><https://phabricator.wikimedia.org/T110070>, this move was done in >partnership with Mxn, the primary maintainer of the portal in its previous >system. Mxn and I spoke in person about the portal at Wikimania 2015, >which was what really kicked this project off; I also mentioned that in >my very comment <https://phabricator.wikimedia.org/T110070#1568488> on >that T110070. I was also very clear in my comments on the task ><https://phabricator.wikimedia.org/T110070#1653320> that we were >specifically trying to improve only wikipedia.org to keep our work >manageable and maintain cost effectiveness for our efforts. Regarding portals other than www.wikipedia.org, perhaps you can respond at <https://phabricator.wikimedia.org/T135929>? MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] update: wikipedia.org portal
rupert THURNER wrote: >ah, interesting. moving this to git sounds ok to me from a technical >viewpoint. i read >https://www.mediawiki.org/wiki/Wikipedia.org_Portal/Migration_to_gerrit. >despite that i am not clear how the current portal maintainers would >then activate a proposal e.g. from the discovery team? It turns out that the other portals were quietly moved to Git in November 2015. I filed <https://phabricator.wikimedia.org/T135929> about cleaning up the project portals, since they're now being updated in two places, one of which is a decoy, and the various wiki pages on Meta-Wiki don't seem to reflect or acknowledge this at all. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] update: wikipedia.org portal
Derk-Jan Hartman wrote: >I like the addition of the descriptive subtitles. But I would suggest >taking them to meta to settle on what they should be exactly, and also >then documenting them (including arguments) to make sure that they can be >used consistently throughout the projects. Meta-Wiki already has this template, used on its main page: <https://meta.wikimedia.org/wiki/Template:Main_Page/Sisterprojects/en>. Though some of the text there isn't great either. I agree with most of what you wrote in your reply. We should either move all of the project portals into Gerrit/Git and implement server-side features such as serving translated output and including dynamic counts. Or we should move www.wikipedia.org back to Meta-Wiki and continue to serve it from a wiki page. The current hybrid situation of having only www.wikipedia.org served by Gerrit/Git and not being able to, for example, share code between the project portals, is terrible. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] update: wikipedia.org portal
Quim Gil wrote: >On Sat, May 21, 2016 at 1:07 AM, MZMcBride <z...@mzmcbride.com> wrote: >> It's frustrating and annoying that your happy team hijacked this >>portal... > >(snip) > >Hostility and anger are not welcomed in this mailing list, neither in the >rest of Wikimedia spaces. Any problems can be reported and explained in a >respectful and even friendly way. The topics you are exposing in this >thread are no exception. I expressed frustration and annoyance. Those aren't the same as hostility or anger. And there's nothing wrong with being angry sometimes. Sometimes people do stupid things and anger is the most appropriate (or at least the most natural) reaction to have. >Please read https://www.mediawiki.org/wiki/Expected_behavior for more >thoughts about keeping our communities respectful, welcoming, and >friendly. If you want to discuss my reply, please use the discussion page >of the URL above, or reply to me directly. Let's keep this thread >on-topic about the update to the www.wikipedia.org portal. Thank you. No, you don't get to both start and end a tangent. You're as capable as anyone of starting a new thread and you chose not to. rupert THURNER wrote: >quim, i would not be angry if you would show a little bit more empathy >towards a client, a volunteer. if mzmcbride is right and there is a >well established procedure to change this page which was not followed, >the person not following might read the "expected behaviour" page. Project portals such as www.wikipedia.org were managed on Meta-Wiki: <https://meta.wikimedia.org/wiki/Project_portals>. I believe most of the portals continue to be managed on Meta-Wiki, with the exception of www.wikipedia.org; background: <https://phabricator.wikimedia.org/T110070>. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] historical trivia: who first picked UTC as Wikimedia time, when and why?
David Gerard wrote: >Question about obscure historical detail: Who picked UTC as Wikimedia >time? When was this, and what was the thought process? > >(the answer is almost certainly "Brion or Jimbo, early 2001, it's the >obvious choice", but I'm just curious as to details.) Maybe Lee in 2002? Here's what I dug up. https://phabricator.wikimedia.org/rSVN633 This revision by Lee from July 10, 2002 added the ability for users to specify a time zone offset in hours. It also added three messages: timezonetext, localtime, and timezoneoffset. Of particular note, the text for the timezonetext key reads: Enter number of hours your local time differs from server (U.S. Pacific) time. For example, for U.S. East coast, enter "3". https://phabricator.wikimedia.org/rSVN635 This revision (same author and day) reiterates that the server time is "U.S. Pacific" when establishing the dellogpagetext and uploadlogpagetext messages. https://phabricator.wikimedia.org/rSVN723 This revision by Brion from August 28, 2002 adds a first draft of Esperanto translations. I believe (I don't read and write Esperanto) that the uploadlogpagetext and dellogpagetext messages say that the server time is UTC. However, the timezonetext message appears to say that the server time is UTC-8 and that if you want to use Central European Time, you need to specify an offset of 9 hours. https://phabricator.wikimedia.org/rSVN744 This revision by Lee from September 5, 2002 changes the timezonetext, uploadlogpagetext, and dellogpagetext messages to read "UTC" instead of "U.S. Pacific". https://phabricator.wikimedia.org/rSVN773 This revision by Brion from September 18, 2002 introduces the $wgLocaltimezone configuration variable. I've updated https://www.mediawiki.org/wiki/Manual:$wgLocaltimezone to note this. Looking at early English Wikipedia contributions, <https://en.wikipedia.org/w/index.php?oldid=56697> is the oldest edit I can find of a signed comment that includes a time zone: "05:42 Jul 21, 2002 (PDT)". There are many older signatures, to be sure, and some of them in early 2002 include a date, but without a time zone. This signature seems to confirm that the time zone was U.S. Pacific time in 2002. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] garbage characters show up when fetching wikimedia api
MZMcBride wrote: >The error you're getting generally means that the JSON was malformed for >some reason. It seems unlikely that MediaWiki's api.php is outputting >invalid JSON, but I suppose it's possible. I left a note on the Phabricator task that Marius linked to: <https://phabricator.wikimedia.org/T133866#2272654>. It seems api.php end-points really are outputting garbage characters in some cases, though it remains unclear which layer is to blame. :-/ MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] garbage characters show up when fetching wikimedia api
Trung Dinh wrote:
>Hi all,
>I have an issue why trying to parse data fetched from wikipedia api.
>This is the piece of code that I am using:
>api_url = 'http://en.wikipedia.org/w/api.php'
>api_params =
>'action=query=recentchanges=5000=edit=0
>dir=newer=json=20160504022715'
>
>f = urllib2.Request(api_url, api_params)
>print ('requesting ' + api_url + '?' + api_params)
>source = urllib2.urlopen(f, None, 300).read()
>source = json.loads(source)
>
>json.loads(source) raised the following exception " Expecting ,
>delimiter: line 1 column 817105 (char 817104"
>
>I tried to use source.encode('utf-8') and some other encodings but they
>all didn't help.
>Do we have any workaround for that issue ? Thanks :)
Hi.
Weird, I can't reproduce this error. I had to import the "json" and
"urllib2" modules, but after doing so, executing the code you provided
here worked fine for me: <https://phabricator.wikimedia.org/P3009>.
You probably want to use 'https://en.wikipedia.org/w/api.php' as your
end-point (HTTPS, not HTTP).
As far as I know, JSON is always encoded as UTF-8, so you shouldn't need
to encode or decode the data explicitly.
The error you're getting generally means that the JSON was malformed for
some reason. It seems unlikely that MediaWiki's api.php is outputting
invalid JSON, but I suppose it's possible.
Since you're coding in Python, you may be interested in a framework such
as <https://github.com/alexz-enwp/wikitools>.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tool Labs and my new job at WMF
Thank you for this e-mail and for your work so far, such as redesigning the Wikitech main page. I think this new role will be a good fit for you. I left some initial thoughts on the Meta-Wiki talk page: <https://meta.wikimedia.org/wiki/Special:Permalink/15530025>. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Diff algorithms: the shootout
Max Semenik wrote: >Right now, MediaWiki has 2 pure-PHP engines to produce diffs (there's also >a native PHP extension wikidiff2, but we're not discussing it right now): >* DairikiDiff is what everybody uses, and >* Wikidiff3, and alternative implementation by Guy Van den Broeck that was >around for 8 years but required a configuration change >While less battle-tested, Wikidiff3 offers vastly improved performance on >heavy diffs compared to DairikiDiff. The price, however, is that it makes >certain shortcuts if the diff is too complex. I ran through 100K diffs >from English Wikipedia, and 6% of diffs were different. Lots of changes >were seemingly insignificant but I need your help with determining if >it's really so. Is there a related Phabricator Maniphest task about this? I'm not sure I understand the motivation for making a switch. I would think that heavy diffs are a very small portion of traffic. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The future of Related Pages feature
Moushira Elamrawy wrote: >Related pages feature has been in beta for over two months now, the >future of the feature depends on our discussions. While we currently >don't have a clear process for deciding collaboratively on an all >languages product, Alsee and the reading team have put together this >document on meta [0], as a request for comment, seeking comments and >ideas on modifications required, and how to further test the feature. In >fact, we are not sure if an rfc is the best strategy to move forward with >product decisions, but lets see how the discussion evolves, and we might >explore the need for a different process, as we move on with this one. I have pretty grave concerns about the deployment of the RelatedArticles extension to Wikimedia wikis. It's my sense that RelatedArticles is similar to UserProfile and Gather: there's a kernel of a good idea, but the implementation is so problematic that pressing ahead with it will result in doing more harm than good. Already German Wikipedians are planning a Meinungsbilder, which is reminiscent of the MediaViewer debacle. On Meta-Wiki, there's an acknowledgement that this extension was deployed without any Wikimedia community asking for it. At its worse, the "related articles" feature reminds the viewer of the pseudo-content spam that's curerntly infesting parts of the Web (e.g., "Do These 7 Things or You'll Get Alzheimer's"; screenshot: <https://i.imgur.com/tYcdrLk.png>). In short, there's a lot of bad juju here. My recommendation is to disable this extension. There are two related functionalities that editors would like to have: * the ability to retrieve the page image of article "White House" from the article "Barack Obama", probably using a parser function; and * the ability to specify the page image of the article "White House" if the heuristic is wrong and an override is needed. I'm not sure where we stand on these two features currently. Having the ability to retrieve an arbitrary page image and specify an arbitrary page image will empower editors. This is preferable to indiscriminately slapping three sometimes irrelevant photos and article links on every page. Part of what makes Wikimedia wikis great is that we exercise editorial control. We're not serving up unprocessed machine output, we're curating content, which for now results in a much better product. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ArchCom RFC update
Thank you for these RFC update e-mails. I enjoy reading them! Gabriel Wicke wrote: >T16950: Support global preferences ><https://phabricator.wikimedia.org/T16950>: "It would be nice if users and >developers could designate certain preferences to automatically apply >across all wikis. This will require A Lot of Work™. >Extension:GlobalPreferences is a rough draft of the functionality." > Leaving in inbox, RobLa will ask Kunal. I'm not sure why this task is seemingly so difficult. Is it "just" the user interface portion or are there other complicated pieces? MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Reducing the environmental impact of the Wikimedia movement
Lukas Mezger wrote: >I am a member of the Wikipedia community and I have started a project to >reduce the environmental impact of the Wikimedia movement ><https://meta.wikimedia.org/wiki/Environmental_impact>. The main idea is >to use renewable energy for running the Wikimedia servers and the main >reason for this is that by doing so, Wikipedia can set a great example >for environmental responsibility in the entire internet sector. This issue has been discussed previously. I would recommend trawling through the mailing list archives to find older discussions. A somewhat cynical reply from May 2009: <https://lists.wikimedia.org/pipermail/foundation-l/2009-May/051656.html>. I can't find the rest of that thread off-hand, but surely it's somewhere. >In order to further advance the project, I would like to learn more about >how much energy Wikipedia's servers use. As far as I can tell, these >figures are not public, but I believe they could very well be. There's been a greater push for transparency in the past few months. I think what you want here from the Wikimedia operations team is a full index of the particular hardware that's in use in the various data centers. That would allow you or others to take this list of hardware and research its energy use. Most of the hardware is off-the-shelf from Dell and other companies, I believe, so information about its specifications, including energy use, is likely already public. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [BREAKING CHANGE] Legacy wikibits will no longer loaded by default on Wikimedia wikis and MediaWiki 1.27
Krinkle wrote: >However I do want to emphasise that for importScript in particular, there >is no rush. If we need to keep an alias around indefinitely on most larger >wiki's Common.js, that seems fine. Same for addOnloadHook (though that one >is significantly easier to update). > >The main thing we're trying to clean up here is the dozens of legacy >global functions and variables that are largely unused. Such as >'clientPC', 'ie6_bugs', 'escapeQuotesHTML', 'killEvt' etc. And the >negative performance impact of having to load it before all other modules. I don't understand this. If your main goal is to remove unused and unneeded legacy global variables and functions, and your examples such as 'ie6_bugs' and 'clientPC' seem like fine kill targets to me, why not just remove that code and leave used/useful code like 'importScript'? I'm somewhat reminded of the minimum supported PHP version discussion and the remark about supporting software that can run on our own servers. While this is not directly analogous, if we're going to put a bunch of shims in place on "large" Wikimedia wikis, why not just keep supporting 'importScript' in wikibits? We can move the code to a more modern location in MediaWiki core, if desired. If Wikimedia wikis are largely unable to do this full migration to updated syntax, it seems pretty unreasonable to expect every other MediaWiki installation to essentially copy and paste some snippet into their "MediaWiki:Common.js" page when updating MediaWiki to 1.28 in order to keep useful functions like 'importScript' working. You note that there's no rush, so why make this extra work for everyone? Can we just kill the largely unused portions of wikibits for now and wait till usage of the other code is acceptably low enough to properly remove? Or could we just have 'importScript' indefinitely be an alias for 'mw.loader.load', etc.? MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Per-language URLs for multilingual wikis (RFC T114662)
Daniel Kinzler wrote: >During next Wednesday's RFC meeting on IRC, we are planning to discuss >introducing "Per-language URLs for pages of multilingual wikis". This is >an exploratory discussion, with no expectation of a final decision. We >are looking for concerns and suggestions. > >If you care about improved support for multi-lingual wikis, please visit ><https://phabricator.wikimedia.org/T114662> and comment before next week's >"live" meeting on IRC. And of yourse, join that meeting, if you like! As I said on the Phabricator task, before we extend our URL specifications, I'd like us to explicitly define them. I think it's time. * Maybe we no longer want /wiki/ in the URL for regular views. * For the two cited examples, commons.wikimedia.org and wikidata.org, maybe we want to move the former to its own domain (e.g., wikicommons.org) and change the latter to load from en.wikidata.org, fr.wikidata.org, etc. I think outside users and developers don't want to learn the intricacies of why some URLs end in "en" and some start with "en". I think most people just want a repeatable procedure for determining what URL they can hit and what to expect from it. In the process of defining our URL schemes, we can probably make our resource locators a bit more uniform, or at least document what we would like to eventually achieve. For the Architecture Committee in particular, I think giving some renewed focus to our information architecture is reasonable and prudent. (I know Brion and Gabriel have both worked on this previously.) MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Update from the Wikimedia Performance Team
Federico Leva (Nemo) wrote: >Login pretty much never does what I expect nowadays, but I'm not sure my >expectations are correct so I can't identify actual bugs. There are various open tasks in Phabricator about user sessions currently, such as <https://phabricator.wikimedia.org/T124440>. Being unexpectedly logged out lately has been a bit annoying, though I don't know if it's related to the Performance team or some other team. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Using assignees for RFC shepherd
Rob Lanphier wrote: >In the ArchCom meeting earlier today, Daniel, Timo, Tim and I discussed >the way we handle RFC assignments in Phabricator. Previously, the RFC >would frequently be assigned to person writing the RFC. As we try out >the Rust model (per T123606 <https://phabricator.wikimedia.org/T123606>), >and as we try to increase the speed by which RFCs move though the >process, we thought it would make sense to also assign RFCs to shepherds >on the ArchCom. > >We didn't discuss all of the implications of this in the meeting today, >but we think this might help us scale our RFC triage process. What do >you all think? I guess <https://www.mediawiki.org/wiki/Requests_for_comment/Governance> tries to answer the question "what's a shepherd?" --- * Nominate a shepherd from a (sub)team to guide an RFC through the process. ** Makes sure that stakeholders are informed. ** Guides the discussion. ** Once the discussion plateaus or stalls & in coordination with the RFC author(s), announces and widely publicizes a "Final Comment Period", which is one week. --- I'm still not really sure what any of this means. The biggest focus seems to be on speed and throughput for the RFC process itself, when the focus should actually be code quality, sustainability, and overall architecture. I found the recent RFC discussion about adding an expiration field to the watchlist table to be very disappointing. My impression was that people were more concerned with quickly pushing through a new feature (with unknown user interface implications) than with solving the deeper underlying problems we have with page lists. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Data visualization for wiki
Ivo Kruusamägi wrote: >What I'd like to see is some development, that would make it possible for >user to create visualizations inside MediaWiki. Something so easy that a >child could do that. Like this <https://infogr.am/>. Workflow example: 1) >user selects sth like Create Data Visualization, 2) has some selections >about cart type, colors, etc, 3) place to write down text (title, axes, >description) and 4) a table to fill in with data (values + their text >labels). That could then be saved as one revision. After that every other >user could edit this graph with the same selections and data tables just >like users edit articles and edit history is saved and easy to compare. > >Image files like this ><https://et.wikipedia.org/wiki/Pilt:VikiArtiklitearv.jpg> or that ><https://commons.wikimedia.org/wiki/File:Tree_map_exports_2010_Estonia.svg > are ridiculous and fixes like that ><https://en.wikipedia.org/wiki/Template:Pie_chart> are not that flexible, >pretty and easy to use as what we need. So lets move forward. Are you familiar with the "Graph" MediaWiki extension? Here's a demo: <https://www.mediawiki.org/wiki/Extension:Graph/Demo>. This MediaWiki extension is deployed to Wikimedia wikis, including all the Wikipedias. >There are plenty of GPL licensed solutions that could be integrated with >MediaWiki. But I can't be only one thinking about this. You're not. :-) >So what should I know about that topic so that this work could really be >useful? I.e. how to avoid reinventing the wheel (like building something >already in development) and how to be sure that it could be easily >incorporated later? Who would be the perfect people to talk about this >topic? This mailing list is great for general discussion. Or we have a Phabricator installation at <https://phabricator.wikimedia.org/> where we track bugs and feature requests. You can search around for Phabricator Maniphest task related to vectorized and rasterized image editors, such as <https://phabricator.wikimedia.org/T39732>. You're welcome to discuss on those tasks. Integrating a decent SVG editor and a decent PNG/JPG/GIF editor would be amazing! >P.S: I also have some development plans for a web platform that will help >to gamify organizing media files in Wikimedia Commons (coordinates, >categories, descriptions, quality assessment, etc). Sort like adding an >additional data layer and when everything works fine then migrating that >information into Commons. Any great ideas there as well? (not so great >ideas could be sent to list :P ) Sure. Maybe poke around <https://tools.wmflabs.org/wikidata-game/> if you haven't already? It sounds similar to what you want to do. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New [[Main Page]] for Wikitech
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 Very nice! Thank you for doing this. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] meta: AbuseFilter on mediawiki.org and related sites
Amir E. Aharoni wrote: >At least twice I found AbuseFilters that prevented people from testing >extensions that I develop or posting feedback about them on MediaWiki.org >and the beta testing sites (such as >http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page ). > >[...] > >One of them filtered out the whole Russian alphabet, so the extension >couldn't be tested by Russian-speaking users. Another one didn't allow >submitting Flow posts that don't have a sufficient amount of English words >from users who have less than 6 edits, so users who have a lot of edits in >their home wikis, but no edits in mediawiki.org, and who want to post in >languages other than English are blocked. Luckily, one of those people >pinged me directly, but I don't know how much useful feedback was filtered >out and lost. I have also had issues with AbuseFilter filter false positives on mediawiki.org. My approach has been to disable the problematic filters immediately and leave an explanatory note at <https://www.mediawiki.org/wiki/Project_talk:AbuseFilter>. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia dumps
Bartosz Dziewoński wrote: >On 2016-01-11 22:06, gnosygnu wrote: >> So, to answer your question, the IDs never change. 14640471 will always >> point to Mars, while 699008434 points to the 2016-01-09 revision for >>Mars. > >While it's unlikely/rare, I think the page id can change when a page is >deleted and re-created, and maybe some other cases. MediaWiki tries to >keep it constant (for example, I think it's preserved after deletion and >undeletion), but it's not always possible. It looks like <https://phabricator.wikimedia.org/T28123> was just fixed, so page IDs changing should now hopefully be rarer. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mediawiki message delivery problems
Purodha Blissenbach wrote:
>the point is do the writers know that?
>Seems not all. Who tells them?
Hi.
People sending messages to hundreds or thousands of users, potentially
across hundreds of Wikimedia wikis, ought to be familiar with standard
practices such as signing posts with a regular timestamp. If users are
unfamiliar with these practices, they probably should not be using the
MassMessage tool. Or, at minimum, they should be carefully reading the
user documentation, as instructed. :-)
I replied at <https://phabricator.wikimedia.org/T121209#1876778>.
Andre Klapper wrote:
>Currently the actual creator is added as a (HTML source code) comment
>(your link to the diff shows "User:Matiia@metawiki"). It's not too
>obvious and I'd also prefer real user names, for accountability.
I think you're referring to <https://phabricator.wikimedia.org/T71954>
("Add support to MassMessage to allow using the sender's username for
deliveries")?
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Ifexists across wikis
Bartosz Dziewoński wrote: >It's also why #ifexist is expensive: it needs a separate database query >for each time it's used, to check for a single page, because it's >impossible to determine the list of pages to check in advance. I'm not sure I understand the impossibility here. When the expensive parser function count feature was added, I remember this issue being discussed and my memory is that it seemed possible to batch the ifexist lookups in a similar way to how we batch regular internal link lookups against the pagelinks table, but nobody was interested in implementing it at the time. If the wikitext is parsed/evaluated on page save, I don't see why ifexist lookups would be impossible to batch. We're already using the pagelinks table for the ifexist functionality to properly work, as I understand it (cf. <https://phabricator.wikimedia.org/T14019>). MZMcBride ___ 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
Ricordisamoa wrote: >The PHP development team announces ><http://php.net/archive/2015.php#id2015-12-03-1> the immediate >availability of PHP 7.0.0. >The newphp <https://phabricator.wikimedia.org/tag/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
Re: [Wikitech-l] Ending RFC review meetings a little early
From the link: > But there’s the alternative setting called “Speedy Meetings”, here’s >what it does: > > * Encourage meeting efficiency and get to your next meeting on time. > * 30 minute meetings end 5 minutes early, 1 hour and longer meetings end > 10 minutes early. Rob Lanphier wrote: >Sowhy not? Is there any opposition to us ending RFC meetings 5-10 >minutes early? Requests for comments used to be 30 minutes (two in an hour), but the trend lately seems to have shifted toward one per hour. I would hope that most people aren't paying attention to the meeting time length. RFCs vary widely in scope and complexity, so I think it makes sense to hold a meeting (or multiple meetings) as often as is appropriate and necessary for the specific RFC. If you think a topic can be discussed in a time slot smaller than 60 minutes, schedule it for that. This is to say, I can't imagine anyone cares what your Google Calendar settings are, but I do think people shouldn't let themselves or their thoughts be cut off by arbitrary time limits. The start and end to the "formal" discussion can be decided by the person operating that silly bot. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Pageview API
Dan Andreescu wrote:
>The API can tell you how many times a wiki article or project is viewed
>over a certain period. You can break that down by views from web crawlers
>or humans, and by desktop, mobile site, or mobile app. And you can find
>the 1000 most viewed articles
><https://wikimedia.org/api/rest_v1/metrics/pageviews/top/es.wikipedia/all-
>access/2015/11/11>
>on any project, on any given day or month that we have data for. We
>currently have data back through October and we will be able to go back to
>May 2015 when the loading jobs are all done.
This looks very promising. Congratulations to all on getting this launched!
I hit a bug involving gzip compression and HTTP headers that was quickly
fixed (<https://phabricator.wikimedia.org/T118817>). Now that I'm
lightly poking at the API's data, the "Paul_Elio" article on the English
Wikipedia allegedly received 4,832,338 views on 2015-11-16, according to
<https://phabricator.wikimedia.org/P2325>. This anomaly and a few others
make me a bit wary about the accuracy of this data. That said, a lot of
the results look about right and are easily explained ("Charlie_Sheen" and
"November_2015_Paris_attacks" are easy examples).
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Pageview API
Krinkle wrote: >The only hurdle I found is that the 'articles' property is itself >nested/double encoded JSON, instead of a plain object. This was somewhat >unexpected and makes the API harder to use. I filed <https://phabricator.wikimedia.org/T118931> about this. MZMcBride wrote: >Now that I'm lightly poking at the API's data, the "Paul_Elio" article on >the English Wikipedia allegedly received 4,832,338 views on 2015-11-16, >according to <https://phabricator.wikimedia.org/P2325>. I decided that the numbers for this page are strange enough to warrant an investigatory task: <https://phabricator.wikimedia.org/T118933>. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Update about on-going work on Notifications, especially cross-wiki notifications
Pine W wrote: >The hypothetical here is that I have a binary choice between Echo and >Flow. In practice it's possible to develop them in parallel. With the >hypothetical in mind, I'll outline why I would prioritize Echo. > >My thinking is that Echo is used widely on many, many wikis and is helpful >to users of all skill levels. It must be years since I've heard someone >say that they find the nature of Echo to be problematic. By contrast, the >reception to Flow is more mixed. Also, as some of us are discussing with >Lila, it may be feasible to extend VE to talk pages and/or give some love >to the wikimarkup editor at less expense and with less disruption than the >expense and disruption involved with converting talk pages to Flow pages. > >[...] > > Flow has its supporters and I think that keeping it maintained and >healthy on wikis where the communities like it is probably wise. Given >the choice of investing more resources into further development of a >product that has mixed reviews, is used on only some wikis, and about >which community questions aren't answered, seems questionable to me when >investing in a well-accepted and widely-used tool (Echo) is an >alternative. Hi. Thank you for your reply. To me, it highlights and confirms a number of troubling trends and a few misconceptions that I think really need to be openly discussed and ultimately addressed. However, wikitech-l isn't the most appropriate discussion venue for this, so I'll move to wikimedia-l. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Update about on-going work on Notifications, especially cross-wiki notifications
Pine W wrote: >Agreed. If I had a binary choice between investing in Echo and investing >in Flow, I would be inclined to choose Echo. Can you please elaborate on why you would prioritize Echo over Flow? The Wikimedia Foundation has made the same decision and it's mind-boggling to me. I'd really like some greater insight into the thought process here. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Git for idiots
S Page wrote: >I would urge people to judiciously update the pages we have, and only >create very targeted new pages rather than yet another starting point. For sure. It might also make sense to investigate placing some of the more in-depth Git tutorial content on a project other than mediawiki.org such as Wikibooks. Wikibooks already has programming language guides, so adding version control system guides seems like a potentially nice complement. Ideally the documentation on mediawiki.org would focus more on contributing to MediaWiki (or Wikimedia code repositories). >https://www.mediawiki.org/wiki/Gerrit/Getting_started seems OK, it's >focused on a new gerrit contributor. I submit changesets to Gerrit infrequently enough that I still refer to this page. I've really enjoyed reading this thread and the links within it. A few people have told me that the "Git For Ages 4 And Up" video is decent (<https://www.youtube.com/watch?v=1ffBJ4sVUb4>), if anyone is interested in a non-textual Git guide. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Random rant
Ricordisamoa wrote: >ALL of my OAuth applications expired without anyone noticing. Whom am I >supposed to lobby to get one approved? Hi. This rant doesn't seem very random. :-) This sounds like <https://phabricator.wikimedia.org/T67750> (you're already subscribed). Also <https://phabricator.wikimedia.org/T61772> and <https://phabricator.wikimedia.org/T103587>. I don't really understand why an approvals process exists. When I asked in 2014, the answer was "we weren't sure how it was going to be used, and what way we would need to extend the protocol." It's been over a year and I still don't really know what that means. That same note indicated a willingness to fully re-examine the OAuth workflow, so given that it's now late 2015, here are the options I see, in order of preference: * kill the approvals queue altogether; * distribute the approvals process to the Wikimedia stewards; * distribute the approvals process to additional Wikimedia Foundation employees; or * keep the status quo. It's difficult for me to figure out how realistic option 1 (killing the queue) is because I continue to have an incomplete understanding of OAuth and specifically why an approvals process was ever put into place. Given that several Wikimedians have complained about the speed of the approvals process, it seems like option 4 (keeping the current situation) is a no-go. That leaves us with options 2 and 3 (expanding the pool of approvers) as the most straightforward choices. Even if we implemented options 2 or 3 immediately, the lack of external visibility into the queue and the lack of notifications for queue submissions would very likely also need to be addressed. Option 1 would obviate the need for such additional features, of course. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Audit of inline styling in the main namespace of the English Wikipedia
Robert Rohde wrote: >Which, after substituting "display:none;" I think translates directly to >the regex search: > >insource:/style[ ]*=[ ]*\"display:[ ]*none;[ ]*\"/i > >That gives me 487 articles. Almost, but not quite. You actually want this: insource:/style[ ]*=[ ]*\"display:[ ]*none;?[ ]*\"/i With the semicolon being made optional, the search results increase from 487 to 2,487 currently on the English Wikipedia. The normalization script (<https://phabricator.wikimedia.org/P2229>) made the trailing semicolon consistent, in addition to lowercasing and trying to account for strange spacing. For whatever reason, "display: none;" is often written without the trailing semicolon in main namespace pages on the English Wikipedia. I was worried that I may have made a major coding mistake, so I re-ran my script using this pattern: pattern = r'style[ ]*=[ ]*"[ ]*display[ ]*:[ ]*none[ ]*;?[ ]*"' The results are available here: <https://phabricator.wikimedia.org/P2255>. Sixteen articles have over 1,000 instances of "display: none;" each! The total is 142,176 instances of "display: none;" (normalized) in 2,507 main namespace pages on the English Wikipedia, as of about 2015-10-02. >I am happy to agree that searching the XML should be better than the local >search tool, but I still find these numbers hard to reconcile. After re-reviewing the code and re-running the script to focus on "display: none;" specifically, there's strong evidence to suggest that the numbers are accurate, if not a bit surprising in some cases. :-) MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Audit of inline styling in the main namespace of the English Wikipedia
Robert Rohde wrote:
>On Mon, Oct 26, 2015 at 2:13 AM, MZMcBride <z...@mzmcbride.com> wrote:
>>The following are the top ten instances of inline styling from main
>>namespace pages on the English Wikipedia, as of about 2015-10-02:
>>
>>1552197 text-align: center;
>>499756 text-align: left;
>>355952 background: #dfffdf;
>>235222 background: #cfcfff;
>>215038 background: #efcfff;
>>210702 text-align: right;
>>143095 display: none;
>>93646 background: #efefef;
>>86391 font-size: 90%;
>>80420 background: #fff;
>
>I'm not sure what your bug is, but those counts are way too high to be
>accurate reflections of the wikitext in the main namespace on enwiki.
Err, based on what? :-)
These numbers are instances of style="[...]", not page counts. Looking at
a specific example from <https://phabricator.wikimedia.org/P2230>:
1164 font-family: 'microsoft yi baiti', 'noto sans yi', nsimsun-18030,
simsun-18030, 'sil yi', code2000;
These 1,164 inline styling instances all come from a single article:
<https://en.wikipedia.org/w/index.php?oldid=672244691=edit>.
Maybe that's the confusion? I tried to make my descriptions as clear as
possible and I'm not saying a major bug is impossible, of course, but I
don't have any reason so far to doubt the data I collected.
Another strange case is "background-color: {{/meta/color}};", which had
16,432 instances. This almost looks like it would try to transclude a
subpage of the article, but due to subpages being disabled in the main
namespace on the English Wikipedia, it's actually transcluding a template
named "/meta/color": <https://en.wikipedia.org/wiki/Template:/meta/color>.
I did concurrently look at the approximate number of non-redirect pages
that contain inline styling. My findings were that about 408,777
non-redirect pages contain some kind of inline styling on the English
Wikipedia (cf. <https://phabricator.wikimedia.org/T115228#1752223>).
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Audit of inline styling in the main namespace of the English Wikipedia
Daniel Friesen wrote: >Perhaps some deeper segregation of those stats would be useful. ie: >Separate the numbers of styles used between templates and pages. > >Then we might have a better idea of what kind of patterns are being used >directly in pages that should actually be moved to templates or >stylesheets. This reply confused me a little. The script I ran exclusively looked at pages in the main namespace and exclusively looked at an XML dump, which is unexpanded wikitext. That is, assuming people aren't doing a lot of inline styling as arguments/parameters to templates, we should already have a decent amount of segregation as I only looked at direct uses. Looking at the template namespace or looking at pages post-expansion would be annoying. I think templates aren't necessarily a bad place for inline styling, so I'm a lot less focused on templates than I am on articles. Vi to wrote: >Do you have a old dump to check whatever the ratio has increased? I'm personally not very interested in doing this, but using a similar dump from <https://dumps.wikimedia.org/> and following the instructions laid out in <https://phabricator.wikimedia.org/T115228> should make this fairly easy to do, if anyone is interested. I tried to methodically document all of the relevant source code and commands that I used, so that this same audit or an audit on another project or dump would be less work. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
