Wikipedia:Village pump (idea lab)
Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
Before creating a new section, 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.
Wikipedia Hall of Fame?
What are your thoughts? Is it going to work? Comment down below. Wolverine XI (talk to me) 17:28, 8 April 2024 (UTC)
Hall of fame topic; section break 1
- I'll bite. What do I get? Like, a room with a comfy chair? The one caution I would have about this is that there are some editors whose positive contributions to the encyclopedia would unquestionably earn them a spot, but who are presently indef-banned for other reasons. BD2412 T 17:37, 8 April 2024 (UTC)
- "The one caution I would have about this is that there are some editors whose positive contributions to the encyclopedia would unquestionably earn them a spot, but who are presently indef-banned for other reasons." That's a good point. Though, IMO, I don't think HOF should be behavior-exclusionary and should be open to anyone who has made an enduring impact on WP, regardless of how they made the impact. For instance, I say induct Jordan French (maybe not in the inaugural cohort, but eventually). Chetsford (talk) 18:47, 8 April 2024 (UTC)
- I agree with Chetsford on this. Wolverine XI (talk to me) 04:11, 9 April 2024 (UTC)
- French certainly made an impact but then so did many LTA vandals. If this idea is adopted, it seems appropriate to limit membership to those who have shown altruism rather than encouraging those who make Wikipedia worse for personal gain. Certes (talk) 08:24, 9 April 2024 (UTC)
- Never say never. Wolverine XI (talk to me) 13:16, 9 April 2024 (UTC)
- Yeah, that's a good point, Certes. I think this was intended more as an exaggeration for emphasis that we not be rules-bound for a HOF, but probably not a good example to underscore that! Anyway, I agree with your suggestion. Chetsford (talk) 15:26, 9 April 2024 (UTC)
- French certainly made an impact but then so did many LTA vandals. If this idea is adopted, it seems appropriate to limit membership to those who have shown altruism rather than encouraging those who make Wikipedia worse for personal gain. Certes (talk) 08:24, 9 April 2024 (UTC)
- I agree with Chetsford on this. Wolverine XI (talk to me) 04:11, 9 April 2024 (UTC)
- "The one caution I would have about this is that there are some editors whose positive contributions to the encyclopedia would unquestionably earn them a spot, but who are presently indef-banned for other reasons." That's a good point. Though, IMO, I don't think HOF should be behavior-exclusionary and should be open to anyone who has made an enduring impact on WP, regardless of how they made the impact. For instance, I say induct Jordan French (maybe not in the inaugural cohort, but eventually). Chetsford (talk) 18:47, 8 April 2024 (UTC)
- We already have a lot of perks for experienced editors (Special holidays, Wikimedian of the Year, Editor of the Week, Service awards, ...), and I honestly don't think we need yet another way to separate "elite" Wikipedians from the rest of us. Chaotıċ Enby (talk · contribs) 18:02, 8 April 2024 (UTC)
- Similar to Internet Hall of Fame, to be serious, there would need to be a reliable advisory board. They can help surface little known but important people from the early founder days. It could be a popular vote nomination process, like the Nobel, but picking the winners would need a small august body, known for deep institutional knowledge and experience. After a few rounds/years of winners, those winners then become members of the advisory board. Overall this is probably something that should be organized by WMF. Or you can just do it, but it will be another "This one is special. This one is also special" award. -- GreenC 18:32, 8 April 2024 (UTC)
- @GreenC, i like the discussion here of this idea, but how about an opposite approach? such as, anyone who wants to be in the hall of fame, can be?? and maybe split it up by topic, so that it would have some actual useful format to make it readable to others? Sm8900 (talk) 20:10, 17 April 2024 (UTC)
- I like it. While we may have a superfluidity of awards, these cost essentially nothing to produce so I'm not sure I ever understand the resistance. All recognition systems are voluntary and those who don't approve can opt-out. Moreover, a HoF -- if managed through some approximation of the way GreenC describes -- would be different from existing accolades which are either interpersonal recognition (editor to editor) or metric-based recognition (e.g. Four Award, etc.). Chetsford (talk) 18:41, 8 April 2024 (UTC)
Hall of fame topic; section break 2
- Of course they "cost nothing to produce", that's not the problem, the problem is that they give one more excuse to divide Wikipedians between "the ones who have power" (i.e. the unblockables) and the plebs like us. Chaotıċ Enby (talk · contribs) 13:36, 10 April 2024 (UTC)
- It might be a good idea. 3.14 (talk) 19:07, 8 April 2024 (UTC)
- The key questions for any initiative is what is the objective, and how helpful is the initiative in achieving this objective? For recognition programs, it's important to also consider how the selection process will work, and whether or not it will create more difficulties than benefits gained. Recognition programs are tricky because the flip side of selecting some is that many others are not selected, and that can result in conflict. isaacl (talk) 02:36, 9 April 2024 (UTC)
- That's how recognition programs work, but I don't think they'll necessarily cause any conflict. Wolverine XI (talk to me) 04:09, 9 April 2024 (UTC)
- "it's important to also consider how the selection process will work" After the inaugural cohort is selected, maybe it should become self-perpetuating with all prior inductees selecting each subsequent cohort. (Though you'd still need some system to choose the inaugural cohort.) This would mitigate politicization and degradation as inducted members would have a vested interest in maintaining its reputational coherence. Chetsford (talk) 05:37, 9 April 2024 (UTC)
- That would be difficult if they are dead or so long retired from WP they don't give a toss about the place anymore/are out of touch about who is still active and "deserves" a shout. - SchroCat (talk) 07:44, 10 April 2024 (UTC)
- "would be difficult if they are dead" I imagine it would. Chetsford (talk) 08:48, 10 April 2024 (UTC)
- I would object to exclusion of the deceased. There are some amazing editors who left us too soon, but with great work done first. BD2412 T 02:37, 11 April 2024 (UTC)
- We don't mean a blanket exclusion, just that we will ensure that batches of cohorts keep on coming; this line of discussion was about a proposal to have each cohort select the next. Aaron Liu (talk) 02:59, 11 April 2024 (UTC)
- I would object to exclusion of the deceased. There are some amazing editors who left us too soon, but with great work done first. BD2412 T 02:37, 11 April 2024 (UTC)
- I don't think we'll select a cohort that are all dead or inactive, for the reasons you've mentioned. Aaron Liu (talk) 11:34, 10 April 2024 (UTC)
- I think it best if you don't have any intake at all: voting for one's friends make this an inbred and insular process. As I've said before (as has Chaotic Enby), this is a bad idea - divisive and with the potential for conflict when the "wrong" people are elected and the "right" people over looked. - SchroCat (talk) 12:02, 10 April 2024 (UTC)
- "would be difficult if they are dead" I imagine it would. Chetsford (talk) 08:48, 10 April 2024 (UTC)
- That would be difficult if they are dead or so long retired from WP they don't give a toss about the place anymore/are out of touch about who is still active and "deserves" a shout. - SchroCat (talk) 07:44, 10 April 2024 (UTC)
- The English Wikipedia Hall of Fame idea sounds peachy keen, as Babe Ruth would say before tying his hands behind his back and hitting a home run with his neck (Ruth is, all kidding aside, the most underrated ballplayer in baseball history). The initial "class" obviously would include J and L, the pioneering heroes of our story, and I can think of several others who would be obvious. That first class probably shouldn't be large, maybe 7 or 8 inductees. Then the rules get tricky, but doable. In a perfect world we'd lock J and L in a room until they get to a place where they can come up with a plan of how to handle this that everyone says "Of course that's how it should be done". But, bottom line, I think an EWHoF is a good idea all around (without WMF involvement). Randy Kryn (talk) 03:22, 10 April 2024 (UTC)
- A second rate popularity contest with ill-defined criteria? What could possibly go wrong. Terrible and divisive idea. You think someone's great - give 'em a barnstar, or, even better, leave them a thank you note, but to 'promote' people who will undoubtedly be divisive to others? That way grief and conflict lies. And this ignores the fact that "hall of fame" is not a worldwide concept that people everywhere readily grasp or buy into.- SchroCat (talk) 07:44, 10 April 2024 (UTC)
- Schro, the procedure is akin to the Wikimedian of the Year, except that it exclusively concentrates on the English Wikipedia. There's a purpose for these initiatives, and I firmly disagree that this is a "bad idea." Wolverine XI (talk to me) 13:25, 10 April 2024 (UTC)
- You are, of course, entitled to disagree. For what it's worth, I think the Wikimedian of the Year is a fairly crap award too, being a process with no criteria and something else that divides, rather than unites. Most people are happy to do the work for the sake of the work, not to seek vacuously external praise or validation just because they've caught the eye of someone powerful or happen to be pushing a zeitgeist line of thinking. - SchroCat (talk) 14:44, 10 April 2024 (UTC)
- As you haven't yet stated the purpose behind your suggestion, nor proposed a process, there isn't enough info to understand the potential benefits and costs. There's an understandable view that costs quickly outweigh benefits as any process involves more people, adding up to more total effort expended. isaacl (talk) 16:53, 10 April 2024 (UTC)
- Schro, the procedure is akin to the Wikimedian of the Year, except that it exclusively concentrates on the English Wikipedia. There's a purpose for these initiatives, and I firmly disagree that this is a "bad idea." Wolverine XI (talk to me) 13:25, 10 April 2024 (UTC)
Hall of fame topic; section break 3
- More awards? At this rate, all our time will be spent giving ourselves pats on the back and giving each other shiny things. While I don't agree with the more extreme anti-award views (take wiktionary for example; wikt:Template:User barnstar has been nominated for deletion twice, and been described as
cheesy and gaudy. I don't think we need all that Wikipedia's tinsel to encourage people.
), we shouldn't go overboard with this. Cremastra (talk) 22:07, 10 April 2024 (UTC)- (the correct link is wikt:Template:User Barnstar, with a capital B. Aaron Liu (talk) 01:51, 11 April 2024 (UTC)
- Thanks. Cremastra (talk) 19:39, 12 April 2024 (UTC)
- It's okay if you choose not to participate in the process. Wolverine XI (talk to me) 04:55, 11 April 2024 (UTC)
- How would one choose not to participate? I would not participate, but saying so would make it look as if I thought I stood a chance of being elected, which I do not. I imagine that most of those who would choose not to participate think the same way. Phil Bridger (talk) 20:07, 11 April 2024 (UTC)
- (the correct link is wikt:Template:User Barnstar, with a capital B. Aaron Liu (talk) 01:51, 11 April 2024 (UTC)
I don't much like anything on Wikipedia which encourages elitism, political campaigns, cliques, inequality, etc. I can imagine that many wiki-politicians would waste a lot of time campaigning to be elected to a HOF and that the results would be divisive. "How come so-and-so got elected, and I didn't?" Smallchief (talk) 21:44, 12 April 2024 (UTC)
- I think this sort of thing is better left to other sites. Maybe the people who hang out at Wikipediocracy would create a Wikipedia Hall of Fame? Or would it become a Wikipedia Hall of Infamy? Phil Bridger (talk) 08:09, 13 April 2024 (UTC)
- I especially don't like the idea of putting infamous characters in a HOF. Follow baseball standards. Pete Rose and Shoeless Joe Jackson are not in the baseball HOF because of scandal, despite being qualified. No bad actors, no matter how famous, in a HOF. Smallchief (talk) 09:04, 13 April 2024 (UTC)
- Good point, but Wikipedia is not baseball. Wolverine XI (talk to me) 06:57, 14 April 2024 (UTC)
- Indeed. Baseball is a sport where defeating others on the field is encouraged. Wikipedia is a cooperative endeavour where it's frowned on. Certes (talk) 09:48, 14 April 2024 (UTC)
- Yes, this program is designed for honoring purposes rather than competition. I hope that's clear to all. Wolverine XI (talk to me) 04:41, 16 April 2024 (UTC)
- In that case, it seems the honor should not be of the Wikipedian itself, but of the work that they accomplished in a given area. That's why the Barnstars exist, of course. Just as WP:NPA encourages us to comment on the content and not on the creator, so too should we be aware to not place individual people on a pedestal.
- Frankly I find it disappointing that, in bringing forth the idea, the OP has not brought forth any comprehensive or detailed arguments in support of this idea and in response to the above critique. We are simply discussing a nebulous concept of recognition, which I think Wikipedia already addresses, and which if people really needed to see more of, they could use other websites or mediums for this purpose. Duly signed, ⛵ WaltClipper -(talk) 12:29, 16 April 2024 (UTC)
- And we do celebrate content, quite satisfactorily, with DYK and TFA. So there is no need for a "hall of fame", it's just more self-congratulation. Cremastra (talk) 20:45, 16 April 2024 (UTC)
- Yes, this program is designed for honoring purposes rather than competition. I hope that's clear to all. Wolverine XI (talk to me) 04:41, 16 April 2024 (UTC)
- Indeed. Baseball is a sport where defeating others on the field is encouraged. Wikipedia is a cooperative endeavour where it's frowned on. Certes (talk) 09:48, 14 April 2024 (UTC)
- Good point, but Wikipedia is not baseball. Wolverine XI (talk to me) 06:57, 14 April 2024 (UTC)
- I especially don't like the idea of putting infamous characters in a HOF. Follow baseball standards. Pete Rose and Shoeless Joe Jackson are not in the baseball HOF because of scandal, despite being qualified. No bad actors, no matter how famous, in a HOF. Smallchief (talk) 09:04, 13 April 2024 (UTC)
section break 4; [wikilounge idea]
- how about a
loungeWikiLounge for experienced wikipedians? would that be immediately misused, or could it serve a helpful purpose? Sm8900 (talk) 13:41, 17 April 2024 (UTC)- That would just be a way to create an in-group, and I don't really see how it would help the project. Chaotıċ Enby (talk · contribs) 13:47, 17 April 2024 (UTC)
- I agree with Enby. What purpose would that serve? Aaron Liu (talk) 15:27, 17 April 2024 (UTC)
- Who decides who is experienced enough? On what basis? I hope it's not edit count, which can vary enormously between people having the same overall effect. Phil Bridger (talk) 15:48, 17 April 2024 (UTC)
- Like an actual lounge, or some cliquey forum that would do nothing to benefit the project? All these ideas go against our core principles. Cremastra (talk) 19:46, 17 April 2024 (UTC)
- ok, fair enough; all of these points are quite valid. so then, how about a lounge which would be labeled as being open to all experienced wikipedians, plus anyone who wishes to shmooze with them? that way, we are actually opening it to everyone, but giving it an underlying theme for those who are interested.
- to use an analogy, it would be like opening a lounge for woodworkers, or one for musicians, or one for ferryboat drivers, and also admitting anyone interested in that specialty. it would be basically open to anyone, and yet the theme would be clearly stated in terms of the specialty which is its actual focus. Sm8900 (talk) 19:56, 17 April 2024 (UTC)
- can an editor nominate themselves for this "Hall of Fame"? if so, then it might preserve the grassroots nature of wikipedia, and still have a positive effect. kind of like hanging out at the local skateboard park, and popping wheelies to show off one's skills to other fellow aficionados. Sm8900 (talk) 20:08, 17 April 2024 (UTC)
- Don't we already have every single needed discussion "board" known to Man? Aaron Liu (talk) 20:24, 17 April 2024 (UTC)
- What would actually be the point of having a lounge with this theme? Like, how would it help the project like, say, the Wikipedia:Teahouse, the Wikipedia:Help desk or the Wikipedia:Administrator's noticeboard does? Chaotıċ Enby (talk · contribs) 21:21, 17 April 2024 (UTC)
- The idea of an "experienced user lounge" very much echoes of Wikipedia:Esperanza which, although it did result in useful derivative projects, very much had a problem back in its day with regards to ingroup/outgroup behavior. Duly signed, ⛵ WaltClipper -(talk) 12:58, 18 April 2024 (UTC)
- how about a
- One downside of this proposal is that it would involve a fair amount of the electorate's time if they are not to just elect people who they already know. That time would be better spent improving the encyclopedia, which is what we are here for (or at least are supposed to be here for). Phil Bridger (talk) 15:48, 17 April 2024 (UTC)
- another idea; how about simply call it something whimsical or jocular, such as "Wikipedia League of Super-friends"? or "league of adventurers"? that way, it still retains the air of a unique league, yet it would be clear it is not anything awarding actual higher privileges here. Sm8900 (talk) 20:15, 17 April 2024 (UTC)
- I still don't see what the actual point is. Even with a funny name, it will still be a pretty divisive thing. Chaotıċ Enby (talk · contribs) 21:22, 17 April 2024 (UTC)
- Divisive programs, like the WP:Editor of the week, already exist. Wolverine XI (talk to me) 22:41, 20 April 2024 (UTC)
- And that's not an excuse to have more of them. Chaotıċ Enby (talk · contribs) 22:46, 20 April 2024 (UTC)
- OK, if you say so. Let us see if we can reach a consensus. Wolverine XI (talk to me) 23:10, 20 April 2024 (UTC)
- And that's not an excuse to have more of them. Chaotıċ Enby (talk · contribs) 22:46, 20 April 2024 (UTC)
- Divisive programs, like the WP:Editor of the week, already exist. Wolverine XI (talk to me) 22:41, 20 April 2024 (UTC)
- I still don't see what the actual point is. Even with a funny name, it will still be a pretty divisive thing. Chaotıċ Enby (talk · contribs) 21:22, 17 April 2024 (UTC)
- another idea; how about simply call it something whimsical or jocular, such as "Wikipedia League of Super-friends"? or "league of adventurers"? that way, it still retains the air of a unique league, yet it would be clear it is not anything awarding actual higher privileges here. Sm8900 (talk) 20:15, 17 April 2024 (UTC)
Section break 5
- Editor of the Week was set up with a specific goal in mind: to demonstrate appreciation of specific positive behaviours and collaborative spirit by its recipients, with an explicit disclaimer that it's not intended to be a judgement about their overall characteristics. It was deliberately set up as a no-big-deal award with a very lightweight process, to avoid making it something that people would argue a lot about. The original pool of candidates was lesser-known editors, in order to give them a bit more encouragement to continue contributing, but has since been broadened to anyone. It's basically a slightly fancier barnstar, with some people slapping recipients on the back with a "good job". As a result of this carefully planned design, it hasn't fostered division. isaacl (talk) 02:05, 21 April 2024 (UTC)
- Many such award schemes have been previously proposed. Only two, to my knowledge, still function: WP:QAI, because of the dedication of one editor, and WP:EOTW. If you want another one, set it up and run it yourself—if people like it, you can then apply to formalize it as a Wikipedia-wide process. ~~ AirshipJungleman29 (talk) 12:13, 26 April 2024 (UTC)
- Oppose. I'm not sure what I'm opposing here, but whatever it is, I'm against it.
- Anyway, the Service Awards are good because they are purely mechanical and entirely removed from politics. Entirely: If you're banned, you qualify. If everyone hates you, you qualify. If you drove your car up the steps and into the door of the Wikimedia Foundation offices on purpose, you qualify. Also, you continue to accrue service time -- which is measured from the date of your first edit, and does not take into account gaps -- after you're dead. So, if service time is the limiting factor for you, you will progress up the levels even after your demise, and I know of one editor who is. So... Maybe our Hall of Fame could be only for deceased editors. After all, you have to be dead five years before you're eligible for the baseball Hall of Fame. Then I think most people would be "Oh its nice to remember Smith" and not upset about the politics. My 2c. Herostratus (talk) 02:53, 28 May 2024 (UTC)
How about a Hall of Shame?
I know generally we are a bit negative especially when it comes to disruption, which is why we generally note previous hurdles as a cautionary tale of what not to repeat. A reminder everyone is human. A hall of fame will make editors more concerned with scoring brownie points than actually improving the project. Awesome Aasim 20:29, 7 May 2024 (UTC)
- We already have Wikipedia:STOCKS, more than this would actually be more harmful than it might help. Chaotıċ Enby (talk · contribs) 20:33, 7 May 2024 (UTC)
- Yeah I know. I was just thinking about why we have a hall of shame but not a hall of fame. Awesome Aasim 00:05, 8 May 2024 (UTC)
- The stocks aren't a hall of shame, it's a humourous list of mistakes. -- LCU ActivelyDisinterested «@» °∆t° 21:04, 9 May 2024 (UTC)
- Yeah I know. I was just thinking about why we have a hall of shame but not a hall of fame. Awesome Aasim 00:05, 8 May 2024 (UTC)
- Awesome Aasim, isn't WP:Long term abuse already kind of that? — 🌙Eclipse (talk) (contribs) 14:49, 18 May 2024 (UTC)
- That page should not really be intended to be a 'hall of shame' due to WP:DENY and WP:BEANS (none of which apply to the village stocks in comparison). Xeroctic (talk) 19:33, 20 May 2024 (UTC)
We already have a hall of shame. Just Step Sideways from this world ..... today 17:40, 26 May 2024 (UTC)
Allowing Master's theses when not used to dispute more reliable sources
WP:SCHOLARSHIP generally allows PhD dissertations and generally disallows Master's theses, unless they have had "significant scholarly influence." I feel that this is really locking us out from a lot of very reliable sourcing. I understand that these are often not quite as polished as something like a monograph or PhD dissertation, but often times they are the highest quality sources available about very niche subject matters. They are subject to professional review, they cite their sources, and they are published by reliable institutions. Can we really say that these are less reliable than an entry in a historical society newsletter or an online news report from an assuredly hurried local journalist?
Just today I encountered a 2022 masters thesis, East Meets West in Cheeloo University (doi:10.7916/scmr-6237). As far as I can tell, this is the most comprehensive source available on the architecture of Cheeloo University. But I can't use it, since it's a masters thesis, and as far as Google Scholar can tell, it has yet to be cited elsewhere.
I feel that people should be allowed to use masters theses in certain fields (I can only speak for the humanities, I'd be interested to know this from a STEM perspective) so long as A) They are not used to dispute something said in reliable sources and B) They are not used to confer notability. I feel this would strike a good balance of allowing us to use these often very useful sources, while still recognizing that a book, journal article, or PhD thesis is probably preferable if you have the choice between them. I'd love to hear other folks thoughts! Generalissima (talk) (it/she) 00:43, 7 May 2024 (UTC)
- In the stem area I would expect that important research would also be published in journals. I would discourage use of Masters theses rather than disallow. One issue is lack of accessability. Even when referenced, may not be accessible. The lack of "peer" review can also mean there are more errors included. Graeme Bartlett (talk) 02:03, 7 May 2024 (UTC)
- Is there any public information generally available about the process of publishing masters' theses for a given university? What level of scrutiny or review is generally applied, etc. I think considering whatever information is available there could lend a lot of clarity to deciding whether a given thesis is reliable. Remsense诉 02:09, 7 May 2024 (UTC)
- The rule in question is a counsel of perfection but perfect is the enemy of good and so WP:IAR applies. By coincidence, notice that today's featured article is about a work which started as a dissertation. The main thing I notice about this is that the readership for this topic is tiny. If you're working on a topic like the architecture of an obscure university that no longer exists, then you're mainly writing to please yourself and so should do what you think best. Andrew🐉(talk) 06:49, 7 May 2024 (UTC)
- I both agree and don't, to the extent that I don't think less popular topics should be viewed as less important as regards our content policies. Of course, I certainly understand the distinction between there being less available coupled with internal motivation, and that. Remsense诉 06:54, 7 May 2024 (UTC)
- I'd question whether Master's theses are really
subject to professional review
orpublished by reliable institutions
. By professional review, I assume you mean that somebody examines them. But unlike a PhD examination or journal peer review, which both act as barriers to publication, getting a low grade on a Master's thesis doesn't stop the thesis existing. The author can still put it online – presumably without the grade. Also, and speaking as a university teacher myself, the person who examined it examined it as a Master's thesis, not as a piece of publishable research. A middling or good grade means "I think the student did a good job with this material" not "I think this is a reliable source on this subject". As for publication, in my experience most Master's theses are not published (though those that are, e.g. in a journal, certainly become reliable sources). Some university libraries make archived copies available online, but this isn't really the same thing because again, any Master's theses that meets the formal requirements for submission will be there, regardless of quality. – Joe (talk) 07:59, 7 May 2024 (UTC)- Fair enough, I didn't think about the barrier to publication angle. I guess if we think about them more along the lines of a newspaper article (which can be of wildly different quality) then we could just evaluate them on their own merits. Just like how there is great journalistic coverage of some areas of history and archaeology, there is horrible, misleading coverage; and if it's not used as a major source in the article, it's pretty easy to spot when it's the latter. Generalissima (talk) (it/she) 15:42, 7 May 2024 (UTC)
- Purely anecdotal, but with respect to professional review, the only person on my master's thesis committee (my director) who understood what I was doing left on sabbatical half-way through. His replacement as chair kept me on the straight and narrow in my use of statistics, but knew no more about what I was doing than the rest of the committee. In retrospect, I can say that my thesis did not add anything useful to the sum total of human knowledge. On the other hand, I have dug into the bibliography section in a thesis to find sources I had otherwise missed, but that is a long shot. - Donald Albury 16:20, 7 May 2024 (UTC)
- If we would accept a blog post from the university itself (which would be self-published, primary, and non-independent) for the same kind of contents, then we should probably accept a master's thesis for it. A source only needs to be strong enough to support the weight of the claims it's cited for. If they're non-controversial (e.g., everyone agrees that there are some buildings on the campus), then the source doesn't have to be ideal. WhatamIdoing (talk) 21:53, 7 May 2024 (UTC)
- I believe that you are referring to WP:ABOUTSELF. My understanding of that is that we could cite the thesis for statements about the thesis and the author of the thesis, but not for statements about topics covered by the thesis. Donald Albury 22:33, 7 May 2024 (UTC)
- Not really. With the possible exception of contentious BLP matter, I think we should accept it for pretty much all non-controversial content. WhatamIdoing (talk) 22:50, 17 May 2024 (UTC)
- I believe that you are referring to WP:ABOUTSELF. My understanding of that is that we could cite the thesis for statements about the thesis and the author of the thesis, but not for statements about topics covered by the thesis. Donald Albury 22:33, 7 May 2024 (UTC)
- I agree that rigid exclusion of master's theses does not serve the project well. The language in WP:SCHOLARSHIP regarding Ph.D. dissertations would seem also to address many of the concerns above:
Some of them will have gone through a process of academic peer reviewing, of varying levels of rigor, but some will not. If possible, use theses that have been cited in the literature; supervised by recognized specialists in the field; or reviewed by independent parties.
(Of course, this issue would also be solved more efficiently by treating this guideline like a guideline to be applied flexibly in service of the mission rather than as a pseudo-policy that must be followed rigidly except in the most exceptional circumstances -- but that seems to be a bit too much to ask these days.) -- Visviva (talk) 04:12, 8 May 2024 (UTC) - I have come across some very high quality master's theses and agree that rigid exclusion of master's theses does not serve the project well. I had to work around this on Revolt of the Admirals and it was painful. In the case of my own master's thesis, it was thoroughly reviewed by two external examiners (as well as, of course, by my supervisor). It is available online and widely cited in the literature. The PhD was reviewed by three external reviewers, but is not as widely cited, and while also available online, I never got around to publishing it. Hawkeye7 (discuss) 04:47, 8 May 2024 (UTC)
- I think there's some regional differences here. In Europe, a Master's thesis isn't examined by a committee and their are no external examiners, just the supervisor. – Joe (talk) 06:34, 8 May 2024 (UTC)
- I agree that theses provide weak arguments for controversial points, as do other sources often accepted as reliable such as news articles or unreplicated one-off studies (I also think that there are many PhD dissertations that are questionable.) But, in writing research on historical topics, I these can be very useful and informative. They often provide a well-cited overview of a particularly esoteric topic that may not be the focus of a book or major study, which interested readers can read an analyze themselves. I like using them when they can be linked so readers can view them. As others have pointed out, At bare minimum, I'd like to be able to cite them even if they aren't standalone. (e.g., sometimes I can get the point cited by a book by a mainstream press, but it covers the topic in a sentence, whereas the dissertation gives the in-depth detail.) Wtfiv (talk) 20:47, 9 May 2024 (UTC)
- Theses are a mixed bag. Master's thesis even more so. I can say that mine went through a rigorous review process (I had a former president of the Canadian Association of Physicists as an external examiner on mine) as well as one other physics PhD, and had two physics PhD as my supervisors. The comments/feedback were substantive and relevant, and had to be addressed before acceptance.
- But go to a different department, in the same university, and the reviewing standards and requirements for a master's thesis are quite different. Headbomb {t · c · p · b} 21:34, 9 May 2024 (UTC)
- As Visviva said above, if people treat the guideline like a policy that "no masters theses can be cited for anything (or they can only be cited if lots of other people cite and repeat what they say, making it unnecessary to cite them), because we assume no masters thesis has ever been reviewed and made reliable; meanwhile, PhD theses are reliable because we're assuming every one has been reviewed by reviewers who know what they were doing", that's a problem (in fact, it's two problems separated by a semicolon). I think it would make more sense, as Visviva seems to be suggesting, to apply the same kinds of evaluative criteria as are supposed to be applied to PhD theses to both PhD and Masters theses, plus OP's suggestion that we don't use them to contradict a more reliable source; together with the fact that tighter sourcing requirements are already in effect for BLPs, medical topics, and various contentious topics, we'd in practice only cite masters theses when there was reason to think they were reliable for the uncontentious thing we were citing them for, e.g. the architecture of a particular university, which seems reasonable. (As WhatamIdoing said, if we'd accept a passing aside in blog post by the university as reliable for saying the buildings were neoclassical, it seems weird to reject a masters thesis all about the buildings being neoclassical.) Notability seems like a separate issue and it seems reasonable to say masters theses also don't impart much notability. -sche (talk) 00:48, 19 May 2024 (UTC)
- As per Graeme Bartlett's comment, if the underlying research in a master's thesis is of sufficient quality to source, the author should have or would have submitted it for publication to a journal. If sources used in the literature review are beneficial, then just directly cite those, don't cite the thesis (I've used many master's theses to discover references for WP articles, but I've never directly cited the thesis). My thesis was looked at by external examiners but it was certainly not done with the same critical eye as they would have applied to a Ph.D. dissertation. Opening this door seems like a recipe for disaster. Chetsford (talk) 01:04, 2 June 2024 (UTC)
- I think I agree most with WhatamIdoing here. Master's theses face nowhere near the oversight of that PhD theses do, but it's still generally going to be much more thorough work than the newspaper articles that make up the bulk of Wikipedia citations. signed, Rosguill talk 01:35, 2 June 2024 (UTC)
Ideas for promotion of the mentorship program
Hello all,
As you are probably aware, the growth team has introduced the Mentorship program on the English Wikipedia a little while ago. Currently, only 50% of new accounts on Wikipedia are assigned a mentor due to the amount of mentors currently available. I would like to know if anyone had ideas about potential ways to promote the mentorship program to experienced editors who would not know about it, or not have considered it?
This could include:
- Mass-messaging users involved in help forums who might be interested in mentoring
- Adding mentorship on the Task Centre for experienced editors
Any other ideas welcome!
Cheers, Cocobb8 (💬 talk • ✏️ contribs) 18:20, 11 May 2024 (UTC)
- Have you asked @Trizek (WMF) about what's worked at other Wikipedias? WhatamIdoing (talk) 23:11, 17 May 2024 (UTC)
- Let's see what he says! Cocobb8 (💬 talk • ✏️ contribs) 21:09, 18 May 2024 (UTC)
- Well, you are the only wiki where it is difficult to find enough mentors!
- At most other wikis, we got the right amount of mentors to signup; in a few cases, we had too many mentors for the size of the wiki (Ukrainian Wikipedia has so many mentors that some mentors never got a question after 6 months).
- My advice: try what you suggested. :) Trizek_(WMF) (talk) 15:09, 20 May 2024 (UTC)
- Thanks for the info! @WhatamIdoing, what are your thoughts on the options I proposed for promoting mentorship here on English Wiki? Should I propose adding mentorship on the task centre on the centre's talk page, and formally proposing mass-messaging at proposals in village pump? Cocobb8 (💬 talk • ✏️ contribs) 16:55, 20 May 2024 (UTC)
- Let's see what he says! Cocobb8 (💬 talk • ✏️ contribs) 21:09, 18 May 2024 (UTC)
- How about an article in the next Signpost, explaining the program and recruiting experienced editors to sign up? Schazjmd (talk) 16:57, 20 May 2024 (UTC)
- @Schazjmd Neat idea as well, I would support that! I have no experience in writing/proposing anything for the signpost though. Cocobb8 (💬 talk • ✏️ contribs) 17:01, 20 May 2024 (UTC)
- @Cocobb8, me neither, but they do have a quick-start guide. Schazjmd (talk) 17:05, 20 May 2024 (UTC)
- Nice idea! Let me know how I can assist you there @Cocobb8. I can find facts and data, but also stories to share. Trizek_(WMF) (talk) 17:05, 20 May 2024 (UTC)
- @Trizek (WMF) and @Schazjmd, I have started a Signpost draft. Please, feel free to edit it and add to it (anyone, really)! The more people who have some things to add, the better chances are we can have a successful Signpost news story to share :). Cocobb8 (💬 talk • ✏️ contribs) 18:54, 20 May 2024 (UTC)
- There is also opportunity for graphs and images, so if you have any of value @Trizek (WMF) that would be amazing. Feel also free to comment direclty on the draft's talk page. Cocobb8 (💬 talk • ✏️ contribs) 18:55, 20 May 2024 (UTC)
- @Trizek (WMF) and @Schazjmd, I have started a Signpost draft. Please, feel free to edit it and add to it (anyone, really)! The more people who have some things to add, the better chances are we can have a successful Signpost news story to share :). Cocobb8 (💬 talk • ✏️ contribs) 18:54, 20 May 2024 (UTC)
- Nice idea! Let me know how I can assist you there @Cocobb8. I can find facts and data, but also stories to share. Trizek_(WMF) (talk) 17:05, 20 May 2024 (UTC)
- @Cocobb8, me neither, but they do have a quick-start guide. Schazjmd (talk) 17:05, 20 May 2024 (UTC)
- @Schazjmd Neat idea as well, I would support that! I have no experience in writing/proposing anything for the signpost though. Cocobb8 (💬 talk • ✏️ contribs) 17:01, 20 May 2024 (UTC)
- I have added the mentorship on the Task Center. Cocobb8 (💬 talk • ✏️ contribs) 19:10, 20 May 2024 (UTC)
- @Cocobb8, rather than a mass message, if might be more effective to try Snowball sampling. Imagine a template that's easy to post on someone's talk page that says something like this:
Seeking mentors for new editors The homepage needs new mentors. Mentors are important because... If you're interested in helping new editors learn how to become productive contributors, please take action... If you know someone that would make a great mentor, please invite them by adding {{subst:Snowball}} to their talk page.
- The overall idea is that a semi-personal invitation from someone you know might be more effective than impersonal spam. WhatamIdoing (talk) 19:29, 20 May 2024 (UTC)
- Great point, that might be more effective and there would be no need for consensus before posting on talk pages. I'm not really good at creating templates though, but what you proposed looks pretty good! Cocobb8 (💬 talk • ✏️ contribs) 19:31, 20 May 2024 (UTC)
- The important part is writing good text. You probably need:
- a brief explanation of what it is,
- a reason why this is important,
- a specific, straightforward action that they should take, and
- a talk page where they can ask questions.
- The format above is just a table. I copied it from one of the Wikipedia:Barnstars. WhatamIdoing (talk) 05:50, 25 May 2024 (UTC)
- The important part is writing good text. You probably need:
- Great point, that might be more effective and there would be no need for consensus before posting on talk pages. I'm not really good at creating templates though, but what you proposed looks pretty good! Cocobb8 (💬 talk • ✏️ contribs) 19:31, 20 May 2024 (UTC)
- The overall idea is that a semi-personal invitation from someone you know might be more effective than impersonal spam. WhatamIdoing (talk) 19:29, 20 May 2024 (UTC)
Wikipedia:Naming conventions (royalty and nobility) - RfC drafting for reversion of the November 2023 change
In November 2023, NCROY was altered by consensus to instruct editors to not disambiguate royalty and nobility with their geography unless disambiguation is required.
This has proven controversial with some editors arguing that the result does not reflect the consensus of the broader community; there has been considerable disruption as a result of this.
To resolve this I believe a second, broadly advertised, RfC would be beneficial; this would be held at the Village Pump, be listed at WP:CENT, and ping all the editors involved in the recent RfC as well as any relevant RM's. One way or the other, this should provide a path to resolving this dispute; I am opening this discussion to help draft it with the intent of opening it once the current ArbCom case request closes.
My initial proposed question is:
Should our naming convention on royalty and nobility instruct editors to generally disambiguate royalty and nobility with their geography, unless there is an "overwhelming commonname"?
The context for this discussion includes:
- A November 2023 RfC consensus instructing editors to disambiguate only if disambiguation is required.
- A May 2023 ArbCom case request that raised concerns about disruption in the topic area. This case lists a number of recent requested moves and move reviews.
- A village pump discussion drafting this RfC.
BilledMammal (talk) 05:11, 13 May 2024 (UTC)
- It's a good question, in my opinion. Deb (talk) 10:18, 13 May 2024 (UTC)
- First thought: I'm not convinced that the RFC should lump royalty and nobility together. The changes made following the November RFC related only to monarchs. Non-ruling nobility are a different kettle of fish with their own issues, but if we want to avoid getting sidetracked it would be best to keep the focus on monarchs only at this point IMO. Rosbif73 (talk) 07:38, 13 May 2024 (UTC)
- I'm not sure that the proposal quite captures the nature of the opposition. In at least some of the RMs the dispute is whether NCROY is more, less or equally important than other guidelines (e.g. WP:PRECISE, WP:RECOGNISABLE, WP:PRIMARY, WP:COMMONNAME). I think a better question would be something like "Should articles about monarchs include a geographical element in the title when it would be unambiguous without it (e.g. "Oliver III" or "Oliver III of Montenegro")?" The possible answers to that should be "(almost) always", "sometimes" and "(almost) never". Including the "sometimes" option is important, further discussion would probably be needed (if that gets consensus) to determine whether there should be guidance (and if so what) about when to include and when not to inlcude. Thryduulf (talk) 09:08, 13 May 2024 (UTC)
- @User:BilledMammal Thank you for the initiative.
- For pragmatic reasons, I'd also like to consider the possibility of a carve-out for British monarchs and/or 20th Century monarchs (or some other arbitrary date). We're searching for a norm that is workable for thousands of articles, across two thousand years of history, covering hundreds of countries, serving readers from all across the globe. The search for a workable norm should not be held hostage to nationalist squabbles of recent or local interest.
- It should also consider the matter of variant spellings of names. Monarch names are usually translated in reliable sources, often in a variety of ways (Louis, Luis, Ludwig, Ludovico, Luigi, Lajos, Lodewijk etc. are all the same name). Wikipedia readers come from all sorts of backgrounds, using different sources with different spellings, and they should not have to guess which language or spelling Wikipedia editors happened to choose. The aforementioned "Oliver III" is the same name as "Olivier III".
- Expanding the norm with full designation "king" should be considered. That is, to obtain "Oliver III, King of Montenegro", or "King Oliver III of Montenegro" or "King Oliver III" (which is how he is usually referred to in most RSs, e.g. Britannica, indexes of books, etc.). This would be consistent with how we treat non-numeral monarchs (e.g. "John, King of England"), and practically all nobility and peers articles ("Geoffrey II, Count of Anjou", "William Cavendish-Bentinck, 3rd Duke of Portland" etc.). I expect this would not find much support among minimalists. But maybe should be an option to consider. It would be particularly useful for such unrecognizables as Nicholas II (Who? Pope? King? Duke? Rocket? Ship? Movie? Hedge fund?), who would be instantly recognizable as "Tsar Nicholas II".
- On Sovereign vs. Nobility. Clarification needs to be made for non-sovereign German & Italian nobles, who some editors oddly think or treat as sovereigns, and try to apply WP:NCROY rather than WP:NCPEER (weirdly arguing that NCPEER only applies to British). And if they are treated as sovereigns, then does this apply also to great French nobles, Polish nobles, Danish nobles, etc.? If the norms are going to be different, then it needs to be clear who is sovereign and who is nobility.
- On Big vs. Small Countries. This came up in RMs. If shortening is permitted, what, if any, safeguards will there be for small countries? Or shall big famous countries (Great Britain, France, etc.) be allowed to dominate the titling? In the previous norm, "Oliver III of France" is on equal footing with "Oliver III of Montenegro" - article titles are distinct, neither primary over the other. But with shortening, which is the WP:PRIMARYTOPIC for "Oliver III"? The current post-RFC says to keep country "when disambiguation needed", but nonetheless that was not respected. Once shortening was allowed there was an immediate spate of RMs to move the kings of large countries as primary at the expense of small countries (or other units - e.g. Tsars are apparently primary over Popes for some reason). France is a big country, with a large population, and a lot more history books written about it, whereas Montenegro is a small country with fewer works on it. So if allowed to shorten, then it is very easy for RMs to insist that the French king is "primary topic" for "Oliver III", and relegate the Montenegrin Oliver III. I don't think Wikipedia should be setting up a norm that reinforces the dominance or superiority of big countries over small countries. The insinuation is disturbing: "my king is more important than your king", "my country is large & important, yours is small & irrelevant" etc. This is not something Wikipedia guidelines should endorse, in an international encyclopedia, written for a global audience. It is not only distasteful in itself, it it also setting up a pig's breakfast that will feed a lot of horrific nationalist squabbles (France over Sweden, Great Britain over Georgia, Serbia over Montenegro, Spain over Portugal, Russia over Ukraine, etc.). So I'd like the proposal to contain CLEAR safeguards that prevent large country monarchs from dominating titling, and protect monarchs of small countries from being relegated to second tier status. Walrasiad (talk) 10:32, 13 May 2024 (UTC)
- If one of the contenders for a primary topic features much more prominently in the history books (or other reliable sources) than all the others, then it is normal for them to be considered primary. Sure, in many cases that will appear to favour "big countries", but there are also cases where the sources show a prominent monarch from a "small country" to be of greater long-term significance than their namesakes from larger countries. In all cases, primacy on Wikipedia is simply a reflection of primacy in sources, not any form of judgement on the relative importance of the countries. The only safeguards that are needed are already laid down in WP:PRIMARYTOPIC. Rosbif73 (talk) 13:21, 13 May 2024 (UTC)
- Regarding translation / variant spellings of names, Wikipedia should simply reflect the preferred spelling in reliable English-language sources. It is perfectly normal, per WP:SMALLDIFFERENCES, for Maria I to be a different person than Mary I. It is also normal to find Philip V but Felipe VI, because the norms in English-language sources have changed over time. Any potential confusion can and should be cleared up via standard wiki mechanisms such as hatnotes and short descriptions. Rosbif73 (talk) 13:49, 13 May 2024 (UTC)
- Strongly disagree with both your points.
- (1) Deliberately introducing large country bias should not be acceptable in Wikipedia guidelines, for both moral and practical reasons. (WP:SYSTEMICBIAS). There are ways of avoiding it. I would hope for a better answer than that.
- (2) You can title the article as per RSs. But you can't rely on "small differences" when the sources Wikipedia readers are coming from use many variations. Readers of Wikipedia can be expected to read & understand English. They should not be also expected to know Romanian, Danish, Portuguese, etc. and certainly not be demanded to guess the idiosyncratic tastes of Wikipedia editors. Walrasiad (talk) 14:16, 13 May 2024 (UTC)
- You raise some points that will be worthwhile to consider - but we also need to keep in mind that the primary goal is to conclusively resolve whether editors who oppose the recent moves are correct that the November 2023 RfC did not reflect community consensus.
- Because of that I want to keep the primary question of the RfC simple, so that this question can be clearly answered - if the primary question starts to deviate too far from the pre-RFC status quo then it will become unclear whether the community opposes recommending geographical disambiguation even when otherwise not required, or whether the community merely opposes the additional changes proposed in that RfC.
- However, if we are going to run a widely advertised RfC then it may be appropriate to make the RfC a multi-part one, to take full advantage of that attention - are any of your points part of long-running disputes that it would be helpful to bring the broader communities attention to? BilledMammal (talk) 17:41, 13 May 2024 (UTC)
- I think we should almost certainly phrase this in terms of an example. Using Louis XVI, the question would be:
In the absence of a need to disambiguate, how should we title the articles of monarchs?
- Louis XVI
- King Louis XVI
- Louis XVI of France
- King Louis XVI of France
Loki (talk) 13:34, 13 May 2024 (UTC)
- I like this formulation because I find it very easy to understand. But whether the rule (whatever it may be) should apply to monarchs or nobles or both, and whether it should apply to all monarchs/nobles or just some, seem to be live issues? I also think the polling should be set up as ranked voting so people can express a preference for, e.g., 3/4 over 1/2 (include geography regardless of title), or 1/3 over 2/4 (exclude title regardless of geography), or 1>2/3>4 (less is better), or 4>2/3>1 (more is better), etc. Levivich (talk) 14:57, 13 May 2024 (UTC)
- Having read WP:NCROY more closely, I would like to also add
5. Louis XVI, King of France
as a possibility, to match what it currently recommends for monarchs with a title lower than king. Loki (talk) 21:19, 13 May 2024 (UTC)
- Having read WP:NCROY more closely, I would like to also add
- I like this phrasing. I would adjust it slightly, though, to include both the general description and the example:
In the absence of a need to disambiguate, how should we title the articles of monarchs?
- Regnal name and nominals; eg Louis XVI
- Title, regnal name, and nominals; eg King Louis XVI
- Regnal name, nominals, and realm; eg Louis XVI of France
- Title, regnal name, nominals, and realm; eg King Louis XVI of France
If you support multiple, please rank your preferences. If the closer finds it necessary to resolve preferences, they will resolve them through the single transferable vote method.
- This also includes Levivich's suggestion of ranked voting; I've also added a proposed method for resolving the preferences, as previous ranked !votes have resulted in disputes over the method used - by specify it at the start we should be able to avoid that. BilledMammal (talk) 17:52, 13 May 2024 (UTC)
- Should we really be envisaging a poll (single transferable vote or otherwise) rather than the usual assessment by the closer of policy-based arguments? WP:VOTE reminds us that the use of polls is
often controversial and never binding
. Rosbif73 (talk) 19:05, 13 May 2024 (UTC)- I agree that the only allusion to voting we should have is an instruction to rank choices. Saying the closer will resolve "votes" in any particular way mistakes how RFCs work. While they can feel similar to votes from the perspective of the participants, from the perspective of the closer they're very clearly not votes. Loki (talk) 02:29, 14 May 2024 (UTC)
- While I understand the impulse here, in my view the actual effect of including the description is to add a bunch of extra jargon that's completely redundant with the examples. Loki (talk) 02:32, 14 May 2024 (UTC)
- How about
Levivich (talk) 02:47, 14 May 2024 (UTC)- Louis XVI (regnal name and nominals)
- King Louis XVI (title, regnal name, and nominals)
- Louis XVI of France (regnal name, nominals, and realm)
- King Louis XVI of France (title, regnal name, nominals, and realm)
- Louis XVI, King of France (regnal name, nominals, title, and realm)
- I like that a lot better. I'm still not convinced the description is necessary, but I'd accept it. Loki (talk) 03:37, 14 May 2024 (UTC)
- What about Louis XVI (king of France) (following standard practice, no special rules for monarchs) or Louis XVI (France) (how German WP does it)? Not all options would be possible for every king, since some names are ambiguous. We have to distinguish between the question of how to handle kings like Henry IV (which one?) and Louis XVI (no question of primary topic). Srnec (talk) 15:45, 14 May 2024 (UTC)
- At this time, I have no comment on which of Loki's proposals may be the "best". However, after seeing the comment on German Wikipedia article titling, I do want to the note that according to WP:CONSISTENT (emphasis mine):
The English Wikipedia is ... under no obligation to use consistent titles with other language versions of Wikipedia.
AndrewPeterT (talk) (contribs) 15:54, 14 May 2024 (UTC)- The English Wikipedia is indeed under no obligation to be consistent with other language Wikipedias, however that is irrelevant to Srnec's comment. If another language Wikipedia solves a problem in a certain way, it is entirely reasonable to suggest including that way in a list of options for how to solve that same problem on the English Wikipedia. Thryduulf (talk) 21:28, 14 May 2024 (UTC)
- At this time, I have no comment on which of Loki's proposals may be the "best". However, after seeing the comment on German Wikipedia article titling, I do want to the note that according to WP:CONSISTENT (emphasis mine):
- What about Louis XVI (king of France) (following standard practice, no special rules for monarchs) or Louis XVI (France) (how German WP does it)? Not all options would be possible for every king, since some names are ambiguous. We have to distinguish between the question of how to handle kings like Henry IV (which one?) and Louis XVI (no question of primary topic). Srnec (talk) 15:45, 14 May 2024 (UTC)
- How about
- Should we really be envisaging a poll (single transferable vote or otherwise) rather than the usual assessment by the closer of policy-based arguments? WP:VOTE reminds us that the use of polls is
- On a slight tangent, I note that my proposal to change the guideline's name to "Naming conventions (European royalty and nobility)"—to better reflect what the guideline purports to be—received no input: any thoughts now? ~~ AirshipJungleman29 (talk) 17:36, 13 May 2024 (UTC)
- Since this issue is different from what the potential RfC seeks to address, I will comment on this: Yes, I support this change to the guideline's title (and creating a shortcut like WP:NCEUROY accordingly). And I would even go further to retitle the guideline Naming conventions (post-classical European royalty and nobility). Simply stated, it is Eurocentrism and/or WP:BIAS to attempt to conform article titles like Emperor Kinmei, Nawaf Al-Ahmad Al-Jaber Al-Sabah, or even Claudius to WP:NCROY as written. AndrewPeterT (talk) (contribs) 18:54, 13 May 2024 (UTC)
- The guideline notes all those exceptions and points editors to the right places for guidance. —Compassionate727 (T·C) 00:29, 14 May 2024 (UTC)
- In this case, the European guideline shouldn't have a generic title that makes it appear to be the "default" for royalty naming conventions. Chaotıċ Enby (talk · contribs) 19:48, 14 May 2024 (UTC)
- The guideline notes all those exceptions and points editors to the right places for guidance. —Compassionate727 (T·C) 00:29, 14 May 2024 (UTC)
- Since this issue is different from what the potential RfC seeks to address, I will comment on this: Yes, I support this change to the guideline's title (and creating a shortcut like WP:NCEUROY accordingly). And I would even go further to retitle the guideline Naming conventions (post-classical European royalty and nobility). Simply stated, it is Eurocentrism and/or WP:BIAS to attempt to conform article titles like Emperor Kinmei, Nawaf Al-Ahmad Al-Jaber Al-Sabah, or even Claudius to WP:NCROY as written. AndrewPeterT (talk) (contribs) 18:54, 13 May 2024 (UTC)
- One other point worth clarifying is the definition of "Europe" (assuming that the November 2023 change is preserved). There were some recent RMs over Georgian monarchs for which it was disputed whether Georgia was a European country. -- King of ♥ ♦ ♣ ♠ 17:41, 13 May 2024 (UTC)
- If we are going to include multiple questions I like the idea of focusing on ones that will apply regardless of the result of the primary question, such as the question you raise here. BilledMammal (talk) 17:53, 13 May 2024 (UTC)
- The introduction to NCROY sets out its scope as being European monarchs that share a set of given names, and tells us that
elsewhere, territorial designations are usually unnecessary in article titles
. Georgia is something of a special case: some of its monarchs share given names (Stephen, David, George, Michael, Alexander, Constantine, Simon) with western European monarchs, but most do not. The important point is the namestock, not the geographical location. Rosbif73 (talk) 19:34, 14 May 2024 (UTC)- Indeed, it may be worth amending the guideline to explicitly apply to all names following the (name)(ordinal)[of territory] pattern, because Georgia is not the only non-European example of this. (E.g., Musa III [of Mali]). —Compassionate727 (T·C) 16:16, 26 May 2024 (UTC)
- Yep. If the proposed RfC takes place and confirms the current status (i.e. use a territorial designation only if disambiguation is necessary) then we really ought to review the entire guideline. As it stands, the November RfC was implemented by making a minimal change to the wording, and some of the provisions in the introduction could do with being revised for consistency. Rosbif73 (talk) 06:30, 27 May 2024 (UTC)
- Indeed, it may be worth amending the guideline to explicitly apply to all names following the (name)(ordinal)[of territory] pattern, because Georgia is not the only non-European example of this. (E.g., Musa III [of Mali]). —Compassionate727 (T·C) 16:16, 26 May 2024 (UTC)
- BilledMammal, thank you for taking the time to start this conversation. Because my previous comments on this topic (namely in a previous November 2023 request for comment (RfC) on this same matter) have received negative feedback, I have no comment on the scope of potential new RfC at this time. My only hope is that the community will finally be at a mutually agreeable place with WP:NCROY after this discussion concludes, however long it takes. AndrewPeterT (talk) (contribs) 18:43, 13 May 2024 (UTC)
- That being said, should a notice at WP:AN to invite an uninvolved administrator to monitor and close this possible RfC be posted? This way, any problematic conduct can be immediately addressed. AndrewPeterT (talk) (contribs) 18:43, 13 May 2024 (UTC)
- I would also note that
European monarchs whose rank is below that of emperor or king
(i.e. those of the tiny German states in the Holy Roman Empire) follow the different notational standard established in WP:NCROY#5 ([Name] [Ordinal if applicable], [Title] of [Primary holding]; ex. Maximilian I, Elector of Bavaria or Casimir, Margrave of Brandenburg-Kulmbach). So the latest proposed RfC questionIn the absence of a need to disambiguate, how should we title the articles of monarchs?
may more accurately be titled something along the lines of[...] how should we title the articles of European imperial and royal monarchs?
. Curbon7 (talk) 20:53, 13 May 2024 (UTC) - I think all of the above is skirting the real issue. The scope here is only those articles where the COMMONNAME for the subject does not include regional information ("of country") and is sufficiently PRECISE to distinguish from other uses (i.e., the COMMONNAME is either unique or this use is the PRIMARYTOPIC for the COMMONNAME). That is, if usage in RS demonstrates that including the regional information is the COMMONNAME, or the regional information is necessary for disambiguation because the COMMONNAME is not unique and this use is not primary for this COMMONNAME, then there is no issue about including the regional information. So the RfC question should reflect exactly that:
When the COMMONNAME for a sovereign or royalty subject does not include "of country" regional information, and the COMMONNAME is unique, or the subject is primary for its COMMONNAME, should we ever include "of country" information in the title? If so, when and why?
- Of course, people can also disagree about what the COMMONNAME is based on usage in RS, but in those cases CONCISION is an excellent and convenient tie-breaker, favoring leaving off the regional information. Similarly, there can be disagreement about whether a given use is primary for the COMMONNAME in question, but that's no different than for any other article with an ambiguous COMMONNAME and there is debate about whether the topic is primary, and is not a problem unique to NCROY. So we don't need to be concerned with addressing those cases in this guideline.
- --В²C ☎ 03:41, 17 May 2024 (UTC)
- As I asked elsewhere, can you provide any actual examples of sovereigns whose regnal name would be unambiguous without a territorial designation but whose COMMONNAME unequivocally includes one? If not, then this issue is moot and should be kept out of the guideline to avoid future contention. Rosbif73 (talk) 06:41, 17 May 2024 (UTC)
- I wanted to account for the possibility for such cases. But if you want to assume there are none, fine:
When the COMMONNAME for a sovereign or royalty subject is unique, or the subject is primary for its COMMONNAME, should we ever include "of country" information in the title? If so, when and why?
- —
- В²C ☎ 23:05, 17 May 2024 (UTC)
- I wanted to account for the possibility for such cases. But if you want to assume there are none, fine:
- As I asked elsewhere, can you provide any actual examples of sovereigns whose regnal name would be unambiguous without a territorial designation but whose COMMONNAME unequivocally includes one? If not, then this issue is moot and should be kept out of the guideline to avoid future contention. Rosbif73 (talk) 06:41, 17 May 2024 (UTC)
- I think that the missing piece of context is: A lot (most? nearly all?) of the individual RMs since that November RFC have come to the opposite conclusion. It's bad form to have a rule saying the opposite of what the community wants to do. WhatamIdoing (talk) 23:16, 17 May 2024 (UTC)
- The majority of the decisions have been consistent with NCROY since it was revised. —В²C ☎ 12:49, 24 May 2024 (UTC)
- That's obscuring that many of the decisions have been highly controversial and there have been comments that support moves to match NCROY with the sole purpose of matching NCROY rather than any opinion about whether that is best - indeed I've seen at least one comment that supported a move to match NCROY despite the editor thinking that was an inferior title. Thryduulf (talk) 16:28, 24 May 2024 (UTC)
- That may be, but presumably most editors who supported "per NCROY" like the guideline's prescription. Those who dislike it have been vocal enough. —Compassionate727 (T·C) 22:24, 25 May 2024 (UTC)
- Maybe, maybe not. We have insufficient evidence to say one way or the other. Thryduulf (talk) 00:23, 26 May 2024 (UTC)
- That may be, but presumably most editors who supported "per NCROY" like the guideline's prescription. Those who dislike it have been vocal enough. —Compassionate727 (T·C) 22:24, 25 May 2024 (UTC)
- That's obscuring that many of the decisions have been highly controversial and there have been comments that support moves to match NCROY with the sole purpose of matching NCROY rather than any opinion about whether that is best - indeed I've seen at least one comment that supported a move to match NCROY despite the editor thinking that was an inferior title. Thryduulf (talk) 16:28, 24 May 2024 (UTC)
- The majority of the decisions have been consistent with NCROY since it was revised. —В²C ☎ 12:49, 24 May 2024 (UTC)
Inflation template
The template is a terrific idea, but can give ludicrously precise quotients. An example I recently came across in the Miles Davis article:
- ". . . leaving Davis to pay over $25,000 (equivalent to $251,800 in 2023)"
It's a basic principle that the solution of a conversion should not have a greater degree of precision than that of the supplied data. That applies to measurements where the conversion factor is known with a high degree of accuracy, but of course depreciation of the value of currency depends on the medium of exchange, be it gold or a tradesman's wages. In an improved template, the above should, by default, read:
- ". . . leaving Davis to pay over $25,000 (equivalent to roughly $250,000 in 2023)" (my bolding)
with the option for the editor to increase or decrease the level of precision for special purposes. Doug butler (talk) 14:50, 14 May 2024 (UTC)
- IMO {{inflation}} should be deleted and Wikipedia shouldn't be in the business of calculating inflation. {{inflation/US}} uses the Consumer price index (CPI). The problems with using CPI to measure inflation are extremely well-reported, so much so that even the Bureau of Labor Statistics, which published CPI in the US, has said
The CPI cannot claim to be a completely precise measure of inflation and publishes the variance of its estimates.
{{inflation/US}}, however, doesn't present the figure as a range, it provides a calculation, leading to false precision (on top of the problems with using CPI in the first place). I have no idea what {{inflation}} uses for countries other than the US or how accurate it is. And I don't know how often the numbers are updated or with what precision or what the qualifications are of the editors who are doing the updating. If you ask me, the templates should be deleted, we are basically misinforming the reader when we say that $X in year Y is equal to $Z today. Such statements should be cited to reliable sources, not to CPI calculations by editors. It's WP:OR. Levivich (talk) 15:21, 14 May 2024 (UTC)- Well, if you don't know (and cannot be bothered to look up) anything about the template, how it works, where the information comes from, or how it's computed, why would your opinion about it be useful or relevant? jp×g🗯️ 04:03, 15 May 2024 (UTC)
- FWIW, I fully agree with you on this. —Compassionate727 (T·C) 16:25, 26 May 2024 (UTC)
- I would agree. If I recall correctly, the inflation template does some amount of rounding (either by default or as an option, I can't remember) so as to avoid false precision of this sort. jp×g🗯️ 04:05, 15 May 2024 (UTC)
- The template already has a parameter to round the output -
r=
, see Template:Inflation#Rounding so what the OP is really asking is to change the default from unit precision to the same precision as the source data. Given that it is not possible for the template to know the precision of an input (e.g. is £2000 accurate to 1, 2, 3 or 4 figures?) the option to specify a non-default level of precision is always going to be required. - All pages that currently correctly use the default precision would need to be adjusted to explicitly specify that before changing the default so as to avoid introducing inaccuracies. Given that there is no automatic way to know which articles are using the default correctly and which are using it incorrectly, every such usage would need to be examined by a human. That would be a very large job, for not really much benefit. Thryduulf (talk) 08:23, 15 May 2024 (UTC)
- The template already has a parameter to round the output -
- I agree that inflation figures usually need rounding, but it is difficult to get the default right. Whenever you see this type of false precision, WP:SOFIXIT by using the parameter as suggested by Thryduulf. —Kusma (talk) 09:18, 15 May 2024 (UTC)
- Yep. — SMcCandlish ☏ ¢ 😼 18:20, 15 May 2024 (UTC)
- I've marked it as such in the templatedata. Aaron Liu (talk) 18:27, 15 May 2024 (UTC)
- It would surely be possible to automatically calculate the number of significant figures in the input and by default round to the same. —Compassionate727 (T·C) 00:23, 26 May 2024 (UTC)
- It isn't possible to reliably calculate the number of significant figures in the input without the context from the source material. For example "It cost £2000" could be accurate to 1, 2, 3 or 4 significant figures. Thryduulf (talk) 00:34, 26 May 2024 (UTC)
- Nobody on Wikipedia uses scientific notation or "$4000. blabla were lost." with that dot. Aaron Liu (talk) 01:17, 26 May 2024 (UTC)
- Good points. However, I do think that for numbers ending in some quantity of zeroes, it would probably be okay to round by default to the corresponding number of preceding digits, especially given the vagaries inherent in inflation calculation. —Compassionate727 (T·C) 16:23, 26 May 2024 (UTC)
- Hmm, good point. I guess the user could always specify if it's different. Aaron Liu (talk) 19:34, 26 May 2024 (UTC)
- Good points. However, I do think that for numbers ending in some quantity of zeroes, it would probably be okay to round by default to the corresponding number of preceding digits, especially given the vagaries inherent in inflation calculation. —Compassionate727 (T·C) 16:23, 26 May 2024 (UTC)
Revisiting date auto-formatting
Back in the late 2000s to early 2010s, we had a feature by which dates were auto-formatted. This ended up leading to a bunch of strife, and the feature was turned off. This happened because the feature (implemented as a MediaWiki parser function) relied upon linking, such that every date was a link, and it caused a "sea of blue" problem.
With the advent many years ago of Lua modules, it seems that we could do this better now, untied in any way to linking. We already have Lua code in various templates (as well as Javascript code in user scripts) that can parse most dates. So, it seems to me that it would be beneficial to have something like the following:
- Parse all sane date formats, from 1852-02-08 to 8th February 1852 to Feb. 8, 1852 to 8-FEB-1852, and so on.
- Exclude material between quotation marks or inside a quotation template.
- Flag as errors any instances that cannot be unambigously parsed, e.g.
- Provide an "ignore" wrapper template that can be used around things that appear to be (or contain) dates but should not be parsed as such (e.g. a serial number that is coincidentally in the format 1852-02-08, or a book titled On Feb. 8, 1852.
- Identify templates like
{{use mdy dates}}
, etc., at the top of the page and "obey" them, to normalize all dates to the prescribed format for that page.- If there isn't one, but there is a
{{Use X English}}
template, pick the date format that conventionally matches the specified country name. - If both of the above conditions fail, then do some statistical analysis, and normalize dates to whatever date format already dominates in the article (other than ISO's YYYY-MM-DD, which is not human-friendly for our readers).
- If there isn't one, but there is a
- Read a preferences setting, for logged in users, and override the display of dates to whatever the user set as their preference.
- Use a bot to replace all the non-excluded dates in the code with a single canonical format (probably ISO).
The results of this would be:
- An end to the need to keep re-re-re-normalizing dates (manually or by script) in an article back to the format specified in
{{use xxx dates}}
. (The dates always become inconsistent over time because various citation tools that people use only output a single format, or have an option to pick one that people don't bother to use, or people are writing entirely manually and use the date format they like better without regard to the rest of the article content). - Article source code that is better for WP:REUSE purposes, with consistent dates that can be reformatted by reusers in an automated manner as they see fit.
- Articles with consistent date display, matching whatever is set by the article-top template.
- Ability of readers who really, really like one particular format to impose it on their personal WP experience.
— SMcCandlish ☏ ¢ 😼 18:17, 15 May 2024 (UTC)
- WHAT HAVE YOU DONE WITH SANDY MCCANDLISH? EEng 18:25, 15 May 2024 (UTC)
- That sounds better suited as a configured mw:Writing systems/LanguageConverter than basically a specific version of zhwiki's NoteTA, though both would work, and Lua does seem like the language more popular here than PHP. Aaron Liu (talk) 18:31, 15 May 2024 (UTC)
- No, there is no need to revisit auto-formatting, for the reasons that were given when it was discontinued, but we should recognise that is some countries, such as the UK and India, either 8 February 1852 or February 8, 1852 is perfectly acceptable, with the addition of "th" to "8" also acceptable. Phil Bridger (talk) 20:24, 15 May 2024 (UTC)
- Given that the Chinese Wikipedia manages to allow people to switch between different varieties of Chinese with a single click, I have always found it a bit embarrassing that we can't even offer date formatting choices. A date autoformatter would need to be more powerful than the old one, though, and would need to be able to deal with date ranges (the old one could only do full dates). —Kusma (talk) 20:47, 15 May 2024 (UTC)
- I certainly see no harm in developing a tool that allows readers to choose a display for their own purposes. Starting with that functionality and getting it working reliably and consistently would likely be a useful first step towards implementing something broader.
- Rather than/as well as inferring things that look like dates in prose and marking things that aren't, having something like "Bob Smith ({{date|1852|February|8}} – {{date|1921|August|8}}) was a British politician. He served as Chancellor of the Exchequer from {{date|1890|March|1890}} to {{date|April|1894}}. He was president of the Imperial Society {{date range|1899|-|1908|April}}" a la semantic HTML may prove useful more broadly. Thryduulf (talk) 12:59, 16 May 2024 (UTC)
- I don't think this would work for "readers". See Read a preferences setting, for logged in users. The average reader does not have prefs settings.
- If I were going to mess with dates, it would be to specify in WP:BADDATE that unambiguous year–month combinations (e.g., 2024-05, which never means "this year through nineteen years in the past) are acceptable, and that it is concerned solely with what readers see, and definitely does not restrict the input for templates such as the CS1 citation templates.
- In other words, people shouldn't be manually replacing the ISO-approved "2024-05" to "May 2024" in citation templates, because the citation templates should detect the unambiguous dates and treat them exactly the same way they already convert the display of "2024-05-01" to "1 May 2024" or "May 1, 2024" (the choice is made automagically, based on the specified ENGVAR for the page). WhatamIdoing (talk) 23:34, 17 May 2024 (UTC)
The average reader does not have prefs settings.
Easy, default to converting to mdy. I also don't see how "2024-05" is relevant here. Aaron Liu (talk) 00:43, 18 May 2024 (UTC)- The problem to be solved is: "An end to the need to keep re-re-re-normalizing dates (manually or by script) in an article back to the format specified in
{{use xxx dates}}
." - Most of the dates that need to be re-re-re-normalized are in the citations (not in the words of the article). See Category:CS1 maint: date format for the current list.
- This problem could be solved by changing a bit of code in the citation templates. To be clear: nearly every article that appears in this category, or that has been in this category during the last few years, could have been prevented from appearing there by changing the citation template's code.
- The reason this change was rejected is because the maintainers of that code believe that MOS:BADDATE disallows editors from putting unambiguous, ISO 8601-compliant numeric year–month combinations in wikitext, even when the numeric form of the date would never be shown to a single reader. That is, they believe that the MOS will allow editors to type
|date=2024-05-01
in a citation template, so they can show "May 1, 2024" to readers (if the article is tagged asmdy
), but that the MOS does not allow editors to type|date=2024-05
and have "May 2024" shown to readers. - If you want to end "re-re-re-normalizing dates (manually or by script) in an article back to the format specified in
{{use xxx dates}}
, I suggest that you start with the problem that could be solved in two edits: a single edit to the MOS page, to officially reassure the template maintainers that it's 'legal', and a single to the citation template's main module, to implement the code (which AIUI already exists). WhatamIdoing (talk) 06:36, 18 May 2024 (UTC)- Well, that change would probably be put in tandem with this one, but only if this (automatic date conversion) is developed and passed. Aaron Liu (talk) 00:59, 19 May 2024 (UTC)
- I don't think that solving the citation problem needs to wait for solving the other problem. WhatamIdoing (talk) 04:37, 19 May 2024 (UTC)
- I don't think we should explicitly allow "2024-05" as a "good " date format. There could be an RfC about this small issue, though. Aaron Liu (talk) 13:04, 19 May 2024 (UTC)
- Why not? It's an officially accepted international standard. It cannot be confused with a date range. So why not use it? WhatamIdoing (talk) 19:31, 20 May 2024 (UTC)
- Huh, TIL ISO 8601 actually explicitly allows it. Aaron Liu (talk) 20:30, 20 May 2024 (UTC)
- 2024-05 cannot be confused with a date range, but 2004-05 can. That's why we disallow it. Headbomb {t · c · p · b} 09:44, 22 May 2024 (UTC)
- But we could allow the format for anything can't be confused that way (e.g., the years 1912 to 1999 and 2012 to 2099 + year–month combinations that can't be a range of years, such as 2010–09). I think the whole thing could be evaluated in a single line of regex. WhatamIdoing (talk) 05:48, 25 May 2024 (UTC)
- No, we really shouldn't, because as soon as you have a new date, you have to re-evaluate if the old date format is allowable or needs to be converted to something new, or have inconsistent date formats in an article, e.g.
- Headbomb {t · c · p · b} 12:28, 2 June 2024 (UTC)
- Allowing it would reduce that problem. We would go from today:
- 2009-01 produces a red error message that will have to be fixed by hand
- 2009-08 produces a red error message that will have to be fixed by hand
- 2009-23 produces a red error message that will have to be fixed by hand
- to
- 2009-01 automagically gets displayed as January 2009, which means the article has consistent date formats
- 2009-08 automagically gets displayed as August 2009, which means the article has consistent date formats
- 2009-23 produces a red error message that will have to be fixed by hand
- I'd rather have two automatically fixed than three broken. WhatamIdoing (talk) 00:24, 4 June 2024 (UTC)
- Allowing it would reduce that problem. We would go from today:
- But we could allow the format for anything can't be confused that way (e.g., the years 1912 to 1999 and 2012 to 2099 + year–month combinations that can't be a range of years, such as 2010–09). I think the whole thing could be evaluated in a single line of regex. WhatamIdoing (talk) 05:48, 25 May 2024 (UTC)
- Why not? It's an officially accepted international standard. It cannot be confused with a date range. So why not use it? WhatamIdoing (talk) 19:31, 20 May 2024 (UTC)
- I don't think we should explicitly allow "2024-05" as a "good " date format. There could be an RfC about this small issue, though. Aaron Liu (talk) 13:04, 19 May 2024 (UTC)
- I don't think that solving the citation problem needs to wait for solving the other problem. WhatamIdoing (talk) 04:37, 19 May 2024 (UTC)
- Well, that change would probably be put in tandem with this one, but only if this (automatic date conversion) is developed and passed. Aaron Liu (talk) 00:59, 19 May 2024 (UTC)
- The problem to be solved is: "An end to the need to keep re-re-re-normalizing dates (manually or by script) in an article back to the format specified in
- I'm a bit leery of this step:
Use a bot to replace all the non-excluded dates in the code with a single canonical format (probably ISO).
Wouldn't this entail making edits to every article on the project that contains a date of the format "11 November 1919" or "January 1, 1970"? Do we have any idea what the scope of that effort might be? I would expect at least a few hundred thousand articles, which people with large watchlists might get pretty annoyed about. Folly Mox (talk) 21:26, 18 May 2024 (UTC)- I also agree that that step is probably unnecessary. They're gonna get converted anyway. Aaron Liu (talk) 00:52, 19 May 2024 (UTC)
- For something like this, we need a special way to hide these edits from watchlists (something that will not hide other edits), where editors who do want to see them need to opt in and swear an oath that they won't complain about seeing these edits. We should solve the problem of annoying people with large watchlists, but we should not let this issue prevent large-scale improvements. —Kusma (talk) 08:56, 22 May 2024 (UTC)
- But why would we want to replace all the dates in the first place? Aaron Liu (talk) 11:27, 22 May 2024 (UTC)
- If we don't need to, that is fine. Currently there are people with scripts who annoy me greatly by replacing my beautiful ISO dates in citation templates with mdy or dmy although they are already displayed like that via
{{use dmy dates}}
. So apparently some people think we need to replace all dates. —Kusma (talk) 11:34, 22 May 2024 (UTC)- I agree, that is annoying. But the better solution would probably be to filter out edits that only change date formats. Aaron Liu (talk) 11:41, 22 May 2024 (UTC)
- If we don't need to, that is fine. Currently there are people with scripts who annoy me greatly by replacing my beautiful ISO dates in citation templates with mdy or dmy although they are already displayed like that via
- But why would we want to replace all the dates in the first place? Aaron Liu (talk) 11:27, 22 May 2024 (UTC)
- FYI, a
{{#dateformat:}}
magic word already exists to apply the preference. I don't think the preference is directly accessible in Lua, but you could useframe:callParserFunction{ name = '#dateformat', args = { date } }
to format dates according to the preference. Anomie⚔ 12:11, 19 May 2024 (UTC) - I'm very supportive of this entire proposal except for using a bot to update dates in articles (or any other changes to how dates should be entered in the source / editor behaviour). Today we accept any date format in citation templates and have them display in the proper format without any extra work from the editor; this works well today and it doesn't seem to cause any problems of having the article display dates in a different format (the article's "correct" format, in the future also a user preference) than what's entered in the source. This proposal would extend the functionality to any date in a "sane" format within the article body, without the need for any edits to the article content or any changes to editor behaviour. I also think the "Ignore" bit would take some work to minimize unintentional date reformatting (extending the proposed ignore logic to try to catch as many reasonable scenarios as possible where a date might be in a title or quotation). I would generally oppose any changes that require change to editor behaviour or bot edits (e.g. having dates structured in the source in a non-editor friendly format like {{date|1852|February|8}}). Consigned (talk) 08:19, 5 June 2024 (UTC)
- Who are these people who either don't understand or get seriously offended by dates, with the month being non-numeric, in the "wrong" format? I certainly haven't come across any. Phil Bridger (talk) 08:39, 5 June 2024 (UTC)
Make the edit request facility optional
An uncontroversial, "change X to Y" request can be done just as easily using a normal discussion thread. The edit request facility exists for low-activity protected articles where there is a need to summon an editor to handle the request; otherwise the request could sit unseen or ignored for years. In my experience, edit request is used far more often for changes that are not uncontroversial, and/or are not in the required "change X to Y" format. This is because users don't take the time to read the instructions presented to them in the request path.
It should be possible to turn off the edit request facility at articles where it isn't needed; i.e., articles that always have editors around. In such cases the edit request path could be replaced by instructions directing the user to the talk page (or saving them a step and presenting the same thing they would get by clicking "New section" at the talk page). ―Mandruss ☎ 22:31, 21 May 2024 (UTC)
- Well it is already optional and editors do make requests in text only. The template makes it formal and encourages identifying the exact change, although often not used correctly. Graeme Bartlett (talk) 22:52, 21 May 2024 (UTC)
- The use is optional; the facility is not. Again in my experience, editors are spending too much time rejecting "invalid" edit requests (which also wastes the requester's time).The facility summons an outside editor by placing the article in a maintenance category for that purpose. In my 10+ years at normal-activity articles, I've yet to see a request handled by such an outside editor. Rather, the request is invariably changed to answered=y by a "local" editor, removing the article from the category, before an outside editor arrives to handle it. So, for a normal-activity article, what's the point of the category or the facility? ―Mandruss ☎ 23:26, 21 May 2024 (UTC)
- Not every request-reviewer is that lazy. Quite a bit will engage in discussion. Aaron Liu (talk) 23:29, 21 May 2024 (UTC)
- And they will do so improperly, all the more reason to turn off edit requests. The edit request instructions are quite clear: "What an edit request IS NOT for: [...] making a comment or starting a discussion: go to the talk page [...]". Again, if discussion is the goal, there is already a way to do that. ―Mandruss ☎ 23:55, 21 May 2024 (UTC)
- Hmm. But should people new to a topic carry the burden of assessing whether a talk page is active? Aaron Liu (talk) 01:24, 22 May 2024 (UTC)
- I don't understand the question. If you're referring to the requesters, they wouldn't have to make that assessment. It would have already been made by the article's editors (or not). For example, the editors at Donald Trump would turn off the edit request facility and any user clicking "View source" on the article page would be directed to the talk page (or, as I said, the box would be presented to start a discussion thread). More precisely, they would be presented the option to start a discussion thread, just as they're presented the option to submit an edit request today (big blue button).And, again, if they don't seek discussion—if they have something clearly uncontroversial—a normal thread works equally well for that purpose. Heading: "Typo correction". Comment: "Please correct the spelling of 'envirmental' in the 'Climate change, environment, and energy' section. ~~~~". Done. The only material differences are (1) a more meaningful section heading, hopefully, (2) no need to change to answered=y, and (3) no maintenance category pointlessly involved. ―Mandruss ☎ 02:15, 22 May 2024 (UTC)
- Then just add the edit notice for articles where all edits will be controversial. I don't see why we should remove the ER facility, which is still perfectly good for uncontroversial edits. I don't see why editors already being available is a problem. Aaron Liu (talk) 11:31, 22 May 2024 (UTC)
- I don't understand the question. If you're referring to the requesters, they wouldn't have to make that assessment. It would have already been made by the article's editors (or not). For example, the editors at Donald Trump would turn off the edit request facility and any user clicking "View source" on the article page would be directed to the talk page (or, as I said, the box would be presented to start a discussion thread). More precisely, they would be presented the option to start a discussion thread, just as they're presented the option to submit an edit request today (big blue button).And, again, if they don't seek discussion—if they have something clearly uncontroversial—a normal thread works equally well for that purpose. Heading: "Typo correction". Comment: "Please correct the spelling of 'envirmental' in the 'Climate change, environment, and energy' section. ~~~~". Done. The only material differences are (1) a more meaningful section heading, hopefully, (2) no need to change to answered=y, and (3) no maintenance category pointlessly involved. ―Mandruss ☎ 02:15, 22 May 2024 (UTC)
- Hmm. But should people new to a topic carry the burden of assessing whether a talk page is active? Aaron Liu (talk) 01:24, 22 May 2024 (UTC)
- And they will do so improperly, all the more reason to turn off edit requests. The edit request instructions are quite clear: "What an edit request IS NOT for: [...] making a comment or starting a discussion: go to the talk page [...]". Again, if discussion is the goal, there is already a way to do that. ―Mandruss ☎ 23:55, 21 May 2024 (UTC)
- Not every request-reviewer is that lazy. Quite a bit will engage in discussion. Aaron Liu (talk) 23:29, 21 May 2024 (UTC)
- The use is optional; the facility is not. Again in my experience, editors are spending too much time rejecting "invalid" edit requests (which also wastes the requester's time).The facility summons an outside editor by placing the article in a maintenance category for that purpose. In my 10+ years at normal-activity articles, I've yet to see a request handled by such an outside editor. Rather, the request is invariably changed to answered=y by a "local" editor, removing the article from the category, before an outside editor arrives to handle it. So, for a normal-activity article, what's the point of the category or the facility? ―Mandruss ☎ 23:26, 21 May 2024 (UTC)
- @Mandruss:
The facility summons an outside editor by placing the article in a maintenance category for that purpose. In my 10+ years at normal-activity articles, I've yet to see a request handled by such an outside editor.
Can you please clarify what you mean by this. Many volunteers watch CAT:ESP and related pages and handle requests. RudolfRed (talk) 02:45, 22 May 2024 (UTC)- @RudolfRed: I'm sure they do, but I've never seen them handle one at an article that always has editors around to handle it. Not once in 10+ years. They simply can't get there fast enough, presumably because they are processing a FIFO queue containing a number of older requests. Even if they could, why bother them when they aren't needed? They have many requests to handle where they are needed. ―Mandruss ☎ 02:56, 22 May 2024 (UTC)
- There's a lot of high traffic articles here. In my experience handling well over 10,000 edit requests and patrolling all of the edit request queues, edit requests are often ignored by the regulars on well attended talk pages, and edit request patrollers handle requests on those articles very often. ScottishFinnishRadish (talk) 02:36, 25 May 2024 (UTC)
- Great. Then those articles would not turn off the edit request facility. Hence "optional". ―Mandruss ☎ 04:30, 25 May 2024 (UTC)
- There's a lot of high traffic articles here. In my experience handling well over 10,000 edit requests and patrolling all of the edit request queues, edit requests are often ignored by the regulars on well attended talk pages, and edit request patrollers handle requests on those articles very often. ScottishFinnishRadish (talk) 02:36, 25 May 2024 (UTC)
- Pages that are protected are normally of interest to many editors. So hopefully they are on watchlists. Also I expect that admins the protect, add the page to their watchlist so they can see any requests or edits. Graeme Bartlett (talk) 22:39, 23 May 2024 (UTC)
- That reads like an argument for eliminating the edit request facility entirely, which would be a step too far in my opinion. It's certainly not an argument against making the facility optional at article level. ―Mandruss ☎ 01:10, 24 May 2024 (UTC)
- And the argument is very wrong too. There are plenty of obscure protected pages. High-risk templates. MediaWiki-namespace pages. Gadgets like MediaWiki talk:Gadget-watchlist-notice-core.js, where even the edit request template itself has failed for two months. * Pppery * it has begun... 04:04, 24 May 2024 (UTC)
- @RudolfRed: I'm sure they do, but I've never seen them handle one at an article that always has editors around to handle it. Not once in 10+ years. They simply can't get there fast enough, presumably because they are processing a FIFO queue containing a number of older requests. Even if they could, why bother them when they aren't needed? They have many requests to handle where they are needed. ―Mandruss ☎ 02:56, 22 May 2024 (UTC)
- I implemented this a while ago per Wikipedia:Administrators' noticeboard/Archive334#Possible new tool/technique/procedure as {{Manual edit requests}}. It never got used then because the person who was advocating for it retired due to unrelated drama shortly after that discussion. * Pppery * it has begun... 04:04, 24 May 2024 (UTC)
- I still don't see why editors being already available is a problem. Aaron Liu (talk) 11:29, 24 May 2024 (UTC)
- You're choosing to frame this in a greatly oversimplified way that ignores points already made. I hate circular/repetitive discussion, and I suggest a re-read with more effort to see a different perspective. ―Mandruss ☎ 02:27, 25 May 2024 (UTC)
- I still don't see why editors being already available is a problem. Aaron Liu (talk) 11:29, 24 May 2024 (UTC)
- Bump. It's been said, not by me, that Idea Lab is where good ideas go to die. ―Mandruss ☎ 21:48, 5 June 2024 (UTC)
- Even if that's true, I don't think the precondition is met for this one.Suppressing the normal edit request mechanism IMO should only be done for pages where it makes it too easy for confused users to make completely misplaced edit requests (e.g. all the people who used to wind up at Template talk:Reflist trying to add references to some particular article, or Help talk:Edit summary trying to add a summary to their edit). If people are using it to make appropriate requests, even if malformed and even if the article always has editors around, then it's not a problem. Especially in the "always has editors around" case, those editors can handle it.Above you complain about
Rather, the request is invariably changed to answered=y by a "local" editor, removing the article from the category, before an outside editor arrives to handle it
, which IMO is the mechanism working as intended: an editor answers the request and sets answered=y. Just because that happens to be an editor who'd have seen it anyway because they watch the page is not a "problem" that needs fixing. Anomie⚔ 11:22, 6 June 2024 (UTC)- The point is that, where there is no need to summon someone via the category, there is no need for the facility. That's it. In my nine years at the perpetually-protected Trump article, perhaps one in twenty edit requests have resulted in an edit to the article—and it could have been done using a normal thread. The other nineteen have been malformed, controversial, attempts to start discussion, or requests for permission to edit the article directly. That is a distracting waste of resources too easily avoided. ―Mandruss ☎ 12:12, 6 June 2024 (UTC)
- It's not that I don't understand your point. It's that I disagree that removing the edit request pre-fill would make things better, outside of your own personal annoyance at seeing the edit request template. You or other editors on the page are free to retitle sections and mark the "bad" request as answered when you answer them. Anomie⚔ 12:46, 6 June 2024 (UTC)
- The point is that, where there is no need to summon someone via the category, there is no need for the facility. That's it. In my nine years at the perpetually-protected Trump article, perhaps one in twenty edit requests have resulted in an edit to the article—and it could have been done using a normal thread. The other nineteen have been malformed, controversial, attempts to start discussion, or requests for permission to edit the article directly. That is a distracting waste of resources too easily avoided. ―Mandruss ☎ 12:12, 6 June 2024 (UTC)
- Even if that's true, I don't think the precondition is met for this one.Suppressing the normal edit request mechanism IMO should only be done for pages where it makes it too easy for confused users to make completely misplaced edit requests (e.g. all the people who used to wind up at Template talk:Reflist trying to add references to some particular article, or Help talk:Edit summary trying to add a summary to their edit). If people are using it to make appropriate requests, even if malformed and even if the article always has editors around, then it's not a problem. Especially in the "always has editors around" case, those editors can handle it.Above you complain about
idea for a new resource; "Town Hall"
I would like to suggest a new type of resource here for discussions. It would be called a "Town Hall." The purpose would be a place where wikipedians for various communities could have group discussions, centered on a particular field, i.e. based on topic.
- One main idea is that there would be various town halls centered around groups of active WikiProjects, based on their general topical category.
- Would also include any other groups of wikipedians who edit various topics, as a group.
- E.g. one town hall would be all wikipedians who work on wikiprojects focused on science. and another for all based around history. and another for all wikiprojects centered on specific places such as cities, countries, etc.
- a wikiproject would add the relevant Town Hall to their own page, by adding a new tab to their own tab header, where that Town Hall would be transcluded.
Ok so what do you think of that? Open to feedback. Thanks! Sm8900 (talk) 15:17, 23 May 2024 (UTC)
Comments on "Town Hall" idea
- I like the idea. Would it be for Wikipedia-related discussion or topic-focused discussion? Cocobb8 (💬 talk • ✏️ contribs) 15:29, 23 May 2024 (UTC)
- it would be mainly topic-focused discussion, but it would be as it relates to new efforts to add new entries to wikipedia, or refine existing entries, but the discussion itself would have a very broad scope and latitude, within the topic itself of course. and thanks for your reply!
Sm8900 (talk) 15:31, 23 May 2024 (UTC)
- I think this a great proposition because rn most discussion places have to be Wikipedia-related Cocobb8 (💬 talk • ✏️ contribs) 15:37, 23 May 2024 (UTC)
- it would be mainly topic-focused discussion, but it would be as it relates to new efforts to add new entries to wikipedia, or refine existing entries, but the discussion itself would have a very broad scope and latitude, within the topic itself of course. and thanks for your reply!
- We already have larger and more encompassing wikiprojects like Science, and many projects have task forces. I don't see the need, which will also require some infrastructure in guidelines. Aaron Liu (talk) 15:39, 23 May 2024 (UTC)
- I think the point that Sm8900 is making is that it would allow for discussion on the topic to happen, scuh that it wouldn't need to be related on specific articles to improve, Cocobb8 (💬 talk • ✏️ contribs) 15:41, 23 May 2024 (UTC)
- I don't think any stretch beyond reference desks would be accepted, due to WP:NOTFORUM. Aaron Liu (talk) 15:43, 23 May 2024 (UTC)
- Hmm good point. Cocobb8 (💬 talk • ✏️ contribs) 15:44, 23 May 2024 (UTC)
- I don't think any stretch beyond reference desks would be accepted, due to WP:NOTFORUM. Aaron Liu (talk) 15:43, 23 May 2024 (UTC)
- I think the point that Sm8900 is making is that it would allow for discussion on the topic to happen, scuh that it wouldn't need to be related on specific articles to improve, Cocobb8 (💬 talk • ✏️ contribs) 15:41, 23 May 2024 (UTC)
ok. any other comments? Sm8900 (talk) 16:30, 30 May 2024 (UTC)
Quantifying current consensus on LLM usage
Would User:Sohom Datta/LLM be a good description of current consensus in the area? Sohom (talk) 16:20, 23 May 2024 (UTC)
- I don't think there is anything close to a consensus yet, although that description is something I would personally agree with. Chaotıċ Enby (talk · contribs) 16:27, 23 May 2024 (UTC)
- Your statement generically covers any content: all submitted content must be checked for accuracy, including references, and all submitted content that conflicts with policy can be removed. isaacl (talk) 17:19, 23 May 2024 (UTC)
- Yes, definitely. I wanted to use it as a starting point to having a baseline policy/document on the usage of LLMs that we could point editors to. If there is a majority opinion/consensus that we need to do something stronger, I see that as a good outcome. Sohom (talk) 17:40, 23 May 2024 (UTC)
- My suggestion for a base line policy on the use of LLMs on Wikipedia: “Don’t”. Blueboar (talk) 12:48, 24 May 2024 (UTC)
- +1. Although Sohom's text is the closest formulation I've seen to what I think might be consensus. Levivich (talk) 14:09, 24 May 2024 (UTC)
- Agreeing too. And yes, in terms of consensus Sohom's proposal is a baseline we should be able to start with. Chaotıċ Enby (talk · contribs) 14:13, 24 May 2024 (UTC)
- Well, I agree with your comment in terms of creating new articles/new content. I'm less convinced that indirectly using LLMs to copyedit a paragraph is really that bad but I'm open to being proven wrong. Sohom (talk) 15:13, 24 May 2024 (UTC)
- Yes, I mostly had content generation in mind, although LLMs can add a lot of puffery when "copyediting" so that's also a risk. Chaotıċ Enby (talk · contribs) 15:15, 24 May 2024 (UTC)
- Yeah that's fair, I just saw the link you posted on the Discord (relevant link for peeps not on Discord) and I'm now less confident of that statement :) There are ways (anecdotally) of prompt injecting LLMs remove puffery, but I absolutely don't trust new editors to be using them. Sohom (talk) 15:29, 24 May 2024 (UTC)
- Yes, I mostly had content generation in mind, although LLMs can add a lot of puffery when "copyediting" so that's also a risk. Chaotıċ Enby (talk · contribs) 15:15, 24 May 2024 (UTC)
- +1. Although Sohom's text is the closest formulation I've seen to what I think might be consensus. Levivich (talk) 14:09, 24 May 2024 (UTC)
- It's a starting point for anything, though: Any X must be checked for accuracy, including references, and all X that conflicts with policy can be removed. isaacl (talk) 17:17, 24 May 2024 (UTC)
- My suggestion for a base line policy on the use of LLMs on Wikipedia: “Don’t”. Blueboar (talk) 12:48, 24 May 2024 (UTC)
- Yes, definitely. I wanted to use it as a starting point to having a baseline policy/document on the usage of LLMs that we could point editors to. If there is a majority opinion/consensus that we need to do something stronger, I see that as a good outcome. Sohom (talk) 17:40, 23 May 2024 (UTC)
- The text you've linked is identical to that of WP:LLMP, which I wrote over a year ago.
- I started an RfC, in which a quite wide majority of commenters supported adopting it, and it was closed as "no consensus" for reasons that remain unclear; essentially, the closer arbitrarily chose to interpret a large amount of the support votes as being opposed to each other, in which case it would no longer have a majority. This has been extremely disheartening to me, and I have been intending to initiate a review of the close, but it's been several months, and I think the whole landscape has changed in the meantime. jp×g🗯️ 12:39, 24 May 2024 (UTC)
- It's not identical, it's not even similar. Sohom's text takes out the two major provisions of LLMP that most editors in that RFC objected to. From the LLMP RFC closure:
The primary objections from those opposing included concerns about mandatory disclosure and about the proposed ability to summarily remove suspect LLM content...There does seem to be an implied consensus for "Large language model output, if used on Wikipedia, must be manually checked for accuracy (including references it generates)" among those both favoring and opposing this wording but this was not stated explicitly enough by enough editors for me to formally find a consensus for it. Nothing in this close should be construed to suggest that current policies and guidelines do not apply to Large Language models, with a number of editors explicitly noting (especially among those opposing) that current policies and guidelines do apply.
- Sohom's text omits the mandatory disclosure and summary removal provisions of the LLMP draft (that's how it differs). The first sentence of Sohom's text is the manual checking provision, and the second sentence of Sohom's text is the existing-PAGs-apply provision, both of which were suggested by the LLMP close as having implied consensus or at least significant support.
- @Sohom: I wouldn't go so far as to say that is the "current consensus" as that's never been confirmed, but it certainly seems to match the prevailing views of editors, based on prior discussions (such as the LLMP RFC). Levivich (talk) 12:58, 24 May 2024 (UTC)
- You are incorrect.
- The proposal was supported by 44 people and opposed by 23, so almost a factor of two -- it was closed as "no consensus" under the completely arbitrary claim that half of the 44 supporters were actually opposed to it.
- However, even if we play along with the idea that everyone who said e.g. "I support this as a half-measure for the thing I really want" was lying (?) and disregard their comments, the proposal was still favored by 52% of commenters, both a plurality and an absolute majority.
- Furthermore:
jp×g🗯️ 13:05, 24 May 2024 (UTC)− Largelanguagemodeloutput,ifusedonWikipedia,must be manually checked for accuracy (including references itgenerates),anditsuse(includingwhichmodel)mustbedisclosedbytheeditor;textaddedinviolationofthispolicymaybesummarilyremoved.+ If used on Wikipedia, large language model output must be manually checked for accuracy (including references it generates). If potentially LLM-generated text conflicts with existing policies, it should be removed.- This is not the place to argue with the close of that RFC, jp. You're derailing this discussion, which is not about the close of that RFC, so I'm going to hat this now. Levivich (talk) 14:05, 24 May 2024 (UTC)
- I reverted the hat, the discussion of the consensus established at the previous RfC is absolutely relevant to the topic of
Quantifying current consensus on LLM usage
Chaotıċ Enby (talk · contribs) 14:09, 24 May 2024 (UTC) - You were the one who brought up that close in the first place -- and to say something that was flatly incorrect (that "most editors objected to" it). Most editors did not object to it. If you're going to be clerking this section, how about you strike "most editors" from your comment, and I'll strike "identical" from mine? jp×g🗯️ 21:38, 24 May 2024 (UTC)
- I reverted the hat, the discussion of the consensus established at the previous RfC is absolutely relevant to the topic of
- This is not the place to argue with the close of that RFC, jp. You're derailing this discussion, which is not about the close of that RFC, so I'm going to hat this now. Levivich (talk) 14:05, 24 May 2024 (UTC)
- It's not identical, it's not even similar. Sohom's text takes out the two major provisions of LLMP that most editors in that RFC objected to. From the LLMP RFC closure:
- I'm not going to pull out the "if it's disruptive they can be blocked for disruptive editing" line, but due to the lack of a firm consensus that is what I did recently when blocking for, largely, disruptive LLM use. There are tools in the toolbox now, but firmer consensus would be great.
- In that recent situation I reverted multiple responses at WP:AN to close reviews that were clearly generated by chatGPT. Editor time is our most valuable resource, so making people argue with robots is disruptive on its face. ScottishFinnishRadish (talk) 14:14, 24 May 2024 (UTC)
In terms of article content, I don't understand why we need anything more than what we already have: "all submitted content must be checked for accuracy, including references, and all submitted content that conflicts with policy can be removed." If content is accurate, referenced, notable, neutral and compliant with copyright, etc. then we should be including it regardless of whether it was written by human or machine. Likewise if it isn't those things we should be removing it regardless of whether it was written by human or machine. Thryduulf (talk) 21:28, 24 May 2024 (UTC)
- The issue that arises is that enormous amounts of shit can be created with little or no time. Investigating and addressing that requires a significant investment of editor time to remedy. Time we're already lacking. ScottishFinnishRadish (talk) 21:33, 24 May 2024 (UTC)
- That's true of both humans and machines. If it's shit it doesn't matter whether it's human shit or machine shit, get rid of it. Thryduulf (talk) 21:36, 24 May 2024 (UTC)
- The difference is that the average human typing speed is fifty words per minute, versus a thousand. jp×g🗯️ 21:45, 24 May 2024 (UTC)
- You can generate shit that's hard to easily detect infinitely faster training an LLM. The speed and scale at which large language models (LLMs) can produce content present unique challenges that surpass those associated with human-created content. While human editors certainly can and do produce inaccurate or low-quality material, the volume is naturally limited by human capacity. An LLM, however, can churn out vast quantities of text in a fraction of the time it would take a person. This means that even if only a small fraction of machine-generated content is problematic, the absolute number can quickly become overwhelming.
- One major issue is the subtlety of errors in LLM-generated text. Machines can produce content that appears superficially accurate and well-referenced but may contain nuanced inaccuracies or fabrications that are not immediately obvious. These errors can be particularly insidious because they might be less apparent to casual readers or even experienced editors at a glance. The result is that detecting and correcting such content requires a disproportionate amount of editorial effort.
- Moreover, the nature of machine-generated text often involves creating convincing but ultimately false narratives, sometimes interwoven with factual information. This can mislead readers and complicate the editorial process as it blurs the lines between fact and fiction. The effort required to meticulously verify every claim, cross-check references, and ensure neutrality becomes exponentially greater when dealing with a high volume of content.
- In addition, there is the issue of copyright compliance. While human writers are generally aware of the need to respect intellectual property, LLMs may inadvertently generate content that closely mirrors existing copyrighted material, leading to potential legal issues. This requires an additional layer of scrutiny to ensure that machine-generated content does not violate copyright laws.
- The editorial community is already stretched thin, and adding the burden of sifting through vast amounts of machine-generated content exacerbates the problem. Each piece of content, whether human or machine-generated, demands a thorough review to ensure accuracy, neutrality, and compliance with policies. However, the sheer speed and volume at which LLMs can produce text mean that editors could find themselves perpetually behind, struggling to keep up with the influx.
- Additionally, the motivation behind content creation differs between humans and machines. While humans generally write with specific purposes, interests, or biases, machines generate content based on prompts and training data without intrinsic motivation or understanding. This can lead to the production of content that is contextually irrelevant, off-topic, or otherwise misaligned with editorial standards and community guidelines.
- To address these challenges, it might be necessary to implement stricter pre-publication checks for machine-generated content, including more rigorous fact-checking protocols and automated tools to assist in the detection of subtle inaccuracies. Furthermore, encouraging transparency about the origins of content can help readers and editors apply the appropriate level of scrutiny.
- In summary, while the core principles of content inclusion should remain consistent—accuracy, neutrality, notability, and compliance with copyright—the unique challenges posed by machine-generated content necessitate additional considerations. The editorial community must adapt its strategies and tools to effectively manage the influx and maintain the quality and integrity of published content. ScottishFinnishRadish (talk) 21:46, 24 May 2024 (UTC)
- More shortly: humans and elephants poop the same thing, but you won't get rid of elephant poop by flushing it down the toilet. Chaotıċ Enby (talk · contribs) 21:54, 24 May 2024 (UTC)
- You haven't seen my toilet! Levivich (talk) 22:36, 24 May 2024 (UTC)
- And how is a policy against using LLM going to stop bad actors from flooding the encyclopedia with LLM-generated content? In the end, we will have to sort the bad contributions out, and we can deal with editors who make disruptive edits without having to figure out whether the edits are LLM-generated or human-generated. Donald Albury 00:09, 25 May 2024 (UTC)
- And how is a policy against X going to prevent bad actors from doing X isn't a good argument.
- The benefit of having a policy is that administrators could take action immediately upon recognizing LLM usage with significantly less opportunity cost than there is currently. ScottishFinnishRadish (talk) 00:18, 25 May 2024 (UTC)
- The main issue is that there is (or at least was when I last looked a few months ago) no reliable way to detect LLM content - everything has significant rates of both false positives and false negatives. And anyway what we want is not to detect LLM content, but to detect bad content.
how is a policy against X going to prevent bad actors from doing X isn't a good argument
why is it not a good argument? A policy that cannot achieve its aim is a bad policy. Thryduulf (talk) 00:26, 25 May 2024 (UTC)- WP:VANDALISM cannot achieve it's aim, so let's get rid of it? That's bonkers. We establish and enforce acceptable and unacceptable behavior all the time. ScottishFinnishRadish (talk) 00:37, 25 May 2024 (UTC)
- And how do admins recognize that an editor is adding LLM-generated content? If the edits violate any of our policies or guidelines, we can deal with it. And if edits adding LLM-generated content do not violate any of our policies or guidelines, why should we care? Donald Albury 00:27, 25 May 2024 (UTC)
- That depends, do you want to read 18.8 tomats long arguments between LLMs? Do you want to close those discussions, or are you fine with people just feeding discussions into chatgpt and asking it for a close? That's why we need to care.
- As for recognizing it, it's pretty easy with a human brain. User talk:FailedMusician#LLM usage has an example of an admin (me) easily recognizing LLM written text. ScottishFinnishRadish (talk) 00:35, 25 May 2024 (UTC)
- Looking at the linked thread, this feels like we should have a "LLM-generated text is not exempt from 'don't make up fake sources'" reminder somewhere... Chaotıċ Enby (talk · contribs) 00:44, 25 May 2024 (UTC)
- That concerns me far less than using LLMs in internal project discussions. ScottishFinnishRadish (talk) 00:48, 25 May 2024 (UTC)
- One doesn't prevent the other, but you're right that the latter is much more worrying indeed. Chaotıċ Enby (talk · contribs) 00:56, 25 May 2024 (UTC)
- That concerns me far less than using LLMs in internal project discussions. ScottishFinnishRadish (talk) 00:48, 25 May 2024 (UTC)
- Looking at the linked thread, this feels like we should have a "LLM-generated text is not exempt from 'don't make up fake sources'" reminder somewhere... Chaotıċ Enby (talk · contribs) 00:44, 25 May 2024 (UTC)
- While some edits are definitely harder to detect and fall into a grey area, having a policy could at least help weed out the most egregious cases. LLM-generated content is often unsourced and way more editorializing than our standards, and this kind of policy could help deal with these mass additions more easily. Chaotıċ Enby (talk · contribs) 00:37, 25 May 2024 (UTC)
having a policy could at least help weed out the most egregious cases
how?LLM-generated content is often unsourced and way more editorializing than our standards
often != always, but when it is unsourced and/or more editorialising than our standards we can source it, rewrite it or remove it under existing policy.this kind of policy could help deal with these mass additions more easily
how? Thryduulf (talk) 10:39, 25 May 2024 (UTC)- If users repeatedly add many paragraphs of unsourced, editorializing text that is clearly consistent with the use of keywords used by LLMs (see Wikipedia talk:WikiProject AI Cleanup#Some common AI-generated phrases), it could be good to have a policy allowing us to remove it rather than having to nitpick every single sentence. Chaotıċ Enby (talk · contribs) 11:04, 25 May 2024 (UTC)
- If any user repeatedly adds many paragraphs of unsourced editorialising text that's a user problem that needs to be dealt with regardless of whether they're using an LLM or not. Thryduulf (talk) 11:26, 25 May 2024 (UTC)
- Except that's what LLMs typically write. That's their default text output. Yes, some users might do it on their own, but LLMs make it so much easier and more frequent that we shouldn't ignore the correlation between the two. Chaotıċ Enby (talk · contribs) 11:48, 25 May 2024 (UTC)
- The problem is the output, not the method.
- If our current polices are adequate to resolve the problems with the output then adding new ones just for LLMs is a waste of time and effort better spent actually resolving the problems.
- If our current policies are not adequate to resolve the problem, then we need to strengthen our existing policies for all methods not just LLMs. Doing otherwise would mean we can't fix them problem when the method isn't LLMs, which would obviously be harmful to the encyclopaedia. Thryduulf (talk) 11:56, 25 May 2024 (UTC)
- The issue is that the method (LLMs) completely changes the scale of the problem, which means policies adequate at a smaller scale might not translate effectively at a larger scale, even if the output is superficially similar. While LLM ability to generate text is unlimited, volunteer time isn't, meaning we simply do not have the time to verify every single line of massive LLM outputs like our current policies will have us do. Chaotıċ Enby (talk · contribs) 12:04, 25 May 2024 (UTC)
- Your argument only makes sense if you are claiming that large amounts of nonsense in the encyclopaedia is only a problem when it is written by an LLM. If that is not what you are claiming then the final paragraph of my previous comment applies. Thryduulf (talk) 12:08, 25 May 2024 (UTC)
- The issue is that the method (LLMs) completely changes the scale of the problem, which means policies adequate at a smaller scale might not translate effectively at a larger scale, even if the output is superficially similar. While LLM ability to generate text is unlimited, volunteer time isn't, meaning we simply do not have the time to verify every single line of massive LLM outputs like our current policies will have us do. Chaotıċ Enby (talk · contribs) 12:04, 25 May 2024 (UTC)
- Except that's what LLMs typically write. That's their default text output. Yes, some users might do it on their own, but LLMs make it so much easier and more frequent that we shouldn't ignore the correlation between the two. Chaotıċ Enby (talk · contribs) 11:48, 25 May 2024 (UTC)
- No. I'm claiming that LLMs can add a much larger amount of nonsense than users can write organically. While you claim that
Doing otherwise would mean we can't fix them problem when the method isn't LLMs
, the fundamental difference is that the scale is completely different. LLMs can write more nonsense in a minute than users can in an hour. Chaotıċ Enby (talk · contribs) 12:11, 25 May 2024 (UTC)- None of that addresses my points. Either our current policies are adequate to handle it or they are not. In neither case do we need a policy specific to LLMs. Thryduulf (talk) 12:33, 25 May 2024 (UTC)
- Our current policies are not adequate to handle it, so we need stronger policies, like, being allowed to remove paragraphs of unsourced, editorializing text on sight rather than having to argue every sentence of it. Whether these policies are LLM-specific or not, we still need them because of the disruption potential caused by LLMs. Chaotıċ Enby (talk · contribs) 12:57, 25 May 2024 (UTC)
- None of that addresses my points. Either our current policies are adequate to handle it or they are not. In neither case do we need a policy specific to LLMs. Thryduulf (talk) 12:33, 25 May 2024 (UTC)
- If any user repeatedly adds many paragraphs of unsourced editorialising text that's a user problem that needs to be dealt with regardless of whether they're using an LLM or not. Thryduulf (talk) 11:26, 25 May 2024 (UTC)
- Also, regarding the "often unsourced" part, the cases where the generated text isn't unsourced are often more concerning, as LLMs are known for creating spurious, plausible-sounding sources, or even citing unrelated sources that don't support the claims. Chaotıċ Enby (talk · contribs) 11:06, 25 May 2024 (UTC)
- Again, adding sources that don't support the claim is a problem regardless of whether it's LLM-generated or not. Verifying whether sources actually support what they claim to is something we should be doing for all text added. Thryduulf (talk) 11:28, 25 May 2024 (UTC)
- The issue is that users have already (more or less successfully) argued that they were exempt from the blame of adding fake sources if ChatGPT wrote them. This shouldn't be the case, and users should not get off the hook just because they used a LLM to generate fake sources instead of making them up themselves. Chaotıċ Enby (talk · contribs) 12:00, 25 May 2024 (UTC)
users have already (more or less successfully) argued that they were exempt from the blame of adding fake sources if ChatGPT wrote them
[citation needed]. Policy is already clear that everybody is responsible for the content of the edits they make. If what you claim is true then all we need is to point editors claiming that to the existing policy and noting that there is no exception for LLM-generated text. Once again the problem is the fake citations, not the method used to generate the fake citations. Thryduulf (talk) 12:11, 25 May 2024 (UTC)- See User talk:FailedMusician#LLM usage for an example, where some users argued that ChatGPT-hallucinated sources were not fully the responsibility of the user adding them, or less than made-up sources they wrote themselves. Chaotıċ Enby (talk · contribs) 12:27, 25 May 2024 (UTC)
- No they are not claiming that at all - they are claiming that ChatGPT was not used to generate content. Regardless of whether that is true or not, nobody is arguing that they are not responsible for the content of the edits. Thryduulf (talk) 12:37, 25 May 2024 (UTC)
- See User talk:FailedMusician#LLM usage for an example, where some users argued that ChatGPT-hallucinated sources were not fully the responsibility of the user adding them, or less than made-up sources they wrote themselves. Chaotıċ Enby (talk · contribs) 12:27, 25 May 2024 (UTC)
- The issue is that users have already (more or less successfully) argued that they were exempt from the blame of adding fake sources if ChatGPT wrote them. This shouldn't be the case, and users should not get off the hook just because they used a LLM to generate fake sources instead of making them up themselves. Chaotıċ Enby (talk · contribs) 12:00, 25 May 2024 (UTC)
- Again, adding sources that don't support the claim is a problem regardless of whether it's LLM-generated or not. Verifying whether sources actually support what they claim to is something we should be doing for all text added. Thryduulf (talk) 11:28, 25 May 2024 (UTC)
- If users repeatedly add many paragraphs of unsourced, editorializing text that is clearly consistent with the use of keywords used by LLMs (see Wikipedia talk:WikiProject AI Cleanup#Some common AI-generated phrases), it could be good to have a policy allowing us to remove it rather than having to nitpick every single sentence. Chaotıċ Enby (talk · contribs) 11:04, 25 May 2024 (UTC)
- More shortly: humans and elephants poop the same thing, but you won't get rid of elephant poop by flushing it down the toilet. Chaotıċ Enby (talk · contribs) 21:54, 24 May 2024 (UTC)
- I linked to the highest talk page section for context, but other users later down the line claimed that
if you truly believe that this wasn't the work of an LLM, this [...] means the block was even more justified
and that adding fake citationsis just a simple misunderstanding regarding an LLM
(if I misinterpreted these comments, please tell me and I will retract this). Chaotıċ Enby (talk · contribs) 13:01, 25 May 2024 (UTC)- What we have there is a user that didn't know that ChatGPT can hallucinate references and a lot of argument about whether that is a suitable justification for an indefinite block. I'm still not seeing anybody claim that the editor inserting such sources is not responsible for them, just disputing whether someone should be indefinitely blocked for doing something they didn't know was wrong. Thryduulf (talk) 14:00, 25 May 2024 (UTC)
- That's the issue. Whether a user knows or doesn't know that ChatGPT can hallucinate references, they are still responsible for checking that whatever they add is not made up, and not knowing about what they added should not exempt them from this responsibility. Chaotıċ Enby (talk · contribs) 14:18, 25 May 2024 (UTC)
- And nobody is arguing anything different. A few years ago I saw something that claimed child pornography wasn't banned in one of the countries in the Middle East. The justification for this claim was that there was no law specifically banning child pornography. While technically true, the reason for this was because that country bans all pornography, so no specific law was needed. It's the same issue here - we don't need a specific rule against adding fake references using LLMs because we already have a rule against adding fake references. Thryduulf (talk) 14:27, 25 May 2024 (UTC)
- Yes, that makes sense and I agree. I just feel like it would be helpful to have it spelled out that "ChatGPT wrote this" is not an exemption, but I agree that it does already fall under our current policies. Chaotıċ Enby (talk · contribs) 15:14, 25 May 2024 (UTC)
- And nobody is arguing anything different. A few years ago I saw something that claimed child pornography wasn't banned in one of the countries in the Middle East. The justification for this claim was that there was no law specifically banning child pornography. While technically true, the reason for this was because that country bans all pornography, so no specific law was needed. It's the same issue here - we don't need a specific rule against adding fake references using LLMs because we already have a rule against adding fake references. Thryduulf (talk) 14:27, 25 May 2024 (UTC)
- That's the issue. Whether a user knows or doesn't know that ChatGPT can hallucinate references, they are still responsible for checking that whatever they add is not made up, and not knowing about what they added should not exempt them from this responsibility. Chaotıċ Enby (talk · contribs) 14:18, 25 May 2024 (UTC)
- What we have there is a user that didn't know that ChatGPT can hallucinate references and a lot of argument about whether that is a suitable justification for an indefinite block. I'm still not seeing anybody claim that the editor inserting such sources is not responsible for them, just disputing whether someone should be indefinitely blocked for doing something they didn't know was wrong. Thryduulf (talk) 14:00, 25 May 2024 (UTC)
- That's true of both humans and machines. If it's shit it doesn't matter whether it's human shit or machine shit, get rid of it. Thryduulf (talk) 21:36, 24 May 2024 (UTC)
Proposed revision of the COI guideline
Our current Conflict of Interest guideline is 6000 words - or 0.2 tomats - long, and often ambiguous and confusing. To address this we have recently been discussing at WP:COI a replacement, and I'm opening a discussion here to get further input on it now that it has gone through a few rounds of revisions.
It is considerably shorter than the current guideline, at just 1000 words, and is intended to be clearer about what restrictions apply to which editors. The intention is that it would replace the current COI guideline; the current text would be moved to an explanatory supplement where it could be edited and pruned as appropriate. BilledMammal (talk) 18:06, 23 May 2024 (UTC)
Draft of the proposed guideline
|
---|
|
Discussion
- Any way to internationalise the bit under Significant roles? A "precinct captain for the Democratic Party" doesn't really map intuitively onto anything in my experience, and others may feel similarly. Folly Mox (talk) 20:41, 23 May 2024 (UTC)
- I tried to think of a few as I didn't consider it ideal either, but I couldn't think of anything more recognizable. If you have any ideas I would be glad to change them. BilledMammal (talk) 00:08, 24 May 2024 (UTC)
- I am really not liking the direction this proposal is taking us. This focuses on the editor and not the edits.
- Having a conflict of interest should NOT bar anyone from editing as long as their edits are in accordance with our content policies and guidelines. Even a paid editor is not problematic UNLESS they are editing in a way that is contrary to our p&g.
- I agree that it IS all too easy to (even unintentionally) edit in a way that is contrary to p&g when you have a tie to the topic… and so I agree with requiring disclosure. After all, when you disclose, others can better guide you when you unintentionally edit in a problematic way. BUT… those with a conflict CAN edit properly with such guidance.
- The flaw isn’t in having a conflict of interest… the flaw is in allowing that conflict to impact one’s editing. And THAT is resolved by addressing the edits, not the editor. Blueboar (talk) 22:36, 23 May 2024 (UTC)
- I agree that the flaw is in allowing the conflict to impact one's editing. However, I don't believe it's useful to focus on the edits within the conflict of interest guideline. All edits are held to the same standard: they are proper if they align with our content policies and guidelines, and improper if they don't.
- Instead, we should recognize that editors with a conflict of interest can make significant positive contributions but also face an increased risk of making problematic edits - especially ones that are difficult to detect and address. Our goal should be to minimize this risk without hindering those positive contributions, and we can achieve this through two complementary processes: providing additional guidance to editors with a conflict of interest and subjecting their edits to greater scrutiny.
- A conflict of interest guideline that focuses on the editor, promoting transparency and disclosure, supports these processes, and allows us to better manage the risk. BilledMammal (talk) 00:08, 24 May 2024 (UTC)
- I agree with Blueboar, the only thing that matters is the edits. Everything that isn't directly supporting the inclusion of good edits and the exclusion of bad edits, regardless of source, is irrelevant. The significant majority of this proposal is focusing on completely the wrong thing. Thryduulf (talk) 21:34, 24 May 2024 (UTC)
- @Blueboar and @Thryduulf, can't the same thing be said about the existing COI guideline? Is this really "taking us" somewhere new, or is it "keeping us exactly where we have been since 2012"?
- Related to the comment from @Curbon7, I think the most recent major change was when Gigs and SlimVirgin largely re-wrote COI in 2012. If memory serves, the goal was to make COI focus on the editor instead of the edit, because real-world definitions (e.g., for corporate board malfeasance) focus on the individual actors instead of the actions. For example, if a non-profit board member owns an office building, and offers to rent badly needed office space to the non-profit at a massive discount, he can theoretically get in COI trouble for voting to accept his offer, even if that's clearly the best possible thing for the organization. WhatamIdoing (talk) 06:17, 25 May 2024 (UTC)
- I agree with Blueboar, the only thing that matters is the edits. Everything that isn't directly supporting the inclusion of good edits and the exclusion of bad edits, regardless of source, is irrelevant. The significant majority of this proposal is focusing on completely the wrong thing. Thryduulf (talk) 21:34, 24 May 2024 (UTC)
- I think rather than re-writing the guidelines entirely it may be more wise to trim the guideline section-by-section. I'm not sure many editors have an appetite for a ground-up re-structuring which to some may seem to be the addition of new guidelines and removal of existing one; the issue with huge proposals like this is the risk of a controversial change in one spot derailing the entire thing. Curbon7 (talk) 22:59, 23 May 2024 (UTC)
- As a matter of practical politics, you're probably right. I don't remember a wholesale re-write ever being adopted in one go, though we have (10+ years ago) made really substantial changes to some policies through a series of edits. But it's also helpful to look at the potential goal. If it's going entirely the wrong way, then we might not want to propose any of the changes. WhatamIdoing (talk) 06:05, 25 May 2024 (UTC)
- I think an attempt at a ground-up restructuring is worth attempting; a lot of the changes only make sense in context, and I feel trying to run a dozen RfC's will quickly fatigue the community. BilledMammal (talk) 07:18, 2 June 2024 (UTC)
Worth the effort; there are many problems caused by the current guideline. North8000 (talk) 13:43, 4 June 2024 (UTC)
Talk page archives and RfCs
Hey, don't do that, you should know there was an important RfC 6 years ago on talk page archive page #7 of #14. The only one who remembers has retired from Wikipedia. There should be a way for perennially important consensus results to be permanently and easily visible on the main talk page. Easily accessible not just for those with a long memory or time to doom scroll talk archives. -- GreenC 18:08, 27 May 2024 (UTC)
- There was very recently a discussion (archived at Wikipedia:Administrators' noticeboard/Archive362) about these "/Consensus" subpages listing key points, often decided in previous RfCs. It seems to be the closest to what you are looking for, if you wish to take a look at that discussion. Chaotıċ Enby (talk · contribs) 18:14, 27 May 2024 (UTC)
- Apparantly there are only 7 of these, and they are controversial. I was thinking like the mechanism to notify of prior AfDs. This could include prior RfCs and prior RMs. That's all, nothing proscribing consensus, only notifying the location of formal consensus discussions, and maybe a brief summary of the result. -- GreenC 18:27, 27 May 2024 (UTC)
- That could be a great improvement on that old "Current consensus" system indeed! Chaotıċ Enby (talk · contribs) 18:37, 27 May 2024 (UTC)
- Templates already existing:
{{Old XfD multi}}
for AfD and related deletion discussions.{{Old moves}}
for RMs.
- Templates that might be useful:
{{Discussion interlink}}
for RfC notification on top of talk page, using the|T=yes
option. See also Category:Wikipedia requests for comment templates
- I added a discussion interlink to the top of Talk:Elizabeth_Holmes, it's not very good or clear. This is not what the template was designed for. -- GreenC 19:21, 27 May 2024 (UTC)
- Templates already existing:
- FAQ, a similar system, has 574 results. Aaron Liu (talk) 16:24, 28 May 2024 (UTC)
- User:Aaron Liu, FAQ could work. Although it looks easy to abuse: gaslighting non-existent or weak consensus. Looking at Talk:Shin_Bet/FAQ, consensus is described, but there is no link a consensus discussion(!) Checking the talk archives, there was never an RM for this question. Only a few talk page posts, but no clear consensus discussion. Recently I had 4 users tell me, forcibly, that there was established consensus end of story. I disagreed, started an extremely neutral RfC (black and white question this or that), they go so angry, they almost took me to ANI for "abusing the consensus process". After 30 days the RfC closed and my position prevailed, they lost. I guarantee you they would have used FAQ and "current consensus" to continue gaslighting their non-existent consensus. -- GreenC 18:10, 28 May 2024 (UTC)
- The same thing can happen to any way of "pinning" consensus. Such gaslighting is very disruptive editing, and I believe the benefits outweigh the risks here. Aaron Liu (talk) 01:04, 29 May 2024 (UTC)
- Also, there was, in fact, a requested move. I'll edit that FAQ entry to include relevant information. Aaron Liu (talk) 01:05, 29 May 2024 (UTC)
- I don't see how notifying users of previous RfCs is the same. There is no interpretation of results, like you see in Talk:Shin_Bet/FAQ. They are qualitatively different things. -- GreenC 21:57, 29 May 2024 (UTC)
- I don't see why one must include the entire RfC to inform on prior consensus. If something's misleading, overwrite it. Aaron Liu (talk) 22:28, 29 May 2024 (UTC)
- Hmm.. check Talk:Jack_Schlossberg. Notice the list of previous AfD's listed at the top. It is generated by
{{Old XfD multi}}
. This is all, except for RfCs. It's a way for readers to find old consensus discussions in the archives. It's completely neutral and informative and in-line with other similar systems for AfDs and RMs. -- GreenC 00:18, 30 May 2024 (UTC)- I don't see how omitting a summary of rationale makes things more neutral or helpful. Aaron Liu (talk) 00:40, 30 May 2024 (UTC)
- It's helpful because it removes the ability to gaslight users with fake consensus results like we see with the broken FAQ system at Talk:Shin Bet/FAQ. The proposed template
{{Old RfCs}}
would display the question and a link to the actual RfC result, so users can explore it directly, for themselves. Nobody should be describing the consensus, it's unnecessary and easily prejudiced. -- GreenC 05:23, 30 May 2024 (UTC)- As if you can’t just link and claim consensus or change the bolded AfD/RfC result to something you’d like. Disrupters gotta disrupt, and only blocks and sanctions may stop them. Aaron Liu (talk) 10:58, 30 May 2024 (UTC)
- Also, results like userfy, keep and delete have clear meanings across all AfD contexts while these and Option 4 don’t. Aaron Liu (talk) 11:00, 30 May 2024 (UTC)
- Now you're at the level of vandals, and obviously that is true for the entire site on every level with everything so we might as well shut Wikipedia down because it's hopeless. But there is a qualitative difference between a system like FAQ and
{{Old RfCs}}
, if you can't see it, I don't know what else to say. -- GreenC 14:41, 30 May 2024 (UTC)
- Now you're at the level of vandals, and obviously that is true for the entire site on every level with everything so we might as well shut Wikipedia down because it's hopeless. But there is a qualitative difference between a system like FAQ and
- It's helpful because it removes the ability to gaslight users with fake consensus results like we see with the broken FAQ system at Talk:Shin Bet/FAQ. The proposed template
- I don't see how omitting a summary of rationale makes things more neutral or helpful. Aaron Liu (talk) 00:40, 30 May 2024 (UTC)
- Hmm.. check Talk:Jack_Schlossberg. Notice the list of previous AfD's listed at the top. It is generated by
- I don't see why one must include the entire RfC to inform on prior consensus. If something's misleading, overwrite it. Aaron Liu (talk) 22:28, 29 May 2024 (UTC)
- I don't see how notifying users of previous RfCs is the same. There is no interpretation of results, like you see in Talk:Shin_Bet/FAQ. They are qualitatively different things. -- GreenC 21:57, 29 May 2024 (UTC)
- User:Aaron Liu, FAQ could work. Although it looks easy to abuse: gaslighting non-existent or weak consensus. Looking at Talk:Shin_Bet/FAQ, consensus is described, but there is no link a consensus discussion(!) Checking the talk archives, there was never an RM for this question. Only a few talk page posts, but no clear consensus discussion. Recently I had 4 users tell me, forcibly, that there was established consensus end of story. I disagreed, started an extremely neutral RfC (black and white question this or that), they go so angry, they almost took me to ANI for "abusing the consensus process". After 30 days the RfC closed and my position prevailed, they lost. I guarantee you they would have used FAQ and "current consensus" to continue gaslighting their non-existent consensus. -- GreenC 18:10, 28 May 2024 (UTC)
- That could be a great improvement on that old "Current consensus" system indeed! Chaotıċ Enby (talk · contribs) 18:37, 27 May 2024 (UTC)
- I am indeed saying that an {{old AfD}} analogue does not provide any more protection. Your premise is that anyone can edit the FAQ to be absolutely wrong and mine is that anyone can edit the results to be absolutely wrong. Aaron Liu (talk) 15:02, 30 May 2024 (UTC)
- Talk:Elizabeth_Holmes#RfC_list_(pinned) works fine, until we get a template like
{{old RfC}}
. You will notice it does one thing, and one thing only: link to previous RfCs. Thus, when someone uses the word "fraudster" in the article, one can simply revert with the comment "see talk page", and the person will know where to find the discussion. All this stuff about rephrasing the consensus results, indeed even creating consensus results, is nuts it will be a continuous source of trouble. -- GreenC 02:52, 3 June 2024 (UTC)
- Talk:Elizabeth_Holmes#RfC_list_(pinned) works fine, until we get a template like
- I think the /Consensus pages interpreted as binding policy exist on somewhat questionable procedural grounds, but the /FAQ pages are a very good idea, and ought to be used wherever appropriate, jp×g🗯️ 21:37, 30 May 2024 (UTC)
- Apparantly there are only 7 of these, and they are controversial. I was thinking like the mechanism to notify of prior AfDs. This could include prior RfCs and prior RMs. That's all, nothing proscribing consensus, only notifying the location of formal consensus discussions, and maybe a brief summary of the result. -- GreenC 18:27, 27 May 2024 (UTC)
- What I've done is create a frequently asked questions page, and use {{FAQ}} to include it on the talk page. isaacl (talk) 21:29, 27 May 2024 (UTC)
there are only 7 of these
- So far. Best way to prevent wide adoption of something: Avoid it because it isn't yet widely adopted.and they are controversial
Show me something powerful and highly visible that isn't controversial. No good deed goes unpunished.that old "Current consensus" system
, read time-tested.Create something that functionally overlaps consensus lists (the lists cover RfCs and other consensuses), solve a nonexistent problem, I don't care, but I'm not letting go of my consensus list. And don't ask me to help maintain your new thing in parallel with it. ―Mandruss ☎ 08:45, 28 May 2024 (UTC)- Well... actually I do care, per every new thing should survive a rigorous application of the question: Is it really worth the added complexity? A principle that has been ignored far too long, resulting in the massive over-complexity that we have to live with every day (never mind the barrier to entry and the several-years-long learning curve). We have a strong tendency to focus on benefit and fail to fairly weigh it against cost. Lacking a concerted community effort to simplify the existing environment (good luck with that), this can only continue to get worse with time. ―Mandruss ☎ 02:04, 29 May 2024 (UTC)
- By the by, RMs are nothing but a special kind of consensus, so there's no reason they couldn't be included in consensus lists.
9. Article title is: Reproductive habits of Wikipedia admins. (RM July 2024)
Fits quite nicely, actually. ―Mandruss ☎ 00:42, 30 May 2024 (UTC)
Inappropriate capitalization of links is making me claw the draperies
Executive summary: There are zillions of instances of "He then ate a Pork chop, and sang..." when it should be "He then ate a pork chop, and sang..." and it's slurvy and let's think if it's possible to do anything about it. I got an idea for a bot.
Detailed exposition:
So, there are very many instances where links are capitalized, or the first word of multi-word links are capitalized, when they shouldn't be. For example, a passage that should read "...he worked in legitimate theatre after that..." instead reads "...he worked in Legitimate theatre after that..." (emphasis added). So wrong. I'm sure it jars other readers than me. Very very common.
It's little better than if our material was peppered with constructions like "...there were twenty People on deck...". It looks slurvy and it is slurvy.
I'm confident that this mostly happens because the editor is copying from the title of a page and pasting it into running text and moving on. There's no way to stop that I guess.
I can imagine a fix for this -- a program, a bot. Writing code for that would be way above my pay grade, but the process I imagine would be something like this (if this is laughably wrong or simplistic, OK, but you can see where I'm going):
- Go thru an article checking each link
- If it's the beginning of a sentence (preceded by a period and space(s) or a line break or whatever), skip it. Else
- If it's piped, skip it. Else
- If it's just one word, skip it (for now). Else
- If the first word is capitalized and the others not, you've got a potential positive.
So then
- Go to the article that the link points to.
- If it's a redirect, go home (for now). Else
- Check for each instance of the article-title string in the text. And
- If it's not found (somewhat uncommon), go home. Else
- If it's at the beginning of a sentence, skip it. Else
- If the first word (perforce midsentence) is capitalized, go home. Else
- Check the next instance (if any). And when you reach the end
- Since you've gotten to the end without being sent home (non-zero instances of midsentence use, and they all have the first word uncapitalized), you've got a likely positive.
So uncapitalize the first word in the link in the original article.
I recognize that this would be checking a lot of links -- into the nine figures I'd guess. Not a billion I hope. I have no idea if that'd be a deal-killer. If it is, well just slap my butt and put me to bed and forget it I guess. Just an idea.
Still here? OK. Now... of course you're going to get some false positive. I can't think of any, but there must be some. In which case maybe the devs could do code magic. They're smart. If not, maybe that's a deal killer.
Altho, for every "Should be this" --> "should be this" errors you're going to have a hundreds of "Pork chop" --> "pork chop" corrections I would think. A net positive, at least by the numbers, altho "we're not going to have a bot that we know is going to generate some non-zero number of errors, period" would probably be the response. Anyway, I got this Off my chest. Herostratus (talk) 06:44, 28 May 2024 (UTC)
- This idea sounds at least interesting enough to try it with a read-only bot that proposes a list of changes without making them. The main false positives might occur where the link is already incorrect, e.g. Ash Vale is near Ash where the second link should have been piped to Ash, Surrey but is still correctly capitalised. It may also be led astray by the occasional lead such as Cairns is named after some rock cairns. (it isn't; I made that up) but hopefully not too many. Certes (talk) 16:38, 28 May 2024 (UTC)
- In the latter case, I think the title "Cairns" will likely also be found in later places in the article. From what I understand, it looks at whether there's at least one capitalized mid-sentence instance, not whether all mid-sentence instances are capitalized. Chaotic Enby (talk · contribs) 17:21, 28 May 2024 (UTC)
- Fair enough. We can probably also exclude targets with {{Infobox settlement}} (or {{Infobox person}}, if k.d. lang and will.i.am aren't looking). Certes (talk) 17:31, 28 May 2024 (UTC)
- Probably not a terrible idea to exclude targets with a taxobox or automatic taxobox (or the various other related templates like {{speciesbox}}), as well, since the binomial naming system requires initial-capitals on anything genus and above, as well as the generic part of a species' binomial name, subspecies' trinomial name, etc. AddWittyNameHere 08:12, 2 June 2024 (UTC)
- Fair enough. We can probably also exclude targets with {{Infobox settlement}} (or {{Infobox person}}, if k.d. lang and will.i.am aren't looking). Certes (talk) 17:31, 28 May 2024 (UTC)
- In the latter case, I think the title "Cairns" will likely also be found in later places in the article. From what I understand, it looks at whether there's at least one capitalized mid-sentence instance, not whether all mid-sentence instances are capitalized. Chaotic Enby (talk · contribs) 17:21, 28 May 2024 (UTC)
- Here are some other interesting cases that could make things easier or harder:
- Acronyms. I would expect nearly any link beginning with two or more caps is intentionally that way, so the target probably would not need to be checked. Except "IPhone" is not correct and "iPhone" is not a unique situation.
- Multi-word phrases. Building on the acronyms case, if there is any subsequent capital letter, maybe assume the first letter should also be capitalized? That immediately accepts "City, State" and a ton of proper nouns without having to parse any target pages.
- {{lowercase title}}. Although this template is "only" used 24k times, checking for its presence (which should be even prior to the first sentence of content) catches 24k targets that are known with absolute certainty and need no further parsing or heuristics. It solves the iPhone case.
- Prefixes. Lots of technical terms have tons of prefixes (non-English characters, numerals, English-spellings of Greek letters) that should be ignored, prior to the first English character that is actually the one that follows sentence-case. Therefore, they also are subject to the "copy-paste the article title" mistake. And many of those articles' pagenames make it even harder to automate. Example: the page Gamma-Hydroxybutyric acid is titled "gamma-Hydroxybutyric acid" but "gamma-hydroxybutyric acid" is how it should be used mid-sentence. But L-Glucose is "L-glucose" mid-sentence (and the "L" is set smallcaps) and 1-Bromobutane is "1-bromobutane" mid-sentence. Many of these also use the various title-formatting templates, so that could be a short-circuit to flag ones that really need human eyes.
- All special titles. It would be useful if articles could declare their own non-obvious sentence-case styling. If (just thought about this as a seed for a different task) articles did that, we could always just obey them, and that includes forbidden special characters, italics, smallcaps, and other fun things.
- I definitely don't think we need a perfect solution, but I'd want to be as conservative as possible (minimize false-positives) to make this potentially large task that affects many pages be more acceptable when watchlists start blowing up. DMacks (talk) 17:29, 28 May 2024 (UTC)
- I think the biggest problem is going to be figuring out whether it's the start of the sentence. Some are easy enough: Pork Chop, otherwise known as Floyd Womack, ate a pork chop but others are really complicated: My shoping list includes 1. pork chop 2. flour 3. eggs 4. mushrooms. Detecting these things programmatically is very difficult in English.
- @Herostratus, I suspect that most of these are being added in the visual editor. In 2013 or 2014, the Editing team's PM (a long-time Wikipedia admin) had to decide whether to default to incorrect capitalization in Pork chop or in porkchop Cash. Getting the capitalization right for BLPs won.
- It's possible that what we should do is consider an inline tag that says [capitalization?]. It could be bot-applied under limited circumstances (e.g., less experienced editor, using the visual editor, article hasn't been edited for >30 minutes [to avoid an edit conflict]). Checking and fixing them could be an easy task for the Wikipedia:Newcomer homepage. WhatamIdoing (talk) 22:43, 1 June 2024 (UTC)
- I'd rather have it default that any link after terminating punctuation will be ignored. Worst case is a false negative and nothing is corrected. Aaron Liu (talk) 23:20, 1 June 2024 (UTC)
- False negatives aren't a big problem. We should accept that the solution can't be 100% automated and ensure that there are a negligible number of false positives which might bring calls to cancel the whole task. Certes (talk) 10:40, 2 June 2024 (UTC)
Wow thanks for the interest! OK, so first, yes, of course, test rollouts first. Second, to address some of the false positive issues-- many I think, tho far from all I'm sure, can be avoided by being as conservative as reasonably possible; some of the objections raised would not go thru cos the links are more than one word or it gets caught in one of the other nets. Yes links that start a sentence should not be checked, and also let's say anything with a character that is not in the Latin alphabet would be skipped (links with parenthesized disambiguation would have been thrown out anyway as these are very often piped except on disambig pages), and any links with a word other than the first capitalized, as suggested.
Zimmerman telegram... you'd have soooo many potential positives like that, but is that article going to have either no midsentence uses of "Zimmerman telegram", or, if any, all of them would be lowercase "zimmerman telegram"? Not many... but you are going to have an article with a link to say "Liederman effect" capitalized like that (which is the correct capitalization), but the person(s) who edited the Liederman effect article prefer "liederman effect" on grounds of parallelism with "low-voltage effect" etc. (or whatever), and use the title term once (or more) midsentence and always in lowercase. You'd think with AI there's be a way to figure out some solution to this, I don't know. Herostratus (talk) 22:01, 2 June 2024 (UTC)
- Please don't use an AI, unless you want an external link to the Telegram account of someone called Zimmerman. Certes (talk) 22:19, 2 June 2024 (UTC)
- I think that before attempting to code anything, it would be worth deciding what level of (active) errors we could tolerate from the bot/script/whatever. Does it need 95% accuracy? That might be acceptable if it's only tagging, but downcasing the wrong thing in one out of every 20 edits will not be accepted by a bot. WhatamIdoing (talk) 00:02, 3 June 2024 (UTC)
- 99.9+% I would say, if you're talking about corrections vs erroneous changes. Very very few changes of links from "This should be capitalized" changed to "this should be capitalized" would be acceptable I think. People watching an article where this is done will be plenty mad (also the bot will keep doing it I supppose). I think this'd be achievable by adding code to handle exceptions causing errors found during debugging? I haven't yet seen any of you come up with an example of a error (once you throw out links with non-Latin characters as suggested above).
- I think that before attempting to code anything, it would be worth deciding what level of (active) errors we could tolerate from the bot/script/whatever. Does it need 95% accuracy? That might be acceptable if it's only tagging, but downcasing the wrong thing in one out of every 20 edits will not be accepted by a bot. WhatamIdoing (talk) 00:02, 3 June 2024 (UTC)
- I don't know about AI. I do know that I can open a free app and ask it for a picture of Susan Hayward in a bikini (don't crush shame) and boy howdy if it doesn't do it a couple minutes. It's smart. Maybe it can figure out stuff like that.
- Absolutely run paper tests first, I assume that that's done with all bots. Maybe instead of a fix we just send a message to users on their talkpage as suggested above: "You capitalized the text for such-and-such link, we think that might be wrong, are you sure you intended that?" might be as far as we're willing to go. This is done for links to disambiguation pages and it's almost always correct. This might well be the most that is acceptable to the community (and that'd be after we'd shown like 99.9+% accuracy). This means that existing wrongly capitalized links would not be changed, which is big shame IMO, but that's life.
- So... I'm actually seeing possible interest in this idea (by a few people, granted). Would it be reasonable to go on to a next step? Would that be to move it to the Proposals section of the Village Pump? Herostratus (talk) 21:51, 3 June 2024 (UTC)
- AI uses a ton of resources for this task for which I have yet to see a false positive for.So, bots usually test themselves on test.wikipedia first and then go through a trial run of a certain amount of edits. Aaron Liu (talk) 21:57, 3 June 2024 (UTC)
- So... I'm actually seeing possible interest in this idea (by a few people, granted). Would it be reasonable to go on to a next step? Would that be to move it to the Proposals section of the Village Pump? Herostratus (talk) 21:51, 3 June 2024 (UTC)
- This sounds like a task for human supervised editing, like many typo fixing projects or disambiguation runs. I do not think it is suitable for bots. —Kusma (talk) 22:17, 3 June 2024 (UTC)
- Initially, yes. If we find that 99.9+% of its suggested edits are good then we can consider automating later. Certes (talk) 23:30, 3 June 2024 (UTC)
Ready for the mainspace
I'm here to solicit opinions about what it means for an article to be "ready for the mainspace". This phrase has turned up in hundreds of AFDs during recent years. Here's the story:
You are looking at an article. You have determined that the subject is notable, and that none of the Wikipedia:Criteria for speedy deletion apply to the article. Another editor says to you: "I don't think that article is ready for the mainspace".
What would you guess that the editor means? Is that consistent with our rules, such as the WP:NEXIST guideline or the WP:IMPERFECT policy? WhatamIdoing (talk) 19:32, 28 May 2024 (UTC)
- Personally, and this is just my own opinion here, I find this "ready for the mainspace" thing a little ambiguous. As you said, as long as WP:GNG is met, an article that is properly sourced (or at least whose topic does) deserves to be in the mainspace. Not all articles are perfect, and by having an article in the mainspace, more people will see it and improve it, which is exactly the purpose of Wikipedia. It's a work in progress! Cocobb8 (💬 talk • ✏️ contribs) 19:45, 28 May 2024 (UTC)
- I think it's a little ambiguous, too, which is why I'm asking.
;-)
WhatamIdoing (talk) 20:14, 28 May 2024 (UTC)- However, WP:DRAFTIFY clearly states that
the aim of moving an article to draft is to allow time and space for the draft's improvement until it is ready for mainspace
, so maybe a change to that guideline could be required to make it clearer? Cocobb8 (💬 talk • ✏️ contribs) 20:17, 28 May 2024 (UTC)- If we can figure out what it means, that might be helpful. WhatamIdoing (talk) 20:32, 28 May 2024 (UTC)
- However, WP:DRAFTIFY clearly states that
- I think it's a little ambiguous, too, which is why I'm asking.
- I would generally interpret it as "WP:N has not been shown." Gråbergs Gråa Sång (talk) 19:53, 28 May 2024 (UTC)
- Then what about
you have determined that the subject is notable
per @WhatamIdoing's original comment? Cocobb8 (💬 talk • ✏️ contribs) 20:02, 28 May 2024 (UTC)
- Then what about
- If I couldn't see for myself why the other editor would say that, I'd ask. For myself, I could see saying "not ready for mainspace" for something so poorly or inappropriately written that it does a disservice to the topic and the reader (although I'd probably say specifically what my concern was). Schazjmd (talk) 20:12, 28 May 2024 (UTC)
- Wikipedia:Drafts#During new page review says that it's enough that
the topic is plausibly notable
to draftify. An unsourced article with a claim of significance (or notability) could fit this description, not being eligible for WP:A7 but still not meeting the referencing standards for mainspace. Chaotic Enby (talk · contribs) 20:34, 28 May 2024 (UTC) - In my opinion, if the
articledraft meets all of the following it's ready for mainspace:- Is not being discussed at XfD
- Would not meet a speedy deletion criterion in article space
- Has no identified copyright, BLP, etc issues
- Has sufficient sources to demonstrate notability
- Has been at least minimally proof-read (perfection is not required, basic readability is).
- Has no in-line editing notes ("need to reword this", "add more info here", etc) (excluding templates and hidden comments).
- Has no obviously broken templates (if you don't know how to fix it, ask for help before moving). Thryduulf (talk) 21:22, 28 May 2024 (UTC) ("article" changed to "draft" for clarity Thryduulf (talk) 23:20, 28 May 2024 (UTC))
- I'm not sure why you're asking in this venue. The only way to know is to ask the editor making the statement what they meant. Even if it could be done, I don't think it will be helpful to try to establish a common interpretation. Editors should be specific about their concerns. isaacl (talk) 22:15, 28 May 2024 (UTC)
- It's difficult to ask hundreds of editors. Also, if everyone has their own ideas, then the phrase becomes useless. We might as well just say WP:IDONTLIKEIT in that case. WhatamIdoing (talk) 22:29, 28 May 2024 (UTC)
- The phrase is useless on its own, as it's not specific. It sounds more like you want to revisit the criteria for deleting an article, to examine what should be considered showstopping shortcomings. Commenters in deletion discussions should be encouraged to list those shortcomings. They can optionally add that as a result, the article isn't ready for the mainspace. isaacl (talk) 22:48, 28 May 2024 (UTC)
- I do not want to revisit the criteria for deleting an article. Also, if you take a look, this phrase frequently is given as a reason for not deleting the articles (but instead moving them to Draft: or User: space).
- Consider Wikipedia:Deletion policy#Deletion of drafts: "If an article isn't ready for the main namespace, it can be moved to the draft namespace". Commenters in deletion discussions can listed specific shortcomings, but the deletion policy itself can't. Is this a matter of pure consensus, in which case it's nearly indistinguishable from IDONTLIKEIT (which sounds worse than it probably would be in practice)? Does it mean, e.g., what @Thryduulf said about "Has sufficient sources to demonstrate notability", in which case WP:NEXIST is no longer valid? Would a visibly broken template count as the sort of IMPERFECT thing that the deletion policy won't countenance? WhatamIdoing (talk) 23:09, 28 May 2024 (UTC)
- To be clear, my criteria are for moving a page from draft space to article space, not for moving a page in the other direction (where such issues as broken templates should simply be fixed). Thryduulf (talk) 23:18, 28 May 2024 (UTC)
- Articles don't avoid deletion to be moved to draftspace simply because they're not ready for mainspace by someone's measure, but because someone thinks there's promise to demonstrate that the topic meets English Wikipedia's standard for having an article. There's no point in trying to retroactively figure out what others have meant by a non-specific phrase they used in the past. Moving forward, users should be asked to provide specific details, assuming that it's not already clear from context what shortcomings are being considered.
- Regarding the quote from the deletion policy, I agree that ideally it wouldn't use a vague phrase. I appreciate, though, that the sentence is trying to be a placeholder to cover any scenario where the participants in a deletion discussion agreed that the best course of action was to move the article to the draft namespace. It's essentially tautological. isaacl (talk) 00:05, 29 May 2024 (UTC)
- If it means "by consensus at AFD", then it should say that. We could change the deletion policy to say that.
- In re no point in trying to retroactively figure out what others have meant by a non-specific phrase they used in the past, I don't agree. This phrase seems to mean something to people. You are the only editor who thinks that understanding what we want to communicate (in about a thousand AFDs, in the deletion policy, twice in Wikipedia:Drafts, in more than forty thousand pages all told). When a bit of wiki-jargon has been used tens of thousands(!) of times, I don't think that figuring out what we mean, and whether we all mean the same thing, is pointless. If it doesn't interest you, then that's fine, but please don't tell other editors that what they've been saying is meaningless.
- Also, I suspect that in a substantial fraction of cases, "not ready for mainspace by someone's personal standards" is exactly what is meant. WhatamIdoing (talk) 02:10, 29 May 2024 (UTC)
- To clarify, I mean from my view, there's no point in trying to guess at the meaning in a village pump thread. If we're serious about trying to figure it out, we should be systematic: take a sampling and ask the editors in question if they're still around. We can also analyze the discussion threads to see if there is enough context to understand. isaacl (talk) 05:05, 29 May 2024 (UTC)
- This phrase is used in WP:DELPOL and WP:DRAFTIFY. The village pump is the normal place to discuss confusion that affects multiple policy/guideline/help/etc. pages.
- But I'm no longer hopeful that we can have that discussion. If you look at this thread, five editors thought they had something useful to contribute. Then you started posting that you thought it was not helpful to figure out what editors mean, that it's useless, that there's no point – and nobody else has shared their thoughts since. I think you have effectively discouraged editors from sharing their their views. WhatamIdoing (talk) 18:54, 31 May 2024 (UTC)
- To clarify, I mean from my view, there's no point in trying to guess at the meaning in a village pump thread. If we're serious about trying to figure it out, we should be systematic: take a sampling and ask the editors in question if they're still around. We can also analyze the discussion threads to see if there is enough context to understand. isaacl (talk) 05:05, 29 May 2024 (UTC)
- The phrase is useless on its own, as it's not specific. It sounds more like you want to revisit the criteria for deleting an article, to examine what should be considered showstopping shortcomings. Commenters in deletion discussions should be encouraged to list those shortcomings. They can optionally add that as a result, the article isn't ready for the mainspace. isaacl (talk) 22:48, 28 May 2024 (UTC)
- It's difficult to ask hundreds of editors. Also, if everyone has their own ideas, then the phrase becomes useless. We might as well just say WP:IDONTLIKEIT in that case. WhatamIdoing (talk) 22:29, 28 May 2024 (UTC)
- The main thing that it means to me is that most claims in the article are sourced, and that they're sourced to enough separate reliable sources to establish notability by just reading the references. Many topics are notable in the sense that sources exist out there somewhere, but implicit in the notability guideline is that the reason we're looking to establish there exist such-and-such many reliable sources about a topic is to use those sources to write the article. Any article that does not actually do this is half-baked. Loki (talk) 04:30, 1 June 2024 (UTC)
- @LokiTheLiar, how many existing articles do you think meet the standard of "most claims in the article are sourced"? WhatamIdoing (talk) 21:56, 1 June 2024 (UTC)
- I'm aware that there's lots of bad articles out there, if that's what you're asking. I'd still say that the majority of articles meet that standard, and that the overwhelming majority of traffic to Wikipedia is to articles that meet that standard.
- Like, compare naked butler, which doesn't meet the standard I've set here, to complaint tablet to Ea-nasir, which does. They're both small articles on obscure subjects but the complaint tablet one is totally fine. Loki (talk) 22:12, 1 June 2024 (UTC)
- I believe that the complaint tablet has about five times as many sentences as the median article and about ten times as many sources. So if that's the standard, we'd probably be deleting about 90% of current articles. WhatamIdoing (talk) 22:19, 1 June 2024 (UTC)
- To put it another way: The median article is a stub. You have given a C-class article as an example that should be considered a "small article". A quick look at Wikipedia:Version 1.0 Editorial Team#Statistics suggests that my off-the-cuff 90% estimate is correct. Only about 10% of articles (excluding lists, dab pages, etc.) rate as C-class or higher. WhatamIdoing (talk) 22:25, 1 June 2024 (UTC)
- Stub class articles don't necessarily violate this standard. So for instance, I just found a list of stubs and clicked randomly and found Ty Barnett, which clearly meets my standard. Or have Fred Baxter or William Beavers, literally the next two articles I clicked on. All stubs of obscure people, all definitely meet the standard I laid out. Loki (talk) 04:31, 2 June 2024 (UTC)
- ORES says the first is Start-class. I think editors might have different opinions about whether it's a long stub vs a short Start, but at 200 words/10 sentences long, it is at minimum on the long side for a stub.
- The second is a four-sentence, four-source stub, which might put it around the median article for length, but I think it is above average for sourcing.
- The third is also Start-class. It has 2750 bytes of readable prose and 450 words. This is about twice the length of the maximum described in Wikipedia:Stub#How big is too big? The stub tag was removed from the article during an expansion in 2006. I have corrected the WP:1.0 rating on its talk page.
- Looking at Fred Baxter (the second one), would you feel the same way if it had only three sentences and three sources? WhatamIdoing (talk) 06:16, 2 June 2024 (UTC)
- Yes. I don't care about length at all. Loki (talk) 13:44, 2 June 2024 (UTC)
- Are you interested in the number of sources, or the percentage of sentences with inline citations? WhatamIdoing (talk) 18:05, 2 June 2024 (UTC)
- Number of sources only has to be enough to meet the notability guideline. Otherwise it's fraction of claims that need to be sourced that aren't. Loki (talk) 23:39, 2 June 2024 (UTC)
- WP:NEXIST says that the number of citations required to meet the notability guideline is zero. (Per that long-standing guideline, the sources have to exist in the real world, but they don't have to be cited in the article.) There are no claims in User:WhatamIdoing/Christmas candy that need to be sourced (nothing about BLPs, nothing WP:LIKELY, etc.). Is that "ready for the mainspace" in your opinion? WhatamIdoing (talk) 23:51, 2 June 2024 (UTC)
- In my opinion, that article isn't 'ready for mainspace' because it is unreferenced. Cremastra (talk) 00:51, 3 June 2024 (UTC)
- I realize that the notability guideline itself says that the sources just have to exist somewhere, and not be actually present in the article. However, it's pretty clear that the reason the notability guideline says the sources have to exist somewhere is so they can be used to write the article.
- My big problem with the example article you linked is that it's not clear that "Christmas candy" is a notable subject separate from specific types of Christmas candy. I also think some of the list of examples is more WP:LIKELY to be challenged than you think. I think that for instance someone who did not know what a szaloncukor was is very likely to start out doubtful that it is Christmas candy. Loki (talk) 02:33, 3 June 2024 (UTC)
- Do you really think I needed to consult sources to write that "Christmas candy is candy associated with the Christmas holiday season. Candy canes are one type of Christmas candy"? WhatamIdoing (talk) 05:25, 3 June 2024 (UTC)
- No, but someone who doesn't celebrate Christmas and has lived in a Hindu/Buddhist/Muslim-majority country all their life might need to. WP:V still stands, whether you like or not. Cremastra (talk) 12:05, 3 June 2024 (UTC)
- WP:V says that it must be possible to find sources (e.g., at a library). It does not say that sources must be cited in the article, except four types of material, none of which are in this article. WP:V is not violated by having those two sentences uncited. WhatamIdoing (talk) 19:31, 3 June 2024 (UTC)
- No, but someone who doesn't celebrate Christmas and has lived in a Hindu/Buddhist/Muslim-majority country all their life might need to. WP:V still stands, whether you like or not. Cremastra (talk) 12:05, 3 June 2024 (UTC)
- Do you really think I needed to consult sources to write that "Christmas candy is candy associated with the Christmas holiday season. Candy canes are one type of Christmas candy"? WhatamIdoing (talk) 05:25, 3 June 2024 (UTC)
- WP:NEXIST says that the number of citations required to meet the notability guideline is zero. (Per that long-standing guideline, the sources have to exist in the real world, but they don't have to be cited in the article.) There are no claims in User:WhatamIdoing/Christmas candy that need to be sourced (nothing about BLPs, nothing WP:LIKELY, etc.). Is that "ready for the mainspace" in your opinion? WhatamIdoing (talk) 23:51, 2 June 2024 (UTC)
- Number of sources only has to be enough to meet the notability guideline. Otherwise it's fraction of claims that need to be sourced that aren't. Loki (talk) 23:39, 2 June 2024 (UTC)
- Are you interested in the number of sources, or the percentage of sentences with inline citations? WhatamIdoing (talk) 18:05, 2 June 2024 (UTC)
- Yes. I don't care about length at all. Loki (talk) 13:44, 2 June 2024 (UTC)
- Stub class articles don't necessarily violate this standard. So for instance, I just found a list of stubs and clicked randomly and found Ty Barnett, which clearly meets my standard. Or have Fred Baxter or William Beavers, literally the next two articles I clicked on. All stubs of obscure people, all definitely meet the standard I laid out. Loki (talk) 04:31, 2 June 2024 (UTC)
- To put it another way: The median article is a stub. You have given a C-class article as an example that should be considered a "small article". A quick look at Wikipedia:Version 1.0 Editorial Team#Statistics suggests that my off-the-cuff 90% estimate is correct. Only about 10% of articles (excluding lists, dab pages, etc.) rate as C-class or higher. WhatamIdoing (talk) 22:25, 1 June 2024 (UTC)
- I believe that the complaint tablet has about five times as many sentences as the median article and about ten times as many sources. So if that's the standard, we'd probably be deleting about 90% of current articles. WhatamIdoing (talk) 22:19, 1 June 2024 (UTC)
- @LokiTheLiar, how many existing articles do you think meet the standard of "most claims in the article are sourced"? WhatamIdoing (talk) 21:56, 1 June 2024 (UTC)
- I would guess the editor means:
- The article is completely unreferenced, and/or many of the claims are factually dubious
- The article is written in English, but is barely coherent. It can be understood, so isn't gibberish, but is an embarrassment and not very helpful.
- The article is blatantly and overtly promotional
- Cremastra (talk) 20:30, 1 June 2024 (UTC)
- I could also interpret "not ready for mainspace" to include glaring MOS or technical issues, like:
- templates outputting nothing but error messages
- external links peppering article prose
- infobox with default values for parameters
- entirely empty sections
- no subheadings whatsoever, just a giant chunk of text
- unintentional blockquotes from starting a paragraph with whitespace
- other Wikipedia pages incorrectly formatted as references instead of internal links
- etc
- Folly Mox (talk) 14:22, 2 June 2024 (UTC)
- I could also interpret "not ready for mainspace" to include glaring MOS or technical issues, like:
First, to emphasize the obvious, "ready for mainspace" is a vague subjective term. Probably the only more objective term that could fall under that is "allowed to exist in mainspace" and the most universal standard for that is "likely to survive a reasonably well run AFD". And for an article (NOT article content) NPP and AFC passage ostensibly follow that. Which in turn (presuming no eggregious speedy or wp:not violations) the main criteria ends up being passing wp:notability. Many people (e.g. at AFC, during mentoring, and in this thread) set a higher standard for "ready for mainspace" which is that the content of the article and the article does not have any significant problems or shortcomings. Yes, this is a double standard, and can make AFC a somewhat rough and arbitrary path. But we need to recognize that it is only human by the person reviewing it. If somebody took an article to you that was allowed to exist in mainspace (usually a wp:notability decision on the topic) but which was in really bad or undeveloped shape, would you be willing to bless putting it into mainspace? Most people would want it to meet a higher quality standard before they would personally say "ready for mainspace". North8000 (talk) 19:21, 31 May 2024 (UTC)
- If I'm not mistaken the "not ready for mainspace" phrase originated in WP:DRAFTIFY and has since leaked into deletion discussions. As everyone here seems to agree, it is very poorly defined phrase and, far from the low bars proposed above, I've seen new page and AfC reviewers invoke it for things like a draft not being long enough or using plain text references instead of {{cite}} templates. Rather than trying to define it, I think we should purge it from guidelines and templates in favour of listing specific problems in an understandable way. – Joe (talk) 12:35, 4 June 2024 (UTC)
Rather than trying to define it, I think we should purge it from guidelines and templates in favour of listing specific problems in an understandable way.
I agree with this. U ideally we would not move something out of mainspace or disallow moving it into mainspace unless there are problems that are all of specifically identified, actionable, adversely detrimental* and not trivially fixable (anything that is trivially fixable should just be fixed). *"adversely detrimental" means things like failed verification or no evidence of notability, not merely lacking inline sources, cite templates or being "too short". Thryduulf (talk) 12:44, 4 June 2024 (UTC)- I suppose we could try to re-define it as "does not qualify for deletion" (either CSD or AFD), but (a) it'd take a couple years for the usage to shift and (b) there is a strong demand from a minority of the community to have ways to get rid of "ugly" (i.e., short) articles. WhatamIdoing (talk) 16:42, 4 June 2024 (UTC)
Guestbook/New Editors' Corner?
My proposal is to create a simple page in which new editors can say hi and other editors can greet them. It will introduce newcomers to our community and the concept of editing and communicating. I think being greeted and welcomed would create a warmer atmosphere and aid in editor retention. Korean Wikipedia has a space identical to my proposal Do you see any potential issues? What should the pagename be? From where should it be linked? Ca talk to me! 14:28, 29 May 2024 (UTC)
- Are you familiar with the Wikipedia:Tea Room? I'm not active there but my first impression is that covers much of what you propose. Thryduulf (talk) 15:20, 29 May 2024 (UTC)
- Regarding the place where to put a link to any greeting space, each newcomer has access to Special:Homepage as their first step while onboarding. Trizek_(WMF) (talk) 15:24, 29 May 2024 (UTC)
- WP:TEAHOUSE is more for answering questions from new editors. What I am thinking of is a space for new editors to introduce themselves or just say hi. Ca talk to me! 15:25, 29 May 2024 (UTC)
- I totally support this idea. Sm8900 (talk) 16:29, 30 May 2024 (UTC)
- I would also support this. Cocobb8 (💬 talk • ✏️ contribs) 20:01, 31 May 2024 (UTC)
- The best way for new editors to introduce themselves is to start editing. They can introduce themselves on their user pages, in case anyone cares. EEng 20:49, 31 May 2024 (UTC)
Copyleft trolling -- taking the temperature in the room
Years ago, there was someone who paid low-wage workers to create a ton of stock photos. He released them all with a free license, then scoured the internet for anyone who used those images and sued them indiscriminately for even trivial violations. This practice is called "copyleft trolling", taking advantage of the "please use this!" signal that free licenses send and then exploiting it. It has been strongly condemned by Creative Commons itself (here and elsewhere) and various free culture advocates (Cory Doctorow has written about it several times, for example, referring to it as "a new breed of superpredator"). Flickr changed their community policies in response to the behavior, requiring users who opt for a CC license to give people the opportunity to fix the problem before suing them. In short, it's widely viewed as antithetical to free culture principles.
Over on Commons, that user's files were deleted. It was no great loss because the quality wasn't all that high to begin with. Sometime later it happened again, but with someone's personal concert photography. In that case, as the quality of the photo was higher, Commons settled on "forced watermarking" as an intervention that would let us keep good quality free media while doing all we can to ensure reusers know the terms and the risk involved with making a mistake. You can see an example at File:Lukas Nelson.jpg. I don't know how we settled on that precise wording of the watermark, but in hindsight it should probably be changed to be a bit clearer and less pointed. Of course, these files can still be displayed on Wikipedia without the watermark using {{CSS image crop}}, but when you go to download the image or view it at full size it's intrusive by design. The idea is to make someone either use the image with correct attribution intact or manually crop an image that ensures they see the correct attribution that will avoid them getting sued.
It's happening again, and this time with one of our most accomplished and celebrated wikiphotographers, whose images are widely used on enwiki and elsewhere on the internet (long threads here, here, and here). They have been clear that they have contracted with Pixsy (the company most closely associated with copyleft trolling) and will insist on payment from even independent/small-time/non-profit media users, even if they agree to fix the issue and there was no real damage done. It's perhaps the case with the most potential for harm for people who rely on us for free content, but also the case with the most valuable images.
There are ongoing debates on Commons over what to do, and forced watermarking is back on the table. If it happens, enwiki will have a decision to make: stop using the images altogether (not likely), replace all syntax with {{CSS image crop}} (on about 1500 pages), or host a watermark-free local version (ignoring the risk for reusers in order to avoid the hassle of the CSS image crop template). If forced watermarking doesn't happen on Commons, enwiki has a different decision to make about whether it's ok with people building a business demanding money from the wide range of people who depend on our content but make a mistake in using it (whether a major mistake or trivial mistake).
Another way to frame this discussion is: where does the English Wikipedia community stand on using our projects for "copyleft trolling"?
There are a lot of strong opinions over on Commons ranging from "delete all the files and ban the user" to "anyone who messes up attribution deserves to be sued" (though most are somewhere in between). I'm hoping this section won't turn into a splintered conversation between the same folks so we can better understand the English Wikipedia's take on what we've been discussing on Commons. — Rhododendrites talk \\ 15:07, 29 May 2024 (UTC)
- Genuine question, why isn't the usual attribution on Commons considered enough for these specific authors, like it is for everyone else? I don't see why they should be able to say "nope, I don't like this attribution, I want a watermark on the file". Otherwise, no, I don't believe it's productive to host images whose main purpose is to make money by suing people who re-use them. Chaotic Enby (talk · contribs) 17:22, 29 May 2024 (UTC)
- What's the usual attribution, though? Technically the CC licenses typically require (a) appropriate credit (which can include the name of the creator/attribution parties, a copyright notice, a license notice, a disclaimer notice, and a link to the material), (b) a link to the license itself, and (c) must indicate if any changes were made. If it's a sharealike license and you produce a derivative work with it, you must also release the resulting work with the same license.
Most of us who use the licenses just don't care that every detail is satisfied because we, you know, want people to use the work. That's why we use a free license. Now, I'm not a professional photographer (although my images are used enough that copyleft trolling would probably be pretty lucrative), but when someone says "By Rhododendrites, via Wikimedia Commons" I don't care that they omitted the license.. because meh. When they just say "By Wikimedia Commons" I might send them an email to tell them to fix it to include the "by Rhododendrites" part (and they almost always do). But I would technically be within my rights to demand money for their error, even if just missing a little piece of it, and even if it's because I chose an intentionally overcomplicated attribution statement, and even if they offer to fix it, and even if it's just some kid who threw it up on their blog with 0 visitors. The question is what we want to do about it if someone abuses CC licenses in this way (which, again, CC itself condemns). — Rhododendrites talk \\ 17:33, 29 May 2024 (UTC)- By usual attribution, I mean the fact that the link to the image points to the usual Commons file description page with the license and attribution statement, as described in c:Commons:Credit line. As far as I know, this has usually been considered enough to comply with CC BY licenses. In this case, as the creator's required credit line
Photo by Larry Philpot, www.soundstagephotography.com
is already present in the file's description, I don't see why this is not considered enough and an additional watermark is needed. Chaotic Enby (talk · contribs) 17:40, 29 May 2024 (UTC)- Presumably the software used to identify violations is either not taking linking into consideration or, more likely, when people reuse content they find here on on Commons, they're not providing that link. To clarify, we're not talking about Wikipedia violating the license and creating watermarks to protect this encyclopedia. The watermarks are to protect everyone else who comes to Wikipedia/Wikimedia Commons knowing that this is a great place to find free content (WP:5P#3) and don't fully understand the complexities of what's technically required by the license. Wikipedia doesn't need to display a watermark, which is why I talk about using the CSS crop template to avoid displaying the watermark here. — Rhododendrites talk \\ 17:47, 29 May 2024 (UTC)
- Thanks a lot for the clarification! I still believe it's quite a sleazy move from the user doing the "copyleft trolling", and very much not in the spirit of Creative Commons. Chaotic Enby (talk · contribs) 17:52, 29 May 2024 (UTC)
- Presumably the software used to identify violations is either not taking linking into consideration or, more likely, when people reuse content they find here on on Commons, they're not providing that link. To clarify, we're not talking about Wikipedia violating the license and creating watermarks to protect this encyclopedia. The watermarks are to protect everyone else who comes to Wikipedia/Wikimedia Commons knowing that this is a great place to find free content (WP:5P#3) and don't fully understand the complexities of what's technically required by the license. Wikipedia doesn't need to display a watermark, which is why I talk about using the CSS crop template to avoid displaying the watermark here. — Rhododendrites talk \\ 17:47, 29 May 2024 (UTC)
- By usual attribution, I mean the fact that the link to the image points to the usual Commons file description page with the license and attribution statement, as described in c:Commons:Credit line. As far as I know, this has usually been considered enough to comply with CC BY licenses. In this case, as the creator's required credit line
- What's the usual attribution, though? Technically the CC licenses typically require (a) appropriate credit (which can include the name of the creator/attribution parties, a copyright notice, a license notice, a disclaimer notice, and a link to the material), (b) a link to the license itself, and (c) must indicate if any changes were made. If it's a sharealike license and you produce a derivative work with it, you must also release the resulting work with the same license.
- I think as you explained on the Commons village pump, the ultimate issue is that the options for dealing with failures in attribution are poor. Unless some billionaire decides to fund a organization to only pursue violations in a spirit-of-the-license manner, accounting for the legal savviness of the violators, unfortunately at present it may be best to advise Commons contributors that there is no cost-effective way to pursue violations selectively. isaacl (talk) 18:29, 29 May 2024 (UTC)
- We learned in subsequent discussions that there is a stage in the process whereby the copyright owner could decide not to take action on the violations Pixsy flags. Diliff still pursues compensation when the violation wasn't a big deal because he feels it is owed to him for time spent determining that the violation wasn't a big deal. It was that which pushed me over to "the other side". At that point, where you're billing people for your own time spent investigating their violation, it has become the kind of business Creative Commons objects to (and, I would argue, we should, too). — Rhododendrites talk \\ 19:43, 29 May 2024 (UTC)
- I'll qualify my earlier statement: any contributor who wishes to enforce the attribution requirements needs to consider the cost-to-benefit ratio, including the opportunity cost. I think trying to single out specific methods of enforcing licensing terms is in effect a backdoor way to try to add additional license conditions, but it's not very effective in limiting problems for re-users, since we can't enact any remedies that will help them. Watermarking is probably the best way to inform re-users of potential issues, but cropping them out on Wikipedia would work against this. It would both hide the attribution information, and seem to make it legitimate to do so. If the community can't agree on displaying watermarks, I think either a new license needs to be allowed that balances the concerns of professional photographers versus unaware, casual re-users, or Commons and English Wikipedia will just have to make do without contributions from photographers concerned about enforcing attribution. isaacl (talk) 21:51, 29 May 2024 (UTC)
a new license needs to be allowed that balances the concerns of professional photographers versus unaware, casual re-users
– That's actually what CC BY 4.0 already does, as it gives people one month after a notice to fix the attribution. And that's why it is (and should be) encouraged compared to previous versions of the CC licenses. Chaotic Enby (talk · contribs) 22:36, 29 May 2024 (UTC)- CC4 doesn't do that. CC4 makes it so after you cough up your fee, your license is restored and, assuming you've fixed the violation, you can continue using it. Under older licenses even if you fixed it, the license was invalidated so you could be sued again. So CC4 doesn't stop this behavior, but does make it less lucrative in some situations. — Rhododendrites talk \\ 23:33, 29 May 2024 (UTC)
- Thanks for the explanation! I knew it gave an opportunity to fix the violation, but didn't know the person was still liable for prior use. Chaotic Enby (talk · contribs) 23:58, 29 May 2024 (UTC)
- Re
after you cough up your fee
: while you may still legally have to pay a fee for the violation, the restoration of rights if you fix the violation within 30 days is automatic as soon as you do so, whether or not you pay any fees. Anomie⚔ 13:08, 1 June 2024 (UTC)
- Sure, and commons:Commons:Village pump/Proposals#Feedback from Creative Commons covers the viewpoint that content licensed under version 4 is probably less likely to be a target for claims of copyright violation. But it doesn't prevent suing for damages that occurred prior to the violation being cured, so there remains an exposure for casual re-users and the potential for aggressive enforcement. There is good reason for the curing provision not to eliminate damages for prior harm, and so I can't see the Creative Commons licence getting rid of it in a future version. isaacl (talk) 23:39, 29 May 2024 (UTC)
- CC4 doesn't do that. CC4 makes it so after you cough up your fee, your license is restored and, assuming you've fixed the violation, you can continue using it. Under older licenses even if you fixed it, the license was invalidated so you could be sued again. So CC4 doesn't stop this behavior, but does make it less lucrative in some situations. — Rhododendrites talk \\ 23:33, 29 May 2024 (UTC)
- I'll qualify my earlier statement: any contributor who wishes to enforce the attribution requirements needs to consider the cost-to-benefit ratio, including the opportunity cost. I think trying to single out specific methods of enforcing licensing terms is in effect a backdoor way to try to add additional license conditions, but it's not very effective in limiting problems for re-users, since we can't enact any remedies that will help them. Watermarking is probably the best way to inform re-users of potential issues, but cropping them out on Wikipedia would work against this. It would both hide the attribution information, and seem to make it legitimate to do so. If the community can't agree on displaying watermarks, I think either a new license needs to be allowed that balances the concerns of professional photographers versus unaware, casual re-users, or Commons and English Wikipedia will just have to make do without contributions from photographers concerned about enforcing attribution. isaacl (talk) 21:51, 29 May 2024 (UTC)
- We learned in subsequent discussions that there is a stage in the process whereby the copyright owner could decide not to take action on the violations Pixsy flags. Diliff still pursues compensation when the violation wasn't a big deal because he feels it is owed to him for time spent determining that the violation wasn't a big deal. It was that which pushed me over to "the other side". At that point, where you're billing people for your own time spent investigating their violation, it has become the kind of business Creative Commons objects to (and, I would argue, we should, too). — Rhododendrites talk \\ 19:43, 29 May 2024 (UTC)
I think Rhododendrites has misrepresented things a little here. Copyleft trolling is the deliberate creation of supposedly freely licenced images and then running a business collecting "fees" from people who don't follow the licence conditions perfectly. Diliff was an active Commoner and Wikipedian for many many years and uploaded 1500 world class images. Many English cathedrals and other historic buildings are illustrated to professional level thanks to Diliff. They are frequently lead images and featured pictures. Diliff was active on both projects reviewing images for featured picture and offered his expert knowledge to others trying to learn better techniques (myself included). Diliff uploaded his images not only to illustrate Wikipedia, but also on both Commons and Flickr with CC licences so others could use the images for free (though the Flickr licence was NC). He frequently got asked by people to reuse the images and if X was acceptable and were helped to do so. You can see such a query here just yesterday, where someone enjoyed being able to use Diliff's images for free for next to no effort and no cost.
What appears to have happened is Diliff got increasingly pissed off with companies using his images for free without attribution, including for example Apple. He enlisted the service of a controversial company, Pixy, that locates such misuse and demands a fee for unlicenced use of copyright images, which is indeed the case and legal. Unfortunately, Pixy's business model doesn't allow for forgiveness or for differentiating between small companies and large. I don't think Rhododendrites characterised Diliff's attitude correctly, as he has said that personally he would do so but (a) he doesn't have time/resources to do the work Pixy do and (b) he isn't given the choice by Pixy who need to get a return on their investigative work.
I think the general mood on Commons is that what Diliff is doing isn't acceptable and doesn't meet with CC's own recommendations that forgiveness and allowing users to fix up the attribution should be a priority and fees/fines left for egregious misuse. However, despite what Rhododendrites hinted above, about "on the table", neither deletion nor watermarking are anywhere near consensus levels of support.
I think we mostly are where we are because Wikipedia itself does not explicitly attribute in the way the CC licence demands. If you read a CC licence it requires something like "(c) David Iliff, CC BY-SA 3.0, Source" and none of that appears on Wikipedia. Users have to click on the image and then (for most) get a page where the licence reuse terms are only shown after further right clicks or clicking on download buttons etc. If the user simply left clicks on the big image to get the full size one, then they don't get any help on licence at all. Wikipedia has hidden the attribution behind a click, which legally is acceptable but practically isn't working 100% and isn't what nearly any reuser would do.
I assume the purpose of "idea lab" would be to figure out if we can come up with a good solution. Can we enhance the experience when a user clicks on one of Diliffs images so they are even more aware of the conditions attached to reuse. I wouldn't be opposed to such a page having a carefully worded warning that users of such images have been sued if the licence conditions are not met, for Diliff's works. But I don't think we should start defacing the image with a "watermark" or deleting them. -- Colin°Talk 08:01, 30 May 2024 (UTC)
- You may want to read the CC licenses again, they do not require a specific method of attribution. They merely require the method be "reasonable to the medium or means You are utilizing". The 4.0 license simplifies the language and explicitly states that a URI or hyperlink to a page providing the information is reasonable. Anomie⚔ 11:38, 30 May 2024 (UTC)
- I don't think he's alleged an actual violation by Wikipedia. I think he's pointing out that when we don't provide a "visible" credit line (e.g., in plain text in the caption of an image in an article), then it's not obvious to casual re-users that they might need to include a visible credit line. WhatamIdoing (talk) 19:04, 31 May 2024 (UTC)
- In re Users have to click on the image and then (for most) get a page where the licence reuse terms are only shown after further right clicks or clicking on download buttons etc. If the user simply left clicks on the big image to get the full size one, then they don't get any help on licence at all.
- In mw:MediaViewer, which is what most readers use to get the full size one, there is a proper credit line. For example, if you open today's Featured Picture at Commons in MediaViewer, underneath the image is the caption ("Interior of the Cathedral of Brasília.") and the credit line ("Donatas Dabravolskas - Own work"); on the other side is the "More details" button and the license ("CC BY-SA 4.0").
- If by "they don't get any help", you mean that there's no tutorial about license requirements, then that's true, but all the information is there. Nobody in this discussion would need any further information to know what's required. WhatamIdoing (talk) 19:16, 31 May 2024 (UTC)
- But there isn't a credit line where they see the image - in the article. There is nothing that tells them they need to give a credit when they use the image. There is nothing that tells them they need to know what the license is, not what "CC BY-SA 4.0" means. I suspect many people just click to get the larger version, then right click to save the image locally so they can use it. Obviously as experienced Wikimedians we understand what copyright is, what licenses are, that we need to know what license an image is released under, that there are (probably) conditions we need to comply with and that the license will tell us what they are. Not everybody does know that, and they don't even know that there is something they don't know. Thryduulf (talk) 19:36, 31 May 2024 (UTC)
- It might not be a bad idea to put a copyright notice above the images in the File: namespace. Putting messages like that "above the fold" increases the chance that readers will see it. The WordsmithTalk to me 20:58, 31 May 2024 (UTC)
- On Wikipedia, readers mostly don't see the File: page. On Commons, it's not up to us. WhatamIdoing (talk) 22:46, 1 June 2024 (UTC)
- Most readers don't see it, but if they're looking to reuse images they're going to click on the image (which brings up the File: page) so they can get a better resolution and copy/save it from there. Putting a notice there gives them a better chance of seeing it. The WordsmithTalk to me 18:38, 2 June 2024 (UTC)
- When readers click on the image, it doesn't bring up the File: page. It brings up the image (including credits and license information) in MediaViewer. WhatamIdoing (talk) 00:09, 3 June 2024 (UTC)
- The Wordsmith, the behaviour you describe is similar to me and controlled by my Settings choices. I go straight to the Commons file page, which is fairly useless at helping re-users. If you read a Wikipedia page with a different browser or logged out you'll see what 99% of our readers see. Alternatively, try this link. The MediaViewer does the attribution explicitly per CC license terms (if the appropriate templates are used on the Commons page). It is good, but it doesn't explain to the reader that this is what they need to do to reuse this image, vs some random clutter on the page. I mean "CC BY-SA 4.0" looks like some sort of code. If that text appeared in the caption of every CC-licenced thumb, the reader would be left in no doubt that this is some kind of requirement. Showing it on mouse hover might also be acceptable (I know tablets and phones don't have this, but I suspect most people reusing the images are doing it on a computer).
- If you right-click on the big image you do get a pop-up saying that you need to attribute this image and guidance for doing so. But if you left-click on the big image, it goes to the full size version and you are dealing with a JPG in your browser, not an HTML page, so no help at all. Since your cursor is a little magnifying glass, the temptation to left click and zoom in is high. -- Colin°Talk 13:50, 3 June 2024 (UTC)
- Got it, I have MediaViewer disabled so I forgot it exists. I definitely think there's room to change that text to better explain the copyright terms. The WordsmithTalk to me 19:11, 3 June 2024 (UTC)
- When readers click on the image, it doesn't bring up the File: page. It brings up the image (including credits and license information) in MediaViewer. WhatamIdoing (talk) 00:09, 3 June 2024 (UTC)
- Most readers don't see it, but if they're looking to reuse images they're going to click on the image (which brings up the File: page) so they can get a better resolution and copy/save it from there. Putting a notice there gives them a better chance of seeing it. The WordsmithTalk to me 18:38, 2 June 2024 (UTC)
- On Wikipedia, readers mostly don't see the File: page. On Commons, it's not up to us. WhatamIdoing (talk) 22:46, 1 June 2024 (UTC)
- It might not be a bad idea to put a copyright notice above the images in the File: namespace. Putting messages like that "above the fold" increases the chance that readers will see it. The WordsmithTalk to me 20:58, 31 May 2024 (UTC)
- But there isn't a credit line where they see the image - in the article. There is nothing that tells them they need to give a credit when they use the image. There is nothing that tells them they need to know what the license is, not what "CC BY-SA 4.0" means. I suspect many people just click to get the larger version, then right click to save the image locally so they can use it. Obviously as experienced Wikimedians we understand what copyright is, what licenses are, that we need to know what license an image is released under, that there are (probably) conditions we need to comply with and that the license will tell us what they are. Not everybody does know that, and they don't even know that there is something they don't know. Thryduulf (talk) 19:36, 31 May 2024 (UTC)
- I don't think he's alleged an actual violation by Wikipedia. I think he's pointing out that when we don't provide a "visible" credit line (e.g., in plain text in the caption of an image in an article), then it's not obvious to casual re-users that they might need to include a visible credit line. WhatamIdoing (talk) 19:04, 31 May 2024 (UTC)
- I think that the root of the problem is that the English Wikipedia's piss-poor image attribution practices somehow manage to combine the worst possible aspects of every approach to create a user-hostile experience AND provide insufficient attribution. That is to say:
- On one hand, it's far too onerous. Every image in every article is a hyperlink that takes you away from the current page -- often including icons and interface elements! -- this is horrible for usability.
- On the other hand, it's nowhere near onerous enough, as it doesn't really give attribution to the photographer/artist/etc -- the page itself is totally verboten to give any textual credit, and something as simple as their name is hidden behind a hyperlink... the very same hyperlinks that are annoying and disruptive to click on and everyone learns to avoid doing that. This gets far worse if somebody, say, mirrors the page or prints it out or reuses the image somewhere else -- they probably don't even realize there is a photographer. Before I became an involved Wikipedia editor I just figured that they had all come from some kind of public-domain catalog, or were taken by paid employees of the WMF, or were fair use stock photos or something.
- There are other Wikipedias that provide the photographer's name in the thumbnail next to a photo, and it's completely normal and unobtrusive (almost every major website does this already, and you don't see anybody saying that it makes the Washington post look unprofessional).
- I think that we should probably lead by example and stop hosing all the photographers who give their images out for free. jp×g🗯️ 11:58, 30 May 2024 (UTC)
- Generally endorse all of this. There are a wide variety of ways that attribution could be better integrated into Wikipedia itself. But that would require some combination of consensus to highlight dreaded "authors" in articles or improvements to the interface that volunteers can't realistic expect to execute. But yeah if we could resolve all that, clunky kludges like forced watermarking wouldn't be necessary (and, I'd add, could easily be undone should these improvements come along). — Rhododendrites talk \\ 12:51, 30 May 2024 (UTC)
- @Colin:
Copyleft trolling is the deliberate creation of supposedly freely licenced images and then running a business collecting "fees" from people who don't follow the licence conditions perfectly
- It's defined by the enforcement, not the creation. Someone who creates images in order to collect fees is indistinguishable in effect from someone who creates images and then collects fees. Pixy's business model doesn't allow for forgiveness or for differentiating between small companies and large. I don't think Rhododendrites characterised Diliff's attitude correctly, as he has said that personally he would do so but (a) he doesn't have time/resources to do the work Pixy do and (b) he isn't given the choice by Pixy who need to get a return on their investigative work.
- I think one of us misunderstands something about Pixsy. When I was looking for information about the site, what I saw was that Pixsy doesn't take action without the rights holder's go-ahead. i.e. there is a point where one could intervene. The way I interpreted that, combined with what Diliff actually said was that [when he reviews the violation] even if he determines there was no real harm to his photography business, he still wants money from people who messed up attribution to make up for the time he spent determining there was no real harm to his photography business. (this is from multiple comments in the DR). If Pixsy doesn't actually give him that opportunity, or if Pixsy perhaps charges Diliff if he decides to pass, which would be surprising, then that changes my understanding of the situation a little without actually fixing anything as the effect on reusers is the same. — Rhododendrites talk \\ 12:42, 30 May 2024 (UTC)- I think you'll find law has a thing or two to say about intent rather than effect. Diliff's first comment on the DR was to deny being a "copyleft troll". Diliff's a bright chap. I think there is room for reasonable people to disagree on the definition, which isn't in any dictionary. All the evidence points to his body of CC work being created in good faith with the ongoing (just yesterday on his talk page) intention of allowing free use, subject to the terms of the licence. There is zero evidence of the opposite. Zero evidence of malicious intent. Zero evidence of setting a trap. Zero evidence of someone making a "minor" mistake. Zero evidence that anyone asked to pay is actually short of funds or using the image non-commercially. We know nothing about the person who complained at Commons other than that they fully admit to thinking the image was public domain and not giving licence conditions a moments thought. Why they might think a modern professional-level photo of a London landmark was public domain I don't really know.
- I think there is room to interpret Diliff's comments in different ways. You could ask him. I read it more as an explanation of Pixsy's business model. He says
"I do want to make it clear that I am sympathetic to those who have been inadvertently caught up in this due to accidental misuse, and that this is not, as Nosferattus implies, the actions of a heartless copyleft troll"
and"I did feel the need to correct the assumption being made by many here that all reusers involving minor breaches are being 'extorted' for the initial asking figure as I don't believe that is the case."
- I think we are giving way way too much weight to some random unknown person on the internet who's annoyed they messed up and wants revenge, and not enough to a user we actually know to be a generous free-content producer for many many years. I suspect the fact Pixsy's involved has led to the automatic assumption this is copyleft trolling, but Diliff's remarks suggest otherwise. Read the descriptions here. These are people who set out to create a mass of supposedly CC images and then demand high fees for "minor attribution errors". There's nothing at all in Doctorow's articles about him having sympathy for people who just steal photos off the internet because "If it's on the internet it is free" stupidity and lack of care about content creators. Are we overreacting because someone got butthurt when they got caught stealing one of Diliff's photos for commercial use without the slightest concern for licence conditions? No evidence at present to suggest otherwise. -- Colin°Talk 13:34, 30 May 2024 (UTC)
- That gets back to the ultimate problem to which I referred, regarding the available enforcement mechanisms being poor. From the re-user's perspective, the photographer's intent doesn't matter, just how enforcement of the licensing requirements is done. Changing English Wikipedia to provide attribution next to the images would at least provide a very prominent example of the attribution requirement being visibly met, thus making the need to do so more evident to re-users. (To avoid any discrepancy with user interface graphic elements, English Wikipedia could choose to only use public domain images for this purpose.) isaacl (talk) 15:18, 30 May 2024 (UTC)
- On a side note, I disagree that the use of term "trolling" should be defined solely by enforcement. Not everyone who tries to enforce their license terms should be considered a troll, whose origins as an online term derives from its meaning in fishing. isaacl (talk) 15:25, 30 May 2024 (UTC)
- Of course. I mean "by [manner of] enforcement". — Rhododendrites talk \\ 16:16, 30 May 2024 (UTC)
- I don't think manner of enforcement is a sole determinant, either, but as I said, it doesn't really matter to the re-users. isaacl (talk) 01:36, 31 May 2024 (UTC)
- Of course. I mean "by [manner of] enforcement". — Rhododendrites talk \\ 16:16, 30 May 2024 (UTC)
- On a side note, I disagree that the use of term "trolling" should be defined solely by enforcement. Not everyone who tries to enforce their license terms should be considered a troll, whose origins as an online term derives from its meaning in fishing. isaacl (talk) 15:25, 30 May 2024 (UTC)
IMO both the apparent intent of putting the images up and also the nature and scope of enforcement should be relevant to Commons/Wikipedia's stance. North8000 (talk) 21:20, 31 May 2024 (UTC)
- I don't think this has necessarily been presented neutrally, and I'm in favour of going after people who are commercially appropriating CC-licensed work without adhering to the terms of the license. At the same time, I think we're within the licensing requirements - I guess the question is whether we make it easier for users to understand what is CC-licensed. I generally like the idea of including attribution in-line in the article itself. SportingFlyer T·C 02:50, 1 June 2024 (UTC)
- Indeed not neutral, and not intended to be (this isn't a proposal, after all). But [again] this has nothing to do with whether Wikipedia is within the licensing requirements. This is about the reality that these licenses are poorly understood by the public and our "use our media!" messaging has been so successful that people assume they can just use it. A few users have decided to build a business on that misunderstanding -- a business model which both Flickr and Creative Commons itself have condemned and taken steps to curb. What I've said thus far is that we should be thinking about two things (a) design changes to avoid these misunderstandings, but (b) thinking about what to do about users who adopt this model of enforcement, without taking for granted that we will be successful in implementing any significant design changes (which is not something we're reliable for). Colin disputes whether Diliff should be considered a copyleft troll in particular. I'll disagree and say that anyone using automated means to demand money from small-time reusers, without providing any opportunities to fix the problem and demanding money even after determining damages are little-to-none, should qualify for use of that term, but we don't need to decide about Diliff here. I opened this thread to talk about the different options available and to see how enwiki views the more ... unorthodox approaches like "forced watermarking" (whether or not it happens for Diliff, and that does very much remain to be seen, it has already happened for Philpot and many users seem to consider it on the table for this sort of scenario). Ideally we can come to better design solutions to avoid licensing errors to begin with, but until we get there we need to deal with the problems as they arise. — Rhododendrites talk \\ 04:03, 1 June 2024 (UTC)
- I see a few people above suggesting the idea of inline image credits in articles. If some of you think you want to turn that into an actual proposal, I'd encourage you to address the points listed at WP:Perennial proposals#Add in-article credit for images, particularly the points about whether there's evidence that doing this would actually make an impact on people copying images without correct attribution (not just your hopes that it would), whether it would incentivize people to spam their images into articles to get their name in them, and whether the CC-BY 3.0 and earlier's requirement that credit be "at least as prominent as the credits for the other contributing authors" would be problematic for icons using those licenses if we make the standard credit for illustrative images more prominent. Anomie⚔ 12:50, 1 June 2024 (UTC)
So what level of enforcement is acceptable
There are many many sites out there using my stuff without attribution. So which of these people if any would people say its acceptable for me to send legal threats to:
- conferences-uk Seems to be a commercial site using my image with no credit of any kind nor mention of CC-BY-SA
- organrecitals.uk same image seems to be a one man fan site no credit of any kind nor mention of CC-BY-SA
- 4coffshore.com some kind of consulting firm using this image no credit of any kind nor mention of CC-BY-SA
- plymouth.ac.uk University on the south coast of England. same image used as a header. no credit of any kind nor mention of CC-BY-SA
- railfreight.com Some kind of trade publication. Gives credit but no mention of CC-BY-SA.
©Geni (talk) 12:58, 1 June 2024 (UTC)
- My take is that the problem isn't in contacting them, it's what you're saying to them. Are you trying to get them to fix the missing attribution and such, or are you going for big fees regardless of whether they fix it? I think https://creativecommons.org/license-enforcement/enforcement-principles/ that was linked at the start of the discussion is a good read. Note that doesn't mean you can't ask for money in any situation, just that it should be reasonable to the use.I'd also expect little sympathy from general editors (versus other photographers) for "I need $X from every violator to compensate me for the time I spent searching for violations and sending letters" or "to compensate me for what I paid some company to do the searching and sending for me", or for "the company I hired does this, even though I sometimes try to reduce it in some cases". Anomie⚔ 13:58, 1 June 2024 (UTC)
- Well US statutory damages start at $750 a time so lets assume thats what is being asked for.©Geni (talk) 15:33, 1 June 2024 (UTC)
- Going straight for statutory damages seems counter to the principles suggested in https://creativecommons.org/license-enforcement/enforcement-principles/ to me. Anomie⚔ 16:50, 1 June 2024 (UTC)
- Well US statutory damages start at $750 a time so lets assume thats what is being asked for.©Geni (talk) 15:33, 1 June 2024 (UTC)
- Many of these people probably aren't specialists about the exact specifics of what attribution is needed, so maybe first you could contact them to ask them to fix it and tell them what attribution is needed? Going for legal threats directly sounds a bit too much for just forgetting to credit an image. Chaotic Enby (talk · contribs) 22:29, 1 June 2024 (UTC)
- This was Flickr's approach when they modified their community guidelines (see "give some grace"). — Rhododendrites talk \\ 22:54, 1 June 2024 (UTC)
- That puts us in the "CC-BY-SA means public domain outside the unlikely event that the photographer contacts you personally" position. Remember most of these images have no attribution at all so we aren't talking "exact specifics" here.©Geni (talk) 00:35, 2 June 2024 (UTC)
- Well, sure, in that "CC BY-SA means public domain outside the unlikely event the photographer sues you personally" is also true. Both require that the copyright owner notices and does something about it; the difference is what they do. But you're right that figuring out how to draw the line is very difficult and will probably defy short definitions. I don't think we'll see Commons adopt the Flick approach of "you need to give them a chance to fix it" (maybe, but I'd be surprised). At minimum because we just host so much content imported from other sites where the copyright owner isn't involved. So any determination of "copyleft trolling" (or whatever we want to call it) is going to require a degree of evidence, pattern of behavior, and judgment of uninvolved parties like most other behavioral cases around here, From the past cases the things which, I think, have pushed people over the line in that judgment have been: commissioning a ton of low-quality work just to enforce licenses and using a very particular custom attribution line that includes a URL and suing people for omitting the entirety of that custom line. In the current case, for me anyway, it was learning that the copyright owner wants to charge people for the time he spends determining that their license mistake wasn't damaging. I should say, in case it's not evident by Colin's replies, that not everyone sees a problem with that (or doesn't see it as enough of a problem to intervene). — Rhododendrites talk \\ 16:39, 3 June 2024 (UTC)
- I think is unfortunate that Rhododendrites focused on the "copyleft trolling" aspect rather than a neutral discussion of how we help our content re-users comply with the licence conditions. It taints things with the idea that those enforcing the licence conditions are bad people, and has let this discussion to focus too much on whether Diliff is a copyleft troll and has "decided to build a business on that misunderstanding" which is so exaggerated I am getting BLP concerns we might have to erase this conversation. -- Colin°Talk 13:38, 3 June 2024 (UTC)
- That was the framing in this section because that was the framing on Commons. Regardless of what you'd like to call it, this section (which didn't even directly mention Diliff to begin with) was to see what the enwiki community thinks about the various solutions that have been proposed, in part because you said at the DR that the enwiki community would reject the watermarking idea. It's not about how bad anyone is but how to protect reusers from people who, yes, build a business on people making licensing mistakes (that quote referred to a category of people doing so and didn't mention Diliff btw). After learning a bit more about Pixsy, I learned that they do nothing other than automate the collection of possible violations and sort them into a bunch of categories of websites for copyright owners to peruse. It's 100% up to the user to decide whom they want to initiate a case against. So that means Diliff is manually looking at these independent reusers and then, per his comments in the DR, making the affirmative decision to pursue damages even when there wasn't any real harm, in order to make money from the time he spends evaluating those cases. If that isn't explicitly contravening the enforcement principles set out by Creative Commons, I don't know what is. I don't know why you're trying to litigate the Diliff case here, though. — Rhododendrites talk \\ 16:10, 3 June 2024 (UTC)
Re
Unless some billionaire decides to fund a organization to only pursue violations in a spirit-of-the-license manner
Well I can think of one, if not a billionaire then a multi-millionaire at anyway: the Wikimedia Foundation, which takes in millions and millions of dollars more than it needs, could throw a roomful of good lawyers at anyone, and is a nonprofit public good with as much standing as anyone to sue or counter-sue.
The Foundation continues to have a huge income (for good or ill). It only costs us a fraction of our income to run the IT department, run a developer group, run a cubicle farm with people in suits doing accounting and all the other stuff a big nonprofit requires, run Wikimania, and do various other cost-effective interfacing with other organization and whatnot. And I mean not only do we not need to turn a profit, we can't. Can'td take it with us, so might as well spend it on something worthwhile. Experienced and profitable grift operation or on, adozen white-shoe lawyers being unleashed on you is hard to beat, or at least being a slam dunk to beat, so...
(I do get that there are various ah organizational issues that might prevent the Foundation from doing this, but also some encouraging markers... never know til you try I guess...)
I'm just saying, to anyone who knows how to get thru to important people in the Foundation and the political chops to make a good case... wouldn't this be a job for the Foundation? Herostratus (talk) 19:01, 2 June 2024 (UTC)
- No. WhatamIdoing (talk) 00:12, 3 June 2024 (UTC)
- This seems very very unlikely. I definitely can't see an organization with the ethos of Wikimedia being at all associated with suing someone for content enforcement. In theory, it might be nice if there were some automated process that contacted websites to say "hey it looks like you have an unattributed photo that came from commons -- can you fix that. the copyright owner could take legal action if you don't fyi" with no teeth behind it, but that doesn't seem remotely realistic to automate reliably and there's still a lot more we can do on the front-end much more cheaply to better communicate what reusers have to do. — Rhododendrites talk \\ 16:14, 3 June 2024 (UTC)
- Wrt "I don't know why you're trying to litigate the Diliff case here, though", your opening post brought Diliff into the discussion with "It's happening again, and this time with one of our most accomplished and celebrated wikiphotographers,...." so your turned what could have been a neutral discussion into a posting that is trashing a Wikipedian's reputation and standing in our community.
- I think there are two possible Wikipedia discussions. One is a neutral one about trying to improve things so that when people reuse CC images, they do so properly per the licence. I don't see how that discussion needs to involve Diliff or trolling or moral views. And that discussion might well belong on the idea lab. The second discussion would be if the Commons DR decided they would in fact delete or watermark all of Diliff's excellent photos (which right now seems as likely as the Tory party winning the general election). Then I think you'd need to go to the more public village pump, and ping all the relevant wiki projects, and personally I think a mob would go after you with pitchforks and flaming torches. That's the aspect I was most concerned about, because I don't think Wikipedians prioritise "free content project" the same way Commoners do. And also because Diliff is a human and I'm concerned about what news coverage might do. We both are disappointed in Diliff's actions here. -- Colin°Talk 14:20, 5 June 2024 (UTC)
Why Wikipedia articles have no DOIs?
I was recently asked and I am not sure. Why don't we have them? Wikipedia:Digital Object Identifier does not answer this. (WikiJournals articles have them, but also many articles in academic encyclopedias do have them, ex. https://onlinelibrary.wiley.com/doi/full/10.1002/9781405165518.wbeos0736.pub2). Should we have DOIs for our articles? Piotr Konieczny aka Prokonsul Piotrus| reply here 06:04, 31 May 2024 (UTC)
- Huh, I had a vague impression that a DOI was something higher and mightier. But is DOI stuff supposed to be as changeable as a WP-article? Gråbergs Gråa Sång (talk) 11:59, 31 May 2024 (UTC)
- @Gråbergs Gråa Sång Good question. Need more research, but this forum post suggests it should be fine. Better citation needed, sure :P Piotr Konieczny aka Prokonsul Piotrus| reply here 12:09, 31 May 2024 (UTC)
- It costs money and I'm not sure it provides a great deal of benefit. Barnards.tar.gz (talk) 12:30, 31 May 2024 (UTC)
- It would provide a magnitude more credibility to middle school papers.Main Author et. al (2024). "Village pump (idea lab)". A Wikimedia Project. doi:10.1234/enwiki.26740553. CMD (talk) 12:57, 31 May 2024 (UTC)
- In that case, Veto. Gråbergs Gråa Sång (talk) 13:06, 31 May 2024 (UTC)
- It would provide a magnitude more credibility to middle school papers.Main Author et. al (2024). "Village pump (idea lab)". A Wikimedia Project. doi:10.1234/enwiki.26740553. CMD (talk) 12:57, 31 May 2024 (UTC)
- We have RevIDs. Our articles get merged, deleted, revised, etc... which goes against the purpose of DOIs: to link to stable versions. Headbomb {t · c · p · b} 03:04, 2 June 2024 (UTC)
I think it would make sense to have DOIs that resolve to Special:Permalink/rev_id, so if someone has reason to reference a Wikipedia article, they would at least perforce be providing a link to the version they're quoting, but I'm not sure how DOIs interact with CC-BY-SA 4.x licensing. Folly Mox (talk) 12:26, 31 May 2024 (UTC)
- The goal of a DOI is that you can always find the link, even if the periodical gets sold or the website gets rearranged. We don't really have that problem. A link to a revid will always find the page.
- (I could imagine someone doing this for the specific revid at FA promotions. It would cost about US$2,000 in fees, and much more [the time needed to find/check each relevant revision].) WhatamIdoing (talk) 19:27, 31 May 2024 (UTC)
- As in US$2,000 per article/instance? Gråbergs Gråa Sång (talk) 19:33, 31 May 2024 (UTC)
- No. As in US$2,000 to get all of the existing FAs and FFAs listed, at an average cost of about twenty-five cents each. WhatamIdoing (talk) 21:59, 1 June 2024 (UTC)
- Just noting that a, WMF has a ton of surplus funds (enough to give six digits to other NGOs doing stuff of no relevance to the community, see User:BilledMammal/2023 Wikimedia RfC) and b, according to this, "it is possible to get DOI without... paying a fee". I think getting DOIs for FAs, and possibly GA+ (i.e. articles that have passed semi-reasonable review process) would be a good idea. Piotr Konieczny aka Prokonsul Piotrus| reply here 02:50, 2 June 2024 (UTC)
- Zenodo’s scope is “research outputs” so it’s debatable whether encyclopaedia articles would qualify. But even if it were a completely free and open system, I’m not seeing a problem that it would solve. Barnards.tar.gz (talk) 08:05, 2 June 2024 (UTC)
- DOIs make a source look more reliable/respectable. Making Wikipedia more reliable/respectable is good, no? Piotr Konieczny aka Prokonsul Piotrus| reply here 11:52, 2 June 2024 (UTC)
- Making Wikipedia more reliable/respectable is definitely a good thing. Making it look more reliable/respectable... not so much. Barnards.tar.gz (talk) 15:27, 2 June 2024 (UTC)
- Yeah, that. WP:General disclaimer etc. Though pretty good in parts, we're a user generated wiki, to a significant extent open to any article-change whatsoever. Though I might enjoy it if a WP-text I mostly wrote has a DOI. What do you think, @Jenhawk777? Gråbergs Gråa Sång (talk) 17:34, 2 June 2024 (UTC)
- I have no real opinion on this one way or the other. Jenhawk777 (talk) 23:00, 2 June 2024 (UTC)
- Imagine the co-author list. I’ll change my mind if this proposal allows me to lower my Erdős number. Barnards.tar.gz (talk) 21:27, 3 June 2024 (UTC)
- Yeah, that. WP:General disclaimer etc. Though pretty good in parts, we're a user generated wiki, to a significant extent open to any article-change whatsoever. Though I might enjoy it if a WP-text I mostly wrote has a DOI. What do you think, @Jenhawk777? Gråbergs Gråa Sång (talk) 17:34, 2 June 2024 (UTC)
- Making Wikipedia more reliable/respectable is definitely a good thing. Making it look more reliable/respectable... not so much. Barnards.tar.gz (talk) 15:27, 2 June 2024 (UTC)
- DOIs make a source look more reliable/respectable. Making Wikipedia more reliable/respectable is good, no? Piotr Konieczny aka Prokonsul Piotrus| reply here 11:52, 2 June 2024 (UTC)
- Zenodo’s scope is “research outputs” so it’s debatable whether encyclopaedia articles would qualify. But even if it were a completely free and open system, I’m not seeing a problem that it would solve. Barnards.tar.gz (talk) 08:05, 2 June 2024 (UTC)
- Just noting that a, WMF has a ton of surplus funds (enough to give six digits to other NGOs doing stuff of no relevance to the community, see User:BilledMammal/2023 Wikimedia RfC) and b, according to this, "it is possible to get DOI without... paying a fee". I think getting DOIs for FAs, and possibly GA+ (i.e. articles that have passed semi-reasonable review process) would be a good idea. Piotr Konieczny aka Prokonsul Piotrus| reply here 02:50, 2 June 2024 (UTC)
- No. As in US$2,000 to get all of the existing FAs and FFAs listed, at an average cost of about twenty-five cents each. WhatamIdoing (talk) 21:59, 1 June 2024 (UTC)
- As in US$2,000 per article/instance? Gråbergs Gråa Sång (talk) 19:33, 31 May 2024 (UTC)
- Exactly. Our links are stable. There's no need for DOIs. Case closed. Jason Quinn (talk) 20:36, 31 May 2024 (UTC)
- The DOI databse isn't freely available is it?©Geni (talk) 23:45, 31 May 2024 (UTC)
- Yes, it is. However, getting new DOI numbers is rather expensive, especially for a free project like us. NW1223<Howl at me•My hunts> 20:54, 1 June 2024 (UTC)
- The expensive part is getting someone to do the work. WhatamIdoing (talk) 22:00, 1 June 2024 (UTC)
- Specifically, someone would need to spend hours figuring out which version of the 8,000 FAs and FFAs is the correct link. For example, Schizophrenia is an FA. Do we use the original 2003 promotion, or the 2011 FAR keep?
- Once we had the list of versions in hand, someone need to spend hours figuring out which metadata to report for that version.
- Some of this is easy (
titles
,posted_date
,acceptance_date
[the same],institution
,license
,funding
[i.e., none]). I don't know whethercitation_list
is desirable. I'm not sure whatcomponent_list
is (Table of Contents? Or is that for abstract/tables/figures/appendices?). - The entry for
contributors
is possible, but it would take some doing. Clicking around with Wikipedia:Who Wrote That? tells me that Vaughan wrote 84.4% of the 2004 version, 213.253.39.xxx 4.1%, and Ram-Man 3.4%. For the 2011 version, Doc James wrote 19.7%, Vaugahn 13%, Casliber 6%, EverSince 5.3%, SandyGeorgia 4.3%, and a whole lot of people wrote tiny amounts (this is not systematic, so I could have missed important contributors). - The fees themselves are trivial. The costs are all in human time. WhatamIdoing (talk) 19:31, 2 June 2024 (UTC)
- Where can I get a complete database DOI dump from?©Geni (talk) 00:36, 2 June 2024 (UTC)
- The expensive part is getting someone to do the work. WhatamIdoing (talk) 22:00, 1 June 2024 (UTC)
- Yes, it is. However, getting new DOI numbers is rather expensive, especially for a free project like us. NW1223<Howl at me•My hunts> 20:54, 1 June 2024 (UTC)
Better pipeline for anonymous AFD nomimations
Currently, if an anonymous editor wants to nominate an article for deletion, they have to make a request at WT:AFD. Sometimes it gets done promptly, sometimes slowly, and sometimes not at all. This also tends to flood this page with AFD requests instead of general talk about the main AFD page or specific AFD-related issues.
It might be good to have a more streamlined approach for this situation. Maybe a template that could be placed on the article's talk page that would place open requests onto a tracking page, like how edit requests are handled? Maybe just a dedicated subpage with a clear "yes", "no", or "more info needed" response to requests?
Thoughts? Suggestions? 35.139.154.158 (talk) 17:02, 2 June 2024 (UTC)
- It sounds like you're asking for another page that would still work the same way: users post their nominations somewhere, and logged-in editors use that as a backlog. I don't see how either of your suggestions would make that more efficient. Toughpigs (talk) 17:24, 2 June 2024 (UTC)
- I'm not sure "efficiency" is the full goal; if you've watchlisted the page interested in policy changes in the text of the page or development of new procedures but have no interest in helping with anonymous deletion requests (and I have zero idea how many people that describes), you're getting a lot of unhelpful notifications. Meanwhile, discussion topics are archived quicker than they might be otherwise because there is so much more traffic (example this attempt to suggest a new notification related to AfDs was on the talk page less than a month.) So the current situation is not ideal, but if we shuffled it off to its own tracking board, I'm not sure how many people would move over there to actually answer requests (he says, looking at the months of wait for a AfC.) -- Nat Gertler (talk) 18:53, 2 June 2024 (UTC)
- I agree with Toughpigs. Plus, if you can't be bothered to read to find out how to do it in a way that even if you mess up someone'll notice it, I doubt that you have read deletion policies. Aaron Liu (talk) 17:41, 2 June 2024 (UTC)
Category:Wikipedians against censorship
I was going to create Category:Wikipedians against censorship but saw that it was removed during a long discuss in 2007. I think, the members of this project need to be placed in a separate category. This category can be connect to Template:User against censorship then, on users pages, "Wikipedians against censorship" is shown instead of "WikiProject Wikipedians against censorship participants". Same as "Wikipedian WikiFairies" or "Disabled Wikipedians".
In my opinion, the same idea should be implemented for "Biography Wikipedians" and "Human rights Wikipedians". Claggy (talk) 04:39, 3 June 2024 (UTC)
- Category:WikiProject Wikipedians against censorship participants has existed since Category:Wikipedians against censorship was "selectively renamed and deleted" following Wikipedia:Categories for discussion/User/Archive/December 2007#Category:Wikipedians against censorship. It is possible consensus regarding categories for Wikipedians who like/dislike/support/oppose X has changed in 16½ years, but you haven't presented any arguments why it should. Thryduulf (talk) 11:37, 3 June 2024 (UTC)
- The OP has been glocked. Liz Read! Talk! 02:56, 4 June 2024 (UTC)
- That’s a great abbreviation Dronebogus (talk) 09:33, 4 June 2024 (UTC)
- The OP has been glocked. Liz Read! Talk! 02:56, 4 June 2024 (UTC)
Having WMF pay for IRCCloud for all users who have a Wikimedia cloak
Before officially posting this to the WMF section of Village Pump, I'd first like to gather some feedback on this. What I would like to propose is that all users who have a Wikimedia cloak be given a paid subscription to IRCCloud by the WMF.
- Why IRCCloud?
- IRCCloud seems to be the best IRC client that works for all users. It does not require installation, as it works directly on any web browser. As such, it will work on MacOS, Windows, any Linux distro including ChromeOS (Chromebooks). IRCcloud also has iOS and Android apps.
- Why a paid subscription?
- A paid subscription to IRCCloud would give cloaked users the ability to stay connected to Libera chat server at all times even when they're offline, unlimited access to chat history, and priority support.
Given the WMF's stable economic state, this seems like a productive use of their money that would benefit users accross Wikimedia projects.
Thoughts?
Cheers, Cocobb8 (💬 talk • ✏️ contribs) 20:10, 3 June 2024 (UTC)
- Would support this. Qcne (talk) 20:13, 3 June 2024 (UTC)
- Even though I wouldn't use this - I have a client I regularly use already - I would support this. —Jéské Couriano v^_^v threads critiques 20:16, 3 June 2024 (UTC)
- Before proposing this, I would recommend working out a ballpark figure for how much it would cost. Pricing seems to be £5 (+20% VAT) per user per month, but I haven't the foggiest how to find out how many people have a cloak. I haven't used IRC in years, but when I did I think I had a cloak - if they don't expire (again, I have no idea) then the raw figure will be too high as it's only worth spending money on people who are going to benefit (i.e. active users). Thryduulf (talk) 20:21, 3 June 2024 (UTC)
- @Thryduulf It would totally depend on the amount of cloaked users of course (I also have no clue what the current number is)... But that's a good point though, maybe have something like "the subscription cancels after 3 months of inactivity on Libera chat (i.e. connection to)"? That way money wouldn't be spent unnecessaril. The good thing is, in order to obtain a cloak, users still need to be quite active on Wikimedia projects so it shouldn't be too much of an issue. Cocobb8 (💬 talk • ✏️ contribs) 20:27, 3 June 2024 (UTC)
- Speaking as a GC, there are currently 802 cloaked users. (This includes Wikimedia-cloaked bots though too) stwalkerster (talk) 21:14, 3 June 2024 (UTC)
- Another option would be to have this be on-request so that only those who are botk cloaked and active on IRCCloud for Wikimedia channels. Cocobb8 (💬 talk • ✏️ contribs) 14:22, 4 June 2024 (UTC)
- What is a Wikipedia cloak? Phil Bridger (talk) 20:25, 3 June 2024 (UTC)
- @Phil Bridger See https://meta.wikimedia.org/wiki/IRC/Cloaks Cocobb8 (💬 talk • ✏️ contribs) 20:26, 3 June 2024 (UTC)
- It also auto-voices users in #wikipedia-en-help. Cocobb8 (💬 talk • ✏️ contribs) 20:30, 3 June 2024 (UTC)
- @Phil Bridger See https://meta.wikimedia.org/wiki/IRC/Cloaks Cocobb8 (💬 talk • ✏️ contribs) 20:26, 3 June 2024 (UTC)
- While I'd love for folks to get easier access to IRC clients that are usable on mobile devices and from a browser, I'm going to have to oppose this. I love the general idea of "WMF provides web-based IRC client to Wikimedians", but this proposal has too many issues. Firstly, cloaks on Libera Chat are designed to show an affiliation to a project, and some people (myself included!) don't have a Wikimedia cloak even though they may be eligible for one. Sure, it's a minor detail, but it changes the cost calculation immensely. Secondly, this would have to be an on-request thing. Like Jeske, I've got my own preferred client setup and I suspect most people who've been around IRC for a while do too. Finally, IRCCloud is a commercial service, and free self-hosted alternatives exist that could probably be hosted somewhere for a much lower cost. stwalkerster (talk) 21:20, 3 June 2024 (UTC)
- There are dozens perfectly good IRC clients including many free and open source options. Why on earth should the WMF, an organisation that exists to promote free content, throw all this money at one particular commercial product over all the rest? – Joe (talk) 09:37, 4 June 2024 (UTC)
- I used to use Matrix as an IRC bouncer before they (Libera) shut that off, so if we were wanting an official form of IRC persistence IMO a better use of resources might be looking at a way to reenable or self-host a bridge for Wikimedia users. Or just host a bouncer themselves, that would probably be easier. One good thing about bridging is the potential to have one or two channels (probably not the main ones unless people primarily using IRC want that) also bridged to Discord (I know it's not official, but we could probably make an official one) to unify the community. I know some open source projects that do that. Alpha3031 (t • c) 14:07, 4 June 2024 (UTC)
- Doesn't Libera Chat already provide a free web client for everyone at web.libera.chat? Why would we want to send our users to this other vendor in the middle? — xaosflux Talk 14:12, 4 June 2024 (UTC)
- KiwiIRC is not robust and lacks in functionality when you compare it to IRCCloud, at least from my experience in using web-browser clients. Cocobb8 (💬 talk • ✏️ contribs) 14:13, 4 June 2024 (UTC)
- @Xaosflux, general webchat tools like either of Libera Chat's web-based clients do not allow for persistent presence, and generally disconnect users whenever the user's browser decides to stop running JS on that tab to save resources. It leads to a fairly unreliable connection for anyone who wants to idle in a channel and isn't actively using IRC all the time. Bouncers (ZNC, irssi, weechat, soju, etc) and web clients which behave like bouncers (such as IRCCloud or The Lounge) persist the connection server-side, allowing persistent presence and easy session resumption.For casual users, such as those who visit -en-help, -en-revdel, or -en-unblock for assistance with a specific issue, webchat is absolutely fine. For users who want to hang around in channels long-term, webchat isn't really feasible. stwalkerster (talk) 14:22, 4 June 2024 (UTC)
- Thanks for the update. We have several channels that specifically ask for no-logging, wouldn't this completely circumvent that? Additionally, as far as privacy goes this would insert another man-in-the-middle correct? IF WMF is going to purchase and provide subscriptions to this vendor I'd like to hear what their legal, privacy, and vendor management teams have to say about it. — xaosflux Talk 14:33, 4 June 2024 (UTC)
- I think you're conflating things here. Most of our channels ask for no public logging - aka publishing of channel logs in a way that others can access it. It's even one Libera Chat's policies that public logging shouldn't happen without explicit notification. I'm not aware of any of our channels which ask no private logging (please do enlighten me if you know of any - I'm curious), nor am I aware of any non-webchat client that doesn't log privately by default. If we do have no-logging-at-all channels, then I strongly suspect that not every member of those channels has configured their client to not log that channel.We already have many users who use IRCCloud as their main client, either using the free version that doesn't offer persistent sessions or the paid version which does. As far as I'm concerned, WMF paying for a tool that many people use already will have zero practical impact on our privacy stance. If you look at a names list in any of our channels (or even look through joins/parts), you'll probably see that the user/ident part of a good portion of people's
nick!user@host
is either sid000000 or uid000000 - this is the common pattern for IRCCloud users (paid and free respectively).That said, as I mentioned above, I don't think IRCCloud is a good solution to the underlying issue when other FOSS alternatives exist (The Lounge) that we might be able to host somewhere like WMCS. stwalkerster (talk) 16:39, 4 June 2024 (UTC)- As long as a good, free (and unlimited in terms of connection) alternative that works for basically any device can be found, that would satisfy what I wanted with this proposal :). Cocobb8 (💬 talk • ✏️ contribs) 17:39, 4 June 2024 (UTC)
- I think you're conflating things here. Most of our channels ask for no public logging - aka publishing of channel logs in a way that others can access it. It's even one Libera Chat's policies that public logging shouldn't happen without explicit notification. I'm not aware of any of our channels which ask no private logging (please do enlighten me if you know of any - I'm curious), nor am I aware of any non-webchat client that doesn't log privately by default. If we do have no-logging-at-all channels, then I strongly suspect that not every member of those channels has configured their client to not log that channel.We already have many users who use IRCCloud as their main client, either using the free version that doesn't offer persistent sessions or the paid version which does. As far as I'm concerned, WMF paying for a tool that many people use already will have zero practical impact on our privacy stance. If you look at a names list in any of our channels (or even look through joins/parts), you'll probably see that the user/ident part of a good portion of people's
- Thanks for the update. We have several channels that specifically ask for no-logging, wouldn't this completely circumvent that? Additionally, as far as privacy goes this would insert another man-in-the-middle correct? IF WMF is going to purchase and provide subscriptions to this vendor I'd like to hear what their legal, privacy, and vendor management teams have to say about it. — xaosflux Talk 14:33, 4 June 2024 (UTC)
Adding some bracket colors (or anythin) to improve readability (and shorten sentences) therefore helping the reader's eye to jump from core sentense part to core sentence part (without the need to seek eternally for a lines away closing bracket) even though shorter sentences are a superior solution (but not so easy to enforce with open data).
Dealing with forum bloat
Some high-activity fora (in particular WP:ANI and WP:RSN) are so clogged with activity they become difficult to navigate and can even start to glitch and slow down web browsers. I think it’s a reasonable idea to break these down somehow, probably with case-based subpages. thoughts? Dronebogus (talk) 09:32, 4 June 2024 (UTC)
- The main issue with RSN at the moment is that the very large at the top was restored from the archives. It needs to be closed, but that could have happened without it being restored. Anyone interested in closing it? -- LCU ActivelyDisinterested «@» °∆t° 15:41, 4 June 2024 (UTC)
- I still think it’s emblematic of a larger issue— i.e. major fora working more akin to XfDs (lots of discussion and sometimes voting, more than enough for separate pages) but being treated like a simple noticeboard with minimal user interaction (i.e. Wikipedia:AIV) Dronebogus (talk) 16:48, 4 June 2024 (UTC)
- There was a discussion about similar issues here on Village Pump, see WT:VPR#Looking for some unofficial clerks and Wikipedia:Village pump (technical)/Archive 209#SIZESPLIT but for Village pumps. I could see the same idea working, opportunistically creating subpages for large topics, but doing it in anyway automatically could cause issues. Especially on RSN the vast majority of posts get few is any replies, pushing them to subpages would only give them less visibility. -- LCU ActivelyDisinterested «@» °∆t° 17:00, 4 June 2024 (UTC)
- I think the main solution for RSN is to insist that RSP proposals happen somewhere else. WhatamIdoing (talk) 17:01, 4 June 2024 (UTC)
- We also need to do better at emphasizing what RSP is for (or perhaps stress what it ISN’T for). It has turned into a general RFC page for sourcing questions, and that was NOT the original intent. It is supposed to be a list of perennial sources (ie sources that are repeatedly discussed), not a comprehensive list of reliable/unreliable sources. Blueboar (talk) 12:59, 5 June 2024 (UTC)
- Rename it to “perennial sources noticeboard”? Dronebogus (talk) 13:00, 5 June 2024 (UTC)
- WP:RSP is the list of perennial sources, which doesn't seem to be particularly bloated or diluted. WP:RSN is the noticeboard that deals with questions about reliable sources - both determining the general reliability of frequently-used sources and whether a source is reliable in a specific context - that is very long. We need a place to discuss both types of question the RSN currently deals with and while that doesn't necessarily have to be the same place, there is sometimes overlap between them. I can think of two ways of reorganising that might help:
- Leaving all discussions as they are currently until they get to beyond a certain size, at which point they are moved to a subpage that is linked/transcluded from the main page (similar to how some VP and AN/I discussions are treated)
- Leaving RSN as is for small, specific discussion with new RFCs being their own subpage. There would be a (bot-maintained?) list of open (and recent?) RFCs at the top of the noticeboard, possibly similar to the recent ECP protections report at the top of WP:AN (but not collapsed) showing the title of the RFC, the source(s) being discussed, date and time initiated, number of comments and timestamp (and author?) of the latest comment and whether it is open or closed (and if the latter when it was closed and who by).
- Thryduulf (talk) 13:34, 5 June 2024 (UTC)
- WP:RSP is the list of perennial sources, which doesn't seem to be particularly bloated or diluted. WP:RSN is the noticeboard that deals with questions about reliable sources - both determining the general reliability of frequently-used sources and whether a source is reliable in a specific context - that is very long. We need a place to discuss both types of question the RSN currently deals with and while that doesn't necessarily have to be the same place, there is sometimes overlap between them. I can think of two ways of reorganising that might help:
- It's a common problem that editors open discussions/threads about getting sources added to RSP that have been regularly discussed, they all get closed down quite quickly. Very few source have recently been added to RSP.
RSN isn't usually very long, it only gets so when specific discussions are ongoing. Dealing with those discussions as they happen seems a lot less bureaucratic then setting up a mess of transcoded bot maintained pages.
Also transcluding all pages to one page is worse than having all discussions on one page, all the translcuded text has to be displayed but now with the overhead of transclusion. If the issue on any page is difficulties in display due to size then transclusion is the opposite of the solution. -- LCU ActivelyDisinterested «@» °∆t° 14:17, 5 June 2024 (UTC)
- Rename it to “perennial sources noticeboard”? Dronebogus (talk) 13:00, 5 June 2024 (UTC)
- We also need to do better at emphasizing what RSP is for (or perhaps stress what it ISN’T for). It has turned into a general RFC page for sourcing questions, and that was NOT the original intent. It is supposed to be a list of perennial sources (ie sources that are repeatedly discussed), not a comprehensive list of reliable/unreliable sources. Blueboar (talk) 12:59, 5 June 2024 (UTC)
- I still think it’s emblematic of a larger issue— i.e. major fora working more akin to XfDs (lots of discussion and sometimes voting, more than enough for separate pages) but being treated like a simple noticeboard with minimal user interaction (i.e. Wikipedia:AIV) Dronebogus (talk) 16:48, 4 June 2024 (UTC)
- I've thought about splitting ANI. My current favorite idea is to imagine that we split it according to the day of the week (Wikipedia:Administrators' noticeboard/Incidents/Monday, Wikipedia:Administrators' noticeboard/Incidents/Tuesday, etc.). Everything can get archived together, but you could watch just the one page that "your" discussion is on. Because most are resolved and archived in about two days, the page should be nearly empty by the time it rolls around again. Admins could sign up to deal with a defined fraction of the week's load and not feel like the firehose never stops. We might have less feeling that it's just overwhelming because there are "too many" sections on the same page. And maybe we'd see less emotional spillover, in which I'm so mad about this discussion that I'm too harsh about everything else on the page. WhatamIdoing (talk) 17:00, 4 June 2024 (UTC)
- I know this is a minor thing and a bit of a tangent, but ANI is not only frequently large (50+ sections some days, despite aggressive archiving) but it has an unusually high number of revisions, which means that various tools like https://xtools.wmcloud.org/ don't work on it. Sometimes I think it would be a good idea to do an archiving-esque Move procedure on that page at the start of each year (or at least for each decade). WhatamIdoing (talk) 17:07, 4 June 2024 (UTC)
- I really like this idea. And the built-in reminder it provides when a discussion has been open for a week (and two weeks) could have a salutary effect. Newimpartial (talk) 17:08, 4 June 2024 (UTC)
- What about going the whole way and turning it into dated subpages like TfD or MfD? Each subpage would be transcluded at WP:ANI until all the discussions on it have been closed. This could have the side benefit of making ANI more outcome-oriented, which seems to be a common characteristic of our more functional noticeboards. – Joe (talk) 09:09, 5 June 2024 (UTC)
- Subpages make it much more difficult for people to watchlist the page and become aware of new discussions. Currently you can subscribe to and/or watchlist the page and be alerted to new discussions. With daily subpages you have to explicitly visit the main page and look for changes, watchlist/subscribe to 365 individual pages per year and/or use a workaround equivalent to user:Thryduulf/RfD watchlist. A forum like ANI needs visibility to work. Thryduulf (talk) 10:12, 5 June 2024 (UTC)
- It needs visibility from admins, and I don't think that will stop. Maybe the peanut gallery watchlisting ANI and showing up for every discussion is actually a bad thing. Wilhelm Tell DCCXLVI (talk to me!/my edits) 11:19, 5 June 2024 (UTC)
- Agreed. The problem with ANI is that it's too visible. A person with ANI on their watchlist is a person we don't want participating in ANI (I'm joking... kind of.) – Joe (talk) 12:04, 5 June 2024 (UTC)
- As a non-admin, I occasionally watchlist ANI when there's a discussion of particular interest to me, such as unconstructive editing that I've recently helped to deal with. I try not to do so regularly, because it would flood my watchlist with edits which are important to someone but largely irrelevant to me. I would love to have my watchlist show only updates to a particular section. (I'm aware of subscriptions.) Certes (talk) 13:54, 5 June 2024 (UTC)
- The issue with that is we need consensus from uninvolved editors for a lot of proposed actions at ANI. Making it more difficult to keep an eye out for something you may be able to contribute to isn't going to make it better. Also, this is another chance for me to bang the
Administration noticeboard
, notAdministrators' noticeboard
drum. AN and ANI are not for administrators, they're for site administration. ScottishFinnishRadish (talk) 13:59, 5 June 2024 (UTC)- We don't seem to struggle to get a consensus of uninvolved editors at other high-volume venues that use subpages, like AfD, TfD/MfD, or DRV. Conversely, it is rare for discussions at those venues to turn into lengthy pile-ons, boomerangs, or unclosable trainwrecks. When was the last time you heard somebody complain that ANI is awful because there are too few opinion-havers there? – Joe (talk) 14:31, 5 June 2024 (UTC)
- I've also seen many threads there which start with a small group of editors pushing for something, that later uninvolved editors push back on. With less visibility comes less oversight. As a new editor the other high volumes venues you mention certainly felt more cliquey with the same editors turning up in discussion on a very regular basis, something the other noticeboards didn't seem to have. -- LCU ActivelyDisinterested «@» °∆t° 14:45, 5 June 2024 (UTC)
- You think that the average AfD, MfD, or DRV would meet a reasonable quorum of uninvolved editors to indefinitely block, topic ban, ban, or otherwise sanction an editor? AfD is chronically underattended, for example, and articles are often deleted or kept on the word of two or three editors. ScottishFinnishRadish (talk) 14:51, 5 June 2024 (UTC)
- Yes. When the outcome is obvious at XfD, a few editors will participate and others will not see the point in piling on: this is a feature, not a bug, and something that we could well try to emulate in our user conduct processes. When they're controversial (as an ANI sanctioning an established editor would be), 10-20 participants is not uncommon. – Joe (talk) 15:06, 5 June 2024 (UTC)
- It's difficult to measure people not posting a comment, but I can confirm what @Joe Roe says: I avoid "piling on" at AFD, especially when the outcome is to delete, because it's unnecessary and might feel hurtful to the article's creator. WhatamIdoing (talk) 03:55, 6 June 2024 (UTC)
- Yes. When the outcome is obvious at XfD, a few editors will participate and others will not see the point in piling on: this is a feature, not a bug, and something that we could well try to emulate in our user conduct processes. When they're controversial (as an ANI sanctioning an established editor would be), 10-20 participants is not uncommon. – Joe (talk) 15:06, 5 June 2024 (UTC)
- We don't seem to struggle to get a consensus of uninvolved editors at other high-volume venues that use subpages, like AfD, TfD/MfD, or DRV. Conversely, it is rare for discussions at those venues to turn into lengthy pile-ons, boomerangs, or unclosable trainwrecks. When was the last time you heard somebody complain that ANI is awful because there are too few opinion-havers there? – Joe (talk) 14:31, 5 June 2024 (UTC)
- Agreed. The problem with ANI is that it's too visible. A person with ANI on their watchlist is a person we don't want participating in ANI (I'm joking... kind of.) – Joe (talk) 12:04, 5 June 2024 (UTC)
- Subpages make it much more difficult for people to watchlist the page
- That's why I thought that /Monday, /Tuesday would be better than each day. People can manually click on seven buttons more easily than 365 (times however many years you wanted to pre-load). However, I believe there is a script-y kind of way to watchlist all the pages for (say) a calendar year, if someone really wanted to do that. WhatamIdoing (talk) 03:54, 6 June 2024 (UTC)
- It needs visibility from admins, and I don't think that will stop. Maybe the peanut gallery watchlisting ANI and showing up for every discussion is actually a bad thing. Wilhelm Tell DCCXLVI (talk to me!/my edits) 11:19, 5 June 2024 (UTC)
- I'm not sure formally closing all discussions at ANI is a good idea. Currently most of the uncontentious stuff is "closed" by bot archiving; explicit human closes of everything could easily lead to increased bickering about discussion closures for "no one cares"/"no longer interesting"/"nobody wants to act on this"/"no action needed" discussions (usually it is not worth determining which of these is the case). —Kusma (talk) 15:19, 5 June 2024 (UTC)
- Subpages make it much more difficult for people to watchlist the page and become aware of new discussions. Currently you can subscribe to and/or watchlist the page and be alerted to new discussions. With daily subpages you have to explicitly visit the main page and look for changes, watchlist/subscribe to 365 individual pages per year and/or use a workaround equivalent to user:Thryduulf/RfD watchlist. A forum like ANI needs visibility to work. Thryduulf (talk) 10:12, 5 June 2024 (UTC)
Maybe mention drafts after redirects?
In my opinion, the {{Draft at}} template is very useful. I'm wondering if it would be useful for visitors to get a similar notice after being redirected from an article that has a draft. I will give three semi-random examples (their names start with A, B, and C). AIOS, Beatpath, and Capitol Highway. Each has a draft, but each redirects without displaying the template. Maybe a knowledgeable editor visiting one of these would have helped improve the draft, were they made aware a preliminary version is available. Maybe something as basic as "(Redirected from X; there is a draft at Y)"? --Talky Muser (talk) 18:22, 4 June 2024 (UTC)
- Technically speaking this could work. By default it would only display a message if there exists a page in draftspace with a name that exactly matches the title of the redirect used. For example Capitol Highway, Oregon would not indicate the existence of Draft:Capitol Highway unless explicitly linked (I'm not sure whether matching is case sensitive). The message would also not display in a logical place if the redirect is to a section (the "redirected from" message always appears at the top of the page). Within those limitations though this seems like something useful to have. Thryduulf (talk) 19:28, 4 June 2024 (UTC)
Reliable source engine
Created a prototype 'reliable source engine' (you can try it here) to simplify finding reliable sources. Is this something that already exists? That others might use? (if so, maybe Wikimedia can partner with Google to make the search engine ad-free?) Superb Owl (talk) 20:11, 4 June 2024 (UTC)
- I just tried it and liked the results. Thanks! Schazjmd (talk) 20:23, 4 June 2024 (UTC)
- See WP:WRS. --Talky Muser (talk) 20:37, 4 June 2024 (UTC)
- Love it! Maybe that's something to implement to the Find sources link present in most citation needed templates? But, it already seems to exist as above. Cocobb8 (💬 talk • ✏️ contribs) 21:53, 4 June 2024 (UTC)
- Thanks all! I pinged User_talk:Syced/Wikipedia_Reference_Search#Relationship_with_WP:RSP? for feedback and to see if they think it'd be helpful to have more versions and added a second version narrowed down to reliable sources without paywalls. Superb Owl (talk) 09:14, 5 June 2024 (UTC)
- WP:RSSE is another. Levivich (talk) 02:29, 6 June 2024 (UTC)