Votes formalize and document the consensus-building process and the decisions that the community makes. This page displays the full contents of recent, current and planned votes. Edit Wiktionary:Votes/Active to add new votes to the “active” list and remove old ones. Finished votes are added to Wiktionary:Votes/Timeline, an organized archive of previous votes and their results, sorted by the vote end date.
See also Wiktionary:Votes/ for an automatically generated, less organized list of votes.
Before clicking the “Start a new vote!” button below, change “Title of vote” in the field just above the button to a short descriptive title. Once you have created your vote, add it to the list at Wiktionary:Votes/Active.
{{Wiktionary:Votes/2023-09/Title of vote}}
{{Wiktionary:Votes/pl-2023-09/Title of vote}}
Note: add to this page andWT:A.
{{Wiktionary:Votes/sy-2023-09/User: for admin}}
Note: add to this page andWT:B.
{{Wiktionary:Votes/bc-2023-09/User: for bureaucrat}}
Note: add to this page andWT:C.
{{Wiktionary:Votes/cu-2023-09/User: for checkuser}}
{{Wiktionary:Votes/bt-2023-09/User: for bot status}}
Other
Admins, please periodically check for orphan votes at Wiktionary:Votes/.
Look for votes and voting templates, including templates for creation of new votes:
Vote to unblock Wonderfool and readmit them as a member of this community. Specifically:
It is the consensus of this community to unblock Wonderfool and readmit them as a member of the community. Their original account will be unblocked and the page unprotected. Wonderfool may treat it as their user page.
We will petition the stewards on Meta to respect our decision by removing the global lock on Wonderfool's account.
Wonderfool will be allowed to use multiple accounts just like any other user, provided these accounts are not used for abusive purposes.
"This list does not include accounts that have been globally locked on charges of cross wiki disruption, spamming, or vandalism. Such users are not globally banned, per se. If they create new accounts and are not disruptive with those accounts, they will not be locked again merely because it is discovered that they were previously globally locked."
Support It’s been a long time since WF did anything drastically destructive like deleting the main page and it’s a headache trying to work out who he’s posting as when his accounts keep getting blocked. WF also does some good work (such as recently adding long lists of derived terms to various entries). --Overlordnat1 (talk) 23:59, 26 July 2023 (UTC)Reply[reply]
Support I think the editor likes to make productive edits and that this kind of editing work should be welcomed unless there is a drastic negative impact. In the past year or so, WF has made corrections on a dozen to two dozen of my citations/quotations that corrected various errors I made, and only a few other editors have done the kind of correction WF has made even once (in this past year or so). WF also did some edits I did not necessarily agree with but were definitely innovative and interesting related to "See also" sections. If this vote is successful, I would like to think that its a step toward reversing the close-mindedness that characterises our present backward era. --Geographyinitiative (talk) 00:33, 27 July 2023 (UTC)Reply[reply]
Support Was going to abstain, but not anymore. If we're not going to enforce an indefinite block against WF, then there's no good reason to have one, nor is there a good reason to slap another permaban on them ever again unless it's a situation where we really are willing to implement it. Not interested in this "we can't block WF" hogwash; yes we could (imagine if someone else block-evading like WF were posting child porn; you guys really think we couldn't stop them if they kept creating new accounts? Plz). Deep down, the community doesn't actually want WF indefinitely blocked because their positive contributions far outweigh their negative ones. Can’t have your cake and eat it too. Either block or unblock. Ergo: Unblock. Megathonic (talk) 01:33, 27 July 2023 (UTC) Nah, on second thought, I'm gonna stick with abstaining. Megathonic (talk) 17:49, 27 July 2023 (UTC)Reply[reply]
Re "imagine if someone else block-evading like WF were posting child porn; you guys really think we couldn't stop them if they kept creating new accounts?": I think that example actually highlights what makes it difficult to stop WF: most of WF's edits are valid (until he gets bored). If someone were posting links to porn sites, that'd be sufficiently different from valid lexicographic behaviour that we could just write an Abuse Filter to automatically prevent posting links to those sites, and that would only hit that user because no 'valid' editor would be adding such links. But to stop the kind of edits WF makes... what, do we write an Abuse Filter that stops new users from adding citations to words? block anyone who RfVs a word that doesn't have cites? - -sche(discuss) 17:14, 28 July 2023 (UTC)Reply[reply]
My hypothetical wouldn't just be someone posting links to websites. They could also upload images of child porn themselves, or add sexually perverted text about children as usage examples or definitions. That would make it much more difficult to stop, especially if they're also doing so in languages where there are less editors to catch it.
Personally, I don't care whether WF is indefinitely blocked or not, which is why I decided to keep my vote as abstain after all. What I don't care for, however, is this firestorm over an admin enforcing our policies because other admins don't want WF blocked on sight. All right, then our indefinite block of WF is misaligned with our treatment of them in practice, so bring it into alignment: remove the indefinite block. Megathonic (talk) 18:34, 28 July 2023 (UTC)Reply[reply]
You've mentioned this child porn stuff repeatedly now and it's hard to see where you are going with it beyond a sort of osmosis of moral outrage. An indefinite block would presumably be applied more stringently in the case of someone posting child porn, yes. —Al-Muqanna المقنع (talk) 19:14, 28 July 2023 (UTC)Reply[reply]
Repeatedly? Only in two comments, and the second comment only exists because I received a reply to the first and wanted to clarify that a person could also do it in the way that WF posts, whereby a filter alone wouldn't be able to stop it. "indefinite block would presumably be applied more stringently". Yes, that's my point. Since I first learned of WF last year, I've read continuously that we can't block them, and I'm arguing that's not the case. We could, if we really wanted to, but we don't want to. As a counterexample I gave an unambiguous situation where everyone would be united in stamping that person's presence on this wiki out, and I do think in such a situation we could be successful. Megathonic (talk) 19:30, 28 July 2023 (UTC)Reply[reply]
I'm not sure hypotheticals help all that much, though. Of course we could block them by putting wide range-blocks in place, but the collateral damage of that is outweighed by their productive edits.
To draw my own analogy, it feels about as helpful to bring up as it does to suggest amputation as a cure for something like athlete's foot (which is often very difficult to get rid of). Just because it would work doesn't mean we should consider it a serious option. Theknightwho (talk) 19:44, 28 July 2023 (UTC)Reply[reply]
Support to pause the weird tail-chasing over them if nothing else. —Al-Muqanna المقنع (talk) 02:05, 27 July 2023 (UTC)Reply[reply]
I agree with Thadh below (and Equinox, and WF themselves) that this presumably won't change anything on WF's part; ultimately a time-out just seems useful to me: my vote's squarely directed at how it's being handled. Should be said I'm apparently also more comfortable than some with rules not being applied 100% consistently, according to common sense, but since it's obvious that some users do understandably take an issue with it regularising the situation a bit might be healthy. —Al-Muqanna المقنع (talk) 11:31, 27 July 2023 (UTC)Reply[reply]
Support with the following caveats or understandings of the proposal: —Justin (koavf)❤T☮C☺M☯ 02:32, 27 July 2023 (UTC)Reply[reply]
"Their original account will be unblocked": I'm assuming that this is User:Wonderfool. If this user (who has 800+ aliases) wants to use any other account as a sole main account from now on, that's fine by me and may be a way of wiping the slate clean, but it seems tacitly assumed that the "main account" for these purposes is "Wonderfool", which is one of several that is globally locked and has been a sockpuppet account used by this person(s). While we're on the topic, I would also support that only one person use this account: it's not clear to me that all of these edits have been from the same person.
"Wonderfool will be allowed to use multiple accounts just like any other user", which to my mind is consistent with m:Sock puppetry, since we have no local definition of this page (e.g. w:en:Wikipedia:Sockpuppetry). So legitimate uses of multiple accounts would be for privacy reasons (using one account on public terminals and another on private devices) or if Wonderfool is working on a technical or designated role (seems unlikely, but not impossible). There may be other uses, but I'm struggling to think of what they could be. In any case, those alternate accounts must be declared and never used for purposes like gaming a vote or providing fake support for controversial edits, getting in revert wars, etc. —Justin (koavf)❤T☮C☺M☯ 02:32, 27 July 2023 (UTC)Reply[reply]
@Koavf Why are you continuing to block Wonderfool accounts after the end of the vote? These caveats that you've written here were not part of the vote, and hold no weight. Theknightwho (talk) 19:50, 28 August 2023 (UTC)Reply[reply]
Because any other user does not use multiple accounts for standard editing. When does that happen? What users have 900+ accounts that they use to do standard editing? —Justin (koavf)❤T☮C☺M☯ 19:56, 28 August 2023 (UTC)Reply[reply]
I'm not an expert in any of this, but I believe the intent was to indeed treat him like any other user. And while it is against the rules to have sock puppets, I would imagine that for the average user that rule would be unlikely to be enforced unless it was being abused, since otherwise it would be difficult to detect. I.e. if I had an alt acct that I used for some reason, would anybody even be able to tell?
I'm wondering now how all the WF socks were found out until now. I'm sure some of them were blatant, but were the other ones just hunted down even if they were non-abusive? With my (limited) understanding of checkuser, I wasn't sure that was possible... – Guitarmankev1(talk) 21:06, 28 August 2023 (UTC)Reply[reply]
We do have local CheckUsers and they may have investigated Wonderfool, but it's typically from patterns of behavior and explicit admission. I have proposed a vote for a policy on multiple accounts, since we do not have a local one and the general guidance from Meta is that users are requested to have one account. It is definitely not normal to have 1,000. So rather than have this implicit disagreement or loophole or whatever, we should have explicit language about when it is acceptable to have multiple accounts. Please see Wiktionary:Beer_parlour/2023/August#Determining_language_for_a_vote_on_multiple_accounts, User:Guitarmankev1. —Justin (koavf)❤T☮C☺M☯ 22:49, 28 August 2023 (UTC)Reply[reply]
Support It has been my experience that the blocking hardly slows Wonderfool down, as I am daily finding new edits from yet another sockpuppet. I would much prefer to know right away whose edits I am dealing with, and to have a single talk page I can use for messages. Kiwima (talk) 04:38, 27 July 2023 (UTC)Reply[reply]
Supportas the user in question to hopefully end this inane block-or-no-block drama. Ioaxxere (talk) 05:26, 27 July 2023 (UTC)Reply[reply]
Support as the best way forward. —Soap— 07:57, 27 July 2023 (UTC)Reply[reply]
Support. I am pleasantly surprised with the voting so far. DonnanZ (talk) 09:17, 27 July 2023 (UTC)Reply[reply]
Support. Cautious support, assuming the sock puppetry stops and that situation continues to be monitored. If the user starts making trouble, they can just be blocked again. And if they do spit in the face of the community after this gesture of good will, that's just going to be much more of a detriment than a badge of honor, as plenty of people will get to say "I told you so" and many more community members will be motivated to shut down the sockpuppets. --Veikk0.ma (talk) 11:00, 27 July 2023 (UTC)Reply[reply]
Support. I've found and fixed plenty of WF mistakes, and they've fixed some of mine, too. I think WF is editing in good faith and the project is better off with their continued participation. I'm in favor of ignoring past transgressions and treating future participation the same way we would treat any other editor. JeffDoozan (talk) 12:27, 27 July 2023 (UTC)Reply[reply]
"I'm in favor of ignoring past transgressions and treating future participation the same way we would treat any other editor." Note: as mentioned on the talk page, we do not and should not treat other editors like this. We do not give full pardons, and thankfully, that specific section was removed from the vote. AG202 (talk) 14:22, 27 July 2023 (UTC)Reply[reply]
Recently WFs accounts have been aggressively banned not (AFAIK) for bad behavior but because one admin has decided to strictly enforce infinite blocking for "sockpuppets created for the purpose of vandalism or block evasion", which is a valid interpretation of WT:BLOCK. I hope that by unblocking User:Wonderfool, any use of sockpuppets cannot be considered "created for the purpose of ban evasion" and we can treat WF as we would treat any other productive editor, including temporary blocks for disruptive behavior per WT:BLOCK. JeffDoozan (talk) 15:39, 27 July 2023 (UTC)Reply[reply]
Support. He does indeed provide a lot of productive and beneficial changes to this dictionary, and I myself have had some good experiences working with him. Regarding the sock puppetry, I don't see it as be a punishable offence as long as it isn't being abused (vote manipulation, dogpiling discussions, etc), but neither should it be encouraged since the official position is "no sock puppets". So hopefully point 3 above is interpreted as "harmless sock puppet accounts won't be banned solely because they belong to WF". Vote changed to Oppose, see below. – Guitarmankev1(talk) 13:12, 27 July 2023 (UTC)Reply[reply]
Weak support. I do not have high hopes that Wonderfool will abide by the proposal, because I expect him to value low-key anarchy and "Internet infamy" over regular editing. But at least it might persuade a sysop to stop unilaterally tilting at windmills, and it might prevent newish users from developing an unrealistic threat perception once they learn about Wonderfool. ←₰-→Lingo BingoDingo (talk) 21:41, 27 July 2023 (UTC)Reply[reply]
Weak support, per Lingo Bingo Dingo and Al-Muqanna. Andrew Sheedy (talk) 23:32, 27 July 2023 (UTC)Reply[reply]
Support. I also agree with Lingo Bingo Dingo and Al-Muqanna above; I don’t expect this to accomplish anything but a reprieve from the recent fruitless crusading, but I strongly disagree with the unilateral way the latter has been carried out and think it ought to stop. Rules exist to serve the dictionary, not the other way around – and when it comes down to it, WF does a good deal more good than harm for the project. (I would add that, as I understand it, the purpose of blocks is not to punish or make a point, but to prevent harm to the project, and the blocks against WF, whether you see them as a troll or a lovable scamp, simply do nothing towards accomplishing this.) — Vorziblix (talk · contribs) 03:23, 28 July 2023 (UTC)Reply[reply]
Given numerous people have now expressed they have a problem with this approach, it quite frankly seems absurd that the daily bans still continue. Theknightwho (talk) 03:35, 28 July 2023 (UTC)Reply[reply]
I'd appreciate a cessation for the duration of the vote as well. ←₰-→Lingo BingoDingo (talk) 18:14, 28 July 2023 (UTC)Reply[reply]
If the goal is to stop the daily bans, and we know that WF isn't going to stop what they're doing, then there should be a more specific vote imho. Of all the votes that I've seen fail because of specifics & hypotheticals (including votes that involve small policy changes), I'm rather surprised (and a bit concerned) that this is the one that folks feel can be hand-waved. AG202 (talk) 19:56, 28 July 2023 (UTC)Reply[reply]
Support. Was the essentially the status quo before this whole mess. I would say, if WF does bad in the mainspace, go a little harder on them. (And do a mass cleanup to undo all their bad stuff that still exists.) cf (talk) 01:14, 30 July 2023 (UTC)Reply[reply]
Support. I would prefer the status quo, which I like to explain as a type of work release: we refrain from enforcing his block as long as WF behaves and does useful work. It's not an endorsement of bad behavior, but a conditional suspension of punishment predicated on good behavior. If he acts up, we have all the authority we need to block him and revert his edits- no waiting while we decide whether we have consensus. This was arrived at after years of failure to stop or even slow down his editing, and after WF got tired of playing games. It's not perfect: it requires constant vigilance and a certain amount of cleanup, but there are enough of us willing to put in the effort to make it work. It also requires thinking outside the box, because WF lives outside the box. Chuck Entz (talk) 22:14, 5 August 2023 (UTC)Reply[reply]
That said, I think that trying to keep WF from contributing is a waste of effort and probably doomed to failure. I would rather unblock him if that's what it takes to stop this mindless obsession with the letter of the blocking policy to the exclusion of common sense. It will probably have unforeseen consequences and may not work- but it's worth a try. Chuck Entz (talk) 22:14, 5 August 2023 (UTC)Reply[reply]
@Chuck Entz if we're thinking outside the box, maybe this is an opportunity to realize that in this day and age, individuals with enough obsession and technical means can materially impact a project like Wiktionary, e.g. by creating an inordinate amount of work for admins to either enforce anti-sockpuppetry measures, or revert bad edits. Maybe there's need for more sophisticated automation that doesn't exist today - perhaps at the platform level - to handle persistent behavior of WF-like proportions. This is a conversation that, I assume, can be had with the WMF, and a putative feature could be funded in various ways (including GoFundMe) if deemed desirable and adequate. It's 2023 - we're kinda lucky that WF is our only editor with the kind of pattern of rule abuse he has. I don't know that we want to continue relying on luck indefinitely, though. Chernorizets (talk) 22:06, 10 August 2023 (UTC)Reply[reply]
If you'll forgive me for inserting myself here, while serial vandals/sockpuppeteers like Wonderfool are certainly rare, he's not unique: there was a long-term person like this on Commons and another on Wikispecies for many, many years. The nature of these projects is also that there are probably a few others who are active now (as far as I know, the entire WMF-spehere is just made up of a bunch of Wonderfool sockpuppets and me). I think the solution to this kind of issue may be addressed by more aggressive CheckUser work and artificial intelligence to spot certain patterns. For a variety of reasons, local CheckUsers seems unable, uninterested, or unwilling to resort to that kind of approach. —Justin (koavf)❤T☮C☺M☯ 23:54, 10 August 2023 (UTC)Reply[reply]
Support - I think it is worth trying something new after more than a decade of quasi-blocked status. If there is some obvious negative outcome to this vote it is trivially easy to re-block him and get right back to where we are now, hence no real downside. - TheDaveRoss 14:05, 7 August 2023 (UTC)Reply[reply]
Support WF's work overall has been constructive, especially if only the more recent ones are counted. That being said, I would prefer returning to the status quo, though unblocking WF doesn't do much more harm than that. Frankly speaking, it is Koavf's recent block-on-sight actions that has prompted me to vote support; I would have voted abstain were that did not happen. – Wpi (talk) 09:39, 10 August 2023 (UTC)Reply[reply]
Support. It's clear that the community does not support a ban on the person, which means there's no point to a block on the account. —Mahāgaja · talk 20:38, 10 August 2023 (UTC)Reply[reply]
Support Seen his work and it seems that he's contributing well enough. Yes, he was a rogue admin that had multiple socks but he didn't commit any crimes and should be given a second chance. But I'd like to note that he should never be granted any advanced privileges again. Minorax (talk) 10:17, 12 August 2023 (UTC)Reply[reply]
Support. I think we should give the user another chance. John Cross (talk) 07:19, 15 August 2023 (UTC)Reply[reply]
Support This guy is just really funny and I want to see them back. Look at this edit I found recently. Tc14Hd (talk) 15:34, 15 August 2023 (UTC)Reply[reply]
Support The bans have proven ineffective and only cause more drama than the person himself. I disagree with point 3 allowing multiple accounts because I want to see his edits in one place, but I will accept it if it's needed to pass the vote. His edits are constructive and not even reverted, so the bans have become an awful running joke. If the bans were to avoid rewarding him, the current situation is giving him more fame. Bans have not excluded him from the community, but have rather annoyingly made the community play detective and whack-a-mole. Again, video game players reflexively create a new account upon permanent bans without thinking, but temporary bans for a day might make them reflect. Administration should be used constructively to clean up problematic behaviours, not in vengeance to punish a specific individual. Daniel.z.tg (talk) 18:15, 19 August 2023 (UTC)Reply[reply]
Support it will makes things more interesting कालमैत्री (talk) 13:50, 24 August 2023 (UTC)Reply[reply]
Weak support Per most supporters above, I’m supporting the vote to maintain the de facto status quo while ending the special case so that WF’s accounts won’t be banned simply because his main account was banned years ago. Mcph2 (talk) 14:08, 25 August 2023 (UTC)Reply[reply]
Support Wonderfool has shown a willingness to stick to a single account if not blocked, and the status quo is clearly not working. By unblocking him we give him a chance to behave more like a normal contributor. I see the status quo like Prohibition; it didn't work and in fact actively made things worse, and in comparison the "legalize and regulate" approach ultimately did. Benwing2 (talk) 22:11, 25 August 2023 (UTC)Reply[reply]
@Benwing2 Unfortunately, as seen in the Talk page, Wonderfool has explicitly stated that the outcome of this vote won't really change any of their behavior. I doubt that they're going to stick to their original account, which will honestly put us back to square one in however long it takes. That's part of why I'm honestly quite disappointed, yet not surprised, that this vote is proceeding in this manner. Nothing is going to change. If the goal was to stop the insta-banning, then a vote on it specifically and updating our policy should've been made. This gets us nowhere in the long term. Also, the votes just to "see where this goes" and that it'd be "funny" do not spark confidence for me in this project. AG202 (talk) 22:50, 25 August 2023 (UTC)Reply[reply]
I’m inclined to agree that it would have been helpful to address the insta-banning head on. Theknightwho (talk) 23:04, 25 August 2023 (UTC)Reply[reply]
@AG202 Not sure I agree this vote gets us nowhere. The status quo isn't working and people seem willing to tolerate Wonderfool on the theory that his actual editing behavior isn't block or ban-worthy outside of the block-evading. We know that Wonderfool did things 10 or 15 years ago that were worthy of perma-blocking, but we don't know whether this will still happen when he is unblocked. Several people seem to think it won't, and we will never know without giving him the opportunity to demonstrate that he can be a constructive member of this community. If he acts constructively, so much the better; otherwise, we can block him in good conscience. As for "this is funny" votes, yes, they aren't helpful, but online cooperative communities are messy by their nature; I don't think you can expect perfection, and the perfect is definitely the enemy of the good. Benwing2 (talk) 00:45, 26 August 2023 (UTC)Reply[reply]
@Benwing2, WF already said that nothing will materially change. Multiple folks have sent recent edits here that would lead to any other user being blocked (after being told to stop). Imho they’ve already been given the chance. If they really wanted to be a productive member of the community, with their sockpuppet creating skills, they would’ve made an account and made edits from there with no connection to their prior history. They love the fame, frankly put. The main issue that folks had here was the constant blocking, which could’ve been solved with a more precise vote. There’s nothing stopping another admin from blocking WF again when they inevitably make another disruptive edit as they’ve implied they would. (This doesn’t even get into the issue of global locks which haven’t been addressed properly). As for the issue of comments here, I’m not expecting perfection or anything, but that doesn’t mean that I can’t comment on or try to work towards improving the messiness. (though my patience has run thin) Especially considering that prior votes that actually worked towards improving the overall project have failed due to the slightest of inconsistencies, yet this vote had multiple votes in favor due to essentially vibes and for the fun of it, even praising disruptive edits! Where do the priorities lie? It’s just disappointing. AG202 (talk) 02:45, 26 August 2023 (UTC)Reply[reply]
@AG202 All I can say is, the status quo was clearly a failure, and I believe this change has at least a possibility of working. And of course I don't mean to imply you can't comment on the imperfections of this project. Benwing2 (talk) 05:05, 26 August 2023 (UTC)Reply[reply]
I agree it would have been preferable to stop the instabanning, but I suspect people must have felt, like I did, that having a formal site-wide vote on "tell user X to stop specific behaviour Y" was too abnormal to even suggest — normally, if a user X is being disruptive in some way Y, we ask them to stop (like multiple admins and bureaucrats did ask for the instabanning to stop), and if the user persists, we remove their ability to continue, whether that's by protecting a page they were editing, blocking them, etc. In this case, the normal way to respond to an admin continuing to use admin tools disruptively would've been to desysop him, and I suspect people must have felt, like I do, that it's preferable to try other approaches before resorting to that! (Unrelated, but re some other comments which have been made throughout this vote: I don't think we should be expecting Wonderfool to edit from specifically the account named User:Wonderfool as a condition of this, if only because how often does someone remember the password for or have access to the e-mail used to create an account he hasn't used in more than a decade? Maybe he does, but I couldn't consider it disqualifying if he doesn't.) - -sche(discuss) 01:01, 26 August 2023 (UTC)Reply[reply]
@-sche I agree with you that desysopping would have been pretty extreme, but on the other hand they've completely failed to demonstrate that they understand why their behaviour was a problem. The reaction was far more egregious than the original issue, which is a sentiment that has been expressed by quite a lot of people at this point, and it would be nice to see some actual accountability for it. Theknightwho (talk) 04:23, 26 August 2023 (UTC)Reply[reply]
Oppose
Oppose Bad precedent. I find no reason to believe that after 10+ years of skirting Wiktionary's rules, this user will honor the constraints set out in this proposal. Chernorizets (talk) 03:28, 27 July 2023 (UTC)Reply[reply]
Oppose: Wonderfool is a troll, not due to the "folly of youth", but because they enjoy trolling. They enjoy upsetting people, not for the sake of the project, but as a sport, feeding their own narcissism. Voting support for this vote is a vote for Wonderfool the user, not a vote for the betterment of the project. --{{victar|talk}} 06:08, 27 July 2023 (UTC)Reply[reply]
Weak oppose. I'm absolutely convinced that WF likes the chase more than he likes editing, and so the unblocking will do absolutely nothing, since he's just going to once again play some prank and get blocked - even without Koavf's crusade, WF has a track record of sneaking in mistakes and then going nuts once in a few months, then getting banned, create a new account, and resume editing as usual. I don't see any evidence he'll do anything differently given the opportunity. Also, I'm still sulking about diff going unnoticed for six years. Thadh (talk) 09:39, 27 July 2023 (UTC)Reply[reply]
Oppose per reasons already provided. AG202 (talk) 14:20, 27 July 2023 (UTC)Reply[reply]
They are also globally locked, however that should be interpreted, so would they even be able to log in? AG202 (talk) 15:45, 27 July 2023 (UTC)Reply[reply]
Oppose, though at the very least I probably won't be the one who has to revert definitions like "the act of having forced sex with a broccoli." Hythonia (talk) 15:56, 27 July 2023 (UTC)Reply[reply]
If there is an entry like that, it should be removed, probably via RFD. DonnanZ (talk) 16:36, 27 July 2023 (UTC)Reply[reply]
I wouldn't waste time with RFD for blatantly bad-faith edits. Just delete on the spot. Megathonic (talk) 17:17, 27 July 2023 (UTC)Reply[reply]
It was rather juvenile. Thanks for finding it. DonnanZ (talk) 20:38, 27 July 2023 (UTC)Reply[reply]
Oppose Why legitimise unrepentant trolling behaviour stretching back over a decade? Nicodene (talk) 13:22, 28 July 2023 (UTC)Reply[reply]
"Why legitimise unrepentant trolling behaviour stretching back over a decade?" I don't view it as legitimizing rule breaking more than recognizing contributions, which is more important. To me, the rules are there to serve the dictionary-building mission, and if an application of various rules weakens dictionary building, that application is at least suspect. This is not a workplace or a gated community, it's literally a for-fun, volunteer website. --Geographyinitiative (talk) 21:11, 4 August 2023 (UTC)Reply[reply]
Granted, but someone being a scofflaw or getting special treatment definitely makes it less fun. Without dredging up the very recent past, we have had threads on this re: users' abusive behavior and general poor judgement driving away other users. When we have a handful of power users that get to make things working for their benefit, it drives away a number of casual users and actually decreases productivity, as one terminally online power user cannot be as effective as dozens of casual users. —Justin (koavf)❤T☮C☺M☯ 21:35, 4 August 2023 (UTC)Reply[reply]
A culture that rewards bad actors drives away "power" users too. I'm apparently one of the most prolific citation-adders, but if problem users are allowed to arbitrarily and unilaterally toss out my work because they personally dislike it and/or personally dislike me, I'm not really interested in investing any more time in this venture. I hope that Wiktionary is satisfied with the cost of its purchase as far as this vote goes. Only time will tell if banking everything on a habitual troll over productive users who have the temerity to occasionally point out systemic issues is a winning strategy. WordyAndNerdy (talk) 19:36, 5 August 2023 (UTC)Reply[reply]
Weak oppose Good contributions from troll accounts are not enough to convince me that the user in question wants to contribute positively to the project. Although I would like this annoying situation to end, I feel that unblocking the user will just exacerbate the situation. - Sarilho1 (talk) 17:45, 29 July 2023 (UTC)Reply[reply]
Oppose. I support consistent and unbiased policy enforcement against disruptive editors (especially long-term ones like WF) versus creating a selective policy carveout for the one disruptive user arbitrarily deemed to be a puckish class clown. No other long-term troll has been granted so much goodwill and a decade's worth of chances to clean up their act. WF's modus operandi is to hide nonsense among otherwise solid contributions. In some ways, that's worse than standard drive-by vandalism, since it forces the community to manually sift through countless decent edits in search of the garbage. WF could've mended their ways at any point in the past decade. They could've even quietly come back under a new account and done only good work. In that case I would've agreed that blocking them for socking would've arguably been heavy-handed and counterproductive. But they're still up to their old tricks, as the broccoli diff above shows. Koavf is unquestionably in the right here for enforcing policy as it is actually written over arbitrary unwritten rules. The fact that something as straightforward as blocking a ban-evading troll is being met with such fierce opposition and even hostility only proves that the jester has control of the court. WordyAndNerdy (talk) 22:09, 5 August 2023 (UTC)Reply[reply]
I'd say what it proves is that this community goes to great lengths in order to retain long-time productive contributors. You're benefiting from this yourself ... we've allowed you to contribute here despite your walling off your talk page to all but admins, because you asked us to. This is against all Wikimedia tradition and a new user would not be afforded this special exemption without a very compelling reason. I'm voting to unblock because I believe Wonderfool has proven himself worthy of a fresh start, even though a strict reading of the policy shows that we could just keep blocking every single new account. Best wishes, —Soap— 09:01, 7 August 2023 (UTC)Reply[reply]
"We've allowed you to contribute here." Well, that doesn't have an ominous ring to it, does it? The difference between WF and me is that I haven't spent the last decade knowingly and intentionally injecting nonsense into mainspace. And I think you've mistaken tying up loose ends for active contribution. How was I to predict that not cutting off my nose to spite my face – i.e. by refusing to create entries for things I'd already attested before asking to have my talk page "walled off" – would be held against me? I'm tired of being put on the defensive every time I speak out on systemic issues. Anyway, it's time for me to peace out. WordyAndNerdy (talk) 04:44, 8 August 2023 (UTC)Reply[reply]
Oppose. One of my conditions of support would be that Wonderfool doesn't use sock puppet accounts to manipulate votes. Since he did just that by trying to use a sock account to participate in this very vote, I unfortunately now must oppose. – Guitarmankev1(talk) 13:25, 24 August 2023 (UTC)Reply[reply]
Wiktionary:Voting_policy says "3. Only one vote can be made per person. Sockpuppet voting results in a block on all related accounts." Give him a chance, and if he does that, the community will have a fresh reason to block him. Daniel.z.tg (talk) 07:03, 26 August 2023 (UTC)Reply[reply]
Oppose. I've found a fair few people's analysis/commentary valuable, in particular that of AG202, Chuck Entz, Equinox, Koavf, Sarilho1, Thadh, and WordyAndNerdy. I don't think Wonderfool's edits are especially valuable or worth fighting to keep. I would say Wonderfool's behavior is overall a problem to be confronted. But unless a process can be implemented that prevents new sockpuppets from being created (which I worry range blocks wouldn't even do), I expect Wonderfool to persist and continue to vandalize. Trying to force Wonderfool to use one account seems a fools errand as once Wonderfool begins vandalizing with that account and gets blocked - even if its just for a day - it seems likely that a new sockpuppet will be born, leaving us back at square one. The "work release" treatment summarized by Chuck Entz seems likely the best we can do to minimize the amount of time and energy sunk into managing the situation. —The Editor's Apprentice (talk) 10:38, 25 August 2023 (UTC)Reply[reply]
Abstain
Abstain I'm undecided. PUC – 12:25, 27 July 2023 (UTC)Reply[reply]
Abstain If the vote passes, I will support unblocking Wonderfool's original account. If the vote fails, I will support those who block WF's socks at will. I'm not going to cast a vote deciding how that turns out. The only thing I'm going to oppose no matter what are those who want it both ways: Having Wonderfool indefinitely blocked, but allowing block-evading socks and getting mad when our policies against that are enforced. Time for this "special case" nonsense to end! Megathonic (talk) 17:49, 27 July 2023 (UTC)Reply[reply]
Abstain I really don't know what's better for the project. Many of these comments ignore either his trolling or his positive contributions. Ultimateria (talk) 19:44, 28 July 2023 (UTC)Reply[reply]
The comments might be, but I don't think anyone here does (as in, no one truly ignores either). It appears to be difference in approach: some seem to think that the positive contributions excuse the occasional idiocy, some — that we can afford to be picky with who we allow to contribute. Hythonia (talk) 08:48, 29 July 2023 (UTC)Reply[reply]
Abstain I believe he deserves to be given a second chance, but at the same time, I don't know. Chuterix (talk) 23:30, 28 July 2023 (UTC)Reply[reply]
Abstain and comment: the main vibe of the vote is "let's end special cases". This is still a special case and we should discuss if it sets precedent. I don't think this has been thought all the way through. Vininn126 (talk) 09:20, 29 July 2023 (UTC)Reply[reply]
Can you elaborate on that? What would make this a more fully-baked idea? —Justin (koavf)❤T☮C☺M☯ 10:05, 29 July 2023 (UTC)Reply[reply]
Analyzing the consequences of such an unbanning - it would be unprecedent to unban such a user, and what kind of precedent would we be setting? Vininn126 (talk) 09:03, 30 July 2023 (UTC)Reply[reply]
My 2p: some users have expressed concern about special cases, but ultimately the circumstances are special regardless and any precedent set by passing this vote could only be taken as applying to cases that are equally special. WF has, after all, received special treatment in some form for the better part of two decades now and the precedent notionally set by that does not in practice seem to have spilled over to anyone else. —Al-Muqanna المقنع (talk) 13:11, 30 July 2023 (UTC)Reply[reply]
WF has skills, notably the creation of sockpuppets, but his hallmark comments soon betray him. It is better to give him a chance, and have him out in the open. We would still have to monitor his contributions though, and revert on sight any silliness. Maybe a period of probation wouldn't go amiss. DonnanZ (talk) 14:08, 31 July 2023 (UTC)Reply[reply]
Abstain I can't help but feel this may be counterproductive, and would prefer a return to the status quo ante. Theknightwho (talk) 20:59, 7 August 2023 (UTC) Changing to support. Theknightwho (talk) 17:43, 10 August 2023 (UTC)Reply[reply]
Abstain: leaning oppose but both support and oppose voters make decent and compelling arguments. I wish to note though that I doubt this would set any major precedent as Wonderfool is a special and very unique case. (Also, imagine how funny it would be if half of the support votes and even oppose votes turned out to be Wonderfool socks). LunaEatsTuna (talk) 11:41, 25 August 2023 (UTC)Reply[reply]
Thank you for doing this. But the incoming link doesnt work ... i think you need to type out "Wiktionary" twice, once for the project and once for the namespace. —Soap— 14:03, 26 August 2023 (UTC)Reply[reply]
@Koavf: I thought the vote passed on August 26, but then how did this diff happen on August 27? Daniel.z.tg (talk) 20:26, 27 August 2023 (UTC)Reply[reply]
@Koavf This information should be moved to User talk:Wonderfool at the very least. It is, in my honest opinion, highly inappropriate to have a Wiktionary page dedicated to them. If they’re now a regular normal user, then treat them as such. Nowhere in this vote did it say we need to maintain such a page. There is also no need to mention a count of any sort. AG202 (talk) 20:10, 27 August 2023 (UTC)Reply[reply]
Agreed on the count. The information is also stored on another wiki, so if any admin wants to delete this or convert it into a category in the style of those under w:en:Category:Wikipedia sockpuppets, then that's fine by me. I retained it because some users claimed that it's helpful for monitoring these sockpuppets. —Justin (koavf)❤T☮C☺M☯ 20:16, 27 August 2023 (UTC)Reply[reply]
I don't think a category would work in this case. On Wikipedia those users are blocked so they can't edit, so the categories are stable. Here we have WF who is no longer blocked. What if he edits and removes himself from the category? There wouldn't a single page to watchlist and it would make it easy for one of the accounts to escape our notice. Daniel.z.tg (talk) 20:22, 27 August 2023 (UTC)Reply[reply]
This would work with me. AG202 (talk) 20:26, 27 August 2023 (UTC)Reply[reply]
WF's original account has now been globally unlocked, although this may be a purely symbolic gesture, as WF recalls having scrambled the password at some point. Some of WF's other sock accounts are globally locked too, but I note that global locks apply to the account, not the person, so there is no issue from a global perspective if WF continues editing under some other account(s) of his choice (noting point 3 of the vote). This, that and the other (talk) 01:14, 28 August 2023 (UTC)Reply[reply]
Sorry, there is no way off the staircase"scrambled the password"-- General inquiry, is there no recourse for an account if the password is "scrambled"? Like, if I got hacked and then the password was scrambled, would there be no way to come back from that? An account on an internet website is not a booby trap in an ancient Egyptian pharoah's tomb, can't you just call the cyberpolice hotline to reset password? --Geographyinitiative (talk) 11:32, 31 August 2023 (UTC)Reply[reply]
It can be done in theory, but it would require time from WMF staff, who have better things to do than confirm someone's identity (this is the tough part actually) and reset their password, especially in a situation where the account holder does not have advanced rights AND is known to freely create accounts to suit their whim. In WF's case the confirmation of identity is probably not possible to the standard that would be demanded. This, that and the other (talk) 10:08, 2 September 2023 (UTC)Reply[reply]
@This, that and the other so what did the vote accomplish? As of my last check from a minute ago, User:Wonderfool's last edit is from 2010, and the sockpuppets subpage indicates they've created several accounts since the vote passed. I'm not an admin, so this is mostly a question for those of you who are - was this the envisioned end result? Chernorizets (talk) 05:05, 2 September 2023 (UTC)Reply[reply]
Not sure why I'm being pinged specifically with respect to this question, or why only the views of admins are relevant, but since you're asking me, it's more or less what I foresaw when I noticed this vote had been created. In my mind there was little danger of WF returning to his Wonderfool account again.
I would add that these accounts are not technically sockpuppets, since WF is not trying to avoid a block, nor is he pretending to be someone else. But I'll probably keep thinking of them as "socks" for nostalgia's sake. This, that and the other (talk) 10:18, 2 September 2023 (UTC)Reply[reply]
Installing the WikiSEO extension
A vote on whether to install the WikiSEO MediaWiki extension:
The WikiSEO extension allows you to replace, append or prepend the HTML title tag content. It also allows you to add common SEO (Search Engine Optimization) meta elements such as "keywords" and "description".
The extension seems to be well-maintained and already used in various wikis. By improving SEO, we can hopefully increase the amount of attention Wiktionary gets and attract new editors.
Support: seems like a useful thing and I don't see anyone presenting any downsides. - -sche(discuss) 17:02, 17 August 2023 (UTC)Reply[reply]
Reading through the Phabricator discussion, I see it passed security review. I assume if there are any clear security risks we could, or the devs would, turn it back off. But if we want to be extra safe, we could always treat it like our other interface infrastructure, major modules, etc, and use an edit filter to stop anyone but admins / template editors / interface editors (trusted users) from adding or editing "the {{#seo}} parser function or [...] mw.ext.seo.set()" (the two ways the documentation says it can be invoked). - -sche(discuss) 00:19, 18 August 2023 (UTC)Reply[reply]
Also just commenting that I found this thread on the Phabricator relating to a request to add WikiSEO to English Wikiversity. There's been an extensive process of making sure it's up to scratch, but the good news is that there seems to have been lots of progress, and it also passed the WMF security review back in April 2022. That's probably the most difficult hurdle passed, and means the WMF don't see anything inherently wrong with the design of the extension. That being said, I haven't read over the discussion in depth, so there may be qualifiers to that which may restrict some of the features - it's hard to be sure at this stage. Theknightwho (talk) 19:25, 17 August 2023 (UTC)Reply[reply]
Support I'm supporting this because I think we should have the power to decide what we put in our HEAD tags etc. When I first saw this I thought "SEO is usually spam" (SEO is usually spam and lies). But it's really one of those cases where guns don't kill people, people (with SEO) kill search engines. Yes, why not have a feature that gives us more power? Equinox◑ 01:12, 18 August 2023 (UTC)Reply[reply]
Support. I'm confused as to whether there's going to be a separate vote or proposal on exactly how to use WikiSEO on Wiktionary, but either way we should install it first :-) Ultimately, I'd like to see whether SEO will, indeed, attract more editors and more (constructive) attention, hopefully for the better. Chernorizets (talk) 03:56, 18 August 2023 (UTC)Reply[reply]
Support. I've personally noticed that when searching for "[keyword] dictionary", Wiktionary usually seems to rank below at least five other results and often more. I've had to go to the second page of DDG and Google to find Wiktionary sometimes. SEO is important, and even a simple description such as "Dictionary definition of [pagename]" would probably help search engines to better understand Wiktionary pages. I'd also like to emphasize that this is not just about Google Search. There are a variety of search engines out there, and I'd argue that many of these "Google alternatives" would benefit more from better SEO more than Google would. --Veikk0.ma (talk) 23:18, 22 August 2023 (UTC)Reply[reply]
Support: as other support voters have pointed out, this may not do too much—Google generally chooses to extract keywords themselves from page content, but installing this will not hurt, and it might help Wiktionary appear more prominently in search results on other search engines. LunaEatsTuna (talk) 00:15, 24 August 2023 (UTC)Reply[reply]
Support: too many SEO-proficient sites use our content to run ads or other shenanigans. - Jberkel 10:55, 24 August 2023 (UTC)Reply[reply]
Support But I understand that Google (and others?) use some kind of page index if a site creates one of the right kind. SEO is a kind of game between would-be SEO manipulators and Google, Google attempting to detect manipulation and avoid bad consequences (to Google) from such manipulation. DCDuring (talk) 16:01, 25 August 2023 (UTC)Reply[reply]
Support Metadata should still have an option to be hidden, either on a specific page or sitewide via user preferences. Netizen3102 (talk) 06:09, 30 August 2023 (UTC)Reply[reply]
Support As much as it feels weird saying it, I support adding the SEO. As long as it doesn't even slightly go out of hand. CitationsFreak (talk) 00:21, 4 September 2023 (UTC)Reply[reply]
Oppose I oppose this; I oppose SEO on Wiktionary; I oppose attracting low-quality editors. Wiktionary is already usually on the first Google page and possibly specifically prioritized by Google, so interested people who bother to look can find us, though I don't know how much difference opposing this will make. I am concerned that we might not be able to handle all those low-quality editors. I already see plenty of incidents discussed in WT:V. People making test edits are blocked instead of welcomed like on Wikipedia, showing a lack of resources. I like our current well-functioning community of editors, and I want it to remain somewhat scholarly. A dictionary must not sacrifice entry quality for quantity. Daniel.z.tg (talk) 18:30, 19 August 2023 (UTC)Reply[reply]
So this site is supposed to be only for the cognescenti? DCDuring (talk) 16:03, 25 August 2023 (UTC)Reply[reply]
As apparently scholars don’t use search engines. 🤡 Fay Freak (talk) 16:07, 25 August 2023 (UTC)Reply[reply]
Perhaps if it was like that, cognoscenti wouldn't be misspelled as cognescenti. I just don't want us to turn into Urban Dictionary.
I might also be biased as I use an offline version instead of online searching as the webpages load too slowly. Anyway, it's 19:1 already so I don't expect my oppose to go far. Daniel.z.tg (talk) 06:20, 26 August 2023 (UTC)Reply[reply]
I think that these editors will learn the ropes quickly. (Plus, a few extra hands might help with any other low-quality editors.) cf (talk) 02:45, 26 August 2023 (UTC)Reply[reply]
You know that most editors started off not knowing what they're doing, myself included. Vininn126 (talk) 09:46, 26 August 2023 (UTC)Reply[reply]
Myself included, I am learning languages and simultaneously writing Wiktionary for those languages. However, I take the time to research and analyze to reduce the risk of me doing Wiktionary:Requests for deletion/CJK#초면이다 and diff. Daniel.z.tg (talk) 10:12, 26 August 2023 (UTC)Reply[reply]
That does not mean we shouldn't train or help new editors. How would you feel if I told you to go away just because you don't know all the ins and outs yet? Vininn126 (talk) 10:23, 26 August 2023 (UTC)Reply[reply]
I never said that we shouldn't train or help new editors. I'm saying we shouldn't invite more than we can train or help. Daniel.z.tg (talk) 10:25, 26 August 2023 (UTC)Reply[reply]
Perhaps my sentiment is from a similar one in the open source community. We say on Reddit/GitHub that we don't need better advertising, and that should just have a better product. If you build a better mousetrap/dictionary, they will come. Daniel.z.tg (talk) 02:27, 27 August 2023 (UTC)Reply[reply]
Hmm, I think it seems somewhat beneficial honestly, and implementing it in a proper way rather than the silly way it was done years ago looks good I think. For the record I haven't had the chance to actually look at docs and such for WikiSEO but the description given here for this vote seems to give me the gist of how it works. I guess I'll make my stance official now by adding a support vote. User: The Ice Magetalk to meh 17:19, 28 August 2023 (UTC)Reply[reply]
Nomination: I hereby request the Bot flag for User:KamusiBot for the following purposes:
I (User:tbm) have done a lot of supervised QA fixes recently with the help of Python scripts that show me a diff. Some of these should have been run under a bot account and I have more cleanups pending that really ought to be done with a bot account.
I've documented the kind of QA fixes I've done plus some example edits (manually or supervised with the help of scripts).
Description
Tasks
Current
I'd like to run the following tasks:
Apply more whitespace and cosmetic fixes (Examples: diff, diff, diff, diff)
Convert Arabic roots to {{ar-rootbox}}. I'll coordinate with Fenakhay on this. (Example: diff)
Standardize category template usage on {{C}} for Swahili
Future
Possible tasks for the future:
More cleanups and fixes. I have a long list of issues
Add information from other language Wiktionary (e.g. hyphenation patterns)
Create Swahili forms (verb forms, noun plurals, etc)
Generate Swahili entries from Google Docs (to work with volunteers who are not familiar with Wiktionary)
Approach
I'll follow a conservative approach since my scripts don't take every corner case into account (yet?):
To start with, for the majority of edits, I'll have scripts generate a patch file (diff) which I'll review manually. The bot can then apply the changes.
For edits where I'm reasonably sure that a pattern covers it fully, I will make automatic edits (after sufficient testing). For example, Arabic root conversion based on the regex ^==Arabic==\n\n===Etymology===\nFrom the root (\{\{ar-root\|[^}]+\}\}\.?)\n\n=. (This is the most simple case; there are harder ones.)
Mistakes
I make mistakes but I promise to clean up after myself. Some mistakes I've made so far:
Arabic root conversion didn't take into account pages with two different roots and created two boxes with the same root (bad edit; revert; good edit).
A off-by-one error that meant a stray character remained (bad edit; fix).
I can't remember what went wrong but I introduced a syntax error when trying to fix a hyphenation pattern (bad edit; good edit).
Doing supervised editing but not paying enough attention and removing "duplicate" words from non-English text where these are probably not duplicate (diff, diff).
Removing a duplicate word from a quote where the duplicate word is in the original (maybe we need to add "sic"?) (diff)
Source code
I use Python and Pywikibot. I intend to clean up my code and publish it under a FOSS license on GitHub (famous last words, I know, but I'll do it).
Naming
I picked "KamusiBot" rather than "tbmBot" because I wanted to run the bot with a friend. He's busy but I like the name (Kamusi is Swahili for dictionary). Erutuon runs ToilBot so UserBot doesn't seem like a hard requirement.
Voting on: the way the sections "References" and "Further reading" work, as well as what content is in them.
One vote may be cast for each proposal. A vote of "no consensus" or against all proposals would result in none of the proposals being implemented, and the status quo as described at Wiktionary:Entry layout § References and Wiktionary:Entry layout § Further reading would remain in place. As expanded upon at Wiktionary:References § Implementation, this status quo does not imply any obligation to format the "References" section in a specific way. If more than one proposal achieves consensus, the proposal with the highest support ratio will be implemented.
Proposal 1: Both the header "References" and "Further reading" stay, but when references are added that are not cited inline, "References" is split in two, containing a section with only inline references and a section for non-inline references.
Without subsections, References may contain either inline references, handled by <references/> or {{reflist}}, or a list of non-inline references.
If both inline and non-inline references are listed, the non-inline references must be listed under the subheading Additional sources, nested under References.
Allow only supplementary material which is not used in creating the entry under Further reading.
Rationale: This gives editors more control and discretion while providing enforceable criteria for what kinds of links can go where. By having a subsection, all works whose materials are used in the entry can be listed as a reference while not cluttering up the style and functionality of the text printed by <references/> or {{reflist}}. It also clarifies that non-inline references used as sources for an entry are still references and not supplementary reading. This comes at the cost of being less bot-enforceable than proposal 3.
===References=== <references/> ====Additional sources==== * {{cite-book}} [source used for creating the entry] ===Further reading=== * {{cite-book}} [source not used for creating the entry] * {{pedia}}
Weak support This works, but I prefer option 2. AG202 (talk) 08:35, 8 September 2023 (UTC)Reply[reply]
Support. I believe the distinction between references and further reading is valuable and should be maintained, and believe reason to believe otherwise is from who got used to a flawed system (diff). Bot enforceability would indeed be more complex, but I believe the important thing is having good, solid rules for us humans, rather than letting bots completely wipe out the distinction that we've been maintaining just because they can't understand it, as #3 suggests. In practice this proposal is essentially the same as #2, and I have no strong preferences. #1 is better at clarifying that both inline references and non-inline references are equally references, but I must not ignore the big gap in keystrokes. Catonif (talk) 14:08, 8 September 2023 (UTC)Reply[reply]
Having inline sources at the bottom would have made it worse, not that it would've made any difference, given how this vote is going. -- Sokkjō 00:14, 21 September 2023 (UTC)Reply[reply]
Very weak support Honestly, only supporting this in the case option #2 doesn't get enough support. I think this one is slightly a net positive in respect to the status quo, but is still not ideal. Thadh (talk) 19:58, 8 September 2023 (UTC) Switched to oppose Thadh (talk) 21:52, 8 September 2023 (UTC)Reply[reply]
Strong oppose This option is more complicated than proposal 2 and thus inferior to it. For example, if references for non-inline citations already exist (under "References") and someone wants to add inline citations, this option not only requires creating a new subheader, but also moving the existing non-inline citations out of "References" and into "Additional sources". This moving-things-around is bound to cause confusion and while a bot can help clean this inevitably reoccurring mess up, I don't see the value in needlessly complicating things. Also oppose for reasons I listed under proposal 2. Megathonic (talk) 04:03, 8 September 2023 (UTC)Reply[reply]
Don't be silly. The required change to the references section in this case would be simply to add
<references/> ====Additional sources====
at the top of the section. All that changes is that the 'Additional sources' L4 header becomes mandatory when there is a mix of in-line references and non-in-line references. This change really just standardises a way of dealing with the ugly format mismatch if there is no separator between the two types. --RichardW57m (talk) 12:37, 20 September 2023 (UTC)Reply[reply]
If you look at the edit history of this page, my comment was made prior to it being re-clarified like that. And it will still cause confusion for people who forget to add the header once a mix is present or don't realize that an extra header is required in the first place. While a bot can go back and add it, I don't see value in adding this sort of complexity. Megathonic (talk) 15:48, 21 September 2023 (UTC)Reply[reply]
Oppose for reasons I outlined on talk, and reasons given by Megathonic. It's not realistically maintainable (people already don't maintain any coherent distinction between the two headers we have now, and this adds a third [sub]header), and even adds extra work relative to the also-not-maintainable option 2. - -sche(discuss) 20:25, 8 September 2023 (UTC)Reply[reply]
Oppose The last thing we need is a third header where one is enough. DCDuring (talk) 21:01, 8 September 2023 (UTC)Reply[reply]
Oppose Don't want to type "Additional sources" for the rest of my life, and subheaders seem overstructured. --{{victar|talk}} 21:22, 8 September 2023 (UTC)Reply[reply]
Oppose Re-read the proposal and it really isn't an improvement to the current situation. Thadh (talk) 21:52, 8 September 2023 (UTC)Reply[reply]
Oppose I don't really think adding new or different (sub-)headings is going to reduce confusion. We might as well stick to the current situation. — Sgconlaw (talk) 05:37, 10 September 2023 (UTC)Reply[reply]
Oppose Virtually all Bulgarian entries pretty much exclusively use reference templates (e.g. {{R:bg:RBE}}) in the References section vs inline references. We'd have to rename every References section for Bulgarian entries to Additional sources, which isn't an improvement. Chernorizets (talk) 09:44, 17 September 2023 (UTC)Reply[reply]
@Chernorizets: No! If there are no inline references, no change is required. Moreover, such references can be converted to inline references <ref>{{R:bg:RBE}}</ref>, or <ref name=RBE>{{R:bg:RBE}}</ref> for one and <ref name=RBE/> for the others. --RichardW57m (talk) 12:23, 20 September 2023 (UTC)Reply[reply]
@RichardW57m Thanks. Apparently I hadn't fully parsed the if-then-else branches of this proposal. It seems I'd only have to move all non-inline references under "Additional sources" if I add an inline reference, unless I had already artificially made everything an inline reference. I don't think this would come up a lot in Bulgarian entries, but I also don't think people (including myself) would remember to split the section in the cases when it should be split. Chernorizets (talk) 22:31, 20 September 2023 (UTC)Reply[reply]
@Chernorizets: But the splitting is something that can (and I think would) be done by bots. It's also easy for passers-by to fix. And non-inline references wouldn't have to be moved. It's just that two lines (plus a blank line? - again a bot job) would be inserted at the top of the references section. --RichardW57m (talk) 08:28, 21 September 2023 (UTC)Reply[reply]
Oppose Adding an L4 header that is used among the other two existing L3 headers will only make matters more confusing. The wording "Additional sources" is also a bit mouthful and out of place. – wpi (talk) 13:41, 21 September 2023 (UTC)Reply[reply]
Abstain I may have missed the problem that this proposal is intended to solve, so I wont support or oppose this solution, but it is the most agreeable to me in that it doesnt have the two problems that led me to oppose the other two proposals. —Soap— 17:00, 11 September 2023 (UTC)Reply[reply]
Perhaps @Vininn126 deliberately omitted it. The problem this approach solves is the formatting mismatch between in-line references and non-in-line references. The change of format is hidden by the new L4 header within the L3 section.. --RichardW57m (talk) 12:42, 20 September 2023 (UTC)Reply[reply]
Proposal 2: Add a new header
Add the L3 header ===Citations=== above ===References===.
Allow only references cited inline in the Citations section, handled by <references/> or {{reflist}}.
Allow only non-inline references under References.
Allow only supplementary material which is not used in creating the entry under Further reading.
===Citations=== <references/> ===References=== * {{cite-book}} [source used for creating the entry] <references/> ===Further reading=== * {{cite-book}} [source not used for creating the entry] * {{pedia}}
Support
Support. Prefer 1 but this is also fine. —Al-Muqanna المقنع (talk) 08:23, 8 September 2023 (UTC)Reply[reply]
Support. Easy to implement of for new editors and maintains the distinction between further reading & references. If people are putting references under further reading in a community then that's something that should be more clearly defined and enforced within that community. AG202 (talk) 08:35, 8 September 2023 (UTC)Reply[reply]
Support. As explained under my vote at #1, I support this as much as I support #1. Having citations outside of the =References= is theoretically wrong and misleading, but as the two proposals stand, #2 is much easier to type. If I had realised this before maybe I would have suggested some sort of ===References=== * {{cite-book}} =====Citations==== <references/>, but oh well. Catonif (talk) 14:08, 8 September 2023 (UTC)Reply[reply]
Weak support I'm not fully convinced we have a problem that really needs solving, but out of the listed options, this one is least disruptive to Bulgarian entries. Chernorizets (talk) 09:48, 17 September 2023 (UTC)Reply[reply]
Support per AG202, though I would prefer using a different wording to avoid confusion with the citations tab, perhaps "Notes" or "Footnotes". – wpi (talk) 13:41, 21 September 2023 (UTC)Reply[reply]
Oppose This is only partially bot enforceable as opposed to fully bot enforceable: A bot cannot tell the difference between something that should be classified under "References" or under "Further reading". Also, it's unrealistic that a distinction will be maintained in practice between sources used in creating the entry and sources which are not (we already have this problem). Furthermore, the initial BP discussion that sparked this vote was created because for Belarusian, sometimes editors would put a given dictionary under "References", and sometimes the same dictionary would get put under "Further reading", which appeared inconsistent. Yet, according to this proposal, such placement would be 100% consistent if the editor who placed the dictionary under "References" used it in creating the entry, and the editor who put it under "Further reading" did not. However, for the average reader, this "meaning" will not be conveyed; instead it will look disorganized. Megathonic (talk) 04:03, 8 September 2023 (UTC)Reply[reply]
Isn't it a good thing that it is not bot enforceable? References to construct entries are added by users so makes sense that the judgement is also make by users, not bots. I think it would be a very big mistake if we delegated to bots the enforcement of something that, so far, still requires human judgment. - Sarilho1 (talk) 15:36, 8 September 2023 (UTC)Reply[reply]
We don't have enough humans, let alone willing humans, and least of all willing humans with good judgment willing to enforce rules that are not obviously a net benefit. DCDuring (talk) 21:07, 8 September 2023 (UTC)Reply[reply]
Oppose for reasons I outlined on talk, and reasons given by Megathonic. It's not realistically maintainable: people already don't maintain any coherent distinction between the two headers we have now; in practice, adding a third header means references will be placed haphazardly under any of three headers instead of under any of two headers. I suppose from the perspective of supporters this is not a problem, because there will usually be plausible deniability by which they can think that the user who added their references to whatever header was present really did mean whatever ideal distinction between "I consulted and used this" vs "I didn't use this but am citing it anyway" is being envisioned, since the user's mind will usually be unknowable to anyone else. So then we can present haphazardness as meaningful (to people who have read there is supposed to be a distinction, while just looking as randomly disorganized as ever to other people, as Megathonic says). I would rather not. - -sche(discuss) 20:26, 8 September 2023 (UTC)Reply[reply]
I think the wording in the vote was a bit rushed, and from the talkpage discussions it seems clear to me that "used in the creation of the entry" really just means "includes the headword or term and can be used for attestation". This is not something that should be difficult to maintain - either the source work you include actually mentions the term (and is not a wiki) or it doesn't, and based on that, you put it in either of the two headers. Thadh (talk) 21:47, 8 September 2023 (UTC)Reply[reply]
No, that's not what it means; it means exactly what is written. If a source can be used for attestation, but it was not used in creating the entry itself, then it would go under further reading. I added this clarification based on what Al-Muqanna said.[1][2]. This wording was unchallenged for 8 days prior to the vote starting. Megathonic (talk) 03:52, 9 September 2023 (UTC)Reply[reply]
I think diff from five days later, which is also unchallenged, takes priority, wouldn't you say? Just because nobody replied to Al-Muqanna's message with "You should clarify that" doesn't mean that it is to be taken as a definite description of the vote as understood by the ones composing it. From my understanding, "supplementary material which is not used in creating the entry" means that it has to be 1) supplementary and 2) not used in creating the entry (so, supplementary material that is used, is added to references). It's not a description of the word "supplementary". Thadh (talk) 08:30, 9 September 2023 (UTC)Reply[reply]
I meant that my wording in the vote proposal went unchallenged. I am the one who wrote "source not used for creating the entry" and "supplementary material which is not used in creating the entry" and stated my reason for adding this clarification in the edit summary. I wrote that precisely so that people wouldn't walk away from the vote with different interpretations as to what just happened. In retrospect I would have left the word "supplementary" out since it seems that word itself is causing confusion. Megathonic (talk) 13:13, 9 September 2023 (UTC)Reply[reply]
Oppose Introduces confusion with Citations tab, where the meaning is "attestation". DCDuring (talk) 21:01, 8 September 2023 (UTC)Reply[reply]
Oppose I don't really think adding new or different (sub-)headings is going to reduce confusion. We might as well stick to the current situation. — Sgconlaw (talk) 05:37, 10 September 2023 (UTC)Reply[reply]
Oppose per my vote below. —Soap— 16:59, 11 September 2023 (UTC)Reply[reply]
Oppose Given these three choices and the fourth (the current regime), I am in support the current regime despite its flawed implementation and common misuse. I oppose this proposal's (Proposal #2) artifical distinction between a section of materials that was "used to create" an entry and one of sources that were not used to create the entry- this is so far from an objective standard that the current regime seems awesome by comparison. What if I re-read something in Further reading and it confirms something I added on the entry- is it now a References seciton entry? What if I re-read a References and change something that I added from it, such that now there's no close connection to the entry- is that material now moved to Further reading? Absurdity of absurdities. --Geographyinitiative (talk) 10:04, 17 September 2023 (UTC)Reply[reply]
Proposal 3: Two sections are maintained, one specifically for inline references and one specifically for sources and supplementary material that have not been cited inline. The distinction between non-inline "References" and "Further reading" is abolished.
Merge References and Further reading into one category called References.
Add the L3 header ===Citations=== above ===References===.
Allow only references cited inline in the Citations section, handled by <references/> or {{reflist}}.
Allow only a plain list of reference works in the References section.
Rationale: Such a system is easily enforceable by a bot, allows non-inline references to be marked as references, and removes the need for editors to make a judgement call between listing something under either "References" or "Further reading". Sources from which lexical information can be derived (e.g., a dictionary) would be categorized uniformly across all entries. This comes at the cost of no distinction being made between reference and non-reference works.
===Citations=== <references/> ===References=== <references/> * {{cite-book}} [source used for creating the entry] ===Further reading=== * {{cite-book}} [source not used for creating the entry] * {{pedia}}
Support
Support 100% bot enforceable. Keeps everything simple and consistent. I would have preferred a better name than "References" for the second section, but this is an improvement over what we have currently. Two big items often categorized as further reading are dictionaries and encyclopedias. Dictionaries convey lexical information and are still a general reference source. To a lesser extent, an encyclopedia is too, as the entry itself is an illustration of how the word is used. I'm not sure what other types of "further reading" would belong on this project; a general list of "further reading" is something for wikipedia. If this vote passes, "reflist" could be renamed to something like "cite-list" or whanot to keep the name consistent with the Citations section. Megathonic (talk) 04:03, 8 September 2023 (UTC)Reply[reply]
Support Simple. Easy for humans to understand more or less correctly. The distinction between inline footnoted references and general references can me made visually, as it is now. A better look should be achievable by our CSS masters. DCDuring (talk) 21:03, 8 September 2023 (UTC)Reply[reply]
Oppose
Oppose. On balance I don't think abolishing the further reading/citations distinction is helpful to readers. —Al-Muqanna المقنع (talk) 08:23, 8 September 2023 (UTC)Reply[reply]
Oppose. Removing the longstanding distinction because a few users are confused goes too far; if anything, we should be educating users more and making sure that it is abundantly clear. AG202 (talk) 08:35, 8 September 2023 (UTC)Reply[reply]
Strong oppose. We should not bring our human capabilities down to bots'. I don't see any reason to let them wipe out the distinction we have and value, as has already happened in Italian entries without consensus. Moreover, the headers' names would be very wrong: a Wikipedia link is not a "reference" (and if it is, it cannot, and should be substituted with the original source, as WMF projects aren't eligible resources). Catonif (talk) 14:08, 8 September 2023 (UTC)Reply[reply]
Oppose. I don't hold much love the "Further reading" section and I would be fine to see it go, but only if those links under it were removed. I cannot support categorizing those links (Wikipedia in particular) as references. - Sarilho1 (talk) 15:30, 8 September 2023 (UTC)Reply[reply]
Oppose I don't really think adding new or different (sub-)headings is going to reduce confusion. We might as well stick to the current situation. — Sgconlaw (talk) 05:37, 10 September 2023 (UTC)Reply[reply]
Oppose There is a bot which places "Further reading" below "References" (God knows why). I don't agree with that. No to ===Citations===, which can be entered at the top of each entry. There are still some ====Quotations==== headers with content which needs rehoming. DonnanZ (talk) 10:04, 11 September 2023 (UTC)Reply[reply]
Oppose based on naming. The <references /> tag is hard-coded into MediaWiki. We could create a new template that renames it, but people are used to using <references /> and that'll be a difficult habit to break; even with a new template, people might not recognize it for what it is and will try to add it. Also I think having a header for citations is confusing when we already have a Citations namespace which is more in line with what the word citation usually means on this project. I think the status quo is fine. All the best, —Soap— 16:58, 11 September 2023 (UTC)Reply[reply]
I wouldn't object to this, but also wouldn't object to enforcing this type of distinction while keeping the current headers. Perhaps what would resolve the competing concerns of (a) not having sister-wiki links presented as 'references', and (b) being maintainable without having to give some of our users The Boys' Compound V so they can read every random IP's mind to know how deeply that user consulted a reference and hence which header it belongs under, is: put (1) inline references under one header, (2) non-inline, non-wiki references under another header, and (3) links to other wiki projects under a third header. That would be bot-maintainable. - -sche(discuss) 20:44, 8 September 2023 (UTC)Reply[reply]
The issue here is that there are also some links that can be added as further readings but not be used for attestation - actual encyclopedias that are not wikis and (particularly for reconstructed terms) descriptions of the principles of reconstruction and/or soundlaws relevant to the entry but not mentioning the reconstructed term itself. Thát is the main problem I have with this proposal. Thadh (talk) 21:50, 8 September 2023 (UTC)Reply[reply]
I'm not sure I follow what you mean. Aren't reconstructed terms by definition not attested? It's not necessary for the encyclopedia (or book, paper, etc.) to specifically mention the term itself in order for it to serve as a reference: The sound laws/reconstruction principles would themselves be a reference that was used for reconstructing the term. In this case, wouldn't it actually be incorrect to list it under further reading? Megathonic (talk) 03:22, 9 September 2023 (UTC)Reply[reply]
A reconstructed term is not attested, but a reconstruction is (it is reconstructed elsewhere).
And I don't think that reconstruction principles that are explained in a paper serve as proof of the reconstruction, and thus should be included under the "reference" header - since essentially that makes it extremely difficult for anyone to figure out if we're just pulling the reconstruction out of our [name your favourite body part], or if it is actually a solid reconstruction used elsewhere. There is nothing wrong with original research, but readers should be aware that we are doing it.
Compare *lɛbalni: To anyone familiar with the Permic languages, it is clear that this term should go back to PP, since it is present in every branch of Permic, and is completely regularly formed. However, nobody has reconstructed it yet. If I were to add the etymological dictionary to "references" though, every reader would have to check with the reference whether or not this is something we have reconstructed ourselves or if it has already been reconstructed by someone else. Thadh (talk) 08:38, 9 September 2023 (UTC)Reply[reply]
@-sche Is this intended to be an abstain vote? AG202 (talk) 21:15, 13 September 2023 (UTC)Reply[reply]
Functionally, yes; it's more of a comment than a vote, but since it's neither a vote of support nor a vote of oppose, I put it in the abstain section. My actual vote/preference would be to implement the bot-enforceable distinction described by this proposal 3, but while using the current header names (or at least, continuing to call the header that <references/> and {{reflist}} go under "References", and maybe renaming "Further reading" if people think it sounds too much like "Not references" to put references under). - -sche(discuss) 21:44, 13 September 2023 (UTC)Reply[reply]
Abstain, due to not really knowing how frequently/effectively the "Further reading" heading is used today. Chernorizets (talk) 09:55, 17 September 2023 (UTC)Reply[reply]
Abstain. I am sympathetic to any of the three in principle, but I'm not wild about any of the headings. As Soap notes above and DCDuring points out in Proposal 2, a "Citations" heading and a separate "Citations" page with different functions is ambiguous and potentially confusing. Proposal 1 avoids that ambiguity, but I agree with Megathonic and others that using three headings seems more complicated than is necessary. Cnilep (talk) 06:48, 19 September 2023 (UTC)Reply[reply]
Decision
Appendix Part of Speech Templates
Voting on: The addition or modification of part of speech templates (noun, verb, adjective, adverb, etc.) that work correctly in the Appendix namespace. Currently, use of these templates in the Appendix namespace results in automatic linking back to the main namespace and requires some trickery in order to link within an appendix. New templates can either be added or the existing templates can be modified to work in appendices.
Support Being able to create separate pages in appendices should be supported, especially for complex terms. Netizen3102 (talk) 06:00, 23 September 2023 (UTC)Reply[reply]
Oppose
Abstain
Decision
Proposed votes
The following are proposals for new votes, excluding nominations, in cases where the proposer of the vote prefers that the vote is written collaboratively, or where the vote appears to require substantial revision. If you have not created a passing vote yet, it is recommended that you use this section and actively solicit feedback by linking to your proposal in discussion; your vote may have a better chance of passing if it is first reviewed.
Votes may linger here indefinitely. If changes in policy make a proposal irrelevant, the voting page will be requested for deletion. On the other hand, you do not have to be the creator to initiate one of the votes below. Place any votes with a live start date in the section above at least a few days before that start date arrives.
0 
0 
0
Support It’s been a long time since WF did anything drastically destructive like deleting the main page and it’s a headache trying to work out who he’s posting as when his accounts keep getting blocked. WF also does some good work (such as recently adding long lists of derived terms to various entries). --Overlordnat1 (talk) 23:59, 26 July 2023 (UTC)
Oppose Bad precedent. I find no reason to believe that after 10+ years of skirting Wiktionary's rules, this user will honor the constraints set out in this proposal. Chernorizets (talk) 03:28, 27 July 2023 (UTC)
Abstain I'm undecided. PUC – 12:25, 27 July 2023 (UTC)
Wiktionary:Grease pit/2023/August § Add the word "dictionary" somewhere in every page