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.
Idea: 3RR Bot
A bot that detects potential 3RR problems could work, although the bot might need an advanced algorithm for ruling out self reverts. 0xDeadbeef 05:06, 5 July 2022 (UTC)
- @0xDeadbeef We have User:ProcBot/EW which does what you describe, though it is currently inactive pending a move to toolforge. 192.76.8.85 (talk) 11:46, 5 July 2022 (UTC)
Idea: using JavaScript to display protection icons
A few years ago I wrote a script that automatically would insert protection icons to protected pages. This would completely eliminate the need for the addition and removal of protection templates from an overwhelming majority of pages.
Something similar is already used on Wikidata because for technical reasons you cannot have protection icons on data items. Here, you can have protection icons on Wikipedia pages through the addition of templates (which is okay), but it takes time to add these icons to articles that are protected.
I want to suggest using JavaScript to insert the protection icons into the corner. This would allow for these icons to be added to pages without the need to insert protection templates like {{pp}} or {{protected page}}. It would also allow for the icons to display in the "edit" and "history" modes. Finally, it would allow for the icons to be displayed differently if a user has permissions to edit. In my implementation I have it that if a user has rights to edit or move the page, the protection icons display in the unlocked state. I think this would be helpful so that new users can understand intuitively which pages they are almost certainly able to edit and which ones they cannot edit. Aasim - Herrscher of Wikis 04:38, 7 July 2022 (UTC)
- Awesome Aasim, I think having javascript to display these icons is great, but only when used in addition to protection templates. There are noscript users and bots out there and we can't ignore them. 0xDeadbeef 05:22, 7 July 2022 (UTC)
- Well yeah. I see the templates still a bit needed for categorization of the different protected pages. The goal of this though is so new users can know which actions they can make on a page and which ones are restricted. And about noscript, unfortunately almost all of the web relies on JS to work correctly. Bots can also ascertain that a page is protected through the API, not by screen scraping. All of the protected titles can be viewed in Special:ProtectedPages and Special:ProtectedTitles anyway~ Aasim - Herrscher of Wikis 15:39, 7 July 2022 (UTC)
- Having dynamic page content just to read can be a problem for all sorts of caching, additionally there are pages where for whatever reason we don't want to display an icon on the page. — xaosflux Talk 15:47, 7 July 2022 (UTC)
- I think resolving ancient (and since-renamed) phab:T12347 would be a more valuable expenditure of time. Izno (talk) 18:41, 10 July 2022 (UTC)
Using "Edit distance" instead of "Byte size difference"
Hi, in history pages like https://en.wikipedia.org/w/index.php?title=Main_Page&action=history there is a "Byte difference" in parentheses like
(cur-prev) 15:25, June 17, 2022 Cyberpower678 (talk - contribs) (2,964 bytes) (+3) Undid revision 1093586636 by Cyberpower678 (talk) Whoops. Tested on the wrong page (thank) (Tag: Undo)
Here (+3) denotes "Byte size difference of previous and current edition of this page". I really think that "Byte size difference" is wrong here, and we should show "Edit distance", for example by using Levenshtein distance. Suppose this scenario: someone only changes one word e.g., "on" to "in" in his edit. Here "Byte size difference" says that their difference is zero, because no change occurs in length of strings, but "Edit distance" shows the correct item to to the user, e.g. by Levenshtein distance the edit distance of "on" and "in" is equal to 1. So what should be shown to the users in parenthesis is the "edit distance" not "byte size distance" of editions. Thanks, Hooman Mallahzadeh (talk) 11:23, 7 July 2022 (UTC)
- How do you propose this be reconciled with the page size value (unavoidably in bytes) right before it? It might be that the edit distance would be a more informative indicator in some cases, but it would also be very unintuitive to very many people, and certainly so with the way this information is currently being displayed. That is to say nothing about the technical feasibility of making such a change, which I'm not qualified to speak on. Dr. Duh 🩺 (talk) 11:36, 7 July 2022 (UTC)
- It might not be perfect but it is only an indicator of a change. No matter what the value represents you will not be able to tell what the edit is by having a number (+2/-50) explain what a user has done. The difference here would mostly be for copy editing which I don't see an improvement of showing a +1 over a 0. Terasail[✉️] 11:48, 7 July 2022 (UTC)
- @Terasail For myself +1 (i.e., edit distance) is very more informative than 0. And I really think that (and hope) it would be more informative to others. Hooman Mallahzadeh (talk) 11:52, 7 July 2022 (UTC)
- @Terasail Yes! A copy task makes "Byte size difference" equal to 0, but in such cases, "edit distance" should be equal to 1, and not bigger than 1, so implementation by Levenshtein distance is not a good choice for such scenarios. You are right! We should somehow modify the algorithm for such copy tasks, to return edit distance equal to 1. But for scenario of "in" and "on", Levenshtein distance is good enough. Hooman Mallahzadeh (talk) 13:16, 7 July 2022 (UTC)
- @Terasail For myself +1 (i.e., edit distance) is very more informative than 0. And I really think that (and hope) it would be more informative to others. Hooman Mallahzadeh (talk) 11:52, 7 July 2022 (UTC)
- @Doctor Duh You are right, for someone that does not know anything about edit distance, this data may be unintuitive. But edit distance is more informative for an expert. I really think that by using the idea of edit distance here, this concept becomes more frequent among people. I have an idea too. We can show both items, i.e., both "Byte size difference" for beginners and "edit distance" for experts, be shown here.
- Technically edit distance is
The minimum number of operations required to transform one string into the other.
- implementing that technically is not hard. Hooman Mallahzadeh (talk) 11:49, 7 July 2022 (UTC)
- @Doctor Duh@Terasail Implementing for different scenarios like copy/paste scenario makes it more difficult, but I think number of scenarios is small and we can implement that. Hooman Mallahzadeh (talk) 13:24, 7 July 2022 (UTC)
- @Doctor Duh @Terasail And I should note that "Byte size difference of editions is equal to -5", is so much ambiguous that nearly says nothing about what happened in the article, it says nothing about how much change have been occurred in the article. These are some probable scenarios:
- a word omitted - in this case edit distance is equal to byte size change by a sign change
- in article many changes occurred but size difference is equal to -5 - in this case edit distance is big
- very small parts changed but size difference is equal to -5, - in this case edit distance is small but greater than 5
- some copy/paste occurred and a word omitted - in this case, "edit distance" information is much more reliable
- Among these scenarios, only in the first scenario, byte size has good information about what has been occurred in the article. Edit distance says how much (minimum) operations required to achieve the next edition of an article. Hooman Mallahzadeh (talk) 13:57, 7 July 2022 (UTC)
- I find just remembering the bounds of a metric is often sufficient for practical intuition in this kind of thing. From the Levenshtein distance article:
- It is at least the difference of the sizes of the two strings. [Lower bound]
- It is at most the length of the longer string. [Upper bound]
- It is zero if and only if the strings are equal. [Null case]
- Moving blocks of text wouldn't count, but if that's a desired feature it's an easy addendum to the code (appearing as "mv" text on the Watchlist or something). As for the issue of minor copy edits, they can still vary in byte difference, and that's what the "minor edit" flag is for. There is no non-linguistic algorithm that can determine if a "small" edit may actually be vandalism: it takes only 4 chars to do
Jeffrey Dahmer was a jerk
→Jeffrey Dahmer was not a jerk
. - Of course my preference for quantitative metrics is determined first by the Rule of Cool (first search result is such a downer), but I imagine this idea would lose a lot more people if we brought in some stat mech spice. So regardless I'm on board 100%. SamuelRiv (talk) 14:10, 7 July 2022 (UTC)
- @Doctor Duh @Terasail And I should note that "Byte size difference of editions is equal to -5", is so much ambiguous that nearly says nothing about what happened in the article, it says nothing about how much change have been occurred in the article. These are some probable scenarios:
- @Doctor Duh@Terasail Implementing for different scenarios like copy/paste scenario makes it more difficult, but I think number of scenarios is small and we can implement that. Hooman Mallahzadeh (talk) 13:24, 7 July 2022 (UTC)
- It might not be perfect but it is only an indicator of a change. No matter what the value represents you will not be able to tell what the edit is by having a number (+2/-50) explain what a user has done. The difference here would mostly be for copy editing which I don't see an improvement of showing a +1 over a 0. Terasail[✉️] 11:48, 7 July 2022 (UTC)
- @Hooman Mallahzadeh: this idea has been proposed in phab:T10571 - I don't think this is anything that we can just do here on the English Wikipedia (having to run some script to rewrite every one of those values on each line for everyone is really unlikely to happen - but maybe you could do some initial trials with a personal user script) - and that it is something that would be best done server side. You can join in the discussion at T10571 to further develop it. — xaosflux Talk 14:06, 7 July 2022 (UTC)
- Yep - I proposed this a few months ago as well and was told the same IIRC. Cross-fingers we'll get it at some point. Theknightwho (talk) 22:45, 7 July 2022 (UTC)
- Good idea (whether original or not). In particular, I would love my watchlist to show at a glance whether
Some article (2 changes | history) .. (0) .. [Vandal420; GoodGuy123]
has a net change of zero because the first edit was reverted (nothing to see here) or for other reasons (investigation required). Certes (talk) 17:42, 7 July 2022 (UTC)- It would certainly make life easier for human patrollers, yeah. Theknightwho (talk) 22:46, 7 July 2022 (UTC)
One way to clarify the size of the edit is to show separate values for characters added and characters removed (characters changed contributing to both values). So an edit that changes 1,000 characters but does not affect the total size of the article would be shown as "+1,000 −1,000". Gdr 07:57, 18 July 2022 (UTC)
- @Gdr I am not agree with you! A single value showing «functionally» the amount of edit distance is more appropriate for patrollers. But you are right, we can tooltip edit script operation numbers. For example, edit script summary could be shown in a tooltip as:
Edit distance = {{tooltip|100|ins:50, del:48, subs:2}}
- which yields:
- Edit distance = 100
- which in tooltip, we show that this edit distance that equals 100, is made up of 50 insertions, 48 deletions, and 2 substitutions (assuming operations of Levenshtein distance). Hooman Mallahzadeh (talk) 08:43, 18 July 2022 (UTC)
- I like the idea of splitting the edit distance into insertions and deletions with their difference being equal to the byte size change. This would be both informative enough for experienced editors and intuitive enough for beginners. Some examples:
- no change → (0)
- (in → on) → (+1/−1)
- (in → where) → (+5/−2)
- (in → into) → (+2)
- (into → in) → (−2)
- (unconditionally surrender → surrender unconditionally) → (+9/−9)
- Petr Matas 07:42, 19 July 2022 (UTC)
Uniform measurements based on preferences/settings
All throughout Wikipedia are various measurements depending on editor preferences. An example is the usage of dates like "3rd millennium BC", "3,000 years ago", "3 Kya", "4928 BP", and "3,000 BCE". The same goes for other measurements like imperial and metric systems. Can we create a system that tags measurements and allow users to set, or at least, possibly use Geo location or IP to convert these measurements? For example, I write "(--[5'11"][Imperial]--)". If the user preference is metric, then that part is automatically converted to "1.8 meters" in the article. This way, every article I read, I do not have to convert measurements, and more importantly, we have uniform measurements. This would be similar to the "date format" in the "global settings" under "appearance", but expanded to measurements and other dates.
Here is example article using various formats - https://en.wikipedia.org/wiki/Homo_erectus
The first paragraph uses "2 million years ago" and "117,000-108,000 years ago". The third paragraph has "146–185 cm (4 ft 9 in – 6 ft 1 in) in height and 40–68 kg (88–150 lb)" (thankfully, someone added both measurements). Then the article uses other measurements like "1.6 Mya", "780 kya", "1.6-0.5 Ma", "600,000 years", "400–300,000 years ago", etc.
Eventually, the setting can be expanded to spelling preferences like "meter" or "metre", "grey" or "gray", "analyse" and "analyze", and so on. This would be great for copying and pasting, and not having to go back through and "correct" the spellings of words. Fixaloticus (talk) 10:22, 10 July 2022 (UTC)
- This sounds too much like the date autoformatting feature which we did away with back in 2008. --Redrose64 🌹 (talk) 20:32, 10 July 2022 (UTC)
- Wikipedia:Date formatting and linking poll and Wikipedia talk:Manual of Style (dates and numbers)/RFC: Unresolved date delinking and autoformatting issues for the curious. Ductwork (talk) 17:55, 18 July 2022 (UTC)
Merge reform
Adapting a comment I made on Discord last month:
Does this situation sound familiar to anyone else? You nominate a textbook merge for topics with clear very heavy overlap per guidelines [WP:BROADCONCEPT and WP:MULTIPLENAMES]. You get a bit of early support from one or two users following merge discussions. Then an oppose from a newer editor who's clearly a specialist in the area and thinks the miniscule difference in scopes between the articles is the most important distinction in the world. And then, after a few weeks/months, another along the same lines. And then another. And then a no consensus close from someone too timid to go against the numbers. This very much isn't the first time I've encountered this; merge reform can't come soon enough.
I'm looking for concrete suggestions about how to change the merge process to make it functional again. I think having a tighter timeframe and involvement from a dedicated group of editors independent of the topic is essential, and that we could take substantial inspiration from the many XfD forums that function (comparatively) well. {{u|Sdkb}} talk 16:56, 10 July 2022 (UTC)
- Notified: WT:Merging, WT:WikiProject Merge, WT:BROADCONCEPT, WT:Ambiguous subjects. {{u|Sdkb}} talk 17:05, 10 July 2022 (UTC)
- A general comment: it is incredibly difficult for non-experts to reliably and generally distinguish between cases where an apparently "minuscule distinction" is important to a general audience and where it is not. One could just as easily come to this discussion with praise for stubborn experts who refuse to allow a drive-by discussion from some people who don't know better to conflate two topics whose difference matters. Protonk (talk) 17:37, 10 July 2022 (UTC)
- I'd say that, as a general rule, if you need to be an expert to tell the difference between two topics even after reading their respective articles, then they're closely related enough that they should be merged under WP:BROADCONCEPT. The most ideal editors to hear from would be those with both subject expertise and WP guidance expertise, but such editors often do not exist. What's currently happening is that subject experts are dominating discussions, and failing to understand that, per our policies, the question is not "are these two things identical?" (they almost never are) but rather "are they closely related enough that they do not justify the substantial cost of forking them?" {{u|Sdkb}} talk 18:08, 10 July 2022 (UTC)
- it's hard to judge the merit of what you're saying without some examples. can you point to a few instances of insignificant differences being overblown by experts/enthusiasts? TryKid [dubious – discuss] 18:21, 10 July 2022 (UTC)
- If one starts from the assumption that differences which aren't immediately apparent to non-experts don't require differentiation then they will invariably conclude that a merger should proceed regardless of expert opinion. Protonk (talk) 19:17, 10 July 2022 (UTC)
- I'd say that, as a general rule, if you need to be an expert to tell the difference between two topics even after reading their respective articles, then they're closely related enough that they should be merged under WP:BROADCONCEPT. The most ideal editors to hear from would be those with both subject expertise and WP guidance expertise, but such editors often do not exist. What's currently happening is that subject experts are dominating discussions, and failing to understand that, per our policies, the question is not "are these two things identical?" (they almost never are) but rather "are they closely related enough that they do not justify the substantial cost of forking them?" {{u|Sdkb}} talk 18:08, 10 July 2022 (UTC)
- One thing that makes creating a “process” for mergers difficult is that “merge X into Y” is not always the best option. While parts of X might work well in Y, other parts of X might best work in Z (etc). We thus need to keep mergers somewhat flexible. Blueboar (talk) 17:43, 10 July 2022 (UTC)
- As always, it would we good to have some actual concrete examples to go on. Wikipedia works by such concrete examples, rather than possibly hypothetical cases. Could we start by having some evidence that the merge process is dysfunctional, as implied by the OP's statement that we need to change the merge process to make it functional again. Phil Bridger (talk) 18:19, 10 July 2022 (UTC)
- @Phil Bridger and @TryKid, I sometimes leave out specific examples since I want us to focus on the broader issue rather than particulars of a single case, and since I don't want to seem like I'm just appealing a specific result. With those caveats, the close that motivated me to post here was at Talk:Oriental studies#Proposed merge of Asian studies with Oriental studies, where the current lead of Asian studies begins
Asian studies is the term used usually in North America and Australia for what in Europe is known as Oriental studies.
{{u|Sdkb}} talk 18:56, 10 July 2022 (UTC)
- @Phil Bridger and @TryKid, I sometimes leave out specific examples since I want us to focus on the broader issue rather than particulars of a single case, and since I don't want to seem like I'm just appealing a specific result. With those caveats, the close that motivated me to post here was at Talk:Oriental studies#Proposed merge of Asian studies with Oriental studies, where the current lead of Asian studies begins
- I suspect that there is a bias that encourages "oppose" votes on discussion posts such as proposed mergers. For every one oppose vote from a vocal SME with idiosyncratic views about overlap, there may be a dozen or so lurkers who believe the change is so common sense that there is no need to leave a supportive comment. The solution may be to encourage a shorter discussion period, followed by a WP:BOLD merge by the proposer. Schierbecker (talk) 19:19, 10 July 2022 (UTC)
- Many mergers are content matters, and the apparent problem that's driving this proposal is the fact that merge discussions receive input from content editors? – Uanfala (talk) 23:59, 10 July 2022 (UTC)
- In the few merge discussions I've initiated and participated in, I've found it to be a lot smoother of a process if you make the proposal, wait around a month (or longer depending on the size of the page/what's being merged), and then do it yourself if there's no opposition or comments whatsoever. Unless you're seeking a WP:HISTMERGE (which you shouldn't be in most merge cases), bold merges are very easily undone if someone refutes them in the future. Anarchyte (talk) 04:25, 11 July 2022 (UTC)
- Justlettersandnumbers and Talpedia had a discussion recently at Wikipedia talk:WikiProject Medicine#Preventive and social medicine related to this point. You can't always tell from the name what the difference is, but when there actually is a material difference, then it should be possible to write and source a paragraph that says "Foo and bar are both types of baz, but they are different because foo is qux and bar is quuz." I would think that any actual experts in such a discussion would be very well placed to identify such sources. Such a paragraph would not only be useful for readers, but should make it clear to future editors why the article hasn't been merged. WhatamIdoing (talk) 18:38, 11 July 2022 (UTC)
- I'm a fan of this. Given my experience I'm not sure it will always result in a merge, since in this case I added some details to a couple of articles then moved on to other this, but at least some useful information is added to the articles, the articles are linked for readers and the link encourages future readers or editors to considering merging or add more information - which is perhaps a good alternative to lots of messages on talk pages without clarity about what is actually true. I'll repeat what I said before, that it isn't necessarily easy to find sources that do this sort of "meta-commentary" comparing different fields, but I guess in the cases where I've tried to do this I have suceeded eventually.
- I'd also throw in the sometimes I'm not sure that merges are always based on literature comparing the two topics. Sometimes you get "self-contained literature" that aren't connected to the rest of the literature (kinda like pseudoscience) and you might want to merge to add contextualization (Victim mentality and Trauma come to mind) or (Mental illness denial and Antipsychiatry)) and the choice to merge is more of an editorial decision than one based on the literature. Who knows if this sort of "editorial original research" is a good thing. It feels sort of related to the "See also" sections in articles. Talpedia (talk) 22:37, 12 July 2022 (UTC)
- I have seen this and it doesn't make me think of merge reform. IME, merge discussions take a long time (I usually give them a year). You often don't get the result you're expecting and I try to flow with that. As articles are improved the issue usually becomes more clear and a consensus you're comfortable with will typically emerge. ~Kvng (talk) 13:50, 13 July 2022 (UTC)
- This is too abstract a proposal to give a solid answer. Yes, there are times where I've seen two articles duplicate most of the same subject matter, and they really should be merged, as per WP:MULTIPLENAMES. But there are other times where two articles cover different material as per WP:MULTIPLESUBJECTS and should continue to be treated as separate articles. All that said, I think some type of WikiProject could be beneficial here. (Compare: Wikipedia:Articles for improvement or Wikipedia:Counter-Vandalism Unit) But it would be hard to keep it free from bias, and there's a risk it promotes a WP:BATTLEGROUND instead of encouraging more consensus building. Shooterwalker (talk) 20:38, 13 July 2022 (UTC)
- We do have WP:WPMERGE. I think you're suggesting project members could take a more authoritative role in closing merge proposals so that the forest perspective has more sway than the trees. ~Kvng (talk) 20:56, 13 July 2022 (UTC)
- I fully agree that the merge process is broken; not enough independent editors see the discussion, and it takes far too long for the discussions to be closed. I have wondered if this could be addressed by merging the merge process into WP:RM. BilledMammal (talk) 21:54, 13 July 2022 (UTC)
- Can people get notified of requested merges in certain topics similar to how people are notified of RFCs through Wikipedia:Feedback request service? If not, perhaps working towards a tool like that would be useful imo. — Ixtal ( T / C ) ⁂ Join WP:FINANCE! 12:35, 16 July 2022 (UTC)
- Merge requests are included in WP:AALERTS. --Redrose64 🌹 (talk) 16:09, 16 July 2022 (UTC)
5P3 to be clear and not "merciless":
The pillars are "popular summaries", so they should be clear and simple. Maybe this reword would help,
Editors do not own their contributions, and they which may be dispassionatly edited or deleted by others, but Wikipedia records contributions article histories,
Editors respect others media creators by striving not to plagiarise, by respecting copyright, by attribution, and by preferring quality content that is free to use (especiallly from our sister projects), rather than that available under fair useThe issues in WP:5P3 that the reword adresses in the current version are, it
- Uses the word 'mercilesslmy' which clashes with wikipedia:5P4,
- Does not mention that the free content is subject to the license terms
- Makes no mention that the Editor moral rights's are not given up, but are recored in the article history
- Uses the legalism 'can and may',
- Does not mention WP is free also because of the wikipedia foundation purpose,
- Uses both redistribute and distribute,
- Does not state a preference for other wiki projects or like minded unbiased projects content, and
- Does not specify that the free content should be quality content Wakelamp d[@-@]b (talk) 09:07, 11 July 2022 (UTC)
- Mercilessly needs to stay. The point is when you contribute on Wikipedia, others may, can, and will edit over your contributions. They are not protected, they are not sacred, and you do not own them. If you can't handle writing 10 paragraphs and having someone else come over and taking an axe to your contributions, rewording them, rearranging them, etc... for the improvement of the article, then Wikipedia is not the place for you. This is not restricted to Wikipedia. If you write "Jimmy Twopants is great guy [picture from the PR team], he founded Twopants Inc, a global leader in pharmaceuticals that specializes in cancer treatments." someone can use what you wrote and merciless convert that to "Jimmy Twopants is terrible guy [edited picture], he founded Twopants Inc, a pharmaceuticals company that poisoned several babies." and put that anywhere on the internet (alongside credit for the original text), and you have zero moral or legal grounds to take that content down (so long as it's not libelous). Headbomb {t · c · p · b} 09:24, 11 July 2022 (UTC)
- The other things are already covered by "freely license their work to the public", or are either implied (quality) or are not pillars (preference for other wikis/likeminded projects). Headbomb {t · c · p · b} 09:27, 11 July 2022 (UTC)
- We do own our contributions. They are licensed under a Creative Commons licence, so they can be used and edited, but we still own them. Hawkeye7 (discuss) 05:53, 12 July 2022 (UTC)
- @Hawkeye7So you agree that the current 5P3 is incorrect?
- "Since all editors freely license their work to the public, no editor owns an article and any contributions can and may be mercilessly edited and redistributed. Respect copyright laws, and never plagiarize from any sources. Borrowing non-free media is sometimes allowed as fair use, but strive to find free alternatives first."Wakelamp d[@-@]b (talk) 10:58, 12 July 2022 (UTC)
- Hawkeye7 is technically correct, but it's a bit of a nitpick. While we still have some semblance of legal ownership over the content we contribute under the Creative Commons license, we have voluntarily and irrevocably relinquished many key rights associated with that ownership, such that the only important right we have left is attribution: other people can edit, copy, and use our work without asking for our permission, but when they do so, they must give credit to us as the original author (this is done on-wiki through the page history). Mz7 (talk) 17:02, 12 July 2022 (UTC)
- There's a difference between owning your contribution and owning an article. If I write an article, I own what I wrote and I license it under the terms of the Creative Commons License. If you then edit the article, you own what you wrote, which is a derivative of what I wrote. The idea behind no one owning an article though is that although I own the rights (and have licensed them under the Creative Commons License), I don't own or control the cumulative product. So the current 5p is correct when it says "no editor owns an article", and your version above is incorrect when you say "Editors do not own their contributions". ~ ONUnicorn(Talk|Contribs)problem solving 17:11, 12 July 2022 (UTC)
- Does anyone know when the word merciless was first used in refeence to edits in WP?
- The 2007 version is at Wikipedia:Five_pillars&oldid=169010005 (sorry I couldn't find/cant rememeber out how to link history versions) is actually better I think.
- "Wikipedia is free content that anyone may edit. Articles can be changed by anyone, and no individual owns any specific article. If you don't want your writing to be edited mercilessly, do not submit it. All text is available under the GNU Free Documentation License (GFDL) and may be distributed or linked accordingly. Do not submit anything that infringes copyright, or that is licensed incompatibly with the GFDL."
- Wakelamp d[@-@]b (talk) Wakelamp d[@-@]b (talk) 15:33, 16 July 2022 (UTC)
- We do own our contributions. They are licensed under a Creative Commons licence, so they can be used and edited, but we still own them. Hawkeye7 (discuss) 05:53, 12 July 2022 (UTC)
- In a "popular summary", (defs from wiktionary) merciless ("Showing no mercy; cruel and pitiless.") seems less professional and more emotional than dispassionate ("not showing, and not affected by, emotion, bias, or prejudice"). It also implies judegment/punishment, rather than consensus/improevement. "Wikipedia is not the place for you" is merciless and exclusionary, dispassionate would be "Read the edit comments, and see if you agree, thee talk" (Aside - What does "Twopants mean??)Wakelamp d[@-@]b (talk) 10:50, 12 July 2022 (UTC)
- Reference to Jimmy Two-Shoes. Headbomb {t · c · p · b} 19:33, 12 July 2022 (UTC)
- I think the idea was to be accurate. Editing can feel merciless. I will not show mercy on poor grammar or if you want to use some WP:CLICHE or WP:EUPHEMISM in an article. The number of times I have had pity on editors who tell me that "lost his battle with cancer" is good because the cliche sounds more pretentious and indirect than a statement of the bare facts is zero, and will remain zero. I also show no pity on the people who have argued that it's unkind to say that babies die from fatal diseases, because that destroys their parents' misplaced hopes. Even outside these obvious areas, sometimes editors spend hours or days creating a trivia section or writing something based on impossibly bad sources. We don't show mercy and agree to let them keep half of the unwanted content; we show no mercy and remove it. WhatamIdoing (talk) 19:32, 13 July 2022 (UTC)
- But do you do it cruelly? Fron Wikitionary again "causing or reveling in pain and suffering; merciless, heartless. Synonym: heartless or sadistic. With pitiless, I totally agree with avoiding cliches about death, unless of course as a quotation.
- With the trivia section, I agree that such should be removed. But not cruelly or pitlessly. Wakelamp d[@-@]b (talk) 05:05, 14 July 2022 (UTC)
- Even if my own emotions are noble, the other editor might think it quite cruel of me.
- I want you to think specifically about the medical example I gave. The idea that we must preserve hope, above all else, is very strong in American culture. The old saying that "Where there's life, there's hope" has been turned on its head. Cancer patients are told that they must have a good attitude, or they'll die. Some of them actually go to their graves blaming themselves for "failing the treatment" (the treatment failed them) or because they didn't have the right attitude, and that "allowed" the cancer to spread. We have research showing that the oncologists who are rated "the best communicators" by their patients are the ones that mislead them into thinking that they'll live when they won't. Some of these are appalling diseases. The long-term survival rate for advanced pancreatic cancer is 1%. There's one hematological malignancy that, if it recurs after a first remission, has exactly one known survivor ever – so rare that the Catholics declared it a divine miracle. Even if I write and source those words with tears running down my face, if you get this diagnosis, the Wikipedia articles are going to seem cruel, merciless, pitiless, heartless, sadistic, and so forth. We are trying to win the "understanding reality" prize, not the "protecting you from very upsetting facts" prize. WhatamIdoing (talk) 21:06, 18 July 2022 (UTC)
- Thank-you for explaining. I think we are conflating merciless editing and merciless content in this discussion. To draw this difference out, let's slightly uspend the essay Wikipedia:SAMEHEIGHT for this discussion and talk about their relationship in Wiki.
- the Reviewing Editor. They should obey all the pillars. So,WP:5P4, should be tempered with WP:5P4 civility which meets my dispassionate suggestion. Except WP:5P5 is really not the same height as the others.
- the Content. The pillars must apply, but that means we should not be intentionally cruel (WP:5P4 (even though that policy does not apply to readers}. Using your example, I think both the Pancreatic_cancer#Outcomes and End-of-life_care articles strike a good balance.
- the orginal author. Their edits must meet all the pillars. But we should avoid wasting thier good faith time, because of WP:5P4, but currently WP:5P3 acts a caveat emptor This is also self serving, as if we waste time, then they leave Wakelamp d[@-@]b (talk) Wakelamp d[@-@]b (talk) 04:56, 19 July 2022 (UTC)
- Thank-you for explaining. I think we are conflating merciless editing and merciless content in this discussion. To draw this difference out, let's slightly uspend the essay Wikipedia:SAMEHEIGHT for this discussion and talk about their relationship in Wiki.
- Aside. but our shared opinion of cliches, made me wonder if there were any tools to help detect them. There is unsuccessful cliche update bot which was too broad Wakelamp d[@-@]b (talk) 07:14, 14 July 2022 (UTC)
- Thank-you. It looks quite bizarre and fun, but I dont remember seeing it in Asutralia, I thought it was a reference to The History of Little Goody Two-Shoes Wakelamp d[@-@]b (talk) 15:12, 16 July 2022 (UTC)
- I think the idea was to be accurate. Editing can feel merciless. I will not show mercy on poor grammar or if you want to use some WP:CLICHE or WP:EUPHEMISM in an article. The number of times I have had pity on editors who tell me that "lost his battle with cancer" is good because the cliche sounds more pretentious and indirect than a statement of the bare facts is zero, and will remain zero. I also show no pity on the people who have argued that it's unkind to say that babies die from fatal diseases, because that destroys their parents' misplaced hopes. Even outside these obvious areas, sometimes editors spend hours or days creating a trivia section or writing something based on impossibly bad sources. We don't show mercy and agree to let them keep half of the unwanted content; we show no mercy and remove it. WhatamIdoing (talk) 19:32, 13 July 2022 (UTC)
- Reference to Jimmy Two-Shoes. Headbomb {t · c · p · b} 19:33, 12 July 2022 (UTC)
- The other things are already covered by "freely license their work to the public", or are either implied (quality) or are not pillars (preference for other wikis/likeminded projects). Headbomb {t · c · p · b} 09:27, 11 July 2022 (UTC)
- See the discussion about the long history of the use of this term in this thread. Sometimes content does indeed need to be removed/edited without regard to the feelings of the original author, therefore being pitiless or (from their perspective) perhaps cruel. Graham87 04:53, 17 July 2022 (UTC)
- Graham87 thank-you for your answer on the other thread (I had no idea that there was a nostalgia wikipedia). Anyway to the point, there seems a very strong attachment to merciless. With merciless, I was thinking more about the editor's attitude rather than that of original author. No editor that acts dispassionately (:-)) can control how another user reacts, but an editor being merciless (cruel/pittliess) defintely can.Wakelamp d[@-@]b (talk) 12:24, 17 July 2022 (UTC)
Track Changes / Show Markup to Display Edit History
Alternative to the Compare Selected Revisions diff viewer. Have a version where you can select (Revision 1) to (Revision 2) and then view an inline markup / changes comparison of the results superimposed over the actual page with colorization per user. An implementation reference for such a feature is the Google Docs collaborative editing feature, which shows each user with a color next to their edits. Ex: Added some text (User1, 00:00, 01 Jan 2022)Removed some text (User2, 00:01, 01 Jan 2022) Possibly with the names and timestamps only visible with onHover/onMouseOver. I believe this would make it easier to find changes on particularly active pages such as Portal:Current_events where some days there may be 100's of edits and it can be difficult to find when a specific edit was added or removed. This seems like it would also make contentious edit war pages easier to see at a glance because they would look like AddedRemovedAddedRemovedAddedRemoved in any region that was especially fought over. Araesmojo (talk) 21:50, 13 July 2022 (UTC)
- You may be interested in Wikipedia:WikiBlame or mw:Who Wrote That? WhatamIdoing (talk) 21:08, 18 July 2022 (UTC)
WP:Vital Direct
I've written down sorta a plan to boost the production of WP:Vital Articles, which in the last 15 years have made zero progress. What do you think about the plan and how could it be improved? CactiStaccingCrane (talk) 02:29, 15 July 2022 (UTC)
Year-denominated Currency Format
Hi there! First post in the Ideas board (or any board) so please let me know if I could improve anything. Feedback is much appreciated.
Problem:
Often I will be reading some historical entry and a currency amount will be mentioned (e.g. "Adam died in 1824 and left behind $230,000 to his niece.")
1. I do not always have an intuitive understanding for how historical amounts translate into today's currency. When reading these older entries, the currency amounts seem a bit meaningless (if the reader does not know the inflation-adjusted conversion) or unintentionally misleading/confusing (if the reader does not know to convert the amount at all).
2. Sometimes the currency amount is not clearly tied to a particular year in the text, and it is left ambiguous, so the reader can't convert it confidently at all.
How this is often partially solved already:
Sometimes authors will include a conversion themselves in the text. Here's an example:
> "On January 15, 1948, Redfield won US$2,300 (equivalent to $25,940 in 2021)."
This is much appreciated, but not an ideal solution. It requires authors to fill up the text with these conversions, and even then the conversions themselves are still tied to a particular year and will themselves require updating in the future. In 30 years the reader may not have an intuition for 2021 dollar values any more than they do 1948 dollar values.
Idea for improvement:
Could we add the year to the currency format and require/strongly encourage it? That would separate the concerns.
All the author would need to do is include the year the currency amount was originally tied to. Then automation could handle displaying that meaningfully to the user with clear reference to the original year as well as some smart UX for letting them view the equivalent amount in today's currency.
I suppose this could be done either on the markup side or the actual content side, so long as the formatting was standard and machine-parseable. However, I don't know of any existing standard for year-denominated currency so it seems a bit brittle to just make up a wikipedia-specific one. I believe this ought to end up in some ISO standard so any mention of a currency amount always includes the basis year, it just prevents confusion and manipulation (e.g. discussion of minimum wage gets warped when people do not understand that $7 in 1950 is much less than $7 in 2020). If it already is a standard then please let me know!
Thanks for reading this and considering, I'm looking forward to hearing what people think!
SmoothAmber (talk) 16:10, 15 July 2022 (UTC)
- I'd think this should be in the prose. Inflation/deflation certainly do happen (in your example above I'm not even sure what you mean by 1950$USD$7 is "much less than" 2020$USD$7 - I'd think it is "much more" as it could be converted to more goods and services). — xaosflux Talk 18:12, 15 July 2022 (UTC)
- I'm pretty sure in the past I've used the {{Inflation}} template for these purposes. It shows also how to do a currency conversion at the end if necessary (I'm not sure if there's a standalone wrapper template for that). The documentation also shows the date bounds for the datasets, though I would still be very cautious about portraying any value prior to the 20th century in modern currency as better than very approximate (I would suppress the cents output of precision for one thing), and anything before the 19th is just... well it depends on the region, social change, and quality of data. For pre-20th century I agree that simply "getting an idea" of what one thing was comparatively worth at one time is enlightening information, properly qualified, but just getting that base number to work from I think no matter what requires an RS. Past the 1920s or so, and certainly post-WW2, the conversion gets a lot better and the data table in the calculator should be relatively uncontroversial except when dealing with economies that are in utter crisis when you do your conversion. SamuelRiv (talk) 20:51, 15 July 2022 (UTC)
- Yes, I think {{inflation}} does more or less the job that is being asked for here (including rolling over to current year if desired). However, I also very much agree with the comment that any automatic method can give a quite misleading result when used outside the context of "modern figures for reasonably small amounts", and we should definitely be cautious about applying it wholesale.
- York Castle has a good example of how to handle figures like this - it contextualises by saying eg that repairs cost "£200, about the annual income of a baron". If you were to use the RPI-based template, or a similar automated method, you would get a figure of about £150k - a bit less than the price of an average flat in the city today, which gives quite a difference sense to "the entire income from a large estate".
- Similarly, Economic history of the United States Civil War takes a nuanced approach by giving a modern equivalent for one value (income tax levels) where the conversion is reasonably meaningful, but omitting them for the larger ones (the total cost of the war, national debt, etc) where RPI-based conversions would be inappropriate. Andrew Gray (talk) 13:08, 18 July 2022 (UTC)
- I'm pretty sure in the past I've used the {{Inflation}} template for these purposes. It shows also how to do a currency conversion at the end if necessary (I'm not sure if there's a standalone wrapper template for that). The documentation also shows the date bounds for the datasets, though I would still be very cautious about portraying any value prior to the 20th century in modern currency as better than very approximate (I would suppress the cents output of precision for one thing), and anything before the 19th is just... well it depends on the region, social change, and quality of data. For pre-20th century I agree that simply "getting an idea" of what one thing was comparatively worth at one time is enlightening information, properly qualified, but just getting that base number to work from I think no matter what requires an RS. Past the 1920s or so, and certainly post-WW2, the conversion gets a lot better and the data table in the calculator should be relatively uncontroversial except when dealing with economies that are in utter crisis when you do your conversion. SamuelRiv (talk) 20:51, 15 July 2022 (UTC)
Incentivise article improvement
Background: The ArbCom are some weeks into taking evidence about Conduct in deletion-related editing. I've been watching, thinking, and trying to imagine a solution to what I perceive as the underlying problem. On the face of it, the problem is behaviour at WP:AFD. This idea, attempts to deal with the issues that motivate editor behaviour.
I raised this issue here, and @Tryptofish suggest I post here.
The Problem (my amateur psychology musings): The problem is human tendencies. Consider the politician who makes the front page of the local newspaper for opening a school. Consider how no politician ever gets on the front page for quietly, smoothly running a school. It's human nature, we value starting things more than maintaining things. And it's the same here. Editors like to say how many articles we created, tools allow us to see that and compare ourselves. It plays to our nature: enjoyment of competition, gamification. Tools, as far as I know, don't make it easy to see how many articles we improved. Less editors, I think, boast on their user page how many gnomish improvements they made. I am sure I am not alone in getting a little dopamine hit every time I create a new article. Likewise I have seen people boast on user pages how many bad pages they got deleted, I am sure people get a little satisfaction knowing they improved the encyclopaedia, removed the junk, maintained the standards. Which leaves us with behaviours, supported by tools and culture that gives little rewards for creating and little rewards for deleting. Less clear rewards and less strong incentives exist and to measure or undertake article improvement. Humans respond to incentives. We are emotional animals that like to feel good about ourselves. We tend to do what we can measure.
Suggested strategic solution: We need to incentivise article improvement. Mass stub creation is only a problem when there is not an equal or larger effort to improve them, I say that with the assumption that all these articles about Olympians, sports people, islands, or TV shows are notable. I assume good faith by those who create them. Wikipedia would be better if there were better ways to measure article improvement. We need to add gamification: rank editors by their efforts to improve articles. Maybe the Article Rescue Squadron should have been called the Article Improvement Team. Maybe the tendency to frame this as tension between deflationists and inclusionists is wrong and it's more of problem about lack of article improvement efforts and incentives. CT55555 (talk) 21:12, 15 July 2022 (UTC)
- Rank editors how? We've already got various things like Wikipedia:List of Wikipedians by article count, Wikipedia:List of Wikipedians by number of edits, Wikipedia:List of Wikipedians by featured list nominations, Wikipedia:List of Wikipedians by featured article nominations, and similar, plus people already collect barn stars and other forms of WikiLove and thanks, icons for WP:GOOD articles they've worked on, etc. There are various gamified drives to improve backlogs in some areas (e.g. I'm taking part in Wikipedia:New pages patrol/Backlog drives/July 2022), and thinking of NPP in particular there's lists like Wikipedia:Database reports/Top new article reviewers, etc. I am however also conscious of WP:EDITCOUNT. I personally don't create many articles and am definitely more of a WP:GNOME/WP:ELF. -Kj cheetham (talk) 13:56, 16 July 2022 (UTC)
- I hope others might chime in with ideas about how. But I still think we need to incentivise to me more like you. At risk of relying on anecdote, I think you have edited more articles I created more than anyone, and I see your role-model behaviour as a statistical outlier. I don't mean to diminish anyone else's work, but what I see from reading the ArbCom case is a consequence of too much focus on creation and deletion at the expense of article improvement. Maybe I should ask, what motivates you so we can try and bottle and replicate that?
- Also the "number of edits" I think encourages small bot like edits over article improvement. I note we're not comparing Wikipedians by volume (kb) of kept content added, Wikipedians by number of articles improved out of stub. CT55555 (talk) 14:09, 16 July 2022 (UTC)
- Highly likely I think I'm not a "typical" editor. :) Stats based on articles moved from stubs would be very hard to track technically I think, if relying on people from projects to manually classify articles. Something by volume of content could be interesting though... Things like https://xtools.wmflabs.org/ec/en.wikipedia.org/Kj_cheetham can tell you average edit size, and the ratio of small/big at least for a single editor, and things like https://xtools.wmflabs.org/authorship tell you what fraction editors contributed to a single article. I suspect I find looking at stats more interesting than most people. (I do have a highly scientific background.) Barnstars and Wikipedia:Service awards are slightly motivational to me, as well as watching numbers increase, but generally I just like to try and make things better by doing some of the "boring" things other people don't tend to like to do, though I primarily focus on biographies most of the time. I try to stick to uncontraversial things most of the time (hence I work on things like WP:RMTR rather than closing discussions) and mostly staying off the "drama boards", and I like to do little edits than require minimal thinking by me a lot of the time. -Kj cheetham (talk) 14:24, 16 July 2022 (UTC)
- There are some ways in which we encourage article improvement, for example 5x expansion DYKs are an excellent way to earn WikiCup points. There are also improvement projects like Women in Green or the Core Contest. But perhaps we should have more ways to celebrate content creation and improvement outside DYK and GA/FA. —Kusma (talk) 14:36, 16 July 2022 (UTC)
- One of my fellow editors expressed the sentiment that Wikipedia is not a video game, and I agree wholeheartedly. Humans are good enough at creating hierarchies without making it this formal – we already have lists of our works on our userpages, and barnstars... I would oppose any sort of further social-status-based incentive to write articles. Another editor pointed out DYK – main page exposure is definitely a neat reward for a new or expanded article, as is the very formal DYK credit you receive for it. theleekycauldron (talk • contribs) (she/they) 03:50, 17 July 2022 (UTC)
- @TheleekycauldronI think we have to careful that we don't start to think that there is only one way to Wiki. I am sure there is shortcut for that, but I can't remember it. I understand people who don't want social status incentives, but there are 30 or 40 K regular editors, we are largely anonymous so the status isn't really that hig. Wakelamp d[@-@]b (talk) 12:56, 17 July 2022 (UTC)
- @CT55555 "Maybe the tendency to frame this as tension between deflationists and inclusionists is wrong and it's more of problem about lack of article improvement efforts and incentives." I agree. My personal bugbear is drive-by taggers, and the various "this article needs improvement" tags. Yes, you have found a problem, well done - now fix it. I think that is in part because of mismatched incentives, and of power imbalances. The NPP tools allow and editor to rack up edits faster than if they were playing Galaga with tags. but does that improve WP? Wakelamp d[@-@]b (talk) 12:58, 17 July 2022 (UTC)
- Thing is… tagging is a step towards fixing. I can identify a problem with an article just from reading it… but not know the topic well enough to know how to fix that problem. For example, I can say “hmmm… this statement needs a source” but not know what the best sources are… so I tag it with a “citation needed” tag so that other editors (who DO know what the best sources for the topic are) can follow up and add the needed citation. Blueboar (talk) 13:27, 17 July 2022 (UTC)
- @Blueboar I am 50/50 on the citation tags, because although they are a great collaboration tool, however
- Tagging stubs is redundant, on the benefit of tagging mid-class articles I am uncertain, but i agree for others for the reasons you mention. Wikipedia:Template index/Cleanup has similar advice.
- Tagging is shaping the way WP works in negative ways. When an editor tags it satisfies the itch, by moving the resposibility to subsequent editors. If enough editors existed, then it would be great process, but they don't {based on the age of unaddressed tag edits and the huge backlogs). Instead, mass tagging could be seen a way we reduce the impetuous to change, so that new editors stay, Wakelamp d[@-@]b (talk) 03:36, 18 July 2022 (UTC)
- I do think that certain kinds of tags are pointless. Do we need a (visible) {{more footnotes}} banner on a one-sentence substub? I don't think so. I don't think it provides value to us, and I don't think our readers are so stupid that they can't count the number of little blue clicky numbers all by themselves in extremely short articles. Most readers can count up to at least three pretty reliably.
- I'm also doubtful that these tags produce improvements merely by lingering at the top of the page. Maybe if someone's actively improving the article, they'd respond, but when nobody has made a substantive edit in the article for a long time, then it's probably pointless.
- Also, in terms of edits, the way to make lots of edits is generally to do nothing important. Fix a tiny formatting error. Remove your pet WP:CLICHE. If you want to a contest to really improve articles, then Wikipedia:Citation Hunt has a leaderboard. This month's leader has posted only 51 citations. I bet you could beat that. WhatamIdoing (talk) 21:17, 18 July 2022 (UTC)
- The justification for tags is that they urge users to become editors. The justification for this is personal experience But there is no quanitiative proof that that first edits are tag corrections or ...., but I am not certain whather quantitative data would be compelling in our process.
- I must disagree that "Most readers can count up to at least three pretty reliably.", as I think we are underestimatimg as I remember in Watership Downs rabbits can count up to four. :-)
- And I shall try to avoid talking in cliches, but only "At the appropriate juncture.In the fullness of time. When the moment is ripe. When the necessary procedures have been completed. Nothing precipitate, of course." Yes, Minister Season 1 episode 5 Wakelamp d[@-@]b (talk) 06:14, 19 July 2022 (UTC)
- @Blueboar I am 50/50 on the citation tags, because although they are a great collaboration tool, however
- I don't think tagging is a problem. I do both, as in, I both tag, and I remove tags. I both improve articles (from creating new ones to rescuing bad ones) and get others deleted. IMHO, tags "look bad", making our articles more obvious work in-progress, ugly to the readers, but are important both as indicators of what needs to be fixed, and yes, reminder for the readers that many articles are not finished and that they can help. While I do agree tag bombed articles are not aesthetically pleasing, I think it's ok. Bad, untagged articles which "look" good are not a service to the readers. It's better for everyone to see there's a problem then to mask it with swathes of problematic content that looks good for uninformed readers. Piotr Konieczny aka Prokonsul Piotrus| reply here 11:28, 18 July 2022 (UTC)
- In the past, I've tried to use notability tags to give editors time to address the notability issues prior to taking the article to AfD. I no longer do that, due to a very negative reaction from an editor, but I believe it is generally a good practice, and a step towards improving the encyclopedia, either by improving the article or deleting it. BilledMammal (talk) 13:23, 18 July 2022 (UTC)
- Thing is… tagging is a step towards fixing. I can identify a problem with an article just from reading it… but not know the topic well enough to know how to fix that problem. For example, I can say “hmmm… this statement needs a source” but not know what the best sources are… so I tag it with a “citation needed” tag so that other editors (who DO know what the best sources for the topic are) can follow up and add the needed citation. Blueboar (talk) 13:27, 17 July 2022 (UTC)
- I seem to detect (but I apologise already if I'm wrong) that there's an underlying suggestion that NPPers are at fault for either over-tagging, or not immediately addressing the issues. I would just like to point out however, that fixing articles is absolutely not within the NPP remit. If it were, the huge backlog would be even bigger. Let's also not forget that anyone, however inexperienced, can tag articles; the only thing they can't do is pass them as reviewed for indexing. There are millions of perma-tagged articles and most of them will never be improved; Wikipedia needs to find a way to ensure that at least the creators of new articles are made aware of the minimum required standards before they click 'publish', Currently they are not informed. Kudpung กุดผึ้ง (talk) 00:57, 19 July 2022 (UTC)
- Nothing about my suggestion has anything to do with NPP, which is something I am completely under informed to have an opinion about. I have only good things to say about the editors who do the effort to review the huge number of new pages. I did not intend to suggest otherwise. CT55555 (talk) 01:47, 19 July 2022 (UTC)
- CT55555 ,It was a general observation and there was nothing to suggest that you in particular were responsible for any trend I felt I detected in the thread. That said, you may wish to get up to speed with what WP:NPP is all about and apply for the user right and help out. It looks to me as if you already have more than sufficient experience and it would be much appreciated. Kudpung กุดผึ้ง (talk) 02:16, 19 July 2022 (UTC)
- Thanks. I did consider it before. I looked at the process and felt a bit intimidated by the user interface and rules and decided to keep my focus on article creation instead, but I'll reconsider. I fear it is a role that attracts confrontation and I'm already borderline stepping back from Wikipedia due to the nature of some debates, but I'll not use this space as any more of an outlet on that now. All the best. CT55555 (talk) 02:20, 19 July 2022 (UTC)
- @CT55555 I beleive that was addressed at me. Choosing incentives can be tricky, as there are often unintended consequences, especially if they are blanket or are not in line with a desire path. There is an adage (apoligies I can't remember the ref) that any part of an organisation/person will optimise itself at the expense of the others, and the origanisational goals.
- Rejection of new incentives that you may not perform well against, or reduce your existing status, is very human. Even if we are not a video game, people deserve recognition and satisfaction for their ggo faith work.
- @Kudpung I think the NPP do a great job, but there is a possibility of tool misuse that I think an article on the NPP page acknowledges.
- So, are there any stats on what % of how many tags are added by NPP/automated tool users? About ten years ago there was a WMF foundation paper by the NPP tool creator, where he expressed his disquiet at how it had changed WP, particularly to do with new editors. NPP automatically judge new articles, by tools that we oo not provide new article creators (10 hours work versus 10 seconds to review). The justification why we don't is that vandals might use these tools in the same way google does not reveal pagerank for fear of SEOs.
- Wakelamp d[@-@]b (talk) 07:36, 19 July 2022 (UTC)
- CT55555 ,It was a general observation and there was nothing to suggest that you in particular were responsible for any trend I felt I detected in the thread. That said, you may wish to get up to speed with what WP:NPP is all about and apply for the user right and help out. It looks to me as if you already have more than sufficient experience and it would be much appreciated. Kudpung กุดผึ้ง (talk) 02:16, 19 July 2022 (UTC)
- Wakelamp, New Page Reviewers do not use any automated tools for their work and they do not judge or criticize the articles' creators. Apart from being able to pass articles as reviewed there are no tools that are not available to anyone else in Twinkle and the NewPagesFeed. Everything is based on having enough knowledge and experience to correctly asses the quality and notability of a new article, and more often than not it means checking out the sources. I would be extremely concerned if any NPPers think 10 seconds is enough to thoroughly review a new page.
- I don't know anything about a ten-year-old paper by the NPP tool creator. but I would be very interested to read it. I knew the the team of tool creators personally - I collaborated with them in 2012 on the development of the new NPP system. Any negative effect of the tools or even ACTRIAL has been thoroughly disproved and acknowledged by the WMF in an in-depth scientific study. All Wikipedia wants now is more New Page Reviewers of the right calibre, some bugs and a couple of new features in the software being addressed, and better incentive for new users who create articles to create them properly.
- Probably the best solution would be to end the constant experiments with the design and function of the Article Wizard, rebuild it to the professional principles of UX and communication studies, give it a sleek modern look, and insist that new editors use it. The mantra 'The encyclopedia anyone can edit' does not mean 'Come to Wikipedia and dump your spam, junk, CV, and garage band here'. Kudpung กุดผึ้ง (talk) 10:48, 19 July 2022 (UTC)
Automatic notification of users at ANI/AN; templatising AE/ARBCOM cases
At the present stage people have to manually notify every user involved in the discussion, which I think should be automated (after all, if it is so important as to be highlighted in a red box, it could just as well be at least semi-automated so that there is no chance it is overlooked. Unfortunately not being able to program, I have no idea how to implement it in code, but the idea is more or less this:
For AN/ANI:
- A user starts a thread about other users concerned.
- Writes some text
- When clicking "Save changes", the user is prompted (by popup or any other means) to notify users - the user has to choose a valid username (with the options to choose more) or click "I don't wish to notify anyone".
- An automatic comment in small font is added about the users notified for the discussion, or that none were.
- A bot notifies specified users (if any).
- Drama begins.
The only problem in this particular case is to force it to be the case only for the OP but not for the other users who happen to comment in the thread (maybe by triggering the prompt when == [Some title] == pattern is typed or when the user clicks on "New section" button?)
For AE:
- A user clicks the link as instructed
- A popup appears, similar to DYK-helper; could be some other form. Since the reported must have autoconfirmed user status, the program checks the user rights. The following fields are created: User(s) notified as accused in the case; remedy enforced (dropdown list); diffs (by id or by link), up to 20; diffs of previous sanctions, if any; awareness criteria fulfilled for each user (ticking boxes, upon ticking, the box displays a prompt to enter either a diff id or the date); additional comments, with a word counter, writing in wiki syntax (warning displayed at 500 words, hard limit at 550 words). The report is then automatically generated, either by itself or as a template; apart from the text, it generates sections titled as "Statement of [accused party]" and the admin section.
- For appeals, the user ticks the relevant box, and the following changes occur: "users notified as accused" becomes "admin imposing sanctions"; awareness criteria are removed from the menu.
- A bot automatically inserts a notification on the talk pages of relevant parties/admins.
- The deliberations begin.
For ARBCOM: The word limits are adjusted accordingly; prior dispute resolution box is added. Otherwise similar to AE.
I would like to see your thoughts. Szmenderowiecki (talk) 13:44, 16 July 2022 (UTC)
- I don't really think we need to make it easier to open ANI or AE cases. But if someone wants to write an optional helper script, they are free to do that. —Kusma (talk) 14:11, 16 July 2022 (UTC)
- The idea is more about making compliance with the rules of notification (and word limits) easier, rather than enabling more drama; and non-compliance with these technicalities wastes userhours of work. Szmenderowiecki (talk) 16:16, 16 July 2022 (UTC)
- Is it really making it easier to open a case, or simply easier to open one correctly if you've never done it before? I don't actually see it as a huge problem, either, though -- the most common response to a newer editor opening a case at ANI without notifying is "You are required to notify; I have done that for you." Occasionally someone points out the big red alert, but honestly I think most editors at ANI understand that there's a lot of clutter in those edit notices, and that someone navigating the process for the first time while upset might not be reading the instructions thoroughly. valereee (talk) 16:21, 16 July 2022 (UTC)
Make Talk Pages shorter and more useful
They are long and I skim, so here are some ideas
- All editors to show compressed view of a template. (maybe just the template name and paramaters. Show only the template name rather than an explanation. Experienced Editors know what the rules are.
- Be able to show archived topics back on the page in say a different colour.
- Make it easy to do mass updates without triggering watchlists. Change watchlist preference (except for admin users) to ignore minor edits to yes, and send a message to users to change back if they wish
- Be transparent about the # of editors watching, and warn the user that know one is watching except anti-vandalim . Even on popular articles,80 % never get a reply. For instance looking at the old movie which is far better Talk:Top Gun/Archive 1 - Wikipedia. The argument is that vandalism will increase, but why not try it on a secton of wikipeia and see?
- Watchlist on Talk transparency. Does the number of watchers include only permanent and non expired?
- Watchlist details on user talk - why can't an editor see who is watching their own page?
- Prompt to look at the talk page. I don't unless i see something odd, or it's controversial. Have the Tab show a nunebr similar to how email systems show open messages
- Does archiving actually still serve a purpose? The Bulk of the page is because of the above, and slow internet connecion is a thing of the past.
"It is customary to periodically archive old discussions on a talk page when that page becomes too large. Bulky talk pages may be hard to navigate, contain obsolete discussion, or become a burden for users with slow Internet connections or computers. Notices are placed at the beginning of the talk page to inform all editors of an archive.: Wakelamp d[@-@]b (talk) 14:42, 16 July 2022 (UTC)
- By "compressed" I assume you mean collapsed? Not sure how archived topics in a different colour would help? Most of the other ideas seem to be about watchlists more generally. I wish slow internet connections were a thing of the past for everyone though! -Kj cheetham (talk) 23:10, 16 July 2022 (UTC)
- The issue of too many template banners on Talk pages has been raised before. I saw someone in the archives raise the idea of combining them all into an infobox – not sure if anyone's actually tried that yet.
- Mass updates are typically done by bots which users can filter on the Watchlists, including to just the Talk namespaces. While some bot actions simply noise on a Watchlist (archiving, rating, category fixes), a great number of users would still like to watch bot edits for mistakes, because they do happen and can be quite controversial. Plus the bots have fairly descriptive edit summaries so it's easy enough to ignore.
- Talk page tab prompts seem odd -- they would only be relevant to editors who have visited the Talk page previously, and thus likely have it on their Watchlist already... so the logical place to put a prompt (if desired) is on the Watchlist.
- Regarding page size, maybe dial-up is mostly gone (places with no internet infrastructure tend not to have phone infrastructure either), but data rates and memory usage are still a thing.
- Having the number of watchers visible to those wanting to post on the Talk page is an interesting idea -- I don't know if it's been explored before. I'm sure you could get a good metric for what you think would represent which editors watching are "expired" at the moment, but I'm reasonably sure most people here have had long periods of inactivity. Still, it could be useful. SamuelRiv (talk) 23:41, 16 July 2022 (UTC)
BLP violations in non-linked on the main page
There was recently a discussion at WP:ERRORS concerning a DYK entry that had a BLP violation – not in the bolded article, mind you, but in one of the supplementary links that are just applied. BLP is a super important policy – how should we approach not publicizing violations on the main page? We could allow for unlinking if BLP issues aren't resolved... theleekycauldron (talk • contribs) (she/they) 03:46, 17 July 2022 (UTC)
- BLP violations must not be linked from the Main Page. If the vio can't be fixed and the link is crucial for the hook, the hook must be pulled. —Kusma (talk) 13:53, 17 July 2022 (UTC)
Invisible comments about section's incoming links
Notifying editors about incoming links pointing to a given section seems so important, that MOS:COMMENT and WP:HIDDEN mention it as the first use case for invisible comments:
<!-- If you change this section title, also change the links to it on the pages ... -->
I would like to see this markup standardized, for example with a template understandable even to VisualEditor (VE). For example in the article Limit of a function we could write
===Limits at infinity===
{{If you change this section title, also change the links to it on the pages|Limit at infinity}}
to inform editors (especially the VE users, as mentioned in Wikipedia talk:Manual of Style/Hidden text/Archive 1#This is now obsolete) that Limit at infinity redirects to this section. Transclusion of the template will not output anything, just like the invisible comment. A related discussion: Wikipedia:Village pump (proposals)/Archive 8#Redirects to sections in articles. Petr Matas 11:39, 18 July 2022 (UTC)
- The ideal solution, which is unlikely to happen, is to warn editors automatically by checking [the API equivalent of] Special:WhatLinksHere for section links whenever an editor attempts to change or remove a section heading. We have 276,000 {{R to section}}s, plus an unknown number of section redirects without the template, so commenting every destination might create a lot of clutter as well as being a major maintenance task. Certes (talk) 11:56, 18 July 2022 (UTC)
- Hidden comments are now visible in the VE (the fact that they weren't for a long time was a bug that got fixed some time ago). However, using a standardised template can bring other advantages, so the proposal sounds like a good idea. – Uanfala (talk) 11:58, 18 July 2022 (UTC)
- That was fixed in 2014, as part of phab:T51603.
- I'm not sure why this should be standardized. Offhand, the cons are:
- It's more complicated.
- More things to get 'wrong'.
- One more fiddly little thing to learn.
- One more Shibboleth to separate the outsiders from those of us who know the right way to do things.
- It doesn't work if you copy it other wikis.
- If you get a typo in the template name, you'll have a visible mess in the article.
- The pros are:
- Some of us like to have everything match.
- If we wanted to solve the actual problem, then I would think that
{{anchor|Limits at infinity}}
would be more pointful. Then you could change the section heading and still have the incoming links work. We could even set up a redirect for that template with a name like Template:Anchor for incoming links, if you were worried that people might not understand what Template:Anchor is for. WhatamIdoing (talk) 22:37, 18 July 2022 (UTC)- I must agree. Maybe the problem needs a different approach: A bot could track all redirects to sections (independently from R templates) and update them automatically. If it is unable to solve a specific case (for example, a section removed altogether), it will leave a message on the culprit's talk page. Petr Matas 08:04, 19 July 2022 (UTC)
- We already have such a bot, so the problem is solved. Certes (talk) 11:20, 19 July 2022 (UTC)
- I must agree. Maybe the problem needs a different approach: A bot could track all redirects to sections (independently from R templates) and update them automatically. If it is unable to solve a specific case (for example, a section removed altogether), it will leave a message on the culprit's talk page. Petr Matas 08:04, 19 July 2022 (UTC)