Informatics Educational Institutions & Programs

Post closure discussion on Wikidata lists

• Andrevan, just to clarify/confirm, this is a no consensus outcome? {{u|Sdkb}} ^talk 06:40, 1 February 2023 (UTC)[reply]

Good question… is “lack of consensus” the same as “no consensus”? Blueboar (talk) 12:30, 1 February 2023 (UTC)[reply]

No consensus to change the existing consensus of past RFCs. Andre🚐 15:38, 1 February 2023 (UTC)[reply]

So the existing consensus at prior RFCs still stands. Blueboar (talk) 17:02, 1 February 2023 (UTC)[reply]

Yes Andre🚐 17:08, 1 February 2023 (UTC)[reply]

Thanks for closing, but I think the wording needs clarifying. As I pointed out above, there is no previous consensus on using Wikidata in tables, so this does not get us anywhere different as there is no previous consensus to go back to. The close of the 2013 discussion includes There is a valid point raised that while running text is clearly not suitable for Wikidata use, it might be worth discussing use in tables specifically – but no consensus regarding this has been reached in this discussion. — Martin (MSGJ · talk) 19:58, 1 February 2023 (UTC)[reply]

There is a previous consensus on using Wikidata in tables. It's Wikipedia:Bots/Noticeboard/Archive 13#Re-examination of ListeriaBot and Template talk:Wikidata list#"Not permitted" in mainspace. * Pppery * _{it has begun...} 23:36, 1 February 2023 (UTC)[reply]

It's funny I had also drafted a comment saying "Thanks for closing" and requesting the closing text be more clear, as there was clearly a dispute over how to interpret the previous consensus. However on reconsideration, I hoped that no consensus to permit was sufficiently clear. It is not possible to read this as allowing Wikidata lists, as that opposite interpretation would have required no consensus to prohibit phrasing.

In any case, this closure has already resulted in an editing conflict. Andrevan I thank you for your close, and I request a more clear close-text to avoid further conflicts. Specifically are editors (1) prohibited from converting Wikidata lists to non-wikidata? (2) Are editors prohibited from creating new wikidata lists? Or (3) both are permitted. Alsee (talk) 20:42, 1 February 2023 (UTC)[reply]

There is no consensus to permit using wikidata in article text. My understanding of the prior consensus is that the prior consensus did not permit wikidata in article text. I don't see any consensus here to change the status quo. No specific consensus was reached to allow use in tables, but I didn't review the previous close to see if the use in tables was permitted, but I'm guessing if it wasn't expressly prohibited, then existing usage of it could be justified under whatever prior justification existed. It's a no consensus close with no change to the existing status quo and no new resolution obtained as to new usage of wikidata. Andre🚐 21:12, 1 February 2023 (UTC)[reply]

My understanding of the prior consensus is that the prior consensus did not permit wikidata in article text. This is false. Some of those opposed to Wikidata use tried to imply that, by saying it would run counter to, as one !voter put it, the spirit of the various RFCs on Wikidata use, but that was heavily contested. {{u|Sdkb}} ^talk 23:21, 1 February 2023 (UTC)[reply]

If you are asking me to vacate the close I will vacate it, but the close was a no consensus for any new proposal being enacted close. If the existing state of things was a limbo then it should still be in limbo. I will admit that in the section of the RFC that discussed this I took the word of the participants on the state of the status quo ante, but it didn't factor into this close being a no consensus one. If you really think someone else would close this differently, I am happy to revert myself. Andre🚐 23:29, 1 February 2023 (UTC)[reply]

I don't see a need for you to vacate the close currently; I suspect a different closer would arrive at the same no consensus result. {{u|Sdkb}} ^talk 23:32, 1 February 2023 (UTC)[reply]

For me, the ambiguity lies not in the statement that it is not appropriate to use Wikidata in article text on English Wikipedia, but in the fact that a table is structured content and not article text. The 2013 discussion specifically excluded tables in its close, so there is certainly no existing status quo in this respect. If the closer had written article article prose then it would have been clearer still. — Martin (MSGJ · talk) 23:38, 1 February 2023 (UTC)[reply]

Lists are article text. Tables (unless images) are article text as well. Article text does not need to be in prose form. Blueboar (talk) 00:35, 2 February 2023 (UTC)[reply]

Well that's not how I understand the term. And why else would Coren (the closer) specifically contrast running text with tabular content? Infoboxes are mini-tables, and the usage of Wikidata on them is widely accepted. — Martin (MSGJ · talk) 08:16, 2 February 2023 (UTC)[reply]

@MSGJ you are attempting to argue that calling wikidata in lists was previously permissible, but you are forgetting the consensus banning Wikidata links in the body of the article. There is no interpretation of this RFC or any other RFC granting an exception to that ban. That leaves the options of (1) accepting elimination of these lists, or (2) eliminating wikidata links from these lists and then we can resume debate on how to interpret other past RFCs. Alsee (talk) 15:37, 8 February 2023 (UTC)[reply]

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

RexxS has not - alas - edited for two years. It might be said that if something they did has persisted for that long, then there is consensus for it to be so. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:28, 1 February 2023 (UTC)[reply]

Either that or it simply flew under the radar. I suspect the latter is more likely. * Pppery * _{it has begun...} 23:36, 1 February 2023 (UTC)[reply]

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

"Many people have reservations but see the potential but NOTNOW" is akin to my reading. There's no consensus to permit new things. If there are gray areas before there are gray areas now. The intention is not a consensus for a thumbs down but no consensus for a thumbs up. I'm happy to vacate the close and let someone else close if there are concerns, though. Andre🚐 21:13, 1 February 2023 (UTC)[reply]

• I've amended the close to address this discussion. Let me know if you have further concerns. I am sorry that this outcome isn't very useful but I do not see how it can be closed other than a no consensus for a new proposal to be enacted regarding wikidata lists. Andre🚐 23:39, 1 February 2023 (UTC)[reply]

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

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

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

Responses: Approval of Enforcement Guidelines

• Oppose. I will never approve Enforcement without approval of a code itself. The current Code of Conduct is botched, and without consensus the Code has no legitimacy. Consensus is especially NECESSARY as the Code is almost entirely worthless and ineffectual without active community support for it. Repeated attempts by the WMF to "improve" and re-vote the Enforcement Guidelines can never fix those fatal flaws. The WMF needs to stop trying to steamroll forwards, it is necessary to back up and let the community develop a new Code which actually gets consensus approval. Alsee (talk) 08:07, 14 January 2023 (UTC)[reply]
• This RfC seems founded on a rather narrow understanding of "approval". The UCoC was approved by the WMF Board of Trustees, the legal custodians of this project, who we play a part in selecting. Not all decisions are subject to consensus of editors and local policy specifically recognises acts of the WMF Board as one of those exceptions. The UCoC isn't the first policy to come via this route and we can enforce it with or without guidelines, just like we enforce the Terms of Use, for example. – Joe (talk) 10:12, 13 January 2023 (UTC)[reply]
  • It's also worth pointing out that the (global) community has already approved the enforcement guidelines – the first vote was 56.98% in favour. – Joe (talk) 07:44, 16 January 2023 (UTC)[reply]
• Oppose I didn't participate in this before and I haven't really looked into it all in any depth but it seems to me that if the foundation position is that they must have the code whether community approved or not, then they can impose the enforcement as well and see what occurs. I would not personally approve the enforcement guidelines since by doing so that is in fact approving the code of conduct retrospectively. Selfstudier (talk) 08:18, 14 January 2023 (UTC)[reply]
• Oppose. I agree with everything Barkeep49 said earlier, except the conclusion. If it was a mistake and you don't want the mistake repeated you have to speak up. Frederick Douglass expressed it like this: If there is no struggle there is no progress … Power concedes nothing without a demand. It never did and it never will. Find out just what any people will quietly submit to and you have found out the exact measure of injustice and wrong which will be imposed upon them. Following his crystal-clear logic, there is no choice but to oppose. There is another reason to oppose as well: subject the UCoC to community vetting, and it will become a more robust, less ambiguous document. It will become better, more fit for purpose. --Andreas JN466 09:21, 14 January 2023 (UTC)[reply]

  I see that an abolitionist's words on fighting against racial inequality are being compared and applied to a code of conduct that prohibits name calling, using slurs or stereotypes, and any attacks based on personal characteristics...like...race (m:Universal Code of Conduct § 3.1 – Harassment). 🐶 EpicPupper ^{(he/him | talk)} 00:57, 15 January 2023 (UTC)[reply]

• Oppose. It would be grossly improper for the en.Wikipedia community to in any way endorse a 'code' being imposed without consensus by an outside body. AndyTheGrump (talk) 10:02, 14 January 2023 (UTC)[reply]
• Oppose. The UCoC is well intentioned and contains many sensible rules. However, a similar and more tailored set of rules is already approved and enforced by the English Wikipedia community. The UCoC provides a model which smaller communities may choose to adopt, perhaps even by default, but neither the code nor the new police force that comes with it would be helpful to enwp. The WMF will impose UCoC anyway, but they need to understand that this is a power grab without consensus which conflicts with the community's needs rather than satisfying them. Certes (talk) 10:59, 14 January 2023 (UTC)[reply]
• Oppose as it is inappropriate to enforce something that is not approved. Current codes and practice handles inappropriate behaviour here. Graeme Bartlett (talk) 21:41, 14 January 2023 (UTC)[reply]
• Oppose Graeme Bartlett said it perfectly. it is inappropriate to enforce something that is not approved. Current codes and practice handles inappropriate behavior here. Adding to that, if WMF insists on pushing guidelines invented by them without community approval, its time to fire WMF and replace them with an organization that has not gone astray and revised the bylaws that allowed that to happen. North8000 (talk) 22:05, 14 January 2023 (UTC)[reply]
• Oppose per all of the above (and more). Paul August ☎ 22:17, 14 January 2023 (UTC)[reply]
• Alternative - drop the facade of this being something was in any way “approved” by the community, and admit that it is something imposed by the WMF. Let them figure out how to “enforce” it. Blueboar (talk) 22:38, 14 January 2023 (UTC)[reply]
• I am not sure what this vote is about, but I am personally going to vote on Meta to adopt the enforcement. I opposed it last time and raised a specific concern. From what I see, the problematic part was eliminated, and I do not see any further issues with the enforcement.--Ymblanter (talk) 23:39, 14 January 2023 (UTC)[reply]
• Oppose per Alsee. I'm confused how we enforce a thing that has not, itself, been approved. Somehow I misunderstand. Chris Troutman (talk) 03:53, 15 January 2023 (UTC)[reply]
• I voted against the first enforcement guidelines as I thought there were enough flaws that nothing was better than those. I will be supporting the enforcement guidelines when they come up for a vote again, as enough has changed to tip me over. One concern noted above is something we don't have to worry about. No one is going to be compelled to enforce the UCoC, in the same way no one is compelled to enforce UPOL, BLP, Harassment, or any other policy (or guideline) now. In fact this removes a requirement for admin to agree to the UCoC at risk of losing their adminship and that change is one of the reasons I can support the revision. In the end this is a non-neutrally worded advisory RfC about a Wikimedia wide advisory vote to the Board who will make an actual vote. I suspect that this RfC will attract the people who are most opposed to the UCoC and I think it is important for their voices to be heard, in particular their frustration (which I share) about the lack of community ratification of the original guidelines. I also suspect this RfC will be less likely to attract the people who are mildly supportive of the guidelines but who might vote to approve them in the final vote. So I hope everyone takes note of whatever consensus is reached here - because if a consensus is reached it's worth taking very seriously - but at the same time those participating realize the limitations of what that consensus will mean. Best, Barkeep49 (talk) 05:16, 15 January 2023 (UTC)[reply]
  • I generally agree with Barkeep's perspective here. — Wug·a·po·des​ 20:43, 19 January 2023 (UTC)[reply]
• Support - I might be the only editor on this project who voted for the enforcement guidelines last time and is looking forward to voting for it again. Yeah, it would have been better for the UCOC to be put to a community ratification vote, but that doesn't bother me so much because that decision was made by different WMF leadership than the one that is handling (well, IMO) the enforcement roll-out (cf. it passed with like 55% or so but they didn't implement it, sort of the opposite of how the UCOC itself was handled). The other reason it doesn't bother me is because the UCOC is such a vanilla document--like, it's beyond me what objections anyone could have to those provisions that aren't nitpicky--other than that it's way longer than it needs to be. But overall, put me down for being glad that there's a UCOC and hopeful that enforcement provisions will be put in place soon. That's been long overdue on this website, which has a terrible, terrible record of self-regulating user conduct over the past two decades. It's long past time for English Wikipedia to grow up and start behaving like the rest of the world and not like the wild west... which means a UCOC, and at least some method of UCOC enforcement by impartial professionals rather than volunteer members of the community. Cf. Twitter, which was improved significantly when they started being more serious about regulating user conduct on that website, and has backslid since those regulations were recently relaxed. Cf. all other social media. Levivich (talk) 20:19, 15 January 2023 (UTC)[reply]

  It's long past time for English Wikipedia to grow up and start behaving like the rest of the world and not like the wild west... which means a UCOC, and at least some method of UCOC enforcement by impartial professionals rather than volunteer members of the community. this is going to come off like snark, but I mean this sincerely: if you believe this you should vote against the UCoC Enforcement Guidelines. The Enforcement Guidelines have the Principle of subsidiarity as a major tenet which means that nearly all enforcement, including all new enforcement enabled on other projects that don't have policies and guidelines that already cover the tenets of the UCoC (unlike us), will continue to be done by volunteers (both in the sense that it's people willing to enforce the UCoC and that they are not impartial professionals). There's a path not taken where professional enforcement of the UCoC is what happens but that was not what either of the committees that drafted the UCoC Enforcement Guidelines chose. Best, Barkeep49 (talk) 02:21, 16 January 2023 (UTC)[reply]

  Oh I know, but I disagree that one should vote against the UCOC Enforcement Guidelines if one believes in professional enforcement... I see UCOC and the Enforcement Guidelines as incremental steps. My prediction: both the UCOC and the Enforcement Guidelines will work, and work well. I think we will perceive no change on enwiki (for the reasons you point out: it's set up to not 'mess' with our developed self-government), and that in and of itself will be a big deal, as the enwiki community will come to realize that this is not a "power grab" or anything like that. I think, give it a few years, but it will help develop trust between enwiki and the WMF, and I hope that trust makes enwiki more comfortable with the idea of professional enforcement, which, btw, I pitched today at the idea lab in case anyone is interested (don't forget to hit that like and subscribe button). Levivich (talk) 04:32, 16 January 2023 (UTC)[reply]

  My own expectation is that there will mostly be "no change" until someone decides to try for another WP:FRAMBAN. And then the UCoC will be used to counter the opposition that ultimately resulted in the WMF's attempted ban being overturned. They've got the overbroad language that can be selectively interpreted, they've got the "protect the victim" language to justify not giving any details, they've got the language allowing them to override local processes if they think local processes "refuse to enforce the UCoC" or "lack will to address issues", they've got language mandating the committee be "diverse" in a bunch of ways (but not viewpoints) that could allow for disqualifying troublesome candidates for not being "diverse" enough, etc. Anomie⚔ 00:05, 17 January 2023 (UTC)[reply]

  In the current proposed enforcement guidelines, there is no requirement that the Universal Code of Conduct Coordinating Committee be diverse. That being said, the process for electing this committee is still to be determined by a yet-to-be formed group. isaacl (talk) 00:40, 17 January 2023 (UTC)[reply]

  There is a requirement that the building committee reflect the diversity of the movement and there is a requirement that the work of the building committee be ratified by vote. So while it's true that there is no requirement for the U4C to be diverse, but I would be amazed if there isn't a requirement by the time the U4C comes into existence. To give a peek behind the scenes, the way that the U4C building committee came to be was because I proposed some diversity requirements for the U4C and the original Enforcement Guidelines drafting committee quickly realized just how much time it would take to hammer those and other fundamental U4C questions out. Best, Barkeep49 (talk) 00:45, 17 January 2023 (UTC)[reply]

  Yes, for brevity I omitted discussion of the building committee. If the entire coordinating committee membership is elected, I can only imagine mandated diversity that covers certain broad characteristics, like geographical region. We'll see what the building committee comes up with. isaacl (talk) 00:56, 17 January 2023 (UTC)[reply]

  It says The U4C’s membership shall be reflective of the global and diverse makeup of our global community. True, the current "such as but not limited to" list is only in connection with the building committee, but I'd be surprised if they didn't wind up with basically the same thing for the committee itself. Anomie⚔ 10:17, 17 January 2023 (UTC)[reply]

• I don't broadly disagree with the intent of creating a UCoC, but I think that it's important to observe that the rest of the internet is (on the whole) even worse at this than Wikipedia, at least aside from smaller communities that are easier to moderate in a hands-on manner. Compared to eg. Facebook or Twitter we are vastly better at handling issues even on talk - I definitely don't agree that (even prior to their current issues) they were doing better than we are. Twitter and Facebook, for the most part, still allow, and have always allowed, things like the aggressive promotion of fringe theories or even "dogwhistle" racism, sexism, transphobia, blatant trolling and so on as long as it doesn't trip one of the few red lines they've set; similarly, aggressive harassment occurs on those platforms quite regularly as long as it doesn't cross one of their few red lines. Wikipedia isn't perfect but I feel that it has generally done better than those, and part of the reason is because of the limitations that come from trying to solve complex social issues via a set of rigid rules established from above with no input or buy-in from the community. I absolutely do not think we should be looking at Facebook or Twitter as the model for how to handle anything, ever, and I'm baffled that anyone would say otherwise - they are examples of what not to do. --Aquillion (talk) 04:24, 16 January 2023 (UTC)[reply]

  allow, and have always allowed, things like the aggressive promotion of fringe theories or even "dogwhistle" racism, sexism, transphobia, blatant trolling and so on as long as it doesn't trip one of the few red lines they've set is how I'd describe Wikipedia ¯\_(ツ)_/¯ I don't really think that Twitter or Facebook (or any other social media, or reddit, or 4chan, etc.) is any better or worse than Wikipedia, especially not Wikimedia as a whole. I don't have any statistics or way of measuring it, but in my admittedly anecdotal experience, I just don't perceive a difference between the people here, the people on any other social media I've used, and the people out there in "the real world". It's all filled with racism, sexism, -phobias, etc. If anything, I think we're a little bit worse, because we let people vote other people off the website, which gives Wikipedia more of a Lord of the Flies vibe than other sites, IMO...and I say that as a participant in many such votes. It's a YMMV situation I think. Levivich (talk) 04:36, 16 January 2023 (UTC)[reply]

  I suspect we're better than those other sites you name. One reason I suspect this is that none of them have published how many of its users feel safe, unlike us. Best, Barkeep49 (talk) 00:48, 17 January 2023 (UTC)[reply]

You're not the only one. One of the (many) problems of us only discussing the UCOC in negative RfCs like this one is that we tend not to hear from people who think the UCOC sounds like an okay idea and/or aren't into playing power games with the WMF. That in turn gives the impression that the UCOC is being imposed an an enwiki community that largely opposes it (seemingly taken as writ by many above), which we don't actually have any evidence of. The results of the last vote on the enforcement guidelines (57% in favour) would suggest that a majority are supportive – unless you think enwiki is out of step with the rest of the movement on this, which again we have no evidence of. – Joe (talk) 07:59, 16 January 2023 (UTC)[reply]

• Oppose. I don't think that this sort of top-down approach is workable on a site as large as Wikipedia is. We function, to the extent that we do, because of our collaborative culture, and while a UCoC is something we could benefit from, it is completely unworkable to try and impose or enforce one from above without the consensus of the community. --Aquillion (talk) 04:24, 16 January 2023 (UTC)[reply]
• Regardless of the provenance of the code of conduct, I agree with giving the community the opportunity to support or oppose the enforcement guidelines. Those who wish to oppose based on who approved the code of conduct are free to do so. Those who want to ensure that the enforcement guidelines defer to existing enforcement structures and existing guidelines (as per UCoC violations that happen on a single wiki: Handled by existing enforcement structures according to their existing guidelines..., from the revised enforcement guidelines) have a way to influence the process. isaacl (talk) 04:40, 16 January 2023 (UTC)[reply]
• Oppose acting on them, neutral on actual voting on the EGs - I will join the gang in saying that I don't plan on ever (at least, in my role as an en-wiki admin - and I'm not planning on running for any other position in the next few years!) executing a sanction based on the UCOC here. I opposed the last set of enforcement guidelines, but am probably a weak support for the new set - although they *still* lack sufficient bits on the two aspects of right to be heard (evidentiary access and actually being heard). But while the EGs are much improved (and presumably passed by vote) the reasoning everyone else has given for the original UCOC holds true. I don't accept as a reasoning "you could always oppose the EGs if you don't like the UCOC", because that splits the reasoning with everyone who thinks it's already in place.

The base policy text is unacceptably vague at multiple aspects, unacceptably blurs necessary and desired actions, and imposes a scope that covers every action any of us will take on this planet. It also lacks a sufficiently codified amendment structure. Per Barkeep49 - this technically is a just a community position RfC, with the issues he raises. I suppose we could do another one that would prohibit any on-en-wiki UCOC-based action that doesn't have an underlying (overlying?) en-wiki PAG as well, which could reasonably be viewed as causing quite a lot of conflict for not much practical difference. Nosebagbear (talk) 14:30, 16 January 2023 (UTC)[reply]

• Oppose per all the above. Just because the WMF is intent on imposing this, there is no reason we have to approve it. As has been pointed out, it's so vague anything we do could be an offence, or not, or it could be different based on how we identify, and they could call it anything they want and deal with it however they want. After all, they own the servers. It wasn't meant to be this way.--Wehwalt (talk) 16:46, 16 January 2023 (UTC)[reply]
• I think Barkeep49 has put it in a much better way than I could (see above): In the end this is a non-neutrally worded advisory RfC about a Wikimedia wide advisory vote to the Board who will make an actual vote. Also I'm somewhat skeptic about how to interpret whatever result comes out of this RFC, given there is a community consultation about EG approval via vote, which I'd expect to have higher participation than this RFC. MarioGom (talk) 20:11, 16 January 2023 (UTC)[reply]
• Oppose, per (all) the other opposes. Lectonar (talk) 12:10, 17 January 2023 (UTC)[reply]
• Oppose I have to laugh at the WMF looking to take 'enforcement' action against ENWP users while simultaneously Rebecca MacKinnon (WMF VP, Global Advocacy) is deliberately attempting to interfere in UK legislation that would (potentially) hold tech executives liable for their organisation's misdeeds by mischaracterizing it as an attack on free speech. Only in death does duty end (talk) 13:15, 17 January 2023 (UTC)[reply]
• Support I don't find anything strongly objectionable in the UCOC or the Enforcement Guidelines, nor do I think they will have a significant impact on the way the English Wikipedia is run. Their influence is likely to be stronger on smaller Wikis, giving the WMF more tools to fight institutional capture by bad faith actors. The process was and is imperfect. However, the WMF is holding multiple community-wide ratification votes on these guidelines and has given many clear opportunities for us to be heard over a period of years. They have responded seriously to feedback and made changes as a result. Simply put, I think this is a net benefit for the Wikipedia movement as a whole and probably largely irrelevant to the English Wikipedia specifically. I echo what Barkeep and Levivich have said. —Ganesha811 (talk) 13:32, 18 January 2023 (UTC)[reply]
• Oppose I've seen little effort by the Foundation -- & especially the employees who were driving its adoption -- to discussing why their draft of the UCoC was a good thing. Instead, they engaged in patting themselves on the back for getting the board to adopt it (whom I doubt fully understood the document or how it would be implemented) & how it would be such a good thing. Considering the hostile acts the Foundation have taken against the volunteer communities in the past, I can't support this document without serious reservations & doubts about how it will be applied. One of the features about ruling by consensus is that one has to engage in dialogue with all parties so they know their concerns are heard, & hopefully addressed; there has been little effort by the Foundation to do exactly that. -- llywrch (talk) 21:24, 18 January 2023 (UTC)[reply]
• Oppose even being on the Arbitration Committee and hearing WMF talk about the early parts of the UCOC, I still don't really understand how it is particularly an improvement on the English Wikipedia's current mechanisms, and beyond that the fact that it was foisted upon the community and we're doing all these quasi-democratic showpieces around the thing treated as a fait accompli is beyond insulting, and against the pillars Wikipedia is supposed to operate on. The reality is regardless of what "votes" say about the UCOC, the first high-profile time someone tries to actually sanction someone based on it, we're going to get into a huge pissing contest the likes of the Fram debacle or similar WMF overreach showdowns. If they're so confident in their product, how about the community gets to decide? Der Wohltemperierte Fuchs ^talk 20:06, 19 January 2023 (UTC)[reply]
• Comment. I have very mixed feelings, and will make a "comment" instead of a support or oppose. It's very clear that the UCoC is going to be implemented and enforced regardless of what editors say here. The UCoC actually has been approved, just not by us. I will also say that I am actually pleased that the enforcement proposal being voted on now has removed, in response to community feedback, the implied requirement that all admins here would have to sign some sort of loyalty oath. So, on the one hand, I, like many other editors above, would like my opinion here to be heard as finding it offensive that the UCoC is being put into effect without clear community support, and that, as such, it feels wrong to ask us to approve its enforcement. But, on the other hand, I think that the proposed enforcement guidelines are as good as we are going to get, and could have been a lot worse. I'm going to say those two things, hope that both messages are heard, and accept that this RfC will be treated as advisory no matter what. And, more likely than not, en-wiki will adjudicate disputes as we choose to do, and when the day comes that we and the WMF disagree, we will have to fight that out regardless of what the WMF will have done with the input they are getting from us here. --Tryptofish (talk) 20:55, 19 January 2023 (UTC)[reply]
• Oppose I think it is quite evident how little regard WMF has for the community, and pushing though the CoC without community vote and then trying to add the associated enforcement guideline only goes to continue the pattern of disregard. It is not clear to me how another layer of rules changes or improves the situation for the enwiki community. We already have plenty of policy, rules, ToS, consensus and enforcement mechanisms as it is, and the complexity of engaging with Wikipedia already drives people away. I have never seen a serious case of disregard for community standards from any established editor, and the community has plenty of ways to police itself. Melmann 20:37, 20 January 2023 (UTC)[reply]
• Oppose This word might be used too often, but this is Orwellian. ~ HAL333 02:40, 21 January 2023 (UTC)[reply]
• Oppose. Nonsensical to discuss how to enforce a policy without first deciding if the policy should be enforced. I plan to propose that we hold an enwiki-only securepoll vote or RfC to determine whether there is a consensus here for either the policy or the enforcement guidelines. BilledMammal (talk) 07:35, 2 February 2023 (UTC)[reply]

Discussion: Approval of Enforcement Guidelines

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

@Alsee you should have a single neutral RfC question followed by a signature. But right now this RfC has neither. You could after the question then have background and then responses. Best, Barkeep49 (talk) 15:57, 14 January 2023 (UTC)[reply]

I think it was poor form to simply discard the responses you received so far and start again. The question posed here is essentially the same as above. – Joe (talk) 07:32, 16 January 2023 (UTC)[reply]

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

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

HouseBlaster^talk 23:31, 14 January 2023 (UTC)[reply]

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

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

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

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

The first version of the enforcement guidelines included a section stating that all advanced rights holders should be required to affirm [that] they will acknowledge and adhere to the Universal Code of Conduct. There's nothing in there about what would happen if someone refused to affirm it. – Joe (talk) 07:40, 16 January 2023 (UTC)[reply]

• Houseblaster correctly notes that the WMF and the BOT has shown genuine, highly positive steps with their ultimate actions in the fundraising banner dispute. The UCOC issues however, rather significantly predate those. When the WMF finally started discussing ratification for EGs (and they at least were quite clear in those meetings it was the cross-arbcom letter that drove those), they seemed to feel that no-one had raised the desire for ratification on the policy text. When I provided the diff of I and another asking for it during the phase 1 consultations, that particular staffer seemed to ghost me for the remaining discussions - before the WMF just decided to opt for 50%+1 as a ratification margin. No adequate reason has ever been given for why, say, the policy text couldn't undergo ratification attempt alongside the EG's. Nosebagbear (talk) 14:37, 16 January 2023 (UTC)[reply]

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

I don't feel that Facebook and Twitter are good comparisons to Wikipedia, because whereas they are explicitly for chatter about anything, Wikipedia discussions must be related to Wikipedia editing and thus ultimately to improve Wikipedia. This provides a central guiding purpose that can be used to filter unrelated discussion. De-centralized enforcement of process can allow for more consideration of context, and that is what the code of conduct enforcement guidelines are proposing: disruption on English Wikipedia will continue to be handled by English Wikipedia's policies and enforcement procedures.

On a side note, the problem with English Wikipedia's decision-making process is that it's a mass, unmoderated conversation amongst everyone, and that doesn't scale well to more than a small number of people. As a result, we don't necessarily get full consideration of context, as a small number of people can dominate discussion and drown out others, leading to attrition in participants. With no bar to participation, it's easy for anyone to chime in without taking time to become familiar with all aspects of the situation. It's also inefficient, taking up the time of a lot of people, and inconsistent, relying on whoever shows up on a given day. Without refinement, it's not a model for social networks to follow. isaacl (talk) 21:46, 16 January 2023 (UTC)[reply]

@Aquillion: Yeah, I think as you say because I'm a "power user", I'm more familiar with inner workings, and that's why I beleive "the last great place on the internet" media narrative is more myth than reality--plus, as you mention, they (the studies, the media) focus on content dispute resolution (where I agree we are better than social media), but I'm talking exclusively about conduct dispute resolution (subject of the enforcement guidelines). I don't think there have been many (any?) studies of how well ANI has worked (or AE, or Arbcom, etc.). I freely concede that much of this is very subjective. In the recent massive RFA incident you mention, whether one sees that as a failure or success depends very much on one viewpoint: a block, and an unblock, and a reblock, but not a siteban. It's a glass-half-full-or-half-empty situation.

The thing is, I don't see UCOC and UCOC enforcement as a "top-down" situation, mostly because I see us (the community) as being on top. I fully and always will support the community being the ultimate decider of policy, even though I think we should delegate some day-to-day stuff to paid professionals since we have the money. The enforcement guidleines are coming from the community: multiple votes, plus the drafting committee has community members on it, and the trustees who ultimately approve it are elected by the community. It's our document, written by our people, approved by our people. The UCOC was essentially the same except for the community ratification part. To me, neither document are "top-down" (imposed on us by the WMF).

While I believe professional first-line-of-enforcement would reduce abusive reporting, the UCOC/enforcement guidelines don't do that, and they leave first-line-of-enforcement to enwiki, so in that sense, it's not changing, which means I don't believe that it'll have an effect on abusive reporting. However, I think the possibility for appeal to the U4C (or whatever it's called) would reduce abusive reporting by allowing another level of review, one of the things I like about the enforcement guidelines. Levivich (talk) 22:14, 16 January 2023 (UTC)[reply]

• Note, voting has opened on the UCOC-REG, I've added it to the Watchlist Notice per the precedent of the last notice. — xaosflux ^Talk 00:58, 17 January 2023 (UTC)[reply]
• After 3 days this RfC has, at the time I write this, attracted 22 participants who've given a topline comment in "responses". After less than 1 day of voting, the official ratification has had 151 participants whose homewiki is English Wikipedia. It appears that there will be a consensus of some kind reached here and it should be respected for what it is. But what it is not is a consensus of people interested in the UCoC on English Wikipedia. Best, Barkeep49 (talk) 15:50, 17 January 2023 (UTC)[reply]

  I agree completely. I still tend to think this RfC was created to serve as a fait accompli, and struggle to see how this could be interpreted by WMF in any way other than "micro-consensus". 🌈WaltCip-(talk) 13:33, 19 January 2023 (UTC)[reply]

• Quick question: Isn't there already a mechanism for users to vote on the enforcement guidelines? Why this second vote? Surely, anyone can go vote in the SecurePoll vote and have their voice heard that way. Why are we having a second vote here? --Jayron32 18:43, 19 January 2023 (UTC)[reply]

  If I understand correctly, the point of this RfC is to discuss whether the SecurePoll is about the right question. ~ ToBeFree (talk) 20:07, 20 January 2023 (UTC)[reply]

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

But someone else can start that eventual RfC : )

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

Hiding the talk link is a very very bad idea.

We operate on the consensus model here.

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

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

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

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

RfC Discussion

• @Jc37, I'm not sure what you mean. The talk page link is just below the page title. — Qwerfjkltalk 20:37, 19 January 2023 (UTC)[reply]

  I think they mean the link to their own user talk page, which is indeed now in a dropdown (unless you have new talk page messages, in which case it's more prominent like before). Matma Rex talk 21:13, 19 January 2023 (UTC)[reply]

  @Matma Rex, I see. But people still get the big yellow notification that they have messages, so I don't see the problem. — Qwerfjkltalk 21:22, 19 January 2023 (UTC)[reply]

  anything - anything that reduces the visibility and/or ease of accessing the talk page is a bad idea. We want people to discuss. We want people to respond to talk page concerns about their editing. Not to get frustrated because they can't find the link, and thus not engage. There are innumerable reasons that hiding the talk page link is really bad. Even just from the optics of suggesting that talk pages are uninportant. I understand that this may seem an innocuous change for some, but when I consider years - decades - worth of dispute resolution, among many other things, this just really really seems an incredibly bad idea.- jc37 21:46, 19 January 2023 (UTC)[reply]

  @Jc37, so your problem is that people might get talk page message, dismiss that notification, and then not know how to find their user talk page and respond? — Qwerfjkltalk 21:59, 19 January 2023 (UTC)[reply]

  One, of several. Anything we can do to get people using talk pages, the better. We've repeatedly seen that initial talk page usage helps bridge the learning curve gap for people to turn into regular editors. It's part of why we encourage the community aspect of Wikipedia. Learning how to thread discussions on a talk page can lead to being confortable to add to lists, to add references, and just merely feeling comfortable to edit a paragraph on a page. These are called "gateways" for a reason. - jc37 22:14, 19 January 2023 (UTC)[reply]

  Most newcomers are using the Reply button, so they don't have to count colons any longer. The learning curve is essentially flat.

  The Editing team, as a result of mw:Talk pages consultation 2019, considered ways to make talk pages more visible, but it's tricky, and I don't think that they got very far. You don't want the "Talk" tab at the top to be more prominent than the article tab. You also don't want it to be more prominent than the Edit button. So at best, it's in third place. In terms of your own User_talk: page specifically, I think that Growth's Newcomer homepage work has made some difference there. Whatamidoing (WMF) (talk) 23:37, 19 January 2023 (UTC)[reply]

  I appreciate all that. I do. But all I need do is look at the default signature for editors to see that Wikipedia sees the value of a talk page link. (And yes, I'm aware that mine isn't there - user pages are important too : )

  But anyway, if it's in third place, then watchlists decidedly aren't. And while I may have done some looking around to find out the difference between notices and alerts, I doubt the average person would know, or care.

  tried and failed doesn't = push through anyway. I understand the idea of the perfect is the enemy of the good - Wikipedia is a work in progress after all. but something like this is different, we're being asked to swallow the watermelon whole, with no changebacks allwed due to fait accompli." what's done is done" and all that.

  I'm not merely complaining to the air, I've actually proposed some suggestions and welcome others. (not adding "support/oppose" sections was intentional). So if you have any ideas for a way forward, I'd be happy to hear them. - jc37 23:54, 19 January 2023 (UTC)[reply]

  I don't think that I want to get in the middle of whether the talk page or the watchlist is the more important thing to show. I imagine that most editors want both.

  But now I'm not sure that we're talking about the same thing. At the top of an article, volunteer-me sees these options:

  Article – Talk – Read – Edit – Edit source – View history – Watchlist star – More menu – Twinkle menu

  This is what I see in the new Vector 2022. Are you seeing something different? Are you not seeing the "Talk" item right next to "Article"? Whatamidoing (WMF) (talk) 21:45, 20 January 2023 (UTC)[reply]

  @Whatamidoing: I think Jc37 is referring to one's personal user talk page (), which is in the dropdown menu for , rather than a page's talk page (). —Tenryuu 🐲 ( 💬 • 📝 ) 22:30, 20 January 2023 (UTC)[reply]

  You also don't want it to be more prominent than the Edit button. Yes I do. Levivich (talk) 16:54, 21 January 2023 (UTC)[reply]

  I think that in the end, anything that improves or makes more efficient the talk page in a non-obnoxious manner should be implemented. In particular, I believe that the talk page is one of the biggest catalysts for recruiting new editors, and if they see a place where not only their voice matters but they can participate in a discussion with consequences they can see, I think we've done a good job at recruiting a new editor. Put another way, to know that the change you helped to support 10 years ago can still be found on the website is, for lack of a better term, a magical feeling. InvadingInvader (userpage, talk) 21:46, 31 January 2023 (UTC)[reply]

  Very few editors make their first edit on a talk page. Whatamidoing (WMF) (talk) 01:11, 1 February 2023 (UTC)[reply]

• Let editors have the option to unhide the Contributions link, too. Some1 (talk) 01:32, 20 January 2023 (UTC)[reply]

  @Some1 and @Anarchyte - see Wikipedia:Village_pump_(technical)#Customizing_button_shortcuts_in_top-right_menu_area? for a userscript an editor can use to add contributions to the page top. — xaosflux ^Talk 01:03, 21 January 2023 (UTC)[reply]

  The userscript is better than nothing I guess, thanks xaosflux! Some1 (talk) 01:14, 21 January 2023 (UTC)[reply]

• Support - adding the ability to choose which buttons appear outside of the user dropdown menu would be a drastic improvement. Anarchyte (talk) 08:08, 20 January 2023 (UTC)[reply]
• This RFC is a bit misleading in the title, "Talk" in general is not in any menu, this is only about the link to someone's own usertalk page. This is also something that is skin-wide, so would really need to be changed upstream. I don't see this as severely breaking the consensus building model, as most consensus building discussions don't take place on personal user talks, but on article talks or project pages, both of which are already accessible. — xaosflux ^Talk 12:32, 21 January 2023 (UTC)[reply]

  The title is: "restore "talk" from drop down" - that is exactly what this is about. the talk link in the drop down. Nothing there misleading at all. - jc37 08:32, 22 January 2023 (UTC)[reply]

• FWIW, started talking about maybe making a gadget for this (see Wikipedia:Village_pump_(technical)#Customizing_button_shortcuts_in_top-right_menu_area?). However it would be opt-int. — xaosflux ^Talk 15:38, 21 January 2023 (UTC)[reply]

  Should not require Javascript. - jc37 08:32, 22 January 2023 (UTC)[reply]

• Support: There is a huge gap between search box and "CX Zoom" at the top, which could've been utilised in better ways. Talk pages should absolutely be visible on up there in order to assist new editors find a link to there. —CX Zoom[he/him] ^{(let's talk • {C•X})} 16:17, 21 January 2023 (UTC)[reply]

  This is exactly what I was saying about the "log in" button for unregistered users. Whether logged in or not, the WMF seems intent on wasting that space and forcing us to live with it. —pythoncoder (talk | contribs) 17:56, 1 February 2023 (UTC)[reply]

• Support, per CX Zoom. Also support restoring a link to an editors contributions. BilledMammal (talk) 07:38, 2 February 2023 (UTC)[reply]
• As someone who has been using Timeless, I can say that having the user links in a dropdown does not cause me any issue today, and it's second nature to click these links through a dropdown. (I'll move to Vector22 on desktop probably Soon, just have to get off my preferences butt, and mobile Whenever it actually supports mobile.) Oppose accordingly. "Supports" and "opposes" aren't really valuable here. Discussing why you want a link in X or Y position might be, but is still squarely in the realm of design, especially (as I'm sure they will) as they start turning to making the skin friendly(er) for mobile. It might be valuable to decide on what the most valuable links are in the dropdown, rather than having RFCs for this that and the other thing, and see if there can't be some thought put into displaying certain links at certain widths (perhaps as icons, though I know the group that hates the dropdown is probably a concentric set with the group that hates icons). In general though, this dropdown is provided for the set of people who already do have access to scripts, so they always have a workaround to what is/isn't displayed. Izno (talk) 21:08, 4 February 2023 (UTC)[reply]

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

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

• Strong support, as in "this could be one of the most important changes Wikipedia makes" support. To a new user, the wikitext editor is terrifying and bloated. To an experienced user, it can still be bloated. I'm fairly competent with wikitext, but I still use the visual editor for most purposes simply because the wikitext editor is too much to wade through unless you're making a really technical edit. I genuinely think Wikipedia would have a much larger user base contributing if the visual editor was the default. Thebiguglyalien (talk) 03:56, 31 January 2023 (UTC)[reply]
• According to Wikipedia:VisualEditor this is already the case. CMD (talk) 03:57, 31 January 2023 (UTC)[reply]

  For an IP editor, the default is the wikitext editor, but it gives a pop up asking if you want to switch to the visual editor, which I imagine is meaningless to most users. I suppose it's not quite the same thing as a new account (and SunDawn might want to look into it to see where the discrepancy is), but visual editor definitely needs to be more accessible. Thebiguglyalien (talk) 05:20, 31 January 2023 (UTC)[reply]

• Strong oppose.

  

  The WMF has been persistently and attempting to force this, despite the fact that they have data showing that defaulting into VisualEditor is harmful. There of course are some people who prefer VE, but the objective data shows the overal impact is negative. The WMF has been resistant to collecting good data on this, but I can report what we do have. If you examine the graph at the right, you'll find that the Desktop Wikitext Editor has approximately DOUBLE the retention rate as Desktop Visual Editor, and that Mobile Wikitext also has about DOUBLE the retention rate as Mobile Visual Editor. That is a pretty staggering difference. From the published graph we cannot tell whether Visual Editor is causing half of editors to quit editing entirely, or whether users given VE-by-default merely abandon VE to use the Wikitext editor instead, or more likely some mix of both. Regardless, the data is extremely damning.

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

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

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

  I don't agree with your assessment of the data shown in the graph. The caption reads, emphasis added: This includes all logged-in users who made an edit at any time, on any wiki, between October 2017 and March 2018, regardless of the number of edits made before the study started. This graph does not show overall retention rates for new accounts. Edits in four editing environments were measured: the 2010 WikiEditor, VisualEditor's visual mode, the MobileFrontEnd wikitext editor, and the MobileFrontEnd visual editor. It excludes all edits using VisualEditor's 2017 wikitext mode, [...] All manual "Undo" actions are counted as "using" the 2010 WikiEditor. Users who used multiple editing environments are counted separately for each editing environment. Therefore, each user can appear up to four times in this graph. If a primary user of VisualEditor uses the undo button frequently, then they are counted as a "retained" user of the 2010 WikiEditor. 0xDeadbeef→∞ (talk to me) 12:44, 31 January 2023 (UTC)[reply]

  I agree that the available data isn't exactly the data we need. I said it's the best available data, and that it's pretty damning. The result was disastrous when they tried collecting data for VE-on-mobile. How about we agree that we shouldn't be making such a critical change like this unless-and-until we actually do collect data on what effect changing the desktop default has? I have requested the WMF collect this data, and they declined. I'm all for a formal community request that the WMF do a proper test on this. Alsee (talk) 12:55, 31 January 2023 (UTC)[reply]

  "How about we agree that we shouldn't be making such a critical change like this unless-and-until we actually do collect data" If the situation we're complaining about wasn't justified with data, why should a change to it require that justification? Is the current situation (that in effect, new editors get locked into VE or wikitext almost at random) even the result of a consensus? MartinPoulter (talk) 13:13, 31 January 2023 (UTC)[reply]

  I just realized - this isn't even a proposal to change the default editor. This is vastly worse. This is actually a proposal to move away from the "remember my last editor". People who actively choose to use the Wikitext editor would get screwed waiting for VE-to-load and then switch to wikitext on EVERY edit, unless/until the locate preference item to fix this. I likely would have quit editing before I discovered there was a way to fix it. Alsee (talk) 13:07, 31 January 2023 (UTC)[reply]

  The problem is not for prominent editors like you or me - but for newer editors. Experienced editors have the knowledge and the time to go to their own Preferences (which took less than a minute) but newer editor, in my opinion, will immediately be confused by the text editor and stopped contributing. They don't know that Wikipedia have a very user-friendly UI at VisualEditor. They will think that the only way to edit is through this confusing text editor. ✠ SunDawn ✠ (contact) 15:45, 31 January 2023 (UTC)[reply]

• Support. I'm not sure why, but during a recent edit-a-thon at least one new logged-in editor was unable to use VisualEditor, and it us 5 minutes in Preferences to show both editing tabs. VE is easier for beginners. Femke (alt) (talk) 12:18, 31 January 2023 (UTC)[reply]
• Strong support. This is a solid way to make Wikipedia user-friendly and increase the pool of willing contributors. DFlhb (talk) 12:23, 31 January 2023 (UTC)[reply]
• Strong support. Visual editor is the more friendly option for new editors, so we should enable it by default. 0xDeadbeef→∞ (talk to me) 12:34, 31 January 2023 (UTC)[reply]
• Support Despite some long-term attempts to continue forcing wikitext on new editors, it is extremely clear that VE is the more welcoming and easy to understand editing environment. I use it more often than wikitext when editing articles, and have not once in recent years considered wikitext an improvement when trying to explain how to edit to a new editor. Sam Walton (talk) 12:47, 31 January 2023 (UTC)[reply]
• Strong Support I also have been recently running training events for new editors and am having the same problem that it is very easy for them to get locked into the wikitext editor without realising that the visual editor is an option. Fixing that involves taking them to their preferences and is a speed-bump on the whole training process. That's with in-person training; it's exponentially harder to fix this when training remotely. It shouldn't be so hard for new users to access something which has been created to make the experience easier for them. MartinPoulter (talk) 13:04, 31 January 2023 (UTC)[reply]
• Whoa. Why not give them VA as the editor on their first edit, but "Remember my last editor" as the default? Why force them back to VE even after they have switched to edit with wikitext? If they found the switch once, they will find it in the opposite direction as well if and when they want it. Fram (talk) 13:34, 31 January 2023 (UTC)[reply]

  I do agree with this. It didn't break "last editor used" but it provided a good interface for new editors. ✠ SunDawn ✠ (contact) 15:55, 31 January 2023 (UTC)[reply]

• Strong oppose: Alsee has articulated this much better than I could've, so there's that, but I'll add extra. Ever wondered why we teach young kids do addition/subtraction when we all have calculators today (smartphone ones included)? The problem with Visual editor is that it is not univerally compatible to all pages, try editing the tables at United States congressional delegations from New York, for example. To edit them, you need advanced knowledge of wikitext. And to gain that advanced knowledge, you need to gain basic knowledge first, which is gained by editing normal prose. And that isn't hard. My first Wikipedia edit was made when I was in 1st grade (≈6 year old) as an IP. I could understand the wikitext logic and implement it to write prose and construct wikilinks. Is the next generation going to be dumber? No one is taught wikitext syntax in schools or colleges, people learnt it as they edited Wikipedia and that has kept the site running smoothly for about two decades. When we default to VE, and people may start using it for basic editing, they fail to acquaint themselves with the wikitext logic, which will hurt them make complicated edits where visual editor fails. Even today, most complicated templates/modules are maintained by a few old guards who familiarised themselves with wikitext/lua, a level of familiarisation which the newer generation of editors has probably not achieved. No one here will be here forever, and newer editors should be encouraged to use wikitext, rather than be served with VE on a silver platter. I know this is a controversial opinion of mine and will probable lose at the end, but I genuinely consider it to be detrimental to the future of the project. —CX Zoom[he/him] ^{(let's talk • {C•X})} 13:48, 31 January 2023 (UTC)[reply]

  The way I see it, if editors didn't understand wikitext, that is still fine by me - as long as they are able to edit constructively. In my case, my friend just want to add a single information. Forcing him to "learn" wikitext took time, as he will have to read about how to cite properly in wikitext, find the "location" he wanted to edit in the middle of the jumbled things he didn't understand, and so on. While if he got VE, he could just see it, use the cite button, let Wikipedia handle the citing, and he is finished. There are many other scenario. Someone stumbling into a typo on an article can fix it easily if he use VE, while if he see the complexity of text editor, he may be afraid that he broke something then he did nothing. In short, for most editors, I didn't think the knowledge of text editor is necessary. If they are interesting in doing more for Wikipedia, they will learn that text editor offered more, and learn. But if they just want to fix small mistakes and add small bits of information, that should be fine as well. ✠ SunDawn ✠ (contact) 15:54, 31 January 2023 (UTC)[reply]

  This sounds like an argument to import the cite button into the wikitext editor. CMD (talk) 17:54, 31 January 2023 (UTC)[reply]

• Conditional Oppose if this is going to end up breaking the "remember my last editor" option - users should get a consistent experience. — xaosflux ^Talk 14:50, 31 January 2023 (UTC)[reply]

  Let's say we use Fram's input - keep the "remember last editor" while change the default editor for newer editor to VE, would you reconsider your position? My objective is not break the current "remember last editor", but to make VE default for newer editor. ✠ SunDawn ✠ (contact) 15:59, 31 January 2023 (UTC)[reply]

  @SunDawn: I marked that as conditional. I haven't created a brand-new account just to test this, but if I recall correctly the the current default is "Ask me what I want to use" with a big pop up box, isn't it? — xaosflux ^Talk 16:55, 31 January 2023 (UTC)[reply]

  Good question. Does anyone know the current default? I assumed it was wikitext. If it's a pop-up box then I'll change to oppose because a choice is better for editors who can handle wikitext and raises awareness of the "real" editor for newbies. Certes (talk) 17:24, 31 January 2023 (UTC)[reply]

  The current default for IPs appears to be the wikitext editor covered by a large "Welcome to Wikipedia" banner which has a "Switch to the visual editor" button and a "Start editing" button. If this is also the case for new editors, then Wikipedia:VisualEditor is wrong and this list is misleading or bugged. CMD (talk) 17:58, 31 January 2023 (UTC)[reply]

  That's what I recall seeing when making my first logged-in edit on other wikis. If it's also true for enwp, perhaps all we need do is reword the buttons to something more equal like "Edit using Visual Editor" and "Edit as wikitext". One of the buttons is highlighted by default; we may want that to be VE rather than Wikitext. Certes (talk) 18:35, 31 January 2023 (UTC)[reply]

  The way I recall it (when assisting someone new editing) is that they are immediately represented by text editor. The "edit" beside the heading is "edit source", and he is immediately taken to to the text editor. I didn't recall him given the option between VE and text editor. Of course, the sure way to know is to create another account to test it by ourselves. ✠ SunDawn ✠ (contact) 04:49, 1 February 2023 (UTC)[reply]

  Whether you see one tab or two, and if you see one, which one you see, depends on your prefs settings. Whatamidoing (WMF) (talk) 17:57, 2 February 2023 (UTC)[reply]

• Conditional support, only if editors are prominently offered a simple and persistent way to opt out of VE. Certes (talk) 16:19, 31 January 2023 (UTC) It's complicated: see my comment above. Certes (talk) 18:38, 31 January 2023 (UTC)[reply]
• Comment By adding an obscuring layer which is obscure itself, I suspect that visual editor does more harm than good for about 90% of editors. But it might be a good default for the 10% which is those who are just starting.North8000 (talk) 17:58, 31 January 2023 (UTC)[reply]
• Strong oppose. Even on fast machines, the visual editor has a very perceptible lag. If you want to encourage people to continue editing, that is going to be a negative. --Trovatore (talk) 18:01, 31 January 2023 (UTC)[reply]

  @Trovatore I've not seen any "very perceptible lag" with VE recently on my machines - when do you experience it? Sam Walton (talk) 18:18, 31 January 2023 (UTC)[reply]

  To be fair, I'm probably thinking of "realtime preview". But it would be surprising if VE were less laggy than that. Is it? --Trovatore (talk) 18:23, 31 January 2023 (UTC)[reply]

  @Trovatore Realtime preview is a niche feature that new editors probably won't use, and it has to be laggy by design, as I understand it. Rendering wikitext into a preview takes time so it can't happen instantly. There needs to be some delay between the preview updates. VE itself, in terms of actually editing articles, is almost completely lag-free for me. Sam Walton (talk) 18:32, 31 January 2023 (UTC)[reply]

  OK, withdrawn. It looks like I misunderstood the proposal anyway. --Trovatore (talk) 19:57, 31 January 2023 (UTC)[reply]

• Generally support - But this thread is already a bit confusing. It would help to revise the top part to state clearly what the current situation is and what specifically would change. VE is already the default for new users AFAIK, as it should be. As I understand it, this would address a specific issue: people switching to the wikicode editor and not understanding how to get back. If my understanding is correct, I definitely support it. Alternatively, we could replace the unclear toggle button that nobody ever thinks to click with a bright line that says "GET ME BACK TO VISUAL EDITING MODE" unless you disable that in prefs. My engagement with new users has largely been through edit-a-thons and university classes. When I started with those activities, wikicode was still the standard. VE existed, but wasn't very good yet, and I had everyone working in wikicode. It was fine, and I still use wikicode most of the time. At some point some years back, though, VE got good. Using VE during events/classes was -- and I don't like using this term -- a game-changer. It presented a learning curve that took time to get over, and people used to just run away from editing and/or never really got comfortable. Using VE means newbies can get right into editing and spent their learning time focused on things like wikipolicy, citations, style, etc. rather than syntax. Sure, we still talk about wikicode for talk pages, but with the reply tool, even that's less needed. In short, moving newbies away from wikicode has been an incredible boon for new user engagement in my experience, and now one of the most frequent questions I get is "I think I did something wrong; how do I get back to what we used before" when people accidentally find themselves in the wikicode editor. — Rhododendrites ^talk \\ 18:02, 31 January 2023 (UTC)[reply]

  Last I checked, when an IP makes their first edit, they are taken to the source editor and then get a dialog box asking if they want to switch to the visual editor. Has this changed? —pythoncoder (talk | contribs) 18:00, 1 February 2023 (UTC)[reply]

. Comment I would support a far clearer way of switching between the two. When I first started I found VE couldn't do what I was try to do, switch to wikicode and never looked back. However a couple of times I mistakenly switched back to VE, and had to spend 10 minutes trying to work out how to switch back. Hiding the option behind a very unclear toggle is bad UI design. Having a large "back to VE" would be a bad idea, as any IP editor using wikicode wouldn't be able to get rid of it using preferences. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:36, 31 January 2023 (UTC)[reply]

I'm slightly unsure about what's being discussed here. As far as I'm aware VE is the default, yet editors are supporting making it the default. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 16:52, 1 February 2023 (UTC)[reply]

• Support making VisualEditor default. Now that it works well and reliably I tend to use it over source editing unless I'm adding an infobox template or something like that, an activity that new editors are unlikely to be doing. VisualEditor is much more accessible and is capable of performing most edits nowadays. There's quite a few tables across wikipedia that should be altered to make them easier to edit with VisualEditor.Garuda3 (talk) 22:27, 31 January 2023 (UTC)[reply]
• Oppose When you start users on the VE as the default, they will basically never learn to edit the source in proper wikitext. I'd rather have users who come in and get familiar with wikimarkup from the get-go, and then once they get some experience, they can later decide to activate the VE. I'd rather not create a breed of new editors who don't know how to manually add a template or an infobox or troubleshoot a badly formatted table, or whatever. There's value in learning to work in the markup, and if we start people on the VE, we basically create an artificial barrier to advancement in Wikipedia to true competence, which is likely to be as, if not more, frustrating than learning to write in wikimarkup from the start. --Jayron32 16:31, 2 February 2023 (UTC)[reply]
• Oppose until VE is significantly improved. You almost need to have a better understanding of wikitext for using VE than for SE if you want to avoid breaking links and removing semantic templates. Syntax highlighting should definitely be made default though, as without it reference and template bloat can get in the way of the content of the article. – small jars tc 10:47, 5 February 2023 (UTC)[reply]
• Support. I don't believe that markup is inherently off-putting to 'ordinary users'. It wasn't ten years ago when BBCode was everywhere and it isn't now when Markdown is everywhere. But wikitext was never the cleanest markup language to begin with and now that the average article starts with a wall of templates and long embedded references, it clearly is off-putting. This isn't 2013: VisualEditor works fine, offers a kind of distraction-free writing interface that lets you focus on prose, makes it easier to add and format references, and if they find its limits new users can easily switch to source editing. It would be nice to have some hard (and up to date) data on how the switch might impact editor retention before making a permanent change, though. – Joe (talk) 16:38, 5 February 2023 (UTC)[reply]

  I sorta see your point, and I remember ten years ago BBCode was used on forums etc, but even those have some technical barrier. On sites used by 'very ordinary users' like Facebook, I think there were still WYSIWYG editors. I use Markdown on sites like GitHub but on 'normal sites' not geared at technically proficient people I don't recall using Markdown or any other language, it's usually either plaintext editors with no syntax support, or WYSIWYG editors. (with the caveat that my memory might be selectively omitting normal sites using BBCode/markdown!) ProcrastinatingReader (talk) 12:49, 6 February 2023 (UTC)[reply]

  on 'normal sites' not geared at technically proficient people I don't recall using Markdown or any other language – I don't share this experience. I thought the asterisks and underscores used in youtube comments where pretty well known. Discord also has rich text markup and escape codes. They even have little codes for creating emojis in comments on Scratch, a website used mainly by children. [2]. None of this is quite as complex as wikitext, but I don’t think that very ordinary users are yet so dependent on WYSIWYG that the difference is going to be deterring. small jars tc 18:58, 6 February 2023 (UTC)[reply]

  I suppose asterisks and underscores are well known, yes. I guess they're in WhatsApp also. Though IME most people do not use them, I think because they aren't aware how they work. I think Discord does target itself at a relatively technical audience, certainly more-so than Wikipedia. ProcrastinatingReader (talk) 11:57, 8 February 2023 (UTC)[reply]

• Strong support - I didn't even realise VE isn't the default for unregistered users. It should be IMO; in 2023 the average user does not want to write wikitext/raw syntax, is not used to doing so (think the avg site a normal person uses), and even techy users who don't use WYSISYG editors tend to use markup languages that are much simpler than wikitext (e.g. Markdown). As for preferences, it'd be ideal if the choice persisted, and maybe that will happen (n.b. the persisting of fixed/full width opening the door on that), but even without that I think it's better to have VE as the default. Even I use VE to write articles, and not the wikitext editors, and I'd consider myself more technically proficient and used to wikitext than the average person. ProcrastinatingReader (talk) 12:49, 6 February 2023 (UTC)[reply]

  Can we make showing both editing tabs the default for new editors instead? I don't see any reason that this would harm people, and it would give a nice easy button to choose which editing mode you want to use. — Red-tailed hawk _(nest) 00:08, 9 February 2023 (UTC)[reply]

  Going back to two edit tabs, one for each editor, is a very reasonable solution. Note that the WMF imposed the change to a single edit tab without consensus or consulting the community. Here's the MWF's announcement. They unilaterally declared that they are going to drop from two edit links to just one. Alsee (talk) 12:05, 10 February 2023 (UTC)[reply]

VE default discussion

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

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

Further discussion on what to do with the language selector may be warranted on WP:VPIL, since WMF doesn't know either. See phab:T293470 or come talk to me for more details. Izno (talk) 21:21, 4 February 2023 (UTC)[reply]

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

Proposer's note: see recent discussion at Wikipedia talk:WikiProject Years#Births & Deaths sections. Levivich (talk) 18:27, 1 February 2023 (UTC)[reply]

• Support as proposer. The year articles are very long (e.g. 2022 is 206k, 2021 is 227k, 2020 is 360k, 2019 is 316k, 2018 is a comparatively lean 153k). The Births and Deaths sections take up half the pages or more by my eye. Moving them to sub-pages (e.g. Deaths in 2022) is the fastest and easiest way to cut year articles down by about half and finally comply with WP:SIZE, while still having a place to put the content. Note we already have List of deaths by year, Deaths in December 2022 and so forth. (If a death itself was a significant event and not just "old person dies", e.g., an assassination of a world leader, it would still be listed in the "events" sections.) Levivich (talk) 18:27, 1 February 2023 (UTC)[reply]

  If we already have month-by-month death articles, why do we need yearly ones? Seems like unnecessary content duplication. Der Wohltemperierte Fuchs ^talk 18:31, 1 February 2023 (UTC)[reply]

  I support splitting them out from the main year articles. I don't really have a strong opinion about how the sub-articles are organized (e.g. by year or month). Levivich (talk) 18:39, 1 February 2023 (UTC)[reply]

  Monthly articles are for all deaths of internationally notable people. Those on main year articles are only for those who have substantial international notability. Jim Michael 2 (talk) 18:42, 1 February 2023 (UTC)[reply]

  International notability as it has been practiced on year articles is already being questioned as a criteria, as it has been both too arbitrary in what it means and is the subject for all these content disputes. InvadingInvader (userpage, talk) 07:17, 6 February 2023 (UTC)[reply]

• Support - I believe this is being done in the 2021 in the United States, 2022 in the United States & 2023 in the United States pages. GoodDay (talk) 18:32, 1 February 2023 (UTC)[reply]

  Correct. As a frequent contributor to US Years articles, this has been hugely beneficial as we have had more time to add in events without having to be worried about article size due to these deaths. InvadingInvader (userpage, talk) 01:27, 6 February 2023 (UTC)[reply]

• Question – How far back would we go? Splitting 591 BC, which has one death and no births, would seem excessive. Certes (talk) 18:41, 1 February 2023 (UTC)[reply]
  • In my view it's not about how far back, it's about how large the page is. Any page that doesn't need to be WP:SPLIT because it already complies with WP:SIZE shouldn't be split. Levivich (talk) 18:49, 1 February 2023 (UTC)[reply]
• Support. This has been my position for a while. Beyond size considerations, most births and deaths are not notable in their own right. Births and deaths are a WP:MINORASPECT of each given year, and they do not warrant such massive coverage in the year's article. The inclusion of births and deaths is a relic of before Wikipedia was standardized, and the year articles are late to catch up. Thebiguglyalien (talk) 18:50, 1 February 2023 (UTC)[reply]
• Support, per Levivich and Thebiguglyalien. Useight (talk) 18:51, 1 February 2023 (UTC)[reply]
• Support within reason.--⛵ WaltClipper -(talk) 18:55, 1 February 2023 (UTC)[reply]
• Oppose we shouldn't be having discussions about major changes to layout & inclusion criteria of main year articles when their best editor is absent. Jim Michael 2 (talk) 19:20, 1 February 2023 (UTC)[reply]

  What? Who? Levivich (talk) 19:23, 1 February 2023 (UTC)[reply]

  Deb, who is by far the best & most prolific of all editors of main year articles, has been absent since 10 January. Jim Michael 2 (talk) 19:29, 1 February 2023 (UTC)[reply]

  When will she be back? Levivich (talk) 19:31, 1 February 2023 (UTC)[reply]

  We don't know, but the recent discussions about major aspects of main year articles on here & on Years are incomplete without her. Jim Michael 2 (talk) 19:34, 1 February 2023 (UTC)[reply]

  Deb's input is valuable and I hope we have a chance to hear it, and I hope she's having fun while on wikibreak, but I can't imagine Deb ever suggesting we not have an RFC while she is on a wikibreak that's lasted three weeks and will continue for an unknown duration. Levivich (talk) 19:42, 1 February 2023 (UTC)[reply]

  And cf. WP:OWN, WP:YANI, etc. The project is not hostage to any individual editor's attention and participation.  — SMcCandlish ☏ ¢ 😼  23:37, 1 February 2023 (UTC)[reply]

  Of course I would not suggest that :-) I was away for 4 weeks but for obvious reasons I didn't give out that information on my user page. I am fairly neutral on this proposal, but I have to say I am not sure it will have much effect. Year articles should undoubtedly be shorter. I also don't object in principle to summaries. Unfortunately I can't see anyone willing to put in the work to ensure that the global picture is what we get, as opposed to duplication of what's in the article on the United States. I see some people (below) already suggesting that the articles should include everything that is "newsworthy", which may just mean relocating the problem. Deb (talk) 17:52, 7 February 2023 (UTC)[reply]

  Welcome back! We've written several novels about year articles in your absence, apologies for all the reading to catch up on :-) Levivich (talk) 18:11, 7 February 2023 (UTC)[reply]

  One more thing - I just added a comment to the ANI "incident" that you may like to check out in case it hasn't been considered with reference to this RFC. Deb (talk) 17:31, 8 February 2023 (UTC)[reply]

• Splitting the long ones makes sense. Oppose making a general rule (if the list is short, keep everything together). —Kusma (talk) 19:37, 1 February 2023 (UTC)[reply]
• Isn't this what categories are for? --Golbez (talk) 19:58, 1 February 2023 (UTC)[reply]

  No, main year articles have lists of births & deaths of internationally notable people. Those aren't anywhere else. Jim Michael 2 (talk) 20:42, 1 February 2023 (UTC)[reply]

  If their birth or death is newsworthy, it should be included in the article. Otherwise, we're picking and choosing who gets to qualify, which is what we've already done by having articles on them in the first place. I propose removing all lists of births and deaths and relying on categories. Otherwise, what even are categories for? --Golbez (talk) 21:14, 1 February 2023 (UTC)[reply]

  How do you define newsworthy? There's a much higher bar to be in main year articles than to have a WP article. Cats are for many things. Jim Michael 2 (talk) 21:38, 1 February 2023 (UTC)[reply]

  Dying in office. New heir apparent born. First [x] born in [y]. Last person killed by [z]. That kind of thing. And you say there's a higher bar, I say there should be no bar. They should only be included in the year article if they were somehow significant to that year, right? So either their birth is notable, their death is notable, or their actions in life are notable. Everything else, that's (at risk of repeating myself) what we have categories for. --Golbez (talk) 22:38, 1 February 2023 (UTC)[reply]

  Your first sentence would mean that Millvina Dean would be included but Shinzo Abe wouldn't. Significant to that year is arguable in many cases. Jim Michael 2 (talk) 23:02, 1 February 2023 (UTC)[reply]

  You really don't think the assassination of Shinzo Abe wouldn't be mentioned? You seem to still think I'm arguing for a discrete "here are the important people who died" list. No, I'm saying, include them in the actual list of events, if their birth or death was actually notable. I'm pretty sure Abe's is. --Golbez (talk) 23:07, 1 February 2023 (UTC)[reply]

  Which would mean excluding the deaths of Sidney Poitier & Pelé? Jim Michael 2 (talk) 23:16, 1 February 2023 (UTC)[reply]

  Their deaths, in themselves? Sure. Looks like Pele's funeral was a major event though, so that would probably be included. You do realize that all I'm suggesting is that, if people want to find out who died in 2022, they look at the category of people who died in 2022. That's all. There's no need to duplicate efforts in a year article, especially since then it just becomes a popularity contest of who gets included. --Golbez (talk) 23:58, 1 February 2023 (UTC)[reply]

  That cat has multiple times more people in it. The deaths in main year articles are only of those that have substantial international notability. You're implying that thousands of editors have pointlessly made those lists on main year articles during the last two decades. Jim Michael 2 (talk) 00:31, 2 February 2023 (UTC)[reply]

  Kind of! Their sacrifice will be remembered. --Golbez (talk) 04:34, 2 February 2023 (UTC)[reply]

  Many people go to main year articles to see lists of the internationally notable people who died that year. Such lists are nowhere else on WP. Jim Michael 2 (talk) 11:50, 2 February 2023 (UTC)[reply]

  Why? Why do they go to the list? I'm not being facetious. If they want to know who died in the year, that's what the category is for. If they want to know who famous died in the year, well, first of all, if they're on Wikipedia they've already passed notability. Secondly, they aren't going to find the famous people - they're going to find what a tiny subset of a subset of Wikipedia decided were the people worth mentioning. I know this isn't going to change, and I'm not about to right some great wrong with this argument. But I will defend it. --Golbez (talk) 16:19, 2 February 2023 (UTC)[reply]

  Those cats include a huge number of people. The deaths lists in main year articles are those who have substantial international notability. The criteria have been discussed at length. Jim Michael 2 (talk) 18:09, 2 February 2023 (UTC)[reply]

  Jim, this statement is False. We already have lists (such as Deaths in April 2020). InvadingInvader (userpage, talk) 20:03, 7 February 2023 (UTC)[reply]

  I mean that they aren't anywhere else without being mixed in with a far larger number of less notable people. Jim Michael 2 (talk) 18:20, 9 February 2023 (UTC)[reply]

• Support. this sounds like a good idea. --Sm8900 (talk) 20:46, 1 February 2023 (UTC)[reply]
• Support for long cases. If the page is short (mostly it'll be pre-modern years), then no need to split.  — SMcCandlish ☏ ¢ 😼  23:37, 1 February 2023 (UTC)[reply]
• Very weak support I think that this is an axe being asked to do a scalpel's job. Yes, if the article is too long per WP:ARTICLESIZE, than births and deaths make a good target for spinning out into their own articles. However, to say that we need to do so for all year articles is a bridge too far. I'd be okay with guidance that says "If a year article is too long, then it should be considered to split the birth and death sections as their own articles" however, this wouldn't be even necessary for most year articles. Picking a few random years 175 (not needed), 1211 (not needed), 1472 (not needed), 1811 (a bit of a longer article than the rest, but probably still not needed), 1877 (getting longer still. Probably not needed, but reaching the edge-case territory), 1922 (needed, being overwhelmed by births and deaths, and reaching the "probably a bit too long" area), 1988, (likely needed). Given that data, I'd be fine with setting a cutoff of 1900 or later, but even still, we should be careful about how we do this. The current proposal is far too broad. We need to tailor it to actually fix the problem at hand. --Jayron32 12:08, 2 February 2023 (UTC)[reply]
• Support, the WP:SIZE argument applicability gets tricky as this mixes prose and lists, but perhaps that is another argument for a WP:STANDALONE list. Most of the year articles are just lists of course, but they could be much more! Even without that step, I suspect any prose would develop from the events sections, not the births and deaths, so spinning off the undue elements makes sense. (As mentioned above but to clarify, births and deaths that would make the event section are of course fine in the main articles.) CMD (talk) 12:30, 2 February 2023 (UTC)[reply]
• Comment If births & deaths are to be split off main year articles, for which years would this be done? Recent year articles have the most deaths in them, but far fewer births. Jim Michael 2 (talk) 12:35, 2 February 2023 (UTC)[reply]

  It should only be a size issue. If the births section is not too big, don't split it. It's not that complicated. --Jayron32 13:06, 2 February 2023 (UTC)[reply]

  Where do you draw the line? Jim Michael 2 (talk) 13:10, 2 February 2023 (UTC)[reply]

  Do you have any reason to suppose that WP:SPLIT somehow doesn't apply here? --Jayron32 13:28, 2 February 2023 (UTC)[reply]

  I'm not saying it doesn't, but there isn't an exact size at which we should split, so how many main year articles should the births be split off from? How many for the deaths? Jim Michael 2 (talk) 15:49, 2 February 2023 (UTC)[reply]

  WP:WHENSPLIT. Like Jayron said, this is not complicated. Levivich (talk) 15:59, 2 February 2023 (UTC)[reply]

  I'm not convinced that it's not. The way the discussion seems to be heading, we're in danger of creating two articles of unmanageable length in place of the existing ones, with the same debate over "international notability" having to continue. Deb (talk) 13:29, 9 February 2023 (UTC)[reply]

• Support per all above. —Locke Cole • t • c 16:02, 2 February 2023 (UTC)[reply]
• Support Split any article that is over 125K in size (but not with a hard and fast rule: aim for less than or ~100K final article size, if possible.) GenQuest ^"scribble" 16:11, 2 February 2023 (UTC)[reply]
• Support removal, this is what categories are for. No need to split. Just delete. If categories aren't up to the task, then we need to improve how categories work. (can't help but wonder if this is where my 20 year old Semantic Wikipedia proposal would have come in handy...)^{[citation needed]} --Golbez (talk) 16:37, 2 February 2023 (UTC)[reply]

  @GhostInTheMachine well if you insist. =p here --Golbez (talk) 17:57, 2 February 2023 (UTC)[reply]

  Many readers want to find out who the most important people are/were who were born or died in a particular year. Jim Michael 2 (talk) 15:20, 4 February 2023 (UTC)[reply]

That seems like the kind of editorializing other websites, like news sites, might excel at. Maybe if we had a better category system, we wouldn't need to maintain a list like this. --Golbez (talk) 22:48, 6 February 2023 (UTC)[reply]

• Support as long as readers could easily navigate to "Deaths in year X" from "Year X". It is getting too long and too unwieldy. Ancient years where there are no long list of births and deaths should not be changed.✠ SunDawn ✠ (contact) 16:04, 4 February 2023 (UTC)[reply]

  I think that how [[[2022 in the United States]] handled it is the best way. We have a level 2 header with a hatnote. InvadingInvader (userpage, talk) 01:29, 6 February 2023 (UTC)[reply]

• Oppose as it is clear that recent years are suffering from recentism, and need to be cleaned out. Graeme Bartlett (talk) 21:03, 4 February 2023 (UTC)[reply]
• Partial Support, as it fixes the usability issue of having multiple long timelines per page (which makes it harder to use scroll bars to judge which point in the timeline you are looking at). Partial because articles like Deaths in February 2022 appear to include all notable deaths, so are very likely to already include the more selective subset of deaths from the main year articles, so in practice we are talking about deletion of those sections rather than splitting. I support that too, but I’m not sure this is laid out clearly enough in the proposal. Barnards.tar.gz (talk) 22:22, 4 February 2023 (UTC)[reply]

  Barnards.tar.gz: Just to clarify, situations like this would be the exception. There are preexisting standalone lists of deaths for 1990-2023, so it would be effectively be a deletion in those cases since the content already exists at the destination. But all the years before that don't have dedicated lists of deaths, and to my knowledge there aren't any preexisting standalone lists of births by year. Thebiguglyalien (talk) 22:50, 4 February 2023 (UTC)[reply]

• Support per Useight. Good suggestion. This would also have the benefit of preventing some of the horrendously long and mind-numbing disputes recently seen. Happy days ~ Lindsay^Hello 16:18, 5 February 2023 (UTC)[reply]
• Support as it would drastically reduce the amount of content disputes, though I would prefer to see some mention of notable funerals under events, as well as hatnoting these. I would also not be a big fan of splitting these contents if it would end up creating mini stubs, but in general, especially for years 1900+, this is a good idea. InvadingInvader (userpage, talk) 01:25, 6 February 2023 (UTC)[reply]
• Support The articles are moderated pretty well, but the pattern right now is every time someone disagrees it goes to RfC and it basically becomes a popularity contest with no regard for how the article has been managed. Since there's no consensus on a way forward it makes sense to just remove the deaths altogether. Nemov (talk) 16:52, 6 February 2023 (UTC)[reply]
• Support. I agree that births & deaths are minor aspects of a yaer. The freed-up space could be used to turn the lists into prose, which would make these articles far better. DFlhb (talk) 18:13, 6 February 2023 (UTC)[reply]
• Support, so there is no more discussion about who is "internationally" noteworthy enough to be included in the main year article which really comes down to editor opinion. Right now, people are arguing to include Viktor Mazin or Josef Panáček due to winning gold in the Olympics despite a lack of potential WP:DUEWEIGHT in sources (Josef's bio has two sentences, but he's included over someone like Ash Carter). If you list them all on their own page and remove them from the parent, that solves the problem. Of course, deaths like Shinzo Abe and Queen Elizabeth can still be included in the "events" section, as there is related news to that beside just their act of dying (e.g., the assassination; the new king). Why? I Ask (talk) 02:19, 8 February 2023 (UTC)[reply]
• Support Births and Deaths sections are the reason why recent years articles are cluttered. A split would be a good idea, as it would make most discussions regarding death of notable figures moot, and not just that, it would do away the possibility of another discussions regarding these - which always fills up the talk pages of year articles because of debates after debates about THESE deaths. MarioJump83 (talk) 09:01, 8 February 2023 (UTC)[reply]

  Not only that, but these sometimes ridiculous deaths discussions have been draining my mental health. I feel confident in assuming that some other people can relate. I'm glad that we've finally gotten rid of the old "International notability" standard in general, but deaths at this point are best if they face a Morgenthau Plan-like fate. InvadingInvader (userpage, talk) 21:28, 11 February 2023 (UTC)[reply]

• Oppose. Neatly trimmed sections that contain births and deaths should be included, per summary style. That we have a hard time doing this might be part of the task, but merely splitting it out without providing some summary overview in the article seems contrary to that style. — Red-tailed hawk _(nest) 19:16, 8 February 2023 (UTC)[reply]
• Support only for those that satisfy the conditions of WP:SPLIT. If the articles are way too long, then it's a good idea, but for e.g. earlier centuries, most of the year articles are short enough that the list of comparatively smaller births and deaths of people with articles is unobtrusive. Joseph2302 (talk) 13:35, 9 February 2023 (UTC)[reply]
• Support - Where the year article is over-long, and the birth/death is not a major historical event in itself (like, e.g., the birth of Jesus or the death of Stalin). If there is any dispute about where a birth/death should be included as a major event, typically I would expect an article about the birth/death as an event for it to qualify. FOARP (talk) 14:46, 9 February 2023 (UTC)[reply]

so you're saying that we should include a list of very significant events, births and deaths in the year articles, and have a separate set of articles of 'all deaths' in those years? This is already the case. JeffUK 12:50, 10 February 2023 (UTC)[reply]

• Oppose - We already have articles listing all (notable) births and deaths in each year. This is supposed to be a curated list of very significant events in each year; If the problem is that the article is too long, we need an RFC to agree the inclusion criteria for Births and Deaths that would drastically raise the bar for inclusion. I think the same is true of 'Events' as well. JeffUK 12:50, 10 February 2023 (UTC)[reply]

  This is supposed to be a curated list of very significant events in each year. You're right, which is why a deaths and births sections is unneeded in the parent page. It's not a big event that Coolio died. Other deaths, such as Shinzo Abe or the Queen, are notable events themselves with their own pages. But that can be added to the events section as special mentions. There is not need for the random duplication of content across pages, and currently the inclusion criteria is vague and handled by only a small subset of editors. Why? I Ask (talk) 13:13, 10 February 2023 (UTC)[reply]

  My view comes from 'look at what other similar sources tend to include', and a 'year in review' type resource will often include a list of 'important' deaths which is separate from 'events'. There's a difference between a death with is significant (Joe Nobody killed by aliens) which is an 'Event', and the death of someone who is significant, but who's death was otherwise not (Rich old formerly important man dies at home). I think readers expect a listing of significant deaths in the year in some easy-to-consume format, without having to read through all the other events. Looking at the newly formatted 2001 article, I think having a section on 'Deaths' would fit perfectly. I like the idea I saw on one of these myriad discussions about having a guideline/soft limit of X deaths on the main article. JeffUK 19:23, 10 February 2023 (UTC)[reply]

  "My view comes from 'look at what other similar sources tend to include', and a 'year in review' type resource will often include a list of 'important' deaths which is separate from 'events'."

What "similar" sources do that? Most WP:RS that might publish a 'year in review' editorial would be WP:Secondary sources with functions and policies which allow for editorial discretion in making such a list. This project is a WP:tertiary source, an encyclopedia, meant to summarize the positions of primary and secondary sources, with neutrality policies that greater constrain our ability to pick favourites, so to speak, from among topics, on the basis of personal judgment of what is an "important" topic. There seems to be a problem understanding that point of policy and community consensus so far at WikiProject Years, and thus no suggestion (that I have seen presented anyway, from my indirect view of the project and the recent related VP and ANI discussions) that is based in WP:WEIGHT has been advanced out of that project. If there was, I for one should be happy to consider it, as I think there's at least an argument for keeping a summary section in the main article. And yes, a soft limit might make sense there as well. But inclusion criteria has to somehow be rendered out of source-based/NPOV/WEIGHT processes. None of this !voting the opinions of our individual editors as to what we think is important, and then reverse-engineer policy-like language such as "international notability" to rationalize those idiosyncratic preferences after-the-fact nonsense that seems to have become quite common practice on some the years articles in recent years, from the look of the talk pages.

In the meantime, until such a RS-based standard and process is proposed and endorsed by the community at large, the current proposal is a reasonable middle ground solution that addresses the main concern that arises out of the WP:YEARS crowd--which is doubtlessly exaggerated but nevertheless a cognizable issue--that the years articles are too large, but balances that concern against broader, more central, and more critical content policies that the community expects other more localized standards to generally conform to. SnowRise ^{let's rap} 02:31, 11 February 2023 (UTC)[reply]

A deaths section on paper would look nice, but it's like premium gasoline for an engine which produces the lamest edit wars and most unnecessary discussions. I feel like I need ten extra cups of coffee whenever I'm entering Talk:2022 to argue in favor of or opposing deaths. It's become mentally draining for me, and the removal of the section is not only in the interest of the project for reducing these wars, but by extension also in my self interest. No one can agree on a criteria, and given the about of opposition to "International notability" as previously implemented, unless we remove deaths altogether, we're going to be stuck in a gridlock because it seems like no one is willing to concede disputes until an RFC closes or outside admin intervention occurs. InvadingInvader (userpage, talk) 21:24, 11 February 2023 (UTC)[reply]

• Support. I actually think that the need to curtail content on these articles may be at least somewhat exaggerated, in the WP:NOTPAPER sense. But if the choice is going to be between 1) allowing users to run around applying thinly-veiled WP:OR criteria as to the "importance" of this or that person based on nothing nothing remotely tethered to WP:WEIGHT or, 2) simply sequestering the content into separate articles to reduce the perceived need to constantly be asserting policy non-compliant personal calls as an excuse to "prune" the article to personal taste of importance, and then rationalize it by page byte size, then I have to choose the latter. That's unlikely to stop the arguments based on subjective calls in the Years articles altogether, nor completely forestall debates in the death/birth offshoot articles, but it is a start. If the Year regulars come up with a WEIGHT-centered test for inclusion of a summary section in the main years articles that the community can get behind, we can then make that adjustment as well. For the meantime, a clear break moving all death/birth entries to a separate list seems like a workable system. SnowRise ^{let's rap} 02:31, 11 February 2023 (UTC)[reply]

  I personally doubt that such a measure can be agreed upon. When I try to propose criteria myself, I feel that too many people follow an "all or nothing" approach, either restricting ourselves to the old "international notability" standards or including everybody. Frequently, I remember seeing Jim Michael 2 before his TBAN and 4me689 make a lot of these arguments, like "by including Robbie Coltrane we must include Anne Heche" or "we must include Takeoff because we included Coolio". I also remember Scrubby making a lot of anti-Americentric arguments, but there came a point where it at least seemed his position was less anti-Americentric and more so exclude because they're American, which is worse. My attempts to persuade editors into a more consensus-based system not rooted in a standard have all but failed. I think that my support of the removal of deaths, as much as it is rooted in article size, is even more intended to prevent chronic and energy-draining debates. As dumb as the following sounds, it's come to the point where I felt I've been losing my Monday and Friday chess games partly because I used most or all of my brain energy to argue in favor of including Barbara Walters. InvadingInvader (userpage, talk) 21:18, 11 February 2023 (UTC)[reply]

• Support very sensible and long overdue measure. Aza24 (talk) 02:55, 11 February 2023 (UTC)[reply]

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

Incorrect date above?

The RFC just above here says "On 18 January 2022, shortly after ..." Isn't that year wrong? David10244 (talk) 07:25, 4 February 2023 (UTC)[reply]

Yes, but that's kind of irrelevant for a closed proposal... Izno (talk) 21:19, 4 February 2023 (UTC)[reply]

I want to figure out what would I need to do if I want to reopen this proposal in the future? It might have been a case of Wikipedia:TOOSOON. Maybe when WMF adapts the Vector 2022 skin to Mobile Frontend this can be reopened. Aasim - Herrscher of Wikis ❄️ 16:58, 7 February 2023 (UTC)[reply]

When you can actually use it like Minerva on a phone, yes. Aaron Liu (talk) 17:02, 7 February 2023 (UTC)[reply]

Background for assessments on inactive wikiproject banners

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

the wikiproject template now displays a message like:

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

Proposal about assessments on inactive wikiproject banners

This is to propose:

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

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

Discussion about assessments on inactive wikiproject banners

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

• Support. To clarify from previous discussions, the assessments are not just suppressed (hidden), the are detached and no longer included in the total assessment scheme for articles that have only inactive project banners (example: Talk:Ork (Warhammer 40,000), within the scope of defunct WH project and without any active WP project banners, was rated as start, but now is considered unassessed). _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 17:42, 22 January 2023 (UTC)[reply]
• Partial support per my reasoning on Wikipedia:Village pump (miscellaneous). I support the display of the quality assessment on the template. But I do not support the recreation of hundreds of categories deleted over many years. I have put some code on Template:Inactive WikiProject banner/sandbox which will display the class rating and also repopulate the PageAssessments database, which will mean that most of the tools should work correctly. — Martin (MSGJ · talk) 20:36, 22 January 2023 (UTC)[reply]

  *Oppose. This strikes me as a waste of time. Just because there hasn't been a recorded action by a project for three months, doesn't mean that the assessments need to be, well, assessed differently. If they were valid when they were posted, they are very likely valid now, and someone could come along any time and renew activity at the particular project. If the assessments strike someone as needing to be revised, then revise them, but that doesn't require changing the template content in that way. We should be making it easy for projects that have temporarily gone quiet to become active again, not rush to sweep them out the door. --Tryptofish (talk) 22:58, 22 January 2023 (UTC)[reply]

  @Tryptofish, I read the proposal as doing what you suggest, and don't understand why you oppose. —Kusma (talk) 23:10, 22 January 2023 (UTC)[reply]

  You're right, and I struck what I said. I misread it. Sorry for my mistake. --Tryptofish (talk) 23:12, 22 January 2023 (UTC)[reply]

• Support per what I should have understood from the start. --Tryptofish (talk) 23:12, 22 January 2023 (UTC)[reply]
• Support making assessments independent of project activity. Ideally assessment should not be connected to WikiProjects at all, but we certainly should not delete the working infrastructure just because a project seems dormant. —Kusma (talk) 23:08, 22 January 2023 (UTC)[reply]
• Weak oppose, I guess. The inactive project banners give the impression that the project assessments are not being maintained because the associated project is inactive and have therefore been deactivated. This is silly, as normally, quality assessment and other banner flagging (such as needing infoboxes or images) is updated for all project banners by an editor who usually has nothing to do with any of them, and often this editor will make the importance assessment too, even though they're usually just guessing based on what the article says about its topic. With a couple of exceptions, such as WP:MILHIST's A-class reviews, messing with the project banners is not a project-related activity. Consequently, WP banners for inactive projects are pretty much redundant, unless the goal is to use the inactive projects' banners as a proxy for "Article condition by topic" categories, in which case I think the correct way to move forward is re-open that functionally fully and retire {{WPBannerMeta/inactive}}. —Compassionate727 ^(T·C) 04:24, 23 January 2023 (UTC)[reply]

  We could convert project templates that use {{WPBannerMeta/inactive}} to instead use {{WPBannerMeta|inactive=y}}. But the main assumption is that if an article has been assessed, there is no reason to drop the quality and/or importance assessment when the project goes inactive. I imagine some projects sporadically become inactive and later become active again. If a project is deleted, that is a different question. Aymatth2 (talk) 15:08, 23 January 2023 (UTC)[reply]

  Unless the parallel discussion on VPI is successful :) — Martin (MSGJ · talk) 15:18, 23 January 2023 (UTC)[reply]

  As someone who does a fair number of quality assessments, I don't really treat it as a Wikiproject activity. And since all the projects mostly use the same scale, I'd support just creating a global assessment system (with importance remaining within WikiProjects' domain). —pythoncoder (talk | contribs) 02:50, 24 January 2023 (UTC)[reply]

  @Pythoncoder that is exactly what we are discussing at Wikipedia:Village pump (idea lab)#Project-independent quality assessments. If that passes this whole proposal is moot — Martin (MSGJ · talk) 12:38, 25 January 2023 (UTC)[reply]

  Not really because importance parameters still continue to exist for most projects. And no proposal has been floated to deprecate them yet. —CX Zoom[he/him] ^{(let's talk • {C•X})} 18:24, 25 January 2023 (UTC)[reply]

  A rating for how important an article is to an inactive/defunct project? That would be absolutely useless information, unless the project is revived — Martin (MSGJ · talk) 19:28, 25 January 2023 (UTC)[reply]

  @Compassionate727 I am not sure I understand why you oppose this? For me, per the reasons explained at the Wikipedia:Village pump (miscellaneous)/Archive 73#Improper_handling_of_assessment_for_inactive_WikiProjects, one of the main issues is that the current way we are doing so consings numerous, perfectly fine assessments, to oblivion, as soon as a project is declared inactive. For articles for which this was the only banner present, those assessments become removed from the assessment scheme and the the page will now show as unassessed in the assessment scheme (see links in my comment a bit above). Any solution to fix this glaring error is a step in the right direction, no? _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 04:50, 25 January 2023 (UTC)[reply]

• Weak support, but the third banner is my personal favorite as it both addresses the presence of the WikiProject and preserves its older ratings. It would be nice, however, to see when the WikiProject was declared inactive. InvadingInvader (userpage, talk) 21:49, 31 January 2023 (UTC)[reply]

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

  @MSGJ: I think it includes articles with an active project but not assessed. E.g. Talk:9th Annual BFJA Awards- Aymatth2 (talk) 16:56, 28 January 2023 (UTC)[reply]

  It's only looking for banners of the form {{WikiProject... - a rather crude search with many false positives. Probably not worth keeping unless I can improve the regex — Martin (MSGJ · talk) 20:49, 28 January 2023 (UTC)[reply]

• Support, assessing is a lost art, and mostly ignored even in active WikiProjects. Abductive (reasoning) 08:44, 29 January 2023 (UTC)[reply]
• Support. Just like Abductive, I've seen plenty of active WikiProjects where the assessments are woefully out of date. People tend to remove assessments from talk pages for projects with inactive banners; but let's say I want to revive a WikiProject, or turn it into a task force; do I now need to manually reassess thousands of articles? It's silly. DFlhb (talk) 09:23, 29 January 2023 (UTC)[reply]

  People remove assessments from talk pages for projects with inactive banners? I've not seen this, and I'm not sure why anyone would do this. CMD (talk) 18:24, 31 January 2023 (UTC)[reply]

• Comment. It is often the case that members of a wikiproject make edits and improvements in the filed covered by the wikiproject, but whatever method the person who decides to mark it inactive uses to detect activity does not notice these edits and improvements. Thus the inactivity marker is wrong. Jc3s5h (talk) 18:41, 31 January 2023 (UTC)[reply]
• Support Assessments (mostly quality, not so much importance) can still be of value to editors outside of the Wikiproject, regardless of its status. Pinguinn 🐧 10:29, 3 February 2023 (UTC)[reply]

  If an article already has active projects containing assessments, is there any benefit in adding the (duplicate) assessment of an inactive project? — Martin (MSGJ · talk) 10:45, 3 February 2023 (UTC)[reply]

  Only if the assessments would differ, which can occasionally happen with quality but is far more common with importance. Pinguinn 🐧 11:37, 4 February 2023 (UTC)[reply]

• Oppose along the same lines as Compassionate. Having inactive values displayed (you could sell me on categorized) is inevitably makework for the users who come along and find assessments differ between projects. One might call these nuisance edits (because we shouldn't have to make them), as we maintain a system that there are even people who have considered tearing it down entirely. Izno (talk) 21:15, 4 February 2023 (UTC)[reply]
• Support per all the lengthy discussions we already had at WP:VPM and earlier, where I was a participant. Let us not lose all the assessment data, which makes it incredibly difficult for (a) new interested editors to reactivate a project, and (b) statisticians to find where Wikipedia is putting out our best and needs more attention. —CX Zoom[he/him] ^{(let's talk • {C•X})} 16:54, 7 February 2023 (UTC)[reply]
• Comment I would say the "supports" have it. If the proposal below, #Project-independent quality assessments is accepted, this change could be implemented at the same time. That would alleviate the concerns of the two "opposes", since quality ratings would generally move up into the {{WikiProject banner shell}}, maintained for all projects.The iImportance rating does not need much maintenance: if the subject is mid-importance to a project it will generally remain mid-importance regardless of how the article evolves. Aymatth2 (talk) 21:08, 7 February 2023 (UTC)[reply]

  Yes, absolutely the proposal below will help immensely. In that case we are not relying on inactive banners to give us anything valuable anymore, right? — Martin (MSGJ · talk) 21:36, 9 February 2023 (UTC)[reply]

• COMMENT I think it should display importance but should suppress quality display. The quality would not be updated unless there is some other wikiproject also signed on to the page. The importance would usually not change much unless some drastic event happened in the real world. However quality shifts with editing. -- 64.229.90.199 (talk) 03:22, 8 February 2023 (UTC)[reply]

  Who actually cares what importance an article is to an inactive project? That rating is of use to that particular project alone, and does not reflect importance of the article generally. — Martin (MSGJ · talk) 21:29, 9 February 2023 (UTC)[reply]

  People may care about the importance of a topic to a topic area, which is represented by proxy via the wikiproject that is aligned with the topic area. This may spur them to improve higher importance articles, or even revive the project. When I say suppress display of quality, I still think they should be categorized, to maintain banner functions, just not displayed in the banner. -- 64.229.90.199 (talk) 05:16, 11 February 2023 (UTC)[reply]

• Oppose The assessment and importance information implies that the article's status is being maintained. If the project is defunct, that isn't true. The assessment and importance data can be recovered from the talk page history if the project gets restarted again, so that seems like a non-starter in terms of problems for me. --Jayron32 19:12, 9 February 2023 (UTC)[reply]

  @Jayron32 You are missing a key point: may articles are assessed (maintained...) by people who are not members of the project. I've assed many articles for many wikiprojects without being their member, and I don't see why I shouln't be allowed to do so, nor why should my assessment be blanked once a relevant WikiProject becomes inactive? _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 07:55, 10 February 2023 (UTC)[reply]

  The assessment is not blanked, not is it hidden in the talkpage history. It remains right there in the untouched wikicode. Whether a project is active or inactive has zero bearing on editing its article quality assessment parameter in any particular article. CMD (talk) 08:28, 10 February 2023 (UTC)[reply]

  @Chipmunkdavis But the problem is that right now the assessment is not piped to the aggregate assessment data, as the categories are deleted. We are also loosing information on statistics of past assessmensts. Ex. once Project Foo is declared inactive, the desctruction of the category system means that all of articles that were assessed just by Project Foo revert to "unassessed" in the main stats for how many assessed articles we have, and the table matrix for how many articles Project Foo tagged and how was it assessed is destroyed as well. See example I give in my support vote at the very top. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 05:33, 11 February 2023 (UTC)[reply]

  That's understandable, but the assessment is not blanked. It remains on the article talk page, and high-level category tweaks will be able to immediately pick up on all that existing data if desired. CMD (talk) 05:53, 11 February 2023 (UTC)[reply]

  @Chipmunkdavis Well then, my point is that it is desired and they should do it. Plus, what's wrong with the low-level categories? They hurt noone and were useful. I would like to know what were and are the breakdowns of articles assessed by some defunct projects. Why is that knowledge denied to me and others? _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 06:09, 11 February 2023 (UTC)[reply]

  No, Piotrus, I got that point abundantly it just didn't affect my vote on this proposal. See the vote below, however, for perhaps a more relevant view of what I do or don't get about your key point. --Jayron32 15:34, 10 February 2023 (UTC)[reply]

• Support granted a page supported by only inactive projects is going to have its rating checked marginally less frequently, but at the end of the day the error rate isn't going to be dramatically different and if once in a blue moon a project does get reactivated because a new enthusiastic group of editors comes to us then all the better. The whole point of placing quality assessments in the banner shell is that a stub is a stub regardless of which project is assessing, and if we really wanted to we could create a taskforce dedicated to checking all pages that have no associated active project; in fact tools could probaly do most of the work, flagging for review only those pages who's quality rating is suspect. 74.73.224.126 (talk) 19:32, 9 February 2023 (UTC)[reply]

  Isn't that exactly what the proposal below is going to resolve? I agree that all articles should have a rating, but the rating of an inactive project is not going to help much, if there are other banners of active projects on the page. — Martin (MSGJ · talk) 21:31, 9 February 2023 (UTC)[reply]

  The point is that baring certain idiosyncratic rankings (e.g. the MILHIST list stuff) the quality should be the same throughout. It doesn't help much, but it's harmless and potentially beneficial in that it both facilitates reactivation of a project if interested editors emerge and offers a different way to explore content. In the past when I was more active I sometimes sought out low-hanging fruit by looking at WikiProjects covering topics of interest and seeing which high and top importance articles were stubs; usually those were excellent candidates for expansion with sources that were easy to find. I doubt I'm the only one to ever explore content that way, and a project doesn't need to be active for that kind of organization to be helpful. 74.73.224.126 (talk) 04:28, 10 February 2023 (UTC)[reply]

See Wikipedia:Village pump (idea lab)#Project-independent quality assessments for discussion on this concept.

Quality assessments define how close we are to a distribution-quality article in terms of completeness, organization, prose quality, sourcing, wikilinks etc. Most projects follow the general guidelines at Wikipedia:Content assessment, but some large projects have specialized assessment guidelines. This is to propose adding a |class= parameter to {{WikiProject banner shell}}, which can display a general quality assessment, and letting project banner templates "inherit" this assessment. {{WPBannerMeta}} will look after the details, so the project banner templates will not have to change.

Projects with specialized quality assessment approaches, which will be recognized by {{WPBannerMeta}} using a new |QUALITY_CRITERIA=custom parameter, can continue to record these assessments on their project banners and link to their specialized quality assessment scales.

Importance assessments are project-specific, showing how important the article is in providing complete coverage of the project subject area. An article may be high importance for one project, low importance for another, and irrelevant to most projects. This proposal does not affect importance assessments.

Banners using article-level general quality assessment are illustrated below:

• {{WikiProject banner shell}} may now accept, validate and display an optional |class= parameter as shown above.
• {{WikiProject banner shell}} may be added to an article talk page with no wikiproject banners, in which case it will populate a general category like Category:C-Class articles
• If a new {{WPBannerMeta}} parameter |QUALITY_CRITERIA= has the value "custom", the project class will be displayed and used to create categories as at present. The project class will be displayed even if it is the same as the article class. Projects will be canvassed to set this parameter if they want to use custom quality assessment criteria.
• Otherwise, the project is assumed to follow the general assessment approach, which is true of most projects today
  • {{WPBannerMeta}} will retrieve the article-level |class= value (if present) using:

    {{Template parameter value|{{FULLPAGENAME}}|WikiProject banner shell||class}}}}

  • If no article-level class value is found, the wikiproject banner will be processed as at present
  • If the wikiproject banner does not supply a |class= value to {{WPBannerMeta}}, or if it supplies a value the same as the (non-blank) article-level class, the class will not be shown in the project template, since that would be redundant. The article class will be used to form categories like Category:C-Class Linguistics articles
  • If the wikiproject banner supplies a class value that differs from the (non-blank) article class value, the talk page will be placed in a tracking category and the project class will be used to form categories like Category:C-Class Linguistics articles
• A future project may consider bulk change to remove |class= values from wikiproject banners where the value is the same as the article level class, and where the wikiproject uses the general Wikipedia:Content assessment approach. That is outside the scope of this proposal.

Project-independent quality assessments comments

Comments? Aymatth2 (talk) 17:58, 6 February 2023 (UTC)[reply]

• @Aymatth2, it might be worth notifying major WikiProjects, especially ones with non-standard assessment criteria. — Qwerfjkltalk 18:08, 6 February 2023 (UTC)[reply]

  Not sure how to find active WikiProjects - perhaps the top 50 from Wikipedia:Database reports/WikiProject watchers? — Martin (MSGJ · talk) 18:24, 6 February 2023 (UTC)[reply]

  The first on the watchers list is inactive! But I will start working through the active projects on the list. Aymatth2 (talk) 18:33, 6 February 2023 (UTC)[reply]

  I'm a bit confused as to what this is proposing. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 20:29, 6 February 2023 (UTC)[reply]

  It is a way to put a general assessment of an article quality at the top of the article talk page, and let the project banners "inherit" that assessment. It saves space on the page, and makes it easier to update the general assessment. Projects can opt out and use specialized ways of assessing articles if they prefer. Aymatth2 (talk) 16:06, 7 February 2023 (UTC)[reply]

  Oh ok. Thanks for clarifying. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 20:42, 7 February 2023 (UTC)[reply]

• Strongly support. This is a long-overdue simplification. There's no need for article-class to be project specific, when the assessment criteria are overwhelmingly not project specific (with a handful of notable exceptions). I especially like the fact that MILHIST can continue using its own assessment standards. I'll also note that this approach has been done on French Wikipedia for more than a decade, and always felt more "modern" to me. DFlhb (talk) 18:21, 6 February 2023 (UTC)[reply]
• Very strong support from me too. This will simplify talk pages and reduce redundancy. — Martin (MSGJ · talk) 18:25, 6 February 2023 (UTC)[reply]
• Strong support. The current quality assessment structure is an overly-complicated mess; the fact that there are individual assessments given for each project is just one of many ways. The vast majority of projects just copy-paste the generic criteria into their project space, which adds no value. Those with legitimate reason to continue to maintain their own criteria (for example: Wikipedia:WikiProject Highways/Assessment specifies A list of the road's junctions and landmarks, if appropriate), can still do that. -- RoySmith (talk) 18:35, 6 February 2023 (UTC)[reply]
• Strong support. I think this is a great improvement. Updating assessments will be quicker for editors (change once, rather than for each project). The banner looks good and communicates clearly. Schazjmd (talk) 18:39, 6 February 2023 (UTC)[reply]
• Support. Seems like an obvious change to centralize something that's almost universally the same across WikiProjects. Practical considerations: It might also be worth considering how this would affect the WP:RATER tool and whether this should affect Template:Vital article. Thebiguglyalien (talk) 19:06, 6 February 2023 (UTC)[reply]
• Support iff the ability of certain WikiProjects to choose their own assessment is retained if they so desire. But there are many that don't seem to care and there's no need to make those projects assess everything. --Rschen7754 19:09, 6 February 2023 (UTC)[reply]
• Support as the best of both worlds: a default which should pool resources well, with the facility to opt out when necessary. Certes (talk) 20:08, 6 February 2023 (UTC)[reply]
• Support, right now there's generally no difference between different project's ratings, so it's superfluous to mark it in each template. I hope, though, that the technical implementation allows for easy per-project overrides; the video games project, for example, stopped using A-class 8 years ago, so it would be convenient if the template would put those articles into the GA-class video games articles category automatically instead of the deleted A-class one if another project wants to mark an article as A-class. --PresN 21:00, 6 February 2023 (UTC)[reply]

  The categorisation should not be affected by this proposal at all — Martin (MSGJ · talk) 21:05, 6 February 2023 (UTC)[reply]

• Support with an opt-out for projects that have their own criteria. I also propose integrating things better with tools like Rater.js, which makes assessment and proper tagging much easier. SounderBruce 21:25, 6 February 2023 (UTC)[reply]
• Support, strongly. Fundamentally, having each project evaluate an article independently is a fork, generating significant additional work for essentially no benefit. I would further support an opt-out implementation, in which projects are assumed to be okay with the project-independent assessment unless they specifically request to have their own system. I have mixed feelings about whether any projects should be allowed to have their own system. But this is unquestionably a good step along the path to unification. {{u|Sdkb}} ^talk 21:27, 6 February 2023 (UTC)[reply]
• Support: this aligns with common practice, where an article is rated the same class across each project banner, even if the editor who makes this assessment is only a member of a proper subset of those WikiProjects. I think things like Milhist's BL-class are reasons for allowing projects to have custom assessments, not because this is how you'd design a system from scratch but because there are active communities that find these ratings helpful. — Bilorv (talk) 21:36, 6 February 2023 (UTC)[reply]
• Support - I think this is a good idea as long as WikiProjects with their own more specific assessment scales are allowed to retain them, such as WP:USRD/A and WP:HWY/A. Dough4872 21:55, 6 February 2023 (UTC)[reply]
• Support – This seems like a sensible simplification, and a reflection of how (in my experience) assessments work. I don't think any project I'm involved in uses project-specific criteria, but it's good to keep the opt-out (which, as I read it, is there in the proposal) for projects that do. Robminchin (talk) 22:02, 6 February 2023 (UTC)[reply]
• Support – I think this is a good change per above, and WikiProject-specific ratings could still be kept. Additionally, it solves the issue of topics that do not fall under the scope of any WikiProject not having a class assessment. DecafPotato (talk) 23:54, 6 February 2023 (UTC)[reply]
• Support I don't see how article quality would vary like importance does, so this seems like a pure upgrade to me. I've never really seen an instance of quality differing across projects. ᴢxᴄᴠʙɴᴍ (ᴛ) 00:47, 7 February 2023 (UTC)[reply]
• Strongly Support – This proposal does a lot in an elegant way! I firmly believe this consolidation opens up an easier learning curve for newer editors: We can get comfortable with "the standard" in an incremental way, without always being pulled by multiple (competing? hard to understand?) WikiProjects. Further, as a mobile view reader and editor, I appreciate anything that 1) means less code overall for my thumbs to screw up and 2) clears up space on my tiny screen. Happy, happy all around. — LumonRedacts 01:18, 7 February 2023 (UTC)[reply]
• Support with an opt-out if a project wants it as mentioned above. –Fredddie™ 01:20, 7 February 2023 (UTC)[reply]
• Strong support, long overdue. CMD (talk) 01:30, 7 February 2023 (UTC)[reply]
• support--Ozzie10aaaa (talk) 02:33, 7 February 2023 (UTC)[reply]
• Support, definitely. Abductive (reasoning) 04:15, 7 February 2023 (UTC)[reply]
• Support, standardization is good. EpicPupper (talk) 04:42, 7 February 2023 (UTC)[reply]
• Comment I can see the advantages on this, with articles rated B or better being the minimum acceptable standard for DYK and ITN. The criteria do differ slightly from those that the MilHist Project is currently using. The main differences are criterion 5, where we require an infobox or images (not hard to do), and 6, which we rejected years ago. I trust that everyone understands that classification up to B is handled by our MilHistBot, so that if this proposal passes, then the MilHistBot will assign a global assessment whenever the article falls under WP:MILHIST (with criterion 6 being always assessed as true). Hawkeye7 (discuss) 05:48, 7 February 2023 (UTC)[reply]

  @Hawkeye7 I don't know what they do at ITN, but I can assure you, having a B rating or better is not a DYK requirement. All we require in the way of quality assessment is that the article isn't a stub. -- RoySmith (talk) 14:52, 7 February 2023 (UTC)[reply]

  @RoySmith: DYK Supplementary Rule D2 requires that the article be fully sourced, which is required of a B class article or better. Hawkeye7 (discuss) 18:59, 7 February 2023 (UTC)[reply]

  All articles that rate B or better will meet D2, but there's a lot of other things that B requires which DYK doesn't. -- RoySmith (talk) 20:05, 7 February 2023 (UTC)[reply]

  True, but note that DYK already has certain requirements: A1 requires a 1,500 character minimum, and D7 requires and article "to be complete and not some sort of work in progress". It is likely that if this proposal for project-wide classification is accepted, there will be a proposal to set the bar for DYK articles at B class. It is pretty much the minimum acceptable standard now anyway. Hawkeye7 (discuss) 00:26, 8 February 2023 (UTC)[reply]

  While I've for a while been a member of the "assessments don't matter" school of philosophy, I feel compelled to point out that an article can be fully sourced without meeting other B class requirements such as comprehensiveness, and that doesn't disqualify an article from DYK eligibility. Trying to require all DYK submissions to be B class is also a non-starter when different projects have very different requirements for what B class means. Trainsandotherthings (talk) 16:14, 8 February 2023 (UTC)[reply]

  Start-class articles that are fully sourced but not broad enough in their content coverage are allowed to run at DYK. I think this is a good thing; DYK isn't a mini-GA review, nor should it be. People who produce a good number of well-referenced C-class articles that fail B-class only for their breadth of coverage provide substantial value to the encyclopedia, and we need some system to reward creators while evaluating that sort of work (which is what DYK functionally is). — Red-tailed hawk _(nest) 16:56, 8 February 2023 (UTC)[reply]

  Theoretically yes, but in practice articles that are fully referenced but fail one of the other B-class criteria are quite rare. Hawkeye7 (discuss) 22:49, 8 February 2023 (UTC)[reply]

  Agree (with everyone except Hawkeye7); this will never fly. Except for the GA ones, very very few DYK articles are assessed as B (although I think we have a general problem of under-rating in assessments). I'm appalled that Milhist seem (per Hawkeye7) to insist on an infobox for B-class. This should never be done. There's no chance of this being accepted at DYK. Johnbod (talk) 19:05, 8 February 2023 (UTC)[reply]

  I may have misled you. Our B5 criterion requires that an article "contains appropriate supporting materials, such as an infobox, images, or diagrams." My own article on Singapore strategy (for example) does not contain an infobox. Hawkeye7 (discuss) 22:49, 8 February 2023 (UTC)[reply]

  Phew! Glad to hear it. Johnbod (talk) 05:18, 9 February 2023 (UTC)[reply]

  From the Wikipedia:Content assessment/B-Class criteria, I can say that B1 is enforced at DYK (DYK's rules are possibly a bit more strict). The similarities do kind of end there, though: bolded articles regularly fail B2 and B5. B3, B4, and B6 are... not requirements per se, but there are a lot of cases where a reviewer rightfully wants the nominator to take the article vaguely in that direction if it's too far away, and DYK will generally uphold those requests. I mean, you could make the case that all DYK articles are B-class if you stretch them broadly enough, just because of how much hedging this guideline does. theleekycauldron (talk • contribs) (she/her) 10:09, 9 February 2023 (UTC)[reply]

• Support – While |importance= can vary by project, |class= is one parameter that should be universal across the board. InfiniteNexus (talk) 06:22, 7 February 2023 (UTC)[reply]
• Comment French Wikipedia does this, project independent quality setting with project dependent importance, I support this. I think this should be done as a general quality assessment, while each project should have a separate topic specific quality assessment for the topic area of each wikiproject, which generally would not be the same until it reaches A-class or FA-class, where all assessments would need to reach A-class or FA-class to meet that level. -- 64.229.90.199 (talk) 06:25, 7 February 2023 (UTC)[reply]
• Support, yes please. Some projects will probably also want to simplify their criteria (WikiProject Germany has a B-Class checklist but doesn't have the manpower to use it properly); I guess projects should explicitly opt out of using the standard rating scale. —Kusma (talk) 09:12, 7 February 2023 (UTC)[reply]
• I wouldn't shy from opposing this if I felt it deserved it just because 20-odd users all voted 'support' before me, but there's a good reason for that; this is a very sensible improvement, and it does deserve it. It's got my Support, too. I'll have to go find some other Rfc where I can buck the trend, but this is not the one. Mathglot (talk) 10:10, 7 February 2023 (UTC)[reply]
• Support Absolutely. I've same reply InfiniteNexus as above. Articles and individual projects can have their own requirements if need be, but a general guideline would suffice — DaxServer (t · m · c) 15:16, 7 February 2023 (UTC)[reply]
• Support Almost all articles I see have the same assessment for all wikiprojects anyway so this makes sense Terasail^[✉️] 17:01, 7 February 2023 (UTC)[reply]
  • Some editors just unify the quality assessments across wikiprojects... so that isn't a proper indication of individual topic-area-specific quality (as opposed to general article quality) on Wikipedia right now; unless it's a few missing classes (ie bottom/low/C/A) that some projects have that others don't -- 64.229.90.199 (talk) 03:26, 8 February 2023 (UTC)[reply]
• Strong support May we also standardise the "This article has been checked against the following criteria for B-Class status" from Template:WikiProject Film?--LaukkuTheGreit (Talk•Contribs) 18:45, 7 February 2023 (UTC)[reply]

  Can we save that discussion for later please? Baby steps ... — Martin (MSGJ · talk) 20:20, 7 February 2023 (UTC)[reply]

• Support - Crying tears of joy. This will save untold hours of manpower. Support per User:DFlhb. Schierbecker (talk) 19:13, 7 February 2023 (UTC)[reply]
• Strongest support possible This will make things so much easier. And some wikiprojects seem to not have some levels of criteria, leading to articles being rated as, for example, Start Class and C class at the same time. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 20:46, 7 February 2023 (UTC)[reply]

  A better example is that some projects still don't have Redirect-class or Disambig-class, which are shockingly still considered "Non-standard grades" (I'll propose standardization posthaste on WT:Content assessment). But newbies who don't use the Rater tool would never know it, and would be confused why 3 projects say "Redirect", and one project says "NA". DFlhb (talk) 21:22, 7 February 2023 (UTC)[reply]

• Question How will this affect the unassessed article categories? eg. Category:Unassessed military history articles Will they still be correctly populated? Hawkeye7 (discuss) 00:15, 8 February 2023 (UTC)[reply]

  An interesting question, including the issue of what is "correct". I think the default should probably be that articles are in the "unassessed" categories if the main banner doesn't have an assessment. It shouldn't be too hard to code a category for articles that have a global assessment but not a local one (if the banner says B-Class but the checklist hasn't been filled out, perhaps you would prefer to be in an "unassessed" (or perhaps "half-assed" or something) category for MILHIST). —Kusma (talk) 09:28, 8 February 2023 (UTC)[reply]

  For projects that opt out, presumably including military history, the article will be categorized as unassessed if the project banner does not have an assessment. For other projects, if there is also no article-level assessment. Aymatth2 (talk) 14:43, 8 February 2023 (UTC)[reply]

  Speaking now as the project's lead coordinator, I am not presuming that at all; discussion is ongoing, and if the proposal passes, I will put it to the project for a vote. But this is a make-or-break criterion. We are not talking about merely changing {{WikiProject banner shell}} ! Every project that opts in will require changes to {{WikiProject banner shell}} and to its own project banner template in order for this proposal to work. We must know how many and what articles are covered by the project and what their classifications are. Unless we have a volunteer to preform a great deal of work, I strongly recommend that this be "opt-in" and not "opt-out", as someone from each project will have to work on the template. Start with {{WPBannerMeta}}. But {{WikiProject Military history}} does not use it (maybe it should) and I don't know how many projects do or do not. Hawkeye7 (discuss) 22:49, 8 February 2023 (UTC)[reply]

  Opt-in poses a problem since so many WikiProjects are inactive. Couldn't a bot deal with this effectively, avoiding the need for manual intervention? I also agree that Category:Unassessed military history articles should only show articles that have been unassessed by MILHIST (even if the WPBannerShell contains an assessment).

  BTW, I'd strongly support WP:Content assessment being replaced by the MILHIST criteria, rather than the opposite, but would support MILHIST opting-out if that isn't done. Perhaps a discussion on the enWiki-wide criteria should precede the MILHIST vote? DFlhb (talk) 10:28, 9 February 2023 (UTC)[reply]

  The opt-in projects do not have to do anything. As pointed out above, a bot could at some point run through the articles taking out the |class= value for opt-in projects when the same as the article-level |class= value. The opt-in projects could also change their banner templates to stop passing the |class= value to {{WPBannerMeta}}, or this could also be done by a bot, but there is no urgency for such a change. Aymatth2 (talk) 14:58, 9 February 2023 (UTC)[reply]

  The change can be coded within {{WPBannerMeta}} without requiring changes to individual banners templates afaik, except if a project opts-out. Ofcourse, there's no rush. If/when the proposal succeeds, every WikiProject should be given ample time to discuss (de)merits of opting-out and making a decision. I have a proposal on how to move forward, but of course necessary adjustments may need to be made as per the wishes of the stakeholders:

  • If a WikiProject decides to opt out: All of its quality ratings, including unassessed remain independent.
  • If a WikiProject does not decide to opt out:
    • If all banners (of the WPs that didn't opt-out) show same quality rating, run a bot to introduce it directly at the article-level.
    • If some banner(s) are unassessed, but all else^{(WPs that didn't opt-out)} have same quality rating, run a bot to introduce that quality rating directly at the article-level, so the unassessed are no longer unassessed.
    • If banners^{(of the WPs that didn't opt-out)} differ between their quality ratings, categorise them for human review, and assign them a proper class at the article-level.
    • If all banners^{(of the WPs that didn't opt-out)} are unassessed, it remains so, even at the article-level.

  [Slightly unrelated]: I have also seen WP:WikiProject India to have a parameter for last assessment date, which in my opinion should be introduced more globally at the article-level, to have a rough idea of what articles among the millions may have improved/degraded in quality over periods of time. This one probably requires separate discussion, but if it gains support, it would be easier to implement both proposals together. —CX Zoom[he/him] ^{(let's talk • {C•X})} 16:56, 9 February 2023 (UTC)[reply]

  @Hawkeye7, re {{WikiProject Military history}} does not use it (maybe it should) and I don't know how many projects do or do not. see Category:WikiProject banner templates not based on WPBannerMeta. Only 3 WikiProjects don't use it. These should probably all be converted. — Qwerfjkltalk 18:58, 9 February 2023 (UTC)[reply]

  I don't think WP Vital Articles needs to switch, since it's always outside the WPBannerShell, so that leaves two. I'm only decent at template editing, but I'll try to help for the MilHist banner if Hawkeye7 agrees on the change. DFlhb (talk) 19:08, 9 February 2023 (UTC)[reply]

• That is a generous offer. This would need to be carefully tested in the sandbox; the number of articles is large, and the template is complicated. A Bot run may be needed to aid the conversion. Hawkeye7 (discuss) 20:04, 9 February 2023 (UTC)[reply]

• Support long overdue. HouseBlaster^talk 01:13, 8 February 2023 (UTC)[reply]
• weak support as it will make it easier for project assessors. But it is not that important to get right. Graeme Bartlett (talk) 11:35, 8 February 2023 (UTC)[reply]
• Support and hopefully this would include a new tracking category for globally unassessed articles, whether they have a Wikiproject attached or not. Pinguinn 🐧 12:35, 8 February 2023 (UTC)[reply]
• Support Ajpolino (talk) 15:20, 8 February 2023 (UTC)[reply]
• Support This will eliminate a massive "backlog" which attempting to clear manually would be a massive waste of time. Trainsandotherthings (talk) 16:09, 8 February 2023 (UTC)[reply]
• Weak support. So long as there is some ability for individual WikiProjects to maintain individual quality assessments that are uncommon but nonetheless useful (such as A-Class), then I would support this. I do not support giving MilHistBot a veto power over global quality assessments; global quality assessments should be given by the global criteria, and MilHist should be free to separately list its own rating if the WikiProject dissents from the quality assessment performed by the community. That being said, this will save editor time, and I look forward to the implementation of this across EnWiki. — Red-tailed hawk _(nest) 16:36, 8 February 2023 (UTC)[reply]

  I want to assure you that I have no intention of that. This proposal is on that basis of Wikipedia:Content assessment and any project that opts in will need to accept that. Hawkeye7 (discuss) 22:49, 8 February 2023 (UTC)[reply]

• Weak support echoing almost entirely the comment above, it's fine as long as Wikiprojects such as Military History can still set their own classes for only their WP where they disagree e.g. they want A-class, which isn't commonly used, and therefore the general rating should never be A-class. It will benefit articles with many WPs listed, and only half of the WPs have been assessed for quality rating, even though generally it should be the same for all WPs. Joseph2302 (talk) 16:48, 8 February 2023 (UTC)[reply]

  I don't understand why there's a dozen or so comments which assume that there's any doubt as to whether MILHIST can keep its own grading criteria, when that's a fundamental part of this proposal. The WP:VPI discussion that preceded this proposal extensively discussed ways to let WikiProjects retain their own criteria. DFlhb (talk) 16:54, 8 February 2023 (UTC)[reply]

  It may make wikiprojects with their own quality assessment criteria a bit more visible, so an editor making a change to the general assessment may leave it to a project member to change the project assessment. Not sure if that is good or bad. A bot could perhaps be developed to flag articles with wide variants in assessment values such as "stub" in general and "B" for milhist, or vice-versa.. Aymatth2 (talk) 18:06, 8 February 2023 (UTC)[reply]

• Support Looks good, no real concerns with the proposed set-up. 74.73.224.126 (talk) 21:36, 8 February 2023 (UTC)[reply]

I think you can go ahead and implement this; I have removed it from WP:CENT as it's clear enough at this point. ~ ToBeFree (talk) 22:18, 8 February 2023 (UTC)[reply]

@ToBeFree: I think the discussion should be allowed to run a bit longer. Don't want anyone saying it was rushed through. Aymatth2 (talk) 14:58, 9 February 2023 (UTC)[reply]

Would you think the same if all support had been opposition instead? ~ ToBeFree (talk) 18:24, 9 February 2023 (UTC)[reply]

No. If there had been solid opposition there would be no point wasting time. But a weekend editor may identify a roadblock. I would be surprised, but this has waited more than 15 years so a few more days will not hurt. Aymatth2 (talk) 00:00, 10 February 2023 (UTC)[reply]

• Support, I have thought this was a good idea for years. --Jayron32 19:14, 9 February 2023 (UTC)[reply]
• Support with a question: how will this affect the situation of articles that are currently asssed for inactive Wikiprojects only? Will those assessments be automatically restored and piped to the general assessment scheme? --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 05:30, 11 February 2023 (UTC)[reply]

  This is apparently a quite common thing with around 25000 pages impacted according to my quick PetScan. Definitely something that should be considered while implementing. --Trialpears (talk) 13:50, 11 February 2023 (UTC)[reply]

• Support in principle, Will there be any way to see what changes are made relating to a specific project?, like which B-classes get downgraded to C or start and which C or start end up as B? · · · Peter Southwood ^(talk): 14:59, 11 February 2023 (UTC)[reply]

  See my comment above: Special:Diff/1138422273/1138428686. If all projects assign same class, that class will be made the global-class by a bot. If projects differ among themselves, they will be categorised for human review, and a human will decide what happens with it. —CX Zoom[he/him] ^{(let's talk • {C•X})} 15:25, 11 February 2023 (UTC)[reply]

• Support. Long overdue. If there are many ratings per article, there ends up being a de facto/consensus rating anyway, such as what is used in Wikipedia:Metadata gadget. To whoever ends up implementing this, we should consider using the mw:Extension:PageAssessments improvements that were made in recent years, if they haven't been fully implemented. czar 17:58, 11 February 2023 (UTC)[reply]

Hello all. Myself and User:Ser Amantio di Nicolao have been adding 'Use ... English' maintenance templates (e.g. Template:Use British English) to articles that deserve them en masse utilising AutoWikiBrowser, however another admin has suggested that we gain consensus before continuing doing this. I believe the argument against was that it's [neither] necessary or desirable to place that tag on tens of thousands of articles (see this short discussion). A bot was suggested to carry out this purpose, however I believe that the nature of these tags, i.e. garnering context from the article itself, requires a human edit. Neither of us see anything undesirable about adding this maintenance template per se, however we both paused our efforts until some sort of discussion had been had. Any comments on this would be most welcome. Thank you and best wishes. SɱαɾƚყPαɳƚʂ22 (Ⓣⓐⓛⓚ) 19:58, 6 February 2023 (UTC)[reply]

I would tend to agree that these edits are unnecessary, and making thousands of unnecessary edits is undesirable. Unless there has been some kind of editing history on a particular article that would suggest this template is needed, then it is probably better not to add it. PS, I note that it seems to be classified as a maintenance template, but it really is not a maintenance template because no maintenance is required on these articles. — Martin (MSGJ · talk) 20:24, 6 February 2023 (UTC)[reply]

To be frank, I think the problem is with the template. What purpose does the template serve? Perhaps the idea is so discrepancies like a {{Use British English}} article containing "color" (not "colour") are automatically identified, but I'm not convinced that this is worth the wikitext it takes up at the top of the page. There must be a better way to do this. I can't really fault the editors here for adding a tag to applicable articles, but I don't think their actions are useful. — Bilorv (talk) 21:41, 6 February 2023 (UTC)[reply]

I see the value in having an explicit statement that a given variety of English is used on an article when it is not obvious which should be used (Seattle and Tony Blair are obvious, Acre isn't), especially if the article has had to be actively cleaned up from multiple varieties. I think bots can (or at least would have the capability to) standardise in some cases, e.g. adding or removing the spell=us parameter from {{convert}}. Thryduulf (talk) 22:42, 6 February 2023 (UTC)[reply]

Over half the audience won’t care either way, as they are neither British nor American….. ;) —TheDJ (talk • contribs) 00:02, 7 February 2023 (UTC)[reply]

If only there were a way to make everyone happy. There could be a setting in your preferences asking what your preferred ENGVAR is and words like col(o|ou)r, defen(se|ce), etc. were templated to conform to your ENGVAR regardless of the topic's ENGVAR. Number templates could default to lakh and crore instead of thousands and millions for our Indian readers. To me, that is more useful than slapping {{Use British English}} on top of a page. –Fredddie™ 01:13, 7 February 2023 (UTC)[reply]

Not a bad idea, but only if it could be done via some widget or script in your browser, and not if it's visible in the Wikicode, which would pollute the code in a way making it harder to maintain, and likely would have other knock-on effects. Mathglot (talk) 02:02, 7 February 2023 (UTC)[reply]

Because of things like torch/flaming torch/flashlight, or truck/bogie, it's difficult to do an automated straight substitution without additional markup in the source text in some fashion. Variations like "licence/license" are tricky too, since the spelling depends on whether or not the word is a noun or verb. isaacl (talk) 17:40, 7 February 2023 (UTC)[reply]

Years ago we had a system (date preferences) in which you could set the format in which dates would be shown in your preferences. It required that all dates be wikilinked in a specific pattern. It was deprecated because it was clumsy, and only worked if you were logged in. Remember, users who are not logged in (most of our readers) do not have preferences available. Donald Albury 02:08, 7 February 2023 (UTC)[reply]

If the only downside is that "it doesn't work for IP users", then I think that's not a major problem. IP users already miss out on all sorts of benefits, and it's by their own choice. If they are "forced" to view articles in whatever the default English is, I would say that is extremely minor inconvenience. Specifically: implementing Fred's idea would not make any IP user's viewing experience worse than it is now; it would only improve the experience of other users. I don't see a downside to this. Mathglot (talk) 02:15, 7 February 2023 (UTC)[reply]

It works perfectly on the Chinese Wikipedia, where you do not need to log in to switch between simplified and traditional Chinese (and a few sub-varieties). —Kusma (talk) 09:10, 7 February 2023 (UTC)[reply]

I thought it was deprecated because of MOS:OL and, on the developer side, concerns over cache-splitting. Anomie⚔ 14:29, 7 February 2023 (UTC)[reply]

• Disagree A number of articles have popped up on my Watchlist, with edit summaries saying, "Use Ghanaian English". Now, I'm not surprised that Ghana has its own variety of English, but honestly, that notice on the page does only one thing wrt my editing at the article: it discourages it, and waves me off, since I haven't a clue about Ghanian English, and even if it's pretty close to Commonwealth or some other English, as soon as I have it under my belt, then the next article that hits my list is going to say, "Use Liberian English", and now I'm going to have to start using that? I've got about all I can handle dealing with US, UK, OZ, NZ, Canadian, and Oxford English, and I'm willing to go out on a limb once in a while for a worthy article in Caribbean or maybe Nigerian English. But as for articles in Ghanaian English and Liberian English and Pitcairn English and all the rest, count me out; someone else can go edit those articles in that case; it's more effort than I'm willing to offer. Mathglot (talk) 01:54, 7 February 2023 (UTC) Clarifying: agreeing with the STOP sign from the admin; disagreeing with placing any more of these. Place the bot in reverse, and have it undo all the ones it did. Mathglot (talk) 01:57, 7 February 2023 (UTC)[reply]

  Lol, I thought that was a joke but {{Use Ghanaian English}} is real and is used in 2402 pages, for example Accra added on 29 January 2023. That is beyond crazy. I would like the wikitext to tell me whether to use color or colour (or whether to revert an edit that changed that spelling), but adding stuff like Use Ghanaian English has no point beyond increasing one's edit count. Johnuniq (talk) 02:30, 7 February 2023 (UTC)[reply]

  Not a joke. Most of them have scrolled off my Watchlist but I found this recent one at Kwame Nkrumah. Worse, are these two recent examples:

  rev. 1136291731 at Accra, with the edit summary, "Use Nigerian English" (Accra is the capital of Ghana), and

  rev. 1136292968 at Cape Coast, with the edit summary, "Use Nigerian English" (Cape Coast is a major port in Ghana).

  That's just carelessness. Can someone help me set up an AWB run, so I can place one Trout on Ser Amantio's Talk page for each incorrect edit summary, and a big, golden mega-trout for starting this without consensus? That could be eight thousand trouts, but it's healthy protein, and could help the global supply. Mathglot (talk) 02:45, 7 February 2023 (UTC)[reply]

  I've long wished that the people who have the idea that every country in the world needs to be flagged for its own variety of English would include in these templates' documentation an explanation as to how exactly those varieties actually do vary from American or Commonwealth English when written in an encyclopedic register. I see no need to care about varieties that differ only in slang, or in colloquial registers, or in spoken pronunciation (at least until "SpeakGPT" exists to make natural-sounding spoken versions of articles in an appropriate accent), or the like. Anomie⚔ 14:38, 7 February 2023 (UTC)[reply]

  The issue is that documenting all of the differences would be tedious and no one is interested in doing the work (true for documentation in general). Most of the time this probably isn't a big deal if someone puts "color" or "lorry" into an Australian article there are enough Australian editors that they will be converted to "colour" and "truck" with no documentation needed; there's probably also enough Kiwis around that instances fjord will be converted to fiord without us needing to document that peculiarity of NZ English anywhere. On the other hand I'd be surprised if we had even a handful of regular Ghanian editors so without documentation changes will happen only slowly.

  It's also best to remember that some national varieties of English are tagged separately solely to be polite. There's no functional difference between British and Irish English when written in an encyclopedic register; Likewise for Indian and Pakistani English, but the shitstorm that would ensue from trying to replace all transclsuions of the Irish template with the British one, or the Pakistani one with the Indian one far outweighs any benefit. As a practical matter tools can be instructed to treat the two identically, and it's actually easier for new editors to manually tag correctly per TIES when tag names directly match country names anyway. 74.73.224.126 (talk) 16:14, 9 February 2023 (UTC)[reply]

  I'm not sure that even that isn't a solution in search of a problem. Surely it's better to have sourced content with Us and Zs in incongruous places than to not have the content at all? HJ Mitchell | Penny for your thoughts? 17:46, 9 February 2023 (UTC)[reply]

  Agree, in fact I suspect most pages are not fully MoS compliant, and in general MoS issues are pretty far down the priority list of editorial standards. 74.73.224.126 (talk) 17:56, 9 February 2023 (UTC)[reply]

  I like my articles to look pretty and be neatly formatted and consistent throughout. But most of all I like them to be informative. HJ Mitchell | Penny for your thoughts? 17:59, 9 February 2023 (UTC)[reply]

• Disagree, not seeing what the value of these templates is. The dmy and mdy templates actually have purpose, interacting with the citation templates. The documentation of Template:Use British English says that all it does is add a category, in which case all it does is duplicate the talkpage notices (themselves not always a great use of screen space). CMD (talk) 06:29, 7 February 2023 (UTC)[reply]

  Playing Devil's advocate here a bit: there is a legit value, imho, in having some of them, some of the time: for cases where MOS:TIES doesn't apply but MOS:RETAIN does apply, it's useful to have had someone else go through the article history before me and figure out what the stable usage was at the beginning or has been up till now, so I don't have to figure it out for myself for every article. I wonder if those templates, in articles where there's consensus that they really do help, would work better in an WP:EDITNOTICE, than as a inline template in the article? We don't really need to know what version of English it is, unless we decide to edit it. Mathglot (talk) 10:05, 7 February 2023 (UTC)[reply]

  There is some value some of the time, but that is already provided for by the talkpage templates (which are indeed sometimes put in edit notices). CMD (talk) 15:41, 7 February 2023 (UTC)[reply]

• I think these are mostly make-work edits and aren't helping editors. Unless a page has had a recurring issue that has since been resolved about dialects this isn't helping editors - and may actively discourage casual editors who should be most concerned with adding relevant verifiable content, not which spelling their prose used. Further, most any massive templating shouldn't be done except by a bot - it just annoys watchers and recent change patrollers. — xaosflux ^Talk 14:45, 7 February 2023 (UTC)[reply]
• Deciding on a variant of English to use, and harmonizing a whole article onto it, is good practice when you're trying to bring an article to GA or FA class, but I don't see the point of doing it en-masse. As a side note, while I have no interest in telling anyone what to do, I just don't understand why so much of Wikipedia has turned into menial busywork. Why is it that the vast majority of articles I come across are substantially unchanged from ~2010-2013, save from Wikignoming? Surely article expansion is more rewarding? DFlhb (talk) 19:30, 7 February 2023 (UTC)[reply]

  Exactly. Ppl seem very busy 'standardizing' things to a level that is never achievable (for long) in a public editing model by thousands of (imperfect and untrained) people. It is better to accept certain imperfections and mistakes of the users. It is part of what makes it a wiki. —TheDJ (talk • contribs) 21:58, 7 February 2023 (UTC)[reply]

• Disagree, per Xaosflux. I can sympathise with the intent, but mass changes can very easily become disruptive and there's no pressing need that justifies it in this circumstance. XAM2175 ^(T) 12:33, 8 February 2023 (UTC)[reply]
• No mass addition, although the templates can be useful on a case-by-case basis. Like Mathglot above, if I see "Ghanaian English" I would be quite reticent about touching the article. And FWIW, our Indian articles are generally dreadful, not just for lack of sourcing, but because of the abysmal strings of characters which I understand are supposed to pass for "Indian English". I think the weird capitalisations are mistakes, but they're so predominantly "wrong" (to my USian eyes), that I wonder if there's not actually a system. The grammar, meanwhile, just seems sloppy. Summary: templates are useful, added individually and selectively, but would be even more useful if, as above, there were some clue about what they mean. Stop adding these by bot. — JohnFromPinckney (talk / edits) 14:36, 8 February 2023 (UTC)[reply]
  • We have a long article on Indian English, which in most cases is like British English, but this is a second language to most users, and exists in several registers. Academic Indian prose is virtually the same as British, or intended to be so, but most of our Indian editors aren't academics, and lean towards the colourful Indian form of journalese, just as huge numbers of American editors do towards their local version. Johnbod (talk) 15:49, 8 February 2023 (UTC)[reply]
• No mass addition. Whilst I did appreciate {{Use British English}} being added to 5-10 articles I started (as I usually add them myself), I don't see a general need to add them, particularly when it's not clear to the majority of people what the differences between some of these are. E.g. Despite being English, I'm not really sure what the differences between British, Indian, South African English would be (other than Indian articles might use lakh/crore). Joseph2302 (talk) 16:32, 8 February 2023 (UTC)[reply]
• No mass addition, especially for the more specific variants. I agree with Xaosflux's comments about these are mostly make-work edits and aren't helping editors and may actively discourage casual editors who should be most concerned with adding relevant verifiable content, not which spelling their prose used. Among other things, some of these templates such as {{Use Trinidad and Tobago English}} strike me as not helpful - our article on Trinidadian and Tobagonian English seems to be describing it as essentially a dialect more than a standard variety. I don't think anyone would consider {{Use Southern American English}} to be useful, and several of these strike me as a similar level of over categorization. Hog Farm _Talk 19:41, 8 February 2023 (UTC)[reply]
• Oppose Far too nuanced a matter to use any mass addition method. --Jayron32 14:14, 10 February 2023 (UTC)[reply]
• Insufficient data How is the decision made as to which language template is added?? · · · Peter Southwood ^(talk): 15:13, 11 February 2023 (UTC)[reply]

I have a few basic reasons for proposing this:

1. It can be useful for vandalism patrol, as well as monitoring false positives produced by the title blacklist.
2. I see no reason why someone trusted to view private filters and their logs can't be trusted to view the log of a publicly viewable blacklist. It's not like an EFM will suddenly go rogue and create a bunch of nonsense pages.

137a (talk • edits) 14:48, 10 February 2023 (UTC)[reply]

This seems to be currently a technical matter for the devs. See https://phabricator.wikimedia.org/T68450 --Jayron32 15:32, 10 February 2023 (UTC)[reply]

@137a as noted by Jayron32 this proposal (which would effectively be "Give (titleblacklistlogs) access to group x, group y") is useless. Not even admins who have this permission can see this, because it isn't logged at all. — xaosflux ^Talk 11:13, 12 February 2023 (UTC)[reply]