Wikipedia:Village pump (proposals)
Idea lab
First discussion New post
The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:
Discussions are automatically archived after remaining inactive for nine days.
« Archives, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181

Centralized discussion
Village pumps policy tech proposals idea lab WMFmisc
For a listing of ongoing discussions, see the dashboard.
view edit history watch archivetalk purge
Consolidating help venues
Moved from Wikipedia:Village pump (policy)
AFAICS, we have a few primary help venues for questions of a general nature:
I don't know exactly what the difference between Teahouse and Help desk is (in this MP discussion other editors raised this point), possibly the former is considered useful for newbies and the latter for experienced editors? Though skimming the Teahouse and HD I don't really get the impression that these are really distinct in terms of questions asked. More importantly, my feeling is that Wikipedia:Editor assistance should probably be redirected somewhere, as that venue is completely inactive and mostly goes back to pre-2011, and WP:EAR should probably be redirected to either Teahouse or the help desk as it doesn't seem to have any distinguishing features from either. ProcrastinatingReader (talk) 16:10, 20 April 2021 (UTC)
resolved venue discussion
@​ProcrastinatingReader​: I'm missing which policy or guideline this is seeking to create or amend - perhaps a different venue would be more appropriate for this. — xaosfluxTalk 17:34, 20 April 2021 (UTC)
I think I'd meant to post this at VPR (only just realised it's at the policy pump). I'll move. ProcrastinatingReader (talk) 17:37, 20 April 2021 (UTC)
IIRC, even some of our level-one warning templates direct them there.
– Pelagicmessages ) – (12:45 Sun 25, AEDT) 01:45, 25 April 2021 (UTC)
Proposal: deprecate WP:EA/WP:EAR and close down all active templates or help pages linking to it
There is consensus to enact this proposal, to consolidate help venues, hence the less active one is closed down. It has been suggested to redirect these pages, but there is no consensus as to exactly where. starship.paint (exalt) 04:01, 31 May 2021 (UTC)
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.
  • Support No point in newcomers being directed to an inactive venue. Pages also needs marking as 'historic'. Pinging ProcrastinatingReader as OP. Nick Moyes (talk) 23:10, 23 April 2021 (UTC)
    Nick Moyes, where are you getting the idea it's an inactive venue? The oldest request was the 16th, and the newest on the 30th. Huggums537 (talk) 14:32, 1 May 2021 (UTC)
    @Huggums537: Here are the figures:
    Hope this helps, Nick Moyes (talk) 23:39, 1 May 2021 (UTC)
    Yes, this does help because I can see the "inactive" tag was improperly attributed to a forum that is actually just "less active", a misrepresentation I wouldn't have been so miffed about if it had been properly presented as "nearly" or "almost" inactive. Huggums537 (talk) 10:57, 2 May 2021 (UTC)
    Ok Nick Moyes, I owe you an apology for harping about the "inactive" tag bit. Upon further investigation, it seems the idea originated from the original post of ProcrastinatingReader who said the venue was, "completely inactive", leading others such as GreenMeansGo, Levivich, and Sdkb to conclude the venue was of a "historical" nature. ProcrastinatingReader could you explain why you described the venue as "completely inactive"? I'm assuming good faith that you were referencing the EA signup page not the EAR project page, and had no intention to misdirect anyone. I also agree that page is not very active. However, I think it is very similar to the signup page of many other projects, and that it is not intended to be be all that active since it's only real purpose is for people to sign on to the project. Many of these project signup pages are not really that active. This is hardly grounds for putting any project into a "historical" condition, or calling it completely inactive when an editor signed up for the project just a month and a half ago. Huggums537 (talk) 12:31, 2 May 2021 (UTC)
    The statement is quite clear: More importantly, my feeling is that Wikipedia:Editor assistance should probably be redirected somewhere, as that venue is completely inactive and mostly goes back to pre-2011, and WP:EAR should probably be redirected to either Teahouse or the help desk as it doesn't seem to have any distinguishing features from either. It does not say what you seem to think it says. The last 5 registrations go back to 2018, and the last 10 go back to 2012, almost a decade ago. That's "completely inactive". ProcrastinatingReader (talk) 13:16, 2 May 2021 (UTC)
    @Huggums537: While they may not be entirely dead, there is still probably some calculation to be done there about whether we're confusing new editors by having unnecessary duplication of forums that have very little variation in scope. As already covered, there is a non-overlapping region for TH and HD. That's largely due to efforts like HostBot, that specifically target new users.But we're not doing ourselves any favors if we have so much redundancy that "where do I ask my question" ends up being somebody's first question. Alternatively, if you have links to helping forums far and wide, and a new user that doesn't know hot to use their contribution history, and can't find the question once they've asked it. GMGtalk 16:05, 2 May 2021 (UTC)
    I agree more calculations would need to be done because I very seriously doubt we would be facing any "where do I ask my question" issues. This is an irrational fear-based argument that has no basis in reality since the status quo has not already produced any significant amount of such issues that I'm aware of. There is no reason to expect that leaving the EA/EAR and TH/HD intact would cause things to change in that way. However, removing EAR removes options available to a user that are not available in the other help forums such as the ability to make certain dispute/content/edit requests. This is entirely useful for those who have no interest in a venue so vile as the peanut gallery. I recently discovered the joy of Wikipedia:Dispute resolution requests and found it extremely helpful to have dispute options available so that I could find a more friendly and suitable way to resolve a dispute. More options are better. See my bathroom argument below. Huggums537 (talk) 16:47, 2 May 2021 (UTC)
    We have lots of issue-specific noticeboards and general question venues. Unnecessarily splitting up conversation reduces good outcomes, both in terms of answers to question asked and in confusion to the asker. There's a legitimate argument that merging HD+TH would cause the volume to be so high that the merge is counter-productive (hence it hasn't been proposed). Same is not true of EAR. We have {{edit request}} and WP:DR venues like WP:DRN and WP:3O. If EAR is duplicating the work of 4 different systems, and doing so in an inferior manner, then that's absolutely not a productive venue. ProcrastinatingReader (talk) 17:11, 2 May 2021 (UTC)
    The key question as I mentioned previously is whether or not the requestors and responders feel the system works well for them. I don't like telling volunteers that they should stop working in a way they find productive just because I think they could be productive elsewhere. isaacl (talk) 17:20, 2 May 2021 (UTC)
    It's not just because they'll be productive elsewhere, it's because having too complex a system scares off new volunteers. There's a survivorship bias in who actually makes it to posting a question, and many editors get intimidated simply when faced with multiple places to ask a question. While we would like them to be bold and pick one, many people are afraid of choosing wrong and getting yelled at so they just don't post. Duplicating work can be harmful, and if volunteer workflows are harming efforts to bring in more volunteers then yes I think we should ask them to learn a new workflow. — Wug·a·po·des 06:54, 3 May 2021 (UTC)
    Wugapodes, where is your data or any evidence to suggest that any such harms have been occurring with the current processes? I grow weary of these fear-based arguments rampant on Wikipedia without any rational evidence to back them up. This proposal is essentially asking that we go intrude upon a group happily conducting business, and force them to pack up shop to do business in places they may not want to, and in ways that are not exactly the same as they are accustomed to all because we think we know better, or don't like what they are doing, and all in the name of less activity. That makes just about as much sense as boarding up the guest room so nobody can use it at all since it doesn't get used that much anyway. Huggums537 (talk) 11:27, 3 May 2021 (UTC) Also, your argument suggests we should put a sign over the boarded guestroom door that says, "Harmful! Do not enter!" It's kind of comical actually. All this talk about "duplicating" work as if we are somehow going to be multiplying things just by leaving them as they happily have been is really absurd. The Wikipedified logical mentality mystifies me. Huggums537 (talk) 11:48, 3 May 2021 (UTC)
    If there's a problem with the productivity of one or more of the help systems from the point of view of questioners or responders, then certainly we ought to examine means to improve matters. I've only seen theoretical examples here, though, which is why I think we should talk to the participants for the different initiatives, see what they think, and give them wide latitude to decide what modes of operation work well for them. Regarding being yelled at, I think the ideal solution is not to yell at anyone, and provide reassurance upfront that no matter where someone asks for help, the request will be directed towards responders who can help. Imperfect world that this is, that might mean moving the request to a more specialized venue (such as the technical village pump for questions tied to MediaWiki's implementation, the reliable sources noticeboard for questions on appropriate sources, and so forth), which I think is manageable. isaacl (talk) 20:13, 3 May 2021 (UTC)
    I agree. Relating this to my guest room analogy above, we have to consider that in this case the guest room is actually currently occupied. I think it would be far more proper to get the opinions of the guests themselves as to how harmful they think the guest room is as opposed to suddenly tossing them all out under the pretext that we *think* it might be harmful, then trying to justify it by saying it wasn't used that much anyway so board it up and we'll slap a "Danger" sign on it to make ourselves feel better about it. Huggums537 (talk) 07:08, 4 May 2021 (UTC)
    If requests for assistance are still being answered suitably, the venue is still active. isaacl (talk) 17:18, 2 May 2021 (UTC)
    Agree with points made by Isaacl. Huggums537 (talk) 17:41, 2 May 2021 (UTC)
    It would probably be impossible to know. I guess we could look on the user talk pages of the editors listed there for any questions asked, but it'd be impossible to know WP:EA is where they came from. With ~150 pageviews per month, I'm not optimistic. In any case, the format is IMO archaic and inferior to newer systems. ProcrastinatingReader (talk) 17:43, 2 May 2021 (UTC)
    Well, there are the requests on the request page for which you can see the responses and response time. If you're thinking about direct contact with helpers, personally I wouldn't call it an inferior mechanism: one-on-one assistance can be effective. In any case, I don't think a shutdown should be imposed. Feel free to have a chat with the editors involved and reach a consensus that answering questions at the help desk would be essentially equivalent. isaacl (talk) 18:45, 2 May 2021 (UTC)
  • Support per comments in section above. {{u|Sdkb}}talk 23:29, 23 April 2021 (UTC)
  • Support - ditto Levivich harass/hound 00:46, 24 April 2021 (UTC)
  • Support – very sensible and solid proposal that hopefully begins to address our issues with help venues. Aza24 (talk) 01:37, 24 April 2021 (UTC)
  • Support per Aza24. ProcrastinatingReader (talk) 07:46, 24 April 2021 (UTC)
  • Support per Nick Moyes. EpicPupper 23:21, 24 April 2021 (UTC)
  • Support Assuming we haven't missed anything, this seems like a no-brainer. ElKevbo (talk) 02:56, 25 April 2021 (UTC)
  • Makes sense. ~ HAL333 20:36, 28 April 2021 (UTC)
  • Oppose because this seems like a useful venue to me, and I don't understand why anyone thinks the venue is inactive since there are currently 15 open requests. I also don't understand why notice was given about this discussion on the Teahouse and Help Desk talk pages, but not the other two, so I will do that now. Huggums537 (talk) 14:32, 1 May 2021 (UTC)
  • Support it may have been useful historically, but now it seems to be an unnecessary duplication of the Help Desk. – Teratix 14:38, 1 May 2021 (UTC)
    Except the Help Desk does not offer dispute resolution or take edit requests like EAR does even though they might be able to do so if asked, but it isn't offered as a standard feature, so it's not really a duplicate. Huggums537 (talk) 10:57, 2 May 2021 (UTC)
    There are many other forums that offer dispute resolution (both content- and conduct-related). I'm not sure what you mean by "take edit requests", since those are posted on articles' talk pages. If you're intending to convey the generic meaning of "helping implement a suggested edit" – these are already easily handled by the Help Desk (example from today). – Teratix 01:23, 4 May 2021 (UTC)
    Teratix, that wasn't the point. You said EAR was a "duplication" of Help Desk, and it isn't because EAR does disputes and Help Desk does not. Neither does Teahouse. Therefore this idea about EAR being a "duplication" is an incorrect assessment. Huggums537 (talk) 05:58, 4 May 2021 (UTC)
    EAR doesn't seem to "do disputes"; one of its first instructions to potential requestors is that discussions related to content disputes might better be addressed at the dispute resolution noticeboard. But even if EAR did resolve disputes, I would merely update my assessment from "EAR duplicates the functions of Help Desk" to something like "EAR duplicates the functions of the Help Desk and DRN". My core argument would be unaffected. – Teratix 09:38, 4 May 2021 (UTC)
    Except we aren't discussing the merging of DRN, we are discussing the merging of help forums. So, I think it's an irrelevant part of your core argument. Also, just look at some of the request history and you can easily see that they DO handle disputes. Huggums537 (talk) 14:56, 4 May 2021 (UTC)
    I don't mind having a discussion, but if you don't accurately represent my views, you won't make any progress towards changing my mind. We aren't discussing the merging of DRN. I never said DRN should be merged. You can easily see that they DO handle disputes. I've clearly explained that the question of whether EAR resolves disputes is irrelevant to my core argument – EAR duplicates the functions of other Wikipedia forums. None of your three replies have actually addressed this point. – Teratix 02:13, 5 May 2021 (UTC)
    I've been trying to address the point, but you're not accepting it, or I'm not explaining it well enough. EAR offers services that the Teahouse and Help Desk do not, such as those also found at DRN, and other forums. Since we are comparing and discussing the merging of help forums it is an invalid, and false equivalence to compare the services of EAR to the other help forums, therefore it is also invalid saying EAR is a "duplicate" of the other help forums. It is not. It is unique. It borrows from several forums. Likewise, you would never claim EAR to be a "duplicate" of DRN since it offers other services DRN does not such as help requests. DRN is strictly dispute resolution so it would be an unfair comparison, not a "duplicate". Just because something has similar qualities does not make it "duplicate". I don't think people understand what a "duplicate" is, or they are just throwing the term around far too loosely. Either one of these things would be equally sub-optimal. In a nutshell, I think the "duplication" argument (of help or any other Wikipedia forums) about EAR is an invalid one. Huggums537 (talk) 03:46, 5 May 2021 (UTC)
    Once again, you're not accurately representing my views. I'm not claiming EAR is an exact duplicate of a particular alternate forum, I'm claiming it duplicates the functions of other forums. It is also invalid saying EAR is a "duplicate" of the other help forums. It is not. It is unique. It borrows from several forums. Yes, that's my point; it has no functions that are not fulfilled elsewhere! At this point, you've argued your view in about 20 comments and replies to other editors, without making any headway. In my opinion that comes close to bludgeoning the process. It might be time to step back from discussion. – Teratix 09:15, 5 May 2021 (UTC)
    I'm glad we could finally get down to the bottom of your actual point. If you had only said this at the beginning instead of claiming it was a duplicate of the Help Desk, it would have saved us a lot of discussion to get to your point. However, there is a big difference between having a long discussion to get to your point, and "bludgeoning the process". It's very poor form to accuse other editors for disruptive editing because of your own lack of being able to explain your point properly in the first place. Any other comments I've made elsewhere have only been in those specific places where I felt a response was needed to make a case for keeping EAR. At any rate, I still feel that your point is wrong anyway because [overlooking that] EAR does in fact perform a function that is not performed elsewhere by virtue of the fact that it is the only help forum that also does disputes and other requests. The very fact that it "duplicates the functions of other forums" is evidence that it is a forum that fulfills a function in a way that no other forum does. With that, I will stop commenting here before anyone else decides to make any wild bad faith accusations. Huggums537 (talk) 13:30, 5 May 2021 (UTC) In other words, EAR is the only forum I am aware of that fulfills the function of combining these other services. Huggums537 (talk) 15:41, 5 May 2021 (UTC)
    I suggest we not get stuck on semantics and adopt a holistic view. It's not essential to label the editor assistance initiative as a help forum, nor is it necessary to only look at other venues labelled as help forums as potential replacements. (If everyone participating in the editor assistance project were happy to move activity to other areas, for instance, I don't think it matters if those other areas are all help forums.) isaacl (talk) 04:46, 5 May 2021 (UTC)
    Isaacl, Well, yeah if they were happy to go to other forums then they would just choose to go to whatever they prefer, either DRN or Teahouse, but if they like both, then we would be splitting their interests across multiple venues and creating the very problem that IP user said we would be solving. Huggums537 (talk) 05:22, 5 May 2021 (UTC)
    Well, you've already argued for the benefits of having multiple venues in which editors can get assistance. Note there's no need to ping me to this discussion.isaacl (talk) 05:31, 5 May 2021 (UTC)
    Yes, I do argue for more choices and options to be available. I think EAR offers that in a very unique way that others do not. It can do more than the help forums can, and it is not as awful as ANI. However, you seem to be implying that since I've argued for more choices, I shouldn't be making an argument about forcing contributors to go to more places. Well, they are really two different arguments, aren't they? I feel just fine making both of them. Sorry about the ping. The script puts it in, and I sometimes forget to remove it. Huggums537 (talk) 06:13, 5 May 2021 (UTC) BTW, thank you for attempting to point out the apparent paradox of my arguments, as the larger paradox of creating the very problem we are trying to solve by implementing the solution has been revealed... Huggums537 (talk) 07:58, 5 May 2021 (UTC)
    No, I was just saying I don't need to discuss the advantages of being able to handle questions on one or more venues, as both sides see fit, since you've already done so. It's normal for processes to change over the years, which can mean creating new ones or eliminating old ones. If there is a shortage of volunteers to make one process work effectively, then we may need to consolidate efforts; as the size of the English Wikipedia community grows, it may be more effective to have more specialized initiatives. isaacl (talk) 16:02, 5 May 2021 (UTC)
  • Oppose The OP's claim is false. Page statistics indicate that activity has been quite constant and stable in recent years and is far from zero. Andrew🐉(talk) 15:00, 1 May 2021 (UTC)
    See comparison stats above. Nick Moyes (talk) 07:15, 2 May 2021 (UTC)
    That's also just half the point, the other is that it causes needless redundancy and unproductive decentralization. Aza24 (talk) 07:22, 2 May 2021 (UTC)
    The main thing I notice from the stats above is that the person who adds the most text to the Teahouse is one Nick Moyes. So, what we have here is a takeover bid in which smaller rivals are crushed and destroyed. The trouble is that you do not get economies of scale in Wikipedia. Bigger is not better because wiki pages become unusable when they get too large, becoming unreadable and having technical trouble with template overload. And, if you force people to do things in the one true way, then volunteers who don't care for this will tend to withdraw their labour. So then fewer volunteers are given a larger workload. This may work for a while but you then get burnout of a single point of failure. Notice how the Signpost is in crisis again because its centralised structure is burning out the chief editor once more. My !vote stands. Andrew🐉(talk) 08:56, 2 May 2021 (UTC)
    I kind of agree with Andrew Davidson. This logic that we already have a place being used for help so we don't need another is akin to the family who upgraded their home from a 1 bed/1 bath up to a five bedroom home and said to themselves; "we don't need another bathroom, we need a centralized place for everyone to pee to make things easier". It's completely senseless. Also, there is no redundancy in keeping EAR when you are comparing two forums that offer different kinds of services and EAR offers services the others do not. However, even if it were a "redundant" service, I think my "more bathrooms is better" argument still applies. Huggums537 (talk) 10:57, 2 May 2021 (UTC)
    This bathroom argument does not fit—I can't believe I'm saying this, but more bathrooms is of course helpful because only a single person can use it at a time, but that is not the case with these help venues. Having multiple locations for purposes with no significant difference is just not helpful, it's confusing, dividing up resources and repetitive. And why are we acting like there's some conspiracy here? " smaller rivals are crushed and destroyed" I mean what????? The page views data has shown that the activity at EAR is certainly lower, and at the rate it's descending I see no reason to believe diverted traffic could overwhelm the teahouse or help desk, both of which are extremely efficient. In fact, if anything, it will hardly have an effect at all in the average "workload" at these places. Centralization is not inherently negative, it's the a core practice of WP—the Sign Post is completely incomparable, and has a host of its own issues. Aza24 (talk) 17:05, 3 May 2021 (UTC)
    Splitting up noticeboards only works well in my experience when each of the sub-noticeboards has a specific purpose and takes a specific section of the traffic. Look at some of the successful splits, the village pump, for example, has separate sections has separate sections for policy, WMF relations, technical stuff etc. Can you imagine the mess if instead we'd split it by creating "Village pump 1", "Village pump 2", "Village pump 3" etc, and the rules were "Post on whatever board you feel like"? If we want to split the help boards into smaller sections it should be done by splitting the help desk into topics, e.g. "help with templates", "help with sourcing", "help with policy and guidelines". I don't think the bathroom analogy really fits either, I think the situation is more akin to buying a five bedroom home, then buying the identical home next door, trying to live in both at the same time and wondering why you're ending up with everyone congregating in the same house. (talk) 17:29, 3 May 2021 (UTC)
    In my experience, I see plenty of processes on Wikipedia that work well without being centralized. One example I can think of right off the top of my head are these very help forums under discussion. What evidence has anyone offered that any of these forums have not worked well other than low traffic status? That's no indication whatsoever about whether the forums have or have not worked for the people who are using them. If anything, it's only an indication that the forums with more traffic were advertised more, and the ones with less did not get as much exposure. Huggums537 (talk) 06:19, 4 May 2021 (UTC)
    Having low traffic is inherently bad for a help board - to give people good and timely advice you need a large base of volunteer helpers with a range of experience answering questions. Yesterday someone on the board asked for help with an article dispute involving the sizing of an image in an infobox - it took 8 hours for them to get a response, which basically boiled down to "Usually we leave the image size at default". They asked a follow up question about how to prevent future edit wars, which as of writing this comment, has been unanswered for 14 hours. Looking through the talk page archives this is not an uncommon occurrence. People have laid out other issues with having multiple help boards above and below, not least of which is that it's extremely confusing for newcomers looking to ask a question to be faced with multiple pages with completely different names that do the same thing. (talk) 09:41, 4 May 2021 (UTC)
    And so you think mass consolidating all three forums into one huge conglomerate is going to actually reduce response times as opposed to making them longer? I would seriously rethink that position if I were you. Huggums537 (talk) 14:56, 4 May 2021 (UTC) Also, your decry about response times is rather laughable. I invite you to look at some other consolidated and unified venues that are proving they don't work such as Articles for Creation where the backlog is over 5,000 and the response time is measured in months not hours or you could look at something like the unblock request system and see how you like those response times. Admins should be able to review a block just as easily as a dispute is reviewed at EAR, but they don't and that's what you get for your unified consolidation. Huggums537 (talk) 15:55, 4 May 2021 (UTC)
    The comparison with AfC seems sound. I just took a close look at the Teahouse and found that it's just an unfocussed Q&A board – there doesn't seem to be any of the gentile socialising which its name suggests. There, Nick Moyes explains that "Sadly, quite a lot of our work here is telling hopeful editors that they stand no chance of their pet article becoming a reality..." and so we see that it's mainly a hostile obstruction just like AfC. As an event coordinator who regularly deals with new editors at editathons, I make sure to steer new editors away from AfC and I will now be treating the Teahouse in the same way. And this also shows how careful you have to be with statistics. If the Teahouse is actually having an adverse effect by discouraging newcomers and driving them off rather than helping them, then making it busier may make matter worse. What we need are statistics on the effect of these various help desks. Which of them actually increase productivity and retention and which hurt it? Andrew🐉(talk) 08:38, 5 May 2021 (UTC)
  • Support Make sense to me.Afernand74 (talk) 13:59, 2 May 2021 (UTC)
  • Comment- LOL, "takeover bid". What absolute nonsense. Reyk YO! 14:10, 2 May 2021 (UTC)
  • Support Per NickMoyes's data above. We should not be dividing our efforts because having too many venues confuses newbies. It's best to steer new editors to a single place to ask questions or make requests, and the Teahouse got 30x more traffic than WP:EAR in 2020 so I think we should go with that one. Editors active at EARS can still continue to fulfill requests, just watch the Teahouse for them instead. — Wug·a·po·des 06:47, 3 May 2021 (UTC)
  • Support. I don't see the value in having multiple venues with overlapping focus, and I think it creates more issues than it solves:
    • It's confusing for newcomers, who are already confronted with a huge number of noticeboards, help pages and discussion forums. As an example, if you were looking to find out if a source is usable in a draft you're writing you could be directed to WP:TEA, WP:RSN, WP:HD, WP:AFCHELP or WP:EAR, all of which could be suitable places for asking your question.
    • It splits volunteer contributors across multiple pages, which means helpers who are experts in one aspect of editing may miss questions posted on a help forum they don't check often, resulting in lower quality answers.
    • People asking for help on the lower traffic noticeboards will have an unnessasarily longer waiting times for responses. Some of the questions on WP:EAR took 3 hours or more to get a response, which isn't ideal for a newcomer in the middle of writing their first page. (talk) 16:45, 3 May 2021 (UTC)
      Since EAR offers multiple services such as dispute resolution and help services, you are still splitting volunteer contributors across multiple forums. For example, if a volunteer at EAR likes reviewing disputes and helping new editors at one centralized location, they will now have to split their efforts across multiple venues because they will now need to go to both Teahouse and DRN. Huggums537 (talk) 05:29, 5 May 2021 (UTC)
  • Support EAR is a moribund page, and having too many options is detrimental to the efficient operation of any of them. We wouldn't have to if it were a well-used part of Wikipedia. Though it may have been in the past, it isn't now, and we're better served shutting it down. --Jayron32 16:06, 4 May 2021 (UTC)
    Nobody has provided any evidence whatsoever that this so called "moribund" page has been of any detriment to the operation of any of the others in any way at all. Huggums537 (talk) 05:00, 5 May 2021 (UTC)
  • Support The slow proliferation of Wikipedia behind-the-scenes forums is inevitable, but a well-maintained garden needs pruning from time to time. This seems sensible. Ganesha811 (talk) 01:08, 5 May 2021 (UTC)
  • Support - make the pages redirects. — Ched (talk) 03:58, 5 May 2021 (UTC)
  • Support Rather a few large venues than many small ones. CaptainEek Edits Ho Cap'n! 21:23, 8 May 2021 (UTC)
  • Support, when I founded the Editor Assistance project, it was mainly as a reaction to the closure of the old "Association of Members' Advocates", so that people would have somewhere to go and ask for advice. Any more, it does seem rather duplicative of what the Teahouse does, and it makes sense to have a single place to direct people to get help and advice on editing rather than several. Seraphimblade Talk to me 13:39, 14 May 2021 (UTC)
  • Oppose There is no harm in diversity as long as the different venues are clear about what they are for — GhostInTheMachine talk to me 15:34, 16 May 2021 (UTC)
  • Support. Sensible consolidation, as this page isn't so active and doesn't seem to have a distinct identity and purpose from the Help Desk / Teahouse / Dispute resolution. the wub "?!" 00:13, 19 May 2021 (UTC)
  • Support consolidation with the Help Desk.  – John M Wolfson (talk • contribs) 14:44, 23 May 2021 (UTC)
  • Support I think the case made for consolidation is convincing. --Trialpears (talk) 15:27, 23 May 2021 (UTC)
  • Oppose. EAR and the Help Desk have different purposes. At the Help Desk, you ask "how can I do this?" At EAR, you say "I'm not able to do this, can someone please do it for me?" Admittedly, some users ask things at EAR which should have been asked at the Help Desk or Teahouse, but that's not a reason to get rid of it. Maproom (talk) 07:45, 29 May 2021 (UTC)
    So... it duplicates edit requests? ProcrastinatingReader (talk) 09:11, 29 May 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Proposal: Close down Help Desk and replace with Teahouse
I find a clear consensus against this proposal. Editors feel that the Help Desk and the Teahouse have differing purposes, cultures, and intended audiences. Extraordinary Writ (talk) 18:07, 25 May 2021 (UTC) (non-admin closure)
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.
Before I start, I know that this is most definitely going to be very constroversial, and I just want to put it out there to get some feedback on it. The Teahouse looks like a great replacement to the Help Desk, the hosts system works well, there is a nice onboarding process for new questions, and it looks pretty welcoming in general. I think that consolidating the Help Desk and Teahouse would also help some of the confusion for where to ask questions as well. Thoughts? EpicPupper (talk) 04:44, 9 May 2021 (UTC)
  • I strongly oppose this. I help out at both places occasionally and they are intended for different situations (new vs experienced users). There is no need to merge them and doing so would only add frustration. Elli (talk | contribs) 21:16, 12 May 2021 (UTC)
  • Oppose and no. Huggums537 (talk) 21:58, 12 May 2021 (UTC)
  • Oppose if I want help I go to a help desk. If I want tea I go to a tea house. DuncanHill (talk) 22:03, 12 May 2021 (UTC)
  • Oppose even now, if I need Help in a topic where I don't know anything about the field at all (3D images was an example) I go to the Teahouse, because helpers there know to start from first principles. But for most of my questions, I only need to know how to handle a specific edge case - running me through all of copyright as a primer would be undesired, so I ask that at the Helpdesk etc Nosebagbear (talk) 12:31, 13 May 2021 (UTC)
  • Oppose. The cultures of these two help venues are distinct. Help Desk serves experienced editors and Teahouse newbies. When answering at these venues, I don't need to check the asking editors' credentials and tailor my response accordingly because it's assumed. – Finnusertop (talkcontribs) 12:48, 13 May 2021 (UTC)
  • Oppost per Nosebagbear and Finnusertop. MB 13:24, 13 May 2021 (UTC)
  • Oppose. The Help Desk is inherently designed as and functions as a place for all editors to go, including the experienced ones. the Teahouse is specifically for new editors, needing basic help. ---Sm8900 (talk) 🌍 14:31, 13 May 2021 (UTC)
  • Oppose per above, they have clearly defined and distinct domains, and they are both very active. No need to shut down either. --Jayron32 14:32, 13 May 2021 (UTC)
  • Oppose The two venues are intended to be different in character — GhostInTheMachine talk to me 15:36, 16 May 2021 (UTC)
  • Oppose. The Teahouse has a distinct culture and identity, which research has shown to be effective in retaining new editors. Merging in the Help Desk would dilute this, and reduce its effectiveness. the wub "?!" 00:14, 19 May 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Proposal: Replace Main Page Help Desk link with Teahouse link
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)
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. (talk) 23:18, 25 May 2021 (UTC)
Great idea! nagualdesign 23:23, 25 May 2021 (UTC)
leave things until the Growth team featured are fully implemented
WP:Mentorship tools gives new users a much easier path to get help. Might want to let those stabilize in production before making major changes. –xenotalk 13:47, 30 May 2021 (UTC)
Like EpicPupper (he/him | talk, FAQ, contribs) 21:35, 9 June 2021 (UTC)
Restricting GFDL-licensed uploads
Why GFDL is impractical for visual media
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)
^ The term "GFDL software" was based on a misunderstanding. GFDL was created two decades ago to accompany free software licenses because using free software licenses for manuals was considered odd. GFDL was adopted by some software projects for their manuals, but never for the software itself. Since GFDL-licensed software doesn't exist, it is not possible to extract anything from it. Software logos, diagrams or screenshots can only be extracted from GFDL-licensed software manuals, which do exist. This note was added by Alexis Jazz, coauthor of this proposal. Apologies for any confusion that may have arisen from this error. — Alexis Jazz (talk or ping me) 15:17, 12 May 2021 (UTC)
^ 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)
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)
@Pandakekok9: Exactly what OID said, I saw your proposal it just didn't make any sense, sorry. Regards, (talk) 14:21, 16 May 2021 (UTC)
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)
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)
@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)
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)
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)
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)
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)
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).
So the numbers conform that it is only Wikipedians that still use GFDL (primary one user). --MGA73 (talk) 19:16, 25 May 2021 (UTC)
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)
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:
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)
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)
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)
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)
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)
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)

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)
  • 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)
  • Oppose Books still exist, fix the software and books will come back to life. Headbomb {t · c · p · b} 18:42, 15 May 2021 (UTC)
  • Oppose What? Per Headbomb. Throwing out the baby with the bath water. Fix the software! Littleolive oil (talk) 18:47, 15 May 2021 (UTC)
  • 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)
    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. Headbomb {t · c · p · b} 19:12, 15 May 2021 (UTC)
    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)
    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. Headbomb {t · c · p · b} 12:56, 16 May 2021 (UTC)
    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)
    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. Headbomb {t · c · p · b} 21:33, 16 May 2021 (UTC)
  • 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)
  • 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)
  • 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)
  • Support as secondary option to deletion for the reasons given in the comment below. ƒirefly ( t · c ) 20:30, 15 May 2021 (UTC)
  • 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. Beeblebrox (talk) 20:50, 15 May 2021 (UTC)
  • 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 Book:European history doesn't exist, not as a book, nor as a redirect to something relevant. Not a good start in terms of ease of searching when the mainspace equivalent (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 Book:EuropeHistory, which illustrates all the worst problems with books. Created by a single user in 2009 - 2011, the only edits since have been the occasional bit of wikignomery. Massive due weight problems: why does the roman empire get a total of 4 articles, while the European union gets 134? Why is there no mention of world war II? What is cruft like List of tallest buildings in the European Union, Galileo (satellite navigation) and 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. (talk) 21:05, 15 May 2021 (UTC)
  • 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)
  • Support. Please! Gog the Mild (talk) 21:59, 15 May 2021 (UTC)
  • Oppose for lack of any benefit in doing so. Nemo 22:00, 15 May 2021 (UTC)
    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)
  • 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)
  • Support. It's a feature that never gained much traction and is obsolete now. -- RoySmith (talk) 00:20, 16 May 2021 (UTC)
  • Support. —¿philoserf? (talk) 02:09, 16 May 2021 (UTC)
  • 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)
  • 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)
  • 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)
  • Support This is a broken namespace and massive waste of time. — Preceding unsigned comment added by Jackattack1597 (talkcontribs)
  • Oppose I oppose anything that uses the word "deprecate" — GhostInTheMachine talk to me 14:07, 16 May 2021 (UTC)
  • Support, but archive the content. —Kusma (t·c) 14:13, 16 May 2021 (UTC)
  • 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)
  • 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)
  • 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). 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)
  • 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 wordsdeeds 22:18, 16 May 2021 (UTC)
  • 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. EpicPupper (talk) 04:14, 17 May 2021 (UTC)
  • Support per 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)
    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)
  • 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)
  • 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)
  • 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)
  • Support This is an encyclopedia, books belong to Wikibooks. So how about moving the books to Wikibooks instead of deleting them? -Killarnee (CTU) 17:22, 18 May 2021 (UTC)
  • 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)
    What time is required by our outsized editor? — GhostInTheMachine talk to me 18:10, 19 May 2021 (UTC)
  • Support. Unmaintained features should be removed. Sandstein 07:09, 20 May 2021 (UTC)
  • 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)
  • 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)
  • 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)
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.
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)

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)
  • 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)
  • Support on a temporary basis. With the re-enabling of indexing when/if the PDF renderers are fixed. Headbomb {t · c · p · b} 18:45, 15 May 2021 (UTC)
  • Support - as a minimum, per my comments in support of deprecation. Levivich harass/hound 19:22, 15 May 2021 (UTC)
  • Support per nom; this should go along with deprecation. {{u|Sdkb}}talk 20:19, 15 May 2021 (UTC)
  • Support per all the above. Beeblebrox (talk) 20:51, 15 May 2021 (UTC)
  • 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. (talk) 21:17, 15 May 2021 (UTC)
  • 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)
  • 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)
  • 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)
  • Support. —¿philoserf? (talk) 02:10, 16 May 2021 (UTC)
  • 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)
  • 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)
  • 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)
  • 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)
  • Support: per my reasoning above. — Bilorv (talk) 22:10, 16 May 2021 (UTC)
  • Support per above. EpicPupper (talk) 04:15, 17 May 2021 (UTC)
  • 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)
  • Support makes sense — GhostInTheMachine talk to me 11:54, 17 May 2021 (UTC)
  • 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)
  • 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)
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.
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)

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)
  • 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)
  • Support on a temporary basis. With the re-enabling when/if the PDF renderers are fixed. Headbomb {t · c · p · b} 18:44, 15 May 2021 (UTC)
  • Support - per my comments in support of deprecation. Levivich harass/hound 19:23, 15 May 2021 (UTC)
  • Support, as something that should go along with deprecation. {{u|Sdkb}}talk 20:21, 15 May 2021 (UTC)
  • Support. —¿philoserf? (talk) 02:14, 16 May 2021 (UTC)
  • 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)
  • 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)
  • Support to along with namespace deprecation proposal above. – SD0001 (talk) 07:11, 16 May 2021 (UTC)
  • Support Makes sense to limit the books to user space — GhostInTheMachine talk to me 14:02, 16 May 2021 (UTC)
  • 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)
  • Support: per my reasoning above. — Bilorv (talk) 22:10, 16 May 2021 (UTC)
  • Support. Makes sense along with depreciation. EpicPupper (talk) 04:16, 17 May 2021 (UTC)
  • Support as a step towards removing the namespace entirely. Ajpolino (talk) 05:53, 17 May 2021 (UTC)
  • 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 (TALKCONT) 07:06, 17 May 2021 (UTC)
  • 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)
  • Support. the wub "?!" 13:56, 23 May 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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)
Delete all books within the book namespace
WP:REFUNDs to user space would be possible. If all books are deleted the namespace should be uninstalled if deemed appropriate by the developers. This would remove it from lists of namespaces in places like Special:Search and Special:RecentChanges and allow pages like 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)
Oppose for historical reasons. Books should be deprecated instead and left at that. Tyrone Madera (talk) 20:13, 28 May 2021 (UTC)
Hide TfD notices for non-autoconfirmed users
‹ The template below (Example) is being considered for deletion. See templates for discussion to help reach a consensus. ›
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)
Survey (TfD notices)
Reader-focused editing
I can already see the way this is going, and it's depressing. Systemic bias toward the needs of editors compared to 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)
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)
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)
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)
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)
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)
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)
@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)
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)
Those crowds tend to be editors, not readers, though. Elli (talk | contribs) 12:53, 17 May 2021 (UTC)
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 systemic bias I am seeing is toward the needs of editors who dislike the TFD notice. MarnetteD|Talk 23:25, 18 May 2021 (UTC)
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)
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)
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)
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
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)
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)
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)
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)
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)
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)
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)
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)
Is there even a technical way to achieve this? CaptainEek Edits Ho Cap'n! 01:06, 18 May 2021 (UTC)
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)
Mobile users
Does this notice even display for mobile users? If not, then most of this conversation is practically moot. –MJLTalk 03:48, 23 May 2021 (UTC)
It does.Gluons12 t|c 01:25, 24 May 2021 (UTC)
Yup, it does display on mobile.--Vulphere 08:55, 27 May 2021 (UTC)
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 autoconfirmed editors who have no idea that their article is not ready for mainspace. The tag #new user moving page out of userspace is quite a good example of this. If you surf through the list of articles at https://en.wikipedia.org/wiki/Special:RecentChanges?hidebots=1&hidecategorization=1&hideWikibase=1&tagfilter=de-userfying&limit=50&days=7&urlversion=2 you will see many articles that could definitely be 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)
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)
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)
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)
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)
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)
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)
Same result for the 1850s but here Max Hirsch (economist) is the only article. --Trialpears (talk) 22:49, 29 May 2021 (UTC)
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)
@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)
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)
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)
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)
Or two centuries. Or millennium. Then there are time zone issues, relative to place of birth. IMO this discussion is an artifact of computer architecture which wants 1 or 0, and has trouble with gradients and nuance. Maybe pick one (best) version of the truth for the black and white stuff like categories, and explain nuance in the body of the article. Creating duplication in categories is breakage IMO. -- GreenC 03:20, 9 June 2021 (UTC)
The original proposal is to avoid duplication in categories by creating a new set of categories like Category:1962–1963 births where the subject is known to have been born sometime during that span. It would work just as well for a Category:1959–1960 births or a Category:1999–2000 births. Articles in those categories would not be in any other date of birth categories. If the subject's actual birthdate was determined, they would be recategorized to the specific year. BD2412 T 04:38, 9 June 2021 (UTC)
Each sibling would only belong in one year. I couldn't see why you would have a combined article unless they were conjoined. And having conjoined twins born in different years would be next to impossible.--Khajidha (talk) 17:11, 7 June 2021 (UTC)
Khajidha, regarding I couldn't see why you would have a combined article unless they were conjoined, see Dionne quintuplets, which is in all of Category:1954 deaths, Category:1970 deaths, Category:2001 deaths, and Category:Living people. -- RoySmith (talk) 02:45, 9 June 2021 (UTC)
I'd think the thing to do in such instances would be to create redirects from the individual names and put the year-of-death categories on the redirects. BD2412 T 03:09, 9 June 2021 (UTC)
Sorry, but if we don't know the exact year of birth, we should not be trying to put them in categories based on exact years. I don't care how much "easier" it makes some things. This strikes me as lying to our readers. It makes no sense to be "easy and wrong". If the two years are in the same decade, I could see a category like Category:1960s births with uncertain years. --Khajidha (talk) 14:00, 7 June 2021 (UTC)
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 {{request edit}} for COI editors, and the {{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 {{edit partially blocked}} request template (with instructions to reviewers to check the requester's block log, similar to how we advise reviewers to check the protection log for pending changes) which would populate Category:Wikipedia partially blocked edit requests, and adding a sublisting of pages in that category to Wikipedia:Dashboard in the requested edits section. I could do this 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)
@Ivanvector: I am amazed that you do not know of Template:Edit partially-blocked. 🐔 Chicdat  Bawk to me! 12:34, 29 May 2021 (UTC)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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:NOTBROKEN. Requiring review of their edits before going live is a good compromise between losing a useful volunteer and letting reports about them clog up ANI. Technical restrictions like blocks and protection should be sparing and only as much as we need to prevent disruption (i.e., create a net-positive outcome). Blocks are one way to handle 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)
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)
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)
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)
I don't know if I fully agree regarding categorization or requiring the same scrutiny, but insofar as the request to create a template for pblocked editors to request edits, this can be considered resolved. Thanks to all. Ivanvector (Talk/Edits) 18:19, 2 June 2021 (UTC)
Change the partial block message to be orange or yellow instead of red
This proposal is clearly successful, and at this time, I think we should transition to talking about how we're going to implement the proposal. Mz7 (talk) 19:12, 11 June 2021 (UTC)
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.
Tech note: this is about styling the child div box .mw-contributions-blocked-notice-partial .mw-warning-with-logexcerpt in Special:Contributions that displays this text when a user is partially blocked.
If at all possible, I think that we should change the partial block notification box from red to either orange or yellow in order to differentiate partial from full blocks. This would be helpful to reduce confusion - most obviously for sysops who might not notice the message says "partially blocked" instead of "blocked" and not take action on disruptive editors, but also for other patrollers who might refrain from reporting a problematic editor if it seems at first glance like they have already been blocked. This was brought up a couple months ago, but there was not a substantial amount of discussion beyond determining that it may be technically possible to do something like this. Aspening (talk) 03:02, 1 June 2021 (UTC)
I agree - the present notice looks too much like a siteblock. This is particularly confusing when encountering partial blocking on ranges. Acroterion (talk) 03:10, 1 June 2021 (UTC)
  • I agree as well, full blocks and partial blocks should be more quickly and easily distinguishable. —El Millo (talk) 03:39, 1 June 2021 (UTC)
  • Support this as well. — Ched (talk) 09:18, 1 June 2021 (UTC)
  • Sure. ProcrastinatingReader (talk) 09:25, 1 June 2021 (UTC)
  • Great idea. Slightly embarrassing it's taken us so long to notice actually! ——Serial 09:44, 1 June 2021 (UTC)
  • Seems entirely reasonable, no real reason not to and plenty of good reasons for doing this. firefly ( t · c ) 10:13, 1 June 2021 (UTC)
  • I would support orange; yellow is usually considered to be more cautionary. 331dot (talk) 10:15, 1 June 2021 (UTC)
  • Are we talking about {{uw-pblock}} or something else/more? --Trialpears (talk) 10:18, 1 June 2021 (UTC)
    That's not very red. I assumed the log notice when you open a user's page to edit? ([9]) ——Serial 10:37, 1 June 2021 (UTC)
Looks entirely reasonable. Support. EpicPupper (talk) 18:06, 1 June 2021 (UTC)
Some notes for nerds are in here. See the mini-hatnote above for what the specific box is being disucssed
@Aspening: can you be more specific, exactly what templates/messages/etc do you want to change? (I have no idea what the partial block notification box is referring to). For example, here is a recent partially blocked user - what specifically do you want to change? This may very well not require a full VPPR discussion to make a color tweak. — xaosflux Talk 14:51, 1 June 2021 (UTC)
Xaosflux: Aspening is probably referring to the red box on the top of this page: Special:Contributions/Ioannesko Sungodtemple (talk) 14:53, 1 June 2021 (UTC)
@Xaosflux: I'm referring to the box that appears on the user's special:contributions page that says "This user is currently partially blocked." I am suggesting that that box should be orange or yellow for partial blocks to reduce confusion per the reasons listed above by myself and other users. 331dot also brings up a good point that yellow is more cautionary, so I'm now leaning more towards having this box be orange. Aspening (talk) 14:57, 1 June 2021 (UTC)
@Aspening: OK, so that box is wrapped in a class, "mw-contributions-blocked-notice-partial", but itself is in a div with classes "warningbox mw-warning-with-logexcerpt mw-content-ltr". The second of those classes is being used for the styling from common.css. The message itself is from MediaWiki:sp-contributions-blocked-notice-partial​. So adjusting the color style is not super-easy, but markup can be added to the message very easily (see example at testwiki:Special:Contributions/Example~testwiki​). Would markup something like that be enough to address your concern? — xaosflux Talk 15:11, 1 June 2021 (UTC)
@Xaosflux: Possibly - I think a color change would be preferable, but if that is difficult or impossible I think that emphasizing the partial block in that way could be satisfactory. Aspening (talk) 15:17, 1 June 2021 (UTC)
@Aspening: I added the emphasis to to the text at least for now. Coloring may be blocked on a technical challenge as there is a class collision with mw-warning-with-logexcerpt there. Perhaps someone else has a technical idea that isn't an ugly hack. — xaosflux Talk 15:29, 1 June 2021 (UTC)
Uh, is it an ugly hack to just overwrite it with .mw-contributions-blocked-notice-partial .mw-warning-with-logexcerpt {border-color:#fc3;background-color:#fef6e7;}​? I didn't think that was verboten in CSS practice, but I'm no expert... Writ Keeper  15:36, 1 June 2021 (UTC)
@Writ Keeper: I only said "may" :) Something like that could work, putting in hyper-specific styles in the common.css isn't ideal, but we don't have much else to work with on this message so may be the way. — xaosflux Talk 15:47, 1 June 2021 (UTC)
The box is yellow per the MediaWiki defaults. Our common.css code is making it red. So having another rule to put it back to yellow may not be unreasonable. – SD0001 (talk) 15:52, 1 June 2021 (UTC)
@SD0001: I'm not disagreeing with the color choices, just that applying layer after layer of overlapping css via common.css isn't ideal (even when it is the only tech option), that specific implementation isn't a hard blocker. That we are currently styling on "warning-with-logexcerpt" there isn't ideal either, but it is what it is. If this proposal keeps trending towards support we can mock up some technical solutions. — xaosflux Talk 16:04, 1 June 2021 (UTC)
  • Support Seems reasonable. --Jayron32 15:22, 1 June 2021 (UTC)
  • Administrator note I've added some emphasis to MediaWiki:Sp-contributions-blocked-notice-partial while this is being discussed. If this proposal is implemented ideally that message can be deleted to default. — xaosflux Talk 18:12, 1 June 2021 (UTC)
  • Makes sense to me. ~ HAL333 01:04, 2 June 2021 (UTC)
  • I support orange because it's generally easier to read than yellow. —pythoncoder (talk | contribs) 20:16, 2 June 2021 (UTC)
  • Support To reduce confusion between partial and full blocks. — Preceding unsigned comment added by Jackattack1597 (talkcontribs) 01:26, 4 June 2021 (UTC)
  • Support either colour. Distinguishing full and partial blocks will reduce confusion and reduce the likelihood of unfortunate misunderstandings. Thryduulf (talk) 20:34, 4 June 2021 (UTC)
  • Support. Current display is confusing. – SD0001 (talk) 07:01, 6 June 2021 (UTC)
  • Support per everyone. Distinguishing partial blocks from site blocks is an improvement. No colour preference. Ivanvector (Talk/Edits) 12:08, 6 June 2021 (UTC)
  • Support per WP:SNOWPRO with preference for orange. Huggums537 (talk) 17:46, 6 June 2021 (UTC)
  • Support It's more intuitive, which helps the 'pedia. Tyrone Madera (talk) 19:22, 7 June 2021 (UTC)

Technical implementation
@Xaosflux, Aspening, Writ Keeper, and SD0001: I can see in your collapsed conversation that there is a potential MediaWiki:Common.css hack that could do this (e.g. to change the red back to the default yellow), but it seems more discussion on the technical implementation is needed. What would be necessary to implement this proposal? Mz7 (talk) 19:12, 11 June 2021 (UTC)
Testing on testwiki (​testwiki:MediaWiki:Common.css​) - waiting for update to populate it. — xaosflux Talk 21:07, 11 June 2021 (UTC)
Test cases:
  1. Normal block: testwiki:Special:Contributions/Xaosflux2
  2. Partial block: testwiki:Special:Contributions/Xaosflux2a
@Mz7: that what you are looking for? — xaosflux Talk 21:12, 11 June 2021 (UTC)
@Xaosflux: Ooh, yeah. That looks really nice. Mz7 (talk) 21:27, 11 June 2021 (UTC)
Doing...xaosflux Talk 21:49, 11 June 2021 (UTC)
 Done @Mz7: see live example at Special:Contributions/Example​. If there are any issues please post at MediaWiki_talk:Common.css#pblock-style​. — xaosflux Talk 21:58, 11 June 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Display UTC with current UTC time
I propose that instead of displaying the Time Zone as "UTC" plus an offset, it should be displayed as the current UTC (at time of page load) in addition to a refresh link.
- Current: UTC+05:00 - Proposed: 04:33, 5 June 2021 (UTC) + 05:00 [refresh]
This format will allow the viewer to easily compute the local current time while avoiding the complexities of trying to dynamically display the correct current time at that place. Nbardach (talk) 04:44, 5 June 2021 (UTC)
Please take the hint: it's not going to happen. Someone looking at the page on 1 July 2021 is going to be totally confused when seeing a cached time such as 04:33, 5 June 2021. Wikipedia does not support dynamic displays and displaying confusing text is not a good replacement. Johnuniq (talk) 04:54, 5 June 2021 (UTC)
@Johnuniq: It already happens on all of the Time Zone pages (ex: UTC-08:00), which each display the Current Time in that Time Zone plus the [refresh] link. Why should this be any different? — Preceding unsigned comment added by Nbardach (talkcontribs) 06:08, 5 June 2021 (UTC)
Hi, MediaWiki developer here. I think displaying the current time is a (technically) perfectly reasonable and trivially achievable proposal to implement on Wikipedia.
I do fully agree with the concerns laid out above in this section and the previous, in so far that it would be absurd to implement this with wikitext in a server-side fashion. However, such thinking is exactly why ideas and technical implementation need to be more separated from one another. Doing this server-side would require software changes to allow minute-level parser cache expiry (which I would not approve), or a fragile community-run purge bot (which I'd likely block). Apart form that, there'd still be the issue of punishing at least one visitor — every minute — with an unusually slow page load due to the server having to parse the page in its entirety. (I say at least one, since visitors will be queued behind one another; with a maximum queue length after which the copy from prior to the purge will be revived and served instead.) And after that, a high likelihood the result would still be off by a few minutes due to clock differences between the server and client, and the time it takes to transfer the data over the Internet. After that, the text would remain static while in the reader's browser and not update. Thus by the time someone actually looked at it, I'd give it a 50% chance of being off by at least two minutes compared to their own clock, growing more stale with every passing second/minute while they scroll up and down the page. So apart from any infrastructure concerns, I think this would offer a slow, confusing, and unprofessional experience to readers; even if it the servers did somehow instantly update it every minute (which they won't).
The appropiate way to implement something like this would be with a few lines of client-side JavaScript (via MediaWiki:Common.js​, or a default-enabled gadget). Such script would be very trivial to write, and would not require any modern or complex APIs (I see Intl.DateTimeFormat was mentioned above, but this isn't needed). Assuming we aim for displaying hours and minutes (not seconds) this would not incur any notable performance cost on the browser.
The way I would approach this:
--Krinkle (talk) 23:48, 5 June 2021 (UTC)
Wikipedia should Celebrate Autistic Pride Day
There is consensus against this proposal. Closing per WP:Snowball clause. —pythoncoder (talk | contribs) 13:44, 9 June 2021 (UTC)
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.

Upcoming 18th June is Autistic Pride Day. Can wikipedia celebrate that day, such as by showing an infinity badge on the front page? Where is the right forum to discuss this proposal? Regards. RIT RAJARSHI (talk) 03:59, 7 June 2021 (UTC)
@RIT RAJARSHI: Generally there hasn't been much support for celebrating individual events, and I don't think the community would support adding an infinity badge to the main page. I think the best thing you could do would be to have a read of the guidelines for selected anniversaries, and if the event/article meets the criteria to add it to the page for June 18. (talk) 11:25, 7 June 2021 (UTC)
This is an issue dear to my heart, as I am a trustee of a small charity whose mission is to stage plays that raise awareness of autism (and I am deeply honoured to have been invited to become the only trustee without autism), but I would oppose this. I think a slippery-slope argument is valid here. Why shouldn't we do something for Mental Health Awareness Month, or AIDS Awareness Week or International Tea Day, which I am sure are dear to some editors' hearts? The only such day that we should take note of, if it exists, is one to raise awareness of open encyclopedias that anyone can edit. Phil Bridger (talk) 12:50, 7 June 2021 (UTC)
We don't celebrate individual days in a formal way, but relevant submissions of articles following our gazillion other rules can be highlighted on the Main Page on a given day. Did you know allows for special date requests for a given new article, and so does Today's Featured Article. If you have an article that meets the rules and is appropriate for Autistic Pride Day, you'll be welcomed with (fairly) open arms. (18 June this year might be too close, though). —Kusma (talk) 13:09, 7 June 2021 (UTC)
@Phil Bridger: One thing to be make clear; Autism awareness and autism pride isn't same thing. Autism pride stresses on the thing that autistic individuals have right to be ourselves and we do not have to force mask ourselves into a broken version of neurotypicals. We have the infinite potential but for that we need the niche which is accessible for us. We also speak that world needs more of us. We speak against eugenic elimination of genetic diversity. We encourage cognitive diversity. We believe that strength lies in diversity and not in sameness. We say "Nothing about us without us. We share day to day our experience about hidden disability and how the disability doesn't belong to the affected person but it belongs to an inaccessible world. As a person in the spectrum, I feel these messages are missed or omitted in the autism awareness programs; and both are very different.
Now why to spread autism pride? Because awareness is misleading. Awareness often leads to fear about autism. What helps us, is understanding, acceptance and confidence. Yet awareness is a majoritarian (neurotypical) view, funded by neurotypical agencies, governed by mostly neurotypical-led charities. Awareness programs are something about us without us. In contrast, what actually helps us to flourish and expand our potentials, is not promoted by neurotypical authority. It is promoted by our little efforts.
Now I agree its primarily an encyclopedia, but since it perform various anniversaries, an 1 day anniversary would not be a big deal. Regards. RIT RAJARSHI (talk) 13:22, 7 June 2021 (UTC)
This article was presented several times on this day series
So it should be made a regular anniversary. RIT RAJARSHI (talk) 13:30, 7 June 2021 (UTC)
I agree that awareness and pride are different things, but disagree that there is anything bad about awareness, or that it in any way excludes pride. Quite the reverse. Much fear stems from a lack of awareness, and, as I said, I am the only trustee of the charity that I am involved in who doesn't have autism, so it can't be accused of being run by neurotypicals or being a "without us" organisation. Indeed that is a criticism that would be better levelled at Wikipedia if this proposal was agreed. Let's think about what's best rather than indulge in infighting about words, over which we would find it just as difficult to get agreement among diverse people with autism as among diverse neurotypicals. Phil Bridger (talk) 16:26, 7 June 2021 (UTC).
@Phil Bridger: Thank you for all your inputs. "Lets think what's best"... yes definitely, everyone deserves the niche where they can function at best. Instead of moulding oneself. We appreciate the whole diversity (not only autism and ASD), that includes neurotypicals, and we are thankful to the little number of neurotypicals who tries to understand instead of moulding us. RIT RAJARSHI (talk) 02:06, 8 June 2021 (UTC)
  • OPPOSED - It is not our job to promote pride days… no matter how worthy the cause. Posting a DYK or featuring a related article is fine, but placing banners and emblems on our main page is not. Blueboar (talk) 14:13, 7 June 2021 (UTC)
  • Oppose adding any sort of special logos to the MP for any of these condition-recognition-days; however assuming the article is in good shape feel free to drop an edit request at Wikipedia talk:Selected anniversaries/June 18 to have it listed at OTD again. — xaosflux Talk 14:36, 7 June 2021 (UTC)
  • Oppose per others above. I'm glad Autistic Pride Day exists, and it's a great way to help combat stigma/discrimination, but that is simply not our role and this would open up a can of worms. {{u|Sdkb}}talk 14:54, 7 June 2021 (UTC)
  • Oppose. Major NPOV issue, along with other concerns mentioned above. Sungodtemple (talk) 15:27, 7 June 2021 (UTC)
  • Oppose. We already have a process and set of guidelines for determining what gets to go on the main page; we shouldn't be overriding that process to add events with substandard articles simply because they're for a worthy cause - that will open a massive can of worms. If you want to see the event on the main page it should have to go through the same process as everyone else, which in this case will involve fixing up the clean-up tagged under referenced section which caused it's removal in the first place. (talk) 16:01, 7 June 2021 (UTC)
  • Oppose per all Opposes above. Tyrone Madera (talk) 19:23, 7 June 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Archive RfPP reports (again)
It's snowing in June, and withdrawn by proposer. ProcrastinatingReader (talk) 13:11, 12 June 2021 (UTC)
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.

Back in April, I proposed that RfPP reports be archived. However, no action was taken on this, and the discussion itself was archived. I was just wondering if this will happen, and if so, when. 🏳️‍🌈 Chicdat  Bawk to me! 11:41, 7 June 2021 (UTC)
Chicdat I'm still not clear on why it is needed. I'm frequently reviewing RFPP and I never felt the need to look into an archive. I also use WP:Twinkle which tells me if the page has been protected before and links to the protections page. The bot will tag some some requests with "Automated comment: A request for protection/unprotection for one or more pages in this request was recently made, and was denied at some point within the last 8 days". Even then I don't go back into the archive to see. I go the page and see if it is necessary now. CambridgeBayWeather​, Uqaqtuq (talk), Huliva 00:51, 11 June 2021 (UTC)
CambridgeBayWeather Just because you wouldn't find it useful doesn't mean others wouldn't. 🏳️‍🌈 Chicdat  Bawk to me! 10:11, 11 June 2021 (UTC)
I'm pinging the editors involved in the last discussion. @​ProcrastinatingReader​, PEIsquirrel, Jayron32, Pppery, Xaosflux, Cyberpower678, GenQuest, Malcolmxl5, CaptainEek, Beeblebrox, Nosebagbear, Fastily, and ToBeFree: 🏳️‍🌈 Chicdat  Bawk to me! 10:11, 11 June 2021 (UTC)
  • That a proposal is archived with no action is usually a good indicator that there is little interest in it. I am not enthused by it. It’s not clear to me how it would be used or what the benefits would be. --Malcolmxl5 (talk) 10:28, 11 June 2021 (UTC)
  • Please explain clearly why this should be done? and, what are the benefits of this action? I thought this was done and put to bed. Right now, this sounds like you want to take clutter from a pile over 'there,' and start a new pile for it over 'here.' But, what is your reasoning, and how is that a benefit in any way to WP? GenQuest "scribble" 12:31, 11 June 2021 (UTC)
  • I'm also struggling to see why we should bother with this? it seems like a change that will simply create hundreds of useless archive pages that no-one is ever going to look at. These aren't like deletion discussions or arbitration enforcement reports where someone might need to pull them up again in 10 years time for a related deletion discussion/arb case/RFC, basically every one of these reports is a standard template and one line sentence, with a template response from an administrator. If a request at RFPP is acted upon then there will be an entry in the protection log for the page which already serves as a reasonable record of what kind of disruption has occurred historically, and if a request for page protection is declined then I fail to see any reason we would need to access it again. The fact that a page wasn't protected 6 months ago should have no relevance at all on a new report - a decision on whether a page should be protected or not should be based on what disruption is occurring now. (talk) 13:30, 11 June 2021 (UTC)
  • My opinion has not changed; I would find such a process completely useless, but will not get in the way of anyone doing the work necessary to make it happen. It serves no purpose to myself, as an admin, in doing my work at RFPP, and provides no benefit in that area. I'm also neither smart enough nor imaginative enough to see how any admin could find any use in such a system, but I'm a pretty low bar in that regard, which is why I won't stop anyone... --Jayron32 13:42, 11 June 2021 (UTC)
  • There was actually a consensus in the previous section; 7 leaning oppose/not useful, 2 support, and 1 indifferent. Combined with unique responses above, that's 9 oppose, 2 support, 1 neutral. ProcrastinatingReader (talk) 13:45, 11 June 2021 (UTC)
  • Archiving the pages makes them available to Search and Whatlinkshere. This has advantages and disadvantages: sometimes forgetting things is better. I haven't seen a convincing use case yet. —Kusma (talk) 13:47, 11 June 2021 (UTC)
  • Meh, but I don't think these are really needed. They don't really set precedent like an xFD does. If it is granted, the protection log can link to whatever the protecting admin wants to link to; if it is declined that won't preclude a non-extremely-short-time-in-the-future request from being able to be reviewed on its own merits. — xaosflux Talk 15:22, 11 June 2021 (UTC)
  • Why not automate adding a summary that includes the permanent link to the RfPP revision ID if the fulfilling admin is taking action from there. This is how the fulfilled WP:RM/TR requests are now tracked without creating archive bloat. -2pou (talk) 15:49, 11 June 2021 (UTC)
  • Again, not sure what problem this would solve. There is already a quite useful protection log for pages. CaptainEek Edits Ho Cap'n! 18:58, 11 June 2021 (UTC)
  • I agree with everyone above. No convincing reason (or, frankly, any reason at all) has been articulated for why this is necessary. Mz7 (talk) 19:03, 11 June 2021 (UTC)
  • Can someone please withdraw this discussion for me? It's obviously not going to get anywhere, but I am banned from closing discussions, so I can't do this myself. Chicdat (talk) 12:38, 12 June 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Growth team feature test begins tomorrow (June 8)
Follow up announcement from the April 2021 proposal to trial new Wikipedia:Growth Team features. Please place any feedback at Wikipedia talk:Growth Team features.
Hello everyone -- I'm Marshall Miller; I'm the product manager for the WMF Growth team. I'm following up on @Nosebagbear's post from April 23 about testing the Growth team's features here on English Wikipedia. In short, the Growth team features provide new account holders with important tools to get started: they're suggested articles that need simple edits (based on maintenance templates) and they are assigned a mentor to whom they can ask questions.
In the past weeks, lots of English community members have tried out the features, and we've heard largely positive reactions and ideas. We also have 16 mentors signed up (we don't need more for this test, but we will need more in the future!) After discussing it with the most involved community members, we set a date to begin testing the features on this wiki. Our plan is to start giving the Growth features to 2% of newcomers starting tomorrow, June 8. This means that for all new accounts created starting tomorrow, 2% of them will have the Growth features and the rest will not. Because English Wikipedia gets about 130,000 new accounts per month, we expect this will amount to 2,600 newcomers having the features over the course of the month. They'll mostly be visible in Recent Changes and watchlists by completing suggested edits and asking questions to their mentors. These edits can be found with the tags #Newcomer task, #Mentorship module question, and #Mentorship panel question.
While the test is running, the Growth team will monitor newcomer activity to identify if anything negative is occurring (like an increase in vandalism) -- if something goes wrong, we'll be able to quickly make changes. At the end of about four weeks, we'll reflect on the data and ask mentors about their experiences to decide how to proceed, in terms of whether to increase the number of newcomers who receive the features.
I hope this sounds good to everyone here -- we think we've planned this carefully with community input, but I definitely want to hear if anyone has questions or concerns. I'll plan to post again tomorrow to confirm that the test has started. MMiller (WMF) (talk) 18:42, 7 June 2021 (UTC)
Also would like to mention, please don't be a mentor, there already are more than 15 of them. Oh shoot, Streisand effect.Sungodtemple (talk) 22:10, 8 June 2021 (UTC)
Hi all -- we began the test today, giving the Growth features to 2% of new accounts being created. Please follow along with the progress on the project's talk page! MMiller (WMF) (talk) 04:51, 9 June 2021 (UTC)
Allow links to multiple articles in other languages/to sections of articles
The current method of allowing only one link between articles of different languages assumes that a concept that is sufficient to make an article in one language will always be one article in another language, and never multiple articles. However, there are many instances when this is not the case. For example, there is the English Changchun which discusses its history as Hsingking in the same article. However, in the Japanese Wikipedia, Hsingking has one article, while Changchun also has one article. Both Japanese articles are long enough that it seems impracticle to merge them, and it doesn't seem right to make the Japanese Wikipedia change their articles based on the English Wikipedia.
My suggested solution would be to allow articles like the Japanese Hsingking article to link to the section of the English Changchun article that discusses Hsingking. The English article could still link to the Japanese Changchun article, as there is a disambiguation at the top of the Japanese Changchun article that would allow people to make their way to the Japanese Hsingking article. Erynamrod (talk) 16:16, 10 June 2021 (UTC)
@Erynamrod: You're talking about the interlanguage links that appear in the sidebar aren't you (just to be sure that I'm writing about the same thing)? These are currently populated using wikidata, which only supports 1:1 linking of articles and does not support linking to sections, but there is a workaround - you can still use the old style manually entered links. You can only have one link for each language in the sidebar of each article, but you can have multiple pages on other wikis linking to the same article, e.g. to add a link to the Hsingking article on the Japanese article just add something like [[en:Changchun#Manchukuo and World War II]] anywhere on the page. The English article can only have one link in it, so as you note the only way of dealing with it is to have disambiguation on the Japanese side. (talk) 18:03, 10 June 2021 (UTC)
Hsinking is a redirect to Changchun. If you like, you can link the redirect page to the Japanese Hsingking on Wikidata and add a {{Wikidata redirect}}. – Finnusertop (talkcontribs) 18:44, 10 June 2021 (UTC)
Mis-placed RfC to elevate WP:DUCK to guideline status
 – Pointer to relevant discussion elsewhere.
Please see Wikipedia talk:The duck test#RfC on making this a guideline. This is a regular RfC that would elevate that {{Essay}} to {{Guideline}} status. It really belongs as a WP:PROPOSAL on this page. I suggest that it be shut down there and moved here, actually. If it's worth bothering. We didn't even make WP:BRD a guideline, after many proposals to do so.  — SMcCandlish ¢ 😼  18:28, 12 June 2021 (UTC)
Last edited on 12 June 2021, at 21:02
Content is available under CC BY-SA 3.0 unless otherwise noted.
Privacy policy
Terms of Use
HomeRandomNearbyLog inSettingsDonateAbout WikipediaDisclaimers