Wikipedia:Village pump (idea lab)

The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, please note:

Discussions of technical issues belong at Village pump (technical).
Discussions of policy belong at Village pump (policy).
If you're ready to make a concrete proposal and determine whether it has consensus, go to the Village pump (proposals). Proposals worked out here can be brought there.

Before commenting, note:

This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.

Discussions are automatically archived after remaining inactive for two weeks.

« Archives, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61

Hosting scripts with non-CC licenses

rant

I've been extremely disappointed by the way many commenters have been shitting on me in Wikipedia:Miscellany for deletion/MediaWiki:Gadget-afchelper.js/core.js. Being widely used is not a reason not to nominate something for deletion (unless one wants to invoke WP:IAR, but, really?), it having been around for a long time isn't either, the shifting of the burden to prove compatibility is downright ludicrous, accusations of the nomination being disruptive and pretending I'm trying to change policy with it or something are a serious violation of WP:AGF if I ever saw one.
Yes, I'm pissed and I needed to get that off my chest. I nominated it because I didn't think the license was compatible, and I'm still unsure whether it is. Nothing more, nothing less. I don't automatically assume there's a wider problem.

While I hate to have to be the one to initiate the discussion, there appears to be a desire to host third-party scripts on Wikimedia that have a free license that isn't compatible with CC BY-SA 3.0. A few options I have thought of that could achieve this:
1. Toolforge. Already available, but not readily accessible to everyone to upload. Will require CORS exceptions. May cause downtime/performance problems.
2. Add an exception to WP:Copyrights. Somewhat complicated. Would have to be well-written. Would only provide a solution for enwiki, assuming we don't want to host everything here for all projects in all languages.
3. Create an exception on Meta and load any non-CC scripts from there. No CORS or performance issues and available to anyone who isn't blocked on Meta. Similarly complicated, but would solve the issue for all projects.
4. Same, but on Commons. The likelihood of getting blocked on Commons without bad faith is probably higher than meta (copyright is hard) so I have rather mixed feelings about that.
5. Create a new wiki just for this. None of the problems, but even less trivial.
6. Create an exception on foundation:Terms of Use#7. Licensing of Content. I'm not sure about the implications there, if it would overrule WP:Copyrights, etc.
Or we simply ban non-CC scripts of course, but my gut tells me that won't be a popular option. — Alexis Jazz (talk or ping me) 19:58, 15 January 2022 (UTC)[reply]

As a few participants in the linked MfD noted, we should seek advice from qualified individuals (e.g. WMF Legal) before doing anything. Enterprisey (talk!) 07:33, 18 January 2022 (UTC)[reply]

I do not see a conflict with code under a permissive license in the current system, though GPL'd software could be a bigger problem. I would support something like using MCR to add a Wikitext field to JS and CSS pages, so they could be categorized and license tags could be used. This is definitely something that would have to be done in coordination with the WMF, and only if they think it is necessary or important. AntiCompositeNumber (talk) 21:35, 20 January 2022 (UTC)[reply]

AntiCompositeNumber, what does "MCR" refer to? (I don't recognize the abbreviation) Why do you think there is no conflict atm? In some cases (sufficiently permissive license or code written by the page creator) the code can be licensed as CC BY-SA 3.0. But in other cases, where is the exception in Wikipedia:Copyrights that allows uploading third-party scripts here? If Wikipedia:Copyrights#Re-use of non-text media would cover scripts there wouldn't be an issue I think. Whether scripts are "non-text media" is already questionable, but the reference to the "media description page" clarifies that exception is only meant to apply to files in the File: namespace.
Enterprisey, it would help if we vaguely knew what we maybe wanted before asking them. Though for this, depending on what we do, I don't think Legal strictly needs to be involved. Maybe to clarify the footer if we update policy. foundation:Resolution:Licensing policy doesn't dictate a specific license, only that the license meets https://freedomdefined.org/Definition/1.0. — Alexis Jazz (talk or ping me) 01:21, 21 January 2022 (UTC)[reply]

Message from Legal:

The Wikimedia legal team has received your message. It's somewhat difficult to answer a general question about relicensing, especially as relicensing isn't the only aspect of hosting content on the Wikimedia projects. For example, many Wikipedia pages host non-free fair use images according to the English non-free content policy. They're allowed to be on Wikipedia and no law is violated by the CC BY-SA page footer even though the specific work depicted on the page is not a CC BY-SA licensed work. In this case, the Foundation does not see any copyright violation from the apache 2.0 code on the mediawiki page mentioned in the discussion and there is no need to take down the code. That is likely true for apache licensed code reproduced in full original or modified form on any mediawiki page.

Apologies that I can't be more specific than that. We are limited both by the fact that Foundation attorneys can't give the community legal advice and also by the fact that a full analysis of all possible mixtures of apache and CC licensed works would likely be quite extensive and go well beyond what's possible on Wikimedia-hosted sites.
— Jrogers (WMF)

Basically what I had already said. Legal doesn't care about policy violations. But we should. Right? — Alexis Jazz (talk or ping me) 01:29, 21 January 2022 (UTC)[reply]

MCR is mw:Multi-Content Revisions, basically a way to have two different types of content on the same page. It's only used for Structured Data on Commons at the moment, but it could be used to create a description page for script pages. That would take some development work, there's still a few days to propose it for m:Community Wishlist Survey 2022. Ultimately that's a "nice to have", a header comment will suffice as a license statement.

I think it could be useful to add some clarifying language to WP:C, stating something along the lines of "User and site JavaScript (pages in the MediaWiki: and User: namespaces ending in .js) may be licensed under any free license, as designated by a comment at the top of the page. Any JavaScript pages without such a comment are licensed under CC BY-SA 3.0/GFDL". MediaWiki:Wikimedia-copyrightwarning should also be changed to state something similar on such pages (which requires WMF approval). An RfC on WT:C would probably be the place to start. AntiCompositeNumber (talk) 02:14, 21 January 2022 (UTC)[reply]

Based on the referenced discussion, I don't think a consensus view has been established yet to host scripts that cannot be licensed under terms compatible with CC BY-SA 3.0. The participants didn't feel comfortable with interpreting the license in question. I do agree, since WMF Legal has no immediate objections, that from a policy perspective, we can try to reach a consensus about tool content on the site (as opposed to mainspace content and other pages that directly affect mainspace, such as templates). Perhaps there is a set of open source licenses that the community deems acceptable for redistribution to anyone seeking to fork their own copy of the entire Wikipedia editing ecosystem. isaacl (talk) 02:08, 21 January 2022 (UTC)[reply]

With apologies, we generally do not evaluate specific pages in this manner and it would be not be good practice to do so. If it would be helpful, we can likely take my general answer on license compatibility and do a wikilegal article on the topic of posting licensed code around the internet in a few months. I'll add it to the queue for our legal fellows to research.

If you think material in a specific case was copied onto wikipedia in a way that doesn't match with its license, you can correct it as needed, remove it, or discuss with other users to determine what to do. The Foundation would generally only evaluate a page if the copyright owner sends us a DMCA notice.
— Jacob Rogers (Wikimedia Trust & Safety / Legal)

So we are free to violate both copyright law and our own policy as much as we want, as long as the copyright holder doesn't file a claim. At least as far as Legal is concerned.

Legal isn't nearly as proactive as some users think it is. — Alexis Jazz (talk or ping me) 05:01, 26 January 2022 (UTC)[reply]

Sure; as far as I know, historically office actions related to copyright infringement have only been done in reaction to takedown notices. For better or worse, as a crowd-sourced site, editors bear individual responsibility for their edits. isaacl (talk) 05:25, 26 January 2022 (UTC)[reply]

I don't agree with your assertion that copyright law nor our own policies are being violated here. Legoktm (talk) 06:06, 26 January 2022 (UTC)[reply]

Legoktm, why do you twist my words? I said that as far as Legal is concerned we can do whatever we want as long as the copyright holder doesn't file a claim. There is no copyright violation as MediaWiki:Gadget-afchelper.js/core.js is used under the Apache 2.0 license and according to Kevin Brown-Silva the license link on MediaWiki:Gadget-select2.min.js is sufficient as this file is unmodified from the pre-compiled file for distribution and this particular case falls within their compliance guidelines for Select2. (I've already asked for more information on these compliance guidelines as I couldn't find them online)
Our own policy however is a different matter. WP:C contains no exception for scripts. While MIT/Expat licensed code can maybe be relicensed as CC BY-SA 3.0 (can't say for sure), it seems highly unlikely the same would be true for Apache 2.0. Josve05a, you said I've come to understand that the Apache license is a permissive license which allows you to relicense your whole project under a new license, as long as you details your specific modifications since permissive licenses do not force derivative works to use the same license in this discussion. But isn't this incompatible with CC BY-SA 3.0? BY-SA 3.0 would allow me to remove the modification notices. — Alexis Jazz (talk or ping me) 05:49, 28 January 2022 (UTC)[reply]

Local policy is meant to be interpreted with common sense, and in spirit rather than the letter. The policy must have been written with text content in mind, not code. It can be modified to match practise – such as by mentioning "code licensed under permissive open-source licenses can be hosted on-wiki if doing so is compliant with the terms of the license". – SD0001 (talk) 12:52, 28 January 2022 (UTC)[reply]

The key question is to what extent does the community want to promote the Wikimedia Foundation's mission, ... to empower and engage people around the world to collect and develop educational content under a free license or in the public domain, and to disseminate it effectively and globally. Does this include freely licensing the English Wikipedia editing ecosystem, going beyond the MediaWiki software itself and including commonly-used tools used by the community? (Think of the rationale underlying the Affero GPL: being able to ensure any modifications to how the service is provided can be replicated by others down the line.) If so, does it want to provide a unified licensing policy, as is done for English Wikipedia's text, or does it want to leave it to re-users to sort through the licensing requirements of each component? If the latter, do we try to roll up the licensing information to help re-users identify what needs to be done? All of the possible answers still support the overall mission; they just help draw boundaries around the scope. isaacl (talk) 21:58, 30 January 2022 (UTC)[reply]

We already require that of re-users by our use of files both locally with our NFCC policy and globally with our use of files from Commons, never mind our fair use of quotations. Izno (talk) 22:10, 30 January 2022 (UTC)[reply]

I'm not sure what "that" you're referring to. The non-free content criteria is related to content viewed or heard by readers, whereas I was referring to tools used by the community, such as the AFC helper script that was referred to in the original post. Re-users of the site don't have to replicate our editing processes, such as Articles for Creation, so we could choose to leave them out of scope entirely (and not worry about licensing at all), or keep them a little in scope by allowing tools that have contributions with free software licenses other than GFDL and CC BY-SA 3.0. isaacl (talk) 02:29, 31 January 2022 (UTC)[reply]

or does it want to leave it to re-users to sort through the licensing requirements of each component? is the that in question. Izno (talk) 20:58, 31 January 2022 (UTC)[reply]

Thanks for the clarification. The situation for content is a bit different. If the files are just being included from Commons, then they aren't being re-distributed by the re-user. The underlying basis for the non-free content criteria is fair use, where a free equivalent is not available or cannot be created. The requirements are stringent so re-users can feel reasonably assured that they can re-use the content without significant problems. With software components, though, the potential of a free equivalent being created is always there. "It would cost a lot to replicate" wouldn't be enough to claim that a legal free equivalent couldn't be made, from a copyright perspective (there could be patent issues, but there's no fair use for patents anyway). isaacl (talk) 21:32, 31 January 2022 (UTC)[reply]

(a bit off topic in regard to the policy question: Apache is compatible with by-sa in terms that you are free to modify it, as long as you attribute and specify changes. By-sa however does not allow you to remove the attribution (the -by part), and you need to keep the same license requirements (the -sa part).)

The question at hand is if we can host code which are not yet relicensed as cc-by-sa 3.0, but rather under other licenses. We have policy exceptions for Files, where other licenses can be used as long as they are more or as permissive as cc-by-sa (unless used under fair use policy), but we do not allow such exceptions in article space, nor in "code space" at the moment. Jonatan Svensson Glad (talk) 00:08, 29 January 2022 (UTC)[reply]

Concur with SD0001. If doing something useful (hosting AFCH) conflicts with policy, then changing the policy should at least be an option. Enterprisey (talk!) 08:10, 30 January 2022 (UTC)[reply]

It wasn't my intention to twist your words, I was just replying to "So we are free to violate both copyright law and our own policy as much as we want...", because I don't think neither copyright law nor our own policies are being violated. WP:COPYOTHERS says "If you want to import media (including text) that you have found elsewhere...you can only do so if it is public domain or available under terms that are compatible with the CC BY-SA license". I believe that clause is being complied with as IMO the general consensus is that Apache 2.0 is generally compatible with CC-BY-SA.

I do agree with others that WP:C would benefit from explicit clarification on this front. Legoktm (talk) 07:50, 4 February 2022 (UTC)[reply]

Important to note what the notice on the bottom of every page says.

Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. This is the equivalent of the "Unless otherwise noted". It means if we put a notice that the script is licensed under something else (like MIT or Apache) no terms are being violated. Aasim - Herrscher of Wikis 20:48, 31 January 2022 (UTC)[reply]

Awesome Aasim, that's more of a catch-all disclaimer, law and ToU and local policy are all different things. For example mw:Extension:WikiHiero, here's a non-compliant use of a GFDL-licensed work using the extension:

I noticed that in 2018. But if S. Rosmorduc, G. Watson and J. Hirst ever decided to try and sue re-users, the re-users won't be able to pass the buck to the WMF because "additional terms may apply". — Alexis Jazz (talk or ping me) 16:19, 15 February 2022 (UTC)[reply]

I have some thoughts but been thinking on how best to respond to this.

First, history: We have generally been laissez faire on enforcement of copyrights in scripts and CSS from what I've observed of the detritus in the user space. However, all the cases I've observed have been freely-licensed (for various values of free, sometimes MIT, sometimes Apache, etc.). So that means either a) we don't generally care about what's in that space as long as it's free, or b) we don't know it's there (well, some people clearly do, so not b), or c) someone has maintained some minimal standard (i.e. any proprietary stuff has been removed), or d) people have generally thought "open license is reasonable to put here and proprietary license stuff would not be", or e) some combination of the above depending on admin and user.

I think from a practical perspective of wanting to control the scripts that are used here (for potential change) as well as a safety perspective, as well as the performance perspective, that we should minimize cross-site loading. So, I do not think requiring non-CC licensed code to be offsite is reasonable.

Regarding the TOU, do note The only exception is if the Project edition or feature requires a different license. I think it's reasonable to call a user script or a gadget a feature. YMMV.

Accordingly, I do not think any of the suggestions presented besides "modify WP:C to make the exception clear" +- some discussion on where that bar is (e.g. Toolforge uses the OSD crtieria) is appropriate, in the spirit of "we can decide how to treat spaces X or Y" that the WMF seems comfortable with to some degree. Izno (talk) 03:20, 5 February 2022 (UTC)[reply]

Izno, I think it's reasonable to call a user script or a gadget a feature. YMMV. I doubt it. I think structured data on Commons is a feature. And maybe Toolforge and mailing lists. I've asked Legal to clarify the meaning. — Alexis Jazz (talk or ping me) 14:26, 15 February 2022 (UTC)[reply]

What licences are acceptable? Where do we put the bar?

I think we should update WP:Copyrights to allow some licenses for .js pages in addition to CC BY-SA 3.0. MIT License and Apache License 2.0 seem like no-brainers. What about..
• GNU General Public License v2?
• GNU General Public License v3?
• GNU Lesser General Public License?
• Affero General Public License?
• BSD licenses?
• WTFPL?
• Anything else from Comparison of free and open-source software licences we should consider? — Alexis Jazz (talk or ping me) 17:12, 15 February 2022 (UTC)[reply]

Idea for an "Edit Wizard"

See User:Enterprisey/Edit Wizard design doc. I'll copy/paste a bit here:

The Edit Wizard is a proposed better edit request process. New editors will be guided step-by-step through building up an edit request.
There will be four workflows:

Add Fact: Choose Source, Choose Quote (quote must appear exactly in source), Rephrase Quote (in your own words), Choose Place (for the new fact)

Tag an Issue: Select Text (in the article), Choose Tag (Category:Inline cleanup templates), Choose Source+Quote (optional)

Update Text: Select Text, Choose Source, Choose Quote, Rewrite Text

Delete Text: Select Text, Choose Reason (irrelevant, incorrect (require source), misleading, redundant (require selection of other text))

Thoughts appreciated. Enterprisey (talk!) 07:23, 18 January 2022 (UTC)[reply]

@Enterprisey: as ER is a step wise process, do you have any samples of what the request output will be (what other editors will have to deal with)? These are often defective today. — xaosflux ^Talk 14:10, 18 January 2022 (UTC)[reply]

Have you seen Ed's code for handling {{fact}} tags? If memory serves, it's blocked on the two-parser problem, but it sounds like it would fit your goal. Whatamidoing (WMF) (talk) 00:12, 19 January 2022 (UTC)[reply]

I haven't thought much about that yet, but I don't think it'll be a difficult part of the project. We could start with a template sentence, like "Please insert the text '___' at this location '___'. It is supported by the quote starting with the words '___' from the website/book/journal ___". There will be as much detail as the user gave - . Possibly also a sample diff (copy existing text to sandbox, make edit, take diff). Where it gets interesting is that I want other readers to be able to offer feedback on the requests, perhaps by - gasp! - upvoting. @WAID, that sounds interesting and I haven't seen that. Would you happen to have a link? Enterprisey (talk!) 00:22, 19 January 2022 (UTC)[reply]

See phab:T211243 and phab:T225750. Whatamidoing (WMF) (talk) 01:01, 19 January 2022 (UTC)[reply]

Great idea. It would be worth creating a prototypical implementation. If it takes off it can later be made into a gadget (default-enabled on namespaces=1) or extension. – SD0001 (talk) 19:37, 21 January 2022 (UTC)[reply]

Thanks. I had a conversation with Legoktm about getting this deployed, because it'll need to do a bunch of API calls and HTML fetching that would need a server (e.g. fetching the HTML of a page to check if a chosen quote is actually from the page), and we concluded that it might be tough, but at least it's possible. Enterprisey (talk!) 23:11, 21 January 2022 (UTC)[reply]

Still a pure-JS prototype would be easier to have deployed for testing among real users. Server-side capabilities could be added as optimisations later. Couldn't the HTML fetches be done client-side? If a user is citing from a website it means they've already visited the site and trust it so there should be no privacy issue in making a cross-domain request. – SD0001 (talk) 06:40, 22 January 2022 (UTC)[reply]

Oh yeah, I expressed myself poorly. Yeah, the first prototype will certainly be pure-JS, just way down the line when this hits production it'll need a MW extension, which we all know isn't the speediest process. Enterprisey (talk!) 03:26, 23 January 2022 (UTC)[reply]

I made a Google Summer of Code proposal for this: T300454. If anyone wants to be listed as a mentor (*cough* @SD0001), let me know. Enterprisey (talk!) 09:14, 30 January 2022 (UTC)[reply]

@Enterprisey Happy to help with mentoring – I see there are already 2, so I'm guessing the time commitment would be light! – SD0001 (talk) 12:42, 30 January 2022 (UTC)[reply]

Strongly agree there should be some edit wizard. Don't agree with the exact workflows. What should be done IMHO is the user makes a wikitext edit, the edit gets noted, an {{edit protected}} is added to the talk page, the text to remove, change, or add is put down with the appropriate section with the reason, and then an experienced editor can either accept the change as is, make additional edits then accept, or reject the change. This could be a Wikipedia-exclusive script hosted on something like MediaWiki:Gadget-editrequest.js. This would work very very nicely and be extremely user friendly if implemented. Aasim - Herrscher of Wikis 20:53, 31 January 2022 (UTC)[reply]

Ah, I didn't explicitly state I was targeting new editors. Your proposed script should exist too, and I've certainly wished for it, but it's for experienced editors. New editors would still have a difficult time making the right change to the wikitext in the first place. My proposal's goal is to provide guidance for that part. Enterprisey (talk!) 06:42, 1 February 2022 (UTC)[reply]

Aasim's suggestion sounds like (plain) Wikipedia:Flagged revisions. Whatamidoing (WMF) (talk) 01:46, 5 February 2022 (UTC)[reply]

@SD0001 - yup, as light as you want. Feel free to add yourself in phabricator. I'd be happy to "take point" (running weekly checkins, keeping an eye on project requirements) so that any other mentors would be free to choose their level of time commitment. Although that's the default option, I'd also be happy to share that responsibility too :) Enterprisey (talk!) 08:11, 1 February 2022 (UTC)[reply]

I think this is a pretty great idea and I commend you for taking it on! Ganesha811 (talk) 02:16, 5 February 2022 (UTC)[reply]

Simplified lead sections

Complicated topics on Wikipedia are often explained in their lead sections in a way that people inexperienced with the subject or younger people could not understand.

Many times the Wikipedia link for a topic is the top result in a search engine and users often click on it expecting to learn what it is. However, if the topic's lead section description is beyond their scope of knowledge, it could lead them to go back and find a resource that explains it better. I'm sure this has happened to you...

An example article is Imaginary numbers. Unless you know what complex numbers, real numbers, and imaginary units are, you're immediately going to be distracted by learning what those things are when fundamentally you just need to know that imaginary numbers are the square roots of negative numbers and their squares produce negative numbers.

So, I am proposing that we create simplified versions of lead sections that can be accessed through a tab selector.

This is an example UI:

The switchable lead sections could be implemented with a template. It would just switch between the two types of lead sections. The rest of the article would remain the same.

The simplified versions should be explained at a level in which the fundamental pieces of knowledge needed to understand the topic are the only things mentioned. In the case of imaginary numbers, that would be numbers and squares.

If the reader does not know about those fundamental topics, the topics will at least be linked and they can further work their way through the knowledge tree and possibly visit other articles with simplified leads until they finally grasp what the topic they were originally searching for is about.

Some might say "the lead section is supposed to describe exactly what an article is about and nothing more or less. The Imaginary number article does that perfectly fine". And I would agree with that statement. But, we are truly causing a lot of people's days to be worse and decreasing the possible usefulness Wikipedia could provide. Wikipedia is supposed to be a free source of knowledge. It can't do that well if the readers can't even understand the knowledge to begin with.

Some might say "this is why we have the Simple English Wikipedia". The Simple English Wikipedia is meant to simplify topics only grammatically. This proposal is aimed at improving the comprehensibility of the knowledge itself (and a bit of the grammar). Additionally, as explained above, people click on the top-ranked English Wikipedia to learn about something. The Simple English Wikipedia is not top-ranked and does not provide a range of knowledge like the main Wiki. Fulfilling this demand for information on this wiki and not another will be extremely beneficial for both readers and editors alike.

Some might say "the Imaginary number article is an exception. The lead section just needs to be improved". There are countless examples of things that should be easy to explain but their lead sections do not. Here are some more examples: Schrödinger's cat, Order of operations, Atom. Lectrician1 (talk) 03:43, 20 January 2022 (UTC)[reply]

I'm afraid that this would make Wikipedia less of a encyclopedia, and more of a how-to guide in some cases. The proposed format is also probably too complex for the average user to intuitively understand without a explanation of the two purposes. Sea Cow (talk) 04:34, 20 January 2022 (UTC)[reply]

We have Category:Introductory articles, which is basically this, only applying to the entire article, and using hatnotes instead of the fancier UI in your mockup. Two are even FAs: Introduction to viruses and Introduction to general relativity.

Their existence is a little controversial; the main objections are that they are a form of WP:CONTENTFORKING that doubles the editor effort needed to cover a topic, and that they give non-introductory versions an unwarranted free pass to have inaccessible content. {{u|Sdkb}} ^talk 05:59, 20 January 2022 (UTC)[reply]

Lectrician1, your original point is a good one. But your proposed solution is cumbersome and highly unlikely to gain consensus. The real solution is to follow Wikipedia:Manual of Style/Lead section#Provide an accessible overview. I agree with you that explaining the concept of Imaginary number as fundamentally you just need to know that imaginary numbers are the square roots of negative numbers and their squares produce negative numbers is a good simple explanation. It is a real shortcoming that the lead section of this article does not mention or wikilink to negative number or square root. The solution is not to create a two-tiered system of competing "simple leads" and "complex leads". Instead, it is to bring the existing leads into compliance with the Manual of Style. It ought to be easy for you to write a new accessible introductory paragraph for that article that incorporates your simplified explanation. Cullen328 (talk) 06:38, 20 January 2022 (UTC)[reply]

I'm with Cullen here - the first paragraph of the lead ought to define and describe the subject in simple terms. Where it's not doing that, it needs to be improved. There is also Simple English Wikipedia as well - I wouldn't be averse to making links to the relevant article over there where it might help. Girth Summit _(blether) 06:48, 20 January 2022 (UTC)[reply]

Simple explanations can be misleading. Such as in in the humanities and politics. If we have to debate is it simple and accurate, no thanks, too constraining and fiddly. Person 1 changes to be more simple, person 2 changes to be less POV but person 3 thinks it's too complicated etc.. Accuracy competes with simplicity. Nevertheless, the creativity of the suggestion and image markup are noteworthy, the idea of parallel or complimentary text in a tab might have other application. -- 07:11, 20 January 2022 (UTC)

Our coverage of Boolean algebra ran into a related problem in the early years, namely that the way the topic was developed by algebraists was a bad entry point to the many other users of this mathematical formalism. We 'solved' the problem by developing a parallel set of overlapping articles on the topic, including Boolean algebra (structure), Boolean algebra and Boolean algebras canonically defined. I seem to recall we used to have a treatment directed at engineers, but I don't find it. Separately considered, these are decent treatments, but the problem is that the lead of each article isn't ideal for helping readers who do not know what we have to offer which is likely to be the right article for them to start with.

This is the most extreme example I know of, but there are many examples of topics that have several articles on them that are pitched at different kinds of reader. The idea of a standard navigation interface like the tab suggested that users would know to consult if the feel they are not reading the right presentation is a promising one, but (i) I think the idea that we can just assume there is a simple vs an expert presentation of any given topic doesn't do justice to the wide variety of ways in which we have tried to accommodate the mismatch between what the treatment demands and what the new reader brings, and (ii) we have a fundamental competence issue here, which is that WP is mostly edited by people who have a relatively good feel for what material we have on a particular topic, and so are not good at putting themselves in the shoes of the new reader: good facilities for introductory jumping-off points is quite likely not to result in us writing up a lot of good jumping-off points. — Charles Stewart (talk) 11:53, 20 January 2022 (UTC)[reply]

Simple English Wikipedia already exists. X-Editor (talk) 00:30, 22 January 2022 (UTC)[reply]

@X-Editor I cover that in my initial post 😑. Lectrician1 (talk) 01:31, 22 January 2022 (UTC)[reply]

Sorry, I missed that. X-Editor (talk) 01:49, 22 January 2022 (UTC)[reply]

If this mainly a maths/math problem? what about having a link to the simple English version in the Lede?

Although this is the simple English version of https://simple.wikipedia.org/wiki/Complex_number and https://simple.wikipedia.org/wiki/imaginary_number

The imaginary is rather complex

This website is poorly named (it's a web site for people sceptical about climate sceptics), but it has a nice feature of explaining science in three different ways - basic /intermediate/advanced Wakelamp d[@-@]b (talk) 07:06, 23 January 2022 (UTC)[reply]

@User:Wakelamp That's a cool site! Lectrician1 (talk) 02:09, 27 January 2022 (UTC)[reply]

Just an update, I've decided to focus on improving lead sections for now. I would like to come back to this though, especially in regards to creating simplifications for things that a child can understand (like a kid Wikipedia). Lectrician1 (talk) 02:09, 27 January 2022 (UTC)[reply]

The TV Tropes wiki (they use pmwiki) has a “Laconic” subpage selector at the top of many (but not all) of their articles (example) that shows something sort of like our “Short Description”, but a similar UI concept might be worth considering if this kind of thing was implemented. It saves tons of reading time, especially for wiki readers that spawn tons of tabs when reading! Jim Grisham (talk) 14:59, 27 January 2022 (UTC) Couldn't we just flag the worst articles articles Wikipedia:Make_technical_articles_understandable? It looks like science and philsophy articles may the most issuesWakelamp d[@-@]b (talk) 01:45, 11 February 2022 (UTC) What about showing Lede/Article readability scores in the short XTOOLS stats?Wakelamp d[@-@]b (talk) 01:45, 11 February 2022 (UTC)[reply]

Spoiler bar

I wounder if there could be some kind of spoiler bar that could be opened and closed, for movies, TV, and literature. — Preceding unsigned comment added by Mr.Lovecraft (talk • contribs) 15:51, 25 January 2022 (UTC)[reply]

I think our readers expect that an encyclopedia such as Wikipedia will contain spoilers. So a notification is pointless. Blueboar (talk) 16:01, 25 January 2022 (UTC)[reply]
@Mr.Lovecraft: its a reasonable idae, but has 2 issues: (a) see Wikipedia:Spoiler for recap of long running community discussions on that ; (b) we try to avoid any sort of hide/collapse in articles - as these technical features can be disruptive to some readers. — xaosflux ^Talk 16:34, 25 January 2022 (UTC)[reply]

Read WP:NOTCENSORED. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 19:57, 7 February 2022 (UTC)[reply]

New: Template:Introductory pages for pages helpful as introduction

Hi. We have a lot of introductory pages, and a lot of guides and central pages to help newcomers to find introductory pages. I felt that instead of adding another page to list the links, perhaps a nav box might be helpful to some newcomers.

Below is what I came up with so far. Please feel free to comment, provide feedback, etc. this is Template:Introductory pages. thanks!

Thanks! ---Sm8900 (talk) 🌍 03:19, 30 January 2022 (UTC)[reply]

I would appreciate if anyone here could please offer a reply; anything, even something very brief, would be greatly appreciated. thanks!! --Sm8900 (talk) 10:50, 11 February 2022 (UTC)[reply]

section break

@Sm8900: It's presently at TfD, where it's getting plenty of feedback. To avoid a discussion fork, people should either comment there, or wait for that to conclude - and if it survives, the place to discuss improvements will then be its own talk page, not here. --Redrose64 🌹 (talk) 23:20, 11 February 2022 (UTC)[reply]

@Redrose64: ok, noted. so in that case, if this navigational box is indeed deleted, which seems very likely, then would it be ok if we could please then proceed to discuss this item's content and ideas here, but obviously as an idea for a nav box, rather than as an existing nav box, of course?? I have saved a copy of this item on a page in my own user space.

Please bear in mind, I have simply been asking for feedback all along; if someone wanted to provide some feedback that was negative but constructive, I would be totally fine with that. I do appreciate your helpful reply. thanks. --Sm8900 (talk) 13:32, 13 February 2022 (UTC)[reply]

If it's deleted, there is nothing to discuss. If iit's not deleted, this is the wrong venue. --Redrose64 🌹 (talk) 21:55, 13 February 2022 (UTC)[reply]

@Redrose64:, if it is deleted, then I will greatly revise the idea, and come back to Village Pump, to discuss the new revised version, taking account fully of all the valid and helpful feedback that I received on this, elsewhere. However, since I did initially ask for constructive feedback right here in this section, and have not (still!) received any actual feedback here on this page, I will retain this section here, simply to document and reflect that I did in fact make a full good-faith effort to discuss my initial nav box idea, very much in advance and previously before I tried to insert the navbox for use on any actual page. I do appreciate your helpful reply. thanks! --Sm8900 (talk) 01:07, 14 February 2022 (UTC)[reply]

@Sm8900: Here's a few thoughts on the template as it stands, hopefully you'll find some of them useful:

It's way too big for an introductory template, the number of links is overwhelming. If I was given that as an "introduction" when I was getting started I would have just given up.
There's a lot of duplication. You have multiples of some things (tutorials for example) and listing out both the main and sub-pages for various policies is unnessasary. Do we really need "Help Contents", "Help:Directory" and "Site map for help pages"? do we need both "Essays in a nutshell" and "Essay directory"?
You have way too many sections. Some of these (like "categories" and "Text formats") essentially only list one page. Some categories are broken into sub-categories for reasons I don't understand, what's the point of the "By topic" subsection in the article tips box that only lists one page?
You have a lot of pages here for things that I would consider to be either extremely niche or rather advanced. How many people are going to be interested in "The Bugle for military history"? Are database reports something that a brand new editor needs to know about? Is WikiProject Democracy really a page that newbies should be getting directed to?
I don't understand some of the categorisation here, "Article tips" seems to be entirely stuff that would be better placed elsewhere.
I can see a few omissions, e.g. you don't really seem to have anything related to reliable sources here. I would expect a template aimed at beginners to include something like Help:Referencing for beginners.
Some of this does give the impression that pages have been selected based on your personal interests, rather than pages that would be of use to everybody getting started. E.g. why do the wikiprojects for science, cities and military history get specifically called out and linked, while all the others you have to navigate to through a list? Why does "The Bugle for military history" get a link but there's no sign of the other newsletters for wikiprojects?

I agree with the general feeling in the TFD that it would be better to focus on improving Template:Basic information, we already have a load of introductory help pages (probably to the point that it's a bit overwhelming) and I don't think it's really worth the effort of maintaining duplicates. I hope this doesn't come across too harshly. 192.76.8.70 (talk) 18:19, 14 February 2022 (UTC)[reply]

@User talk:192.76.8.70, your points are actually indeed helpful. I will indeed either act upon those points, or else seek some way to implement them with an existing template. I appreciate your points, and will give them some thought. your last sentence is very considerate and thoughtful, and is appreciated as well. thanks. --Sm8900 (talk) 02:54, 15 February 2022 (UTC)[reply]

Thinking about deprecating IRC in favor of something like Discord [proposal idea]...

This is just an idea, but I have only recently developed concerns for IRC as of recently. I am thinking maybe IRC be deprecated for privacy concerns and because of inactivity. I do not think I am ready to propose it, but I want to develop it into something that is ready for an RfC.

IRC by default displays IP addresses, which can actually be used for determining someone's location. WMF is currently in the process of cloaking these IPs which makes IRC essentially pointless if used uncloaked. Discord and Guilded on the other hand has IP addresses hidden by default from everyone except the staff that can access IP information for each user (that is how they do IP bans from Discord servers as well as Discord itself).

The next concern I have is activity. I checked some of Wikipedia's main IRC channels and only see a hundred or so users on IRC compared to, say, Discord's Wikimedia Community, which has ~3000 members and ~600 active users. IRC has mostly died as soon as Discord became a reasonable option for most.

Lastly, IRC does not allow for transmission of media, which is something that Discord and Guilded allow. Sometimes an image gets deleted from Commons for being potentially non-free, yet it is in line with Wikipedia non-free criteria. I remember asking once for a deleted file so I could upload it on Wikipedia with "do not move to commons". This is not possible with IRC. Attachment of media files on wiki could potentially violate wiki policy (particularly NFCC), and a lot of the forum software is public. Discord's privacy settings also means I can control who can direct message me in what guild on a per-server basis.

I heard WMF is working on a chat solution based on Mattermost, but I do not know how that stacks up to Discord and similar freemium services. I am not sure if it is even maintained, but anyway, here are some of my reasons why I'd want to deprecate IRC. Aasim - Herrscher of Wikis 23:17, 30 January 2022 (UTC)[reply]

I have seen the downsides of Discord (namely being for profit and its privacy policy not exactly aligned with WMF's), but personally I think the downsides of IRC (namely the privacy concerns with IRC, lack of usage, and limitations with IRC) are greater than the benefits we may get from continuing to use IRC. That is why I would like to build this proposal into something that might pass. Aasim - Herrscher of Wikis 23:21, 30 January 2022 (UTC)[reply]

Relevant xkcd. In all seriousness, I do not believe this idea is worth pursuing. It's not clear what it would mean to "deprecate" IRC. There is no requirement on Wikipedia that editors must use IRC for communication—if you are concerned by privacy or activity, there isn't anything to prevent users from simply not using IRC. In practice, I see management of the Wikipedia-related IRC channels as being WP:CONEXCEPT—at the end of the day, my understanding is that they're run by the IRC Group Contacts, so even in the unlikely event that we can get an RfC with consensus to "deprecate" IRC (which would probably have to be a global RfC on Meta Wiki, since it's not just enwiki that uses IRC), there's nothing stopping the Group Contacts from simply ignoring that discussion and keeping the channels running. In terms of privacy, one benefit of IRC is the lack of scrollback—any user that joins the Wikipedia Discord server now and in the future will be able to see the complete history of all messages that were ever sent, whereas IRC users can only see the messages that were sent while they were connected to the network. In my view, this is actually ideal for discussing privacy-related issues, such as requesting revision deletion in the channel #wikipedia-en-revdel ^connect. You're correct that IRC by default exposes a user's IP address, but it is easy to mitigate this by requesting a cloak (see [1] for instructions on how to get a generic one within seconds). As for transmission of media, what I like to do is upload the image I want to a third-party site like imgur, and then paste the link from that through IRC. Mz7 (talk) 01:55, 31 January 2022 (UTC)[reply]

To be honest, I'd prefer a more modern solution that does not have privacy concerns such as with IP exposure. I also think it is ridiculous that we promote channels on IRC without putting a disclaimer when they connect that their IP will be visible until cloaked. Personally, if we want to keep on using IRC, we ought to put a disclaimer before they connect to let them know that their IP information may be made publicly visible. Even if we use Discord we need to make it clear that 1. the service is not controlled by the WMF, and 2. Discord's guidelines take precedent over Wikipedia guidelines. That could be done with an update to the IRC template, but also Discord is what is being used as of latest for communication. I am guessing it could be untrivial to get Discord linked in the relevant notices like MediaWiki:Readonlywarning and MediaWiki:Readonlytext as editors also discuss Wikipedia off-site there as well. Aasim - Herrscher of Wikis 17:35, 31 January 2022 (UTC)[reply]

@Awesome Aasim Links to #wikipedia-en-help generally are passed through Wikipedia:IRC help disclaimer, and similar disclaimer pages could easily be spun off for other channels. --Ahecht (TALK
PAGE) 19:11, 14 February 2022 (UTC)[reply]

I think people should know what they are getting into before they connect to Discord or IRC or whatever. One thing we can do is we can make mention of the platform in the template (like Join on Discord, Join on IRC, etc.) so that people know what they are actually joining. But I'd also link Discord channels in places where they are useful as well. Aasim - Herrscher of Wikis 20:43, 15 February 2022 (UTC)[reply]

What about an IRC/Discord bridge? — xaosflux ^Talk 19:14, 31 January 2022 (UTC)[reply]

Hmm... That might work... I know the RedWarn Discord has an IRC to Discord bridge... I think a Toolforge solution would work best though... Aasim - Herrscher of Wikis 20:41, 31 January 2022 (UTC)[reply]

IRC and Matrix are already bridged; #foo on libera.chat is automatically connected to #foo:libera.chat. Matrix doesn't have the issues with privacy or features. We could recommend people join those instead. I was going to suggest we add a warning about IRC's low activity, but it's more that you'll get fewer responses on IRC, not zero. Concur in full w/ Mz7, with a further note that the two platforms have distinct cultures, and some users (myself included) prefer IRC's. Enterprisey (talk!) 07:23, 16 February 2022 (UTC)[reply]

One thing I've never understood is how does the average IRC user get messages that were sent when the IRC app isn't running? I know there are tools like IRCloud but it's not free. Is there a simpler way? – SD0001 (talk) 09:08, 16 February 2022 (UTC)[reply]

Some don't care that they'll miss stuff that was said while they're not there, or rely on people who are in the channel all the time to let them know if there was anything interesting. Others use a bouncer of some sort, but I don't know of any free bouncer services offhand; ZNC is popular free software (in both senses), but you'd still need to pay for hosting somewhere to run it. Anomie ⚔ 12:55, 16 February 2022 (UTC)[reply]

Most IRC systems, including Libera Chat have a MemoServ for this purpose. For example, you can message me when I'm offline with /msg memoserv send xaosflux Please check your email when you get this!. — xaosflux ^Talk 14:52, 16 February 2022 (UTC)[reply]

Also, IRC is not designed to be a persistent message platform, it is designed to be a real-time message platform, non-archival of messages can be considered a feature. — xaosflux ^Talk 14:53, 16 February 2022 (UTC)[reply]

It is not for me, then :) I use discord and check messages just once or twice a day, or when I'm pinged. Such a workflow just doesn't fit with IRC, it seems. – SD0001 (talk) 04:01, 18 February 2022 (UTC)[reply]

Alt text stored on image page?

For those of you unfamiliar with the alt text accessibility feature, quick primer: This image depicts John Oliver, a comedian and satirist, and below the image is the caption: John Oliver, comedian and satirist, pictured in 2016. However, this image also contains alt text, and its purpose is to tell screen readers (e.g. not you, but a bot that converts text to speech for the blind) what's in the image without being able to use the image as a visual aid. So, the alt text on this article reads Man in his 40s with a gray suit jacket and spectacles, visible only from the shoulders up. When screen readers come to the image, they will read the alt text instead of, y'know, trying to read off the pixel values (or the caption, which may explain what the image is doing in the article.)

As of now, this alt text has to be set when it is called by the file handler (e.g. [[File...). My question is: alt text, unlike the caption, is generally not specific to the article its in. Why be forced to redefine it in every image? When images are uploaded to wikipedia, there should be a "default alt text" option, which is automatically substituted in when the image is called. This can still be overridden by calling the alt parameter in the file-calling text of the article, but there should be a way to provide a centralized alt description in the image page, so that adding alt text is more convenient for the user (i.e. more widely used) and not just something that has to be done to promote an article to GA status. Plus, main page images (at least at DYK) don't generally come with alt text, so this would add it to at least some of them. Thoughts? theleekycauldron (talk • contribs) (she/they) 08:55, 31 January 2022 (UTC)[reply]

My understanding was that ALT text is actually specific to the way the image is used. Some images can be used to illustrate different things, and need different ALT texts. Jo-Jo Eumerus (talk) 10:27, 31 January 2022 (UTC)[reply]

There could be a "suggested alt text" but to do this properly you'd need to have suggested alt texts in all possible languages, and make sure you override the alt text on Commons if it is in a different language than the one you wish to use. Probably currently still easier to keep the alt text on each page using the image. —Kusma (talk) 11:24, 31 January 2022 (UTC)[reply]

No image needs to have the alt text in every language filled right away—It could be a template, something like: {{alt text |en=... |es=... |he=...}} and more are added as needed. When using an image on wiki, it would look for an alt text template with the parameter matching the language of the wiki. theleekycauldron (talk • contribs) (she/they) 11:30, 31 January 2022 (UTC)[reply]

We have enough difficulty getting image uploaders to describe what the image is that they are uploading. I don't think it would be practical to add another ask at upload. Worse, that could only address new media - you instantly create a backlog of epic proprtions re our existig content on Wikimedia Commons, and sooner or later someone would then annoy past uploaders by demanding that they add alt text to images they added to commons, some more than a decade ago. This then gets into the next practical problem, Wikimedia Commons is a multilanguage project, alt text has to be in one or more specific languages and don't asssume that the uploader you are requiring to add alt text is going to do so in the language of your choice. Lastly, alt text should be specific to the use in an article. The same photo of a church might be used to illustrate an article about round towers, thatched roofs, or locations used in a particular TV series, and the appropriate alt text would likely be very different in each. Ϣere SpielChequers 12:04, 1 February 2022 (UTC)[reply]

I suppose that's fair—any way to add articles missing alt text to a maintenance category, then? And create an alt text addition helper, too- theleekycauldron (talk • contribs) (she/they) 06:23, 2 February 2022 (UTC)[reply]

I'm more positive about this idea than some of the others here. When we're talking about alt text, we have to consider our starting point, which is that our current approach isn't working. I'm not sure exactly what the percentage of images with alt text currently is, but I wouldn't be surprised if it's <1%. The only way that changes is if we change our approach, and that means either introducing AI or adopting something like this. I don't think a suggested alt text field on Commons would be used extensively, but even if it's only used occasionally, it could start to help. {{u|Sdkb}} ^talk 08:18, 2 February 2022 (UTC)[reply]

Consider review of meta:Community Wishlist Survey 2021/Reading/Alt-Texts and Image Descriptions and related tasks (and I think the tasks have much more reading), and meta:Community Wishlist Survey 2016/Categories/Multimedia#Default alt text in image file. Izno (talk) 23:27, 12 February 2022 (UTC)[reply]

Mass creation of articles

Idea: Editors wishing to mass create articles, whether manually or with the help of automated tools, must obtain a consensus from the community prior to doing so

It seems like a sensible measure; it adds minimal overhead to mass creations that are supported by the community, but will save a lot of time, both for the creator and those who are cleaning up afterwards, if it is not supported by the community.

I don't believe this is covered by any current policies, but I might be wrong. BilledMammal (talk) 04:24, 2 February 2022 (UTC)[reply]

Mass creation of articles with the assistance of tools is covered in Wikipedia:Bot policy § Mass page creation. Manual mass page creation at a speed similar to what would be done by bots is covered by Wikipedia:Bot policy § Bot-like editing. Prior consensus is not currently required for high-speed manual edits, though if there consensus against the type of edits, they can be treated in the same manner as bot edits (and so a new consensus in favour of the edits is required). isaacl (talk) 05:10, 2 February 2022 (UTC)[reply]

How many (manual) article creations a day would you consider to be "mass" creation? Jevansen (talk) 06:18, 2 February 2022 (UTC)[reply]

I think it is likely to be obvious when it is happening; though WP:MASSCREATION has a guideline "anything more than 25 or 50". BilledMammal (talk) 11:55, 2 February 2022 (UTC)[reply]

Would this include mass deletions as well? I've seen a couple of instances where a user deleted numerous pages for varying reason in one swoop and were given the stink-eye by other editors. Panini!^🥪 14:37, 3 February 2022 (UTC)[reply]

Deleting articles for non-CSD reasons without following process is an admin tools issue; we already have policies for that. BilledMammal (talk) 23:46, 3 February 2022 (UTC)[reply]

Generally, “Mass editing” of any sort is considered disruptive. Large volumes of change can be overwhelming - and will often be rejected based on the volume rather than the merit of the changes. Eager editors can often achieve more by slowing down, taking more time and working in short chunks. Blueboar (talk) 01:16, 4 February 2022 (UTC)[reply]

Such limits should be situational. I have used reliable databases to source the fast creation of several dozen articles on state supreme court justices for a given state. Howeer, I generally create these in draft space and then move them to mainspace at a more leisurely pace. I think that presents a possible solution. BD2412 T 18:03, 6 February 2022 (UTC)[reply]

Making all extended confirmed editors, pending change reviewers

I think once a user becomes extended confirmed the should have the ability to review pending changes. There's no special requirements to perform pending change task and sometimes the backlog can get bad, so this would help a lot. Iamreallygoodatcheckers (talk) 04:11, 4 February 2022 (UTC)[reply]

Pending changes reviewers should have a reasonable familiarity with guidelines and policy. This does not necessarily correlate with EC, although I do not know how admins treat the permission granting in practice. That said, when is the backlog that bad? It seems one of the most easily managed backlogs on Wikipedia, likely in part due to it appearing prominently on all reviewers' watchlists. CMD (talk) 04:57, 4 February 2022 (UTC)[reply]

Probably 95% of EC editors would be capable of pending changes reviewing. That's why PERM hands it out so freely. However, there is an aspect that PC reviewers commit to actually checking the other edits, while just giving PC to everyone might encourage someone to just press accept when their edit gets stuck behind something else in the queue. There is also the case of that 5% - some certainly couldn't be relied upon. As 'davis says, the status quo seems to be working fine --Nosebagbear (talk) 10:41, 7 February 2022 (UTC)[reply]

As someone that requested similar rights (rollback IIRC) while extended confirmed, but was denied, I personally believe that the fact one needs to request these rights is a good thing. If 95% of EC editors are granted PC rights, then I don't see a point in making them get PC automatically. I'd just see it as an increase in the risk of someone misusing the tools. However, there is some argument to be said that perhaps there are other ways to increase the visibility of PC rights requests that would lead to more people using these tools (such as displaying these prominently in the notifications editors receive when they achieve EC rights). I also wonder if increasing the visibility and use of these rights might encourage more editors to be admins in the future, which is something we desperately need. A. C. Santacruz ⁂ Please ping me! 10:50, 7 February 2022 (UTC)[reply]

WAV format

Not only WAV files automatically fail WP:NFCC#3b, they also go over one megabyte for minimally decent quality. Any more downgrading of a wav file would worsen its quality. Furthermore, I no longer think the .wav format is suitable for this project, especially when uploading non-free audio content. We already have ogg and mp3 as more preferable formats. WAV files are allowed on Commons but only for free content. I thought about proposing a technical blocking of newer uploads of wav files on Wikipedia. For some reason, I'm unable to upload WebP files locally here. Anyways, if successful, I may file a Phabricator task to implement this. Any other ideas about what else to do with WAV? --George Ho (talk) 23:01, 7 February 2022 (UTC)[reply]

I don't see how it fails 3b any more than an mp3 does. From an audio encoding perspective that makes no sense. —TheDJ (talk • contribs) 16:27, 8 February 2022 (UTC)[reply]

How does a non-free wav not fail 3b? From what I've seen, there aren't many non-free .wav files remaining. Rather the amount of them is under either fifty, thirty, or ten. How do you explain that? --George Ho (talk) 17:17, 8 February 2022 (UTC)[reply]

You say a WAV equals to being non-free (automatically as you say). I say some non-free files happen to be wav. That seems like a pretty substantial difference to me. —TheDJ (talk • contribs) 19:23, 8 February 2022 (UTC)[reply]

I don't understand this either. A lossy-compressed copy clearly satisfies 3b better than an uncompressed one (unless the latter has a really crappy sample rate). Nardog (talk) 17:26, 8 February 2022 (UTC)[reply]

I agree that we should be deprecating any use of WAV, but that's because lossless content should be uploaded as Ogg FLAC, or just FLAC. However, I disagree that using a lossy version satisfies 3b better than lossless: the issue is the length of the recording, and whether it's the minimum amount required to illustrate the point. We want to be able to do that in the best possible way. Uploading something in 64kbps mono wouldn't magically make it okay to have more of a non-free recording, after all, so the inverse goes for having lossless versions of anything that does fall under fair use. Theknightwho (talk) 18:25, 8 February 2022 (UTC)[reply]

Contrary to non-free wav files here, there are still bunch of wav files in Commons (use either c:Special:MediaSearch or c:Special:Search). --George Ho (talk) 18:51, 8 February 2022 (UTC)[reply]

I don't see why we should tell ppl what formats to use. Its hard enough already to add media files. And the transcoding pipeline will only serve back mp3/ogg for ppl anyway. Converting them manually to mp3s like George has been doing is just wasting storage by adding additional transcodes which ALREADY had been made. —TheDJ (talk • contribs) 19:21, 8 February 2022 (UTC)[reply]

Yeah, I agree that converting to MP3 is pointless - I hope we've not been getting rid of the lossless version as well, as that would be worse than pointless. Something in the back of my mind is telling me that Ogg and FLAC are preferred formats, but I can't remember why. Not that it matters much. Theknightwho (talk) 21:21, 8 February 2022 (UTC)[reply]

I'm... at loss of words. My replacing any wav (lossless) version with a lossy version is just time-wasting and pointless, right? Oh great. Now my rigid interpretation of WP:NFCC#3b is put into question. ...I hope you didn't mean that, right? --George Ho (talk) 21:29, 8 February 2022 (UTC)[reply]

I've already explained why I don't think it makes any sense under 3b, though: the issue is the length of the recording, and whether it's the minimum amount required to illustrate the point. We want to be able to do that in the best possible way. Uploading something in 64kbps mono wouldn't magically make it okay to have more of a non-free recording, after all, so the inverse goes for having lossless versions of anything that does fall under fair use. Theknightwho (talk) 21:34, 8 February 2022 (UTC)[reply]

Well 64kb mono would be something else perhaps (though I'd think you'd compromise the artist's artistic integrity by creating such a badly sounding derivative, which might also be a fair use problem). It's just that there is virtually no audible quality difference between most wav and an mp3s. MP3 is very good at compression or rather wav just doesn't do compression (only encoding) and wastes lots of bits. But users never get to hear the wav file after uploading, only the mp3. If you really try, maybe you'll find the 'original file' link, but.. who cares ? —TheDJ (talk • contribs) 09:05, 9 February 2022 (UTC)[reply]

Wait, the very old Special:Upload still allows WAV (and WebP), but the newer UploadWizard doesn't. --George Ho (talk) 23:07, 7 February 2022 (UTC)[reply]

It seems that MediaWiki:FileUploadWizard.js has a hardcoded set of allowed extensions. So that would indeed cause it to get out of sync with the actual allowed list of filetypes indeed. It should be fixed. —TheDJ (talk • contribs) 16:31, 8 February 2022 (UTC)[reply]

Well.... Please feel free to propose it if you wish as I did for mp3 and as I'm doing for webp and webm formats at Wikipedia talk:File Upload Wizard. However, I (or another editor) might oppose, or express my concerns about, adding "wav" to that Wizard out of my concerns that two of you don't see. George Ho (talk) 18:36, 8 February 2022 (UTC)[reply]

I ran into a very confusing comment by George Ho on the talk of an article I steward about this, and forgot to reply or look into it deeper. I'm happy I stumbled upon this, because it explains the matter is "one guy" rather than "a consensus I missed". Theknightwho, TheDJ, Nardog, it's worth making it clear George Ho is enforcing this on articles without any apparent discussion, which as TheDJ points out is creating unnecessary duplication. Vaticidalprophet 05:18, 9 February 2022 (UTC)[reply]

I don't know what I'm depicted as based on comments about me here. I think you made me feel guilty and look bad about my disdain toward WAV format. To reduce the risk of looking like a bad guy, I'll mention the files that I think you feel strongly for: File:Fifth Harmony - Write On Me.flac and File:Despacito by Luis Fonsi sample.wav. I PROD-ded them and replaced them with MP3. I thought about taking both WAV and MP3 files to FFD if de-PRODding happens, so the consensus can decide which one(s) to keep. I do feel strongly for FFD mostly because I'm unsure whether NFCC can allow non-free FLAC/WAV files. But maybe you want me to have the MP3 files deleted without FFD and shorten the length of a FLAC file, right? I just am wary about reducing its quality without ruining it too much. Don't worry: I saved the master copies of the samples recorded in Audacity.

Speaking of quality, File:Kiss & Cry (Sample).wav has subpar audio quality due to its low bit-rate, and I'm unsure whether you want me to improve the WAV quality further. Hopefully, the MP3 one I uploaded should have a better sound, despite being lossy. Also, I PRODded other remaining WAV files mostly due to "contextual significance" issues; that has nothing to do only just "minimal extend of use". I might mention more of them if necessary. Honestly, this situation is becoming more similar to SVG discussions unless I stand corrected.

BTW, I didn't know that additional transcodes would waste space. AFAIK, even transcoded files converted from lossless or uncompressed formats are often larger than other files using lossy formats. George Ho (talk) 07:38, 9 February 2022 (UTC)[reply]

As others have already said, from an NFCC perspective it doesn't matter whether it's wav, flac, mp3, or whatever. NFCC concerns would focus on the amount of the work used and the context in the article, not the file format. As an analogy with images, you might compare wav with bmp versus flac with png and mp3 with jpeg (and ogg/oga with webp, particularly since both can use both lossless and lossy compression). We do generally avoid bmp too, not because of any NFCC concern but simply because there are better formats available.

The FUD around SVGs and NFCC is an entirely different matter, which at least has better arguments (and, unfortunately IMO, more adherents) than the FUD you've expressed here regarding NFCC and wav or flac files. P.S. A good audio analogy for SVG would probably be something like a MIDI file.

The comments regarding uploading a transcoded version not saving space is simply that MediaWiki will still keep the old version of the file too. Even if it's deleted, MediaWiki keeps the original file in case it's later undeleted. It would take action by sysadmins to completely remove the old version of the file. Anomie ⚔ 13:11, 9 February 2022 (UTC)[reply]

Page Numbers

Moved from WP:AN

08 FEB 2022 It would be nice if page numbers appeared when the text of your article is printed or saved. It would also be nice if the date of retrieval was listed, but this is less important. You do a great job and I thank you. I contribute regularly to Wikipedia. — Preceding unsigned comment added by 2603:6080:6B00:2B00:DDCE:7446:84C5:A2B3 (talk) 13:46, 8 February 2022 (UTC)[reply]

A2B3, are you using Special:DownloadAsPdf - or the browser print function? — xaosflux ^Talk 16:36, 8 February 2022 (UTC)[reply]

Wikipedians with degrees to show their subject

I do not know whether this idea has been formulated at Wikipedia: Perennial proposals, but I thought I would raise it here. If you look at the user pages of Wikipedians, one will often see that they categorise the Wikipedian according to the degree(s) that s/he has achieved. For example, we can see the categories "Wikiped- ians with B.Sc. degrees", "Wikipedians with B.A. degrees", "Wikipedians with M.Phil. degrees" and "Wikipedians with Ph.Ds." Would it be an idea to make Wikipedians who advertise that they have degrees indicate the subject in which they have degrees? That may help readers of Wikipedia appreciate where edits are likely to be reliable and valid. For example, I have a B.Sc., an M.Phil. and a Ph.D. in psychology, so my edits to articles to do with psychology may be based on a solid knowledge base. If my user page listed that this was the topic of my degrees, readers would be able to tell that any edits I made to the psychology articles in the encyclopedia would be based on greater expertise than, say, any edits I were to make on quantum mechanics. YTKJ (talk) 16:34, 8 February 2022 (UTC)[reply]

@YTKJ: All information you add to an article must be cited to published reliable sources. Your personal knowledge or expertise does not play into it. Just cite your sources. RudolfRed (talk) 16:44, 8 February 2022 (UTC)[reply]

See Wikipedia:Expert_editors for more on that topic. RudolfRed (talk) 16:45, 8 February 2022 (UTC)[reply]

@YTKJ: there are many templates you can use, see Category:Academic degree user templates. I just tweaked the PhD one, so you do something like this: {{user degree/PhD|field=[[topic]]}}

PhD

This user has a Doctor of Philosophy degree in awesomness.

— xaosflux ^Talk 16:45, 8 February 2022 (UTC)[reply]

But as RudolfRed points out, "being an expert" doesn't make your edit any more authoritative - but it may help other editors find you to let you know about topics you could be interested in. — xaosflux ^Talk 16:47, 8 February 2022 (UTC)[reply]

I gained a degree almost 50 years ago. It doesn't make me an "expert" now - not without checking more up-to-date information, at least. Ghmyrtle (talk) 16:49, 8 February 2022 (UTC)[reply]

I received a PhD in Linguistics 47 years ago, but never worked in the field. I quickly gave up on editing linguistics articles after I saw how many linguistics grad students were editing. :) - Donald Albury 18:09, 8 February 2022 (UTC)[reply]

I don't think you need a doctorate in psychology to figure out that not everything Wikipedians say about themselves is necessarily true... AndyTheGrump (talk) 16:50, 8 February 2022 (UTC)[reply]

On the Internet, nobody knows you're a dog. We do want people who are experts in their field to edit Wikipedia, but that is useful only because they have access to sources that the rest of us may not, and that they are able to contextualize their fields so that the information is useful to a general knowledge encyclopedia like Wikipedia. What we don't particularly need is people claiming that credentials trump verifiability. Any formal recognition of credentials is just a slippery slope in that direction, coupled with the fact that we have no way of confirming anyone's credentials. --Jayron 32 16:53, 8 February 2022 (UTC)[reply]
I think you're understating the importance of that contextualisation, to be fair. I completely agree that credentials shouldn't be a factor in verifiability, but applying concepts such as WP:DUEWEIGHT inherently require good familiarity with the topic. Theknightwho (talk) 17:58, 8 February 2022 (UTC)[reply]
It does, but you missed the context of my first link. We have no way to confirm that someone is who they say they are, so there is no point in even asking or recognizing it, and granting it any special privileges. Some of us have long memories of when we were burned by this in the past. --Jayron 32 13:25, 10 February 2022 (UTC)[reply]

In a world where this exists, perhaps it is best that we remain focused upon WP:RS rather than contributors' alleged credentials. On a more personal but germane note, some of the most stupid people I have ever had the misfortune of dealing with hold the same advanced degree as me. And I'm not exactly Mister Peabody, either. JoJo Anthrax (talk) 18:15, 8 February 2022 (UTC)[reply]

Citation needed that you have those degrees. And that anyone with those things on their pages has the degrees they claim. Basically, this is another side of "nobody knows you're a dog". --User:Khajidha (talk) (contributions) 18:45, 8 February 2022 (UTC)[reply]

Many thanks for your swift responses, everyone. Your points are well taken - I especially take the points of User: Ghmyrtle and User: Donald Albury, which seem to be saying that if a degree were taken a long time ago, it might not reflect expertise in contemporary knowledge of the field.YTKJ (talk) 22:15, 8 February 2022 (UTC)[reply]
... and alternative hypotheses are available. Thincat (talk) 22:33, 8 February 2022 (UTC)[reply]

I have stated my own name, my academic degrees, and offered links to verify my academic degrees. This being said, I have never used my credentials in order to win a dispute at Wikipedia, they are just stated so that people know who they are talking to and what they can expect from me. tgeorgescu (talk) 16:32, 10 February 2022 (UTC)[reply]

Something I don't understand

Okay, so like I write an article. Let's use Cinema of Eritrea as an example. It's not translated or split from another article. It's just words from my brain straight into the page.

Now, my credit for that is found by looking at the history section. I know this going in, and I'm fine with it. If I translate an article from another Wikipedia, the expectation is that I put in the first edit summary that the work is a translation, and (at my discretion) post to the article talk page saying where the translation came from.

However, we have templates like {{Wikia content}} and a whole host of attribution templates which go right into the main page. I don't see what's so special about {{Peter Kemp}} that he gets his own fancy template (also like.. someone might want to look into that). Shouldn't these kinds of templates really be on the talk page instead of in mainspace? –MJL ‐Talk‐^☖ 06:23, 10 February 2022 (UTC)[reply]

This was created back in 2005 to "reference" text that, seemingly, was only agreed to be allowed on Wikipedia given this form of attribution. This was later accepted via OTRS in 2015.[2] It might be worth checking with OTRS to see what form of attribution is required. We often used to (and still do) cite public domain text in this way, see {{EB1911}}. If the text has been copied rather than "based on" then Wikipedia:Plagiarism would likely apply. Thincat (talk) 10:16, 10 February 2022 (UTC)[reply]

@Thincat: It appears the 12th and 13th editions (supplements) are now in the public domain; it might be worth incorporating the content from them as we did with the 11th. BilledMammal (talk) 10:32, 10 February 2022 (UTC)[reply]

Yes. In the early years when Wikipedia was desperately short of articles (!), I suppose before professional football had been invented, text was copied wholesale from public domain sources with no editorial intervention. Later that became disapproved of but often nothing was done about rewriting the content. Thincat (talk) 10:55, 10 February 2022 (UTC)[reply]

Coming back to your main questions, if the source is reliable and the use of it appropriate then yes, at the foot of the article itself is a suitable place. It is where citations go. Personally, I'm not too happy with attribution merely via an edit summary. I've never done a translation myself but I often copy text within Wikipedia and I use {{Copied}} on source and target talk pages. It looks to me that {{Translated page}} can be used for much the same thing. The translated text should still have citations on the article page. Thincat (talk) 11:13, 10 February 2022 (UTC)[reply]

@Thincat: I mean, I am highly doubtful that Forum:CT:Amendment to naming policy for real-world transgender individuals is considered a "reliable source" (it's not even a tertiary source which Wookiepedia as a whole is even if it is WP:USERGEN). Despite that, it's right there in the references section of Fandom (website). That's where I am getting at mostly here. –MJL ‐Talk‐^☖ 18:19, 10 February 2022 (UTC)[reply]

If you translated from another WMF project, we can bring over the history as well post at WP:RFPI; links are sufficient generally, but we can do this. Some projects are more strict or accustomed to this (especially German), so if you do a DE->EN translation they normally appreciate that we bring the history over. — xaosflux ^Talk 18:44, 10 February 2022 (UTC)[reply]

Clarifying the number of sources required by GNG

WP:GNG states There is no fixed number of sources required since sources vary in quality and depth of coverage, but multiple sources are generally expected. In theory, this nuanced rationale is useful, but in practice it is rarely applied; editors find their preferred definition of "multiple" (I believe it is typically three, in line with the essay by RoySmith and with most of the remainder defining it as two) and so long as the editor believes each source meet WP:SIGCOV they consider it sufficient.

As such, I believe this nuance doesn't benefit the project, instead making it more difficult for new editors to understand what is required for their article to survive, harder to determine a consensus at AFD, and complicating the work of AFC and NPP. To resolve this, I believe it would be useful to provide a fixed number; as a first thought, I would propose the above quoted text be replaced with At least three sources are required.

Raising this here, to develop the idea and because if an RFC is opened broad input would be desirable due to the significance of GNG. BilledMammal (talk) 16:27, 13 February 2022 (UTC)[reply]

We have never spelled out the number because this is far too game-able. We are looking for what is sufficient to show that significant coverage exists. That could come from one really strong comprehensive source like an in-depth biography, or it might require six or more sources that each only have a paragraph or three but combined provide good coverage. Just saying N sources means that editors at AFD will only focus on the number of sources with no consideration of what significant coverage there is. We know this happens. --Masem (t) 16:33, 13 February 2022 (UTC)[reply]

I would agree, except editors already focus on finding N sources that individually meet the other requirements of GNG; the only difference is that they use their own definition of N. This idea won't fix the issue, but it won't make it worse and it will fix other issues. BilledMammal (talk) 16:40, 13 February 2022 (UTC)[reply]

@BilledMammal please read the notes that go along with that essay. -- RoySmith (talk) 16:42, 13 February 2022 (UTC)[reply]

Thank you; I originally had both yours and WP:3REFS, but for concision I shortened it to just yours, as the more influential essay in establishing or maintaining the position that N is three, not two or four, even though that wasn't your intent. BilledMammal (talk) 16:50, 13 February 2022 (UTC)[reply]

That's still the point: the GNG is 100% centered on showing significant coverage and that can come from 1 high quality source or may require many where the topic itself is not the central topic of each source. Counting sources is not a replacement for reviewing significant coverage, and editors that continue to equate GNG to number of sources using those essays are fundamentally wrong. --Masem (t) 16:59, 13 February 2022 (UTC)[reply]

Unfortunately, counting sources (that meet the other criteria of GNG) is what happens, and the fact that there should be more nuance doesn't change that.

On a side note, I disagree that one high quality source is enough, as I don't believe we can comply with NPOV when we only have a single perspective, but that isn't relevant to this discussion. BilledMammal (talk) 17:38, 13 February 2022 (UTC)[reply]

What I mean is if I have a book-length biography, high quality, it will likely have its own set of references about that same person. The initial WP article about that person would not need to include those references but that they exist with the biography means more sources exist out there. This doesn't apply to, say, a single long-form obit that is not going to have that type of feature. --Masem (t) 18:05, 13 February 2022 (UTC)[reply]

I agree with Masem here. A. C. Santacruz ⁂ Please ping me! 18:18, 13 February 2022 (UTC)[reply]

With this clarification, so do I, although I would interpret it as having multiple uncited sources, rather than just one. BilledMammal (talk) 18:22, 13 February 2022 (UTC)[reply]

The GNG (and pages related to retaining/deletion of articles due to notability) should be viewed as the potential for articles to be developed further from the likelihood of additional sourcing to be found in the future or that can be added that has been identified but not yet added. EG: if an article goes to AFD and 10 new sources are found and agreed to be sufficient to give that topic significant coverage, then the only thing that should be done is getting those 10 articles added to the article, but we don't have a deadline for that; if years later those 10 sources have yet to be added, it would still be inappropriate to AFD the article because we know those sources exist. Same concept with the "one great source that has a known bibliography/reference section to work from" situation. This comes back again to why we try not to judge just on the number of sources since one source could be a link to potentially multiple additional sources that could build more significant coverage in time. Of course, what more commonly happens today is that editors are just using web-based sourcing that rarely include references to other source, so we judge each source on its own and not what it can led to. --Masem (t) 19:11, 13 February 2022 (UTC)[reply]

Umm, how about 1? A new stub could be one line, sourced, and be GNG OK. — xaosflux ^Talk 17:55, 13 February 2022 (UTC)[reply]

42. JoJo Anthrax (talk) 18:15, 16 February 2022 (UTC)[reply]

Just went to newpages, Glaucium calycinum is a brand new article, I see no reason it would be a good deletion candidate for lack of another source yet. — xaosflux ^Talk 17:57, 13 February 2022 (UTC)[reply]
That would fall under WP:OUTCOMES eg WP:NSPECIES. Not so much a GNG issue. --Masem (t) 18:02, 13 February 2022 (UTC)[reply]
I think it would actually fall under WP:COPYVIO; the only difference is that some connecting words have been added, and some technical words have been replaced. BilledMammal (talk) 18:16, 13 February 2022 (UTC)[reply]
Possibly, I'm not saying it was "good" - just that the lack of 2(+) sources are not enough to say it should be deleted for failing GNG. — xaosflux ^Talk 19:06, 13 February 2022 (UTC)[reply]
I think most plants would be better as subsections within their Genus; for example, Aa (plant); all the articles listed there should be merged into it. BilledMammal (talk) 20:13, 13 February 2022 (UTC)[reply]

@BilledMammal, there are only a few standard ways of describing plant species, looking at the same parts in the same order. I wouldn't characterize the article as close paraphrasing, and certainly not of the reference you list as being copied from. That's a very harsh way to treat an editor whose article just came up as an example. A non-templated note about close paraphrasing on the talk page would be enough and have it discussed there. I'm removing the copyvio notice. StarryGrandma (talk) 23:18, 13 February 2022 (UTC)[reply]
I've responded on your talk page. BilledMammal (talk) 23:32, 13 February 2022 (UTC)[reply]

Aforementioned editor here, could we discuss this on the talk page of the relevant article instead of on half a dozen different user pages? If this is an issue, I'd like to be involved and for there to be a central point of public discussion. Thanks y'all. Fritzmann (message me) 23:49, 13 February 2022 (UTC)[reply]

Wikipedia:Notability (biology)

Hello all. There was recently a discussion at WT:WikiProject_Molecular_Biology#Notability_guidelines_for_science/database_topics? about notability in cases where there are large classes of possible items in databases (e.g. genes, species, proteins and RNA families). I summarised the results of that discussion at Wikipedia:Notability (biology) and listed it at WP:MOLBIO#Resources. I'm wary of policy creep, but in this case, I think it's reasonable since the topics have come up multiple times, most similar to geographic_features, astronomical_objects, and numbers. I'd be interested in people's suggestions or direct edits. The starting questions I listed at WT:MOLBIO are below, but feel free to approach from a more generalist perspective!

Are there classes of molbio (or other) topics with inherent/De facto notability?
What are the principles / common features for which classes are notable?
If a database is a sufficient secondary source to support notability, what are the features of such a database?
Does the number of items of that class matter? Would the call on RNA motifs have differed if there were 100,000 observed motifs?
Does it make a difference if the class is naturally occurring vs man-made? (e.g. observed microbial species vs created cell lines)
Does it make a difference if the class is stable vs changes rapidly?

T.Shafee(Evo&Evo)^talk 23:08, 14 February 2022 (UTC)[reply]

I would oppose assigning inherent notability to anything; I would suggest that the guideline instead grants the presumption of notability, but that GNG needs to be met if the presumption is challenged. I would also note that a database is typically a primary source, as it usually doesn't contain an author's analysis, evaluation, interpretation, or synthesis of the facts, evidence, concepts, and ideas taken from primary sources. Beyond that, I need to consider further. BilledMammal (talk) 23:16, 14 February 2022 (UTC)[reply]

Watchlisting sections, not pages

Hi all, I 'd like to propose something on watchlisting.

Problem: high traffic pages (like various noticeboards) are hard to watch. They are almost always at the top of your list. And while you contribute to an issue that interests you and you would like to follow it, there is no way you can dοing that.
Prob solution, if it is technical feasible: Watchlisting sections of certain pages.

What do you think? Cinadon36 08:31, 18 February 2022 (UTC)[reply]

@Cinadon36: Wikipedia:Talk pages project#Notifications for topic subscriptions may be what you're looking for (although it is pings and not watchlist). CMD (talk) 09:02, 18 February 2022 (UTC)[reply]

@Cinadon36: This is a frequent request, apparently difficult to implement in Media Wiki software. See Wikipedia:Perennial_proposals#Allow_watchlisting_individual_sections_of_a_page There is a user script there you can try out. RudolfRed (talk) 00:40, 19 February 2022 (UTC)[reply]

@Chipmunkdavis and RudolfRed: Thanks mates! Cinadon36 07:08, 19 February 2022 (UTC)[reply]

Protection idea

I got a random idea:

- Protected pages appear normally to anyone who can't edit it.

- Edits to a protected page by editors who didn't have the rights to do so are logged, for purposes of determining if an article can be unprotected.

- When attempting to publish the edit, the editor will instead be offered an option to automatically make an edit request. – AssumeGoodWraith (talk | contribs) 01:44, 19 February 2022 (UTC)[reply]

What advantages would this have over WP:Pending changes? --Ahecht (TALK
PAGE) 16:29, 19 February 2022 (UTC)[reply]

The advantages that I can see are two: you won't need to switch over all semi-protected pages to pending changes, and you don't get the page history polluted by long series of reverted edits. – Uanfala (talk) 16:34, 19 February 2022 (UTC)[reply]

It's a fine idea to be implemented as a user script (see WP:US/R), which in fact can be written quite easily. – SD0001 (talk) 19:19, 19 February 2022 (UTC)[reply]

Create a new page

Guys I need help, I was asked to create a page for a social networking and book sharing site (feraahub). I do have a information and feraahub owner gave me it's logo but I need a link to create a page not a user page — Preceding unsigned comment added by B.matias brown (talk • contribs) 13:15, 20 February 2022 (UTC)[reply]

@B.matias brown: It sounds like you have a conflict of interest with feraahub. As such, you will need to create the article in WP:DRAFT space and it will be reviewed by the volunteers at article for creation. Please note that if the company does not meet the requirements of WP:NCORP the article will be rejected. BilledMammal (talk) 13:39, 20 February 2022 (UTC)[reply]

Add "Did you find what you were looking for?" feature to the end of any article.

At the end of any article, there would be a box asking whether the reader had found the information they were looking for. They could either click a green tick or a red cross. In the latter case, they could be asked to indicate the question they were hoping to find an answer to (the simplest implementation would just be a text-field, but adding the option to select among previously suggested topics would reduce friction and make it easier to see which questions most commonly go unanswered).

Example: Recently, I was researching Proton-Exchange Membrane Fuel Cells, a topic to which I'm fairly new. I was hoping to find some information about polarization curves, which are a very common way to characterize the behavior of a fuel cell, but the article didn't contain any. Suppose for the sake of argument that my experience here was relatively common. If the system laid out above were in place, it would now be much easier to improve the article; editors would know that adding information about the polarization curve specifically was going to be especially helpful to many users.

I expect the above is one of the most straightforward ways to implement this. However, coming up with variations and iterations is generally valuable and there might be other ways of gathering more user feedback.

Disclaimer: I'm new to this community. I hope I've tried to obey all the norms, but it's possible I did something wrong, in which case I apologize. I want to emphasize that I don't feel "entitled" to someone else doing my research for me or anything; Wikipedia has been of immense value to me and I'm really thankful to this community for that!

- Matt — Preceding unsigned comment added by 82.135.82.55 (talk) 13:50, 20 February 2022 (UTC) (just found my old (not very active) account, so figured I could try signing the right way) MathieuPutz (talk) 20:01, 20 February 2022 (UTC)[reply]

I like this idea. It would give editors ideas for improving/expanding articles based on questions asked, and it would help readers feel like participants. The text entry could auto-create a section on the Talk page. I have no idea how technically feasible any of this is, but I think it's a useful suggestion. (Granted, there will probably be plenty of "questions" that aren't appropriate for answering in the article, but those can just be disregarded.) Schazjmd (talk) 16:14, 20 February 2022 (UTC)[reply]

I like the idea too. Wikipedians are self-directing volunteers so there's limited scope for influencing the ways they choose to contribute, but there's probably enough of us that could be spurred on when gaps are pointed out. The suggested question for readers seems focussed enough, so it will be less likely to repeat the results of the discontinued article feedback tool. – Uanfala (talk) 16:29, 20 February 2022 (UTC)[reply]

This sounds like an improvement on the old article feedback tool, in that it is more focused on what the reader wants. One possible drawback of this is that it could raise people's expectation that a volunteer editor will add the information requested pretty soon. That expectation is likely to be dashed. Maybe there could be an additional request that the reader should add the information if it is found somewhere else in a reliable source? Phil Bridger (talk) 17:36, 20 February 2022 (UTC)[reply]

v t e Introductory pages
Starting guides and lists	Contributing to Wikipedia List of introduction pages List of directories and indexes Instructional material The Missing Manual About this manual Your first edits Your user account Creating an article Communicating with others Wikiprojects and other groups Helping other editors Community portal Contents Reader's Index Editor navigation Navigating Wikipedia Index to all technical pages
Intro pages	Primer for newcomers Who writes Wikipedia? About Wikipedia Main entry on Wikipedia submit a new article FAQ Main Contributing Editing
Tutorials	Basic tutorials list All tutorials list Introduction to editing Editing Formatting Links Saving changes New articles Summary Introduction to the Manual of Style Article sections Images and refs Linking Consistency Summary For students Contibuting to Wikipedia The Wikipedia Adventure
Text formats	Manual of Style Simplified Reading schedule
Guidelines	List of guidelines Behavioral Content Deletion Editing Notability Style Other Introduction to guidelines Content Conduct Summary
Help directories	Menu Help Contents directory Site map for help pages
Help pages	Glossary Quick list of codes Dos and don'ts Tips Editing overview Page history Editing steps Joining Navigating
Get help or advice	Places to ask Questions Help desk Teahouse Reference desk Centralized discussion Students forum Dispute resolution Admin noticeboard No original research Incidents Current events List of places for requests
Basic policy	Purpose Essence of Wikipedia Principles Volunteers' role Editor integrity Core content policies Administration
Policies	Essays summary Essay directory Simplified rules Core content policies Neutrality Verifiability No original research Five pillars Be bold Neutral point of view Civility List of policies Content Conduct Deletion Enforcement Legal Procedural
Article structure	Structure: Lead section Format Referencing Sections Content: Development "The perfect article" Featured articles
Article tips	General: Biographies of living persons Writing better articles By topic: Science sources
Group tasks	Maintenance Cleanup Task Center Copy Editors' Guild Science collaboration Requested articles\| Natural sciences Version 1.0 editorial team Projects at Wikipedia Library
Research resources	The Wikipedia Library Request Resources Databases website WikiProject Resource Exchange
Community	Statistics Wikipedia community Wikipedia:Meetup Organizations Collaborations WikiProjects Science Cities Military history
Discuss proposals	Dashboard Requests for comment Village Pump Items for deletion/discussion articles by date Articles by category Project for Wikipedia Democracy
News and data	Newsletters: Signpost Library Newsletter The Bugle for military history Data: List of database reports
Categories	Guidelines
Portal:Current events