Wikipedia:Village pump (proposals)

Moved from Wikipedia:Village pump (policy)

AFAICS, we have a few primary help venues for questions of a general nature:

• WP:Teahouse
• WP:Help desk
• Wikipedia:Editor assistance (inactive)
• Wikipedia:Editor assistance/Requests

I don't know exactly what the difference between Teahouse and Help desk is (in

• The latter two are mostly or entirely historical AFAIK. The Teahouse is for the newest of the new. The help desk is generally for more complicated questions, but not unwelcoming for people who end up there as opposed to THQ. GMG^talk 16:13, 20 April 2021 (UTC)[reply]
• Broadly speaking, the Teahouse is designed for new users, unfamiliar with Wikipedia, its culture, and its jargon, while the Help Desk is designed for people who are more familiar with Wikipedia in general. Which is not to say that it works out so 100% of the time, but in general that is how it is supposed to work. As a result, a person answering a question at the help desk would feel free using shortcuts, referring people to technical documents, and using wikijargon to answer questions there; however the Teahouse is supposed to presume that the OP would know none of that, and strives to treat users as though they need to have their hands held through the process, and responders should adopt a tone in their response that they are dealing with Wikipedia newbies who wouldn't know how to read a Wikipedia namespace document, what a diff is, or what any of the terms d'art that we use in daily conversation at Wikipedia mean at all. We need both of those two help desks to keep that distinction available. EAR has long been moribund, and I'm actually shocked to see it hasn't since been marked historical. --Jayron32 16:16, 20 April 2021 (UTC)[reply]
• The editor assistance page isn't a venue in itself but a place to find a specific willing helper. I agree though that the help desks are as good a place to find a helpful editor and make a personal connection. isaacl (talk) 16:54, 20 April 2021 (UTC)[reply]
• I agree the last two seem historical. As to the difference between the first two, it's something I also wondered when working on user:Levivich/Help, which is my prototype attempt at consolidating new user help pages. Levivich ^harass/_hound 17:25, 20 April 2021 (UTC)[reply]

• Do we have a good mapping of the ingresses to each of these processes that may need adjusting? — xaosflux ^Talk 19:08, 20 April 2021 (UTC)[reply]
• I think our helpers are more than capable of determining what level of help to provide to users. I think combining the help desk and the Teahouse could be a useful turn of events. Experienced users shouldn't mind, and new users will be less confused. We have so many possible pages for new users, consolidation is key to accessibility. We really need to be thinking hard on how to make it easier to onboard new users. On a side note, calling it the Teahouse feels confusing to me. I wish it was just called the "help desk", which is self explanatory, but it should retain the cultural norms of the Teahouse. AdmiralEek (talk) 23:29, 20 April 2021 (UTC)[reply]

  Also, advertised this at the TH and HD talk pages. AdmiralEek (talk) 23:33, 20 April 2021 (UTC)[reply]

• Planning to add some more substantive comments later, but people might want to take a look at Morgan, Jonathan T.; Halfaker, Aaron (22 August 2018). "Evaluating the impact of the Wikipedia Teahouse on newcomer socialization and retention". Proceedings of the 14th International Symposium on Open Collaboration: 1–7.
  doi:10.1145/3233391.3233544.. It has some useful empirical evidence about what the Teahouse does, as well as an explanation of its goals as opposed to the Teahouse. Vahurzpu (talk) 05:54, 21 April 2021 (UTC)[reply
  ]
• I support keeping the Teahouse and the Help desk separate as I have the Help desk watchlisted and occasionally contribute, but I would find it onerous to follow Teahouse guidance and explain every Wikipedia process in my own words rather than linking to the process and answering any follow up questions. The Help desk has a prominent link to the Teahouse and the Teahouse page should probably have a similar link the Help desk. Both links should probably be followed by a request to post queries in one venue rather than both. TSventon (talk) 12:19, 21 April 2021 (UTC)[reply]
• Per
  WP:TH might make the most sense. Nick Moyes (talk) 22:39, 21 April 2021 (UTC)[reply
  ]
• I agree with Procrastinating Reader that the help venues ought to be consolidated, and I'm fine with marking the editor assistance forum as historical. One of the things that newcomers most often say about Wikipedia is that the number of back-end pages is overwhelming, so it is not good that editors are encountering potential confusion over where to ask their question in the first place.
  Regarding the point made about the intended difference between the TH and the HD, that's all fine and dandy, but the key word is intended. There are currently lots of complete newcomers ending up at the HD, and relying on them to read the hatnote and switch to the Teahouse if they want a friendly response is not working. We need to do a better job of pointing to the TH rather than the HD in all newcomer-facing areas, and making the latter a much quieter venue that gets only non-obvious questions from established editors. {{u|Sdkb}} ^talk 01:41, 23 April 2021 (UTC)[reply]
• I was the main user answering at
  WP:EAR for a few years. It was one of the principal help venues until the The Tea House opened. My original comment about closing EAR down was in fact in 2013. I'm surprised no one has taken the initiative to deprecate it and close down all the links to it. Kudpung กุดผึ้ง (talk) 05:12, 23 April 2021 (UTC)[reply
  ]
• In a volunteer environment, I think groups interested in an initiative should be free to decide how to organize it, as long as it doesn't impose an undue burden on others. In this context, I think the following questions should be examined regarding any potential burden:
  1. Are questions being asked and answered effectively?
  2. Are responders able to deal with questions effectively?
• Regarding the first question, different types of venues appeal to different editors, so it can be useful to have a metaphorical teahouse setting as well as a more terse question-and-answer format. Regarding the second question, as noted by others, different responders may be interested in answering at different levels of detail. Is having multiple venues effective at supporting this, versus the tradeoff of some responders having to monitor several places? Related to both questions, if someone asks a question in one place that, based on the level of detail needed by the questioner, is better suited for another place, is that question still handled effectively (by still answering at the desired level, by smoothly moving it to the other place, or by other means)?
• In short, I'd like to hear from the people on the ground: does having two venues hinder your ability to get appropriate responses or to adequately respond to questions? Do we need to have a wider mix of people watching the help desk or teahouse in order to deal with different expectations on level of detail? Is eliminating one going to actually draw more watchers to the other? I'm not enthusiastic about telling volunteers to stop contributing to a productive initiative, even if I think they could equally help another productive initiative. isaacl (talk) 19:46, 24 April 2021 (UTC)[reply]
• I occasionally stop by both the Teahouse and Help Desk, and even answer questions. I wouldn’t call myself highly experienced in either. I do see a lot of overlap (but also much difference). If someone asks a noob question at HD, it’s better to answer them in-place rather than tell them to go off and re-ask at Teahouse. Vice-versa, having some more-clueful questions at Teahouse helps break the monotony there. If we did want to maintain a strong separation, rather than an intent, then we could move discussions from one forum to another, just like this discussion has been moved from VPP to VPR. But moving threads on MediaWiki is a bit more cumbersome than on some other discussion platforms. I do think we're a bit curt with people asking a question in both places: having two fora is potentially confusing and asking for help in more than one place isn't in the same league as forum-shopping across DR–AN–ANI.
  Both HD and TH are limited by the high volume and rapid archiving, especially Teahouse. I recall one new editor who was quite miffed that the Teahouse is presented as a place to have a friendly chat, but is in practice mostly a rapid-fire Q&A feed. If we were a smaller community, we could have all chat at le Bistro or the Beerhall, rather than compartmentalising it into multiple silos (VP* is a good example). This brings us to a practical limitation. Merging the two would exacerbate the situation with high volume of questions. And there’s also the nature of the questions: the merged Help venue could be overwhelmed with so much repeated "how i make new article for non-notable thing?", "my thing's not showing up in Google", and "why AFC take so long?".
  Talking about practical as opposed to intended differences, a big difference between Teahouse and Help Desk is the entry points. New users often get a big welcome message directing them to the TH.

IIRC, even some of our level-one warning templates direct them there.
– Pelagic ( messages ) – (12:45 Sun 25, AEDT) 01:45, 25 April 2021 (UTC)[reply]

• For those wondering what the differences are between EA/EAR and Teahouse/Help Desk; If you take a close look, you will notice that many EAR requests are dispute/content related, something I think Teahouse/Help Desk either do not deal with, or do not promote being that they are mainly promoted as Q and A forums. Other things that are promoted heavily on EA/EAR, but not on Teahouse are the ability to contact a list of helpful editors directly and make edit requests. While these features might be technically possible at the Teahouse, they are not promoted in any way that makes them functionally useful such as they are at EA/EAR. Huggums537 (talk) 16:03, 1 May 2021 (UTC)[reply]
• Comment. I've been active answering requests at WP:EAR lately. I like it because it's low traffic, but not completely inactive. I can keep it on my watchlist without it bloating to 100+ revisions a day, and I have a decent chance of being able to answer (before someone else provides a good answer, making the need for me to answer unnecessary). –Novem Linguae (talk) 23:19, 1 May 2021 (UTC)[reply]
• Comment. Putting myself in the mindset of a noob, I know what a helpdesk is, I have no idea what the teahouse is - some fancy facility for the experts in the know to have a chat, I suppose. I know which I would turn to for help. Yet we do it backwards; we are so used to doing it backwards we don't even realise we are. I can see your replies now; "@steelpillow, the Help:Contents explains which and why" - except noobs don't read smallprint, they just go "Great, a nice blue help desk link >click<". Just a word of advice from a long-serving technical author and UI designer in the IT business; whatever you guys decide, a prominent clickable Help Desk button is what noobs want and expect. — Cheers, Steelpillow (Talk) 15:40, 23 May 2021 (UTC)[reply]

Proposal: deprecate

WP:EAR

and close down all active templates or help pages linking to it

Proposal: Close down Help Desk and replace with Teahouse

Proposal: Replace Main Page Help Desk link with Teahouse link

• Support Whilst we're here: to follow up from this discussion which closed with consensus to add a Teahouse link but wasn't sure on which form it should take. It seems like there's probably a consensus to keep TH and HD separate for now. So I think replacing the Help Desk link on the Main Page with a link to the Teahouse would be better. Editors coming from there are probably newcomers, and it's too confusing/bloaty to have them both listed trying to explain the differences IMO. ProcrastinatingReader (talk) 07:46, 24 April 2021 (UTC)[reply]
• Commment Whilst happy to support this, I am slightly concerned about removing the Help Desk link entirely. Wouldn't the following work OK?:

  • Community portal – Bulletin board, projects, resources and activities covering a wide range of Wikipedia areas.
  • Help desk – Ask questions about using Wikipedia.
  • Teahouse - A help desk for novice editors. A friendly space to ask about editing Wikipedia.
  • Local embassy – For Wikipedia-related communication in languages other than English.
  • Reference desk – Serving as virtual librarians, Wikipedia volunteers tackle your questions on a wide range of subjects.
  • Site news – Announcements, updates, articles and press releases on Wikipedia and the Wikimedia Foundation.
  • Village pump – For discussions about Wikipedia itself, including areas for technical issues and policies.

  I wouldn't want to undermine any attempt at gaining a consensus by offering a formal counter-proposal at this early stage, but do add one if it helps. Nick Moyes (talk) 09:12, 24 April 2021 (UTC)[reply]

  This works for me, although I'd say put the Teahouse above HD in order, and replace the Help desk description with something like "For more experienced editors to ask questions about editing Wikipedia." I still think I prefer replacing the link altogether, as I think the Teahouse does a better job at helping newbies and that giving unnecessary choices is bad UX and adds a slight bit of friction. ProcrastinatingReader (talk) 09:44, 24 April 2021 (UTC)[reply]

• Support one link. Oppose two links. We don't need and shouldn't have two forums for asking questions (so help desk and teahouse ought to be merged). If we do have two forums, TH should be linked on the main page (so support this proposal). Under no circumstances should both be linked; that will just confuse people. Levivich ^harass/_hound 13:24, 24 April 2021 (UTC)[reply]
• Support Teahouse link on Main Page and, if we have both links, putting it above the Help Desk. If we retain both, the Helpdesk blurb line should include something that it is for non-novice editors. I am neutral to removing the Helpdesk from main page and just having Teahouse there. Nosebagbear (talk) 14:02, 24 April 2021 (UTC)[reply]
• I do not support this good-faith, well-intentioned suggestion. I support adding an additional link to the tea house and I have no objections whatsoever to placing that link above the help desk link. But as long as the help desk is open and we want editors to use it then we need to link to it. I strongly recommend a separate discussion focused solely on whether we can and should consolidate these two efforts; I would strongly support such a motion but it seems to be a much larger proposal than what has been put forth here that warrants a separate, dedicated discussion with a clear header so other editors can see what is being proposed. ElKevbo (talk) 02:59, 25 April 2021 (UTC)[reply]

  We do have links to the help desk, from internal pages like WP:Questions, Template:Wikipedia help pages, Template:Noticeboard links, etc. The proposal isn't to scrap all those links. It's just to replace it on the Main Page specifically, from where it's more likely we'll be getting newcomer clicks rather than anything else. ProcrastinatingReader (talk) 15:32, 25 April 2021 (UTC)[reply]

• Link to both but put the Teahouse above the Help Desk. Adding another line won't damage the layout, but it will allow more people to get the assistance they need. —
  talk ~ contribs) 17:11, 25 April 2021 (UTC)[reply
  ]
• Further comment on Main page wording I'm uncertain what words are best if the Teahouse goes above the Help desk on the Main page links. I've racked my brain, and this is the best I can come up with:

  • Teahouse - A help desk for novice editors. A friendly space to ask about editing Wikipedia.
  • Help desk – Ask questions about using Wikipedia. Aimed mostly at those with some editing experience already.

  (or perhaps...*Help desk – Ask questions about using Wikipedia. Less friendly, more curt and tons of abbreviations!) Nick Moyes (talk) 00:19, 26 April 2021 (UTC)[reply]

  Can the wording for the Teahouse just be "A friendly space for new editors to ask about editing Wikipedia"? —

  talk ~ contribs) 16:21, 28 April 2021 (UTC)[reply

  ]

• Support removing the Help Desk link and replacing it with a link to the Teahouse. The Main Page is likely where new editors will go for information. Experienced editors can still manually go to the Help Desk.
  EpicPupper 20:26, 27 April 2021 (UTC)[reply
  ]
• Support Per Epicpupper. Two links is just confusing, and the better of the two links for the main page is the teahouse. Calliopejen1 (talk) 04:21, 30 April 2021 (UTC)[reply]
• Support Link to both as proposed by Nick Moyes here. My logic is that we need two different places to get either advanced or novice answers. As a newer user, I'm glad to now be aware the help desk exists. I've been going to the Teahouse for answers, and while I appreciate the friendly, and helpful manner, it kinda sucks getting treated like a day one IP user getting spoon-fed answers. Now I know I have a place I can go to get answers I can handle. I think other users will like to know this too. Huggums537 (talk) 14:48, 1 May 2021 (UTC)[reply]
  • But you didn't learn this information from a link on the Main Page, and other established editors won't either. — Bilorv (talk) 23:18, 1 May 2021 (UTC)[reply]
    • But still, I learned about Teahouse from my talk page, and if there had been a descriptive Teahouse link on the main page with a contrasting descriptive Help Desk link right below, I most likely would have picked up on it much sooner. Huggums537 (talk) 12:31, 2 May 2021 (UTC)[reply]
• Support: just a link to the Teahouse is preferable (don't make people confused before they've even clicked on a help forum, because they don't know which one is right for them) but a link to both Teahouse and Help Desk would be an improvement, as the Teahouse is friendlier. — Bilorv (talk) 23:18, 1 May 2021 (UTC)[reply]
• I would support replacing with something like {{tq|Need help? Try our
  Help forum for more experienced users. GMG^talk 22:39, 2 May 2021 (UTC)[reply
  ]

  I think GreenMeansGo offers an interesting solution. Huggums537 (talk) 00:01, 3 May 2021 (UTC)[reply]

Support replacement of link....only need one and the teahouse is better at recruitment for new editors. This past year has seen a good increase in the amount of individual edits but a decrease in registration.....perhaps the Teahouse can help us fix this problem.Moxy- 23:08, 2 May 2021 (UTC)[reply]

• Support. The teahouse is pretty much the clearing house now. Guy (help! - typo?) 20:18, 3 May 2021 (UTC)[reply]
• Support, I'd be surprised if experienced editors didn't know about the help desk, and more so if they were accessing it from the front page. Accessing help venues from the front page seems like something more aimed towards newer users, hence the use of a teahouse link. Aza24 (talk) 22:21, 3 May 2021 (UTC)[reply]
• Support two links, with the Teahouse link above, and the help desk link reading something like "for more advanced questions." Ganesha811 (talk) 01:09, 5 May 2021 (UTC)[reply]
• Oppose The Teahouse has a misleading name as there doesn't seem be any socialising or group activity and there's certainly no tea. When I attend physical editathons, the tea/coffee breaks are the best bit as sharing refreshments is a good way to bond and engage with other editors. The Teahouse actually seems to be just an unfocussed Q&A board. We already have plenty of those with more accurate names like the Help Desk and Reference Desk. Andrew🐉(talk) 08:54, 5 May 2021 (UTC)[reply]

  The lack of tea is indeed distressing. Maybe it should be renamed to Coffeehouse so that we can instead be distressed about the lack of coffee? — GhostInTheMachine ^{talk to me} 18:01, 5 May 2021 (UTC)[reply]

• Oppose Add a link to the Teahouse to the 6 links already in
  Other areas of Wikipedia section on the Main page — as proposed by Nick Moyes right at the start — GhostInTheMachine ^{talk to me} 18:07, 5 May 2021 (UTC)[reply
  ]
• Oppose removing the Help Desk link. Support adding an extra link to the Teahouse. --Jayron32 14:33, 13 May 2021 (UTC)[reply]
• Strong oppose linking to both, weak support for switching to Teahouse. Folks, we've been through this before, where we can't agree on the best help link to use, so we end up including two very similar help links, and pretty soon newcomers are overwhelmed with redundant options and succumb to
  choice paralysis. Whatever happens here, don't let that be the outcome—a single link to either the TH or the HD is vastly superior to linking to both. As for which venue to link, I don't think we've differentiated them clearly enough to be able to say for certain which is most appropriate. De jure, it's probably the Help Desk, as theoretically anyone could be seeking help from the main page, but de facto, it's probably the Teahouse, as in reality it's basically just newcomers using that link. {{u|Sdkb}} ^talk 05:13, 14 May 2021 (UTC)[reply
  ]
• Oppose Add the Teahouse link and update the Helpdesk and Teahouse link descriptions to clarify the distinction — GhostInTheMachine ^{talk to me} 15:44, 16 May 2021 (UTC)[reply]
• Support using Teahouse link. Users coming from the Main Page are more likely to be newbies, so it makes sense to direct them to the forum designed for them. The Help Desk isn't going away for more experienced users. the wub "?!" 00:15, 19 May 2021 (UTC)[reply]
• Comment - There seem to be a roughly equal number of editors here second-guessing what links other people use, or are likely to use, and drawing diametrically opposite conclusions. Proof, if proof were needed, that none of us really know which idea is best. From a website design perspective, it might be a good idea to trial both links and include some kind of referer data. To borrow GreenMeansGo's suggestion, that might look something like this: Need help? Try our [[WP:THQ#RefMain|Help forum for new users]] or our [[WP:HD#RefMain|Help forum for more experienced users]] nagualdesign 19:47, 25 May 2021 (UTC)[reply]

nagualdesign The easiest way of tracking what links people actually click on would be to pipe the links through some statistical redirects, like we did when we wanted to see if anyone was using the COVID-19 banner. 192.76.8.73 (talk) 23:18, 25 May 2021 (UTC)[reply]

Great idea! nagualdesign 23:23, 25 May 2021 (UTC)[reply]

leave things until the Growth team featured are fully implemented

]

RfC: look of Authority Control

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following lists: Wikipedia style and naming Wikipedia technical issues and templates When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

Can the new style of the

• Support A, second choice B, as RfC initiator. After the RfC, there has been discussion and proposals on the template talk page, with the version as now (temporary) implemented in the "Arts" subtemplate as a compromise between the RfC results and some extras that were wanted (like accommodating multiple IDs from one institution, or keeping the explanatory link for some of the more obscure acronyms). Articles like
  Fram (talk) 07:42, 7 May 2021 (UTC)[reply
  ]
• Oppose – gives, in mainspace, way too much prominence to a rather technical aspect: the new design gives even more bandwith to this than the old design. Suggestions:
  1. In #Authority control above the question was raised whether we should have this template at all. That was already one of the points following from the previous RfC: I'd suggest to ask that question in a formal RfC (which may go in another direction than the current informal discussion), before this second RfC on the design goes forward.
  2. At Andy Warhol#External links (just taking the first example of the list proposed in the OP), the new design is shown *uncollapsed* under two collapsed navboxes: for Wikipedia these (internal) navboxes are far more important than the (external) unique identification (which can be handled by WikiData): *as a bare minimum* the new design should be shown collapsed, *at the very least* always autocollapsing when the article contains an internal navbox of whatever kind.
  3. The color scheme of the authority control box (new as well as old design) follows the standard color scheme of internal navboxes: the color scheme should be *different* (as in: a color scheme not normally used by internal navboxes) and *less conspicuous* (colors that draw not attention whatsoever), thus proposing to use only
     grey-scale
     background colours in the template (instead of the purplish background colors now). Authority control is a rather technical aspect (not really encyclopedia content as such), and such less colorful background colors would be a better indication for that.

--Francis Schonken (talk) 08:49, 7 May 2021 (UTC)[reply]

• Oppose – even leaving aside that the point of authority control is not the links to AC sites, but the unique identifier values, which this proposed design hides, the new design takes up too much space in too many cases, making multiple table rows where one is currently used, often with a single identifier on each - the proponents of this unnecessary change have acknowledged that they have done no research into how many such cases exist. It also removes links to Wikipedia articles which explain the origins and use of those identifiers (example on template talk page). The close of the previous RfC explicitly stated that there was "not any consensus on the exact form that an improved version might take." Insistence that anyone not approving the new design must provide alternatives is false; unless a better proposal is made and meets community approval, the status quo pertains. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:24, 7 May 2021 (UTC)[reply]
  • I don't think you will find many people who agree that the point of AC is the values, not the links. The links without the values (i.e. this proposal, and the one accepted at the RfC) is or can be useful to get extra information; the values without the links would just lead to this template being deleted(or at the very best hidden from view, like persondata in the old days) in the blink of an eye as utterly useless clutter. Nothing was "acknowledged" in the way you claim, and you fail to mention that "one is currently used" is a rather one-sided manner of presenting the current template, where you often have one "row" which is displayed over multiple "lines" anyway (depending on the number of entries obviously, and on your screen width and font size).
  • There is consensus, community approval, for a new layout much like the one proposed now, and there is community approval to get rid of the current version. Opposing the new layout without providing alternatives which respect the result of the previous RfC is just stalling to get the result you want, the already rejected status-quo.
    Fram (talk) 10:40, 7 May 2021 (UTC)[reply
    ]
    • "I don't think you will find many people who agree that the point of AC is the values" Perhaps; perhaps not. But anyone who has taken the time to understand what AC is will know that that is so, and that's what's important.
    • There was consensus for a vague proposal for an unspecified new layout, but as we all know, consensus can change, and now you need to demonstrate consensus for a specific proposal. People can choose that, or an alternative if one emerges, or the status quo if that is deemed to be the best option. So far, it is. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:53, 7 May 2021 (UTC)[reply]
• Oppose The issues discussed on the talk page need to be resolved first: in particular, the new template has a lot more whitespace than the previous one, and it doesn't include wikilinks to the relevant articles (and discussion on that talk page has been needlessly dramatic, which isn't a surprise given the people involved in this rewrite). My preference would be to go back to the previous version, which also showed the ID values (which is useful), and just change the acronyms to the words used by the new template, which meets the consensus from the previous RfC. Thanks. Mike Peel (talk) 10:34, 7 May 2021 (UTC)[reply]
  • Auto-collapsing would be even worse, since that would hide the content. Making it smaller, like the old version, is a far better solution. Thanks. Mike Peel (talk) 10:55, 7 May 2021 (UTC)[reply]
• Note: I have added options above, as "it's too big" seems to be the common theme here. @
  Fram (talk) 10:51, 7 May 2021 (UTC)[reply
  ]
  • You appear to have neglected to add "D: no change". Your RfC is no longer neutral, as is required. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:55, 7 May 2021 (UTC)[reply]
• And why has this new design been implemented, without consensus on the 14K articles using {{Authority control (arts)}}? That change described as a "Test" should be reverted immediately. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:06, 7 May 2021 (UTC)[reply]
  • I've reverted this since sandboxes should *never* be used in mainspace, particularly on so many articles. Mike Peel (talk) 11:26, 7 May 2021 (UTC)[reply]
    • Note that this now uses a fork of {{Authority control}}, at {{Authority control (arts) Master}}. If that isn't temporary, then probably Wikipedia:Templates_for_discussion/Log/2021_February_26#Template:ACArt should be revisited. Mike Peel (talk) 12:34, 7 May 2021 (UTC)[reply]
      • Of course that's temporary.
        Fram (talk) 12:42, 7 May 2021 (UTC)[reply
        ]
        • Just to note that this is at Wikipedia:Templates_for_discussion/Log/2021_May_7#Template:Authority_control_(arts)_Master. Mike Peel (talk) 13:14, 7 May 2021 (UTC)[reply]
• Note that, having learned from many previous experiences, I will not respond to comments from Pigsonthewing and Mike Peel, as they seem incapable or unwilling to post about the template without adding snide remarks or outright attacks on the people they don't agree with (just read their replies above, or other related discussions). Please take whatever they write here with a big grain of salt.
  Fram (talk) 11:10, 7 May 2021 (UTC)[reply
  ]
  • Note that this is untrue, however Fram has a long history of doing *exactly what they are claiming of Andy and me* in any discussion about Wikidata. This harassment has been going on for years now. It's generally better to focus on the facts than the drama, but unfortunately they can't help it. Mike Peel (talk) 11:21, 7 May 2021 (UTC)[reply]
  • And just 92 minutes later, Fram responds to Mike Peel. I mention this as it needs to be noted that Fram will respond when they choose to; which means that lack of response to other posts (such as my pointing out that their RfC is therefore no longer neutral; or that consensus specifically for what they are now proposing needs to be demonstrated)) is selective, and is not for the (bogus) reason stated immediately above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:01, 7 May 2021 (UTC)[reply]
• Fram, I think it would've been better to do the AC RfC at the top first. If AC is to be scrapped, or changed to a different form altogether, then spending time trying to redesign it is wasted. I think that this RfC is required (or such is felt) is somewhat IDHT - the will of the previous RfC on design was quite clear, so I don't really see why this is necessary. ProcrastinatingReader (talk) 11:16, 7 May 2021 (UTC)[reply]
• Oppose. Consensus has not yet been reached, as requested, @ Template talk:Authority control, so why are we having a premature RfC?
  • Oppose any change that entices auto-collapsing a 1-QID AC (see enticing comments already received).
  • Oppose incomplete wikilinks - on
    VIAF wikilinked, but Integrated Authority File, WorldCat, etc., not? Integrated Authority File
    doesn't mention "Integrated Authority File", so what is it?
  • Oppose dramatic size increase & gratuitous whitespace - on Claus Sluter#External links, {{Authority control (arts)/sandbox}} is THREE TIMES (~3.25x) the size of {{Authority control (arts)}}:

  ~ 

dgaf)  11:52, 7 May 2021 (UTC)[reply

]

• Why should there be consensus at the template talk page before starting an RfC here? It was obvious that no such consensus was possible there, with the same few people arguing against each other. The previous RfC (also started without consensus, and boy has that been complained about by you three) clearly showed that the opinion of you three is out-of-sync with that of many other editors. The time has come to gather wider input instead of clashing again and again about the same issues.
  Fram (talk) 12:15, 7 May 2021 (UTC)[reply
  ]

• "The time has come to gather wider input instead of clashing again and again about the same issues." - AKA
  dgaf)  12:52, 7 May 2021 (UTC)[reply
  ]

• So that's one OPPOSE and three SUB-OPPOSES? Would you like fries with that? — JohnFromPinckney (talk) 12:23, 7 May 2021 (UTC)[reply]

• COMMENT - I think this RFC needs to be put on “hold”... it is counter-productive, given that we currently have an open RFC (above) about whether to have any AC templates in our articles. It won’t matter what the template looks like if the consensus in the above RFC is to not have it at all. Blueboar (talk) 12:49, 7 May 2021 (UTC)[reply]
  • I don't see an RfC, but obviously if there's a proposal to remove this from 1-point-however-million pages, there would need to be (plus CENT, yada yada). — Rhododendrites ^talk \\ 13:07, 7 May 2021 (UTC)[reply]

    It's not an RfC yet per se. I wanted to 'test the waters', because I knew it would devolve into what it has, but wanted some time for some less involved people to opine, particularly on viable options. I guess by definition it'd be more suitable in the idea lab, but I don't know that place to be successful at achieving much, so wanted to try this. I don't think a normal RfC (i.e. a survey/discussion-style) would be conclusive, in part due to the persistent personalisations, so I'm still thinking on what form it should take. There's also some brainstorming going on by less involved parties and maybe that might help bridge some gaps between different views on this template. In any case, I obviously wanted to take some aspect of the proposal to an RfC... ProcrastinatingReader (talk) 13:21, 7 May 2021 (UTC)[reply]

    • Sorry, my bad... There is an ongoing discussion (above) about whether to have (or not have) the template at all, and I assumed it was an RFC. Thanks for pointing out that it isn’t.

So, I will change my comment to: “C” - something else (my preference would be to provide a simple link to Wikidata - similar to how we link to commons for images - instead of hosting the AC stuff directly in our articles) Blueboar (talk) 14:20, 7 May 2021 (UTC)[reply]

• A somewhat reluctant A, I guess. Not collapsed by default, but with whether it should be collapsed left to an article-by-article basis. Definitely open to C, too, if someone has other ideas. I don't fully agree with the closing statement of the last RfC. There was clear support for the RfC statement about making this template user friendly, but most people didn't actually speak specifically to the example provided (and many who did were highlighting issues with it). But that RfC is what we have, and nobody has challenged the close AFAIK. So we have the idea that we must make it more user friendly, and an example to use as a rough starting point for discussion of what that should look like. At the same, I think there are a lot of people who like the idea of user-friendliness but didn't really think about just how big that would make some of these templates. If the design of the old version of the template had one virtue it was being compact, of course. So I suspect the user-friendliness may make ultimately it easier for those who want to remove it from the page to convince others, ironically. We'll see, I suppose. — Rhododendrites ^talk \\ 13:07, 7 May 2021 (UTC)[reply]
• Support A This RfC constitutes forum shopping (by the opposers of the original RfC, not by Fram) in an attempt to overturn the clear consensus of the first RfC. As I wrote on the template talk page, the [original] RfC shows clear consensus that the sandbox is preferable to the status quo. That consensus should not be overturned by a few vociferous objectors on the talk page. Also weakly support B, on the grounds that, again quoting myself from the template talk page, I [see] no reason to deviate from the standard navbox behavior (of autocollapsing when there are two or more navboxes and not collapsing when there is only one navbox). * Pppery * _{it has begun...} 13:55, 7 May 2021 (UTC)[reply]
  • Fram starting an RfC (nor indeed later changing it to be non-neutral) is not me or anyone else forum shopping. When you wrote that on the talk page, I replied [emphasis in original]: The burden is on you to show consensus for the change you propose to make (and not just for a change). Note also that the RfC did not speak at all about the version currently in the sandbox, which was not presented there; indeed, it explicitly stated that there was "not any consensus on the exact form that an improved version might take.". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:54, 7 May 2021 (UTC)[reply]
• A, looking at the examples below. It is much more human-readable, and I'd call it an incremental improvement over the old template. I think the default auto collapsing behavior is fine (collapse when it's not the only footer template). I also think though that we should pursue an RFC based out of the earlier discussion here above, as there are some alternatives (like link to wikidata or an intermediate enwiki page) that could make AC redesign moot. Levivich ^harass/_hound 16:28, 7 May 2021 (UTC)[reply]
  • B is fine with me too per others below. Personally I don't think whether it's always collapsed or has the default behavior is a big deal for me. Levivich ^harass/_hound 21:13, 9 May 2021 (UTC)[reply]
• A - while I like authority control templates, I don't like the fact that they're so cryptic. This would be a big increase in usability at a relatively small cost of more "junk" at the bottom of a page. Guettarda (talk) 16:44, 7 May 2021 (UTC)[reply]
• B I don't think our readers actually use this template much, heck I can't remember the last time I actually used an authority control template. This template should stay out of sight and out of mind; if folks really want it they can uncollapse it. Frankly, the whole idea of Authority Control seems like something mostly for internal use, perhaps it would be best to put such templates on talk pages instead. CaptainEek ^{Edits Ho Cap'n!}⚓ 21:30, 8 May 2021 (UTC)[reply]
• B to the extent that we're doing this RfC, per CaptainEek. Second choice option A, because something slightly longer and... English... is better than something shorter and machine. ProcrastinatingReader (talk) 12:24, 9 May 2021 (UTC)[reply]
• B As per the comments above. Sea Ane (talk) 19:56, 9 May 2021 (UTC)[reply]
• B seems to the ideal compromise for providing extra and immediately available information to readers, without shoving it in their face. Of course, the more accessible layout is certainly desirable for our readers, who will be surely confused otherwise. Aza24 (talk) 20:12, 9 May 2021 (UTC)[reply]
• B with A as a close second. Per ProcrastinatingReader above. The new version is (I'm guessing) substantially more understandable to the overwhelming majority of people. Ajpolino (talk) 15:55, 14 May 2021 (UTC)[reply]
• B All of the new examples are less bewildering than any of the old ones. Autocollapse allows formatting into logical groups without being offensively large most of the time. Information remains available but unobtrusive. · · · Peter Southwood ^(talk): 08:22, 15 May 2021 (UTC)[reply]
• A (or possibly C but I don't have a suggestion myself, it's a hard problem!) I oppose autocollapsing: as many have pointed out the term "Authority control" is not well understood outside librarians, and hardly provides an explanation to the average user of why they might want to expand the template. If it starts expanded then at least it's very clear "oh, these are links/cross-references to other sites". Wikipedia is not paper, no trees will die from the extra space taken up, people will just need to scroll a few more millimetres to view the categories or the thrilling legal blurb of the footer. (I appreciate there are more issues with the size on mobile, but the template doesn't display there, and as far as I can tell there's no plans to make it do so.) the wub "?!" 16:52, 23 May 2021 (UTC)[reply]

Examples

From the template testcases page:

Old:

new:

old:

new:

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:21, 7 May 2021 (UTC)[reply]

Note: the above examples are fictitious, these ones don't appear on a real article. The RfC made sure that next to the 1 million examples of the old template, there were 14000 examples of the new template to be checked out on actual articles (as the previous RfC example was said to be "cherry-picked"), but the 3 main opposers of all these changes have reverted all efforts to do this, claiming "disruption" (the new version worked just as well as the version they reverted to, and showed the same number of ACs). Basically, the 3 defenders of the status quo are doing everything in their power to disrupt this (and the previous RfC, and the discussions at the template talk page). A very tiring situation, about which I started Wikipedia:Administrators' noticeboard/Incidents#Pigsonthewing et al.. Perhaps this RfC should be simply stopped and restarted then under the supervision of some neutral admins, to avoid further disruption. As it stands, the chances of getting anyone interested in participating in these shambles are slim, which was probably the intention.

The above examples are also, to use the terminology used against the previous RfC, cherrypicked. The testpages also contain some equally fictituous examples: vs.

And

vs.

Note that the large example you mention isn't fictitious, it's the actual authority control template used on Douglas Adams. * Pppery * _{it has begun...} 16:43, 7 May 2021 (UTC)[reply]

This is a proposal to make some restrictions on uploading new files licensed {{GFDL}}-only.^[1]

GFDL was originally designed for software manuals and it is not good for media because it makes it difficult to re-use the material (see comic to the right). Motivated by the the wish of making it easier to re-use files in compliance with the world-wide wiki-vision the Wikimedia Foundation Board decided in 2009 to stop using GFDL as a sole license while allowing importation of text without the GFDL license. The Wikimedia Foundation Board did not forbid GFDL for media files but encourages people to use licenses other than GFDL, for example CC licenses.

The Wikimedia Foundation Board explicitly mentioned that each wiki could restrict the use of GFDL. The English Wikipedia has removed GFDL from MediaWiki:Licenses and MediaWiki:Licenses/en-ownwork but it is still possible for users to add it manually.

In September 2018 is was suggested to deprecate the GFDL license but at the time no consensus could be formed to limit GFDL on the English Wikipedia.

Some of the arguments against the restrictions were:

1. We have a lot of non-free files so why should we not allow GFDL?
2. If we find media that is licensed GFDL we won't be able to copy it to Wikipedia.

Re 1) The idea of a wiki is to share knowledge freely. That is the reason we have Wikipedia! Non-free content is an exception per the licensing policy. It is something a community may decide to have (not must) but the use must be minimal. So while we have non-free files that is not a reason to allow anyone to license their uploads with a license that isn't quite in the spirit of sharing free knowledge. We also don't allow CC BY-NC or CC BY-ND.

Re 2) Technically true, but the use of GFDL for media files is virtually (if not completely) nonexistent outside Wikimedia. When files are uploaded as GFDL in 2021 it is either because it is a copy or a derivative of another file from another wiki-project or because the uploader has specifically chosen to use GFDL.

Several projects already have restricted the use of GFDL, for example Japanese Wikipedia, Commons and Wikivoyage. Other projects are likely waiting to see what English Wikipedia does.

The suggestion is this:

GFDL is not permitted as the only acceptable license where all of the following are true:

• The content was licensed on or after 1 July 2021. The licensing date is considered, not the creation or upload date.
• The content is primarily a photograph, painting, drawing, audio or video.
• The content is not a software logo, diagram or screenshot that is extracted from GFDL software or^[2] a GFDL software manual.

The above does not restrict non-free usage of content. If a work that is not a derivative work with a GFDL license is used under a non-free rationale, it doesn't have to be scaled down but other non-free limitations will still apply.

The theoretical possibility of future GFDL-licensed content that would be eligible for non-free inclusion has been brought up as an argument in the past and this is a compromise that will hopefully mitigate that.

I'm not a native English speaker so if there are typos or bad wording you are welcome to fix. Thank you! --MGA73 (talk) 16:37, 10 May 2021 (UTC)[reply]

]

^ Some voters expressed a desire to restrict GFDL for Wikimedians but not for external sources. Since many Wikimedians are active on other self-published sources like photo sharing sites, social media or blogs, this would be very difficult to enforce. However, we'd like you to know that if a source for fresh GFDL-content is found in the future outside Wikimedia (this is purely theoretical, we know of no such source today), it is always possible to have a new vote to create an exception for that specific source. — Alexis Jazz (talk or ping me) 16:42, 14 May 2021 (UTC)[reply]

• Oppose. We are the free encyclopedia. That means, as far as files are concerned, that any license that is free enough will do. What constitutes a free enough license is defined by the foundation:Resolution:Licensing policy, referring to the Definition of Free Cultural Works (1.0), and GFDL fully meets these these requirements. That Commons no longer allows GFDL-only files is an excellent reason to allow them to be uploaded locally here. The "free" in the free culture movement includes the freedom to choose between equally free licenses. – Finnusertop (talk ⋅ contribs) 17:03, 10 May 2021 (UTC)[reply]

  Thank you for your comment. I would like to point out that it was the Wikimedia Foundation Board that decided in 2009, that GFDL should not be used on wiki projects. If anyone know what "we" are it must be the Wikimedia Foundation Board? Commons continued to allow GFDL for 9 years before they fully implemented the resolution. Do not blame Commons for the resolution if you disagree with it. --MGA73 (talk) 17:59, 10 May 2021 (UTC)[reply]

  It decided it would stop allowing it on uploads as the sole license. At no point did it decide that it 'should not be used on wiki projects'. You would make your point better if you did not state outright falsehoods. Only in death does duty end (talk) 18:15, 10 May 2021 (UTC)[reply]

  Sorry it is was not clear. I'm only talking about future uploads. Files allready uploaded can of course stay. Thank you for letting me know. --MGA73 (talk) 19:29, 10 May 2021 (UTC)[reply]

  @MGA73: The 2009 resolution implemented meta:Licensing update, which switched licensing of text contributions from GFDL-only to GFDL + CC BY-SA. It continued to allow files under any free license but encouraged to dual license existing GFDL-only files under CC BY-SA where possible. It neither ruled that already uploaded GFDL-only files "should not be used on wiki projects" nor that future uploads under that sole license should not be allowed. The way English Wikipedia implemented it is that "All media licenses existing before the transition remain valid and acceptable to the Foundation. However, the community may choose to modify or restrict the licenses it encourages people to use. For example, emphasizing CC licenses in the upload form and de-emphasizing GFDL licenses." I am not sure if it even allows us to completely deprecate a free license (that's more than just "de-emphasizing" one). Even if it does, I'm of the opinion that we should allow free licenses of files to the maximum extent possible. It's not about which licenses are better/more ideal, but which licenses are free, and that has already been settled since the 2007 resolution which the 2009 one in no way overruled. – Finnusertop (talk ⋅ contribs) 13:38, 14 May 2021 (UTC)[reply]

• Support. The link Finnusertop provides links to [3] from where you end up at [4] which also notes the problem with GFDL. Finnusertop speaks of allowing "GFDL-only files" to be uploaded here so they won't be homeless. The reality is that without Wikimedia, GFDL-only licensed photos wouldn't exist to begin with. Not all free licenses are equal. One could even make up a completely ridiculous but technically free homebrew license, and I can only hope we'd reject it if that happened. GFDL is a relic of the past. It served a purpose, once. It no longer does, it has been superseded by better licenses. GFDL is not a practical license for visual media (like photos) and there is literally no reason for a photographer to license their photos as GFDL other than to pester re-users. We shouldn't allow photographers to pester re-users. — Alexis Jazz (talk or ping me) 18:01, 10 May 2021 (UTC)[reply]
• Support. The GFDL is free, and I don't think anyone here is questioning that. The GNU FDL is perfect for free software documentation, as well as any other text where the list of contributors is not as large as Wikipedia's. But this is not the case for media (especially photographs), where it's very impractical to use. We are supposed to make knowledge easier to disseminate. The GFDL doesn't allow that for media. Even the FSF has acknowledged the impracticality of the FDL on those media, which is why they released FDL 1.3 in the first place.

  I'm okay with the compromise that has been put here. I don't see any reason to restrict the resolution of a solely GFDL-licensed medium. But we certainly should discourage solely using the GFDL for non-text, non-software media. pandakekok9 (talk) 05:24, 11 May 2021 (UTC)[reply]

• I'm somewhat meh on this. On the one hand, we shouldn't be afraid of trying to clean up relics of the past to simplify the maintenance burden, and GFDL is clearly a relic of the past. However, because of past media uploaded with it, we'll never be able to get rid of it completely. It appears that we've already done what we can to discourage its use by making it super far from the default. Given that, the number of files being uploaded via GFDL is likely tiny. If someone really wants to use it for some reason and won't contribute their work otherwise, then sure, I hope we'll decide to take the work. But hopefully pretty much everyone will just go and put it on Commons under CC. {{u|Sdkb}} ^talk 05:41, 11 May 2021 (UTC)[reply]
• Support. I see no drawbacks and even WMF itself is saying it's not ideal for image media. SpartaN (talk) 05:52, 11 May 2021 (UTC)[reply]
• Too early to just prohibit GFDL, instead deprecated and discourage it for a year, especially with an edit filter warning. After a year we can evaluate whether it is still needed at all and prohibit if it really is useless. Graeme Bartlett (talk) 10:14, 11 May 2021 (UTC)[reply]

  @Graeme Bartlett: Thank you. The license was removed as a suggested license in 2009: Special:Diff/294994426. So it has been discouraged for almost 12 years now. --MGA73 (talk) 13:40, 11 May 2021 (UTC)[reply]

• Support This is years overdue, how are GFDL-only licenses still allowed here? GFDL really isn't suitable for images, and GFDL-only uploads haven't been allowed on Commons since 2018! Thanks. Mike Peel (talk) 10:50, 11 May 2021 (UTC)[reply]
• Meh leaning support, how many GFDL only uploads have we had in the past 12 years? —Kusma (t·c) 14:23, 11 May 2021 (UTC)[reply]

  @Kusma: Thank you. My guess is around 1380 files. --MGA73 (talk) 19:34, 11 May 2021 (UTC)[reply]

  MGA73, thanks. The vast majority of these seem rather old, with very few exceptions such as File:RitwikSanyal1.JPG (which is a new upload overwriting an older one GFDL licensed in 2010). Incidentally, the "Upload a new version of this file" dialog doesn't do a good job at checking that the license of the new and old files are identical. —Kusma (t·c) 20:44, 11 May 2021 (UTC)[reply]

  MGA73, actually far less. Kusma asked about the last 12 years. (so since 2009) Files older than that which weren't eligible for relicensing would also be included in your query. Who hopper.png was actually PD-self (maybe the uploader was confused?), File:Poktori-2.jpg is PD-self, File:Chuck Close 1.jpg is nonfree, File:Paullusmagnus-logo.JPG comes from m:File:Paullusmagnus-logo (small) reloaded.png and is GFDL-presumed and would be eligible for relicensing as CC BY-SA 3.0 if we accept the GFDL-presumed, this isn't own work?, File:Shared interest lending diagram.PNG was incorrectly tagged as not being eligible for relicensing, File:Tenka Qing.png is identical to w:ja:ファイル:Tenka Qing.png so also incorrectly tagged as not being eligible for relicensing, File:Pb0.9.2 (r86)Win7.PNG is GPL I guess, File:Fence Lake Monument.jpg is also PD-self. And so on. Excluding false positives, overwrites where the original upload is eligible for relicensing but the overwrite isn't and uploads from 2009 and 2010 when some uploaders just weren't aware yet of the license migration, only a small fraction would be left. — Alexis Jazz (talk or ping me) 21:54, 11 May 2021 (UTC)[reply]

  @Kusma and Alexis Jazz: I know the number can be discussed. There are also files that are moved to Commons, deleted or where the uploader have later agreed to relicense. I hope everyone will accept if GFDL is no longer accepted for new uploads and therefore use a cc-license. --MGA73 (talk) 07:30, 12 May 2021 (UTC)[reply]

• So, I'm supportive of not allowing new original works in GFDL only; but not so supportive of relegating uploads of existing GFDL works found elsewhere to non-free/fair-use only status. — xaosflux ^Talk 14:41, 11 May 2021 (UTC)[reply]

  @Xaosflux: Thank you. If existing works are licensed GFDL today they can still be uploaded as GFDL. Also in 2 months or 2 years from now. --MGA73 (talk) 19:21, 11 May 2021 (UTC)[reply]

  Xaosflux, if it was licensed before 1 July 2021 you could still upload it, even after 1 July 2021. If it was licensed after 1 July 2021.. Just try to find something that was recently licensed as GFDL outside Wikimedia. I'll be surprised if you find anything. IIRC, some years ago a Wikipedian convinced an organization that didn't want to release their work with a free license to release some work under the GFDL because the terms would complicate/inhibit re-use anyway, so they wouldn't have to worry much about those pesky re-users. Errr, yeah. notafish advocated for this all the way back in 2005: Why the Wikimedia projects should not use GFDL as a stand alone license for images. — Alexis Jazz (talk or ping me) 19:40, 11 May 2021 (UTC)[reply]

  @Alexis Jazz: so if we are not going to purge the ones we have or consider them non-free, and they would be a rarity -- why would we need to prohibit them? What problem is that solving? I'm fully supportive that any editor-created images should be CCBYA (and really, they should be uploaded to commons not enwiki unless there is some esoteric non-article related reason). — xaosflux ^Talk 19:57, 11 May 2021 (UTC)[reply]

  Xaosflux, we don't want to name and shame, but there are photographers who either multi-license their work with GFDL+CC BY-NC knowing full well the GFDL is largely useless for commercial use of a single image in a printed publication or who will hang on to GFDL until it is no longer allowed to either make a point about GFDL being a bad license (some will know who I'm talking about) or out of some sort of misplaced nostalgia. Not being able to completely dry the room doesn't mean we shouldn't stop people from using the faucet above the broken sink. Use of GFDL-only images in articles can only decline after we've sealed the faucet. — Alexis Jazz (talk or ping me) 20:34, 11 May 2021 (UTC)[reply]

  I'm not convinced this is a problem in need of solving, if that photog is an editor - then sure, lets say they can only upload their own work under CCBYSA; If you find one of their pics and think it is useful to include then I don't think we should stop you from uploading it though. — xaosflux ^Talk 20:57, 11 May 2021 (UTC)[reply]

  Xaosflux, I guess I was unclear. All the photographers I'm talking about are Wikimedians. One does not find GFDL-licensed photos outside Wikimedia. — Alexis Jazz (talk or ping me) 21:59, 11 May 2021 (UTC)[reply]

  @Alexis Jazz: well - you could, but in any case I'd be fine with the next step being that we disallow anyone to upload their own work here with only a GFDL license. — xaosflux ^Talk 23:10, 11 May 2021 (UTC)[reply]

• Support GFDL was always a poor fit for images. It is
  designed for manuals, textbooks, other reference and instructional materials, and documentation which often accompanies GNU software... it can be used for any text-based work, regardless of subject matter. (bold mine). It was used for images in Wikipedia's early days because the Creative Commons licenses didn't exist yet. Once CC became fully developed and it was clear that CC was a better license for use on images, the WMF wisely began the process of migrating image licensing policy to favor CC licensing. Basically, the GFDL was a poor tool to fit the purpose, but was all that we had in 2001 when Wikipedia was founded. When better tools came along, it was no longer needed as a tool. Other than legacy images which have been licensed with only GFDL before we change the policy, we should deprecate any future uses of the license. --Jayron32 14:47, 11 May 2021 (UTC)[reply
  ]
• Support. Flickr does not offer GFDL licensing on uploaded images. Google does not show GFDL licensed images in their "free images only" tools on Google Images. GFDL itself is intended for "manual, textbook or other document"s. For these reasons, we shouldn't allow images solely licensed under GFDL - because not only are they limiting the reuse on Wikipedia, it prevents other image hosting sites from reusing our images as part of their repositories. However, I do not think it should be deprecated as a whole - as long as someone chooses to license their image under another acceptable free license (or to the public domain/CC0), they should be permitted to also select GFDL and license it that way. Furthermore, images licensed only under GFDL should continue to be uploadable, and I do not believe that they should be considered fully "non-free content". If a GFDL image is the only one that is able to be found for a purpose, even if a freer image could be created, I think that the non-free content criteria should accommodate using a GFDL licensed image as opposed to relegating it to the strictness of those criteria - but not a full relaxation thereof. Part of the Wikimedia movement is to encourage free access to information - and we are not accomplishing that by considering the GFDL, with its onerous and strict terms for abiding with attribution, the same as a CC license. The GFDL is great for its purpose - especially when considering digital documentation/media that can easily contain a plethora of required attribution/copying elements without it becoming unusable - but that is not what we consider "free". -bɜ:ʳkənhɪmez (User/say hi!) 22:06, 11 May 2021 (UTC)[reply]
• Support, mainly per Alexis Jazz. GFDL-only is a bad license for images, and it's now obsolete. No reason to continue to allow it, especially since the only people who use GFDL-only for images are Wikimedia editors. In effect we continue to perpetuate a bad copyright practice that doesn't exist anywhere else. Regarding fair use concerns, I think they are mostly theoretical, again since the only people who might ever want (and ever do) upload a GFDL-only image to Wikipedia are Wikipedia users themselves and they upload their own work. The likelihood that we are going to find an image somewhere on the web licensed as GFDL-only that we may want to upload here (as fair use or as a free image) is quite small. But for formal purposes I'd be perfectly fine explicitly specifying that if someone wants to upload a GFDL-only licensed image as a fair use image, that's allowed and that in this situation GFDL-only will be treated the same as a non-free license. Nsk92 (talk) 23:57, 11 May 2021 (UTC)[reply]
• Oppose per
  WP:CREEPy instruction set about if you uploaded before or after this date is just adding adding more needless confusion to the process that we say we want to remove by getting rid of "3 pages" of licensing. Except, the 3 pages have already been determined to be "free enough" so there is no confusion, but the new policy would bring plenty of confusion while people attempt to make "determinations" about already existing media. I can see all the disputes happening already... Huggums537 (talk) 01:47, 12 May 2021 (UTC)[reply
  ]

  @Huggums537: Thank you for your comment. I agree that we should make things as simple as possible. But I think that the only way to make it more simple is to reduce it to "GFDL is not allowed!". I know you oppose but if you had to chose between those 2 alternatives which one do you think is the best (or the least crappy)? --MGA73 (talk) 07:43, 12 May 2021 (UTC)[reply]

  Forgive me, but exactly which 2 crappy alternatives are you asking me to choose from? Huggums537 (talk) 10:10, 12 May 2021 (UTC)[reply]

  @Huggums537: First alternative is my original (the one you call CREEPy) and the second alternative is "GFDL is not allowed.". --MGA73 (talk) 10:22, 12 May 2021 (UTC)[reply]

  Ok. Got it. I vote for a third alternative, just leave things as they are because you can't very easily add free software with a Creative Commons, but you can with a GFDL. This proposal overlooks that fact. Huggums537 (talk) 10:28, 12 May 2021 (UTC)[reply]

  @Huggums537: Thank you. But the proposal is that software licensed GFDL can still be uploaded to Wikipedia as GFDL. --MGA73 (talk) 12:02, 12 May 2021 (UTC)[reply]

  Yes, I understand your point, but I read your proposal differently because educational and/or instructional software as well can oftentimes also be primarily categorized as video or audio, so the proposal as it is written could cause those softwares to be excluded. These are the kinds of softwares I was thinking of that might get overlooked, but there very well may be other factors that have not been taken into consideration. Huggums537 (talk) 14:29, 12 May 2021 (UTC)[reply]

  GPL. Before that, the manual that came with free software was typically licensed under the free software license, which was odd because reasons. Software itself does not get licensed as GFDL. — Alexis Jazz (talk or ping me) 14:56, 12 May 2021 (UTC)[reply

  ]

  Okay, that addresses a lot of my concerns, and I still do think the Creative Commons is a better license for photos. I'm just not convinced it's better for audio or video or even drawings since they can be comprised of illustration such as flow charts and blueprints etc. You can find a good example of the confusion I'm talking about if you do a Google search for Harry Potter wizarding world DVD game, then try to make a determination whether it should be classified as a DVD video, a software video game or perhaps either or both. Huggums537 (talk) 15:38, 12 May 2021 (UTC) An even better general example that I can think of is a document called an electrical schematic which could be interpreted as both a drawing and/or a manual. Huggums537 (talk) 16:30, 12 May 2021 (UTC)[reply]

  The distinctive aspects of the GFDL is the requirement to maintain some of the identity of the original—the specified cover text, any specified invariant sections, and the acknowledgment or dedication sections—while also requiring the modified version to distinguish itself from the original with a different title. For audio or video recordings, frankly I think it would be preferable for someone to craft a new free licence that appropriately takes into account the attributes of those media. For a schematic, sure, issue it within a document that already complies with the GFDL. isaacl (talk) 19:58, 12 May 2021 (UTC)[reply]

  I guess that makes sense. Another good example is blueprints because they are architectural drawings, but also construction manuals. Huggums537 (talk) 20:14, 12 May 2021 (UTC)[reply]

• GFDL only makes sense for printed works that can contain within themselves the sections required to be preserved by modified versions, as the licence assumes this context. At a minimum, this means a title page, copyright and licensing page, and history section. I think it is reasonable to restrict its use to files that already contain within themselves a title page, a copyright and licensing page, and if the file is a modification of an earlier one, a history section. Thus even for an image extracted from a GFDL book, I think the uploaded work should contain within itself a title, copyright and licensing, and history pages, either within the image or with everything bundled together in a document file format. This would make it easier for re-users to comply with the licensing terms. isaacl (talk) 02:17, 12 May 2021 (UTC)[reply]

  That is a very reasonable argument. However, the argument could also be made that the title of a photo technically constitutes a "title page", and the revision history of the photo a "history page" while licensing does not need to be within the photo itself, unlike other media such as film or software. On the flip side of this argument, we could allow media such as film and free software under a GFDL license because they have titles, revision histories (maybe not so much in film), and licensing within them. Huggums537 (talk) 10:05, 12 May 2021 (UTC)[reply]

  @Huggums537: yes we could. But the question is why should we? WMF conluded in 2009 that GFDl is not good for Wikipedia so they decided not to use it as the sole license. There are better alternatives so why not use them? --MGA73 (talk) 10:32, 12 May 2021 (UTC)[reply]

  Because in the case of drawings, audio, and video this could be instructional or educational in nature such as a type of course work that is more suitable to a GFDL license than Creative Commons for the authors. While we are a "free knowledge" site even CC acknowledges authorship [through attribution]. Huggums537 (talk) 10:49, 12 May 2021 (UTC)[reply]

  If you squint just right, and turn your head just so, you can sort of invent ways for other forms of media to have equivalents to the sections described by the GFDL. (For a photo distributed as its own individual work, separate web pages is not one of them, as the license refers to sections and pages of the document itself. Also reproducing the license in full within the document is mandatory.) But the fact remains that the licence was written assuming the context of a printed work with specific sections contained within the document, and thus it makes most sense to limit the use of the license to works within this context. isaacl (talk) 14:42, 12 May 2021 (UTC)[reply]

• Support GFDL is impractical for new content, and if people practically can't reuse our content, then it's not really free (as in freedom). It is important that we have an exception for legacy content though like Commons has, as there is a lot of legacy early 2000s content out there that was licensed as GFDL just because it was the popular license at the time (I uploaded some to Commons a few months ago). Legoktm (talk) 15:29, 12 May 2021 (UTC)[reply]
• Support. Ruslik_Zero 20:47, 12 May 2021 (UTC)[reply]
• Oppose. "Is it helpful? Is it necessary? Is it kind?" Does this solve an actual problem Wikipedia has? Or only an imagined one, that will make uploading (and RE-uploading) relevant media more difficult? Does this improve the encyclopedia or its usability or its RE-usability? If not, vote NO. 71.62.227.79 (talk) 02:52, 13 May 2021 (UTC)[reply]

  Does this solve an actual problem Wikipedia has? Didn't want to name and shame, but I guess there's no avoiding it eventually. Here's an example. that will make uploading (and RE-uploading) relevant media more difficult? GFDL hasn't been a default option for years. Licensing date counts, not the upload date. Is it necessary? Is it kind? If you simply don't care, why require a license at all? Even easier. Yes, it's necessary. or its RE-usability? Yes, that one. See this real-world example from notafish and the comic above. — Alexis Jazz (talk or ping me) 04:27, 13 May 2021 (UTC)[reply]

• Strongly oppose. I use the GFDL because I have frequently seen images I uploaded under Creative Commons used outside Wikipedia without attribution because it is widely assumed to be equivalent to public domain. I no longer upload my photos to Commons because they adopted a proposal like this. Jonathunder (talk) 16:41, 13 May 2021 (UTC)[reply]

  Lots of people erroneously assume that Wikipedia's text is PD and violate the license. Doesn't mean we should go back to GFDL only for the text. —Kusma (t·c) 16:51, 13 May 2021 (UTC)[reply]

  Thank you for your comment. Sadly there are always someone that do not care about copyright. I do not think that it makes much difference to them if you add CC or GFDL. May I ask if there is always attribution for the files you have licensed GFDL? --MGA73 (talk) 17:20, 13 May 2021 (UTC)[reply]

• Strongly oppose per Finnusertop, 71, and Jonathunder. We should not be restricting the use of free licenses because a sister project does (and quite a few people have complicated relationships with that sister project); banning GFDL uploads because Commons does makes about as much sense as switching to CC-BY because Wikinews uses it. As an active editor at Wikivoyage, that comparison is in turn totally inappropriate, because Wikivoyage has completely different goals to Wikipedia and GFDL text licensing genuinely does serve it poorly; Wikivoyage articles are intended to be used in print more often than Wikipedia ones (see our goals and non-goals and our guide for Wikipedians working cross-project), where printing out the GFDL license is a much bigger concern. However, files uploaded locally to the English Wikipedia are implicitly intended for use on the English Wikipedia, a project with very little focus on print; they may be used in many places, including as print images, as their free license encourages, but the situation depicted by that comment or described by Wikivoyage is downplayed because it simply isn't the original use case. GFDL is a free license, and while we perhaps don't encourage it as strongly as our preferred ones, we can use it just as any other. Banning GFDL uploads because they're 'outdated', as some have encouraged here, makes as much sense as banning CC-BY/CC-BY-SA 1.0 or 2.0 ones for the same reason, and I can tell you there are many useful files with those licenses. Vaticidalprophet 09:32, 14 May 2021 (UTC)[reply]

  @Vaticidalprophet: Thank you for your comment. You should not restricting GFDL because Commons did. You should restrict it because the Wikimedia Foundation Board and many other agree that GFDL is not a good license and it does not match the vision of Wiki. Also I think you are wrong about photos uploaded to English Wikipedia. They are very often copied to other projects and used there. There is no such thing as "for Wikipedia". The purpose of Wikipedia is to share with everyone!

  I think that if the only reason to keep GFDL is because "Commons is stupid" then it is not a good reason at all! --MGA73 (talk) 11:34, 14 May 2021 (UTC)[reply]

  There is no such thing as "for Wikipedia". The purpose of Wikipedia is to share with everyone! Then it's a good thing I said exactly that, then, isn't it? Wikipedia content is intended to be shared under a free license, not "a free license except this one because it might be awkward". Wikivoyage has a completely different purpose to Wikipedia as regards GFDL compliance, i.e. it's intended to be used in print form, and so "GFDL might be awkward in print" is an actual strong argument. Commons is an intended dedicated image repository, and images hosted on it are being used for that purpose, while Wikipedia is not an image host, and images hosted on it are targeted at Wikipedia articles; that's not to say they can't/shouldn't/won't be shared elsewhere, because they're free images under free licenses, but it does mean "this might be awkward to use in a certain form it's far less likely to be used in than these other random things" is a singularly unconvincing argument. Banning GFDL for new uploads can only hurt Wikipedia's free mission, it cannot help it, because it would only serve to prevent the uploads of files licensed under a free license. There is absolutely no circumstance where banning a free license for reasons of "it might be awkward to use in a specific way" is helpful towards a free mission, ever. Also,

  there is no need to respond to, let alone ping, every opposer. Vaticidalprophet 11:42, 14 May 2021 (UTC)[reply

  ]

  Sorry you see it that way and noted your point. I try not to repeat myself. When I comment or ask it is because I would like to hear the arguments. I do not claim always to be right and if someone make the right arguments I might even withdraw my suggestion. As you can see it has been modified a bit because it was unclear. --MGA73 (talk) 12:27, 14 May 2021 (UTC)[reply]

  makes as much sense as banning CC-BY/CC-BY-SA 1.0 or 2.0 ones for the same reason There is a compatibility mechanism for CC 2.0 with newer versions. There is no compatibility for the 1.0 license, but: CC-BY 1.0 includes "credit reasonable to the medium", so unlike GFDL it is feasible to comply with the license terms. Also I have never seen any not-ancient content with a CC 1.0 license. (unlike 2.0 which is still commonplace because of Flickr) — Alexis Jazz (talk or ping me) 17:16, 14 May 2021 (UTC)[reply]

• Oppose I would support a limitation on GFDL for Wikipedian-created content, but if we are reusing a third-party's work that happens to be licensed GFDL and it otherwise meets all other appropriate factors, I do not see any reason to limit that use. We should not be cutting off a potential source simply because of all the free licenses they could have used they used one that's not the best option for images, but otherwise still compat with "free license" otherwise. --Masem (t) 13:26, 14 May 2021 (UTC)[reply]
• Weak oppose per above, modulo the fact that I believe the GFDL is not a "free" license. If someone uses GFDL-only, just ask them to dual license and give them the reasons why it is helpful; we don't need to create more convoluted rules that no one will read. If something is suitably licensed and improves the encyclopedia, we should be able to use it. — Wug·a·po·des​ 23:42, 14 May 2021 (UTC)[reply]
• Support, very well thought out proposal that's worth enacting. It's also better late than never to follow the WMF's guidance. Setting the restriction based on license date, not upload date, is a reasonable way to allow older material while cleaning things up for the future. I agree with Alexis Jazz that this restriction can always be revisited if a significant amount of fresh GDFL content appears in the future. -M.Nelson (talk) 14:12, 15 May 2021 (UTC)[reply]
• Weak Oppose the GFDL is clearly suboptimal for images to put it mildly, and it's nice to be able to copy things to commons so other projects can take advantage of them. That said I don't like the idea of rule creep here; we can always request dual-licensing, and if someone really only wants to contribute images under the GFDL that's not ideal but it's still improving the encyclopedia and I see no reason to stop them. Regards, 31.41.45.190 (talk) 01:56, 16 May 2021 (UTC)[reply]
• Note that most of the concerns raised by the opposers here have already been solved by the compromise put up here. Let me highlight that part:

  The above [proposal] does not restrict non-free usage of content. If a work that is not a derivative work with a GFDL license is used under a non-free rationale, it doesn't have to be scaled down but other non-free limitations will still apply.

  The theoretical possibility of future GFDL-licensed content that would be eligible for non-free inclusion has been brought up as an argument in the past and this is a compromise that will hopefully mitigate that.

  Material that is solely GFDL-licensed after the cut-off date of 1 July 2021 can still be used in the English Wikipedia, just under a non-free rationale. And they are exempted from the resolution limit. So before opposing this proposal, please check first if your concern has already been resolved by the said compromise. pandakekok9 (talk) 05:52, 16 May 2021 (UTC)[reply]

Your solution is to use a non-free rationale for freely licensed media. Thats ridiculous. Only in death does duty end (talk) 13:45, 16 May 2021 (UTC)[reply]

@Pandakekok9: Exactly what OID said, I saw your proposal it just didn't make any sense, sorry. Regards, 31.41.45.190 (talk) 14:21, 16 May 2021 (UTC)[reply]

It makes no sense to require a non-free rationale for content that shares the same license as our text. Beyond that, we have enough trouble getting people to properly use non-free rationales for stuff that is completely non-free so I'm suspicious expanding its use to copyleft media will do anything more than confuse people further. It's a clever idea, and I'd prefer it over forbidding them entirely, but it doesn't resolve my concerns. — Wug·a·po·des​ 22:06, 16 May 2021 (UTC)[reply]

This is a misunderstanding of our licensing. The only contributions which are actually dual-licensed are those which came before the date we switched to CC BY SA 3.0. The contributions made after are solely CC by SA 3.0. (Generally anyway, a few people dual license CC and some others after that date.) See our reuse page. Going by the counts at Wikipedia:Size_of_Wikipedia, that means there are some 3.5 million articles which are CC BY SA 3.0 alone. Izno (talk) 00:43, 17 May 2021 (UTC)[reply]

@Izno: I was going off the text at the bottom of my editing box which says By publishing changes, you agree to the Terms of Use, and you irrevocably agree to release your contribution under the CC BY-SA 3.0 License and the GFDL (emphasis added). This text seems based on our (legally binding) terms of use, specifically foundation:Terms of Use/en#7. Licensing of Content which by my reading says that all our content is available under the GFDL and Re-users may comply with either license or both. I haven't gone through the history of our ToS, but unless that was recently changed the entire (text of the) encyclopedia is available under the GFDL. — Wug·a·po·des​ 01:34, 17 May 2021 (UTC)[reply]

Oh gosh, the inconsistency. The Meta FAQ on the point is interesting, as is the introduction to the update itself. Maybe I'm the one reading it wrong. Izno (talk) 02:12, 17 May 2021 (UTC)[reply]

See meta:Licensing update/Questions and Answers#Replacing GFDL with CC-BY-SA?. As per GFDL, modifications of older GFDL content has to continue to be available by GFDL. For completely new content, say a new article, individual editor contributions are made on the basis of dual licensing. But with the licensing update, there is the option to import a purely CC-BY-SA-licensed work from an external source. The resulting content would only be licensed CC-BY-SA, since it would be incorporating non-GFDL content. isaacl (talk) 02:31, 17 May 2021 (UTC)[reply]

Isaacl, As per GFDL, modifications of older GFDL content has to continue to be available by GFDL. Technically what you say is correct, but it doesn't apply here. Talking about the wikitext, it has been relicensed as CC BY-SA 3.0. So modifications of that content can be published with a BY-SA and/or GFDL license. We could simply abandon GFDL for wikitext completely without repercussions. — Alexis Jazz (talk or ping me) 03:09, 19 May 2021 (UTC)[reply]

I stand corrected: it's true the Wikimedia Foundation could set a cutover date where the snapshot of Wikipedia at that time is made into a derivative work following the terms of the CC-BY-SA licence, and so going forward, all text content would be relicensed soley as CC-BY-SA. isaacl (talk) 05:11, 19 May 2021 (UTC)[reply]

• Support The restrictions of the GFDL, when applied to most files, are sufficiently restrictive for the license to be less free than what we would otherwise expect. --AntiCompositeNumber (talk) 01:49, 18 May 2021 (UTC)[reply]
• Strong support. Visual media that are licensed solely under the GFDL do not meet the definition of a free cultural work. In particular, the freedom to copy and redistribute the work must be "practical" and "without any risk". This change is long overdue. Kaldari (talk) 20:08, 20 May 2021 (UTC)[reply]
• Strong support - doesn't meet free standard and can't be used on Commons and thus other wikiprojects. This decisively makes the work non-free for all intents and purposes. This shouldn't even be a tough call. Magog the Ogre (t • c) 23:20, 24 May 2021 (UTC)[reply]
• Support. GFDL is waaayyy too easy to abuse. For example, let's say I have this picture of a fetal pig I took in Forensics class one day. It's my work, and I want to use it on our article on fetal pigs except I want to punish re-users just because I can. Besides forcing people to provide a copy of the license (just for using my singular picture of a fetal pig), here's what else I can do:
  1. Use {{GFDL-self-with-disclaimers}} to require re-users provide a copy of all our disclaimers. See Wikipedia:GFDL standardization.
  2. Mark my userpage as a "Cover text" which means it is also required to be included.
  3. Add a bunch of invariant sections. These are basically appendices which have to be included in every re-use in order to remain compliant with the license. I am not aware of any restrictions regarding the use of invariant sections.

  I don't think anyone should be allowed to do this. –MJL ‐Talk‐^☖ 01:16, 25 May 2021 (UTC)[reply]

  I can see the disclaimers thing, but I'm not sure whether you're allowed to use the latter two on Wikipedia. Wouldn't that already make the work undisputably nonfree? If such things are allowed on Wikipedia all this time, we are facing an even larger problem than before. pandakekok9 (talk) 10:37, 30 May 2021 (UTC)[reply]

• There have been questions about the number of files and also some said that we should not say no to freely licensed files from external sources. So I checked a bit to find out more about the files. Sadly there is no easy way to find information about deleted files so the numbers below does not include deleted files (copyvios, orphan files no longer usable and files moved to Commons).

As of today there are 1,343 files in Category:Wikipedia license migration not eligible that have no creative commons license. It is fewer than the 1380 I mentioned earlier but some have been deleted as copyvios, some was licensed wrong and a few users relicensed.

999 files are own work (have the templates GFDL-self, GFDL-user or self) and 344 files are not marked clearly as own work.

After the change of license in 2009 there were still many uploads with GFDL by many different users. Today there are 331 files from 2010 and they are uploaded by 198 different users. The number dropped over time and there are only 11 files from 2017 uploaded by 9 different users.

When Commons restricted use of GFDL in 15 October 2018 the number increased. 394 files are uploaded after that date (some are an edited version of an older upload).

• But of the 394 files 365 is uploaded by 1 user and all uploads in 2021 is made by that user.
• And of the 394 files only 2 are not marked as own work. The 2 files that are derivated from files on Commons licensed both GFDL and cc-by-sa-3.0 so they should be relicensed.

So the numbers conform that it is only Wikipedians that still use GFDL (primary one user). --MGA73 (talk) 19:16, 25 May 2021 (UTC)[reply]

For all of 2020, there is only one image left (that isn't from Jona) that maybe isn't copyvio: File:MV Alta, Co. Cork, February 2020.jpg. And here is the rationale for using GFDL: "Yo, thanks for your query. Fundamentally I'm wary of relicensing this photo as CC as neither I nor the original photographer wanted it being used willynilly outside of Wikipedia, and GFDL seemed the best bet for that." That is what GFDL is used for. — Alexis Jazz (talk or ping me) 03:18, 26 May 2021 (UTC)[reply]

The future of the Book namespace

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following lists: Wikipedia proposals Wikipedia technical issues and templates WikiProjects and collaborations When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

Should the

book namespace be deprecated and if so what should deprecation include? --Trialpears (talk) 18:27, 15 May 2021 (UTC)[reply

]

This RfC will involve several different but related proposals. First of all I will give some history on the book namespace since many editors are likely to be unaware of the namespace. I will also explain the current status and link to some previous discussions (not required reading by any means). Then I will outline a few possible actions each in their own section. When the RfC is closed the consensus for each proposal will be evaluated and hopefully there will be a consensus on how to deal with this zombie namespace. --Trialpears (talk) 18:27, 15 May 2021 (UTC)[reply]

History (book namespace)

The book namespace was introduced in 2009 as a way to download or print a collection of articles. To do this you use Special:Book to select a collection of articles you want in the book. divide them into chapters and choose some rendering settings. You can also give it a cover image, change the color of the book, choose rendering settings, and divide the articles into chapters.

After this was done you could either purchase a printed copy from PediaPress or download it in a wide variety of formats including PDF using the Offline Content Generator.

Eventually the Offline Content Generator became outdated and unmaintainable. Bugs and security issues could no longer be fixed so the Wikimedia Foundation turned off the book rendering service on all Wikimedia wikis in October 2017. Since then, Wikipedia books have only been available either in physical form from PediaPress or through MediaWiki2LaTeX (de:b:Benutzer:Dirk Huenniger/wb2pdf/manual). The issue with this is that we now require readers to visit a third party site to access our content and either purchase it or wait for a significant amount of time to get access to the book to render if MediaWiki2LaTeX even works properly for you. A large proportion of our books are too long to render and a good chunk of the rest have things like navboxes breaking the renderer and even if it in theory should work I've had times were it randomly stop or I can't download the book for unexplained reasons. If you want to do it locally (which I've heard works significantly better) you will have to do it on Linux or set up a virtual machine. After investing a few hours trying to do this I gave up so I haven't tested that personally. If you want a PDF of an article I would instead suggest using the "Download as PDF" option in the side bar which can reliably give you a PDF version in seconds.

Currently the namespace has total pageviews on the order of a popular portal like Portal:South Africa. This is spread out over a bit over 6000 pages. During a normal month without significant editor activity most books don't get a single view and just 1.5% of books get a pageview a day. The most popular one Book:Fundamental Data Structures gets just 15. It's also worth noting that these figures are significantly inflated by my and others recent maintenance work which has resulted in thousands of these views.

There have been several previous initiatives to hide books from readers, the biggest three being 2019 removal of book creator from side bar and suppression of many links, 2021 removal of remaining links and 2021 deletion of some book related templates. The latter two were basically unanimous decisions.

Books are still considered a community facing namespace and are on help pages often referred to as "community books" and are supposedly being community maintained. They are indexed by search engines. You can create books in the book namespace using Special:Book, but they can also be created in userspace as Category:Wikipedia books (user books). The namespace is listed as unused at WP:Namespace.

PediaPress links to a few of our books at the Catalog, which may or may not be possible to retain if the books are deleted on Wikipedia. It would continue to be possible to use PediaPress as long as Special:Book isn't removed. Either by not saving the book on wiki and saving it at PediaPress or by saving it user space.

The question now is how should we handle books in the future. This could include alternatives from keeping the status quo since it's barely seen by anyone to complete deletion of the namespace including all books within it. --Trialpears (talk) 18:27, 15 May 2021 (UTC)[reply]

In 2019 PediaPress implemented a new PDF render, which is used for the "Download as PDF" link, but it is clear in phab:T186740 that book support will not happen.--Snævar (talk) 19:32, 15 May 2021 (UTC)[reply]

• Comment. I'd like to add some further remarks to that. The original agreement was between the WikiMedia Foundation (WMF) and PediaPress. They wrote our original rendering engine, the Offline Content Generator (OCG). They also wrote one for themselves and at first you could download a free PDF softcopy in their format if you did not want to pay for a dead tree. They subsequently withdrew the softcopy option. Meanwhile OCG never worked right. PediaPress's attempts to fix it were constantly overtaken by changes to the templating and other games in both software and user spaces. Also, Wikibooks gained in functionality and content. So the early interest in our books faded. We have twice tried and failed to develop a replacement, MediaWiki2LaTeX is suffering from under-development and Collector, a replacement for OCG promised by PediaPress, has also gone silent since its alpha test site appeared. It has become impossible to know whether a viable in-house renderer would actually attract users; we have never had such a thing, volunteer effort is insufficient to deliver it and WMF have consistently refused to resource its development. I'd suggest that we have reached the crunch decision: is there any point in having both Wikipedia:books here and Wikibooks? Isn't one enough? Fiddling with our dying namespace is merely prolonging the agony. We need to either resurrect it or drive a stake through its heart. Although my preference lies with the former, I am under no illusions that the majority consensus would be for the latter. I used to believe that we owed PediaPress to keep it going, but on reflection they pulled the free downloads of their format from under our feet for expressly commercial reasons, and let us down again over Collector; we owe them nothing any more. I can always maintain book pages manually in my userspace and upload them to MediaWiki2LaTeX or whatever, I don't need anything else. — Cheers, Steelpillow (Talk) 14:04, 16 May 2021 (UTC)[reply]

Proposals (book namespace)

Formally deprecate the book namespace

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

There is a consensus to formally deprecate the book namespace, describing pages within it as historical or not maintained. (non-admin closure) (t · c) buidhe 09:22, 24 May 2021 (UTC)[reply]

---

This would include changing the language used at pages such as Wikipedia:Books, Help:Books and {{Saved book}}. Books in the book namespace would no longer be described as community maintained. --Trialpears (talk) 18:27, 15 May 2021 (UTC)[reply]

• Support This at a minimum should be done. The namespace does not enjoy community maintenance and we should make that clear. Calling it deprecated will make it clear for anyone that books aren't really supported. --Trialpears (talk) 18:27, 15 May 2021 (UTC)[reply]
• Oppose Books still exist, fix the software and books will come back to life.
  b} 18:42, 15 May 2021 (UTC)[reply
  ]
• Oppose What? Per Headbomb. Throwing out the baby with the bath water. Fix the software! Littleolive oil (talk) 18:47, 15 May 2021 (UTC)[reply]
• Comment @Headbomb and Littleolive oil: The status of fixing the software is that nothing has happend since 2017 and the extension is only bugfix maintained. I can not imagine a developer being willing to spend many weeks or months of work to get this up and going again, especially when the download as PDF feature exist. The amount of pageviews (many of which would not want to download a book) is like I said comparable to one popular portal which I can't imagine any developer justifying spending that kind of time on with 100s of more important projects. If the software is fixed usage may return to pre removal levels. December 2016 the namespace got a bit over 6000 daily pageviews on average which is comparable to a page like Dog. If you want to hold on hope that it will one day be fixed that's reasonable but I thought I should at least explain why I can't see that happening. --Trialpears (talk) 19:04, 15 May 2021 (UTC)[reply]

  Your lack of imagination is not ground for the deletion of books. If the PDF renderer works, one could make use of it to batch render collections of articles/books, and that would be a perfectly good basis for book-rendering to build upon.

  b} 19:12, 15 May 2021 (UTC)[reply

  ]

  Or... one could just print multiple PDFs with what we have now? No one uses books, and it seems no really ever did. TP is hardly speculating, if it's easy as you say, why hasn't anyone done it yet? Aza24 (talk) 19:20, 15 May 2021 (UTC)[reply]

  Chicken and egg issue. No one uses books because the software is broken. Fix the software, people will use books again. They were decently popular back when the renderer worked. As for "why hasn't anyone done it yet", ask the WMF.

  b} 12:56, 16 May 2021 (UTC)[reply

  ]

  Some data about usage is at User:SD0001/Books. It shows that the vast majority of this namespace has single-digit monthly page views. Most books have very few editors. Max number of distinct editors who have edited a book is 36 for Book:The Beatles. About half of all books have 2 just distinct editors (the 2nd edit mostly being AWB/HotCat). This doesn't indicate that they were decently popular ever. – SD0001 (talk) 19:46, 16 May 2021 (UTC)[reply]

  Yes, that's rather normal after all links to books were removed from the mainspace in 2020. See the clear drop in [5], and [6], [7] for examples.

  b} 21:33, 16 May 2021 (UTC)[reply

  ]

• Support—I just made a book on Gilbert Reaney with one of the external softwares and see nothing of use. In fact, the only differences I see from the PDF & Printable version downloads are a formal table of contents, title page and (for some reason) every single WP link turned into a url to that Wikipedia page in a note. I mean, what nonsense! We shouldn't support something as unhelpful as this, especially when a)there are 3rd party alternatives b)We literally have PDF and printable versions already c)it has remained unfixed for 4 years d)No one even used them when they were functioning! Aza24 (talk) 19:16, 15 May 2021 (UTC)[reply]
• Support - books are like portals: just not in enough demand by readers to be worth spending community resources on. And there are existing services to create PDFs. WikiBooks should be it's own wiki or inter wiki tool, and it can create books from any language wiki not just enwiki; but it's a distraction as an enwiki namespace or enwiki project. Levivich ^harass/_hound 19:21, 15 May 2021 (UTC)[reply]
• Support per nom, Aza24, and Levivich. Books was an experiment that we tried, which is fine. It failed, which is also fine. Let's acknowledge the failure and move on, not continue to waste effort trying to maintain it. {{u|Sdkb}} ^talk 20:18, 15 May 2021 (UTC)[reply]
• Support as secondary option to deletion for the reasons given in the comment below. ƒirefly ( t · c ) 20:30, 15 May 2021 (UTC)[reply]
• Support There is a real trend hereon WP to hang on to things that don't work anymore, are inactive, etc. It's a bad trend and the book namespace is a perfect example of it.
  talk) 20:50, 15 May 2021 (UTC)[reply
  ]
• Support. As a long time reader and on-off IP editor I've had a few attempts at using the book namespace over the years, but each time it has been a universally terrible user experience. It's common to find books that have significant NPOV, weight, and design issues, and let's not kid ourselves that the book namespace is community maintained - it's not. It's a dumping ground for people's personal book projects which are occasionally fixed up by a passing wikignome. To illustrate this let's have a look at the user experience for finding a book on a random topic that any encyclopedia should be able to cover well - "European history"

Extended content

So, to start European history ) has existed since 2002 and averages over 1000 page views a month. The internal search engine turns up 3 books with overlapping focus - in a community maintained namespace surely duplicate pages should be merged? The first book that turned up was European Union acronyms, jargon and working practices doing in a history book? This is massively out of date and has been abandoned since it's user created it - despite covering the European union in an inordinate amount of detail there's no mention of Brexit? The second book that turned up is Book:History of Europe. This has better focus IMO, but it consists only of a chronological list of articles with no attempt to sort the content into chapters. Created by a single user in 2010, only edits since have been wikignomery and an aborted attempted merge, so the book is missing anything that happened in the last 10 years. The final book that turned up is Book:Europe1. This is the best of the bunch in my opinion - it has a well defined chapter structure, a reasonable amount of articles and is relatively up to date (though that's just because it was created more recently, again it was created by a single author in 2017 and has seen only gnoming edits since). Even as the best of them I still don't see how it offers a better user experience than History of Europe, which sorts the same articles into the same basic time periods and is much more readable, and at this title it isn't something that readers are going to be able to easily find. The last two sections of this book are duplicated (and have been since creation 4 years ago) seemingly without anyone noticing. Having now found a reasonable book I have a few options to read it - I can either click through each of the articles in the list using it as a poor substitute for a summary style article or list, I can muck about setting up a Linux virtual machine to export the pages to latex then compile that to a pdf, or I can pay a third party company to print me a paper copy of an electronic encyclopaedia that will be outdated in a couple of years. Who is this aimed at? People who can't access the website reliably but can download enormous pdf files on a regular basis? People who can't afford internet access but can spend $$$ on print on demand books? People who need an easy to use book creation wizard but know how to set up Linux and use latex? I just don't see what demographic this is targeting.

• Overall the book namespace is just not a good or useful experience for readers, and there is no sign of any community actively curating these books. I would support depreciating the community book namespace and moving all books in it to the userspace of the original creator, as in my experience in 95% of cases they will be the only person to have actually added any content to the book. 192.76.8.91 (talk) 21:05, 15 May 2021 (UTC)[reply]
• Support and all the ones below too. I find the "just fix it" argument weak. If somethings been broken for this long and no one wants to fix it, its probably not worth fixing. I am struggling to see the value of this namespace even if it did work properly. Aircorn (talk) 21:49, 15 May 2021 (UTC)[reply]
• Support. Please! Gog the Mild (talk) 21:59, 15 May 2021 (UTC)[reply]
• Oppose for lack of any benefit in doing so. Nemo 22:00, 15 May 2021 (UTC)[reply]

  The benefit is that more editorial time gets spent on articles, which is what matters in the long run. – SD0001 (talk) 10:12, 16 May 2021 (UTC)[reply]

• Support - This has been broken for years. There doesn't seem to be much of a push to fix this, and per Aircorn, this isn't really looking like a thing a whole lot of people want. If a few users desire something like this, they can do it in their userspace, but as a whole, the book namespace seems to be dead. Hog Farm _Talk 23:01, 15 May 2021 (UTC)[reply]
• Support. It's a feature that never gained much traction and is obsolete now. -- RoySmith (talk) 00:20, 16 May 2021 (UTC)[reply]
• Support. —¿philoserf? (talk) 02:09, 16 May 2021 (UTC)[reply]
• Support. Nobody seems interested in maintaining any of this. If volunteers apply, perhaps it could be revived one day. For now, let it continue in userspace. — Alexis Jazz (talk or ping me)
• Support per evidence presented as well as IP192's. --Izno (talk) 03:27, 16 May 2021 (UTC)[reply]
• No Vote on the one hand, it's been broken for years and nobody has cared to fix it. Also, this feature should really be in user-space (for individual users' books) or project space (for collaborative efforts on topics). While it should be a good idea, I'm not sure we want to encourage people to do churnalism publishing of "Wikipedia content books" on self-publishing platforms. No vote myself, but unless somebody comes up with an idea to improve the usage of the namespace this will certainly pass. User:力 (power~enwiki, π, ν) 03:31, 16 May 2021 (UTC)[reply]
• Support deprecating the namespace. As others have said the namespace is a failed experiment, I just don't understand the utility in maintaining these as a community. Some users are still interested in creating books, sure, they can do so in userspace – there is no need for community maintenance which is a waste of resources over something which the readers don't care about. – SD0001 (talk) 07:07, 16 May 2021 (UTC)[reply]
• Support This is a broken namespace and massive waste of time. — Preceding unsigned comment added by Jackattack1597 (talk • contribs)
• Oppose I oppose anything that uses the word "deprecate" — GhostInTheMachine ^{talk to me} 14:07, 16 May 2021 (UTC)[reply]
• Support, but archive the content. —Kusma (t·c) 14:13, 16 May 2021 (UTC)[reply]
• Oppose As this seems to be a technical matter controlled by PediaPress and the WMF/MediaWiki, governed by a legal contract between them, then this is none of our business. If editors or readers do not find the facility useful then they are not required to use it. Andrew🐉(talk) 17:27, 16 May 2021 (UTC)[reply]
• Support. (1) Books are out of scope. The feature is peripheral to
  our purpose and should not be maintained as critical infrastructure, either technically or editorially. (2) re: "fix it", any intrepid volunteers or businesses can do so without the book namespace. (3) Books are already deprecated, per the above history. That we update our documentation should be uncontroversial. (4) Separate from this discussion, I would be curious to learn what positive impact (readership or wider audience) has come from Books during its existence. czar 18:18, 16 May 2021 (UTC)[reply
  ]
• Support: I'll lay my reasoning out once and refer to it in each subsequent comment. I support all progression towards ridding ourselves of the book feature. No-one has given a convincing use-case worthy of all the volunteer time that is still going into it (which is hardly a large proportion of what is done on the site, but still a substantial number of raw hours). 192.76.8.91 lays out brilliantly some examples of how there is no convincing use-case for at least much of the content. A tiny proportion of casual readers have heard of it. It's not good for people with good internet, or with bad internet. It doesn't relate to how people actually browse and read articles. And finally, we are not preventing anyone from implementing this functionality properly, and even for profit—so long as the CC-BY-SA attribution legally required is given. — Bilorv (talk) 22:10, 16 May 2021 (UTC)[reply]
• Support This is a new topic for me and I've read your reasoning and all the comments above carefully. I am not persuaded by "it's a bug so fix it!" near the top. Clearly the facts speak for themselves, in my view. The book format is not working, but on top of that, the book format is not popular or well used. I think it's time to draw down the curtain, empty the orchestra pit, and switch off the foyer lights, for the show is over. doktorb _words^deeds 22:18, 16 May 2021 (UTC)[reply]
• Support this is the minimum that should be done. I thought about this for some time, and your reasoning seems solid. Personally, PDFs seem like a much better solution than books, and the only difference I see is a Table of Contents. Through looking at pageviews, books also seem rarely used.
  talk) 04:14, 17 May 2021 (UTC)[reply
  ]
• Support per 192.76.8.91. First of all, the software doesn't work. That is to say, the software is broken, and doesn't work. That is to say, working is something that the software, in this situation, does not do. We have PDF rendering, which does basically every single thing "books" were supposed to do, except it actually works. So then we are left with "the book namespace", which is... just a bunch of random very badly put together lists of articles? The fact of the matter is that, not only does the namespace receive virtually no views and no edits, the content in it is almost all far below what we'd consider to be Wikipedia quality. The question then becomes why we're formally endorsing, in the voice of the community, some random namespace where random people throw random articles together with no peer review or consensus procedure, and giving it the veneer of respectability. Sad! jp×g 04:34, 17 May 2021 (UTC)[reply]

  It is wholly wrong to suggest that "We have PDF rendering, which does basically every single thing "books" were supposed to do." It falls very short of book functionality as implemented by the old OCG. It processes only a single article (not much worse than my web browser's standard web-page-to-PDF print option handles Wikipedia articles). A book renderer also needs to pull in every article from the contents list and adjust chapter titles as per the contents list. In order to comply with the legal requirements of our licensing, it then has to collate and append the users from the entire histories of all the articles into one massive Copyrights section. Then again for the images from the Commons. Finally, it must render to PDF, paginate, and add the page numbers to the Contents list. For some reason the false meme that "PDF creator does it all" is quite widespread and many refuse to acknowledge its utter falsehood (Indeed, failure to address it was the principal reason our own developer community has consistently failed, but that is another story). — Cheers, Steelpillow (Talk) 10:31, 17 May 2021 (UTC)[reply]

• Support per Levivich above, and per BlueRaspberry's deletion comment below. We should move to avoid wasting precious volunteer hours on projects that are not well-enough supported to survive. Ajpolino (talk) 05:53, 17 May 2021 (UTC)[reply]
• Support - I've been here for six years and I have never edited the book namespace, even in an administrative capatcity. Anarchyte (talk) 10:45, 17 May 2021 (UTC)[reply]
• Support an interesting experiment that didn't catch on. I don't see any point in spending any resources on it at this stage. Hut 8.5 19:50, 17 May 2021 (UTC)[reply]
• Support This is an encyclopedia, books belong to Wikibooks. So how about moving the books to Wikibooks instead of deleting them? -Killarnee (C•T•U) 17:22, 18 May 2021 (UTC)[reply]
• Support We are an encyclopedia, not a bookstore. Books are just not in high enough demand from our userbase to be worth the outsized editor time required. AdmiralEek ^{Thar she edits!} 17:53, 19 May 2021 (UTC)[reply]

  What time is required by our outsized editor? — GhostInTheMachine ^{talk to me} 18:10, 19 May 2021 (UTC)[reply]

• Support. Unmaintained features should be removed. Sandstein 07:09, 20 May 2021 (UTC)[reply]
• Oppose Deprecation is half-baked nonsense, it will confuse the heck out of visitors and book enthusiasts will keep right on adding books to it anyway. We really do not want a "hidden" wiki stitched into the one that anyone can read. — Cheers, Steelpillow (Talk) 08:58, 20 May 2021 (UTC)[reply]
• Support. This is just formalising what's currently the case: these aren't maintained by the community, the software doesn't work, and barely anyone views the books. Realistically it doesn't seem that any of these things will change. the wub "?!" 13:56, 23 May 2021 (UTC)[reply]
• Support Although it gives me no great joy to say this, we should have deprecated portals and we should deprecate books, to trim the number of namespaces.  – John M Wolfson (talk • contribs) 14:37, 23 May 2021 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Noindex the book namespace to hide it from search engines

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

Tracked in Phabricator
Task T283522

There is a clear consensus to noindex the book namespace to hide it from searches. (non-admin closure) (t · c) buidhe 09:23, 24 May 2021 (UTC)[reply]

---

This would occur by changing the MediaWiki configurations and prevent Wikipedia Books from showing up in search results. Books would still be reachable with Wikipedia's internal search function. --Trialpears (talk) 18:27, 15 May 2021 (UTC)[reply]

• Support If we are to hide the links internally we should also hide them from search engines for the same reasons. This content does not benefit readers and leaves room for publishing something in an indexed namespace without supervision. This could possibly be abused by spammers or COI editors. --Trialpears (talk) 18:27, 15 May 2021 (UTC)[reply]
• Support on a temporary basis. With the re-enabling of indexing when/if the PDF renderers are fixed.
  b} 18:45, 15 May 2021 (UTC)[reply
  ]
• Support - as a minimum, per my comments in support of deprecation. Levivich ^harass/_hound 19:22, 15 May 2021 (UTC)[reply]
• Support per nom; this should go along with deprecation. {{u|Sdkb}} ^talk 20:19, 15 May 2021 (UTC)[reply]
• Support per all the above.
  talk) 20:51, 15 May 2021 (UTC)[reply
  ]
• Support per nom if there is no consensus to depreciate the namespace outright, as there is no point in directing readers to a namespace for a withdrawn service that isn't particularly well maintained. 192.76.8.91 (talk) 21:17, 15 May 2021 (UTC)[reply]
• Oppose as there is no indication that people landing on such pages from search engine caused anyone harm. Nemo 22:00, 15 May 2021 (UTC)[reply]
• Support - Frankly, I don't see anyone searching the internet really finding this useful. Doesn't seem helpful to land people searching for a topic to get sent to the book namespace. This should be largely masked from search engines. Hog Farm _Talk 22:55, 15 May 2021 (UTC)[reply]
• Support If nobody's watching this namespace and it's indexed, it's just an open invitation for spammers and other SEO-miscreants. -- RoySmith (talk) 00:22, 16 May 2021 (UTC)[reply]
• Support. —¿philoserf? (talk) 02:10, 16 May 2021 (UTC)[reply]
• Support, also, get rid of the book namespace. Nobody seems interested in maintaining any of this. If volunteers apply, perhaps it could be revived one day. For now, let it continue in userspace. — Alexis Jazz (talk or ping me)
• Support per evidence presented. --Izno (talk) 03:27, 16 May 2021 (UTC)[reply]
• Support per above - no benefit to search engine visitors to landing here while this is broken. User:力 (power~enwiki, π, ν) 03:28, 16 May 2021 (UTC)[reply]
• Support per above. I think we should go further (see comments in the deletion section below), but this would be a start. ƒirefly ( t · c ) 06:49, 16 May 2021 (UTC)[reply]
• Oppose As this seems to be a technical matter controlled by PediaPress and the WMF/MediaWiki, governed by a legal contract between them, then this is none of our business. If editors or readers do not find the facility useful then they are not required to use it. Andrew🐉(talk) 17:29, 16 May 2021 (UTC)[reply]
• Support: per my reasoning above. — Bilorv (talk) 22:10, 16 May 2021 (UTC)[reply]
• Support per above.
  talk) 04:15, 17 May 2021 (UTC)[reply
  ]
• Support, per the arguments I made (and cited) in my support for the above section. Namely, for a variety of reasons, the Book namespace is filled with low-quality content (which is regrettable and could have been avoided). But, as it stands, there's no reason to think that we are benefiting from having the Book namespace open to all and sundry. jp×g 06:20, 17 May 2021 (UTC)[reply]
• Support makes sense — GhostInTheMachine ^{talk to me} 11:54, 17 May 2021 (UTC)[reply]
• Oppose Hiding it is half-baked nonsense, it will confuse the heck out of users looking for them and book enthusiasts will keep right on adding books to it anyway. We really do not want a "hidden" wiki stitched into the one that anyone can read. — Cheers, Steelpillow (Talk) 08:58, 20 May 2021 (UTC)[reply]
• Support as an initial step. These pages aren't maintained, we shouldn't be presenting them to search engines with the Wikipedia name as if they are. the wub "?!" 13:56, 23 May 2021 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Remove the option to save in the book namespace from the book creator

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

Tracked in Phabricator
Task T283523

There is a consensus to remove the option to use this tool to create books in the book namespace. (non-admin closure) (t · c) buidhe 09:31, 24 May 2021 (UTC)[reply]

---

This would be implemented by changing a simple MediaWiki configuration setting as documented at mw:Extension:Collection#User rights for saving books. The book namespace would still be editable and it would be possible to move books from user space there or manually create a book using wiki text and then use the book creator. --Trialpears (talk) 18:27, 15 May 2021 (UTC)[reply]

• Support This would be a great way to heavily discourage creation of new community maintained books while not impacting creation of user books or editing of existing books. --Trialpears (talk) 18:27, 15 May 2021 (UTC)[reply]
• Support on a temporary basis. With the re-enabling when/if the PDF renderers are fixed.
  b} 18:44, 15 May 2021 (UTC)[reply
  ]
• Support - per my comments in support of deprecation. Levivich ^harass/_hound 19:23, 15 May 2021 (UTC)[reply]
• Support, as something that should go along with deprecation. {{u|Sdkb}} ^talk 20:21, 15 May 2021 (UTC)[reply]
• Support. —¿philoserf? (talk) 02:14, 16 May 2021 (UTC)[reply]
• Support, also, get rid of the book namespace. Nobody seems interested in maintaining any of this. If volunteers apply, perhaps it could be revived one day. For now, let it continue in userspace. — Alexis Jazz (talk or ping me)
• Support per evidence presented. --Izno (talk) 03:26, 16 May 2021 (UTC)[reply]
• Support per above. I think we should go further (see comments in the deletion section below), but this would be a start. ƒirefly ( t · c ) 06:50, 16 May 2021 (UTC)[reply]
• Support to along with namespace deprecation proposal above. – SD0001 (talk) 07:11, 16 May 2021 (UTC)[reply]
• Support Makes sense to limit the books to user space — GhostInTheMachine ^{talk to me} 14:02, 16 May 2021 (UTC)[reply]
• Oppose As this seems to be a technical matter controlled by PediaPress and the WMF/MediaWiki, governed by a legal contract between them, then this is none of our business. If editors or readers do not find the facility useful then they are not required to use it. Andrew🐉(talk) 17:29, 16 May 2021 (UTC)[reply]
• Support: per my reasoning above. — Bilorv (talk) 22:10, 16 May 2021 (UTC)[reply]
• Support. Makes sense along with depreciation.
  talk) 04:16, 17 May 2021 (UTC)[reply
  ]
• Support as a step towards removing the namespace entirely. Ajpolino (talk) 05:53, 17 May 2021 (UTC)[reply]
• Oppose if still creatable, even if discouraged, removing the tool (which likely goes largely unused; if it was causing a problem, that would be one thing) that may prove useful in the rare case a book is helpful is silly. — Godsy ^(TALK_CONT) 07:06, 17 May 2021 (UTC)[reply]
• Oppose "Discouraging" others is disgustingly self-oriented social engineering - if a feature is undesirable, be honest enough to get rid of it. And if there is no consensus to do that, then you have absolutely no excuse for poking others in the eye. — Cheers, Steelpillow (Talk) 09:03, 20 May 2021 (UTC)[reply]
• Support. the wub "?!" 13:56, 23 May 2021 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Drop support for book class from WikiProject assessment

This would involve emptying and deleting the categories at Category:Book-Class articles and editing the associated templates to not support the book namespace. --Trialpears (talk) 18:27, 15 May 2021 (UTC)[reply]

• Support At this point these don't serve a purpose and has already been marked historical. --Trialpears (talk) 18:27, 15 May 2021 (UTC)[reply]
• Oppose Books still exist, this is no different than having a category class.
  b} 18:42, 15 May 2021 (UTC)[reply
  ]
• Support - per my comments in support of deprecation. Levivich ^harass/_hound 19:23, 15 May 2021 (UTC)[reply]
• Support these are not, and never were, articles. Has already been marked as historical for a year. Clearly we aren't doing this already, might as well acknowledge it.
  talk) 20:54, 15 May 2021 (UTC)[reply
  ]
• Support - This no longer has a function. Hog Farm _Talk 21:01, 15 May 2021 (UTC)[reply]
• Support. —¿philoserf? (talk) 02:15, 16 May 2021 (UTC)[reply]
• Support, also, get rid of the book namespace. Nobody seems interested in maintaining any of this. If volunteers apply, perhaps it could be revived one day. For now, let it continue in userspace. — Alexis Jazz (talk or ping me)
• Support per evidence presented. --Izno (talk) 03:25, 16 May 2021 (UTC)[reply]
• Support Books are just collections of existing articles. The articles are the things to assess — GhostInTheMachine ^{talk to me} 14:03, 16 May 2021 (UTC)[reply]
• Oppose As this seems to be a technical matter controlled by PediaPress and the WMF/MediaWiki, governed by a legal contract between them, then this is none of our business. If editors or readers do not find the facility useful then they are not required to use it. Andrew🐉(talk) 17:30, 16 May 2021 (UTC)[reply]
• Oppose, conditional on the book namespace being kept: I'm not sure what actual benefit this brings if we're not getting rid of books entirely (which I do support). Is there much time being spent maintaining these Book-class transclusions? And why is it our jurisdiction to control how individual WikiProjects maintain things? So far as I understand, unless the wider community really establish global consensus to stop us then a WikiProject I'm part of can start an assessment scale with 64 different ratings, from 3 independent 4-valued scales measuring how "well-sourced", "well-written", "well-illustrated" each page is (regardless of namespace). — Bilorv (talk) 22:10, 16 May 2021 (UTC)[reply]
• Suppport per above.
  talk) 04:16, 17 May 2021 (UTC)[reply
  ]
• Support as a consequence of removing the books namespace. No point in doing this otherwise. Ajpolino (talk) 05:53, 17 May 2021 (UTC)[reply]
• Oppose These are useful in evaluating the aggregate score of articles in a given topic. Dobbyelf62 (talk) 23:25, 18 May 2021 (UTC)[reply]
• Oppose. Many books are cruft, some are worthwhile about different things. It is actually useful to know which is which. — Cheers, Steelpillow (Talk) 09:11, 20 May 2021 (UTC)[reply]

  Steelpillow, this "assessment" isn't sorting books by quality, but (roughly) by topic. The book quality assessment (via User:Cyberbot I/Book Reports) seems independent of the WikiProject assessments. —Kusma (t·c) 10:26, 20 May 2021 (UTC)[reply]

  OK, I have updated the detail but the principle is unchanged. — Cheers, Steelpillow (Talk) 12:05, 20 May 2021 (UTC)[reply]

• Neutral on this. I think the books should go, but if they're kept then it makes sense to keep the assessments unless WikiProjects feel otherwise. If the books are all deleted, the categories become eligible for speedy deletion under
  C1, and the necessary adjustments can be made to the templates. Either way there's no action required now. the wub "?!" 13:56, 23 May 2021 (UTC)[reply
  ]
• Oppose per Headbomb, Dobbyelf62, and Steelpillow. See also my !vote and comments in the section below. Cordially,
  † (wire) 16:17, 28 May 2021 (UTC)[reply
  ]
• Support per above. –Fredddie™ 19:05, 30 May 2021 (UTC)[reply]

Delete all books within the book namespace

Book – A Novel to be located at the correct title. Special:Book will continue working like normal and saving books in user space is still possible. PediaPress would continue to work except for possibly the catalog depending on their implementation. --Trialpears (talk) 18:27, 15 May 2021 (UTC)[reply

]

• Neutral It would be nice to never have to worry about the namespace again and to remove the possibility of vandalism staying for months or the namespace containing a safe harbor for unsuitable pages. There is however some non-zero value from some of these pages for a small number of users. Since the previous link hiding combined with proposals here (mostly noindexing) would prevent people from accidentally coming to the namespace I believe it's fine to leave it like this. While we would still have a small amount of vandalism going uncaught for months, vandalism on a page with just a handful of views isn't that bad. --Trialpears (talk) 18:27, 15 May 2021 (UTC)[reply]
• Support Each of these proposals is making the namespace more and more like a second user namespace and less and less a functioning namespace (to the extent it ever was one). Once each of these are implemented, there will be no meaningful difference between books in the book namespace and books in the user namespace, and thus no reason to keep them separate. I would suggest userfying books whose creator is still active rather than deleting them, however. This renders all of the above proposals moot, so I'm not commenting in any other sections * Pppery * _{it has begun...} 18:36, 15 May 2021 (UTC)[reply]
• Oppose This is an overreaction to a software issue. The solution is to fix the software, not throw out the baby.
  b} 18:41, 15 May 2021 (UTC)[reply
  ]
• Oppose. Fix it rather than remove it. Littleolive oil (talk) 18:50, 15 May 2021 (UTC)[reply]
• Support per nom. I'm convinced 99.99% of our readers don't know about or have ever used books. Most of those who have probably clicked on them accidentally... We already have built in options (PDF & printable version), as well as 3rd party options, for the truly desperate 0.01%. Aza24 (talk) 19:24, 15 May 2021 (UTC)[reply]
• Support - per my comments in support of deprecation. Userfication, where practical, makes sense as an alternative to deletion. Levivich ^harass/_hound 19:25, 15 May 2021 (UTC)[reply]
• Support per nom, Aza24, and Pppery. — Ched (talk) 20:06, 15 May 2021 (UTC)[reply]
• Support with userification, per Pppery. {{u|Sdkb}} ^talk 20:25, 15 May 2021 (UTC)[reply]
• Support as first option - I do not see the software becoming functional any time soon, and personally I feel developer time could be better spent elsewhere. As such, there is no point in keeping the namespace around. ƒirefly ( t · c ) 20:28, 15 May 2021 (UTC)[reply]
• Support the history of this project is littered with ideas that were given a fair chance and just didn't work out in the long run. Nobody is going to come along and magically fix all the software issues for a sidelined,disused project that so few find useful. There are far more important and actually useful things for both the community and the staff to be doing. Let's just admit the obvious, this is over. Those people that really want them they can still have them in userspace.
  talk) 21:01, 15 May 2021 (UTC)[reply
  ]
• Oppose - Wikipedia:Featured and good topic candidates/Nomination procedure instructs that books be created as part of the process for nominating featured and good topics. Some of the books will have some historical value through featured and good topics. I don't think blanket deletion of all is a particularly good step, although many are useless. Hog Farm _Talk 21:04, 15 May 2021 (UTC)[reply]
• Sort of support - I think it would be better to move the books to the userspace of the original creator, rather than outright deletion, but I agree with removing them from a public facing "Community maintained" section if the encyclopaedia. 192.76.8.91 (talk) 21:23, 15 May 2021 (UTC)[reply]
• Oppose because the "books" are just collection of links, which work perfectly fine with adequate software. Users can still use them right now to produce their own derivative products, e.g. for Kiwix or PediaPress. Nemo 22:00, 15 May 2021 (UTC)[reply]
• Support, per nom and Firefly. Gog the Mild (talk) 22:02, 15 May 2021 (UTC)[reply]
• Oppose, don't hide history. At least get a bot to move it all to subpages of Wikipedia:Books/Old/ or something so the connection to Featured Topics stays comprehensible. —Kusma (t·c) 22:32, 15 May 2021 (UTC)[reply]
  • ?? The featured and good topics are barely connected to the books—they provide no more connection than the topic box itself. They're not even displayed in the topic boxes. Aza24 (talk) 22:44, 15 May 2021 (UTC)[reply]
    • I still think that some of these may have some historical value. Not a majority, but some. I don't think nuking an entire namespace indiscriminately is going to be helpful here. I support deleting most of these, but I'm not convinced the blanket approach is the best route as some of these may be historically useful and need more attention before deletion. Hog Farm _Talk 22:58, 15 May 2021 (UTC)[reply]
    • Aza24, they were in the not so distant past: [8] By all means delete those that do harm, but don't delete everything just because it's not "useful" anymore. —Kusma (t·c) 23:03, 15 May 2021 (UTC)[reply]
  • I guess it's worth noting that not all featured topics have an associated book. Checking ~20 random topics only a bit over half had one. --Trialpears (talk) 23:30, 15 May 2021 (UTC)[reply]
• Support per above. ~ HAL333 23:56, 15 May 2021 (UTC)[reply]
• Support. The feature is dead and has been for a long time now. The foundation devs have a huge backlog of other bugs which they aren't fixing, and there is no reason to believe they are going to start on this any time soon. The dev time is anyways better served elsewhere. --Gonnym (talk) 00:00, 16 May 2021 (UTC)[reply]
• Support deletion Feature is not supported, never was well supported, and there is no plan to support either in terms of software or volunteer community organization. I have made books in the past and later felt that the process was disappointing. Since it was an option in Wikipedia, I assumed that it was useful, when in fact, the process gets no support, is not part of a tool suite of other useful functions, and does not give benefits that I expected. Unless somehow someone shows evidence of an existing active book development and maintenance community, and unless there is a plan to make a serious Wikimedia community request for Wikimedia Foundation financial investment in this tool's development, then I say delete what exists and remove the option so as not to distract anyone else from more useful and supported tools. Keeping unsupported tools around is not a benefit. The books function as I know it could be recreated as some kind of tool in Wikidata for sharing lists of articles to run reports on them, print them as a book, or coordinate translation of important articles across languages. By putting this in Wikipedia instead of Wikidata the machine readability benefits are not there. Blue Rasberry (talk) 00:06, 16 May 2021 (UTC)[reply]
• Meh and kind of leaning oppose although mass userfication would be fine. These are already very difficult to stumble across, and if the proposals above trend as they currently are it will become essentially impossible to do so. Basically these are nowhere facing, but there's no need and nothing to be gained by hiding history. If people feel things will somehow be tidier without an extra namespace then sure userfy them, but really once these are unfindable any further steps, be they deletion, userfication, etc. sound like extra work for no discernible benefit. Regards, 31.41.45.190 (talk) 01:38, 16 May 2021 (UTC)[reply]
• Meh, also, get rid of the book namespace. Nobody seems interested in maintaining any of this. If volunteers apply, perhaps it could be revived one day. For now, let it continue in userspace. Mass userfication should work. Any "books" that are clearly garbage could be deleted. — Alexis Jazz (talk or ping me)
• Oppose for now - if the namespace is deprecated this might be good to do next year. Doing it right now is too soon. User:力 (power~enwiki, π, ν) 03:21, 16 May 2021 (UTC)[reply]
• Support the end objective of remove the namespace given the evidence presented. I think deletion of the books should occur, but perhaps only after they have been moved out of the namespace so that REFUNDs can indeed take place. --Izno (talk) 03:23, 16 May 2021 (UTC)[reply]
• Support – This feature is not supported, and no one has any good reason devote the time necessary to make it work. We should not leave a mess like this around, like an abandoned ruin. I support deletion, which will simply be representative of the reality that the 'Book' namespace is and has been dead for a very long time. RGloucester — ☎ 04:10, 16 May 2021 (UTC)[reply]
• Support the end objective of removing the namespace. However, to preserve the history per Hog Farm and Kusma, I would prefer "archiving" these and moving them to a location like like the subpages of "Wikipedia:Books/Old/" or something. – SD0001 (talk) 07:44, 16 May 2021 (UTC)[reply]
• Note: Before any actual deletion occurs, the pages should all be properly tagged so any interested parties are notified. The deletion notice should not be
  WP:LEOPARD essay). —Kusma (t·c) 08:40, 16 May 2021 (UTC)[reply
  ]

  WP:CENT and the village pumps really isn't at the bottom of a locked filing cabinet stuck in a disused lavatory while books not getting a single view most months are. --Trialpears (talk) 09:23, 16 May 2021 (UTC)[reply

  ]

  Would adding it to {{Saved book}} with namespace detection be sufficient? That would save like 12k unnecessary edits. --Trialpears (talk) 09:33, 16 May 2021 (UTC)[reply]

  Trialpears, ideally we just move the whole book namespace back to where it came from (used to be subpages of Wikipedia:Book), then we can avoid notifying people. (For casual users, I think anything other than their talk page and watchlist could just as well be on Alpha Centauri). —Kusma (t·c) 09:56, 16 May 2021 (UTC)[reply]

  I've now added a custom deletion notice through the templates {{Saved book}} and {{Category class}}. --Trialpears (talk) 19:48, 16 May 2021 (UTC)[reply]

• Support, with proper warnings for interested parties (eg the book's creator). Let's just kill this failed experiment off.
  talk) 11:45, 16 May 2021 (UTC)[reply
  ]
• Oppose This is a little extreme, I support deprecating the namespace, but not deleting everything in it.Jackattack1597 (talk) 13:04, 16 May 2021 (UTC)[reply]
• Support but prefer if we could proactively archive them all to somewhere accessible to regular users before deleting the namespace, rather than requiring that books individually go through the
  WP:REFUND process after deletion. I don't see a lot of value in preserving them, but all else being equal, it's better not to erase history. Colin M (talk) 13:50, 16 May 2021 (UTC)[reply
  ]
• Comment This is the only important decision in this RfC, it is the endpoint of the death by a thousand cuts the others are perpetuating. Let's just get on with it, one way or the other. Whichever way this goes, we have to accept that we are voting on whether to revive or kill the initiative. — Cheers, Steelpillow (Talk) 14:20, 16 May 2021 (UTC)[reply]

  Subsequently you oppose because "it's useful" even though it doesn't work. "Let's get on with it", indeed. Izno (talk) 15:47, 16 May 2021 (UTC)[reply]

  @Izno: Why so snarky? Have I upset you or something? Darn, where's the cup of tea template when you need it? — Cheers, Steelpillow (Talk) 15:13, 18 May 2021 (UTC)[reply]

  It's not snarky to say "Let's just get on with it"? :) Izno (talk) 19:52, 18 May 2021 (UTC)[reply]

• Oppose I find the Books feature useful; I would use it more if it still worked as well as it used to. I shall be sad to lose it. — Cheers, Steelpillow (Talk) 14:20, 16 May 2021 (UTC)[reply]
• Oppose Too much for now. Revisit when the future of the technology is clear. We currently have 51,546 books in user space and only 6,198 in Book space, so "just" move all of the books in Book space to a sub-page of the user that created them. — Preceding unsigned comment added by GhostInTheMachine (talk • contribs)

  The future is clear: the technology is dead and will not be resurrected at this point. --Izno (talk) 15:46, 16 May 2021 (UTC)[reply]

  We are probably talking about different things. The gadget that collects articles worked when I tried it. The gadget that converts these article lists into a PDF worked when I tried it. The question here is should we delete all books within the book namespace and I think we should just move them. Once the namespace is empty, then we have the option to turn it off — GhostInTheMachine ^{talk to me} 11:52, 17 May 2021 (UTC)[reply]

• Oppose As this seems to be a technical matter controlled by PediaPress and the WMF/MediaWiki, governed by a legal contract between them, then this is none of our business. If editors or readers do not find the facility useful then they are not required to use it. Andrew🐉(talk) 17:30, 16 May 2021 (UTC)[reply]

  I do not think there ever was any legal contract - both sides have behaved far too off-hand for that. Besides, whatever the WMF may or may not have signed up to without telling us is nothing to do with us - there's no mention of such a thing in the code of conduct etc. If the WMF were to have a sudden "Oh, sh*t!" awakening and change their tune, that would be their problem not ours. — Cheers, Steelpillow (Talk) 17:43, 16 May 2021 (UTC)[reply]

  Unless I am massively misunderstanding something, any contract between the WMF and PediaPress has absolutely no bearing on whether we have a specific namespace on enwiki or not, nor on whether we choose to deprecate the feature given that it hasn't been working properly for years. ƒirefly ( t · c ) 17:44, 16 May 2021 (UTC)[reply]

• Support with no rush—give an ample window for anyone who wants to repurpose the content to do so and delete at the end of that generous period. czar 18:27, 16 May 2021 (UTC)[reply]
• Prompted by Iznos comment above I have looked into what happened when the education program namespace was temporarily uninstalled. While the namespace was uninstalled it was impossible to access or undelete pages (even for admins). To avoid this all books should be moved to Wikipedia:Books namespace before a possible deletion to avoid this technical issue this time around. --Trialpears (talk) 21:41, 16 May 2021 (UTC)[reply]
• Strong support: per my reasoning above. We need to solve the problem at its root. A refund process or archive of the namespace (on another wiki? Even just a nod towards some fork of Wikipedia on a guideline page?) should be made for individuals who have been using the namespace for personally helpful activities—I don't want to delete what you've worked on, but I don't want to be broadcasting it as reader-facing content. — Bilorv (talk) 22:10, 16 May 2021 (UTC)[reply]
• Transwiki them to English Wikibooks per m:Keep history. Many of these are useful and we have a WMF project that can easily house them. We should not delete them and hope someone decides to dig around our dead namespaces before starting a new effort. Instead, we should move the content to an appropriate place: Wikibooks. — Wug·a·po·des​ 23:03, 16 May 2021 (UTC)[reply]

  Wugapodes That really won't work. The books in the book namespace aren't the same type of book wikibooks focus on. While Wikibooks also contain some of this type of books as well at wikibooks:Wikibooks:Collections they won't work since Wikibooks don't contain the Wikipedia articles these books consisted of. If this was done they would literally just be useless lists of red links. I can't imagine Wikibooks would want that. --Trialpears (talk) 23:13, 16 May 2021 (UTC)[reply]

  Ah so I was confused about how the software worked. I thought the books namespace held the output of the program (you can tell how much I use the namespace) but yes, looking through them they would be largely useless to wikibooks unless we copied all the articles over too which would be a bad idea. I've struck my comment. I'm fine with whatever as long as the content is recoverable in the future. — Wug·a·po·des​ 23:44, 16 May 2021 (UTC)[reply]

  I think that the book ns is and always will be pointless. But why can't the related articles stay here and the links can easily be changed? -Killarnee (C•T•U) 17:35, 18 May 2021 (UTC)[reply]

  The book creator is designed to work on pages that are all within the same wiki - when you use it to create or edit a book it adds a banner at the top of the page that you can use to add articles to your book as you browse. I don't know if it would work with cross wiki links, but it really isn't intended to be used in that manner. Also being blunt for a minute, the book namespace is full of crap and I would strongly oppose dumping our rubbish on another wiki with the expectation that they'll either have to preserve it and maintain it for us or turn it into something worthwhile. Is wikibooks going to want Book:Blakfacts: Volume 4.5, which starts with a section on "Short Little Black People"? How about it's companion Book:Blakfacts Volume 12:, which is literally just someone's list of top Africans? Is anyone going to read Book:American Holocaust which is 50% about the extinction of the American bison and 50% about the colonisation and oppression of the native Americans? Is wikibooks going to want Book:Pirates1 a world first in the cosmology/piracy/sci-fi genre? What about Book:Political Alternatives, which lists "valid alternatives to the current political system" which consists entirley of links to articles on socialism? Is anyone ever going to read Book:Gemology and Jewelry, an unsorted 500 article long book including everything vaguely related to jewellery, or Book:Ancient Monuments In The UK, a 350 article long book on ancient monuments in the UK. What's the inclusion criteria that was used to select articles for Book:Core biographies (A–D), is it just some readers list of their favourite articles? Do you want a book containing countries that were featured articles in 2012? Don't worry Book:Featured Country Articles has you covered. I already talked through my experience of searching for a history book above, but the vast majority of the namespace is abandoned personal projects that we should not be presenting to readers as "community maintained". If they're going to be kept then userfying them to the userspace of the original creator is probably the best way of dealing with them IMO. 192.76.8.73 (talk) 22:00, 18 May 2021 (UTC)[reply]

• Support per nom and extended discussion above.
  talk) 04:17, 17 May 2021 (UTC)[reply
  ]
• Support provided there's some path to refund requested material. Ajpolino (talk) 05:53, 17 May 2021 (UTC)[reply]
• Oppose. The reason the Book namespace is filled with garbage isn't because books are a bad idea, it's an artifact of historical factors (primarily the book rendering service being fucked up). If there is no longer an influx of crappy books (i.e. disabling the feature to make them easily), I think it would be easy to clean them up and write good ones. jp×g 06:30, 17 May 2021 (UTC)[reply]
• Oppose - No reason to obscure them from public sight. No-indexing and the removal from certain forms of the search engine is more than adequate. — Godsy ^(TALK_CONT) 07:02, 17 May 2021 (UTC)[reply]
• Support Or what about moving the pages to Wikibooks instead of deleting all the pages? -Killarnee (C•T•U) 17:25, 18 May 2021 (UTC)[reply]

  See the replies to Wugapodes, who made an identical suggestion a few comments up. * Pppery * _{it has begun...} 17:28, 18 May 2021 (UTC)[reply]

• Oppose I often use the Book tab to track changes for specific topics. I get far more use out of this than the Watchlist. Dobbyelf62 (talk) 23:27, 18 May 2021 (UTC)[reply]

  Presumably you could use a userspace book (which won't be affected by this proposal) or Special:RecentChangesLinked for the same purpose. * Pppery * _{it has begun...} 02:43, 19 May 2021 (UTC)[reply]

• Support with the goal of removing the namespace clutter. Also fine with moving to an archive location in another namespace as a few have suggested e.g. Wikipedia:Books/Old. the wub "?!" 13:56, 23 May 2021 (UTC)[reply]
• Support if they can't/shouldn't be moved to WikiBooks  – John M Wolfson (talk • contribs) 14:42, 23 May 2021 (UTC)[reply]
• Support Which other wiki uses this namespace? We're the only one that uses it, and it's currently
  deprecated. We can download pages as PDFs, and there's already another wiki for books. Why keep a namespace that's not used? I think one possibility would be to delete all pages in the Book namespace and to blacklist the namespace. It would be a lot easier than deleting the namespace. If all pages in this namespace do get deleted, please refund all of my edited pages in book ns, and in book talk ns as well if those get deleted. 54nd60x (talk) 03:03, 25 May 2021 (UTC)[reply
  ]
• Oppose
  † (wire) 15:53, 28 May 2021 (UTC)[reply
  ]

Oppose for historical reasons. Books should be deprecated instead and left at that. Tyrone Madera (talk) 20:13, 28 May 2021 (UTC)[reply]

• Support deletion Time to let go of this failed experiment. oknazevad (talk) 22:20, 28 May 2021 (UTC)[reply]
• Support after giving the book creators a chance to download their books. –Fredddie™ 19:07, 30 May 2021 (UTC)[reply]

Following a discussion at WT:TFD I would like proposing hiding TfD notices (the default appearance shown above) from users who aren't autoconfirmed. This would hide content only of interest to editors from readers. It is very important that editors are aware of big TfD discussions since they can have wide ranging effects however and there are at times IPs or new accounts that make their first comments at TfD. I feel like the trade off here between IP input and unnecessary notices is acceptable, but I feel like this is something people who aren't TfD regulars should weigh in on as well. --Trialpears (talk) 19:29, 15 May 2021 (UTC)[reply]

Survey (TfD notices)

• OPPOSE - While I sympathize with the intent, it ignores the fact that we have long-term editors who, for various reasons, continue to edit as IPs and do not log on with user names. They may wish to be participate in TfD discussions, and so should be informed of them. Blueboar (talk) 19:45, 15 May 2021 (UTC)[reply]
• Support—I am sympathetic to the IP users who are actively editing, but (as I understand it) in the grand scheme of Wikipedia virtually none of our readers are registered users, and the number of IP editors who are regularly and actively editing is equally miniscule. As such, it makes no sense to shove these notices in their face and if we truly want to prioritize reader-facing pages—we should remember that. Aza24 (talk) 19:57, 15 May 2021 (UTC)[reply]
• Support Most of the time this is a confusing waste of space. When a large template (such as a widely used infobox) gets nominated at TfD a notice is shown often across hundreds of thousands (sometimes millions) of pages, each with many readers. So basically we have millions of readers seeing a confusing ugly "templates for discussion" notice on the top of pages. As a TfD regular, I can say that IP participation there is not that high anyway. And unfortunately, if one makes the choice to keep using an IP, they need to accept the inconveniences that result, such as article creation limitations, captchas, being more subject to edit filter false positives, unable to edit pages due to semiprotection, etc. Compared to all those, this is a rather minor inconvenience. It's the same as the fact that users too paranoid to enable JavaScript have to accept that many websites will not work properly as a result. ProcrastinatingReader (talk) 19:59, 15 May 2021 (UTC)[reply]
• Support, as something that strikes a much better balance between
  reader and editor needs than the status quo, which (like many things) is too heavily weighted toward editor needs. Aza24 and ProcrastinatingReader successfully rebutted Blueboar's opposition argument. {{u|Sdkb}} ^talk 20:29, 15 May 2021 (UTC)[reply
  ]
• Support - largely per ProcrastinatingReader. This is just going to be an annoyance to most readers who aren't registered editors. The average non-registered reader doesn't care too much about the background processes, so we shouldn't be shoving background processes into their faces with notices. Hog Farm _Talk 21:12, 15 May 2021 (UTC)[reply]
• Support Honestly we could probably hide a lot of the other notifications as well. This is one of the worst in terms of spamming and use to readers (and many editors). Aircorn (talk) 21:51, 15 May 2021 (UTC)[reply]
• Oppose
  non-autoconfirmed users are human too. The last time I checked, making edits like this was not a crime. Unless it becomes policy to semi-protect all XfD pages, why should we deny them the right to see the TfD messages? If they don't see the messages, how will they know that a discussion is ongoing, let alone know that they are welcome to participate? TfD participation is low enough already without lowering it still further. Also, I'm certain that this has been proposed and rejected at least twice before. --Redrose64 🌹 (talk) 22:13, 15 May 2021 (UTC)[reply
  ]

  Indeed, it has been. * Pppery * _{it has begun...} 22:26, 15 May 2021 (UTC)[reply]

  re "why should we deny them the right to see the TfD messages"—because giving irrelevant notices to millions of readers every month overwhelmingly outweighs the needs of the few active IP editors. We are here first and foremost for our readers. Aza24 (talk) 22:58, 15 May 2021 (UTC)[reply]

  Not to mention very few to no IP editors participate at TfD. Consider this on 51k pages (with a combined readership of probably 100k-1M over the TfD period), this on every US SCOTUS case, this on 1,956,845 transclusions (later had to be disabled), this on 5k transclusions, this on all US legislation pages. None of them had any IP participation; this is the norm at TfD. ProcrastinatingReader (talk) 23:10, 15 May 2021 (UTC)[reply]

• Oppose I fail to see what has meaningfully changed since the previous discussions I linked above. * Pppery * _{it has begun...} 22:26, 15 May 2021 (UTC)[reply]

  Which is... not an oppose rationale? Because

  WP:CCC. And there are some IMO poor arguments in those discussions, for example that some Wikipedia editors read Wikipedia logged out, and hence we should show the notice to millions of readers(?). The idea that it encourages editor participation is also shaky. Templates are not an area where a complete newbie can go and can meaningfully contribute to a TfD. No, and what's more likely is far more people go "WTF is this thing? Why does the page look so messed up? What is a "template for deletion" and why am I being shown this?" ProcrastinatingReader (talk) 22:57, 15 May 2021 (UTC)[reply

  ]

• Oppose per all opposes above.   ~ 
  dgaf)  23:01, 15 May 2021 (UTC)[reply
  ]
• Oppose, what is interesting or useful to anyone is not defined by their autoconfirmed status. We show millions of other maintenance messages to all of our users (and many of them are irrelevant to readers not wanting to edit, like {{orphan}} or {{Chinese script needed}}), and TfD is on for only a few days, not many years like some others. (And it is generally a good thing to remind people that Wikipedia is not a finished product and that there does not need to be a distinction between "readers" and "editors"). —Kusma (t·c) 23:14, 15 May 2021 (UTC)[reply]

  You just made a good argument for not displaying {{Orphan}} to readers (and indeed we don't show it to anyone when it's more than a month or so old), but that's a discussion for another time. Ultimately, it'd be nice to have a user preference for displaying editor-focused things like orphan tags or TfD notices, but until that functionality is implemented, autoconfirmed vs. not is the best proxy we have. {{u|Sdkb}} ^talk 06:47, 16 May 2021 (UTC)[reply]

• Support per arguments presented by Aza24 and ProcrastinatingReader. ~ HAL333 23:55, 15 May 2021 (UTC)[reply]
• Oppose There are some IP editors out there. And sometimes participation in xfds is the first step towards more active participation in the project. We could just as easily suppress afd notices, and maintenance templates but we don't, why? Well sometimes they are useful in getting people involved or just getting an outside opinion, and these are far less intrusive than either of those two. Regards, 31.41.45.190 (talk) 01:30, 16 May 2021 (UTC)[reply]
  • Templates are one of the most complex areas of Wikipedia; TfD is not the best place for beginners. {{u|Sdkb}} ^talk 06:40, 16 May 2021 (UTC)[reply]
    • I have to respectfully disagree Sdkb, from the perspective of complexity in terms of policies/guidelines as well as unwritten norms afd is far more daunting. I don't dare to comment on those without reviewing at least some of the guidelines so I'm not spewing nonsense. OTOH I've dropped in on tfds without doing more than re-skimming the top of the page and I've yet to be accused of being a cir case or of making assessments based off out-of-date guidelines. Regards, 31.41.45.190 (talk) 14:11, 16 May 2021 (UTC)[reply]
• Support solves more issues than it creates.
  b} 03:16, 16 May 2021 (UTC)[reply
  ]
• Oppose having these notifications for merge discussions with very common templates such as {{
  tl}}, {{talk header}}, and {{infobox person}} are annoying for all editors. For less common templates, I would want to see these notifications if I am not logged in and constructive IP editors probably would want to see them as well. There are certainly a few notifications that aren't helpful to readers, but I don't think that's a wide enough problem to justify this solution. User:力 (power~enwiki, π, ν) 03:20, 16 May 2021 (UTC)[reply
  ]
• Oppose the implication being that IPs aren't welcome to participate. SpartaN (talk) 07:12, 16 May 2021 (UTC)[reply]
• Oppose Displaying editor-related things to everyone is one of the ways that we are 'the free encyclopedia that anyone can edit.' If you start hiding things because only editors should see them, you will end up with less editors over time. Mike Peel (talk) 07:47, 16 May 2021 (UTC)[reply]
• Oppose these notices do no harm to see. Should we also hide AfD notices? I think it's good to give readers the chance to know about any discussion impacting the content on the page they're reading. Elli (talk | contribs) 10:28, 16 May 2021 (UTC)[reply]

  Elli The comparison to AfD notices isn't particularly fair. An AfD notice is placed on one page where the outcome affects the article a ton while TfD notices can be present on tens or hundreds or thousand of pages with minuscule impact on that page. Here are some examples: Removing a feature that haven't worked for years with around 100k notices, change the internals of in language tags around 300k notices and infobox merge targets whose appearance or parameters won't be affected at all (30k for a currently open discussion over 500k when infobox settlement is involved). --Trialpears (talk) 10:51, 16 May 2021 (UTC)[reply]

  @Trialpears: I guess, the other reason for my reaction against this is for the same reason Kusma has said - In my personal fantasy world "the free encyclopedia that anyone can edit" means, among other things, that we consider every reader to be a potential editor.

  Is it a fantasy that a high percentage of our readers are interested in contributing? Yes. Should we hide the contribution-side of the site from them? Not at all. It's still in the site's vision to include these people.

  Additionally, I think a lot of TfDs do have an appreciable effect on their transclusions (for example, navigation templates). Elli (talk | contribs) 10:55, 16 May 2021 (UTC)[reply]

  Elli, we include AfD notices because they're of substantial use to non-editing readers. They tell readers that the page may have substantial issues, functioning as a kind of stronger version of {{Notability}} or other maintenance tags. They also help out readers who might otherwise try to re-read an article at a later date and be confused when they can't find it. These factors do not apply for TfDs of templates used on a page. The situation here is more akin to a major RfC on an article's talk page. There's no notice about it because it's not something readers need to know to be able to use the page effectively. {{u|Sdkb}} ^talk 22:01, 17 May 2021 (UTC)[reply]

  @Sdkb: we sometimes do have such a notice in articles, such as merge notices (which most readers probably don't care about), RMs (again, and these like to persist at the top of any controversial current event), and tags like {{disputed inline}}. Elli (talk | contribs) 01:21, 18 May 2021 (UTC)[reply]

  The point about RMs having limited relevance to readers is what motivated

  this whole proposal. I think merge notices and disputed online both have relevance to readers: a merge notice signals a potential article change that might otherwise be confusing, and inline disputed warns the reader of potentially biased information. {{u|Sdkb}} ^talk 02:20, 18 May 2021 (UTC)[reply

  ]

• Oppose. We should hide these TfD notices because, there are few IPs participating in TfD. So the solution is, to even decrease the already small amount of IPs participating in TfDs. Sorry, but this just sounds like something Mozilla would do. Don't repeat the same mistake Firefox did, which is to remove features because "nobody is using them".

  However, I would be open to any method that allows to hide these notices. I understand that not everyone is interested in such discussion, but this also applies to autoconfirmed users as well. So I think the best solution here would be to allow an option to hide these notices without discriminating against very new and IP editors. pandakekok9 (talk) 11:01, 16 May 2021 (UTC)[reply]

• Oppose per Elli. We do not need to make it harder for readers to become editors. (I'm reminded that a certain former functionary's first edit was to a TfD he saw transcluded.) Vaticidalprophet 11:26, 16 May 2021 (UTC)[reply]

  I was told that former functionary was hounded for allegedly being a sockpuppet and is now vanished? ProcrastinatingReader (talk) 12:06, 16 May 2021 (UTC)[reply]

  Indeed. The first-edit in question looks very 'convincingly' first-edit to me (it reminds me of my own early XfD !votes). Ironically, a lot of the criticism seemed to be disbelief a new user could possibly find the well-hidden realm of TfD... Vaticidalprophet 12:22, 16 May 2021 (UTC)[reply]

  So, just making sure I got this right, the opposition is arguing here that users should be encouraged to go to TfD because this is the encyclopaedia that anyone can edit. But when someone does that competently, we (with impunity) accuse them of being a sockpuppet. So basically the acceptable threshold is incompetent IP contributions to TfD? ProcrastinatingReader (talk) 12:33, 16 May 2021 (UTC)[reply]

  The acceptable threshold is that the "guilty until proven innocent" way we treat new-through-newish editors as either CIR cases or socks is utterly bizarre and awful, and that we need to get over ourselves. I do not think hiding ever more of the backstage from readers is particularly useful for solving that problem, as it only makes the community even more closed-up. Vaticidalprophet 12:36, 16 May 2021 (UTC)[reply]

• Oppose because most of the opposed arguments make sense to me, and I am in favor of equal transparency for all Wikipedians including both readers/editors and registered/IP users. Huggums537 (talk) 17:41, 16 May 2021 (UTC)[reply]
• Support, per Sdkb. The potential exclusion of a comparatively small number of IP editors from TfD discussions is far outweighed by the mild inconvenience to potentially millions of readers of having confusing clutter at the top of a page. Remember our
  WP:AIM: an accessible encyclopedia. Making thousands of articles slightly less accessible to readers for the benefit of a small subset of editors is contrary to this purpose. 129.49.100.55 (talk) 18:57, 17 May 2021 (UTC)[reply
  ]

  I'm not sure why you are thinking that the TfD notices are making articles less accessible. It's annoying, sure, but makes the article less accessible? There are literally other notices worse than that and arguably makes the article less accessible. Inline {{

  more sources needed}} template? pandakekok9 (talk) 09:17, 18 May 2021 (UTC)[reply

  ]

• Support per ProcrastinatingReader.
  t · c) 07:02, 18 May 2021 (UTC)[reply
  ]
• Oppose: While a grand idea there is a fundamental flaw. Since the "internet at large" uses registration, it is strange that Wikipedia fights against it so hard. I have to register on any place I go on the internet and cannot fathom how registering would place a stumbling block to "allowing anyone to edit". I would not have been hit with two unexplained range blocks (one global) if all registered. However, unless or until there is a change to mandatory registration we cannot tout being an encyclopedia anyone can edit and claim Any contributor to this encyclopedia, unregistered and registered alike, is called a "Wikipedian" and offer restrictions like this. Currently, an unregistered editor (IP editor) holds the same position as I do as a registered editor of over a dozen years. A few of us concerned with the politics of Wikipedia still have to consider the possibility that a reader might see a notice of interest and become an involved "editor" or that currently, although with some restrictions, an IP editor is still a member of the editing community and I am sure many do get involved in TfD discussions. Otr500 (talk) 12:40, 18 May 2021 (UTC)[reply]

  "Restriction" is quite a strong term to use here. We're not talking about semi-protecting

  WP:TfD to prevent IPs from !voting there; any IP that wants could still go there and contribute to the discussions. It'll be less likely they'll find out about a particular situation, yes, but see comments above and below about that being an easy tradeoff to make. {{u|Sdkb}} ^talk 23:50, 18 May 2021 (UTC)[reply

  ]

• Oppose The notion that most readers aren't registered (or even unregistered) editors is hard to credit. Every other "for discussion" template is posted on its article or talk page to bring wider input to the discussion so it makes no sense to try and reduce that input for templates. TFD templates in no way shape or form reduce the access to articles. They are there for a relative short space of time and are much smaller than most FD messages. The fact that some find them aesthetically unappealing is hardly a reason to remove them. MarnetteD|Talk 14:36, 18 May 2021 (UTC)[reply]
• Oppose – I find the proposal confusingly worded. What does the last sentence mean (I feel like the trade off here between IP input and unnecessary notices is acceptable, but I feel like this is something people who aren't TfD regulars should weigh in on as well.? IP editors are often experienced editors who are signed out and who may gain earlier notification of templates they're interested in and qualified to comment on than if they were excluded from such notifications. Dhtwiki (talk) 22:53, 18 May 2021 (UTC)[reply]

  Dhtwiki If we only showed the notice to IP editors I would definitely agree with your analysis but we show them to all IPs. A vanishingly small proportion of views are from editors. We get about 250,000,000 views each day, assume the average person visit 5 pages and we have 50 million unique viewers each day. Perhaps there are 100 IP editors that may be interested in TfDs if they see a notice (I think that would be more than the number of IPs that contributed in the past year). That means with what I think are generous estimates we would get 0.0002% of readers that may be interested. That is several 100,000 readers who don't care about TFD seeing a notice about it for each person who may care. There are lots of things you could debate in this guesstimate, but I have a hard time seeing any somewhat reasonable method getting values other then tens of thousand of notices going out for each relevant one.

  My analogy here would be putting up thousands of posters everywhere in a big city in the hope that you will find one stranger who dropped their hat. Sure, it isn't a big deal at all seeing an irrelevant poster but would it be sensible to put up thousands of them? --Trialpears (talk) 00:30, 19 May 2021 (UTC)[reply]

  How many readers-who-are-not-editors access the talk page at all? How much does it cost to post the message in terms of I/O as opposed to *conditionally* posting the message with the added attendant processing (I know we're not supposed to worry about server-side performance, but still). Dhtwiki (talk) 02:56, 19 May 2021 (UTC)[reply]

• Support. Can anyone think of a single example of a reader who we converted into a prolific editor as a result of a TfD notice? The inconvenience dealt to readers across millions of pages far outweighs any effect on editing. And who is to say that that effect is necessarily positive? It could be that seeing such a scary sign actually puts off potential editors, making them think that Wikipedia's processes are too esoteric for them to learn. -- King of ♥ ♦ ♣ ♠ 03:51, 19 May 2021 (UTC)[reply]
• Oppose, solution looking for a problem. Stifle (talk) 09:15, 19 May 2021 (UTC)[reply]
• Oppose. With these reasons one could suppress the display of all maintenance templates for IP users. But they serve an important function even for readers: they make clear that Wikipedia is a work in progress, that it is based on community discussion is consensus, and that all are free to participate in it. Sandstein 13:19, 19 May 2021 (UTC)[reply]

  For the record, maintenance templates are applied on an article specific basis, usually give tasks that are not technically difficult or require extensive policy knowledge, and probably have better conversion rates. TfD notices tend to be over minor, often housekeeping, merges, often require knowledge of policy and templates, and are broadcasted at scale, and evidence shows do not invite participation. A more apt comparison would be

  WT:MOS discussions, which are far more impactful at scale and not widely advertised to our readers. ProcrastinatingReader (talk) 12:46, 20 May 2021 (UTC)[reply

  ]

• Oppose A username should not be required for participation in any part of Wikipedia. IP editors should have the same expectation to be notified of relevant discussions that may interest them as do autoconfirmed users. --Jayron32 14:32, 19 May 2021 (UTC)[reply]
• Support: Especially when the template is based entirely in text, lately Template:Rotten Tomatoes prose was nominated for deletion and as a result every single transclusion of this template, which is supposed to look like normal text, got tagged with a deletion notice. This is a big inconvenience to our readers who we should always put before our editors. versacespaceleave a message! 13:16, 20 May 2021 (UTC)[reply]
• Oppose O, ye of little faith in readers having the ability to ignore irrelevant TfD messages. Its an intentionally minimally-invasive template that takes almost no effort to mentally dismiss. I suspect strongly that this has almost nothing to do with paternalistically "protecting" users but that the real driver is a desire to not have to deal with input from the hoi polloi of unregistered users which are perceived as uninformed. If they are uninformed, inform them. If they post irrelevant input, give them the tools to make it relevant. This is pretty basic stuff. AfD deals with this on a daily basis and shutting out unregistered users there is an absolute last resort in cases of obvious disruption. This proposal would anomalously make TfD treat unregistered users as shut out by default. Eggishorn (talk) (contrib) 15:30, 21 May 2021 (UTC)[reply]

  I highly doubt your unsupported speculation. Speaking as someone who is both a regular at TfD and who regularly seeks out interacting with newcomers as a Teahouse host, the newcomer presence at TfD is so small that "disruption" from it is essentially a non-issue. Why is it so difficult to AGF believe that some editors care about usability and make related proposals? {{u|Sdkb}} ^talk 16:36, 23 May 2021 (UTC)[reply]

• Oppose per Jayron32's eloquent comment below: There are no such things as "noneditors". There are just "editors that haven't started editing yet". the wub "?!" 13:32, 23 May 2021 (UTC)[reply]
• Strongest oppose per the insightful comments above, and especially the reader-foucused editing observation below.
  talk) 16:56, 25 May 2021 (UTC)[reply
  ]
• Oppose philosophically. IPs are human, too (was one at some point, can confirm). Unless one can present significant evidence of long-term abuse by non-ACs in TfDs, I fail to see what would be gained by the proposal, except the removal of some minor visual annoyance for some users. As for disruption, if one was really intent on doing that, they can just go directly to
  WP:TFD. I don't see what the proposal would even achieve, beyond giving credence to some editor's sentiments about IPs. AfD (and occasionally MfD) are far more prone to the expected kind of disruption, anyway, and when that does happen it's a simple matter. Hence, non-solution to a non-problem. RandomCanadian (talk / contribs) 19:26, 25 May 2021 (UTC)[reply
  ]
• Support any measure that would diminish the eyesore of TfD notices. For all of our readers and 99.9% of our editors, these notices are irrelevant noise. Ugly, confusing notices like these are more likely to dissuade new IP editors from getting involved in the first place. gobonobo ^{+ c} 07:25, 30 May 2021 (UTC)[reply]
• Oppose.
  Wikipedia is a construction zone, and sometimes readers will see a little dust. That may even get a few curious as to how they can join in and participate. For the rest, the notices are neither common nor terribly intrusive. (If an extremely widely used template were up for discussion, an alternate means of notifying the community of the discussion may be reasonable.) Seraphimblade ^{Talk to me} 03:54, 31 May 2021 (UTC)[reply
  ]

Reader-focused editing

I can already see the way this is going, and it's depressing.

readers is probably the most severe form of systemic bias on Wikipedia—it's snarled usability reforms on way too many past occasions, and it's rearing its head yet again in the main oppose argument here. Yes, this proposal involves a tradeoff between the preferences of readers and those of (a few) editors—it's a ridiculously easy trade to make, since IP participation at TfD is miniscule, whereas the prevalence of these notices is enormous. Plenty of IPs are fine editors, but a comment from one of them once a week or so is not worth disrupting literally millions of readers. Please, folks, when you weigh your !vote, keep in mind who we're actually writing Wikipedia for. {{u|Sdkb}} ^talk 06:34, 16 May 2021 (UTC)[reply

]

• In my personal fantasy world "the free encyclopedia that anyone can edit" means, among other things, that we consider every reader to be a potential editor. Non-editing readers do not need the "edit" button or the toolbox on the left. If they really don't want to engage with this, they can go to Wikiwand. —Kusma (t·c) 10:04, 16 May 2021 (UTC)[reply]
  • This. And the TfD notices remind the reader that Wikipedia is a work-in-progress, and always will be. Remember, perfect is the enemy of good.

    I also don't see how keeping those notices makes Wikipedia less usable. It can be annoying, sure, but unusable? That's a bit of a stretch. pandakekok9 (talk) 11:05, 16 May 2021 (UTC)[reply]

I'm a big fan of reader-focused editing. I don't think this is anything near reader-focused editing -- it's, like, one line. What I think of when I think of "reader-focused editing" is the fact literally every non-editor I've happened to discuss the matter with thinks I'm a rabid deletionist. Hate to think what they think of actual deletionism. (That is: reader priorities aren't only not our priorities, but they're often totally different to our priorities in ways that would give the average editor apoplexy.) Vaticidalprophet 11:29, 16 May 2021 (UTC)[reply]

I think it's completely fair to say that the bad of having an unnecessary and potentially confusing notice is many times smaller than the good of a notice reaching someone who is interested. The question is if it's somewhere around 100,000 more good, which is the order of magnitude of the ratio between pageviews of notices to number of non-autoconfirmed editors participating at TfD according to my back of the envelope calculations. I understand that there may be philosophical reasons for not hiding it but purely in practical terms I have a hard time believing it's justifiable to show these notice. --Trialpears (talk) 10:57, 16 May 2021 (UTC)[reply]

I find it unlikely the little bar that appears from this is what turns IPs off when simultaneously we have huge squares at the top of pages about citations and other issues in an article. In fact it's barely noticeable in comparison. I feel we are acting a little too certain maybe it's ugly and they won't like it that we're just assuming that's the case. SpartaN (talk) 12:03, 16 May 2021 (UTC)[reply]

That's how this entire interface is built - from assumptions and extending generally accepted principles to aspects of our interface. We can't commission a WMF research study for every proposal we make. It just seems like Wikipedians are more comfortable relying on assumptions when it means adding something than removing something. ProcrastinatingReader (talk) 12:46, 16 May 2021 (UTC)[reply]

@Sdkb: if the support is about preference for readers, then where did the understanding of readers' preferences come from? Whether I support or oppose hinges on this: do readers actually care about these notices? I don't care if a million pages are loaded with a TfD notice on it if only 1,000 readers actually notice, 50 of them click through and the 49.9 of those who don't leave a comment either go "huh, I wonder how Wikipedia is actually written. Maybe I'll look behind the scenes in some other way" or "Boring, this isn't useful to me". I do care if 10,000 readers find it an eyesore and none learn anything from it. How do I know which is which? No-one seems to have any evidence either way. But if 10,000 found it an eyesore surely some would be clicking through and leaving test comments like "why did you put this notice on the Roman Empire page?" or "are you going to delete the page I was reading? I don't get it". — Bilorv (talk) 22:24, 16 May 2021 (UTC)[reply]

Some evidence: Every time a widely used template is sent to TFD/TFM, crowds show up to say "WHY IS THIS NOTICE HERE?!?!?!?! PLX REMOVE THE NOTICE IT IS DEFACING THE ARTICLEZ" (for some amount of capitals or another). Izno (talk) 01:02, 17 May 2021 (UTC)[reply]

Those crowds tend to be editors, not readers, though. Elli (talk | contribs) 12:53, 17 May 2021 (UTC)[reply]

Why do these kinds of discussions always get framed in a "think about the children" manner. Is their a scrap of empirical evidence that readers stop reading articles because of the TFD notice? Or any of the other discussion notices for that matter. Until well researched studies about people who are only readers react to these the only

dislike the TFD notice. MarnetteD|Talk 23:25, 18 May 2021 (UTC)[reply

]

• There are no such things as "noneditors". There are just "editors that haven't started editing yet". There is no meaningful distinction to be made between "readers" and "editors". We invite all people who read Wikipedia articles to join in on editing them. There is no need to create such imaginary classes of people. The idea itself is antithetical to the very ethos of Wikipedia itself. It is not a finished product, it has no end point, and we don't think of users of Wikipedia as being either readers or editors. All users are invited and encouraged to help out as they see fit, and I find the notion that some people should be classified as "readers" and actively discouraged from helping out is just wrong. --Jayron32 14:32, 19 May 2021 (UTC)[reply]

  I'm very much on board with inviting readers to become editors, but the invitations will be much more likely to work if they're made for newcomer-appropriate tasks. Asking readers to try editing by finding a missing citation is good; asking them to make their first edit by wading into the

  infobox consolidation wars (probably the most frequent way someone would come across a TfD notice) is not. {{u|Sdkb}} ^talk 16:42, 23 May 2021 (UTC)[reply

  ]

Alternate solution to the underlying problem?

The underlying problem here is that TfD notices on popular templates (say, biographical or geographical infoboxes) appear on hundreds of thousands of articles. It is mildly annoying to see notices about some obscure merger proposal that doesn't affect the vast majority of readers (whether they edit or not) on every page you look at. Is it technically feasible to have "dismiss" links on TfD notices? I assume there are good reasons not to have them on every TfD (and on templates with only three transclusions, they aren't so annoying anyway) but could something like this be made to work for templates with more than 1000 transclusions? —Kusma (t·c) 14:00, 16 May 2021 (UTC)[reply]

Sure, if you insert JavaScript to load on every page to allow dismissing functionality. Something like with watchlists at MediaWiki:Gadget-watchlist-notice-core.js, but I imagine the intadmins might have performance concerns with that proposal. I don't think that's the underlying problem anyway; your suggestion is helpful for editors but doesn't fix the problem for readers. I mean yes a global change to templates can alter article pages. But so do CENT RfCs and MOS proposals and we (rightly) don't advertise those to our readers. A dismissible useless notice is still a nuisance. All in all, banner blindness of all forms is a mostly insoluble problem, one of the community's own making and thus no consensus process can fix it. ProcrastinatingReader (talk) 14:22, 16 May 2021 (UTC)[reply]

Why does allowing everyone to dismiss notices not solve the problem that people don't want to see these notices repeatedly? My proposal is to treat editing and non-editing readers exactly the same. —Kusma (t·c) 14:43, 16 May 2021 (UTC)[reply]

I think the ability to dismiss these is an amazing idea. I understand the apprehension behind loading javascript on every page, but this strikes me as similar to the javascript we use to make navboxes collapsible: the implementation opens up a lot of options beyond TfD notices. Personally, I would like the ability to hide TfD notices because they can drag on and I'm not usually interested. But there are tons of notices that readers (and me) might want to dismiss like AfD or CSD notices. It's not even limited to deletion notices, we have templates like {{

Current event}} that are informative but quickly become redundant---the reader probably knows it's a current event (since they're looking it up) and even if they didn't once they see the banner they probably don't need to keep seeing it if they don't want to. It also opens the door to new use-cases for existing templates like the padlock template {{pp}}. I've protected pages where there is a high level of public interest; readers may not understand why a page is protected and draw the wrong conclusions ("Wikipedia is siding with FooBar!"), so instead of using {{pp|smallTemplate:Eqyes}} which produces a padlock icon in the top right, I use it to display a banner which explains page protection and the reason behind it. This is rare (I think I've done it maybe twice) partly because it is incredibly intrusive, but if readers could easily dismiss the banner, the cost of placing it is lowered and we can be more up-front with our readers about when and why a page is protected (not always, but useful for things like BLPs of people in the news for example). So yeah, I think this is an amazing idea regardless of how this RfC goes. — Wug·a·po·des​ 22:52, 16 May 2021 (UTC)[reply

]

 Administrator note Having to manage unique client-side data for each dismissable element can quickly get out of control, as every one would need a unique identifier, relisting would need a new unique identifier, etc. — xaosflux ^Talk 22:05, 17 May 2021 (UTC)[reply]

Xaosflux, that's why I would like to limit this to just a few discussions per month if it is done manually. Or hope for some of our amazing bot coders to work something out :) —Kusma (t·c) 10:39, 18 May 2021 (UTC)[reply]

Do you have an estimate for how many templates for discussion per month are for template with over 1,000 transclusions? If its about 1-10 this alternative sound good, but if its dozens or even hundreds, the burden on the developers/ intadmins might be too large for it to be feasible. Jackattack1597 (talk) 00:45, 20 May 2021 (UTC)[reply]

Time-limited display?

Another possible at least partial solution would be for an agreement that the TfD notice should be shown for a certain period, but then removed. For example, 24 or 48 hours of display would be enough to alert most people interested in such things and removing the notice after that would remove most of the ugliness. Johnuniq (talk) 23:11, 16 May 2021 (UTC)[reply]

This assumes that everyone who is interested in a given template reads a page on which it is transcluded at least once every 1-2 days. I don't think we can reliably make that assumption. While it's likely that someone who reads multiple Wikipedia articles every day will see a noticed that relates to all/most infoboxes within that timeframe, that same reader will be much less likely to see a notice that relates to say {{inflation}}, let alone someone who only looks at Wikipedia once a week. As a real-world example, I look at lots of Wikipedia articles (In the last ~3 months I've visited over 7400 pages on en.wikipedia.org in this browser alone), {{Use Commonwealth English}}/{{Commonwealth English}} have been at TfD since the 14th, yet I've seen a banner about the discussion exactly once (at Head of the Commonwealth). In the past theww days I'm unlikely to have seen a template relating to articles about linguistics, palaeontology, or flags, despite often reading about those subjects. Thryduulf (talk) 00:55, 17 May 2021 (UTC)[reply]

My editing runs in streaks according to my job. I may work 40 hours or 80 and I never sleep much so my editing time is all over the map. I was upset about being hit with a global IP ban (the second so far) so I took a break. When I finally get as trustworthy as an IP editor I am going to try again to get an IP block exemption. The point is that I can't keep up with all the things I would like to do so might miss something in a 48-hour window. I am sure this would be a problem for many. Otr500 (talk) 14:27, 18 May 2021 (UTC)[reply]

It already is a time limited display. It goes away when the TFD is closed. Editors lead lives in the real world that can keep them away from the 'pedia for days at a time. This proposal seems to say that if you haven't seen the TFD in the 48 hours after it is initiated you are out of luck in knowing about the discussion and your input isn't wanted. MarnetteD|Talk 23:13, 18 May 2021 (UTC)[reply]

Feasibility

Is there even a technical way to achieve this? CaptainEek ^{Edits Ho Cap'n!}⚓ 01:06, 18 May 2021 (UTC)[reply]

This is technically trivial: add the autoconfirmed-show class to the output of {{tfm/dated}} and {{template for discussion/dated}} * Pppery * _{it has begun...} 01:09, 18 May 2021 (UTC)[reply]

Mobile users

• Does this notice even display for mobile users? If not, then most of this conversation is practically moot. –MJL ‐Talk‐^☖ 03:48, 23 May 2021 (UTC)[reply]

It does.Gluons12 ^t|c 01:25, 24 May 2021 (UTC)[reply]

Yup, it does display on mobile.--

here 08:55, 27 May 2021 (UTC)[reply

]

Highlighting system

Recently I have been copyediting some Wikipedia articles and fixing grammar issues, however I have noticed that the templates don't specify where is the issue in the article, and it becomes a tedious problem in a long one. I was just wondering about proposing a new system in which editors can highlight the actual issue in the articles, so that way it becomes easier to find the paragraph or sentence that needs to be fixed, especially in lengthy articles. Pink Saffron (talk) 16:54, 18 May 2021 (UTC)[reply]

A template "language problems" and another one called "spelling issues" might be needed yes.

--Joujyuze (talk) 17:41, 18 May 2021 (UTC)[reply]

I think something like this would be a good idea. Two things I dislike: 1)- a tag that is vague with no obvious issue and nothing on the talk page. Maybe it is just too much work to travel all the way to the talk page. A simpler system to go along with a tag might certainly make a difference, 2)- A career tag dated 2007 (any tag in the 3-year range) and many edits and editors since then until now. If I can't find the issue that a tag is supposedly used for I have removed them with talk page comments. I have also sent messages to the editor that placed the tag. All of this creates a longer maintenance time for each article and less available time to look at more articles. Otr500 (talk) 19:00, 18 May 2021 (UTC)[reply]

@Pink Saffron, Joujyuze, and Otr500: We have {{Verify spelling}}, {{Clarify}} and similar templates that can be used inline. {{Copy edit}} also supports per section tagging. All of those also support a reason parameter that can specify the exact problem. – Finnusertop (talk ⋅ contribs) 00:38, 19 May 2021 (UTC)[reply]

@Finnusertop: That's glad to hear! Thanks for notifying me

Too bad they are not used as much as they should be. We can turn on highlighting editing that I think would be of less importance than highlighting issues. Of course, some talk page comments would go a long way. Otr500 (talk) 01:12, 19 May 2021 (UTC)[reply]

I am generally in favour of more specific marking of tagged content. Pale highlighting could work. Explanation/reasons could be added via edit summary. Might be good to leave a mouse-over to show the reason and identify the tagger as well. · · · Peter Southwood ^(talk): 15:37, 19 May 2021 (UTC)[reply]

If the highlight only show up on mouse-over of the tag they would be less obtrusive, alternatively they could require an opt in setting to be default visible. · · · Peter Southwood ^(talk): 15:42, 19 May 2021 (UTC)[reply]

I'd honestly think a more suitable addition would be a more aesthetically pleasing highlighter marking so that it doesn't look like a blushing tomato Pink Saffron (talk) 17:40, 19 May 2021 (UTC)[reply]

I think that the best system would be to return to what I'm sure there was when I started editing Wikipedia - that there should be an expectation that, unless the issue is blindingly obvious, the tagger should state their concerns on the talk page. It is unlikely that this will actually happen, because many people who add tags seem incapable of doing anything that is not automated by Twinkle. We really need to stop valuing quantity over quality.

Phil Bridger (talk) 18:23, 19 May 2021 (UTC)[reply

]

I agree 100% (see above). Career tags that were only clear to the tagger at the time serve little purpose. Another solution is to just delete the tag with talk page comments. -- Otr500 (talk) 04:36, 28 May 2021 (UTC)[reply]

Citations

Moved to Wikipedia:Village pump (idea lab) § Citation needed tagging in VisualEditor

 – Tol | Talk | Contribs 05:10, 25 May 2021 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I think the ability to be able to select and place "citation needed" through the cite feature in the visual editor with a single click would be helpful. Not needed but it would save time. TigerScientist Chat > contribs 21:05, 18 May 2021 (UTC)[reply]

Copy the following text and paste it in any article: {{cn}} This will simply work with the visual editor in the way you're requesting. ~ ToBeFree (talk) 21:09, 18 May 2021 (UTC)[reply]

ehh I guess maybe. TigerScientist Chat > contribs 15:10, 19 May 2021 (UTC)[reply]

You may want to post this on

talk) 19:00, 19 May 2021 (UTC)[reply

]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RFC on moves being marked as minor

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following list: Wikipedia proposals When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

There are many

speedy deleted and others that just need to be improved more. And of course, there is some legitimate minor page moves like this move per WP:ENDASH

. So here are the options I came up with:

1. Status quo. Automatically mark moves as minor.
2. Optional. Leave the option to mark moves as minor or major.
3. Required. All page moves are marked as major.

Yes, this is not a major issue, but I had to bring it up anyways for the editors that do hide minor edits. Sungodtemple (talk) 14:40, 22 May 2021 (UTC)[reply]

• No article title changes are never minor. The suggestion that articles being moved to draftspace should be considered a "minor" edit is too wrong to even engage with. User:力 (power~enwiki, π, ν) 16:20, 22 May 2021 (UTC)[reply]
  • Hmm ... apparently there are minor edits being made along with the log entries. I assumed this was suggesting something about the log entries being considered "minor" edits. This looks like "software weirdness" that nobody noticed. User:力 (power~enwiki, π, ν) 18:24, 22 May 2021 (UTC)[reply]
• I must agree with the above comment. I can't understand the rationale behind marking any move, especially one between namespaces, as minor. Can anyone explain why that is done automatically? I can't believe that that is done without a good reason, but, for the life of me, I can't see what possible reason there might be.
  Phil Bridger (talk) 16:48, 22 May 2021 (UTC)[reply
  ]
• @Sungodtemple: Note, this isn't really something we have a choice on unless this becomes a software option - so a local RfC is going to be advisory at best. See phab:T176053 and linked tasks. — xaosflux ^Talk 19:54, 22 May 2021 (UTC)[reply]
• A page move should NEVER be marked as “minor”. I suspect that the intent was to indicate that the moves are “routine” and probably “not controversial”... but “routine” and “not controversial” are not the same as “minor”. Blueboar (talk) 22:22, 22 May 2021 (UTC)[reply]

  Per

  WP:Minor, a minor edit is one that the editor believes requires no review and could never be the subject of a dispute. So "routine" and "not controversial" are actually a pretty good way to describe them. {{u|Sdkb}} ^talk 20:30, 23 May 2021 (UTC)[reply

  ]

  Note, moves are not "edits" at all; that a null-edit is placed in the history is purely for convenience - moves are recorded in the move log which doesn't have a "minor" indicator. — xaosflux ^Talk 01:28, 24 May 2021 (UTC)[reply]

• No, unfortunately or otherwise, changes of article title can be controversial or just plain vandalism. They're not minor, though in some circumstances they may be easily agreed. Chiswick Chap (talk) 10:39, 24 May 2021 (UTC)[reply]
• The feature of marking edits as minor isn't particularly useful as a whole, so it doesn't matter very much. But given that a move from draft or user space into main space suddenly makes a lot of content appear, so isn't "minor" even from the point of view that edits not changing content are minor: if we do continue to make the distinction between major and minor edits, moves should not be marked as minor. —Kusma (t·c) 10:54, 24 May 2021 (UTC)[reply]
• Two issues are being conflated here. Moving new articles out of draft/sandbox and existing article rename/moves. The latter is almost never going to be a minor edit. The former is almost always going to be minor by the definition we use (with the exception being articles which have been moved back from article space already). Completely new articles by their nature do not *require* review prior to being made live. Our policies and guidelines are clear on this. And until the article is live, realistically there is not going to be much dispute unless its an editor with a history of problematic article creations. The move log already adequately records them, so whats the purpose in having the article history have the minor tag not attached to moves from draft/sandbox? The only real current use of minor flag is to stop cluttering up watchlists. And if you have a new article that is not in article space watchlisted you are either the primary author or someone involved in writing it, in which case you will be aware anyway. This seems like process-wonkery for the sake of it. For existing articles being renamed/moved, what is the practical purpose in preventing the move being listed as minor? What problem does that solve? Only in death does duty end (talk) 11:56, 24 May 2021 (UTC)[reply]

Minor edits

I sometimes forget to toggle minor edits. Maybe the a bot or something automated can automatically determine if it is minor or not. It is already pretty simple so I can see why people wouldn't want to put so much effort into this. TigerScientist Chat > contribs 20:00, 24 May 2021 (UTC)[reply]

Bots don't have the technical ability to change the minor tag of another person's edit (I think), so this is technically impossible. The MediaWiki software could, but it'd probably be a fair bit of work to cook up a decent algorithm to predict whether an edit is minor or not. ProcrastinatingReader (talk) 22:41, 24 May 2021 (UTC)[reply]

Interesting. TigerScientist Chat > contribs 23:12, 24 May 2021 (UTC)[reply]

• Per the instructions that this page is for concrete actionable proposals, brainstorming like this belongs at the idea lab, not here. To address the idea directly, this is a bad task for a bot, since our definition of
  WP:Minor edit is whether or not an edit is potentially controversial. Massive edits can be minor if they're just reverting vandalism, whereas single-word edits to hot topics can be very not-minor. {{u|Sdkb}} ^talk 00:25, 25 May 2021 (UTC)[reply
  ]
• This belongs in the idea lab rather than here since this isn't a firm proposal that you want implementing, but this isn't possible for two reasons:

• It's impossible to edit the minor edit flag once a revision has been saved, it's permanently burned into the database, just like the edit summary, timestamp and revision ID.
• Just like your suggested link bot this program would need to have near human intelligence to determine what is a minor edit or not. Removing a large chunk of text added as vandalism is a minor edit, removing a large chunk of text because it is undue is not. Replacing a dead link in a citation with an archive link is a minor edit, replacing a dead citation with a different site is not. Replacing a number in a table because the previous editor made a typo copying it from a source is a minor edit, replacing a number in a table with a more recent one from the same source probably is not. Removing a Bengali name from an article where it is completely misplaced (e.g. Computer) would be a minor edit, removing an armenian/azeri name from a place in Nagorno-Karabakh would not be.

Your proposed bot would need to be making editorial judgements about what is "uncontroversial" - that is something that would essentially require a AI. 192.76.8.73 (talk) 09:43, 25 May 2021 (UTC)[reply]

Reverting to a stable version of a page, to stop continuous editing of a section, while it is being discussed on a Talk page section

I wanted to ask about the practice of reverting to the previous stable version of a page, while the content of a page is being discussed. I have seen this in practice, where a talk section is established to discuss specific article content, (or an RFC) – and while it was going on, editors were asked to not make changes, and the page was reverted to the long standing version of the page that reflected the section that was being discussed. Then after the consensus was achieved, the page was changed to reflect the decision of the consensus.

The point of this being (1) it stopped random editors who were making changes to the section (with the possibility of starting an edit war) rather than being part of the discussion (2) reverting to the stable version meant that people coming to the talk page discussion, could see the content on the page that was the subject of the discussion.

There’s no rule about this that I could see, I have seen this done, and assumed it was normal, but is this common practice on Wikipedia?... If not, is it a good idea?... I would appreciate your thoughts Deathlibrarian (talk) 02:18, 25 May 2021 (UTC)[reply]

WP:BOLD edit, which is reverted, then a discussion should be started instead of the bold edit being reinstated and beginning and edit war. STATUSQUO refers to leaving the status quo ante while the issue is being discussed, so the first, stable version remains until the issue is resolved. —El Millo (talk) 04:22, 25 May 2021 (UTC)[reply

]

Ah, ok, brilliant, thank you! That may be the policy I couldn't find. It looks like the editors were in fact following this policy. I'll have a read, cheers. Deathlibrarian (talk) 04:43, 25 May 2021 (UTC)[reply]

WP:NOTPOLICY raised in response. It'd be nice if we rectified this. {{u|Sdkb}} ^talk 16:48, 25 May 2021 (UTC)[reply

]

Yeah, "During a dispute discussion, until a consensus is established, you should not revert away from the status quo" I've seen people do it and assumed it was standard protocol, but when I did it, I got called out on it and couldn't find the policy for it. Thanks so much, that was driving me nuts!!! Deathlibrarian (talk) 09:01, 26 May 2021 (UTC)[reply]

• You may also what to read Meta:The Wrong Version. Blueboar (talk) 11:26, 26 May 2021 (UTC)[reply]
• Depends very much on the context. If it's a current event and being heavily edited, this isn't sustainable. If it's a historical event on a mostly stable article, then this is a good idea. And then there's all the in between. Generally it's less contentious and more collaborative to revert to a revision that once had consensus, or is less controversial, while one works on building consensus for the change. ProcrastinatingReader (talk) 12:07, 26 May 2021 (UTC)[reply]
• I rarely find that focusing on what past version might be "stable" to be useful once other editors are involved in talk page discussions and it's clear that editors are disputing content based upon content policy. Hence
  WP:WRONG VERSION
  .
• But if you really want to know good practice, a few additions to what's above: Stable versions should generally be free from disputed content, especially if the disputed content was recently added and there's no strong consensus for it as expressed on the article talk page.
• Consensus can change
  : It's usually best to focus on creating a stronger consensus than identifying a past "stable" version.
• WP:LOCALCONSENSUS
  : Consensus among a limited group of editors, at one place and time, cannot override community consensus on a wider scale. Focusing on a "stable" version can easily become a LOCALCONSENSUS violation, when policy-based arguments are being deferred in order to decide upon what past version may have had "consensus".
• In the recent edit-warring situation that Deathlibrarian was involved (
  ownership. --Hipal (talk) 15:42, 27 May 2021 (UTC)[reply
  ]
• As other people have said,
  WP:PRESERVE means not discarding stuff nobody objects to with a sweeping revert in a situation like that. But in complex situations (eg. lots of people editing a disputed section at once in different and not-easily-compatible ways) there's sometimes no alternative but to revert the whole section, especially if you're not confident about declaring any recent edits uncontroversial. --Aquillion (talk) 16:19, 27 May 2021 (UTC)[reply
  ]

  The problem with implicit consensus is that in many of our articles, "implicit consensus" and "obscure article with a major problem no one noticed for years because it is obscure" look identical. It works only on high-visibility pages. It doesn't work everywhere, and we shouldn't take longevity as the be-all-end-all in determining consensus. --Jayron32 16:31, 27 May 2021 (UTC)[reply]

  Oh, yes, implicit consensus is the weakest sort of consensus and even its limited strength depends on whether many eyes have actually seen and accepted the edit in question. That said, when there's no clear other consensus (and it's not a

  WP:SNOW out. There's a reason we have noticeboards for the most pressing types of issues. In all but the most serious of situations it's usually fine for the page to remain where it was for at least a bit longer while those processes proceed, and if it is a serious situation, bringing it to people's attention on a noticeboard should immediately produce a consensus to fix it.) --Aquillion (talk) 17:33, 27 May 2021 (UTC)[reply

  ]

  I suppose my bar for 'serious issue on a BLP' is lower than most. I'd say any content that seems questionable (per our core content policies; such as being made up, misrepresenting sources, or being blatantly biased) and may have the effect of damaging the reputation of a BLP is a serious issue. Using this definition, I've seen 'serious issues' (IMO) be reported at

  WP:BLPN and have little to no response for weeks. ProcrastinatingReader (talk) 10:58, 28 May 2021 (UTC)[reply

  ]

  I feel that it is often difficult for someone to judge the severity and significance of an issue while they are embroiled in it, but I will point out that there is always another option. If something is a clear-cut, unambiguous BLP violation,

  WP:AE anyway - someone who is doing that ought to be made to stop somehow so they don't just do it on another article.) Obviously, taking that route requires putting your own editing rights on the line - as it should, since we don't want people invoking it frivolously; ignoring 3RR and the prohibition against edit-warring is a big deal. If you're not confident enough to take that step then you might want to consider the possibility that the situation is not as severe as you thought at first and can go the slow route of normal consensus-building, especially if BLPN doesn't seem inclined to react quickly either. --Aquillion (talk) 22:23, 28 May 2021 (UTC)[reply

  ]

• It is way to situationally dependant for us to make any firm recommendations one way or another. I can come up with a dozen good reasons why you would want to go back to the status quo ante bellum, for just one example, if the stable version had a clear
  WP:BURDEN, and that in the case of a dispute, the text under dispute should remain out of the article in question, regardless of what the "stable" version was, until such time as there is consensus that it is added back. But I also recognize that the situation is always variable, and that different edit wars need different responses. --Jayron32 16:28, 27 May 2021 (UTC)[reply
  ]

  I think you mean

  WP:NOCON says longstanding material should remain in. Kolya Butternut (talk) 17:00, 27 May 2021 (UTC)[reply

  ]

  They are both complimentary, and both equally state that inclusion requires consensus.

  WP:BURDEN similarly unambiguous "burden to demonstrate verifiability lies with the editor who adds or restores material" In both cases, they both advise that including material requires explicit consensus. There is nowhere written a similar, explicit statement that non-inclusion of text requires explicit consensus, with the exceptions of NOCON, but that is a much broader concept that covers changes to text (which is not necessarily inclusion or non-inclusion of ideas, and also includes such things as organization, phrasing, tone, etc.) Deciding whether or not some bit of text does or does not belong in an article is a much narrower subset of ideas, and in two different contexts (WP:BURDEN for verifiability and WP:ONUS for relevance) the default state is "don't include", in the absence of a clear consensus. --Jayron32 17:12, 27 May 2021 (UTC)[reply

  ]

  This has been debated elsewhere so I don't want to get into it too much unless you can direct me to other past discussions, but my interpretation is that ONUS does not apply to material that had already achieved explicit or silent consensus. Kolya Butternut (talk) 17:32, 27 May 2021 (UTC)[reply]

  Explicit consensus (as in, we've discussed this and we've decided it's good) yes. "Silent consensus" is not a thing; as I noted elsewhere in this discussion, silent consensus is a synonym for "obscure stuff no one noticed until today". --Jayron32 16:22, 28 May 2021 (UTC)[reply]

  WP:DROPTHESTICK) get taken to ANI or AE for it and could ultimately end up blocked or topic-banned for editing against consensus. If you disagree with this you are free to try and change the relevant policies, or to argue that the current (well-established and completely uncontroversial) practice does not reflect the literal wording of text; but you should not flatly misstate policy and practice as you are doing here. What you are saying is unambiguously incorrect - a no-consensus RFC outcome on whether to remove longstanding text always retains it, fullstop, and whether it has previously been discussed or not is immaterial. --Aquillion (talk) 22:08, 28 May 2021 (UTC)[reply

  ]

  • I was involved in crafting both ONUS and BURDEN ... and we intentionally focused both provisions on the addition of material rather than on removal. The reason we did so is because it is possible to prove that sources exist to support an addition (just cite them). However it is impossible to “prove the negative” (ie you can not “prove” that sources don’t exist). Blueboar (talk) 20:57, 27 May 2021 (UTC)[reply]
    • The issue with
      WP:ONUS to change that, ie. to make the default no-consensus outcome for an RFC over longstanding material to be removal, and to push BRD towards being "bold, revert, delete, discuss" when dealing with such disputed removals? --Aquillion (talk) 21:49, 27 May 2021 (UTC)[reply
      ]

      FWIW: I've seen horrible text on BLPs, technically verifiable but awfully UNDUE, which I've removed, cited ONUS on, and later indeed consensus decided to keep it out. Often when I close RfCs as no consensus I'll say whether it implies the text should remain or be removed. If the article is a BLP, my interpretation of policy is that it usually errs in favour of removal. I don't know if a general rule on this is possible, or even a good idea, but I suppose with sufficient input a carefully worded one could be helpful. ProcrastinatingReader (talk) 10:55, 28 May 2021 (UTC)[reply]

      @Aquillion: On the flip side, what I have personally witnessed far too many times to count, is that people believe that having a source is the entirety of what is necessary to include a piece of text, even in the face of overwhelming consensus. It's almost meme-level at this point that on any given day, there will be a minimum of a half-dozen reports on various DramaBoards where someone's entire complaint is that "so-and-so removed sourced text". As though all that text needs is a source, and then it becomes impervious to any objection. Sources are necessary, but sources by themselves are not sufficient. Things like relevance, tone, NPOV, WP:UNDUE, etc. etc. are all important, and unlike sources, those things require active and explicit consensus. If no one objects, fine, go ahead and add your sourced statement. But once someone comes along in good faith and says "Hey, this seems wrong because WP:UNDUE" or whatever, then we should take the text out and hash it out on the talk page. And, once again, "long term" and "implicit consensus" is just a synonym for "obscure enough that no one noticed until now". --Jayron32 16:29, 28 May 2021 (UTC)[reply]

      No, that is really not a synonym for

      WP:NOCON. Kolya Butternut (talk) 16:55, 28 May 2021 (UTC)[reply

      ]

• As mentioned before,
  WP:3RR which is pretty much the opposite of BRD in that if two editors keep reverting each other with neither blinking, then it's the editor who favours the status quo that will end up with the blockable fourth revert, while the edit warrior favouring change will get their way. Of course, we hope for disputes never to reach such a situation...  — Amakuru (talk) 16:35, 27 May 2021 (UTC)[reply
  ]
• The real fun starts when two wikilawyers get into a debate over which version should have “status quo” or “stable” status. Blueboar (talk) 16:48, 27 May 2021 (UTC)[reply]

  Which is why WP:WRONGVERSION is the best policy out there on how to handle these things. --Jayron32 16:53, 27 May 2021 (UTC)[reply]

Edit filter for AWS URLs that expire

This is a proposal to create an edit filter to block the addition of URLs that pull content from AWS with an expiration time. Example (search on &Expires)

URLs of this type can be identified if they include &Expires=1621985387 where "1621985387" is a unix timestamp seconds since 1970 (converter). The expiration time is often 1 hour or less, after which the URL ceases to function and becomes link rot.

I set up a program to monitor for new inclusions, and issue a SavePageNow at Wayback before it expires, however this is not really working well: the URLs are often already expired by the time the content is committed to Wikipedia and/or the URL was copied from another page or revision and long since expired and/or the program which runs twice an hour doesn't catch it in time and/or the content also requires a password/login which Wayback can't get beyond.

There were old cases in about 550 pages, I ran a bot and checked for working Wayback links to "save" them, it found 35, or about 6% were salvageable the rest were permanently dead with no hope of saving. New one's are being added at about 5-7 a week. These URLs can usually be substituted with more permanent links to the same content (example) - but users will continue to add these links because they work in the moment and there is no realization they expire. -- GreenC 00:31, 26 May 2021 (UTC)[reply]

So why? What should the editor use instead?

WP:SAYWHEREYOUGOTIT says to do just that. Now, it could be that these are just purley unreliable sources - and that would be a reason, and the deny reason could tell the editor why. Basically, if we want to deny this on a basis that they are always bad, it needs to be coupled with a message of why this is an unacceptable source. — xaosflux ^Talk 00:42, 26 May 2021 (UTC)[reply

]

The source (ie. citation), and the URL, are different things. URLs are not required in a source, they are optional. Unclear why we are knowingly adding dead URLs that can never be archived, taking up the |url= spot. -- GreenC 01:50, 26 May 2021 (UTC)[reply]

Is it dead on arrival? What if it "expires" in 20 years - does that make it useless for readers now? In the example you put above, if the editor would have left that blank instead of putting in that cloudfront.net link - wouldn't it have been worse for a reader or other editors? — xaosflux ^Talk 10:50, 27 May 2021 (UTC)[reply]

Sounds like a good idea. Mathglot recently raised a similar issue with library proxied URLs which could maybe be addressed with an edit filter as well. We should't stop people copying and pasting an unstable URL from their address bar instead of the permalink from the page, but it wouldn't hurt to have an informative warning telling them it's a bad idea. – Joe (talk) 11:05, 27 May 2021 (UTC)[reply]

Would it be possible to bot replace such links? Jo-Jo Eumerus (talk) 11:19, 27 May 2021 (UTC)[reply]

No, other than adding a {{dead link}} -- GreenC 00:04, 29 May 2021 (UTC)[reply]

Filters can be requested at

WP:EFR, but I think this falls into bad use for a filter, because the filter should mainly be used for abuse, not to enforce possibly 'bad' edits. A bot would be preferable, if there's consensus. ProcrastinatingReader (talk) 13:25, 27 May 2021 (UTC)[reply

]

I agree that a bot would be better, or even increased frequency if one already runs. Edit filters run on every edit which is a lot of work for little gain, so it might be better to fix it after the fact or notify those who added it (like disambiguation links) rather than check every edit for expired links. — Wug·a·po·des​ 20:27, 27 May 2021 (UTC)[reply]

What would a bot do, though? I don't think these can be automatically fixed. – Joe (talk) 11:40, 28 May 2021 (UTC)[reply]

User:Wugapodes suggested a talk page notification. Plus a {{dead link}} .. might be a way to go. -- GreenC 00:04, 29 May 2021 (UTC)[reply]

Simplify your signature

Moved to Wikipedia:Village pump (miscellaneous) § Simplify your signature

 – {{u|Sdkb}} ^talk 17:42, 30 May 2021 (UTC)[reply]

Two-year range date-of-birth categories

Before I embark on a quixotic quest to create a bunch of categories that could potentially prove controversial, I thought I'd throw it out here for community approval.

Here's the situation. We generally categorize biographical subjects by year of birth (e.g., Category:1965 births). We have thousands of subjects for which we know their age as of a certain date, but don't know which of two potential years was their actual year of birth. For example, Sheri Benson (born 1962/1963), Helena Brunner (born 1957/1958), Matt Galloway (born 1970/1971). Currently all of these subjects are categorized by decade of birth (e.g., Category:1960s births), but I think we could be more precise by creating categories like Category:1962–1963 births. This would also separate out the subjects for whom we have that sort of two-year window from subjects for whom we have much vaguer knowledge that they were born in a certain decade, but could have been born any time in that decade. BD2412 T 04:51, 29 May 2021 (UTC)[reply]

That seems unnecessary to me. It would just create a bunch of very short categories, and very short (non-maintenance) categories are usually discouraged. Chicdat (talk) 11:11, 29 May 2021 (UTC)[reply]

Why not just categorize them in both years? It's not not accurate, it's just the best we can do based on the best information we have. Categorizing by decade seems like it doesn't cover someone born in say 1959-60, or 1899-1900, and I agree that creating a series of very short categories for all of these unusual occurrences seems like over-categorization. Ivanvector (^Talk/_Edits) 11:31, 29 May 2021 (UTC)[reply]

Putting them in both would be my instinct too, and I'm pretty sure I've seen it before for historical figures though I can't think of examples off the top of my head. —Nizolan ^{(talk · c.)} 22:33, 29 May 2021 (UTC)[reply]

After some searching I can say that Andrew Marcus is the only article about a single person in two 1980s birth categories, so it basically doesn't happen currently. --Trialpears (talk) 22:37, 29 May 2021 (UTC)[reply]

Right, by "historical" I meant pre-20th century but granted I can't find examples right now either. —Nizolan ^{(talk · c.)} 22:46, 29 May 2021 (UTC)[reply]

Same result for the 1850s but here Max Hirsch (economist) is the only article. --Trialpears (talk) 22:49, 29 May 2021 (UTC)[reply]

I'm not really thinking of very old article subjects, as I think the convention of saying 'so-and-so, age' is fairly recent. However, I would consider it problematic to list, e.g., Sheri Benson above in both 1962 births and 1963 births because one of those is factually incorrect, and we know it. I hope to some degree that having range categories like those proposed would lead some editors to dig in and find more accurate date-of-birth information for the subjects in those categories. BD2412 T 00:34, 30 May 2021 (UTC)[reply]

@Trialpears: I just realised that I was remembering Wikisource, where the double category is the (automatic) convention, and not Wikipedia, e.g. s:Author:Thomas à Kempis. Confusion on my part, sorry. —Nizolan ^{(talk · c.)} 14:23, 30 May 2021 (UTC)[reply]

Another option would be to create a set of, e.g., Category:Circa 1965 births, which would include people probably born in (or around) 1965, but would not project inaccurate claims that we know the person to have been born in that specific year. BD2412 T 04:40, 30 May 2021 (UTC)[reply]

• Remember that the purpose of categorization ISN’T to pigeon hole the subject ... it is to aid navigation between articles.

I have no problem listing someone in two “birth year” categories if we are not sure which applies. For the purpose of navigation to and from the article, it is better to be overly inclusive. Presumably the relevant bio article would make the uncertainty about the subject’s birth date clear in the first few sentences. Blueboar (talk) 15:24, 30 May 2021 (UTC)[reply]

I have seen such category additions reverted in the past, where there was no source for the specific year. BD2412 T 16:55, 30 May 2021 (UTC)[reply]

Process request: A requested edit template and queue for partially-blocked editors

I partially blocked an editor from article-space today for a three-year history of unreferenced changes and inappropriate categorizations of BLPs. In my advice to the user I started to suggest that they request edits on talk pages, and then realized that we don't have an edit request process specifically for this. We have {{

edit protected}} series for pages that are protected, but none (that I know of) for parblocked editors. I ended up suggesting they use {{edit fully-protected

}}, but that's a half-solution, and requests with those templates on articles that are not protected are routinely rejected for only that reason.

I propose creating an {{

boldly myself, but creating a new queue could have wide-reaching implications, so I'd like to gauge consensus first. Ivanvector (^Talk/_Edits) 11:27, 29 May 2021 (UTC)[reply

]

@Ivanvector: I am amazed that you do not know of Template:Edit partially-blocked. 🐔 Chicdat  ^{Bawk to me!} 12:34, 29 May 2021 (UTC)[reply]

Putting Chicdat's somewhat unnecessary tone aside, that template seems to be a good solution. It doesn't categorise into a specific category, and I agree with Ivanvector that it should to allow for easy reviewing. I've also created {{

edit partially blocked}} as a redirect to match the other edit request templates. firefly ( t · c ) 14:28, 29 May 2021 (UTC)[reply

]

It's not clear to me that edit requests from editors blocked from editing a given page should be given a separate queue from all edit requests (and thus potentially higher prioritization), given that their contributions have been deemed disruptive for that page. isaacl (talk) 15:06, 29 May 2021 (UTC)[reply]

Personally I think it's less about giving them higher priority and more ensuring that they get the higher scrutiny they no doubt require - with a separate queue they are easily identifiable as request that require handling more carefully. firefly ( t · c ) 15:15, 29 May 2021 (UTC)[reply]

Also there may be editors who are willing to handle COI edit requsts but not partially blocked edit requests or vice versa making it easier for them to find the ones they want to process. --Trialpears (talk) 15:21, 29 May 2021 (UTC)[reply]

True enough that edit requests from editors blocked from a page are likely to be more contentious, and it might be nice to flag this without putting the request into a separate stream where it may jump ahead of other requests. It's not clear to me though if there are a lot of admins unwilling to deal with the usual queue of requests (generally conflict-of-interest situations) that are only looking for contentious requests to process. isaacl (talk) 15:44, 29 May 2021 (UTC)[reply]

Putting these requests in a separate stream could just as well result in them jumping behind other requests. It is just an acknowledgement that they are different from other types of request.

Phil Bridger (talk) 17:45, 29 May 2021 (UTC)[reply

]

I'm dubious as to how different they really are in essence. Edit requests using the template are from editors whose edits require additional review for the page in question. Whether that's due to a conflict of interest or a prior dispute, the responding editor is going to have to examine the past history of the requestor and the page to establish context and the best steps forward. isaacl (talk) 23:28, 29 May 2021 (UTC)[reply]

Regarding hinting at level of scrutiny, I think once the request is read, even ignoring the different template that is assumed to be used correctly, the request text will make it evident. isaacl (talk) 15:44, 29 May 2021 (UTC)[reply]

Who is going to volunteer to fulfill edit requests from partially blocked editors??? I cannot comprehend the notion that there is a person who is disruptive enough that they they need to be blocked from mainspace but we still want them to make edit requests. I mean, just indef them. This isn't a day care, right? Levivich 17:00, 29 May 2021 (UTC)[reply]

If they are only partially blocked then the partially-blocking admin has seen a spark of potential redemption. Surely making edit requests is a way towards this?

Phil Bridger (talk) 17:45, 29 May 2021 (UTC)[reply

]

I've used p-blocks this way and I've answered edit requests from them on my user talk. Some people do useful, gnome-ish work, but for whatever reason won't follow particular policies like

WP:CIR issues, but competence is a spectrum and completely prohibiting editing is not always the best solution to the problem. I think adding a (sub-)category for these kinds of requests would be useful for sorting them out per Trialpears. — Wug·a·po·des​ 23:04, 29 May 2021 (UTC)[reply

]

Indeed I did not know about {{edit partially-blocked}} (or I wouldn't have posted this in the first place, of course) and I appreciate that Chicdat pointed it out. Still, I do think that this sort of edit request ought to be categorized separately from COI and protected requests, since they require a different sort of scrutiny. Not necessarily more, just different. And if they're not being categorized at all, then who is answering them? Ivanvector (^Talk/_Edits) 23:27, 29 May 2021 (UTC)[reply]

The template is a wrapper for the {{Request edit}} template and thus is categorized as an edit request. It's not clear to me that the scrutiny is substantially different: the responding editor needs to familiarize themselves with the background context and determine the best next steps to determine if the edit can gain consensus support, or act as a starting point for an edit that the interested parties can agree upon. isaacl (talk) 23:36, 29 May 2021 (UTC)[reply]

I agree, I don't think it's different scrutiny so much as just editor interest. Dealing with COI edits doesn't interest me (partly because I don't know that area of policy well enough to handle requests), and I think protected edit requests are better answered by talk page watchers when possible since they can review the content better than I likely would. So I don't answer edit requests much, but I'd be interested in answering p-block requests if there was a category. Whether that's useful for the project as a whole, maybe, but

I like it. — Wug·a·po·des​ 00:06, 30 May 2021 (UTC)[reply

]