Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
- Table of contents
- First discussion
- End of page
- New post
Before creating a new section, please note:
- Discussions of technical issues belong at Village pump (technical).
- Discussions of policy belong at Village pump (policy).
- If you're ready to make a concrete proposal and determine whether it has consensus, go to the Village pump (proposals). Proposals worked out here can be brought there.
Before commenting, note:
- This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
- Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.
Discussions are automatically archived after remaining inactive for two weeks.
Redesigning the About page
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)
- Hi, I was wondering if and when I'll get a response to this post. Interstellarity (talk) 15:57, 3 May 2022 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- Views ≢ readership. Phil Bridger (talk) 18:21, 7 June 2022 (UTC)
- 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)
- 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)
comments section
@Interstellarity: I think you have some interesting ideas. how is this proposal going? --Sm8900 (talk) 15:08, 20 May 2022 (UTC)
- @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)
- 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)
- Let's try a format that is readable for all platforms. Just make a normal page. Moxy- 04:10, 23 May 2022 (UTC)
- 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)
- Let's try a format that is readable for all platforms. Just make a normal page. Moxy- 04:10, 23 May 2022 (UTC)
- 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)
- 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)
- @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)
- 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)
Ideas for revisions to Template:Basic information
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)
Section for comments (revision to Template:Basic information)
- 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)- 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)
- 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)
- {{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
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)
- @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)
- 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)
Note on proposal
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)
NEW PROPOSAL
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)
(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)
- 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)
- 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)
comments on new proposal
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
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?
- 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.
- Why it matters: Wikipedians more easily learning how a policy decision was made can:
- Make Wikipedia policies more robust and stable because all the underlying argumentation is accessible to everyone
- 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.
- 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.
- 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.
- Make new proposals or changes to policies much more grounded, constructive, potentially productive, by the proponent and any others being aware of previous deliberations.
- 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.
- 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).
- 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)
- @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)
- @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)
- 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)
- @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:
- This proposal would only apply going forward, so no unreasonably exacting rule is retroactively applied on existing policies and guidelines today.
- 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.
- 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.
- I believe that many pieces of policy are quite stable, and therefore would not suffer from a challenge of "overcitation".
- 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.
- 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)
- @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)
- 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)
- 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)
- @Phil Bridger Agreed, and thank you very much for your comments. Al83tito (talk) 17:20, 6 June 2022 (UTC)
- 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)
- @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)
- I'm convinced that it will be taken as lack of consensus. WhatamIdoing (talk) 19:40, 7 June 2022 (UTC)
- 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)
- @Nosebagbear thank you for your comments. Al83tito (talk) 17:20, 6 June 2022 (UTC)
- @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)
- @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)
- 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)
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)
- @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)
- 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)
- I'm not convinced by the rationale.
- 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.
- 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.
- 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.
- 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.
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
Overzealous archiving
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)
- 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)
- 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)
- 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)
- I think it's best if most pages are set to
- 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)
Sources collecting / Further reading
What is the best way to "collect sources" such as all related and reliable articles from websites? I can use browser bookmarks or user space but my idea is to have a list of sources close to article to use not just by myself but others as well. Personally I don't like "Further reading" section in the article and it can list only few works due to limited space. Is this a good idea to add "Further reading" section at the top of talk page? Maybe Talk:Article example/Sources is better idea (I assume it's less noticeable and may be missed)? What is the best way to arrange such list? Chronological order and division by language or website? It would be helpful especially if Google search not show up all results anymore and search is a lottery by algorithms or page is deleted (in some cases without link you can't find the article in Wayback Machine especially if website has more than 10,000 pages - you can't search in archived version inside of Wayback Machine). It's similar idea to "Reliable sources" section of wikiprojects just more detailed with direct links to articles stick to article/group of articles. Eurohunter (talk) 14:37, 4 June 2022 (UTC)
- {{refideas}}? Jo-Jo Eumerus (talk) 16:28, 4 June 2022 (UTC)
- @Jo-Jo Eumerus: Interesting. Is it good in case if you have 100, 200 or 400 links? Eurohunter (talk) 17:15, 4 June 2022 (UTC)
- Maximum is 21, and I kind of doubt that a list of 100, 200 or 400 links would be of much use. Jo-Jo Eumerus (talk) 18:10, 4 June 2022 (UTC)
- @Eurohunter: See Template talk:Refideas#22 refideas limit. --Redrose64 🌹 (talk) 18:20, 5 June 2022 (UTC)
- @Jo-Jo Eumerus: Interesting. Is it good in case if you have 100, 200 or 400 links? Eurohunter (talk) 17:15, 4 June 2022 (UTC)
- {{refideas}}? Jo-Jo Eumerus (talk) 16:28, 4 June 2022 (UTC)
Gambling section needs a cleanup
The entire gambling section is a mess; the citenotes are filled with spam. The reason for this is that there's good money in spamming your blog all over, since this gets you good SEO, which is the name of the game when you're competing with two entirely undifferentiated skins over the same backend software.
Take the Asian Handicap article, for instance. How do we know that Joe Saumarez Smith coined the term? The only primary sources I could find for it are Vegas Insider and BetAsia, which are both owned by one Joseph S. Smith. And yet this claim has undergone citogenesis, being found all over the web.
Also in the same article, two out of six citations are obvious spam.
I know that in cryptocurrencies, there is a strict moratorium on adding new shitcoins. Why isn't there some rule against adding links to new domains for gambling articles?
98.128.180.201 (talk) 00:55, 6 June 2022 (UTC)
PROD-like function for flagging articles in urgent need of resuscitation
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)
- 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)
- 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) - 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)
- And it should stay impossible for privacy reasons. —Kusma (talk) 13:29, 8 June 2022 (UTC)
- 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)
- 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)
- 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)
- @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)
- @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)
- @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)
- @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)
- 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)
- 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)
- @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)
- @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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- We could probably get a Quarry query to identify aggressively archived
- 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)
- @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)
- 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)
- And it should stay impossible for privacy reasons. —Kusma (talk) 13:29, 8 June 2022 (UTC)
- 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)
- 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)
- 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)
- @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)
- 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)
question re options for threaded group conversations
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)
- @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)
- @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)
- @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)