Wikipedia:Village pump (proposals)
Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:
- Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
- This page is for concrete, actionable proposals. Consider developing earlier-stage proposals at Village pump (idea lab).
- Proposed policy changes belong at Village pump (policy).
- Proposed speedy deletion criteria belong at Wikipedia talk:Criteria for speedy deletion.
- Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
- Proposed new wikis belong at meta:Proposals for new projects.
- Proposed new articles belong at Wikipedia:Requested articles.
- Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation belong at Wikipedia:Village pump (WMF).
- Software changes which have consensus should be filed at Phabricator.
Discussions are automatically archived after remaining inactive for nine days.
Does the community still want moved pages to be unreviewed
edit- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
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.
Does the community still want this feature implemented? (cc @Pppery, @Hey man im josh and @Novem Linguae who participated in an initial discussion on the NPP Discord server, also see T370593) Sohom (talk) 07:44, 21 July 2024 (UTC)
- Taking my developer hat away, I personally don't think this should be implemented anymore. Sohom (talk) 07:54, 21 July 2024 (UTC)
- 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)
- 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)
- @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)
- Thanks for clarifying that Sohom. Aszx5000 (talk) 09:01, 9 August 2024 (UTC)
- @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)
- 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)
- 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)
- Strong oppose per nom and Josh. Reviewers already are swamped as it is. (t · c) buidhe 14:53, 21 July 2024 (UTC)
- Oppose on the merits. I agree this is unnecessary and wasteful. But this discussion needed to be had and formally codified anyway to avoid unintentional cabalish behavior /WP:CONLEVEL problems. * Pppery * it has begun... 15:19, 21 July 2024 (UTC)
- 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)
- Hmmm, maybe I should have restricted this to mainspace? But I'll let somebody with better SQL-fu than I have play with it. RoySmith (talk) 15:34, 21 July 2024 (UTC)
- It's even worse than that - there were more moves in mainspace yesterday than there were total curations. —Cryptic 16:27, 21 July 2024 (UTC)
- 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. —Cryptic 16:55, 21 July 2024 (UTC)
- It's even worse than that - there were more moves in mainspace yesterday than there were total curations. —Cryptic 16:27, 21 July 2024 (UTC)
- Hmmm, maybe I should have restricted this to mainspace? But I'll let somebody with better SQL-fu than I have play with it. RoySmith (talk) 15:34, 21 July 2024 (UTC)
- 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)
- 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) - 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)
- That makes more sense. Numbers for July 20 and all of July. —Cryptic 20:02, 22 July 2024 (UTC)
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)
- ??? 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)
- Oppose: Unnecessary. They will almost always be marked as reviewed immediately, so this just adds a pointless burden to the NPP queue. C F A 💬 22:15, 28 July 2024 (UTC)
Rephrase the talk page box "Description" prompt
editI propose to change the message string at MediaWiki:Discussiontools-replywidget-placeholder-newtopic from Description
to Your talk page comment
.
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)
- 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)
- "Your message" is a definite improvement to "Description". Schazjmd (talk) 14:18, 8 August 2024 (UTC)
- 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)- Is there a way to find which pages use that? Thryduulf (talk) 18:32, 12 August 2024 (UTC)
- @Thryduulf, try this search. Cheers, Sdkb talk 19:27, 12 August 2024 (UTC)Edited 02:20, 13 August 2024 (UTC)
- @Sdkb all I get is an error "A warning has occurred while searching: insource expects a non-empty regular expression." Thryduulf (talk) 00:22, 13 August 2024 (UTC)
- 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. Sdkb talk 02:20, 13 August 2024 (UTC)
- @Sdkb all I get is an error "A warning has occurred while searching: insource expects a non-empty regular expression." Thryduulf (talk) 00:22, 13 August 2024 (UTC)
- You could use Special:Pageswithprop to find pages with the "newsectionlink" prop. the action API and DB queries could also be used. Anomie⚔ 01:10, 13 August 2024 (UTC)
- 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:
- (article): 27
- user: 1096
- Wikipedia: 314
- Template: 1 (Template:New section/sandbox)
- Help: 2 (Help:IPA/Aragonese, Help:Books/Feedback)
- Category: 1(Category:Nickel Plate Road locomotives)
- Portal: 8
- Draft: 32
- 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)
- 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)
- 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)
- The Category has already been cleared, a similar IP addition. The 8 Portal space uses are all discussion subpages, as is Help:Books/Feedback. The use on Help:IPA/Aragonese seems an error. CMD (talk) 20:54, 15 August 2024 (UTC)
- 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)
- 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)
- 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:
- @Thryduulf, try this search. Cheers, Sdkb talk 19:27, 12 August 2024 (UTC)Edited 02:20, 13 August 2024 (UTC)
- Is there a way to find which pages use that? Thryduulf (talk) 18:32, 12 August 2024 (UTC)
- 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. Sdkb talk 15:15, 8 August 2024 (UTC)
- I agree it should be changed Alexio2727 (talk) 10:45, 9 August 2024 (UTC)
- 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)
- I've got no objections to "Your comment". Thryduulf (talk) 18:15, 9 August 2024 (UTC)
- "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)
- Thank you for the ping, @Sdkb. And thank you, @Belbury for prompting us to reconsider this message.
- As @DLynch (WMF) shared above, the challenge here is coming up with a message that is both:
- Specific enough for people to understand the tool is meant for communicating publicly with other people on Wikipedia
- 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)
- 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) - 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)
- 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)
- I agree with Schazjmd that
- 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.
- Pages which don't function as talk pages (Wikipedia:Harmonious editing club, Draft:X Mail, Category:Nickel Plate Road locomotives), where "your comment/message" would be confusing. But it seems like it doesn't make much sense to be giving users a way to add a new H2 section to the very end of these pages, anyway.
- 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)
- 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
orveaction=edit
) withsection=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`
- It must be an edit page (
- 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
orARCHIVEDTALK
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 thesection=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)
- I understand that there are different use-cases. Even a barebones label Text is better than Description, I think. Schazjmd (talk) 20:19, 15 August 2024 (UTC)
- 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)
- It will need a fine-toothed comb to find any "existing processes" that are deliberately using __NEWSECTIONLINK__ in a way that would conflict with a change to referring to the text as a "comment". But from a superficial look through the Wikipedia and User namespace usages (where the pages aren't structured as any kind of signed log or conversation), the existing processes that I can find do just appear to be using the magic word in error, for whatever reason - none of the pages appear to need or use their "Add a topic" tab to create new, sequential non-talk sections.
- Making those already-non-standard pages a little more cryptic seems a very small trade-off for the benefit of every talk page on Wikipedia clearer to new users. Belbury (talk) 13:23, 23 August 2024 (UTC)
- I understand that there are different use-cases. Even a barebones label Text is better than Description, I think. Schazjmd (talk) 20:19, 15 August 2024 (UTC)
- 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
- I like the idea, we can start with this! I still fear
Deploying Edit Check on this wiki
editWhile 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.
- Deploy Edit Check.
– robertsky (talk) 17:26, 9 August 2024 (UTC)
- I thought Visual Editor is already the default for new accounts and unregistered editors? Folly Mox (talk) 17:59, 9 August 2024 (UTC)
- 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. Sdkb talk 19:05, 9 August 2024 (UTC)
- 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)
- 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)
- Here's an userscript that I cooked up: User:Robertsky/edit-check-optin.js. It adds
&ecenable=1
to edit links that goes to Visual Editor (mw:Help:Edit_check#Testing_Reference_check). – robertsky (talk) 20:37, 9 August 2024 (UTC)- 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)
- There's a simpler option for userscripts that should work:
- Here's an userscript that I cooked up: User:Robertsky/edit-check-optin.js. It adds
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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.
- To use the famous quote: "There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors." DLynch (WMF) (talk) 21:43, 9 August 2024 (UTC)
- Given the information you've provided.
- 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.
- BlackOrchidd (talk) 09:31, 10 August 2024 (UTC)
- BlackOrchidd, please sanity check your chatbot's AI response before posting embarrassing things like this. Folly Mox (talk) 13:04, 10 August 2024 (UTC)
- 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)
- Agree 100% MichaelMaggs (talk) 12:00, 10 August 2024 (UTC)
- 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)
- Agree 100% MichaelMaggs (talk) 12:00, 10 August 2024 (UTC)
- 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 - Talk 11:08, 10 August 2024 (UTC)
- 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)- 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)
- Agreed, that's a huge bugbear. It was the sixth most agreed upon community wish for 2023, and something that is also already part of the wikitext reference creator. CMD (talk) 12:39, 10 August 2024 (UTC)
- 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)
- 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)
- 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)
- Three phab tickets are listed at meta:Community Wishlist Survey 2023/Editing/VisualEditor should use proper names for references, are they missing something? CMD (talk) 13:18, 11 August 2024 (UTC)
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)- Actually, it's phab:T245199. Not sure why it took me so long to find it. Thank you for pointing me in the right direction. –Novem Linguae (talk) 13:23, 11 August 2024 (UTC)
- There were Phabricator tickets for it. You can find links and even prototypes links in my wishlist request here Meta:Community Wishlist/Wishes/Improved named references ~ 🦝 Shushugah (he/him • talk) 13:18, 11 August 2024 (UTC)
- Three phab tickets are listed at meta:Community Wishlist Survey 2023/Editing/VisualEditor should use proper names for references, are they missing something? CMD (talk) 13:18, 11 August 2024 (UTC)
- 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)
- 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)
- 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)
- 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)
- Agreed, that's a huge bugbear. It was the sixth most agreed upon community wish for 2023, and something that is also already part of the wikitext reference creator. CMD (talk) 12:39, 10 August 2024 (UTC)
- 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)
- I wonder if the code for this is already in CX. Surely it's no more difficult to turn {{cite web}} into {{cite news}} than it is to convert {{cite news}} into a different language. WhatamIdoing (talk) 20:59, 13 August 2024 (UTC)
- @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 Rex talk 13:58, 10 August 2024 (UTC)
- @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)
|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)- 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)
- It is indeed in the TemplateData for each of the Cite_whatever templates -- if you go look at the source to Template:Cite_web/doc around line 1601 you'll see the field-mapping for that one. There's a description of how it all works over on mediawiki.org. DLynch (WMF) (talk) 23:08, 10 August 2024 (UTC)
- @DLynch (WMF) I've got a question for you. As noted above, VE does a good job of guessing the right template type for some sources (say, the NYTimes), and for many other sources, can't figure it out so resorts to {{cite web}}. If I understand the flow properly, the bottom layer in the stack is zotero, and if I wanted to teach VE to understand that https://www.bxtimes.com/orchard-beach-nature-center-reopens-after-2-35m-renovation-officials-hold-ribbon-cutting-event/ should be cited using {{cite news}}, zotero is where that teaching has to happen. Is that correct?
- 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.
- Does this seem like a reasonable understanding of the problem? RoySmith (talk) 00:17, 11 August 2024 (UTC)
- 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)
- DLynch (WMF) I've been told logging the Zotero translator is incompatible with current infrastructure. Folly Mox (talk) 12:46, 11 August 2024 (UTC)
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)- 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)
- 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)
- 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
- @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)
- 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)- @Folly Mox, @Robertsky et al.: have you heard of m:Web2Cit that adds a layer of user-configurable translators? I'm surprised that it's not enabled on the English Wikipedia. Many translators have been created and many more should be. 65.75.64.110 (talk) 08:02, 12 August 2024 (UTC)
- 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)
- 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)
- @Folly Mox, @Robertsky et al.: have you heard of m:Web2Cit that adds a layer of user-configurable translators? I'm surprised that it's not enabled on the English Wikipedia. Many translators have been created and many more should be. 65.75.64.110 (talk) 08:02, 12 August 2024 (UTC)
- Actually, passing Citoid's output directly to Citation bot before returning it to the editing interface – one specific implementation of
- It is indeed in the TemplateData for each of the Cite_whatever templates -- if you go look at the source to Template:Cite_web/doc around line 1601 you'll see the field-mapping for that one. There's a description of how it all works over on mediawiki.org. DLynch (WMF) (talk) 23:08, 10 August 2024 (UTC)
- 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)
- 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)
- T372202 RoySmith (talk) 15:05, 10 August 2024 (UTC)
- Reference naming: T52568 • T92432 • T245199 • T52474 • T334073 • T245199 • T215867 • T52568. Thryduulf (talk) 15:33, 10 August 2024 (UTC)
- The first two in Thryduulf's list (T52568 and T92432) look pretty useful. I've subscribed to those. –Novem Linguae (talk) 16:04, 10 August 2024 (UTC)
- just created phab:T372388 as using Wikidata a possible solution to determining which citation template to use in Citoid, among other possible enhancements. – robertsky (talk) 11:01, 13 August 2024 (UTC)
- 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)
What's next?
editThanks 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.
Feel free to add to the list of questions and answers. And also any help to push this forward is appreciated. – robertsky (talk) 05:35, 12 August 2024 (UTC)
- 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)
- 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)
- I should also add that the other target audience is anonymous editors. Right now the experience is as screenshot.
- 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)
- 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)
- @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)
- 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)
- @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. - – robertsky (talk) 18:32, 14 August 2024 (UTC)
let userEC = mw.config.values.wgUserEditCount // wgUserEditCount: null for anon editors and non null value for registered editors if (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)
- 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)
- @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)
- @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)
- 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)
- 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
- @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)
- @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)
- 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)
- 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)
- @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
- 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)
- I should also add that the other target audience is anonymous editors. Right now the experience is as screenshot.
- 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)
- hi y'all – the Editing Team is excited to see you discussing the prospect of enabling the Reference Check at en.wiki, considering the positive impact it's been proven to have on things like:
- The quality of edits newcomers publish
- The likelihood that newcomers return to edit again
- 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 @CMD put well, seems like a relatively lightweight and low-risk way for us to work together to:
- Put the Reference Check in the hands of some newcomers to validate whether the positive impacts we observed at other large wikis hold true here at en.wiki
- Identify and address potential issues with how references are generated and inserted
- Ensure the Reference Check integrates well with existing en.wiki processes, policies, and conventions[iii]
- 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.
- To set ourselves up for that conversation, I've created T372519 and added the tasks you all have raised here.[x] I also think the analysis we're doing right now might help answer some of the questions @RoySmith and @DLynch (WMF) were discussing above about how successful people are with using Citoid to generate citations.
- And in case it's helpful, as @DLynch (WMF) mentioned, there are two existing Edit Checks within the visual editor already available at en.wiki: the Link and Reference Reliability Checks. [xi]
- 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
andMediaWiki:Spam-blacklist
lists. - The Reference Reliability Checks evaluates the references people attempt to cite against the same local and global lists mentioned above.
- The Link Check evaluates all external domains people attempt to link to against the globally-defined
- 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.
- ---
- i. Note: I now see the note that had been included at mw:Edit check/Deployment status suggested the opposite; I've since removed this note. Thank you for drawing our attention to this, @Fram.
- ii. For context, VE being enabled by default for people who are new and logged out had been a requirement of wikis participating in the Reference Check A/B test. Although, this no longer applies to deployments like you're discussing here.
- 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.
- iv. @CMD
- v. @Thryduulf
- vi. @RoySmith
- vii. @Novem Linguae
- viii. @Shushugah
- ix. @Folly Mox
- 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/spamblacklist PPelberg (WMF) (talk) 21:11, 16 August 2024 (UTC)
- @PPelberg (WMF) in this case, we just need to have the site config updated to activate Edit Check for edits and settings be available at Community Configuration instead of using Common.js? – robertsky (talk) 01:25, 17 August 2024 (UTC)
- @Robertsky, hi – would it be accurate for me to understand you as asking the following questions?
- What steps would we (volunteers) need to take to activate the Reference Check at en.wiki?
- How might we (volunteers) go about configuring the Reference Check? E.g. whose edits has the potential to activate Edit Check, where references are placed (before/after periods), the sections Reference Check should ignore edits to, etc.
- Assuming the above are accurate, to activate reference check at en.wiki you all would need to:
- Ask us to turn it on
- Adjust the configuration on-wiki to reflect your preferences (e.g. example of frwiki’s ignoreSections)
- And the Editing Team would need to then deploy a configuration-change patch to enable Reference Check on en.wiki.
- To configure the Reference Check, any interface admin can adjust the configuration variables by editing MediaWiki:Editcheck-config.json. [i][ii]
- Relatedly: how – if at all – do you think anything about the current configuration variables might need to be changed to meet en.wiki's needs?
- ---
- i. In the future, we plan to enable volunteers to be able to configure editing Check using the Community Configuration experience.
- ii. If you needed help with this, please ping @DLynch (WMF) who would be happy to help. PPelberg (WMF) (talk) 19:13, 21 August 2024 (UTC)
- @Robertsky, hi – would it be accurate for me to understand you as asking the following questions?
- @PPelberg (WMF) in this case, we just need to have the site config updated to activate Edit Check for edits and settings be available at Community Configuration instead of using Common.js? – robertsky (talk) 01:25, 17 August 2024 (UTC)
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)
- @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)
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?
editEdit type | % of Total Machine Edits |
Machine suggestion accepted | 23.49% |
Machine suggestion modified | 14.49% |
Machine suggestion rejected | 62.02% |
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)
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)- Let's test it by first providing us with a correct test environment. Sending editors to a test environment which doesn't reflect the actual environment is useless. Step 1: test if it is technically working. This should happen on a testwiki, not a live wiki. This is not an unnecessary step, there have been too many rollouts of supposedly ready new software addons which turned out to be very, very buggy and were not at the beta-stage but at some pre-alpha stage. Step 2: after approval from enwiki, do a limited test on enwiki completely reviewable by editors here, not a test where we just have to believe the results in good faith, and automatically shut down the test afterwards. Step 3: after approval, do a further rollout (larger test or full rollout). For this, we are not at step 1 yet. Fram (talk) 11:13, 19 August 2024 (UTC)
- @PPelberg (WMF) can you help verify if https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Fox&action=edit is set up to be used for testing? – robertsky (talk) 01:14, 24 August 2024 (UTC)
- It wasn't until about five minutes ago. Beta was left with an extremely-restrictive configuration since about April as a result of some validation testing our QA was doing for that configuration process. Specifically, it would only activate the edit check if your account had less than three edits made -- though you could have tested it as an anonymous user to get around that.
- I just reset the config file to the defaults, so right now it'd be fair to test it there. I can also adjust any of the values if you want to see what the experience is like.
- One thing that's not obvious from the config if you want to test it is that the "add a reference" check will only trigger when you add a completely-unreferenced new paragraph. DLynch (WMF) (talk) 03:51, 29 August 2024 (UTC)
- Besides Beta Wikipedia, if anyone prefers an English-based example can have a look at simple.wikipedia.org. It is already deployed there and anyone can monitor the changes made when References check is shown to the user, as all edits are tagged (including rejections).
- Reference check is deployed at all Wikipedias but 8. It is not deployed at these wikis because we haven't yet informed them that it is an available option. Trizek_(WMF) (talk) 15:37, 29 August 2024 (UTC)
- @PPelberg (WMF) can you help verify if https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Fox&action=edit is set up to be used for testing? – robertsky (talk) 01:14, 24 August 2024 (UTC)
- Let's test it by first providing us with a correct test environment. Sending editors to a test environment which doesn't reflect the actual environment is useless. Step 1: test if it is technically working. This should happen on a testwiki, not a live wiki. This is not an unnecessary step, there have been too many rollouts of supposedly ready new software addons which turned out to be very, very buggy and were not at the beta-stage but at some pre-alpha stage. Step 2: after approval from enwiki, do a limited test on enwiki completely reviewable by editors here, not a test where we just have to believe the results in good faith, and automatically shut down the test afterwards. Step 3: after approval, do a further rollout (larger test or full rollout). For this, we are not at step 1 yet. Fram (talk) 11:13, 19 August 2024 (UTC)
Proposal: Create quizzes on Wikipedia
editI’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)
- 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.
- My gut feeling is people won't be enthused about an AI-generated quiz. RoySmith (talk) 21:44, 10 August 2024 (UTC)
- 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) - 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)
- 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)
- 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)
- 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)
- Though an encyclopedia is categorically a pedagogical resource: Category:Teaching -> Category:Educational materials -> Category:Reference works -> Category:Encyclopedias -- GreenC 20:53, 12 August 2024 (UTC)
- 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 isjust 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)
- For sure! I probably could have done a better job in selecting a qualifier than the term "general" in
- Though an encyclopedia is categorically a pedagogical resource: Category:Teaching -> Category:Educational materials -> Category:Reference works -> Category:Encyclopedias -- GreenC 20:53, 12 August 2024 (UTC)
- Adding such pointless drivel would make the site much LESS fun to use. There is already too much silly game-like (ie barnstars) or extraneous (userboxes) crap here.--User:Khajidha (talk) (contributions) 20:29, 12 August 2024 (UTC)
- 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. -- GreenC 20:37, 12 August 2024 (UTC)
- @Interstellarity: as you are clearly passionate about your idea, perhaps you would like to start creating quizzes on a project page as a pilot initiative? isaacl (talk) 06:03, 13 August 2024 (UTC)
- Oppose - this is an encyclopedia, not Facebook or TikTok. We do not need to degrade ourselves by turning ourselves into a host for social media games. --Orange Mike | Talk 20:58, 20 August 2024 (UTC)
- Hi everyone, sorry for responding so late. I don't check Wikipedia as often as I used to. Unfortunately, I don't have all the time in the world to be dedicating to making the quizzes all by myself. I'd be open to suggesting ideas that will help make the quizzes better. I feel that if I had help with the quizzes rather than alone (not saying I won't contribute, but I don't to put a heavy load on my editing and my personal life), I think it would be helpful to increase the chances of it being a successful feature on the site. Interstellarity (talk) 22:50, 20 August 2024 (UTC)
- It's not necessary for you to do all the work, if there are other interested contributors. As the one who seems most interested in the idea, though, you are a good candidate to co-ordinate the work, or even to just create some quizzes on whatever schedule is convenient for you to try to figure out what might be a sustainable way of working. isaacl (talk) 17:32, 21 August 2024 (UTC)
- ...and the best way to find out who could be involved is for you to start with a few questions. I'm sure you will get people saying "I wouldn't have asked that" so you can ask them what they would have asked instead, and the second quiz will already be written. Phil Bridger (talk) 19:23, 21 August 2024 (UTC)
- @Interstellarity: Pitch this on Wikipedia talk:Wikipedia Signpost. We already sometimes do crosswords, so this would be a well-received proposal. Svampesky (talk) 16:32, 26 August 2024 (UTC)
- Oppose per Orangemike. * Pppery * it has begun... 18:56, 26 August 2024 (UTC)
- I think you (and Mike) are being a bit bah-humbugish here. Of course this shouldn't be an official™ part of Wikipedia, but there's no reason why someone shouldn't ask a few questions in their user space if that's what floats their boat. It will probably fail anyway. Phil Bridger (talk) 19:24, 26 August 2024 (UTC)
- The proposal was to put it on the main page, so it merits being discussed (and, in this case I guess, opposed) as a serious proposal, not assumed to be automatically relegated to a userspace project (which can be done without a village pump proposal). Honestly, having it on the main page or articles directly would be bloat, but I'm down for having quizzes on the Signpost, and it would definitely be fun! Chaotic Enby (talk · contribs) 19:54, 26 August 2024 (UTC)
- I think you (and Mike) are being a bit bah-humbugish here. Of course this shouldn't be an official™ part of Wikipedia, but there's no reason why someone shouldn't ask a few questions in their user space if that's what floats their boat. It will probably fail anyway. Phil Bridger (talk) 19:24, 26 August 2024 (UTC)
Getting Current With Cultural Trends
editTo keep up with recent trend to keep relationships defined as per their choice, there are partnerships such as Civil Partnership, Platonic Relationships, or just Girlfriend and Boyfriend etc... please change spouse to partner or any culturally relevant term thar reflects the current state of preferences on bio pages of individuals. DhawanMohan13 (talk) 16:33, 18 August 2024 (UTC)
- DhawanMohan13 This isn't the place to propose edits, and we already attempt to reflect what independent reliable sources say about a topic. 331dot (talk) 16:56, 18 August 2024 (UTC)
- DhawanMohan13, why change "spouse" to "partner" in the majority of cases where it is correct? I am married. I have a wife (gender-neutral term "spouse") and she has a husband (gender-neutral term also "spouse"). Many people that I know have partners or boyfriends or girlfriends. We should describe everyone, incuding those who have a spouse, accurately. Phil Bridger (talk) 17:18, 18 August 2024 (UTC)
- The definition of spouse is (written) your husband or wife, I doubt it acknowledges people who are in a relationship they dont want to label. For example just boyfriend girlfriend, civil partnership, etc... DhawanMohan13 (talk) 05:03, 19 August 2024 (UTC)
- I think what Phil is saying is that if someone is married, there is no reason not to use the word 'spouse' accurately. Otherwise, 'partner' is fine. – Joe (talk) 05:06, 19 August 2024 (UTC)
- Or is the concern in the opposite direction?
- @DhawanMohan13, it's not clear which problem concerns you:
- "Mrs. Married" is legally married, but you think we should write "her partner" instead of "her spouse", to sound current and trendy.
- "Miss Girlfriend" is not married, but you have found a Wikipedia article that talks about "her spouse", when it ought to say "her partner" or "her boyfriend".
- If you are aware of any articles of the last type, please post a link here. WhatamIdoing (talk) 06:23, 19 August 2024 (UTC)
- Of course the article about Miss Girlfriend should be corrected, but we should leave Mrs Married as is, unless we have sources saying that she prefers not to use the term. Phil Bridger (talk) 07:14, 19 August 2024 (UTC)
- Yes, Joe, you think correctly. Phil Bridger (talk) 07:14, 19 August 2024 (UTC)
- DhawanMohan13, most people who are married use the traditional terms, so, in those cases, we should too. Phil Bridger (talk) 07:14, 19 August 2024 (UTC)
- I think what Phil is saying is that if someone is married, there is no reason not to use the word 'spouse' accurately. Otherwise, 'partner' is fine. – Joe (talk) 05:06, 19 August 2024 (UTC)
- The definition of spouse is (written) your husband or wife, I doubt it acknowledges people who are in a relationship they dont want to label. For example just boyfriend girlfriend, civil partnership, etc... DhawanMohan13 (talk) 05:03, 19 August 2024 (UTC)
- If there is no legally defined relationship, there is no reason to list the person. We don't list every girlfriend/boyfriend, we list people who are joined in a marriage or civil partnership. For those relationships the terms are "spouse" and "partner". --User:Khajidha (talk) (contributions) 14:54, 19 August 2024 (UTC)
- Wikipedia follows; it does not lead. The onus is on you to show that any such "trend" has become predominant in reliable sources; you have not even attempted to do so. I fervently oppose cultural activism at Wikipedia (repeal the "mankind" ban until such time as the word is widely considered archaic, etc.). ―Mandruss ☎ 19:53, 19 August 2024 (UTC)
Improve readability of hyperlinks in Dark Mode
editThe current dark blue color of hyperlinks in Wikipedia's Dark Mode can be difficult to read, especially for users with visual impairments. I propose changing the color of hyperlinks in Dark Mode to a brighter, more readable color, such as yellow.
This change would improve the overall usability and accessibility of Wikipedia for users who prefer Dark Mode. A brighter hyperlink color would provide sufficient contrast with the dark background, making it easier for users to navigate and read articles both on the website and the app.
Rationale:
- Improved readability and accessibility for users with visual impairments
- Enhanced user experience for Dark Mode users
- Consistency with web accessibility guidelines, which recommend sufficient contrast between text and background colors
Implementation:
- Change the color of hyperlinks in Dark Mode to a brighter color, such as yellow (#FFFF00)
- Ensure the new color is consistent across all devices and browsers
Discussion:
I welcome feedback and discussion on this proposal. Please share your thoughts on the proposed change and suggest alternative solutions if you have any. Galilean-moons (talk) 14:53, 19 August 2024 (UTC)
- If there is a standard colour for links in website dark modes we should use that (for the same reason we use blue as the standard link colour on light mode). I'm not a regular user of dark mode meaning I have little direct experience, so I looked for examples. Of about 20 websites with dark modes that were highlighted as good by various discussion forum contributors, only 3 were primarily text-based, had links of a different colour to the body text when not mousing over the link and had a dark mode that I could easily find and activate. Two of them used a pale blue (#3ebcf4 and #9eb1ff) and 1 used purple (#a667e4). A couple of git hub results were people commenting/complaining that yellow is not an intuitive colour for hyperlinks. Thryduulf (talk) 19:19, 19 August 2024 (UTC)
- Further, it would probably be best if the color is set in same place where the light-mode link colors are set rather than us overriding them locally. That would likely be in the skin. Anomie⚔ 21:31, 19 August 2024 (UTC)
- Light blue is good, although cyan could also be an option. It is visually brighter than blue at similar HSL lightness levels, while a light blue (higher lightness level, i.e. adding white) isn't visually as sharp, especially if we want to make it visually distinct from purple. Chaotic Enby (talk · contribs) 23:03, 20 August 2024 (UTC)
- Further, it would probably be best if the color is set in same place where the light-mode link colors are set rather than us overriding them locally. That would likely be in the skin. Anomie⚔ 21:31, 19 August 2024 (UTC)
- I use dark mode and am (slightly) vision impaired. The difficulty for me is less the blue hyperlinks and more the difference between blue and purple (non-visited/visited). Gnomingstuff (talk) 18:47, 20 August 2024 (UTC)
- @Gnomingstuff Yeah, unfortunately I don't expect much improvement there, especially considering how many websites style away visited link coloring entirely, forcing them to the same color as unvisited links. (Something that will always earn them a UserStyle in my browser, restoring the difference, because WTH is it with site authors just deciding that a useful browser feature isn't necessary on their site?) So I guess we should be happy there's any color difference at all.
- I know at least for the light-mode skin, in the last round of design updates not too long ago, the decision was made to slightly lighten the unvisited blue, and massively lighten the visited purple. The focus was on increasing their contrast relative to the black body text (for some reason), though I pointed out that it came at the cost of decreasing their contrast with the background color, particularly in infoboxes and other non-white sections of the page, but the whole contrast-with-unlinked-text thing was a big priority for some reason. It was an unfortunate additional side effect that the change also brought the two colors much closer to each other, but I suppose contrast in particular is always a balancing act. FeRDNYC (talk) 15:00, 23 August 2024 (UTC)
- A new color might be useful, but yellow seems to me to be a pretty poor choice, as it's quite an aggressive color. I think another shade of blue would be optimal, as up to now people have made things with yellow backgrounds but not with blue ones, and yellow-on-yellow situations would violate MOS:CONTRAST. — Alien333 ( what I did
why I did it wrong ) 20:20, 24 August 2024 (UTC)- @Alien333 I can see the point of yellow, in that it's the complementary color to blue in many color models, and yellow links inline with white text (remember, we're talking about dark mode here) wouldn't really be that "aggressive", I don't think. I'm not entirely sure how easy it would be to detect yellow links in white text, particularly for users with color-vision impairments. Though IIUC, both the yellow/white and yellow/blue pairings would be good choices because the difference would remain completely visible to those with the most common form, deuteranomaly ("red-green color blindness").
- Also, just for the record, there are a ton of blue-background elements on Wikipedia, particularly in the article space — including all of the standard infobox, navbox, and table styles. (Heck, even the standard background for inline
<code>...</code>
elements used to be a subtle blue, though it seems it's been changed to a neutral gray.) Yellow may reign in Talk page headers, but blue is very common elsewhere. - The prevalence of blue backgrounds on article pages is why I tried to point out that lightening the blue link text in the light mode palette was an especially poor choice, because links often appear inside those boxes, and quickly become combinations that fail the WCAG's thresholds for text contrast against background color. In dark mode, those background colors either get erased entirely, become a shade of dark gray, or (least commonly) become a much darker blue, so it isn't as much of an issue there. FeRDNYC (talk) 21:18, 26 August 2024 (UTC)
- After some CSS tinkering:
- Actual yellow would be nearly invisible, and certainly not legible. Some kind of inverted yellow, such as this one, could do the trick, but as long as we're going to do that we might as well just take a cyan of the same level, like that one. Also this green, maybe. I'd prefer the cyan or green because that is more logically linked to the light blue of unvisited links. — Alien333 ( what I did
why I did it wrong ) 22:57, 26 August 2024 (UTC)
Allow Names without Caps
editThe following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Hello, I'm a new user and was wondering if we can have our username start with a small letter. Almost every website I use has my username as "brishtibheja" but only here it becomes "Brishtibheja". Brishtibheja (talk) 20:53, 20 August 2024 (UTC)
- There are ways to make your username appear as brishtibheja in your signatures and on your user page and user talk page, etc. For help with that, I suggest WP:HD; it would be a misuse of this page. No proposal is in order. ―Mandruss ☎ 21:04, 20 August 2024 (UTC)
Sarbajeet Mohanty & Pooja Vijay's Article
editWondering why there are no articles on Sarbajeet Mohanty and Pooja Vijay? They have been a notable paranormal investigators for the last many years and are currently featuring on MTV India's Paranormal reality show, Dark Scroll as Paranormal Experts, streaming on a notable streaming platform Jio Cinema. Scareguy123 (talk) 19:32, 21 August 2024 (UTC)
- The best way to prove notability is usually to show WP:THREE reliable sources discussing the subject in detail, to fulfill the Wikipedia:General notability guideline.Also, this is probably not the best place to ask this question, this is for large-scale proposals such as new policies or mechanisms. May I suggest you the Wikipedia:Teahouse, which is a lot more newcomer-friendly? If you want, you can write a draft yourself and submit it at Wikipedia:Articles for creation (and again, don't hesitate to ask for help at the Teahouse!) Chaotic Enby (talk · contribs) 19:38, 21 August 2024 (UTC)
- I haven't looked at this particular case, but the usual reasons for a missing article are either that the subject is not notable or that they are notable but nobody has volunteered to write the article yet. The latter is particularly common for subjects based outside the Western Anglophone world. Phil Bridger (talk) 19:53, 21 August 2024 (UTC)
For sources that are not the primary topic, such as ABC News (Australia), it is common for citations to link to the "work" wrong target, such as ABC News which, prior to the recent move, was the article for the American source.
In the case of this ABC News, there are hundreds of articles with broken links, such as LGBT rights in Afghanistan.
It is even more common for it to omit a link to the "work", either displaying it in plain Wikitext or not at all. This excludes important contextual information, and goes against MOS:UL which says that proper names that are likely to be unfamiliar to readers
, which would include news sources as few have global recognition, should be linked.
In the case of this ABC News, there are thousands of articles with missing links, such as Joel Reddy.
Following a discussion with Robertsky, I proposed a bot that would be able to rectify one or both of these issues, as well as add additional information to the citation template that can be determined from the URL or other content already in the template, such as the publisher or publication location.
To minimize impact on watchlists, it can be configured so that only some errors or omissions will trigger an edit, with the rest being done only if the article is already being edited.
I am raising this in the community now to determine whether the community believes that this task is worth completing.
In addition, the bot uses a configuration file that I would need the communities help to expand. Currently, it addresses issues with the following sources:
Sources
|
---|
Please provide details for the other sources that you wish to see corrected by leaving a comment on the configuration talk page, or if you are sufficiently familiar with JSON to understand the configuration file by editing it directly. BilledMammal (talk) 09:02, 25 August 2024 (UTC)
- Overall, I support more frequently linking publication names. For an article that doesn't use them, though, it should be kept consistent. Sdkb talk 22:41, 25 August 2024 (UTC)
- I’ve already touched on this, with the above reference to WP:UL, but to address it in a little more depth in regards to consistency:
- First, I don’t think we want to follow the pattern of the majority of the article, as in most cases they will be unlinked solely because RefToolbar doesn’t add links rather than because of any deliberate editor choice.
- Second, a sufficiently expansive configuration file will be able to switch from unlinked majority to linked majority.
- However, I would be able to alter the program to not include links under certain circumstances if that is what the community would prefer. BilledMammal (talk) 23:19, 25 August 2024 (UTC)
add additional information [...] such as the publisher or publication location.
If that's done, it should be VERY selective, erring on the side of omission. Cites for The New York Times do NOT need to show that the publisher is A. G. Sulzberger or that the publication location is New York City. Et cetera. Bots should reduce work for human editors, not create work for them; we have too much of the latter already. ―Mandruss ☎ 22:44, 25 August 2024 (UTC)- New York Times is actually a very convenient example, as it is already in the configuration file.
- Not only will it not add the publisher or publisher location, it will actually remove them if it is already editing a page, in accordance with the specifications at {{cite news}} BilledMammal (talk) 23:09, 25 August 2024 (UTC)
- Ok, provided equally sound judgment is applied to all cases. I'll take that as a matter of faith. ―Mandruss ☎ 23:31, 25 August 2024 (UTC)
Reword "Publish" to "Save"
editPeople keep becoming confused because they think clicking "Publish" means "Move my changes to article space". But they should think that! – that IS what "Publish" must mean to any reasonable person in their situation, and there's no good reason for them to think it might have the meaning it currently does. "Publish" means to make something generally available and accessible, to put it on public display – it doesn't mean "commit changes to upstream server" (or whatever is actually happening), and it certainly can't mean that to the average person editing Wikipedia.
The only potential good reason I can see to keep it as it is would be "We deliberately keep this process confusing" – and I don't agree with that kind of policy. TooManyFingers (talk) 17:09, 27 August 2024 (UTC)
- I can see your point, but as far as editing Wikipedia goes, anything you 'publish' is both available and accessible by other people. Relabelling as 'save' could likewise be easily misunderstood. AndyTheGrump (talk) 17:17, 27 August 2024 (UTC)
- Wikipedia's lawyers wanted the button changed to say "publish changes" to emphasize that all edits to any type of page are public. "Save" does not do that. 331dot (talk) 17:22, 27 August 2024 (UTC)
- meta:Editing/Publish discusses the rationale for changing "Save" to "Publish". The change was supported by the WMF legal team, but was based on user interface concerns that new users interpreted "Save" to mean save a private copy, without making their changes visible on the web to everyone. The WMF did a study in 2016 regarding using Save or Publish on the label (see mw:Wikimedia Research/Design Research/Contributors Team UX Research/2016.12 New Wikitext Editor and Save/Publish; findings regarding Save/Publish start on page 33), and some of its wikis already used Publish, so aligning with one improved consistency. isaacl (talk) 17:45, 27 August 2024 (UTC)
- I think this is a case of 'fixing the wrong thing'. What is wrong is Drafts. It is an incomplete feature because it's just a public page in a public thing that isn't really 'public'. It could be fixed by making these particular cases "Publish draft" or something the like however, making every single control in MediaWiki super context specific is a bit difficult (it is designed on purpose to be a generic system after all). —TheDJ (talk • contribs) 19:00, 27 August 2024 (UTC)
- Someone creating a draft has to grapple with several things...
- Writing some text in their draft
- Saving (which is published publicly; which means both legally it can be reused/edited/scrutinized)
- Even with all that, they need to transclude {{subst:submit}} which is when it is really submitted for review...and still then it's not published in sense of being visible in Mainspace (not to be confused with Wikipedia namespace)
- ~ 🦝 Shushugah (he/him • talk) 19:22, 27 August 2024 (UTC)
- Every control being context specific, sure. But having the text for a few select UI elements being namespace-specific (or namespace-overridable) may not be the worst idea for a future WMF developer project. ― novov (t c) 12:36, 28 August 2024 (UTC)
- Someone creating a draft has to grapple with several things...
- Just a general comment: even very common words do not mean the same thing to everybody. A change you think makes things clearer may make things more confusing for someone else. It's one of the areas where we have to find a rough consensus, using language that makes general sense to most users without leading too many astray. Discussions like this are how we figure it out. Donald Albury 21:03, 27 August 2024 (UTC)
- We're unlikely to find a word that can't be misinterpreted. "Save" is more ambiguous than "Publish", in my opinion. Perhaps "Commit". The absence of anything else that might mean "put this in the page" might be a clue. But, ultimately, any uncertainty lasts as long as it takes to try it and see what happens. Are we getting a lot of complaints from newbies who can't figure out what to do? If not, it's the proverbial solution in search of a problem.
People keep becoming confused
- Show me, please. Operative phrase is "a lot". A few is not enough. ―Mandruss ☎ 23:07, 27 August 2024 (UTC) - But what you write is public, even in draft space. That's the whole thing.
The only potential good reason I can see to keep it as it is would be "We deliberately keep this process confusing" – and I don't agree with that kind of policy.
Come on, that's an obvious strawman. The fact that the WMF already weighed on it, and that people gave it many thoughts before making this choice, should tell you there is probably a less dishonest reason for it. Chaotic Enby (talk · contribs) 23:09, 27 August 2024 (UTC) - We do cause confusion when we say (accurately) that every edit is 'published' but also use the verb 'publish' to refer to moving drafts to mainspace. But as others have said, the problem lies with the drafts, which is a poor choice of words to begin with (people don't usually publish 'drafts'). I've never heard or been able to come up with a better phrase, though. – Joe (talk) 08:39, 28 August 2024 (UTC)
- @Joe Roe A simpler change would be to change verb for move from Draft to Article as "Promote" to indicate it's a positive thing, without touching the thorny legal/technical side of publish. It's celebratory and fits other descriptions of being declined/rejected. The namespace bit is an implementation detail. ~ 🦝 Shushugah (he/him • talk) 11:55, 28 August 2024 (UTC)
- That sounds like a mixed metaphor to me. When else would you 'promote' a 'draft'? – Joe (talk) 12:09, 28 August 2024 (UTC)
- That sounds even worse to me. I would interpret "promote" to mean "show this to lots and lots of people". --User:Khajidha (talk) (contributions) 16:29, 28 August 2024 (UTC)
- @Joe Roe A simpler change would be to change verb for move from Draft to Article as "Promote" to indicate it's a positive thing, without touching the thorny legal/technical side of publish. It's celebratory and fits other descriptions of being declined/rejected. The namespace bit is an implementation detail. ~ 🦝 Shushugah (he/him • talk) 11:55, 28 August 2024 (UTC)
Discussion from when the change was new: Wikipedia:Teahouse/Questions/Archive_860#No_SAVE_button_in_sandbox. Gråbergs Gråa Sång (talk) 06:18, 28 August 2024 (UTC)
- And a more recent discussion: Wikipedia talk:Teahouse § "Publish" vs. "save". How the interface presents this button might be WP:CONEXEMPT for legal reasons. Pinging @Slaporte (WMF): does WMF Legal have any input on what alternatives (if any) would meet the same requirements as does in English? Folly Mox (talk) 10:51, 28 August 2024 (UTC)
- I think it important that editors understand that when they click the button, they are “publishing” whatever they have written. Where it is published does not matter. It may be published in Mainspace, in Draftspace, in Talkspace, in P&G space, etc. … but it is all a form of “publication”. Blueboar (talk) 12:16, 28 August 2024 (UTC)
- Long story short, it's gonna stay "Publish" - lots and lots and lots of prior arguments about this were already made, and the WMF is going to enforce that. The OP thesis is that editors are confused when editing in draft space. We could add additional guidance to Template:Editnotices/Namespace/Draft - which appears in the edit window for all pages in the Draft namespace if there is special guidance needed. — xaosflux Talk 13:33, 28 August 2024 (UTC)
- And additionally... complicated processes will always cause confusion, not matter how much text you throw at the user. The whole process only exists because we didn't want Pending Changes/Flagged revisions in main space. Flagged revisions would have probably been simpler to understand for the users, even if it would have been more annoying to us editors. Its always a balance. —TheDJ (talk • contribs) 16:03, 29 August 2024 (UTC)
Enable Meta:CampaignEvents feature on this Wiki
editThe Foundation has developed a new tool at Meta:CampaignEvents which is used by other editions of Wikipedia. Anyone who organizes an Edit-a-thon knows the event management tooling is quite limited and requires lot of behind-the-scene knowledge for promotion of events.
If you believe English Wikipedia should try this feature out, please support this proposal. It does not remove any existing options or require people to use this over other forms of event management. In order to set this up, we need to establish consensus to try it out and then file a Phabricator ticket request, which I am happy to do. See the recent talk from 2024 Wikimania about it here on Youtube and notes from the same session. Here are the slides.
In the past I organized edit-a-thons using the Outreach Dashboard which helped with tracking contributions, but not collaboration between editors (see here). I am also happy for English Wikipedia to try tooling that is used by other language editions of Wikipedia and contribute insightful feedback in order to make these tools useful. ~ 🦝 Shushugah (he/him • talk) 22:24, 29 August 2024 (UTC)
- Has the support team been looped in on this? There are 3 projects using so far, and it would be useful to know any outstanding issues. Also note, this requires a permission group (c.f. meta:Meta:Event_organizers) that we'd have to determine how to deal with. (some options: WP:PERM, autopromote). — xaosflux Talk 22:44, 29 August 2024 (UTC)
- I would suggest (if we do this) repurposing the existing "event coordinator" group as "event organizer". * Pppery * it has begun... 22:51, 29 August 2024 (UTC)
- The description says "enhance the management and visibility/discoverability of events within Wikimedia". That certainly sounds like a good thing.
- But going off on a tangent, as a checkuser, one thing I'd love to see is some way for an event coordinator to register the IP address(s) which are going to be used at the event, and having that be visible in the checkuser tool (@Dreamy Jazz). One of my suckiest CU experiences was blocking a whole pile of socks only to discover after the fact that what I really did was stomp on a perfectly legitimate "Learn to use Wikipedia" event for 13 year olds. There would be much awesomeness if a notification about that could come up in the tool. RoySmith (talk) 23:06, 29 August 2024 (UTC)
- I have not yet, but will ask a WMF Staffer to come here for comments. There is a recent video recording from the 2024 Wikimania. Currently available on Youtube. Repurposing WP:Event coordinator sounds excellent. ~ 🦝 Shushugah (he/him • talk) 23:06, 29 August 2024 (UTC)
- I would suggest (if we do this) repurposing the existing "event coordinator" group as "event organizer". * Pppery * it has begun... 22:51, 29 August 2024 (UTC)