Talk:Admin tools development

Volunteering: Jack Phoenix

I'm not overly familiar with what a Project Manager does, nor with the AbuseFilter extension or git, but this is definitely an area where I'd like to help out! I've worked on some anti-spam/anti-vandalism extensions (ProtectSite, SpamRegex, regexBlock and Phalanx, to name a few) before and I know from experience that this area of MediaWiki is in need of love.
MediaWiki needs to have some sort of anti-spam mechanism in core, and this would also give me a nice excuse to clean up Phalanx and release it. Let me know if I can be of use. --Jack Phoenix _(Contact) 12:42, 27 July 2012 (UTC)

Hi Jack, we're in the process of defining what exactly we want this person to do, and how particular we want to be about choosing someone to do this. The biggest reason to be particular is because we want someone who can say, with some level of authority, "issue A is more important than issue B" given any particular issue A and B that affects admins. Since there's likely to be disagreement on this, I think it'll be important to deputize one person for this role as the tiebreaker.

Anyway, if you've got a little time to help out now, the most pressing issue is probably finding all of the bugs that fall into this category, and linking them up with the list we created (adding new items as appropriate). If there's any high priority items, ping us directly in email or on wiki. Thanks! -- RobLa-WMF (talk) 19:31, 30 July 2012 (UTC)

Well, if that's what you're after, Jack Phoenix would indeed probably be quite helpful if you'll give him a chance, being both a wiki admin on several projects as well as our favourite resident dev some vague place I can't mention... and he's here. That helps. Right? -— Isarra ༆ 21:09, 30 July 2012 (UTC)

Let me be clear here....we're not presupposing a candidate, and from what I've seen, I think Jack would be awesome. I just don't want to presume that Jack is going to be the only person to come forward, and I want to make sure process is not "Jack just happened to notice the wiki page at the right time and responded first". But, we can deputize Jack for a short period (say the next 2 months), and then work out a process for how we want to do this moving forward. This is really a very nascent idea to even do anything like this, so we don't have a lot of the details sorted out. Does that make sense? -- RobLa-WMF (talk) 21:49, 30 July 2012 (UTC)

Being first to edit or speak definitely shouldn't be a criteria for anything! Like I said to Chris earlier on when we spoke about admin tools, the current status of things and how they should be improved, project management definitely isn't my speciality, but I'm always willing to learn new and useful skills.
I'm just hoping that we can get the ball rolling and stuff done sooner than later; we can wait, but it doesn't mean that we should, because I'm sure that the spambots wait for no-one.
All that being said, this is just something that I know pretty well and hence why I want to be a part of this project and the team.

Protecting MediaWikis everywhere — not just the WMF sites — against automated spam and vandalism benefits everyone, both in the long and short run. Not too many weeks ago I saw a MediaWiki site, which was on a legitimate domain (the main site was about sustainability and green ideas, if I recall correctly), but since it was openly editable, running an older version of MediaWiki and had no extensions installed, and the owner/admin was inactive, it had been turned into a spam relay that was being spammed on.
That is bad for everyone involved.

I want editors to be able to focus on editing — content creation, tweaking, fine-tuning... — instead of having to play whack-a-mole against spambots and vandals all the time. I have plenty of experience in playing whack-a-spambot, and I'm hoping to use that experience to improve WMF sites and also third-party sites (because really, core has to have some anti-spam mechanisms; plenty of third-party users are somewhat reluctant to look into all the (anti-spam) extensions and install them). --Jack Phoenix _(Contact) 22:29, 31 July 2012 (UTC)

Quick Cleanup:PHPmyadmin

How about just knowing which wiki tables to access to delete all the spam from the inside. I see that even when I delete it, there is a link to restore it. I want it gone, not taking up disk space. —The preceding unsigned comment was added by Debilee (talk • contribs) 

This is not the correct place for support discussions, this is the place to discuss the admin tools development work and related issues. You were probably looking for the Project:Support desk page.

And to answer your question, it's the best to use the wiki interface for deleting spam. --Jack Phoenix _(Contact) 21:55, 3 September 2012 (UTC)

ConfirmEdit development

I see that there is some ConfirmEdit development happening but code review is a little stalled. Jack Phoenix, maybe you could reach out to some of the developers who are writing those commits, and see if a few of them would like to request Gerrit project ownership, so they could merge code? Thanks. Sumana Harihareswara, Engineering Community Manager (talk) 06:24, 2 September 2012 (UTC)

Seven open commits, of which one has no reviews, two have +1 and the rest have -1. I'll try to poke the appropriate people (committers and reviewers of those commits) to get something done to those during this or the next week; feel free to poke me if it appears that I've seemingly forgotten about it. Though I must note that I wouldn't exactly be surprised if we decided to get rid of the CAPTCHA thing in its current form in the long run — because it's a huge usability issue and no longer effective at keeping spambots at the bay. --Jack Phoenix _(Contact) 21:55, 3 September 2012 (UTC)

Requests for comment/Itemise protection

Is Requests for comment/Itemise protection relevant? --MZMcBride (talk) 09:13, 13 September 2012 (UTC)

I doubt so: this seems to be mostly about cross-wiki issues and in particular mass spam/vandalism prevention; that's just a usability problem. --Nemo 10:20, 13 September 2012 (UTC)

Toolserver termination

As noted by Andre Koopal, stewards and admins rely heavily on Toolserver tools for a variety of tasks. As the Toolserver is being terminated soon (2013? 2014?) and there's no other home in the works for those tools as they are, a whole stack of features may suddenly be lacking. --Nemo 08:33, 29 September 2012 (UTC)

Is Labs another option? I can't speak for the developers, but it would be a great opportunity to replace the tools with on-wiki tools, though that's definitely time-consuming.--Jasper Deng (talk) 20:32, 29 September 2012 (UTC)

It's not clear. See m:Future of Toolserver and Wikimedia Labs/Toolserver features wanted in Tool Labs. --Nemo 20:35, 29 September 2012 (UTC)

It looks like this is being dealt with by the labs 'webtools' project: labsconsole:Nova Resource:Webtools and bugzilla:40519. --Krenair ^{(talk • contribs)} 20:36, 29 September 2012 (UTC)

Yep. Platonides asked for this project to be created for this purpose. If anyone is interested in helping make the transition smoother by helping out, please do!--Ryan lane (talk) 20:47, 29 September 2012 (UTC)

Nemo, I really don't understand what you are reading in these discussions. Labs is the slated replacement for Toolserver, according to WMDE. WMDE has also said they will continue to keep Toolserver operational until Labs is suitably fit to replace it. If you're going to summarize a discussion, please don't do it in a way that provides misinformation to everyone else.--Ryan lane (talk) 20:45, 29 September 2012 (UTC)

Of course summaries are always dangerous. (For instance, I've never read anything suggesting that «they will continue to keep Toolserver operational until Labs is suitably fit to replace it».) The good news is that Meta is a wiki and everyone can edit the page there. --Nemo 21:09, 29 September 2012 (UTC)

Ability to block referring IP on XFF

Tracked in Phabricator
Task T25343

Can I ask that we look to give a higher priority to the ability to block incoming spam and vandalism where the incoming IP is identified as being XFF as the means of this abuse. There is an increasing prevalence of spammers and vandals utilising the XFF process to attack wikis, having seemingly researched and lined up the open proxies that they have selected for their joyride. The only defence is to reactively block each abused proxy which is clearly reactive, and most frustrating. While there may be scope to forge these headers, the inability to be able to do anything about this present danger which is being abused and pretty well flouted is quite problematic. — billinghurst sDrewth 13:34, 25 November 2012 (UTC)

Abusefilter filters

AbuseFilter just isn't that useful without them. Unfortunately projects such as enwp that have the best filters also tend to be pretty protective with them, especially since if they were made public that would be apt to make them less effective.

Given that making such things public has that effect and that it takes considerable time for a third-party wiki admin to convince an enwp admin that indeed they can be trusted with given filters, is there any good way to make that sort of thing available at all, or do we all just need to come up with out own, effectively reinventing the wheel on every disparate small project using abusefilter? -— Isarra ༆ 01:43, 2 December 2012 (UTC)

What proof is there that there are so many useful private filters around? I've mostly see overuse of filters import.

Also, if someone was going to reverse engineer or reinvent the en.wiki filters for inclusion in AbuseFilter, what would the point for en.wiki to still keep them private? --Nemo 21:35, 2 December 2012 (UTC)

Many filters I have needed were private - an admin had to export them for me so I could use them. I'm not necessarily saying the things should be included with abusefilter, but it is an issue with the nature of these things and perhaps someone might have a better idea what would be a viable means to make things easier for third-party wiki admins. -— Isarra ༆ 23:26, 2 December 2012 (UTC)

I agree that it's important that wikis share abuse filters; the forthcoming global AbuseFilter software will allow our community to create great filters (informed by work on the English Wikipedia, the German Wikipedia, and dozens of other wikis that successfully use these) that will apply to all wikis. Jdforrester (WMF) (talk) 16:34, 3 December 2012 (UTC)

Well, that's excellent for Wikimedia projects, at least. How will these apply across languages, though, since so many of them are linguistically-specific, and also by scope of the project? What might be fine on wikivoyage would, perhaps, be unequivocally spam anywhere else, for instance... -— Isarra ༆ 19:56, 3 December 2012 (UTC)

Sure. This page is about co-ordination of WMF work on Wikimedia cluster admin tools, hence the scope of my comments. :-)

I agree that there are local considerations for global systems, so in general the global ones will have to be limited. This is exactly the way the global spam blacklist, title blacklist etc. are used in moderation alongside stronger local-specific rules.

Back to your comment, I agree that the idea of bundling some 'default' abuse filters has significant merit. Propose them in gerrit? :-) Jdforrester (WMF) (talk) 20:07, 3 December 2012 (UTC)

Mmm, for some reason I got the idea at some point that this was as much about mw core as Wikimedia... and since that is something that would be needed as well, is there another such project for developing administration tools for in general?

As for specific filters worth bundling, nevermind that I wouldn't have the foggiest inkling how to propose anything in gerrit, I really couldn't say anything specific anymore - my last dealing with the things was over a year ago, and my memory isn't so good. Things stopping common spam and vandalism tactics certainly wouldn't go amiss, but this would be something worth poking someone currently active with the buggers over. -— Isarra ༆ 02:04, 7 December 2012 (UTC)

There's totally stuff that we'd want to fix or alter in MW core that's in scope of this work - for example, the ability to block a user - but it's informed by the Wikimedia cluster's users' needs, and that's what we're mostly looking at. As a community, our support for third-party users of MediaWiki is often patchy, I'm afraid. Will follow-up with Chris to consider if there are some useful 'default' features we could look at bundling. Jdforrester (WMF) (talk) 19:46, 7 December 2012 (UTC)

Thanks, man. Though obviously Wikimedia projects should come first, other users do merit consideration if only for the fact that mediawiki is in many cases not just the best free option available, but at times the only one that would even really work. -— Isarra ༆ 01:01, 8 December 2012 (UTC)

And something about spam and some sort of civic duty, except using better words. -— Isarra ༆ 01:02, 8 December 2012 (UTC)

Or, to put it another way, if MW doesn't ship out-of-the-box with anti-spam measures, it's essentially not fit-for-purpose. Totally agreed. Jdforrester (WMF) (talk) 01:09, 8 December 2012 (UTC)

comment from monthly report

As you can see in this comment one user says:

“Continuing work on identifying accounts that have not been merged with Single User Login, with the goal of merging those accounts starting in April.”

Merging those accounts ? Depending on how it is done, this can be bad news or good news. Currently, the merging of accounts ingores the preferences. I refuse the merging of my accounts if such merging fails to take my prefs into the newly merged account. A contrario, if the merging takes the prefs I have set and has them applied and unified on all wikis, this would be great !

Thank you.

Any response? Sharihareswara (WMF) (talk) 03:40, 9 April 2013 (UTC)

When we said "merging" we meant that the local accounts on different wikis with the same name will turn into a single, global account, if they're all from the same person. We don't currently have plans to create a tool that would merge accounts together. On the point about global preferences, there similarly aren't any current plans for providing these (beyond the shared account name, e-mail and password that global accounts have). Jdforrester (WMF) (talk) 00:24, 10 April 2013 (UTC)

The common term for that around here is Account Unification. Peachey88 (talk) 05:50, 10 April 2013 (UTC)

Indeed. It would have helped if the writer had used the normal terminology. :-) Jdforrester (WMF) (talk) 15:49, 10 April 2013 (UTC)

Volunteering: Steven Zhang

Hi all. I read the WMF blog post about this project and think I could be of assistance here. While I am not a sysop on a WMF site, I believe I am familiar enough with the toolset and MediWiki in general. If I can be of assistance, please get in touch with me. Steven Zhang (talk) 17:44, 1 May 2013 (UTC)