From Meta, a Wikimedia project coordination wiki
(Redirected from Babel)
Jump to: navigation, search
 ← Index of discussion pages Babel archives (latest) →
This is the general discussion forum for Meta (this wiki). Before you post a new comment please note the following:
  • You can comment here in any language.
  • This forum is primarily for discussion of Meta policies and guidelines, and other matters that affect more than one page of the wiki.
  • If your comment only relates to a single page, please post it on the corresponding discussion page (if necessary, you can provide a link and short description here).
  • For notices and discussions related to multilingualism and translation, see Meta:Babylon and its discussion page.
  • For information about how to indicate your language abilities on your user page ("Babel templates"), see User language.
  • To discuss Wikimedia in general, please use the Wikimedia Forum.
  • Consider whether your question or comment would be better addressed at one of the major Wikimedia "content projects" instead of here.
Wikimedia Meta-Wiki
This box: view · talk · edit
Filing cabinet icon.svg
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose oldest comment is older than 30 days.

Know about a bot to sign unsigned posts?[edit]

Hi. I find it tiresome to fix threads with no signature, something that needs to be done in order for the archive bots to do their tasks. Does somebody know a bot operator who runs this task elsewhere and is willing to do so here as well? Regards, —MarcoAurelio (talk) 11:09, 21 January 2018 (UTC)

I know en:User:SineBot from enwiki that signs unsigned comments. But I don't like when it signs vandalism edits as well. And then reverting them is harder. On Finnish Wikipedia we have an abuse filter that warns users if they forget to add a signature. Stryn (talk) 11:40, 21 January 2018 (UTC)
I haven't though on the vandalism side. Maybe an abusefilter to warn editors could be enough, I don't know. —MarcoAurelio (talk) 21:21, 10 February 2018 (UTC)

Restoring global abuse filter editor group[edit]

This came up in this discussion. Basically there are a few of us who feel we could benefit from being able to edit filters across all wikis, including global filers here on Meta. Currently the only option is applying for stewardship, and I'm not sure that filter management alone would warrant such a promotion.

For me, my interest exceeds no more than helping out with performance. I have access to the slow filter dashboard, which shows filters that are unusually slow and could use attention. Not every wiki is reported there, but there are plans to make that happen. Anyway, the issue is the dashboard is only available to those with logstash access, which doesn't include many abuse filter experts. Even those who do have access may not know how to best improve their filters, so someone like me has to walk the local abuse filter manager through it, relaying information we see on the dashboard. Beyond that, I do occasionally get requests to assist other wikis, but again it is almost always out of the interest of performance.

Pinging User:DerHexer, who I believe both created and removed the abuse filter editors group. Do you recall why it was removed? Any thoughts on restoring it? — MusikAnimal talk 18:36, 2 February 2018 (UTC)

@MusikAnimal: the log says it was removed because it was empty. Generally when a global group has no members it gets purged. — xaosflux Talk 18:58, 2 February 2018 (UTC)
(moved from another page) I don't think there is big value in creating a local access group for editing meta-local abuse filters only - reason why: it's not really that hard to become +sysop here and meta-local abuse filters don't need that much management. A stronger need-base argument could be made for a group that allows editing of the global filters (applied to small/medium wikis) - my first inclination would be that global sysops would be the natural extension of this, as this group of volunteers is already vetted to impact lots of wikis - challenge is that they may not have the technical inclination or desire to deal with abusefilters, and making someone a gsysop soley for abuse filter management may not be appealing to the global community. — xaosflux Talk 14:45, 2 February 2018 (UTC)
@MusikAnimal: I don't think most of the 'large wikis' would want someone not very involved with their community making filters/etc. — xaosflux Talk 18:56, 2 February 2018 (UTC)
For meta sysops it is possible to edit CN, Global spam&title blacklist, etc. Likely it should be able to edit global filters as well. CN is imho more dangerous than global filters. I would make sens to give GS access to global abuse filters as well. Or experienced people are getting added to the usergroup mentioned by MusikAnimal. --Steinsplitter (talk) 19:08, 2 February 2018 (UTC)
@Xaosflux: Totally. I don't think global abuse filter editor should in general be used for arbitrary creation of filters without discussion. It would foolish to pretend that I understand local abuse issues, or community processes, when I don't even patrol there. Again for me it's about helping out with performance, which in most cases doesn't even require an understanding of whatever non-English language is used in the regex (more commonly it's the condition ordering and function usage that's the issue). This of course would be limited to highly trusted users. Hopefully I fall in that category, but that's obviously up to everyone else to decide :) It would be nifty for Meta sysops to edit global filters too, but that wouldn't fit my use case. Global sysop doesn't apply to every wiki, either. — MusikAnimal talk 19:24, 2 February 2018 (UTC)
I'd prefer if we focus on the local issue. It might be benefitial to create a local group for some people to also edit local filters, it might be benefitial to create a local group to edit global abuse filters restricted to very trusted and experienced users in that area. The global 'abusefilter' group was created for Andrew G. so it could have a look at its newly deployed extension and I don't think we need one again. —MarcoAurelio (talk) 21:11, 2 February 2018 (UTC)
@MusikAnimal: What about adding the abilities to the sysadmin global group for those of you who need to work on those? —MarcoAurelio (talk) 21:13, 2 February 2018 (UTC)
@MarcoAurelio: I'm happy to help just here on Meta with global filters (if you want my help), but my use case extends beyond Meta. I think sysadmins already can edit all filters, no? I do not hold this right, but I suppose cleaning up filters is broadly related to work... so I might could get it. I realize this is not just about me :) and that there's probably not that many people who could benefit from a global abusefilter editor (any filter, any wiki), so maybe it's not worth it. — MusikAnimal talk 22:31, 2 February 2018 (UTC)
It would be simpler to add abuse filter related userrights to Interface editors group—its membership already consists mainly of developers. Ruslik (talk) 08:06, 3 February 2018 (UTC)
Simpler maybe, but I'm not sure abuse filter management would fall under the purview of an "interface editor", in a literal sense. — MusikAnimal talk 17:00, 5 February 2018 (UTC)
I think the ability to edit the global filters should just be added into the local sysop group. The thing isn't even truly global (though it should be). – Ajraddatz (talk) 21:15, 2 February 2018 (UTC)
Not really opposed in "general" - just need to make sure people know what they are doing. And it is "almost" global (small- and medium- sized wikis) - I don't think we have the capacity to try to examine large-size wiki's edits centrally without a lot more horsepower! — xaosflux Talk 21:20, 2 February 2018 (UTC)
Meta admins can already edit the global spam/title/email blacklists. I trust our admins to not mess around with things they don't know. And so far as making the global abusefilter global is a performance issue, that's fine of course. I'm less convinced by the "but muh local community sovereignty" perspective. – Ajraddatz (talk) 23:08, 2 February 2018 (UTC)
Agreed, the permission suits the Meta-Wiki administrators' job. It doesn't need to be set in stone though: in case the filters become a bigger deal in the future, it can be again restricted to stewards so that people from every wiki have a chance every year to complain about its usage. --Nemo 20:36, 7 February 2018 (UTC)
I suppose we should put something to a vote, I'm seeing a few prevailing options here
Local options
  1. Allow meta Administrators access to abusefilter-modify-global. This will allow them to edit the global abuse filters currently maintained only by stewards here on meta. These filters affect all "small" and "medium" sized public wiki's. No process changes needed, small policy and directions updates. This could be done in addition to options below if desired.
  2. Create a local group (e.g. Edit filter managers) that can manage all of the filters managed on meta, including the global list. Permissions to include: ((managechangetags) , (oathauth-enable) , (abusefilter-modify) , (abusefilter-modify-restricted) , (abusefilter-modify-global)). New process for requesting access can be added to Meta:Requests for adminship. Allow meta Bureaucrats to manage group membership. Possibly allow administrators to add/remove self if not also implementing (1) above.
Global options

A global group would be as (2) above, but apply globally. There are several options on this one, such as using an existing group (e.g. GIE, GS) and if it should apply to ALL projects, or just a subset (such as the GS list). Some specifications would need to be laid out.

Thoughts? — xaosflux Talk 16:15, 10 February 2018 (UTC).

A much simpler solution is to create a personal global group for User:MusikAnimal who wants to help us making abuse filters better as we do from time to time. Ruslik (talk) 18:17, 10 February 2018 (UTC)
I know I'd volunteer to at least help with the global filters here, not sure about visiting all the 100's of local ones though. — xaosflux Talk 21:02, 10 February 2018 (UTC)
I think the best solution is to allow meta admins to edit the global filters (local option 1). Such a change is in-line with their existing scope and abilities. I don't think that another global group is needed; there are already abusefilter helpers that can view all filters, and global sysops/stewards that can help with filters on small projects. – Ajraddatz (talk) 21:08, 10 February 2018 (UTC)

Can I suggest to create a local group here at Meta-Wiki that has the appropriate permissions to edit global abusefilters? I feel it'd be easiest option. A global group could be an option but editting filters outside Meta-Wiki is controversial and I feel that'd require some discussion. —MarcoAurelio (talk) 21:09, 10 February 2018 (UTC) [well, that's option #2 of Local options above].

And on review, global sysops can already manage local filters at the sm/med wikis - if they wanted to manage "global filters" they could use the new local group as well. — xaosflux Talk 21:44, 10 February 2018 (UTC)

Allow admins to add users to translation admins group[edit]

Hi. Could we allow admins to add users to the translation admins user group? This functionality is currently restricted to bureaucrats or own accounts only on Meta-Wiki. --MZMcBride (talk) 18:09, 7 February 2018 (UTC)

Why? TA requires a community vote at WM:RFA and the system is working just fine IMHO. I'd rather not amend the config again. —MarcoAurelio (talk) 18:25, 7 February 2018 (UTC)
Someone asked me today about getting added to the group. I was hoping I could just add them myself, but for some reason we only allow self-changes or bureaucrats to add someone to this user group. It remains unclear to me why a separate translation admin user group is needed at all, but requiring an RFA for it seems even sillier. --MZMcBride (talk) 23:15, 7 February 2018 (UTC)
Meh, our local crats haven't had any trouble keeping up with this. If we wanted to devolve an assignment function from crat to admin things like "uploaders" and "confirmed users" would be more sensible. These are also so rarely used that it's not really causing any backlogs. — xaosflux Talk 20:12, 7 February 2018 (UTC)
There are currently only three local bureaucrats, I believe. Coincidentally, all three have usernames starting with the letter M. --MZMcBride (talk) 23:15, 7 February 2018 (UTC)
We dismissed Barras and appointed Matiia so we could conform the "M for Meta Bureaucrat Cabal", a.k.a "The Three Musketeers" (M for Musketeers too!) :-P —MarcoAurelio (talk) 00:40, 8 February 2018 (UTC)
So I'm hearing you have a chance assuming you can get 2/3 of ALL of them to endorse you! (where did that policy come from?) — xaosflux Talk 00:16, 8 February 2018 (UTC)
Hmm, looks like it just appeared one day. — xaosflux Talk 00:23, 8 February 2018 (UTC)
And before, it seems like there was no requirement for a discussion. I do remember back in the day when Meta had one crat for every two admins. – Ajraddatz (talk) 00:43, 8 February 2018 (UTC)
I don't mind leaving most of the userrights-related stuff to bureaucrats. Since translation adminship requires some sort of discussion, it should be fine to keep there. – Ajraddatz (talk) 23:22, 7 February 2018 (UTC)
Out of curiosity, why is a seven-day discussion needed? What's the specific concern? Are we worried people are going to go rogue and mark pages for translation? --MZMcBride (talk) 23:42, 7 February 2018 (UTC)
Not sure, honestly. Probably just something that was done initially and then continued. – Ajraddatz (talk) 00:43, 8 February 2018 (UTC)
I realize nobody wants to touch the user rights configuration again (myself included), but I do wonder whether it would make sense to have a "trusted user" group or similar and fold a lot of these individualized user groups into a larger, more general group. This user group could be viral instead of self-added or removed. Viral meaning users already in the group can add other users to the same group. This creates a chain or web of trust, in some ways.
In my ideal world, we'd just let all users do all of this. I think we should be as open as possible, just as we are with editing. Why should page translation be treated special? Or we could make anyone an administrator. But obviously that isn't going to happen anytime soon. --MZMcBride (talk) 01:34, 8 February 2018 (UTC)
"Touching" the config to move existing permissions between existing groups is pretty trivial, if the community wants a change there should be no great technical argument. — xaosflux Talk 02:07, 8 February 2018 (UTC)
Sure, but I think there may be some change fatigue. I didn't mean to suggest that this was difficult from a technical perspective, I was referencing comments like MA's about preferring not to re-amend the configuration. --MZMcBride (talk) 02:10, 8 February 2018 (UTC)
I recently standardized the Translate permissions WMF-wide (previously we had to do this for every wiki using Translate). I think the system works fine and there's no backlog currently. The discussion at RFA proved helpful in my experience, as it has helped to exclude some people asking for this without the knowledge on how to properly tag a page for translation, effectively breaking translatable pages. This is not to say that I do not trust my fellow administrators to handle this permission, but given the above I'm not sure if there's any need or it's worth the effort to do so. Thanks. —MarcoAurelio (talk) 11:22, 8 February 2018 (UTC)
Translation admins can easily break a lot of translation pages or unnecessarily create them etc. So I think it makes sense to only give it to users who know how to deal with it. --MF-W 17:03, 8 February 2018 (UTC) IMHO, "translators are not toys" which is also mentioned at Meta:Translate extension#In general when I read and translated the Chinese page in not long ago. It maybe a good option to have 1 week support consensus discussions from community users trusted to grant the TA tool by any local admins or crats. SA 13 Bro (talk) 22:48, 8 February 2018 (UTC)

Sandbox link[edit]

Hello. Does anyone know how to enable the sandbox link (as on English Wikipedia)? Is it disabled here for a reason? Thanks in advance. Rehman 07:19, 14 February 2018 (UTC)