Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
• This page is for concrete, actionable proposals. Consider developing earlier-stage proposals at Village pump (idea lab).
• Proposed policy changes belong at Village pump (policy).
• Proposed speedy deletion criteria belong at Wikipedia talk:Criteria for speedy deletion.
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Wikipedia:Requested articles.
• Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation belong at Wikipedia:Village pump (WMF).
• Software changes which have consensus should be filed at Phabricator.

Discussions are automatically archived after remaining inactive for nine days.

« Archives, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Consolidating help venues

Moved from Wikipedia:Village pump (policy)

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

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

I don't know exactly what the difference between Teahouse and Help desk is (in 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)

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

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. — xaosflux Talk 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)

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

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

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

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

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

Proposal: deprecate WP:EA/WP:EAR and close down all active templates or help pages linking to it

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:

    • Teahouse 2020 edits: 31,653
    • Teahouse 2021 edits: 18,347
    • Help Desk 2020 edits: 25,016
    • Help Desk 2021 edits: 9,039
    • Ear/Requests 2020: 1,121
    • Ear/Requests 2021: 434

    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. GMG^talk 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 192.76.8.91 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. 192.76.8.91 (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. 192.76.8.91 (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. 192.76.8.91 (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

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 (talk ⋅ contribs) 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

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

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

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

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

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

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

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

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

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

  Can the wording for the Teahouse just be "A friendly space for new editors to ask about editing Wikipedia"? —Naddruf (talk ~ contribs) 16:21, 28 April 2021 (UTC)

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

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

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)

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

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

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

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

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

• Support As the teahouse is more useful for newer editors it should replace the help desk link, my second choice is adding the teahouse link while keeping the help desk link. Jackattack1597 (talk) 10:58, 4 June 2021 (UTC)
• Support Works for me. ~ HAL333 04:39, 8 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.

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. –xeno^talk 13:47, 30 May 2021 (UTC)

Like EpicPupper (he/him | talk, FAQ, contribs) 21:35, 9 June 2021 (UTC)

The proposed changes are pretty minor and IMO uncontroversial. We may need to do some thinking about pathways to help once those tools go into production fully, but I don't think these (mostly housekeeping) updates are that. ProcrastinatingReader (talk) 18:14, 18 June 2021 (UTC)

Restricting GFDL-licensed uploads

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.

---

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  Huggums537, I might otherwise need that far less practical option some day Actually, you won't. If somehow in the future you find a problem with Creative Commons, you might switch to the basic {{Attribution}} or {{PD-self}} templates, perhaps {{FAL}} or another free license or write a better license from scratch. But not GFDL. instruction set about if you uploaded before or after this date That's actually not in there. There is a standard grandfather clause based in the licensing date. So if you find a GFDL-only licensed file on, say, dewiki or itwiki, you may upload it here if it was tagged GFDL before 1 July 2021. make "determinations" about already existing media Already existing media is simply not affected by this proposal, so there is no need to worry about dispute over that. Except, the 3 pages have already been determined to be "free enough" The real-world example from notafish and the comic explain why GFDL just isn't a practical license for visual media. There appears to be some confusion about "GFDL software", but this appears to be an error in the proposal that I overlooked (I coauthored the proposal): GFDL was created two decades ago to accompany existing free software licenses like the GPL. Before that, the manual that came with free software was typically licensed under the free software license, which was odd because reasons. Software itself does not get licensed as GFDL. — Alexis Jazz (talk or ping me) 14:56, 12 May 2021 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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, 31.41.45.190 (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)

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

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

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

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

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

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

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

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

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

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

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)

• Support per User:MGA73, but the second bullet point, "* The content is primarily a photograph, painting, drawing, audio or video" is too narrow and should include all types of media and image files including both still and animated computer graphics, as well as files representing 3D objects. Better would be "* The content is a media file representing still or moving images, 3D objects, or audio". MichaelMaggs (talk) 11:43, 1 June 2021 (UTC)
• Support per above. On a side note, I can't tell you how many times I have accidentally clicked on GDFL when trying to publish an edit. ~ HAL333 04:41, 8 June 2021 (UTC)
• Support per nomination & others, although isn't this really an issue for Commons? Most free media will be uploaded there, not on English Wikipedia. There's essentially no good reason to use GDFL for images any more, so this will exclude the "clueless user selects a license at random" case and the mostly-hypothetical but still bad malicious "trolly GDFL" case where a user just wants to lock down their image in a non-standard way. SnowFire (talk) 17:10, 11 June 2021 (UTC)
  • GDFL-only already forbidden on Commons. Calliopejen1 (talk) 17:07, 22 June 2021 (UTC)
• Support per nomination. It's high time we should move ahead rather using the GFDL. --C1K98V ^{(💬 ✒️ 📂)} 13:10, 14 June 2021 (UTC)
• Support We should stop supporting the usage of an outdated license.Jackattack1597 (talk) 00:40, 19 June 2021 (UTC)
• Support Way past time. The only reason this is purposely used on Wikipedia is by uploaders who don't really want their images to be freely usable. Wikipedia is a free culture project. If you don't want your images to be freely reused, post them on Flickr or elsewhere. Calliopejen1 (talk) 17:07, 22 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.

RFC on moves being marked as minor

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)

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

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

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

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

  Elli, the problem is that many editors turn off notifications of minor edits, which means something as large as a bad page move could go unnoticed for longer than necessary. Kamala Harris was moved to C**tala Harris after Biden announced her as his running mate. It fortunately lasted only a couple minutes before someone saw it and fixed it, but even that short a time made it show up that way in google searches. If that mover had been able to mark that change as minor, it could have taken longer. —valereee (talk) 19:26, 22 June 2021 (UTC)

  Filtering by minor is a very bad idea -- so if I'm a vandal or about to knowingly be disruptive, all I need to do to attract less scrutiny to my action is mark it as 'minor'? I'm of the opinion that nobody who wants to catch problematic edits on their watchlist should be filtering out edits marked (by their author) as "minor". ProcrastinatingReader (talk) 22:48, 22 June 2021 (UTC)

  @Valereee: you'll still see moves even if you filter out minor edits. Elli (talk | contribs) 23:49, 22 June 2021 (UTC)

  Elli, I didn't know that -- so a page move doesn't get filtered out of a watchlist by the mover marking it minor? (I actually think the Harris move maybe was a redirect, but that's probably moot.) —valereee (talk) 23:57, 22 June 2021 (UTC)

  @Valereee: no - the move log is included in watchlists separate from the null edit (just like the delete log, block log, protect log, etc etc). Unless you filter out the move log, you'll see it (and, well, if you're filtering out the move log than you probably wouldn't expect to see moves). Elli (talk | contribs) 00:00, 23 June 2021 (UTC)

  I would have no idea how to filter out the move log. Or to filter it in. :D —valereee (talk) 00:16, 23 June 2021 (UTC)

• Always major. Whether between namespaces or within the same one, a move is not "minor". Seraphimblade ^{Talk to me} 00:14, 23 June 2021 (UTC)
• The term "minor" means the content is not significantly altered. A move does not alter any content and technically is minor. Perhaps people want moves flagged more prominently in their watchlist but anyone hiding minor edits should not be surprised when stuff is not shown (e.g. vandalism marked as minor). Johnuniq (talk) 02:18, 24 June 2021 (UTC)

  I think the question is, for what reason? Isn't the title being altered as significant as a content alteration? Tamwin (talk) 00:03, 27 June 2021 (UTC)

• A page move/rename is a major event in the history of an article - flag them always as such. -- Netoholic @ 00:10, 27 June 2021 (UTC)

Classes of articles shown on pages.

Plain and simple. Just showing the classes of articles. I know that it says "this article is a stub" on the bottom, and Good articles and featured articles are shown on the top, but I think it would be a good quality of life change. This would be good because people could see what articles need work without skimming through it or going through the list page of all the class lists. Also, this will give a incentive to class articles because it will show up on the main page. — Preceding unsigned comment added by Thisisaverygoodusername (talk • contribs) 22:45, 15 June 2021 (UTC)

Oppose: Classes are already displayed on the talk page of articles. Articles are supposed to be reader-facing and their talk pages are supposed to be editor-facing. The reason why good and featured articles have a topicon is because they are the 'best content', and tell the reader that the article is more professional. Sungodtemple (talk) 21:30, 16 June 2021 (UTC)

@Thisisaverygoodusername: You can enable this for yourself - go to preferences, then gadgets, and under "Appearence" click the box for "Display an assessment of an article's quality in its page header". DuncanHill (talk) 21:33, 16 June 2021 (UTC)

I think we'd need to massively encourage editors to do this and to fix ratings they encounter before we consider showing the ratings to readers. Non-GA/FA ratings are often several years out of date. —Kusma (talk) 13:39, 23 June 2021 (UTC)

Basically what the last two just said. We identify the lowest quality articles so we can ask for help in expanding them, and we identify the cream of the crop to form a basis for what we strive for. Anything in between either isn't ready yet or hasn't been assessed to be top tier yet. There's no need for the average joe schmoe reader to be told anything in between. They can work out for themselves whether an article is all it can be based on whether it has the green plus or bronze star up top. Zeke, the Mad Horrorist ^{(Speak quickly)} _{(Follow my trail)} 21:33, 18 June 2021 (UTC)

• I'm not opposed in theory to displaying more classes to readers, but currently, start/C/B are just too subjective and too unreliable to be of much use. {{u|Sdkb}} ^talk 02:03, 20 June 2021 (UTC)

  I think we would need to be more transparent to the casual reader as to the scale we're using. Stub, Good, and Featured are all they really see — and that's if we go to the trouble to physically put such on the page — but the average joe reader is more accustomed to a scale like Poor, Fair, Good, Very Good, and Great. Something along those lines. And again, the rating is not something the software itself can assess; editors have to take time out of their day to not only rate the articles but then post those ratings there. I don't really find it would be constructive to do that for anything between the article ratings we already go to the trouble to outwardly show. We already post these ratings to the relevant talk pages; I think anyone looking through there would already be a prospective Wikipedian who probably just hasn't registered yet. I don't think anyone else, among the unregistered crowd, would be interested. Zeke, the Mad Horrorist ^{(Speak quickly)} _{(Follow my trail)} 02:36, 20 June 2021 (UTC)

  I think this is a good idea. I like having it enabling while reading articles, it gives me a rough sense of article quality. Even though it's not a perfect metric by any means, an unobtrusive icon does no harm (and getting people thinking about how Wikipedia works is a slight positive). Zoozaz1 talk 02:41, 20 June 2021 (UTC)

• Oppose. I don't think this is a good idea with the rating system in it's current form. I think if we were to start displaying ratings on articles the system would need a fundamental reorganisation to make it more understandable/useful to readers and to make it easier to enforce consistency in ratings across wikiprojects - as it stands the system is very much intended for internal use and is mostly written in Wikipedia jargon. Ask someone who doesn't know about editing Wikipedia to identify which is best - a featured article, a good article or an A-class article - it isn't obvious from the names. Likewise ask them what the difference is between a start-class article, a C-class article and a stub: all three names are Wikipedia jargon with specific meaning on the site. It's easy to find articles with multiple conflicting ratings, the 3rd article I checked (New York City) is rated as both C-class and B-class by varying wikiprojects. There's other oddities that make the system unintuitive too, why do lists have their own scale but with only 3(?) ratings? Why do some wikiprojects use classifications that don't exist in other projects (like future-class, merge-class, current-class etc)? I just don't feel that the system was designed to be a reader facing part of the site. 192.76.8.91 (talk) 21:20, 21 June 2021 (UTC)

  It's not even clear that "featured article" is a measure of quality. The most obvious reading of the term is that this article is one that we have selected to feature. And the reason for that selection could easily be something other than quality (such as an association with today's date). --Khajidha (talk) 16:06, 23 June 2021 (UTC)

• I would support showing the A class topicon and what not on said article's page but I am not quite sure about the others yet.  Spy-cicle💥  ^Talk? 13:46, 23 June 2021 (UTC)
• Oppose other than FA/GA. Featured and good articles' evaluations are based on a standard set of criteria, while all other levels are based on criteria which differ depending on which WikiProject is handling the review, and are usually one editor's drive-by opinion of the article in a very early state, and then never updated nor maintained. For users who want to view this information anyway, they can enable the "Display an assessment of an article's quality in its page header" gadget in preferences (more info here). Ivanvector (^Talk/_Edits) 16:52, 26 June 2021 (UTC)
• Oppose Ratings, other than GA and FA, aren't really informative enough to go splashing around. They can lag behind the actual state of a page for a long time, etc. XOR'easter (talk) 19:33, 26 June 2021 (UTC)
• Oppose The project ratings are typically just one reader's opinion and are not reliable. It would be more useful to enable all the readers to rate the article more easily so we'd then get thousands of assessments. Andrew🐉(talk) 21:32, 26 June 2021 (UTC)
• Oppose The letter ratings tend to be subjective and inconsistent. ~ HAL333 04:25, 27 June 2021 (UTC)

RFC: Pending-changes protection of Today's featured article

A one-month trial was authorised in April 2021 following Wikipedia:Village pump (proposals)/Archive 178#Pending-changes protection of Today's featured article. I understand that that trial has now ended (see User talk:Primefac#Follow-up RfC to TFA PC protection trial; courtesy pings, and thanks for the heads-up, to Goszei and Primefac). I am therefore opening this discussion to invite comments as to how it went, and what (if anything) to do next.

Consider me neutral. All I will say is, that I don't think I've seen a request for protection of a TFA at WP:ANI since February 2021.

Pinging all editors who took part in the original discussion: TheDragonFire300, Iridescent, Redrose64, Jéské Couriano, Izno, Thryduulf, Vaticidalprophet, Wugapodes, Buidhe, Nosebagbear, Mz7, Bilorv, Hawkeye7, Aza24, HAL333, RandomCanadian, Elli, Extraordinary Writ, firefly, Pinchme123, Yair rand, Espresso Addict, Levivich, Zoozaz1, Venicescapes, ToBeFree, Waddie96, ONUnicorn, Kusma, Dennis Brown, CaptainEek, Jason Quinn, Nsk92, Snow Rise, MusikAnimal, King of Hearts, Wretchskull, ProcrastinatingReader, Phil Bridger, Asartea and 力 (and Somebody "Notme" Else, who unaccountably did not). Narky Blert (talk) 12:06, 26 June 2021 (UTC)

Survey (TFA PC)

• From a quick look through the protected pages, what I see is:
  1. A significant uptick of activity on the day of the TFA
  2. Much of the activity on pages which were not already semi-protected was vandalism or other forms of unconstructive editing (there were a few here and there which were good edits, but they're the exception not the rule)
  3. Most edits by non-ACs on those pages were coming from VOAs or the like who would probably have vandalised something else anyway
  4. Problematic edits were quickly reverted
  5. No sign of any LTA which prompted this
• I was also thorough, and checked the first few TFAs after the trial expired. The nature of edits to these articles is broadly similar with that of the PC-protected TFAs (supporting point no. 3), and point no. 4 also holds. In short, the trial was successful as far as point no. 5 is concerned (though it is hard to judge how effective the measure was in respect to this), but I don't think it was otherwise effective in preventing vandalism to the TFA - whether we want a few vandals wasting their time at the TFA and getting caught and blocked rather quickly, or whether we want them messing around elsewhere (where their vandalism is less visible, and where enforcement can also take more time if nobody is checking AIV) is another question. Since PC had no appreciable impact on points 2 through 4, I would personally support semi-protecting the TFAs for the foreseeable future (this could be combined with the existing TFA Protector Bot run by Legoktm). RandomCanadian (talk / contribs) 13:29, 26 June 2021 (UTC)

  Note that I don't have fundamental issues with the protection just being PC, so support PC too, but I think semi will be more effective. RandomCanadian (talk / contribs) 23:38, 26 June 2021 (UTC)

• I fully support permanent PC-protection of TFAs; I have repeatedly seen vandalised TFA ledes upon clicking on them throughout my time here. I've also seen that most non-autoconfirmed edits are either vandalism or unconstructive edits. A phenomenon I see in TFA reverts is that they are more prone to collateral damage; sometimes more than one edit has been made by a vandal, and I've seen people (even ClueBot) accidentally only undo one of the edits, forcing a revision restoration. I do not quite understand when some people say that anyone should be able to edit Wikipedia and no protection shall be installed in TFAs, if that is the case, why not just remove all protection from all pages? Shouldn't they be able to edit their favourite articles? Why should TFAs be a scapegoat for vandals? They have been upgraded to a point where they may only need very few, almost unnoticeable corrections. Sidenote: RandomCanadian I support PC-protection over semi-protection as there may be some who spot mistakes that could be quickly corrected. Also, the fact that it is PC-protected would perhaps draw them away from unprotected sites over the illusion that they may be able to vandalise. Wretchskull (talk) 14:36, 26 June 2021 (UTC)
  • FAs can still have fundamental mistakes in them, particularly for more technical subjects. The process is very thorough for some particular kitsch Wikipedia things, but remember that most reviewers at FA are not subject experts. — Bilorv (talk) 17:34, 26 June 2021 (UTC)
• Support automatic PC protection. As I stated in the discussion that authorized the trial, the utility of pending changes is different from semi-protection in the sense that the goal is not to reduce the workload on administrators and editors (it effectively creates more work), but rather to ensure that vandalism is not seen by readers and thus potentially bringing the project into disrepute. In general, TFAs often receive a considerable uptick in viewership while they are on the Main Page. For example, yesterday's TFA about an obscure plant, Grevillea juniperina, saw 18,112 views, which is approximately 12 views per minute. Thus, for every sixty seconds that vandalism is allowed to remain on a TFA, that's potentially at least 12 readers who are seeing that revision on what is supposed to be a showcase of our very best content on Wikipedia, and a scroll through revision histories reveals that vandalism is indeed not getting reverted immediately on a consistent basis. On Shojo Beat, which is today's featured article, [5] was not reverted for 7 minutes (warning: it contains a link to porn). The trial successfully showed that turning pending changes protection on did not pose any unbearable burden to the PC backlog (it's only on for 24 hours anyway), and this small cost is worth the benefit of maintaining the polished quality of our featured content while still allowing prospective/inexperienced editors to suggest changes. Mz7 (talk) 16:22, 26 June 2021 (UTC)

  For the record, I oppose semi-protection. I think PC is sufficient. Several editors below have expressed vague or hypothetical problems with pending changes protection on TFA, but no one has pointed to concrete evidence of such issues during the trial period. It's true that pending changes protection is usually a bad fit for high-edit rate articles because doing so extensively would bloat the pending changes backlog—but when it's just on one article per day, the situation is entirely manageable. As I stated above, TFAs are often viewed at least once every five seconds, and the record demonstrates that vandalism on TFAs are often up for much more than that, even up to several minutes—the utility of pending changes is that we can avoid the embarrassment of presenting vandalism as our "finest work". The one point of opposition I can understand has to do with the technical issues impacting the pending changes tool—at the original RfC that authorized the trial, I also expressed skepticism about this whole idea on that basis, but as it stands right now, it seems that the tool is working well enough at the moment that we can cautiously proceed. Mz7 (talk) 17:13, 27 June 2021 (UTC)

  Nobody knows what will break next, and when. There has been half a dozen random critical bugs in the past year (less?), half of them were fixed 'by luck' IIRC, ie the devs couldn't/didn't figure out what was wrong but sometimes things just seemed to start working again. Nobody wants to touch the codebase, and few even know the codebase well. If it screws up, we could be largely on our own. I personally don't think we should encourage the proliferation of buggy technology; we need to be looking to undeploy pending changes and/or limit its use, not the opposite. ProcrastinatingReader (talk) 22:46, 27 June 2021 (UTC)

• Support per last discussion. ~ HAL333 16:28, 26 June 2021 (UTC)
• Oppose automatic PC protection; support automatic semiprotection while on the mainpage as an alternative. The edit rate on TFA is much too high for the pending changes system to be useful. Ivanvector (^Talk/_Edits) 16:43, 26 June 2021 (UTC)
• Strong support per RandomCanadian's very thorough assessment. I'm particularly interested in this point that lots of TFA vandals are likely just looking for a page to mess up and would do it on something else instead if TFA was semi'd. Unfortunately, whether this is true or not is very difficult to assess properly, but it's plausible to me. I like PCP because keeping the TFA editable is particularly valuable in helping people discover that we are the encyclopedia that anyone can edit. Sure, most edits are going to make it worse, but that's not really the point. A lot of valuable editors' first edits made articles worse. We need to see test edits and unhelpful good faith edits (and even some vandal edits) as a cost worth investing in to stop cutting the already dwindling flow of new contributors. I would oppose semi-protection. On a TFA page, at least some editors (and generally at least one with comprehensive subject knowledge) are going to be watching. — Bilorv (talk) 17:34, 26 June 2021 (UTC)

  I don't know whether TFAs actually recruit new editors. They've been through a thorough and picky review process. While they can certainly still be improved, a newbie (or even active editor) is more unlikely to be able to improve them compared to other articles. All in all, I'm not sure how many editors actually began their editing career by editing a TFA. ProcrastinatingReader (talk) 20:10, 26 June 2021 (UTC)

• Support temporary full protection (2-7 days max) via my comment in the last discussion "My first concern is with the reader, THEN the editor." PC is still a bad idea. I would also note that I think you are mistaken when you say "who would probably have vandalised something else anyway". Vandalism like this is akin to opportunistic theft, which is reduced when the targets are less visible, ie: less opportunity. There is a distinct attraction to vandalizing something on the front page that is different from run of the mill vandalism, so saying they would have done the same thing elsewhere, in absolute terms, is not accurate. For the editors that DO go vandalize something anyway, the damage is repaired just as quick with less visibility, in most cases. Dennis Brown - 2¢ 17:40, 26 June 2021 (UTC)
• Strong support - if it's featured, it has already been through the rigors and highly unlikely that it needs CE or anything else that can't wait 2 weeks. Atsme 💬 📧 17:50, 26 June 2021 (UTC)

  Quite a few TFAs have been promoted years ago, so {{cn}} on the "highly unlikely it needs CE". —Kusma (talk) 18:15, 26 June 2021 (UTC)

  I think there are certainly lower-hanging fruit, like the non-GA DYKs on the Main Page. I know that when I'm looking for something to do, I work through the DYKs and don't really bother with the TFA. Sdrqaz (talk) 20:35, 26 June 2021 (UTC)

• I passionately hate pending changes, but there are enough other places to freely edit. I'd like to see a second trial with semi instead of PC, but I support the general idea of doing something to protect TFA but keep editing open a bit. —Kusma (talk) 18:15, 26 June 2021 (UTC)
• Strong support. A long time coming. TFA is a prime example of where pending changes protection shines. The high edit rate is not an issue because the article has such high visibility. Still, I can't count how many times I've checked Today's Featured Article and it was in some broken or vandalized state. I know this won't change for me as a registered user, but I'll feel a lot better knowing the nonsense is hidden from the vast majority of readers. Meanwhile the good faith editors can still contribute, and our most visible article still follows the "anyone can edit" philosophy. It's a win-win. — MusikAnimal ^talk 18:21, 26 June 2021 (UTC)
• Support Agree that our first concern should be the readers. My experience with TFAs over the period has confirmed the value of pending changes protection. Pending changes doesn't stop suggested good edits, but it has prevented vandalism. Hawkeye7 (discuss) 18:59, 26 June 2021 (UTC)

  I actually think it is healthy for our readers to see some vandalism every now and then, it serves as a good reminder not to trust everything you read on Wikipedia. —Kusma (talk) 19:02, 26 June 2021 (UTC)

  LOL! Narky Blert (talk) 20:57, 26 June 2021 (UTC)

• Support per previous discussion, and strengthened by RandomCanadian's argument. waddie96 ★ (talk) 19:08, 26 June 2021 (UTC)
• Support per MusikAnimal. While I'm suspicious of pre-emptive protection, this is a viable compromise to solve a legitimate problem for our readers, so I'm fine supporting. To be honest, I didn't even know this trial was going on so it clearly did not wind up being a problem. For that reason I don't put much stock in the idea that there is something inherent to PC protection that will cause major problems. — Wug·a·po·des​ 19:09, 26 June 2021 (UTC)

I still oppose preemptive semi-protection per per the protection policy. That policy is quite clear: Applying page protection as a preemptive measure is contrary to the open nature of Wikipedia and is generally not allowed if applied for these reasons. I maintain my strong opposition to preemptive protection especially where no human judgment is involved like in automatic protection. I am willing to compromise on that and preemptively apply pending changes protection based on the trial results and protection policy: the protection level should be set to the lowest restriction needed in order to stop the disruption while still allowing productive editors to make changes. When compared with pending changes protection, preemptive semiprotection is not only against our fundamental values but more extreme than necessary to stop anticipated disruption. If we are going to carve out an exception to NOPREEMPT, that policy says we should choose the lowest protection level that is effective, and the trial shows that level is pending changes. For that reason I oppose preemptive semi protection as well as a trial of semiprotection which would show us nothing other than that semiprotection stops new and IP edits. Those preferring semi protection have offered no policy or evidenced based reason to prefer it over pending changes. Arguments so far offered for preemptive semiprotection are based on anecdotes, fear, and assumptions of bad faith, all of which are unconvincing given our policies. — Wug·a·po·des​ 23:56, 29 June 2021 (UTC)

Respectfully, I'm not sure any of us would have noticed the most likely PC problems unless we were actively working as reviewers in a robust fashion over the test period, which is part of why I wish I hadn't been so absent from the project over recent months and might have a better grasp on what the impacts were. Then again, maybe you were intending to say you -had- been working that area and didn't notice substantial impacts. But further (and again with respect) I would submit that such an argument is not a super compelling one (as either an empirical or rational measure) for the overall cost-benefit value of this change, because said observation cuts both ways: if you didn't even realize the trial was running, then you failed to notice any benefits in equal measure to failing to note any issues. Which makes the observation rather a wash at best--afterall, absence of evidence is not evidence of absence, for either any benefits or drawbacks that we may speculate about. This is why I am a little concerned that this discussion is building steam towards a result just as fast as the first one: I'd really like to hear more from those who were in the trenches in the involved areas, or otherwise did notice effects, however subtle, in one respect or another, before we rubberstamp this change as one that is fit for purpose/returns more value than negative side-effect on the whole. Snow ^{let's rap} 01:16, 27 June 2021 (UTC)

• Support Seems to strike a reasonable balance. XOR'easter (talk) 19:31, 26 June 2021 (UTC)
  • I'd generally go with semiprotection rather than pending-changes. The latter has always struck me as a "huh? when is this beneficial?" kind of feature. The operation of it is more complicated and harder to explain, too. I'd prefer the course of action that doesn't clog page histories and doesn't lead to oversight headaches. XOR'easter (talk) 02:18, 27 June 2021 (UTC)
  • It seems implausible to me that TFA actually serves to bring in new editors. If a reader cares about a subject and has enough enthusiasm for it that they want to write about it, they've probably already found the Wikipedia article on it. TFA shows off the community's work to people who don't already specialize on the article's topic. XOR'easter (talk) 20:28, 27 June 2021 (UTC)
• I would prefer to see a deeper analysis of the 30 days of trial data we collected. Were there any constructive edits from non-confirmed users? If so, what proportion? I'm not a big fan of pending changes. Technically, the functionality is barely functioning (we literally had to approve a bot to keep it working as a hotfix, because the devs couldn't find the bug) and in terms of development it is practically abandoned. Further, all it does is stop the vandalism appearing live. It doesn't stop the page history being clogged up with crap. If all or most the edits are unconstructive, then just go semiprotection (the only reason not to do so would be ideological, and I prefer pragmatism). ProcrastinatingReader (talk) 20:04, 26 June 2021 (UTC)

  Support semiprotection and oppose pending changes. The former because the evidence suggests almost all such edits are unconstructive, leading to vandalism on an article on the Main Page, but more importantly deriving users of factually accurate information for some period of time. Oppose pending changes because a) the functionality is broken (see Wikipedia:Bots/Requests for approval/FireflyBot II) and long-term unmaintained by the WMF (see phab:T185664); b) for the reasons above (and some others). Per the WP:Protection policy (WP:PCPP): Pending changes protection should not be used on articles with a very high edit rate, even if they meet the aforementioned criteria. Instead semi-protection should be considered. (which TFA is) -- there's a good reason for that, the PC user interface is inferior to edit requests, and quickly becomes a mess at high edit rate. ProcrastinatingReader (talk) 22:34, 27 June 2021 (UTC)

• Support either PC or semiprotect for the duration of main page appearance. As noted above, the majority of edits blocked were not constructive and we should avoid allowing high visibility pages to be vandalized because it undermines the reputation of the encyclopedia. (t · c) buidhe 20:27, 26 June 2021 (UTC)
• Strong Opposition to using pending changes protection in this role, but a somewhat lukewarm level of support for using semi-protection instead. Much as with the original RfC on this topic, I think I am arriving at a point where it is already clear which way the wind is blowing, but I'm still going to take a moment to register my disagreement with the emerging consensus (which I don't always do in such circumstances), just because I can't shake the impression that this would be a substantially ill-advised move on multiple levels. I'm a pending changes reviewer myself and having logged a fair number of hours on the process over recent years, and I think I can say with some confidence that most editors who have not had to work with the approval side of the tool do not fully comprehend how complicated the application of that oversight becomes, particularly when you have multiple pending edits coming right on top of eachother, interspersed with auto-confirmed user/non-pending edits. Which is precisely the situation we would (more or less as a per se/absolute matter) be setting ourselves up for here. This extra demand (of complicated use of the permissions/manual editing to resolve conflicting edits) would create a substantial amount of unnecessary busy work for the reviewers, in what is already an area where the work often swamps the relatively small number of volunteers working consistently on the backlog--and this before we even contemplate the not-entirely-infrequent PC technical bugs--and all for a dubious benefit, since featured articles already are protected by vandalism pretty effectively by the fact that they are routinely patrolled during their day in the sun by the corps of regular editors, with most of the vandalism and otherwise problematic edits swiftly reverted.

There's also the question of hampering access in an area that traditionally has been a vehicle for first-time edits of new users, at a time when we are in the middle of a long and substantial downward trend in both editor recruitment and retention. Indeed, as I also noted in the previous discussion, having a situation where first-time users are funneled into a context where the community has abundant eyes on their initial edits, thus improving the odds that said new users will get essential feedback, engagement, and tutelage on our basic policies and procedures (and that their first, almost inevitable mistakes are caught and transformed from longterm errors into quickly fixed mistakes and teachable moments) strikes me as the best of all possible worlds, given the alternatives.

So the cost-benefit analysis on this proposal is way, way off, as I see it. That said, switching the approach from pending changes to semi-protection as the default at least eliminates the cumbersomeness of the concept a little and avoids the deleterious effects on the PC backlog and the volunteers who chip away at it on a daily basis. But my first choice would be to avoid both and rely on the traditional, largely self-correcting approach. And at a bare minimum I also agree with ProcrastinatingReader in their very pertinent caution above: I'd at least want to see a more fulsome exploration of whatever insight (impressionistic though it may be) that the trial has provided us, before I could be convinced to move to support a change from the status quo here. I really don't mean or want to tweak anyone's nose in particular here, but my impression of both the discussions is that there has been rather a rush to action here and rather too little consideration of the possible numerous and substantial knock-on effects. I can probably be convinced that this proposal isn't entirely a solution in search of a problem, but I really think we need a subtler parsing of the issues here. Not that the majority needs to convince me here--consensus seems to be moving solidly away from my perspective on this--but anyway, those are my impressions. Snow ^{let's rap} 00:42, 27 June 2021 (UTC)

• Support semi-protection - From my experience, PC doesn't work well in high edit-rate situations, which TFA generally is. And from the perspective of a FA writer who's had two of the article's I've worked on as TFAs, some of the bad edits can hang around for a bit. This lasted 4 minutes, this edit which removed an infobox through vandalism was up for 12, this for 11, etc. etc. The no-protection system is just resulting in the pages being messed up when they're most visible for sometimes decent chunks of time. PC would be nice if viable, but I'm afraid that it would frequently break down under the high edit rates TFAs often get. Hog Farm _Talk 01:03, 27 June 2021 (UTC)
• Support semi-protection, it just needs to be done folks. Semi-protection does wonders, we all know this. Every single TFA I've ever watched is just brutally vandalized, every single one. And more than half the time the article ends up getting semi anyways, so why has it just become this awkward race on how long the article can hold out when they almost never do? The vast majority of IP/non-registered edits to TFAs are vandalism—with semi, worst comes to worst, and they have to suggest edits on the talk page, not a big deal. I'll support pending if that's all this gets to, but we all know it's broken and messy, time to move on. Aza24 (talk) 01:28, 27 June 2021 (UTC)
• I strongly support semiprotection and am neutral on pending changes. I find monitoring pending changes to be a colossal labour-intensive timesink about 90% of the time. Cas Liber (talk · contribs) 04:19, 27 June 2021 (UTC)
• Support per all the above. No-brainer. Lugnuts ^{Fire Walk with Me} 07:37, 27 June 2021 (UTC)
• Support semi-protection, PC as a second choice, all per above. MER-C 08:43, 27 June 2021 (UTC)
• Support semi-protection, oppose pending changes. I strongly opposed the use of PC in the initial RfC because of technical issues with the flaggedrevs extension. I am still uneasy about using flaggedrevs on a high-profile page given that it still doesn't appear to have a dev team 'owning' it. I note that my "patch the holes" bot (User:FireflyBot II) hasn't had to do much work at all lately, which is a good thing - however I don't believe we've yet gotten to the bottom of exactly what caused the issue (autoconfirmed editors' edits not being automatically accepted when they should be) in the first place. I don't think we should be using potentially buggy code on our most high-profile articles. I agree with ProcrastinatingReader that we must be pragmatic here, not ideological. firefly ( t · c ) 09:04, 27 June 2021 (UTC)
• Support PC, semi second choice To me PC is the best option, but semi is preferable over nothing.Jackattack1597 (talk) 10:45, 27 June 2021 (UTC)
• Strongly oppose pending changes. Per several commenters above me there is no evidence that it is a net positive in highly visible places such as TFA, and indeed some evidence that it is a net negative. Oppose automatic protection of any sort for any reason. We want to encourage people to edit Wikipedia so we should be erecting as few barriers to participation as we can and that means protecting only where there is a demonstrated need for it. Thryduulf (talk) 11:29, 27 June 2021 (UTC)
• Comment I see a lot of people asserting that PC protection causes "problems" on high-traffic articles. Did anyone notice these problems in May, when the trial was running? Can specific examples be provided? Anomie⚔ 11:55, 27 June 2021 (UTC)
• Support semi-protection while it is featured, oppose putting pending changes on it. Pending changes is a complicated mess and on an a highly active article it would be doubly a complicated mess. There are always several guardians for the TFA article and that combined with semi-protection should be enough. North8000 (talk) 13:59, 27 June 2021 (UTC)

I'd like to emphasize that this is a very narrow case. It's only one or 1 1/2 days of semi-protection for one or 2 articles at a time. North8000 (talk) 13:35, 28 June 2021 (UTC)

• Support semi-protection. IP/non-autocomfirmed editors can use edit requests, and even though I admire the ideal of pending changes protection for TFA (à la anyone can edit), I'm hesistant because of the technical issues raised by Firefly and the practical issues mentioned by Hog Farm. Clovermoss (talk) 18:53, 27 June 2021 (UTC)
• Question: Has anyone done a study on the effects of protecting the TFA on valdalism on other pages linked from the main page? If the vandalism simply transfers to there when the TFA i semi'ed, that woukd be a good reason to prefer PC. 93.172.254.2 (talk) 08:31, 28 June 2021 (UTC)

  I haven't seen any studies, so I can only offer the usual anecdotal evidence: Speaking as a reasonably frequent DYK contributor, vandalism on my DYK articles has been negligible over the last two years. —Kusma (talk) 08:39, 28 June 2021 (UTC)

  However, on Saskatchewan, the article was only vandalized since being put on the main page under Template:In the news, and in fact was semi-protected. Sungodtemple (talk) 13:21, 28 June 2021 (UTC)

• I support a second one-month trial for semi-protection (first choice), semi-protection (not a trial, second choice), and pending changes (third choice). I support all three for the purposes of coming to a consensus on at least one of them. KevinL (aka L235 · t · c) 16:32, 28 June 2021 (UTC)
• Support semiprotection as a first choice with PC as a second. PC isn't great for high traffic articles and consumes a nontrivial amount of editor time reviewing changes. I also doubt that most non-autoconfirmed users can make that many good edits to an FA. Hut 8.5 17:25, 28 June 2021 (UTC)
• Support some kind of protection, no specific preference as to which kind. The ratio of vandalism and poor edits to genuine improvements is far too low in my opinion, and personally I think that for a newcomer being able to edit an article only to have your work instantly reverted is much more likely to drive people away than simply stopping them from editing. Looking at today's features article, of the 10 IP edits that have occurred so far 9 were instantly reverted and the last one is pointless (they turned an alternate name in the lead into a wikilink, so there are two links to the same article in the same sentence). 192.76.8.91 (talk) 17:59, 29 June 2021 (UTC)
• Oppose, either PC or semi-protection. The TFA's editability's usefulness as a recruitment tool outweighs the reputation problems it causes. --Yair rand (talk) 22:15, 29 June 2021 (UTC)
• Oppose pending changes is a technical feature of MediaWiki that is broken, has no one supporting it at the Foundation, and is harder for volunteers to patrol than just dealing with the vandalism in live articles. We should remove it as a technical feature on this wiki, not make it automatic. TonyBallioni (talk) 02:50, 30 June 2021 (UTC)
• Oppose any automatic protection (other than potentially move). I'd be curious if someone better versed in statistics could use the pageviews for TFA on a day and number of accounts made on that day to gauge how more popular TFAs tend to lead to more accounts created. This is logical, but I can't say for certain it's true because I don't have the data. What we do have data for, however, is the number of new accounts whose first (or one of their very first) edits is to a TFA. "Today's" featured article (only been up for about 3 hours total now, today's in quotes because it's UTC today, not necessarily your local today) already has one potentially new editor - who made what appears to be a test edit, then apologized for doing so, and immediately made edits to the featured article. Sure, they weren't necessarily good edits - but it's someone who now has an account and likely wouldn't have if not for the TFA they were interested in. The prior TFA has an IP editing from the app making good faith, reasonable changes who may have made an account (no way to know), as well as one other brand new account making one of their first edits to it. It only takes looking at varying topics to see that on average, TFAs result in at least 1-2 brand new editors whose first edits include to the TFA. That doesn't prove that new editors are joining because they can edit TFA, but imagine someone going to Wikipedia to look up "X", seeing the TFA "Y" they're interested on the main page, clicking it, noticing a change they want to make, and then making it. That reinforces the encyclopedia "anyone can edit" mentality, and is likely the biggest drive to them creating an account - seeing that "hey, yeah, I actually can edit this!" Automatically doing things is great - but indiscriminately doing it is not. I could potentially support a targeted automatic protection (ex: maybe base it on topics under DS or similar) where only articles with a very high likelihood of being vandalized while TFA are protected - leaving TFAs that aren't usually getting vandalized alone. And I don't buy arguments about it being "more work" - when I was looking through TFAs to prepare my comment, I noticed that over almost all (read: somewhere above 80% at least) of true vandalism was reverted by either ClueBot or someone using an automated tool within minutes, and usually barely a minute. Not to mention that sometimes changes were an improvement (or at least not vandalism), and they were still reverted by people - not sure what's going on with that. So no, the problem with TFAs isn't vandalism - it's that we are not capitalizing on the obvious fact that a non-zero number of new editors start out because they can edit a TFA - and we need to work on improving it so that people editing TFAs are retained. I digress slightly, but the solution is more effective communication when an edit to a TFA by a new user is reverted - perhaps a new, soft template message would be useful, or just writing custom ones instead of standard templates. The "solution" is not a solution at all - it creates a new problem of losing editors before they even start, because to them we are no longer "the encyclopedia anyone can edit". We would become "the encyclopedia some people can edit" - because they won't know how protection works, and they aren't going to read up on it - they'll just see "I can't edit this". -bɜ:ʳkənhɪmez (User/say hi!) 03:09, 30 June 2021 (UTC)
  • Ah, but see, the problem is you're actually looking at the article histories instead of assuming IPs are bad and making gut judgments based on that. Even beyond TFAs, a section of my user page currently lists articles semi-protected for over a decade that I've unprotected and the outcomes of doing so. In nearly all cases, disruption was minimal to non-existant. Take Flower for example which gets about 2k views per day. In the 27 days since the last protection expired there have been 9 edits by new or unregistered users. Of those, two were immediate self-reverts by IPs making test edits. Of the 5 remaining edits, three were reverted within one minute. The last two are actually interesting. An IP adds unconstructive text to the beginning of the article, then a new account comes and builds on it before both edits getting reverted a few minutes later. Both revisions were reverted 15 minutes after the IPs edit. So of the roughly 38,800 minutes since that article was unprotected, unconstructive text was visible to readers for at most 18 minutes or about 0.05% of the time. For simplicity, let's assume those 2k daily readers are spread roughly evenly across those 38k minutes. That means we can estimate that of the 54,000 readers this past month, vandalism was seen by roughly 25 readers. Meanwhile, we had four people try their hand at editing!
    Another example, probably more similar to TFA, is Pablo Picasso which I unprotected 22 May. In that time it's averaged about 6.7k views per day with two days spiking over 10k daily views. In those 39 days, there have been 10 edits by new or unregistered users. Of those ten edits, 8 were reverted. One was good faith but unsourced. Another was a change of date format. A third was a (sourced!) addition of content that was reverted because the IP didn't know how to use ref tags (seriously, that was the revert edit summary). That leaves us with 5 reverted edits that were not obviously in good faith. Of those 5, two were reverted immediately by ClueBot, and the remaining three were reverted within two minutes. Of the 56,000 minutes that the Pablo Picasso article was unprotected, vandalism was visible for at most six minutes or about 0.01% of the time. Making the same assumption as last time, that means of the 261,000 viewers, vandalism was seen by approximately 28 people.
    Of course, there's other examples and counter examples, but unprotections of visible pages support the basic assumption of Wikipedia: people are more constructive than destructive. Even an article with millions of annual page views has not only minimal disruption but multiple constructive and good faith edits by new and unregistered editors. Even where we have disruption visible, it is rarely visible for long and the impact is minor. Now let's turn to TFAs.
    All About That Bass (ft. 30 June) saw edits from 9 unique new or unregistered users before it was protected after 13 hours. Three of those 9 editors were constructive and unreverted. Of the 6 remaining, one was an account that got blocked after 15 minutes and 8 edits. Two of the remaining 5 were good faith but reverted for being unnecesarry changes. The last 3 were vandalism. Of those vandalism edits, two were reverted within two minutes, and the third was alt-text vandalism not visible to readers which stood for a little under 30 minutes before reverting. Despite being protected and including the vandal who got blocked, disruption was visible to readers for about 13 minutes of the 794 minutes it was unprotected. Hardly the epidemic people claim. Berlin to Kitchener name change (ft. 29 June) was never protected and saw edits from 6 distinct unregistered editors. Two of them wound up blocked. Of the remaining 4, one was reverted for writing a too detailed short description. Another (still unreverted) fixed some external links in citations. Another (still unreverted) added wiki links to the lead to Berlin and Ontario. The last added a weird symbol to the then-empty "image" parameter of the infobox. It stood for 16 minutes before someone noticed, all other vandalism was reverted within one minute. Phillip Davey (ft. 28 June) was protected after 7 hours and 6 distinct IPs but all of which were on the same sub net. Instead of protection, this could easily have been dealt with by a range block (and was, see 188.162.254.128/25). CM Punk (ft. 27 June) was already indefinitely protected. Shojo Beat (ft. 26 June) was never protected and saw 6 edits from new and unregistered editors. One was a good faith attempt to undo vandalism but resulted in an edit conflict that messed up the paragraph break. Another actually did undo vandalism. Another was to add a wiki link. The remaining three were vandalism. One seemed to attempt image vandalism (which I thought we had an edit filter for) but the revision is deleted and I'm having trouble loading it. Another was undone immediately by clue bot, and the last was undone by an IP after 5 minutes. Of the 1440 minutes that the article was featured, vandalism was visible for 12 minutes. Grevillea juniperina (ft. 25 June) was never protected and saw 9 distinct new or unregistered editors. Three of them were constructive and in really interesting ways. Two IPs worked together to improve the article after a vandal messed it up. Another editor had just registered that day and helped by adding links to the lead. Of the six unconstructive editors, One seems good faith but like they misunderstood hyphenation and alt text. Another seems like a test edit but might be good faith (I don't know much about plants). A third changed the file name from the latin to the English, maybe not realizing that it would break the image. The rest are pretty typical vandalism that was quickly reverted.
    I've already spent hours going through TFA page histories and many more before this looking at how readers interact with unprotected pages. The claim that semi-protection is inevitable is false. Many TFAs don't get protected, and in one case I would argue the page shouldn't have been protected (but it was a new admin who probably didn't understand range blocks so a proper response for the tools at their disposal). The idea that TFAs are uniquely subject to mass vandalism is hyperbole. While they get more than the usual vandalism, it is still minor and at a much lower rate than people are hyping it up to be. Over 5 TFAs I saw one revision deletion. The idea that TFAs need no work is false, multiple new and unregistered users have improved these TFAs and some of their edits still stand days later. The idea that pending changes would lead to a huge backlog of work is unsupported. Not only are most edits done by people who would go right through PC protection without review, those who would are very few and would be auto accepted by a revert without needing PC reviewers to intervene. When I say that those supporting automatic semi-protection are relying on intuition and not evidence, this is what I mean. If you actually took the time to look at the edits being made instead of checking to see if it's an IP address with the "reverted" tag, you'll see that these fears about vandalism are overblown. I've even shown you examples of helpful but imperfect IP edits being sumarily reverted by regulars because of formatting errors. Tons of new and unregistered editors are helpful and make valuable contributions to TFAs. Having looked through hundreds of revisions of both TFAs and regular articles I seriously need more evidence about the evil IPs than a bunch of gut feelings, and it's tiring to have actual facts and trial outcomes dismissed in favor of feelings. — Wug·a·po·des​ 01:03, 1 July 2021 (UTC)

    Many decisions are made on intuition and anecdotes rather than hard data analysis. I don't remember the last time I saw statistical evidence influencing an RfC. The best (and perhaps the only good) analysis I've seen on Wikipedia is User:Enterprisey/AIV analysis, but I'm still not sure how many peoples' minds that data changed. The ROI of taking the time to generate and analyse data on Wikipedia is low I feel, and data-based arguments will seldom be more convincing than anecdotes. I would personally not put in the effort to do this kind of analysis for this reason. ProcrastinatingReader (talk) 01:22, 1 July 2021 (UTC)

    On the contrary, I find User:Wugapodes' analysis very useful and has helped convince me we are in very little danger of going under if we don't protect TFAs. Whether the ROI is sufficient is up to Wugapodes in this case. — JohnFromPinckney (talk / edits) 07:10, 2 July 2021 (UTC)

    While I'm sure Wugapodes's analysis took time and is certainly better than anecdotes, when I was referring to "statistical evidence" I meant using a large sample size, such as User:Enterprisey/AIV analysis. Probably using some data science tool, since it'd be too tedious to do by hand. We have 30 days of trial data from the previous RfC that remains unanalysed (for the most part), and a lot of historical data (in the revision history) of what happens to articles while they're on TFA. If we want definitive answers to the questions we ask, the data exists and it's in public revision history. But only so many people can analyse it, and I just can't imagine it'd be worth their while, because it seems unpredictable how much of a difference it would make -- if the data suggests problems, will people abandon their 'pre-emptive protection/anyone can edit' philosophy? similarly, if the data suggests minimal issues, will editors forget about their anecdotes? ProcrastinatingReader (talk) 13:37, 2 July 2021 (UTC)

• Support semi first choice per everyone else above, PC distant second choice (because it still takes up too much editor time). Levivich 06:51, 30 June 2021 (UTC)
• Support semi PC is useless in general, it should almost never be applied. It is a waste of editor time. Semi'ing TFA is a sensical and reasonable action that should have happened years ago. It is hardly premature: we know that TFAs are routine targets of vandalism. We're so stuck in the idea that pages aren't pre-emptively protected that we forgot that our rules can be changed if doing so benefits the encyclopedia. TFA protection is a reasonable exception to our regular policy because it saves significant editor time and attention. CaptainEek ^{Edits Ho Cap'n!}⚓ 06:01, 1 July 2021 (UTC)
• Oppose pre-emptive protection in part based on Wugapodes' selective analysis above. I don't care for (it's impolite to say "I hate") PC anyway, and if it's as poorly maintained as I hear then I'm even more glad to avoid it. Applying semi-protection pre-emptively is a big hammer for a couple of small gnats, at most, and as mentioned multiple times above it goes against our anyone-can-edit ethos. Let's just let TFAs be as they are, and the few which get vandalized can (and will) get cleaned up, and when needed protected for the day. — JohnFromPinckney (talk / edits) 07:20, 2 July 2021 (UTC)

Side comment

I have always thought that if the goal is to entice new editors to get involved, then featuring an article that has been worked on for years, and is (essentially) complete is the wrong way to go about it (and yes, I know WP articles are never “finished”… but I think you know what I mean). Perhaps we should (also) highlight an “article for improvement” to fulfill that goal. Blueboar (talk) 13:45, 28 June 2021 (UTC)

This was tried back in 2013, and didn't work out * Pppery * _{it has begun...} 13:58, 28 June 2021 (UTC)

The main issue (I think) with improving articles is the broadness of the topic. For example, I would probably be unable to improve the article Philosophy much, as I don't even know what to add or remove. Only an expert would know consensus and due and undue weight. Looking at Wikipedia:Articles for improvement/2013/21, subjects like Ancient music and Emigration are also very difficult to improve. What should be improved? Due and undue weight? And what about Wikipedia policies and guidelines? I think a better idea would be to list pages that are easy to improve, such as minor CE. Sungodtemple (talk) 17:14, 28 June 2021 (UTC)

Wikipedia:Growth Team features is currently being trialled on English Wikipedia. One of them is to provide a list of suggested tasks for newcomers. isaacl (talk) 23:19, 30 June 2021 (UTC)

The Main Page has different sections. DYK and ITN articles are more underdeveloped. ITN articles are more exciting and ITN events are good for editor recruitment, perhaps the best Main Page section for that purpose. I think one section - TFA - for showing off sustained development to get an article to a 'complete' form is a good thing, both for possible motivation to get articles to that stage, and for readers to see what such articles look like. ProcrastinatingReader (talk) 14:08, 28 June 2021 (UTC)

Getting people to the correct talk page

Template:Wikipedia information pages talk page editnotice is displayed on how-to/instructional pages that get a lot of "irrelevant" posts by newcomers (NB: not guidelines, not policies, not articles, not user pages, etc.).

If you've been around long enough, you've probably seen this: A newcomer will somehow end up on the talk page for a guideline or help page, and they'll post the contents of the article they'd like to create, or they'll ask a question that belongs on an article talk page. If you haven't seen this before, look at Wikipedia:Citation needed and Wikipedia talk:Citation needed and its archives (Wikipedia talk:Citation needed/Archive 5 is the most recent). Almost none of the discussions on that talk page are about that page.

This was the old version of that notice:

I found this ineffective, so three months ago, I changed it to this:

I think this is more effective. Instead of inviting people to read a paragraph, it grabs people's attention (good-faith newcomers are often worried that they're doing things wrong, so if you tell them they're about to screw up, they'll read it), and it highlights the key action that most newcomers need to take (go to a different talk page).

As evidence of it likely being more effective, I made a similar change to the top of Wikipedia talk:Citation needed. In the three months before that change, there were four misplaced requests. In the three months since then, there was only one.

Amakuru, an admin with about 70,000 edits (i.e., not a newcomer who doesn't understand what these pages are for), recently reverted this change because "I found I wasn't in the wrong place at all" (exactly as the end of the new instructions indicates is possible...) and suggested a discussion, so that's why we're here. What do you think we can with this message to help newcomers stop posting on the wrong pages? WhatamIdoing (talk) 19:59, 28 June 2021 (UTC)

The problem is that Wikipedia talk:Citing sources shouldn't have that editnotice at all, it's one of the information pages whose talk page is, in fact, being used (by experienced editors) to discuss things other than issues specific to this information or how-to page. It has nothing to do with the wording of the editnotice, and I think that your change is fine on the cases where the editnotice in fact applies. * Pppery * _{it has begun...} 20:08, 28 June 2021 (UTC)

I've nominated the specific editnotice for Wikipedia talk:Citing sources for deletion at Wikipedia:Templates for discussion/Log/2021 June 28#Template:Editnotices/Page/Wikipedia talk:Citing sources * Pppery * _{it has begun...} 20:50, 28 June 2021 (UTC)

This feels a bit WP:SLAPpy, but I support putting notices on all project talks, including policies and guidelines. Newcomers will be directed away, experienced users will know they are right themselves. WP:CREEP really needs to be addressed here. Sungodtemple (talk) 20:27, 28 June 2021 (UTC)

Yes, sorry for not discussing this as well as reverting, but the page I was editing doesn't even have a talk page and it was unclear if there had been any discussion leading to the change. It's obviously a good idea to put messages up for newcomers when they're editing project pages, asking them the question of whether they're really in the right place. I have no objection to that. But if I see a big bold message saying "you're probably in the wrong place" then I tend to believe it, even if I am "an admin with about 70,000 edits". And, as Pppery notes, the majority of people who ever see that message will indeed be in exactly the right place, so the message was just a bit misleading that's all and led me to briefly think I wasn't where I'd intended to be. Cheers  — Amakuru (talk) 20:32, 28 June 2021 (UTC)

You gave an actual explanation in your edit summary, and as far as I'm concerned, that counts as "discussing". :-D WhatamIdoing (talk) 21:35, 28 June 2021 (UTC)

Looks like a more careful thought process about which pages this editnotice should be on and then this change to a more attention-grabbing notice is what's needed. Maybe we only want the dramatic editnotice (or an editnotice at all) on talk pages that correspond to very highly-linked/transcluded things, like Wikipedia talk:Citation needed. — Bilorv (talk) 07:07, 29 June 2021 (UTC)

RfC to elevate NMEDIA to guideline status

FYI

 – Pointer to relevant discussion elsewhere.

There's an open RfC proposing to make WP:Notability (media) into a {{Guideline}} instead of a {{Supplement}} essay: Wikipedia talk:Notability (media)#Status. The discussion really belongs here, but this page should at very least have been notfied.  — SMcCandlish ☏ ¢ 😼  06:16, 29 June 2021 (UTC)

Per the WP:PROPOSAL policy, the discussion about whether to promote a page to guideline status rightly belongs exactly where that discussion is: on that talk page. WhatamIdoing (talk) 20:28, 29 June 2021 (UTC)

Put banners on pages signifying momentous view counts?

Moved to WP:Idea lab § Put banners on pages signifying momentous view counts?

 – {{u|Sdkb}} ^talk 03:03, 30 June 2021 (UTC)