Meta:Babel/Archives/2020-05

Proposal to amend Meta:Interface administrators

Hello. I have started a proposal for a little amendment to our Meta:Interface administrators. The discussion can be seen at the talk page. Thanks. —MarcoAurelio (talk) 10:16, 6 May 2020 (UTC)

This section was archived on a request by: Sgd. Hasley 14:55, 20 May 2020 (UTC)

Proposal to add Lenta.ru to the global spam blacklist

Lenta.ru earlier this year is in the English Wikipedia spam blacklist entry. Lenta.ru over the years has published fake news, conspiracy theories and propaganda, just like Alex Jones' InfoWars.The Guardian I think that Lenta.ru should be added to the global spam blacklist in order to prevent COVID-19-related conspiracy theories. 139.101.127.181 10:24, 18 May 2020 (UTC)

Please make requests for consideration for global blacklist to Talk:Spam blacklist. Adding conversations to this page for that list will gain little discussion as it isn't the place.  — billinghurst sDrewth 02:18, 19 May 2020 (UTC)

This section was archived on a request by:  — billinghurst sDrewth 09:10, 30 May 2020 (UTC)

Propose to amend Meta:Snowball

After Stewards'_noticeboard#Steward_requests/Global_permissions#Global_rename_for_Joseluispasa, we have a second request on SRGP that is clearly not going to pass. I propose to add the following to Meta:Snowball:

==Exception==
Any request that is purely disruptive, or suggests that the requester is going to the wrong venue, may be closed by any uninvolved steward or Meta-Wiki administrator, or any uninvolved user in good standing if the requester is indefinitely blocked in Meta or globally locked.

Note:

• One may argue IAR, but using IAR repeatly means the policy should be amended.
• An example the second case (wrong venue) is Steward_requests/Global_permissions/2014-09#Global_rename_for_Shibuki_803
• This will work in parallel with the amendment of SRGP which only allow closure request only by stewards and after a reasonable amount of input.

--GZWDer (talk) 15:30, 16 May 2020 (UTC)

That policy has only ever applied to closing and implementing a successful discussion early. Votes have been and can continue to be closed when they are clearly in the wrong place, the person has absolutely no chance of passing, etc. This was also confirmed in a discussion for SRGP within the last few years. – Ajraddatz (talk) 16:24, 16 May 2020 (UTC)

I don't see a need for adding this exception. Nemo 18:21, 16 May 2020 (UTC)

@Ajraddatz and Nemo bis:

• Among Wikimedia project using snowball on successful permission requests seems rare.
• Votes have been and can continue to be closed when they are clearly in the wrong place, the person has absolutely no chance of passing, etc. - this means we are (harmlessly) violating the established rule. Alternatively this means the rule should be rewritten. See File:Diagram_of_IGNORE.svg.
• "This was also confirmed in a discussion for SRGP within the last few years" - I mention the amendment above, which only allow stewards to close the request and only after a number of inputs.

--GZWDer (talk) 19:55, 16 May 2020 (UTC)

• Comment Meta:Snowball does not apply to stewards' pages, it is for metawiki business alone. Stewards/community are welcome to adopt it as required, though I don't think that it should be adapted in the formats expressed to cover stewards' business.  — billinghurst sDrewth 22:36, 20 May 2020 (UTC)

Not done No support for this proposal. --MF-W 00:40, 21 June 2020 (UTC)

A transparent appeal venue for users locked out of local talk pages

The following discussion is closed: User blocked. ——SerialNumber54129 08:03, 20 May 2020 (UTC)

---

Accepting the general point that Meta is not an appeals court, what do people here think of carving out a specific portion of this project for use as a venue for appealing instances of local project user talk page lockouts, as typically the next and final step after a local block. I think this would provide much needed transparency and a sort of brotherly sanity check to counter the incredible power that such a thing represents to local functionaries. To completely shut a user out of a project, after all, is an extreme measure that should be deployed only in response to extreme threats, or at the very least, incontrovertible abuse of the page. Whenever a local project locks a user out of their talk page, they would be provided a link to the Meta appeals venue, where independent functionaries would respond, either upholding or rejecting the appeal. If people here have no appetite for a general case appeal venue, then perhaps it can be one that can only be used if the user's case satisfies certain qualifying criteria, such as a reasonable belief that availing themselves of the local private channels would put their personal data at risk, or that the manner of the lockout was so egregiously bad, seen from the outside, the user would probably be justified in preferring to contact the media rather than spend their time and energy navigating local private channels. It strikes me that such a venue would not only be a nice way to show local projects do not hold certain users in contempt, seeing the process of locking people out as some kind of grand game of chicken, as if they only want to test their willingness to actually use private channels to challenge a lockout, it would also stop that apparently unwanted behaviour of the next logical step for a user locked out of one project, to want to take the matter up on other projects, including of course, Meta, much to its apparent irritation. BarryBoggside (talk) 19:53, 18 May 2020 (UTC)

•  Oppose Most projects already have a local method of doing this most involve IRC or email. One is not needed on meta as only local admins would be able to solve that problem. -Examknow (talk) 20:31, 18 May 2020 (UTC)

The proposal is for people who cannot or will not use private channels, for very good reasons, such as protecting their privacy. Is it impossible for you to even conceive of such a scenario? What makes you assume private channels will keep your information secure, or that complaints submitted privately are always handled properly? Have you ever tested this assumption? Have you ever even been locked out of a local project? BarryBoggside (talk) 21:03, 18 May 2020 (UTC)

Also if you are only looking for a way to be unblocked on the English Wikipedia since your TPA has been revoked, please see en:WP:AAB. -Examknow (talk) 20:34, 18 May 2020 (UTC)

I am not. Take the proposal in good faith, or not at all. Don't simply oppose it because you cannot believe anyone here would want to help anyone but themselves. BarryBoggside (talk) 21:03, 18 May 2020 (UTC)

Comment Meta is not an appeal court. Wikis look after their local management of their wikis, so bringing formal processes here as a means for alternate resolution is just rehashing a closed conversation; it sounds like an appeal court. The resolution is able to be determined at that language wiki, so there is no need to bring it out of the wiki. We understand "I don't like the decision", however, each wiki is self-managing, and that means that their decisions hold where there is a suitable and significant community.

That said many users over the years have made enquiries at meta with those administrators of their local wikis about processes, and opportunities and that is acceptable as long as it done with civility and as a reasonable approach. Some have done it as a continuing attack on their local administrators, and that is not considered acceptable.  — billinghurst sDrewth 02:29, 19 May 2020 (UTC)

As I thought I had already made clear in the very first line, this would be a justified exception against 'Meta is not an appeals court', and given the reasons for it. Suffice to say, this is not about giving people who merely dislike a local decision, an alternative outlet. It is a recognition that there are going to be situations where even a large community can make an egregious mistake in how it wields this ultimate power of exclusion, and before the excluded user is forced to either put their personal data at risk, or persuaded they are better off trying to capitalize on it through negative media coverage, there is a sensible and indeed ethical role for Meta to play, one that at the very least can be seen as entirely in the interests of the local communities, to the point it should be possible to support it even if you were the sort of person who assumes, before it is even live, that every single person who arrived there, will not have a valid case. BarryBoggside (talk) 10:01, 19 May 2020 (UTC)

• @Billinghurst and Examknow:, now that User:BarryBoggside has been established to be a sock of AttackTheMoonNow on en., this should clearly be opposed as a blatant attempt to weaponise one wiki against another. ——SerialNumber54129 06:26, 19 May 2020 (UTC)

  I will discuss the issue on the premise of the argument, not the proponent.  — billinghurst sDrewth 06:45, 19 May 2020 (UTC)

  Weopnise is an apt phrase, only in the sense that the proposal is in effect a counterbalance in the same vein as opposing nuclear arsenals. It is a means to ensure local projects don't, through their own sheer collective hubris and group-think, or simple internal power dynamics, amass a power at their highest levels so great it is possible for them to wholly disregard what are in reality meant to be community wide norms and expectations, such as this idea people's personal data is sacrosanct, or that it is only the Foundation (or the entire movement acting in their name) who can block a user forever. Although quite how far that analogy holds when in this case the United Nations would also have a sovereign base in Switzerland with their own missile silos, for use against any rogue nation not upholding their values, up to and including the US, is open for debate. Perhaps we are still at the stage of the movement's development that en.wiki is as powerful and unassailable as the U.S. is to the UN, and places like Commons (Canada) are not independent in the true sense, not when there are so many close ties between it and the U.S. But it is ironically the Wikimedia Movement who are apparently working to rectify that issue, on behalf of the whole world, through appealing to a notion of universal human rights. The proposal therefore is no more threatening to local projects than the establishment of international criminal courts should be to the U.S. If they have nothing to cover up, they have nothing to fear from a genuinely independent and wholly public appeal mechanism, whose scope is necessarily limited to only challenging the most draconian measure any local functionary can implement as an individual, in the name of their local project. The local private channels will still be available for those who think they have a reasonable expectation of their use will not merely compound or even exacerbate the original abuse, hence the suggestion of using qualifying criteria in this proposal to show there is reason to believe that is unlikely, if an appeal mechanism for the general case is rejected. BarryBoggside (talk) 10:01, 19 May 2020 (UTC)

• The mention of my supposed connection to "AttackTheMoonNow" is entirely irrelevant, to the point I am now struggling to see why it was mentioned here at all, in that context. I will say though that it is relevant in the sense that my talk page lockout at en.wiki prevents me from appealing these further charges using local procedures, for reasons of personal data security, but that is as far as I will risk going here in terms of details or accusations on the specifics of my case, on the understanding this proposal is not about me, but the protection of future victims of this sort of tactic of using local lockout powers not as a defensive mechanism, but as an offensive one, a powerful weapon that can and should have a counterbalance, at least in any movement that genuinely believes in transparency and equanimity. BarryBoggside (talk) 10:45, 19 May 2020 (UTC)

Centralized discussion on standardizing format of COVID-19 maps

You are invited to join the discussion at w:Wikipedia talk:WikiProject COVID-19#Continued discussion on standardizing map format. Sdkb (talk) 21:26, 21 May 2020 (UTC)

This section was archived on a request by: Sgd. —Hasley 01:24, 21 June 2020 (UTC)

Enabling events calendar gadget for all

On the page Events calendar there is an embryo for a Wikimedia wide events calendar, which could be really useful. However, in order to get full functionality, one has to enable two user scripts (see How to use it). I suggest that we add those as a gadget, enabled for all by default. That way everyone can easily interact with no hassle, and those who have no interest have a way to turn it off. Besides getting consensus around this, we'll need an interface administrator to turn it on. Ainali (talk) 07:35, 30 May 2020 (UTC)

Gadgets should only be added as default ON for compelling reasons. I don't see a compelling reason.  — billinghurst sDrewth 09:13, 30 May 2020 (UTC)

The compelling reason is that anyone would be able to both edit and navigate the events calendar which brings this tool up to the usability level of the rest of the wiki. Ainali (talk) 10:56, 30 May 2020 (UTC)

That is not a compelling reason to have a gadget, let alone one turned on by default. How many people do you suspect will use it? I see 82 people have installed it and 2 people have used it in three years. How many IP editors will be among that group of people who will be editing it. I suspect that the group of users will be relatively small for the population of users of metawiki, so a default gadget simply doesn't make sense. I suggest that maybe start the discussion about the addition of the gadget at MediaWiki talk:Gadgets-definition  — billinghurst sDrewth 23:03, 21 June 2020 (UTC)

Well, this is of course a chicken and the egg problem. If people are not aware of it, no one will enable it. Now, the calendar has also suffered from the deviation of the calendar that was set up at Space. But the proper place for an all movement calendar is here at meta. Let's get that one working. It has potential to be used by all affiliates, which probably make up quite a fair amount of those active on meta. Ainali (talk) 20:05, 23 June 2020 (UTC)

That makes sense. I support it. --MF-W 00:46, 21 June 2020 (UTC)

@Ainali: instead of making this a default gadget - can't it just be an opt-in gadget? That makes maintaining and the instructions easier. — xaosflux ^Talk 01:39, 22 June 2020 (UTC)