Redesigning the About page[edit]

Hello, I am currently working on redesigning our about page. I started a draft at User:Interstellarity/sandbox where we can improve on the page and was hoping to get some ideas on how to redesign the page. I welcome anyone to edit my sandbox to improve the page. Interstellarity (talk) 15:40, 30 April 2022 (UTC)[reply]

Hi, I was wondering if and when I'll get a response to this post. Interstellarity (talk) 15:57, 3 May 2022 (UTC)[reply]

To get the discussion started can you explain the background to this proposed change? What issues you see with the current page? BilledMammal (talk) 16:03, 3 May 2022 (UTC)[reply]

Hello @BilledMammal,

The current About page is too long. I would like to make it more user-friendly especially for newcomers since many newcomers aren't willing to read that long of a page. I would like to shorten it like many about pages you see online. Many of the sections can easily be explained using links. Interstellarity (talk) 17:14, 3 May 2022 (UTC)[reply]

This. The current page reads like an article, not where some readers might be looking for out "About" information. — xaosflux ^Talk 15:51, 6 May 2022 (UTC)[reply]

The current page is here. It is pretty obviously far too long, but shortening it will require a lot of effort, as it suffers from the same problem that everything designed by a committee does: everyone wants to keep "their" bit in. Does anyone really think that anyone reads it? I certainly never have until now, and I've been editing for fifteen years. Phil Bridger (talk) 17:11, 6 May 2022 (UTC)[reply]

That’s exactly what I thought, but then I looked the page information and apparently it gets about 20,000 page views a day. I like the redesigned page, we need a simpler layout for it. Bluealbion (talk) 05:34, 15 May 2022 (UTC)[reply]

Yeah, I was about to say that no one even reads this. But then I realise that it has never had less than 10k views in the past 12 months and going as high as 40k views on certain days, averaging 20k daily pageviews. Obviously, a bunch of sections don't really belong to an "About" page. Take the "feedback and questions" section for example. I really like the new, shorter page, but I think some of that 20k daily viewers visit the page to read the sections that are about to be removed. Where do they go now? —CX Zoom[he/him] ^{(let's talk • {C•X})} 06:48, 15 May 2022 (UTC)[reply]

The viewership is because this page is linked prominently on the site UI, in both the site sidebar and (at least in Timeless) the site footer. IznoPublic (talk) 18:40, 28 May 2022 (UTC)[reply]

Views ≢ readership. Phil Bridger (talk) 18:21, 7 June 2022 (UTC)[reply]

comments section[edit]

@Interstellarity: I think you have some interesting ideas. how is this proposal going? --Sm8900 (talk) 15:08, 20 May 2022 (UTC)[reply]

@Sm8900: I’m not sure what you mean by how the proposal is going. Perhaps if I make the change, more people will comment. Interstellarity (talk) 23:00, 22 May 2022 (UTC)[reply]

I see you've done that; good idea. The content is good, but I wonder if a more standard format would be better, as it is quite different from standard article format. BilledMammal (talk) 03:50, 23 May 2022 (UTC)[reply]

Let's try a format that is readable for all platforms. Just make a normal page. Moxy- 04:10, 23 May 2022 (UTC)[reply]

Help:Introduction to Wikipedia is in the format of the proposed About page. It is directly linked to home page and is right here:

Welcome to Wikipedia

the free encyclopedia that anyone can edit. Narutmaru (talk) 09:03, 27 May 2022 (UTC)[reply]

• Hi there ! I think a change like the one are your proposing needs a RfC to get community approval. I personally oppose the change, the original version has more information and gave a better glimpse of what Wikipedia is about. Alexcalamaro (talk) 04:51, 23 May 2022 (UTC)[reply]

  @Alexcalamaro: I respectfully disagree with you. While I'm not against an RfC to get community approval, About pages on many websites tend to be short and sweet. We should not provide more information than what is necessary for an About page to function to its original purpose. If we need to provide more info, we can use links to link to the appropriate page. The original About page is too long and not everyone has the time to read everything about it. We should provide at most 10 paragraphs of what Wikipedia is about so that people are more willing to read it. Interstellarity (talk) 11:59, 23 May 2022 (UTC)[reply]

Maybe we could reframe the discussion as a content v.s. title issue. I mean, the original article could be move to a new one titled "Introduction to Wikipedia" or "Wikipedia overview", and link it from a "see also" section in the "about" article you have created. Alexcalamaro (talk) 12:56, 23 May 2022 (UTC)[reply]

I agree. Narutmaru (talk) 07:52, 7 June 2022 (UTC)[reply]

We should also shift here to somewhere else if we turn the first article to this. I propose "Introduction to Wikipedia Edting" or somewhat to hold the content in here. Narutmaru (talk) 07:56, 7 June 2022 (UTC)[reply]

Ideas for revisions to Template:Basic information[edit]

I would like to propose some changes to Template:Basic information. this is based on valuable feedback and comments that I received on a prior proposal. this new proposal leaves most of the existing template in place. it mainly adds two new groups, at the bottom. I did relocate some links; I have highlighted these by using a label "MOVED" to highlight their new locations.

I welcome any and all comments, feedback, ideas, etc on this proposal. thanks!!

{{User:Sm8900/templates/template basic info two|state=expanded}}

--Sm8900 (talk) 14:35, 20 May 2022 (UTC)[reply]

Section for comments (revision to Template:Basic information)[edit]

• The Help Desk link in "Getting Assistance" is redundant to the "Requests for help" link, which does a better job of explaining which requests go where. Everything in the Research row except the Reference Desk should be in the "Sourcing and referencing row". I fail to see the difference between "Wikipedia community" and "Community groups", and don't understand why the Data section belongs in the latter. I would instead propose:
  • Move the Signpost link to Wikipedia community
  • Move the Wikipedia Library and Resource Exchange sections to Sourcing and Referencing, and add the Library Newsletter inside the parentheses after Wikipedia Library
  • Move the Data section to "About Wikipedia"

The rest would be left as it is in the original template. --Ahecht (TALK
PAGE) 15:08, 20 May 2022 (UTC)[reply]

thanks for your helpful input. Based on your comments, I renamed the section for "Community groups, news" to simply "Groups,news." the existing section for "Community" is for standing resources, under this proposal. the new section for "Groups" would be for group efforts which are intrinsically fluid in nature.

for that reason, the links for news are also included, as the news sources here illustrate new efforts, events and projects being carried out on a continuous basis by the community. the data section fulfils a similar role; it is for fluid databases and resources which provide updated data to reflect current and recent activity and changes in wikipedia.

I feel the two new sections at the bottom are useful as an addition; the point is not topical consolidation, the point is to highlight these resources due to their role as interactive and/or fluid resources for individual editors. the role of the library, the reference desk, etc is to serve as a current resource for current needs. the existing section for "reference and sourcing" highlights links to procedures for referencing, not interactive community resources. so in my opinion, that is why these new sections would be useful. I do appreciate your insightful comments on this. thanks. Sm8900 (talk) 15:14, 20 May 2022 (UTC)[reply]

• I think the organization could use a bit of work. The "information" section, for example, is sort of like a catch all and contains a real mix of stuff, there's reader facing stuff, editor facing stuff, bits of policies and guidelines etc. I would get rid of that section and move the links elsewhere, e.g. I would move the manual of style to the "policies and guidelines" section and delete the duplicate link to the simplified version. Plus it doesn't make a lot of sense to have an "information" section in an "information" template. Do you have a sandbox of this where other people can make changes? 192.76.8.78 (talk) 16:43, 20 May 2022 (UTC)[reply]

  {{ping|192.76.8.78}}, that is an excellent idea. Based on your very helpful comment, I have set up a sandbox at the page below. please do absolutely feel free to edit this in any way that you wish. and to anyone else, I can set up multiple additional sandboxes for anyone else's use; please feel free to let me know, if you wish. thanks!

Sandbox page: User:Sm8900/templates/Sandbox draft template basic info 

Sm8900 (talk) 16:50, 20 May 2022 (UTC)[reply]

Thanks, I'll make some edits in a couple of hours when I get some free time! 192.76.8.78 (talk) 17:00, 20 May 2022 (UTC)[reply]

that's terrific! by the way, I absolutely agree with all of your specific points entirely, in your comment above. please feel free to go ahead and fully make every one of the edits and revisions that you suggest above, to the fullest extent. thanks! Sm8900 (talk) 17:01, 20 May 2022 (UTC)[reply]

Now that we are at 74% using mobile view and only 25% of normal view scrolling to the bottom of the page...these templates are basically not used anymore.....thus dont care about them anymore. That said less is more....I Would recommend trimming of links not more.Moxy- 17:17, 20 May 2022 (UTC)[reply]

@Moxy, I would be totally glad to implement your suggestion to trim some parts of this template. especially since I feel that the grouping of the various pages in the existing template is not necessarily intuitive, or easy to use for the average user, editor, etc. however, i would still want to add the links that i have suggested to add, in my currrent proposal above. I would be glad to consider some other areas elsewhere in the existing template, where the overall size of this template could be trimmed. so if you wish, if you have some existing links in the current template that you think that you might wish to trim, reduce, etc. feel free to elaborate. i do appreciate your comment here. thanks! Sm8900 (talk) 17:22, 20 May 2022 (UTC)[reply]

What, is this happening again? We have had Wikipedia:Village pump (idea lab)/Archive 40#New: Template:Introductory pages for pages helpful as introduction, Help talk:Contents#Proposal for changes to nav box and Template talk:Basic information#Proposal for changes to nav box (possibly more), and I smell WP:MULTI. --Redrose64 🌹 (talk) 22:29, 20 May 2022 (UTC)[reply]

Well, I think I was pretty clear that I had a prior proposal on this item, in my opening comments above, when I said this is based on valuable feedback and comments that I received on a prior proposal. thanks. Sm8900 (talk) 02:26, 22 May 2022 (UTC)[reply]

Note on proposal[edit]

hi all. I am currently working on a revised version of this proposal at the sandbox link above, using some valuable edits provided by the IP User who has commented above. Since one commenter has alleged WP:MULTI on my part, I may try to use this existing section to achieve some kind of consensus for the proposed changes. I will resume discussion once the sandbox version is fully ready for discussion.

just for the record: for my prior initial proposal on this way back, my steps were as follows: (1) I first introduced the idea here at Village Pump for general brainstorming; then (2) I formally proposed the changes at the talk page for this navbox, and then made the changes to that navbox; then (3) the changes were reverted by a highly-respected and experienced editor, who asked me to propose the channges at the talk page for Help:Contents, which I was glad to do. when the proposal did not achieve consensus there, I waited for quite some time, and then came here to offer a totally new and alternative proposal.

In general, I am always open to all comments and viewpoints, on any proposal. I think the whole point of WP:Assume good faith is to reserve any blanket criticism for actual misconduct. any good-faith effort to bring this to the community in a fair-minded, open, and positive way, does not fall under WP:MULTI, even if one disagrees somewhat with any, or even most, of the interim steps; since the whole point of WP:MULTI is to deter people who seek to present a wholly-rejected proposal in a separate forum, without any connection to previous presentations. in the case of a proposal where one venue leads directly and positively to the next one, then any such concerns would be less relevant or applicable.

I truly appreciate the kind attention that I have received here from the community, and the valuable input above. thanks! --Sm8900 (talk) 14:44, 23 May 2022 (UTC)[reply]

NEW PROPOSAL[edit]

I would like to submit the revised navbox below as a new proposal. I have adopted some suggestions from comments here by other editors, as specified below;

• I have withdrawn any proposal to add new sections.
• We have removed over ten links, due to being overly technical/obscure or not needed for new editors. the list of removed links is at this page section.
• As a result of the above, the total size of this proposed navbox is smaller than the existing active version.

I would welcome any comments. Thanks! --Sm8900 (talk) 16:17, 23 May 2022 (UTC)[reply]

(Previous link to draft template: {{User:Sm8900/templates/Sandbox_draft_template_basic_info|state=expanded}} )

just a quick placeholder comment, to keep this talk page section active in order to enable any comments to be made, and to prevent it from being archived prematurely. thanks! --Sm8900 (talk) 13:11, 24 May 2022 (UTC)[reply]

one more reply, just to leave this topic open for feedback for just a little while longer. thanks. Sm8900 (talk) 23:53, 3 June 2022 (UTC)[reply]

ok, this change has now been done.  Done. I plan to discontinue any commments here very soon; however, with this current reply, this talk page section will now remain for at least 14 days from today, in case any further questions or comments may arise. I truly appreciate the help, input, and feedback, of all of the valued fellow members here of our editing community. thanks! Sm8900 (talk) 17:23, 8 June 2022 (UTC)[reply]

comments on new proposal[edit]

section for comments.

Idea: In policies and guidelines, place links to the discussion pages that shaped them -- so all Wikipedians can easily learn of the decision-making processes and rationales behind policies[edit]

Hi everyone.

• The "problem": When you lookup Wikipedia policies and guidelines it is very difficult to find out the decision-making that has shaped them.
  • In other words, there is a lot of deliberation and effort that has gone into shaping those policies, but those deliberations become hard to know about unless you were taking part in them.
    • When I look up policies, I often wonder: What were the pros and cons that were weighed in choosing a certain policy? What were the arguments made? How much support did the final decision get?
• Why it matters: Wikipedians more easily learning how a policy decision was made can:

1. Make Wikipedia policies more robust and stable because all the underlying argumentation is accessible to everyone
2. Conversely, it can also help update some policies by more easily knowing when a policy was decided based on circumstances or arguments no longer applicable.
3. Reduce potentially unnecessary discussions when new Wikipedians not privy to the original decision making repeatedly propose changes that may have been already repeatedly considered previously.
   1. This also helps avoid "biting newcomers" by not having to resort to "shutting down" well-intentioned proposals that seasoned editors from their vantage point see as redundant.
4. Make new proposals or changes to policies much more grounded, constructive, potentially productive, by the proponent and any others being aware of previous deliberations.
5. And maybe redundant but in other words: it creates a more transparent system of institutional knowledge, so that the deliberations and decision-making of earlier generations of wikipedians are visible to later generations of wikipedians.

• Idea: In the policy pages, near specific pieces of them, place small unobtrusive links to the discussion(s) that created or modified them.
  • Further, to be practical, I would propose this apply going forward (new decisions get linked to their policy outcomes), but without requiring reconstructing and linking all past discussions to all existing policies, which I understand would be a near-impossible task (which speaks to the system being opaque in having decision-making and outcomes quite difficult to connect after the fact).
    • And to be clear: I am not positing that the currently the policy-making discussions are completely lost; they do exist deep in the wiki and someone really motivated could dig into the years of history of conversations in the Village Pump to painstakingly reconstruct a specific decision. The point here is to make easy to find them by creating a link between the policy outcome and the policy deliberation process.
• Because this is the idea lab, I am not coming here with a ready-to-implement proposal, but a more general idea/rough draft so get a sense of whether I am going in the right direction with this. What does the community think of the general sentiment? And, do you have any ideas on how to better implement it? Thank you. Al83tito (talk) 18:19, 2 June 2022 (UTC)[reply]

@Al83tito the refernces system can be used, along with the project talk. For example see Wikipedia:Administrators#Notes - is something like that what you are looking for? — xaosflux ^Talk 18:54, 2 June 2022 (UTC)[reply]

@Xaosflux Yes! The footnotes of Wikipedia:Administrators#Notes are a good example, and more specifically footnote #7 links to the discussion where a decision was made. That is indeed a real-life example of what I'd wish we could consistently do going forward. And while somehow first I thought of placing links adjacent to each piece of policy, the footnote system is more natural since we usem them all the time in actual articles.

This certainly sounds like a good idea, if it's not already done for most policies and guidelines, in that it promotes transparency and avoids reinvention of the wheel. I haven't thought about this for long yet, so there may be downsides that I haven't thought of. Phil Bridger (talk) 19:34, 2 June 2022 (UTC)[reply]

• I like the idea, but I am not sure if it is practical. One issue is that most policy and guideline provisions have evolved over time.

A particular provision might have first entered a policy back in 2006 - but it might have been reworded in 2010, tweaked several times between 2013 and 2016, and then reworded again in 2020… etc. Each rewording and tweak has (or should have) a related talk page discussion - and sometimes more than one. So deciding which discussion(s) to link to in the footnotes would be difficult. Blueboar (talk) 00:03, 3 June 2022 (UTC)[reply]

@Blueboar if I understand you correctly you make two points: 1) it is too difficult now to go back in time and figure out all the multiple discussions that led to the shaping and reshaping of a piece of policy. And what I thinks is your larger point: 2) whether looking backwards or forwards, policies typically may be reshaped many times that it is too difficult to track all the decisions points even if we start from this point forward.

And you make good points that those are real hurdles to reckon with. I would like to brainstorm here , after identifying these challenges, if they are surmountable. I have some thoughts about potential remedies:

1. This proposal would only apply going forward, so no unreasonably exacting rule is retroactively applied on existing policies and guidelines today.
2. Wikipedia as a digital encyclopedia has the advantage that the space for footnotes is unlimited and mostly unobtrusive, so that multiple footnotes can be added to a piece of policy as it continues to evolve for a good number of years without creating clutter.
3. By placing in-line citations at the side of each piece of policy (each sentence of paragraph as appropriate), we can keep track of individual decisions at a more granular level. The more granular we go, the less likely is that a small piece within a policy page would be changed so frequently and therefore create a problem of a too-large a cluster of in-line citations.
4. I believe that many pieces of policy are quite stable, and therefore would not suffer from a challenge of "overcitation".
5. Conversely, if some piece of policy undergoes numerous proposals and modifications, I think that makes it all the more valuable to place citations there to point to all the arduous past work done by the editors to come to that policy, and so any additional modifications benefit from the knowledge of all the past deliberations. I think that in the long term it would foster more stability in the rules, and better informed new proposals.
6. And finally this potential a proposal could state that linking to policy bits to discussions would be a requirement only when the modification is significant (not trivial). Editors often make judgement calls on how much or little to reference a claim, for example, so I think this rule would go along those lines.

As I was pondering more about this I realized that another simplified way to put forth this potential proposal is that what this idea is about is extending the core principle of Verifiability to also apply to Wikipedia's documentation on its policies and guidelines. Since verifiability is so central and esteemed in Wikipedia, and we have plenty of experience implementing it through reasonable in-line citations, I think we could find a reasonable way to apply it to the documentation that governs the project.

Thanks! Al83tito (talk) 17:32, 3 June 2022 (UTC)[reply]

@Blueboar: My digging through old archives suggests that the more ancient parts of policies and guidelines tend not to have had extensive or explicit discussions that led to them, which complicates part of what's going on. The more ancient forms of WP:NPOV were (to some extent) created by Bomis employees for NuPedia without apparent extensive community discussion. NPOV is core to Wikipedia, but it's also something that (according to older versions of the page) partly predates Wikipedia itself. — Ⓜ️hawk10 (talk) 18:13, 3 June 2022 (UTC)[reply]

In the early days, most discussions happened off wiki (mailing lists and IRC). Talk pages – the entire concept of namespaces, in fact – did not exist until the English Wikipedia was about one year old; therefore, you will never be able to find an original talk-page discussion about anything that happened in 2001. See mw:Talk pages consultation 2019/Discussion tools in the past for more information. WhatamIdoing (talk) 19:39, 7 June 2022 (UTC)[reply]

• On reading through the comments here I would still support this proposal with the proviso (as should be the case with anything, whether policy, guideline, essay, procedure, or something else) that it should be treated with a bit of common sense. If it cannot be done in a particular instance then don't do it, but I would have thought that in most cases where it could be at all controversial it could be done. Phil Bridger (talk) 18:46, 3 June 2022 (UTC)[reply]

  @Phil Bridger Agreed, and thank you very much for your comments. Al83tito (talk) 17:20, 6 June 2022 (UTC)[reply]

• It's worth pointing out that we already do this, sometimes; see the notes on Wikipedia:Drafts, for example. RfCs and other discussions are also often linked in edit summaries. I think it's a good idea and I don't see any reason why you (anyone) couldn't add more "references" like this, if you find the relevant discussion. Although it's important to bear in mind that it's by design that most of our policies evolved without explicit discussion, and lack of a reference shouldn't be taken as lack of consensus. As Mhawk10 says, some of our most important principles were never formally discussed because they have been accepted from the beginning and shaped subsequent policy. – Joe (talk) 07:44, 4 June 2022 (UTC)[reply]

  @Joe I very much agree that in the policies and guidelines, lack of a reference shouldn't be taken as lack of consensus. Thank you.Al83tito (talk) 17:20, 6 June 2022 (UTC)[reply]

  I'm convinced that it will be taken as lack of consensus. WhatamIdoing (talk) 19:40, 7 June 2022 (UTC)[reply]

  In line with this, I back adding formation and "major change/controversial change" RfCs to the bottom of the policy pages to which they apply (with formation RfCs, that seems to be fairly common for new PAGs these days anyway). I'm not sure I would support adding a reference to each new discussion (assuming it got a discussion). Nosebagbear (talk) 08:34, 6 June 2022 (UTC)[reply]

  @Nosebagbear thank you for your comments. Al83tito (talk) 17:20, 6 June 2022 (UTC)[reply]

• @Xaosflux, @Phil Bridger, @Blueboar, @Mhawk10, @Joe,@Nosebagbear: Thank you all for your thoughtful responses to this idea; they will help it become a better idea. I will ponder on all you have said and I will try to develop a new iteration for your later consideration. Thank you very much. Al83tito (talk) 17:20, 6 June 2022 (UTC)[reply]

  Oh sure, in general, if you see some policies that have some especially important points that were discussed, you can add a reference to a past discussion, but it will take a lot of work to try to find everything. In some cases we document very extensively, but it can also make the text look complicated - see Wikipedia:Requests for comment/Arbitration Committee Elections/ACERFC decisions to date for an example of having almost everything point to a prior discussion. — xaosflux ^Talk 17:39, 6 June 2022 (UTC)[reply]

We have that now.....we can see what changes were made when and all of the discussion history. North8000 (talk) 17:43, 6 June 2022 (UTC)[reply]

@North8000 somewhat, sure the pages have histories - but the discussion that led to a specific revision may not be on the pages associated talk page, or linked to from an edit summary. — xaosflux ^Talk 21:45, 6 June 2022 (UTC)[reply]

For example, I can think of one sentence where the latest rev. took about 500,000 words, multiple RFC, spread amongst multiple archives, plus some at notice boards and Jimbo's talk page. Where would the link to that one go?  :-) North8000 (talk) 22:16, 6 June 2022 (UTC)[reply]

I'm not convinced by the rationale.

1. Make Wikipedia policies more robust and stable because all the underlying argumentation is accessible to everyone – except that Wikipedia:Nobody reads the directions, and they certainly aren't going to read the footnotes in the directions.
2. Conversely, it can also help update some policies by more easily knowing when a policy was decided based on circumstances or arguments no longer applicable – You can do this now. If a page is not giving advice that you believe is helpful and relevant to your situation, you should ask about changes, and you should do this no matter what someone said or thought in the past.
3. Reduce potentially unnecessary discussions when new Wikipedians not privy to the original decision making repeatedly propose changes that may have been already repeatedly considered previously – so long as newer folks are telling us about genuine problems that they're encountering, we want them to tell us about it. We don't want them to give up because it's the fifth time this has been discussed, or because a 15-year-old RFC was summed up in firm language.
4. Make new proposals or changes to policies much more grounded, constructive, potentially productive, by the proponent and any others being aware of previous deliberations – anyone who wants to do that can usually find out by (a) searching the archives or (b) asking the regulars on that talk page. This is a lot of work for limited additional value.
5. And maybe redundant but in other words: it creates a more transparent system of institutional knowledge, so that the deliberations and decision-making of earlier generations of wikipedians are visible to later generations of wikipedians – I agree that it is somewhat more transparent, but it will also have the very negative effect of enshrining our old decisions as The One True™ Decision.

Overall, I think this will discourage editors from updating and adapting policies. It will tend to carve decisions in virtual stone, including decisions that were meant to be experimental or small improvements. I haven't looked up how much experience you have with policy writing (which is hard, and a distinct skillset), but to give you an idea of my vantage point, just between Wikipedia:External links and Wikipedia:External links/Noticeboard and their talk pages, I've probably made more than 2,000 edits over the last 15 years. I think it's a very good guideline, and I think that I am one of the (two) best-informed editors about its contents and history, but I do not think that it would benefit from careful documentation of its history. Some changes I've made to it have been discussed; some changes have not. Some thoroughly discussed changes have been contentious and hotly disputed; some undiscussed changes have been embraced as obviously correct. Some changes we would have to describe as "undiscussed*", because the idea arose from a series of comments or situations, and having resolved individual disputes, I (or others) documented the pattern that we saw developing in these individual discussions.

And this leads me to say: The main source for most policies, guidelines, help pages, etc., is what editors are already doing. The ideal is "After some trial and error, everyone seems to have settled on _____ already, so let's write this down as a convenience for new folks". The ideal is not a major discussion creating rules out of nowhere. WhatamIdoing (talk) 20:05, 7 June 2022 (UTC)[reply]

Sure, but if we have had a major discussion (as we often do), what's the harm in documenting it more clearly? – Joe (talk) 21:06, 7 June 2022 (UTC)[reply]

As I said: "Overall, I think this will discourage editors from updating and adapting policies. It will tend to carve decisions in virtual stone".

If you look at a line in a policy or guideline today, and you think it could be improved, then you might try to improve it. However, if you look at the same line and see ^[1][2][3][4] at the end, then you might decide that it's not worth bothering. You would probably expect someone to tell you that you have to overcome the heavy weight of four prior discussions; you might even tell yourself this story. I would also expect to see made-up rules like "There was an RFC eleven years ago about something in that paragraph, so you have to have an RFC before you can change anything in that paragraph" or "Since a total of 18 editors supported (some aspect of) the current version on those old discussions, then we should assume that all 18 of them still WP:SILENTly oppose all changes, so you have to get at least 27 editors to support your proposal, because 60% approval is really quite minimal for a change to a policy."

The English Wikipedia needs to be able to adapt its policies and guidelines. Wikipedia:Consensus can change, even about policies and guidelines. The overall effect of this proposal is to make it more difficult to make any changes to these pages. That will result in the policies and guidelines not accurately reflecting editors' normal practices. WhatamIdoing (talk) 03:36, 8 June 2022 (UTC)[reply]

I think it's a stretch to say editors care about how many reference indicators are at the end of sentence on a guidance page. We already have endnotes on some policy pages pointing to underlying discussions, and none of these negative effects you are listing have come to pass. (At the recent RfC for sports-specific notability criteria, we got the opposite: the closer used the current-day results to cast doubt on the consensus that had been affirmed repeatedly in the past.) Editors continue to make changes boldly, in the same way they edit articles boldly, even with their endnotes. isaacl (talk) 05:55, 8 June 2022 (UTC)[reply]

Unfortunately, I don't think it's a stretch to say that some opponents of a proposed change would do this. Many editors are unaware that WP:PGBOLD is a long-standing policy, and wikilawyers regularly invent bureaucratic requirements that favor "their side". WhatamIdoing (talk) 15:34, 8 June 2022 (UTC)[reply]

Personally, I think those who resist minor changes are going to do so regardless of the presence of citations. I don't think it should be mandatory to point to the underlying discussions. I see too much time wasted speculating about why a passage was added, though, and so think citations can be helpful to skip ahead and actually discuss the issues at hand to determine current consensus. isaacl (talk) 20:45, 8 June 2022 (UTC)[reply]

It sounds like you're describing the status quo. If you try to change a part of a policy that is based on an RfC or well-attended discussion, you'll be sharply reverted. At least with the footnotes, it's visible which parts are more or less difficult to change. – Joe (talk) 07:07, 8 June 2022 (UTC)[reply]

I think you'll find it's more complicated than that. I can make a substantive edit to a policy or guideline without it being reverted; a newbie can't. I can copyedit a policy or guideline without it being reverted; some others can't. Some of this is skill-based (e.g., I have a pretty solid grasp of English punctuation), and some of it is knowing the our culture and systems (e.g., I know that this fairly obvious edit will someday benefit from a paper trail to protect it from wikilawyers), but some of it is reputation-based: we are slower to revert admins, highly experienced editors, people we know, etc. Even for text that is based on your "RfC or well-attended discussion", some changes can be made boldly and others will require careful negotiations.

My concern with adding documentation is that some editors will be scared off from even attempting to make needed changes, and other editors will resist changes even more than they might now. Right now, if you try to make a change to a core policy like NPOV, it's probably going to be an uphill battle. This proposal will make it even harder than it already is. Is that what you want? WhatamIdoing (talk) 16:02, 8 June 2022 (UTC)[reply]

@WhatamIdoing @User:Al83tito, I'd strong oppose a "inline reference" system for the reasons WhatamIdoing mentioned. On the other hand, I would strongly be in favor of a "Past discussions" section convention which easily provides historic context for how a policy arose, without making any pretense to its validity/relevance. This strikes a balance between allowing users to be bold, and easily making historic context available, should users want to go digging. This is a very nice idea and discussion, thank you for raising it. ~ 🦝 Shushugah (he/him • talk) 11:41, 19 June 2022 (UTC)[reply]

Overzealous archiving[edit]

I've noticed a lot of article talk pages have "|minthreadstoarchive =" set to "1". If you are like me and want your watchlist to be actually remotely useful and not fire hose of ANI replies, you have the "latest edit" filter turned on. This has the unintended effect of hiding any new discussion threads opened on the talk page. That is, if "|minthreadstoarchive =" is set to one, any new topic to a talk page will be obscured from my watchlist when a bot comes by 12 hours later to archive the oldest thread. In my watchlist, I can only see that a bot archived one discussion thread. I cannot see that Randy in Boise has proposed to delete the main page.

I can't think of a legitimate reason for discussion pages to be archived on a one-for-one basis. Solution: "|minthreadstoarchive =" must always be set to ≥ "3". Thoughts? Schierbecker (talk) 00:41, 3 June 2022 (UTC)[reply]

Schierbecker, I think you're expected to exclude bot edits from your watchlist. (which I don't because reasons) But with the "latest edit" filter enabled that won't help IIRC. It bugs me too, but what can you do. — Alexis Jazz (talk or ping me) 04:22, 3 June 2022 (UTC)[reply]

I don't exclude bots either for the same reason as above. My only solution has been to nuke half my watchlist and to check more diligently. Schierbecker (talk) 04:32, 3 June 2022 (UTC)[reply]

I think it's best if most pages are set to |minthreadstoarchive=4. I thought that used to be the default, but it appears that unless you explicitly state more than 1, it will remove all except the most recent. WhatamIdoing (talk) 20:07, 7 June 2022 (UTC)[reply]

I think that in addition to the above, archive bots should mention the topic of the last human post in their edit summary. For pages that only have edits every two weeks, bots should also not archive anything when the most recent human edit is less than a week old. —Kusma (talk) 12:17, 19 June 2022 (UTC)[reply]

I don't think you've thought this through. What if the last human post was talk-page vandalism? I'm sure you don't want that memorialized for all time in the un-editable edit summary. WhatamIdoing (talk) 23:50, 19 June 2022 (UTC)[reply]

Adding a new section already generates an edit summary with the new section title. So I am not so concerned. Can be oversighted the normal way if it is really that bad. Schierbecker (talk) 03:03, 20 June 2022 (UTC)[reply]

I was imagining that the vandal would change an existing section heading, rather than adding a new section. I'm not sure that we need edit summaries that contain vandalism even if they aren't bad enough to oversight. WhatamIdoing (talk) 04:18, 20 June 2022 (UTC)[reply]

Would this not just make the problem happen once every 3 talk posts rather than every new talk section. So you would still miss 1 every 3 posts. This doesn't really fix your issue and will just create longer talk pages since when a section is ready to be archived it will need to wait until another 2 are also ready to archive. This is not a great solution to a minimal problem since it is not arduous to check a talk page which has just been archived by a bot. Terasail^[✉️] 12:42, 19 June 2022 (UTC)[reply]

It may not be arduous, but 98% of Wikipedians don't do it. Very often, new posts to an article or Wikiproject talk page that don't get an answer in the few hours until a bot edit is top of the watchlist will not get an answer for weeks. —Kusma (talk) 12:47, 19 June 2022 (UTC)[reply]

If you have two memory sticks to rub together, I promise the three extra posts on the talk page will not destroy your computer. :) Schierbecker (talk) 03:09, 20 June 2022 (UTC)[reply]

Another option that may be better could be a userscript that detects and shows the summary for the previous edit before the archive in the watchlist? Terasail^[✉️] 12:49, 19 June 2022 (UTC)[reply]

or the last section created.. Terasail^[✉️] 12:50, 19 June 2022 (UTC)[reply]

The problem I want to solve is that others don't see my edits, not that I don't see the edits of others, so I don't see how userscripts will help. —Kusma (talk) 13:01, 19 June 2022 (UTC)[reply]

I'd bet that 98% of editors don't check their watchlists at all. Most editors are inactive. Even among active ones, many don't use their watchlists or even know that they exist. Only 22% of the accounts watching this page have visited Special:Watchlist during the last 30 days, and this is a popular, high-traffic page.

If your problem is that the default prefs setting hides bot edits from the watchlist, why don't you just see about changing that prefs setting to show bot edits? Or to show every single edit separately, so that bot edits can be hidden without the previous edits being hidden? (I personally loathe that style, but it had its supporters while they were working on mw:Help:New filters for edit review – for all I know, they might have changed the default years ago, and we're talking about a problem that only affects old-timers like us.)

It still won't do you any good on a page like Talk:750 Seventh Avenue (number of page views that weren't you or the GA nom during the last month: likely zero, definitely less than six), because almost nobody else is watching that page in the first place, but at least on higher traffic pages, you'd see more. WhatamIdoing (talk) 00:03, 20 June 2022 (UTC)[reply]

My frustration mostly comes from pages like Wikipedia talk:WikiProject Germany having become ghost towns (and I am aware that archive bots making watchlists suck is just a small piece of the reasons for that). There were a few years when topic-related noticeboards and WikiProject pages used to work, but they no longer do. Now the best ways to find people who know something in a topic are what they used to be before WikiProjects: either look through article histories to find experts or to ask in a less targeted place like on IRC or Discord and hope for the best. —Kusma (talk) 13:41, 20 June 2022 (UTC)[reply]

As an aside, I find the "Group results by page" option on the new watchlist system to be a useful compromise (I'm not sure if I first started using it for that reason but anyway) in that it normally has everything on a page collapsed to a single line, but it allows you to see all the edits if you wanted. Alpha3031 (t • c) 13:45, 19 June 2022 (UTC)[reply]

PROD-like function for flagging articles in urgent need of resuscitation[edit]

Given the recent consternation at ANI over the prevalence of PROD and AfD activity, and the use of these tools to nudge articles unsuitable for deletion, I've been wondering if what is really needed is another tool, something far softer than a PROD, designed specifically to coax page improvement. Because, at the moment, a lot of old content avoids the same scrutiny as new content and enjoys, in effect, a double standard.

The use case is this: Say there is an established article that is not suitable for deletion, because it has, say, one good source. However, the article, despite being on the Wiki for more than a decade, is barely a start class, has multiple cleanup tags and is frankly a mess. It says it has two dozen editors watching it, but there has been little or no activity for many years. You are not at all knowledgeable about the subject and it is outside the types of article you are focused on editing anyway. What do you do? Quite possibly nothing, right? But what if we had a different kind of PROD, a much softer PROD of sorts, to stimulate page improvement?

This could, for instance, be a tool to actively hail all of the editors watching that page on their talk page, flagging the poor state and need for maintenance on that page. I think this would be a great first step. The articles could also be automatically fed into a a feed at WP:CLEANUP, much like AfD articles get sorted via a feed. (Not sure if there is some reason why the listing at cleanup isn't already automated by means of a tool-based feed function.) Another feature could be something akin to a PROD, with the function setting in motion a period of, say, one month, where, if no significant cleanup is managed, the article is eligible to be returned to draft.

Anyway, these are just ideas that I'm throwing out. What are people's thoughts? Has anything of this nature been considered or suggested before? Is the idea just totally unworkable? I just see a situation where the volume of content is growing tremendously and a lot of old and often highly degraded content just passes under the radar because so many editors are absorbed dealing with new page reviews and AfDs. But a lot of old articles are actually as bad if not worse than many new page submissions, and, were they submitted today, would clearly not pass AFC and would certainly remain in draft. Iskandar323 (talk) 08:02, 8 June 2022 (UTC)[reply]

I think that there might be some cleanup listings by project around. But there are so many on the list that attention is unlikely. If you post a note on a project notice board about one article you may stir up some help for that one. Graeme Bartlett (talk) 11:15, 8 June 2022 (UTC)[reply]

We already have many such processes: cleanup tags, WikiProject templates that have an |attention= parameter, WikiProject talk pages, noticeboards, user talk pages, pings, etc. They obviously don't always lead to immediate attention—because this is a huge project, people are free to work on what they like, and we have no deadline—and I don't see how a new process like this would be any different. If new articles are getting more scrutiny than old articles, I'd suggest that the problem there is the non-policy-based gatekeeping that has crept into our new page review processes, not the old articles. For example, if AfC is declining drafts that couldn't be sent to AfD if they were in mainspace, then AfC is broken, because it's sole purpose is sifting drafts that aren't like to pass an AfD. – Joe (talk) 11:42, 8 June 2022 (UTC)[reply]

It is technically impossible to send talkpage notifications to users watching a page. Information about who watches a page is not available to any wiki editors, only developers have access to it. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 13:17, 8 June 2022 (UTC)[reply]

And it should stay impossible for privacy reasons. —Kusma (talk) 13:29, 8 June 2022 (UTC)[reply]

However -- that doesn't mean that a means to generate echo notifications to page watchers couldn't happen. It would preserve privacy of the watchers. Would likely need a permission to prevent abuse of such function - and of course people could opt out of that echo type. Thoughts? — xaosflux ^Talk 14:00, 8 June 2022 (UTC)[reply]

Some "generic" types of these are in subtasks of phab:T125653 - but perhaps a "Send free-form notification to all watchers of a page", Allow a short message (edit summary style) - log that it happens publicly, including what the message says (similar to mass message sending), require some permission to do so (that then we could issue to say extended confirmed users, bots, admins). — xaosflux ^Talk 14:06, 8 June 2022 (UTC)[reply]

I think the message should just be posted on the article talk page, and perhaps some people can flag their message as "ping all watchers". We don't need an additional way to send text to people already watching a page where text can be added. —Kusma (talk) 14:13, 8 June 2022 (UTC)[reply]

@Kusma hmm so perhaps what I was thinking above above, but no free-form text - it would just send a notification of the diff? — xaosflux ^Talk 14:26, 8 June 2022 (UTC)[reply]

@Xaosflux: Exactly. This also avoids sending a secret message to talk page watchers without a permanent public record. —Kusma (talk) 14:37, 8 June 2022 (UTC)[reply]

@Kusma in my idea above the message content would have been public, the destinations would have been secret. But this sounds much simpler in any case. I'll try to open a feature request on it soon, but don't hold your breath that it gets implemented without maybe the 2023 wishlist pushing it up! — xaosflux ^Talk 14:43, 8 June 2022 (UTC)[reply]

@Xaosflux, @Kusma: Cool idea, and potentially a good way to leverage existing page watchers. Thanks for giving it your attention. Iskandar323 (talk) 14:52, 8 June 2022 (UTC)[reply]

If I understand correctly, you are proposing there be a logged notification to page watchers of a new diff, without identifying the recipients of the notification? isaacl (talk) 14:54, 8 June 2022 (UTC)[reply]

phab:T310185 yea, log could either be a revision flag (Z = include watcher notification) or a log like (User:Isaacl sent an edit notification to page watchers in edit Diff/x) or the like. — xaosflux ^Talk 14:56, 8 June 2022 (UTC)[reply]

The reason why it could be a useful function is that page watchers are a demographic that at least presumably are marginally interested in the material in the first place, compared to other forms of listing that might target a broader, but more general and less interest-specific demographic. The key advantage of a notification directly to the talk pages of watchers is that for less frequent users the notification would have more permanence and be more likely to generate awareness than a rather more transitory watchlist status update. Iskandar323 (talk) 14:31, 8 June 2022 (UTC)[reply]

The one problem with using their talk pages is that "who is watching a page" is secret, and that would reveal the list. — xaosflux ^Talk 14:57, 8 June 2022 (UTC)[reply]

Yes, I understand now that there's a fundamental privacy problem there. No matter, the less intrusive ping is likely a better idea anyway. Iskandar323 (talk) 15:05, 8 June 2022 (UTC)[reply]

A "ping all watchers" function for talk page messages isn't a bad idea either though - that would obviously also be more 'alerting' than watchlist. Iskandar323 (talk) 14:35, 8 June 2022 (UTC)[reply]

Yes. One of the problems with watching talk pages is that most of our page archiving bots do their best to hide the existence of new threads. Far too many pages have automated archiving even where that does more harm than good. —Kusma (talk) 15:01, 8 June 2022 (UTC)[reply]

We could probably get a Quarry query to identify aggressively archived Talk: pages, and see about removing/slowing archiving from them. WhatamIdoing (talk) 16:05, 8 June 2022 (UTC)[reply]

I don't think we need a new process, we need new people who do the actual work... —Kusma (talk) 13:28, 8 June 2022 (UTC)[reply]

I don't think we need a new process, we need new people who do the actual work.. North8000 (talk) 13:41, 8 June 2022 (UTC)[reply]

We have 3.7 million stubs. Out of all content articles with an assessment (excluding lists), fully 90% are stub or start class. We have lots and lots of ways to say "this is a stub", lots of ways to tag pages for cleanup, lots of ways to try to involve WikiProjects, etc. It's hard to prod people into action based on "this article I just stumbled upon is a more urgent than the other millions of articles on our collective to-do list". There needs to be a better reason (something in the news, a vital article, a core topic, etc.). As someone with a 5-figure watchlist, I would not be up for pings flagging problems with articles on my watchlist -- there are just too many with problems. Fix what you can, tag if necessary, coordinate improvement drives, etc. if you have the time. — Rhododendrites ^talk \\ 17:03, 8 June 2022 (UTC)[reply]

@Rhododendrites: The obvious follow-up to that is: then how would you feel about using such a tool for degraded or neglected vital articles or core topics? Iskandar323 (talk) 17:14, 8 June 2022 (UTC)[reply]

Even if the notification option I suggested gets built above were done, it would certainly be able to be disabled like other notification types. — xaosflux ^Talk 19:02, 8 June 2022 (UTC)[reply]

question re options for threaded group conversations[edit]

is there any way to create or utilize some kind of threaded discussion format, i.e. similar to the internal messaging app that would be available for users of Facebook, LinkedIn, Twitter, etc? I think that maybe that might be highly useful here.

I guess that maybe one thing I am thinking of is having some sort of an in-box for individual messages as well as group meesage threads, available to users here, similar to what a user at facebook would routinely utilize? please feel free to let me know. thanks! --Sm8900 (talk) 17:03, 8 June 2022 (UTC)[reply]

@Sm8900 you may be thinking of something like WP:FLOW. For an example of a page using Flow see mw:Talk:Talk pages project. High-level, it has a bunch of technical problems with the way we use many of our pages. A new set of tools (Wikipedia:Talk pages project) are being worked on right now, and you can enable some in your preferences to try them out. — xaosflux ^Talk 18:59, 8 June 2022 (UTC)[reply]

@Sm8900 I think private group chats are a really bad idea. Wikipedia is fundamentally a very open website governed by consensus, having groups of editors discussing things behind closed doors creates all sorts of problems related to consensus building, distrust and canvassing. For an example of this have a look at the recent guerilla sceptics or wikiproject tropical cyclones arbcom cases which demonstrate many of the problems related to private chat groups. You also have to consider how these private groups will be moderated - who's going to remove illegal or grossly inappropriate content? How do you enforce policies like BLP? How do you stop wikipedia being misused as a free private messaging app by people who have no intention to contribute? We had a lot of issues moderating the semi-private "collections" feature that was introduced a few years back, moderating tens of thousands/hundreds of thousands of private chat groups would be a massive job. 192.76.8.78 (talk) 15:03, 10 June 2022 (UTC)[reply]

@Sm8900 You should have gotten a notification in your inbox that I had replied to you here. The ping notification system and your talk page basically are "some sort of an in-box for individual messages". Also, if you enable the new reply tool feature in your preferences, you will see a link to "subscribe" to individual discussions, so you get notifications whenever someone replies to them. I wouldn't say it's "similar to what a user at facebook would routinely utilize", because Wikipedia is not Facebook, and discussions here serve a different purpose and need different tools. ~ ONUnicorn^{(Talk|Contribs)}problem solving 15:16, 10 June 2022 (UTC)[reply]

these replies are all extremely helpful. I want to take some time to give these some real thought, and then reply further in a little while. thanks! Sm8900 (talk) 16:02, 10 June 2022 (UTC)[reply]

CfD backlog and closing instructions[edit]

We are hosting a discussion of ideas at Wikipedia_talk:Categories_for_discussion#Backlog_reduction to reduce the notorious CfD backlog, and why it is far worse than other XfD pages.

Marcocapelle (talk · contribs) has suggested at Wikipedia_talk:Deletion_process#Attempt_to_make_instructions_for_closing_CfD_discussions_better_readable that one reason for the perennial CfD backlog is that the closing instructions at Wikipedia:Categories_for_discussion/Administrator_instructions are unclear; they have a rewrite drafted at User:Marcocapelle/sandbox2. See the relevant pages for further discussion.

At the main backlog reduction, I have suggested that WP:CFD/W should be reorganized and linked from a more visible place on the main CfD page. A planned feature for XfDcloser seeks to bypass this subpage for closures that can be implemented automatically. –LaundryPizza03 (dc̄) 05:12, 18 June 2022 (UTC)[reply]

• Thank you for posting this here. I should add that the rewrite is not a revolutionary rewrite. One thing I have focused on in particular is to reduce the amount and depth of bulleting, because imho that makes the current text very overwhelming. Other proposed changes are commented in the proposed text. Marcocapelle (talk) 05:25, 18 June 2022 (UTC)[reply]
• Also, if it is useful to move the proposed text to somewhere outside user space, please ping me to let me know to where. Marcocapelle (talk) 05:29, 18 June 2022 (UTC)[reply]

Better coverage of internet addiction related to Wikipedia[edit]

There was recently a thread about this somewhere but I can't find it. It's a bit of a shame WP:ADDICTED only really exists as a humorous page and there's very little helpful guidance or explanation of the topic. What do? What's the best way a serious essay could be written on the topic? — Ixtal ^{( T / C )} ⁂ Join WP:FINANCE! 22:33, 18 June 2022 (UTC)[reply]

Personal censoring as an option for an account[edit]

If you log in, you can select certain kinds of articles that contain material you might consider objectionable. So the article would have a tag or maybe even images would have a tag which would cause them not to be displayed unless you chose to view them. This allows individual users to prevent themselves from seeing material they find objectionable. It doesn't prevent anyone else from doing so.

2600:6C4E:1200:1E85:28F3:C4B0:B9A8:3958 (talk) 14:39, 19 June 2022 (UTC)[reply]

See Help:Options_to_hide_an_image If you create an account, there are several options to hide images. RudolfRed (talk) 19:14, 19 June 2022 (UTC)[reply]

See also m:Image filter referendum/en. Basically, enough people opposed it in 2011 that it's unlikely to happen. The opposes had a variety of reasons; offhand, common objections included:

• Someone would have to tag that.
• If I decide to put an image in an article, then anyone who refuses to look at my picture is violating my sacred free speech rights.
• Nobody will ever agree on which categories to implement, even though everyone knows that sex, disgust, and violence are the main subjects that produce complaints. (Think: stills from porn films, disgusting medical situations, and violent rapes. Complaints about spiders – the usual example given – pale in comparison to complaints about unexpected or unnecessary nudity [from Africa, most of Asia, and the US] or about violence [Europe]. As for disgusting pictures, have a look at Talk:Smallpox. Requests to remove images are probably the single most common question on that page.)
• People should not live in countries (or schools, or families) in which they can get arrested or beaten for having pictures of naked bodies and/or sex acts on their computer screens.
• "Strictly optional" means the same thing as mandatory.

I've written these in a possibly provcative style, but these are not all entirely unreasonable objections. Someone would have to tag the images, and whenever anyone tags anything, we argue over it, and we can expect vandals to abuse it. If you build a system that permits optional blocking, then someone (e.g., a school system) might be able to find a way to make it mandatory. It's a matter of balancing rights, and the editors who participated in that discussion were not generally sympathetic to the readers' rights to read only what they wanted, and many of them were very concerned about ways such a system could fail. WhatamIdoing (talk) 00:32, 20 June 2022 (UTC)[reply]

I remember responding to a similar suggestion a long time ago. The gist of my response was that this is straightforward to implement as an add-on service. Build a system which lets a person view images and apply tags to them, which you then store in your database. You could publish a bit of javascript, perhaps as a gadget so it's easy for people to enable, which gets loaded each time you view an article. The gadget would find all the images, look them up in your database, and do some trivial DOM manipulation to hide the ones which match whatever set of filters the user desires.

This seems like it would fit under the umbrella of WMS Cloud Services, so it wouldn't even cost you anything. You'd need to write the software, but nothing I described is terribly difficult. You'd also need to crowd-source people to do the tagging, but that's how everything works here.

Just because you haven't been able to sell the community on doing it as an official part of the project doesn't mean you can't do it yourself. The hard part (by a long shot) will be finding enough people willing to do the tagging. But at least if you do it as a side project, you and your fellow taggers can agree amongst yourselves on the tagging criteria. I may not agree with your criteria, but nobody's saying I need to install your gadget. -- RoySmith (talk) 00:57, 20 June 2022 (UTC)[reply]

That (the image blocking option described in the help page) works well enough for me. Thank you.

2600:6C4E:1200:1E85:28F3:C4B0:B9A8:3958 (talk) 07:59, 20 June 2022 (UTC)[reply]