Jump to content

Stewards' noticeboard

Add topic
From Meta, a Wikimedia project coordination wiki
This is an archived version of this page, as edited by Metrónomo (talk | contribs) at 05:23, 4 January 2014 (→‎Proxy server). It may differ significantly from the current version.

Latest comment: 10 years ago by Metrónomo in topic Proxy server
Shortcut:
SN
<translate>

Welcome to the stewards ' noticeboard. This message board is for discussing issues on Wikimedia projects that are related to steward work. Please post your messages at the bottom of the page and do not forget to sign it. Thank you.

<translate>

<translate>

  • See also: [[<tvar name="in">Access to nonpublic personal data policy/Noticeboard</tvar>|Access to nonpublic personal data policy noticeboard]].</translate>

<translate>

  • This page is automatically archived by [[<tvar name="bot">User:SpBot</tvar>|SpBot]]. Threads older than 30 days will be moved to the archive.</translate>
Stewards
For stewards
Noticeboards

Edit warring over hr.wikipedia sitenotice

See [1]. It seems to be over a request to desysop three administrators, and one of the parties who is revert warring is one of the administrators who is included in the request to desysop. Is something like this (technically a wheel war, but not as serious as warring with the block button) something that stewards generally act on? --Rschen7754 08:53, 28 October 2013 (UTC)Reply

Should wait for the vote to be completed and will see what to do next. Administrators who were make edit war are those they remove administrator rights. --Kolega2357 (talk) 09:27, 28 October 2013 (UTC)Reply

This is local issue. Let the local community handle the situation. Things are under control, if we talk about the sitenotice. Mediterranean temper.
Local community has problems because their most active admins (SpeedyGonsales, Roberta F., Zeljko, myself) were (and still are) victims of media lynch, calumny, OUTING, HARASSING, e-bullying and e-mobbing on Facebook etc. They are defamated. On Facebook, militant activists openly call for violence and physical attacks.
Some people on wiki want to misuse that situation, since the users (whose identity is known) are intimidated. Anyone who opposes to the attackers from Facebook risks being lynched in media and on Facebook, loss of job or not finishing the studies. Kubura (talk) 03:17, 1 November 2013 (UTC)Reply

It has been stopped for ~1 day, no actions are needed now but please inform everyone over there further wheelwars won't be tolerated. Personally I must note using sitenotice for internal processes like vote of confidence is definitely an overkill and, I should also note, hr.wiki seems to be about to have no more sysops. --Vituzzu (talk) 20:07, 1 November 2013 (UTC)Reply

Request for attention

Request: This situation needs outside help and intervention. Could one or two stewards please take a look and weigh in on the latest proposal? Denny, Joy and flopy have all indicated that things are out of control. The recent action of a number of admins to interfere with a desysop discussion was troubling; as were the results: all 3 admins had a ~47/53 vote; the closing admin did not consider arguments but simply counted and said "majority does not support desysop"; drama continues.

I have spent a number of hours reading pages and looking into the discussions (including recentchanges, to avoid overweighting the drama here). My thoughts: editing on the project seems good, but the process for choosing admins and blocking users are troubling. This creates bias over time in who is allowed to edit, and is increasingly distressing half of the active editors. Despite the comments of the criticised admins (above and in the RfC), the local community has not been able to handle the situation. Problems raised here on meta over the past years have only intensified. Whatever happens next, some editors will leave; others are being perma-blocked month by month by current admins, some for political speech or publicly stated positions (with block reasons given as disruption, incivility, hate speech).

As is often the case, those in the spotlight are active good editors, and care about the project; their controversial actions are a result of their passion. As is also often the case, there is bound to be a bit of sockpuppetry somewhere (most of the active editors took part in the recent votes), though I doubt that affects the balance. It is worth checking for sockpuppets, to clear the air. I don't know if local CUs will work - the active local checkusers are caught up in this conflict. And the community needs help implementing other patterns to release the current tension. SJ talk  06:51, 4 November 2013 (UTC)Reply

(Not a steward, but) In my opinion, I am concerned that there are local CUs at that wiki, where a significant minority appears to not trust them; also, stewards cannot view the CU logs (without granting themselves local CU). I have not heard accusations of misuse of CU, but we have no way of auditing such use, save for a request to the Ombudsmen. I personally think this may be one of the most pressing issues, though the other issues need close examination of course. --Rschen7754 07:03, 4 November 2013 (UTC)Reply
A fair point, Rschen. I've also not heard any such accusations. But this does need some persistent attention. SJ talk  06:45, 11 November 2013 (UTC)Reply

CheckUser controversy on croatian wikipedia

The following discussion is closed: not a stewards issue for resolution or discussion. Please see associated RFCbillinghurst sDrewth 00:05, 5 December 2013 (UTC)Reply

Situation on croatian wikipedia is, once again, spinning out of control. About a week ago, hr:user:Imbehind opened a discussion about possible missuses of checkuser tool by SpeedyGonsales, who failed to find hr:user:Croq's sockpuppets in October, while another CU, just a few weeks later, found 10 of them. Imbehind asked for clarification (without making any accusations), but was blocked for "disturbing the project". Me and hr:user:Dean72 also asked for clarification, but received none. After repeated call for clarifications, we were blocked by hr:user:Zeljko (one with WW2 fascist leader en:Ante Pavelić images on his facebook account) on 2 years and 4 days, respectively. Other admins tried to unblocked me (at least 3 of them openly complained about the block), but Zeljko insisted on blockas and now we have wheel-war.

We are waiting for the solution of CW issues for too long. About 2 months ago, user:Miranche asked Mr. Wales if he could list abuses in systematic way. Mr. Jimbo Wales endorsed the idea. After a few extensions, the process of collection of data will be concluded in 4 days from now. Croatian wikipedians are exsausted and tired of fighting the cabal. We can wait for that 4 days, but not much more.

Can we expect some action from Wikimedia after November 30th? --Argo Navis (talk) 14:41, 26 November 2013 (UTC)Reply

What is particularly problematic is the fact that Croq and several of his sockpuppets voted to keep SpeedyGonsales and two other admins in the recent admin recall vote. There is reasonable doubt regarding SG's conflict of interest, since he failed to find what appears to be an obvious connection between accounts that all supported him. I've asked for clarification too, and although I haven't been blocked (maybe that's because I used an editor's talk rather than village pump), I haven't received a satisfactory answer.
To keep the long story short, hr wiki is seriously dysfunctional, blocks are repeatedly used to quell dissent, the admins are rather sharply divided, as is the community, a war-like mentality ("it's us or them") has seemingly prevailed, and it seems to be impossible to establish an open and constructive discussion. I feel it is time to consider serious action, as anything less than a project reset is unlikely to help in the long term. GregorB (talk) 15:53, 26 November 2013 (UTC)Reply
Check this wheel war about my block today. Zeljko blocked me for no reason, 4 different admins tried to unblock me, but he reverted it every time. Talking about tirany... --Argo Navis (talk) 21:15, 26 November 2013 (UTC)Reply
You are on the stewards' noticeboard, which is where the volunteer stewards can coordinate response to matters within our scope as permitted by the community; this is not a board used by the officials of the Wikimedia Foundation. The hrWP wiki is outside the remit of the volunteer stewards, and there is nothing that we can do to process or progress this issue. If your approach is to the Wikimedia Foundation or its board, then you will need to use the designate means to do so. If your complaint is about the potential or the clear abuse of the CheckUser tool, then please address those to the Ombudsman Commission which has the remit on that matter. — billinghurst sDrewth 13:35, 27 November 2013 (UTC)Reply
However wheel-warring is a reason for emergency desysop in some cases. Zeljko is wheel-warring against four other administrators. Ruslik (talk) 02:19, 28 November 2013 (UTC)Reply
Correction to Argo Navis -- I was among the group of users who initiated the evidence gathering pages per WP:BOLD; Jimbo was not involved in this decision. We let him know after we had already started & he then endorsed the idea.
I am not familiar with wheel war policies, so I have no input regarding that particular incident. Reading the CU issue, the Ombudsman Commission certainly seems like the appropriate venue. But solving overall issues at hr.wiki will almost certainly need Wikimedia Foundation involvement. Miranche (talk) 05:42, 4 December 2013 (UTC)Reply
Well, User:Sj is a member of the WMF Board. --Rschen7754 05:55, 4 December 2013 (UTC)Reply

How can Zeljko to stay administrator? After more than a few serious violations of the administrator rights. --Kolega2357 (talk) 13:48, 28 November 2013 (UTC)Reply

The question to ask is, who can evaluate his behavior and act upon it? Miranche (talk) 05:42, 4 December 2013 (UTC)Reply
Closed Closed this is not an issue for the resolution of stewards. There are admins, bureaucrats that are answerable to the community or community processes. There are checkusers answerable to the Ombudsman Committee. Stewards have no authority to intervene without direction from the WMF board, or local bureaucrats. — billinghurst sDrewth 00:05, 5 December 2013 (UTC)Reply

Inactivityrule nlws

The following discussion is closed: Rights of the inactive admins removed per request on SRP. Trijnsteltalk 23:11, 9 December 2013 (UTC)Reply

In response to the following message at the dutch wikisource. inactive sysops. I would like to point out that nlws has an inactivityrule for sysops being that every sysop loses his rights after having less than 20 edits over a period of 12 months as stated here: rules inactivity. Asacha (talk) 10:01, 7 December 2013 (UTC)Reply

Thanks for this information, Asacha. However, please note that if stewards should enforce this inactivity policy by removing the inactive sysops, you need to make such requests on SRP. --MF-W 13:50, 7 December 2013 (UTC)Reply

inactivity hu.wikiquote

As per QuiteUnusual's message: I am alive and well and I usually appear on small hu language wikis (where there are no admins or the amount of admins/community activity is low) on requests. Sodomising my admin bit would result inability to handle problems and tasks which otherwise would fall on stewards quite unnecessarily. I cannot really pull up community support on wq since it's mostly edited in a fire-and-forget fashion; if it helps the other 2 admins can sign their support here, if you insist. Thanks. --grin 14:12, 11 December 2013 (UTC)Reply

You don't need to demonstrate support, as you are still active no rights will be removed. QuiteUnusual (talk) 14:42, 11 December 2013 (UTC)Reply
That is not true; grin only now made the first edit after 3 years (after the notification). Therefore the AAR process for keeping the rights should be followed (=discussion/decision by local users which show up). --MF-W 15:58, 11 December 2013 (UTC)Reply
Okay, you're the boss ;-) QuiteUnusual (talk) 17:43, 11 December 2013 (UTC)Reply
Yep, that's another bad example where bureaucrazy takes over common sense. My guess the original intent was deactivate unreachable people or those who do not want and need the flag anymore, but right now it's another "administratively controlled substance". I spare you from the rant about making more work for stewards, alienating people who offered their help and generally generating more noise than content. That's the way ah-ha ah-ha I like it ah-ha ah-ha... ;) But anyway, I'll ask all the active users to sign here, and let's hope both will come. :-) --grin 13:39, 12 December 2013 (UTC)Reply

┌─────────────┘
Thank you for your patience, and apologies for the long holding tone, your call is important to us. Please… oh, no, that's another recording. So, the strong community support arrived for your viewing pleasure here around in vast amounts. I'm happy that we're progressing according to the books. Am I declared innocent, Your Honour? :-) (Let me repeat, again, that the process is faulty and possibly against the original intentions.) (Also thanks for QuiteUnusual's positive approach, which nowadays is, well, quite unusual. :-]) --grin 11:15, 13 December 2013 (UTC)Reply

Based on the level of support for you to retain the rights, I see no reason for them to be removed. QuiteUnusual (talk) 08:26, 16 December 2013 (UTC)Reply

@Grin: The inactivity policy is about alerting a community to the extended non-presence of their people with elevated rights, and then letting the community to determine the actions to be taken. If your presence in the community had been evident, then we would not have needed to do a thing. There is a whole consultative process that was undertaken, so rather rehash that here, I invite you to go and read it Requests for comment/Activity levels of advanced administrative rights holders. Call it bureaucratic, administrative, ... the whole purpose is to be fair to the communities to know that their advanced rights holders are still present and active. — billinghurst sDrewth 14:51, 16 December 2013 (UTC)Reply

Usurpation policy

Hi. Is anyone still interested in this proposal? How would this work with usurping global accounts after SUL finalization? PiRSquared17 (talk) 02:49, 25 December 2013 (UTC)Reply

With the proposed global accounts there should be no need for usurpation. At this point of time, I see that usurpation is a local issue for local communities and their bureaucrats.  — billinghurst sDrewth 10:21, 25 December 2013 (UTC)Reply
Indeed; usurpations won't happen anymore once SUL is finalized finally. --MF-W 00:02, 26 December 2013 (UTC)Reply

Renaming namespaces

Hi, i found a little problem. On ro.wiki namespace ”Module” is not translated correctly.
Currently it's name is "Module", but this is not proper name for romanian language.
In romanian language:

module = modul
module_talk = discuție_modul

Without "e" at the end! In romanian, if you put "e" at the end, it will become the plural. So, currently we have there all namespaces at singular (normally), and only module is at plural.

I asked our local birocrats at "Village Pump" if they can rename namespaces, but no one reply in 2 ¾ days. Probably they can't, so i decided to write here. Thank you. XXN (talk) 17:59, 1 January 2014 (UTC)Reply

<non-steward answer>(Btw, this is not a Steward-thing). Also on fi-wiki it's named as "module" when it should be "moduuli". I've tried to find the correct place to change those translations, but I'm not sure where to do it. It's not possible in Translatewiki. Translations for Module namespace were asked on Meta many months ago (also Gerrit change), but when it was asked there I didn't know about that. So maybe we should make a request on Bugzilla to rename those namespaces. --Stryn (talk) 18:20, 1 January 2014 (UTC)Reply
The correct place to ask is translatewiki:Support. --MF-W 18:24, 1 January 2014 (UTC)Reply
Yeah, the translation updater bot handles this automagically (you need to submit a patch to gerrit). Just ask on TWN. PiRSquared17 (talk) 18:25, 1 January 2014 (UTC)Reply

Thank you for redirection to right place to solve my problem. --XXN (talk) 19:35, 1 January 2014 (UTC)Reply

I also asked Matma Rex to help us with this issue. Rsocol (talk) 05:34, 3 January 2014 (UTC)Reply

Patch submitted: https://gerrit.wikimedia.org/r/105175 – it should go live within a few weeks (16 January on Wikipedias if everything goes right), see mw:MediaWiki 1.23/Roadmap. Matma Rex (talk) 13:15, 3 January 2014 (UTC)Reply

Checkusers on loginwiki

Stewards nowadays often do checkuser actions on loginwiki for crosswiki checkuser activities like identifying spambots, interrogating IP ranges for effects of potential global blocks, and the identification of accounts undertaking crosswiki long-term abuse. In loginwiki's checkuser data every creation of a global account is recorded once. No other data (e.g about edits) are there because no edits happen on that wiki.
You can see the frequency on Special:Log/rights, which nowadays is cluttered by such actions ("permanent link": [2], e.g. [3], [4]).
The setting and removing of the checkuser rights on one's own account everytime one does a check is quite annoying and one also tends to "forget" (either really or intentionally to save clicks for the next check) to remove the flag at times. For this reason, I'd like to announce in the name of stewards that from now on those who want will keep the checkuser rights on loginwiki permanently (of course it will be removed when they stop to be stewards).
For the information of the community, we will create Stewards/CheckUser statistics for loginwiki (similar to commons:Commons:Checkusers/Statistics and en:Wikipedia:Arbitration Committee/Audit Subcommittee/Statistics) so that everyone can still see who is active doing CU actions there. --MF-W 21:09, 2 January 2014 (UTC)Reply

Sorry, but you are not announcing anything here in the name of stewards as there isn't consensus even between stewards (specially when it is said that stewards are intentionally "forgetting" to remove rights). Stewards are not in position to announce such change; we are not allowed to disobey checkuser policy, that says:

If local CheckUsers exist in a project, checks should generally be handled by those. In emergencies, or for multi-project CheckUser checks as in the case of cross-wiki vandalism, Stewards may perform local checks. Stewards should remove their own CheckUser access on the projects upon completion of the checks and notify the local CheckUsers or the CheckUser e-mail list.

So, local rights are temporary and we have to remove it upon completion of checks. There is no exception. If time has come to change it, fine. Let us discuss that with community and change policy. I think that may be a good idea. However, we are not the ones empowered to decide in the name of community.
At least, two stewards were not agreed on a not really long discussion on list. Please, revert that as you can't add checkuser rights without a valid reason. In fact, you just can't add permanent CU rights for yourself with any reason.
I understand you have good intentions on doing that and want to improve stewards' capacities to better deal with spambots, but, even though in good faith, we have to follow regular procedures, we have rules to follow, we have a community to listen to and make this kind of decision in our name; not the opposite. Regards.—Teles «Talk to me ˱C L @ S˲» 17:38, 3 January 2014 (UTC)Reply
Well, a discussion started on stewards' mailing list a week ago; the announcement draft was sent by me 5 days ago. At the time I posted this, there were no stewards who had expressed disagreement, so I could very well have announced this in the name of stewards. By the way stewards did express on the list that they intentionally don't remove their CU rights there.
About the quote from CU policy, I already said on the ML that that whole section only talks about what to do on projects with local CUs.
I couldn't find anything in Stewards policy or CU policy that says explicitly that rights we self-grant in order "to act as a member of any permissions group on any project with no active member of that permissions group" (S) must always be removed. It is reasonable of course in most cases, but not here. For the same reason, the global group already contains permissions that local sysops, crats etc. have. In fact, I think nothing policy-ish prevents us from creating a global group which would have checkuser rights, and be restricted to wikis without local CUs. --MF-W 18:03, 3 January 2014 (UTC)Reply
  • I also would like to note my disagreement with the feelings and reasoning expressed by the statement posted here. I strongly believe that granting ourselves permanent CU access on a local wiki is a violation of both the letter and the spirit of the Checkuser policy as well as being in general a bad idea without the updating of policies to proper regulate this new development.. I offered full reasoning for this in two post to the mailing list that I made after this was posted. While I disagree with the feelings expressed, I think it was entirely fair for MF-Warburg to post the statement as at the time no objections to its content, as I understand it, had been made on the mailing list or elsewhere. And no, MF-Warburg, the Checkuser policy does prevent us from having any sort of global CU, specifically stating that such a thing is restricted to the OC. Snowolf How can I help? 19:17, 3 January 2014 (UTC)Reply
    • Hm yes, you are probably right on global CU; I retract this stuff about the possibility to create a global group with checkuser rights. I'll catch up with the ML posts soon. --MF-W 00:07, 4 January 2014 (UTC)Reply

Proxy server

Please, translate it. Thank you.

Hola, soy un administrador de la Wikipedia en español y detecté que el rango 14.32.0.0/11 pertenece a servidores proxy. Pero debido a que es muy amplio, no me animé a bloquearlo. ¿Pueden ustedes confirmar esto y tomar las medidas necesaria? Gracias anticipadas. --Metrónomo-Goldwyn-Mayer 05:22, 4 January 2014 (UTC)Reply