When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.
Back in 2017, the community decided in this RfC that moved pages should be unpatrolled. The feature was stuck in Phabricator purgatory and was never actually implemented.
I'm really surprised so many people supported that: it would create a substantial added burden for patrollers in exchange for maybe making a very rare problem slightly easier to detect. (Redirects from page moves already go into the queue, and even if they're retargeted elsewhere, a good reviewer should notice the suspicious history.) Unless this is a much larger-scale issue than I'm aware of, I don't think that proposal should be implemented. Extraordinary Writ (talk) 08:00, 21 July 2024 (UTC)[reply]
I have seen cases (e.g. recently at AT CBS This Morning) where a long-standing patrolled page becomes unpatrolled because a non-autopatrolled user moved the page - like from vandalism being reverted like CBS This Morning, or from requested moves like (709487) 2013 BL76. There can be quite a lot of these cases. Is this scenario also part of this discussion? thanks. Aszx5000 (talk) 09:36, 21 July 2024 (UTC)[reply]
@Aszx5000 That specific behavior is part of a bug that started happening recently and will be probably reverted. It's being tracked in T370593. The default behaviour is to not unpatrol page that are moved. Sohom (talk) 10:00, 21 July 2024 (UTC)[reply]
I think the RfC should be respected. Yes, WP:CCC but we really shouldn't overturn an RfC without an new RfC. Besides, this will help with detecting move vandalism in some cases so it is a useful change. Nickps (talk) 12:32, 21 July 2024 (UTC)[reply]
Oppose: If the RfC hasn't been implemented in 7 years, and it was only recently implemented by accident, it makes sense to revisit the discussion instead of implementing it by surprise so much later on in time. As one of the more active patrollers, I absolutely hate the idea of adding to the workload / massive backlog by adding pages to the queue just for being renamed. Really we'd want to just mark it as patrolled 99% of the time anyways. Hey man im josh (talk) 14:49, 21 July 2024 (UTC)[reply]
FWIW, I attempted to figure out how much moving and patrolling actually goes on so I could see if making it necessary to re-patrol moves would indeed add a significant workload. I came up with 916 moves and 1225 patrols yesterday. My SQL is weak (and my understanding of the MediaWiki schema even weaker) so I don't know if these numbers are accurate or not. If they are, then it looks like this would almost double the patrolling workload. RoySmith(talk)15:33, 21 July 2024 (UTC)[reply]
Though, as usual, raw statistics are misleading. Neither of our queries, for instance, try not to count page moves by autopatrolled users, or pages moved out of the main namespace without leaving a redirect or where the redirect was later deleted. I can at least compensate for the small sample size by showing stats for all of July up to now, which are better: 7068 page moves starting in mainspace, 13519 mainspace page curations. —Cryptic16:55, 21 July 2024 (UTC)[reply]
Oppose. I don't see much of a point in implementing this as it would unnecessarily double the workload of the NPP team. Redirects left behind from moves are already placed in the redirect queue (except for users in the page mover, autopatrolled, and redirect autopatrolled groups, including administrators). DannyS712 bot then automatically reviews a portion of them if the changes fit certain criteria, and the rest are reviewed manually. I feel like this system works just fine; it's not like we have a runaway page-move vandalism issue on our hands. —TechnoSquirrel69 (sigh) 17:50, 21 July 2024 (UTC)[reply]
Oppose. To quote myself from 2017: Oppose pending more information. I'm concerned about rushing into something that will potentially hugely increase the load at the already hugely-backlogged WP:NPP. How many pages are moved per day? How many more reviewers would we need to handle the extra load? What's the scale of this problem? Are there other solutions we could explore (e.g. marking pages that have {{disambig}} removed as unpatrolled)? We have the answers to some of those questions above, and it's not looking good. Doing this would double the NPP workload in order to close a loophole that is apparently so small that nobody noticed it had been accidentally left open for the last seven years. Really bad idea. – Joe (talk) 21:35, 21 July 2024 (UTC)[reply]
Comment: the proposal as it developed in the 2017 RfC was not for all article moves but for those by non-EC users which I think was 40 a day at the time. Cenarium's comment is not clear to me but search for "40" (not pinging them because they have not edited since April). Pinging @Ivanvector: who initiated the proposal for their comments. We don't know if this is still a concern or if other mechanisms were put in place. S0091 (talk) 19:39, 22 July 2024 (UTC)[reply]
not for all article moves but for those by non-EC users which I think was 40 a day at the time. This somehow ended up not reflected in the 2017 RFC close and not reflected in the 2017 Phabricator ticket. We could go off on a tangent about whether that RFC was closed correctly or not, but I think it's a non-issue because we'll get a fresh consensus in this RFC that will override any lack of clarity about the previous close. –Novem Linguae (talk) 23:58, 28 July 2024 (UTC)[reply]
??? I don't know that area that well because that not normally where I do my NPP work but I thought this was already happening. For example Extracorporeal procedure was in the cue. The community really needs for fix some things to help with the disaster at NPP but worrying about easy stuff like this really isn't it. North8000 (talk) 20:28, 22 July 2024 (UTC)[reply]
Oppose: Unnecessary. They will almost always be marked as reviewed immediately, so this just adds a pointless burden to the NPP queue. CFA💬22:15, 28 July 2024 (UTC)[reply]
Currently if a user clicks "Add a topic" on an article talk page, a box appears which prompts them for a "Subject" and a "Description".
"Description" is somewhat cryptic in that context, and seems like a placeholder string that was never reassessed. A talk page message or question isn't really a description of anything. In some contexts (like Talk:ChatGPT and Talk:Google, talk pages which ended up locked in response to so many people mistaking "Add a topic" for a direct query to those services) asking for a "Description" may, to some users, look more like a prompt to communicate privately with a generative AI or web service, rather than the start of a human conversation with Wikipedia editors.
I raised the suggestion more broadly at the idea lab earlier in the year and was told that, regarding a change to this specific interface message, altering these strings will affect all pages. This change has to be very carefully considered. So here's a concrete proposal to change it. Will "Your talk page comment" make sense in all contexts where this string is displayed, and would we agree that it was an improvement on "Description"? Belbury (talk) 14:06, 8 August 2024 (UTC)[reply]
We can certainly improve on "description", and "Your talk page comment" would be such an improvement although I am not immediately certain it is the best we can do - especially if this appears anywhere other than talk pages? Perhaps something as simple as "Your message" would work? Thryduulf (talk) 14:13, 8 August 2024 (UTC)[reply]
I think our motivation behind keeping it so aggressively-generic was that we weren't sure what places were using the "new section" form that this takes over, and we wanted to avoid something like "start a new discussion thread" as being too specific to only talk-page workflows. (The thing to watch out for is places outside the talk namespaces, that use __NEWSECTIONLINK__ to get that behavior...) DLynch (WMF) (talk) 17:12, 12 August 2024 (UTC)[reply]
Thryduulf, oops, looks like the URL contained NEWSECTIONLINK, which caused it to be parsed as the prop and not as a URL. I've edited it to add "deletethis" — follow the link and delete those words and then it'll work, or just use Anomie's better method below. Sdkbtalk02:20, 13 August 2024 (UTC)[reply]
I don't know how to use the API or run db queries, but the special page worked. I've not got time right now to look in detail, but that reports there are a lot more uses in non-talk namespaces than I expected:
Many of these are going to be appropriate (e.g. on this page, the portal page titles suggest they are nomination spaces) but I wonder especially about the articles. Thryduulf (talk) 02:17, 13 August 2024 (UTC)[reply]
I suspect the articles will turn out to be either vandals being weird or people not knowing what stuff does and throwing a bunch of magic words on the page trying to get Google to index a new article. Of the handful I spot-checked, I saw one that seems like the former and a bunch that seem like the latter. Anomie⚔02:36, 13 August 2024 (UTC)[reply]
There were 9 remaining in article space, all redirects. I have removed them, along with other code. It seems it was often added with other magic words in a group (eg.), so perhaps your second theory, although I wonder where the collection of magic words is found. CMD (talk) 20:49, 15 August 2024 (UTC)[reply]
This is a smart suggestion; thanks for raising, Belbury! I'm inclined to support "Your message" for conciseness and to be on the safe side given Thryduulf's concern that it might be used outside of talk pages. Sdkbtalk15:15, 8 August 2024 (UTC)[reply]
I agree with the idea, but would be inclined to suggest "Your comment", given that "Your message" might still be mistaken for a ChatGPT/Google/etc. prompt query. Chaotic Enby (talk · contribs) 18:06, 9 August 2024 (UTC)[reply]
"Your comment". Just based on widespread, almost universal Wikipedia terminology. Messages are for emails and texts—things that are sent, not posted. ―Mandruss☎18:22, 9 August 2024 (UTC)[reply]
Thank you for the ping, @Sdkb. And thank you, @Belbury for prompting us to reconsider this message.
Generic enough to be helpful in the range of contexts it will ultimately appear
With the above in mind, what do you all think about starting with something a bit more specific like, Topic description and seeing if/how that proves effective? From there, we can consider whether further iteration is needed.
Meta: I feel moved to say: it's a delight to work on a project with folks like you all who consistently pay close attention to details of this sort in service of improving peoples' experiences contributing to our mission. Thank you to @NAyoub (WMF) for reminding the Editing Team of this point when discussing this offline earlier today ^ _ ^ PPelberg (WMF) (talk) 17:56, 15 August 2024 (UTC)[reply]
I like the idea, we can start with this! I still fear Topic description might still be a bit too abstract in a way, as it doesn't really indicate that the "description" corresponds to the message that will be posted on the page. Nonetheless, definitely an improvement over what we currently have. And yes, fully agree that details like this are much more important than people realize, happy to see the WMF team on board with this too! Chaotic Enby (talk · contribs) 18:03, 15 August 2024 (UTC)[reply]
I agree with ChaoticEnby about being too abstract. To me, "description" is meta; it's about something but isn't the thing itself. Your message or Your comment or even Your post are less confusing. Schazjmd(talk)18:17, 15 August 2024 (UTC)[reply]
I agree with Schazjmd that "description" is meta; it's about something but isn't the thing itself. - it's a better fit for the edit summary than the main substance. An exception might be if it was paired with "Title" but then I'd be expecting a third box in which to post the details. Thryduulf (talk) 18:34, 15 August 2024 (UTC)[reply]
Thanks for the response! The range of contexts where the message appears is definitely key to any decision here, so it would be good to establish for sure what that range is. The Special:Pageswithprop search above shows that the __NEWSECTIONLINK__ magic word (which causes the "Add topic" tab to appear, creating a Subject/Description box when clicked) is being used across various different types of non-talk page, which seem to break down into:
Pages of sequential, titled conversations which are effectively functioning as talk pages (like Wikipedia:SVG help, Help:Books/Feedback), where a string of "your comment/message" would still work.
There's also some unusual niche usage of the magic word to, I assume, create a handy shortcut for starting a new section on a log-type user page (User:Fabrickator/questionable edits).
Should the second and third cases be something to bear in mind when crafting a message, or can they be regarded as misuse of the __NEWSECTIONLINK__ magic word, and not something to worry about?
And are there any other places in Wikipedia where the discussiontools-replywidget-placeholder-newtopic "Description" string would appear, unrelated to __NEWSECTIONLINK__ magic word? Belbury (talk) 18:53, 15 August 2024 (UTC)[reply]
Those second/third cases are definitely the sort that we were concerned about when introducing the tool -- we thought that if we came in and took over the existing section=new behavior, we'd wind up stepping on the toes of people who had built up workflows around it (or at least, would be surprised by us auto-signing things). To that end we have a bunch of checks that determine when we actually take over from the old tool...
Summarizing here from the code that spells out whether following the ?section=new link on a page should open the new topic tool:
It must be an edit page (action=edit or veaction=edit) with section=new
It must either not be using any preloads (editintro, preload, etc) or have opted in via adding the `dtpreload` parameter to the URL
It mustn't be trying to preview / switch from some external tool via having posted a field named `wpTextbox1`
Then the new topic tool must be enabled for that page in general, meaning the URL has `dtenable=1` as a parameter OR
It's a wikitext content-model page (but not liquid threads)
It doesn't have the NOTALK or ARCHIVEDTALK magic words
It's in a namespage that wants signatures (any talk namespace, or $wgExtraSignatureNamespaces), or it has the NEWSECTIONLINK magic word
Finally, it must be available to the user, which is a combination of "turned on for that wiki" and the user actually having it turned on in preferences (Editing > Enable quick topic adding).
So! All that adds up to the challenging-to-search for part: pages in wants-signature namespaces that don't have NEWSECTIONLINK (we can probably assume that anything in an actual talk namespace is either really talk or won't be too offended if someone assumed it was), but which are somehow linking to the section=new tool as part of some on-page flow, perhaps even using the preload parameters so the user can fill out a form-template. Here on enwiki the extra signature namespaces are just Wikipedia (NS_PROJECT) and Help (NS_HELP) -- the question's much trickier if we were talking about some discussion/coordination focused wikis (mediawiki.org, metawiki, etc) which have their main namespace as an extra signature namespace.
For instance, if you follow this link to AfD with the right url parameters you'll get the new topic form, even though it doesn't have NEWSECTIONLINK. This is obviously not the way to interact with AfD specifically, but you can imagine some other process-page that does work this way...
That said, I think there's a fair extent to which "how should these process pages and magic words work?" is a community question. Our default message choices were kinda based around not wanting to cut off options / break existing processes, particularly since they had to fit more than just a single wiki, and I think (not having talked to Product about it) that we wouldn't want to drift too far away from that for the default... but a particular wiki wanting to tighten it up seems fine, so long as you're aware of the trade-offs. DLynch (WMF) (talk) 20:13, 15 August 2024 (UTC)[reply]
Yeah, separately from the question of exactly how talk-specific it should be, I agree that we might want to tweak the generic-default over to something a little more indicative of "this is the body-text of a message"... DLynch (WMF) (talk) 20:30, 15 August 2024 (UTC)[reply]
While attending Wikimania this year, Selena Deckelmann (User:SDeckelmann-WMF) demonstrated a new feature for Visual Editor, Edit Check in a session. Edit check introduces additional prompts in Visual Editor when an editor tries to insert a blacklisted URL as reference and also when they try to publish a revision without inserting a reference. This greatly helps with encouraging editors inserting references in their edits. If I recall correctly, the percentage of editors inserting references increased from 11% to 40% in their tests (do correct me if I am wrong as I am going off on my recollection).see #What's next? for corrected stats
There is certainly some benefits in enabling this, primarily on improving the verifiability and reliability of content that's on English Wikipedia. Most of the sister projects have already been deployed with this feature. English Wikipedia does not have this feature enabled yet. The only thing that is holding back this feature is that Visual Editor is not set as the default editor for anonymous and new editors.
Therefore, I would like to propose that:
Visual Editor be the default editor for anonymous and new editors.
The last time I checked, new editors are presented with a pop-up box that asks them to choose which editor they'd like to use, with the solid blue button pushing them a bit toward the VisualEditor.
This thread is rather underdeveloped. For a proposal of this magnitude, I think we should figure out relevant factual questions (like what the current default is) and then draw up a more formal survey that could be CENT-listed, etc. Sdkbtalk19:05, 9 August 2024 (UTC)[reply]
Another question is how does it work with edits that don't need references adding (e.g. creating redirects, adding links on disambiguation pages, fixing spellings, etc)? Thryduulf (talk) 19:08, 9 August 2024 (UTC)[reply]
In theory, this sounds like a great idea. I'm eager to try it out, but I think a first step would be to make it available as an opt-in on enwiki. Then after people have got some experience with it, let's come back and talk about making it the default. RoySmith(talk)20:09, 9 August 2024 (UTC)[reply]
There's a simpler option for userscripts that should work: window.MWVE_FORCE_EDIT_CHECK_ENABLED=true;
So long as that's there before VE loads, it should force you to have edit check. Either method also bypasses the account restrictions on edit check, so you're not quite getting the pure experience that people would if we just turned it on for enwiki. By default it only shows up for new users (defined as under 100 edits), and someone might want to edit the configuration on-wiki for that. DLynch (WMF) (talk) 21:26, 9 August 2024 (UTC)[reply]
The add-reference check is very conservative currently. You need to be a user with less than 100 edits who has added a whole new paragraph of at least 50 characters (configurable per-wiki) that contains no references before it'll pop up. This can all be loosened up in the future, whether by default or through community configuration, but we figured that those criteria had pretty low odds of being a false positive to start with.
It's quite interesting that this boosts the percentages so much, because I honestly thought that complete new-editors would be doing far more minor edits. But no, major new blocks of text are pretty popular.
It's actually turned on with the reference check everywhere but 8 of the wikipedias (bn, de, en, hi, id, nl, pl, ru), so it's pretty easy to try it out on another wiki if you don't want to jump through userscript hoops here. DLynch (WMF) (talk) 21:34, 9 August 2024 (UTC)[reply]
Not sure where ReplyTool will put this, but nothing I'm seeing in the documentation requires VE to be the default editing interface in order to deploy the new tool. So deployment doesn't seem contingent upon answering the larger question of whether VE should be default. Folly Mox (talk) 22:17, 9 August 2024 (UTC)[reply]
Unless things have changed in the last year, it doesn't need it to be the default, but editor does need to be in the visual editor, and that's somewhat more likely to happen (especially for the editor's first edit) when the visual editor is the default. WhatamIdoing (talk) 01:29, 10 August 2024 (UTC)[reply]
The functionality is targeted towards new editors and anonymous editors, therefore the need for Visual Editor to be the default before the deployment of the functionality is considered complete. Also there are on wiki configuration options that we may want to adjust. As stated by Dlynch (WMF) above, the tool is configured by default for an user with less than 100 edits and making revisions of more than 50 characters. – robertsky (talk) 04:15, 10 August 2024 (UTC)[reply]
Minor quibble: enwiki has already got the prompts about blacklisted URLs for references/links. We rolled those out everywhere on the logic that any edits involving them were going to get blocked-on-save anyway so it wasn't going to disrupt any workflows. :D
It's a bit fuzzy because we called the project "Edit check", and we're developing a specific system called edit check (of which the "add reference" check is the first example), but we're also doing smaller edit-enhancement features along the way that colloquially get called checks just because of the project.
Conduct a thorough analysis of the potential consequences of setting Visual Editor as the default for anonymous and new users. Consider factors such as user experience, editor retention, and overall editing patterns. If making Visual Editor the default is not feasible, investigate other strategies to increase Edit Check adoption. This could include targeted outreach to experienced editors, promoting the feature through in-editor messages, or developing incentives for reference usage. Regardless of the chosen approach, it's essential to closely monitor the impact of Edit Check on reference usage and article quality. This data will be crucial for refining the feature and measuring its overall effectiveness.
I'd support making Visual Editor the default, as long as they also leave wikitext editing as an option (which I'm sure they will). VE is much better nowadays than when it was first released. As a WYSIWYG editor, I suspect it is much more new editor friendly. It is unarguably better at things such as automatic citation generation and table editing (adding and removing columns and rows, moving columns and rows around). And for the few things it is bad at (such as complicated template syntax), power users can just switch to wikitext editing. Any logged in user can select their default at Special:Preferences (under "Editing mode"). –Novem Linguae (talk) 10:47, 10 August 2024 (UTC)[reply]
I totally agree that VE should be the default for new users. I use VE every day, and it's just fine for most stuff, and getting better incrementally. Folks who think VE should not be the default should go to edit-a-thons and try teaching new users. 20 years ago, wiki-markup was the new hotness and was miles ahead of editing raw HTML. Today it's just a barrier to entry for potential new editors. RoySmith(talk)12:24, 10 August 2024 (UTC)[reply]
When I first edited English Wikipedia as an IP editor, I found WikiText editing very difficult to understand. I’m sure that most new IP editors face this issue. I strongly support making the Visual Editor the default. New IP editors are often unfamiliar with Wikipedia and may not know how to cite a reference using the WikiText editor. They may also not know how to switch to Visual Editing. Frankly, I still have to check the preview before publishing edits using the WikiText editor because I sometimes make mistakes. GrabUp - Talk11:08, 10 August 2024 (UTC)[reply]
Potentially minor bugbear alert: The visual editor reference creator still hasn't figured out the basic functionality of allowing for an easily accessed and obvious use of an |author= field, instead forcing all authors into |last and |first. It's not a groundbreaking issue, but it's really disappointing that it's still around after so long, especially given the many words given over the years about attracting more diverse perspectives etc. The default reference tool that we are going to create a pop up asking all new editors to use should allow for sources from authors whose names don't fit into the common European name format. It may be hidden behind an additional field button, but at least the wikitext reference creator has the option. CMD (talk) 12:10, 10 August 2024 (UTC)[reply]
My biggest bugbear is the lack of ability to set a reference name. For example in this edit I switched from visual to source editing so I could reuse citations between prose and infobox. Although admittedly this is not something a brand new editor wants to do, being able to set a name other than ":0", ":1", etc would be rather handy. Thryduulf (talk) 12:28, 10 August 2024 (UTC)[reply]
Is naming references a policy? Or is it something you consider useful? I don't edit the code. I just reuse citations when I need them, directly from the citation insertion menu. Very convinient. 37.169.50.102 (talk) 12:52, 11 August 2024 (UTC)[reply]
I mostly work in VE; I'm not personally bothered by the opaque names (i.e. ":0") that VE invents because I never see them. But many people work in wikitext, where having human-friendly names is important. So, I agree that improving support for reference naming should be a high priority. RoySmith(talk)12:57, 11 August 2024 (UTC)[reply]
I just went looking, and I don't see a Phab ticket for this. I was a bit surprised there was no ticket, but then I thought about it a bit more. It's probably hard to come up with a wiki-agnostic way to generate good citation names. You'd have to program it with something very enwiki specific to get it to read our unique citation templates then extract the author last name and year from them. User:Nardog/RefRenamer is a good workaround though. –Novem Linguae (talk) 13:14, 11 August 2024 (UTC)[reply]
I thought we were talking about auto-generating good names. Those tickets are for something else. Maybe I am misreading this subsection though. Apologies if we are not actually talking about auto-generating good reference names. –Novem Linguae (talk) 13:20, 11 August 2024 (UTC)[reply]
When copy pasting named references to another page, you get false matches that are not obvious. If automatic named references were more unique (slugified title) this false collision would happen less often. I am all for hiding/abstract workflows where needed. ~ 🦝 Shushugah (he/him • talk) 13:03, 11 August 2024 (UTC)[reply]
All programmers should read Falsehoods Programmers Believe About Names, and then re-read it every few years to refresh their memory. People who design database schemas should re-read it every time they start a new project. I agree that it's not a showstopper for our purposes, but it is a surprising lack of cultural sensitivity from an organization which is so into i18n.
For me, the biggest bugbear is that there's no good way to convert a {{cite web}} into another template without basically starting from scratch. It really should be smart enough to figure out that if {{cite web}} has a "first=" field, it can safely map that into {{cite news}}'s "first=" and so on. It won't be perfect, but it'll get you most of the way there. RoySmith(talk)12:57, 10 August 2024 (UTC)[reply]
@Chipmunkdavis @RoySmith Visual editor follows the definition of the template parameters at Template:Cite web#TemplateData (and so on for other cite templates). I think the developers would also wish that you didn't require the name to be split into two fields; it's a chore to fill it out this way. If you think this can be changed, please edit it there. Matma Rextalk13:58, 10 August 2024 (UTC)[reply]
@Matma Rex you are entirely correct that VE gets its field definitions from the templates. The first part of my comment about first_name/last_name ethnocentricity applies equally well to template writers.
But, the part about being able to convert one type of citation to another really is a VE issue. The "automatic" feature of the VE template editor is very handy, but it often can't intuit the proper type of template (that's not VE's fault) and falls back to using {{cite web}}. It would be really handy if you could say, "Please make that into {{cite news}}, and do the best job you can converting the fields". RoySmith(talk)14:38, 10 August 2024 (UTC)[reply]
|author= is already present in the existing template parameters, even if just as an alias of |last. Not presenting the alias in VE is a choice of VE, the buck should not just be passed to blindly following a particular table. CMD (talk) 14:56, 10 August 2024 (UTC)[reply]
It might be controlled by the WP:TEMPLATEDATA in something like Template:Cite/doc. I think VE reads the template data to determine the parameters it displays. If a parameter is omitted or set as hidden, perhaps it is not displayed. Not 100% sure but that is probably worth checking. –Novem Linguae (talk) 15:08, 10 August 2024 (UTC)[reply]
Assuming it is, then it would be really useful to have some statistics of how often VE (I know, I should really be saying Citoid or Zotero, or something else, but I'll just keep saying VE because that's what the end user sees) gets it wrong. I'm not entirely sure how we would define "gets it wrong", but a first pass might be "VE initially calls it {{cite web}} which is later corrected to a different {{cite xxx}} variant". Some of that might require instrumentation inside VE to detect when the user abandons a constructed citation before saving it. Some of it might require analyzing revisions to the page to see when template types are corrected after the fact. But let's assume one way or another, we could build a log of incorrect categorizations.
Then what we would do is take the full log of these reports, group them by top-level domain, and sort by frequency. If it came out that "bxtimes.com" was the most frequently domain which got mis-categorized, then it would be the highest priority for a human to go figure out how to fix and add that knowledge to the VE (Citoid? zotero?) database. After enough iterations of fixing the highest priority ones, we'd end up with a better system. If (total SWAG here) we could find the 100 top problems that accounted for 50% of the total errors, with a very small amount of human work to fix them, we could have a major win.
It sounds like a reasonable stab at the misassignment-of-citation-templates issue.
Caveat up front: I'm a developer, but I've never actually touched the internals of Citoid+Zotero, so I might be wrong about details here. That said, I believe you're right that the classification part happens entirely in Zotero, and further that if you want to teach Zotero about how to classify a new site there's some guidelines we have for that over on mediawiki.org. This coming from Zotero is also why we have vastly more classifications than we actually use on-wiki -- check out the mapping for that.
It's possible that some of the incorrect template-usage you see could be at the level of those mappings, as well -- I note that the `statute` type is just hooked up to the generic `Citation` rather than to {{Cite_act}}, for instance, though that's probably far from the most common one to need.
As for the specifics of working that list-of-sources out...
We do have some instrumentation inside VE already that could probably be looked at to work out how often someone gets all the way to the "presented with a citation-template" step and then abandons it, which would give us an okay up-front guess at the rate where something is wrong with the generated citation. Ignoring the question of other types of failure for now, the next problem is that our VE usage-instrumentation is carefully ignorant of content for privacy reasons, so it doesn't know anything about what URL was looked up when that happened. Looking for revisions which consist of just a citation template being replaced with a different citation template sounds doable, albeit slow.
I wonder if we could approach it another way. Assuming that Zotero has some internal logging of the translator it used when we make a request to it, or that it can be persuaded to tell Citoid this, we could perhaps add some logging for requests that fall back to the default-translator for unknown pages. That's not a perfect match for the misclassifications, but it's much easier to find. It does leave out cases where the translator exists but is getting it wrong, of course. DLynch (WMF) (talk) 01:46, 11 August 2024 (UTC)[reply]
it doesn't know anything about what URL was looked up when that happened does it know/track what type of template it chose? If so we can possibly work out what proportion of e.g. cite-news vs cite-web generations were abandoned? I don't think, ottomh, there would be any privacy issues with that? Thryduulf (talk) 01:53, 11 August 2024 (UTC)[reply]
Unfortunately not. All it tracks is that a citoid request happened, and then either that the "insert" button was chosen or that something was done to move away from the citoid results list. It doesn't even track what type was chosen if you go to the "manual" tab and explicitly pick one of the templates listed there.
I do agree it seems very unlikely to be a privacy issue. I mostly mentioned that was the guiding principle to explain why the case for so many questions like this turns out to be "we never needed this actually-very-innocuous content-related data before, so we weren't collecting it". DLynch (WMF) (talk) 02:09, 11 August 2024 (UTC)[reply]
Superb Owl has been maintaining a table of domain names where mw:Citoid has trouble producing a correct citation at User:Superb Owl/Community Wishlist § Automatic Citation Tool. As I understand it, Citoid's problems are partially due to how it scrapes target pages, and if domains are not putting all the information we need in <meta> tags then our only recourse is to improve Zotero translators directly.However, Citoid is understandably geared towards internationalisation and extension to all Wikimedia projects. En.wp has a considerably more complicated / sophisticated / mature citation framework than probably anywhere else. Little things like an automated citation using {{cite web}} instead of {{cite news}} or {{cite periodical}} don't bother me: User:Citation bot converts these, and the only template type it really struggles with is conversion to {{cite book}}, which has a pretty different parameter set.What does bother me about the automated citations output by the Visual Editor (apart from all the <ref name=":0">) is how often it just dumps out obviously incorrect information with no message to the user. Things like |last=B.C. |first=Sima, Qian, approximately 145 B.C.-approximately 86 (1); |last=Company |first=Rand McNally and (2); |last=Feb. 1 |first=the Office of Communications on |last2=2019 |last3=P.m |first3=3:06 (3); |last=à 00h00 |first=Par Le 2 avril 2008 (4); |first=Government of Canada National Research Council|last=Canada (5), etc, etc, etc, bonus consequence.A few days ago, I floated the idea to add a layer of error-checking into the VE citation generation interface. That's really all we need, I think. It shouldn't be the responsibility of WMF staff to ensure that every citation generated by their tools somehow makes sense for our project. But if there could just be one extra step for editors using the interface, where they could see the errors their automated citations are causing our community-maintained modules to throw, maybe they'd take the steps necessary to compare the output against the source and correct the problems before publishing.This won't fix every problem, obviously: algorithmically generated citations are only perfect when they draw on structured metadata that maps properly and completely onto our template parameters. But being able to get feedback during the edit should help editors in the VE environment clean up some of their own messes before they hit mainspace, unreviewed at the bottom of the article. Folly Mox (talk) 12:37, 11 August 2024 (UTC)[reply]
@RoySmith, @DLynch (WMF), @Folly Mox, speaking from experience from creating Zotero translators for a couple websites that I frequently use for citations, errors like this are more often than not a byproduct of missing specific Zotero translator rather than anything else. The default translator will interpret og:type = article as itemType = 'webpage', therefore citiod will use {{Cite web}}. This is unfortunate as even in the default translator's own test cases, vox.com is expected to return as 'webpage' for itemType. However, I would agree with this output, as in Open Graph Protocol, the last object type specified is 'article', and I am assuming that that's the fallback for Facebook as Facebook would use the embedded preview for articles if there's no og:type in the header (i.e. Facebook debugger on wikimedia.sg).
Therefore, what's needed to be done is to either have another translation layer on citiod to map generated citations from identified websites to use {{Cite news}} instead of {{Cite web}}, or write a specific translator for bxmedia.com, or investigate if the default translator in Zotero can be extended further so that the rework for specific websites can be minimal. – robertsky (talk) 18:16, 11 August 2024 (UTC)[reply]
Actually, passing Citoid's output directly to Citation bot before returning it to the editing interface – one specific implementation of another translation layer – sounds like a minimally effortful solution using tools already deployed and currently maintained. Citation bot doesn't fix everything (and breaks some things) but it usually does a good job in selecting which template type to apply to a citation, and in mapping data to appropriate parameters. Folly Mox (talk) 18:35, 11 August 2024 (UTC)[reply]
Yes. I have it enabled as an user script. It just won the Coolest Tool Award for improving the quality of edits. While I appreciate the work there, I also wish there is an easy way to translate the JSON files to Zotero translator format so that the work can be enjoyed by those who cannot use it out of the box on Wikipedia and everyone else who is using Zotero in general. – robertsky (talk) 08:36, 12 August 2024 (UTC)[reply]
65, I had heard of that tool, but wasn't previously aware of its functionality. It looks like a great idea, but for the fact that it is presented as an option to Citoid's output rather than a replacement of it (community generated translators for domains Citoid struggles with should – by definition – always be superior).I'm not interested in apportioning blame for Citoid's output: generalised parsing of html meta elements across the entire set of domains is a hard problem and a big task, with a lot of people involved in every step. But it remains true that for a significant portion of domains lacking structured metadata, Citoid's output ranges from suboptimal to unusable.Any additional translation layer that can be configured by the community would be superior to none, and that functionality should exist in Visual Editor so as to improve the quality of citations generated and reduce the maintenance burden shouldered by script maintainers and experienced editors on this project. Folly Mox (talk) 11:29, 13 August 2024 (UTC)[reply]
Please post corresponding Phabricator tickets for all mentioned "bugbears". 1) Having tickets for these things and 2) making noise in them is the best way to move these fixes forward. –Novem Linguae (talk) 14:31, 10 August 2024 (UTC)[reply]
Thanks all who have participated in the discussion above. I wil admit that this is my first time opening a proposal. Apologies if it is lacking in some details. While early, it seems that at this juncture, there a large support among the participants to have Edit Check deployed and/or Visual Editor be set as the default editor, keeping in mind that there are still some bugbears, or wishes to have some citations related issues resolved (honestly, I think belongs to another thread, but I appreciate the discussion nonetheless). I would like help in bringing this proposal to the next step of having it as a CENT discussion, be it by opening another thread/discussion here or elseswhere, or reformating the current one.
Impact report
In the opening, I presented a wrong statistics from the test that the product team conducted. Upon further check, I found the impact report on reference checks. Short of reproducing the whole report, these are the key numbers:
The number of constructive edits from newcomers increased from 19% to 42% (2.2 times more. As defined by newcomers with less than 100 edits and not reverted within 48 hours).
Breaking down the above number, this is consistent across all wikis with the test on. And on mobile, the increase was 4.2 times more.
Contributors that are shown Reference Check and successfully save a non-reverted edit are 16 percent more likely to return to make a non-reverted edit in their second month (31-60 days after).
10% decrease in edit completion rate for edits where Reference Check was shown
1.8% false nagative
6.6% false positive
From the report, we can see that Edit Check, in particular the Reference Check functionality, helps with improving the content contribution of newcomers and helps to improve the retention of newcomers as well. The 6.6% false postive rate may be a concern, but in my opinion, a minor one. Details from the report indicates that some of the dismissal is essentially WP:SKYISBLUE. Additionally, further finetuning of the configuration for the Reference Check may be made as well to attempt to reduce the false postive rate.
Questions asked
The following are some questions and answers summarised from above (feel free to add more):
Qn: Is Visual Editor is the default editor for newcomers on enwiki?
No. Newcomers are presented with an option to use Visual Editor upon first edit. Declining it will let editors to use source editors instead.
Qn: how does it work with edits that don't need references adding (e.g. creating redirects, adding links on disambiguation pages, fixing spellings, etc)?
The default configuration of needing 50 characters or more before the Reference Check kicks in means that most of the edits asked in the question will not have the Reference Check triggered. Further more, it is for newcomers with <100 edits, therefore it won't be presented to a majority of registered editors.
Qn: Must Visual Editor be the default editor for this to be deployed?
While the functionality is available through a JavaScript switch or through a query parameter, Edit Check is meant for newcomers. If it is not set as default editor, the effacies of Edit Check will definitely be reduced.
Having the user pick whether they want to use visual editor or wikitext editor their first time editing a page (the status quo) seems reasonable and it wouldn't hurt to leave that alone. Perhaps we should just RFC deploying edit check, and leave the visual editor issue alone? The two issues don't seem as strongly linked as I first thought. –Novem Linguae (talk) 06:16, 12 August 2024 (UTC)[reply]
If Edit Check can be deployed without changing the default or not status of VE, it would probably sail through any approval process. If it works, then later someone will be able to pull up stats saying "New editors using VE put references in 80% of their edits but those using wikitext only put them in 15%" or similar to inform that second issue. CMD (talk) 06:45, 12 August 2024 (UTC)[reply]
I should also add that the other target audience is anonymous editors. Right now the experience is as screenshot. This may be a subpar outcome for Edit Check if the primary CTA button is 'Start editing', and the anon/new editors continue to edit in source editor.
As for the statistics of how many new editors are using Visual Editor now, this is one which Foundation staff can help to answer since we do not have the access to user data. – robertsky (talk) 09:54, 12 August 2024 (UTC)[reply]
That information could be gleaned from an appropriate query, since Visual Editor tags its edits. quarry:query/84486 has the first edit for accounts registered in the first half of 2024; something similar and significantly less complicated could probably check for the "Visual Edit" tag. It would be a bit more difficult to include unregistered editors, but a basic usage ratio should be possible to estimate using public data. Folly Mox (talk) 10:32, 12 August 2024 (UTC)[reply]
@DLynch (WMF), I believe these stats are on a Superset dashboard. Can you pull them? If memory serves, there's one query for the first five edits and another for the first 100, but I don't know if one is set up for the first edit alone. WhatamIdoing (talk) 22:40, 13 August 2024 (UTC)[reply]
Edit check will work the same way for VE editors whether or not VE is default. Either way, any usage stats will be within VE users. The message given to anonymous editors who click edit, and the default or not use of VE, do not affect Edit check outside of absolute usage numbers. Generally for new features we have adopted small trials rather than immediate maximal pushses, so in that respect the current VE setup is more a benefit than an issue. CMD (talk) 11:42, 12 August 2024 (UTC)[reply]
@Chipmunkdavis, if the community thinks that an intermediate step to trial out this among the newcomers who enable Visual Editor first is required, we should explore the idea. This may simply mean that window.MWVE_FORCE_EDIT_CHECK_ENABLED=true; or the query parameter should be set in MediaWiki:Common.js (and maybe MediaWiki:Mobile.js as well), of course with account restriction criteria being set to limit the force enablement to newcomers of <100 edits.
letuserEC=mw.config.values.wgUserEditCount// wgUserEditCount: null for anon editors and non null value for registered editorsif(userEC===null||(userEC!==null&&userEC<100){window.MWVE_FORCE_EDIT_CHECK_ENABLED=true;}
I don't see how enabling edit check is an intermediate step, unless the plan is to later expand it to <500 or <1000 edits? CMD (talk) 03:42, 15 August 2024 (UTC)[reply]
It is intermediate step to see if Edit Check on enwiki does encourage an uplift in new/anon editors who are using VE adding content with references. Dependent on the result, we then can determine if it is beneficial to have VE to be the default editor with respect to Edit Check. – robertsky (talk) 05:30, 15 August 2024 (UTC)[reply]
@Robertsky: respectfully, I understand you've personally operationalized Edit Check deployment as involving making VE the default (which it may be recalled I thought was already the case), but these are two separate things. Linking them muddies the proposal and gives the impression of an agenda.I'd love for Edit Check to be enabled on this project, not necessarily for the initial check of adding a reference to a chunk of sufficiently long text (which sounds like a fuzzy test), but for all the stretch goals we could add to it for giving immediate feedback about identified categories of problem edits.Very little opposition should be expected if you disentangle all the Visual Editor stuff from this proposal, and if you wait until more kinds of checks are implemented – the kinds that save experienced editors from making the same kinds of corrections to newbie mistakes over and over – I think you'll see strong support for making Visual Editor the default when that separate question is revisited sometime down the line. Folly Mox (talk) 10:47, 16 August 2024 (UTC)[reply]
@Folly Mox you are mistaken that I am involved in the operationalizing of Edit Check with VE. I simply come across the feature and think that it is a good idea to have it enabled. Of course, there is also a strong desire to set VE as the default, but I am pragmatic. The immediate personal aim is to have Edit Check enabled and then we see if it is really beneficial for the English community. – robertsky (talk) 14:21, 16 August 2024 (UTC)[reply]
I must not know how to use the word operationalized correctly, which is actually something of a relief 🙃 I was trying to describe a comment of yours above where you explained the need for Visual Editor to be the default before the deployment of the functionality is considered complete. Anyway, glad you're embracing the stepwise pragmatism. Should be an easy pass for the simpler "enable Edit Check" proposal. Often mistaken, Folly Mox (talk) 17:58, 16 August 2024 (UTC)[reply]
The likelihood that newcomers will include a reference the next time they add new content
And while we are confident that enabling the visual editor by default for people who are new will have a net positive impact on volunteers across experience levels, the idea @RoySmith, @FollyMox, and @Whatamidoing raised about decoupling the decisions to enable the Reference Check and VE for newcomers and people who are logged out seems wise. [i][ii]
Reason being: doing so, as I think @CMDput well, seems like a relatively lightweight and low-risk way for us to work together to:
Further, as @CMD, @Thryduulf, @RoySmith, @Novem Linguae, @Shushugah, @Folly Mox have mentioned [iv][v][vi][vii][viii][ix], it sounds like there are some facets of the reference experience that would be worth us talking together in more detail about.
The Link Check evaluates all external domains people attempt to link to against the globally-defined meta:Spam_blacklist and the locally defined, en:MediaWiki:BlockedExternalDomains.json and MediaWiki:Spam-blacklist lists.
The Reference Reliability Checks evaluates the references people attempt to cite against the same local and global lists mentioned above.
Zooming out, I think you all are in the best position to decide what you think the most effective deployment sequence here is. And please know: the Editing Team is ready to support you in what you decide.
Alright, I think this is a good place for me to pause.
Please ping me as new questions about Edit Check and/or VE emerge so that I, or another member of the Editing Team, can try to help.
In the meantime, we're going to continue following this conversation and will chime in when we think there is helpful information we can offer.
iii. We'll be able to filter Special:RecentChanges for edits made with Reference Check. You can see this in action at wikis like fr.wiki, es.wiki, and ar.wiki where Edit Check is already enabled.
x. Please boldly add tickets/issues as you see fit
xi. There is an open task the Editing Team will soon address to ensure each time the Link and Reference Reliability Checks are activated, a log entry is recorded in Special:Log/spamblacklistPPelberg (WMF) (talk) 21:11, 16 August 2024 (UTC)[reply]
Call me wary for a number of reasons. First off is the false claim (also posted at the linked Mediawiki page) that Visual Editor must be the default to deploy this, or the later made implication that it makes no sense to deploy this without making VE the default. If these are coupled in this way, with the bigger change used as a prerequisite for the smaller one, then it is a hard no.
Then there is my last (in a long line) experience with a tool that had been tested or even deployed elsewhere, and worked oh so well (makes me thing of Flow, may it rest in peace). A year ago, we were asked to help with a new tool for the Android App[1]. We were told that "During initial evaluation of the model, it was preferred more than 50% of the time over human generated article descriptions. Additionally, Descartes held a 91.3% accuracy rate in testing." and that it had been succesfully been tested in 15 languages already. When we actually tested, it turned out to be very, very buggy and not usable at all. The result was that in August they posted "We’ve officially received grades for all languages and are now finalizing analysis. We will share the outcomes in next month’s update as well as our recommendations for next steps based on the experiment." and then crickets. So from an A/B tested in 15 languages, successful tool with 91.3% accuracy rate to an abandoned project after one short test by enwiki.
And then I tried to test this new tool here. I added a paragraph of text without a source, published, and got the "add reference" pop-up. Choose "yes", got presented with the automatic reference option by adding a title, typed "Lord of the Rings", no luck, so tried "manual". Click on "Book", and get "thank you for adding a citation!" even though no citation is added. Same result if I manually try to add a website or anything. Perhaps it works in real life, perhaps not, but this certainly doesn't give much confidence. Fram (talk) 13:39, 13 August 2024 (UTC)[reply]
@Fram You may see it as a false claim, but it may simply that for the end goal of Edit Check to encourage better content submissions among all anon and newly registered editors can be met by having VE be the default editor.
Your experience in testing out new tools certainly tempers one's expectations on the viability of tools on the platform. With respect to using AI to generated short description, I would also have similar reservations (my cautious approach to/use of AI is known), and still I have to say that it is an unfair comparison given that we are not expecting 91.3% of the new editors to give references. The A/B test in the impact report shows a more modest uplift of ~x2 inputs. Of course, further detailed analysis on a roll-out (in whatever form) on a trial basis can be made if we can tap on the existing tags (i.e. possible unreferenced addition to BLP) or edit filters or even sorting through the raw data.
With respect to the patchdemo wiki, maybe a more updated wiki mirrors better the current real world setup? The demo was generated back in June 2023, more than a year ago. I would have expected bugs and issues between then and now. Furthermore, it might be a patchdemo for limited use? i.e. to show partially the progress of the work? When testing directly on here in enwiki (until before publishing the edit), the reference are being added as a citation be it automatic or manual mode. – robertsky (talk) 19:05, 14 August 2024 (UTC)[reply]
If you insist that statements that VE must be made the default for this isn't a false claim, then I think we're done discussing this. And I see no reason to trust the WMF on any test results, considering that coincidentally just now they posted the results of that other software thing I mentioned above:
" By the time most of you provided feedback the experiment was already completed, and we already received support from some of your fellow experienced editors of English Wikipedia ". Yeah, right, like you posted in the "January update" which you posted in, er, August. And which is completely unverifiable, is based on a very small number of edits apparently by unknown "experienced" editors. They claim on that page that "If users that see the treatment do not select a suggestion more than 50% of the time after viewing the suggestions, we will not expand the feature". Let's see:
How often were Machine Suggestions Accepted, Modified or Rejected?
So why do they plan to continue with the feature anyway? Same as always, I guess, features aren't abandonded no matter how bad, no matter which promises were made, until after (usually) enwiki or dewiki find out how bad they really are, and even then only after an unnecessary, unwanted clash with WMF has been had and mutual distrust gets cemented for another 10 years. So yes, I don't trust WMF test results, I don't trust WMF promises, I don't trust WMF false claims and those defending them, and I don't support a rollout of such features without much better, verifiable (by us) testing or with added "requirements" which aren't needed but pushed by the WMF anyway. Fram (talk) 08:41, 16 August 2024 (UTC)[reply]
I don't support a rollout of such features without much better, verifiable (by us) testing sure. let's test Edit Check out, as what I have said in my previous replies to others. – robertsky (talk) 16:43, 16 August 2024 (UTC)[reply]
I’ve always been disappointed that Wikipedia doesn’t offer this feature and would love for it to be put in to Wikipedia. Since we have AI around, we can easily create quiz questions on a larger scale for the most popular articles. We could start by implementing quizzes on the main page and going from there. I understand that Wikipedia is an encyclopedia, but the question I came here to answer is that is it just an encyclopedia or is it more than an encyclopedia that includes features that are not just for encyclopedias as a general learning site. Britannica has something similar and I think it would be great not to copy everything it does, but have it as inspiration for creating quizzes. I would like to discuss if Wikipedia should have extra features that make the website more enjoyable rather than just reading and editing. I hope you will consider this suggestion. Interstellarity (talk) 21:33, 10 August 2024 (UTC)[reply]
The NY Times runs a weekly quiz, with questions about the previous week's news stories. It's kind of fun (even if I rarely score above 50%). My guess is if you pitched this to WP:SIGNPOST they'd be happy to run it. On the other hand, there's absolutely nothing stopping you from doing it in your own userspace and announcing it on WP:VP. If people like it, they'll vote with their mouse clicks.
I'm not too on board with including quizzes and other gadgets like this, that are a pretty heavy weight to maintain (especially with having to review all the AI-generated quiz questions), while not really being encyclopedic and probably being an uncomfortable distraction for a lot of readers (including me). However, having them on the Signpost would be cool, although I don't think them being AI-generated is a good thing. On a larger scale, I'm afraid of "feature bloat" where the core thing (here, the encyclopedia) gets buried under layers of gimmicks, ultimately making it much less convenient and not necessarily more enjoyable. Adding more for the sake of adding more isn't necessarily a good thing. Chaotic Enby (talk · contribs) 22:43, 10 August 2024 (UTC)[reply]
The idea of quizzes was discussed in June 2022 and by you in March 2022. As I said in those discussions, anyone should feel free to start quizzes on a project page to establish a track record of being able to produce them regularly, and to figure out what audience exists for this feature. isaacl (talk) 04:03, 11 August 2024 (UTC)[reply]
Heh, I just looked up the March 2022 discussion (which I had long since forgotten about) and discovered that I said almost exactly what I said here :-) RoySmith(talk)14:45, 11 August 2024 (UTC)[reply]
I don't get why we need things like extensions and AI to run quizzes. Quizzes existed long before Mediawiki and AI. Just take a couple of minutes to ask a few questions each day/week/month in your user space and advertise it on one of the village pumps and/or Signpost. If the feature is popular then it can be formalised to the main page etc. Nothing will happen unless someone (most likely you) volunteers to do it. Phil Bridger (talk) 08:40, 11 August 2024 (UTC)[reply]
Wikipedia already has loads of extra features that make it more enjoyable, most of which are dramaboards 😉 The true "extra feature" that makes Wikipedia so great is how lightweight and on-mission it is. Even on a bad connection, on a slow device with an old browser, I can navigate to a Wikipedia article, and it will load the whole thing for me to read (certain restrictions apply).I don't have to stop the page loading before stylesheets are applied because it can't reach an advertising partner, I don't have to leave the tab open two minutes and go do something else while my phone wearily executes javascript routines, I just open the page and read the page, like how the internet used to be before it became total capitalism garbage.Any extra interactive features added to the default experience reduce our availability and usability for people on the lower end of computing resource / network infrastructure privilege. It feels important to preserve that equity.So I guess my position is: no, Wikipedia isn't just an encyclopaedia— it's also an online community; but also no, Wikipedia isn't a general pedagogical resource— it's pretty much just an encyclopaedia with an active editing community. Folly Mox (talk) 13:27, 11 August 2024 (UTC)[reply]
For sure! I probably could have done a better job in selecting a qualifier than the term "general" in general pedagogical resource, or maybe should have chosen different words altogether. I was attempting to communicate my personal opinion on the OP's question on whether Wikipedia is just an encyclopedia or is it more than an encyclopedia that includes features that are not just for encyclopedias as a general learning site.Folly Mox (talk) 09:47, 13 August 2024 (UTC)[reply]
Sure, why not! It's an education website. This is something many loose track of, we are in the business of a non-profit education resource. The best way to do this is start a Project and run the quizzes in project space. Once it has a following and support, which might take years and press exposure, then consider something on the front page. -- GreenC20:37, 12 August 2024 (UTC)[reply]
It would surprise most outsiders viewing our non-article space, as well as new editors, that civility is a required as a matter of policy, and is so theoretically important that it is one of the project's Five Pillars. The section on civility in the Five Pillars has an almost quaint sound to it, like something preached in church that no one actually observes. In certain project areas, a kind of "toxic workplace" atmosphere exists, in which low levels of hostility are the norm, are taken for granted, and as a practical matter are not subject to sanction.
We used to have an informal sounding board to deal with civility, WP:Wikiquette assistance. When WQA was shut down in 2012 in a discussion on this board, the community found that WQA "did more harm than good," but there was "also a consensus that there needs to be an intermediary process between the talkpage and ANI, now that WQA is closed." No such intermediary board was ever created, and as far as I can see, perhaps I missed it, but searching through the archives of this board I see no discussion of creating such a board since 2012. I think we need to revisit the topic and create an intermediary civility board. Perhaps just simply revive WQA. Figureofnine (talk • contribs) 13:43, 13 August 2024 (UTC)[reply]
I very much agree that something is needed to avoid the toxic workplace atmosphere while not having to drag people to ANI for every civility issue (which often creates even more drama, on top of needing a pretty high bar for some remedy to actually be enacted). Not sure whether WQA itself is the best, but we definitely need to have an intermediate process for that matter. Chaotic Enby (talk · contribs) 13:58, 13 August 2024 (UTC)[reply]
I just wanted to add (EC) that while the "more harm than good" verdict may have been correct in 2012 (personally I think it was a mistake) it would not be true today, and that an intermediary board is urgently needed if WP:CIVIL is to be taken seriously. Figureofnine (talk • contribs) 14:01, 13 August 2024 (UTC)[reply]
There have been discussions over the years on venues to discuss editor behaviour (such as a noticeboard focused on civility, or a return of the request for comment process for user behaviour). The most recent one I could find is Wikipedia:Village pump (policy)/Archive 167 § A page to report violations of WP:Civility policy. The key question is can a process be created that avoids the pitfalls of the past processes and the incidents' noticeboard, while also being more effective. Many of those who weigh in on this matter want a process that has a feedback process without automatically enacting a sanction, but that only works when the person in question is receptive, and when unfounded inquiries can be swiftly filtered out. English Wikipedia's consensus-based decision-making traditions aren't very good for analyzing behavioural issues in a sympathetic manner: large public, unmoderated group conversations are the opposite of how most organizations provide feedback to its members. Until the English Wikipedia community is willing to look at other decision-making methods in this situation, the root problem can't be addressed. isaacl (talk) 14:57, 13 August 2024 (UTC)[reply]
Maybe we could have a group of users elected by the community to provide feedback on these issues? A sort of mini-ArbCom, but without the gravitas, that will still make the discussions more manageable. We could adopt a format similar to moderated discussion for resolving such issues. Chaotic Enby (talk · contribs) 15:05, 13 August 2024 (UTC)[reply]
Historically, the editors who like to weigh on these matters have been wary of delegating decision-making to a sub-group. An election process is additional overhead, and its results are decided by a self-selected sampling of interested editors. Editors are thus concerned that the sub-group won't adequately represent the community (and from a partisan perspective, that their viewpoint won't be adequately enforced). Personally, I think there will have to be some form of hierarchy introduced to be able to sustain a community of this size (though I think it would better to focus on managing content-related decisions more effectively, which would in turn forestall many behavioural issues, as they become losing strategies for influencing content). But it's not clear to me when the community might reach this conclusion. Moderated discussion might be a form of hierarchy to which the community is more receptive, but at present, it's still more concerned about moderation unduly restricting editors from saying whatever they want. isaacl (talk) 15:34, 13 August 2024 (UTC)[reply]
"Somehow" is the wildcard. Right now, a small number of vocal editors can stop actions from occurring, because the community genuinely seeks approaches that satisfy as many people as possible, in accordance with consensus. Such editors could be considering themselves as holding the line against a devolution into more biased editing, where sheer numbers of editors with an agenda are swamping a given page or topic area, or they could be the ones trying to give an outsized amount of weight to a minority view. If we can find a way to pull the content-decision out of the fray, with a result that remains in force until there are specific reasons to revisit it (*), then we can avoid re-litigating the decision endlessly, and thus remove incentive to be stubborn, aggressive, and repetitive.
But we're not talking about actions, but rather an area where the broader community can make input into specific alleged violations of WP:CIVILITY. The worst that can happen is what currently happens, which is nothing. However it gives a complainant the ability to vent their concerns about the behavior of specific editors or groups of editors. Figureofnine (talk • contribs) 16:44, 13 August 2024 (UTC)[reply]
It seems like this proposal, along with another proposal by Bon courage to shut down WP:DRN as ineffective and Kovcszaln6's comments in that thread, point to a need for an infernal internal forum where disputes are referred to for input by uninvolved editors with the goal of either a) quickly defusing the situation with relevant policy/guideline advice or b) referring it to a more appropriate forum or process. signed, Rosguilltalk19:37, 13 August 2024 (UTC)[reply]
I used "actions" generically to mean anything that the community agrees upon. With English Wikipedia's consensus-based decision-making traditions, many editors don't want to reach an agreement on something that they know several people disagree with. Editors will even try to make accommodations for a single editor objecting.
Regarding a venue to vent, I disagree that this should be a goal of a new noticeboard. There are plenty of places for venting. The community needs effective discussion. isaacl (talk) 20:51, 13 August 2024 (UTC)[reply]
"Vent" was not meant to mean "venting" in the sense of "getting stuff off your chest." "Express" would have been more precise. Yes I agree that we want a mechanism that will do more than give people a place to blow off steam.
I agree with the comments above re an informal forum. I had forgotten about DRN even though I guess I used to participate, as a DRN userbox is on my user page. Figureofnine (talk • contribs) 21:25, 13 August 2024 (UTC)[reply]
The preceding comments seem to be about an internal forum, not an informal one. The dispute resolution noticeboard, as it states at the top, was created to resolve small disputes and help redirect to more appropriate forums. I'm not clear how a new forum with the same purpose would be more effective. isaacl (talk) 02:14, 14 August 2024 (UTC)[reply]
Recreating the dispute resolution noticeboard under a different name isn't a productive use of the community's time. Ultimately, the self-selected set of editors who like to discuss behavioural issues aren't able to reach a consensus agreement on some of the situations that are raised. Moving the discussion from one central forum to another doesn't change this. Determining questions by consensus scales poorly as a group grows larger in size, and it reaches that point very quickly. Further, the way it's done on English Wikipedia, the outcome is highly dependent on who happens to participate in discussion, and so results are inconsistent. isaacl (talk) 15:36, 14 August 2024 (UTC)[reply]
My apologies; I did forget this. I do appreciate that due to there being different people willing to discuss content disputes vs behavioural disputes, a separate noticeboard would be desirable. Nonetheless, it's not clear how to avoid the ineffectiveness of the previous venues as long as the same decision-making processes are in place. isaacl (talk) 20:34, 14 August 2024 (UTC)[reply]
A few thoughts:
Ask four editors to define civility, and you'll get at least five mutually incompatible answers.
The Robustness principle gets applied backwards. What it says is: Ignore the fact that the other guy is dumping profanity on you, but don't ever use profanity yourself. What we see on wiki is: "I'm allowed to use profanity, and you're not allowed to be upset about it!"
Anyone who thinks this is easy has never thought about this.
In particular, anyone who has never considered how to get two people, both upset, to agree on how to treat each other during a hot-button dispute that is important to both of them, when one of them is from a hierarchical face-saving culture and the other is from an egalitarian guilt/sin culture, probably has no idea how impossible it is. The latter person is probably insulting the first person left and right without even realizing it. Now toss in English as a second or third language (anyone else remember the Indian students trying to be friendly by saying "Hi, buddy"?).
We could impose a default culture (which actually will end up being the manners of US white-person middle-class males, no matter what anyone says or wants), but supporting and including all the cultures equally is really, really, really hard. Like "mediator charges US$1,000 an hour" hard, not "we'll all have to think nice thoughts" hard.
I have frequently seen civility arguments improperly introduced either as distraction or defense of some other impropriety, that might explain admin reluctance as well. Do you have any statistics on how many cases are not being properly pursued? Selfstudier (talk) 12:36, 15 August 2024 (UTC)[reply]
If there is no incivility, an uninvolved volunteer can point that out to the complainant. That's the advantage of having a forum in which editors with no knowledge of the topic area can weigh in. The motive of the complainant is immaterial. Civility is required. Figureofnine (talk • contribs) 12:43, 15 August 2024 (UTC)[reply]
I think the nature and motive of the complainant can be material, despite being essentially unverifiable. The complainant can, for example, be a person who uses deception via sockpuppetry to evade a block or ban, then exploits sampling bias to select instances of past incivility to target a perceived political opponent. And this is not a hypothetical. It's something you can observe from time to time. In certain topic areas, when thinking about Wikipedia's homeostatic systems, it is probably worth asking "How would a person willing to use deception exploit this system for their mission?", because that will definitely happen. Employing deception is relatively common in Wikipedia, the protections against it are relatively weak, it is one of the drivers of incivility and people employing deception are immune from all sanctions, including those related to civility of course. So, the way I see it is that civility requirements are nice, but right now, they only apply to honest editors. For editors willing to use disposable accounts, there is zero cost for incivility, and it is another tool that can be used to manipulate a community that will almost always prioritize compliance with WP:CIVIL over compliance with WP:SOCK (and other mandatory policies), probably in part because it is much easier, and people pay attention to drama. Sean.hoyland (talk) 15:13, 16 August 2024 (UTC)[reply]
There is all kinds of rotten stuff that goes on in many topic areas. Somebody in this discussion mentioned tag-teaming in response to civility complaints. There has been canvassing proven time and again that has come up on AE. That is beyond the scope of any Wikipedia forum short of AE or Arbcom. Figureofnine (talk • contribs) 15:50, 16 August 2024 (UTC)[reply]
A good thing about a WP:3O or WP:RfC for civility is that it'd put more focus on wikiquette (probably) in new editors' minds. Currently, there are a lot of avenues for dispute resolution regarding content, which creates a lot of focus on work. The work of building an encyclopaedia is of course important. But if editors are driven off due to incivility, who is left to build it? Aspets (talk) 14:35, 17 August 2024 (UTC)[reply]
Way back in the day, I was a regular at WQA. WQA was non-binding, and explicitly not a place to request that another user be sanctioned in any way. I thought it was a good thing to have a page to discuss civility issues without the threat of a block. I don't agree that it "did more harm than good" but I would admit that it was very often innefective. Somewhere between half and two-thirds of cases filed there moved on to ANI after a day or two, while other suffered from one or more of the parties simply ignoring it. In the end the fact that it could not lead to sanctions is probably what doomed it. Like the also-deprecated WP:MEDCOM or the moribund backwater that is WP:AARV, completely voluntary processes with no "teeth" have proven largely innefective. I think that's a shame but there it is. Just Step Sidewaysfrom this world ..... today18:38, 14 August 2024 (UTC)[reply]
In the I/P area an admin, ScottishFinnishRadish kindly allows his talk page to be used as a very informal sounding board on issues relating to that area. It a good thing to have. Matters are not always resolved but it is a good way for people in that area to ascertain if behavior they see in that area is undesirable or not, and if undesirable, if potentially sanctionable. Perhaps in the eyes of an objective admin it's not worth pursuing. So OK, the editor may not like that, but that is an objective judgment.
People I think should lower their expectations. Having something is better than nothing. Having an admin generously allow his user page to be utilized in this fashion is certainly a lot better than nothing at all. Having an intermediary board on civility of some kind (for which there was a consensus in 2012) is better than nothing. How to structure such a board is another matter. But let's not just throw up our hands because civility is sometimes subjective. Personally I don't think it is as subjective as some here have argued. It is difficult to measure "success," and perhaps we are too hung up on that and not on having a kind of "peace process," pardon the expression. Going back to the point I raised at the beginning, editors who perceive an ongoing low-level civility issue, a toxic workplace of sorts, at the current time have, for all intents and purposes, nothing. Figureofnine (talk • contribs) 18:56, 14 August 2024 (UTC)[reply]
I think the old Wikipedia:Requests for comment/User conduct process was more useful than WQA, but it still fundamentally relied on people voluntarily responding to the feedback. In particular, it was useful for the sort of WP:IDHT cases in which getting people to "vote", all on the same page, that they disliked your behavior might convince you that all of the previous complaints weren't just random individuals with weird standards, and that The Community™ actually didn't approve. But I don't think it was wildly successful; I think it was just occasionally helpful. WhatamIdoing (talk) 19:10, 14 August 2024 (UTC)[reply]
I feel editors got tired of the something just being a dead end that took up time before taking up the issue at a different noticeboard. A redundant noticeboard isn't better than not having it. On the other hand, I can see how something more like Wikipedia:Administrative action review, with a no-fault review of a given scenario, could be useful in separating the evaluation of behaviour from the determination of any restrictions. But the problem of a lack of consensus in the community (at least among the subset that discusses these matters) regarding accepted behaviour remains. isaacl (talk) 20:34, 14 August 2024 (UTC)[reply]
I keep hearing people saying that WQA was a waste of time, a dead end and so on. I beg to differ. I participated in it myself as a volunteer, and just checked the archives to confirm that I was actually pretty active for a time. I found my participation to be interesting and rewarding. I feel that I helped people. While I was fairly new to the project at the time, it wasn't hard. WP:CIVIL wasn't and isn't rocket science. While a good deal about Wikipedia was complicated, civility was not. It didn't, and doesn't, take a law degree to figure out what's civil and what isn't. I wish people would be more positive on the WQA. It was better than I think it is being characterized, and I certainly don't feel that it was such a snake pit or horror show at all. Figureofnine (talk • contribs) 21:26, 14 August 2024 (UTC)[reply]
Common sense is often enough, especially when the disputants come from the same culture. However, common sense isn't enough when Alice, who thinks in black-and-white terms, feels justice is only served by clearly and directly stating that Bob's actions were wrong, and Bob, coming from a culture that values indirectness, deeply feels that clearly and directly stating that anyone's actions were wrong is inherently, appallingly rude and that doing so is a loud, firm message from the community that they want him to stop editing entirely. If you don't have a lot of information about different cultures, you'll probably think that Bob flounced off. WhatamIdoing (talk) 17:24, 15 August 2024 (UTC)[reply]
This seems exaggerated to me. There are going to be some differences in what people consider "uncivil" both across and within cultures. But I've only ever seen one instance of "this isn't a problem in my culture", and it was shut down immediately because it was a direct attack on people with mental illness. Thebiguglyalien (talk) 21:44, 15 August 2024 (UTC)[reply]
It's not really exaggerated IMO. Seldom does anyone actually say "this isn't a problem in my culture" though. In my experience off Wikipedia, it's more likely that Bob would make a complaint about Alice to HR, then HR will spout some BS about making a "safe space for everyone" and threaten to fire Alice over it while ignoring how they're making an unsafe space for her. On Wikipedia, more likely is that Bob would feel chased off and nothing much else happen. But something like WP:FRAMGATE is also a possibility, particularly once the UCoC committee gets running. Anomie⚔22:30, 15 August 2024 (UTC)[reply]
Some years back, we had at least two editors claiming to be Australian and insisting that using profanity was a core cultural value for All True Australians™. We had 800K registered editors last year. Finding a few people whose truthfulness you doubt a bit is to be expected.
(If you are interested in mental health conditions among editors, then you might be interested in the back-of-the-envelope estimate at User:WhatamIdoing/Editors are people. NB I left out autism – an obvious source of tension between "face-saving" and "plain speaking" disputes – because we have far more Autistic editors than average, so the usual calculations don't hold.) WhatamIdoing (talk) 01:59, 16 August 2024 (UTC)[reply]
We're focusing quite a bit in this discussion on "results." Skimming through my own contributions there (I don't believe I ever came in as a complainant or respondent) I see that true, sometimes the discussions that I participated in did not bear fruit. But people would come and I'd look at their problems and I'd say, "well this is uncivil and this isn't." Is that a bad result? We can't always box-score these things, folks. I was surprised when I learned, afterwards, that WQA had been closed. Figureofnine (talk • contribs) 21:31, 14 August 2024 (UTC)[reply]
In your original post, you expressed concern about there being an uncivil environment on English Wikipedia. Thus I think it's reasonable to consider if a proposed change would help address this concern. What barriers are there now that keeps the community from looking at discussions and thinking, well, this is uncivil and this isn't? Is bringing back an old venue an effective way to remove these barriers? Is it worth the opportunity cost? isaacl (talk) 07:10, 15 August 2024 (UTC)[reply]
Of course, and I appreciate your "reality check" comments. But as I go back to the archives and look at my participation in WQA as a volunteer (which I had pretty much forgotten as it was a 13+ years ago) I remember positive aspects that hadn't previously occurred to me, and which are at variance with how WQA is sometimes portrayed. I don't recall even once being flummoxed as to what was civil or what was not. Obviously the complainants and respondents had their own view, or it wouldn't have come to WQA. But as a volunteer, even a relative newcomer, it was always a slam dunk one way or the other.
Another point that I think needs to be made, which didn't previously occur to me, is this. Let's say Editor X is editing in an environment in which other editors WP:OWN the topic area or seek to do so. They engage in sarcasm, personalize discussions or otherwise contribute in a deleterious way. While WQA or something like it can't resolve the issue, it can certainly help with a subsequent resolution if a volunteer uninvolved in the topic area says "yes this is uncivil" or "no, this is not uncivil." It helps Editor X if he wishes to make a fuss going forward, or may discourage him from doing so. This kind of input is difficult to quantify. The volunteers are just ordinary editors with no stake in the matter under discussion, but their perspective matters. The fact they're not admins with the ability to block or topic ban does not detract from their impact. Such input may well make the subject area less toxic and more civil, easier for everyone, even if it does not resolve the underlying dispute. Making things more civil should not be underrated.
Incidentally we're not talking about resuscitating WQA, necessarily. The consensus back then, which of course does not bind us, is to create some kind of "intermediary" forum. Figureofnine (talk • contribs) 12:15, 15 August 2024 (UTC)[reply]
Sure, I just went with the concrete proposal you made in your original post. Like it or not, there was a consensus about the shortcomings of the previous noticeboard. I don't think you'll be able to overcome those views just by saying you disagree with them. A new proposal needs to identify a goal, which could be qualitative in nature, and demonstrate the value and effectiveness of the proposal in achieving it.
In practice, we don't get a volunteer saying "this is/isn't civil", and everyone saying, ah, OK. We get some uninvolved volunteers saying the behaviour is civil, and other uninvolved volunteers saying that it isisn't. We get editors disagreeing with the assessment and thus seeking broader and broader input, consuming more and more community time. A proposal for a new process would have to find a spot where it could add value without just becoming another cycle in this spiral. I'm not sure how to bypass this roundabout, other than my thoughts on fostering collaborative behaviour and thus making poor behaviour a losing strategy. isaacl (talk) 14:45, 15 August 2024 (UTC)[reply]
The fact that you don't recall even once being flummoxed as to what was civil or what was not either says something about WQA attracting only simple complaints (e.g., most reports were mere tattling about obvious misconduct), or your lack of awareness about the complexities involved in intercultural communication. WhatamIdoing (talk) 17:29, 15 August 2024 (UTC)[reply]
No, I don't recall being flummoxed. Not once. Not a single time. Ever. The behavior complained about ("tattled" as you inappropriately put it) was always either civil or uncivil. The policy is simple and editors of any background or culture can go to WP:CIVIL and absorb what is there.
The purpose of an intermediary board, as I see it, is to provide a third opinion on these matters. the 30 suggestion below is not a bad idea. For the umpteenth time, I'm not suggesting we resuscitate the old WQA board but figure out in good faith a possible intermediary board as was the consensus in 2012. Figureofnine (talk • contribs) 12:21, 16 August 2024 (UTC)[reply]
As you know (as I assume you saw my ping there), ScottishFinnishRadish's talk page serves as an intermediary step in the I/P area that allows people to come to him rather than AE. There are plenty of "rules and guidelines" dealing with contentious topic areas but still it helps having his talk page as an intermediate, informal step short of AE. Figureofnine (talk • contribs) 12:34, 15 August 2024 (UTC)[reply]
Yes, and an admin has the power to engage in topic bans and worse. An intermediary board is just a fellow editor weighing in on civility alone. Nothing else. It's a nonpunitive way of an uninvolved editor telling another editor that he's either not being civil or that his incivility complaint is without merit. Figureofnine (talk • contribs) 12:45, 15 August 2024 (UTC)[reply]
You mentioned above that civility complaints are often brought without merit. An intermediary board volunteer can make that same point in a non-punitive way. I know because that is what I did when I was a volunteer on WQA. Figureofnine (talk • contribs) 12:47, 15 August 2024 (UTC)[reply]
I'm sympathetic to the idea of a new (or revived) method of dealing with incivility. But most solutions are going to run into the same problem that we see at ANI, in that it's ultimately cultural instead of procedural. If we want to fix this, we need to make cultural changes:
Crack down on victim blaming and "get a thicker skin" comments.
Abandon the toxic "more heat than light" philosophy. When this refrain or some variation of it is invoked, it tells the people affected that we either aren't able to help them or that we don't care enough to help them. It says that we'd rather let it be someone else's problem, even if it means kicking the can down the road and letting it get worse (which makes the eventual boiling point even more chaotic).
Challenge incivility tag-teaming. User A is frequently uncivil and eventually gets taken to ANI. They're causing harm everywhere they go and are a serious threat to editor retention. They've been given dozens of chances and a ban should have been implemented years ago. But then Users B, C, and D all show up and oppose any sanctions for whatever reason they come up with. Maybe they ignore the context and say that this interaction isn't sanctionable, or maybe they pick one mistake the reporter made and make it all about that. Their filibuster gets it closed without action. The next month, User B is brought to ANI for incivility. Users A, C, and D then show up to complain about "civility police" and ask that the discussion be closed as a frivolous report. And so on.
Unless someone has any creative ideas to fix this, the only solution is for everyone who's tired of Wikipedia's toxic culture to call out incivility when they see it and make their voice heard at ANI. Thebiguglyalien (talk) 21:40, 15 August 2024 (UTC)[reply]
I've been here a while and I don't find it toxic. Get a thicker skin is sometimes appropriate and there are different ways to say that. Maybe a bit cut and thrust time to time, at the end of the day it's just words not bullets. OK sometimes they can hurt too and egregious cases need to be dealt with as does persistently bad behavior. There's a lot worse places to be than WP. Selfstudier (talk) 22:03, 15 August 2024 (UTC)[reply]
Getting a thicker skin is not something people can do on command, though, which makes it inappropriate.
Sure, but it isn't necessarily only about the present moment. Surely a constructive, civil observation about someone's conduct can factor into their future self-reflection and ultimately help them out? That's often how these things seem to work. Remsense ‥ 诉11:21, 16 August 2024 (UTC)[reply]
I'm probably from the wrong culture to be offended / hurt on Wikipedia. I deeply value kindness and consideration towards others, but I also feel like if I make a lot of mistakes and generate a lot of work for others, I should be called out on it, and told why what I'm doing is a problem. Any cultural corrections we attempt to implement to improve our atmosphere also need to take into account that we're working on a project together, and the quality of our output does matter. We also need to take into account weaponization of civility policy used for removing frustrated / escalated opponents from content disputes. Folly Mox (talk) 11:15, 16 August 2024 (UTC)[reply]
I think the whole "culture" issue is a red herring. We have no way of knowing what "culture" an editor is from, and editors are obliged to follow Wikipedia policies regardless of background. Figureofnine (talk • contribs) 12:27, 16 August 2024 (UTC)[reply]
That would make more sense if this were a content policy and not a conduct one. The concept of civility is mediated by culture, if explicated considerably in the policy body. Remsense ‥ 诉12:32, 16 August 2024 (UTC)[reply]
We sometimes used to get editors saying they were on the spectrum as a reason they were behaving contrary to policy. Usually the best approach was for fellow editors to calmly point out to them what the standards are. Likewise, if somehow one's claimed culture results in incivility, then the best approach is for a uninvolved volunteer to calmly point out what our civility policy says, rather than an administrator to impose sanctions or a formal warning. Figureofnine (talk • contribs) 12:39, 16 August 2024 (UTC)[reply]
That's why an intervention by an ordinary editor is helpful if an editor gets carried away or has an emotional issue or is genuinely on the spectrum. If an editor is using incivivility as a tactic in a larger "battlefield" campaign, then obviously nothing short of a block or topic ban will deal with it. But if the civility aspect of a problematic editor is addressed by an uninvolved editor, and they reject that counsel, it establishes a record for future action if necessary. Figureofnine (talk • contribs) 13:04, 16 August 2024 (UTC)[reply]
Having an "ordinary editor" intervene is only going to helpful if that editor knows what he's doing. Imagine that you have an editor who is trying to fix something and unintentionally breaking something else in the process. It's generating a lot of work for other editors, and we need to do something to stop that problem.
However, the correct "something" depends on the editor's perception of what constitutes civil behavior. Here are three different ways to say the same thing:
For someone like Folly Mox, you might take a direct, informal approach: "Hey, you probably didn't realize it, but when you frob the widget, it breaks the glorkanfangle. I fixed one of them for you like this so you can see how to fix it. Ping me if you've got any questions."
For someone from a face-saving culture, you would make more of an effort to affirm the value of their efforts and your humble request: "Hello, and thank you for your helpful contributions to fix the widget. I appreciate you noticing and fixing that problem. When you are making those edits, would you please consider fixing both the widget and the glorkanfangle at the same time? It would save the community a lot of effort, because the glorkanfangle's operation depends on the widget's settings. Here is a combined diff that shows how to fix both at the same time. Please let me know if there is anything I can do to help you."
For someone who is autistic, your message should be direct, detailed, and comprehensive: "You have made many edits to articles containing the widget. Unfortunately, the changes you have made to the widget are interfering with the glorkanfangle on those pages. Please stop making edits that break the glorkanfangle. According to the template's documentation page, if you need to fix the widget, then you must also adjust the glorkanfangle settings. You should do this either in the same edit or immediately afterwards. If you don't do this, then the page will be in violation of the Wikipedia:Manual of Style/Accessibility guideline, the readers will see a misformatted infobox, and your edits may be reverted without warning by any editor who sees them. Here is a diff showing the correct way to adjust the widget and the glorkanfangle at the same time, and here are pages showing what the pages look like before and after adjusting the glorkanfangle. When you make these changes, be sure that widget remains above the glorkanfangle in the wikitext code. As soon as possible, you should either self-revert all of your edits to the widgets, or go back and fix the broken glorkanfangles on all of those pages."
All three of these communicate the same three main points to their specific audience:
Stop breaking pages.
Here's the information you need to achieve your goal without breaking pages.
Go clean up your mess.
But:
For the first two, "Stop breaking pages" and "Go clean up your mess" are implied, rather than directly stated. For the last, everything is plain and clear. You don't need to guess what the message-writer might be thinking about your edits. You don't need to guess what might have been left unsaid. You only need to follow the written instructions.
For the middle one, the message emphasizes the editor's positive contributions and downplays the problems created. We are not saying that the editor did anything truly wrong, because that would be offensive. We are instead only making a humble request that the valuable editor make even better contributions. We are trusting that the face-saving editor will be able to infer from the information provided that their edits screwed things up and that we want them to fix it.
If you go to a face-saving person with the autistic-oriented message, the person is likely to feel like it is an offensively direct public rebuke. They will not feel like it is a civil message. But the face-saving message will confuse and stress some people on the autism spectrum, because it's so vague: Is this an optional extra? Do they want something specific from me? Is this just an interesting fact to know? They didn't tell me to take any action about this, so I didn't – why are they mad at me now?! The end result is that they will not feel like it is the kind of message that supports and builds up the community – which, depending on how you define civility, means they will not feel like it is a civil message.
When we look at human interactions, there are a few universals (e.g., condemnation of unprovoked murder), some commonalities (e.g., table manners exist everywhere, though they look different in different places), and some differences (e.g., approach to punctuality). Especially for ordinary communication, what's considered civil depends on the culture. That's true regardless of whether the humans are interacting in person or online. The end result is that what counts as "civil" to people from one culture is very obviously "uncivil" to people from another culture. WhatamIdoing (talk) 18:10, 16 August 2024 (UTC)[reply]
In terms of process, I feel like a step we could take would be expanding / forking WP:3O to include behavioural concerns alongside content disputes. Dropping a quick template transclusion in a conversation where you're looking for an uninvolved opinion on civility feels like a much more lightweight process, without all the visibility and unstructured commentary a noticeboard is likely to generate.Of course, any process without the power to impose sanctions is unable to deal with genuine problem actors, but if it's a case where someone is being inappropriate but willing to listen to a voice outside the immediate dispute, calling in a single busybody to have a look at the exchange might have some positive outcome. Folly Mox (talk) 11:07, 16 August 2024 (UTC)[reply]
Having a third person provide an opinion works best when both sides are receptive to feedback. With a behavioural dispute, though, if both persons recognize there is a dispute regarding behaviour yet fail to agree on ways to mitigate the behaviour, then they're unlikely to be receptive to a third person weighing in. (If they were, it's likely they would have found a way forward on their own.) In the case of an unrecognized clash in cultures, a third person could help provide context, but that would depend on the two parties recognizing there is a clash, and that third person being able to recognize this as well and subtly learn through discussion with the two parties about their cultures to isolate the clash. isaacl (talk) 20:17, 16 August 2024 (UTC)[reply]
Could you elaborate regarding point #2? I've never heard that idiom before, but after looking it up (neat!) I'm only a shade more sure what behavior was being characterized as such. Apologies in advance! Remsense ‥ 诉11:14, 16 August 2024 (UTC)[reply]
"More heat than light" usually used to mean "this comment is expressing the emotion of anger, instead of objective facts". The idea that expressing emotions is unhelpful or inappropriate is fairly common in Western culture, particularly in English-speaking or northern European cultures. It is odd and uncomfortable to people from cultures that are less fearful/more accepting of emotional expression. WhatamIdoing (talk) 18:13, 16 August 2024 (UTC)[reply]
Just to clarify, I'm referring to entire discussions getting shut down per this reasoning. My argument is that sweeping problems under the rug is dismissive to the people trying to bring attention to them, and it entrenches long-term issues to make things marginally easier in the short-term. And I'm not concerned by whether someone is from a given culture or not; civility isn't a matter of never saying anything imperfect ever, it's about being able to communicate these things and walk away with a mutual understanding. Thebiguglyalien (talk) 18:53, 16 August 2024 (UTC)[reply]
The analogy is with a light bulb, where the intended purpose is to provide light to an area, and the side effect is to generate heat. (If the reverse is intended, then you'd call it a heating element.) Ideally you want as much energy as possible emitted as light rather than heat, to be more efficient. A conversation generating more heat than light isn't providing enough additional insight into the topic to make it worthwhile. isaacl (talk) 20:24, 16 August 2024 (UTC)[reply]
Most of the really vicious stuff done to other editors is not covered by wp:civility, in fact weaponizing wp:civility is a common way to "get" other editors. Most people would rather have us stop people from civilly sticking the knife into their ribs than stopping people from using swear words. North8000 (talk) 20:25, 16 August 2024 (UTC)[reply]
Although I imagine there could be cases where it would help, as I discussed earlier, I think it would more often be disregarded as just one other person's opinion. In situations where two people have failed to find a way forward on their own regarding behaviour, I'm hard-pressed to think of cases where one uninvolved person joining the conversation has resolved the dispute. isaacl (talk) 12:13, 17 August 2024 (UTC)[reply]
One thing I like to do occasionally is to use AutoWikiBrowser to make spellings on articles consistent with their English vareity (for example changing "favorite" to "favourite" in British English articles). A mistake I made once was changing "-ize" spellings to "-ise" spellings in British English articles, when both are correct in British English. We have Template:Use Oxford spelling to say "this articles uses the -ize suffix" but we do not have one for -ise spellings. I propose creating a template for that, and I have already created it and the documentation in my sandbox.
To be clear, this proposed template is not for English varities that only use the -ise suffix (such as New Zealand English). It is only for British English (and to a lesser extent, Canadian English) which allows both -ize and -ise. ―Panamitsu(talk)07:59, 17 August 2024 (UTC)[reply]
This seems like a rather narrow justification for taking up an entire additional line at the top of articles. It seems far more practical just to be more discriminate with your AWB gnoming, unfortunately. Remsense ‥ 诉08:08, 17 August 2024 (UTC)[reply]
Why is any of this needed? From what I am reading at {{Use Oxford spelling}} and at Oxford spelling, "-ize" is Oxford spelling, and "-ise" is part of normal British spelling. If the article you are checking uses "-ize", you can presumably add the Oxford spelling template; otherwise, leave the British spelling template and leave the -ise endings alone. What am I missing? – Jonesey95 (talk) 15:27, 17 August 2024 (UTC)[reply]