Wikisource:Administrators' noticeboard

Wikisource snapshot

No. of pages = 4,312,335
No. of articles = 1,042,984
No. of files = 16,358
No. of edits = 14,180,701

---

No. of pages in Main = 597,781
No. of pages in Page: = 3,227,975
No. validated in Page: = 640,243
No. proofread in Page: = 1,240,084
No. not proofread in Page: = 1,056,707
No. problematic in Page: = 44,442
No. of validated works = 6,414
No. of proofread only works = 6,217
No. of pages in Main
with transclusions = 393,134
% transcluded pages in Main = 65.77
Σ pages in Main

---

No. of users = 3,125,454
No. of active users = 409
No. of group:autopatrolled = 500
No. in group:sysop = 23
No. in group:bureaucrat = 2
No. in group:bot = 17

Statistics
User preference statistics
Special:Statistics

Checkuser requests

• Wikisource:checkuser policy
• At this point of time, English Wikisource has no checkusers and requests need to undertaken by stewards
  • it would be expected that requests on authentic users would be discussed on this wiki prior to progressing to stewards
  • requests by administrators for identification and blocking of IP ranges to manage spambots and longer term nuisance-only editing can be progressed directly to the stewards
  • requests for checkuser

Bureaucrat requests

• To request a global rename, go to Special:GlobalRenameRequest.

Page (un)protection requests

Request protection of Main Page templates

According to the very first point under Wikisource:Protection_policy#Special_cases “The main page should always be protected…”, yet this edit took place today. Some care and attention, please? (Normally Phe-bot is the sole updater of Template:ALL TEXTS!) 114.73.248.245 17:57, 15 October 2018 (UTC)

Thanks. I have place soft protection on the page. — billinghurst sDrewth 20:09, 15 October 2018 (UTC)

 Comment To fellow administrators, I have up'd the protection on a couple of templates that won't need updating. I have a question about Template:Highlights, should this be sitting at semi/soft? If we are unlikely to change it, then we should be protecting it further. — billinghurst sDrewth 20:27, 15 October 2018 (UTC)

Other

Resource Loader issue needs outside guidance

The more I read up on this RL change and the subsequent actions needed (or taken?), the more I get the feeling some of my approach to site wide & gadget .js/.css organization over the months is going to behind this week's latest problems. If that winds up to be the case, then I'm truly, truly sorry for that. Let me try to document those steps and the reasoning behind them in hopes someone (@Krinkle:) can made sense of our current state and put us on the right path post RL change(s).

Originally, we not only had a ridiculous amount of scripting and .css definitions in our primary site-wide MediaWiki files to begin with but also called a number of stand-alone .js/.css files within those primary MediaWiki files called unnecessarily in addition to calls to various sub-scripts on top of any User: selected gadgets being called -- some of which eventually became default loaded per concensus, etc..

A simple depiction of the key files mentioned minus any Gadgets basically went like this...

MediaWiki:Common.js called MediaWiki:Base.js calls MediaWiki:PageNumbers.js calls MediaWiki:IndexForm.js called MediaWiki:OCR.js calls MediaWiki:DisplayFooter.js called MediaWiki:Dictionary.js called MediaWiki:Corrections.js calls MediaWiki:InterWikiTransclusion.js called MediaWiki:Common.js/IEFixes.js called MediaWiki:Common.js/watchlist.js and a few others I can't recall

MediaWiki:Common.css called MediaWiki:Common.css/Boxes.css called MediaWiki:Common.css/Lists.css called MediaWiki:Common.css/Mainpage.css called MediaWiki:Common.css/Tweaks.css and a few others I can't recall

Over several months with help of other folks, I began to consolidate and/or eliminate as much scripting calls as I could -- creating optional Gadgets whenever possible -- and tried much the same for the .css class definitions. The rationale behind doing this can be found in several places, most importantly: Wikipedia. The premise to keep the MediaWiki site-wide files "lean" goes like this....

 /**
 * Keep code in MediaWiki:Common.js to a minimum as it is unconditionally
 * loaded for all users on every wiki page. If possible create a gadget that is
 * enabled by default instead of adding it here (since gadgets are fully
 * optimized ResourceLoader modules with possibility to add dependencies etc.)
 *
 * Since Common.js isn't a gadget, there is no place to declare its
 * dependencies, so we have to lazy load them with mw.loader.using on demand and
 * then execute the rest in the callback. In most cases these dependencies will
 * be loaded (or loading) already and the callback will not be delayed. In case a
 * dependency hasn't arrived yet it'll make sure those are loaded before this.
 */

The result of that effort as it stands today can be depicted basically like this....

MediaWiki:Common.js calls MediaWiki:PageNumbers.js calls MediaWiki:IndexForm.js calls MediaWiki:DisplayFooter.js calls MediaWiki:InterWikiTransclusion.js MediaWiki:Gadget-Site.js calls MediaWiki:Common.js/watchlist.js calls MediaWiki:InterProject.js

MediaWiki:Common.css calls MediaWiki:Coltest.css calls MediaWiki:Dynimg.css MediaWiki:Gadget-Site.css calls MediaWiki:Gadget-enwp-boxes.css calls MediaWiki:Gadget-enwp-lists.css calls MediaWiki:Gadget-enws-mainpage.css calls MediaWiki:Gadget-enws-tweaks.css and a few others basically still being tested

The predominant change in order to move towards the previously cited rationale & approach is that the bulk of the scripting and class definitions now reside in the default-enabled Site gadget files, MediaWiki:Gadget-Site.js & MediaWiki:Gadget-Site.css. And by no means is the current state the desired final approach; its been a work in progress as time allowed over several months.

Obviously, now with the recent change to Gadgets and ResourceLoader, either the existing rationale or my attempts (or both) are no longer in harmony -- if they ever were. In my view, we need someone like Krinkle (or maybe the collective minds of Wikitech-l?) to take the time and attention needed to come in here and straighten all this out -- one way or the other. My gut tells me THAT will resolve the reported loss of one thing or another post-RL change(s). Again, if I'm right about my actions exacerbating problems for other, I apologize and take full responsibility. -- George Orwell III (talk) 20:54, 8 August 2015 (UTC)

I've made a few minor changes in addition to yours that hopefully make things work a bit more like you intended. I'm happy to provide further guidance but that probably works better for a more specific need or question. Perhaps bring it up on Wikitech-l or on IRC so we I can help you move forward with any unresolved issues. Krinkle (talk) 21:37, 20 August 2015 (UTC)

Interface administrators

Hi. Please see https://www.mediawiki.org/wiki/Topic:Unisfu5m161hs4zl. I do not remember if this was already discussed and how it is going to be addressed. Comments and suggestions welcome.  Comment As far as I am concerned I would trust any admin who feels skilled and confident enough to tackle such edits.— Mpaa (talk) 21:05, 29 October 2018 (UTC)

I can handle the technical aspects of it. However, it can take me a while to get around to tasks that take longer than a few minutes, so I don't want to create a false expectation of being able to handle time sensitive matters on my own. —Beleg Tâl (talk) 02:35, 30 October 2018 (UTC)

We should decide how to address the fact that EnWS has no m:interface administrators. I see basically the following options. Please add/amend as you feel appropriate.

Option A - Assign right on demand when needed

Option B - Assign right permanently to willing Admins, to be reviewed in the confirmation process

As I said above, I am for the simplest one.— Mpaa (talk) 21:28, 30 October 2018 (UTC)

Option C - Assign right permanently to selected Admins, after approval process, to be reviewed in the confirmation process

Option C sounds like you're being volunteered (based on the lack of the word 'willing'). ;) --Mukkakukaku (talk) 06:27, 31 October 2018 (UTC)

Option D - assign the rights to all the admins, who have already been vetted for community approval, and then whoever has the ability and desire can make use of it as they will and as needed. —Beleg Tâl (talk) 13:33, 31 October 2018 (UTC)

Option D would make the most sense for us. For anyone to get themselves to the point that we trust them with the admin tools just so that they can mess around in the interface, they would be playing a very long game. Beeswaxcandle (talk) 22:05, 2 November 2018 (UTC)

I agree with Beeswaxcandle, Option D, although I would also be fine with the right only going to admins who express an interest. BD2412 T 23:00, 2 November 2018 (UTC)

It is so rare I disagree with Beeswaxcandle but this must be one of those times. The whole point of this change is to prevent the ignorant from accidentally screwing up - insulting as the implications undoubtedly are! As such under the new regime trust is no longer enough; perhaps somebody ought to draw up some kind of eligibility examination…? 114.73.248.245 23:03, 2 November 2018 (UTC)

That hasn't been an issue for us yet, and accidental changes are easily reversed. If we had more users it would be more of a problem, but as it stands this kind of distinction is more cumbersome than helpful in my opinion. —Beleg Tâl (talk) 00:08, 3 November 2018 (UTC)

As much as I like the idea of making all existing admin interface admin, IA were separated from regular adminship specifically to reduce attack surface(from hackers), and it was pretty dangerous if the access fell into the wrong hand, I'd rather propose having existing admin request right from bureaucrat and could be granted at the bureaucrat's discretion, and should be automatically removed if no action after two month.Viztor (talk) 02:13, 10 August 2019 (UTC)

•  Comment we discussed it when the rights were split, and it was agreed that it could be assigned on a needs basis. That has been done at least once for me with the temporary assignation of the IA rights. — billinghurst sDrewth 05:58, 10 August 2019 (UTC)

  Note that WMF Legal requires 2FA to be enabled for users who are to be assigned this right, so bureaucrats will have to verify this before doing so. MediaWiki's 2FA implementation is also sufficiently finicky that one may not want to enable it without proper consideration. --Xover (talk) 08:21, 10 August 2019 (UTC)

  What's wrong with the 2FA implementation? I haven't had any issues with it at all. —Beleg Tâl (talk) 22:17, 10 August 2019 (UTC)

  Ah, sorry, I should have been more clear. I am going on hearsay, mostly from admins on enwp (a crotchety bunch if ever there was one), and my own assessment of the documentation at meta. The main complaints are that the implementation in general is a little bit primitive (as is to be expected since WMF rolled their own instead of federating with one of the big providers), and that there is no way to regain access to your account if something goes wrong with the 2FA stuff (if your phone is stolen etc.) unless you happen to know one of the developers personally. None of these are in themselves showstoppers, and many people are using it entirely without issue. The phrasing sufficiently finicky that one may not want to enable it without proper consideration was not intended to discourage use, but merely to suggest that it is worthwhile actually giving it a little thought before requesting it be turned on. --Xover (talk) 17:52, 11 August 2019 (UTC)

  Okay, gotcha. As it happens, Wikimedia 2FA does include emergency access codes for use when your phone is unavailable. —Beleg Tâl (talk) 19:56, 11 August 2019 (UTC)

Transwiki Import request

Per this post and this Wikipedia deletion debate. Admins over there would like to transwiki Full translation of the Behistun Inscription over here (likely to Translation:Behistun_Inscription). –MJL ‐Talk‐^☖ 20:09, 28 May 2019 (UTC)

This is a published translation (in 1907, see footnote [1]), so it would not go into the Translation namespace. However, we would need a copy stripped of all the added images and commentary. A second (annotated) copy containing reference images and wikilinks could be hosted once a stripped down copy of the original was in place. --EncycloPetey (talk) 20:58, 28 May 2019 (UTC)

@EncycloPetey: {{Done}} No wait, I forgot the Wiki-links. –MJL ‐Talk‐^☖ 22:31, 28 May 2019 (UTC)

Now it's Done –MJL ‐Talk‐^☖ 22:43, 28 May 2019 (UTC)

• I have copied the trimmed form of w:Full translation of the Behistun Inscription to Translation:Behistun_Inscription; I then reverted w:Full translation of the Behistun Inscription to the full form with notes. Anthony Appleyard (talk) 22:51, 28 May 2019 (UTC)

  I have moved the text to Behistun Inscription (King and Thompson) because this is a published translation from 1907, and not a Wikisource original translation. When the annotated version is transwikied, it should go to Behistun Inscription (annotated) and have a pointer to the unannotated version. --EncycloPetey (talk) 00:17, 29 May 2019 (UTC)

  @EncycloPetey: Could you please import the page history as well? –MJL ‐Talk‐^☖ 01:52, 29 May 2019 (UTC)

  I don't have the ability to do that, as far as I know, and my computer is incompatible with the mechanism used for transwiki imports. There are only a couple of admins here who might be able to transwiki a file from Wikipedia, and I can't recall the last time we did so, or who performed the action. Billinghurst, Hesperian, DeirdreAnne, or Jusjih are the admins most likely to know what to do. --EncycloPetey (talk) 03:08, 29 May 2019 (UTC)

  Every admin has the ability to transwiki import, it is XML that is restricted. Rights expressed at special:listgrouprights#sysop. The source of import is configured on an individual wiki level, and we have enWP on that dropdown list. — billinghurst sDrewth 10:58, 29 May 2019 (UTC)

• I have transwiki'ed w:Full translation of the Behistun Inscription and moved the result to Translation:Behistun Inscription. I ticked the wrong box so the edits in its revision history are assigned to the enwp users rather than the local users, but that should be a mostly cosmetic issue; its full revision history is included. I put the one with full history in the Translation: namespace since the richest version (the annotated one) is the one with the most edits, and the mainspace version is in effect a cut&paste move of a pared down version. For revision history this makes sense, even if for policy purposes the bare version should be primary and come first, and the annotated version be secondary and follow after. For technical reasons, both versions cannot have full revision history (each edit has a unique identity and can only exist once on a given wiki). Translation:Behistun Inscription now needs cleaning up (redlinks, enwp templates, etc.), and Behistun Inscription (King and Thompson) needs to refer to it for attribution purposes. --Xover (talk) 05:44, 29 May 2019 (UTC)

 comment about import I am a little surprised to see the work here in the current form, as that is an excerpt of what was published, and out of context of its publication. It isn't our task to rescue enWP's out of scope works just because. — billinghurst sDrewth 11:01, 29 May 2019 (UTC)

I acted on my understanding of the above discussion that suggested the issue was simply one of annotated—unannotated, and since an unannotated version was provided the annotated one could be hosted here. If there are further issues with it then my importing of it should not be taken as any particular stance or argument on the issue. Or put another way, I've mainly acted as a technical helper because EncycloPetey indicated they were unable to perform the technical task. (I also see I was mistaken in thinking annotated works should go in the Translation: namespace. I've either misunderstood something somewhere, or my understanding was based on out of date information). --Xover (talk) 11:24, 29 May 2019 (UTC)

@Xover: Translation namespace is for works that were translated from other languages by Wikisource editors, and for nothing else —Beleg Tâl (talk) 12:57, 29 May 2019 (UTC)

@Xover: That's pretty much my fault because I was the one who suggested it be moved there because I didn't know it was based on a published work. –MJL ‐Talk‐^☖ 19:48, 29 May 2019 (UTC)

@Billinghurst: Normally I would agree with regard to extracts of works. In this case, however, the parent work puts the translation text interlinear with the original, which is written in a script that almost no one here would be able to code and prepare. As such, the translation seemed to have merit, especially since a heavily annotated version had been prepared to assist readers. Under other circumstances, an extract from a publication would simply be subsumed into a transcription, and effecting a text rescue would not be of significant value. --EncycloPetey (talk) 00:15, 31 May 2019 (UTC)

@EncycloPetey: The approach taken by Beleg Tâl is more in line with what I would have expected. I simply said I was surprised that it was there in the form that arrived. It is a published work, publicly available and among zillions of published works that we don't have. There was no need to rush, nor ultimately to rescue when it was outside of our scope.

At enWP we had the opportunity to explain about their halved-chewed discards, and we could have educated and informed about editions, and provenance of our works. For this work, like any other work, if someone wishes to work on it great, and there may have been some volunteers at enWP who were going to take interest. Dunno.

P.S. If it came across as laying fault, then my apologies, that was not my intent. My intent was we rushed, rather than took the step back and considered our scope, and alignment with our scope.— billinghurst sDrewth 02:15, 31 May 2019 (UTC)

I didn't take your comment as implying any fault. After all, I'm the one who tracked down a scan of the source at IA and linked to it, establishing a toehold for what Beleg Tâl has now done. --EncycloPetey (talk) 02:24, 31 May 2019 (UTC)

Index:The sculptures and inscription of Darius the Great on the Rock of Behistûn in Persia.djvu is now live. Differences in the translation were made by Wikipedia editors and will need to be reverted. —Beleg Tâl (talk) 13:01, 29 May 2019 (UTC)

And I have moved the two pages to their appropriate locations.

• The Sculptures and Inscription of Darius the Great on the Rock of Behistûn in Persia/The Persian Text is the work itself, to be migrated to DJVU
• The Sculptures and Inscription of Darius the Great on the Rock of Behistûn in Persia/Annotated/The Persian Text is the annotated edition

—Beleg Tâl (talk) 13:11, 29 May 2019 (UTC)

@Beleg Tâl: So how should I go about transcluding this? Should we include the non-latin characters in the annotated version? I would suspect not, right? –MJL ‐Talk‐^☖ 19:48, 29 May 2019 (UTC)

@MJL: I have already started a discussion on the subject, at Index talk:The sculptures and inscription of Darius the Great on the Rock of Behistûn in Persia.djvu —Beleg Tâl (talk) 20:08, 29 May 2019 (UTC)

Obligations / expectations of administrators

In light of recents matters where it might have helped if there were clear community guidelines on what our expectations of administrators are, I have rewritten Wikisource:Adminship#Obligations of administrators to express my own view of the matter.[1] This is of course merely a conversation starter. Please feel free to revert, edit, but most importantly, discuss. Hesperian 00:52, 31 May 2019 (UTC)

@Hesperian: The way your additions are worded put them in conflict with some established policies, such as the Wikisource:Blocking policy, specifically regarding unblocking. Your added text would change policy so that if any established user challenges a block, then the blocked account must be unblocked and cannot be blocked until a community discussion is held to obtain consensus, even in cases where the blocking admin has additional (even sensitive) information. It also strains against the blocking policy's guidelines for controversial blocks.

I would disagree with a single opposition constituting a failure of consensus and the need to obtain consensus. Two established editors, perhaps, but not just one. We have a number of policies and decisions established by consensus for which there are lone voices of dissent. And as we have no ground rules rule for deciding "consensus" in a discussion, where typically there are often only two or three voices doing the discussing, I can see a path down which every decision could be challenged, rendering sysops impotent. Look through most deletion discussions, where the rules are well defined: yet deletion discussions have few participants, and can drag on for months without reaching any clear decision.

I would recommend starting a discussion to gather input and iron out the phraseology before adding the text, particularly as there has not been strong support of your view expressed in any of the discussion thus far. --EncycloPetey (talk) 02:08, 31 May 2019 (UTC)

I've made a few alterations to try to account for the fact that policies are the result of community consensus, and that some actions follow discussion. I'm still not sure about "Administrators should not use their rights in disputed matters in which they are involved" because "involved" could mean almost anything. On Wikipedia, the very fact that an administrator has stepped in means they are "involved", so the limitation becomes self-referential. On Wikisource, it is also much rarer to find any situation where active admins are not "involved" because we are a much smaller community than Wikipedias. Any active admin is going to be "involved" in most situations. --EncycloPetey (talk) 02:48, 31 May 2019 (UTC)

Petey, I don't see a substantive conflict with the blocking policy. Let us say that an established editor engages in disruptive behaviour, and that an administrator blocks them in accordance with the blocking policy. Your concern is that the established editor who has been blocked would immediately object to the block, and that the blocker would be obliged immediately to unblock. I can appreciate your concern that this would render the blocking policy toothless. However, my response is that blocking an established editor is always a highly contentious action, even when in accordance with policy; and that the blocker, upon applying the block, ought immediately to advise the community what they had done and why. Having done so, it would very soon become clear whether the block had broad community support or not. If the block turns out to be contentious, then yes, the block should be lifted. If the blocking admin is so silly as to block an established editor and not immediately lay their rationale before the community, then yes, the block should be lifted as soon as the established editor objects.

The over-riding principle is that the administrator uses their tools to enact the will of the community, rather than their own will. If they act unilaterally and fail to check that the will of the community is what they think it is, they may find they have to undo what they've done.

What I want to move us away from is the situation where administrators take unilateral actions that turn out to be contentious, then argue down the community until we all get sick of the drama and move on, until the next contentious unilateral use of the tools.

Hesperian 03:08, 31 May 2019 (UTC)

The way your additions were originally worded, any objection by any established editor would overturn any sysop action, even if there is clear policy (established by consensus) or even if there had just been a discussion which had reached consensus. Even if there was clear policy, established by consensus. This isn't about "will", it's about the fact that policies and discussions can exist where there has been consensus reached. If any objection by anyone can overturn policy and consensus discussions, then consensus is meaningless. If someone has an objection to policy or a closed discussion, then that person should initiate a discussion to reverse previous decision or to change policy. It should not be within the power of any individual to override policies and community decisions. --EncycloPetey (talk) 03:18, 31 May 2019 (UTC)

Well, I disagree with your changes, which pretty much give administrators a free pass if their actions are in accordance with their reading of policy. I would say that 99% of disputes over administrative actions are essentially disputes over whether policy applies / has been properly interpreted / has been properly applied. How are these disputes resolved?: by testing community consensus. How do you know that your application of policy may not be quite in accordance with community consensus? — the first sign is that an established editor objects to what you have done.

It is the will of the community that rules. Policy merely provides excellent guidance in figuring out what the will of the community is.

Hesperian 03:20, 31 May 2019 (UTC)

I appreciate we're editing forward on this, instead of reverting each other, despite coming from quite different viewpoints. I have made further edits that hopefully encompass both our perspectives. Hesperian 03:35, 31 May 2019 (UTC)

@Hesperian: Just to be the obligatory pedantic contrarian that rains on everyone's parade: I don't appreciate it… in that you are having the discussion in a public facing page that carries authority similar to policy. Such pages should be stable (barring trivial changes) until a consensus is established for change. And it doesn't help that the discussion isn't neutral: it is triggered by a specific issue that is the subject of controversy, and as such all observers will be coloured by that context. In other words, the discussion should be had here and Wikisource:Adminship#Obligations of administrators changed only when consensus for that change is reached. In fact, I feel so strongly about that that were I not a relative newbie both to WS and the bit I would have been inclined to revert the page to the status quo pending a consensus forming here.

And I think that issue is somewhat symptomatic of the underlying problem: enWS has a bit of an aversion to what is perceived as "bureaucracy" (process and policy), wanting instead to deal with stuff ad hoc, leading to conflicting guidance, guidance that is a moving target, and subjective judgement on what the policy is, how it is to be interpreted, and "everyone just knows" issues. It also leaves us vulnerable to transient outrage, enthusiasm, or personal antipathy or affinity deciding the outcome of an issue. Not even Solomon would be able to legislate wisely from a single controversial issue, and a wise judgement on that single issue is impossible if there is no existing legislation to cover it. Nemo censetur ignorare legem obligates the legislature more than it does those subject to the legislation.

I also have some thoughts on the substance of this discussion, but those had better be allowed to mature a bit before chiming in. --Xover (talk) 08:38, 1 June 2019 (UTC)

I don't care for the way this is framed. There is recognition of the overarching concerns, but failure to see these actions facilitating discussion and any solutions. CYGNIS INSIGNIS 10:12, 1 June 2019 (UTC)

@Cygnis insignis: I apologise, but I'm afraid I don't understand what it is you are objecting to. Perhaps if you could be a bit more specific I might be able to amend it to remove the grounds for the objection? --Xover (talk) 13:01, 1 June 2019 (UTC)

Because it suggests that this is a reaction to a single incident, and that the discussion is not neutral. Even Solomon … just say what you think it should allow you to do. The purpose of sysops at wikipedia, in stark contrast to what was historically a borstel here, is to facilitate the creation of content only. Contribute some solutions, the insinuations are how every other attempt has been stifled. That is how I read the comment, what is "not appreciated" by you for some reason. CYGNIS INSIGNIS 13:39, 1 June 2019 (UTC)

@Cygnis insignis: Hmm. I seem to have failed to communicate my intent clearly. My apologies. I am all for the discussion taking place above, and for making the obligations and expectations of administrators clear, detailed, and as aligned with community consensus as humanly possible. What I objected to was doing that by making edits directly in the published page instead of copying the text here and making drafts for comments and discussion. I also don't think it is a good idea to rush to make such changes directly from a contentious issue, not because the discussion here is necessarily non-neutral, but because we will all weigh the immediate issue too heavily at the expense of wider and more general concerns (i.e. we will tend to address the last problem we had, not the next one). That wasn't an argument against having the discussion already started, but rather an argument that for the future we should try to make policy and guidance before we end up in the contentious situations, and by doing so preferably avoid getting into those situations in the first place. That is, my entire comment was about the meta-issue of how to do/don't go about it. The specifics of what is being discussed is something I will need to mull over a little more before I have anything sensible to contribute. Was that any clearer? Did it remove some or even all of your objections? --Xover (talk) 15:27, 1 June 2019 (UTC)

Pretty much, thanks for the response. If you are not informed in the usual way, I was a sysop here and there is a tale in that. I love wikisource, and think I helped others who were interested in its objectives, my passion for that is turned to heart-break and have come to some conclusions after many years of careful consideration. Outlining my last attempt to discuss matters might illuminate where I am coming from, or the first, or any in between. There is some pretty iffy activity in the history of this site, don't expect to hear much about that. CYGNIS INSIGNIS 15:47, 1 June 2019 (UTC)

Xover, I believe I understand our culture and can correctly express consensus on this matter with minimal discussion beforehand, which is why I edited boldly. I accept that I may be mistaken, which is why I invited others to revert if they disagree. There has been no revert; only constructive editing towards consensus. That part of this process has succeeded; it has yielded all of the value that has come from this; the value of this discussion is tending towards zero.

You're an established member of our editing community and entitled to revert (whether or not I invited you to do so) but I confess I'll be pissed off if you revert constructive edits just because you don't like the process.

Hesperian 01:30, 2 June 2019 (UTC)

@Hesperian: I won't belabour the point since this digression was about a meta-issue. I also adduce that there are obviously some changes that are so trivial or uncontroversial that even in policy and policy guidance pages they should just be boldly made, and that you are certainly far better qualified than myself to judge when that applies.

However, I'll point out that in the above discussion you argue (I think) that admins should be so sensitive to community opinion that all admin actions should be immediately self-reversed if anyone objects, but here when it comes to changing community-wide guidance for admins you feel comfortable changing it unilaterally and suggest further tweaking instead of reverting. To me these stances are incongruous and, in fact, my immediate thought is that they should be the other way around: more weight should be given to seeking and assessing community consensus before changing policy and guidance than what is needed a priori for individual admin actions: if the policy and guidance is good, most admin actions will be good, and individual mistakes can be handled (overturned) after the fact. Or put another way, admins have been vetted through nomination and confirmation—and are subject to votes of confidence—and their individual actions must be presumed to have been in accordance with policy until a consensus determines that they have made a mistake. But a change to policy or guidance cannot be presumed to have consensus until such is sought and assessed: regardless of how trusted and qualified the proposer is.

Such policy and guidance is what guides all admin actions and the community's expectation of admins; it would be illogical to be less thorough in assessing consensus for this than for a single individual admin action.

But this is all a general point and on a meta-issue. None of it should be taken as applying to any of the substance of the above discussion (it is only about the process). --Xover (talk) 07:22, 2 June 2019 (UTC)

Some thoughts from Xover

Ok, I'm not sure I've fully grasped all the factors playing in here, nor sufficiently pondered the implications. But here are some initial thoughts, deliberately as comments here rather than edits to the page for several reasons (only partly related to the process digression above).

• The term "involved" must be better defined. For example, an admin acting in their administrative capacity does not become involved by those actions. If I patrol recent changes, see someone editing against policy, attempt to guide that editor but is ignored or rebuffed, and then take some admin action like locking a page or blocking the editor, then that does not constitute being involved. The prior actions were all in my capacity as an admin, I was just using softer and non-technical means then the tools that require the +sysop bit. The actions may still turn out to be incorrect for some other reason, but they would not be a violation of the "involved" principle. Absent a definition then the view I saw expressed recently that by stepping in as an admin I ipso facto become involved will obtain, and there will be a disincentive to admins trying softer means first if discussing can be argued to be grounds for considering them involved (safer to jump straight to using the tools that are unequivocally admin actions).
• The bullet point list seems to be doing multiple things: it is listing criteria for using the tools, and establishing primacy of sources of authority for their use, and regulating oversight and recourse for their use. I think that is probably too much work for one short list, without overloading it with subsections and modifiers. Perhaps it would be better to boil it down to something like "All use of tools must be founded in policy or by (consensus) instruction from the community" but that some policy provides room for application of discretion. I have difficulty seeing the specifically admin issue that it would make sense to seek a priori consensus for: all such are really community issues that only incidentally bear on admins in some way (i.e. if the community decides to ban someone or permanently lock a page or class of pages, then that isn't an admin issue except that you need an admin to implement the decision). An admin initiating such a discussion isn't really acting as an admin but as a community member, and for some such cases the output is new policy (all template: pages should be protected, say) that will guide admins. And I'm not sure we want the "is otherwise confident that there is community consensus" point. Isn't the goal to reduce unilateral decisions from admins?
• I'm not sure I agree with the presumption of lack of authority for admin actions inherent in requiring admin actions to be preemptively reversed on objection rather than retroactively on consensus. For admins to be effective there must be some presumption that they have acted correctly until the community has reached a consensus otherwise. The current text presumes all admin actions are incorrect until confirmed by the community. This assumes all actors are acting constructively and in good faith (most blocked editors here do not fall into those categories), and that human beings will not have human failings (frustration and outrage can blind all of us in the short term) when a specific contentious issue is "hot". Policy is (ideally) made when all heads are cool, and an admin acting in accordance with that policy is acting correctly and on established community consensus even if someone disagrees with that policy once an individual application of it has come up. The focus then should be on judging community consensus for changing the policy, not on castigating the admin that acted on the policy the community had given him.
• I think it needs to be made clear that admins have been vetted through nomination, periodic confirmation, and are subject to strictures and oversight in excess of the regular editor, and as such are presumed to have some measure of extra trust. A failed vote of confidence or a failed reconfirmation is an expression that that trust has been lost, which in turn implies that that trust existed in the first place. This bears on the previous point: there needs to be a presumption that they act in accordance with policy until the community decides otherwise. All the admin actions relevant in this context are inherently controversial (otherwise the tools wouldn't have been needed), so if the bar is that low then we might as well say that all admin actions should go to the community first.

Don't get me wrong, I don't disagree with the goals of the changes made so far (provided I understand them correctly); but I think there some issues with the text as it stands that will have unintended consequences. --Xover (talk) 10:02, 2 June 2019 (UTC)

Reverted to stable version

Since my edits have been objected to[2], I have reverted back to the stable version. In my opinion all of the feedback provided so far could have been dealt with by collaboratively editing forward. I consider the objections that have led me to revert the text are pure process wonkery. An opportunity has been lost, and my appetite to participate further is zero. Hesperian 00:00, 4 June 2019 (UTC)

Hmm. That is indeed a little… well, what enwp would call POINTy. Petey is entirely correct: your proposed text does open all admins up to such gaming of their every action. I suggest you try to take the frustration you (I'm assuming) feel and try to view it as "This is what Petey is worried about will happen" rather than as a cause for despair about effecting desirable changes. Their concerns are valid, so lets try to figure out how to best balance all concerns.

I have objected to the process and not the substance of the changes; and I would more characterise my comments on that as arguments in favour of a particular form of process more than an objection, per se, to the current process. If the current process (collaboratively editing the live document) is the only palatable way to progress this discussion I am entirely willing to withdraw my objection, such as it was, to facilitate progress, and to rather reserve it for some future opportunity to get up on my soapbox elsewhere.

My only comments on the actual substance of the changes is in the #Some thoughts from Xover section above, and they are there instead of edits to the live page because 1) they are insufficiently formed to be reasonable to attempt to edit in, and 2) I am sufficiently uncertain that they make sense that I feel they need honing in discussion and vetting by the community first. And, they are relative to the edited text before your revert. --Xover (talk) 05:09, 4 June 2019 (UTC)

That you have been impugning, not assuming, and I see these replies as redundant at best. I honestly thought Petey was joking with his test comment in his trolling reply elsewhere, because any "established editor" could have made a change or reverted at this page. And isn't that the substance of actual disputes involving tools, when used carelessly or with outright vindictiveness. CYGNIS INSIGNIS 06:15, 4 June 2019 (UTC)

@Hesperian, @Cygnis insignis: I started to write a reply here, but have deleted it. Let me instead check: is my input in this discussion unwelcome? I don't mean unwelcome in general or anything like that; but do you feel my contributions to this particular discussion have been unconstructive, derailing, tedious, merely stating the obvious, repeating myself, failing to understand context, or similar? I intend no accusation by that question: I just don't sense anyone engaging with what I write except in ways that signal disapproval or frustration. Since I offer my participation because I imagine it to have some value, I would refrain if that were not the case. --Xover (talk) 08:39, 4 June 2019 (UTC)

For myself, I prefer a solution. Clarity, brevity, edit the page or propose changes. What seems to be happening is bogging this down with blather, assertion and process and keeping the fairly simple clarification to admin actions from being enacted. Why do you think it would be any different to wikipedia, that being an admin imbues one some overriding authority, if they screw some lesser user around that is their business. You have been as rude af in your assumptions and aspersions, also discouraging to any solution. CYGNIS INSIGNIS 09:15, 4 June 2019 (UTC)

Wikipedia is a mess; we should not be using them as a model or standard. We can be better. --EncycloPetey (talk) 03:16, 5 June 2019 (UTC)

Wikipedia has its issues arising in part from the sheer size and scope of the project, and the vast potential for bias and abuse to enter into the system. I think we can be better than that here, given the rather clear boundaries of this project. BD2412 T 03:19, 8 June 2019 (UTC)

@BD2412: would you be willing to revert to the use of "straight" (un-differentiated) quotation marks, if two "established users" or indeed established with 'additional access' were in dispute about which should be used? CYGNIS INSIGNIS 16:08, 8 June 2019 (UTC)

Haven't I been using straight quotation marks, generally? I don't think I have a preference, although I can see an argument for using curly apostrophes to avoid conflicting with the straight apostrophes we use for formatting, and could see an argument from there to use a style of quotation marks that matches those apostrophes. BD2412 T 16:16, 8 June 2019 (UTC)

I honestly don't know and that is why I chose the example. I should have made this clear but the query is and is not hypothetical, Everyone has an opinion on their own use, if they are an admin are they more correct. EP thinks that italic serif font should be imposed, or at least he doesn't mind that is packaged into the display preference he applies (layout 2), but only on the works he is doing afaik. If someone else decides to impose that layout on other documents, based on the fact that an admin has used it extensively, should they be able to do that without objection? My contention is that the past practices and assumptions of what one can do when they are granted additional tools has created a situation that is not conducive to collaboration and will attract an undesirable and unproductive amount of disruption by assertions and counter assertions. If you see where I am going with this, and it is not much to do with the conduct of EP or yourself. CYGNIS INSIGNIS 19:20, 9 June 2019 (UTC)

I don't understand your comment concerning: "EP thinks that italic font should be imposed". Where did that come from? I have never pushed for "italic font", and Layout 2 has nothing to do with italics. I also can't see how the issue might pertain to the current discussion. --EncycloPetey (talk) 21:01, 11 June 2019 (UTC)

I meant a serif font, and fixed that. The discussion is, in part, how "we can be better". It was not an 'issue', it is an example for anyone to demonstrate how a very probable situation could be resolved. My recollection is that you prefer that layout, so make it the default display, the inclusion of a serif font is incidental. In a hypothetical situation User X thinks that other documents should be displayed in serifs, arguing they must emulate the printed page, that it is already widely used and is [obviously] an improvement. The point is how this becomes resolved, not the myriad of possibilities where users will disagree, I know well how it plays out in practice. This is not about any particular situation, if it were I would be discussing the use of differentiated (curly) quotation marks as an example of a little things continuing to create discord. What is the current discussion in your view? CYGNIS INSIGNIS 05:30, 12 June 2019 (UTC)

Vandalism by PigsontheWing

Repeated reversions at Author:Frederick W. Lanchester both of cleanup and of linking to better scan. Metadata should be housed at Wikidata; not on Author pages. Better quality scans, such as those from the University of California are preferred over Google Scans Looking for advice from other admins given recent history. --EncycloPetey (talk) 14:05, 9 June 2019 (UTC)

"from other admins" oh, damn! CYGNIS INSIGNIS 19:24, 9 June 2019 (UTC)

This is too much drama for me, I don't think it matters if the publisher is listed on the author page, or what scan we link to, none of this is against policy, ext scan links are just a convenience anyway, if you want a better scan then you have to upload and proofread one, otherwise there are more important things to do around here, I would just move on if it were me —Beleg Tâl (talk) 02:01, 10 June 2019 (UTC)

@EncycloPetey: The description as vandalism seems unjustified. You removed content that others think desirable. Do you have any further comment? CYGNIS INSIGNIS 18:29, 11 June 2019 (UTC)

WS:VANDAL defines as a "deliberate attempt to reduce the quality of the library". If the revert had happened just once, it might be understandable as an oversight, but repeatedly replacing a link to a high-quality scan with a link to a low-quality scan reduces the quality of Wikisource. Editors who begin transcription projects preferentially upload the linked scan rather than checking for better scans. Thus, replacing scan links with links to poor-quality scans will reduce the quality of the library, and the description as vandalism is justified. --EncycloPetey (talk) 20:57, 11 June 2019 (UTC)

Not what happened, Andy restored the better link after reverting your removal of the other information, in a single edit that clearly shows it was recognised as an improvement. What that user did was not vandalism. CYGNIS INSIGNIS 07:14, 12 June 2019 (UTC)

Deletion request

Please, delete Index:Bohemian section at the Austrian exhibition, 1906.pdf. It was replaced by Index:Guide to the Bohemian section and to the Kingdom of Bohemia - 1906.djvu, which is a better copy of the same edition. Thank you very much. --Jan Kameníček (talk) 10:23, 24 July 2019 (UTC)

Index:Poet Lore, volume 31, 1920.pdf can be also deleted, having been replaced by Index:Poet Lore, volume 31, 1920.djvu. Thank you. --Jan Kameníček (talk) 20:42, 24 July 2019 (UTC)

Done — billinghurst sDrewth 06:54, 25 July 2019 (UTC)

Renaming account with lost password?

I've run into a slightly thorny problem and could use some assistance.

A user has registered an account here, and made several contributions with it, but has subsequently lost access to the account. The account does not have email enabled, and the user has not succeeded in regaining access to it through password reset etc.

Now a different (new) account is claiming to be the person who registered the original account and wishes to have it deleted because the username is the same as that person's real name (they did not understand that their username would be public). Their behaviour is entirely consistent with this, and there is no apparent reason to distrust their story, but neither are there any easy ways to actually verify their identity as the account owner.

If the issue here was just getting access to their old account the standard answer would be "Make a new account". But here the concern is personal information that needs to be hidden.

Do we have any good mechanism to handle this situation? Could we have them email proof of real life identity to OTRS and take a name match to the account name as sufficient verification to have the old account renamed? Are there any magical backdoor mechanisms for resetting the password for an account without email, and, if so, what verification is needed for that?

They assert that their current IP address is the same as it was when they created the original account. Would it be permissible for the Checkusers to check this claim in these circumstances, and would we consider this sufficient evidence on its own to justify a global account rename?

Actually, since we're in effect talking about a global account rename either way here, do I need to ask the Stewards on Meta directly what options we have and what verification would be required?

Any advice would be much appreciated! --Xover (talk) 16:08, 29 July 2019 (UTC)

I think w:WP:RENAME gives an outline of what can be done here —Beleg Tâl (talk) 21:13, 29 July 2019 (UTC)

Just push them to the stewards, don't wear the grief.

If there is personal information available bar the name (names are not unique, and they can be faked) then we just delete the private information. — billinghurst sDrewth 05:53, 30 July 2019 (UTC)

@Billinghurst: In this instance it seems the original account was created to contribute material related to local history, such that now if you google their hometown and real name you'll hit their Wikisource user talk page (and another user's talk page where they also posted). Their original contributions were all deleted as out of scope, and they were rather confused by how Wikisource works, so you can imagine that their talk page isn't exactly a glossy social media profile (nothing spectacular, just not something you want as the first google hit about yourself). I imagine we might be able to alleviate the worst of their concerns by deleting their old user talk page and redacting their name from the other user's talk page, since that would hide it from google. And nothing of any great import would be hidden, but we would be revdel'ing what could potentially be someone else's contribs without actual evidence. Would this be a reasonable course of action here?

If we're to hand the username issue off to the Stewards, what is the proper process and venue for it? Should I post a request on the user's behalf on m:USURP? Request a Steward on IRC? Won't they just bounce it back to WS to resolve?

I feel pretty bad for this user as they were clearly trying to contribute in good faith in an area they cared deeply about, and then ran head first into the brick wall that is all the weird wiki-specific stuff that is completely outside the context that most people are prepared to handle. To the degree we can help them clean up the resulting mess without compromising policy I would very much like us to do so. --Xover (talk) 08:54, 30 July 2019 (UTC)

We manage local issues/edits, we cannot manage global accounts that is stewards (well the limited amount that accounts be managed, and they cannot reset or re-align accounts). I have no issue with our revdel'ing user talk pages. The user should contact stewards either via m:Stewards' noticeboard (public) or via their email address stewardswikimedia.org (privately). — billinghurst sDrewth 09:06, 30 July 2019 (UTC)

Hmm. Ok. Then I am going to use my own judgement in hiding information here, and then refer the user to the Stewards if they want to pursue the username issue. Based on my assessment so far the local actions will amount to simply deleting two user talk pages for accounts that I believe to be previous accounts created by this user, and possibly revdel'ing one old edit to WS:S/Help. All edits to the affected pages are related to the user's now-deleted contributions and are by the user themselves or admins trying to assist the user. I considered also blocking the two old accounts (leaving talk page access open) as presumed abandoned, but have for now decided that that would have little benefit and has some potential for negative effects (I mention this in order to invite feedback if anybody would judge that issue differently). --Xover (talk) 09:40, 30 July 2019 (UTC)

IP range threats

Cross-wiki drama imported by IP using a range of addresses and making threats. e.g. this edit. --EncycloPetey (talk) 20:04, 1 August 2019 (UTC)

If you can point out explicit examples of behaviour on English Wikisource that warrants administrative action, then we can take action accordingly. Otherwise, saying things like "encyclopetey u will pay for this" will just get yourself banned, your edits reverted, and your legitimate grievances ignored. —Beleg Tâl (talk) 19:54, 2 August 2019 (UTC)

Upgrading our abuse filters to allow blocking

The following discussion is closed and will soon be archived:

consensus is to add blocking to the available toolkits for abuse filters;  Comment will get overall abuse rights modernised to standard WMF settings

One of the standard abilities for abuse filters in mediawiki is to allow blocking of accounts or IP addresses (Block the user and/or IP address from editing) based on criteria in a filter. It has not been something that we have typically needed over the years as we haven't had persistent vandalism or spam. Things seem to have changed, and I think that it is probably time for us to move to having blocking functionality available. [technical detail https://noc.wikimedia.org/conf/highlight.php?file=abusefilter.php and setting $wgAbuseFilterActions['block'] = true;]

To have this change made at enWS, we would need to demonstrate a consensus of the community, and lodge a phabricator site request. Accordingly I propose:

• English Wikisource moves to have enabled the ability to block through its abuse filters.

— billinghurst sDrewth 04:44, 22 August 2019 (UTC)

•  Support Sam Wilson 05:08, 22 August 2019 (UTC)
•  Support Beeswaxcandle (talk) 05:31, 22 August 2019 (UTC)
•  Support --Zyephyrus (talk) 12:45, 22 August 2019 (UTC)
•  Support Mpaa (talk) 19:20, 22 August 2019 (UTC)
•  Support Non admin note of support ShakespeareFan00 (talk) 07:35, 23 August 2019 (UTC)
  • I Will also note that I'm also in favour of IP contributors being 'encouraged' to get an account.ShakespeareFan00 (talk) 10:42, 23 August 2019 (UTC)
•  Comment I am… ambivalent.
  What criteria would we block on that are not better handled by the global abuse filter? I haven't noticed any spam or vandalism that seems unique to enWS; and the most common spam seems to have no obvious machine-detectable characteristics in common.
  We also currently allow non-admins to edit the filters: do they get to set the action to block too?
  And would it be only for spam and vandalism, or would it be acceptable to use abuse filters to auto-block also other undesirable behaviours (presumably only those covered by the blocking policy, but…)? We have some spectacular recent examples of that which it would be very convenient to simply delegate to auto-blocks, but those would also be really hard to safely detect with a filter. For example, how would we make sure reports of such behaviour are not caught up with the actual behaviour itself?
  How do we review such blocks to make sure we catch any unintended side-effects? Or even deliberate abuse of them?
  Note that I am not necessarily opposed to enabling this, but I see a lot of potential for misuse and collateral damage that is not addressed sufficiently for my peace of mind. --Xover (talk) 09:03, 23 August 2019 (UTC)

   reply Abuse filter blocks are not new, and have been successfully used at multiple sites, and I am unaware of any abuse of filters, let alone for blocking. We have had them on at meta for +++ years. The community to be setting rules for their use is pretty easy, and the provision of blocks should always be as a last resort. "Hasten slowly" is a pretty good approach for any abuse filter, only slowly increase their consequences and only where necessary, and test test test.

  Review? Like any other filters. 1) special:abuselog and 2) special:log/block through we would specifically look at those by user:Abuse filter special:log/block/Abuse filter. Global abuse filters do not block, it is a steward self-imposed rule; part of the purpose is to manage those spambots that morph their editing and later spam. And to note that I wrote the global spam filters that catch spambots, and a swag of those that continue to do so m:Special:AbuseFilter. — billinghurst sDrewth 07:05, 24 August 2019 (UTC)

  • We allow non-admins to edit the filters? That seems like it would be open to abuse from inexperienced or malicious users. I support restricting access to the filter regardless of this discussion. Also I think that conforming to the block policy goes without saying. —Beleg Tâl (talk) 13:01, 23 August 2019 (UTC)
    • We only allow non-admins to edit the filters if an admin has granted them that right. It has to be turned on explicitly (and can be revoked through the same mechanism). At present there are only 9 users with the right. Of those 6 are admins. The other 3 users have not edited here for some time. I believe that this is restrictive enough. Beeswaxcandle (talk) 18:59, 23 August 2019 (UTC)

      Note. I have just removed two set of abusefilter rights from retired administrators. The remaining non-admin rights user is vastly trusted user who is also a WMF employee, and has rights as they are the best at filters. I would also suggest that we ask the bureaucrats to review whether those rights are retained when they remove admin rights. — billinghurst sDrewth 06:36, 24 August 2019 (UTC)

Question. Is there any particular reason why we don't allow non-admins access to the abusefilter-log-detail right? I feel like that is something we could easily bundle with the Abuse filter editors userright (or even Autoconfirmed/Confirmed users). I generally do most of my anti-vandalism patrolling on enwiki using Special:AbuseLog, but I can't link to reports without that permission. It seems awfully silly that I can view most of them through meta (even while logged out), but I can't see/reference the details for the unique enwikisource ones. –MJL ‐Talk‐^☖ 17:27, 31 August 2019 (UTC)

I am unable to say why those rights were not assigned here when they were rolled out over the years. Best I can assume is that as we were non-standard that we were skipped, and not even asked. I will attempt to get that standarised in my phabricator request. — billinghurst sDrewth 13:27, 1 September 2019 (UTC)

• Support. The proposition would not require that we use this ability with any particular filter; it would apply only where the circumstances merited its use for a particular filter. BD2412 T 01:50, 28 August 2019 (UTC)
•  Support This would go a long way towards preventing abuse. –MJL ‐Talk‐^☖ 17:16, 31 August 2019 (UTC)