This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.
Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).
Policy
Taking the temperature on NACs in CTs
This is not a formal proposal, but may be a precursor to one. WP:NAC is generally cited as the roadmap for non-admin closures. It cautions non-admins against closing potentially contentious discussions, but does not prohibit them. It is also only an essay; but the relevant policy pages that I skimmed do not appear to make distinctions between admin and non-admin closures.
We have a good few experienced non-admin closers. Their decisions are, best as I can tell, not inferior to admin ones. However, based on the caution against contentious closures by non-admins in WP:NAC, I believe they are challenged far more frequently, and consequently their closures often end up costing, rather than saving, the community time (if this comes to a formal proposal, I will do the archival research needed to show this).
I'd like thoughts on a) whether we should prohibit non-admin closures in contentious topics, as a means of saving community time on close reviews; and b) what the best way to do this would be, given that WP:NAC does not currently carry formal weight. Regards, Vanamonde93 (talk) 21:57, 18 July 2024 (UTC)[reply]
First, there are levels of contentiousness, with ARBPIA at one end and ARBBLP at the other. While non-admin closures may be more likely to be challenged for the former to the point of costing community time, I am certain that is not true of the latter.
Second, I am certain this does not apply to request moves. As a NAC, I close a lot of RM's, and as expected given the volume a number are challenged. I haven't found it any more likely that those I close within contentious topics are challenged than those outside, and given the number closed to the number contested I am certain that these closures have saved community time. BilledMammal (talk) 22:11, 18 July 2024 (UTC)[reply]
I generally think we should be offloading bureaucratic workload from admins, not piling more on. If there are specific subject areas that become magnets for poor NACs, existing processes are sufficient to curtail those without instruction creep. VQuakr (talk) 22:17, 18 July 2024 (UTC)[reply]
As a regular NAC, I'm not sure NACs are challenged more often than admin closures; even if they were, close reviews are relatively rare (for example, as of December 2023, there was an average of 2 close reviews per month as discussed here). More importantly, we shouldn't be taking editor's powers away just because some editors spuriously choose to challenge closures solely on the grounds that they were done by non-admins. As for NAC, I read that just as you do—as a word of caution, not as a command. voorts (talk/contributions) 22:35, 18 July 2024 (UTC)[reply]
Thinking out loud, but if NACs are costing the community time in contentious areas, I think it would be better to have a new "userright" (for want of a better term) called "discussion closer" that gives users who have it no extra tools but the same weight in closing discussions as an admin has. Such a right would need to be conferred in a process only slightly heavier weight than file mover - I'm thinking something like request open 2-5 days, consensus in a discussion that has at least 5 supports from admins and/or discussion closers (no consensus after 5 days = not granted). We would then recommend that discussions that are or which are likely to be contentious be closed by admins or discussion closers.
NAC would be explicitly not a permissible ground on which to challenge a closure by a discussion closer - if that's the only reason given the challenge would be speedily declined, if it was accompanied by other reasons then the portion of the statement relating to being an NAC would be struck.
Actually, even without the discussion closer status, speedily declining any review request where NAC is the only ground would be a good thing. Thryduulf (talk) 22:44, 18 July 2024 (UTC)[reply]
speedily declining any review request where NAC is the only ground would be a good thing – This, 100%. As Vanamonde noted, there's no actual policy or guideline that says we give admin closures more weight. Indeed, per WP:NOBIGDEAL and WP:ANOT, being an admin doesn't give anyone special authority over content decisions or determing consensus. To the extent that people read WP:NAC as implying that admin closes are better than NACs just because the closers have a mop, it ought to be clarified. I'm against the new "userright" because I don't like the idea that some editors determinations of consensus are weightier than others. voorts (talk/contributions) 22:55, 18 July 2024 (UTC)[reply]
@Voorts: I agree with you about the admin-non-admin distinction, but in general, there most certainly are editors who shouldn't be doing NACs. We need to allow genuinely bad closures to be reversed: we also don't want the closer's status as a non-admin to become a distraction. I'm open to other ideas on how to achieve that. Vanamonde93 (talk) 01:04, 19 July 2024 (UTC)[reply]
In such cases, the review request needs to say "this summary does not accurately/fully represent the outcome of the discussion" rather than saying "the wrong kind of person wrote this". WhatamIdoing (talk) 21:41, 19 July 2024 (UTC)[reply]
We do allow genuinely bad closures to be reversed through close reviews. If the close is so egregious, the close review will likely be a snow overturn. voorts (talk/contributions) 23:31, 26 July 2024 (UTC)[reply]
And, while this is not a great outcome, it's also not something we should fear. People learn by making mistakes, at least to the extent that they're willing to learn. Some people are resistant to learning from their mistakes; they are the ones to fear. RoySmith(talk)23:58, 26 July 2024 (UTC)[reply]
I've suggested a flag like this in the past, and I still think it's a good idea. We don't even need to say it gives "the same weight that an admin has"; we could just say that closing especially contentious or WP:CTOP discussions requires (or recommends) the discussioncloser right and bundle it into the sysop flag in addition to making it available at WP:RFPERM. The WordsmithTalk to me18:46, 1 August 2024 (UTC)[reply]
I think making it clear that only very experienced closers should close complicated or contentious discussions is sufficient. Relatedly, one of the things I look for at RFA is difficult closes the candidate has made. ScottishFinnishRadish (talk) 23:35, 18 July 2024 (UTC)[reply]
I think the type of discussion being closed plays a substantial role. For RMs and some RfCs in CTs I don't think NACs are per se a problem, but at AfD, where non-admins literally cannot close in favor of the most common outcome, we really do need to retain the current guidance. AfD NACs can become experienced at closing debates that have a relatively clear keep or ATD outcome, but they are perpetually lacking in the skill of finding consensus for deletion. A non-delete outcome is also necessarily predetermined when a NAC decides to close an AfD, which means in close cases where either a keep or a delete outcome would be within discretion they will always go for keep. And that's on top of the already strong selection bias towards inclusionism among current NACs, which would skew things even further. JoelleJay (talk) 05:11, 26 July 2024 (UTC)[reply]
they are perpetually lacking in the skill of finding consensus for deletion I think that's a bit unfair to NACs. After all, we can't close as delete, so how would you know if we can't find consensus for it. In my experience, when I see a discussion where the discussion could reasonably be closed as delete, I add it to my watchlist, skip it, and when it's closed I can see if I agree with the admin closure. voorts (talk/contributions) 13:32, 26 July 2024 (UTC)[reply]
NACs can be plenty competent at assessing discussions, but as they are not supposed to close anything where deletion would be remotely reasonable they can't develop the practical skills needed for both reading nuanced consensus and communicating that consensus. JoelleJay (talk) 22:06, 26 July 2024 (UTC)[reply]
I don't see why assessing/communicating that consensus is any different than assessing/communicating any other form of consensus. Plus, most AfDs appear to be closed without a written rationale anyways. voorts (talk/contributions) 22:09, 26 July 2024 (UTC)[reply]
But the point is that the AfDs closed by NACs should, by definition, not need a close summary because the outcome is uncontroversial. So if NACs have been following the current guidance, they could not have developed experience in closing AfDs where deletion is on the table, and especially not the ones where they would need to provide a close summary explaining why they didn't see consensus to delete. They just literally cannot cultivate that skillset. JoelleJay (talk) 22:44, 26 July 2024 (UTC)[reply]
I disagree. In an AFD with one or two good rationals for delete (e.g. "the sources do not meet GNG") but there are (many) more editors who say that that there are sufficient sources or who come after the first delete comments, I think a close summary is helpful. - Enos733 (talk) 22:50, 26 July 2024 (UTC)[reply]
I agree and I wish close summaries (and relisting comments) were a lot more common, but I think it's still true that they're not expected for uncontroversial outcomes. JoelleJay (talk) 23:00, 26 July 2024 (UTC)[reply]
As a somewhat irregular NAC-er focussed on AfDs, I can appreciate where this is coming from - although my (purely anecdotal) observations of DRV would say this is not, relatively speaking, a problem in that sphere. I think the question is less about status (admin or not) and rather experience; I wouldn't necessarily be opposed to setting some thresholds (edit count, participation etc) for NAC on CTOPs, but I don't see a strong enough case yet for exclusion. Regards,--Goldsztajn (talk) 23:29, 18 July 2024 (UTC)[reply]
Like anything else on the wiki, the qualification to do most things is that you know how to do it, and having a mop is no promise that you do. I'm sure most of the regulars at WP:AfD, admin or not, know the details of our notability guidelines better than I do; it's absurd to suggest that I'm better qualified to close a complicated AfD just because 19 years ago, 27 people thought I'd be an OK admin. Our current NAC mindset is an anachronism and should be done away with. RoySmith(talk)23:54, 18 July 2024 (UTC)[reply]
We should root out and destroy every suggestion that discussion closure is an admin task. It makes sense for the admin noticeboards, and is vestigial in most other places. I like Thryduulf's user right suggestion (I know others have suggested something similar in the past) and speedy close suggestion, though I've rarely seen a situation where NAC is the only objection. We should guide newer closers to less controversial discussions, and we should explicitly indicate that experience multiple discussions is necessary for closing contentious, major discussions. We should still allow for challenges based (in part) on lack of experience, it's just that many non-admin closers are much more experienced than almost all admins. Firefangledfeathers (talk / contribs) 01:14, 19 July 2024 (UTC)[reply]
This isn't any different from any other process. I spend a lot of time at DYK. For all the chaos that goes on there, there's an effective culture of new people being groomed to take on greater responsibility. You start out by doing your obligatory initial reviews and move on to more complicated things like building prep sets. People inevitably make mistakes, the mistakes get fixed, experience is gained, and the cycle continues. WP:GA works the same way. And WP:FA. And dozens of other nooks and crannies of the wiki where just plain editors sans mop keep everything going. As it should be. When somebody's been working in an area for a long time, they become an expert at it. The idea that some random admin who's never worked in that area could possibly do a better job is absurd. RoySmith(talk)01:37, 19 July 2024 (UTC)[reply]
I agree with Roy.
@Firefangledfeathers, even a "major" discussion on an officially Contentious Topic™ can sometimes be easy and uncontentious to summarize. The ideal result of an RFC is that everyone already knows what the outcome is. A given participant might be inclined to privately summarize that outcome as "The community is a bunch of jerks who'll be the first up against the wall when the revolution comes", but even the most passionate editor on the "losing" side can often recognize when a consensus has been reached for the "wrong" result. In such cases, we don't necessarily need a highly experienced editor to state the obvious. WhatamIdoing (talk) 21:53, 19 July 2024 (UTC)[reply]
Outside of deletion discussions and other outcomes that need an admin to carry out (where it absolutely does make sense), I view invoking BADNAC as essentially scope creep. You don't need to be an admin to close RfCs, at all. But I don't think it's fair to dismiss people who bring it up as baseless wikilawyers either. Usually what they're trying to allude to is that contentious discussions are hard to close and therefore that the community expects someone with experience in making successful closes to do it. This is a good and widely agreed upon principle, but it's not written down with a handy shortcut, so BADNAC gets invoked instead. If we articulate that broader principle somewhere, I think we'll see BADNAC cited less often. – Joe (talk) 07:32, 19 July 2024 (UTC)[reply]
Outside of deletion discussions and other outcomes that need an admin to carry out (where it absolutely does make sense). There's no fundamental reason why a non-admin can't close an AfD as "delete" and then find an admin to actually push the button. In fact, it looks like {{Db-xfd}} covers exactly this use case. This is similar to how non-admin SPI clerks can determine that an account is a sock and should be blocked and then have to go find an admin to do it for them. RoySmith(talk)14:57, 19 July 2024 (UTC)[reply]
No fundamental reason, no, but why create the extra work and complexity when we have no shortage of admins willing to close AfDs? Any process that requires admin intervention should be left to admins unless and until it becomes obvious they need the extra help (as with SPI), as matter of efficiency if nothing else. – Joe (talk) 15:04, 19 July 2024 (UTC)[reply]
I think that's over-broad. I think you shouldn't have to be a sysop to close an RfC that's about making a change to a fully-protected page, for example.—S MarshallT/C18:11, 19 July 2024 (UTC)[reply]
Pressing delete from a closed AfD feels like a situation where an admin would need to verify consensus in the first place and so now you've spent the time of two editors where one could have done. Beyond that, I am pretty staunchly opposed to admin close creep in places like RfCs. When I was a regular at AfD, I found non-admin work to be far less "right" than with RfCs; I think it attracts a different kind of non-admin. Best, Barkeep49 (talk) 04:02, 20 July 2024 (UTC)[reply]
@Barkeep49 your point about the button-pusher needing to verify the result is valid, and indeed I've made similar arguments myself. But a good close can make that job a lot easier. A good close won't just say "Consensus to delete". It'll summarize the main points made on both sides, list the minority opinions, and talk about which arguments were rejected by other discussants (or by the closer) and for what reasons. With a good analysis like that, you can get your head around the discussion without having to read every word. And, yes, the button-pusher is ultimately responsible for their actions, and I assume all responsible button-pushers will dig as far as they feel is necessary to validate the summary. RoySmith(talk)15:55, 21 July 2024 (UTC)[reply]
Most AfDs don't require a long closing statement or often don't require any closing statement. This lack of need for closing statements is a way that AfD is different from RfCs. This also doesn't change my point - it's not a good use of editor time to close something which will require substantial re-verification to implement (outside of processes like DYK which are designed to have these multiple levels of checking). Best, Barkeep49 (talk) 17:15, 21 July 2024 (UTC)[reply]
It's true that "Consensus to delete" is an adequate close for many AfDs. I would expect somebody to write the kind of detailed analysis I outlined above only for discussions that warranted it due to their complexity. RoySmith(talk)13:35, 22 July 2024 (UTC)[reply]
now you've spent the time of two editors where one could have done is true, but we don't stop people from wasting their own time. The admin would have to spend time to process the deletion regardless of whether it was NAC'd first or not. So in the NAC scenario, the only person who's time is arguably wasted is the NAC who volunteered their time to do this, and if that's how people want to spend their time, I don't see why policy should prohibit them from doing so. Arguably, two sets of eyes is a benefit anyway, so it's not necessarily wasted time at all. Levivich (talk) 23:51, 21 July 2024 (UTC)[reply]
I would distinguish between a discussion close that's a content decision, and one that's a conduct or technical decision. There are philosophical and principled reasons why we absolutely must not give sysops special authority to make content decisions. Conduct decisions in CT areas, on the other hand, are best reserved for sysops even where an unelected person could make them.—S MarshallT/C07:58, 19 July 2024 (UTC)[reply]
There are non-admins (like S Marshall) who would be in the top 10% of admins regarding closures (even if I disagree with one) if they were one. And vice versa. It's just that the odds and optics are better when it's an admin. I think that the current guidance on this is about right. North8000 (talk) 15:46, 19 July 2024 (UTC)[reply]
There a many inherent reasons for people not to close long, complicated, or contentious discussions, so I see the lessening of the pool of willing closers as throwing the baby out with the bathwater, so to speak. Alanscottwalker (talk) 16:06, 19 July 2024 (UTC)[reply]
It cautions non-admins against closing potentially contentious discussions, but does not prohibit them. WP:NAC should do more than caution, but still should not prohibit. It should advise against NAC closes of contentious discussions where consensus is not abundantly clear.
We have a good few experienced non-admin closers. Absolutely. Adminship is not a requirement for being a good closer, but being a good closer is something tested at RfA, or at least, not being a bad closer and knowing your own strengths is tested at RfA.
Some challenges to NAC closes may be unfair, but this depends on perspective. It is a fact that many ordinary Wikipedians do not consider a non admin close of a contentious discussion to be a satisfactory close. This is not a reason to slap down ordinary wikipedians, but for non admins engaging in advances functions to do it more conservatively. A good skillful close should make a contentious-looking discussion look no longer contentious.
If a non admin's close of a discussion produces another, longer, more contentious discussion, then their close was not a net positive contribution, and they should not do such closes.
We should advise non admins to not close contentious discussions unless they are very confident that they will explain their close to the satisfaction of all the participants. Alternatively put: If an admin is confident that they can close a discussion to the satisfaction of all participants, then they should be encouraged to do so. Despite being very confident, non admins are allowed to be wrong, sometimes. Don't make a habit of it. If a challenge to their close surprises them in any way, then strongly consider reverting the close and listing it at Wikipedia:Closure requests. Then, sit back and see if someone else closes it the same way.
In any discussion, the closer should be the least important person, not the most important person.
All of the above should apply equally to XfDs, RM, and RfCs. It should apply moreso to closes at AN, DRV, MRV and XRV.
Spurious challenges should not be feared. Spurious challenges are characterised by a SNOW endorse at review.
I don't think a special user-right for closing is warranted. If credentials are wanted, I suggest a category of barnstars for good closes.
If a non admin's close of a discussion produces another, longer, more contentious discussion, then their close was not a net positive contribution, and they should not do such closes. Sometimes admin closes are bad and result in additional contentious discussions. Admins aren't magically better at analytical thinking.
We should advise non admins to not close contentious discussions unless they are very confident that they will explain their close to the satisfaction of all the participants. I agree. The guidance should be "to each according to his ability". But, per my first bullet above, the same should be said for admins. If an admin doesn't feel confident that they have the chops to close a particular discussion, they shouldn't feel like their status gives them license to bite off more than they can chew.
Don't make a habit of it. If a challenge to their close surprises them in any way, then strongly consider reverting the close and listing it at Wikipedia:Closure requests. Unless a close is clearly vandalism or extremely incoherent, we shouldn't be reverting closes absent a close review. Otherwise, we invite random editors to revert closes because they think it's inadequate, leading to even more bickering and bad feelings.
I agree that Admins aren't magically better at analytical thinking, but it is a trait that we select for at RFA, so a random admin will usually do better in this area than a random non-admin. WhatamIdoing (talk) 02:58, 28 July 2024 (UTC)[reply]
Amending BADNAC?
I want to be very clear that when I opened this it wasn't because I felt some NACs were inappropriate, but because I wanted to avoid spurious challenges, or challenges where non-admin status was muddying the waters. It's fairly clear that there is strong support for not limiting NACs; so what do folks think of an alternative approach to address the problem I mention, and making BADNAC contingent strictly on experience rather than admin status: that is, essentially striking BADNAC#2, and perhaps strengthening the reference to experience in BADNAC#3? Vanamonde93 (talk) 02:45, 20 July 2024 (UTC)[reply]
I am in favor of striking #2. I think #3 could be struck too; if somebody inexperienced is really good at evaluating consensus and has read Wikipedia's PAGs, I don't see why the close ought to be overturned on those grounds alone. But, I can live with #3 as it's currently if there's consensus that that kind of limitation should be in BADNAC. Also, I've notified WT:NAC of this discussion. voorts (talk/contributions) 03:04, 20 July 2024 (UTC)[reply]
The likelihood that someone using an account with few edits will do a passable job on anything except the most obvious cases is low. Also, it gives anyone on the "losing" side an opportunity to suggest that the newbie is a bad-hand sock, which is more drama that we would like to avoid.
BTW, "experienced editor" appears to be a label that there are different views about. @Levivich and I were chatting about this at Wikipedia talk:Wikipedians#Higher volume: Can someone who has "only" been editing for a year (the median account activity is one day), with "only" 500 edits total (more than 99.25% of accounts that have ever made a first edit), averaging "only" one edit per day during the last month (less than 10% of currently active accounts), be truly considered "an experienced editor"? If you'd like to provide a third opinion (or fourth, or fifth), please share your idea of what the minimum standard for "an experienced editor" could be over there. WhatamIdoing (talk) 05:14, 20 July 2024 (UTC)[reply]
It sounds like we need to temper our expectations regarding how we treat newcomers on Wikipedia, instead of limiting them because others might have bad faith objections.
As for a rare but pertinent counterexample, I noticed Chrhns's close of an RFC within their first 50 edits. It was well reasoned, not "exceptionally obvious" and pretty much the exact close I would make too. I did end up suggesting they edit other parts of the Wiki first, simply because I know how contentious challenges can get. But should they (or editors like them but with 500 more edits) be restricted from one part of the encyclopedia just because they read the rules before they start editing?
I think it's far more important that close challenges cite an actual policy being broken instead of just BADNAC. If a close is flawed, it will be flawed on multiple grounds. Soni (talk) 11:23, 20 July 2024 (UTC)[reply]
Agree in general, CTs excepted, non EC editors cannot close or even participate in internal project discussions. Otherwise I don't object to NACs in principle, if they are messed up, as some will be, we have the procedures to deal with that. Learning by doing is not a bad thing. Selfstudier (talk) 11:30, 20 July 2024 (UTC)[reply]
Your observation that they get challenged more often could be right and a reason to advise non-admin to be careful (thus keeping it included as advice at NAC) without doing the wrong thing of making that advise a prohibition, which is what people are objecting to here. I think some data more than than the philosophical discussion above could be useful in making this kind of decision. Best, Barkeep49 (talk) 04:04, 20 July 2024 (UTC)[reply]
I will attempt to compile data in a few days. I think the problem exists regardless of frequency, however. A close challenge in which the closer's admin/non-admin status has become a factor is, I think, a priori a bad use of the community's time. Evaluations of closures need to focus on other things. Vanamonde93 (talk) 01:33, 21 July 2024 (UTC)[reply]
I oppose simply striking #2 ("The outcome is a close call (especially where there are several valid outcomes) or likely to be controversial") but suggest instead rewording it. As it reads, I don't think it is very good. I suggest, it get ideas started,
"The discussion is contentious and your close is likely to be controversial."
I think it is a good idea to put the judgement of the appropriateness of the NAC in the control of the NAC-er, and point to "the close" as the thing that will be judged. (The number of valid outcomes parenthetical is wordy verbosity)
"#3 The non-admin has little or no experience editing Wikipedia generally or has little or no previous participation in discussions." is good and important. It doesn't require touching. It is important for newbies. To make it easier for newbies to understand, I would suggest closers should have one year experience editing Wikipedia, and 500 edits in projectspace, and 100 AfDs participated before closing AfDs.
Critique or criticise the close, not the closer, absolutely yes, start there. Where the same closer repeated has their closes criticised, maybe there is a pattern of evidence to suggest a change in behaviour.
NAC-ers should be advised to be cautious in closing, not prohibited in closing. NAC-ers should be advised on how the can best help. On a quick review of old-admin closes, I think you'll find they tend to be terse. A newcomer may think that a good close is a terse close. SmokeyJoe (talk) 00:50, 22 July 2024 (UTC)[reply]
nobody can ever know in advance if their close will be controversial? Nonsense. Wrong. If you can't tell that the discussion is contested, with heated participants, and that your close does not address their positions, then you should not be closing. SomeoneTM getting upset over something silly is life, not controversy. SmokeyJoe (talk) 00:45, 22 July 2024 (UTC)[reply]
I think this is the better path. I'd oppose striking #2 entirely, but I think we can make some more room in it for places where NACs are fine by modifying that first clause which seems to be the more objectionable one. I think a small improvement would be The discussion is contentious, (especially if it falls within a Contentious Topic), and your close is likely to be controversial. While it is true that nobody can know for sure if the close will be controversial (occasionally there's an editor who just can't let go), we're only assessing the likelihood which is usually common sense. A high-profile RFC over a controversial WP:ARBPIA issue or certain parts of the MOS, for example, have a high likelihood of being controversial while a merge discussion about insects where basically everyone is on the same page is not. If a closer is unable to see the difference, they probably don't have the judgement to assess consensus anyway. The WordsmithTalk to me18:37, 1 August 2024 (UTC)[reply]
I am in favor of striking #2 and strengthening the reference to experience in #3. I think experience, not the admin bit, is the strongest predictor of good closes. Levivich (talk) 23:56, 21 July 2024 (UTC)[reply]
As I see it, BADNAC serves a couple of purposes. Preventing bad quality closes by telling editors when they might not be appropriate before they attempt to close. Providing the outcome of a close a degree of "authority" against challenges from without or within by setting some minimum standards and allowing closes procedurally to be set aside regardless content. I see the second as being less important than the quality of the close but in terms of optics, if the DAILYMAIL close was made by a 2 day account it would not have had the same weight. Therefore I do see some value in retaining a version of the current #2 somehere in BADNAC which sets a higher bar in terms of required experience for something controversial or complex than a simple snowclose. In terms of how that experience is defined, it should be related to actually closing discussions, not just general editing, and admin status should not be relevant. Scribolt (talk) 08:26, 22 July 2024 (UTC)[reply]
Just throwing this out there: there should be some sort of statement that BADNAC is not itself a grounds to challenge a close, and that challengers should focus on the assessment of consensus, not who assessed it. voorts (talk/contributions) 23:34, 26 July 2024 (UTC)[reply]
I agree with this suggestion.
That section currently ends with ...or could result in a request to redo the process at Wikipedia:Deletion review, and a footnote saying Discuss with the closing editor first before starting a deletion review. We could change it to say:
...or could result in a request to redo the process at Wikipedia:Deletion review. Discuss with the closing editor first before starting a deletion review. If you need to pursue deletion review, your explanation should focus on content. Reviews that only complain that the discussion was summarized by a non-admin, without identifying at least one substantive error in the result, can be removed without warning by any editor.WhatamIdoing (talk) 03:07, 28 July 2024 (UTC)[reply]
I'd oppose at least the last sentence of this. DRV already comes down like a ton of bricks on arguments based solely on the lack of admin privileges, and nominations based solely on that are rare enough that I can't remember the last time it happened. Advising early closes there is already dangerous, since DRVs are themselves overturned so rarely that it's only barely inaccurate to say "it never happens", and so it's important that it's gotten right the first time; simply reverting nominations is even worse, and seems very likely to me to raise the heat in what we try very hard to keep a drama-free zone. —Cryptic03:32, 28 July 2024 (UTC)[reply]
"DRV already comes down like a ton of bricks on arguments based solely on the lack of admin privileges"... so you don't think we should warn folks not to make "arguments based solely on the lack of admin privileges"? WhatamIdoing (talk) 04:08, 31 July 2024 (UTC)[reply]
I mostly object to the rest of the sentence, about removing requests. DRV doesn't even speedy close nominations consisting mostly or entirely of accusations of bias or other personal attacks anymore (despite its own instructions), let alone just blank them. I've got no problem with your suggested text up to and including the WP:FOC link; maybe add something to the effect of ", not just complain that the discussion was summarized by a non-admin." to the end. —Cryptic04:21, 31 July 2024 (UTC)[reply]
I wasn't just speaking to deletion discussions, but also using BADNAC solely as a means to challenge an RfC closure, for example, so I think we need some broader proposed language. Also, the last sentence of BADNAC is odd because it purports to apply only to "inappropriate early closures of deletion debates" (emphasis added), which doesn't really have much to do with the rest of BADNAC. voorts (talk/contributions) 06:16, 28 July 2024 (UTC)[reply]
I think the issue, if there is one, is with bad closes, not specifically with bad non-admin closes. Yes, there is a pretty strong correlation between being an admin and being a good closer, because for both it is usually best to be an "experienced editor" (I'm deliberately avoiding defining that), but correlation is not causation. Phil Bridger (talk) 09:02, 11 August 2024 (UTC)[reply]
I agree that there are many non-admins who are good at closing controversial discussions. The issue is that there are many more non-admins who are bad at closing controversial discussions than admins who are bad at the same thing. So the norm of having admins close discussions does improve the quality of closes.
Because of this, I support something like Thryduulf's discussion-closer userright but wouldn't really support weakening #2 in the meantime. Bad closures are hard to fix and even if the process goes perfectly they waste way more time and effort than just waiting for a better closer, so I'd really rather err on the side of caution here. Loki (talk) 02:37, 13 August 2024 (UTC)[reply]
Templates and WP:MOS
I thought that templates (and modules) used in articles must produce output consistent with WP:MOS. In particular, automatic calculations and unit conversions should use established output formats instead of inventing their own (especially if they are explicitly marked as "unacceptable" in MOS:NUM). Is this always true, or there might be some exceptions? And if such exceptions exist, how they should be established?
My question is general, but the confusion arose from Module talk:Age § abbr=on violates MOS in particular. I was told there (by the WP administrator maintaining the module) that "more than a mention of a guideline is needed to effect a change" and that "it would be good to get opinions from editors currently interested in affected articles rather than rely on a guideline", although without any explanations where these opinions are supposed to be collected and why they should override WP:CONLEVEL. — Mikhail Ryazanov (talk) 00:37, 1 August 2024 (UTC)[reply]
Some easy-to-see cases are at Brazilian currency#Historical currencies. This is not the right place to discuss the details but examples can be helpful to save time:
The issue is that MOS:UNITSYMBOLS says there should be a non-breaking space before the units. Another issue is that m is used as the abbreviation for month (as above) but also for minute, as in the next example from Expedition 59#Uncrewed spaceflights to the ISS.
The manual of style is a guideline, and like all guidelines should be followed unless there is a good reason not to. That is not something that can be discussed at a level higher than either the individual template or a group of closely related templates, because that is the highest level at which it can be determined whether or not there is a good reason for doing something contrary to the guidelines (and that is because the answer is always context dependent).
In the linked discussion there is the additional question of whether the specific guidance in the manual of style is correct on the specific point. Thryduulf (talk) 10:03, 3 August 2024 (UTC)[reply]
It only seems that way if you don't understand what a guideline is. Guidelines are standards that should usually be followed but must be interpreted with common sense and exceptions will apply. This means that the answer to the question "should templates obey the MOS?" is "Usually." However that isn't the question you actually want to know the answer to, which is "should this specific template follow the manual of style?" and that is something that can only be answered in the context of the individual template and so is best discussed at that template's talk page. 01:32, 5 August 2024 (UTC) Thryduulf (talk) 01:32, 5 August 2024 (UTC)[reply]
I am interested in the community consensus, not in your personal interpretation, unsupported by any references (and contradicting the fact that WP:MOS does include many exceptions for specific cases, which would be unnecessary if your ideas about ignoring general guidelines in local contexts were correct). — Mikhail Ryazanov (talk) 03:01, 8 August 2024 (UTC)[reply]
See WP:GUIDES: "Guidelines are sets of best practices supported by consensus. Editors should attempt to follow guidelines, though they are best treated with common sense, and occasional exceptions may apply.
See also the header of each guideline, which says something like "This page documents an English Wikipedia content guideline. Editors should generally follow it, though exceptions may apply." The header varies depending on the type of guideline, but they're all pretty close to that. Firefangledfeathers (talk / contribs) 03:34, 8 August 2024 (UTC)[reply]
Now we need an expert on "common sense"... WP:COMMONSENSE says: "When advancing a position or justifying an action, base your argument on existing agreements, community foundation issues, and the interests of the encyclopedia, not your own common sense. Exhorting another editor to 'just use common sense' is likely to be taken as insulting, for good reasons." And Wikipedia:Ignore all rules linked from "normally"/"occasional exceptions" explains what it actually means: "If a rule prevents you from improving or maintaining Wikipedia, ignore it." I don't think that designing a general-purpose module/template such that it systematically violates the rules without any explanations (or even mentioning the discrepancy) can be called "common sense". I also don't think that broadly using nonstandard formatting, especially if the MOS explicitly calls it "unacceptable", can be considered an "improvement" (otherwise, if this "exception" is really an improvement and is so common, it must be included in the MOS). — Mikhail Ryazanov (talk) 03:18, 9 August 2024 (UTC)[reply]
The point is that if someone claims an exception applies because it improves the encyclopaedia and another person disagrees because they think it doesn't, then what happens next is discussion. That discussion needs to take place in the place relevant to that exception so it has the benefit of full context and is visible to editors who are involved with the relevant article/template/whatever. The consensus of that discussion will determine whether the exception is justified or not.
In this case you need to participate in the linked discussion and make your case there about why you think the the exception is not justified in this particular case. Refusing to engage and just repeating that you don't think there should be exceptions is just wasting your and others' time. Thryduulf (talk) 08:40, 9 August 2024 (UTC)[reply]
Until recently, my impression was de-orphaning can sometimes be beneficial (I did a bit when I was starting to edit) but, in most cases, isn't hugely significant because decent search engines are widespread. Additionally, many orphans cover naturally obscure topics which just aren't going to get many readers or improvements even if they were linked elsewhere.
However, I've been coming across cases where de-orphaning has actually made things worse, generally by giving too much weight to a subject we might not even want to have an article on in the first place. For example, I recently cleaned out a large number of dubiously-notable companies whose establishments were listed as nationally prominent events on pages like 2000 in the United States because of systematic de-orphaning.
It's become increasingly unclear to me whether de-orphaning efforts, as currently practised, are doing more good than harm. But this is based on my impressions, not detailed analysis. So I'm interested to hear others' thoughts.
It probably depends on exactly what is meant by deorphaning. Adding links to relevant articles is good, in that it provides readers a path to find new information. Search cannot help someone find something they don't know they are looking for. The 2017 and 2019 discussions however make a good point that deorphaning as an end in itself is obsolete.Stepping back slightly, is there more information on what the de-orphaning efforts as currently practised are? The adding of links where they are not beneficial is not great, but how much of it is a problem, and is it a systemic issue or a relatively occasional occurrence? CMD (talk) 06:54, 5 August 2024 (UTC)[reply]
The issue with de-orphaning is that it tends to be rather black-and-white. WikiProject Orphanage has the singular objective of reducing the backlog of orphaned articles, which can result in articles that may not meet GNG being given undue weight. Something like the introduction of an 'Orphan-Notability' template, alongside the 'Orphan' template, might help. When de-orphaning a particular article, the option of replacing the 'Orphan' template with 'Orphan-Notability' would create two lists: one for orphaned articles and another for orphaned articles requiring a notability check before they are de-orphaned. Svampesky (talk) 09:15, 5 August 2024 (UTC)[reply]
I've seen good things happen from good links. If an article has no inbound article links it gets very few page views, and thus very few edits. With meaningful links from other articles it is now being seen by readers interested in related topics, and someone reading an article on one topic is probably just the person to make good edits to a related article they click through to. It's true that low-quality links, like linking to a dubiously notable company in a large city article because the company is based there, tend to lower the quality of the established article. Cluttering it up without adding useful information for readers.
I think if meaningful, good article links can't be created to an article, that's a strong sign that the article subject is not notable. It's not a criteria for deletion of course, just an indication that a topic might not be encyclopedic, if no other encyclopedia articles should even mention it. Here2rewrite (talk) 11:29, 5 August 2024 (UTC)[reply]
+1 for I think if meaningful, good article links can't be created to an article, that's a strong sign that the article subject is not notable.. CapitalSasha ~ talk11:33, 5 August 2024 (UTC)[reply]
As an "Orphanologist" working on oldest orphan articles (beginning with 2014 backlog articles), I have seen much progress. At one point the backlog was over 120,000 articles and now about 55,000. And millions more of non-orphan articles. Prior to my involvement, the consensus is to make orphan tag "invisible" after two months. My suggestion would be to show all orphan tags. Regards, JoeNMLC (talk) 13:11, 5 August 2024 (UTC)[reply]
It always seems odd to me if an article can't reasonably be linked to other articles. This could of course mean that those other articles are missing rather than that our orphan is not notable. As for whether we use visible or invisible tags, it rather depends on whether we think the task is something we want to invite our readers to do. In its early days, yes I assume most new orphans can easily be linked into the project. After some time it ceases to be a newbie task and it requires a bit more experience of the project - does this link improve the pedia or is it visual clutter? I'm not sure whether two months is the right time and if not whether it should be increased to three or more or reduced to one. But if we were going to change the interval I'd like it done with some data as to the relative ease of deorphaning articles after one, two or three months. Ideally the link should become invisible at the point where deorphaning becomes a task we don't want to promote to newbies. ϢereSpielChequers13:33, 5 August 2024 (UTC)[reply]
I don't find this odd at all, and being an orphan isn't the end of the world. Of course some articles are crying out to be linked to (creators of new articles are often very poor at looking for links to add). I'm strongly against WP:UNDUE adding the name and a link just for the sake of de-orphaning. Johnbod (talk) 15:08, 5 August 2024 (UTC)[reply]
When this was discussed in 2017, I left rather lengthy comment. Although I no longer de-orphan to the same extent that I once did, I still think the tag is valuable as a diagnostic that signals that an article should be looked at. As I said back then, I have found plenty of instances where investigating why something is tagged as orphaned has helped me improve Wikipedia - merging duplicate articles, upmerging stubs to parent articles, creating new articles in a taxonomic chain, fixing broken links, and initiating the deletion of junk that no one has laid eyes on in years. Issues can arise when people focus more on the idea of removing the tag at all costs rather than figuring out what to do with the article, but that can happen with any maintenance backlog. Think of someone who mass-redirects unsourced articles rather than improving sourcing. Is the problem the tag, or the behavior? Let's not throw the baby out with the bathwater if we can solve the crap-links problem by dealing with whoever is doing it. ♠PMC♠ (talk)08:00, 6 August 2024 (UTC)[reply]
I agree. Even if someone deorphans by mechanically adding a See also link to a more prominent article, the watchers of that more prominent article will then be alerted to the lesser article and it then has an opportunity to be improved. ~Kvng (talk) 14:20, 8 August 2024 (UTC)[reply]
As is often the case when editing WP, de-orphaning requires a degree of editorial judgement. The problems almost always occur when people edit without discernment - adding links just for the sake of linking. The reality is that some de-orphaning links are very beneficial, while others are not. Blueboar (talk) 14:44, 8 August 2024 (UTC)[reply]
The relevant policy/guideline is actually already there:
It may be the case that some articles currently just cannot be de-orphaned. If this is the case then please do not try to 'force-fit' by adding unrelated links to articles where they don't belong just for the sake of de-orphaning. Always keep in mind that our primary goal is to improve the reader's experience, not satisfy the editor's indulgence in statistical achievements. Your priority when adding links should be to maintain article quality by adding relevant and useful links wherever possible — WP:CANTDEORPHAN
So, unnecessary links can always be removed. But it's not always bad, and the inclusion or non-inclusion criteria of certain articles in general articles such as "X year" may not be straightforward; what "degree" of notability (if a person has an article on Wikipedia that person is already notable) a person has to have to be included in "Births"?
Companies can be included in some lists by location or something else. What to put in "See also" is also covered by a guideline.
But do some articles even need to exist? I somewhat agree with other users regarding the (probable) lack of notability (though it may require changes in some notability policies). The other important thing here is the size of the article. Members of the state legislatures are presumed notable, but what if the fact that a person was a member is almost the only thing we know about them? Example. Named natural features are often notable, provided information beyond statistics and coordinates is known to exist. But for some very small streams, this "information beyond" is the etymology and what bodies of water they flow into (sometimes another small stream). Example, Example. The same doubts arise regarding small unidentified villages (that may not even exist), very small neighbourhoods or just "areas".
Finally, there are some interesting guidelines about orphans: Editors may also remove the tag from any article if they believe that de-orphaning is unlikely to be successful, or if they have attempted to provide incoming links-//-However, if you are certain the article is unlikely to ever be de-orphaned then simply remove the tag. Can this also be the answer sometimes? It can also be elaborated. For example, after some time and/or a number of attempts an article may be declared "hopeless" and the tag may be removed.
The reality is that some de-orphaning links are very beneficial, while others are not. A lot of those that "are not" are not harmful either. Oloddin (talk) 05:53, 10 August 2024 (UTC)[reply]
Let's go a bit deeper here. So far, a fair few editors have said something along the lines of "well, sometimes de-orphaning is beneficial and sometimes not", with varying emphasis on "sometimes beneficial" and "sometimes not". But what proportion of de-orphaning, in practice, is beneficial? Is it 90% beneficial, 10% not so much? 70–30? 40–60? 20–80? And where is the threshold for "this benefits Wikipedia on net"? – Teratix₵02:59, 13 August 2024 (UTC)[reply]
To go a bit broader, I would estimate that 90% of good-faith edits are beneficial. The deorphaning edits I have reviewed have about the same level of quality as the other edits I review on my watchlist. ~Kvng (talk) 13:42, 13 August 2024 (UTC)[reply]
"De-orphaning" is not some special process; it's simply connecting an orphan with the other articles by creating links to the orphan. This is beneficial unless these links don't fit into the articles where an editor is trying to put them in. It's hard to estimate how often that happens (not least because, again, whether the link belongs or not is often subjective), but I would say not too often (I agree with Kvng on that). In general, the appropriateness of a link, of some text that includes a link, or of the element in the list (or list-type article) is not dependent on whether it was an attempt to de-orphan or not. Oloddin (talk) 22:36, 17 August 2024 (UTC)[reply]
Palaeogenetics and ethnicity in articles
I had this big plan where I'd intentfully draft my case before even making a post here and it would have robust sourcing and all that, but I realized I should just go for it and if there's any agreement other editors will chime in.
The key summary is: the scholarly field of palaeogenetics (or archaeogenetics) has exploded in the past decade-plus. The data we can collect from the DNA of millennia-old human remains is a shocking new advancement. However, scholarly sources often use ethnic labels for the historical genetic populations they are studying. This creates friction with the universal understanding among serious people since the end of World War II that ethnicity is a social and cultural category, not a genetic one; one's ethnicity is the result of human choices and not amino acid pairs. As such, the distinct field of ethnography generally shies from ascribing ethnic identity to almost any individual that isn't the author or focus of direct literary analysis. To wit, speaking of "Lombard DNA" (etc.) is completely inane if we're to take it as face value; it is best defended as a shorthand for lack of better language to use in these papers.
That said: if one has pages for historical people groups or demographics on their watchlist, they will notice a lot of tertiary analysis of these studies being added to articles, which often transparently conflate the actual subject of the article with genetic populations analysed in a distinct manner, sometimes because that's what those sources themselves do. I think we should consider some guideline regarding the correct representation of what this information is actually saying and how it relates to the universal notion of ethnicity otherwise described in articles about them. Remsense诉07:10, 7 August 2024 (UTC)[reply]
There should be agreement in principle, the discussions on the topics I've seen (and been involved in) tend to land on ensuring that such genetic studies are not over-emphasised in relevant articles. The biggest risk is that detailed coverage of X or Y genetic study, which will use shorthands out of necessity (often explaining so in the paper), gets added to an otherwise underdeveloped article and thus turns the paper output from perhaps an academically interesting note about a certain group of people that comes with a lot of interpretative caveats, to coming off in the article as a defining trait of said group of people. I haven't seen an academic paper suggest that the genetic studies overturn ideas of ethnicity, however unfortunately the papers do get entangled with the many complex issues surrounding defining ethnicity on individual and group levels. I would support a broad guideline noting the principles of understanding the limitations and limited meaning of such studies. CMD (talk) 08:25, 7 August 2024 (UTC)[reply]
The issue isn't that academics suggest genetic studies overturn ideas of ethnicity (particularly the broadly accepted social-constuction one). Rather, the issue is that that the people doing the genetic work have a tendency to use labels as shorthands and these labels frequently coincide with ethnic terms, but they do not mean the same thing in the two contexts. Remsense is onto a for-real problem, one that I've noticed myself, but which WP hasn't really tackled. We have a general "follow the sources" habit of using whatever terminology the source material does, but we have a central purpose and principle to not confuse and even directly mislead readers, especially in a way that promotes pseudo-science (even by inference/assumption/misunderstanding). So, this is the sort of case in which we need to diverge from the (sloppy) practice of some of the specialist literature in a particular field that has mis-borrowed terminology from another, broader, and much better-established field. Exactly how to do that is open to some question. We're not in a positition to make up alternative terminology (WP:NOR), but we are probably in a position to "scare-quote" any ethno-cultural terms that are misused by geneticists and explain (perhaps in a footnote, maybe a standardized templated one) that the term in this context does not equate to an ethnic, racial, linguistic, cultural, politico-national, or other socially defined grouping, and is being used as convenience label that simply refers to a haplogroup's primary geographic locus (often by reference to a social group associated with that area). — SMcCandlish☏¢ 😼 10:33, 12 August 2024 (UTC)[reply]
The issue I mention is not with the academics, it's with the interpretation of the work of the academics here. The easiest way to not mislead readers is not to use the sources where they shouldn't be used, as has been done at various times. Talk:Colombia#RfC: Genetic ancestry of Colombians is the most recent discussion that comes to my mind. CMD (talk) 11:36, 12 August 2024 (UTC)[reply]
More the use than the interpretation. The problem can be alleviated if we:
Include |quote= in the citations.
Include a nomenclature section near the beginning of the article, explaining the variations in nomenclature and the specific nomenclature used in the article.
What I perceived to be the best solution was simply to (make it a guideline to) change the terminology used in the article—e.g. Lombard DNA → DNA of populations in modern Lombardy c. 600 AD or what have you—reflecting a responsible tertiary analysis in the context of the article as a whole. Remsense诉01:06, 13 August 2024 (UTC)[reply]
I can't help but think this is going in circles. The name "Lombardy" derives from the name of the people who lived there c. 600 AD, so how much distinction is there really between "Lombards" and "populations in modern Lombardy c. 600 AD"? How often did a group of people have limited enough exogamy to have both a distinct genetic profile and a distinct culture, so both paleogeneticists and ethnologists would be reasonably correct to use the name of the group? Anomie⚔02:09, 13 August 2024 (UTC)[reply]
The etymology of the toponym is irrelevant—it's just the modern geographical area where the modern extractions were made, as an example. Swap out with whatever name for the studied political, topographical, or geological area as appropriate/given in the source. There's obvious distinctions made between ethnic groups in a given area even in antiquity—esp. given the historical migrations of Germanic groups like the Lombards versus "native" Italians. Hence why it was a particularly illustrative example, another would be between groupings of Anglo-Saxons, Britons, and others in early medieval Britain.Remsense诉02:11, 13 August 2024 (UTC)[reply]
(edit conflict × 2) The etymology of the toponym is relevant since you're proposing saying "the people who lived in Lombardy c. 600 AD" is somehow obviously distinct from "Lombards" when "Lombardy" means "the region where the Lombards lived c. 600 AD". Or, with the attempted "clarification" in the (edit conflict), are you sure the paleogeneticists are really that sloppy that they're assuming everyone currently living in Lombardy is a decendent of the people who lived there 1400 years ago or something like that? As for the rest, you're ignoring my question and going off on an irrelevant tangent. Anomie⚔02:27, 13 August 2024 (UTC)[reply]
No, Lombardy here is meant as Lombardy, the modern region of the modern nation-state of Italy. (Sorry for the post-hoc editing.) And yes, many papers use ethnic labels as shorthand when ethnic groups are not what is being studied. Remsense诉02:30, 13 August 2024 (UTC)[reply]
Thank you for the elucidation here: I really should have picked some real-life examples from articles but I really didn't want to embarrass anyone in particular and felt the practice was ubiquitous enough that anyone with the inclination would likely know what I'm talking about. Remsense诉18:57, 12 August 2024 (UTC)[reply]
In a section above, Oloddin asked "the inclusion or non-inclusion criteria of certain articles in general articles such as "X year" may not be straightforward; what "degree" of notability (if a person has an article on Wikipedia that person is already notable) a person has to have to be included in "Births"?" I think this is a very good question, and on a quick look I couldn't find any guidelines that answered it (please let me know if I've missed it). Should the article 2000 in the United States include everyone in Category:2000 births born in the US? If no, who should it include/exclude? Nikkimaria (talk) 02:58, 11 August 2024 (UTC)[reply]
So long as a person is notable in Wikipedia terms, I would say they should be included. General year lists include everyone born in those years. I don't see why year in X nation lists should be any different.voorts (talk/contributions) 03:15, 11 August 2024 (UTC)[reply]
Shortly after that discussion, I took this "consensus" to the Village Pump and then ANI, where it was found to be a false consensus and one of the editors enforcing it was topic banned. Thebiguglyalien (talk) 06:57, 11 August 2024 (UTC)[reply]
I agree that we ought to have some inclusion criteria. International and national notability for year and year by nation articles respectively seems to be one workable guideline, although I'm not wedded to it.voorts (talk/contributions) 04:04, 11 August 2024 (UTC)[reply]
Per the RfC linked above long lists of births should be removed. Most birth inclusions also seem questionable weight-wise in general; most notable individuals were not notable at their births, and their births would not have had a significant impact on X year. CMD (talk) 07:28, 11 August 2024 (UTC)[reply]
The RfC you both mentioned was (as I understand it) about splitting rather than removing births/deaths and didn't establish a consensus where these removed births/deaths should go. It's also stated that most participants do not favor total deletion of deaths and no agreement about births. I think it's technically possible to break down "complex" year births/deaths articles into smaller articles "births/deaths in X year", "births/deaths in XX month in X year" or even "in XXX days" to cover all people (especially if we classify them further by location/nationality, occupation etc.) in an organized way. The question is whether we should do it. Regarding impact, there are some articles from time to time like "<someone famous> born this day" or "<someone famous> born 10/25/50/100 years ago". --Oloddin (talk) 02:25, 12 August 2024 (UTC)[reply]
– This RfC existed in two places. That's bad. Editors were commenting at both venues, causing the discussions to fall out of sync with each other. I have no position on which venue is appropriate, but there should not be two. I have defaulted to the original venue. If it turns out it should be here, revert me, unless that would end up recreating the problem. – Teratix₵09:57, 12 August 2024 (UTC)[reply]
What is the policy for maintaining access to Wikipedia's library?
It took me six months of steady editing to gain access to the library and for months now, I haven't been able to clip articles at Newspapers.com because I access it through an Ancestry account. Needless to say, this has slowed my editing significantly. How many edits do I have to complete in what sort of timeframe to maintain access? Not being able to clip articles for citations for so long has really sapped my enthusiam but I don't want to lose access to the library after working to gain it in the first place. Oona Wikiwalker (talk) 01:27, 19 August 2024 (UTC)[reply]
Note that there are known issues with Newspapers.com through TWL right now, not sure what the status on fixing them is though. ― novov(tc)01:39, 19 August 2024 (UTC)[reply]
Technical
Adding transparency to make templates more dark-mode friendly
As someone who has witnessed the transition to Fandom Desktop which had a dark mode included, I want to suggest something that might actually be good for templates, and that is adding transparency to backgrounds (not to the font, just to backgrounds using rgba or hex codes) This could be done automatically but it might be better to do so in wikitext and may be a good addition to the manual of style. This would allow the text to be colored white (or whatever) and we would not have to auto-color stuff with backgrounds black. I wonder what level of transparency would be good for this. I was thinking 0.1 but there isn't a good way to check. Maybe this could be done as a bot task for inline styles and by interface admins for CSS sheets. AwesomeAasim19:34, 6 August 2024 (UTC)[reply]
Wait that is so weird. Why is the text color being changed to this black color when background tags are used? I am just testing with safe mode and it is happening. Thoughts? AwesomeAasim22:48, 11 August 2024 (UTC)[reply]
@Awesome Aasim: The text color is changed to black because a CSS rule was put into MediaWiki that automatically sets the text color to #202122 in dark mode if no text color is specified locally. If you don't want this to happen, you can simply add color:inherit; like this: Green. Andumé (talk) 01:06, 12 August 2024 (UTC)[reply]
I am still confused why was that task implemented? They probably should have just consulted with communities first as to how they would like templates and whatnot to be implemented. Using a light/dark mode switch would be ideal but having partial transparency would be easier to implement for template designers. Especially for the number of templates that use a combination of inline styles and TemplateStyles. I think there should probably be a task for adding transparency to inline elements. AwesomeAasim16:09, 12 August 2024 (UTC)[reply]
Adding 'display:transparent' is a later stage thing and too soon to do now. Since you are mentioning templates and templatestyles, pages in the template namespace that are not redirects or subpages are 3047 and number of "styles.css" pages in the template namespace are 570. Disabling night mode styles from Wikimedia Messages needs to be done with other changes that make the whole stylesheet unnecessary. Snævar (talk) 02:27, 13 August 2024 (UTC)[reply]
That CSS does not work. There is the opacity property but that is not what we should use. We should be adding transparency to just the background colors, like I showed above, not to the entire elements. AwesomeAasim18:52, 15 August 2024 (UTC)[reply]
Exactly as title. The checkbox states that it would last a year, yet sometimes I would find myself not logged in even though I am using the same device, same browser, etc. It is just a mild annoyance, but can someone give me pointers on how to fix this? Thanks in advance. —Mint Keyphase (Did I mess up?What have I done?) 01:26, 8 August 2024 (UTC)[reply]
Anything that clears or blocks your local storage (cookies) can invalidate your saved logon. Some browser or browser extension updates can cause this. — xaosfluxTalk15:10, 8 August 2024 (UTC)[reply]
FWIW I was logged out unexpectedly under similar circumstances on the day this was posted as well. I use Windows primarily with Chrome; if you also have a similar configuration, that *could* be an explanation. Graham87 (talk) 04:26, 9 August 2024 (UTC)[reply]
@Mint Keyphase: Do you use uBlock Origin like me? That's the only thing I think we could have in common. But even that would be a pretty common combination .... it could've just been bad luck. I suspect a lot of people wouldn't report being unexpectedly logged out, because it's a relatively minor inconvenience; I certainly didn't think to. Graham87 (talk) 12:10, 13 August 2024 (UTC)[reply]
How often does this happen? Every time you close the browser? Shut down the computer? Can you log in to other websites with the same browser and they persist just fine? Nardog (talk) 15:59, 14 August 2024 (UTC)[reply]
Does your device have any kind of storage problem; if there is cookies are likely to be auto-deleted. Vestrian24Bio (TALK) 04:48, 16 August 2024 (UTC)[reply]
I’ve been noticing a similar thing. Most of the time I get auto logged back in the moment I hit log in, but sometimes I get fully logged out. I use WIN11+Brave and IOS+Safari. Lordseriouspig04:32, 18 August 2024 (UTC)[reply]
If it's as infrequent as once every couple of weeks (and I'm guessing you use Wikipedia considerably more frequently than that), then I'm going with you either logged out on another device or you logged out from some other Wikimedia website. For most web services, your session is tied to your browser or browser instance, but on Wikimedia, when you logout from any Wikimedia session on any browser instance or any computer, you will be logged out on all instances. Fabrickator (talk) 04:52, 18 August 2024 (UTC)[reply]
I'm having the same issue; Sometimes I am logged out and a message comes up saying "You're Centrally Logged In" and I'm logged in automatically; Sometimes I am logged out and logged back in when I press the log in button; Sometimes I have to re-enter my log in credentials again to log in. Vestrian24Bio (TALK) 06:24, 18 August 2024 (UTC)[reply]
As I recall, I was seeing that business of being logged out and a message came up saying "You're Centrally logged in" and then I would be logged in automatically a few weeks ago, but not lately. Editing only from a chromebook. Donald Albury15:43, 18 August 2024 (UTC)[reply]
Add A Fact experimental tool from Future Audiences
The Future Audiences team at the foundation is launching Add A Fact, an experimental tool for adding information to English Wikipedia from outside the website. You can download the extension from the Chrome store here: Add A Fact. For now, an (auto)confirmed English Wikipedia account is required to submit facts with this extension.
The idea was developed and workshopped with Wikipedians at WCNA 2023, demoed and tested with Wikipedia community members as part of our team’s regular monthly community calls.
Here is a short demo video on the extension:
A quick how-to —
While reading any secondary source on the web (a news item, a scholarly article, etc.), you can open Add A Fact and highlight a short claim that you may want to add to Wikipedia.
An LLM will check if the selected claim is related to any existing Wikipedia articles, and will present information about whether the fact is fully, partially, or not present in these articles. You may also search for an article of your choosing.
Once you select a Wikipedia article to add your fact to, Add A Fact will give you the option of sending a pre-filled template message to the talk page of the article, which includes the selected text, any additional comments you’d like to add, and a structured citation. This message will be signed under your Wikipedia username.
If the URL of the source you are on appears on WP:Reliable_sources/Perennial_sources, you will receive a warning message about your source’s reliability (but will still be able to add a suggested fact from this source). If the URL of the source you are on appears on the spam blocklist, you will not be able to add a suggested fact from this source.
To limit any potential misuse/spam, Add A Fact users will be limited to sending a maximum of 10 facts per day during this early experimental period.
Add A Fact seeks to prove or disprove a hypothesis about how we might continue to sustain and grow Wikimedia projects in a changing online knowledge landscape. In this case, we’re seeking to understand how people can make editorial contributions off-platform (that is, without going directly to Wikipedia.org), and if generative AI can support or hinder this process.
If it's a a chrome extension, it will work on Vivaldi, which is better than all previously mentioned browsers, imho. Another possibility is Opera, which can also use the extension, but Vivaldi is better. (We can take this offline to my UTP, or yours, if you wish to go into more detail about browsers.) Mathglot (talk) 00:01, 13 August 2024 (UTC)[reply]
That's a good point. We tried to have the tool warn you about unacceptable sources but encoding all the nuances of the rules is hard. But doing this better is something we should look more into. DErenrich-WMF (talk) 23:05, 9 August 2024 (UTC)[reply]
Having the demo advertise a kind of edit that should never be done is hardly a "nuance". Wikipedia got a good reputation for how it handled the COVID crisis precisely because editors stuck to standards that your demo tells people to avoid. XOR'easter (talk) 21:11, 11 August 2024 (UTC)[reply]
The message left on the talk page, will that include some template or tracking category, so that editors can easily find a list of facts to be added, and act upon them? Otherwise, especially if the facts are posted on lesser-watched talkpages, it'll be like shouting into the void. --rchard2scout (talk) 06:30, 10 August 2024 (UTC)[reply]
Will we be able to find out how many facts posted to talk pages have been reviewed and used in articles, as opposed to rejected, and how many have not been considered at all (eg because of being on a less-watched page)? In what other ways will this tool be evaluated? For example, how might we detect an increase in, as the close of Wikipedia:Administrators' noticeboard/IncidentArchive1160#User:Drbogdan, persistent low-quality editing, and WP:NOTSOCIALNETWORK issues put it, mass-adding content based on low-quality popular science churnalism to our science articles, expecting that other editors will review it and determine whether to improve or remove it, leading to an indefinite community block? NebY (talk) 01:56, 11 August 2024 (UTC)[reply]
Once the experiment is complete (probably in a few months) we will put together a report with our findings. See for example the report for the last project we did. The metrics we're looking at are the kind of things you'd expect: number of users, number of edits, number of reverts, etc. But probably more importantly we're also collecting qualitative evidence (e.g. discussions like this one, feedback forms or by manually looking at the edits being made). DErenrich-WMF (talk) 04:09, 11 August 2024 (UTC)[reply]
@DErenrich-WMF Reverts aren't a meaningful metric for this tool. The tool will post on the talk page and talk page posts are rarely reverted. The only revert metric that would be useful would be the number of resulting additions to the article that are reverted, but that would be very difficult to collect.
Instead, a viable metric would be the proportions of talk page facts that were implemented, rejected, or not acted on. If tool postings used a format similar to {{Edit semi-protected}}, this might be feasible. It would also be immediately helpful to reviewing editors.
It is a bit surprising that the experiment hasn't been designed to allow meaningful reporting and evaluation. Is there some need to to start the experiment regardless, or can you build suitable metrics into it before release? NebY (talk) 14:45, 13 August 2024 (UTC)[reply]
Let's please find a way to make this tool avoid good and featured articles. The last thing we need is to be experimenting with new users and our content that has actually gone through some sort of content peer review. Hog FarmTalk21:21, 11 August 2024 (UTC)[reply]
Yes, that's interesting; I have it installed (on Vivaldi) and will be trying it out.
But I have a proposal for you, that imho, would be far more useful that I would like to bring to your attention. Basically, it means flipping the script on Find-A-Fact and doing it in the other direction. That is, finding an assertion on Wikipedia (possibly with the aid of the Category populated by {{cn}} tags), highlighting it, opening your next extension, which goes to AI and tries to find a reliable source to verify it. (It would possibly use WikiProjects listed on the Talk page to better target its search, and would be aware of perennial sources, as well as the WP blacklist, WP mirror sites, and other helpful exclude- or include-criteria.) It would read the source(s) (up to max-sources maybe?) and then pop up or fill a box with the citations, optionally augmented with better wording (Reword (y/n)?) for the assertion that currently exists in the article. At that point, there could be two paths (Talk or Article?): if user wants to go the Talk page route (default) then you do something similar to what Find-a-Fact does, and compose something for the talk page. If they want to go the Article page route, then you open the article in Preview mode, add the citation(s), optionally replace the existing assertion if AI was able to compose a better one and user selected that option, and show a Diff of the new version you are proposing, along with a canned edit summary. (Note that this flow, i.e., OpenPage-AddChanges-Preview-Diff-and-Wait, is similar to what some user scripts do currently, such as Nardog's RefRenamer script.) Then, user either accepts the change, optionally modifies the edit summary, and hits Publish, or they Cancel, or they go back to the extension box, altering options and checkboxes and hit Apply to try again with a different set of options. How does that sound? Mathglot (talk) 00:35, 13 August 2024 (UTC)[reply]
Do you mean when viewing Special:Watchlist? Here's a CSS rule that hides both:
/* hide edits to redirects and redlinked pages from watchlist */li.mw-changeslist-line:has(a.mw-redirect),li.mw-changeslist-line:has(a.mw-changeslist-title.new){display:none;}
I know this must be an extremely dumb question, but please bear with me.
I have just finished drafting a long article (7,000 words readable prose) in my User space. I asked a friend for comments and was told there is no Table of Contents (TOC). This seems to be the case: unless you are logged in (which my friend wasn't), an article displays with no TOC. This seems to hold for any article, in mainspace or otherwise.
Can this really be true? It makes long articles very difficult to read for readers who are not logged in (i.e. most of them). I have tried forcing a Table of Contents with but it makes no difference.
It seems kind of difficult to believe that the average, casual reader of Wikipedia articles doesn't see a Table of Contents (unless he/she knows to force the display).
Thank you, I believe you are right that it has to do with the default vector-2022 skiin. That said, it doesn't fix the basic problem i.e. the Average Joe doesn't get to see a TOC. My friend has a big, wide laptop. Ttocserp23:37, 13 August 2024 (UTC)[reply]
Ok, I now see that the problem is not what I thought it was. A TOC does display down the left-hand side, but only a rudimentary one (only level 2 headings). So I guess to fix that I have some learning to do.Ttocserp00:36, 14 August 2024 (UTC)[reply]
Some of the headings, for example the one for Add A Fact experimental tool from Future Audiences on this page, should have > symbols beside them. Clicking the symbol opens the further levels. NebY (talk) 00:47, 14 August 2024 (UTC)[reply]
About 24 hours ago, I accessed Wikipedia on my cell phone from a car for hire, but was logged out. I went through the process of entering my password for my mobile account, and was logged back on. I then received an email saying that I had accessed Wikipedia from a device that I had not used recently. That wasn't accurate; it was the same cell phone as I have been using for about six months. My question is whether that message really means that I logged on to Wikipedia from an IP address in an unfamiliar IP address range, because I was using a satellite connection. Or was my device unfamiliar because I hadn't logged on in a few months because I had stayed logged on?
I do not have a security issue. I am just wondering whether it really means that I accessed Wikipedia from an unfamiliar IP address range, or whether it means that my device is unfamiliar because I haven't logged on from it for months because I have been continuously logged on. Robert McClenon (talk) 17:29, 14 August 2024 (UTC)[reply]
Hi, I have noticed that my contributions stats on English Wikipedia haven't updated on Wikiscan since November 2023. [1] However, they still update for my contributions on other projects, like French Wikipedia. [2] Is there anything I can do to fix this? Thanks! – Odjob16Talk17:40, 14 August 2024 (UTC)[reply]
Is this possible to hide "From Wikipedia, the free encyclopedia" description at the very top of each article? Also is this possible to hide description "This page was last edited on 10 August 2024, at 23:16." at the very bottom of the each page? #f-list #lastmod {display: none;} doesn't works. Eurohunter (talk) 18:25, 14 August 2024 (UTC)[reply]
Clicking the cross would remove the template and clicking the checkmark would implement the change and remove the template and then reload the page.
But the downside of a javascript is having to convince everyone to put it in their common.js. If I write the javascript, do you think it could be turned into a gadget? How does that procedure (if any) work? Polygnotus (talk) 01:47, 15 August 2024 (UTC)[reply]
@Pppery: Script is here: User:Polygnotus/verify.js (I am abusing the |reason= because there is no suggestion parameter yet). I've tested it on my userpage with
This seems silly - when would one ever use that template if one knew the typo fix, rather than fixing the typo themselves. If the template adder wasn't sure enough to fix the typo then driveby JavaScript users won't be either. Yes, this is close to an argument to delete {{verify spelling}}. * Pppery *it has begun...04:37, 15 August 2024 (UTC)[reply]
generate possible misspellings. The result looks like this:
description,deescription
description,desscription
description,desccription
check if those misspellings occur in the latest dump and delete all lines that occur 0 or more than 50 times.
check them against the Action API to see if they still exist and which articles they are on.
category|catgeory|David F. Walker
category|cateogry|Natasha Bedingfield
category|cateogry|Giovanni Falcone
I then use a seriously unhealthy amount of regex to see if they should be fixed or not (e.g. they are not in a comment, certain templates, certain parameters and the article does not use stuff like {{nobots}} or [sic] et cetera.
I end up with an insane amount of possible typos.
I can fix em myself with my AWB module or turn them into wikilinks and solve em with my javascript (see User:Polygnotus/typos) or I can use my homebrew AWB-like thing based on Selenium and ducttape. But there are simply too many for me myself and I to fix.
In some cases I have no clue if something is a typo and if so, how to fix it. Figuring that out can take a decent amount of time. No problem for one or two, but if you have tens of thousands it becomes a bit much, you know? Polygnotus (talk) 04:55, 15 August 2024 (UTC)[reply]
@Pppery: Aaah you fixed it. Anyway, while Correct typos in one click is super cool, I can still find tens of thousands of typos. So the problem hasn't been solved yet by its existence.
This is a different approach; Correct typos in one click hinges on luring people to an external website to do a pretty boring task. You could improve that model by offering them barnstars at certain levels of achievement and gamifying it and the like. But attracting people to an external website without an advertising budget is always gonna be hard. And typofixing is not sexy. There will be some hardcore users who return, but who is gonna make a calender event to return monthly when the new dump has been parsed?
External tools will always have a huge discoverability and user retention problem. People adopt bots when their owners disappear so that would also increase the bus factor. Polygnotus (talk) 05:01, 15 August 2024 (UTC)[reply]
Smileys
These smileys look fine in light mode, but they look weird and vaguely racist in dark mode. Does someone know how to fix that?
I'm pretty sure that the appearance (including the colouring) is browser-specific. What I mean is, if I view this page in Firefox and also in Edge, those emojis look different in colour and also in other ways, such as the shape of the teeth. --Redrose64 🌹 (talk) 18:55, 15 August 2024 (UTC)[reply]
Official dark mode is supported on Vector 2022 and on Minerva. It is not supported/provided elsewhere today, but like all the software deployed, the skins are open source. Izno (talk) 20:44, 15 August 2024 (UTC)[reply]
Thank you. I hope official dark mode support comes to Vector2010 soon but that appears to be unlikely (if I understand Phabricator correctly, haven't done much digging). Polygnotus (talk) 21:12, 15 August 2024 (UTC)[reply]
Can't save edit due to blacklisted link, but edit doesn't contain blacklisted link
I'm unable to save an edit due to the error "Your edit was not saved because it contains a new external link to a site registered on Wikipedia's blacklist or Wikimedia's global blacklist."
"The following link has triggered a protection filter: about.com"
I haven't added any external links. I can't share the text that's triggering the apparently erroneous alert, since that text is triggering the blacklist filter. If there is in fact a link to about.com, I can only think it would be due to a typo or some kind of technical issue with a template transclusion, but I have exhausted my own ability to troubleshoot the issue.
@PrimeHunter: I have been working with the {{get short description}} template to pull Short Descriptions of pages in my project into a table for easy reference. I removed the transclusion of the Short Descriptions of those two articles, and the page saved. I don't know why either of those Short Descriptions would trigger the blacklist for "about.com" though, as the transcluded text is "Film that gives an illusion of three-dimensional depth" and "Partial or total inability to hear" respectively. Is there a technical issue with those descriptions or with the template itself?
Also, when in Edit Source mode, I'm getting the message "Warning: Post-expand include size is too large. Some templates will not be included." How do I resolve this?
The cs1|2 messaging is likely because of this. The code fetches the article wikitext and then calls frame:preprocess() on it which renders the wikitext into html (same as happens when you click the publish button). Converting to html causes all cs1|2 templates in whatever article is being preprocessed to be rendered. If there is anything in the cs1|2 templates that creates an error or maintenance message, those messages will show up in the preview message box.
Once converted to html, Module:get short description looks for the <div>...</div> tags that wrap the short description. Not at all obvious that such a complicated mechanism is required. Pinging the author who can perhaps explain.
@Trappist the monk: That seems awfully complex as well as resource-intensive for what seems like could be a simple database call. Is there an easier way to query for Short Descriptions (such as querying Wikidata)? —danhash (talk) 18:50, 15 August 2024 (UTC)[reply]
I expect that there is. Wikidata is possible, but I think that I've seen editors overriding the wikidata short description so, if they are doing that, wikidata won't be very reliable (if it ever was). Let us see what the module author has to say.
To test it, copy the ~/sandbox to your clipboard, and then edit Module:Get short description. Replace its contents with the contents of your clipboard. Put User:Danhash/Film project in the Preview page with this template textbox and then click the attached Show preview button. And yeah, do not click Publish changes.
I want to see if we can implement category editnotices here. Other improvements I have made to this module include page ID-specific editnotices, useful because it allows the page to move around without having to move the editnotice around to match the title. There is probably some cleanup that can be done with this module, for example using Lua functions instead of preprocessing {{replace}}, but I think it is a good start. AwesomeAasim20:19, 15 August 2024 (UTC)[reply]
Because it doesn't require much compute, and because it stays with tables of the database, that we are already accessing while parsing anyways. Things are only marked as expensive if they cause potential exponential increases of load. Crossing from parsing one article to parsing many articles or dependencies of the article is such a case, as this creates a spiderweb of parsing dependencies that have to be accessed. Accessing a blob of text we already have in memory is much less expensive. —TheDJ (talk • contribs) 18:29, 16 August 2024 (UTC)[reply]
More specifically, my thinking back when I was working on Scribunto was that getContent() is the same thing from a data-loading perspective as transcluding a page (and, IIRC, it uses the same underlying data-fetching functions), and since transcluding a page isn't considered an expensive operation so getContent() shouldn't be either. On the other hand, most other parser functions that have to make a separate database query to load some data are considered expensive, and so Scribunto functions that make database queries are marked as expensive for that reason. Whoever implemented the new feature likely followed the same reasoning. Anomie⚔19:05, 16 August 2024 (UTC)[reply]
editing in the dark
The site recently began darkening its countenance at night. I don't have a personal preference one way or another, but it benefits those around me, so I don't want to use hacky methods to undo it. The editing window's colouration has fluctuated several times (see Wikipedia:Village pump (technical)/Archive 214#Dark mode issues), but has settled recently. Unfortunately, mine is still showing dark-grey text against a black editing-window-background; I'm typing this in a separate program and will copy/paste it when done, hoping it'll save properly. I assume this isn't widespread, else there'd be a rapid fix, but I'd really like to find a solution soon. Anybody know what and why I'm experiencing? Much obliged, — Fourthords | =Λ= |01:47, 16 August 2024 (UTC)[reply]
@Fourthords If you are seeing normal text in dark-grey but wiki-syntax like double-square-brackets in colors (e.g. like this screenshot), then this is a bug related to the extension which powers that syntax-highlight feature, phab:T365311. That bug is being worked on and should be fixed soon (next week or two I'd guess, from the latest comments there), but for now you can toggle off the syntaxhighlight with the 7th button in the toolbar (a marker-pen shape). I hope that helps. Quiddity (WMF) (talk) 18:48, 16 August 2024 (UTC)[reply]
Yeah, that's exactly what I'm seeing! I thought the colour-coding behaviour had been the default for... I don't know, a decade or more? Is this not affecting an outsized amount of the editing community? Regardless, at least that'll let me edit within the browser again (and it's not like I have those color-indicating features in the word processor I've been using during the nighttime hours, anyway!). I'll test it in the next couple of days. Thanks for the heads-up! — Fourthords | =Λ= |19:08, 16 August 2024 (UTC)[reply]
I'm having a weird admin problem and that is that Deleted Contributions don't show up when I know that an editor has them. For example, I deleted Draft:Peter Bianca as a hoax article by User:Borris Lana but nothing shows up on Special:DeletedContributions/Borris Lana (sorry only visible to admins). I thought it was just a weird glitch, I just moved on. But I was investigating an edit by User:Abdullah Hill Mahin and in the blocking rationale on Special:Contributions/Abdullah_Hill_Mahin it states Spam / advertising-only account; see also deleted contribs. But when I look at Special:DeletedContributions/Abdullah Hill Mahin, the page is blank, no deleted contributions appear. Luckily, looking at these pages is a small part of what I do as an admin but I do check Deleted Contributions while I'm editing and if there is a problem, I'd like it to get fixed.
Thank you for the advice, folks. I didn't return to this noticeboard until now to see it because the problem looked like it was fixed but it returned today. A sockpuppet account that had reportedly made 100 edits has 0 contributions and 0 deleted contributions (it's User:Santana Montana (Muse)), so I'll try some of your work-arounds. I just want to see if this sock farms keep recreating the same draft or main space article over and over again. Thanks again. LizRead!Talk!20:27, 18 August 2024 (UTC)[reply]
"Prompt me when entering a blank edit summary (or the default undo summary)" preference did not work for me just now
I have had the "Prompt me when entering a blank edit summary (or the default undo summary)" option selected in my Preferences for years. Until just now, it has always prompted me when the edit summary (a) was blank, (b) consisted of only a section header because I was editing a section, or (c) consisted of the default undo summary. Just now, I responded to a talk page section and clicked Publish, forgetting to add custom text to the summary. I was not prompted to add an edit summary. Can anyone reproduce this problem?
I am using Vector 2022 and the old wikitext editor (I don't know what it's called anymore, but in my Editing Preferences, the "editing toolbar", "Visual Editor, and "wikitext mode" checkboxes are empty). – Jonesey95 (talk) 13:29, 16 August 2024 (UTC)[reply]
No, I don't remember, as the tool has conditioned me to put in a comment nearly every time (18 misses in 30,000 edits in 2024; thanks, clever tool!). I probably get prompted by the tool once every few weeks when I click Publish accidentally, so I wouldn't remember what namespace I was in. – Jonesey95 (talk) 17:20, 16 August 2024 (UTC)[reply]
Fascinating; the description of the Preferences option does not indicate this strange exception. I was surprised to encounter it after 300,000+ edits, including many to my own User Talk page. Thanks for the info. – Jonesey95 (talk) 22:28, 16 August 2024 (UTC)[reply]
How odd. I tested just now and did get prompted Reminder: You have not provided an edit summary.... on my user page and my talk page - which is fine. NebY (talk) 03:22, 17 August 2024 (UTC)[reply]
If I write the same thing at fr.wiki, it does not work. The page appears to be there: fr:MediaWiki:Vector-toc-beginning. My code should set content to 'Début'. I'm guessing that the content of the fr.wiki page comes from translatewiki. I can also write:
That, at least, returns a value: 'Beginning'. Yay, but not what I want. Changing my interface language at fr.wiki from English to French gets me the result that I want: 'Début'.
Is there any way to get the French interface message without it gets translated to the reader's interface language? There is a move afoot to internationalize Module:Section sizes. The content of MediaWiki:Vector-toc-beginning (at en.wiki) is used to name the unnamed lede section in the module's output table. That lede section name should always render in the same language as the local wiki regardless of the user's interface language setting.
Try mw.message.new('vector-toc-beginning'):inLanguage(mw.language.getContentLanguage()):plain(). The title_obj:getContent() method only works when the message has been locally customized; if it's using the MediaWiki default, it doesn't work because the page doesn't exist. P.S. Doing just mw.message.new('vector-toc-beginning'):plain() is much like the int method, using the user's interface language. Anomie⚔17:08, 16 August 2024 (UTC)[reply]
It is possible to preload a template, but how can I preload specific text? Preloading a template is useful, but sometimes you don't know the text you want to preload in advance.
I know this is probably out of our remit, but does anyone have any idea why Google currently shows a placeholder instead of the "W" as the favicon for en.wikpiedia.org (example)? It seems to be occurring only for some subdomains (en, fr, la, nn, no). Is there anything WMF can do about it? Nardog (talk) 05:27, 17 August 2024 (UTC)[reply]
Hi! I'm wondering if it is possible to create a clean-up list of articles by Wikiprojects that are assessed as a stub, but don't have a stub template in the bottom of the article? In such cases either wikiproject assessment is outdated, or a proper stub template is missing. My main interest in this matter is WP:Estonia. (And are there any other tools that can help to find higher than stub quality articles that are still assessed as a stub? My guess is Wikipedia has 5-10% more quality than the statistics show) Pelmeen10 (talk) 13:01, 18 August 2024 (UTC)[reply]
Can you please make a screenshot? Which error messages? Cite error: A list-defined reference with the name "ep11t" has been invoked, but is not defined in the <references> tag (see the help page). <= that one? Polygnotus (talk) 03:14, 19 August 2024 (UTC)[reply]
Another thing is when using the new "Parsoid"; the error message doesn't appear but instead a couple of more letters are displayed. Error message appears afeter a dummy edit. Screenshot: [4]Vestrian24Bio (TALK) 07:04, 19 August 2024 (UTC)[reply]
When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.
Back in 2017, the community decided in this RfC that moved pages should be unpatrolled. The feature was stuck in Phabricator purgatory and was never actually implemented.
I'm really surprised so many people supported that: it would create a substantial added burden for patrollers in exchange for maybe making a very rare problem slightly easier to detect. (Redirects from page moves already go into the queue, and even if they're retargeted elsewhere, a good reviewer should notice the suspicious history.) Unless this is a much larger-scale issue than I'm aware of, I don't think that proposal should be implemented. Extraordinary Writ (talk) 08:00, 21 July 2024 (UTC)[reply]
I have seen cases (e.g. recently at AT CBS This Morning) where a long-standing patrolled page becomes unpatrolled because a non-autopatrolled user moved the page - like from vandalism being reverted like CBS This Morning, or from requested moves like (709487) 2013 BL76. There can be quite a lot of these cases. Is this scenario also part of this discussion? thanks. Aszx5000 (talk) 09:36, 21 July 2024 (UTC)[reply]
@Aszx5000 That specific behavior is part of a bug that started happening recently and will be probably reverted. It's being tracked in T370593. The default behaviour is to not unpatrol page that are moved. Sohom (talk) 10:00, 21 July 2024 (UTC)[reply]
I think the RfC should be respected. Yes, WP:CCC but we really shouldn't overturn an RfC without an new RfC. Besides, this will help with detecting move vandalism in some cases so it is a useful change. Nickps (talk) 12:32, 21 July 2024 (UTC)[reply]
Oppose: If the RfC hasn't been implemented in 7 years, and it was only recently implemented by accident, it makes sense to revisit the discussion instead of implementing it by surprise so much later on in time. As one of the more active patrollers, I absolutely hate the idea of adding to the workload / massive backlog by adding pages to the queue just for being renamed. Really we'd want to just mark it as patrolled 99% of the time anyways. Hey man im josh (talk) 14:49, 21 July 2024 (UTC)[reply]
FWIW, I attempted to figure out how much moving and patrolling actually goes on so I could see if making it necessary to re-patrol moves would indeed add a significant workload. I came up with 916 moves and 1225 patrols yesterday. My SQL is weak (and my understanding of the MediaWiki schema even weaker) so I don't know if these numbers are accurate or not. If they are, then it looks like this would almost double the patrolling workload. RoySmith(talk)15:33, 21 July 2024 (UTC)[reply]
Though, as usual, raw statistics are misleading. Neither of our queries, for instance, try not to count page moves by autopatrolled users, or pages moved out of the main namespace without leaving a redirect or where the redirect was later deleted. I can at least compensate for the small sample size by showing stats for all of July up to now, which are better: 7068 page moves starting in mainspace, 13519 mainspace page curations. —Cryptic16:55, 21 July 2024 (UTC)[reply]
Oppose. I don't see much of a point in implementing this as it would unnecessarily double the workload of the NPP team. Redirects left behind from moves are already placed in the redirect queue (except for users in the page mover, autopatrolled, and redirect autopatrolled groups, including administrators). DannyS712 bot then automatically reviews a portion of them if the changes fit certain criteria, and the rest are reviewed manually. I feel like this system works just fine; it's not like we have a runaway page-move vandalism issue on our hands. —TechnoSquirrel69 (sigh) 17:50, 21 July 2024 (UTC)[reply]
Oppose. To quote myself from 2017: Oppose pending more information. I'm concerned about rushing into something that will potentially hugely increase the load at the already hugely-backlogged WP:NPP. How many pages are moved per day? How many more reviewers would we need to handle the extra load? What's the scale of this problem? Are there other solutions we could explore (e.g. marking pages that have {{disambig}} removed as unpatrolled)? We have the answers to some of those questions above, and it's not looking good. Doing this would double the NPP workload in order to close a loophole that is apparently so small that nobody noticed it had been accidentally left open for the last seven years. Really bad idea. – Joe (talk) 21:35, 21 July 2024 (UTC)[reply]
Comment: the proposal as it developed in the 2017 RfC was not for all article moves but for those by non-EC users which I think was 40 a day at the time. Cenarium's comment is not clear to me but search for "40" (not pinging them because they have not edited since April). Pinging @Ivanvector: who initiated the proposal for their comments. We don't know if this is still a concern or if other mechanisms were put in place. S0091 (talk) 19:39, 22 July 2024 (UTC)[reply]
not for all article moves but for those by non-EC users which I think was 40 a day at the time. This somehow ended up not reflected in the 2017 RFC close and not reflected in the 2017 Phabricator ticket. We could go off on a tangent about whether that RFC was closed correctly or not, but I think it's a non-issue because we'll get a fresh consensus in this RFC that will override any lack of clarity about the previous close. –Novem Linguae (talk) 23:58, 28 July 2024 (UTC)[reply]
??? I don't know that area that well because that not normally where I do my NPP work but I thought this was already happening. For example Extracorporeal procedure was in the cue. The community really needs for fix some things to help with the disaster at NPP but worrying about easy stuff like this really isn't it. North8000 (talk) 20:28, 22 July 2024 (UTC)[reply]
Oppose: Unnecessary. They will almost always be marked as reviewed immediately, so this just adds a pointless burden to the NPP queue. CFA💬22:15, 28 July 2024 (UTC)[reply]
Currently if a user clicks "Add a topic" on an article talk page, a box appears which prompts them for a "Subject" and a "Description".
"Description" is somewhat cryptic in that context, and seems like a placeholder string that was never reassessed. A talk page message or question isn't really a description of anything. In some contexts (like Talk:ChatGPT and Talk:Google, talk pages which ended up locked in response to so many people mistaking "Add a topic" for a direct query to those services) asking for a "Description" may, to some users, look more like a prompt to communicate privately with a generative AI or web service, rather than the start of a human conversation with Wikipedia editors.
I raised the suggestion more broadly at the idea lab earlier in the year and was told that, regarding a change to this specific interface message, altering these strings will affect all pages. This change has to be very carefully considered. So here's a concrete proposal to change it. Will "Your talk page comment" make sense in all contexts where this string is displayed, and would we agree that it was an improvement on "Description"? Belbury (talk) 14:06, 8 August 2024 (UTC)[reply]
We can certainly improve on "description", and "Your talk page comment" would be such an improvement although I am not immediately certain it is the best we can do - especially if this appears anywhere other than talk pages? Perhaps something as simple as "Your message" would work? Thryduulf (talk) 14:13, 8 August 2024 (UTC)[reply]
I think our motivation behind keeping it so aggressively-generic was that we weren't sure what places were using the "new section" form that this takes over, and we wanted to avoid something like "start a new discussion thread" as being too specific to only talk-page workflows. (The thing to watch out for is places outside the talk namespaces, that use __NEWSECTIONLINK__ to get that behavior...) DLynch (WMF) (talk) 17:12, 12 August 2024 (UTC)[reply]
Thryduulf, oops, looks like the URL contained NEWSECTIONLINK, which caused it to be parsed as the prop and not as a URL. I've edited it to add "deletethis" — follow the link and delete those words and then it'll work, or just use Anomie's better method below. Sdkbtalk02:20, 13 August 2024 (UTC)[reply]
I don't know how to use the API or run db queries, but the special page worked. I've not got time right now to look in detail, but that reports there are a lot more uses in non-talk namespaces than I expected:
Many of these are going to be appropriate (e.g. on this page, the portal page titles suggest they are nomination spaces) but I wonder especially about the articles. Thryduulf (talk) 02:17, 13 August 2024 (UTC)[reply]
I suspect the articles will turn out to be either vandals being weird or people not knowing what stuff does and throwing a bunch of magic words on the page trying to get Google to index a new article. Of the handful I spot-checked, I saw one that seems like the former and a bunch that seem like the latter. Anomie⚔02:36, 13 August 2024 (UTC)[reply]
There were 9 remaining in article space, all redirects. I have removed them, along with other code. It seems it was often added with other magic words in a group (eg.), so perhaps your second theory, although I wonder where the collection of magic words is found. CMD (talk) 20:49, 15 August 2024 (UTC)[reply]
This is a smart suggestion; thanks for raising, Belbury! I'm inclined to support "Your message" for conciseness and to be on the safe side given Thryduulf's concern that it might be used outside of talk pages. Sdkbtalk15:15, 8 August 2024 (UTC)[reply]
I agree with the idea, but would be inclined to suggest "Your comment", given that "Your message" might still be mistaken for a ChatGPT/Google/etc. prompt query. Chaotic Enby (talk · contribs) 18:06, 9 August 2024 (UTC)[reply]
"Your comment". Just based on widespread, almost universal Wikipedia terminology. Messages are for emails and texts—things that are sent, not posted. ―Mandruss☎18:22, 9 August 2024 (UTC)[reply]
Thank you for the ping, @Sdkb. And thank you, @Belbury for prompting us to reconsider this message.
Generic enough to be helpful in the range of contexts it will ultimately appear
With the above in mind, what do you all think about starting with something a bit more specific like, Topic description and seeing if/how that proves effective? From there, we can consider whether further iteration is needed.
Meta: I feel moved to say: it's a delight to work on a project with folks like you all who consistently pay close attention to details of this sort in service of improving peoples' experiences contributing to our mission. Thank you to @NAyoub (WMF) for reminding the Editing Team of this point when discussing this offline earlier today ^ _ ^ PPelberg (WMF) (talk) 17:56, 15 August 2024 (UTC)[reply]
I like the idea, we can start with this! I still fear Topic description might still be a bit too abstract in a way, as it doesn't really indicate that the "description" corresponds to the message that will be posted on the page. Nonetheless, definitely an improvement over what we currently have. And yes, fully agree that details like this are much more important than people realize, happy to see the WMF team on board with this too! Chaotic Enby (talk · contribs) 18:03, 15 August 2024 (UTC)[reply]
I agree with ChaoticEnby about being too abstract. To me, "description" is meta; it's about something but isn't the thing itself. Your message or Your comment or even Your post are less confusing. Schazjmd(talk)18:17, 15 August 2024 (UTC)[reply]
I agree with Schazjmd that "description" is meta; it's about something but isn't the thing itself. - it's a better fit for the edit summary than the main substance. An exception might be if it was paired with "Title" but then I'd be expecting a third box in which to post the details. Thryduulf (talk) 18:34, 15 August 2024 (UTC)[reply]
Thanks for the response! The range of contexts where the message appears is definitely key to any decision here, so it would be good to establish for sure what that range is. The Special:Pageswithprop search above shows that the __NEWSECTIONLINK__ magic word (which causes the "Add topic" tab to appear, creating a Subject/Description box when clicked) is being used across various different types of non-talk page, which seem to break down into:
Pages of sequential, titled conversations which are effectively functioning as talk pages (like Wikipedia:SVG help, Help:Books/Feedback), where a string of "your comment/message" would still work.
There's also some unusual niche usage of the magic word to, I assume, create a handy shortcut for starting a new section on a log-type user page (User:Fabrickator/questionable edits).
Should the second and third cases be something to bear in mind when crafting a message, or can they be regarded as misuse of the __NEWSECTIONLINK__ magic word, and not something to worry about?
And are there any other places in Wikipedia where the discussiontools-replywidget-placeholder-newtopic "Description" string would appear, unrelated to __NEWSECTIONLINK__ magic word? Belbury (talk) 18:53, 15 August 2024 (UTC)[reply]
Those second/third cases are definitely the sort that we were concerned about when introducing the tool -- we thought that if we came in and took over the existing section=new behavior, we'd wind up stepping on the toes of people who had built up workflows around it (or at least, would be surprised by us auto-signing things). To that end we have a bunch of checks that determine when we actually take over from the old tool...
Summarizing here from the code that spells out whether following the ?section=new link on a page should open the new topic tool:
It must be an edit page (action=edit or veaction=edit) with section=new
It must either not be using any preloads (editintro, preload, etc) or have opted in via adding the `dtpreload` parameter to the URL
It mustn't be trying to preview / switch from some external tool via having posted a field named `wpTextbox1`
Then the new topic tool must be enabled for that page in general, meaning the URL has `dtenable=1` as a parameter OR
It's a wikitext content-model page (but not liquid threads)
It doesn't have the NOTALK or ARCHIVEDTALK magic words
It's in a namespage that wants signatures (any talk namespace, or $wgExtraSignatureNamespaces), or it has the NEWSECTIONLINK magic word
Finally, it must be available to the user, which is a combination of "turned on for that wiki" and the user actually having it turned on in preferences (Editing > Enable quick topic adding).
So! All that adds up to the challenging-to-search for part: pages in wants-signature namespaces that don't have NEWSECTIONLINK (we can probably assume that anything in an actual talk namespace is either really talk or won't be too offended if someone assumed it was), but which are somehow linking to the section=new tool as part of some on-page flow, perhaps even using the preload parameters so the user can fill out a form-template. Here on enwiki the extra signature namespaces are just Wikipedia (NS_PROJECT) and Help (NS_HELP) -- the question's much trickier if we were talking about some discussion/coordination focused wikis (mediawiki.org, metawiki, etc) which have their main namespace as an extra signature namespace.
For instance, if you follow this link to AfD with the right url parameters you'll get the new topic form, even though it doesn't have NEWSECTIONLINK. This is obviously not the way to interact with AfD specifically, but you can imagine some other process-page that does work this way...
That said, I think there's a fair extent to which "how should these process pages and magic words work?" is a community question. Our default message choices were kinda based around not wanting to cut off options / break existing processes, particularly since they had to fit more than just a single wiki, and I think (not having talked to Product about it) that we wouldn't want to drift too far away from that for the default... but a particular wiki wanting to tighten it up seems fine, so long as you're aware of the trade-offs. DLynch (WMF) (talk) 20:13, 15 August 2024 (UTC)[reply]
Yeah, separately from the question of exactly how talk-specific it should be, I agree that we might want to tweak the generic-default over to something a little more indicative of "this is the body-text of a message"... DLynch (WMF) (talk) 20:30, 15 August 2024 (UTC)[reply]
Deploying Edit Check on this wiki
While attending Wikimania this year, Selena Deckelmann (User:SDeckelmann-WMF) demonstrated a new feature for Visual Editor, Edit Check in a session. Edit check introduces additional prompts in Visual Editor when an editor tries to insert a blacklisted URL as reference and also when they try to publish a revision without inserting a reference. This greatly helps with encouraging editors inserting references in their edits. If I recall correctly, the percentage of editors inserting references increased from 11% to 40% in their tests (do correct me if I am wrong as I am going off on my recollection).see #What's next? for corrected stats
There is certainly some benefits in enabling this, primarily on improving the verifiability and reliability of content that's on English Wikipedia. Most of the sister projects have already been deployed with this feature. English Wikipedia does not have this feature enabled yet. The only thing that is holding back this feature is that Visual Editor is not set as the default editor for anonymous and new editors.
Therefore, I would like to propose that:
Visual Editor be the default editor for anonymous and new editors.
The last time I checked, new editors are presented with a pop-up box that asks them to choose which editor they'd like to use, with the solid blue button pushing them a bit toward the VisualEditor.
This thread is rather underdeveloped. For a proposal of this magnitude, I think we should figure out relevant factual questions (like what the current default is) and then draw up a more formal survey that could be CENT-listed, etc. Sdkbtalk19:05, 9 August 2024 (UTC)[reply]
Another question is how does it work with edits that don't need references adding (e.g. creating redirects, adding links on disambiguation pages, fixing spellings, etc)? Thryduulf (talk) 19:08, 9 August 2024 (UTC)[reply]
In theory, this sounds like a great idea. I'm eager to try it out, but I think a first step would be to make it available as an opt-in on enwiki. Then after people have got some experience with it, let's come back and talk about making it the default. RoySmith(talk)20:09, 9 August 2024 (UTC)[reply]
There's a simpler option for userscripts that should work: window.MWVE_FORCE_EDIT_CHECK_ENABLED=true;
So long as that's there before VE loads, it should force you to have edit check. Either method also bypasses the account restrictions on edit check, so you're not quite getting the pure experience that people would if we just turned it on for enwiki. By default it only shows up for new users (defined as under 100 edits), and someone might want to edit the configuration on-wiki for that. DLynch (WMF) (talk) 21:26, 9 August 2024 (UTC)[reply]
The add-reference check is very conservative currently. You need to be a user with less than 100 edits who has added a whole new paragraph of at least 50 characters (configurable per-wiki) that contains no references before it'll pop up. This can all be loosened up in the future, whether by default or through community configuration, but we figured that those criteria had pretty low odds of being a false positive to start with.
It's quite interesting that this boosts the percentages so much, because I honestly thought that complete new-editors would be doing far more minor edits. But no, major new blocks of text are pretty popular.
It's actually turned on with the reference check everywhere but 8 of the wikipedias (bn, de, en, hi, id, nl, pl, ru), so it's pretty easy to try it out on another wiki if you don't want to jump through userscript hoops here. DLynch (WMF) (talk) 21:34, 9 August 2024 (UTC)[reply]
Not sure where ReplyTool will put this, but nothing I'm seeing in the documentation requires VE to be the default editing interface in order to deploy the new tool. So deployment doesn't seem contingent upon answering the larger question of whether VE should be default. Folly Mox (talk) 22:17, 9 August 2024 (UTC)[reply]
Unless things have changed in the last year, it doesn't need it to be the default, but editor does need to be in the visual editor, and that's somewhat more likely to happen (especially for the editor's first edit) when the visual editor is the default. WhatamIdoing (talk) 01:29, 10 August 2024 (UTC)[reply]
The functionality is targeted towards new editors and anonymous editors, therefore the need for Visual Editor to be the default before the deployment of the functionality is considered complete. Also there are on wiki configuration options that we may want to adjust. As stated by Dlynch (WMF) above, the tool is configured by default for an user with less than 100 edits and making revisions of more than 50 characters. – robertsky (talk) 04:15, 10 August 2024 (UTC)[reply]
Minor quibble: enwiki has already got the prompts about blacklisted URLs for references/links. We rolled those out everywhere on the logic that any edits involving them were going to get blocked-on-save anyway so it wasn't going to disrupt any workflows. :D
It's a bit fuzzy because we called the project "Edit check", and we're developing a specific system called edit check (of which the "add reference" check is the first example), but we're also doing smaller edit-enhancement features along the way that colloquially get called checks just because of the project.
Conduct a thorough analysis of the potential consequences of setting Visual Editor as the default for anonymous and new users. Consider factors such as user experience, editor retention, and overall editing patterns. If making Visual Editor the default is not feasible, investigate other strategies to increase Edit Check adoption. This could include targeted outreach to experienced editors, promoting the feature through in-editor messages, or developing incentives for reference usage. Regardless of the chosen approach, it's essential to closely monitor the impact of Edit Check on reference usage and article quality. This data will be crucial for refining the feature and measuring its overall effectiveness.
I'd support making Visual Editor the default, as long as they also leave wikitext editing as an option (which I'm sure they will). VE is much better nowadays than when it was first released. As a WYSIWYG editor, I suspect it is much more new editor friendly. It is unarguably better at things such as automatic citation generation and table editing (adding and removing columns and rows, moving columns and rows around). And for the few things it is bad at (such as complicated template syntax), power users can just switch to wikitext editing. Any logged in user can select their default at Special:Preferences (under "Editing mode"). –Novem Linguae (talk) 10:47, 10 August 2024 (UTC)[reply]
I totally agree that VE should be the default for new users. I use VE every day, and it's just fine for most stuff, and getting better incrementally. Folks who think VE should not be the default should go to edit-a-thons and try teaching new users. 20 years ago, wiki-markup was the new hotness and was miles ahead of editing raw HTML. Today it's just a barrier to entry for potential new editors. RoySmith(talk)12:24, 10 August 2024 (UTC)[reply]
When I first edited English Wikipedia as an IP editor, I found WikiText editing very difficult to understand. I’m sure that most new IP editors face this issue. I strongly support making the Visual Editor the default. New IP editors are often unfamiliar with Wikipedia and may not know how to cite a reference using the WikiText editor. They may also not know how to switch to Visual Editing. Frankly, I still have to check the preview before publishing edits using the WikiText editor because I sometimes make mistakes. GrabUp - Talk11:08, 10 August 2024 (UTC)[reply]
Potentially minor bugbear alert: The visual editor reference creator still hasn't figured out the basic functionality of allowing for an easily accessed and obvious use of an |author= field, instead forcing all authors into |last and |first. It's not a groundbreaking issue, but it's really disappointing that it's still around after so long, especially given the many words given over the years about attracting more diverse perspectives etc. The default reference tool that we are going to create a pop up asking all new editors to use should allow for sources from authors whose names don't fit into the common European name format. It may be hidden behind an additional field button, but at least the wikitext reference creator has the option. CMD (talk) 12:10, 10 August 2024 (UTC)[reply]
My biggest bugbear is the lack of ability to set a reference name. For example in this edit I switched from visual to source editing so I could reuse citations between prose and infobox. Although admittedly this is not something a brand new editor wants to do, being able to set a name other than ":0", ":1", etc would be rather handy. Thryduulf (talk) 12:28, 10 August 2024 (UTC)[reply]
Is naming references a policy? Or is it something you consider useful? I don't edit the code. I just reuse citations when I need them, directly from the citation insertion menu. Very convinient. 37.169.50.102 (talk) 12:52, 11 August 2024 (UTC)[reply]
I mostly work in VE; I'm not personally bothered by the opaque names (i.e. ":0") that VE invents because I never see them. But many people work in wikitext, where having human-friendly names is important. So, I agree that improving support for reference naming should be a high priority. RoySmith(talk)12:57, 11 August 2024 (UTC)[reply]
I just went looking, and I don't see a Phab ticket for this. I was a bit surprised there was no ticket, but then I thought about it a bit more. It's probably hard to come up with a wiki-agnostic way to generate good citation names. You'd have to program it with something very enwiki specific to get it to read our unique citation templates then extract the author last name and year from them. User:Nardog/RefRenamer is a good workaround though. –Novem Linguae (talk) 13:14, 11 August 2024 (UTC)[reply]
I thought we were talking about auto-generating good names. Those tickets are for something else. Maybe I am misreading this subsection though. Apologies if we are not actually talking about auto-generating good reference names. –Novem Linguae (talk) 13:20, 11 August 2024 (UTC)[reply]
When copy pasting named references to another page, you get false matches that are not obvious. If automatic named references were more unique (slugified title) this false collision would happen less often. I am all for hiding/abstract workflows where needed. ~ 🦝 Shushugah (he/him • talk) 13:03, 11 August 2024 (UTC)[reply]
All programmers should read Falsehoods Programmers Believe About Names, and then re-read it every few years to refresh their memory. People who design database schemas should re-read it every time they start a new project. I agree that it's not a showstopper for our purposes, but it is a surprising lack of cultural sensitivity from an organization which is so into i18n.
For me, the biggest bugbear is that there's no good way to convert a {{cite web}} into another template without basically starting from scratch. It really should be smart enough to figure out that if {{cite web}} has a "first=" field, it can safely map that into {{cite news}}'s "first=" and so on. It won't be perfect, but it'll get you most of the way there. RoySmith(talk)12:57, 10 August 2024 (UTC)[reply]
@Chipmunkdavis @RoySmith Visual editor follows the definition of the template parameters at Template:Cite web#TemplateData (and so on for other cite templates). I think the developers would also wish that you didn't require the name to be split into two fields; it's a chore to fill it out this way. If you think this can be changed, please edit it there. Matma Rextalk13:58, 10 August 2024 (UTC)[reply]
@Matma Rex you are entirely correct that VE gets its field definitions from the templates. The first part of my comment about first_name/last_name ethnocentricity applies equally well to template writers.
But, the part about being able to convert one type of citation to another really is a VE issue. The "automatic" feature of the VE template editor is very handy, but it often can't intuit the proper type of template (that's not VE's fault) and falls back to using {{cite web}}. It would be really handy if you could say, "Please make that into {{cite news}}, and do the best job you can converting the fields". RoySmith(talk)14:38, 10 August 2024 (UTC)[reply]
|author= is already present in the existing template parameters, even if just as an alias of |last. Not presenting the alias in VE is a choice of VE, the buck should not just be passed to blindly following a particular table. CMD (talk) 14:56, 10 August 2024 (UTC)[reply]
It might be controlled by the WP:TEMPLATEDATA in something like Template:Cite/doc. I think VE reads the template data to determine the parameters it displays. If a parameter is omitted or set as hidden, perhaps it is not displayed. Not 100% sure but that is probably worth checking. –Novem Linguae (talk) 15:08, 10 August 2024 (UTC)[reply]
Assuming it is, then it would be really useful to have some statistics of how often VE (I know, I should really be saying Citoid or Zotero, or something else, but I'll just keep saying VE because that's what the end user sees) gets it wrong. I'm not entirely sure how we would define "gets it wrong", but a first pass might be "VE initially calls it {{cite web}} which is later corrected to a different {{cite xxx}} variant". Some of that might require instrumentation inside VE to detect when the user abandons a constructed citation before saving it. Some of it might require analyzing revisions to the page to see when template types are corrected after the fact. But let's assume one way or another, we could build a log of incorrect categorizations.
Then what we would do is take the full log of these reports, group them by top-level domain, and sort by frequency. If it came out that "bxtimes.com" was the most frequently domain which got mis-categorized, then it would be the highest priority for a human to go figure out how to fix and add that knowledge to the VE (Citoid? zotero?) database. After enough iterations of fixing the highest priority ones, we'd end up with a better system. If (total SWAG here) we could find the 100 top problems that accounted for 50% of the total errors, with a very small amount of human work to fix them, we could have a major win.
It sounds like a reasonable stab at the misassignment-of-citation-templates issue.
Caveat up front: I'm a developer, but I've never actually touched the internals of Citoid+Zotero, so I might be wrong about details here. That said, I believe you're right that the classification part happens entirely in Zotero, and further that if you want to teach Zotero about how to classify a new site there's some guidelines we have for that over on mediawiki.org. This coming from Zotero is also why we have vastly more classifications than we actually use on-wiki -- check out the mapping for that.
It's possible that some of the incorrect template-usage you see could be at the level of those mappings, as well -- I note that the `statute` type is just hooked up to the generic `Citation` rather than to {{Cite_act}}, for instance, though that's probably far from the most common one to need.
As for the specifics of working that list-of-sources out...
We do have some instrumentation inside VE already that could probably be looked at to work out how often someone gets all the way to the "presented with a citation-template" step and then abandons it, which would give us an okay up-front guess at the rate where something is wrong with the generated citation. Ignoring the question of other types of failure for now, the next problem is that our VE usage-instrumentation is carefully ignorant of content for privacy reasons, so it doesn't know anything about what URL was looked up when that happened. Looking for revisions which consist of just a citation template being replaced with a different citation template sounds doable, albeit slow.
I wonder if we could approach it another way. Assuming that Zotero has some internal logging of the translator it used when we make a request to it, or that it can be persuaded to tell Citoid this, we could perhaps add some logging for requests that fall back to the default-translator for unknown pages. That's not a perfect match for the misclassifications, but it's much easier to find. It does leave out cases where the translator exists but is getting it wrong, of course. DLynch (WMF) (talk) 01:46, 11 August 2024 (UTC)[reply]
it doesn't know anything about what URL was looked up when that happened does it know/track what type of template it chose? If so we can possibly work out what proportion of e.g. cite-news vs cite-web generations were abandoned? I don't think, ottomh, there would be any privacy issues with that? Thryduulf (talk) 01:53, 11 August 2024 (UTC)[reply]
Unfortunately not. All it tracks is that a citoid request happened, and then either that the "insert" button was chosen or that something was done to move away from the citoid results list. It doesn't even track what type was chosen if you go to the "manual" tab and explicitly pick one of the templates listed there.
I do agree it seems very unlikely to be a privacy issue. I mostly mentioned that was the guiding principle to explain why the case for so many questions like this turns out to be "we never needed this actually-very-innocuous content-related data before, so we weren't collecting it". DLynch (WMF) (talk) 02:09, 11 August 2024 (UTC)[reply]
Superb Owl has been maintaining a table of domain names where mw:Citoid has trouble producing a correct citation at User:Superb Owl/Community Wishlist § Automatic Citation Tool. As I understand it, Citoid's problems are partially due to how it scrapes target pages, and if domains are not putting all the information we need in <meta> tags then our only recourse is to improve Zotero translators directly.However, Citoid is understandably geared towards internationalisation and extension to all Wikimedia projects. En.wp has a considerably more complicated / sophisticated / mature citation framework than probably anywhere else. Little things like an automated citation using {{cite web}} instead of {{cite news}} or {{cite periodical}} don't bother me: User:Citation bot converts these, and the only template type it really struggles with is conversion to {{cite book}}, which has a pretty different parameter set.What does bother me about the automated citations output by the Visual Editor (apart from all the <ref name=":0">) is how often it just dumps out obviously incorrect information with no message to the user. Things like |last=B.C. |first=Sima, Qian, approximately 145 B.C.-approximately 86 (1); |last=Company |first=Rand McNally and (2); |last=Feb. 1 |first=the Office of Communications on |last2=2019 |last3=P.m |first3=3:06 (3); |last=à 00h00 |first=Par Le 2 avril 2008 (4); |first=Government of Canada National Research Council|last=Canada (5), etc, etc, etc, bonus consequence.A few days ago, I floated the idea to add a layer of error-checking into the VE citation generation interface. That's really all we need, I think. It shouldn't be the responsibility of WMF staff to ensure that every citation generated by their tools somehow makes sense for our project. But if there could just be one extra step for editors using the interface, where they could see the errors their automated citations are causing our community-maintained modules to throw, maybe they'd take the steps necessary to compare the output against the source and correct the problems before publishing.This won't fix every problem, obviously: algorithmically generated citations are only perfect when they draw on structured metadata that maps properly and completely onto our template parameters. But being able to get feedback during the edit should help editors in the VE environment clean up some of their own messes before they hit mainspace, unreviewed at the bottom of the article. Folly Mox (talk) 12:37, 11 August 2024 (UTC)[reply]
@RoySmith, @DLynch (WMF), @Folly Mox, speaking from experience from creating Zotero translators for a couple websites that I frequently use for citations, errors like this are more often than not a byproduct of missing specific Zotero translator rather than anything else. The default translator will interpret og:type = article as itemType = 'webpage', therefore citiod will use {{Cite web}}. This is unfortunate as even in the default translator's own test cases, vox.com is expected to return as 'webpage' for itemType. However, I would agree with this output, as in Open Graph Protocol, the last object type specified is 'article', and I am assuming that that's the fallback for Facebook as Facebook would use the embedded preview for articles if there's no og:type in the header (i.e. Facebook debugger on wikimedia.sg).
Therefore, what's needed to be done is to either have another translation layer on citiod to map generated citations from identified websites to use {{Cite news}} instead of {{Cite web}}, or write a specific translator for bxmedia.com, or investigate if the default translator in Zotero can be extended further so that the rework for specific websites can be minimal. – robertsky (talk) 18:16, 11 August 2024 (UTC)[reply]
Actually, passing Citoid's output directly to Citation bot before returning it to the editing interface – one specific implementation of another translation layer – sounds like a minimally effortful solution using tools already deployed and currently maintained. Citation bot doesn't fix everything (and breaks some things) but it usually does a good job in selecting which template type to apply to a citation, and in mapping data to appropriate parameters. Folly Mox (talk) 18:35, 11 August 2024 (UTC)[reply]
Yes. I have it enabled as an user script. It just won the Coolest Tool Award for improving the quality of edits. While I appreciate the work there, I also wish there is an easy way to translate the JSON files to Zotero translator format so that the work can be enjoyed by those who cannot use it out of the box on Wikipedia and everyone else who is using Zotero in general. – robertsky (talk) 08:36, 12 August 2024 (UTC)[reply]
65, I had heard of that tool, but wasn't previously aware of its functionality. It looks like a great idea, but for the fact that it is presented as an option to Citoid's output rather than a replacement of it (community generated translators for domains Citoid struggles with should – by definition – always be superior).I'm not interested in apportioning blame for Citoid's output: generalised parsing of html meta elements across the entire set of domains is a hard problem and a big task, with a lot of people involved in every step. But it remains true that for a significant portion of domains lacking structured metadata, Citoid's output ranges from suboptimal to unusable.Any additional translation layer that can be configured by the community would be superior to none, and that functionality should exist in Visual Editor so as to improve the quality of citations generated and reduce the maintenance burden shouldered by script maintainers and experienced editors on this project. Folly Mox (talk) 11:29, 13 August 2024 (UTC)[reply]
Please post corresponding Phabricator tickets for all mentioned "bugbears". 1) Having tickets for these things and 2) making noise in them is the best way to move these fixes forward. –Novem Linguae (talk) 14:31, 10 August 2024 (UTC)[reply]
Thanks all who have participated in the discussion above. I wil admit that this is my first time opening a proposal. Apologies if it is lacking in some details. While early, it seems that at this juncture, there a large support among the participants to have Edit Check deployed and/or Visual Editor be set as the default editor, keeping in mind that there are still some bugbears, or wishes to have some citations related issues resolved (honestly, I think belongs to another thread, but I appreciate the discussion nonetheless). I would like help in bringing this proposal to the next step of having it as a CENT discussion, be it by opening another thread/discussion here or elseswhere, or reformating the current one.
Impact report
In the opening, I presented a wrong statistics from the test that the product team conducted. Upon further check, I found the impact report on reference checks. Short of reproducing the whole report, these are the key numbers:
The number of constructive edits from newcomers increased from 19% to 42% (2.2 times more. As defined by newcomers with less than 100 edits and not reverted within 48 hours).
Breaking down the above number, this is consistent across all wikis with the test on. And on mobile, the increase was 4.2 times more.
Contributors that are shown Reference Check and successfully save a non-reverted edit are 16 percent more likely to return to make a non-reverted edit in their second month (31-60 days after).
10% decrease in edit completion rate for edits where Reference Check was shown
1.8% false nagative
6.6% false positive
From the report, we can see that Edit Check, in particular the Reference Check functionality, helps with improving the content contribution of newcomers and helps to improve the retention of newcomers as well. The 6.6% false postive rate may be a concern, but in my opinion, a minor one. Details from the report indicates that some of the dismissal is essentially WP:SKYISBLUE. Additionally, further finetuning of the configuration for the Reference Check may be made as well to attempt to reduce the false postive rate.
Questions asked
The following are some questions and answers summarised from above (feel free to add more):
Qn: Is Visual Editor is the default editor for newcomers on enwiki?
No. Newcomers are presented with an option to use Visual Editor upon first edit. Declining it will let editors to use source editors instead.
Qn: how does it work with edits that don't need references adding (e.g. creating redirects, adding links on disambiguation pages, fixing spellings, etc)?
The default configuration of needing 50 characters or more before the Reference Check kicks in means that most of the edits asked in the question will not have the Reference Check triggered. Further more, it is for newcomers with <100 edits, therefore it won't be presented to a majority of registered editors.
Qn: Must Visual Editor be the default editor for this to be deployed?
While the functionality is available through a JavaScript switch or through a query parameter, Edit Check is meant for newcomers. If it is not set as default editor, the effacies of Edit Check will definitely be reduced.
Having the user pick whether they want to use visual editor or wikitext editor their first time editing a page (the status quo) seems reasonable and it wouldn't hurt to leave that alone. Perhaps we should just RFC deploying edit check, and leave the visual editor issue alone? The two issues don't seem as strongly linked as I first thought. –Novem Linguae (talk) 06:16, 12 August 2024 (UTC)[reply]
If Edit Check can be deployed without changing the default or not status of VE, it would probably sail through any approval process. If it works, then later someone will be able to pull up stats saying "New editors using VE put references in 80% of their edits but those using wikitext only put them in 15%" or similar to inform that second issue. CMD (talk) 06:45, 12 August 2024 (UTC)[reply]
I should also add that the other target audience is anonymous editors. Right now the experience is as screenshot. This may be a subpar outcome for Edit Check if the primary CTA button is 'Start editing', and the anon/new editors continue to edit in source editor.
As for the statistics of how many new editors are using Visual Editor now, this is one which Foundation staff can help to answer since we do not have the access to user data. – robertsky (talk) 09:54, 12 August 2024 (UTC)[reply]
That information could be gleaned from an appropriate query, since Visual Editor tags its edits. quarry:query/84486 has the first edit for accounts registered in the first half of 2024; something similar and significantly less complicated could probably check for the "Visual Edit" tag. It would be a bit more difficult to include unregistered editors, but a basic usage ratio should be possible to estimate using public data. Folly Mox (talk) 10:32, 12 August 2024 (UTC)[reply]
@DLynch (WMF), I believe these stats are on a Superset dashboard. Can you pull them? If memory serves, there's one query for the first five edits and another for the first 100, but I don't know if one is set up for the first edit alone. WhatamIdoing (talk) 22:40, 13 August 2024 (UTC)[reply]
Edit check will work the same way for VE editors whether or not VE is default. Either way, any usage stats will be within VE users. The message given to anonymous editors who click edit, and the default or not use of VE, do not affect Edit check outside of absolute usage numbers. Generally for new features we have adopted small trials rather than immediate maximal pushses, so in that respect the current VE setup is more a benefit than an issue. CMD (talk) 11:42, 12 August 2024 (UTC)[reply]
@Chipmunkdavis, if the community thinks that an intermediate step to trial out this among the newcomers who enable Visual Editor first is required, we should explore the idea. This may simply mean that window.MWVE_FORCE_EDIT_CHECK_ENABLED=true; or the query parameter should be set in MediaWiki:Common.js (and maybe MediaWiki:Mobile.js as well), of course with account restriction criteria being set to limit the force enablement to newcomers of <100 edits.
letuserEC=mw.config.values.wgUserEditCount// wgUserEditCount: null for anon editors and non null value for registered editorsif(userEC===null||(userEC!==null&&userEC<100){window.MWVE_FORCE_EDIT_CHECK_ENABLED=true;}
I don't see how enabling edit check is an intermediate step, unless the plan is to later expand it to <500 or <1000 edits? CMD (talk) 03:42, 15 August 2024 (UTC)[reply]
It is intermediate step to see if Edit Check on enwiki does encourage an uplift in new/anon editors who are using VE adding content with references. Dependent on the result, we then can determine if it is beneficial to have VE to be the default editor with respect to Edit Check. – robertsky (talk) 05:30, 15 August 2024 (UTC)[reply]
@Robertsky: respectfully, I understand you've personally operationalized Edit Check deployment as involving making VE the default (which it may be recalled I thought was already the case), but these are two separate things. Linking them muddies the proposal and gives the impression of an agenda.I'd love for Edit Check to be enabled on this project, not necessarily for the initial check of adding a reference to a chunk of sufficiently long text (which sounds like a fuzzy test), but for all the stretch goals we could add to it for giving immediate feedback about identified categories of problem edits.Very little opposition should be expected if you disentangle all the Visual Editor stuff from this proposal, and if you wait until more kinds of checks are implemented – the kinds that save experienced editors from making the same kinds of corrections to newbie mistakes over and over – I think you'll see strong support for making Visual Editor the default when that separate question is revisited sometime down the line. Folly Mox (talk) 10:47, 16 August 2024 (UTC)[reply]
@Folly Mox you are mistaken that I am involved in the operationalizing of Edit Check with VE. I simply come across the feature and think that it is a good idea to have it enabled. Of course, there is also a strong desire to set VE as the default, but I am pragmatic. The immediate personal aim is to have Edit Check enabled and then we see if it is really beneficial for the English community. – robertsky (talk) 14:21, 16 August 2024 (UTC)[reply]
I must not know how to use the word operationalized correctly, which is actually something of a relief 🙃 I was trying to describe a comment of yours above where you explained the need for Visual Editor to be the default before the deployment of the functionality is considered complete. Anyway, glad you're embracing the stepwise pragmatism. Should be an easy pass for the simpler "enable Edit Check" proposal. Often mistaken, Folly Mox (talk) 17:58, 16 August 2024 (UTC)[reply]
The likelihood that newcomers will include a reference the next time they add new content
And while we are confident that enabling the visual editor by default for people who are new will have a net positive impact on volunteers across experience levels, the idea @RoySmith, @FollyMox, and @Whatamidoing raised about decoupling the decisions to enable the Reference Check and VE for newcomers and people who are logged out seems wise. [i][ii]
Reason being: doing so, as I think @CMDput well, seems like a relatively lightweight and low-risk way for us to work together to:
Further, as @CMD, @Thryduulf, @RoySmith, @Novem Linguae, @Shushugah, @Folly Mox have mentioned [iv][v][vi][vii][viii][ix], it sounds like there are some facets of the reference experience that would be worth us talking together in more detail about.
The Link Check evaluates all external domains people attempt to link to against the globally-defined meta:Spam_blacklist and the locally defined, en:MediaWiki:BlockedExternalDomains.json and MediaWiki:Spam-blacklist lists.
The Reference Reliability Checks evaluates the references people attempt to cite against the same local and global lists mentioned above.
Zooming out, I think you all are in the best position to decide what you think the most effective deployment sequence here is. And please know: the Editing Team is ready to support you in what you decide.
Alright, I think this is a good place for me to pause.
Please ping me as new questions about Edit Check and/or VE emerge so that I, or another member of the Editing Team, can try to help.
In the meantime, we're going to continue following this conversation and will chime in when we think there is helpful information we can offer.
iii. We'll be able to filter Special:RecentChanges for edits made with Reference Check. You can see this in action at wikis like fr.wiki, es.wiki, and ar.wiki where Edit Check is already enabled.
x. Please boldly add tickets/issues as you see fit
xi. There is an open task the Editing Team will soon address to ensure each time the Link and Reference Reliability Checks are activated, a log entry is recorded in Special:Log/spamblacklistPPelberg (WMF) (talk) 21:11, 16 August 2024 (UTC)[reply]
Call me wary for a number of reasons. First off is the false claim (also posted at the linked Mediawiki page) that Visual Editor must be the default to deploy this, or the later made implication that it makes no sense to deploy this without making VE the default. If these are coupled in this way, with the bigger change used as a prerequisite for the smaller one, then it is a hard no.
Then there is my last (in a long line) experience with a tool that had been tested or even deployed elsewhere, and worked oh so well (makes me thing of Flow, may it rest in peace). A year ago, we were asked to help with a new tool for the Android App[5]. We were told that "During initial evaluation of the model, it was preferred more than 50% of the time over human generated article descriptions. Additionally, Descartes held a 91.3% accuracy rate in testing." and that it had been succesfully been tested in 15 languages already. When we actually tested, it turned out to be very, very buggy and not usable at all. The result was that in August they posted "We’ve officially received grades for all languages and are now finalizing analysis. We will share the outcomes in next month’s update as well as our recommendations for next steps based on the experiment." and then crickets. So from an A/B tested in 15 languages, successful tool with 91.3% accuracy rate to an abandoned project after one short test by enwiki.
And then I tried to test this new tool here. I added a paragraph of text without a source, published, and got the "add reference" pop-up. Choose "yes", got presented with the automatic reference option by adding a title, typed "Lord of the Rings", no luck, so tried "manual". Click on "Book", and get "thank you for adding a citation!" even though no citation is added. Same result if I manually try to add a website or anything. Perhaps it works in real life, perhaps not, but this certainly doesn't give much confidence. Fram (talk) 13:39, 13 August 2024 (UTC)[reply]
@Fram You may see it as a false claim, but it may simply that for the end goal of Edit Check to encourage better content submissions among all anon and newly registered editors can be met by having VE be the default editor.
Your experience in testing out new tools certainly tempers one's expectations on the viability of tools on the platform. With respect to using AI to generated short description, I would also have similar reservations (my cautious approach to/use of AI is known), and still I have to say that it is an unfair comparison given that we are not expecting 91.3% of the new editors to give references. The A/B test in the impact report shows a more modest uplift of ~x2 inputs. Of course, further detailed analysis on a roll-out (in whatever form) on a trial basis can be made if we can tap on the existing tags (i.e. possible unreferenced addition to BLP) or edit filters or even sorting through the raw data.
With respect to the patchdemo wiki, maybe a more updated wiki mirrors better the current real world setup? The demo was generated back in June 2023, more than a year ago. I would have expected bugs and issues between then and now. Furthermore, it might be a patchdemo for limited use? i.e. to show partially the progress of the work? When testing directly on here in enwiki (until before publishing the edit), the reference are being added as a citation be it automatic or manual mode. – robertsky (talk) 19:05, 14 August 2024 (UTC)[reply]
If you insist that statements that VE must be made the default for this isn't a false claim, then I think we're done discussing this. And I see no reason to trust the WMF on any test results, considering that coincidentally just now they posted the results of that other software thing I mentioned above:
" By the time most of you provided feedback the experiment was already completed, and we already received support from some of your fellow experienced editors of English Wikipedia ". Yeah, right, like you posted in the "January update" which you posted in, er, August. And which is completely unverifiable, is based on a very small number of edits apparently by unknown "experienced" editors. They claim on that page that "If users that see the treatment do not select a suggestion more than 50% of the time after viewing the suggestions, we will not expand the feature". Let's see:
How often were Machine Suggestions Accepted, Modified or Rejected?
Edit type
% of Total Machine Edits
Machine suggestion accepted
23.49%
Machine suggestion modified
14.49%
Machine suggestion rejected
62.02%
So why do they plan to continue with the feature anyway? Same as always, I guess, features aren't abandonded no matter how bad, no matter which promises were made, until after (usually) enwiki or dewiki find out how bad they really are, and even then only after an unnecessary, unwanted clash with WMF has been had and mutual distrust gets cemented for another 10 years. So yes, I don't trust WMF test results, I don't trust WMF promises, I don't trust WMF false claims and those defending them, and I don't support a rollout of such features without much better, verifiable (by us) testing or with added "requirements" which aren't needed but pushed by the WMF anyway. Fram (talk) 08:41, 16 August 2024 (UTC)[reply]
I don't support a rollout of such features without much better, verifiable (by us) testing sure. let's test Edit Check out, as what I have said in my previous replies to others. – robertsky (talk) 16:43, 16 August 2024 (UTC)[reply]
I’ve always been disappointed that Wikipedia doesn’t offer this feature and would love for it to be put in to Wikipedia. Since we have AI around, we can easily create quiz questions on a larger scale for the most popular articles. We could start by implementing quizzes on the main page and going from there. I understand that Wikipedia is an encyclopedia, but the question I came here to answer is that is it just an encyclopedia or is it more than an encyclopedia that includes features that are not just for encyclopedias as a general learning site. Britannica has something similar and I think it would be great not to copy everything it does, but have it as inspiration for creating quizzes. I would like to discuss if Wikipedia should have extra features that make the website more enjoyable rather than just reading and editing. I hope you will consider this suggestion. Interstellarity (talk) 21:33, 10 August 2024 (UTC)[reply]
The NY Times runs a weekly quiz, with questions about the previous week's news stories. It's kind of fun (even if I rarely score above 50%). My guess is if you pitched this to WP:SIGNPOST they'd be happy to run it. On the other hand, there's absolutely nothing stopping you from doing it in your own userspace and announcing it on WP:VP. If people like it, they'll vote with their mouse clicks.
I'm not too on board with including quizzes and other gadgets like this, that are a pretty heavy weight to maintain (especially with having to review all the AI-generated quiz questions), while not really being encyclopedic and probably being an uncomfortable distraction for a lot of readers (including me). However, having them on the Signpost would be cool, although I don't think them being AI-generated is a good thing. On a larger scale, I'm afraid of "feature bloat" where the core thing (here, the encyclopedia) gets buried under layers of gimmicks, ultimately making it much less convenient and not necessarily more enjoyable. Adding more for the sake of adding more isn't necessarily a good thing. Chaotic Enby (talk · contribs) 22:43, 10 August 2024 (UTC)[reply]
The idea of quizzes was discussed in June 2022 and by you in March 2022. As I said in those discussions, anyone should feel free to start quizzes on a project page to establish a track record of being able to produce them regularly, and to figure out what audience exists for this feature. isaacl (talk) 04:03, 11 August 2024 (UTC)[reply]
Heh, I just looked up the March 2022 discussion (which I had long since forgotten about) and discovered that I said almost exactly what I said here :-) RoySmith(talk)14:45, 11 August 2024 (UTC)[reply]
I don't get why we need things like extensions and AI to run quizzes. Quizzes existed long before Mediawiki and AI. Just take a couple of minutes to ask a few questions each day/week/month in your user space and advertise it on one of the village pumps and/or Signpost. If the feature is popular then it can be formalised to the main page etc. Nothing will happen unless someone (most likely you) volunteers to do it. Phil Bridger (talk) 08:40, 11 August 2024 (UTC)[reply]
Wikipedia already has loads of extra features that make it more enjoyable, most of which are dramaboards 😉 The true "extra feature" that makes Wikipedia so great is how lightweight and on-mission it is. Even on a bad connection, on a slow device with an old browser, I can navigate to a Wikipedia article, and it will load the whole thing for me to read (certain restrictions apply).I don't have to stop the page loading before stylesheets are applied because it can't reach an advertising partner, I don't have to leave the tab open two minutes and go do something else while my phone wearily executes javascript routines, I just open the page and read the page, like how the internet used to be before it became total capitalism garbage.Any extra interactive features added to the default experience reduce our availability and usability for people on the lower end of computing resource / network infrastructure privilege. It feels important to preserve that equity.So I guess my position is: no, Wikipedia isn't just an encyclopaedia— it's also an online community; but also no, Wikipedia isn't a general pedagogical resource— it's pretty much just an encyclopaedia with an active editing community. Folly Mox (talk) 13:27, 11 August 2024 (UTC)[reply]
For sure! I probably could have done a better job in selecting a qualifier than the term "general" in general pedagogical resource, or maybe should have chosen different words altogether. I was attempting to communicate my personal opinion on the OP's question on whether Wikipedia is just an encyclopedia or is it more than an encyclopedia that includes features that are not just for encyclopedias as a general learning site.Folly Mox (talk) 09:47, 13 August 2024 (UTC)[reply]
Sure, why not! It's an education website. This is something many loose track of, we are in the business of a non-profit education resource. The best way to do this is start a Project and run the quizzes in project space. Once it has a following and support, which might take years and press exposure, then consider something on the front page. -- GreenC20:37, 12 August 2024 (UTC)[reply]
It would surprise most outsiders viewing our non-article space, as well as new editors, that civility is a required as a matter of policy, and is so theoretically important that it is one of the project's Five Pillars. The section on civility in the Five Pillars has an almost quaint sound to it, like something preached in church that no one actually observes. In certain project areas, a kind of "toxic workplace" atmosphere exists, in which low levels of hostility are the norm, are taken for granted, and as a practical matter are not subject to sanction.
We used to have an informal sounding board to deal with civility, WP:Wikiquette assistance. When WQA was shut down in 2012 in a discussion on this board, the community found that WQA "did more harm than good," but there was "also a consensus that there needs to be an intermediary process between the talkpage and ANI, now that WQA is closed." No such intermediary board was ever created, and as far as I can see, perhaps I missed it, but searching through the archives of this board I see no discussion of creating such a board since 2012. I think we need to revisit the topic and create an intermediary civility board. Perhaps just simply revive WQA. Figureofnine (talk • contribs) 13:43, 13 August 2024 (UTC)[reply]
I very much agree that something is needed to avoid the toxic workplace atmosphere while not having to drag people to ANI for every civility issue (which often creates even more drama, on top of needing a pretty high bar for some remedy to actually be enacted). Not sure whether WQA itself is the best, but we definitely need to have an intermediate process for that matter. Chaotic Enby (talk · contribs) 13:58, 13 August 2024 (UTC)[reply]
I just wanted to add (EC) that while the "more harm than good" verdict may have been correct in 2012 (personally I think it was a mistake) it would not be true today, and that an intermediary board is urgently needed if WP:CIVIL is to be taken seriously. Figureofnine (talk • contribs) 14:01, 13 August 2024 (UTC)[reply]
There have been discussions over the years on venues to discuss editor behaviour (such as a noticeboard focused on civility, or a return of the request for comment process for user behaviour). The most recent one I could find is Wikipedia:Village pump (policy)/Archive 167 § A page to report violations of WP:Civility policy. The key question is can a process be created that avoids the pitfalls of the past processes and the incidents' noticeboard, while also being more effective. Many of those who weigh in on this matter want a process that has a feedback process without automatically enacting a sanction, but that only works when the person in question is receptive, and when unfounded inquiries can be swiftly filtered out. English Wikipedia's consensus-based decision-making traditions aren't very good for analyzing behavioural issues in a sympathetic manner: large public, unmoderated group conversations are the opposite of how most organizations provide feedback to its members. Until the English Wikipedia community is willing to look at other decision-making methods in this situation, the root problem can't be addressed. isaacl (talk) 14:57, 13 August 2024 (UTC)[reply]
Maybe we could have a group of users elected by the community to provide feedback on these issues? A sort of mini-ArbCom, but without the gravitas, that will still make the discussions more manageable. We could adopt a format similar to moderated discussion for resolving such issues. Chaotic Enby (talk · contribs) 15:05, 13 August 2024 (UTC)[reply]
Historically, the editors who like to weigh on these matters have been wary of delegating decision-making to a sub-group. An election process is additional overhead, and its results are decided by a self-selected sampling of interested editors. Editors are thus concerned that the sub-group won't adequately represent the community (and from a partisan perspective, that their viewpoint won't be adequately enforced). Personally, I think there will have to be some form of hierarchy introduced to be able to sustain a community of this size (though I think it would better to focus on managing content-related decisions more effectively, which would in turn forestall many behavioural issues, as they become losing strategies for influencing content). But it's not clear to me when the community might reach this conclusion. Moderated discussion might be a form of hierarchy to which the community is more receptive, but at present, it's still more concerned about moderation unduly restricting editors from saying whatever they want. isaacl (talk) 15:34, 13 August 2024 (UTC)[reply]
"Somehow" is the wildcard. Right now, a small number of vocal editors can stop actions from occurring, because the community genuinely seeks approaches that satisfy as many people as possible, in accordance with consensus. Such editors could be considering themselves as holding the line against a devolution into more biased editing, where sheer numbers of editors with an agenda are swamping a given page or topic area, or they could be the ones trying to give an outsized amount of weight to a minority view. If we can find a way to pull the content-decision out of the fray, with a result that remains in force until there are specific reasons to revisit it (*), then we can avoid re-litigating the decision endlessly, and thus remove incentive to be stubborn, aggressive, and repetitive.
But we're not talking about actions, but rather an area where the broader community can make input into specific alleged violations of WP:CIVILITY. The worst that can happen is what currently happens, which is nothing. However it gives a complainant the ability to vent their concerns about the behavior of specific editors or groups of editors. Figureofnine (talk • contribs) 16:44, 13 August 2024 (UTC)[reply]
It seems like this proposal, along with another proposal by Bon courage to shut down WP:DRN as ineffective and Kovcszaln6's comments in that thread, point to a need for an infernal internal forum where disputes are referred to for input by uninvolved editors with the goal of either a) quickly defusing the situation with relevant policy/guideline advice or b) referring it to a more appropriate forum or process. signed, Rosguilltalk19:37, 13 August 2024 (UTC)[reply]
I used "actions" generically to mean anything that the community agrees upon. With English Wikipedia's consensus-based decision-making traditions, many editors don't want to reach an agreement on something that they know several people disagree with. Editors will even try to make accommodations for a single editor objecting.
Regarding a venue to vent, I disagree that this should be a goal of a new noticeboard. There are plenty of places for venting. The community needs effective discussion. isaacl (talk) 20:51, 13 August 2024 (UTC)[reply]
"Vent" was not meant to mean "venting" in the sense of "getting stuff off your chest." "Express" would have been more precise. Yes I agree that we want a mechanism that will do more than give people a place to blow off steam.
I agree with the comments above re an informal forum. I had forgotten about DRN even though I guess I used to participate, as a DRN userbox is on my user page. Figureofnine (talk • contribs) 21:25, 13 August 2024 (UTC)[reply]
The preceding comments seem to be about an internal forum, not an informal one. The dispute resolution noticeboard, as it states at the top, was created to resolve small disputes and help redirect to more appropriate forums. I'm not clear how a new forum with the same purpose would be more effective. isaacl (talk) 02:14, 14 August 2024 (UTC)[reply]
Recreating the dispute resolution noticeboard under a different name isn't a productive use of the community's time. Ultimately, the self-selected set of editors who like to discuss behavioural issues aren't able to reach a consensus agreement on some of the situations that are raised. Moving the discussion from one central forum to another doesn't change this. Determining questions by consensus scales poorly as a group grows larger in size, and it reaches that point very quickly. Further, the way it's done on English Wikipedia, the outcome is highly dependent on who happens to participate in discussion, and so results are inconsistent. isaacl (talk) 15:36, 14 August 2024 (UTC)[reply]
My apologies; I did forget this. I do appreciate that due to there being different people willing to discuss content disputes vs behavioural disputes, a separate noticeboard would be desirable. Nonetheless, it's not clear how to avoid the ineffectiveness of the previous venues as long as the same decision-making processes are in place. isaacl (talk) 20:34, 14 August 2024 (UTC)[reply]
A few thoughts:
Ask four editors to define civility, and you'll get at least five mutually incompatible answers.
The Robustness principle gets applied backwards. What it says is: Ignore the fact that the other guy is dumping profanity on you, but don't ever use profanity yourself. What we see on wiki is: "I'm allowed to use profanity, and you're not allowed to be upset about it!"
Anyone who thinks this is easy has never thought about this.
In particular, anyone who has never considered how to get two people, both upset, to agree on how to treat each other during a hot-button dispute that is important to both of them, when one of them is from a hierarchical face-saving culture and the other is from an egalitarian guilt/sin culture, probably has no idea how impossible it is. The latter person is probably insulting the first person left and right without even realizing it. Now toss in English as a second or third language (anyone else remember the Indian students trying to be friendly by saying "Hi, buddy"?).
We could impose a default culture (which actually will end up being the manners of US white-person middle-class males, no matter what anyone says or wants), but supporting and including all the cultures equally is really, really, really hard. Like "mediator charges US$1,000 an hour" hard, not "we'll all have to think nice thoughts" hard.
I have frequently seen civility arguments improperly introduced either as distraction or defense of some other impropriety, that might explain admin reluctance as well. Do you have any statistics on how many cases are not being properly pursued? Selfstudier (talk) 12:36, 15 August 2024 (UTC)[reply]
If there is no incivility, an uninvolved volunteer can point that out to the complainant. That's the advantage of having a forum in which editors with no knowledge of the topic area can weigh in. The motive of the complainant is immaterial. Civility is required. Figureofnine (talk • contribs) 12:43, 15 August 2024 (UTC)[reply]
I think the nature and motive of the complainant can be material, despite being essentially unverifiable. The complainant can, for example, be a person who uses deception via sockpuppetry to evade a block or ban, then exploits sampling bias to select instances of past incivility to target a perceived political opponent. And this is not a hypothetical. It's something you can observe from time to time. In certain topic areas, when thinking about Wikipedia's homeostatic systems, it is probably worth asking "How would a person willing to use deception exploit this system for their mission?", because that will definitely happen. Employing deception is relatively common in Wikipedia, the protections against it are relatively weak, it is one of the drivers of incivility and people employing deception are immune from all sanctions, including those related to civility of course. So, the way I see it is that civility requirements are nice, but right now, they only apply to honest editors. For editors willing to use disposable accounts, there is zero cost for incivility, and it is another tool that can be used to manipulate a community that will almost always prioritize compliance with WP:CIVIL over compliance with WP:SOCK (and other mandatory policies), probably in part because it is much easier, and people pay attention to drama. Sean.hoyland (talk) 15:13, 16 August 2024 (UTC)[reply]
There is all kinds of rotten stuff that goes on in many topic areas. Somebody in this discussion mentioned tag-teaming in response to civility complaints. There has been canvassing proven time and again that has come up on AE. That is beyond the scope of any Wikipedia forum short of AE or Arbcom. Figureofnine (talk • contribs) 15:50, 16 August 2024 (UTC)[reply]
A good thing about a WP:3O or WP:RfC for civility is that it'd put more focus on wikiquette (probably) in new editors' minds. Currently, there are a lot of avenues for dispute resolution regarding content, which creates a lot of focus on work. The work of building an encyclopaedia is of course important. But if editors are driven off due to incivility, who is left to build it? Aspets (talk) 14:35, 17 August 2024 (UTC)[reply]
In a real-life workplace that relies on collaboration, if somebody has reached the point of swearing, sniping, or snarking at their colleagues, they are probably beyond the point of no return and about to enter a one-way HR process, assuming they aren't fired on the spot. Real-life workplaces have the luxury of enforcing strong filters at the interview stage, which are usually highly effective at enforcing the kind of culture the workplace wants to have. Since we don't have that luxury, perhaps we could consider another popular tool that real-life workplaces use: training.
Wikipedia is a deeply weird workplace. Remote-only text-only collaboration (ROTOC) does not come naturally to human beings. There are some people who find it perfectly obvious, but that's only due to years of training through doing computer-mediated work. To be clear, you don't have to be a computer person to work here, but it helps. The group of people with the most extensive ROTOC training happens to be a group that skews white, middle-class and male.
I'm sure many of us have rolled many an eye through extremely dull and patronising computer-based-training courses that teach us how to suck eggs, but that eye-rolling is a privilege afforded to those who are expert egg-suckers already. I think if we want to improve standards of collaboration, a new/revived form of disciplinary process would be the worst approach, because it would be an inherently negative experience. Explicit training in ROTOC skills has the potential to be a positive experience for the victim.
I was thinking about how maybe we should be thinking in terms of "proactive public health" rather than "remedial process". Remsense ‥ 诉11:07, 18 August 2024 (UTC)[reply]
Remote-only text-only collaboration (ROTOC) does not come naturally to human beings. There are some people who find it perfectly obvious, but that's only due to years of training through doing computer-mediated work. Does in-person collaboration come naturally either, though? Or is it just that neurotypical humans usually pick it up through years of training as young children (with the details varying by culture)? Anomie⚔11:54, 18 August 2024 (UTC)[reply]
Totally unsolicited, slightly overcooked reflections here: without really thinking of natural or otherwise—writing is just comparably discrete (though not discreet) in what it communicates; given the additional social context provided by face-to-face speech and general cues of colocation. You often have to try harder such that you get everything you want across and nothing more, and it can feel alienating, as if anyone you're trying to get on the same page with dissolves into the aether save for the instant where they reply. That is to say, consensus-building sometimes feels less like a directed process you're invested in with others and a bit more like trying to craft the right magic spell to use on your interlocutor, with substantially less clue to what degree they're "getting" what's already been said. Remsense ‥ 诉12:32, 18 August 2024 (UTC)[reply]
As I've discussed elsewhere, unmoderated online conversations are prone to overly verbose, repetitive discussions. In face-to-face conversations, listeners can provide visual cues or well-timed interruptions to mitigate this. There is already a lot of advice pages on English Wikipedia regarding desired behaviour (see Wikipedia:Essays in a nutshell/Civility and Template:Wikipedia essays for many links). I've also discussed elsewhere (though I can't recall exactly where) that although it is desirable to have guidance that outlines expectations that are specific to the English Wikipedia environment, it's too onerous to try to provide training on all aspects of interpersonal communication. We rely on editors having picked up these skills in their lives outside of Wikipedia. isaacl (talk) 15:37, 18 August 2024 (UTC)[reply]
it's too onerous to try to provide training on all aspects of interpersonal communication It's more like training in interapersonal communication that is needed. I don't think we should launch a primary school, but maybe something like a finishing school. Well, not really a school. Just some good guidance on the differences between collaborating with people in person, and collaborating with people in our weird environment. Essays like Wikipedia:Expectations_and_norms_of_the_Wikipedia_community are good, but they are buried in the vastness of project space. I think the "training" form factor for this kind of information could reach people in a way that essays don't and post-incident interventions definitely don't. The medium is the message...
To make this idea concrete, it could be as simple as offering a kind of interactive quiz, with each question being a collaboration scenario, and then some multiple-choice answers for what the best approach would be. The answer-reveal can explain why one of the answers is best, and what the possible bad outcomes of the other answers were. Basic stuff, but perhaps only basic because we've been steeped in it for a long time.
If it's just me creating a curriculum, then sure, I could assemble something. But odds are you have a different idea of what should be covered and emphasized, and editor X wants to add another scenario, and editor Y thinks the structure is entirely wrong, and so forth. Our help pages sprawl because it's really hard to get any agreement on modifying them, so editors just create more of them. And there are endless variations that different people think are vitally important to cover. isaacl (talk) 21:01, 18 August 2024 (UTC)[reply]
Also, I'm not sure if this approach will reach the target audience. A lot of Wikipedia guidance ends up being just link targets that editors brandish, as getting people to read and follow documentation is hard. isaacl (talk) 21:08, 18 August 2024 (UTC)[reply]
In a real-life workplace that relies on collaboration, if somebody has reached the point of swearing, sniping, or snarking at their colleagues, they are probably beyond the point of no return and about to enter a one-way HR process, assuming they aren't fired on the spot. This comment astounds me, Barnards.tar.gz. You and I must have worked in deeply different sorts of workplaces. I can't deny what you said must be true for the kinds of places you've worked, but that type of hardline, attitude-based termination culture seems to me like it might be restricted to a subset of workplaces that exhibit high profitability, staffing, and turnover.I've been in and seen others be in face-to-face meetings over attitude issues, but all the terminations I've seen were based in either exposing the company to legal liability, unreasonable theft of company property, or absenteeism.I'm not arguing we can't do better in showing people the door than all the places I've been employed, but we are talking cultural differences, and my astonishment at the above moved me to chime in with a counterexperience. Folly Mox (talk) 17:01, 18 August 2024 (UTC)[reply]
To be clear, the successful workplaces I have experienced do not have a termination culture at all, and HR incidents are extremely rare, because the input filter is so strong. Any workplace that had as many "admin interventions" as we do here would be a circus of dysfunction. What I'm trying to say is that we don't want to have to resort to interviewing prospective editors to ensure "good fit" or "team player" or equivalent, but we could perhaps learn from other ways that workplaces manage their culture without resorting to disciplinary proceedings. Barnards.tar.gz (talk) 18:00, 18 August 2024 (UTC)[reply]
I'm all for that. I have no disagreement: merely divergent lived experience. I don't believe I've ever worked anywhere with a particularly selective interview process, so that probably has something to do with it. All the best, Folly Mox (talk) 18:10, 18 August 2024 (UTC)[reply]
Folly Mox, in the US, in most white-collar jobs, "swearing, sniping, or snarking at their colleagues" is going to look like a hostile work environment to HR and therefore exactly a case of "exposing the company to legal liability". Whether the swearing or the sniping or the snarking is more likely to attract a performance improvement plan likely depends on the industry (e.g., the construction industry may accept swearing, or the fashion industry may accept snark) and the target (swearing at inanimate objects is usually more accepted than running down your colleagues), but there's a risk. WhatamIdoing (talk) 18:15, 18 August 2024 (UTC)[reply]
Way back in the day, I was a regular at WQA. WQA was non-binding, and explicitly not a place to request that another user be sanctioned in any way. I thought it was a good thing to have a page to discuss civility issues without the threat of a block. I don't agree that it "did more harm than good" but I would admit that it was very often innefective. Somewhere between half and two-thirds of cases filed there moved on to ANI after a day or two, while other suffered from one or more of the parties simply ignoring it. In the end the fact that it could not lead to sanctions is probably what doomed it. Like the also-deprecated WP:MEDCOM or the moribund backwater that is WP:AARV, completely voluntary processes with no "teeth" have proven largely innefective. I think that's a shame but there it is. Just Step Sidewaysfrom this world ..... today18:38, 14 August 2024 (UTC)[reply]
In the I/P area an admin, ScottishFinnishRadish kindly allows his talk page to be used as a very informal sounding board on issues relating to that area. It a good thing to have. Matters are not always resolved but it is a good way for people in that area to ascertain if behavior they see in that area is undesirable or not, and if undesirable, if potentially sanctionable. Perhaps in the eyes of an objective admin it's not worth pursuing. So OK, the editor may not like that, but that is an objective judgment.
People I think should lower their expectations. Having something is better than nothing. Having an admin generously allow his user page to be utilized in this fashion is certainly a lot better than nothing at all. Having an intermediary board on civility of some kind (for which there was a consensus in 2012) is better than nothing. How to structure such a board is another matter. But let's not just throw up our hands because civility is sometimes subjective. Personally I don't think it is as subjective as some here have argued. It is difficult to measure "success," and perhaps we are too hung up on that and not on having a kind of "peace process," pardon the expression. Going back to the point I raised at the beginning, editors who perceive an ongoing low-level civility issue, a toxic workplace of sorts, at the current time have, for all intents and purposes, nothing. Figureofnine (talk • contribs) 18:56, 14 August 2024 (UTC)[reply]
I think the old Wikipedia:Requests for comment/User conduct process was more useful than WQA, but it still fundamentally relied on people voluntarily responding to the feedback. In particular, it was useful for the sort of WP:IDHT cases in which getting people to "vote", all on the same page, that they disliked your behavior might convince you that all of the previous complaints weren't just random individuals with weird standards, and that The Community™ actually didn't approve. But I don't think it was wildly successful; I think it was just occasionally helpful. WhatamIdoing (talk) 19:10, 14 August 2024 (UTC)[reply]
I feel editors got tired of the something just being a dead end that took up time before taking up the issue at a different noticeboard. A redundant noticeboard isn't better than not having it. On the other hand, I can see how something more like Wikipedia:Administrative action review, with a no-fault review of a given scenario, could be useful in separating the evaluation of behaviour from the determination of any restrictions. But the problem of a lack of consensus in the community (at least among the subset that discusses these matters) regarding accepted behaviour remains. isaacl (talk) 20:34, 14 August 2024 (UTC)[reply]
I keep hearing people saying that WQA was a waste of time, a dead end and so on. I beg to differ. I participated in it myself as a volunteer, and just checked the archives to confirm that I was actually pretty active for a time. I found my participation to be interesting and rewarding. I feel that I helped people. While I was fairly new to the project at the time, it wasn't hard. WP:CIVIL wasn't and isn't rocket science. While a good deal about Wikipedia was complicated, civility was not. It didn't, and doesn't, take a law degree to figure out what's civil and what isn't. I wish people would be more positive on the WQA. It was better than I think it is being characterized, and I certainly don't feel that it was such a snake pit or horror show at all. Figureofnine (talk • contribs) 21:26, 14 August 2024 (UTC)[reply]
Common sense is often enough, especially when the disputants come from the same culture. However, common sense isn't enough when Alice, who thinks in black-and-white terms, feels justice is only served by clearly and directly stating that Bob's actions were wrong, and Bob, coming from a culture that values indirectness, deeply feels that clearly and directly stating that anyone's actions were wrong is inherently, appallingly rude and that doing so is a loud, firm message from the community that they want him to stop editing entirely. If you don't have a lot of information about different cultures, you'll probably think that Bob flounced off. WhatamIdoing (talk) 17:24, 15 August 2024 (UTC)[reply]
This seems exaggerated to me. There are going to be some differences in what people consider "uncivil" both across and within cultures. But I've only ever seen one instance of "this isn't a problem in my culture", and it was shut down immediately because it was a direct attack on people with mental illness. Thebiguglyalien (talk) 21:44, 15 August 2024 (UTC)[reply]
It's not really exaggerated IMO. Seldom does anyone actually say "this isn't a problem in my culture" though. In my experience off Wikipedia, it's more likely that Bob would make a complaint about Alice to HR, then HR will spout some BS about making a "safe space for everyone" and threaten to fire Alice over it while ignoring how they're making an unsafe space for her. On Wikipedia, more likely is that Bob would feel chased off and nothing much else happen. But something like WP:FRAMGATE is also a possibility, particularly once the UCoC committee gets running. Anomie⚔22:30, 15 August 2024 (UTC)[reply]
Some years back, we had at least two editors claiming to be Australian and insisting that using profanity was a core cultural value for All True Australians™. We had 800K registered editors last year. Finding a few people whose truthfulness you doubt a bit is to be expected.
(If you are interested in mental health conditions among editors, then you might be interested in the back-of-the-envelope estimate at User:WhatamIdoing/Editors are people. NB I left out autism – an obvious source of tension between "face-saving" and "plain speaking" disputes – because we have far more Autistic editors than average, so the usual calculations don't hold.) WhatamIdoing (talk) 01:59, 16 August 2024 (UTC)[reply]
We're focusing quite a bit in this discussion on "results." Skimming through my own contributions there (I don't believe I ever came in as a complainant or respondent) I see that true, sometimes the discussions that I participated in did not bear fruit. But people would come and I'd look at their problems and I'd say, "well this is uncivil and this isn't." Is that a bad result? We can't always box-score these things, folks. I was surprised when I learned, afterwards, that WQA had been closed. Figureofnine (talk • contribs) 21:31, 14 August 2024 (UTC)[reply]
In your original post, you expressed concern about there being an uncivil environment on English Wikipedia. Thus I think it's reasonable to consider if a proposed change would help address this concern. What barriers are there now that keeps the community from looking at discussions and thinking, well, this is uncivil and this isn't? Is bringing back an old venue an effective way to remove these barriers? Is it worth the opportunity cost? isaacl (talk) 07:10, 15 August 2024 (UTC)[reply]
Of course, and I appreciate your "reality check" comments. But as I go back to the archives and look at my participation in WQA as a volunteer (which I had pretty much forgotten as it was a 13+ years ago) I remember positive aspects that hadn't previously occurred to me, and which are at variance with how WQA is sometimes portrayed. I don't recall even once being flummoxed as to what was civil or what was not. Obviously the complainants and respondents had their own view, or it wouldn't have come to WQA. But as a volunteer, even a relative newcomer, it was always a slam dunk one way or the other.
Another point that I think needs to be made, which didn't previously occur to me, is this. Let's say Editor X is editing in an environment in which other editors WP:OWN the topic area or seek to do so. They engage in sarcasm, personalize discussions or otherwise contribute in a deleterious way. While WQA or something like it can't resolve the issue, it can certainly help with a subsequent resolution if a volunteer uninvolved in the topic area says "yes this is uncivil" or "no, this is not uncivil." It helps Editor X if he wishes to make a fuss going forward, or may discourage him from doing so. This kind of input is difficult to quantify. The volunteers are just ordinary editors with no stake in the matter under discussion, but their perspective matters. The fact they're not admins with the ability to block or topic ban does not detract from their impact. Such input may well make the subject area less toxic and more civil, easier for everyone, even if it does not resolve the underlying dispute. Making things more civil should not be underrated.
Incidentally we're not talking about resuscitating WQA, necessarily. The consensus back then, which of course does not bind us, is to create some kind of "intermediary" forum. Figureofnine (talk • contribs) 12:15, 15 August 2024 (UTC)[reply]
Sure, I just went with the concrete proposal you made in your original post. Like it or not, there was a consensus about the shortcomings of the previous noticeboard. I don't think you'll be able to overcome those views just by saying you disagree with them. A new proposal needs to identify a goal, which could be qualitative in nature, and demonstrate the value and effectiveness of the proposal in achieving it.
In practice, we don't get a volunteer saying "this is/isn't civil", and everyone saying, ah, OK. We get some uninvolved volunteers saying the behaviour is civil, and other uninvolved volunteers saying that it isisn't. We get editors disagreeing with the assessment and thus seeking broader and broader input, consuming more and more community time. A proposal for a new process would have to find a spot where it could add value without just becoming another cycle in this spiral. I'm not sure how to bypass this roundabout, other than my thoughts on fostering collaborative behaviour and thus making poor behaviour a losing strategy. isaacl (talk) 14:45, 15 August 2024 (UTC)[reply]
The fact that you don't recall even once being flummoxed as to what was civil or what was not either says something about WQA attracting only simple complaints (e.g., most reports were mere tattling about obvious misconduct), or your lack of awareness about the complexities involved in intercultural communication. WhatamIdoing (talk) 17:29, 15 August 2024 (UTC)[reply]
No, I don't recall being flummoxed. Not once. Not a single time. Ever. The behavior complained about ("tattled" as you inappropriately put it) was always either civil or uncivil. The policy is simple and editors of any background or culture can go to WP:CIVIL and absorb what is there.
The purpose of an intermediary board, as I see it, is to provide a third opinion on these matters. the 30 suggestion below is not a bad idea. For the umpteenth time, I'm not suggesting we resuscitate the old WQA board but figure out in good faith a possible intermediary board as was the consensus in 2012. Figureofnine (talk • contribs) 12:21, 16 August 2024 (UTC)[reply]
As you know (as I assume you saw my ping there), ScottishFinnishRadish's talk page serves as an intermediary step in the I/P area that allows people to come to him rather than AE. There are plenty of "rules and guidelines" dealing with contentious topic areas but still it helps having his talk page as an intermediate, informal step short of AE. Figureofnine (talk • contribs) 12:34, 15 August 2024 (UTC)[reply]
Yes, and an admin has the power to engage in topic bans and worse. An intermediary board is just a fellow editor weighing in on civility alone. Nothing else. It's a nonpunitive way of an uninvolved editor telling another editor that he's either not being civil or that his incivility complaint is without merit. Figureofnine (talk • contribs) 12:45, 15 August 2024 (UTC)[reply]
You mentioned above that civility complaints are often brought without merit. An intermediary board volunteer can make that same point in a non-punitive way. I know because that is what I did when I was a volunteer on WQA. Figureofnine (talk • contribs) 12:47, 15 August 2024 (UTC)[reply]
I'm sympathetic to the idea of a new (or revived) method of dealing with incivility. But most solutions are going to run into the same problem that we see at ANI, in that it's ultimately cultural instead of procedural. If we want to fix this, we need to make cultural changes:
Crack down on victim blaming and "get a thicker skin" comments.
Abandon the toxic "more heat than light" philosophy. When this refrain or some variation of it is invoked, it tells the people affected that we either aren't able to help them or that we don't care enough to help them. It says that we'd rather let it be someone else's problem, even if it means kicking the can down the road and letting it get worse (which makes the eventual boiling point even more chaotic).
Challenge incivility tag-teaming. User A is frequently uncivil and eventually gets taken to ANI. They're causing harm everywhere they go and are a serious threat to editor retention. They've been given dozens of chances and a ban should have been implemented years ago. But then Users B, C, and D all show up and oppose any sanctions for whatever reason they come up with. Maybe they ignore the context and say that this interaction isn't sanctionable, or maybe they pick one mistake the reporter made and make it all about that. Their filibuster gets it closed without action. The next month, User B is brought to ANI for incivility. Users A, C, and D then show up to complain about "civility police" and ask that the discussion be closed as a frivolous report. And so on.
Unless someone has any creative ideas to fix this, the only solution is for everyone who's tired of Wikipedia's toxic culture to call out incivility when they see it and make their voice heard at ANI. Thebiguglyalien (talk) 21:40, 15 August 2024 (UTC)[reply]
I've been here a while and I don't find it toxic. Get a thicker skin is sometimes appropriate and there are different ways to say that. Maybe a bit cut and thrust time to time, at the end of the day it's just words not bullets. OK sometimes they can hurt too and egregious cases need to be dealt with as does persistently bad behavior. There's a lot worse places to be than WP. Selfstudier (talk) 22:03, 15 August 2024 (UTC)[reply]
Getting a thicker skin is not something people can do on command, though, which makes it inappropriate.
Sure, but it isn't necessarily only about the present moment. Surely a constructive, civil observation about someone's conduct can factor into their future self-reflection and ultimately help them out? That's often how these things seem to work. Remsense ‥ 诉11:21, 16 August 2024 (UTC)[reply]
I'm probably from the wrong culture to be offended / hurt on Wikipedia. I deeply value kindness and consideration towards others, but I also feel like if I make a lot of mistakes and generate a lot of work for others, I should be called out on it, and told why what I'm doing is a problem. Any cultural corrections we attempt to implement to improve our atmosphere also need to take into account that we're working on a project together, and the quality of our output does matter. We also need to take into account weaponization of civility policy used for removing frustrated / escalated opponents from content disputes. Folly Mox (talk) 11:15, 16 August 2024 (UTC)[reply]
I think the whole "culture" issue is a red herring. We have no way of knowing what "culture" an editor is from, and editors are obliged to follow Wikipedia policies regardless of background. Figureofnine (talk • contribs) 12:27, 16 August 2024 (UTC)[reply]
That would make more sense if this were a content policy and not a conduct one. The concept of civility is mediated by culture, if explicated considerably in the policy body. Remsense ‥ 诉12:32, 16 August 2024 (UTC)[reply]
We sometimes used to get editors saying they were on the spectrum as a reason they were behaving contrary to policy. Usually the best approach was for fellow editors to calmly point out to them what the standards are. Likewise, if somehow one's claimed culture results in incivility, then the best approach is for a uninvolved volunteer to calmly point out what our civility policy says, rather than an administrator to impose sanctions or a formal warning. Figureofnine (talk • contribs) 12:39, 16 August 2024 (UTC)[reply]
That's why an intervention by an ordinary editor is helpful if an editor gets carried away or has an emotional issue or is genuinely on the spectrum. If an editor is using incivivility as a tactic in a larger "battlefield" campaign, then obviously nothing short of a block or topic ban will deal with it. But if the civility aspect of a problematic editor is addressed by an uninvolved editor, and they reject that counsel, it establishes a record for future action if necessary. Figureofnine (talk • contribs) 13:04, 16 August 2024 (UTC)[reply]
Having an "ordinary editor" intervene is only going to helpful if that editor knows what he's doing. Imagine that you have an editor who is trying to fix something and unintentionally breaking something else in the process. It's generating a lot of work for other editors, and we need to do something to stop that problem.
However, the correct "something" depends on the editor's perception of what constitutes civil behavior. Here are three different ways to say the same thing:
For someone like Folly Mox, you might take a direct, informal approach: "Hey, you probably didn't realize it, but when you frob the widget, it breaks the glorkanfangle. I fixed one of them for you like this so you can see how to fix it. Ping me if you've got any questions."
For someone from a face-saving culture, you would make more of an effort to affirm the value of their efforts and your humble request: "Hello, and thank you for your helpful contributions to fix the widget. I appreciate you noticing and fixing that problem. When you are making those edits, would you please consider fixing both the widget and the glorkanfangle at the same time? It would save the community a lot of effort, because the glorkanfangle's operation depends on the widget's settings. Here is a combined diff that shows how to fix both at the same time. Please let me know if there is anything I can do to help you."
For someone who is autistic, your message should be direct, detailed, and comprehensive: "You have made many edits to articles containing the widget. Unfortunately, the changes you have made to the widget are interfering with the glorkanfangle on those pages. Please stop making edits that break the glorkanfangle. According to the template's documentation page, if you need to fix the widget, then you must also adjust the glorkanfangle settings. You should do this either in the same edit or immediately afterwards. If you don't do this, then the page will be in violation of the Wikipedia:Manual of Style/Accessibility guideline, the readers will see a misformatted infobox, and your edits may be reverted without warning by any editor who sees them. Here is a diff showing the correct way to adjust the widget and the glorkanfangle at the same time, and here are pages showing what the pages look like before and after adjusting the glorkanfangle. When you make these changes, be sure that widget remains above the glorkanfangle in the wikitext code. As soon as possible, you should either self-revert all of your edits to the widgets, or go back and fix the broken glorkanfangles on all of those pages."
All three of these communicate the same three main points to their specific audience:
Stop breaking pages.
Here's the information you need to achieve your goal without breaking pages.
Go clean up your mess.
But:
For the first two, "Stop breaking pages" and "Go clean up your mess" are implied, rather than directly stated. For the last, everything is plain and clear. You don't need to guess what the message-writer might be thinking about your edits. You don't need to guess what might have been left unsaid. You only need to follow the written instructions.
For the middle one, the message emphasizes the editor's positive contributions and downplays the problems created. We are not saying that the editor did anything truly wrong, because that would be offensive. We are instead only making a humble request that the valuable editor make even better contributions. We are trusting that the face-saving editor will be able to infer from the information provided that their edits screwed things up and that we want them to fix it.
If you go to a face-saving person with the autistic-oriented message, the person is likely to feel like it is an offensively direct public rebuke. They will not feel like it is a civil message. But the face-saving message will confuse and stress some people on the autism spectrum, because it's so vague: Is this an optional extra? Do they want something specific from me? Is this just an interesting fact to know? They didn't tell me to take any action about this, so I didn't – why are they mad at me now?! The end result is that they will not feel like it is the kind of message that supports and builds up the community – which, depending on how you define civility, means they will not feel like it is a civil message.
When we look at human interactions, there are a few universals (e.g., condemnation of unprovoked murder), some commonalities (e.g., table manners exist everywhere, though they look different in different places), and some differences (e.g., approach to punctuality). Especially for ordinary communication, what's considered civil depends on the culture. That's true regardless of whether the humans are interacting in person or online. The end result is that what counts as "civil" to people from one culture is very obviously "uncivil" to people from another culture. WhatamIdoing (talk) 18:10, 16 August 2024 (UTC)[reply]
Agree with your points, and as an irrelevant aside, I actually respond best to being shamed and guilt-tripped, which – perhaps relevantly – I don't regard as incivil. (Nor do I practice those, nor recommend for the general case). I've been too well trained by toxic supervisors and partners. So I'm probably a bad example. Folly Mox (talk) 16:57, 17 August 2024 (UTC)[reply]
In terms of process, I feel like a step we could take would be expanding / forking WP:3O to include behavioural concerns alongside content disputes. Dropping a quick template transclusion in a conversation where you're looking for an uninvolved opinion on civility feels like a much more lightweight process, without all the visibility and unstructured commentary a noticeboard is likely to generate.Of course, any process without the power to impose sanctions is unable to deal with genuine problem actors, but if it's a case where someone is being inappropriate but willing to listen to a voice outside the immediate dispute, calling in a single busybody to have a look at the exchange might have some positive outcome. Folly Mox (talk) 11:07, 16 August 2024 (UTC)[reply]
Having a third person provide an opinion works best when both sides are receptive to feedback. With a behavioural dispute, though, if both persons recognize there is a dispute regarding behaviour yet fail to agree on ways to mitigate the behaviour, then they're unlikely to be receptive to a third person weighing in. (If they were, it's likely they would have found a way forward on their own.) In the case of an unrecognized clash in cultures, a third person could help provide context, but that would depend on the two parties recognizing there is a clash, and that third person being able to recognize this as well and subtly learn through discussion with the two parties about their cultures to isolate the clash. isaacl (talk) 20:17, 16 August 2024 (UTC)[reply]
Could you elaborate regarding point #2? I've never heard that idiom before, but after looking it up (neat!) I'm only a shade more sure what behavior was being characterized as such. Apologies in advance! Remsense ‥ 诉11:14, 16 August 2024 (UTC)[reply]
"More heat than light" usually used to mean "this comment is expressing the emotion of anger, instead of objective facts". The idea that expressing emotions is unhelpful or inappropriate is fairly common in Western culture, particularly in English-speaking or northern European cultures. It is odd and uncomfortable to people from cultures that are less fearful/more accepting of emotional expression. WhatamIdoing (talk) 18:13, 16 August 2024 (UTC)[reply]
Just to clarify, I'm referring to entire discussions getting shut down per this reasoning. My argument is that sweeping problems under the rug is dismissive to the people trying to bring attention to them, and it entrenches long-term issues to make things marginally easier in the short-term. And I'm not concerned by whether someone is from a given culture or not; civility isn't a matter of never saying anything imperfect ever, it's about being able to communicate these things and walk away with a mutual understanding. Thebiguglyalien (talk) 18:53, 16 August 2024 (UTC)[reply]
The analogy is with a light bulb, where the intended purpose is to provide light to an area, and the side effect is to generate heat. (If the reverse is intended, then you'd call it a heating element.) Ideally you want as much energy as possible emitted as light rather than heat, to be more efficient. A conversation generating more heat than light isn't providing enough additional insight into the topic to make it worthwhile. isaacl (talk) 20:24, 16 August 2024 (UTC)[reply]
Most of the really vicious stuff done to other editors is not covered by wp:civility, in fact weaponizing wp:civility is a common way to "get" other editors. Most people would rather have us stop people from civilly sticking the knife into their ribs than stopping people from using swear words. North8000 (talk) 20:25, 16 August 2024 (UTC)[reply]
Although I imagine there could be cases where it would help, as I discussed earlier, I think it would more often be disregarded as just one other person's opinion. In situations where two people have failed to find a way forward on their own regarding behaviour, I'm hard-pressed to think of cases where one uninvolved person joining the conversation has resolved the dispute. isaacl (talk) 12:13, 17 August 2024 (UTC)[reply]
Honestly, while I think that WP:CIVIL is extremely important, it's also probably the easiest of our conduct policies to enforce. When someone is persistently uncivil it tends to produce easy, obvious diffs that can be thrown up on WP:ANI, WP:AE, or even in an ArbCom and which will eventually get them sanctioned. I don't think we need elaborate mechanisms to encourage and enforce it. It's the opposite problem, WP:CIVILPOV, that is difficult to enforce, because it's something that has to be inferred from someone's extended edit history rather than producing easy at-a-glance diffs that can be used to show what someone is doing wrong in a few clicks, compounded by the fact that most CIVILPOV accusations involve multiple editors accusing each other of it while framing themselves as the selfless defenders of the wiki, in situations that tend to look like simple content disputes from the outside (and often just are.) But for CIVIL cases it's not hard to figure out which editor in a dispute is throwing around insult and aspersions, which is why we end up with situations like eg. Wikipedia:Arbitration/Requests/Case/Antisemitism in Poland, where a case premised on serious accusations of intentional distortions of the facts resulted in editors being sanctioned mostly for saying mean things to each other; even ArbCom couldn't untangle the underlying accusations (and to be fair to ArbCom, most of the editors didn't even try to make those accusations during the case, probably because they knew how hard it is to prove compared to pointing out obvious incivility.) If you think there are areas where incivility isn't being sanctioned, though, IMHO all you have to do is take it to ANI or AE - incivility tends to be easy to enforce when someone actually pulls it into the light. --Aquillion (talk) 17:38, 17 August 2024 (UTC)[reply]
I agree that the "easy, obvious" problems are easy to spot and obvious when seen. But I don't think that all cases of incivility are easy to spot, and I don't think that all accusations are true. WhatamIdoing (talk) 18:17, 17 August 2024 (UTC)[reply]
RFC on whether "add prominent links to crisis hotlines at the tops of articles" is a perennial proposal
One thing I like to do occasionally is to use AutoWikiBrowser to make spellings on articles consistent with their English vareity (for example changing "favorite" to "favourite" in British English articles). A mistake I made once was changing "-ize" spellings to "-ise" spellings in British English articles, when both are correct in British English. We have Template:Use Oxford spelling to say "this articles uses the -ize suffix" but we do not have one for -ise spellings. I propose creating a template for that, and I have already created it and the documentation in my sandbox.
To be clear, this proposed template is not for English varities that only use the -ise suffix (such as New Zealand English). It is only for British English (and to a lesser extent, Canadian English) which allows both -ize and -ise. ―Panamitsu(talk)07:59, 17 August 2024 (UTC)[reply]
This seems like a rather narrow justification for taking up an entire additional line at the top of articles. It seems far more practical just to be more discriminate with your AWB gnoming, unfortunately. Remsense ‥ 诉08:08, 17 August 2024 (UTC)[reply]
Why is any of this needed? From what I am reading at {{Use Oxford spelling}} and at Oxford spelling, "-ize" is Oxford spelling, and "-ise" is part of normal British spelling. If the article you are checking uses "-ize", you can presumably add the Oxford spelling template; otherwise, leave the British spelling template and leave the -ise endings alone. What am I missing? – Jonesey95 (talk) 15:27, 17 August 2024 (UTC)[reply]
As a Wikipedia convention I would support this, however if this does not reflect real world understanding of spelling variation, then we need a more precise term/spelling instructions. I was previously under the impression that British English was always -ise unless specified as Oxford English, but learned something new today. ~ 🦝 Shushugah (he/him • talk) 22:11, 17 August 2024 (UTC)[reply]
Respectfully, I really do not think we need more precise spelling instructions. This isn't a big deal, and is only an issue because of automated tools making assumptions that result in disruptive swaps between equally correct forms. Remsense ‥ 诉23:13, 17 August 2024 (UTC)[reply]
I don't think it is only useful for automated tools because editors have to figure out whether to use -ise/-ize when adding content. A tag saying which to use is just like how we already have the tags saying which engvar to use. ―Panamitsu(talk)00:09, 18 August 2024 (UTC)[reply]
But it's not a big deal for generalized gnoming. One single orthographical difference simply does not require a different ENGVAR to be specified, whether as a subtype or otherwise. Remsense ‥ 诉01:49, 18 August 2024 (UTC)[reply]
It doesn't require it to be specified, but it in the same way that it doesn't require any ENGVAR to be specified. That doesn't mean it's not beneficial to specify - especially as it will (in at least some cases) reduce the work needed later on. Thryduulf (talk) 10:01, 18 August 2024 (UTC)[reply]
It's worth zooming out to note there are quite a few WP:VAR things we don't tag articles with, in my mind likely because the undue bureaucracy plus undue clutter outweigh the time saved and clarity achieved. It seems like the potential disruption from editors "making it more clear" with campaigns of various size changing EngvarB → EngvarB-ise makes this worth opposing. Remsense ‥ 诉10:37, 18 August 2024 (UTC)[reply]
It's four more characters, I don't see it as adding too much clutter or bureaucracy compared to the clarity it adds. Also, why would changing EngvarB to clarify "ise" if the article already uses "ise" be a disruption? Chaotic Enby (talk · contribs) 12:25, 18 August 2024 (UTC)[reply]
Getting Current With Cultural Trends
To keep up with recent trend to keep relationships defined as per their choice, there are partnerships such as Civil Partnership, Platonic Relationships, or just Girlfriend and Boyfriend etc... please change spouse to partner or any culturally relevant term thar reflects the current state of preferences on bio pages of individuals. DhawanMohan13 (talk) 16:33, 18 August 2024 (UTC)[reply]
DhawanMohan13, why change "spouse" to "partner" in the majority of cases where it is correct? I am married. I have a wife (gender-neutral term "spouse") and she has a husband (gender-neutral term also "spouse"). Many people that I know have partners or boyfriends or girlfriends. We should describe everyone, incuding those who have a spouse, accurately. Phil Bridger (talk) 17:18, 18 August 2024 (UTC)[reply]
The definition of spouse is (written) your husband or wife, I doubt it acknowledges people who are in a relationship they dont want to label. For example just boyfriend girlfriend, civil partnership, etc... DhawanMohan13 (talk) 05:03, 19 August 2024 (UTC)[reply]
I think what Phil is saying is that if someone is married, there is no reason not to use the word 'spouse' accurately. Otherwise, 'partner' is fine. – Joe (talk) 05:06, 19 August 2024 (UTC)[reply]
Or is the concern in the opposite direction?
@DhawanMohan13, it's not clear which problem concerns you:
"Mrs. Married" is legally married, but you think we should write "her partner" instead of "her spouse", to sound current and trendy.
"Miss Girlfriend" is not married, but you have found a Wikipedia article that talks about "her spouse", when it ought to say "her partner" or "her boyfriend".
Of course the article about Miss Girlfriend should be corrected, but we should leave Mrs Married as is, unless we have sources saying that she prefers not to use the term. Phil Bridger (talk) 07:14, 19 August 2024 (UTC)[reply]
I was looking around some pages, and found the now defunct WP:ADCO. I thought that this would be a great idea to bring back in a way, as the amount of RFAs is dwindling, and I believe there is many Wikipedians who would want to start a RFA, but would find it too daunting. I am aware of programs such as WP:RFAPOLL, but believe we need something more. Now I don’t believe we can revive WP:ADCO in its entirety, but I think we can come up with something similar. Thanks, Lordseriouspig05:06, 31 July 2024 (UTC)[reply]
My take on this is that anyone who needs coaching will not make a good admin. The quality needed (besides honesty, which I hope goes without question) is to "get" Wikipedia, which is very difficult to teach someone. The problem that we have with RfA goes much deeper than this. Phil Bridger (talk) 17:27, 11 August 2024 (UTC)[reply]
Make UI more user-friendly
As a regular, I find the UI honestly dull. In an age where the Olympics has a webpage for the purpose of quizzes and games. I find that maybe Wikipedia would be touted as a technological marvel in 2015, but the year is 2024 and, in all honesty, Wikipedia is quite uninspiring. — Preceding unsigned comment added by Usernamesenior (talk • contribs) 19:02, 3 August 2024 (UTC)[reply]
So, your title is "Make the UI more user-friendly", but your actual interest is "make the website something other than an encyclopedia"? Remsense诉19:06, 3 August 2024 (UTC)[reply]
It is a marvel that in 2024 there is a high-profile mainstream website that isn’t filled with ads, flashy junk, and trendy design churn. Well, as long as you think Vector 2022 was an improvement… Barnards.tar.gz (talk) 16:28, 5 August 2024 (UTC)[reply]
There is a great deal of potential in the notion of supporting a quiz/game interface with Wikipedia. It would not be part of Wikipedia per se, but would draw on and depend upon wikipedia. This could be, potentially, the 21st Century Trivial Pursuits. --03:09, 6 August 2024 (UTC) — Preceding unsigned comment added by Ceyockey (talk • contribs) 03:09, 6 August 2024 (UTC)[reply]
There is also a potential for interfacing generative AI into article enhancements in the following way ... Given Wikipedia Article X and Source Y, what propositions would be suitable to pursue for enhancement of the Wikipedia article (X) based on the newly propositioned citation (Y)? The beauty of this is that it provides suggestions to editors about how to contribute rather than working toward AI-based article revisions. Thoughts? --03:16, 6 August 2024 (UTC) — Preceding unsigned comment added by Ceyockey (talk • contribs) 03:16, 6 August 2024 (UTC)[reply]
This is a nice idea. I suppose people can already do this albeit in a clumsy, high friction way now that LLM context windows are large enough to cope with the entire contents of Article X and Source Y. Sean.hoyland (talk) 13:26, 6 August 2024 (UTC)[reply]
But that's not that hard for a human to do. I think the effort of building that infrastructure for mediawiki would outweigh the total effort of doing it the way we do now. Cremastra (talk) 14:06, 6 August 2024 (UTC)[reply]
Bot to block Proxy/VPN IPs (ST47ProxyBot replacement)
Hey folks, I'd like to get some thoughts on an adminbot that monitors RecentChanges and reactively blocks VPN/open proxy IPs it encounters. We used to have ST47ProxyBot which preemptively blocked such IPs, however the bot's operator, ST47, has indicated that they are no longer interested in running this bot. Long story short, there is a plethora of VPN/open proxies on the internet with new operators coming online every day; it has become technically unfeasible to identify and block all of these. Bad actors have been attacking our admin noticeboards with these VPNs/open proxies which has resulted in them being semi-protected for extended durations of time. That said, I'm interested in building an adminbot that monitors RecentChanges (or just the administrator noticeboards) for edits from VPN/open proxy IPs and blocks them (can optionally revert the most recent edit made by these IPs too). Noting for the record that some discussion on this has occurred here (permalink). Courtesy ping for @Robertsky. -Fastily21:25, 8 August 2024 (UTC)[reply]
I don’t have strong feelings against this one way or another. I share the concerns of others that, especially with developments in internet infrastructure over the past decade or two, it is much less simple to block open proxies now. But if an admin bot can accurately evaluate (with a sufficient level of accuracy) and block/revert, so what if it only catches 1% of the actual open proxies? I also think this should be evaluated as a “continuation” of the prior adminbot - even if it has slightly different code, from what I can see there was consensus for this type of adminbot before so absent significant new concerns about the stability/false positives now, should be fine for Fastily or another admin to take over the *task* even if doing it with different code. -bɜ:ʳkənhɪmez | me | talk to me!21:35, 8 August 2024 (UTC)[reply]
Thus far the disruptive IP addresses that have been blocked on the admin boards has proxy-like behaviours stated in the user information tool (that can be seen on the Contributions page). That can be a likely reliable signal/condition to revert and block such IP addresses if they touch on the admin boards. – robertsky (talk) 10:52, 9 August 2024 (UTC)[reply]
Agree with Berchanhimez that this task doesn't seem like it should require a second consensus for approval, but if it does I support it. Folly Mox (talk) 11:28, 9 August 2024 (UTC)[reply]
A bot that monitors recent changes and reactively blocks VPN/open proxy IPs rather than preemptively may be a useful compromise. We already have a bot that monitors recent changes and logs VPNs/proxies at WP:OPD; it seems to log very many but perhaps not all, that will be dependent on the database. As an aside, I’ve never see so many blocked 'anonymizers' on that log, which is almost entirely due to the current disruption.
The current disruption is using a very particular anonymizing network so perhaps a focus on blocking that one preemptively would be helpful in the short term. -- Malcolmxl5 (talk) 18:38, 9 August 2024 (UTC)[reply]
I think we may need to look at some possible ways to fix WP:OR. Apparently, one editor thinks it means you can't use any news media coverage for articles. i think their point is maybe that you can only use peer-reviewed articles to cover current events, since those are published findings? i think.
this whole thing kind of doesn't make a whole lot of sense, to me. anyway, I am trying to decide what to add to WP:OR. i have a few possible drafts, but i wanted to get this section started now. i hope to work on some possible drafts, and then post them soon. However, please feel free to comment now. Sm8900 (talk) 14:01, 9 August 2024 (UTC)[reply]
If the issue is just one editor misunderstanding the existing content then the solution is to explain to them what it actually means. If they cannot or will not understand that then the solution is to take action against that user to prevent their misunderstanding disrupting the encyclopaedia. Only if the misunderstanding is widespread is a rewrite of WP:OR likely to be needed. Thryduulf (talk) 14:09, 9 August 2024 (UTC)[reply]
@Thryduulf, that sounds pretty good. i could use a little heelp, actually. would you be willing to please add some input? you can find the article talk page easily, in my contribs history today. Sm8900 (talk) 14:52, 9 August 2024 (UTC)[reply]
If we want a misinterpretation that's so wide-spread it has been written into the policy, how about we get rid of most of Wikipedia:No original research#Primary, secondary and tertiary sources? As far as I've ever seen, the distinction between "primary" and "secondary" is often unclear and seldom actually useful versus the nutshell of WP:OR itself, Articles must not contain any new analysis or synthesis of published material that reaches or implies a conclusion not clearly stated by the sources themselves. Even much of what's said in the PSTS section is just as true if you only read "source", ignoring the adjectives. Mostly the section seems a vehicle for people to reject a source for being "primary" (i.e. the opposite of the essay Wikipedia:Primary does not mean bad) instead of having a harder discussion about WP:RS and WP:DUE and the other parts of WP:OR. But I doubt this will go anywhere, too many people value exactly that vehicle. Anomie⚔15:02, 9 August 2024 (UTC)[reply]
@Anomie I agree too. I've lost count of the times that I've had to argue that for objective facts primary sources are often the most reliable sources. Thryduulf (talk) 16:06, 9 August 2024 (UTC)[reply]
I agree too. Secondary sources are fine when we have them, but the current wording seems to disfavour primary ones more than they deserve. Gawaon (talk) 16:45, 9 August 2024 (UTC
here is the kind of comment i have to deal with in opposiition to using perfectly good factual data, from perfectly reliable good sources from newspapers: The text that would be added makes no coherent case or argument. It has no clear theme, thesis or point. It does not show an analysis. This would require secondary sources - preferably of good quality. That would then be encyclopedic content. Research is the analysis of primary material. Drawing together the data is the first step in research. The added text alludes to a thesis, which, if stated, would be OR (where the thesis does not exist in sources). But without this, the text lacks the cohesion and substance that would make it encyclopedic. If the thesis is not presented in sources, it probably isn't noteworthy - or perhaps it hasn't been found. Either way, the addition as made isn't supported.
so this comment is saying that absolutely no data can be gleaned from primary sources such as newspaper accounts, firsthand accounts, etc. really!! this is unbelievable!! is there anything we can do???!!! Sm8900 (talk) 01:59, 10 August 2024 (UTC)[reply]
so by this logic, even a published book would not be able to serve as valid source for self-efident objective facts, such as the book plot etc!!! this doesnt seem reasonable!!! Sm8900 (talk) 02:01, 10 August 2024 (UTC)[reply]
Without more context, that's a discussion that probably needs to happen on the page where it's happening rather than here. "The text that would be added makes no coherent case or argument" is something one cannot judge without knowing the text in question. Gawaon (talk) 06:39, 10 August 2024 (UTC)[reply]
@Gawaon, the talk page is at Talk:Iraq War. they are simply refusing to let me use newspaper articls that clearly show that major national leaders expressed opposition to the war years later. the question of whether that topic is needed is not the focus of the comment above; they are literally rejecting any use of newspaper articles, as clearly shown in the comment above. Sm8900 (talk) 11:12, 10 August 2024 (UTC)[reply]
Instead of "getting rid of" PSTS, I suggested splitting it to its own policy page a while ago (1, 2, 3, probably others). It did not go well. We had really fundamental I-can't-believe-we-are-all-native-English-speakers-here levels of failure in communication. The most frustrating was trying to convince people that if we put the PSTS ==section== on a different page ►with a {{policy}} tag at the top, it would still be a policy. Editors thought that giving PSTS its very own {{policy}} page would be a demotion that would somehow make it stop being a policy. WhatamIdoing (talk) 21:13, 12 August 2024 (UTC)[reply]
Wow, yeah. Looks like you had two people there who had things absolutely backwards, seemingly convinced that whether a source is "primary" or "secondary" is critical to determining whether something is WP:OR or not rather than that WP:OR#PSTS is a (somewhat poor) heuristic for "source that will probably have the kind of analysis we need for a good article". Anomie⚔01:42, 13 August 2024 (UTC)[reply]
really fundamental I-can't-believe-we-are-all-native-English-speakers-here levels of failure in communication
I believe that news sources are good for basic facts, but their use should mostly end there. It's not that you should never use news articles as sources, but at a practical level the key is contemporary versus retrospective coverage. Real time contemporary sources definitely shouldn't be used to determine notability, provide analysis, explain effects or significance, etc. They lack the scope and context to make that possible. To avoid bogging down discussions every time this comes up, I wrote my full thoughts at User:Thebiguglyalien/Avoid contemporary sources. Thebiguglyalien (talk) 07:31, 10 August 2024 (UTC)[reply]
by this logic, you would never be able to write articles about opinions of major public figures at all. you would not be able to use a newspaper article to glean a public figure's opinions on anything, and you would need to someohow search for some complex thesis article when writing even about the most minor issues. Sm8900 (talk) 11:20, 10 August 2024 (UTC)[reply]
Well, that's kinda the point? If no one else has ever written about the views of some major public figure on some topic in e.g. a book about the topic or the public figure, and the only place we can find that information is in some contemporary news article, then it's probably not important enough to include in an encyclopaedia article. Folly Mox (talk) 13:28, 10 August 2024 (UTC)[reply]
on the contrary, most historical statements get completely missed by secondary soruces. this is wikipedia. the historical coverage here is ten times more broad and more complete than any other reference works that are published. Sm8900 (talk) 23:10, 11 August 2024 (UTC)[reply]
Your impression of our historical coverage is roughly the reciprocal of my impression, ± a few orders of magnitude. And I'd posit that most historical statements are deliberately unmentioned by secondary sources, not "missed" during the research phase. Folly Mox (talk) 09:29, 13 August 2024 (UTC)[reply]
ok, so then wikipedia is the repository for such statements, which most historical works and journal articles would otherwise miss entirely. Sm8900 (talk) 14:36, 13 August 2024 (UTC)[reply]
This is a fundamental misunderstanding of what Wikipedia is and is WP:NOT. In all these years, has no one ever nudged you in the right direction and told you that you're supposed to be summarizing information from reliable secondary sources, proportional to how it appears in these sources? That you can't string together primary sources to support an argument? The historical works and journal articles have already decided what's significant enough to cover. We don't get to act like we know better than them; that would be original research and it would deviate from a neutral point of view. Surely at some point your work has seen scrutiny through a process like GAN or PR where a problem like this should have been noticed? Thebiguglyalien (talk) 15:20, 13 August 2024 (UTC)[reply]
ok sorry, i truly don't understand. so if a natural disaster, or an election, or a major coup, or a major government appointment occured within the last week or so, what sources should be used, other than newspaper articles? could you please clarify?
I think this discussion will go much better if we are simply open to asking questions, or expressing constructive ideas and opinions, and getting useful information. ok, so please feel free to clarify. thanks. Sm8900 (talk) 15:28, 13 August 2024 (UTC)[reply]
If a simple fact needs updating like who holds a government office, then yes, a news article is fine to verify that. News articles might also be useful for basic facts, like if one mentions someone's date of birth for example. It's not that primary sources can never be used. It's that they don't dictate content. Like I said under section break 2, WP:PROPORTION lays it out plainly. An event or an opinion simply appearing in the news on its own isn't enough to say it needs to be in an article (let alone have its own article); millions of things appear in the news. But if a subject matter expert includes it in a journal, a book, or any sort of analysis, that's an indication that it might be WP:DUE. Thebiguglyalien (talk) 15:53, 13 August 2024 (UTC)[reply]
ok. thats a valid reply. but then, why do we have articles on elections , coups, natural disasters, new laws, changes in government, etc? if no secondary soruces exist for such event when they are only two or three weeks in the past, then how can such articles exist? Sm8900 (talk) 16:12, 13 August 2024 (UTC)[reply]
Political stuff like elections and coups get analyzed pretty much right away. There's already extensive analysis of the upcoming U.S. elections, and those are still months away. But in my opinion, people often jump the gun on creating articles about events like disasters or crimes, and they often have to get deleted eventually. Thebiguglyalien (talk) 16:18, 13 August 2024 (UTC)[reply]
ok, so now wait a second friend. the title of this is maybe we need to fix wp:or, remember? so now maybe we are finally coming around to the actual topic here. ok, so you vote in the column for not using newspapers as sources too often. ok, fair enough. now can we discuss the fact that we already do use them, and then maybe consider what would be some logical constraints or ideas, for how to actually do so properly? Sm8900 (talk) 16:28, 13 August 2024 (UTC)[reply]
I would actually say that they are often secondary. Sometimes they are primary sources, like if you wanted to source an editorial for someone's opinion. Loki (talk) 17:06, 13 August 2024 (UTC)[reply]
Gawaon This is a common misconception, but it makes a huge difference when it comes to OR and NPOV. When we're considering newly reported content like we are here, they are primary sources. This is the case both in academic historiography and on Wikipedia. Per WP:RSBREAKING: All breaking news stories, without exception, are primary sources, and must be treated with caution. WP:PRIMARYNEWS also gives a little explainer. Thebiguglyalien (talk) 17:19, 13 August 2024 (UTC)[reply]
ok, but "breaking news stories" are totally different from articles pblished in an actual print newspaper. "breaking news" refers to stories that can only exist online, as they would need appear immediately after the event. and also, to quote that page: Just because most newspaper articles are primary sources does not mean that these articles are not reliable and often highly desirable independent sources.Sm8900 (talk) 17:44, 13 August 2024 (UTC)[reply]
Breaking news comes out of radio and television: they would "break into" normal programming (e.g., interrupt a soap opera) to make an announcement. The older equivalent is a Newspaper extra (if you have enough to fill a page) or just a last-second article added at press time (or after it, in the case of a stop press order). WhatamIdoing (talk) 20:40, 13 August 2024 (UTC)[reply]
@Folly Mox, if the only place we can find that information is in some contemporary news article, then thats why we would use the news article as the source for that, actually. Sm8900 (talk) 21:18, 12 August 2024 (UTC)[reply]
Sm8900, I took a Quick Look at the text you would like to add, and immediately saw why other editors are saying that it violates WP:OR. The text starts with a sweeping statement about the world’s view of the war and then attempts to support that statement by giving examples of politicians sharing that view. The examples are individually (and appropriately) supported by citing news sources, but… what is missing is a source that sums up these examples to reach the initial sweeping statement (a conclusion, even though it is written first).
This is classic original research. We can not take examples A+B+C and state conclusion D … unless we have a source that explicitly states A+B+C=D. This is precisely why WP:PSTS warns that primary sources must be used with caution. It is very easy to misuse them to inappropriately support original research. Blueboar (talk) 12:45, 10 August 2024 (UTC)[reply]
That does not resolve the Original research… the problem is that you (a Wikipedia editor) are the one combining these individual statements by various politicians to form a conclusion. What you need is a reliable secondary source that combines the statements by various politicians to reach some form of conclusion.
Weasle wording “some” also introduces DUE WEIGHT issues: why were the statements by these specific politicians chosen? Do they represent the majority view or are they cherry-picked outliers? Are there politicians who have contrary views?
Again… what you need to look for is a secondary source that notes what various politicians have said about the war, puts what they said into context and sums it up. Doing it yourself (even hedged by weasel wording) is where you engage in the original part of NOR. Blueboar (talk) 13:40, 10 August 2024 (UTC)[reply]
Those kinds of secondary sources don't always exist, depending on the topic. And when reporting politicians positions and views, then published news articles seem totally acceptable as sources. Sm8900 (talk) 22:35, 10 August 2024 (UTC)[reply]
That's the point. If those secondary sources don't exist, then it should not be in the article. To quote WP:PROPORTION from the NPOV policy: An article should not give undue weight to minor aspects of its subject but should strive to treat each aspect with a weight proportional to its treatment in the body of reliable, published material on the subject. For example, a description of isolated events, quotes, criticisms, or news reports related to one subject may be verifiable and impartial, but still disproportionate to their overall significance to the article topic. This is a concern especially for recent events that may be in the news.Thebiguglyalien (talk) 22:50, 10 August 2024 (UTC)[reply]
That sounds vastly exaggerated and non-proportional. Especially for recent events, it'll take years, if not decades, until they (maybe) get reliable coverage in secondary (later insertion: academic) ssources. Academics don't work so fast. Plus many films, series etc. may well get next to no coverage in secondary sources at all, despite meeting our notability criteria. If there are secondary sources, it's best to chiefly rely on them. If not, primary and tertiary sources may well come to the rescue, and that's a good thing. Gawaon (talk) 06:58, 11 August 2024 (UTC), edited 07:25, 11 August 2024 (UTC)[reply]
If there's next to no coverage in secondary sources at all, then it is not notable. Per WP:GNG: "Sources" should be secondary sources, as those provide the most objective evidence of notability. There is no fixed number of sources required since sources vary in quality and depth of coverage, but multiple sources are generally expected. If you think that means Wikipedia would have to ignore most current events, then you're correct. Wikipedia doesn't exist to document news. Thebiguglyalien (talk) 07:08, 11 August 2024 (UTC)[reply]
Okay, I got confused a little bit. Generally I tend to think of secondary sources as academic sources, and I'd say those are indeed among the best sources we have. But I had somehow mentally classified newspaper coverage and such as tertiary sources. However, it seems they are generally considered secondary too. WP:NOR#Reliable sources even says that "magazines, journals ... published by respected publishing houses" as well as "mainstream newspapers" are among "the most reliable sources". So sure, a topic needs sufficient coverage in secondary sources, newspapers included, to get its own article, per WP:GNG. I absolutely agree on that. But note that the GNG is about whether a topic gets its own article, it's not about the article content at all. See WP:NNC. Here we're mostly talking about content, so the GNG doesn't apply. Gawaon (talk) 07:42, 11 August 2024 (UTC)[reply]
Secondary sources don't have to be academic. An analysis published in a newspaper is a secondary source for example and these are not uncommon. Traumnovelle (talk) 08:30, 14 August 2024 (UTC)[reply]
While some changes might be needed, I think I would be against "getting rid of most of Wikipedia:No original research#Primary, secondary and tertiary sources." In editing historical topics, I have found WP:PRIMARY useful. Users have, for example, tried to argue that Nathan Bedford Forrest wasn't actually racist or involved with the KKK, tried to argue that Mehmed II committed rape on the floor of the Hagia Sophia, etc., using primary sources. If accounts like these (memoirs, diaries, travel literature, ancient histories, etc.) aren't reinforced or repeated by scholars, they usually don't belong in there. I am definitely not arguing for a blanket ban on journalistic sources; the user you're telling about was clearly misinterpreting it. I am just saying how it has been useful for me.--MattMauler (talk) 14:24, 10 August 2024 (UTC)[reply]
@MattMauler, thats very useful input. your statement here is very useful: I am definitely not arguing for a blanket ban on journalistic sources; the user you're telling about was clearly misinterpreting it.Sm8900 (talk) 23:09, 11 August 2024 (UTC)[reply]
I would make two points. Firstly many editors seem to think that the distinction between primary and secondary sources is something that was made up by Wikipedians. It was not. It has long been used by historians and rather more recently by scientists. And secondly I get the impression that there is a generational divide here between us oldies, who grew up in the days before Wikipedia (and even the World Wide Web) existed, and remember encyclopedias that existed before Wikipedia supplanted them and that were nothing like newspapers, and the youngsters who seem to think that every web site has to be up-to-the-minute with breaking news. Phil Bridger (talk) 20:01, 11 August 2024 (UTC)[reply]
I'm finding it completely baffling to understand the objection to secondary sources. where is the secondary, non-journalistic source to tell you who is the Secretary of Agriculture? who is the governor of Maine? who is the director of budget for the city of Norfolk, Virginia? what is the current status of the Iraqi government? what is the current nature of the Q train in Brooklyn, New York? what are current plans for the BQE expressway in New York?
furthermore, if an article is decribing any recent current event, then what source would they use other than news articles? there are dozens of examples, obviously. for example, if the article is covering the US withdrawal from Afghanistan, or the 2024 US presidential election, or the accession of King Charles of the UK, what sources would exist at all, other than news articles? I'm truly baffled by this. Sm8900 (talk) 03:37, 12 August 2024 (UTC)[reply]
we already have an article on the recent tragic plane crash in brazil. i don't want to detail it too much in this venue, out of respect for the human tragedy here. however, there would not be any source to use for details on this, other than newspapers. Sm8900 (talk) 04:52, 12 August 2024 (UTC)[reply]
The relevant guideline is WP:PRIMARY. Generally speaking a primary source trumps a secondary when it is authoritative. In other words, the Secretary of Agriculture is whoever the Department of Agriculture says it is. When it comes to news sources, they can be primary sources and sometimes not. For current events, news sources may be the only sources available. However... primary sources must always be used with great care. It is fine to use them for facts, but you cannot draw conclusions from them. (WP:No original research) For this, secondary sources are required. Hawkeye7(discuss)05:13, 12 August 2024 (UTC)[reply]
@Hawkeye7, I Agree !! please note, my key point of agreement is with this statement of yours. please note, I'm saying this with sincere assent, as your statement on this seems fully valid to me!! For current events, news sources may be the only sources available. ....primary sources must always be used with great care. It is fine to use them for facts... [etc]Sm8900 (talk) 15:51, 12 August 2024 (UTC)[reply]
Last night I was reading Death in Yellowstone and the author talked about the dilemma of using newspapers: Newspapers, as every historian knows, must be used with care, most often as a supplement to more reliable sources. Unfortunately, with all of their potential inaccuracies, caused by deadlines, distance, and other factors, newspapers are sometimes our only sources for fleeting bits of history, pieces that get too easily lost in the forward march of time, and pieces of strictly local history that get published nowhere else. It caught my attention because of this ongoing discussion. Schazjmd(talk)13:16, 12 August 2024 (UTC)[reply]
can we make a rule against excluding newspapers as sources??!!
there seems to be some contradictory rhetoric going on, above on this page. we Wikipedia has articles such as 2024_United_Kingdom_riots#10_August, yet we have people in the section above stating outright that newspapers should not be used as sources. can we simply make it clear there is no basis for excluding newspapers as sources? this simply seems ridiculous. --Sm8900 (talk) 20:25, 12 August 2024 (UTC)[reply]
Newspapers need to satisfy WP:RS requirements and be weighted accordingly with the claim made. There is extensive and nuanced discussion in WP:RSN to resolve disputes over reliability of said newspapers. Happy verifying! ~ 🦝 Shushugah (he/him • talk) 20:29, 12 August 2024 (UTC)[reply]
further example(s) below, of articles requiring newspapers as sources. this whole issue seems self-evident to me.
I think we can make a blanket rule that no source should be excluded based solely on what type of source it is. Sometimes using a newspaper is appropriate, sometimes using a newspaper is in appropriate - but in neither case is that because it's a newspaper it's because of the combination of the context of the Wikipedia article and the context of the specific source article. Indeed WP:MEDPOP explicitly says the quality of press coverage of medicine ranges from excellent to irresponsible. An excellent newspaper article about a treatment that explains it in appropriate context without oversimplification etc might be the best available for the topic, conversely articles in peer review journals get retracted and those should not be used (other than for WP:ABOUTSELF and similar purposes).
One I've seen a few times is editors rejecting a youtube video as a source because it's a youtube video. Some youtube videos are top quality reliable sources, some are active disinformation. Thryduulf (talk) 00:16, 13 August 2024 (UTC)[reply]
yes, I agree with @Thryduulf on their comments on this, as stated above.
I think we can make a blanket rule that no source should be excluded based solely on what type of source it is.
One [problem] I've seen a few times is editors rejecting a youtube video as a source because it's a youtube video. Some youtube videos are top quality reliable sources, some are active disinformation.
I agree that we can not (and should not) “ban” citing news media… however, I do think that we often cite news sources inappropriately. There is a more nuanced discussion that needs to take place: When is it appropriate to cite news media, and (perhaps more importantly) when is it inappropriate to do so?Blueboar (talk) 15:07, 13 August 2024 (UTC)[reply]
@Blueboar, awesome insight and idea. i'm hoping discussion can proceed, and address the possible refinement that you have helpfully added and expressed above. thanks!!! Sm8900 (talk) 15:10, 13 August 2024 (UTC)[reply]
I don't think we really need any more rules about newspaper sources. We already have WP:PRIMARYNEWS, which qualifies when newspapers should be treated as primary sources, and WP:MEDRS, which state that newspapers aren't usually appropriate for medical topics. It really depends on the context and the reliability of each specific source though. Even generally high quality sources like the NYT may not be reliable for high-level scientific discussion, whereas a local newspapers that gets all the facts right can sometimes be used as a source for a complex topic. Epicgenius (talk) 23:52, 13 August 2024 (UTC)[reply]
this is a helpful reply by @Epicgenius. and in general this whole discussion has been very informative. i think this discussion has brought up a lot of points that were helpful, and which helped me increase my knowledge. i will give this some thought, and review the policies again with the points above in mind. I will comment if I think of any actual changes that I would like to propose. Sm8900 (talk) 02:41, 18 August 2024 (UTC)[reply]
OR is working well and as intended, actually
This discussion wasn't making much sense to me until I read Talk:Iraq War#suggest we need a section on "political impact", and then everything fell into place. Sm8900 is trying to add a section on the war's political impact which synthesises quotes he's selected from various American politicians into sweeping statements like By 2016, the public consensus in both major parties of the United States was that the Iraq War was based on invalid reasons, did not accomplish anything positive, and was highly detrimental. Other editors are correctly pushing back on this because this is a conclusion he has drawn himself rather than a conclusion drawn from a source. This is good. There is no problem here. – Teratix₵06:37, 13 August 2024 (UTC)[reply]
it is not good, and your dismissal of this topic shows your approach.
and there is absolutely nothing wrong with adding a section to describe politicians' opinions on any particular policy issue, using newspaper accounts and articles as sources. it is entirely possible that my own draft on that specific topic needs to be changed or improved, or perhaps discarded if it does not have consensus. that does not change the larger issue here.
your obvious goal is to cause some degree of personal upset here. by the way, @Teratix, all that's needed for WP:Civil to be needed here, is for one of us to state that the other one is acting discourteously. that is it. I will be glad to show you basic courtesy, and ask only the same thing in return. Sm8900 (talk) 14:41, 13 August 2024 (UTC)[reply]
re the public consensus on the Iraq War, when Jeb Bush did not express strong opposition to the Iraq War during the 2016 campaign, he was widely criticized, both by major candidates and also by major media outlets, so in the end he did need to reverse his approach.
and newspaper articles which provide broad overviews of a major societal consensus or reaction, are indeed valid sources in this regard. maybe we need to open a section to address the larger issues here? oh wait, thats right, that's precisely what this section is. Sm8900 (talk) 14:44, 13 August 2024 (UTC)[reply]
in short, your objections above may indeed be valid re my own proposed text for that specific article. with that said, the topics of this discussion here at village pump are entirely different. editors here are entirely free to agree or disagree with my ideas here on the topic of WP:OR, as they see fit.
however i think it is obvious that any editor would find it somewhat demeaning to see their own ideas on one article brought into the discussion as an absolutely non-relevant tangent, in a page section which relates to other issues entirely. i am trying to indeed grant the validity of anyone's views who may wish to disagree with my approach for the proposal at that specific article as you cite above. Sm8900 (talk) 14:59, 13 August 2024 (UTC)[reply]
any editor would find it somewhat demeaning to see their own ideas on one article brought into the discussion as an absolutely non-relevant tangent. By your own account, the pushback you received from other editors regarding your proposed addition on Talk:Iraq War was the impetus for starting this discussion in the first place. You, yourself, have quoted and mentioned the discussion in the above sections. Why would you do that if you didn't think it to be relevant?
there is absolutely nothing wrong with adding a section to describe politicians' opinions on any particular policy issue, using newspaper accounts and articles as sources There is a problem when you draw conclusions that the sources do not reach themselves, when the section gives certain perspectives undue weight or when there are higher-quality sources available that could be used instead. These problems were why your proposed Iraq War section was rejected.
that does not change the larger issue here. The point is, despite what you think, there is no larger issue here. Editors applied the policy exactly how they are supposed to, they got the right result, Wikipedia is better off than it would have been. Changing the policy would make things worse.
I'm not out to upset you. I just think your ideas about how Wikipedia works, and how it ought to work, are badly, badly wrong. It's not personal. – Teratix₵15:55, 13 August 2024 (UTC)[reply]
You, yourself, have quoted and mentioned the discussion in the above sections. Why would you do that if you didn't think it to be relevant? correct, i mentioned the specific views on the question of what sources can be used, since thats the topic of this section here at village pump. i did not belittle any of the replies that disagreed with me on the specific proposal for that specific article.
There is a problem when you draw conclusions that the sources do not reach themselves, when the section gives certain perspectives undue weight .. these problems were why your proposed Iraq War section was rejected. i'm completely ok that there may be flaws or problems with my proposed text for that article, and that the community may choose to disagree or indeed reject the proposed text for that article, if it chooses.
The point is, despite what you think, there is no larger issue here. Editors applied the policy exactly how they are supposed to, they got the right result, with respect, pelase read the mutilple replies i have received above, that agree with my views on the larger issue here. thats the whole point of opening this question for wider discussion here, where the community can comment.
I'm not out to upset you..... It's not personal. ok, noted. I'm fully willing to accept your reply on that, as helpful, and as constructive, and as responsive to my concerns. i do appreciate your reply, on that note. thanks.
Sm8900… WP:NOR is less about which sources we use than it is about how we use them. Wikipedia is a tertiary source. Our job is to summarize what others have said, and not to say original things. When we give examples to support a conclusion, we need to show that at least one reliable source reaches the same conclusion using those same examples. Otherwise, we are stating something original. Teratix is correct in saying that the policy is working as intended. Blueboar (talk) 16:47, 13 August 2024 (UTC)[reply]
Like was pointed out above, newspapers usually are secondary sources. The issue here is that you're using them to cite something they don't technically say.
My suggestion is to just be very precise in your phrasing. To draw a sweeping conclusion you need a direct source for that, but you can definitely source "Many prominent politicians regarded the war as ..., such as X, Y, and Z" with sources quoting X, Y, and Z. Loki (talk) 17:11, 13 August 2024 (UTC)[reply]
I think news articles are usually primary sources. Most news articles, if you actually pick up a paper copy and count them up, are very short and say little more than "An event has been planned" or "Someone got arrested for drunk driving" or "A routine government meeting happened". WhatamIdoing (talk) 20:45, 13 August 2024 (UTC)[reply]
What's more important here is to say that newspapers are usually reliable sources – they're just not appropriate for picking random quotes out of (or cherry-picking quotes that support a preferred POV). As WP:RS says, " Each source must be carefully weighed to judge whether it is reliable for the statement being made in the Wikipedia article and is an appropriate source for that content." An appropriate source for the views of various countries or groups for a war that started more than 20 years ago is going to be a book or a scholarly work. WhatamIdoing (talk) 20:49, 13 August 2024 (UTC)[reply]
A book or scholarly work is usually going to be more appropriate. That's very different to a different type of source always being inappropriate. It depends on the specific claim that the source is being used to support. Thryduulf (talk) 21:23, 13 August 2024 (UTC)[reply]
Again… The NOR policy is not about whether we can use newspapers (or any other type of source), but about how we use them. A source can be used appropriately in one context, but be used inappropriately (in a way that violates this policy) in a different context. Blueboar (talk) 17:52, 13 August 2024 (UTC)[reply]
if you mean my proposal for that specific article is flawed and needs some work, point taken, and no argument there. thanks! Sm8900 (talk) 17:07, 13 August 2024 UTC)
Thank you, User:Teratix, for the clarification. Having read the Talk:Iraq War discussion I couldn't understand the reactions of the other participants in this Village Pump discussion. Even after Sm8900 basically told on themselves. Schierbecker (talk) 20:17, 13 August 2024 (UTC)[reply]
possible new subsection for ideas, options, conclusions
A long discussion like this one might benefit from a new subsection, for ideas or conclusions from those who agree on the need to refine our approach to wp:OR in order to allow greater openness to usage of reliable newspaper articles as sources. Also, if they wish, the commenter could indicate their position separately on whether wp:OR needs actual revisions or not. By the way, I am glad to also note and mull over the comments above against my ideas as well. however my main thought here is to compile ideas and options for any positive changes desired. any such proposed ideas would still be fully open for discussion.
Obviously i have no basis for making rules on any comments here, no matter what the topic may be. It's just a thought on how the subsection might be set up. I may set up this new subsection, once some time has elapsed for further comments in the existing discussions above.thanks. --Sm8900 (talk) 13:55, 16 August 2024 (UTC)[reply]
Content assessment tweaks
Since Content assessment was decoupled from individual WikiProjects, I'd like to develop an idea regarding how it can be tweaked. Currently assessments for Stub-class to B-class can be placed on a talk page by any editor, but the manner in which reassessment is done can be a little tricky. If an editor wants to have their article reassessed (such as moved up from Start to C class), where to do this is currently a little convolluted.
This can be asked on the article talk page, but most talk pages on Wikipedia are will not yield a result, as they are either empty or inactive or both. Or it can be asked on a WikiProject page, which is still not a guarantee of getting it answered (also, might defeat the point of unlinking content assessment from WikiProjects in the first place). Or it can be asked on Wikipedia:WikiProject Wikipedia/Assessment – which doesn't make sense technically. Surely WikiProject Wikipedia/Assessment should be about articles relating to Wikipedia, instead of acting as a general catch-all page as it currently does.
My question is – how could this be optimised? For example, should assessment requests be moved to one centralised location? If so, where? Hope village pump can help me here DimensionalFusion(talk)15:44, 10 August 2024 (UTC)[reply]
Other than promotion to GA or FA status, very few editors pay attention to article assessments… so we don’t actually need clear cut criteria or a process for assessment. We can rely on editorial judgement.
If you think an article should be assessed as being in a certain “class”, feel free to mark it so. If someone else disagrees, discuss it on the article’s talk page. Blueboar (talk) 16:11, 10 August 2024 (UTC)[reply]
Yes, and marking an assessment totally independently, without any input from others is and would remain a valid way to assess an article. However, some people may not wish to do this and may want to have an uninvolved editor look at the page. This is the problem I would like to address DimensionalFusion(talk)16:17, 10 August 2024 (UTC)[reply]
(edit conflict) If there is benefit in an editor being able to request someone else take a look at an article and seeing whether they think the quality assessment is correct then I can think of two approaches that might work:
A central location in which to ask.
A template that can put on an article talk page that populates a category.
In both cases WikiProject article alerts should be generated to aid discoverability by editors interested in the relevant topic area.
Whether there is benefit in such a system is a different question, but I think the answer is yes. Even if it's optional in most cases, someone who was heavily involved in rewriting the article or who has a COI with regard to the subject or who is a declared paid editor may want to (in the latter two cases probably should) ask for another editor's opinion. Thryduulf (talk) 16:20, 10 August 2024 (UTC)[reply]
If I come across an assessment that is clearly wrong on an article I am involved with, I simply edit out the assessment. By means that are completely mysterious to me someone eventually comes along and (re)assesses it. Thincat (talk) 10:17, 11 August 2024 (UTC)[reply]
@DimensionalFusion I think @Thincat is saying that if an article they are involved with is rated as e.g. start class but they believe that is clearly wrong they will simply remove the assessment rank, meaning the formerly start class article is now unassessed class. In their experience these articles then get a new rating (that presumably more closely matches their opinion) from somebody else without any additional input from them (i.e. they make no requests anywhere). They don't know how the people who do the new assessment become aware that this needs doing (although my guess is that they're patrolling e.g. Category:Unassessed United Kingdom articles). Thryduulf (talk) 10:39, 11 August 2024 (UTC)[reply]
In my experience that doesn’t tend to lead to articles being reviewed, either because it is a broad topic (leading to a huge backlog) or because it has a very inactive wikiproject DimensionalFusion(talk)10:51, 11 August 2024 (UTC)[reply]
DimensionalFusion, content assessment between "stub" and "GA" is meaningless. No one is likely to respond to a request to reassess article quality unless you're taking it through a formalised peer review process, and editors interested enough in the topic would likely respond better at any centralised venue to a generic hey I just created / expanded Topic; improvements welcome than to a request for reassessment.If you're not comfortable changing the assessment rating yourself on articles you've significantly contributed to, turn on WP:Rater in Special:Preferences, and use whatever it suggests with the default edit summary. If you want other editors to take a serious look at your work, take it through WP:GA. Folly Mox (talk) 14:52, 11 August 2024 (UTC)[reply]
If content assessment between "stub" and "GA" is meaningless then why does it exist at all?
Anyway, for people who know that an article does not meet GA standards but want it to be looked at/rated by another editor, if only for 15 seconds, would create a massive waste of time in taking it to GAN as you suggest, which already has a massive backlog. One of the ways to reduce that backlog would be to improve the process for content assessment, no?
As someone mentioned below, they're mostly an historical artefact, leftovers from the days when WikiProjects roamed still. I don't know why we still have them. My apologies if it seemed like I was recommending taking a known sub–GA-quality article through GA. I miscommunicate sometimes. What I meant is that other editors are not likely to invest significant time reviewing work that the primary contributors have not already invested significant time into.We might not be seeing eye to eye on this because I'm experiencing disagreement with your problem statement. To me, reassessment has never felt tricky: if I've improved an article and notice its rating feeling out of sync, I'll update it. Also the notion of a venue where someone might be guaranteed a response doesn't feel in alignment with the state or ethos of the project.I suppose you could just remove the rating on articles you've recently improved, which should lead to someone else assessing them eventually. Folly Mox (talk) 18:29, 11 August 2024 (UTC)[reply]
How soon will eventually be though? As far as I'm aware, the Citation needed category for example hasn't led to many articles having citations added
Recent backlog drives at WikiProject Unreferenced articles and WikiProject Reliability have used maintenance categories to improve the project, but it really does seem like that kind of organised effort is what it takes to budge the needle even a little bit on highly populated maintenance categories.At some point last year WikiProject Stub improvement was reactivated to expand stub-class articles, which didn't last long since there were an overabundance of false stubs. I blame myself for rating some of these upwards out of the stub categories without significant expansion.I don't have good anecdata for routes to GA, but I don't think I've ever heard of anyone taking an article there on the basis that it was already B-class. I have seen B-class used in guidance once or twice, like at H:YFA, where newcomers modeling their first article on existing examples are advised to make sure their model is at least B-class.As to my eventually above, that's difficult to predict, and I don't have time at the moment to look into how long articles remain unassessed, nor even how to formulate a method of checking. Late for work, Folly Mox (talk) 11:34, 12 August 2024 (UTC)[reply]
Given the amount of outrage declared paid editors doing anything that could be seen as advancing the interests of their employer (regardless of whether this aligns with Wikipedia's interests) causes among some sections of the community, I think some method of requesting an independent assessment is warranted. Personally I don't see them doing this as an issue at all, but I recognise my views regarding paid editing are a lot more relaxed than the average. Thryduulf (talk) 12:05, 11 August 2024 (UTC)[reply]
If a paid editor has contributed significantly to an article, should they be allowed to change the rating of that article themselves? As I say I don't have a problem with that (as long as it's not to GA/A/FA, but that applies to everyone) but given how controversial paid editing is I suspect some people will have a problem with it. Thryduulf (talk) 12:48, 11 August 2024 (UTC)[reply]
Given that there is absolutely NO BENEFIT to be gained from changing an article assessment from “Start” to “C” (or even “B”)… why would it matter if the changer was paid to do so? Blueboar (talk) 13:19, 11 August 2024 (UTC)[reply]
@Blueboar If there is "absolutely no benefit" why do we have three different ratings? Is telling a client you improved their article from "C" to "B" not a benefit?
@Gawaon neither paid editing or content assessment is a "problem", I think you're misunderstanding this discussion. The question being asked in this discussion is "Should there be some central location or other method for editors to request a different editor re-assess the quality of a given article?" This cannot be answered without answering the question "Is there a reason and/or benefit to requesting another editor do this rather than just doing it themself?". My view is that the answer to the second question is "yes", giving a paid editor as one example scenario of when it would/might be better for another editor to do it. Paid editing is controversial (imo way more controversial than it should be, but that's beside the point) but it is not, in and of itself, a problem. Content assessment is not a problem, but an individual editor reassessing the quality of their own work might be a problem in some circumstances. Given that such circumstances exist, I see benefit in their being a way to avoid the problem. Thryduulf (talk) 13:33, 11 August 2024 (UTC)[reply]
It's like Blueboar says: Ratings are a hint to other editors, our readers will in general neither see nor care about them, and the payer probably won't either. Gawaon (talk) 13:44, 11 August 2024 (UTC)[reply]
Thryduulf- To be blunt, we don’t need all these ratings. The original intent was to help wikiprojects figure out which articles needed the most collaboration (we would focus on high “importance”, low “quality” assessments first).
However, as more and more wikiprojects became moribund, the ratings system became increasingly irrelevant. They are now little more than an ego boost (it’s nice to think that you improved an article to a “higher” level). Blueboar (talk) 15:00, 11 August 2024 (UTC)[reply]
I don’t care enough either way but if I could; I would simplify assessments to Stubs, Start, GA, FA. I have never ever used B, C, A classes. If an article can be improved, then do it! These debates about their classes could be better spent on improving the content however much or little. ~ 🦝 Shushugah (he/him • talk) 15:40, 11 August 2024 (UTC)[reply]
Folly, thanks for the link. I note that the 2021 discussion focused on GA and FA… while this discussion seems focused on the lower assessments (Mostly “c” and “b” class). Blueboar (talk) 16:25, 11 August 2024 (UTC)[reply]
Only big and active WikiProjects like MILHIST use class A. IMO it's good that B-class exists as it has actual, tighter criteria, and the banners always give tick marks for which specific criteria need improvement. I do agree that there need not be a centralized, stringent discussion forum for these ratings. They are not supposed to be formal, and I agree with Blueboar. The assessments are working as they should. Aaron Liu (talk) 17:20, 11 August 2024 (UTC)[reply]
I agree that assessments in their current form are not working as they should. Rating an article as GA or FA gets that article more recognition as they get a topicon, and can be featured in DYK or today's featured article.
Rating an article as A-Class, B, C, Start, or Stub does... nothing. Originally they alerted WikiProjects as to how much an article needs improving but since WikiProjects are no longer giving out ratings this seems irrelevant. Which leads to the obvious question – what is the point of content assessment? But that discussion is most likely out of the scope of this idea lab.
The ratings provide the exact same information regarding article quality to Wikiprojects as they did before. The change to a single rating did not affect their Wikiproject functionality, all the categories etc. still work. CMD (talk) 16:44, 11 August 2024 (UTC)[reply]
The big question is – does content assessment, through wikiprojects or otherwise, help improve Wikipedia? Because from personal experience, lots of wikiprojects seem to not actually undertake coordinated efforts to improve articles, much less using content assessment to do so.
It certainly helps at the upper end (GA and FA)… I don’t think the lower end (from Start through B class) is of much use. However, it doesn’t harm anything to have these levels… so… meh. Blueboar (talk) 17:17, 11 August 2024 (UTC)[reply]
Right, it's not a big question as we know the answer already. They're there if someone wants to use them; if they don't want to use them, no harm done. CMD (talk) 17:19, 11 August 2024 (UTC)[reply]
We have a single long-standing set of criteria defining each assessment rank that has been pretty consistent over time. Editors apply these based on their best interpretation, up to and more or less also including GA. CMD (talk) 17:49, 11 August 2024 (UTC)[reply]
For the people who don't know about our content assessment processes:
The most important level is B class This is implicitly the minimum requirement for DYK and ITN.
GA is B class with a review It is, like Start, C and B, a low level. Since the review is conducted by only one editor, YMMV.
Our highest level is A class This involves reviews by multiple editors from a project.
FA is similar to A class, but reviewers are drawn from all projects. However, unlike all the other levels, there are limits on the articles that can be submitted.
DYK requires Start-class (because their minimum length exceeds a stub).
@Folly Mox (and others), these ratings are primarily for the WP:1.0 team, which uses them for offline/curated releases. The difference between Stub and GA is important to their algorithm. They consider factors like popularity, centrality (=incoming links), and WikiProject ratings (i.e., to identify articles that humans say are important but that otherwise might be skipped). All else being equal, an article with higher ratings in terms of either quality or importance/priority is more likely to make the cutoff. Most of that group's work is coordinated off wiki these days, but AIUI they are still active.
Most of the time, anything well-cited is gonna be B-class, though it could be C-class or start-class if it's short. While ITN doesn't have this criterion, DYK's length criterion means it's usually B-class. Aaron Liu (talk) 01:18, 13 August 2024 (UTC)[reply]
Only 1,500 character are needed, so that's actually most relevant to the B-class criteria DYK is likely to miss (The article reasonably covers the topic, and does not contain obvious omissions or inaccuracies). DYK articles are expected to be well cited though, and being well-written comes from the attention, so most of the other B-class criteria are met in some way. CMD (talk) 14:51, 14 August 2024 (UTC)[reply]
Redirects to Film categories
For context, I am primarily an editor in the Simple Wikipedia, although I occasionally edit here. Many Wikipedia readers and editors switch to Simple Wikipedia by changing the domain from "en" to "simple", and back. This works well until you get into categories involving films. In simple wikipedia, "films" are referred to as "movies". In English Wikipedia, the only redirect that redirects you from "movies" to "films" is Category:Movies. I wonder if it would be possible or even a good idea to create every related Film category and create a Movie redirect page for it. For example, Category:1942 movies would redirect to Category:1942 films. This would also go for any templates, articles, etc., that would be related. I think this would be a good idea since this is an often enough redirect target, and the words are basically synonyms. I would also wonder if there is a way to automate this. Thank you. MrMeAndMrMeTalk04:14, 11 August 2024 (UTC)[reply]
From anecdotal experience, most people do not know how to edit the URL bar. To go to a site like YouTube.com, they'd Google YouTube even though there's a YouTube suggestion that pops up before they hit enter. I doubt that changing the domain is the primary way of switching against Simple Wikipedia.I'd recommend using the language switcher (文A at the top of the screen) to switch between these wikis; after a while of switching with it, the switcher will pick up that you primarily switch between these wikis and put the targets under "suggested languages". Aaron Liu (talk) 13:50, 11 August 2024 (UTC)[reply]
While this may be true in some aspects, that is a very broad and unreasonable assumption of many It is still a very common and reasonable way to switch between wikis. In any case, “movie” is a reasonable redirect for anybody to search up. MrMeAndMrMeTalk14:53, 11 August 2024 (UTC)[reply]
Naming convention for Uzbek names
Although thirty years have passed since the government of Uzbekistan decided to switch to the Latin script, the use of Cyrillic remains widespread, and the Latin script in use is widely considered inadequate to say the least. There's growing pressure to change it, particularly the letters Oʻ/oʻ and Gʻ/gʻ which are particularly problematic. However, so far no political will has materialized.
On Wikipedia, Uzbek names present many challenges, which I discuss in some detail below. Maybe this discussion will lead to a naming convention, which would be quite helpful. I can't start drafting one yet, as I don't have all the answers. Maybe after discussing the issue here, a task force could be put together to start drafting a proposal.
Distinct characters
Google's Uzbek keyboard uses U+02BB ʻ / U+02BC ʼ
The letters Oʻ/oʻ and Gʻ/gʻ (and the tutuq belgisi ʼ denoting a glottal stop or a long vowel) are a nightmare (See Uzbek alphabet#Distinct_characters). Basically, while it's clear that the straight English apostrophe should not be used, there is no official guidance on whether U+02BBʻMODIFIER LETTER TURNED COMMA / U+02BCʼMODIFIER LETTER APOSTROPHE or U+2018‘LEFT SINGLE QUOTATION MARK / U+2019’RIGHT SINGLE QUOTATION MARK should be used to properly render these two letters and the tutuq belgisi.Unicode.org states the former should be used. The Uzbek Wikipedia also favors U+02BB/U+02BC, and Google's Uzbek keyboard uses these characters.
However, Uzbek sources often use both—sometimes within the same text—and some do not distinguish between the modifier letter turned comma and the modifier letter apostrophe, instead opting for the straight English apostrophe, which is incorrect. Here's an example of an unfortunate Uzbek name that contains both problematic characters:
The question is: should we, like on the Uzbek Wikipedia, formally agree on which pair of characters to use in Uzbek words? I've been using U+02BB ʻ / U+02BC ʼ, but other editors might be using, or may have already used, U+2018 ‘ / U+2019 ’ instead.
On a related note, when a new page is created here on enwiki, the U+02BB/U+02BC pair poses no challenges. However, if the article is misspelled, as in the case of Yodgor Sa'diyev, moving it becomes impossible. "Yodgor Sa'diyev" is clearly wrong: reliable Uzbek sources use both U+02BC (Kknew, Zamin; Ministry of Internal Affairs) and U+2019 (Daryo, RFE/RL's Uzbek Service, Xabar), but not the English apostrophe. The handful of English sources that I could find on Yodgor Saʼdiyev use the Romanization of his name in Russian (Yodgor Sagdiev: Uz Daily) or a mix of his Uzbek + Romanized Russian name (Yodgor Sagdiyev: President.uz)! Since there is no single variant used in English sources, I decided to move the article to the Uzbek Latin spelling. (Although, as mentioned above, there isn't one standard Uzbek spelling, but this still seemed the best option.). However, when I tried to move the page to Yodgor Sa’diyev (with U+02BC), the following error popped up:
The page "Yodgor Sa'diyev" cannot be moved to "Yodgor Saʼdiyev" because the title "Yodgor Saʼdiyev" matches an entry (?!(User|Wikipedia)( talk)?:|Talk:)\P{L}*\p{Latin}.*[^\p{Latin}\P{L}ʻ].* <moveonly> # Latin + non-Latin on the local or global blacklists. If you believe that this move is valid, please consider requesting the move first.
When I tried to move it to Yodgor Sa’diyev (with U+2019), I got the following error:
The page title that you have attempted to create contains a right single quotation mark (’) Unicode character. Per MOS:STRAIGHT, such characters should not normally be used in page titles. Please replace it with a standard apostrophe, or a modifier letter turned comma (ʻ) or modifier letter apostrophe (ʼ) character if appropriate, and try again. If you got here by clicking on a red link in an article, you should go back and fix the link first.
Talk about a Catch-22! When there are no English sources and it's appropriate to use the Uzbek spelling, what should I do if I cannot move a misspelled page name due to the technical issues mentioned above? Should I request a name change every time I encounter an Uzbek word wrongly spelled with the English apostrophe, or can we make an exception for Uzbek names to facilitate moving articles?
As a page mover, I should be able to move over the title blacklist, so asking at WP:RM/TR could be an option. However, I notice the page has already been moved in the past, so maybe it is best to discuss it first. On that note, if you end up having a lot of them to request and consensus is that they should indeed be moved to the modifier letters turned commas/apostrophe, asking for the page mover right yourself could also be an option. Chaotic Enby (talk · contribs) 20:00, 11 August 2024 (UTC)[reply]
Romanization through Russian
Since Soviet times, Uzbek names have tended to be crudely transliterated into Russian, especially in official documents such as passports. As you can see in the table above, Йўлдош Аъзамов (Yoʻldosh Aʼzamov in the modern Latin script) was written as Юлдаш Агзамов in Russian, and English sources relying on Russian transliterate it as Yuldash Agzamov (see the table above for sources).
Per WP:COMMONNAME, we should generally use the most commonly used English spelling ("as determined by its prevalence in a significant majority of independent, reliable, English-language sources"). Are sources in broken English, like the ones mentioned above, sufficient for this purpose? While the current policy states "When there is no single, obvious name that is demonstrably the most frequently used for the topic by these sources, editors should reach a consensus as to which title is best by considering these criteria directly", it would be helpful to have a general policy for such cases, as most Uzbeks have multiple names, and the Romanization of Uzbek names through Russian is unlikely to stop any time soon.
Listing all the different spelling variants
When a given entity has many different names, it's helpful to list them in the relevant entry. Over the years, I've variously formulated the existence of different spellings while creating content here on enwiki. For instance, in Yoʻldosh Aʼzamov, I wrote:
Yoʻldosh Aʼzamov (sometimes spelled Yuldash Agzamov in English) (Uzbek: Yoʻldosh Aʼzamov, Йўлдош Аъзамов; Russian: Юлдаш Агзамов; May 10, 1909 – June 16, 1985) was...
In the recent entry on Olim Xoʻjayev, I added the following footnote:
Uzbek Cyrillic: Олим Хўжаев; Russian: Алим Ходжаев, romanized Alim Khodzhaev.
There are also Uzbeks like Hamza Hakimzade Niyazi who almost exclusively wrote their name in the Arabic script, and there are many reliable sources that use his name in the Arabic script. This complicates things even further. Is it best to specify all the various spellings in the lead section, or is it better to list them in a footnote? Either way, how should I word it so that it doesn't get too clunky but at the same time lets the reader know that multiple spelling variants exist? It would be really helpful to have some sort of rule of thumb for such cases.
P.S. I create redirects from all the known spellings to the main entry whenever I can. While I haven't encountered any issues on this, a future naming convention should probably have some guidance on redirects as well. Nataevtalk19:18, 11 August 2024 (UTC)[reply]
Central hub for WikiProjects
I think there should be a central hub for WikiProjects which would provide a space for editors to collaborate on all topics (yes vanilla wikipedia is a collaborative project but note that some editors are more open to collaboration whilst others prefer to work independently, this taps into the former). At the moment WPs are isolated from one another, and collaboration is often limited to within a single WP, when most articles have multiple WP banners and scopes overlap. This central hub could be called something like WP:WikiProject Hub and incorporate the directory (unsure whether WP:WikiProject Council would be best kept technically separate). It could have a resource that people could submit articles to that they would like to collaborate on (eg. most recent at the top, off the list after 2 weeks) and users could filter out/in WikiProjects technically based on the WP banners. I'm sure there's lots of other resources and uses it could provide that I can't think of right now Kowal2701 (talk) 20:08, 12 August 2024 (UTC)[reply]
I would suggest you could call it "WikiProject Cafe." that's a word which easily lends itself to this use, and yet has not been used for actual items here, so far. Sm8900 (talk) 20:19, 12 August 2024 (UTC)[reply]
It'd be like an actual WikiProject, and other WikiProjects would sort of be sub projects of it. I don't know whether WP:WikiProject Council would be best kept separate as a sort of regulator and help hub while this would strictly be for collaboration on articles etc. Kowal2701 (talk) 20:25, 12 August 2024 (UTC)[reply]
oh. well ok, but sorry that sounds overly broad. i don't really see a role for that. sorry.if you want to see why an overly generalized wikiproject might not work, please look at WikiProject History. let me know what you think, if you want. Sm8900 (talk) 20:27, 12 August 2024 (UTC)[reply]
all WP:HIST needs is taskforces for different regions and periods. I really think the lack of collaboration between projects hurts wikipedia and there's a lot of potential here Kowal2701 (talk) 20:31, 12 August 2024 (UTC)[reply]
I'd be happy to, although not sure about the best approach and I'm wary of wasting people's time. Do we immediately ping people to a discussion about taskforces with minimal initial comment or do we make a fleshed out proposal and then ping everyone? Kowal2701 (talk) 20:36, 12 August 2024 (UTC)[reply]
in general, it's neither. you simply create the task force with like-minded editors, in areas that you yourself would be interested in editing. that's not an official rule or method, in any way; it is simply my own personal opinion. Sm8900 (talk) 21:07, 12 August 2024 (UTC)[reply]
there're already taskforces for each continent, is it not just about reviving those and maybe merging WP:WikiProject European history into a taskforce? If people support it, we should probably discuss it with the people at WP Council, they've expressed similar ideas Kowal2701 (talk) 21:12, 12 August 2024 (UTC)[reply]
It's got over 300 members, if it were to be reorganised all could be pinged to a post which lists the taskforces, and hopefully enough would engage with them to keep them all sustainable Kowal2701 (talk) 21:30, 12 August 2024 (UTC)[reply]
@Kowal2701, sorry but there is no practical benefit to doing so. editors generaly edit whatever topics inteest them at the moment. there is little to be gained by organizing a whole lot of task forces which no one is already showing an interest in, actually. Sm8900 (talk) 21:32, 12 August 2024 (UTC)[reply]
I disagree, editors often have narrower interests than just history, which makes WP:HIST too broad like you said. If there was a push to organise the project around taskforces I think enough people might be inclined to engage with them especially considering only a small proportion of the large membership would be needed. I think it's worth a go rather than leaving it semi-active/inactive Kowal2701 (talk) 21:42, 12 August 2024 (UTC)[reply]
I’d assume 150, but with the taskforces that don’t get off the ground we could just message contributors. Idk, it entirely depends on whether there’s appetite for it Kowal2701 (talk) 06:42, 13 August 2024 (UTC)[reply]
@Kowal2701, can you describe your idea in concrete terms, with examples?
I can't tell if this is "I want one group of editors to be in charge of all the other groups of editors" (a WP:WikiProject is a group of editors) or if this is "I want a multidisciplinary group of editors". WhatamIdoing (talk) 21:24, 12 August 2024 (UTC)[reply]
No this is nothing to do with authority or even a group of editors necessarily. It's a restructuring of the wikiproject system. Think of a tree diagram where you have
To serve as a central place for collaboration on Wikipedia. Where people can collaborate on topics without a WikiProject. A place where WikiProjects can collaborate with one another. To macro manage WP’s coverage. Where WikiProjects can notify people of initiatives etc. To foster collaboration and make a healthier culture. I’m sure there are other uses. I think the resource mentioned in the initial post might be a good core idea. Kowal2701 (talk) 06:36, 13 August 2024 (UTC)[reply]
There are basically no topics that don't fall within the scope of an existing WikiProject.
If "macro manage" means "tell people that we need more articles about X or fewer about Y", then it's doomed because we're WP:VOLUNTEERS, but the Village pumps serve that purpose. The Village pumps are also where groups can notify others of their initiatives; WP:VPM is usually the most popular for routine announcements.
Creating yet another forum for communication is not usually helpful. See https://xkcd.com/1810/ ("Chat systems") and think about the problem of walled gardens (a handful of pages/people end up isolated from everyone else, leading to drift) and local consensus (e.g., we declare our group to be the One True™ group for deciding whether Our™ articles get an infobox, and we make sure that nobody else gets notified about or invited to participate in these conversations, because Those Other Editors might disagree with us). WhatamIdoing (talk) 06:57, 13 August 2024 (UTC)[reply]
That makes sense, I think there’s some merit to it but there’s too many ways it could fail and it’d take a lot of community resources and time which might not be worthwhile. Tbh with you I just really like the resource mentioned in the initial post, if that could be incorporated into an existing page I’d be satisfied. People really like serendipity and this could provide that, and bypass the isolation of WPs. It is also entirely voluntary, people can submit articles they’re working on that they’d like more input in and others can choose anything that intrigues them. It sort of serves to direct people I guess Kowal2701 (talk) 07:09, 13 August 2024 (UTC)[reply]
That’s really great. Maybe another list/page with a list could be added which didn’t have nominations so anyone can add an article regardless of importance or page views and it stays on the list for a month and people can filter by WP banners? Kowal2701 (talk) 07:36, 13 August 2024 (UTC)[reply]
WikiProjects are groups of people, and you probably don't want to filter by "WhatamIdoing and her wiki-friends". If you'd like to be able to filter by topic area, then the WMF did some research a few years back, and found that articles could almost always be classified into a couple dozen categories under four main headings of Culture (includes biographies), Geography, History/Society, and STEM. See mw:ORES/Articletopic#Taxonomy for the full list.
It’s more you filter by topic area, so you if you’re interested in say 5 topics, you just filter for them, it’s not necessarily about collaborating with those WikiProjects but with people on the articles for improvement page. Those groups are good, but I imagine it’d be a lot easier technically to use WP banners as identifiers for which topics the article is a part of Kowal2701 (talk) 15:28, 13 August 2024 (UTC)[reply]
It would be nice if there were a way to surface articletopic at the article itself, or its talkpage, rather than only being visible through CirrusSearch and the Suggested Edits pane. Folly Mox (talk) 18:00, 14 August 2024 (UTC)[reply]
Merging mass-created village stubs into district articles
There are a lot of mostly formulaic (though that's not necessarily bad) stubs of villages with 60-100 people that will probably never be significantly expanded, at least beyond one or two events happening there. I know that under the the guideline on geographical features all inhabited places are considered to be notable, but what if very small villages were by default merged into district articles? I'm thinking of a section "Villages" or something similar with a subheading for each village and a few sentences with the population/location (what's already in the leads). Villages that had enough coverage to need their own article would be split; it could be done based on the categories "Rural localities in X district" that already exist.
For example, Basovo and Timonovo in Valuysky District, Russia. The second has 1 event happening there, and the 1st none listed; both are very small towns with a couple hundred people. It's possible Timonovo could be expanded with a description of the event, but that would be rather WP:1E-style and deserve its own article.
I'm posting this here because I don't know the history & policy details sufficiently to put it into proposals (or the 300-vote discussions), but I wanted to see what people thought and if this had been proposed before. Mrfoogles (talk) 04:00, 15 August 2024 (UTC)[reply]
It depends on what the guidelines are agreed to. I'd say if a location only cites census tables and maps (gonna use Hashemabad, Kerman as an example), they should be merged with the above-class subdivision. All these location articles only have maps and census tables, could possibly violate geographic feature Notability. Roasted (talk) 04:22, 15 August 2024 (UTC)[reply]
I would cautiously support this as long as it was done carefully so no information was lost, was explicitly without prejudice to later expansion and excluded places with significantly more extensive articles on another language wiki. Of the three places here, only Timonovo has more information elsewhere (ru:Тимоново (Белгородская область)) but that is borderline. My ballpark suggestion would be that any article with circa two paragraphs of prose of non-census information excluding a description of it's geographical location on any language edition of Wikipedia should not be merged in without an individual discussion. I'd also say that before any merge takes place there needs to be a list of all the merges proposed laid out in a fashion easy for humans to check (separate lists or separate sections for each destination article would probably work well). Thryduulf (talk) 10:25, 15 August 2024 (UTC)[reply]
I support the concept… Wikipedia should continue to cover all noteworthy geo locations, but we can be more flexible in how we cover them. Not all locations require a stand alone article to be included. Blueboar (talk) 11:49, 15 August 2024 (UTC)[reply]
The ru.wiki versions of the villages are not much longer unfortunately, and the length of the longer one comes from quite generic information that would likely apply to the district. Your method of merging to the district article sounds like one in which no information would be lost, although I would leave room for a bit more than what is currently in the leads. CMD (talk) 12:00, 15 August 2024 (UTC)[reply]
I doubt anyone will stop you but I think it's a waste of time. For some reason some editors have strong feelings about the existence of stubs vs. redirects to entries in lists but, from the reader's perspective, they're pretty much the same. I can't tell anyone how to use their time but if all the collective hours we've wasted on merging or talking about merging stubs were instead put into expanding them, the encyclopaedia would certainly be better off. – Joe (talk) 07:13, 16 August 2024 (UTC)[reply]
There's the rest of what I wrote, and if your counter-proposal is to treat the nav boxes as great article content then I don't think that's very helpful to the reader either. CMD (talk) 12:31, 17 August 2024 (UTC)[reply]
I might come to the same conclusion ("As a reader, they are not the same") but in the opposite direction: Hunting through a merged-up page to try to glean which info is relevant and which is about other villages takes up time. With a stub like Timonovo (five sentences, 75 words, five sources, plus the infobox), you know that all the information is what you're looking for, and you know that's all there is. WhatamIdoing (talk) 22:19, 18 August 2024 (UTC)[reply]
List articles don't have to be tabular data with no prose, nor do they have to be internally consistent as to whether or not the list items they contain are bluelinks or not. The GA Infrastructure of the Brill Tramway is basically a list article that contextualises borderline notable information beautifully.I should disclose that I'm strongly in favour of contextualising stubs into their container topics wherever possible. Folly Mox (talk) 16:18, 16 August 2024 (UTC)[reply]
Somehow I doubt the result it this will be a load of GA-level lists. It'll be the existing stubs, pasted in one after the other. – Joe (talk) 05:49, 17 August 2024 (UTC)[reply]
I agree that the implementation of contextualisation is likely to resemble pure concatenation, and would prefer that outcome to the status quo. JMO. Folly Mox (talk) 15:59, 17 August 2024 (UTC)[reply]
I was more thinking of a policy allowing people to merge such things if they felt like it: because there are so many village articles it's never worth it for any one person to start a discussion about merging the villages of one district, because who cares about this one random district in particular. And no one has the hours and hours you refer to to just go do it for all of them. With a pre-consensus it could ideally happen piece by piece? If there was a policy on this I might merge the villages of that district just because I ran across them, but I wasn't planning to spend 900 hrs on trying to do all of them.
As for expanding them: 60 people live in most of these village, and it's unlikely someone's written a book about most of them. Not going to say it's not a little bit of a waste of time, but having a list of villages in a district in its article seems useful: it was helpful to me finding some village list in district articles on the German Wikipedia I think when I was trying to figure something out. I think name+whatever small details exist could be somewhat helpful, if not the most important task. Mrfoogles (talk) 18:54, 16 August 2024 (UTC)[reply]
@BilledMammal put together a sample of 10,000 articles so we could try to find out some basic information about what the community's actual practices are – the revealed preference, if you would like to use that language, rather than the aspirational goals. So far, we're finding facts like these:
90% of articles have between 2 and 95 sentences, heavily skewed towards shorter articles. The most common number of sentences in an article is two. Half of articles have 13 or fewer sentences. A quarter of them have 5 or fewer.
If you define a stub as having ≤10 sentences, then 43% of Wikipedia's articles are stubs. If you define is as ≤250 words, then 41% of articles are stubs.
Half of all articles have 4 or fewer (detectable) inline citations. A quarter have 2 or fewer. Only 21% have more than 10. Having more than 20 (about 10% of them) is a statistical outlier.
Compared to longer articles, stubs tend to have about twice as many citations per sentence.
The reason I bring this up is because when we compare articles against our ideals, it's very easy to think "What garbage. It 'only' has five sentences. It 'only' has five sources. It 'only' has 75 words." We ought to be thinking "Huh, that has more sentences than 25% of our articles. It has more refs than 60% of our articles. It has more words than 16% of our articles. Maybe it's not too different from normal, actually." WhatamIdoing (talk) 22:40, 18 August 2024 (UTC)[reply]
I recently ran a new scan, of 100,000 pages, where the talk page categories are also provided. I’m not sure how to upload it yet - it’s a far larger dataset than all the others I’ve uploaded put together - but it should be helpful as it will allow us to determine which topic areas have abnormal articles.
I suspect that the size of places will vary by location. Most US census places have longer than median articles (e.g., Mulberry, Kansas has 25 refs and almost 1,000 words) but were largely written by bot/script.
I continuously see the word "former" before describing occupations in biographical articles. For example, Tiffany van Soest's article describes her as a "retired American Muay Thai kickboxer who competed in the bantamweight division". This feels redundant, as the past tense is also found in the word "competed".
I only find it helpful in cases when the person has other current jobs, such as in Ben Carson, which says "retired neurosurgeon" as he went into politics.
I say the use of the word "former", "retired" or others versions be banned to describe occupations, except for cases such as Carson's. Roasted (talk) 23:13, 15 August 2024 (UTC)[reply]
It's much less confusing than "was a kickboxer", which sounds like one died (knock on wood). If we make it "is an American Muay Thai kickboxer who competed in the bantamweight division", that sounds like they used to compete there but then moved on to other places. I don't see how this adjective can possibly be harmful. Aaron Liu (talk) 23:31, 15 August 2024 (UTC)[reply]
I agree with Aaron Liu, "former", "retired" and similar are usually unambiguous accurate descriptions that are clearer than omitting them. There might be exceptions in individual cases, but as a general rule they are more good than harmful. Thryduulf (talk) 00:25, 16 August 2024 (UTC)[reply]
The use of former is often used to push a POV in BLPs such as: "Jayle was is a convicted fraudster and former businesswoman". These things are arguably true, but a more neutral way to state it is "Jaylee is a businesswoman who was convicted of fraud". It avoids the name calling, "fraudster"; and makes no crystal ball guess what the future might hold for Jaylee, who might continue to have a career in business, after she serves 10 years in jail. The use of "former" is a dig over her downfall. So yeah I would agree that "former" can be a loaded term and is usually unnecessary. Another hypothetical example: "91-year old Jaylee is a former skydiver, former book author, former model, former Olympic swimmer and currently a painter." Ugh. Please no. -- GreenC01:07, 16 August 2024 (UTC)[reply]
I don't see any problems with your last example except for the fact that some of these formers are probably way more important than others, for which we already have existing guidelines that say that only the most notable occupations should be included. I also don't see how one could be a former businesswoman. Aaron Liu (talk) 02:38, 16 August 2024 (UTC)[reply]
You can stop running a business, just like you can quit any other career. Some people might interpret "is a businesswoman" as meaning that she's running a business right now, which, in the specific case of "a convicted fraudster" might not be compatible with their legal situation. If the BLP in question has been barred from certain business activities (e.g., being a director or officer of a publicly traded company) under the Sarbanes–Oxley Act or similar legislation in the relevant country, they might even consider it harmful to be described as a current businessperson. WhatamIdoing (talk) 22:48, 18 August 2024 (UTC)[reply]
(edit conflict) I don't think the former reads that way in your first example, I wouldn't assume someone with a conviction can't do business. The fraudster use is a separate issue, "former businesswoman convicted of fraud" uses both. ("Businesswoman" is a bit vague I suppose, which makes the example tricky.) CMD (talk) 02:47, 16 August 2024 (UTC)[reply]
Ultimately, what we ought to do is describe subjects the way the sources describe them. If sources generally describe someone as a "former XYZ" then we should to. That said, the lead does also have some degree of leeway to paraphrase and summarize (since it's trying to summarize the entire article); in some situations it's fairly uncontroversial to describe someone's previous roles in the past tense, especially when the ending is unambiguous - for example, former elected / appointed officials. Even then I think it's more commonly worded as eg. "was the secretary of whatsit under whosit" but I wouldn't support a hard-and-fast ban on "former"; it has to be decided on a case-by-case basis, like most things. --Aquillion (talk) 03:02, 16 August 2024 (UTC)[reply]
Past tense is not used in many areas of Wikipedia, such as TV programmes that are no longer made where the word "was" gives the reader straight away that it is no longer made, but the MOS says we cannot use it. I think "former" is acceptable in my eyes, as it what the "normal" world outside of Wikipedia would use, however common sense and this place doesn't always meet. Davidstewartharvey (talk) 05:16, 16 August 2024 (UTC)[reply]
Sure, if we understand how to, and if repairing them there for our project doesn't break them for other projects. I've never tracked an error to Wikidata that I was able to repair myself. Sure, I'm pretty incompetent technically, but so are most of us, and Wikidata is inscrutable and seems poorly documented to those of us who interact with it only infrequently. Folly Mox (talk) 16:07, 17 August 2024 (UTC)[reply]
WikiData can only support one such style. So if you fix Wikidata to match Article A, you break Article B. If you fix Wikidata to match article B, you break article A.
Headbomb {t · c · p · b}23:47, 18 August 2024 (UTC)[reply]
As said at Template:Cite Q#Workflow, that seems like an easy fix: Wikidata already has an easy way for dealing with this through the "object named as" property.
Which is the most convoluted asinine process that defeats the purpose of "universal references". Use {{cite xxx}}, provide DOIs/ISBNs, let User:Citation bot expand the references, and then review the output for uniformity. You'll see directly in the edit window all the information provided, and can standardize everything in one go. Everyone gets to see things are uniform, and no one has to deal with the abyss that is {{Cite Q}}. Headbomb {t · c · p · b}03:30, 19 August 2024 (UTC)[reply]
How is it convoluted or purpose-defeating? You just add a "object named as" property to Wikidata, bam. It's just one step. If you really wanted to go all fancy, you could query the author names for the part that is the family name. Aaron Liu (talk) 04:13, 19 August 2024 (UTC)[reply]
You can use the "object named as" property to cause the reference to appear different ways on different articles? CMD (talk) 05:55, 19 August 2024 (UTC)[reply]
Maybe, in theory, if we take an infrastructure similar to Google Images and then do something complicated that does image recognition involving wikidata. But it hardly seems worth the effort. Cremastra (talk) 19:17, 16 August 2024 (UTC)[reply]
Rename and/or Combine Content Assessment classes
Currently Content Assessment is named arbitrarily at Featured, A, Good, B, C, Start, Stub. Looking for ideas as to what A, B, and C classes should be renamed? And if B and C classes were combined into one, what would that be named?
I would merge B, C and Start together and call them all "start". Anything checking criteria of article like DYK would not solely rely on WikiProject content assessment anyways. ~ 🦝 Shushugah (he/him • talk) 21:51, 18 August 2024 (UTC)[reply]
I’d definitely be opposed to lumping B and Start into the same bucket, the resulting rating would cover a really wide range in quality. There is a difference between “often not used and superfluous in many cases” and “totally unnecessary”. ― novov(tc)01:57, 19 August 2024 (UTC)[reply]
The names aren't really arbitrary. They're basically American letter grades, plus two existing review processes (FA and GA), the separate {{stub}} system, and a squeamishness about rating anything with a "bad grade". C is a relatively recent innovation; back in the day, it was realistically Stub–Start–B, and anything else required extra effort. In 2008, editors basically decided to divide the Start class into two groups (C and Start).
As a first approximation, we started with:
Stub: Less than ~10 sentences.
Start: More than 10 sentences but not yet B-class.
B class: Meets all six specified criteria.
and we decided to have:
Stub: Less than ~10 sentences.
Start: More than 10 sentences but still kind of short and not B-class.
I would consider using something other than the A-B-C convention. I noticed that an inordinate number of editors were adding A class to India articles. Apparently people think it's like self-grading a homework assignment. I think A-class should either become a universal process like GAR or FAR, or go away entirely. That I know about, only WP:MILHIST, WP:USROADS and WP:HIGHWAYS have a process to review A-class articles. WP:WikiProject Biography and Wikiproject Cyclones had a process, but the latter turned out articles that in no way represented the best of Wikipedia. Schierbecker (talk) 02:40, 19 August 2024 (UTC)[reply]
WMF
Copyright tool
One of our most important tools, Earwig's Copyvio Detector, depends on access to Google. According to the tool's creator and operator, The Earwig, the WMF has kindly been paying for this Google access. Unfortunately, we've been hampered by a strict limit on the number of searches allowed per day. The Earwig mentioned that there might be a way to work out a special arrangement with Google to increase the cap. Would someone at the WMF be able to pursue this?
In case it helps, this is a vital tool to a number of English Wikipedia processes, and it would surprise me to learn that the sister projects aren't using it as well. We use the tool routinely as part of our new page patrol, articles for creation, contributor copyright investigations, did you know, good article, and featured article processes. Historically, the WMF has taken a special interest in supporting volunteer work that focuses on our legal responsibilities, of which compliance with copyright law is an obvious example. Firefangledfeathers (talk / contribs) 01:34, 31 July 2024 (UTC)[reply]
My understanding is that Google has a hard daily limit of 10,000 API accesses per day for absolutely everyone across the board, without exception. User:Novem Linguae/Essays/Copyvio detectors#Earwig copyvio detector. My impression is that an exception wasn't possible because Google doesn't provide an exception to anyone. Earwig would know best though.
Earwig didn't ask me to do anything on his behalf. He mentioned that "the WMF pays for it, but Google's API terms limit our usage without some kind of special arrangement that I have been unable to get." This was at a discussion at his user talk. I wasn't sure who might be able to negotiate a special arrangement, and I'm not sure it's a possibility, but this was the best place I could think to ask. Firefangledfeathers (talk / contribs) 04:26, 31 July 2024 (UTC)[reply]
A bit odd that Earwig isn't doing the advocating himself, but on the linked user talk page, it does sound like he's asking for some help with this. Would The Earwig be willing to share his contacts at WMF that have helped with this in the past? Sounds like WMF pays for the tool, so there's some accounting/finance/grants contact that knows a little about it. And we also have partnerships people like NPerry (WMF) that I believe has worked with Google before. –Novem Linguae (talk) 04:43, 31 July 2024 (UTC)[reply]
From what I've heard, the WMF contact that Earwig had has since left the Foundation and wouldn't be able to help in this case. You are correct that WMF pays for the tool. I had mentioned this at the Hackathon with staff and it seems there's some resistance in getting the cost of extra tokens funded, although I'm unsure of exactly how the WMF's budgeting process works, so no clue on the impact it has in this situation (considering we don't have a Google liaison to begin with). Chlod (say hi!) 05:20, 31 July 2024 (UTC)[reply]
Even the name of a former WMF employee contact would be helpful. Let's get all this documented so we can start figuring out what WMF departments/teams have assisted in the past. –Novem Linguae (talk) 05:26, 31 July 2024 (UTC)[reply]
Hi all. Firefangledfeathers, thanks for starting the discussion. Novem, sorry if this thread came up a bit strangely. In truth, I struggle a little with motivation these days, so I really appreciate others' help getting the ball rolling. I am still here, though—it comes in waves. (It's also good to involve the community in the tool so the institutional knowledge isn't stuck with me.)
BTW, I am working on more effectively managing automated/excessive tool usage and will soon require OAuth to run searches (see this active thread on my talk). Right now the tool really doesn't have any usage guards or a way to limit individual users' activity, which isn't good when our resources are so limited. It's possible doing that will free up our resources a lot if a substantial fraction of our current usage is coming from malicious crawlers, despite Chlod and I's attempts at blocking them (the tool has been running for over a decade and it's never been this bad, though I have a theory what this is about). Even so, finding a way to increase our search quota will enable us to support some requested features that are current nonstarters, even if the tool's entire current quota could be devoted to it, like checking all new pages.
My main point of contact with the WMF in the past was Kaldari. The last time we spoke about the tool was 2020; since then, the situation has been unclear. (MusikAnimal, do you remember if we've spoken about this?) Last year Runab WMF and DTankersley (WMF) reached out to me to discuss the tool in the context of WMF efforts "to find ways to reduce single points of failure for tools that require a third party API", but after an initial conversation I haven't heard back aside from being told that Deb was moved to another project, so I'm not sure what happened with those efforts.
Frequently we've discussed adding an alternate search backend aside from Google. While Google is really the gold standard for breadth of search coverage, as far as I'm aware—and this is really what the copyvio detector needs, not necessarily quality/intelligence; people have suggested services like DuckDuckGo, but they're really unsuitable because they just republish raw results from Bing with some additional flair that is basically useless for us—something like Bing itself might work as an (automatic) fallback if we exhaust our Google credits for the day. I believe Bing has roughly equivalent pricing/usage limits as Google, but it's been a while since I've looked into it. And we/the WMF would need to establish a relationship with Bing for that to work; I don't know if that's a better idea than attempting to negotiate our Google limits. There are also other options like Yandex (which the tool did use one dark time in the past before the Google relationship and after Yahoo ended their free service... it wasn't great, at least for English results, but it's something that could be looked into for some other language projects, perhaps). Finally, there was a discussion on my talk earlier this year with Samwalton9 (WMF) about adding The Wikipedia Library as another search backend, and I did correspond briefly with someone at EBSCO about this, but again, I haven't heard from either of them about this in several months. — The Earwig (talk) 06:51, 31 July 2024 (UTC)[reply]
So the Google API proxy and the Google account it runs on are wholly part of Community Tech's budget. Kaldari was the contact in the past when they were my manager on CommTech. So the good news is Community Tech is still here, and we are actively maintaining this proxy (I just migrated it to a newer Debian a few days ago). The part that hasn't changed is our quota from Google, and sadly I doubt it will change. We are already paying hefty fines for the quota we have now, but I believe it is also correct that 10K is a strict limit from Google. I can see from the graphs in the API console that we almost always hit that limit within the first 12 hours of each day.
I am working on more effectively managing automated/excessive tool usage and will soon require OAuth to run searches … – that is most certainly the best immediate recourse for addressing this problem. From my years of shielding XTools from web crawlers, I can say with confidence that putting up a login wall by itself should make a big difference. I also think mitigating excessive and automated use is something that would probably be required before we could consider dishing out more money to Google. However again, I don't think such negotiations would get us anywhere anyway :(
As a general note, such "negotiations" are typically done these days via the Partnerships team. I went though them recently when we solidified our partnership with Turnitin. Speaking of which… do others find the "Use Turnitin" option of Copyvios at all useful? Because that's using the old Turnitin account (the new one can't be used outside CopyPatrol), and the last I checked there were still a few million credits left. — MusikAnimaltalk20:52, 1 August 2024 (UTC)[reply]
The Google API Proxy (docs at wikitech:Nova Resource:Google-api-proxy) exists solely to anonymize requests to the Google APIs, should they be used in a fashion that sends personal data such as your IP or user agent. As far as I know, Copyvios has always accessed Google APIs through this proxy.
I'm not aware of any sort of sliding scale as far as pricing goes, and my use of the word "hefty" was relative to my team. However since I made my reply above, I have been informed that the budget is actually not solely from Community Tech, as it was in the past (but we do still maintain the proxy). I don't have any details about internal accounting, I'm afraid. My apologies for any confusion caused. — MusikAnimaltalk19:48, 2 August 2024 (UTC)[reply]
Wouldn't the Toolforge tool itself serve as an anonymizing proxy as long as the Google API requests are being sent via a backend rather than via browser JavaScript? But that's a bit of a tangent :) –Novem Linguae (talk) 22:18, 2 August 2024 (UTC)[reply]
I'm willing to entertain alternate methods for anonymous users to access the tool. I do need some way to attribute usage to a human, though. Any suggestions? I might present a challenge page where you have to answer some question (essentially a CAPTCHA, but one that works without JS). Or I can require anonymous users request a token (that would be saved as a cookie so does not need to be entered with each request). — The Earwig (talk) 00:00, 10 August 2024 (UTC)[reply]
That's a good question, but I can't tell from the documentation whether temporary accounts are able to use OAuth. I would need to test it. (And we may need some other solution in the meantime, before that's deployed.) — The Earwig (talk) 14:25, 10 August 2024 (UTC)[reply]
I know nothing about what the "modern" methods are of telling bots and humans apart these days (besides knowing that CAPTCHAs are apparently broken: e.g. Table 3 in [6]), so I probably won't be able to provide many helpful suggestions. If we need to request a token from you, I for one would be okay with that if it's a one-time process, but would that be handled by an automatic system or by asking you for one manually—and if the latter, is there any indication how many anonymous editors (legitimately) use the tool so you won't be potentially flooded with hundreds of requests?
Another idea I had is making sure the requesting IP address' /64 range (if IPv6, or the address alone if IPv4) has made at least one edit to the Wikimedia site the Earwig request is for. I could easily be assuming wrong, but I would think there wouldn't be many cases where an anonymous user would want to check for copyright violations on a site they've never even edited before. This would admittedly require anonymous users to be on the same device they edit from to use the tool, but so would requiring a browser token. ...however, I don't know how technically feasible that is, and obviously someone malicious could just manually change their IP address (but would someone running hundreds of web crawlers go to that effort for every single one of them?). 2603:8001:4542:28FB:9566:5D77:1AC4:CB78 (talk) 18:47, 12 August 2024 (UTC) (Actual talk)[reply]
@The Earwig: OAuth is not available for temporary accounts. The T&S Product Team aims to make the experience with temporary accounts very similar to what IPs have now, which includes not having access to OAuth or user groups. @2603:*: For IPs, we don't have access to IP addresses on Toolforge, so we can't check on wikis if a specific Toolforge visitor's IP has made an edit on the wikis. Requesting a special token, as you've mentioned, is probably a better option to go for if we want to have anonymous editors keep their access. Since there aren't that many editors who do all of their edits on an IP, we shouldn't get too many requests for this. What should be decided is the minimum requirements for giving this access, and the criteria for revoking it (should we find out that an editor has been using a token maliciously). Chlod (say hi!) 05:44, 13 August 2024 (UTC)[reply]
Given IP addresses (and thus contributions) can't be measured by Toolforge, what prerequisites could even be measured? Or would the token-giving occur on a different site?
In terms of revoking, my knee-jerk thought is more than M requests in a minute or N requests in a day could cause the token to get revoked until the anonymous user interacts with a human to request it back. But A. I don't know if that's how things work with tokens and Toolforge, and B. I'd be curious to know what the already-established practice and limits for e.g. the Wikipedia API and whatnot are, to have some sort of a benchmark. 2603:8001:4542:28FB:C10F:60AC:578A:3F8 (talk) 22:48, 13 August 2024 (UTC) (Actual talk)[reply]
more than M requests in a minute ... could cause the token to get revoked You need to be careful with that. When I'm checking DYK queues, I check a whole set at a time, which means opening nine (or more) Earwig windows in a few seconds. RoySmith(talk)23:25, 13 August 2024 (UTC)[reply]
Feature updates from the Tech News: Stewards can now globally block accounts; Wikimedia site users can now submit account vanishing requests via GlobalVanishRequest; and interface of FlaggedRevs (also known as “Pending Changes”) is improved.
This month’s Wikimedia Research Showcase highlighted the impact machine translation has on both content and readers of Wikipedia and provided interesting insights on how to overcome related challenges. Watch the recording.
The Charts project officially kicked off. The goal of this new initiative is to restore basic data visualization capabilities to the wikis. Check out the project page and follow our progress on Phabricator.
The CampaignEvents extension is now available on Meta-wiki, Arabic Wikipedia, Igbo Wikipedia, and Swahili Wikipedia, and can be requested on other wikis. This extension helps manage and make events more visible. Learn about how to request this extension.
The Campaigns Product & Programs teams have launched a consultation on WikiProjects and other forms of collaboration on the wikis. They want to understand why they work (or don’t work) for some Wikimedia communities, and they want to learn what can be done to improve the experience. Everyone is encouraged to share their feedback.
The Board of Trustees selection pre-onboarding and campaign period is open from July 25 to August 26.
Foundation Trustee Dariusz Jemelniak was appointed to the Governing Board of the European Institute of Innovation and Technology, established as part of the EU’s key funding program for research and innovation.
I am an occasional user of SWViewer, a vandalism patrolling tool that is (in my understanding) partly maintained by the Wikimedia Foundation. I generall like its interface and design, and I have found it to be a useful tool.
I do have one item that I would like to discuss though: I think it would be wise to add a checkbox for whether or not to mark an edit as minor. Currently, the interface allows users to tick a box for "Use undo" when rolling back an edit with a summary. This is good, but it only allows users to revert edits in a way that is marked as minor. I understand that certain wikis, such as the English Wikipedia, have a very narrow understanding of what constitutes a minor edit, and there are times when I want to undo an edit but it is not technically a minor edit. This makes me have to manually go to the English Wikipedia and click the "undo" button there rather than keeping all of this in the SWViewer interface.
Is there a way that the WMF could either:
Not automatically mark edits made while "Use undo" is ticked as minor (i.e. submit them to non-minor edits); or
Allow users to select whether or not their actions are considered to be minor edits (via a tick box)?
Hi, I'm not WMF staff (although I am the Wikimedian of the Year) but I noticed something I thought should have wider community input. Please keep in mind that as far as I'm aware this is in very early stages and there is no guarantee that it will actually be implemented. Also, please be nice. I anticipate that some people will be surprised by what it was being proposed here so I felt like this was an important reminder. Anyways: mw:Wikimedia Apps/Team/iOS/Fundraising Experiment in the iOS App. There is a feedback section towards the end of you wish to give it. I have already commented there. Clovermoss🍀(talk)17:47, 10 August 2024 (UTC)[reply]
This is an example of what is being proposed. Essentially, there would be a donation button near the top right of an article and these would kind of be like Reddit trophies. I think this needs way more visibility than being buried in the depths of mediawiki which is why I'm posting here. Clovermoss🍀(talk)18:52, 10 August 2024 (UTC)[reply]
Hi @Clovermoss, it’s Haley from the Mobile Apps team! You’re correct that the project is in very early stages. We just recently published the project page and had planned to start outreach after Wikimania—that’s why folks might not have heard about it yet. In short, the idea is that we want to try out other ways of fundraising beyond just banners – hopefully ways that make readers and editors feel more connected to each other. But we know that fundraising ideas have to be considered carefully, which is why our goal right now is just to be in conversation with the community on high level concepts. We hope people will join the discussion on the project page. P.S. Congratulations on Wikimedian of the Year! HNordeen (WMF) (talk) 16:01, 14 August 2024 (UTC)[reply]
This should have been mentioned at the fundraising brainstorming page as soon as it was published. I object to the "gamification" aspect of giving money to people. I'm not sure how "donating from an article" is an improvement over just having a discrete "donate" button, which we already have. In conclusion: I think this is unnecessary.
Also here – is it THAT HARD to say "introduce", which is a long-standing, universally recognized word, rather than "onboarding" which is today's #1 corporatese-jargon? These things always make the WMF look bad, bureaucratic, corporate, and out of touch. Cremastra (talk) 17:06, 14 August 2024 (UTC)[reply]
@HNordeen (WMF): This is what I meant when I said at the page itself that this is likely to cause a public relations disaster. Imagine a thousand comments like this. Please understand that I really don't think this is a good idea and I don't say this because I wish you to fail but I wish to see everyone suceed. Clovermoss🍀(talk)17:13, 14 August 2024 (UTC)[reply]
I'll also note that the phrase "Microinteraction and confirmation snackbar." was used without apparent embarrassment to mean "a notification/confirmation box". The thing is, phrases like this are inaccessible, and make these pages harder to understand. Cremastra (talk) 17:17, 14 August 2024 (UTC)[reply]
While "microinteraction" definitely should've been left out, that's not a "box". "Confirmation box" sounds like a dialog for you to confirm. A snackbar can only be a small message that pops up from the bottom to tell you that the operation has been a success (sometimes with an ündo" button to the right). Aaron Liu (talk) 18:17, 14 August 2024 (UTC)[reply]
Sorry, what I meant by confirmation box was a box confirming that the operation worked. That is, it's sending you a confirmation, not the other way around. Cremastra (talk) 18:19, 14 August 2024 (UTC)[reply]
That's an important distinction for developers, but I think if the page is targeted to the general public, "notification bar" should suffice. Cremastra (talk) 18:46, 14 August 2024 (UTC)[reply]
I don't mean to sound like a complete crank, but this is, I think, part of the reason some or many editors react badly to WMF pages like this: they're sometimes hard to understand and come off as a bit condescending. I've WP:BOLDly toned down the language so that it's easier to understand for non-developers. Cremastra (talk) 18:12, 14 August 2024 (UTC)[reply]
I appreciate that my comment prompted you to reflect and tone things down a little. [7] I also know that your heart is in the right place too and that a lot of the time these comments are caused by a series of frustrating events and not feeling like one has been listened to. Feel free to tell me if I'm putting words in your mouth, Cremastra. I just know that HNordeen (WMF) is relatively new to the foundation and I don't want her to feel like all of this was directed at her personally. Clovermoss🍀(talk)18:19, 14 August 2024 (UTC)[reply]
I guess I can put this here: I feel like calling this "mobile fundraising" is a little bit misleading. Do not misunderstand me: I sincerely appreciate Clovermoss bringing this here, regardless of the title. But this is not really about fundraising on mobile. That always has happened, and I doubt anyone will have feedback on that. This is about allowing people to donate to "support"/"champion"/"appreciate" a particular article. Would "allowing people to donate in appreciation of a particular article" be a neutral way to phrase what is being suggested? Best, HouseBlaster (talk · he/they) 18:32, 14 August 2024 (UTC)[reply]
I said mobile fundraising because I wasn't sure what else I could put without making it sound like I was canvassing and steering the discussion a certain way. Between here and CENT, I'm sure this will get enough eyes instead of being buried at mediawiki. If someone does change the title, I'd suggest that it's as clear and concise as possible. Clovermoss🍀(talk)18:42, 14 August 2024 (UTC)[reply]
@HouseBlaster: What would you think if we added "experiment" to the end of the current text? It'd make it more clear that what is being proposed is a bit different compared to a normal mobile fundraising. Clovermoss🍀(talk)21:01, 14 August 2024 (UTC)[reply]
I'm largely indifferent to the idea of mobile fundraising in general, and was surprised it wasn't already well established. I'm also mostly indifferent to the idea of donations tied to articles. What I have a quite strong opinion about is what happens when someone donates "to" an article. To the point: there should be no direct connection between donations and the appearance of a Wikipedia article for anyone other than the donor. No matter how it's framed (badges, stickers, sponsors, endorsements, pictures, text, etc.), if there's any way to affect the appearance of the article with money, there will emerge metacommunicative/signalling strategies to manipulate the system in unacceptable ways. On some level, I like the idea of audiences being better able to communicate appreciation to contributors, but it has to be divorced from money. — Rhododendritestalk \\ 18:59, 14 August 2024 (UTC)[reply]
To the point: there should be no direct connection between donations and the appearance of a Wikipedia article for anyone other than the donor.
Agreed. I also see that the WMF recognises at least some of issues this could cause, saying Safeguards should be added to prevent inappropriate usage of the feature on sensitive articles, but I don’t think they’ve thought through the complexity of accurately classifying articles as sensitive.
Alternatively, if they have already succeeded in doing so in a robust manner, can they please release the tool, as it will be very helpful in general? BilledMammal (talk) 00:23, 15 August 2024 (UTC)[reply]
I think the safeguards comment was in regards to the concerns that I and other people expressed at the page itself on why you wouldn't want something like this on controversial articles. As far as I'm aware, this is just an idea and nothing has actually been implemented. That would mean that there isn't a way to filter this content out yet either. Clovermoss🍀(talk)00:41, 15 August 2024 (UTC)[reply]
I encourage people to leave their feedback on the mediawiki page itself (see my initial comments at the top of the thread) so it isn't scattered across pages and projects. Clovermoss🍀(talk)00:45, 15 August 2024 (UTC)[reply]
Thank you to everyone who has spoken up here - I'll echo @Clovermoss's request to please leave thoughts and ideas on the mediawiki project page. The mediawiki page has been edited to make it more clear (thank you for suggestions on how to do that!) and in hopes to communicate that this is at an early stage, and we are not limited to this first idea that is on the page. I've also expanded the page to include risks that have been brought up so far. Thanks to everyone who has contributed, we have the capacity to try a new format of fundraising within the iOS app this year, and we're excited to work together with you to identify what form it could take. HNordeen (WMF) (talk) 21:04, 16 August 2024 (UTC)[reply]
Wikimedia Foundation banner fundraising campaign in India postponed to start on the 27th of August
Dear all,
As mentioned previously, the WMF is running its annual banner fundraising campaign for non logged in users in India. Initially, we planned the campaign to start tomorrow and run until the 10th of September. We have had some issues with our local payment provider in India and due to this we are postponing the campaign by a couple of weeks. Our new campaign dates are the 27th of August to the 24th of September.
You can find more information around the campaign, see example banners, and leave any questions or suggestions you might have, on the community collaboration page.
Generally, before and during the campaign, you can contact us:
The Open Conversation with the Trustees at Wikimania hosted breakout discussions about the Movement Charter, affiliate strategy and hubs, the proposal for a Global Resource Distribution Committee (hybrid table--had streaming and is available to watch back online), the Product/Tech Advisory Council & Product/Tech priorities, building a sustainable revenue strategy for the movement: online fundraising, Wikimedia Enterprise and the Wikimedia Endowment, and responding to emerging threats to free knowledge: litigation, censorship, disinformation, and trust in an election year.
I would also say it should be reverted to maintain the original intent, but there will also be sources to support the current version of the article, as the new version is literally for another town. The telugu page (te:పోరండ్ల (జగిత్యాల)) has always been about the current (Jagtial) Porandla, as has the associated Wikidata item (wikidata:Q13003257). The original (Ranga Reddy) Porandla is at te:పోరండ్ల (మహేశ్వరం)/wikidata:Q16340753.If the original wording is restored, the thing to do here would be to revert, split off Jagtial Porandla, disambiguate Ranga Reddy Porandla, and then switch the relevant Wikidata entries.(As an aside, the one-up division, te:జగిత్యాల గ్రామీణ మండలం is one of the few Jagtial district#Mandals without an en.wiki article.) CMD (talk) 04:15, 26 July 2024 (UTC)[reply]
How do you determine the "size" of a list (or merging / splitting purposes)?
Ok, this may be a silly and redundant question. So, WP:SIZERULE gives good guidelines for when articles should be trimmed or merged. However, WP:SIZE states that readable prose size only includes "the amount of viewable text in the main sections of the article, not including tables, lists, or footer sections." For the purpose of merging lists, and with the removal of the kb limits (which I had previously used to judge list size) on WP:SIZEhow do you determine the size of a list (as related to existing guidelines stated on WP:SIZERULE) if you wish to merge or split a page? Historyday01 (talk) 13:17, 5 August 2024 (UTC)[reply]
The kb limits on WP:SIZE also applied only to readable prose, nothing has changed in that respect. List splits likely come down to editorial judgement, what best helps a reader. Some lists do still end up breaking other limits like WP:PEIS, but that's not common. CMD (talk) 01:25, 6 August 2024 (UTC)[reply]
The Wikipedia:Prosesize gadget can't count words in bulleted lists, so I found that the most effective way to count the words was to copy/paste the contents to a tool (e.g., the word count tool in your favorite word processor). WhatamIdoing (talk) 21:25, 18 August 2024 (UTC)[reply]
Low standards for references on the English Wikipedia
Why does the English Wikipedia allow the creation of articles without reliable sources? For example, if you look at the references for "El amor de mi bohío," you will find databases, blogs and other wikis. The same with Mira que eres linda, the sources are blogspot and Brito EcuRed. That's why many editors whose articles are deleted on the Spanish Wikipedia come to create them here, because the requirements for reliable sources are minimal. I don't think this does any good for Wikipedia's reputation. KokuyoKoychi (talk) 22:25, 5 August 2024 (UTC)[reply]
@KokuyoKoychi, the requirements aren't minimal but enforcement is difficult. Hundreds (or more) articles are created every day. There aren't enough editors to screen each one (although the New Page Patrol makes a valiant effort at doing so). Schazjmd(talk)23:41, 5 August 2024 (UTC)[reply]
You are welcome to improve the sourcing. There are many potential sources for the former here and here and for the latter here and here. I would do it myself but my Spanish is rather rudimentary. The article creator does not own an article on English Wikipedia. Phil Bridger (talk) 20:34, 11 August 2024 (UTC)[reply]
Normally it is not possible to full-text search through the Wayback Machine. However, they do make available certain collections for full-text search, such as the US Government docs collection has 403 million pages. The list of collections currently available for searching:
This is a beta service. There is currently a bug in the interface sometimes it redirects to the home page. If this happens, go to a collection search that is working (such as the US govt docs link above) and use the pull-down menu to navigate the collections. You can also search via URL such as:
The technical village pump is a good place to discuss the implementation details of a design. However to discuss the design itself, this village pump page would be more suitable. isaacl (talk) 21:48, 9 August 2024 (UTC)[reply]
Ban in Azerbaijani Wikipedia
Hello, I would like to complain about the administrators of the Azerbaijani Wikipedia.
The fact is that when I added az:Yenisey (Yenisei) in parentheses to the article its name in the Yenisei language in addition to the Russian term (and of course wrote the source from the 1899 book), I was banned by the Nemoralis administrator. To the question “what Wikipedia rule did I break,” he answered in an arrogant manner, “your account will not be unblocked.” I wrote this message here because I don’t know where to write. I also wrote the message to the Azerbaijani section, but Azerbaijani administrators support each other since for several years in a row these are basically the same people.
Please help me in this situation. At least express your opinion, please.
To make it clearer, I write the difference between the articles:
Normally the standard reply is enwiki has no powers over azwiki (and azwiki over enwiki). But you could try to find an azwiki admin who is active on enwiki. You could ask them about it here, in a neutral ground, maybe also try to find a neutral person on enwiki not from azwiki, to help moderate the dispute. It seems extreme to ban someone over what you describe so either they are bad amins or there is more to the story. -- GreenC19:35, 9 August 2024 (UTC)[reply]
"bad admins" is surprisingly plausible. There are four azwiki admins indefinitely blocked here (Solavirum, Nemoralis, Wertuose, Atakhanli), including the admin who blocked Sebirkhan on azwiki. But Google Translate of the azwiki discussion linked to paints a different picture than an admin cabal supporting each other. * Pppery *it has begun...19:59, 9 August 2024 (UTC)[reply]
Indeed, this editor appears to have continuously ignored advice regarding using old sources for names in article leads and received a one-month block in response. I don't see any indication of foul play, and I say that as the admin who blocked 2/4 of the az.wiki admins listed above from en.wiki. signed, Rosguilltalk20:22, 9 August 2024 (UTC)[reply]
However, I do not understand why I cannot add the name of the Yenisei River in the Yenisei language in brackets, while the name of this river in other languages is added at the beginning (Maybe then we should delete all the names and leave only the official one - Russian). Where should I add this name if not in this Wikipedia article? I consider it important for preserving history. After all, I did not come up with this name. But the administrator deleted it and blocked my account and my IP Sebirkhan (talk) 20:35, 9 August 2024 (UTC)[reply]
As the admin of AzViki, I can say that the user presents the situation differently. The user constantly adds words in the old Azerbaijani language or the old Turkish language to the beginning of the articles, changes the names of the articles. We have repeatedly warned him to use only modern Azerbaijani words, not archaic words. As a result, he was blocked at the very end. And now he allegedly says that he added the word in Yenisei language to the beginning of the article, while he added the version in ancient Turkic language, which is unrelated to the topic. However, the Yenisei language has nothing to do with the ancient Turkic language. And the user does such things many times. The user even once wrote that the word "shogun" is a Turkish word in the Shogun article on AzWiki. Cosmic Bardutora!20:32, 9 August 2024 (UTC)[reply]
It is not true because, A regular azwiki user does not have the technical ability to change article titles. Also I do not use Turkish language in Azerbaijani section.
Everything you write is far-fetched, because I have never written in my life that shogun is a Turkish word or comes from a Turkish word. However, thanks to me, the administrators eventually changed the name of the page Syoqun to Şoqun (which is correct from the point of view of the Azerbaijani language and Japanese language, and also others) and this is a fact if you look at the history of the article. Sebirkhan (talk) 20:41, 9 August 2024 (UTC)[reply]
In the edit Cosmic Bard identifies, you added [[Qədim_türk_dili|Əski türkcə]]: 𐱁𐰭𐰆𐰣, /şöŋün/, which would indeed suggest that the origin of shogun is Old Turkic. signed, Rosguilltalk20:52, 9 August 2024 (UTC)[reply]
You are right, however (even though this is a word written in dictionaries), I thereby pointed out the inconsistency of using the Russian form Syoqun in the Azerbaijani language, in the end we came to a compromise Şoqun. I was not banned for this reason. The azwiki administrator is simply trying to direct the conversation in a different direction. While not banned for this, specifically I received a message about blocking after changing the Yenisei page and the administrator canceled my edits. Sebirkhan (talk) 20:58, 9 August 2024 (UTC)[reply]
You are not blocked just because of the Yenisei River article. Everyone can do something wrong. A user cannot be blocked for one edit. You are blocked because you keep doing things like this. Before that, you wrote the Dnepr River as "Ozü River" in a article, and I warned you about this, that this river is not called Özü River in any source in the modern Azerbaijani language. I will not comment further on this issue here, because it is not EnViki's issue, but AzViki's issue. Cosmic Bardutora!21:08, 9 August 2024 (UTC)[reply]
I have no idea who is right or wrong in this case, but I think you have been badly advised above. There is indeed nothing that can be done at the English Wikipedia about the Azerbaijani. The place to go if you are dissatisfied with the response you get at the Azerbaijani Wikipedia is Meta: . Phil Bridger (talk) 20:45, 11 August 2024 (UTC)[reply]
References
^В. В. Радлов, Опыт словаря тюркских наречий, том второй, Санкт-Петербург, 1899 (s. 1202)
making plans to edit articles again
Hey, everyone...
so, uh, I've been making random edits here and there when I see something that bugs me, but haven't edited Wikipedia *in earnest*, regularly, since, ah, ... *checks* idk, it trails off gradually, but since early 2007 or so? and really my heyday was before that. my user page is old enough to drink now.
... Anyway, I find myself interested in coming back and doing some Editing — by this I mean specifically working to improve the intelligibility of the information that is already present in some articles. Are there any good Wikiprojects that I should be looking at which might be a good match for this goal?
So the Open Knowledge Association pays people to write on Wikipedia [8]. On their Meta wiki page they encourage/explain how their paid editors should translate articles: by using AI and letting unpaid volunteers clean up the rest of the work: [9].
I've seen OKA articles pass AfC with completely untranslated sentences, references that have been translated/untranslated causing them to be incorrect, non-English article titles, and non-English section titles.
What change would you like to see? From what you wrote, one thing may be to have AFC reviewers do a better job to not approve submissions with untranslated sentences and such, but that might be better discussed at WT:AFC rather than here since the reviewers are more likely to be over there. Anomie⚔22:37, 15 August 2024 (UTC)[reply]
I don't think making AfC reviewers spend more time reviewing an article than someone spent 'creating' an article is fair and would just create bigger issues with a backlog. The problem is how quickly one can create these translations versus how long it takes to review them. I had to rewrite an entire article translated by OKA due to issues and I would've just been better off creating a brand new article. Traumnovelle (talk) 22:42, 15 August 2024 (UTC)[reply]
Our policy is quite conservative. "Unedited" WP:MACHINETRANSLATION is not acceptable, but there is no consensus on what it takes to be considered edited. If there are a lot of issues from a single editor this is more likely to result in action, but that won't change the general policy. You could argue WP:TNT for a new article at AfD, but I'm not sure how successful that is for prose issues. CMD (talk) 02:57, 16 August 2024 (UTC)[reply]
Would that be a valid deletion rationale in an AfD? I could also report the editor in question but it isn't limited to just his work and I imagine plenty of other people would be willing to do the exact same thing. The problem is that people are financially incentivised to produce these quick translations and rarely stick around to fix it once it's passed AfC. Traumnovelle (talk) 03:01, 16 August 2024 (UTC)[reply]
It can be a valid rationale, but it's one of those rationales where you very much have to make the case and convince others. If they're not up to a standard you'd consider 'edited', that would likely help the argument. CMD (talk) 03:20, 16 August 2024 (UTC)[reply]
Unfortunately, there are plenty of unpaid editors who create poor articles and do not stick around to fix them. One might even say it is part of the culture. (Sigh!) Donald Albury12:51, 16 August 2024 (UTC)[reply]