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:

Discussions are automatically archived after remaining inactive for nine days.

Wikidata listsEdit

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
(non-admin closure) There is no consensus to permit the use of wikidata lists in article text at this time change the consensus status quo treatment of wikidata lists. Andre🚐 03:52, 1 February 2023 (UTC) (clarify that I am not finding a consensus to blanket ban or to endorse, but no consensus to expressly permit anything that isn't already permissible.) Andre🚐 23:37, 1 February 2023 (UTC)

Should mainspace lists where the contents are pulled from and maintained at Wikidata be allowed or disallowed? Fram (talk) 07:25, 19 September 2022 (UTC) (edited same day at 13.35, see start of discussion section)

Summary (Fram)Edit

There are a number of lists where the contents are pulled from Wikidata through Template:wdtable row, with specific subtemplates for different types of content. The result can be seen e.g. here. The Wikipedia-only version of the same list can be seen here. Previous RfCs (see Wikipedia:Wikidata#Appropriate usage in articles have already agreed that "Wikidata should not be linked to within the body of the article except in the manner of hidden comment" and that it is "not appropriate to use Wikidata in article text on English Wikipedia ", but allowing Wikidata in infoboxes and de facto also many in external links templates. Previous lists where not only the contents, but even the entries were Wikidata driven have been disallowed in the mainspace as well.

The new type of lists has a number of disadvantages compared to enwiki-based lists, i.e.

  • it isn't maintainable here but requires going to another website with another interface, making it harder for most people (for the data)
  • requires editing templates or creating new ones for the layout
  • Has issues with e.g. sorting, see for example here where (with the current Wikidata data) sorting on the "opened" column gives a random "Apr 1998" data inbetween the blank dates, and sorts "17 Apr 1968" before 1917 and so on. This example shows also a typical issue with getting data from Wikidata like this, the formatting. Wikidata has "April 1998", so I suppose the "Apr 1998" entry is formatted in a template. This makes it again harder for regular editors to maintain or layout such articles.
  • Similarly, at Talk:List of dams in Saga Prefecture an editor asked to remove the image column from the article, as they were unable to do this under the Wikidata format. This required the creation of a new template, instead of simply editing the article. Fram (talk) 07:41, 19 September 2022 (UTC)
  • There are other more minor issues, like the name appearing in the list being the Wikidata label, not the enwiki article name, or the sourcing being inadequate (Wikidata items referenced to some Wikipedia version, often outdated (e.g. some of the entries on List of islands of the Isles of Scilly use the 2001 census instead of the 2011 census our articles use, indicating the glacial speed of update Wikidata often has) Fram (talk) 09:03, 19 September 2022 (UTC)
  • See for example List of learned societies in Australia, with issues from the start (e.g. one entry with the incorrect Wikidata title instead of the correct enwiki title, and entries which don't even belong there like the Austronesian Formal Linguistics Association), and then made worse by an editor who probably couldn't figure out how to correctly add an entry[1]. This type of list is not editor-friendly at all. Fram (talk) 12:38, 19 September 2022 (UTC)

Summary (MSGJ)Edit

Thank you for starting this discussion and inviting me to present an alternative viewpoint. First, some background for those who may not be familiar with Wikidata. This Wikimedia sister project, launched in 2012, is designed to hold data for use by Wikipedias and other sister projects. Its use on the English Wikipedia is not at all new - it has been used extensively in infobox templates for many years now - so its use in data tables and lists should not be surprising to Wikipedia editors. I really thought and hoped that the "us and them" attitude towards Wikipedia and Wikidata had diminished over the years.

Being designed for this purpose, Wkidata offers many advantages over conventional wikitext for storing reliable data, including:

  • Numerous constraints which can catch incorrect data, such as incorrect units, a date of death before a date of birth, etc.
  • A very user-friendly interface (almost certainly easier than editing wikitext for new editors). For example, compare how you would update the height of a dam on wikitext version compared with on Wikidata.
  • Ability to use powerful queries to find information.
  • And probably most importantly, improvements to the data by one project will be of benefit to all projects.

All data on Wikidata can (and should) be referenced, just as it is on Wikipedia. All changes can be monitored via RecentChanges (if you have the appropriate option selected).

The use of a template to produce the rows of the table has several advantages, including:

  • The template allows any column to be overridden by locally defined content. For example on List of Welsh mathematicians the "Notes" column is entirely local content.
  • The wikicode to produce rows and columns, which is complex for many editors, is conveniently separated from the content of the table.
  • A column can be added or removed from the table by making a single change to the template, rather than dozens of changes to the wikitext.
  • The pencil icon   links straight to where the data is stored.

Finally, a word on the previous discussions about the use of Wikidata on Wikipedia. A table is not classed as "article text" so the prohibition on using Wikidata for article text is not relevant here. And, regarding the linking to Wikidata, the only link is the pencil icon mentioned earlier which is widely used and accepted in infobox templates. — Martin (MSGJ · talk) 17:04, 19 September 2022 (UTC)

Discussion (Wikidata lists)Edit

  • @Fram: Two things: this is asking whether they're allowed, not whether they should be allowed. Is this about getting clarity of where past decisions have landed us, or deciding whether they should be allowed? If it's really just asking whether they're allowed, the list of reasons why they're bad seems out of place. If it's asking whether they should be allowed, you may want to edit the initial statement. The other suggestion is sort of dependent on the first, but you may want to separate the summary of where consensus stands from specific arguments about what our policy should be. The latter isn't so much a summary as arguments supporting one outcome. — Rhododendrites talk \\ 13:00, 19 September 2022 (UTC)
    • Well, it's kind of a double question; are they allowed viz-a-viz the previous RfCs, and should they be allowed or not? I guess the second is more important than the first, as it's not intended as a "you did something that wasn't allowed" but more of a "this is how we'll proceed from now on". I'll change the RfC accordingly. Fram (talk) 13:35, 19 September 2022 (UTC)
  • Initial thoughts (should I be creating my own section per above?): I have mixed feelings about Wikidata lists. On the bad side: technical limitations. Some of the things Fram lists seem like they could be fixable, but for others it's a matter of better integration of Wikidata in Wikipedia (in the sense of editing). The current templates, which send would-be editors to a Wikidata page with no explanation, are a bit clumsy (but, granted, an early step in the process). On the good side: I can see at least two good uses for Wikidata in Wikipedia lists. The first is as a starting point. If you want to make a lists of dams in a given place, that's something Wikidata has data for, and pulling from Wikidata could save a lot of time vs. hunting it down and formatting it yourself. Then you could convert it to wikitext and move on. I don't expect that's very controversial, though. The second case is when Wikidata pulls from databases that are more easily kept up-to-date than a Wikipedia list. We have an awful lot of out-of-date lists, and if it's an appropriate topic, why not let Wikidata gnomes keep it up to date? We just need more sophisticated templates to allow for flexibility in display and for fixing errors without sending someone on a journey to Wikidata. So I guess part of my answer (although per above I'm not sure which question I'm answering) is: yes, at some point these are useful, and I'd encourage people to shift the discussion from a binary yes/no to figuring out (a) in what contexts they're useful, and (b) if the current setup is inadequate, what changes to the interface and/or templates would be needed to ensure we can take advantage of this data in those cases when it's useful? — Rhododendrites talk \\ 13:23, 19 September 2022 (UTC)
    Thanks for this very astute comment. I will happily admit that the template can be improved (e.g. sorting on dates which is mentioned earlier), and any suggestions will be much appreciated — Martin (MSGJ · talk) 18:07, 19 September 2022 (UTC)
    Rhododendrites I agree. If we have concerns about referencing, then use reputatable source checker to confirm them and colour/flag them differently (red = dodgy etc).If we want to see who did the edit change in Wikidata then create a combined history search, if they are coi change the colour.
    WIkidata would be useful for
    • Detecting scam/bankrupt smaller companies/pheonix - they are better setup for receiving feeds from regulators/credit agencies
    • Structured validated data in infoboxes: we could get rid of categories, and instead have a search based on the infobox.
    • Allowing readers to view chnages over time in table data in an article (which would act an an open alternative to statista ) - What were the top 5 exporters of truffle in 1932? Or does Template:Graph:Chart or similar already cater for that?
    • Allowing preferred data formatting in tables to be seperated from validdated data. (Sep rather than Sept, or my bugbear of non date in date fields). Wakelamp d[@[email protected]]b (talk)
    Wakelamp d[@[email protected]]b (talk) 02:40, 22 November 2022 (UTC)
  • My understanding from past RFCs is that we continue to be extremely wary of Wikidata, and have limited its use… but that, within those limits, it can be used.
That said, I don’t think we have been very clear as to what exactly those limits ARE. We need to spell them out clearly. Do we have a guideline or policy section covering this? Blueboar (talk) 13:55, 19 September 2022 (UTC)
I don't think its specific use in lists/tables has been put to RfC before. The closer of 2013 discussion wrote "There is a valid point raised that while running text is clearly not suitable for Wikidata use, it might be worth discussing use in tables specifically – but no consensus regarding this has been reached in this discussion." — Martin (MSGJ · talk) 18:09, 19 September 2022 (UTC)
  • I would think that this is disallowed per the previous RfC, which stated that it is not appropriate to use Wikidata in article text on English Wikipedia. A list article is still an article. I've actually come across some of these lists before and wondered why they were using {{Wdtable row}} instead of {{Wikidata list}}. The presumable reason is that {{Wikidata list}} produces an error when used in mainspace due to the results of that RfC and others. The use of {{Wdtable row}} in mainspace articles strikes me as a clumsy workaround to skirt consensus. Spicy (talk) 16:31, 19 September 2022 (UTC)
    Yes, a list is an article but the values in a table are not "article text", which I take to mean prose. Some tables combine values and prose, e.g. List of Welsh mathematicians, and the template will only produce the content for the values and not for the prose. — Martin (MSGJ · talk) 18:12, 19 September 2022 (UTC)
  • I'm of a mind that we shouldn't encourage them, and don't personally use them, but if someone wants to put together say a rather exhausting list of plant species or something, Wikidata may simplify the process. If someone finds a clever way to use them, why stop them? I agree with Rhododendrites that we should focus on where they're best used and how to improve their usage. CaptainEek Edits Ho Cap'n! 16:54, 19 September 2022 (UTC)
  • I agree with Rhododendrites - tables pulled from Wikidata are suitable for some uses and not from others. Where they are suitable I see no justification for either prohibiting or requiring their use (treat it like ENGVAR or citation styles: either version is acceptable, don't change without both a good reason and consensus). Where they aren't suitable obviously they shouldn't be used, but I hope nobody is advocating for that. We should work on making the integration better so that the problems identified are fixed rather than saying the first version is not perfect so go away and never come back again. I also suggest that developing a set of guidelines about where Wikidata tables are and are not appropriate for use to be a much better use of editors' time than arguing about whether they should or should not be used at all. Thryduulf (talk) 22:30, 19 September 2022 (UTC)
  • In theory, I'm fairly open to tables containing entries from Wikidata. In practice, I'd like to see more working and non-working examples. I think there are a few other language Wikipedias with deeper Wikidata integration, but perhaps I am mistaken and that is all just infoboxes. There are also a lot of things where information is rather fuzzy, making Wikidata difficult to use. It is easy to annotate uncertain dates and debates around them in wikitext; learning how to do that on Wikidata is rather hard and certainly unintuitive for people used to Wikipedia. —Kusma (talk) 08:18, 20 September 2022 (UTC)
    Thanks for your comment. I am of the opinion that only a clear-cut value can be appropriately used from Wikidata. Anything which requires clarification or explanation should be locally defined. There are a couple of approaches I have used in these cases.
    • For example on List of castles in Ireland#County Clare, the imprecise build date of Ballyhannon Castle is locally specified via |c5=c. [[1490 in Ireland|1490]]<ref>{{harvp|Westropp|1899|p=351}}</ref>
    • And on List of lighthouses in Scotland, I clarified the build date of Southerness Lighthouse by adding a footnote to the value from Wikidata via |c5+={{efn|Built in 1748 but not lit till 1800. Rebuilt in 1844.}}
    — Martin (MSGJ · talk) 16:01, 21 September 2022 (UTC)
  • I'll perhaps expand on my rationale later, but fundamentally, I support Wikidata-derived tables being allowed. It all comes down to implementation — if done well, the appearance to readers will be exactly the same as a manually generated article, and the Wikidata-derived one will be far more future-proof. {{u|Sdkb}}talk 06:03, 21 September 2022 (UTC)
  • The only argument presented by people in favor of using Wikidata continuously (as opposed to using it once to generate a list) seems to be making things easier to keep up to date. But most uses of Module:Wikidata table are timeless: lists of dams, lighthouses, and castles, etc. don't need much updating (other than adding new entries if they are built, which still needs to be done manually in the Wikidata version), so in those cases that argument is not convincing. On the contrary, there's been no refutation to several of Fram's points above which amount to the fact that it will almost always be possible to further optimize such a list with local tweaks because humans are better at this then co. So what's the harm in detaching from Wikidata and letting that be done? I'm not seeing it.
    For the few that aren't timeless (List of Brazilian mathematicians, List of Welsh mathematicians and List of Polish mathematicians seem to be the only ones), there is a slightly better case for using Wikidata, and I haven't come to a strong opinion either way. * Pppery * it has begun... 17:43, 21 September 2022 (UTC)
    For me it is not only about the creation of the lists, but the future updates and improvements too. I do not expect these lists to stay the same for ever more - I really hope they will be expanded with more information and better references. I believe this is both easier and better in the Wikidata version. Easier, because of the structured environment which lends itself to data import and verification. Better, because the knowledge will be shared among all language Wikipedias. — Martin (MSGJ · talk) 19:19, 29 September 2022 (UTC)
  • I would have thought the prohibition applied to lists and tables as well, but if that's not the consensus I would support extending the prohibition to lists and tables. No problem with using Wikidata to initially populate a table or list, of course; the onus is on the editor to make sure it's reliable data as with any edit. The problem of "sneaky vandalism", as I think Fram named it years ago, is real -- changes to Wikidata are not easily visible which means you may not know when your article has been vandalized, and even if it's detected a user who can edit here may be unable or unwilling to learn the quite different interface there. Re Rhododendrites' comment that it would be OK to have a table sourced to live Wikidata, knowing that the gnomes over there would keep it up to date -- I don't think anyone would be OK without outsourcing our table data to, say, Fishbase, for certain tables, so why would we be OK with it with an intermediary? Mike Christie (talk - contribs - library) 22:40, 21 September 2022 (UTC)
    Sneaky vandalism is a problem that can occur with any type of list. With watchlist integration, while not perfect, I can effectively patrol all changes to data which affect these articles. So I do not really accept that changes on Wikidata are invisible or hard to catcher than on Wikipedia. — Martin (MSGJ · talk) 19:23, 29 September 2022 (UTC)
    When I last tried "Show Wikidata edits in your watchlist" it added an incredible amount of noise that made the watchlist unusable. Has that changed? Johnuniq (talk) 01:25, 30 September 2022 (UTC)
    Yes, a couple of years ago. WMDE did the work, so it's probably documented at Meta-Wiki. The volume and relevance of notified changes seems to depend on the subjects that you're watching, so I suggest trying it out and seeing what you think for yourself/your own subjects. I feel like volunteer-me gets a surprisingly large number of notifications for Apology (act) and Apologia, but less than I expect for other subjects, like Lymphoma. Most of the changes I see are changes to the linked articles (e.g., someone creating an article at another language's Wikipedia about lymphoma). Whatamidoing (WMF) (talk) 22:32, 30 September 2022 (UTC)
    It's probably fair to say that there are still too many entries that make it through the filter. I don't need to know when someone changes the Bangladeshi label or adds a sitelink to the Hebrew Wikipedia. Really the only ones needed are those which affect the display of the relevant article, although an option to display all changes might be useful for some editors. — Martin (MSGJ · talk) 14:34, 1 October 2022 (UTC)
  • Question, if I wish to change or amend something in a table that uses Wikidata to generate info, would I have to go to Wikidata to make the edit, or can it be done using the edit mode here in WP? Say something simple like a style correction. Blueboar (talk) 01:46, 30 September 2022 (UTC)
    Taking the eventualist view, with future interface improvements, yes, you'll be able to stay on Wikipedia. Also, it's worth noting that tables generated through Wikidata are less likely to have errors to begin with because there are fewer elements being created manually. {{u|Sdkb}}talk 03:47, 30 September 2022 (UTC)
    So your "yes, you'll be able to stay on Wikipedia" is actually a "no". Deciding on the current status of such lists based on what might happen one day, perhaps (Wikidata is 9 years old, so it's not as if such changes happen rapidly) is not a good idea. So, @Blueboar: you indeed have to go to Wikidata to edit the info, Wikipedia edit mode won't help you. And Sdkb, your "less likely to have errors" doesn't seem to make much sense either, the elements are created manually at Wikidata or manually at enwiki, no reason why one would be less likely to have errors (on the one hand, Wikipedia has more editors and thus more vandals: on the other hand, vandalism on Wikidata is much more likely to stay undetected, see e.g. here where it took a full month until someone noticed that the page "Punjabi" had been moved (retitled) to "josh saunders", or here where it took more than a month for someone to notice that "Aaron Ramsey" was moved to "Penalty in the UEL final". Fram (talk) 07:37, 30 September 2022 (UTC)
    The reason Wikidata-derived tables have fewer errors is that, when you're adding a row through Wikipedia, you need to add both the data and the formatting, and each of those is a potential spot to mess up. I'm sure we've all seen tables that have an extra column used only in one row because someone put an extra "|-". When you're adding information on Wikidata, however, all you have to worry about is the data. And even there, constraint violations can help identify errors that Wikipedia would not have been able to flag, and data imports can help a single experienced editor add large amounts of high-quality information (rather than relying on piecemeal contributions by many different editors, any one of whom might mess up). {{u|Sdkb}}talk 15:26, 3 October 2022 (UTC)
    That's a rather anti-wiki position you take there. "relying on piecemeal contributions by many different editors" is what makes Wikipedia, and excluding these editors from pages is a good argument against Wikidata lists, not for them. (Never mind the countless times experienced editors made completely incorrect or botched mass updates of info on Wikidata of course). Fram (talk) 16:07, 3 October 2022 (UTC)
    I'm absolutely a fan of crowdsourced editing or I wouldn't be a Wikipedian. What I'm not for is forcing information that can be more efficiently handled in bulk to be handled piecemeal. That's why I oppose the wholesale deletion of template namespace, and also why I support the use of Wikidata. Neither of those things make me anti-wiki. Regarding the potential for errors in Wikidata imports, that potential exists in normal editing, too. I think the anti-wiki position would be to say that we should prohibit a type of editing entirely just because it's not done properly 100% of the time. {{u|Sdkb}}talk 18:18, 3 October 2022 (UTC)
    the wholesale deletion of template namespace Strewth!! Was that actually proposed? When? — GhostInTheMachine talk to me 19:15, 3 October 2022 (UTC)
    I'm using it as a hyperbolic analogy here, but there are certainly examples of resistance to template usage for things like census data that I'd say fall at a milder point along the same spectrum. {{u|Sdkb}}talk 20:54, 3 October 2022 (UTC)
    And in at least one proposal to implement a list from Wikidata that I examined, the one list of items here would have been replaced with code that got items from dozens of different pages at Wikidata. In other words, the attack surface for vandalism would have been multiplied dozens of times, and manual checking of Wikidata items would have been dozens of times more difficult than looking at wikitext here. Johnuniq (talk) 09:12, 30 September 2022 (UTC)
    • If I need to go to WD to edit WP… that is a deal breaker for me. So put me down as still opposed. Blueboar (talk) 11:26, 30 September 2022 (UTC)
  • I remain extremely sceptical about the value of using Wikidata directly in articles for anything, although obviously compiling a list/table using Wikidata, and then disassociating it, is completely acceptable. As is using it in project space, and potentially talk pages. It makes editing the content nearly impossible for those not used to Wikidata, and it makes watching the page for changes completely impossible. ETA: For instance, List of Welsh mathematicians, linked above as an example, contains entries with three inline sources for things like date of birth, presumably unnecessary (and if the sources disagree, this should be footnoted), and has abbreviated months, which is not Wikipedia style but can't be edited within the Wikipedia page. The repeated edit links are also obtrusive. Espresso Addict (talk) 05:44, 1 October 2022 (UTC)
    Thanks for your comments.
    1. MOS:DATES suggests that abbreviated dates like 2 Sep 2001 or Sep 2, 2001 are acceptable in tables. I think the full unabbreviated dates would take up too much space in most tables.
    2. Do you have any suggestions to make the edit links less obtrusive? They are necessary to allow editors to change the values, but are only currently visible to logged in users.
    3. The maximum number of references is set at 3 and could be reduced further.
    — Martin (MSGJ · talk) 14:32, 1 October 2022 (UTC)
"Sep" as an abbreviation for September looks very odd in UK English, which would appertain to a list of Welsh people. The problem is the lack of easy-to-understand customisation. If I have five sources for a dob, I can choose to include only say no 3 because it is reliable & accessible, or put in two sources because one is highly reliable but not readily accessible, and another less reliable but accessible, &c&c. I have absolutely no idea how to do that within Wikidata, and no desire to have to learn a new and cumbersome editing interface. Also using things like n/a for the death date of a living person feels disrespectful. No clue how to make the edit links less prominent; I dislike them in infoboxes, but there's usually plenty of whitespace there to absorb them. Perhaps if they only showed in edit mode, somehow? And how are logged-out editors supposed to amend things? Espresso Addict (talk) 23:44, 1 October 2022 (UTC)
@Espresso Addict: absolutely. If you are curating a list/table to such a degree then you will almost certainly want to forgo the convenience of the template and gain the greater flexibility. But 99% of lists are not like this, many of which are a bare list of links without additional information or references. For these, the template can produce a nice looking table with more detail, and is more likely to stay up to date. PS I use "Sep" all the time as an abbreviation for September, and it doesn't look odd to me! — Martin (MSGJ · talk) 15:51, 3 October 2022 (UTC)
  • Unless it can be altered on ENWP without going to Wikidata, I am in line with the previous consensus that wikidata imported content should not be used in article space except under the very limited exceptions. If it can be amended on ENWP and draw through to Wikidata, all my concerns disappear. Keep in mind those exceptions exist precisely because of the issues with Wikidata, chiefly its another project with its own rules and policies, its own admins, far less active users to combat deliberate vandalism, BLP violations etc. Importing lists that include living people is most BLP-watchers nightmare when you have to go to other projects to rectify it. (The same issues exist with imported commons content but at least thats relatively simple to fix). Being able to alter the content as it displays on ENWP, while on ENWP, without having to go to another project would seem to be something the WMF's tech tech could spend some time & cash doing (hint, its not difficult as anyone who has worked with a data warehouse and multiple databases knows) instead of whatever waste of time they are concentrating on. Only in death does duty end (talk) 16:22, 1 October 2022 (UTC)
  • Frankly, I read the spirit of the various RFCs on wikidata as being pretty clearly against their use in making articles - so the claim that a table isn't "article text" and so it is fine to make tables from wikidata ... strikes me as very much a rules-lawyering type of statement. I wish that the proponents of wikidata would quit pushing it in such ways - it doesn't help their "cause". Ealdgyth (talk) 13:29, 3 October 2022 (UTC)
    The past RfCs have explicitly considered Wikidata use in tables and found no consensus on the question, so I'm not sure where you're getting that it goes against their "spirit" other than that you're reading your preferred opinion into them. Your idea of "pushing" can just as easily be flipped: I wish that those who fail to see Wikidata's potential would quit resisting it in such ways. {{u|Sdkb}}talk 15:19, 3 October 2022 (UTC)
Its more that we do see the potential ... for abuse. And there needs to be either a strong mitigation or exceptional reason in place to ignore that risk. Which when it comes to wikidata, there rarely is. Only in death does duty end (talk) 16:47, 3 October 2022 (UTC)
Particularly for lists that include BLPs, there is potential for BLP violation going unnoticed; a particularly common form of vandalism is to state a living person is dead, or less malevolently, to believe unreliable sources and assume incorrectly that death has occurred. This happens time and time again, and requires careful oversight. Espresso Addict (talk) 22:13, 3 October 2022 (UTC)
  • No, Wikidata has been repeatedly banned from the body of the article. Every time a Wikidata-activist tries to shove Wikidata into the body of the article there is always consensus against it, they can't even get consensus for infoboxes. That's stuck in no-consensus. It appears that the only way to stop the recurring and disruptive creeping rollout-contrary-to-consensus by Wikidata-enthusiasts is to entirely shut off the calls to Wikidata in Wikitext itself. As long as it's available they just keep cooking up new ways to shove it out unilaterally. Alsee (talk) 06:50, 7 October 2022 (UTC)
    Additional note: lists [] are articles, and we have established consensus against linking to Wikidata anywhere in the body of the article. All of this content may be immediately deleted from any list or other article as a consensus action, as these tables massively spam Wikidata links. In theory the templates could be revised to eliminate the Wikidata links, however I hope/believe that the wikidata-enthusiasts here would not be so perverse as to advocate a blatantly broken and blatantly harmful result. It would be practically impossible for ANYONE to edit the page via Wikipedia OR Wikidata, as the wikitext contains nothing but jibberish and there would be no pencil link to edit via Wikidata. Alsee (talk) 19:57, 6 December 2022 (UTC)
  • Additional issue: editing of tables like this in Visual Editor is nearly impossible and gives, for the few things it can do, very poor results. I tested this with List of dams in Tochigi Prefecture. Compared to "normal", non-Wikidata lists, here I can only add a new line at the top, not anywhere else in the list, and the result is badly formatted. I don't know if the WD list template can be changed to solve these issues, but if not, I don't think it is acceptable to introduce new things into Wikipedia which are incompatible with Visual Editing (even though I loathe it, it is used by a fair percentage of people and many new editors, and making it impossible for them to edit a type of articles is not anything that should be tolerated). Fram (talk) 10:04, 13 October 2022 (UTC)
    That could be partially mitigated through proper use of TemplateData. {{u|Sdkb}}talk 14:06, 13 October 2022 (UTC)
    How so? My remark about the template is not that an editor won't know that they need to add the wikidata template or add a Qnumber, but that even with that information, you can't produce a good result in VE. Perhaps I am missing something, but I don't think Templatedata can solve or even mitigate the underlying technical issue. Fram (talk) 14:26, 13 October 2022 (UTC)
    VisualEditor at this point is capable of doing anything with templates that source editor can do, I believe. Having good TemplateData makes the interface easier for editors. {{u|Sdkb}}talk 17:56, 13 October 2022 (UTC)
    Have you actually tested this, e.g. with List of dams in Tochigi Prefecture? Try to add e.g. a new dam in the middle of the list, or to move one of the existing entries up or down. TemplateData won't change anything about this functionality. Fram (talk) 18:32, 13 October 2022 (UTC)
    This is a valid point, and I have made a start on creating TemplateData for this template, which can be observed on List of dams in Tochigi Prefecture. I do not know if rows can be added in different places, but I will seek advice on this. — Martin (MSGJ · talk) 12:08, 14 October 2022 (UTC)
    Thanks. Adding entries anywhere in the list is just one of the issues, you e.g. also can't delete the existing ones, and when you add a new line at the top (using the Wikidata template) it only fills the first cell, instead of filling the table as it should (no idea if this list is exhaustive, I stopped testing after this). Templatedata helps at editing the already existing lines (though not removing them or moving them inside the table), but does nothing to make the editing of the table possible. Just tested again at List of dams in Toyama Prefecture, and the new Templatedata is good (e.g. overriding an existing row label), but no solution to the fundamental issue. Fram (talk) 12:47, 14 October 2022 (UTC)
  • Thanks for the interesting discussion. I came here after participating in Wikipedia:Articles for deletion/List of CryEngine games and Category:Video games by game engine, and I was pointing people to here to see if a bigger discussion could be had. However this discussion is interesting with respect to the deletion discussion, as one suggested solution to prevent information being deleted was actually using WikiData to store the information, and not need categories or lists, and for users who are interested they could pull the data out of Wikidata. I've read with interest everyone's positions, and I agree with user User:Rhododendrites and User:CaptainEek. We should absolutely not force people to use them, but if editors use them appropriately that is also fine. I feel that inboxes and tables are good uses. Perhaps *not* inline text *for the moment* - we need to still make Wikipedia useful to casual editors and this is likely a step too far. However a table in the text is fine. With the original RfC being done in 2013 (as noted above), it is likely a good time to revisit the topic. I think we should use structured data in tables to help WP articles, and the benefit is that using it consistently means that updating information in WikiData updates it on all language Wikipedias (?potentially even other wikis such as WikiVoyage). The downside is single point of failure; however also single point of fixing - this may need other policies e.g. only logged in edits on WikiData. However may be better for consistency than some pages in WP where information on the same topic is markedly different as pages have not all be updated simultaneously. The application to lists for data is something I'm equivocal about. I hate a lot of list pages and think they should be better categorised, however there are supporters and detractors to this method of organisation as well. I do not like deleting referenced information, and if there was a way of archiving and easily searching it via WikiData I would be all for that. It would be nice if in future a "WikiData Explorer" page type was created where we could just pass it a search string to autogenerate data so we could get rid of lists. This is one for the future. However in the meantime I think we need to at least try improving our use of structured data - not ban but also not force its use. And if it doesn't work go back to normal tables. I quite like the WikiData sourced list of dams provided by the OP. Out of interest for User:Fram - I looked at the example you gave at List of learned societies in Australia. It was interesting as I think the table is generated by passing individual IDs - my futurist hat btw would be looking at this and saying in future it should be "table = learned society + based in australia -> autogenerate table with these fields". Why is this not a case of taking the ID code pointing to the wikidata entry out of there? This kind of error would also be made if manually creating the table, and isn't a commentary on why not to use wikidata for information. It's more a comment on how if you're not careful incorrect information can be put in any type of table, and what I get out of this is that if we truly passed a query to a database (if we made sure we had properly structured data) the presented information would be "better". Or have I missed the point here? - Master Of Ninja (talk) 07:42, 14 October 2022 (UTC)
    Thanks for sharing your comments.
    • No one is suggesting using data for inline text, and I can't think of a situation when that could be appropriate.
    • The reason that each row of the table is produced seperately is to allow human editors to override the data with locally defined content.
    • I agree completely with your comments on keeping tables updated.
    • There are all sorts of ways to browse Wikidata already, and Wikipedia is not really needed for that. See wikidata:Wikidata:Tools/Visualize data for ideas.
    • I can see the possible benefit, if someone is searching for a list which we do not yet have on Wikipedia, of linking to an automatically generated list. But there would be a lot of technical and policy issues to navigate.
    — Martin (MSGJ · talk) 12:21, 14 October 2022 (UTC)
  • Not only does Wikidata have questionable sourcing and verifiability policies not fully compatible with Wikipedia, but I wonder if folks would consider whether it's worth the trouble to make editing list pages even more complicated than they already are? I hate having to jump back and forth between Wikipedia and Wikidata just to manage interwiki links, and it would be an absolute nightmare if it was allowed to make up significant chunks of actual list content. Just say no to more complex articles, so we can focus more on encyclopedic content and less on formatting or template garbage. As for the idea that Wikidata is easier to edit than Wikipedia... I am highly skeptical of this claim, given that I think the average person couldn't even define what a knowledge graph is, much less find out how to add a statement to a Wikidata page. For new and anonymous editors in particular, it is likely extremely confusing to click edit on a cell in a Wikipedia list and then be taken to the read mode of an entirely different website that 99% of our readers have probably never heard of at all. Steven Walling • talk 20:41, 17 October 2022 (UTC)
  • On a procedural note: it seems clear from previous RFCs that existing consensus is toward disallowing Wikidata use in articles. It should almost certainly be removed from any existing lists unless and until a new consensus supporting it develops. Steven Walling • talk 21:01, 17 October 2022 (UTC)
  • Sorry for late comment but I only just saw this discussion. As an occasional compiler of lists of power stations in non-English speaking countries I support the use of Wikidata in lists. There are often new or retired power stations and keeping such a list up to date in 2 languages is too much work without Wikidata. Chidgk1 (talk) 19:10, 30 October 2022 (UTC)
    But I just looked at the template mentioned and I am pretty sure I will not use it as it seems more work than {{Wikidata list}}. I will just leave the English article out of date unless {{Wikidata list}} is allowed here Chidgk1 (talk) 19:47, 30 October 2022 (UTC) *
    It might be easier for some editors to pull data from WD, but using it in a WP article can make it impossible for other editors to edit.
To share my own experience … I went to WD and simply could not figure out how to edit it. I don’t even understand its basic structure, much less it’s coding. I was completely baffled. The thing is, Wikipedia is supposed to be an encyclopedia that anyone (including me) can edit. When an article pulls data from WD, it means that I simply can not edit that data. That is a fundamental flaw. Blueboar (talk) 19:51, 30 October 2022 (UTC)
This unfortunately is my experience too. The idea of Wikidata seems so good, put having tried to use it the implementation of that idea is terrible. That is aside from the implementation of interfacing in Wikipedia to Wikidata. The chances of a new editor trying to edit a Wikipedia page being aware, let alone able, to edit Wikidata to achieve there edit is zero. I have also struggled with trying to edit Wikidata, and having to do so to fix minor issue is a major headache. -- LCU ActivelyDisinterested transmissions °co-ords° 19:03, 5 November 2022 (UTC)
  • Strongly support allowing the use of Wikidata and {{Wikidata list}} in lists. I'll make my case in the first paragraph, and respond to opposition in the second one.
  • Wikidata gives us an enormous advantage: structured data. It'll be highly beneficial to transition more content to Wikidata anyway, thanks to the fantastic meta:Abstract Wikipedia project. It improves verifiability and reliability across Wikipedias (since all data is in one place); allows editors from all languages to contribute to the same database, which automatically gets updated across all Wikipedias (reducing Anglo-centric bias); and will likely help these very low-visibility articles stay "fresh". Using more structured data is vital to reducing our maintainability burden, saves tons of time with adding images and data on separate Wikipedias, and future-proofs the encyclopedia for projects like Abstract Wikipedia.
  • Most of the counterarguments I've seen result from current deficiencies in Wikidata. That doesn't mean we shouldn't use it; we should seek to improve it. It's a collaborative Wikimedia project too, not some kind of exogenous imposition. Some Wikidata pages can't be edited by even established editors here, who lack user rights on Wikidata, due to semi-protection; that should be fixed by switching to a "pending changes" or "edit request" model. Wikidata being edited on a separate website, not here, is a good thing, since it makes it clear that people are changing the structured data, not its presentation. I find {{Wikidata list}}s significantly easier to edit. Some criticized Wikidata's verifiability policy, but they're explicitly based on enWiki's guidelines.
I'm only addressing whether Wikidata should be blanket-banned in tables/lists; not whether it should be mandated. Page-specific consensus still reigns; I just don't want the consensns of a few dozen editors here (you gotta concede this is a low-visibility page) to bind our hundred thousand active editors. DFlhb (talk) 09:30, 8 November 2022 (UTC)
Unfortunately the discussions to include also have low participation as well, and of course WP:LOCALCONSENUS. Maybe it's time to have a site wide discussion of somesort. -- LCU ActivelyDisinterested transmissions °co-ords° 17:45, 8 November 2022 (UTC)
This is a sitewide discussion. * Pppery * it has begun... 17:50, 8 November 2022 (UTC)
Nevermind. -- LCU ActivelyDisinterested transmissions °co-ords° 18:14, 8 November 2022 (UTC)
  • I should start with a disclaimer that I primarily (really, these days *exclusively*) edit on Wikidata and have 200k edits there between me and my bot account. So my comment is not from the perspective of an ENWP editor (although I do read ENWP regularly). That said, I obviously support usage of Wikidata on all Wikipedias, as the Wikidata community - in collaboration with many other WPs including ENWP - has invested a lot of time and energy into collecting a fairly massive depot of data, with citations (though, citations are admittedly somewhat less common in Wikidata vs ENWP currently, sadly) and images. Having the ENWP community and many smaller Wikipedias involved in the collection and validation of the data has been a huge help over the years. It seems that a lot of the concerns here are around tooling and software issues that can ultimately be fixed by improvements to the templates, the Lua scripting tools, and other improvements to the MediaWiki and Wikibase codebases. It'd be a shame to miss out on the ability to optimize list maintenance and leverage data across all language Wikipedias rather than improve the tooling itself. Unfortunately, I admittedly don't have a great solution for getting those improvements to happen short of either convincing WMF folks of its importance or doing it ourselves. Nicereddy (talk) 17:36, 19 November 2022 (UTC)
    Is there any evidence that the existence of Wikidata lists on the English Wikipedia actually inspires people to make useful edits to Wikidata, rather than just give up? * Pppery * it has begun... 17:51, 19 November 2022 (UTC)
    Is there any evidence to suggest the opposite? Nicereddy (talk) 18:18, 19 November 2022 (UTC)
    The fact that people such as Blueboar in this very discussion have complained about being unable to figure out how to make the needed edits to Wikidata is good enough evidence for me. * Pppery * it has begun... 18:21, 19 November 2022 (UTC)
    Yup… as I said above, I took a look at editing WD and quickly became too confused to continue. Quickly gave up. Blueboar (talk) 18:36, 19 November 2022 (UTC)
    More confused than the first time you tried to navigate a template-filled Wikipedia article pre-Visual Editor? The most difficult thing about editing Wikidata is knowing which properties to use. With a list, however, you're typically just working with one or two that have been predefined. I'm curious where the complexity was? (Not saying there can't be a learning curve, but it doesn't seem too advanced for the average Wikipedian. — Rhododendrites talk \\ 13:54, 21 November 2022 (UTC)
    I can't reply for Blueboar, but for me, yes, it is very confusing: and comparing it with a "template-filled Wikipedia article" is not really fair. One can easily create an article on Wikipedia, and then start learning the ropes. On Wikidata, the complexity jumps are a lot larger in my view. I just took a link from one of the lists we discuss here, Anthropological Society of Victoria, Wikidata link. When I try to add the year it was founded, I suppose I need to use "inception". So far, sp good. Then add a reference to the year 1934: some properties I can find through gambling, some others I have no idea what they are called so I can't add them. IF I then want another fact from the same reference (e.g. the first chairperson, Henry Gencoult-Smith), then I have to readd the same fields all over again, and I'm rewarded with a pink box around the name because Wikidata doesn't have that name yet. Adding a reference on enwiki is a lot simpler. Then it merged in 1976 with the Archaeological Society of Victoria (A) to form the "Archaeological and Anthropological Society of Victoria" (B). Is this "part of (merged with)"? No, it merged with (A), but this property seems to expect (B). Or was it "merged into"? No, that only applies if (B) had already existed before the merger. And so on, and so on... Fram (talk) 14:21, 21 November 2022 (UTC)
    One can easily create an article on Wikipedia - For a newbie? Without Visual Editor? some others I have no idea what they are called so I can't add them - sort of like Wikipedia categories, or Wikipedia templates, or Wikipedia help pages, or Wikipedia style conventions. then I have to readd the same fields all over again - When you create multiple Wikipedia articles, you do not have to create the same sections, infoboxes, etc. again? rewarded with a pink box around the name because Wikidata doesn't have that name yet like linking to a red link? I'm not trying to pretend as though Wikidata is a delightful and intuitive interface. Figuring things out is a pain, like Wikipedia was for the non-savvy in its early years. Of course, you can just write something on Wikipedia where you can't on Wikidata, but we don't typically take kindly to people just writing something around here these days (unformatted, with the wrong tone, without references, etc.). Wikipedia has a lot more to understand when it comes to rules, conventions, expectations, etc. Wikidata is frustrating for its lack of obvious properties, but that's 90% of what a typical user does on Wikidata -- find/create an item, find a property, insert a value, repeat. I just have a hard time thinking that anyone could put in a tiny fraction of the time it takes to become a savvy Wikipedia playing with/learning to understand Wikidata and still have trouble updating a list. If we expected people to develop data models, propose new properties, and sync up metadata fields while importing a new database, then sure, but updating a list is just a couple simple properties. Would it be better if it were integrated into Wikipedia and more intuitive? Sure, but I just don't see the people slinging nested template parameters and quoting style guides as the "it's too hard to search for a property and insert a value" type. — Rhododendrites talk \\ 02:58, 22 November 2022 (UTC)
    The last few times I added/updated properties in Wikidata, as I recall I went down a rabbit hole to ensure that all the corresponding Wikidata items were in place to document the citation. I don't know if this has gotten easier since then. It's a large overhead that has discouraged me from editing Wikidata further. isaacl (talk) 21:07, 19 November 2022 (UTC)
    I have struggled with making Wikidata edits in the past, to the point where I have now given up trying to do so in the future. Loopy30 (talk) 23:23, 19 November 2022 (UTC)
  • Unless you can edit Wikidata lists on Enwiki, I'd be against using them in articles. There's this from 2013 that says that local editing is planned, but it's still not a thing nearly a decade later apparently. JCW555 (talk)♠ 18:01, 19 November 2022 (UTC)
    You can't (yet!) edit Wikidata from within Wikipedia - the project is mw:Wikidata Bridge but it seems to have stalled. However the Wikidata item is just one click away from the Wikipedia article. It's a bit like images which are hosted on Commons - they are also one click away. I don't see why this should be a barrier to using Wikidata as we are well accustomed to working with Commons. — Martin (MSGJ · talk) 20:32, 22 November 2022 (UTC)
    I don't do anything with images, so this comparison to Commons isn't applicable to me. Bottom line: I feel like everything on English Wikipedia should be editable on English Wikipedia, including lists and tables. I shouldn't have to go to another site to edit tables/lists on Wikipedia. JCW555 (talk)♠ 20:49, 22 November 2022 (UTC)
  • Note: I have nominated Template:Wdtable row for deletion because, whatever one's opinion about Wikidata lists, I don't believe a template which is incompatible with Visual Editor editing should be allowed. All opinions welcome at the TfD of course. Fram (talk) 09:33, 30 November 2022 (UTC)
    Note: The discussion was closed as keep. {{u|Sdkb}}talk 03:56, 9 December 2022 (UTC)
  • I edit at Wikidata, but I think that making an article solely based on an auto generated list is laziness. An auto generated list might complement an existing article but should not be the sole content of one. My only exception would be if the list was so large it would not fit on the main topic's article page. RPI2026F1 (talk) 03:03, 6 December 2022 (UTC)
    I tend to agree, and yet a "lazy" list is probably better than no list at all, and a maintained list is definitely better than an unmaintained list. The best lists we have tend to combine data and prose. — Martin (MSGJ · talk) 07:25, 6 December 2022 (UTC)
    I never said we should ban lazy lists, I just said they should be merged in with the main topic unless the size of the autogenerated list prevents it from being included in the main topic. RPI2026F1 (talk) 02:17, 9 December 2022 (UTC)
  • Strong oppose, As a massive proponent of One version of the truth in real life; I'd love to say I like this idea. But I don't think it will work practically; I have 3 main issues
    • Verifiability. Wikidata has a different value of 'Truth' than Wikipedia. The 'List_of_dams_in_Kanagawa_Prefecture' fails WP:V on face value (no references), and worst of all, it fails WP:V covertly, people will see 'Wikidata' and assume it's right, but if you dig 3 or 4 clicks into the 'reference' you see things like the 'Elevation' of 'Doshi Dam' being 'referenced' to 'Cebuano Wikipedia' (No article link, no 3rd party source) and the height being referenced to the ENW article (and Wikipedia:Wikipedia_is_not_a_reliable_source) . This could be fixed in wikidata with the reference being changed to the original source, but even then, experienced editors will find it hard to see that the data is poorly referenced and have to click each record individually to see the sourcing. Worse, readers looking for the original source so they can validate the information for themselves (as many students are told to do, for example) won't know where to start. Why would they click a 'pencil' to edit something, to find the source?
    • We might not WANT one version of the truth; using wikidata breaks WP:Consensus on content; what if, hypothetically, the editors on wikipedia agree that 'Doshi Dam' is 117 Metres tall, but the WikiData editors disagree? (Or more likely agree on a different definition of 'Height', for example)
    • Using templates breaks the flexibility of the article, editing a template is a massive pain; say we decide by consensus that (random example) 'Dams in the UK' should have a 'Nation' column, it would be impossible for the average visual editor user to make this happen, especially if we want to add facts that aren't on WikiData. JeffUK 15:05, 3 January 2023 (UTC)
      • It's routine to make Wikidata-based templates not include statements that are either unsourced or sourced only to a Wikipedia; this is already done, for example, in {{Infobox person/Wikidata}}. Facts that aren't on Wikidata (though they can and should be added to Wikidata, of course) and those that are at variance with what Wikidata records are also routinely included in Wikidata-based templates; same example applies. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:13, 3 January 2023 (UTC)
        That's less of an issue for single instance things like info boxes though; as it's 'opt-in' per property/parameter; and once a person has a sourced biographical property, it's unlikely to become unsourced. However, if you have lists of things, where some of them have a source for one particular property, and some don't (and new entrants may appear in either state) you either end up with a list page that's missing loads of entries, or someone has to manually fiddle with the wiki markup to hard-code sourced data back in again (then you get some entries which update automatically, and some that don't, which is absolutely the worst possible case), or the editor must go to WikiData to add the information over there and I don't think participation in another site should be mandatory. Either way it's a barrier of entry to editing boldly. JeffUK 19:01, 3 January 2023 (UTC)
    @JeffUK you raise the issue of cross-wiki disagreements, using dam height as a random example. If I may suggest better examples, we seriously do not want cross-wiki warring on things like nationality or gender. I've dealt with more than enough Russians shoving "Jewish" into Nationality fields, and I sure as heck don't want to waste all my time warring with transphobe-majority communities. Alsee (talk) 00:39, 7 January 2023 (UTC)
    So your preferred approach for a project that aims to document all of human knowledge is to shut out non-English speakers because some of them have objectionable views? {{u|Sdkb}}talk 06:26, 7 January 2023 (UTC)
    I have no idea where that strawman came from. I said, quote, do not want cross-wiki warring. Cross-wiki warring is especially disruptive. "Non-English speakers with objectionable views" aren't locked out of anything. They are free to argue their case on whatever wiki they actually edit.

    On a related note, I am appalled that the WMF was so clueless and misguided as to deploy the existing Wikidata integration such that Wikidata edits BYPASS/OVERRIDE our local page protections. If an infobox (or anything else) uses Wikidata, a vandal/troll/POVwarrior can defeat our Full-Page-Protection by shoving arbitrary text into a field on Wikidata and purging the linked Wikipedia page. Not only does it bypass page protections, it's impossible for a Non-admin to fix it without going to Wikidata. In other words it is effectively for most editors to fix it at all, because most editors have no idea Wikidata even exists. Alsee (talk) 06:34, 10 January 2023 (UTC)

    That is truly awful. BUT It did make me wonder whether we could do something similar in the other direction as an initial step; make it impossible to change end wikipedia referenced data in Wikidata (protect a section). (Actually, Is that possible to do in wikipedia?)
    All up, the way the different Wiki systems integrate is very unclear at least to me.
    For instance
    * Are there permanent integrations in wikidata to external databases, or is everything a once off?
    * When I look at the references on Wikidata, the top level URL is listed but not the source. I would have expected a recipe/script, and an auto check for updates.
    * There are a lot of items with 0 references if an infobox has no reference for something, does it get created in Wikidata as a 0reference? Can you tell that this has happened
    * If there is conflicting Wiki data between say en and de different wikipedia, which does es choose?
    * If editors are using translation software and dumping it in to their wikipedia, is Wikidata needed? (although machine translated pages that are never updated is another issues) Wakelamp d[@[email protected]]b (talk) 10:13, 10 January 2023 (UTC)
    • Anything in Wikidata is stored on Wikidata, i.e. the data may have been obtained from an external database at some point, but it will not be automatically updated unless via a bit
    • I'm not sure what you mean by this - as far as I know, references are just a URL
    • Again unclear, but I think you are referring to how data from Infoboxes is exported to WD. Typically the tools for this just say [imported from page foo at oldid bar]
    • If you're referring to the data on WD, it is the same for all languages. If you're referring to importing data, this is done manually (semi-automatically), so a user will choose.
    — Qwerfjkltalk 21:04, 10 January 2023 (UTC)
    One of the differences between MediaWiki (the software behind Wikipedia, largely developed by the WMF) and Wikibase (the software behind Wikidata, largely not developed by the WMF) is that Wikidata entries can have multiple answers for the same point. To use the example started by @JeffUK, Wikidata can simultaneously say that the height of Doshi Dam is 177 m, 194 yd, 600 ft, and 175 m, with separate sources cited for each number, and an editor-chosen priority level for which one (if any) should be preferred. It is not necessary to have only one version of "the truth" in Wikidata; you can instead choose which one you believe is most relevant. Whatamidoing (WMF) (talk) 22:55, 11 January 2023 (UTC)
    Of course, this doesn't solve the problem, as the template has to decide which of the multiple conflicting sources of truth to show (or show all of them). The module being discussed here seems to do the latter approach, which may not be what is wanted locally. * Pppery * it has begun... 01:33, 12 January 2023 (UTC)
    @Alsee, surely the is like templates, even if most editors are less familiar with it. I don't think it's within the WMF's responsibility to decide who this is used in articles - this can be done locally. — Qwerfjkltalk 20:57, 10 January 2023 (UTC)
  • My concerns have already been brought up repeatedly above, but I oppose the creeping in of content that fundamentally cannot be verified and edited on Wikipedia. Wikidata might be more user friendly in isolation, but it's not on Wikipedia, which makes it extremely user-hostile. The use of WikiData has absolutely crept past community accepted bounds and should be reined in. Der Wohltemperierte Fuchs talk 01:26, 12 January 2023 (UTC)

Poor toolingEdit

The arguments here are transferable to a number of other sister projects, like Commons, which suffer from many more problems than enwp and wikidata, including low adminship, tooling, limited i18n and yet it is the standard way to insert images in enwp, despite the built in tooling that enwp has for hosting files. If the goal is to solely focus on enwp and screw other language editions of Wikipedia, then yes wikidata/commons can feel like overkill at times. Wikidata is one of the few projects, that leverage the knowledge and expertise of non English editors, that can directly benefit enWP, and likewise allow english editors to benfit other language editions. We should celebrate that instead of admonishing it. I am sympathetic to many comments here, about difficulty in editing, and leave the recommended/preferred solution per specific articles (list of plants versus evolving breaking news section). ~ 🦝 Shushugah (he/him • talk) 15:25, 8 November 2022 (UTC)

Absolutely. A lot of systemic bias toward the English-speaking world tends to come through in discussions like this, with editors failing to realize how much content we lack in non-English speaking areas and how much Wikidata could help us there. Reminder: Two thirds of all topics covered on Wikipedia don't have an article in English. {{u|Sdkb}}talk 16:12, 8 November 2022 (UTC)
Yes! Thank you for making this point. ENWP is able to be self-sufficient due to the large English-speaking community, but that isn't true of many languages outside the top 10 or 15 largest Wikipedias. Being able to pull data from Wikidata to get up-to-date information is really useful for smaller communities, and having the large community of ENWP helping verify and maintain that information along with the Wikidata community and the communities of other language WPs would be a huge boon. Nicereddy (talk) 17:26, 19 November 2022 (UTC)
If this is the outcome you'd like the I suggest listening to user issues with using Wikidata and the issue that Wikidata can cause to Wikipedia. That way more editors will start and continuing using Wikidata. -- LCU ActivelyDisinterested transmissions °co-ords° 17:31, 22 November 2022 (UTC)

I expect few, if any, opponents are going to see 'new tooling' as solving anything. However anyone could of course start an RFC to determine whether the new tools lead to a more favorable change in consensus, if/when such 'new tooling' actually exists. Until then we have the inherent downsides of using Wikidata combined with tools and support that even Wikidata-advocates acknowledge are bad. Alsee (talk) 17:49, 9 December 2022 (UTC)

I like the idea of a new tool/data type - if the problem is edit control, referencing, and different guidelines, Why couldn't we just use a wikidata structure in a separate instance linked to enW?
Maybe there is some money as Wikidata has now got an extra USD 2.4 million in the updated Annual Plan 22/23 budget as part of the 17 to 28 % increase in funding "representing inflationary and other year-on-year costs" Do people know why it is such a priority for WMF? Is it auto create of articles using lambda functions in other languages, or high status because of GLAM projects, or selling access, or ,,,??? Wakelamp d[@[email protected]]b (talk) 06:55, 10 December 2022 (UTC)
@Wakelamp while a local Wikidata instance would solve issues with administrative control, referencing, policies&guidelines, that would wipe out the entire argument in support of it. The entire rationale for stripping this content completely out of EnWiki's control was to create a single shared global database. The justification is for other wikis to benefit from any work we do editing Wikidata, and for us to benefit from work done by others there. Creating and using a local version would leave us with all of the increased complexity and difficulties of the additional system, in exchange for pretty much no purpose or benefit for anyone.
While I may disagree with Wikidata enthusiasts on the cost-benefit trade-off of using Wikidata here, I'm pretty sure they'd hate the idea of local instances. I understand the benefits they're trying to pitch. They want to suck up as much data as possible into a single centralized system... and to pipe that data out to as many places as possible. A local instance defeats the entire point. It's all about pushing everyone to become a Wikidata editor, centrally editing everything at Wikidata. Their project is so super-duper amazingly great that they think everyone at every Wikipedia on the entire planet should be feeding and serving their project. Alsee (talk) 03:31, 12 December 2022 (UTC)
@Msgj @Fram Many of the comments are about process (reliable references, etc ) and systems (how can we update in enWikipedia transparently, history) and single source of truth (Wikidata was in part created using enWikipedia data, GLAM databases).
What would you both think of having an interim option of en wikipedia having it’s own wikibase instance updated by en editors using our guidelines?
Looking at the opposite direction from en WP to Wikidata, @Ser Amantio di Nicolao @User:BrownHairedGirl. I think you both do a lot of categoriustion, and my apologies in advance if i am incorrect.
Is Wikidata the reason for the increase in complex intersection categories in Wikipedia? And what do you if the categoristion/infoboxes/lexemes (?) are different between the 2 systems? ~~ Wakelamp d[@[email protected]]b (talk) 10:46, 17 December 2022 (UTC)
I'm very reticent about getting involved here, but I do think we have to look at this from the perspective of a typical Wikipedia reader, and their experience. They almost certainly arrive via Google, and all they do is read. They never use categories explicitly, and tend only to look at lists if they googled for a list. They use links to jump to related articles, and disambiguation pages if their Google search wasn't specific, but that's about it. They look at an article as an integrated whole, and it would never occur to them that the infobox isn't part of the article, or might be following a different set of rules about referencing and data-integrity. There is no logic whatsoever in deciding that a birthdate in an infobox can be derived from wikidata but outside an infobox it can't; from the reader's perspective, both are just birthdates in an article. But our readers do care about being given accurate data. The point about wikidata is that if the world is behaving properly, a lot of French editors will be noticing problems in French data and correcting them; if we decide to go our own way and use our own data, all those French corrections will pass us by, and we'll carry on showing bad data, relying on a tiny number of English-language editors who happen to have a foot in French matters. Or, in the less-likely event of one of those English editors spotting a problem with a French data-item, our correction won't benefit the French Wikipedia. Together, we can curate data much better. Elemimele (talk) 10:27, 22 December 2022 (UTC)
I agree in principle that it would be awesome if we have one repository of verified facts that we could use in multiple projects. But in reality, Wikidata has 23,890 active users, Wikipedia has 116,976 active editors, and consistently more than 50,000,000 unique visitors (devices) every day who can become an editor the second they see something that they know is wrong. That's a hell of a lot more eyeballs finding and fixing incorrect data. and reducing barriers to entry for those millions of people to make edits is surely the most important? Of course if we could have some way to integrate them, such that a 'data list' on Wikipedia is synchronised with wikidata, which in turn can be consumed by other wikis, that would be awesome, but the technology isn't there right now. JeffUK 10:55, 4 January 2023 (UTC)
@JeffUK the issue is worse than that. puts Wikidata "active editors" at 12 thousand, but Wikidata editor stats are severely inflated. Edits on other wikis, such as page moves, may trigger bot clone-edits updating Wikidata links to those pages. Those bot edits get attributed to the person who made the edit elsewhere. They have only a few thousand genuine active editors and over a hundred million Wikidata-items. Wikidata culture is primarily about sucking up as much data as possible, preferably with bulk bot edits. The actual community far too small to meaningfully patrol content quality or vandalism, even if they did consider it a priority. They have few content policies. The only reason they created a fig-leaf BLP policy is because their long-standing failure to create one was dragging their reputation through the gutter. Alsee (talk) 04:53, 7 January 2023 (UTC)
The discussion above 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.

Post closure discussion on Wikidata listsEdit

  • Andrevan, just to clarify/confirm, this is a no consensus outcome? {{u|Sdkb}}talk 06:40, 1 February 2023 (UTC)
Good question… is “lack of consensus” the same as “no consensus”? Blueboar (talk) 12:30, 1 February 2023 (UTC)
No consensus to change the existing consensus of past RFCs. Andre🚐 15:38, 1 February 2023 (UTC)
So the existing consensus at prior RFCs still stands. Blueboar (talk) 17:02, 1 February 2023 (UTC)
Yes Andre🚐 17:08, 1 February 2023 (UTC)
Thanks for closing, but I think the wording needs clarifying. As I pointed out above, there is no previous consensus on using Wikidata in tables, so this does not get us anywhere different as there is no previous consensus to go back to. The close of the 2013 discussion includes There is a valid point raised that while running text is clearly not suitable for Wikidata use, it might be worth discussing use in tables specifically – but no consensus regarding this has been reached in this discussion. — Martin (MSGJ · talk) 19:58, 1 February 2023 (UTC)
There is a previous consensus on using Wikidata in tables. It's Wikipedia:Bots/Noticeboard/Archive 13#Re-examination of ListeriaBot and Template talk:Wikidata list#"Not permitted" in mainspace. * Pppery * it has begun... 23:36, 1 February 2023 (UTC)
It's funny I had also drafted a comment saying "Thanks for closing" and requesting the closing text be more clear, as there was clearly a dispute over how to interpret the previous consensus. However on reconsideration, I hoped that no consensus to permit was sufficiently clear. It is not possible to read this as allowing Wikidata lists, as that opposite interpretation would have required no consensus to prohibit phrasing.
In any case, this closure has already resulted in an editing conflict. Andrevan I thank you for your close, and I request a more clear close-text to avoid further conflicts. Specifically are editors (1) prohibited from converting Wikidata lists to non-wikidata? (2) Are editors prohibited from creating new wikidata lists? Or (3) both are permitted. Alsee (talk) 20:42, 1 February 2023 (UTC)
There is no consensus to permit using wikidata in article text. My understanding of the prior consensus is that the prior consensus did not permit wikidata in article text. I don't see any consensus here to change the status quo. No specific consensus was reached to allow use in tables, but I didn't review the previous close to see if the use in tables was permitted, but I'm guessing if it wasn't expressly prohibited, then existing usage of it could be justified under whatever prior justification existed. It's a no consensus close with no change to the existing status quo and no new resolution obtained as to new usage of wikidata. Andre🚐 21:12, 1 February 2023 (UTC)
My understanding of the prior consensus is that the prior consensus did not permit wikidata in article text. This is false. Some of those opposed to Wikidata use tried to imply that, by saying it would run counter to, as one !voter put it, the spirit of the various RFCs on Wikidata use, but that was heavily contested. {{u|Sdkb}}talk 23:21, 1 February 2023 (UTC)
If you are asking me to vacate the close I will vacate it, but the close was a no consensus for any new proposal being enacted close. If the existing state of things was a limbo then it should still be in limbo. I will admit that in the section of the RFC that discussed this I took the word of the participants on the state of the status quo ante, but it didn't factor into this close being a no consensus one. If you really think someone else would close this differently, I am happy to revert myself. Andre🚐 23:29, 1 February 2023 (UTC)
I don't see a need for you to vacate the close currently; I suspect a different closer would arrive at the same no consensus result. {{u|Sdkb}}talk 23:32, 1 February 2023 (UTC)
For me, the ambiguity lies not in the statement that it is not appropriate to use Wikidata in article text on English Wikipedia, but in the fact that a table is structured content and not article text. The 2013 discussion specifically excluded tables in its close, so there is certainly no existing status quo in this respect. If the closer had written article article prose then it would have been clearer still. — Martin (MSGJ · talk) 23:38, 1 February 2023 (UTC)
Lists are article text. Tables (unless images) are article text as well. Article text does not need to be in prose form. Blueboar (talk) 00:35, 2 February 2023 (UTC)
Well that's not how I understand the term. And why else would Coren (the closer) specifically contrast running text with tabular content? Infoboxes are mini-tables, and the usage of Wikidata on them is widely accepted. — Martin (MSGJ · talk) 08:16, 2 February 2023 (UTC)

Ping RexxS and MSGJ. I get about sixty subpage hits for Special:PrefixIndex?prefix=Template:Wdtable_row. After significant-but-incomplete spotchecking, you two appear to be the primary or sole people editing these templates and deploying them to articles. I was wondering whether either or both of you were willing to accept responsibility for restoring all affected articles to a non-wikidata state? And whether you would be willing to tag all these templates CSD G7 author-requests-deletion once they are no longer in use? Alsee (talk) 19:27, 1 February 2023 (UTC)

RexxS has not - alas - edited for two years. It might be said that if something they did has persisted for that long, then there is consensus for it to be so. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:28, 1 February 2023 (UTC)
Either that or it simply flew under the radar. I suspect the latter is more likely. * Pppery * it has begun... 23:36, 1 February 2023 (UTC)

The closing statement is pretty jarring given the discussion it intends to summarize. If there's any consensus to be found here, it's that many people have reservations about Wikidata lists, and many people see the potential to use them in certain circumstances, and only a handful of people want either a total ban or blanket permission. There are so many opinions here with extended conditions, qualifications, thoughts, and suggestions, that I don't see anything like consensus for a simple thumbs up or thumbs down (which the closing statement grants, given no clear prior position). If this really needs closure (and I'm not sure that it does), probably just "no consensus" with a recommendation to narrow the question to be about certain cases/uses. Also, as an aside, the Community Wishlist is going on now. If you want better tooling, this may be a good time to propose it. If anyone knows of any really good ideas to address Wikidata editing through Wikipedia, I'm happy to be canvassed to that proposal. — Rhododendrites talk \\ 21:10, 1 February 2023 (UTC)

"Many people have reservations but see the potential but NOTNOW" is akin to my reading. There's no consensus to permit new things. If there are gray areas before there are gray areas now. The intention is not a consensus for a thumbs down but no consensus for a thumbs up. I'm happy to vacate the close and let someone else close if there are concerns, though. Andre🚐 21:13, 1 February 2023 (UTC)
  • I've amended the close to address this discussion. Let me know if you have further concerns. I am sorry that this outcome isn't very useful but I do not see how it can be closed other than a no consensus for a new proposal to be enacted regarding wikidata lists. Andre🚐 23:39, 1 February 2023 (UTC)

Approval of Enforcement Guidelines without first approving a Code of ConductEdit

The Wikimedia Foundation has announced that January 17 begins voting on a second attempt to obtain approval of Enforcement Guidelines for the Universal Code of Conduct. There has been no such voting on the content of the Universal Code of Conduct itself.

Does the community Endorse or Oppose approval of Enforcement Guidelines prior to, or in the absence of, any community approval of a Code of Conduct itself?

This RFC is intended to determine and communicate a consensus position. Editors may consider this during current or future Enforcement Guideline votes, and the Wikimedia Foundation may consider it when evaluating how to proceed if the second Guideline vote turns out worse than the first vote. Alsee (talk) 07:53, 14 January 2023 (UTC)

Responses: Approval of Enforcement GuidelinesEdit

  • Oppose. I will never approve Enforcement without approval of a code itself. The current Code of Conduct is botched, and without consensus the Code has no legitimacy. Consensus is especially NECESSARY as the Code is almost entirely worthless and ineffectual without active community support for it. Repeated attempts by the WMF to "improve" and re-vote the Enforcement Guidelines can never fix those fatal flaws. The WMF needs to stop trying to steamroll forwards, it is necessary to back up and let the community develop a new Code which actually gets consensus approval. Alsee (talk) 08:07, 14 January 2023 (UTC)
  • This RfC seems founded on a rather narrow understanding of "approval". The UCoC was approved by the WMF Board of Trustees, the legal custodians of this project, who we play a part in selecting. Not all decisions are subject to consensus of editors and local policy specifically recognises acts of the WMF Board as one of those exceptions. The UCoC isn't the first policy to come via this route and we can enforce it with or without guidelines, just like we enforce the Terms of Use, for example. – Joe (talk) 10:12, 13 January 2023 (UTC)
    • It's also worth pointing out that the (global) community has already approved the enforcement guidelines – the first vote was 56.98% in favour. – Joe (talk) 07:44, 16 January 2023 (UTC)
  • Oppose I didn't participate in this before and I haven't really looked into it all in any depth but it seems to me that if the foundation position is that they must have the code whether community approved or not, then they can impose the enforcement as well and see what occurs. I would not personally approve the enforcement guidelines since by doing so that is in fact approving the code of conduct retrospectively. Selfstudier (talk) 08:18, 14 January 2023 (UTC)
  • Oppose. I agree with everything Barkeep49 said earlier, except the conclusion. If it was a mistake and you don't want the mistake repeated you have to speak up. Frederick Douglass expressed it like this: If there is no struggle there is no progress … Power concedes nothing without a demand. It never did and it never will. Find out just what any people will quietly submit to and you have found out the exact measure of injustice and wrong which will be imposed upon them. Following his crystal-clear logic, there is no choice but to oppose. There is another reason to oppose as well: subject the UCoC to community vetting, and it will become a more robust, less ambiguous document. It will become better, more fit for purpose. --Andreas JN466 09:21, 14 January 2023 (UTC)
    I see that an abolitionist's words on fighting against racial inequality are being compared and applied to a code of conduct that prohibits name calling, using slurs or stereotypes, and any attacks based on personal (m:Universal Code of Conduct § 3.1 – Harassment). 🐶 EpicPupper (he/him | talk) 00:57, 15 January 2023 (UTC)
  • Oppose. It would be grossly improper for the en.Wikipedia community to in any way endorse a 'code' being imposed without consensus by an outside body. AndyTheGrump (talk) 10:02, 14 January 2023 (UTC)
  • Oppose. The UCoC is well intentioned and contains many sensible rules. However, a similar and more tailored set of rules is already approved and enforced by the English Wikipedia community. The UCoC provides a model which smaller communities may choose to adopt, perhaps even by default, but neither the code nor the new police force that comes with it would be helpful to enwp. The WMF will impose UCoC anyway, but they need to understand that this is a power grab without consensus which conflicts with the community's needs rather than satisfying them. Certes (talk) 10:59, 14 January 2023 (UTC)
  • Oppose as it is inappropriate to enforce something that is not approved. Current codes and practice handles inappropriate behaviour here. Graeme Bartlett (talk) 21:41, 14 January 2023 (UTC)
  • Oppose Graeme Bartlett said it perfectly. it is inappropriate to enforce something that is not approved. Current codes and practice handles inappropriate behavior here. Adding to that, if WMF insists on pushing guidelines invented by them without community approval, its time to fire WMF and replace them with an organization that has not gone astray and revised the bylaws that allowed that to happen. North8000 (talk) 22:05, 14 January 2023 (UTC)
  • Oppose per all of the above (and more). Paul August 22:17, 14 January 2023 (UTC)
  • Alternative - drop the facade of this being something was in any way “approved” by the community, and admit that it is something imposed by the WMF. Let them figure out how to “enforce” it. Blueboar (talk) 22:38, 14 January 2023 (UTC)
  • I am not sure what this vote is about, but I am personally going to vote on Meta to adopt the enforcement. I opposed it last time and raised a specific concern. From what I see, the problematic part was eliminated, and I do not see any further issues with the enforcement.--Ymblanter (talk) 23:39, 14 January 2023 (UTC)
  • Oppose per Alsee. I'm confused how we enforce a thing that has not, itself, been approved. Somehow I misunderstand. Chris Troutman (talk) 03:53, 15 January 2023 (UTC)
  • I voted against the first enforcement guidelines as I thought there were enough flaws that nothing was better than those. I will be supporting the enforcement guidelines when they come up for a vote again, as enough has changed to tip me over. One concern noted above is something we don't have to worry about. No one is going to be compelled to enforce the UCoC, in the same way no one is compelled to enforce UPOL, BLP, Harassment, or any other policy (or guideline) now. In fact this removes a requirement for admin to agree to the UCoC at risk of losing their adminship and that change is one of the reasons I can support the revision. In the end this is a non-neutrally worded advisory RfC about a Wikimedia wide advisory vote to the Board who will make an actual vote. I suspect that this RfC will attract the people who are most opposed to the UCoC and I think it is important for their voices to be heard, in particular their frustration (which I share) about the lack of community ratification of the original guidelines. I also suspect this RfC will be less likely to attract the people who are mildly supportive of the guidelines but who might vote to approve them in the final vote. So I hope everyone takes note of whatever consensus is reached here - because if a consensus is reached it's worth taking very seriously - but at the same time those participating realize the limitations of what that consensus will mean. Best, Barkeep49 (talk) 05:16, 15 January 2023 (UTC)
    • I generally agree with Barkeep's perspective here. Wug·a·po·des 20:43, 19 January 2023 (UTC)
  • Support - I might be the only editor on this project who voted for the enforcement guidelines last time and is looking forward to voting for it again. Yeah, it would have been better for the UCOC to be put to a community ratification vote, but that doesn't bother me so much because that decision was made by different WMF leadership than the one that is handling (well, IMO) the enforcement roll-out (cf. it passed with like 55% or so but they didn't implement it, sort of the opposite of how the UCOC itself was handled). The other reason it doesn't bother me is because the UCOC is such a vanilla document--like, it's beyond me what objections anyone could have to those provisions that aren't nitpicky--other than that it's way longer than it needs to be. But overall, put me down for being glad that there's a UCOC and hopeful that enforcement provisions will be put in place soon. That's been long overdue on this website, which has a terrible, terrible record of self-regulating user conduct over the past two decades. It's long past time for English Wikipedia to grow up and start behaving like the rest of the world and not like the wild west... which means a UCOC, and at least some method of UCOC enforcement by impartial professionals rather than volunteer members of the community. Cf. Twitter, which was improved significantly when they started being more serious about regulating user conduct on that website, and has backslid since those regulations were recently relaxed. Cf. all other social media. Levivich (talk) 20:19, 15 January 2023 (UTC)
    It's long past time for English Wikipedia to grow up and start behaving like the rest of the world and not like the wild west... which means a UCOC, and at least some method of UCOC enforcement by impartial professionals rather than volunteer members of the community. this is going to come off like snark, but I mean this sincerely: if you believe this you should vote against the UCoC Enforcement Guidelines. The Enforcement Guidelines have the Principle of subsidiarity as a major tenet which means that nearly all enforcement, including all new enforcement enabled on other projects that don't have policies and guidelines that already cover the tenets of the UCoC (unlike us), will continue to be done by volunteers (both in the sense that it's people willing to enforce the UCoC and that they are not impartial professionals). There's a path not taken where professional enforcement of the UCoC is what happens but that was not what either of the committees that drafted the UCoC Enforcement Guidelines chose. Best, Barkeep49 (talk) 02:21, 16 January 2023 (UTC)
    Oh I know, but I disagree that one should vote against the UCOC Enforcement Guidelines if one believes in professional enforcement... I see UCOC and the Enforcement Guidelines as incremental steps. My prediction: both the UCOC and the Enforcement Guidelines will work, and work well. I think we will perceive no change on enwiki (for the reasons you point out: it's set up to not 'mess' with our developed self-government), and that in and of itself will be a big deal, as the enwiki community will come to realize that this is not a "power grab" or anything like that. I think, give it a few years, but it will help develop trust between enwiki and the WMF, and I hope that trust makes enwiki more comfortable with the idea of professional enforcement, which, btw, I pitched today at the idea lab in case anyone is interested (don't forget to hit that like and subscribe button). Levivich (talk) 04:32, 16 January 2023 (UTC)
    My own expectation is that there will mostly be "no change" until someone decides to try for another WP:FRAMBAN. And then the UCoC will be used to counter the opposition that ultimately resulted in the WMF's attempted ban being overturned. They've got the overbroad language that can be selectively interpreted, they've got the "protect the victim" language to justify not giving any details, they've got the language allowing them to override local processes if they think local processes "refuse to enforce the UCoC" or "lack will to address issues", they've got language mandating the committee be "diverse" in a bunch of ways (but not viewpoints) that could allow for disqualifying troublesome candidates for not being "diverse" enough, etc. Anomie 00:05, 17 January 2023 (UTC)
    In the current proposed enforcement guidelines, there is no requirement that the Universal Code of Conduct Coordinating Committee be diverse. That being said, the process for electing this committee is still to be determined by a yet-to-be formed group. isaacl (talk) 00:40, 17 January 2023 (UTC)
    There is a requirement that the building committee reflect the diversity of the movement and there is a requirement that the work of the building committee be ratified by vote. So while it's true that there is no requirement for the U4C to be diverse, but I would be amazed if there isn't a requirement by the time the U4C comes into existence. To give a peek behind the scenes, the way that the U4C building committee came to be was because I proposed some diversity requirements for the U4C and the original Enforcement Guidelines drafting committee quickly realized just how much time it would take to hammer those and other fundamental U4C questions out. Best, Barkeep49 (talk) 00:45, 17 January 2023 (UTC)
    Yes, for brevity I omitted discussion of the building committee. If the entire coordinating committee membership is elected, I can only imagine mandated diversity that covers certain broad characteristics, like geographical region. We'll see what the building committee comes up with. isaacl (talk) 00:56, 17 January 2023 (UTC)
    It says The U4C’s membership shall be reflective of the global and diverse makeup of our global community. True, the current "such as but not limited to" list is only in connection with the building committee, but I'd be surprised if they didn't wind up with basically the same thing for the committee itself. Anomie 10:17, 17 January 2023 (UTC)
  • I don't broadly disagree with the intent of creating a UCoC, but I think that it's important to observe that the rest of the internet is (on the whole) even worse at this than Wikipedia, at least aside from smaller communities that are easier to moderate in a hands-on manner. Compared to eg. Facebook or Twitter we are vastly better at handling issues even on talk - I definitely don't agree that (even prior to their current issues) they were doing better than we are. Twitter and Facebook, for the most part, still allow, and have always allowed, things like the aggressive promotion of fringe theories or even "dogwhistle" racism, sexism, transphobia, blatant trolling and so on as long as it doesn't trip one of the few red lines they've set; similarly, aggressive harassment occurs on those platforms quite regularly as long as it doesn't cross one of their few red lines. Wikipedia isn't perfect but I feel that it has generally done better than those, and part of the reason is because of the limitations that come from trying to solve complex social issues via a set of rigid rules established from above with no input or buy-in from the community. I absolutely do not think we should be looking at Facebook or Twitter as the model for how to handle anything, ever, and I'm baffled that anyone would say otherwise - they are examples of what not to do. --Aquillion (talk) 04:24, 16 January 2023 (UTC)
    allow, and have always allowed, things like the aggressive promotion of fringe theories or even "dogwhistle" racism, sexism, transphobia, blatant trolling and so on as long as it doesn't trip one of the few red lines they've set is how I'd describe Wikipedia ¯\_(ツ)_/¯ I don't really think that Twitter or Facebook (or any other social media, or reddit, or 4chan, etc.) is any better or worse than Wikipedia, especially not Wikimedia as a whole. I don't have any statistics or way of measuring it, but in my admittedly anecdotal experience, I just don't perceive a difference between the people here, the people on any other social media I've used, and the people out there in "the real world". It's all filled with racism, sexism, -phobias, etc. If anything, I think we're a little bit worse, because we let people vote other people off the website, which gives Wikipedia more of a Lord of the Flies vibe than other sites, IMO...and I say that as a participant in many such votes. It's a YMMV situation I think. Levivich (talk) 04:36, 16 January 2023 (UTC)
    I suspect we're better than those other sites you name. One reason I suspect this is that none of them have published how many of its users feel safe, unlike us. Best, Barkeep49 (talk) 00:48, 17 January 2023 (UTC)
You're not the only one. One of the (many) problems of us only discussing the UCOC in negative RfCs like this one is that we tend not to hear from people who think the UCOC sounds like an okay idea and/or aren't into playing power games with the WMF. That in turn gives the impression that the UCOC is being imposed an an enwiki community that largely opposes it (seemingly taken as writ by many above), which we don't actually have any evidence of. The results of the last vote on the enforcement guidelines (57% in favour) would suggest that a majority are supportive – unless you think enwiki is out of step with the rest of the movement on this, which again we have no evidence of. – Joe (talk) 07:59, 16 January 2023 (UTC)
  • Oppose. I don't think that this sort of top-down approach is workable on a site as large as Wikipedia is. We function, to the extent that we do, because of our collaborative culture, and while a UCoC is something we could benefit from, it is completely unworkable to try and impose or enforce one from above without the consensus of the community. --Aquillion (talk) 04:24, 16 January 2023 (UTC)
  • Regardless of the provenance of the code of conduct, I agree with giving the community the opportunity to support or oppose the enforcement guidelines. Those who wish to oppose based on who approved the code of conduct are free to do so. Those who want to ensure that the enforcement guidelines defer to existing enforcement structures and existing guidelines (as per UCoC violations that happen on a single wiki: Handled by existing enforcement structures according to their existing guidelines..., from the revised enforcement guidelines) have a way to influence the process. isaacl (talk) 04:40, 16 January 2023 (UTC)
  • Oppose acting on them, neutral on actual voting on the EGs - I will join the gang in saying that I don't plan on ever (at least, in my role as an en-wiki admin - and I'm not planning on running for any other position in the next few years!) executing a sanction based on the UCOC here. I opposed the last set of enforcement guidelines, but am probably a weak support for the new set - although they *still* lack sufficient bits on the two aspects of right to be heard (evidentiary access and actually being heard). But while the EGs are much improved (and presumably passed by vote) the reasoning everyone else has given for the original UCOC holds true. I don't accept as a reasoning "you could always oppose the EGs if you don't like the UCOC", because that splits the reasoning with everyone who thinks it's already in place.
The base policy text is unacceptably vague at multiple aspects, unacceptably blurs necessary and desired actions, and imposes a scope that covers every action any of us will take on this planet. It also lacks a sufficiently codified amendment structure. Per Barkeep49 - this technically is a just a community position RfC, with the issues he raises. I suppose we could do another one that would prohibit any on-en-wiki UCOC-based action that doesn't have an underlying (overlying?) en-wiki PAG as well, which could reasonably be viewed as causing quite a lot of conflict for not much practical difference. Nosebagbear (talk) 14:30, 16 January 2023 (UTC)
  • Oppose per all the above. Just because the WMF is intent on imposing this, there is no reason we have to approve it. As has been pointed out, it's so vague anything we do could be an offence, or not, or it could be different based on how we identify, and they could call it anything they want and deal with it however they want. After all, they own the servers. It wasn't meant to be this way.--Wehwalt (talk) 16:46, 16 January 2023 (UTC)
  • I think Barkeep49 has put it in a much better way than I could (see above): In the end this is a non-neutrally worded advisory RfC about a Wikimedia wide advisory vote to the Board who will make an actual vote. Also I'm somewhat skeptic about how to interpret whatever result comes out of this RFC, given there is a community consultation about EG approval via vote, which I'd expect to have higher participation than this RFC. MarioGom (talk) 20:11, 16 January 2023 (UTC)
  • Oppose, per (all) the other opposes. Lectonar (talk) 12:10, 17 January 2023 (UTC)
  • Oppose I have to laugh at the WMF looking to take 'enforcement' action against ENWP users while simultaneously Rebecca MacKinnon (WMF VP, Global Advocacy) is deliberately attempting to interfere in UK legislation that would (potentially) hold tech executives liable for their organisation's misdeeds by mischaracterizing it as an attack on free speech. Only in death does duty end (talk) 13:15, 17 January 2023 (UTC)
  • Support I don't find anything strongly objectionable in the UCOC or the Enforcement Guidelines, nor do I think they will have a significant impact on the way the English Wikipedia is run. Their influence is likely to be stronger on smaller Wikis, giving the WMF more tools to fight institutional capture by bad faith actors. The process was and is imperfect. However, the WMF is holding multiple community-wide ratification votes on these guidelines and has given many clear opportunities for us to be heard over a period of years. They have responded seriously to feedback and made changes as a result. Simply put, I think this is a net benefit for the Wikipedia movement as a whole and probably largely irrelevant to the English Wikipedia specifically. I echo what Barkeep and Levivich have said. —Ganesha811 (talk) 13:32, 18 January 2023 (UTC)
  • Oppose I've seen little effort by the Foundation -- & especially the employees who were driving its adoption -- to discussing why their draft of the UCoC was a good thing. Instead, they engaged in patting themselves on the back for getting the board to adopt it (whom I doubt fully understood the document or how it would be implemented) & how it would be such a good thing. Considering the hostile acts the Foundation have taken against the volunteer communities in the past, I can't support this document without serious reservations & doubts about how it will be applied. One of the features about ruling by consensus is that one has to engage in dialogue with all parties so they know their concerns are heard, & hopefully addressed; there has been little effort by the Foundation to do exactly that. -- llywrch (talk) 21:24, 18 January 2023 (UTC)
  • Oppose even being on the Arbitration Committee and hearing WMF talk about the early parts of the UCOC, I still don't really understand how it is particularly an improvement on the English Wikipedia's current mechanisms, and beyond that the fact that it was foisted upon the community and we're doing all these quasi-democratic showpieces around the thing treated as a fait accompli is beyond insulting, and against the pillars Wikipedia is supposed to operate on. The reality is regardless of what "votes" say about the UCOC, the first high-profile time someone tries to actually sanction someone based on it, we're going to get into a huge pissing contest the likes of the Fram debacle or similar WMF overreach showdowns. If they're so confident in their product, how about the community gets to decide? Der Wohltemperierte Fuchs talk 20:06, 19 January 2023 (UTC)
  • Comment. I have very mixed feelings, and will make a "comment" instead of a support or oppose. It's very clear that the UCoC is going to be implemented and enforced regardless of what editors say here. The UCoC actually has been approved, just not by us. I will also say that I am actually pleased that the enforcement proposal being voted on now has removed, in response to community feedback, the implied requirement that all admins here would have to sign some sort of loyalty oath. So, on the one hand, I, like many other editors above, would like my opinion here to be heard as finding it offensive that the UCoC is being put into effect without clear community support, and that, as such, it feels wrong to ask us to approve its enforcement. But, on the other hand, I think that the proposed enforcement guidelines are as good as we are going to get, and could have been a lot worse. I'm going to say those two things, hope that both messages are heard, and accept that this RfC will be treated as advisory no matter what. And, more likely than not, en-wiki will adjudicate disputes as we choose to do, and when the day comes that we and the WMF disagree, we will have to fight that out regardless of what the WMF will have done with the input they are getting from us here. --Tryptofish (talk) 20:55, 19 January 2023 (UTC)
  • Oppose I think it is quite evident how little regard WMF has for the community, and pushing though the CoC without community vote and then trying to add the associated enforcement guideline only goes to continue the pattern of disregard. It is not clear to me how another layer of rules changes or improves the situation for the enwiki community. We already have plenty of policy, rules, ToS, consensus and enforcement mechanisms as it is, and the complexity of engaging with Wikipedia already drives people away. I have never seen a serious case of disregard for community standards from any established editor, and the community has plenty of ways to police itself. Melmann 20:37, 20 January 2023 (UTC)
  • Oppose This word might be used too often, but this is Orwellian. ~ HAL333 02:40, 21 January 2023 (UTC)
  • Oppose. Nonsensical to discuss how to enforce a policy without first deciding if the policy should be enforced. I plan to propose that we hold an enwiki-only securepoll vote or RfC to determine whether there is a consensus here for either the policy or the enforcement guidelines. BilledMammal (talk) 07:35, 2 February 2023 (UTC)

Discussion: Approval of Enforcement GuidelinesEdit

Note: There was a previous version of this RFC, above, with non-trivial discussion. Pinging previous participants: Joe Roe Certes Andrevan Barkeep49 Isaacl Andreas North8000 Red-tailed hawk FunIsOptional HouseBlaster Alsee (talk) 08:06, 14 January 2023 (UTC)

@Alsee you should have a single neutral RfC question followed by a signature. But right now this RfC has neither. You could after the question then have background and then responses. Best, Barkeep49 (talk) 15:57, 14 January 2023 (UTC)
I think it was poor form to simply discard the responses you received so far and start again. The question posed here is essentially the same as above. – Joe (talk) 07:32, 16 January 2023 (UTC)

I am going to copy my statement from above, given I feel it is still applicable despite the improved RfC format:

As of late, the relationship between the WMF and "the community" has improved drastically (see Wikipedia:Fundraising/2022 banners and Wikipedia:Page Curation/2023 Moderator Tools project). We had the first vote on the enforcement guidelines because we made a politely-worded request. This prompted a detailed response from the BoT, including a commitment that [b]oth the UCoC and the enforcement guidelines (after ratified), will also be open for review and voter-endorsed amendments annually. When we voted last year on the enforcement guidelines, it passed. The board responded by convening a revisions committee to address the concerns of the minority of people who opposed the guidelines, and they changed the UCoC itself based off of similar concerns. They have already shown plenty of good faith. I think an open letter requesting the promised amendment process on the UCoC itself followed by a ratification vote on the entire document is the most productive way forward. One final note: one of the recommendations from the Enforcement Guidelines Revisions Committee was that the UCoC be added to the Terms of Use. A consultation with legal about this (and some other modifications) is scheduled to begin on February 21.

HouseBlastertalk 23:31, 14 January 2023 (UTC)

I am not sure what this vote is about - Ymblanter. I'll try to clarify for anyone unsure what this is about. The issues are (1) the Code of Conduct itself has not been approved by the community, with the predictable result that (2) many people have issues with the contents of the Code of Conduct. It is impossible to "fix" either of those issues by revising the Enforcement Guidelines. The contents of the Enforcement Guidelines are irrelevant here. An "Oppose" vote here presumably indicates an intent to vote against any version of Enforcement Guidelines unless&until we have an approved Code of Conduct. That essentially says to the Foundation that it needs to back up and get an approvable and actually-approved Code first. Alsee (talk) 01:19, 15 January 2023 (UTC)

No. ToU has also never been approved by the community, so what? Ymblanter (talk) 08:30, 15 January 2023 (UTC)

Chris_troutman I suspect your confusion/misunderstanding may be sarcasm, but in case it wasn't: The WMF took charge of producing the Code, the Board accepted it, and neither the WMF nor Board felt there was any need for community approval. I believe(?) it was pressure from various ArbComs that persuaded the WMF to graciously grant us permission to vote on the Enforcement Guidelines. They weren't originally planning on that. Praised-be the WMF, for they have so vastly improved relations and respect for the community as a partner. Oops, I think I just sarcasmed. Alsee (talk) 04:17, 15 January 2023 (UTC)

this removes a requirement for admin to agree to the UCoC at risk of losing their adminship Again with the proviso that I have not looked at this in any real depth, that something like this was included to begin with is, I think, concerning, and makes me even less disposed to approve the guidelines. If anyone thinks that not approving them is misguided because of a lack of understanding/appreciation for the situation, I would appreciate a pointer to the relevant material.Selfstudier (talk) 13:58, 15 January 2023 (UTC)

The first version of the enforcement guidelines included a section stating that all advanced rights holders should be required to affirm [that] they will acknowledge and adhere to the Universal Code of Conduct. There's nothing in there about what would happen if someone refused to affirm it. – Joe (talk) 07:40, 16 January 2023 (UTC)
  • Houseblaster correctly notes that the WMF and the BOT has shown genuine, highly positive steps with their ultimate actions in the fundraising banner dispute. The UCOC issues however, rather significantly predate those. When the WMF finally started discussing ratification for EGs (and they at least were quite clear in those meetings it was the cross-arbcom letter that drove those), they seemed to feel that no-one had raised the desire for ratification on the policy text. When I provided the diff of I and another asking for it during the phase 1 consultations, that particular staffer seemed to ghost me for the remaining discussions - before the WMF just decided to opt for 50%+1 as a ratification margin. No adequate reason has ever been given for why, say, the policy text couldn't undergo ratification attempt alongside the EG's. Nosebagbear (talk) 14:37, 16 January 2023 (UTC)

@Levivich: - continuing this discussion on the effectiveness of Wikipedia's community-based moderation vs. Facebook and Twitter's from-above, since it seems central. Maybe we (or the WMF) should focus on producing those statistics, since we need to understand the problem we're trying to solve. But there's definitely massive volumes of studies on the problems Facebook and (even pre-Musk) Twitter have: [1][2][3] - in comparison, multiple studies have praised Wikipedia's community-based approach - caveat that many of them focus more on content, because that's what we're famous for, but: [4][5][6] Generally speaking, sources that discuss Wikipedia, Twitter, and Facebook's handling of content moderation together describe Wikipedia as a model for getting it right. I think the reason why it feels, anecdotally, like we don't is partially because our community-based system (the "Lord of the Flies" process you mentioned) tends to be loud, especially when dealing with longstanding editors - we just had that a massive incident with Athaenara, say. But that's partially because we do these things out in the open, which IMHO is necessary to catch things that more top-down systems don't and for the moderation system to scale in a way that keeps up with our size. I also think that, as "power-users" who are deep within Wikipedia, we're more familiar with the details of the places where it does fail. My concern is that if we shift to relying more on top-down rules, we'll have less big discussions like that, yes, but that will be because a lot of things slip through the cracks - I think that top-down approaches don't actually work at the scale we operate on. The sometimes riotous discussion is actually necessary for us to consider context and nuance and handle edge-cases that eg. a list of forbidden words wouldn't capture. It's also easier for a blunt top-down system to be abused - yes, sometimes we have issues here where someone is harassed and then snaps and gets in trouble themselves, but at least our processes give us some leeway to observe and understand that context; boomerangs are not uncommon. A more blunt and rigid code of conduct won't necessarily allow for that, leading to victims getting reported and banned by the very people abusing them (not uncommon on Facebook and Twitter.) --Aquillion (talk) 20:09, 16 January 2023 (UTC)

I don't feel that Facebook and Twitter are good comparisons to Wikipedia, because whereas they are explicitly for chatter about anything, Wikipedia discussions must be related to Wikipedia editing and thus ultimately to improve Wikipedia. This provides a central guiding purpose that can be used to filter unrelated discussion. De-centralized enforcement of process can allow for more consideration of context, and that is what the code of conduct enforcement guidelines are proposing: disruption on English Wikipedia will continue to be handled by English Wikipedia's policies and enforcement procedures.
On a side note, the problem with English Wikipedia's decision-making process is that it's a mass, unmoderated conversation amongst everyone, and that doesn't scale well to more than a small number of people. As a result, we don't necessarily get full consideration of context, as a small number of people can dominate discussion and drown out others, leading to attrition in participants. With no bar to participation, it's easy for anyone to chime in without taking time to become familiar with all aspects of the situation. It's also inefficient, taking up the time of a lot of people, and inconsistent, relying on whoever shows up on a given day. Without refinement, it's not a model for social networks to follow. isaacl (talk) 21:46, 16 January 2023 (UTC)
@Aquillion: Yeah, I think as you say because I'm a "power user", I'm more familiar with inner workings, and that's why I beleive "the last great place on the internet" media narrative is more myth than reality--plus, as you mention, they (the studies, the media) focus on content dispute resolution (where I agree we are better than social media), but I'm talking exclusively about conduct dispute resolution (subject of the enforcement guidelines). I don't think there have been many (any?) studies of how well ANI has worked (or AE, or Arbcom, etc.). I freely concede that much of this is very subjective. In the recent massive RFA incident you mention, whether one sees that as a failure or success depends very much on one viewpoint: a block, and an unblock, and a reblock, but not a siteban. It's a glass-half-full-or-half-empty situation.
The thing is, I don't see UCOC and UCOC enforcement as a "top-down" situation, mostly because I see us (the community) as being on top. I fully and always will support the community being the ultimate decider of policy, even though I think we should delegate some day-to-day stuff to paid professionals since we have the money. The enforcement guidleines are coming from the community: multiple votes, plus the drafting committee has community members on it, and the trustees who ultimately approve it are elected by the community. It's our document, written by our people, approved by our people. The UCOC was essentially the same except for the community ratification part. To me, neither document are "top-down" (imposed on us by the WMF).
While I believe professional first-line-of-enforcement would reduce abusive reporting, the UCOC/enforcement guidelines don't do that, and they leave first-line-of-enforcement to enwiki, so in that sense, it's not changing, which means I don't believe that it'll have an effect on abusive reporting. However, I think the possibility for appeal to the U4C (or whatever it's called) would reduce abusive reporting by allowing another level of review, one of the things I like about the enforcement guidelines. Levivich (talk) 22:14, 16 January 2023 (UTC)


  1. ^ Siapera, Eugenia; Viejo-Otero, Paloma (January 22, 2021). "Governing Hate: Facebook and Digital Racism". Television & New Media. 22 (2): 112–130. doi:10.1177/1527476420982232. ISSN 1527-4764.
  2. ^ Matamoros-Fernández, Ariadna (3 June 2017). "Platformed racism: the mediation and circulation of an Australian race-based controversy on Twitter, Facebook and YouTube". Information, Communication & Society. 20 (6): 930–946. doi:10.1080/1369118X.2017.1293130. ISSN 1369-118X.
  3. ^ Matamoros-Fernández, Ariadna; Farkas, Johan (January 22, 2021). "Racism, Hate Speech, and Social Media: A Systematic Review and Critique". Television & New Media. 22 (2): 205–224. doi:10.1177/1527476420982230. ISSN 1527-4764.
  4. ^ Yasseri, Taha; Menczer, Filippo (28 April 2021). "Can the Wikipedia moderation model rescue the social marketplace of ideas?". {{cite journal}}: Cite journal requires |journal= (help)
  5. ^ de Laat, Paul B. (1 June 2012). "Coercion or empowerment? Moderation of content in Wikipedia as 'essentially contested' bureaucratic rules". Ethics and Information Technology. 14 (2): 123–135. doi:10.1007/s10676-012-9289-7. ISSN 1572-8439.
  6. ^ Seidel, Niels (3 July 2019). "Democratic power structures in virtual communities". EuroPLop '19. New York, NY, USA: Association for Computing Machinery: 1–8. doi:10.1145/3361149.3361181. ISBN 978-1-4503-6206-1. {{cite journal}}: Cite journal requires |journal= (help)
  • Note, voting has opened on the UCOC-REG, I've added it to the Watchlist Notice per the precedent of the last notice. — xaosflux Talk 00:58, 17 January 2023 (UTC)
  • After 3 days this RfC has, at the time I write this, attracted 22 participants who've given a topline comment in "responses". After less than 1 day of voting, the official ratification has had 151 participants whose homewiki is English Wikipedia. It appears that there will be a consensus of some kind reached here and it should be respected for what it is. But what it is not is a consensus of people interested in the UCoC on English Wikipedia. Best, Barkeep49 (talk) 15:50, 17 January 2023 (UTC)
    I agree completely. I still tend to think this RfC was created to serve as a fait accompli, and struggle to see how this could be interpreted by WMF in any way other than "micro-consensus". 🌈WaltCip-(talk) 13:33, 19 January 2023 (UTC)
  • Quick question: Isn't there already a mechanism for users to vote on the enforcement guidelines? Why this second vote? Surely, anyone can go vote in the SecurePoll vote and have their voice heard that way. Why are we having a second vote here? --Jayron32 18:43, 19 January 2023 (UTC)
    If I understand correctly, the point of this RfC is to discuss whether the SecurePoll is about the right question. ~ ToBeFree (talk) 20:07, 20 January 2023 (UTC)

RFC - restore "talk" from drop downEdit

Ok, so for me, there's a lot not to like about the new layout.

But someone else can start that eventual RfC : )

I just want to focus on one very specific thing: the talk link being moved to a drop down.

Hiding the talk link is a very very bad idea.

We operate on the consensus model here.

Hiding the talk link just reinforces that edit-warring is the way to go.

And no, I really don't care what some off-site discussion was - so I don't need to hear an WMF employee breezily tell me that a talk page link was determined to not be important on Wikipedia. I'm happy to engage in discussion, but don't blow us off by referring elsewhere as if this project does not matter please. (As an aside, and this goes far beyond this simple RfC - But just thought I'd mention that while I respect the WMF in general - I think it's very important - but I'm really not happy about how things seem to be being pushed through, with fewer and fewer discussions being allowed to be "open" for anyone to participate.)

Anyway, if we weigh importance, I think it's easy to agree that the talk link is more important than the watchlist link. So if space really is the issue argued, then swap them. Or maybe combine "alerts" and "notices" to save space. Or whatever other ideas people may have.

Whatever the case, un-hide the talk link. - jc37 19:30, 19 January 2023 (UTC)

RfC DiscussionEdit

  • @Jc37, I'm not sure what you mean. The talk page link is just below the page title. — Qwerfjkltalk 20:37, 19 January 2023 (UTC)
    I think they mean the link to their own user talk page, which is indeed now in a dropdown (unless you have new talk page messages, in which case it's more prominent like before). Matma Rex talk 21:13, 19 January 2023 (UTC)
    @Matma Rex, I see. But people still get the big yellow notification that they have messages, so I don't see the problem. — Qwerfjkltalk 21:22, 19 January 2023 (UTC)
    anything - anything that reduces the visibility and/or ease of accessing the talk page is a bad idea. We want people to discuss. We want people to respond to talk page concerns about their editing. Not to get frustrated because they can't find the link, and thus not engage. There are innumerable reasons that hiding the talk page link is really bad. Even just from the optics of suggesting that talk pages are uninportant. I understand that this may seem an innocuous change for some, but when I consider years - decades - worth of dispute resolution, among many other things, this just really really seems an incredibly bad idea.- jc37 21:46, 19 January 2023 (UTC)
    @Jc37, so your problem is that people might get talk page message, dismiss that notification, and then not know how to find their user talk page and respond? — Qwerfjkltalk 21:59, 19 January 2023 (UTC)
    One, of several. Anything we can do to get people using talk pages, the better. We've repeatedly seen that initial talk page usage helps bridge the learning curve gap for people to turn into regular editors. It's part of why we encourage the community aspect of Wikipedia. Learning how to thread discussions on a talk page can lead to being confortable to add to lists, to add references, and just merely feeling comfortable to edit a paragraph on a page. These are called "gateways" for a reason. - jc37 22:14, 19 January 2023 (UTC)
    Most newcomers are using the Reply button, so they don't have to count colons any longer. The learning curve is essentially flat.
    The Editing team, as a result of mw:Talk pages consultation 2019, considered ways to make talk pages more visible, but it's tricky, and I don't think that they got very far. You don't want the "Talk" tab at the top to be more prominent than the article tab. You also don't want it to be more prominent than the Edit button. So at best, it's in third place. In terms of your own User_talk: page specifically, I think that Growth's Newcomer homepage work has made some difference there. Whatamidoing (WMF) (talk) 23:37, 19 January 2023 (UTC)
    I appreciate all that. I do. But all I need do is look at the default signature for editors to see that Wikipedia sees the value of a talk page link. (And yes, I'm aware that mine isn't there - user pages are important too : )
    But anyway, if it's in third place, then watchlists decidedly aren't. And while I may have done some looking around to find out the difference between notices and alerts, I doubt the average person would know, or care.
    tried and failed doesn't = push through anyway. I understand the idea of the perfect is the enemy of the good - Wikipedia is a work in progress after all. but something like this is different, we're being asked to swallow the watermelon whole, with no changebacks allwed due to fait accompli." what's done is done" and all that.
    I'm not merely complaining to the air, I've actually proposed some suggestions and welcome others. (not adding "support/oppose" sections was intentional). So if you have any ideas for a way forward, I'd be happy to hear them. - jc37 23:54, 19 January 2023 (UTC)
    I don't think that I want to get in the middle of whether the talk page or the watchlist is the more important thing to show. I imagine that most editors want both.
    But now I'm not sure that we're talking about the same thing. At the top of an article, volunteer-me sees these options:
    Article – Talk – Read – Edit – Edit source – View history – Watchlist star – More menu – Twinkle menu
    This is what I see in the new Vector 2022. Are you seeing something different? Are you not seeing the "Talk" item right next to "Article"? Whatamidoing (WMF) (talk) 21:45, 20 January 2023 (UTC)
    @Whatamidoing: I think Jc37 is referring to one's personal user talk page ( ), which is in the dropdown menu for  , rather than a page's talk page ( ). —Tenryuu 🐲 ( 💬 • 📝 ) 22:30, 20 January 2023 (UTC)
    You also don't want it to be more prominent than the Edit button. Yes I do. Levivich (talk) 16:54, 21 January 2023 (UTC)
    I think that in the end, anything that improves or makes more efficient the talk page in a non-obnoxious manner should be implemented. In particular, I believe that the talk page is one of the biggest catalysts for recruiting new editors, and if they see a place where not only their voice matters but they can participate in a discussion with consequences they can see, I think we've done a good job at recruiting a new editor. Put another way, to know that the change you helped to support 10 years ago can still be found on the website is, for lack of a better term, a magical feeling. InvadingInvader (userpage, talk) 21:46, 31 January 2023 (UTC)
    Very few editors make their first edit on a talk page. Whatamidoing (WMF) (talk) 01:11, 1 February 2023 (UTC)
  • Let editors have the option to unhide the Contributions link, too. Some1 (talk) 01:32, 20 January 2023 (UTC)
    @Some1 and @Anarchyte - see Wikipedia:Village_pump_(technical)#Customizing_button_shortcuts_in_top-right_menu_area? for a userscript an editor can use to add contributions to the page top. — xaosflux Talk 01:03, 21 January 2023 (UTC)
    The userscript is better than nothing I guess, thanks xaosflux! Some1 (talk) 01:14, 21 January 2023 (UTC)
  • Support - adding the ability to choose which buttons appear outside of the user dropdown menu would be a drastic improvement. Anarchyte (talk) 08:08, 20 January 2023 (UTC)
  • This RFC is a bit misleading in the title, "Talk" in general is not in any menu, this is only about the link to someone's own usertalk page. This is also something that is skin-wide, so would really need to be changed upstream. I don't see this as severely breaking the consensus building model, as most consensus building discussions don't take place on personal user talks, but on article talks or project pages, both of which are already accessible. — xaosflux Talk 12:32, 21 January 2023 (UTC)
    The title is: "restore "talk" from drop down" - that is exactly what this is about. the talk link in the drop down. Nothing there misleading at all. - jc37 08:32, 22 January 2023 (UTC)
  • Support: There is a huge gap between search box and "CX Zoom" at the top, which could've been utilised in better ways. Talk pages should absolutely be visible on up there in order to assist new editors find a link to there. CX Zoom[he/him] (let's talk • {CX}) 16:17, 21 January 2023 (UTC)
    This is exactly what I was saying about the "log in" button for unregistered users. Whether logged in or not, the WMF seems intent on wasting that space and forcing us to live with it. —pythoncoder (talk | contribs) 17:56, 1 February 2023 (UTC)
  • Support, per CX Zoom. Also support restoring a link to an editors contributions. BilledMammal (talk) 07:38, 2 February 2023 (UTC)

Display assessments on inactive wikiproject bannersEdit

Background for assessments on inactive wikiproject bannersEdit

A wikiproject is considered inactive if there has been no significant activity for three months. The wikiproject templates that appear on talk pages of associated articles are often changed to invoke {{WPBannerMeta/inactive}} instead of {{WPBannerMeta}}. This has the effect of suppressing display of the quality ratings. Instead of a banner like:

the wikiproject template now displays a message like:

The template no longer assigns the article talk page to assessment categories for the project. This was discussed at some length at Wikipedia:Village pump (miscellaneous)/Archive 73#Improper handling of assessment for inactive WikiProjects, with general agreement that there was no reason to suppress quality and importance assessments because the project was not particularly active.

Proposal about assessments on inactive wikiproject bannersEdit

This is to propose:

  • Modify {{WPBannerMeta}} to accept an |inactive=y parameter, and if present note that the project is inactive, but display assessments in the same way as active projects
  • Modify {{WPBannerMeta/inactive}} to invoke {{WPBannerMeta}} passing all the standard parameters plus the |inactive=y parameter

Note that the inactive project categories like Category:Start-Class Ruritania articles and Category:Low-importance Ruritania articles may have been deleted after they became empty, so will have to be restored. There are about 340 inactive projects, so this will take some effort, and possibly could be partially mechanized. Aymatth2 (talk) 15:14, 22 January 2023 (UTC)

Discussion about assessments on inactive wikiproject bannersEdit

Comments? Aymatth2 (talk) 15:13, 22 January 2023 (UTC)

  • Support. To clarify from previous discussions, the assessments are not just suppressed (hidden), the are detached and no longer included in the total assessment scheme for articles that have only inactive project banners (example: Talk:Ork (Warhammer 40,000), within the scope of defunct WH project and without any active WP project banners, was rated as start, but now is considered unassessed). Piotr Konieczny aka Prokonsul Piotrus| reply here 17:42, 22 January 2023 (UTC)
  • Partial support per my reasoning on Wikipedia:Village pump (miscellaneous). I support the display of the quality assessment on the template. But I do not support the recreation of hundreds of categories deleted over many years. I have put some code on Template:Inactive WikiProject banner/sandbox which will display the class rating and also repopulate the PageAssessments database, which will mean that most of the tools should work correctly. — Martin (MSGJ · talk) 20:36, 22 January 2023 (UTC)
*Oppose. This strikes me as a waste of time. Just because there hasn't been a recorded action by a project for three months, doesn't mean that the assessments need to be, well, assessed differently. If they were valid when they were posted, they are very likely valid now, and someone could come along any time and renew activity at the particular project. If the assessments strike someone as needing to be revised, then revise them, but that doesn't require changing the template content in that way. We should be making it easy for projects that have temporarily gone quiet to become active again, not rush to sweep them out the door. --Tryptofish (talk) 22:58, 22 January 2023 (UTC)
@Tryptofish, I read the proposal as doing what you suggest, and don't understand why you oppose. —Kusma (talk) 23:10, 22 January 2023 (UTC)
You're right, and I struck what I said. I misread it. Sorry for my mistake. --Tryptofish (talk) 23:12, 22 January 2023 (UTC)
  • Support per what I should have understood from the start.   --Tryptofish (talk) 23:12, 22 January 2023 (UTC)
  • Support making assessments independent of project activity. Ideally assessment should not be connected to WikiProjects at all, but we certainly should not delete the working infrastructure just because a project seems dormant. —Kusma (talk) 23:08, 22 January 2023 (UTC)
  • Weak oppose, I guess. The inactive project banners give the impression that the project assessments are not being maintained because the associated project is inactive and have therefore been deactivated. This is silly, as normally, quality assessment and other banner flagging (such as needing infoboxes or images) is updated for all project banners by an editor who usually has nothing to do with any of them, and often this editor will make the importance assessment too, even though they're usually just guessing based on what the article says about its topic. With a couple of exceptions, such as WP:MILHIST's A-class reviews, messing with the project banners is not a project-related activity. Consequently, WP banners for inactive projects are pretty much redundant, unless the goal is to use the inactive projects' banners as a proxy for "Article condition by topic" categories, in which case I think the correct way to move forward is re-open that functionally fully and retire {{WPBannerMeta/inactive}}. Compassionate727 (T·C) 04:24, 23 January 2023 (UTC)
    We could convert project templates that use {{WPBannerMeta/inactive}} to instead use {{WPBannerMeta|inactive=y}}. But the main assumption is that if an article has been assessed, there is no reason to drop the quality and/or importance assessment when the project goes inactive. I imagine some projects sporadically become inactive and later become active again. If a project is deleted, that is a different question. Aymatth2 (talk) 15:08, 23 January 2023 (UTC)
    Unless the parallel discussion on VPI is successful :) — Martin (MSGJ · talk) 15:18, 23 January 2023 (UTC)
    As someone who does a fair number of quality assessments, I don't really treat it as a Wikiproject activity. And since all the projects mostly use the same scale, I'd support just creating a global assessment system (with importance remaining within WikiProjects' domain). —pythoncoder (talk | contribs) 02:50, 24 January 2023 (UTC)
    @Pythoncoder that is exactly what we are discussing at Wikipedia:Village pump (idea lab)#Project-independent quality assessments. If that passes this whole proposal is moot — Martin (MSGJ · talk) 12:38, 25 January 2023 (UTC)
    Not really because importance parameters still continue to exist for most projects. And no proposal has been floated to deprecate them yet. CX Zoom[he/him] (let's talk • {CX}) 18:24, 25 January 2023 (UTC)
    A rating for how important an article is to an inactive/defunct project? That would be absolutely useless information, unless the project is revived — Martin (MSGJ · talk) 19:28, 25 January 2023 (UTC)
    @Compassionate727 I am not sure I understand why you oppose this? For me, per the reasons explained at the Wikipedia:Village pump (miscellaneous)/Archive 73#Improper_handling_of_assessment_for_inactive_WikiProjects, one of the main issues is that the current way we are doing so consings numerous, perfectly fine assessments, to oblivion, as soon as a project is declared inactive. For articles for which this was the only banner present, those assessments become removed from the assessment scheme and the the page will now show as unassessed in the assessment scheme (see links in my comment a bit above). Any solution to fix this glaring error is a step in the right direction, no? Piotr Konieczny aka Prokonsul Piotrus| reply here 04:50, 25 January 2023 (UTC)
Weak support, but the third banner is my personal favorite as it both addresses the presence of the WikiProject and preserves its older ratings. It would be nice, however, to see when the WikiProject was declared inactive. InvadingInvader (userpage, talk) 21:49, 31 January 2023 (UTC)

In an attempt to find how many articles may be left unassessed due to inactive project banners I have created a tracking category Category:Articles possibly without an active WikiProject. It might take a few days to populate and then we'll see what there is — Martin (MSGJ · talk) 21:03, 25 January 2023 (UTC)

@MSGJ: I think it includes articles with an active project but not assessed. E.g. Talk:9th Annual BFJA Awards- Aymatth2 (talk) 16:56, 28 January 2023 (UTC)
It's only looking for banners of the form {{WikiProject... - a rather crude search with many false positives. Probably not worth keeping unless I can improve the regex — Martin (MSGJ · talk) 20:49, 28 January 2023 (UTC)
  • Support, assessing is a lost art, and mostly ignored even in active WikiProjects. Abductive (reasoning) 08:44, 29 January 2023 (UTC)
  • Support. Just like Abductive, I've seen plenty of active WikiProjects where the assessments are woefully out of date. People tend to remove assessments from talk pages for projects with inactive banners; but let's say I want to revive a WikiProject, or turn it into a task force; do I now need to manually reassess thousands of articles? It's silly. DFlhb (talk) 09:23, 29 January 2023 (UTC)
    People remove assessments from talk pages for projects with inactive banners? I've not seen this, and I'm not sure why anyone would do this. CMD (talk) 18:24, 31 January 2023 (UTC)
  • Comment. It is often the case that members of a wikiproject make edits and improvements in the filed covered by the wikiproject, but whatever method the person who decides to mark it inactive uses to detect activity does not notice these edits and improvements. Thus the inactivity marker is wrong. Jc3s5h (talk) 18:41, 31 January 2023 (UTC)

Font size of the show/hide buttons in Template:Collapse and Template:Collapse topEdit

I'd like to increase the font size of the [show]/[hide] buttons in Template:Collapse and Template:Collapse top to the same size as their title text. It is currently smaller than usual, which also causes it to be vertically misaligned. I filed an edit request first but folks thought this required discussion.

For reference, the templates:

Collapse top

Matma Rex talk 09:46, 24 January 2023 (UTC)

@Matma Rex they look vertically aligned to me, how are they off? — xaosflux Talk 11:19, 24 January 2023 (UTC)
@Xaosflux On my screen there is significantly more space below the buttons than above them: Matma Rex talk 11:32, 24 January 2023 (UTC)
@Matma Rex it looks like there isn't an equal size above and below the text line in the entire horizontal element, notice more space under the letters than above them here - are you sure this a font-size issue and not the 2em manual padding that is only on the top of the block? — xaosflux Talk 14:59, 24 January 2023 (UTC)
@Xaosflux I mean… you're saying that there are other ways to adjust this, and I don't disagree, but this is the one I like the most. Matma Rex talk 15:22, 24 January 2023 (UTC)
@Matma Rex no I was suggesting that the entire text line is not vertically aligned in the box, regardless of the font size - the 100% size text is also not vertically aligned. — xaosflux Talk 15:26, 24 January 2023 (UTC)
I don't see a vertical difference in Vector 2010 in my browser. Is this skin-dependent? Does it happen only in the beta Vector 2022 skin, which is still going through various tweaks to fix font sizes, white space, and other significant display bugs? The font sizes in these templates have been the same for at least seven years, maybe more than twelve years, and the templates are used on more than 50,000 pages, so any changes should be for a good reason. I welcome details on the conditions under which this misalignment happens, and changes in the sandbox along with testcases that show better alignment using the same font sizes. – Jonesey95 (talk) 15:32, 24 January 2023 (UTC)
I think it depends on what you're looking at. If you look at phab:F36487116, you can see that the baseline of the "Collapse" title and the square brackets are aligned, but the baseline of the word "show" is elevated. The tops all look vertically aligned. Whatamidoing (WMF) (talk) 23:16, 24 January 2023 (UTC)
Thanks for the detailed screen shot. This shows that the outer brackets appear to be on the same line as the "Collapse" title, which makes sense, and that the word "show" is centered within the brackets, which also makes sense. – Jonesey95 (talk) 05:26, 26 January 2023 (UTC)

Borgward on Boarisch WikipediaEdit

Hi dear Wikipedia users and admins!

I have a request. I want from someone to create Borgward article on Boarisch (Bavarian) Wikipedia Borgward. It has been created many times there, but it was deleted with unspecific reasons. I would like to see this article there, so anyone who understand this language and requests the article to be kept there and not to be deleted anymore, please do it for me.

Thanks (talk) 22:14, 27 January 2023 (UTC)

Please note that the various language versions of Wikipedia are independent projects. Each has unique rules about what is and is not accepted as an article. We here at the English version have no say over what is accepted at the German version. In other words, you are complaining at the wrong place. We can not help you. Blueboar (talk) 22:24, 27 January 2023 (UTC)
While what Blueboar said is true, I want to make it clear that "but it was deleted with unspecific reasons" was misleading. The article was removed as it was a problematic machine translation from an article on one of the different versions of Wikipedia. For the English Wikipedia, there is a policy called WP:MACHINETRANSLATION that explains the problems with articles that are machine translated into English. I would say that the German Wikipedia likely has an comparable policy. --Super Goku V (talk) 17:05, 29 January 2023 (UTC)

Migrating inline references to a separate 'References' spaceEdit

It would be very beneficial to editors if inline references could be migrated to a separate 'References' space (possibly for storage in WikiData). Here's a few benefits:

  • Frequent bot edits of references would no longer choke up our watchlist and bury potential vandalism.
  • Edits of an article wouldn't be hampered by masses of inline references, making the job of editing text more difficult. All there would be are standardized reference identifier tags, possibly with modifiers such as page ranges.
  • There would be no need to edit the entire article to add a named reference at the bottom. That would reduce the number of edit collisions.
  • Reference edits could be converted to an input form, rather than requiring arcane knowledge of various templates.
  • Article reference format could be unified by a single format control at the top, much like the date format is now.
  • A large existing Wikipedia library of references would allow convenient re-use, rather than needing to copy a reference over and over.

Just some thoughts. Praemonitus (talk) 17:34, 29 January 2023 (UTC)

Most of the above may be implemented now at the discretion of editors. There is WP:LDR, WP:NAMEDREFS and WP:SFN that cover issues raised above. Visual editing tools also help. The idea that Wikipedia references could be valid Wikidata or data in a Wikipedia Library is a non-starter. Wikipedia references are not formally validated for reliability, contextual integrity or accuracy (occasional informal checks by concerned editors are hardly sufficient). Until such happens as a standard part of referencing/article submission, they are as unreliable as the rest of Wikipedia or Wikidata.
However I agree that edits (including, and especially structured edits such as some of the Wikipedia short and full citation methods) could be best represented by data-input forms. That is however another discussion. (talk) 18:00, 29 January 2023 (UTC)
I already use many of those methods, so I don't see them as a complete solution. But I'm fine with not using WikiData; just have them on a separate page for parallel editing. Praemonitus (talk) 18:54, 29 January 2023 (UTC)
Inline references are generally superior because they don't get out of sync with a separated section as the article is edited. Moving references to Wikidata is a terrible idea - we rely on these citations to meet our core policy burdens, they need to be in the article and a part of the article's editing history. Exporting that to a separate project where they can be separately changed (or vandalized) will cause many problems. MrOllie (talk) 18:26, 29 January 2023 (UTC)
Inline references tend to gum up the works when you want to edit the text. I only find them acceptable in low usage and at the end of paragraphs. Praemonitus (talk) 18:52, 29 January 2023 (UTC)
This is great in theory (I use BibTeX in the real world) but no good on Wikipedia in practice. We used to have {{cite doi}} with citation data stored in subpages but that system was deprecated, and there is a lot of opposition to the Wikidata version {{cite Q}}. Better to keep critical information like citations in the article. —Kusma (talk) 18:48, 29 January 2023 (UTC)
  • "There would be no need to edit the entire article to add a named reference at the bottom. That would reduce the number of edit collisions." is wrong. Migrating references to a different location means any additions need two edits, one at the location where the reference is used, and one at the external reflist, doubling the potential chances of "collisions". Regarding your issues regarding wikitext confusion, have you tried using WP:VISUALEDITOR? CMD (talk) 18:08, 31 January 2023 (UTC)

Make "Always give me the visual editor if possible" default for new editorsEdit

Yesterday I helped someone to start editing in Wikipedia. Creating an account is a breeze, but when he started editing he is presented with the text editor, instead of the Visual Editor. Text Editor is good and have its uses, but for newer editor it is better to present them with Visual Editor, as it is created to be user friendly and really show changes that you intended. Editing through Text Editor for newer editor may be off putting, as many may just want to do minor changes (maybe add a single line in a table, change the number of things, etc.) and "learning" the wiki markup may be too much for them.

I understand that changing it in Preferences is trivial for many of us, but for many new editors this can be quite hard. This can be changed easily by making "Always give me the visual editor if possible" default. ✠ SunDawn ✠ (contact) 03:03, 31 January 2023 (UTC)

  • Strong support, as in "this could be one of the most important changes Wikipedia makes" support. To a new user, the wikitext editor is terrifying and bloated. To an experienced user, it can still be bloated. I'm fairly competent with wikitext, but I still use the visual editor for most purposes simply because the wikitext editor is too much to wade through unless you're making a really technical edit. I genuinely think Wikipedia would have a much larger user base contributing if the visual editor was the default. Thebiguglyalien (talk) 03:56, 31 January 2023 (UTC)
  • According to Wikipedia:VisualEditor this is already the case. CMD (talk) 03:57, 31 January 2023 (UTC)
    For an IP editor, the default is the wikitext editor, but it gives a pop up asking if you want to switch to the visual editor, which I imagine is meaningless to most users. I suppose it's not quite the same thing as a new account (and SunDawn might want to look into it to see where the discrepancy is), but visual editor definitely needs to be more accessible. Thebiguglyalien (talk) 05:20, 31 January 2023 (UTC)
  • Strong oppose. The WMF has been persistently and attempting to force this, despite the fact that they have data showing that defaulting into VisualEditor is harmful. There of course are some people who prefer VE, but the objective data shows the overal impact is negative. The WMF has been resistant to collecting good data on this, but I can report what we do have. If you examine the graph at the right, you'll find that the Desktop Wikitext Editor has approximately DOUBLE the retention rate as Desktop Visual Editor, and that Mobile Wikitext also has about DOUBLE the retention rate as Mobile Visual Editor. That is a pretty staggering difference. From the published graph we cannot tell whether Visual Editor is causing half of editors to quit editing entirely, or whether users given VE-by-default merely abandon VE to use the Wikitext editor instead, or more likely some mix of both. Regardless, the data is extremely damning.

    Nearly 4 years ago they started work on a mobile-default test. They still have not released any results, however if you dig through the comments of various related tasks it is clear that the results were a disaster for VE. A VE-default on mobile was clearly driving away a significant percentage of edits, and possibly driving away editors. They have been working off-and-on repeatedly shifting the goalposts on that project, trying to get better results. Nearly 4 years, and they still haven't released actual data.

    Important final note: Never believe any claimed "Edit Completion Rate" data. The raw data for VE is so bad that the WMF concocted this specific term and defined it in such a way as to inflate the apparent success of VE. The "Edit Completion Rate" is defined such that every Wikitext-activation that does not result in a saved edit counts as a "failed edit", but a substantial portion of equivalent VE "failed edits" are simply discarded from the dataset and ignored. That artificially inflates the claimed "VE-success" percentage.

    When the VE project was first conceived the WMF internally hyped it as so insanely-awesome that pur biggest problem would be handling the overwhelming flood of new users. The WMF diverted an absolutely excessive percentage of all development time&dollars on this agenda (VE itself, Flow, replacing the translation-editor, attempting to eliminate our wikitext editor in favor of a wikitext mode inside VE, ongoing work to replace our wikitext engine, and various other work). People's paycheck was literally dependent on producing positive results. It resulted in an almost cult-like level of confirmation bias, internally cheerleading and wildly hyping anything that could remotely be interpreted as positive for VE while all unfavorable information and data vanishes down the Memory hole. Nearly 4 years researching VE-on-mobile and we still don't have any published results. I have asked the WMF to preform equivalent research getting solid data on the effect of a VE-default on desktop, but no-go. The retention graph I posted is the best we've got, and that's ambiguous whether VE actively drives new users away or whether it "merely" drives users to flee to Wikitext instead. Alsee (talk) 12:34, 31 January 2023 (UTC) (Some vote timestamps are out of order due to auto-resolved edit conflict.)

    I don't agree with your assessment of the data shown in the graph. The caption reads, emphasis added: This includes all logged-in users who made an edit at any time, on any wiki, between October 2017 and March 2018, regardless of the number of edits made before the study started. This graph does not show overall retention rates for new accounts. Edits in four editing environments were measured: the 2010 WikiEditor, VisualEditor's visual mode, the MobileFrontEnd wikitext editor, and the MobileFrontEnd visual editor. It excludes all edits using VisualEditor's 2017 wikitext mode, [...] All manual "Undo" actions are counted as "using" the 2010 WikiEditor. Users who used multiple editing environments are counted separately for each editing environment. Therefore, each user can appear up to four times in this graph. If a primary user of VisualEditor uses the undo button frequently, then they are counted as a "retained" user of the 2010 WikiEditor. 0xDeadbeef→∞ (talk to me) 12:44, 31 January 2023 (UTC)
    I agree that the available data isn't exactly the data we need. I said it's the best available data, and that it's pretty damning. The result was disastrous when they tried collecting data for VE-on-mobile. How about we agree that we shouldn't be making such a critical change like this unless-and-until we actually do collect data on what effect changing the desktop default has? I have requested the WMF collect this data, and they declined. I'm all for a formal community request that the WMF do a proper test on this. Alsee (talk) 12:55, 31 January 2023 (UTC)
    "How about we agree that we shouldn't be making such a critical change like this unless-and-until we actually do collect data" If the situation we're complaining about wasn't justified with data, why should a change to it require that justification? Is the current situation (that in effect, new editors get locked into VE or wikitext almost at random) even the result of a consensus? MartinPoulter (talk) 13:13, 31 January 2023 (UTC)
    I just realized - this isn't even a proposal to change the default editor. This is vastly worse. This is actually a proposal to move away from the "remember my last editor". People who actively choose to use the Wikitext editor would get screwed waiting for VE-to-load and then switch to wikitext on EVERY edit, unless/until the locate preference item to fix this. I likely would have quit editing before I discovered there was a way to fix it. Alsee (talk) 13:07, 31 January 2023 (UTC)
    The problem is not for prominent editors like you or me - but for newer editors. Experienced editors have the knowledge and the time to go to their own Preferences (which took less than a minute) but newer editor, in my opinion, will immediately be confused by the text editor and stopped contributing. They don't know that Wikipedia have a very user-friendly UI at VisualEditor. They will think that the only way to edit is through this confusing text editor. ✠ SunDawn ✠ (contact) 15:45, 31 January 2023 (UTC)
  • Support. I'm not sure why, but during a recent edit-a-thon at least one new logged-in editor was unable to use VisualEditor, and it us 5 minutes in Preferences to show both editing tabs. VE is easier for beginners. Femke (alt) (talk) 12:18, 31 January 2023 (UTC)
  • Strong support. This is a solid way to make Wikipedia user-friendly and increase the pool of willing contributors. DFlhb (talk) 12:23, 31 January 2023 (UTC)
  • Strong support. Visual editor is the more friendly option for new editors, so we should enable it by default. 0xDeadbeef→∞ (talk to me) 12:34, 31 January 2023 (UTC)
  • Support Despite some long-term attempts to continue forcing wikitext on new editors, it is extremely clear that VE is the more welcoming and easy to understand editing environment. I use it more often than wikitext when editing articles, and have not once in recent years considered wikitext an improvement when trying to explain how to edit to a new editor. Sam Walton (talk) 12:47, 31 January 2023 (UTC)
  • Strong Support I also have been recently running training events for new editors and am having the same problem that it is very easy for them to get locked into the wikitext editor without realising that the visual editor is an option. Fixing that involves taking them to their preferences and is a speed-bump on the whole training process. That's with in-person training; it's exponentially harder to fix this when training remotely. It shouldn't be so hard for new users to access something which has been created to make the experience easier for them. MartinPoulter (talk) 13:04, 31 January 2023 (UTC)
  • Whoa. Why not give them VA as the editor on their first edit, but "Remember my last editor" as the default? Why force them back to VE even after they have switched to edit with wikitext? If they found the switch once, they will find it in the opposite direction as well if and when they want it. Fram (talk) 13:34, 31 January 2023 (UTC)
    I do agree with this. It didn't break "last editor used" but it provided a good interface for new editors. ✠ SunDawn ✠ (contact) 15:55, 31 January 2023 (UTC)
  • Strong oppose: Alsee has articulated this much better than I could've, so there's that, but I'll add extra. Ever wondered why we teach young kids do addition/subtraction when we all have calculators today (smartphone ones included)? The problem with Visual editor is that it is not univerally compatible to all pages, try editing the tables at United States congressional delegations from New York, for example. To edit them, you need advanced knowledge of wikitext. And to gain that advanced knowledge, you need to gain basic knowledge first, which is gained by editing normal prose. And that isn't hard. My first Wikipedia edit was made when I was in 1st grade (≈6 year old) as an IP. I could understand the wikitext logic and implement it to write prose and construct wikilinks. Is the next generation going to be dumber? No one is taught wikitext syntax in schools or colleges, people learnt it as they edited Wikipedia and that has kept the site running smoothly for about two decades. When we default to VE, and people may start using it for basic editing, they fail to acquaint themselves with the wikitext logic, which will hurt them make complicated edits where visual editor fails. Even today, most complicated templates/modules are maintained by a few old guards who familiarised themselves with wikitext/lua, a level of familiarisation which the newer generation of editors has probably not achieved. No one here will be here forever, and newer editors should be encouraged to use wikitext, rather than be served with VE on a silver platter. I know this is a controversial opinion of mine and will probable lose at the end, but I genuinely consider it to be detrimental to the future of the project. CX Zoom[he/him] (let's talk • {CX}) 13:48, 31 January 2023 (UTC)
    The way I see it, if editors didn't understand wikitext, that is still fine by me - as long as they are able to edit constructively. In my case, my friend just want to add a single information. Forcing him to "learn" wikitext took time, as he will have to read about how to cite properly in wikitext, find the "location" he wanted to edit in the middle of the jumbled things he didn't understand, and so on. While if he got VE, he could just see it, use the cite button, let Wikipedia handle the citing, and he is finished. There are many other scenario. Someone stumbling into a typo on an article can fix it easily if he use VE, while if he see the complexity of text editor, he may be afraid that he broke something then he did nothing. In short, for most editors, I didn't think the knowledge of text editor is necessary. If they are interesting in doing more for Wikipedia, they will learn that text editor offered more, and learn. But if they just want to fix small mistakes and add small bits of information, that should be fine as well. ✠ SunDawn ✠ (contact) 15:54, 31 January 2023 (UTC)
    This sounds like an argument to import the cite button into the wikitext editor. CMD (talk) 17:54, 31 January 2023 (UTC)
  • Conditional Oppose if this is going to end up breaking the "remember my last editor" option - users should get a consistent experience. — xaosflux Talk 14:50, 31 January 2023 (UTC)
    Let's say we use Fram's input - keep the "remember last editor" while change the default editor for newer editor to VE, would you reconsider your position? My objective is not break the current "remember last editor", but to make VE default for newer editor. ✠ SunDawn ✠ (contact) 15:59, 31 January 2023 (UTC)
    @SunDawn: I marked that as conditional. I haven't created a brand-new account just to test this, but if I recall correctly the the current default is "Ask me what I want to use" with a big pop up box, isn't it? — xaosflux Talk 16:55, 31 January 2023 (UTC)
    Good question. Does anyone know the current default? I assumed it was wikitext. If it's a pop-up box then I'll change to oppose because a choice is better for editors who can handle wikitext and raises awareness of the "real" editor for newbies. Certes (talk) 17:24, 31 January 2023 (UTC)
    The current default for IPs appears to be the wikitext editor covered by a large "Welcome to Wikipedia" banner which has a "Switch to the visual editor" button and a "Start editing" button. If this is also the case for new editors, then Wikipedia:VisualEditor is wrong and this list is misleading or bugged. CMD (talk) 17:58, 31 January 2023 (UTC)
    That's what I recall seeing when making my first logged-in edit on other wikis. If it's also true for enwp, perhaps all we need do is reword the buttons to something more equal like "Edit using Visual Editor" and "Edit as wikitext". One of the buttons is highlighted by default; we may want that to be VE rather than Wikitext. Certes (talk) 18:35, 31 January 2023 (UTC)
    The way I recall it (when assisting someone new editing) is that they are immediately represented by text editor. The "edit" beside the heading is "edit source", and he is immediately taken to to the text editor. I didn't recall him given the option between VE and text editor. Of course, the sure way to know is to create another account to test it by ourselves. ✠ SunDawn ✠ (contact) 04:49, 1 February 2023 (UTC)
    Whether you see one tab or two, and if you see one, which one you see, depends on your prefs settings. Whatamidoing (WMF) (talk) 17:57, 2 February 2023 (UTC)
  • Conditional support, only if editors are prominently offered a simple and persistent way to opt out of VE. Certes (talk) 16:19, 31 January 2023 (UTC) It's complicated: see my comment above. Certes (talk) 18:38, 31 January 2023 (UTC)
  • Comment By adding an obscuring layer which is obscure itself, I suspect that visual editor does more harm than good for about 90% of editors. But it might be a good default for the 10% which is those who are just starting.North8000 (talk) 17:58, 31 January 2023 (UTC)
  • Strong oppose. Even on fast machines, the visual editor has a very perceptible lag. If you want to encourage people to continue editing, that is going to be a negative. --Trovatore (talk) 18:01, 31 January 2023 (UTC)
    @Trovatore I've not seen any "very perceptible lag" with VE recently on my machines - when do you experience it? Sam Walton (talk) 18:18, 31 January 2023 (UTC)
    To be fair, I'm probably thinking of "realtime preview". But it would be surprising if VE were less laggy than that. Is it? --Trovatore (talk) 18:23, 31 January 2023 (UTC)
    @Trovatore Realtime preview is a niche feature that new editors probably won't use, and it has to be laggy by design, as I understand it. Rendering wikitext into a preview takes time so it can't happen instantly. There needs to be some delay between the preview updates. VE itself, in terms of actually editing articles, is almost completely lag-free for me. Sam Walton (talk) 18:32, 31 January 2023 (UTC)
    OK, withdrawn. It looks like I misunderstood the proposal anyway. --Trovatore (talk) 19:57, 31 January 2023 (UTC)
  • Generally support - But this thread is already a bit confusing. It would help to revise the top part to state clearly what the current situation is and what specifically would change. VE is already the default for new users AFAIK, as it should be. As I understand it, this would address a specific issue: people switching to the wikicode editor and not understanding how to get back. If my understanding is correct, I definitely support it. Alternatively, we could replace the unclear toggle button that nobody ever thinks to click with a bright line that says "GET ME BACK TO VISUAL EDITING MODE" unless you disable that in prefs. My engagement with new users has largely been through edit-a-thons and university classes. When I started with those activities, wikicode was still the standard. VE existed, but wasn't very good yet, and I had everyone working in wikicode. It was fine, and I still use wikicode most of the time. At some point some years back, though, VE got good. Using VE during events/classes was -- and I don't like using this term -- a game-changer. It presented a learning curve that took time to get over, and people used to just run away from editing and/or never really got comfortable. Using VE means newbies can get right into editing and spent their learning time focused on things like wikipolicy, citations, style, etc. rather than syntax. Sure, we still talk about wikicode for talk pages, but with the reply tool, even that's less needed. In short, moving newbies away from wikicode has been an incredible boon for new user engagement in my experience, and now one of the most frequent questions I get is "I think I did something wrong; how do I get back to what we used before" when people accidentally find themselves in the wikicode editor. — Rhododendrites talk \\ 18:02, 31 January 2023 (UTC)
    Last I checked, when an IP makes their first edit, they are taken to the source editor and then get a dialog box asking if they want to switch to the visual editor. Has this changed? —pythoncoder (talk | contribs) 18:00, 1 February 2023 (UTC)
. Comment I would support a far clearer way of switching between the two. When I first started I found VE couldn't do what I was try to do, switch to wikicode and never looked back. However a couple of times I mistakenly switched back to VE, and had to spend 10 minutes trying to work out how to switch back. Hiding the option behind a very unclear toggle is bad UI design. Having a large "back to VE" would be a bad idea, as any IP editor using wikicode wouldn't be able to get rid of it using preferences. -- LCU ActivelyDisinterested transmissions °co-ords° 18:36, 31 January 2023 (UTC)
I'm slightly unsure about what's being discussed here. As far as I'm aware VE is the default, yet editors are supporting making it the default. -- LCU ActivelyDisinterested transmissions °co-ords° 16:52, 1 February 2023 (UTC)
  • Support making VisualEditor default. Now that it works well and reliably I tend to use it over source editing unless I'm adding an infobox template or something like that, an activity that new editors are unlikely to be doing. VisualEditor is much more accessible and is capable of performing most edits nowadays. There's quite a few tables across wikipedia that should be altered to make them easier to edit with VisualEditor.Garuda3 (talk) 22:27, 31 January 2023 (UTC)
  • Oppose When you start users on the VE as the default, they will basically never learn to edit the source in proper wikitext. I'd rather have users who come in and get familiar with wikimarkup from the get-go, and then once they get some experience, they can later decide to activate the VE. I'd rather not create a breed of new editors who don't know how to manually add a template or an infobox or troubleshoot a badly formatted table, or whatever. There's value in learning to work in the markup, and if we start people on the VE, we basically create an artificial barrier to advancement in Wikipedia to true competence, which is likely to be as, if not more, frustrating than learning to write in wikimarkup from the start. --Jayron32 16:31, 2 February 2023 (UTC)

VE default discussionEdit

Ping Femke (alt) DFlhb 0xDeadbeef to consider the WMF's research on this question, that I posted above. You posted while I was writing and digging up the cited info. Alsee (talk) 12:44, 31 January 2023 (UTC)

The WMF research shows correlation, not causation. Phil Bridger (talk) 22:47, 31 January 2023 (UTC)

English main page language selectionEdit

The 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.

The English main page comes with a new layout. But I was unable to find a link or button to switch to another language. My suggestion: Include a "Select Language" link in the left-hand area that provides this option. 2001:16B8:B3FC:AA00:501A:A217:F853:748B (talk) 09:49, 31 January 2023 (UTC)

Hi, the language switch option has been moved to the end of the main page. CX Zoom[he/him] (let's talk • {CX}) 09:59, 31 January 2023 (UTC)
The discussion above 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.

Organize a citation edit-a-thon for WP:Vital articlesEdit

I originally raised the edit-a-thon proposal to the WikiProject Vital Articles, but because in combination of the WikiProject's inactivity and that the edit-a-thon would touch on a lot of WikiProject's core articles, I think that the proposal should be seen by a wider Wikipedian community. Editors can add articles that is not in the Vital list, as long as the article is covering a topic just as broad as many of the vital articles listed.

The edit-a-thon would focus on making the information inside Vital articles verifiable, by citing uncited statements, checking cited claims and removing unreliable sources. Once an article is fully cited, a 25% source spotcheck (check 1 source for every 4 sources) will be done before the article is officially marked as complete. The drive should initially work through the list in small 3-5 articles per batch, though this number can change depending on the edit-a-thon's activity.

Here are a fair number of tools and pages that can be used by drive participants to speed up their works:

CactiStaccingCrane 15:23, 1 February 2023 (UTC)

RFC: split births & deaths from year articlesEdit

Should the "births" and "deaths" sections of year articles (e.g., 2022) be WP:SPLIT into separate articles? RFC posted 18:27, 1 February 2023 (UTC)

Proposer's note: see recent discussion at Wikipedia talk:WikiProject Years#Births & Deaths sections. Levivich (talk) 18:27, 1 February 2023 (UTC)
  • Support as proposer. The year articles are very long (e.g. 2022 is 206k, 2021 is 227k, 2020 is 360k, 2019 is 316k, 2018 is a comparatively lean 153k). The Births and Deaths sections take up half the pages or more by my eye. Moving them to sub-pages (e.g. Deaths in 2022) is the fastest and easiest way to cut year articles down by about half and finally comply with WP:SIZE, while still having a place to put the content. Note we already have List of deaths by year, Deaths in December 2022 and so forth. (If a death itself was a significant event and not just "old person dies", e.g., an assassination of a world leader, it would still be listed in the "events" sections.) Levivich (talk) 18:27, 1 February 2023 (UTC)
    If we already have month-by-month death articles, why do we need yearly ones? Seems like unnecessary content duplication. Der Wohltemperierte Fuchs talk 18:31, 1 February 2023 (UTC)
    I support splitting them out from the main year articles. I don't really have a strong opinion about how the sub-articles are organized (e.g. by year or month). Levivich (talk) 18:39, 1 February 2023 (UTC)
    Monthly articles are for all deaths of internationally notable people. Those on main year articles are only for those who have substantial international notability. Jim Michael 2 (talk) 18:42, 1 February 2023 (UTC)
  • Support - I believe this is being done in the 2021 in the United States, 2022 in the United States & 2023 in the United States pages. GoodDay (talk) 18:32, 1 February 2023 (UTC)
  • Question – How far back would we go? Splitting 591 BC, which has one death and no births, would seem excessive. Certes (talk) 18:41, 1 February 2023 (UTC)
    • In my view it's not about how far back, it's about how large the page is. Any page that doesn't need to be WP:SPLIT because it already complies with WP:SIZE shouldn't be split. Levivich (talk) 18:49, 1 February 2023 (UTC)
  • Support. This has been my position for a while. Beyond size considerations, most births and deaths are not notable in their own right. Births and deaths are a WP:MINORASPECT of each given year, and they do not warrant such massive coverage in the year's article. The inclusion of births and deaths is a relic of before Wikipedia was standardized, and the year articles are late to catch up. Thebiguglyalien (talk) 18:50, 1 February 2023 (UTC)
  • Support, per Levivich and Thebiguglyalien. Useight (talk) 18:51, 1 February 2023 (UTC)
  • Support within reason.--WaltClipper -(talk) 18:55, 1 February 2023 (UTC)
  • Oppose we shouldn't be having discussions about major changes to layout & inclusion criteria of main year articles when their best editor is absent. Jim Michael 2 (talk) 19:20, 1 February 2023 (UTC)
    What? Who? Levivich (talk) 19:23, 1 February 2023 (UTC)
    Deb, who is by far the best & most prolific of all editors of main year articles, has been absent since 10 January. Jim Michael 2 (talk) 19:29, 1 February 2023 (UTC)
    When will she be back? Levivich (talk) 19:31, 1 February 2023 (UTC)
    We don't know, but the recent discussions about major aspects of main year articles on here & on Years are incomplete without her. Jim Michael 2 (talk) 19:34, 1 February 2023 (UTC)
    Deb's input is valuable and I hope we have a chance to hear it, and I hope she's having fun while on wikibreak, but I can't imagine Deb ever suggesting we not have an RFC while she is on a wikibreak that's lasted three weeks and will continue for an unknown duration. Levivich (talk) 19:42, 1 February 2023 (UTC)
    And cf. WP:OWN, WP:YANI, etc. The project is not hostage to any individual editor's attention and participation.  — SMcCandlish ¢ 😼  23:37, 1 February 2023 (UTC)
  • Splitting the long ones makes sense. Oppose making a general rule (if the list is short, keep everything together). —Kusma (talk) 19:37, 1 February 2023 (UTC)
  • Isn't this what categories are for? --Golbez (talk) 19:58, 1 February 2023 (UTC)
    No, main year articles have lists of births & deaths of internationally notable people. Those aren't anywhere else. Jim Michael 2 (talk) 20:42, 1 February 2023 (UTC)
    If their birth or death is newsworthy, it should be included in the article. Otherwise, we're picking and choosing who gets to qualify, which is what we've already done by having articles on them in the first place. I propose removing all lists of births and deaths and relying on categories. Otherwise, what even are categories for? --Golbez (talk) 21:14, 1 February 2023 (UTC)
    How do you define newsworthy? There's a much higher bar to be in main year articles than to have a WP article. Cats are for many things. Jim Michael 2 (talk) 21:38, 1 February 2023 (UTC)
    Dying in office. New heir apparent born. First [x] born in [y]. Last person killed by [z]. That kind of thing. And you say there's a higher bar, I say there should be no bar. They should only be included in the year article if they were somehow significant to that year, right? So either their birth is notable, their death is notable, or their actions in life are notable. Everything else, that's (at risk of repeating myself) what we have categories for. --Golbez (talk) 22:38, 1 February 2023 (UTC)
    Your first sentence would mean that Millvina Dean would be included but Shinzo Abe wouldn't. Significant to that year is arguable in many cases. Jim Michael 2 (talk) 23:02, 1 February 2023 (UTC)
    You really don't think the assassination of Shinzo Abe wouldn't be mentioned? You seem to still think I'm arguing for a discrete "here are the important people who died" list. No, I'm saying, include them in the actual list of events, if their birth or death was actually notable. I'm pretty sure Abe's is. --Golbez (talk) 23:07, 1 February 2023 (UTC)
    Which would mean excluding the deaths of Sidney Poitier & Pelé? Jim Michael 2 (talk) 23:16, 1 February 2023 (UTC)
    Their deaths, in themselves? Sure. Looks like Pele's funeral was a major event though, so that would probably be included. You do realize that all I'm suggesting is that, if people want to find out who died in 2022, they look at the category of people who died in 2022. That's all. There's no need to duplicate efforts in a year article, especially since then it just becomes a popularity contest of who gets included. --Golbez (talk) 23:58, 1 February 2023 (UTC)
    That cat has multiple times more people in it. The deaths in main year articles are only of those that have substantial international notability. You're implying that thousands of editors have pointlessly made those lists on main year articles during the last two decades. Jim Michael 2 (talk) 00:31, 2 February 2023 (UTC)
    Kind of! Their sacrifice will be remembered. --Golbez (talk) 04:34, 2 February 2023 (UTC)
    Many people go to main year articles to see lists of the internationally notable people who died that year. Such lists are nowhere else on WP. Jim Michael 2 (talk) 11:50, 2 February 2023 (UTC)
    Why? Why do they go to the list? I'm not being facetious. If they want to know who died in the year, that's what the category is for. If they want to know who famous died in the year, well, first of all, if they're on Wikipedia they've already passed notability. Secondly, they aren't going to find the famous people - they're going to find what a tiny subset of a subset of Wikipedia decided were the people worth mentioning. I know this isn't going to change, and I'm not about to right some great wrong with this argument. But I will defend it. --Golbez (talk) 16:19, 2 February 2023 (UTC)
Those cats include a huge number of people. The deaths lists in main year articles are those who have substantial international notability. The criteria have been discussed at length. Jim Michael 2 (talk) 18:09, 2 February 2023 (UTC)
  • Support. this sounds like a good idea. --Sm8900 (talk) 20:46, 1 February 2023 (UTC)
  • Support for long cases. If the page is short (mostly it'll be pre-modern years), then no need to split.  — SMcCandlish ¢ 😼  23:37, 1 February 2023 (UTC)
  • Very weak support I think that this is an axe being asked to do a scalpel's job. Yes, if the article is too long per WP:ARTICLESIZE, than births and deaths make a good target for spinning out into their own articles. However, to say that we need to do so for all year articles is a bridge too far. I'd be okay with guidance that says "If a year article is too long, then it should be considered to split the birth and death sections as their own articles" however, this wouldn't be even necessary for most year articles. Picking a few random years 175 (not needed), 1211 (not needed), 1472 (not needed), 1811 (a bit of a longer article than the rest, but probably still not needed), 1877 (getting longer still. Probably not needed, but reaching the edge-case territory), 1922 (needed, being overwhelmed by births and deaths, and reaching the "probably a bit too long" area), 1988, (likely needed). Given that data, I'd be fine with setting a cutoff of 1900 or later, but even still, we should be careful about how we do this. The current proposal is far too broad. We need to tailor it to actually fix the problem at hand. --Jayron32 12:08, 2 February 2023 (UTC)
  • Support, the WP:SIZE argument applicability gets tricky as this mixes prose and lists, but perhaps that is another argument for a WP:STANDALONE list. Most of the year articles are just lists of course, but they could be much more! Even without that step, I suspect any prose would develop from the events sections, not the births and deaths, so spinning off the undue elements makes sense. (As mentioned above but to clarify, births and deaths that would make the event section are of course fine in the main articles.) CMD (talk) 12:30, 2 February 2023 (UTC)
  • Comment If births & deaths are to be split off main year articles, for which years would this be done? Recent year articles have the most deaths in them, but far fewer births. Jim Michael 2 (talk) 12:35, 2 February 2023 (UTC)
    It should only be a size issue. If the births section is not too big, don't split it. It's not that complicated. --Jayron32 13:06, 2 February 2023 (UTC)
Where do you draw the line? Jim Michael 2 (talk) 13:10, 2 February 2023 (UTC)
Do you have any reason to suppose that WP:SPLIT somehow doesn't apply here? --Jayron32 13:28, 2 February 2023 (UTC)
I'm not saying it doesn't, but there isn't an exact size at which we should split, so how many main year articles should the births be split off from? How many for the deaths? Jim Michael 2 (talk) 15:49, 2 February 2023 (UTC)
WP:WHENSPLIT. Like Jayron said, this is not complicated. Levivich (talk) 15:59, 2 February 2023 (UTC)
  • Support per all above. —Locke Coletc 16:02, 2 February 2023 (UTC)
  • Support Split any article that is over 125K in size (but not with a hard and fast rule: aim for less than or ~100K final article size, if possible.) GenQuest "scribble" 16:11, 2 February 2023 (UTC)
  • Support removal, this is what categories are for. No need to split. Just delete. If categories aren't up to the task, then we need to improve how categories work. (can't help but wonder if this is where my 20 year old Semantic Wikipedia proposal would have come in handy...)[citation needed] --Golbez (talk) 16:37, 2 February 2023 (UTC)
    @GhostInTheMachine well if you insist. =p here --Golbez (talk) 17:57, 2 February 2023 (UTC)

Should non-free images be allowed in search results?Edit

  You are invited to join the discussion at Wikipedia talk:Non-free content § Non-free images in search results (redux). {{u|Sdkb}}talk 16:06, 2 February 2023 (UTC)

RFC: Vector 2022 and MobileEdit

The 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.

Should Vector 2022 replace Minerva on the mobile English Wikipedia site ( Aasim - Herrscher of Wikis ❄️ 23:00, 2 February 2023 (UTC)


On 18 January 2022, shortly after Wikipedia turned 23 years old, the Vector 2022 skin was turned on for all users on desktop using Vector 2010 and all logged out users. That has garnered a lot of criticism from both logged-in users and logged-out users alike. Some of the criticism is based on design choices like fixed-width, extreme white, simplified icons, and a mobile-like design on desktop. Some of the comments supporting Vector 2022 notice features such as the pinned table-of-contents and buttons, as well as the extensive UX research conducted by the Wikimedia Foundation.

Please note that there is no easy way to change the mobile skin, for logged out readers and logged in readers alike, without using ?useskin=skinname. The V22 skin also still needs more work to remove unnecessary buttons on mobile like the table of contents which does absolutely nothing, as well as the readdition of icons like the edit section icon. Please also note that this is only about mobile and the outcome may have no effect on desktop. To preview what Vector 2022 would look like with the Mobile Frontend enabled, please see this page. You should open the F12 developer tools and click the "toggle device emulation" button to view what the skin will look like on various mobile screen sizes.

RFC: Should Vector 2022 replace Minerva on the mobile English Wikipedia site?Edit


Click here to reply (Discussion tools must be enabled in Preferences):User:Awesome Aasim 23:00, 2 February 2023 (UTC)

Support as nom. The reason I support this is to get mobile users used to Vector 2022 before, in the future, all the tools on desktop like the VisualEditor and the DiscussionTools all work on mobile. The only tools that currently work on mobile properly through the mobile frontend are extremely limited, like a wikitext editor by mobile frontend. It's a slow change to unify the mobile and desktop experience. Very few companies are using dedicated mobile sites anymore, and having a mobile site in search results when you are expecting the desktop view and vice versa can greatly impede the user experience. Aasim - Herrscher of Wikis ❄️ 23:00, 2 February 2023 (UTC)


Click here to reply (Discussion tools must be enabled in Preferences):User:Awesome Aasim 23:00, 2 February 2023 (UTC)

Strong oppose. V22 has not been suited for mobile, especially not for phones. The width has a minimum, the pop-ups look weird, weird font sizes everywhere as well as using too much performance and maybe memory. There's also the editor and the abundance of whitespace in v22. Aaron Liu (talk) 01:26, 3 February 2023 (UTC)
Oppose – I quickly pulled up Vector 2022 on my phone, and it's clear that it is not designed for mobile in its current state. The page still loads at a desktop width, so the font is tiny and there is minimal responsive design (i.e., the TOC still takes up space on the left). Moreover, without any indication from the WMF that they intend to support Vector 2022 as a mobile skin, I don't think it's worth attempting the change by ourselves. RunningTiger123 (talk) 06:02, 3 February 2023 (UTC)


Click here to reply (Discussion tools must be enabled in Preferences):User:Awesome Aasim 23:00, 2 February 2023 (UTC)

  • Don't care, but am annoyed that such relatively inconsequential matters are placed on a central noticeboard, instead of serious, long-standing issues such as the years-old bugs that prevent mobile users from receiving notifications or the VE numeric ref names issue, which, imho, are way more important to the project in the long run, than this purely cosmetic, I-like-blue-but-you-like-green sort of issue. Putting on my (rarely used) curmudgeon hat, I recommend a procedural close, and a WP:TROUT to those who thought it was worth spending time on this, rather than on more important things. Mathglot (talk) 23:40, 2 February 2023 (UTC)
    I disagree that the proposal should be procedurally closed at this moment. Was the Vector 2022 skin at all perfect when I suggested that it be deployed? Of course not. Some of the major bugs could have quick fixes right now such as removing the ToC button while using Vector 2022 Mobile Frontend, but long-term should really focus IMHO unifying the mobile and desktop site so that mobile users have access to desktop tools, and vice versa. Aasim - Herrscher of Wikis ❄️ 00:39, 3 February 2023 (UTC)
    These aren't things that lack consensus. There is consensus to do so but it has not been done and this isn't about wiki configuration. I'm also pretty sure it falls under WP:CONEXCEPT Aaron Liu (talk) 01:27, 3 February 2023 (UTC)

RFC DiscussionEdit

Why here?Edit

I was told on WP:VPIL that it would be best to create it on the village pump proposals rather than on Wikipedia:Requests for comment/Rollback of Vector 2022. If you think this should go somewhere else such as a new page or a subsection of this mentioned RfC please feel free to move it. Aasim - Herrscher of Wikis ❄️ 23:00, 2 February 2023 (UTC)

Proposal is prematureEdit

The Vector 2022 skin has not been designed for use on mobile devices, thus it's too soon to discuss changing the default skin for the mobile site. isaacl (talk) 23:25, 2 February 2023 (UTC)

The discussion above 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.