Wikimedia Forum/Archives/2019-08

Is it ok if I create a global user page?

Hi. Is it ok if I create a global user page here? All projects but the Swedish wiktionary allowed me to add a userpage. Since it wasn't possible to make an account there I thought I'll make a single account here and then everybody can get the same userpage across all the projects I contribute to. It says I need to get touch with an admin to see what they think about what I want to do. I'd like to get in touch with an admin please. Ελλίντερεστ (talk) 02:56, 2 August 2019 (UTC)

You already have a global userpage. What's at User:Ελλίντερεστ will be displayed on wikis where you've never created a local page. You don't need anyone's permission. –Ammarpad (talk) 06:43, 2 August 2019 (UTC)

Thank you. Do you know if I can delete/blank my wikidata user page so that the global meta-wiki user page is visible there by default? Ελλίντερεστ (talk) 10:17, 2 August 2019 (UTC)

It needs to be removed to show the global user page there. I can remove it if you want. Stryn (talk) 10:19, 2 August 2019 (UTC)

Yes please and thank you for offering your help. Ελλίντερεστ (talk) 11:32, 2 August 2019 (UTC)

Request new language

I have created that page:

https://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Swiss_Italian

Can someone link in properly page for request new language? Thanks!

--5.169.198.223 16:08, 4 August 2019 (UTC)

ItWikiCon 2019: call for submission

Hi, I would like to point out that the submissions are open for the sessions of the ItWikiCon 2019 that will take place in Rome from 15 to 17 November. The reference page is as usual the one of the proposals, in which you can either add ideas on what you would like to see in this edition, or make a proposal of a presentation/workshop/seminar/working group/etc. that you want to make, following the procedure through the inputbox or using directly the proposal model that we have prepared.

The deadline is 13 October 2019, the date from which the program committee will evaluate all proposals received, defining, in the days immediately following, the official program of ItWikiCon 2019.

For any clarification or suggestion please write in the proposal talk page or send an email to itwikiconroma@gmail.com and if you plan to participate, don't forget to sign in the participants page.

On behalf of the programme committee, I would like to thank all those who would like to contribute to making ItWikiCon 2019 rich and diversified.--Ferdi2005 _(Posta) 12:56, 7 August 2019 (UTC)

Spam blacklist

Some of the entries at Spam blacklist is really old, and only motivated by a handful of edits. It seems counter-intuitive to keep them on list. I bumped into this because the Norwegian w:no:Milforum is on the list, due to edits in 2009 and 2010. Hardly very recent activity.

Is there any real verification whether it is necessary to keep entries on the list at all? — Jeblad 11:50, 9 August 2019 (UTC)

There is no any formal periodical verification process. Ruslik (talk) 08:56, 15 August 2019 (UTC)

This section was archived on a request by:  — billinghurst sDrewth 12:33, 10 September 2019 (UTC)

GDPR

Does the WMF comply to the GDPR? If so, which is the procedure for accessing the personal data stored by the WMF? Thanks --Discasto (talk) 15:30, 12 August 2019 (UTC)

See https://foundation.wikimedia.org/wiki/Privacy_policy --Malyacko (talk) 22:42, 12 August 2019 (UTC)

So, the answer is no, isn't it? --Discasto (talk) 23:16, 12 August 2019 (UTC)

This section was archived on a request by:  — billinghurst sDrewth 12:34, 10 September 2019 (UTC)

A question

Can RfCs on Meta be created to make proposed changes to global policies? Or if it is only applicable on global policies talk pages? Znotch190711 (talk) 06:07, 24 August 2019 (UTC)

It's usually better to start from the talk page so that you have a more concrete and polished proposal by the time you open an RfC. There are no hard rules about RfC but it's easy for them to go wrong. Nemo 09:26, 24 August 2019 (UTC)

RFC is basically where most things go to die. Without clear procedures about, for starters, what can be brought there that can result in any action, nearly all end in the archives with no action taken. —MarcoAurelio (talk) 13:13, 24 August 2019 (UTC)

^ that. Also, there's the thing that Wikimedia projects are highly decentralized as a matter of design. Getting a global policy through is intentionally hard and the only ones that do get through are intentionally vague for a reason. TonyBallioni (talk) 13:49, 24 August 2019 (UTC)

This section was archived on a request by:  — billinghurst sDrewth 12:33, 10 September 2019 (UTC)

StalkToy

On the template {{LockHide}}, it says “ST” at one of the links and obviously it means “stalktoy”. What is stalktoy and how do stewards use it to look at the users’ information? Znotch190711 (talk) 12:45, 25 August 2019 (UTC)

Why don't you look yourself? It's just a more advanced interface to see what is now available on Special:CentralAuth. Nemo 16:02, 25 August 2019 (UTC)

It is just a tool, and in this case an old tool. Much of the functionality has been taken over by the built-in system tool CA as stated above or other tools, however, it still functions and has some use. How, or if, current stewards use it is pretty irrelevant to us minions.  — billinghurst sDrewth 23:21, 25 August 2019 (UTC)

I don't think it is widely used by stewards anymore. I haven't opened it in a long time, and it took over a minute to load it for my own account. Not very useful, anymore. – Ajraddatz (talk) 23:26, 25 August 2019 (UTC)

Though you and I have fat ugly usage.  — billinghurst sDrewth 23:34, 25 August 2019 (UTC)

This section was archived on a request by:  — billinghurst sDrewth 12:28, 10 September 2019 (UTC)

Help sysop: WikiConvention translations

Hello everyone!

The WikiConvention is in 8 days, and there's a problem with the pages in French, English and Dutch.

We rather use mw:Extension:Translate than {{Languages}}.

To do so, few pages need to be temporarely deleted :

• WikiConvention francophone/2019/fr
• WikiConvention francophone/2019/en
• WikiConvention francophone/2019/nl

(By the way, I have a backup of these pages... you can delete them without worries...)

Thank you in advance, sysops, for your help ! Best regards, Benoit Rochon (talk) 14:03, 29 August 2019 (UTC)

Done. --Amir E. Aharoni (talk) 15:15, 29 August 2019 (UTC)

Merci a lot Amir ! Benoit Rochon (talk) 15:20, 29 August 2019 (UTC)

This section was archived on a request by:  — billinghurst sDrewth 12:28, 10 September 2019 (UTC)

Global locks for fresh junk accounts

Anyone watching Steward_requests/Global knows that the present condition is like a denial-of-service attack. Stewards are busy processing many hundreds disposable accounts weekly, whereas requests of real importance—such as global range blocks—are conceded to arguments between non-steward regulars and casual visitors, and many are suspended in the backlog for weeks. Large lists of diverse accounts are submitted for global locking – unlikely anyone seriously expects a steward to verify such lists case-by-case. The present situation may escalate to formation of a group of users who (unofficially) “may” request mass locking for accounts, which is dangerous even assuming good faith – noone is guaranteed against errors, even during copy-and-paste. Therefore, an alternative pathway of global locks for the junk is needed. I could bring complicated logical schemes, but, for simplicity, let’s start from discussing the following:

1. Any account less than 16-hours-old and active exactly in one wiki W (that is, having actions in W and no actions elsewhere) may be locked by a sysop of W. Sysops of W should also have a possibility to undo the action.
2. A global sysop may lock any account less than 12-hours-old. This also should be more easily undoable than actions by stewards.

--Incnis Mrsi (talk) 16:39, 29 August 2019 (UTC)

I would be very interested in allowing global sysops (or maybe Meta crats, as was done in the past, or even Meta admins) to globally lock accounts, and maybe globally block IPs as well. This was not allowed from the original RfC, but we're a decade after that vote and something should be done. What are people's thoughts on this? – Ajraddatz (talk) 16:50, 29 August 2019 (UTC)

I'd oppose that fairly strongly. As it stands, global sysop is one of the least significant rights out there: it only allows individuals to take actions on specific wikis, and usually these are wikis with a small or non-existent community where the social damage that can be done by technical misuse of tools is equally small or non-existent. A global lock/block is truly global and would be a significant change in scope. There's also the major issue that global sysops are currently elected by a small subsection of the global community that is hardly reflective of the diversity of Wikimedia projects. TonyBallioni (talk) 16:59, 29 August 2019 (UTC)

Yes, no doubt, but what about other options: a group specifically created for that purpose, meta admins or crats, etc. Options other that stewards. – Ajraddatz (talk) 17:04, 29 August 2019 (UTC)

Again… it’s not about substantial expansion of privileges. I, of course, vehemently oppose additional levers for globally locking established accounts – even not every steward may be IMHO trusted with it, let alone sysops. Let “second-grade” admins take some 30% routine waste-disposal job, and then we sincerely may expect a mild improvement in stewards’ responsibility for jobs of real significance. Incnis Mrsi (talk) 17:18, 29 August 2019 (UTC)

(ec) Personally, I’m not sure. You’d have to have a group that could be trusted to know when to defer to local processes and that has the trust of a significant spectrum of the global community, beyond SRGP (which is more or less 10-15 meta regulars and anyone who has been canvassed.) I’m not really sure how to do that other than holding mini-steward elections with global advertising, and if you’re going to do that, you may as well elect stewards twice a year. I’d support twice yearly steward elections as needed, fwiw, with confirms once a year. TonyBallioni (talk) 17:21, 29 August 2019 (UTC)

Who has documentation on this? I started en:Wikipedia:Sock farming but I want to collect more information about weird automated junk accounts. Blue Rasberry (talk) 17:26, 29 August 2019 (UTC)

• As a GS, I would very strongly oppose this and I think we actually need to move toward a new RFC about the scope of GS instead of basing it on this decade+ old scope that currently exists. Praxidicae (talk) 18:01, 29 August 2019 (UTC)

  What did you have in mind for an RfC about the scope of GS, out of curiosity? Are you thinking of the wikis in the wikiset? – Ajraddatz (talk) 19:05, 29 August 2019 (UTC)

• (Edit conflict.)I oppose this proposal, we should assume good faith always that stewards do due dilligence in locking / blocking. When an user repeatedly gives accounts that should not be locked / IP should not be blocked, they can be asked to not edit SRG at all (including Talk). In addition, giving meta sysop the rights to lock isn't going to solve much, most of them are stewards or former stewards (which can possibly run for stewards if they want) or people who can be trusted with stewardship if they run for, so why not run for stewards. As for crats, we only have one non-steward crat here (and I think MF will not want to lock / block anymore). For GS, their scope is different and are elected based on different standards, but I still feel they are highly vetted by global community. I don't see any merit in this proposal at all. For twice a year SE, expand scope of GS per RFC, even expansion of scope for GR , I am happy to participate in RFC.--Cohaf (talk) 18:25, 29 August 2019 (UTC)

  Again, the DoS attack on stewards is underway. If no relief in sight, then the Wikimedia community will react with election of more overenthusiastic shoot-not-think boys and girls as stewards, not wise and experienced first-grade admins as desirable for me. I could expect that the trade-off between quality and quantity of actions is obvious for every experienced Wikimedian, but likely overestimated and we see quite other things here. WTF? OMG! TMD TLA. ARG… I don't see any merit in this proposal at all. ☺☺ Incnis Mrsi (talk) 19:11, 29 August 2019 (UTC)

• I had clearly explained that DDoS must be stopped at the source, not the other end. You indicated more, are you saying that our current stewards are trigger friendly, I hope not. Lastly, I dont understand what you are trying to say in the last part, care to clarify? --Cohaf (talk) 04:25, 30 August 2019 (UTC)

After the story with locking an established account under “Spam-only account” by a steward who then found refuge behind mates’ backs I don’t feel that much discussion about combating bad practices is needed. Other incidents are known to me, such as an unwarranted shooting exercise by علاء. Incnis Mrsi (talk) 06:45, 30 August 2019 (UTC)

• As a global sysop, I strongly oppose this proposal. It would greatly expand GS scope far beyond it's current level. We need more people to run for steward, yes, but we shouldn't start dishing out steward userrights to other permissions. I agree with Tony in that two Steward elections a year may be better. Regards, Vermont (talk) 22:27, 29 August 2019 (UTC)

  In the case of really fierce attack under the present system—and not necessarily by morons like C.....r and ..X fu....i, it perfectly could be government- or organized-crime-sponsored—stewards will be effectively knocked down for all other purposes. My proposal permits for reinforcement of Wikimedia frontal defence lines. While local and global sysops will fend off myriads of socks, stewards will be able to devise a strategic response. Incnis Mrsi (talk) 11:36, 1 September 2019 (UTC)

• I wouldn't necessarily oppose the concept, but I think it should be to a fresh new user group. I don't know if some of our current global sysops would have been elected if this had been part of the package. --Rschen7754 04:27, 30 August 2019 (UTC)

  @Rschen7754: please, try to understand what do I propose. The heading states “for fresh junk”, not for all accounts. Again, it’s not about substantial expansion of privileges of anybody. Yes, a probability exists that a rogue sysop “kills” an account of a good user in the first 16 hours of its existence, but a probability also exists for the same user to be killed by a thug. In practice, the danger of abuse is minor, if not negligible. Incnis Mrsi (talk) 05:53, 30 August 2019 (UTC)

  I understand but do not agree. --Rschen7754 06:24, 30 August 2019 (UTC)

• As a global sysop I'm against the proposal for Global Sysops pretty much per TonyBallioni & Vermont. We just need more stewards that are elected from a broad spectrum of users and get a confirmation every year. I as a GS was elected once by about 20 people doing the same job and probably similarly minded and never was confirmed. More power without proper increase in the electoral base and the accountability is imho a recipe for disruption. If global IP blocks are strictly excuded I would be in favor of proposal (1) but not for normal sysops. A new group should be created that one should be at first sysop in x.wiki for y months/years and then given the extra bit through meta. Global effects should have global control and moreover, many admins, especially in smaller wikis are not experienced enough to be granted such power only through local procceses that have much lower standards than those of larger wikis and meta.—Ah3kal (talk) 06:19, 30 August 2019 (UTC)

  What means “(1) but not for normal sysops”? Speak more clearly, please. The point 1 was about right of a wiki to shoot their LTA socks and random vandals, saving the stewards’ effort for locking the junk globally after the local indefblock. Incnis Mrsi (talk) 06:45, 30 August 2019 (UTC)

  Sorry for that. I mean a local sysop should be given the extra bit through a process in meta and not automatically just for beeing sysop. Given that, and an explicit statement that no right to global block IPs are given, I fully agree with the first part of your proposal.—Ah3kal (talk) 06:50, 30 August 2019 (UTC)

• Yes, I already read again and got it. Technically killing a brand-new SUL is a “global effect”, but if the SUL has non-empty record in one wiki only, then which de facto global effect would have such global lock? No meta-wiki bureaucracy please for trivial matters. Incnis Mrsi (talk) 07:11, 30 August 2019 (UTC)

  OK you got a point there. The proposed time limit makes this indeed unnecessary.—Ah3kal (talk) 07:16, 30 August 2019 (UTC)

  My proposal enables local and global sysops to process a part of disposable accounts, saving the stewards’ effort (although I don’t expect the majority of global locks to be performed via new pathways). What is indeed “unnecessary” and for which end? Is the heavy use of pro-forms a mandatory part of Ah3kal’s English? Again I have to decrypt a phrase and infer some meaning from it, which possibly lie far from the intended meaning. Incnis Mrsi (talk) 09:48, 30 August 2019 (UTC)

  @Incnis Mrsi: "this" was a reference to "[No] meta-wiki bureaucracy [please] for trivial matters.", the meta-wiki bureaucracy becomes unnecessary. I changed my opinion on this after I had a second thought on the scope of the proposal (16h old accounts). So you convinced me and I fully agree with the first part of your proposal. Sorry for my english, I'm not a native speaker, will try to avoid "pro-forms" in the future.—Ah3kal (talk) 10:12, 30 August 2019 (UTC)

• Make Global managers or .. make "Scoped wide (global) block" ( be able global block to SUL account ; also Global blocks for only applied to GS scoped wikis when global blocks are make by GS) ! If I had consensus this, I can implement that function as MediaWiki volunteer developer.--rxy (talk) 07:03, 1 September 2019 (UTC)

  If it envisages more gunmen who would be able to shot me and my comrades, then I vehemently oppose it, as already said. Hopefully not me alone. Incnis Mrsi (talk) 11:36, 1 September 2019 (UTC)

• Comment I am not seeing that spambot accounts are going xwiki, can anyone point to such a pattern? So where spambots are found by local admins it should suffice for those accounts to be locally blocked, no further harm, no global action required. Where stewards find the spambots in their checkuser searches on meta or login wikis, then they can lock them as they would just do a copy, paste (and clean) to lock. So, this would seem to be have sole solutions in local admins stop requesting locks.  — billinghurst sDrewth 12:39, 1 September 2019 (UTC)

Comment I would happily lock spambots, though I have zero wish to be a steward again. I would say that I have the skills, technical knowledge, and I would say the ongoing trust of the community ... BUT ...

• I have no wish to do the steward dance, nor to have identify myself through renditions of process, nor need checkuser or oversight rights (been there, done that, retired!)
• Can I be dismissive about the expressed worry about abuse of the tool where an admin locks a problematic user? Simply set a process that the role is only to lock spambots, we all know what they look like, and where they are, and their global account signatures.
• Again though, I don't see that locking spambots is a good use of time, and the only means to bulk identify them is presumably through checkuser.

Fix the underlying problem of the spambots and their ready ability to break through weak defences, not set more human hours to battle them. What a waste of people's time to fight this crap rather than have a more resilient system. Put the people's time to editing.  — billinghurst sDrewth 12:57, 1 September 2019 (UTC)

If Billinghurst agrees that only fresh accounts may be lockable via the new pathway, then good. Otherwise respectfully… a steward locked a Commons user with “spam-only”—see above—and no admonishment ensued for a year. Who can believe that empty declarations about “the role only to lock spambots” will serve an effective deterrent? How often sysops who commit, say, blatantly abusive deletions (pretending to be based on CSD) are demoted? Please, no wiki mobs possessing technical possibility to lock established accounts. Incnis Mrsi (talk) 13:24, 1 September 2019 (UTC)

You misread what I said. I made comment, not agreed with anything. Apart from that, this is not the place for criticism of stewards' block commentary. You haven't done the job, and you don't understand the role in its implementation. Paste and like errors will always occur. Don't be a ball-breaker. If you are seeing abuse of the role, then take it up on the stewards' noticeboard, OR at their confirmation. Stewards regulate each others' actions, and hold each other accountable. You don't know what is happening among themselves, so fancy that you should just stop being hypercritical.  — billinghurst sDrewth 15:16, 1 September 2019 (UTC)

Wise comment. It is a pity that there is no Billinghurst among Wikimedia policy-makers – a stark contract against average Wikipedian (and Commons) admins treating us like misbehaving teenagers. Incnis Mrsi (talk) 17:20, 1 September 2019 (UTC)

What is proposed looks like a non-solution for a non-existent problem:

1. Generally locking hundreds and thousands accounts is not a problem at all. There exists the multi-lock tool specifically designed for this purpose.
2. What really consumes a lot of time is a need to checkuser all these accounts and lock all socks and sometimes IP addresses and ranges.
3. So, the proposed "solution" will solve no problem but may create new ones.
4. Locking so called junk accounts will result in a vast expansion of the number of locks as now only accounts that are involved in some sort of cross-wiki abuse (or LTAs) are locked and I routinely deny requests for locking accounts active only in a single project. This proposal will make a huge number of single project accounts eligible for global locks.
5. I seriously doubt that local admins will be able correctly identify LTAs (without checkuser tools) or will care about them at all.
6. And finally I find it is curious that somebody wants to give local admins, many of whom were just appointed by stewards for a short period of time and who have often no experience with administrative tools, a power to take a global action. I am not sure that I really want to give them that power.
7. This will also create a giant new headache for stewards who will need to process all complaints about incorrect locks.

Ruslik (talk) 20:49, 1 September 2019 (UTC)

1. I’m not an imbecile to claim that these are requests to the server which create expense. Expense is the steward’s responsibility. 2. CheckUsing a locked account is possible. Moreover, it never has been a magic dust, right? 3. The problem exists, denial is a minority viewpoint. 4. Yes, nothing wrong with it. 5. Local projects have all devices necessary to regulate their practice. 6. Did Ruslik read the conversation above? It seems that he did not. 7. Again, “sysops of W should also have a possibility to undo the action” – no reasonable comment about this clause. Incnis Mrsi (talk) 07:39, 2 September 2019 (UTC)

I do not know whether you are an imbecile or not.:) However you failed to understand my points. Ruslik (talk) 18:55, 2 September 2019 (UTC)

The point that the most important process is extraction of IPs and—subsequently—global blocks? Not exactly “failed to understand”, rather I disagree with excessive reliance on the CU tool used namely by stewards. Most wikis frequented by LTA have their own hierarchy, including CheckUsers. Wherever stewards failed to block some LTA range, they could be pointed to already locked socks carrying necessary data. Incnis Mrsi (talk) 19:21, 2 September 2019 (UTC)

More frequent steward elections

Can we discuss this concept, which seems to have gained some traction above? Creating its own subheading to help focus the discussion. TonyBallioni (talk) 16:22, 31 August 2019 (UTC)

• Why, are the current elections overloaded with candidates? I suspect it would be more useful to reach a discussion on how many new stewards (and how active) we'd like to see, and then to proactively encourage more candidates for the next round until we have a chance of reaching that number. Nemo 16:27, 31 August 2019 (UTC)
  • We need more stewards. More frequent elections gives multiple opportunities for people to run throughout the year if for some reason February doesn’t work. As an example, in my industry people frequently are working 70 or 80 hour weeks in the normal SE timeframe. Running for steward is not something I want to do, but I pretty much wouldn’t have any time at all to run in SE2020 if I even wanted to. Providing multiple opportunities throughout the year expands the pool of candidates. It would likely also make it more feasible for older wikimedians to run by having elections in the traditional northern hemisphere slow time, which would hopefully make it so we had more candidates beyond the traditional early-20s university student. TonyBallioni (talk) 16:42, 31 August 2019 (UTC)

• More elections is something I briefly pushed for years ago, though I think it was widely dismissed as being unnecessary at the time. I am open to the concept, but I'm concerned that the steward elections (and the voting base) are not generating the same interest that they once did. This is likely due to a combination of:

  Big wikis creating less admins. The ideal (and previously common) path to stewardship was for experienced and trusted users who are admins on their homewiki to run and be elected. With big wikis making less admins, there are just less candidates to pull from that category.

  High expectations for candidates. Common reasons without clearly defined criteria include lack of language proficiency, cross-wiki experience, and overall activity. High expectations are good, to be clear, but unclear goalposts often mean that potentially good candidates are not elected.

  Good but controversial users are sunk by homewiki controversy. Admins/functionaries who have been even slightly active in drama-related positions like ArbCom typically have enough of a hater following to sink their candidacy.

I'm not sure how exactly to fix this, and to what extent it should be fixed. While I have a very cavalier attitude to handing out local-wiki adminship, stewardship *is* a pretty big deal role with with full access to the wiki interface and very little actual oversight. But all of this to say that running a second election each year may not resolve the problem. – Ajraddatz (talk) 16:35, 31 August 2019 (UTC)

While I agree with everything you said (though slight philosophical differences on the role and significance of steward), I don’t particularly think that’s relevant to possible having more elections. Sure, to get elected you have to be pretty bland, but ultimately we need more people than we currently have to push buttons, and a bland person who can be trusted to push them is better than no one doing the work that person could be doing. TonyBallioni (talk) 16:46, 31 August 2019 (UTC)

(Fair enough, changed the wording a bit). As I said, I'd be open to the idea, and would support even a trial run to see what actual impact it would have on recruitment. Let me think a bit more about this, and how it could be sold to the wider group. – Ajraddatz (talk) 17:54, 31 August 2019 (UTC)

In my opinion, we have very few global sysops now, which is the closest step up to the steward role. --Rschen7754 16:48, 31 August 2019 (UTC)

True, though more and more of our global sysops are not admins on their home wiki or any large wikis, which links back to problem 1 and presents a barrier to them moving into stewardship. – Ajraddatz (talk) 17:54, 31 August 2019 (UTC)

Well, and to add to that: why don't we have more global sysops? In my opinion, we've got to be less picky with roles like global rollbacker and global renamer. I'd venture to say that less than 50% of candidacies for GR are successful, and many failures are justified. However, I see quite a few opposes based on ridiculous standards.

I think we also have to get away from the picture of a steward having to fit a certain cookie-cutter mold of fighting cross-wiki LTAs - we need them but we also need the type that do quiet but important maintenance, and the type that work in the policy and governance area (which would have been helpful in some of the azwiki/amwiki issues). I can think of quite a few recent candidates who were perfectly qualified, but didn't fit in the mold and failed election. --Rschen7754 06:05, 1 September 2019 (UTC)

• The present system has two real shortages: stewards are not practically re-callable (unless take part in some grand scandal) and not very large number of Wikimedians vote on their election. I know Wikimedians who are unwilling to vote even yearly; if election to be held twice a year, than influence of relatively small group of Meta regulars will increase whereas relative participation from working Wikimedia communities will dwindle. So the proposal is much like a solution in search of problem(s). Indeed, stewards now perform too much dull and stupid job. Wikimedia should devolve routine job to broader communities of admins, but electing more stewards will devalue the position and erode their responsibility standards (already not very high) further. Incnis Mrsi (talk) 18:31, 31 August 2019 (UTC)

but electing more stewards will devalue the position and erode their responsibility standards (already not very high) further.[citation needed] It seems all of your responses to your own proposal are just to berate stewards and the position overall, so what exactly are you hoping to gain from this? I don't know what your basing your numbers on either, but I simply don't see that there's a wide lack of trust in Stewards. Praxidicae (talk) 19:05, 5 September 2019 (UTC)

This section was archived on a request by:  — billinghurst sDrewth 12:29, 10 September 2019 (UTC)

Emergency powers for stewards

Due to recent spam botnets and sock puppet farming attacks, I feel it would be useful if stewards were given rights to do the following temporarily on a wiki or global level for the duration of mass disruption: Suspend autopromotion, impose a strict rate limit on unconfirmed accounts, limit account creation by unconfirmed accounts and IP users. MorganKevinJ^(talk) 02:07, 31 August 2019 (UTC)

• This all sounds sensible. Stewards are stewards because we trust them. If someone does something with poor judgement or malice, we can remove him. In the meantime, take care of business during this attack and then revert the changes when the stewards feel like it's over. —Justin (koavf)❤T☮C☺M☯ 02:24, 31 August 2019 (UTC)
• There's filters on some of the smaller projects which have serious spam issues that do similar things to those you mention. However, doing this on a global scale (assuming that includes larger projects) strikes me as unnecessary and a net negative. Spam can be quickly deleted and managed, however the edit(s/ors) we would lose from enacting such restrictions cannot so easily be recovered. When it comes to stewards being able to do this, they already mostly have the technical ability through local filters, and global filters for those who are metawiki admins. Best regards, Vermont (talk) 02:30, 31 August 2019 (UTC)

  @Vermont: which wikis? which filters? maybe we should look to run them at meta and see what we can better do.  — billinghurst sDrewth 14:33, 31 August 2019 (UTC)

  cc Praxidicae. Vermont (talk) 15:16, 31 August 2019 (UTC)

• Sounds like a solution in search of a problem. Admins on wikis have extensive tools to achieve what described on a temporary basis. Stewards can step in in sysops' place where necessary. Nemo 12:25, 31 August 2019 (UTC)
• We can basically already do this using global filters or local ones if there are no local admins. – Ajraddatz (talk) 12:43, 31 August 2019 (UTC)
• I think we need to fix our broken CAPTCHA system urgently. We've been complaining for years. We can't take care of other tasks if we spend all of our time locking spambots. —MarcoAurelio (talk) 13:05, 31 August 2019 (UTC)

^^^What he said, and with bells on it! Completely known and completely not actioned by WMF.  — billinghurst sDrewth 14:28, 31 August 2019 (UTC)

Agreed. The single best way to reduce the spambot burden. – Ajraddatz (talk) 18:40, 2 September 2019 (UTC)

• Comment there are already global solutions with global filters that somewhat address these issues, and these other wikis choose not to opt-in. Further, when spambots are hitting multiple wikis, and the system treats them as separate entities for solutions like rate filtering creations, rather than rate filtering based on a global lever, then it is of limited scope for solutions.  — billinghurst sDrewth 14:32, 31 August 2019 (UTC)

This section was archived on a request by:  — billinghurst sDrewth 12:31, 10 September 2019 (UTC)

Recommendation about notability and reliable sources

The draft recommendation by The Working Group about notability and reliable sources is created recently. This needs wider attention from communities of multiple language projects. George Ho (talk) 08:57, 17 August 2019 (UTC)

New tools and IP masking

Hey everyone,

The Wikimedia Foundation wants to work on two things that affect how we patrol changes and handle vandalism and harassment. We want to make the tools that are used to handle bad edits better. We also want to get better privacy for unregistered users so their IP addresses are no longer shown to everyone in the world. We would not hide IP addresses until we have better tools for patrolling.

We have an idea of what tools could be working better and how a more limited access to IP addresses would change things, but we need to hear from more wikis. You can read more about the project on Meta and post comments and feedback. Now is when we need to hear from you to be able to give you better tools to handle vandalism, spam and harassment.

You can post in your language if you can't write in English.

Johan (WMF)

14:18, 21 August 2019 (UTC)

User claims to be an LTA

See wikt:User:AryamanA/Wonderfool. (the whole section applies only to the user described in the page.) In brief:

1. These users (with more than 100 accounts, though only the last one is not stale) claims to be the LTA Wonderfool, though I don't know whether they are really related to the 2006 Wonderfool account.
2. See also w:Wikipedia:Sockpuppet_investigations/Wonderfool and recent archives of SRG. I don't know the relationship of recent activity in English Wikipedia and the user or the 2006 account either.
3. Many of the accounts are blocked, though almost none are blocked on sight. Most of the accounts are not locked. The accounts usually doing good edits initially, but they are blocked after disruption (probably after thousands of edits). The activity seems markedly different from the English Wikipedia accounts, where they are most vandalism-only users.
4. It seems the English Wiktionary community likes to plays with the user (example, example). This is in contrast with deny recognition.

So the point to discussion:

1. Is it permissible or tolerable that the user be contributed in Wiktionary in the form of #3 and #4? Wiktionary community does tolerate the user and not follow deny recognition, but it is only an essay and can not be enforced.
2. Should the (recent and older) accounts be globally locked? some of the accounts have some edits in other projects, including English Wikipedia. Note if the first point is true, the user is not an uncontroversial candidate for global locks (global lock says "As a general rule, global locks happen almost always in clear-cut situations.").

--GZWDer (talk) 12:35, 19 August 2019 (UTC)

Is your question whether a ban from wiki A should extend to wiki B? Because of course it doesn't.

If the English Wiktionary blocked those accounts for various reasons, but never banned the person, they're free to enforce those blocks as they see fit. Nemo 17:00, 22 August 2019 (UTC)

Translations needed for an approved banner about draft recommendations

I need helpers to translate approved banner proposed at CentralNotice/Request/Draft recommendations from Wikimedia 2030 working groups into at least a few major languages. Thanks. --George Ho (talk) 20:53, 24 August 2019 (UTC)