Wikipedia

Wikipedia:Village pump (idea lab)/Archive 32

< Wikipedia:Village pump (idea lab)
Village pump (idea lab) archive  

This page contains discussions that have been archived from Village pump (idea lab). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56

Audio name and music.

All name should be recorded in the pronouncation in which every one will understand to every sector of the world like some people pronounce xavi as x avi not knowing it is pronounce shavi and all music will have audio file in which one can listen to some part of it and if full you can. This what makes article more interesting and back up article. let enforce it more let use wpwp campaign to enforce this more.Tbiw (talk) 14:03, 6 July 2020 (UTC)

It is a good idea to have pronunciations for words like names that you won't find pronounced in a dictionary, or even for words that are not common. But we should not enforce it, as article have to start from stub level and grow. Perhaps we can add it as an expectation for featured article standard. Music is more tricky as such a piece is likely to be under fair use only. But still would be possible. Graeme Bartlett (talk) 01:11, 7 July 2020 (UTC)
@Graeme Bartlett yes it is possible if we have commons co-operation if we could have it. We will go far. Many people wanted this i even also wanted this. I can't pronounce xavi but press wiki audio voice is gonna say shavi not like you saying x avi.It can be possible.Tbiw (talk) 06:01, 7 July 2020 (UTC)
The following discussion is closed and will soon be archived.
  Moved to propsals

Color of AfD Template

 
mobile view
 
desktop view

I've always thought that the color of the current AfD template (dark red) was a bit alarming. When people come in from other sites and see the template, I think the current color could prompt them into meatputting more than a different color could. While speedy deletion and Prods are in my opinion more serious, AfDs, are after all supposed to be a knowledgable discussion, not a unilateral decision or a vote. It could also help content creators understand that this isn't the end of the world, or a very bad thing on par with a PROD or CSD to the page they created, and that it's ok to make these types of mistakes. I was testing colors in my sandbox and I rather like the orange used for problems in articles. I know there is kind of categorization scheme where red means delete, orange means problem in the article, etc., but to be honest I've never paid attention to the colors themselves. All I think the colors really signify to anybody is red = bad, orange = warning, yellow = less warning and so on. What do others think? Sam-2727 (talk) 05:22, 26 June 2020 (UTC)

This would also be in line with the color that twinkle sends for notifications of nominations of deletion (check my talk page for an example...), so wouldn't be completely out of line with current practice. Sam-2727 (talk) 05:22, 26 June 2020 (UTC)
Sorry, can you clarify what you're suggesting changing? The {{Article for deletion}} template isn't dark red; it's your browser default font in your browser default colour (almost always black) against an off-white background with a tinge of green, with a black border and a single narrow crimson stripe. We want the deletion templates to look distinctive, so they stand out from the more routine maintenance tags; we're well aware that readers have banner blindness when it comes to orange tags, so orange is the last colour scheme we should be using for something like deletion where we want to draw the reader's attention. ‑ Iridescent 06:20, 26 June 2020 (UTC)
  • The OP doesn't provide any examples. I suppose that they were thinking of Lynnae Quick but AZ Cephei is a better example because it has more than one template and so shows the comparative impact. Also, they seem to be thinking of the desktop view but note that most Wikipedia traffic uses the mobile web view – the overall split currently is 62.6% mobile web; 37.1% desktop; 0.3% mobile app. Screen shots are shown right.
The main anomaly is that, in the desktop view, there's no warning icon for the AFD notice while the {{notability}} tag has a big bright orange exclamation mark. This is not consistent with the mobile view, where the graphical treatment is similar. As for the colours, the orange looks brighter and more prominent than the crimson, which is so dark that it doesn't stand out from the default black.
Andrew🐉(talk) 09:41, 27 June 2020 (UTC)
From what I can see, it would be very easy to give the AfD or PROD tags an icon, assuming a good one exists. I would assume changing colours (assuming we want to keep the Ambox types meaning what they mean now) is harder—though a cursory read tells me that definitive answer would require more familiarity with Module:Message box than I really want to acquire. If we do go for "change the type", I'd suggest blue, to differentiate between the orange "content" and yellow "style" tags which are more often used. It's also not as scary as red, and semantically it kinda fits as a "notice there's an ongoing discussion". Alpha3031 (t • c) 16:18, 27 June 2020 (UTC)
 
Wikipedia entry as it might appear to a user with deutanopia
  • 4.5% of readers are color blind. This page gives some tips. This tool is useful. When I test it on https://en.wikipedia.org/wiki/Odessa_Grady_Clay with deuteranopia, the most common, the bar on the AfD template turns from red to brown, but the grey-blue backgrounds turn pinkish. https://en.wikipedia.org/wiki/Template:Notability is very pink. Aymatth2 (talk) 14:07, 27 June 2020 (UTC)
  • I think changing it to orange would be an ok idea.★Trekker (talk) 14:47, 27 June 2020 (UTC)
  • Biggest issue imo is banner blindness, as Iridescent mentions, and colour-blindness. The idea of the AfD notice is usually to make editors aware of the discussion. Orange doesn't quite grab the same level of attention. After all, an AfD notice is more important/'serious' than a COI note, or a cleanup/unreferenced/etc tag, all of which are also orange. ProcrastinatingReader (talk) 15:21, 27 June 2020 (UTC)
  • The red used for AfD banners is part of a scheme where orange and other colors already have their own designated meaning; see Template:Ombox#Other pages message box types. If you want to propose an overhaul of that scheme, perhaps that could be done, but you need to look at it as a package, not just change this one element in a way that might cause it to conflict with others. {{u|Sdkb}} talk 22:20, 27 June 2020 (UTC)
    Also, for everyone in this discussion: we're trying to revive WP:WikiProject Usability. If you're interested in this, feel free to join there. {{u|Sdkb}} talk 22:21, 27 June 2020 (UTC)
  • Sorry I couldn't respond earlier. I'll try to respond to everybody once, but hopefully it doesn't get too jumbled. Yes @Iridescent:, I meant the crimson stripe on the side (instead of dark red: I don't really know the difference, but I don't know much about colors). I think the arguments about the template being above that of a warning level are fair, but there's a large bold strip of text across that says This article is being considered for deletion in accordance with Wikipedia's deletion policy. I think that's pretty unambiguous, and if combined with a recognizable icon, could be even more unambiguous. Sdkb, I agree that the technical details for the color split would be a bit difficult to implement, but I'm sure it could be done once an agreement on them is found. As per icons, I think going in line with mobile view would be a good idea with File:Ambox warning orange.svg (this is also what is added for twinkle AfD notifications). That's a very interesting point about color blindness though, I hadn't considered that. Also Andrew Davidson is correct, this is where I'm coming directly from. But really this was just a reflection of how I see new editors participating in AfD almost in a "panic mode." But if others don't see that argument, then I suppose improving the issue of readability is another argument for the new design. Sam-2727 (talk) 03:24, 28 June 2020 (UTC)
  • I think it should stay at its current color, because deletion templates are more important than, say, {{refimprove}}. —pythoncoder (talk | contribs) 22:12, 8 July 2020 (UTC)

Rethinking notability standards for political candidates

WP:NPOL is often used at AfD to justify deletion of political candidates who pass GNG by a mile but lost the election or are candidates for an election that hasn't taken place yet. This often results in such candidates having their articles deleted. A common reason provided for this standard is that if it didn't apply then "every candidate for any office in the US would have an article". So long as the candidate receives enough coverage beyond their local area (often the case in these deleted politician articles) I don't see the problem with that! Wikipedia is a paper encyclopedia, and there's no size limit. It just strikes me as frankly absurd that there seems to be this standard that candidates have to have international level coverage to justify inclusion. We ought to have a discussion about whether that's really the standard we want to keep, and why GNG alone shouldn't be the benchmark (keeping in mind WP:ROUTINE, WP:MILL, etc). Even if that doesn't happen, I'd support changing the standard to national coverage. That way, every random candidate for <insert small county here> board member won't get an article, but a House or Senate candidate or whatever else who receives some national coverage in Politico, NY Times, NBC, etc, will get an article. I think that's a much better setup than the current unofficial standard. Any thoughts? −−− Cactus Jack 🌵 19:26, 30 June 2020 (UTC)

Do you have some examples of these AfDs? Just to get an idea of the kinds of people you're referring to. ProcrastinatingReader (talk) 19:39, 30 June 2020 (UTC)
The purpose of notability guidelines is to constrain our articles to subjects where we'll have sufficient sources. We can't have an article about a person if we know nothing about them, only that they were a losing candidate in a race. Even if you had a national media outlet discuss a local race, the journalism would still be a primary source and likely very one-dimensional about whatever happened in that campaign. That's no real basis for a biography; it's a COATRACK for partisans seeking to see their desired narrative affirmed on this website. We refuse this sort of thing all the time. Depending on the candidate, you might even argue that WP:BLP1E applies. I would wish more editors would wait for people to die before attempting a biography about them. Chris Troutman (talk) 20:00, 30 June 2020 (UTC)
If they pass GNG they should be kept. A guideline like WP:NPOL is for subjects that do not pass GNG but should be kept regardless. The Sheriff of Smallsville may notable as a professional wrestler, violinist and fraudster, but not notable as a politician. Aymatth2 (talk) 20:32, 30 June 2020 (UTC)
No, NPOL is not for subjects that "do not pass GNG" — any politician who passes NPOL, literally by definition, always also passes GNG. The thing is that we're not always very good about actually finding and using all of the potential sources that people actually have, so sometimes their articles won't look like they pass GNG, but that doesn't mean they don't. There's literally no such thing as any politician who has ever somehow passed NPOL while simultaneously failing GNG — covering NPOL-passing politicians is literally the media's #1 job, so sources always exist for NPOL-passing officeholders regardless of whether we've found those sources yet or not. See also WP:NEXIST. Bearcat (talk) 03:07, 1 July 2020 (UTC)
@Bearcat: It is possible for a judge in a country with limited media freedom to be appointed to a state-wide office, but not to be discussed in depth by independent sources. WP:NPOL says they are notable regardless. Aymatth2 (talk) 13:36, 1 July 2020 (UTC)
Gosh, there's an odd one ... how would most judges in a jurisdiction where they are appointed (other than the level of the highest or supreme court) have any discussion in independent sources? You seldom see any coverage until they really screw up, or have retired, and are appointed to head a prominent enquiry or commission. I don't know the history here, as I've never seen anyone argue an appointed judge is notable before - but I seldom dabble in foreign legal articles. Nfitz (talk) 18:36, 1 July 2020 (UTC)

deletion of political candidates who pass GNG by a mile but lost the election This is inaccurate. Anyone who passes GNG should be kept, by definition. NPOL does not overrule GNG; rather it is an additional standard. It allows us to INCLUDE elected officials who may not have received a lot of coverage outside their area (and arguably fail GNG) but still qualify for an article because of their position. NPOL does require that the person actually be elected; running for office and losing does not meet NPOL. -- MelanieN (talk) 20:49, 30 June 2020 (UTC)

I agree they should be kept, but in many cases they are deleted citing NPOL as the reasoning. My goal here is to address that. I'll dig up some good examples today and post them here. −−− Cactus Jack 🌵 20:52, 30 June 2020 (UTC)
NPOL is often brought up in deletion discussions, but you're right: it doesn't override GNG. I think the better argument for deleting these pages is that this project is WP:NOT a newspaper (nor is it a soapbox). While local election campaigns are newsworthy, they usually lack enduring notability. pburka (talk) 20:57, 30 June 2020 (UTC)
  • WP:NPOL does not override WP:GNG, but it's often used in these discussions because the person is not notable under WP:NPOL. WP:NOT does trump WP:GNG. A candidate will typically always receive press that would qualify for WP:GNG all the way down to the local level. We also know that candidates who fail to become elected almost certainly do not maintain lasting notability - they're just a person who tried to run for office, got some press around running for office, then lost and went back to a normal private life, not to mention WP:NOTNEWS and WP:PROMO concerns (it's difficult to write a neutral article about a political candidate.) Recentism is also an issue - candidates who lost several elections ago and didn't do anything else are typically deleted/redirected without any opposition. There are exceptions to the rule, sure, but this is basically an evergreen discussion - pretty much once every two years, timed nicely for the elections in the US. SportingFlyer T·C 03:01, 1 July 2020 (UTC)
A candidate will typically always receive press that would qualify for WP:GNG all the way down to the local level. I disagree. Local coverage in a small local paper, or mentions as part of a list of all the candidates, do NOT qualify for GNG. GNG requires significant coverage in multiple independent reliable sources. And if their coverage is ONLY about the election, we often regard that a sort of BLP1E. NPOL provides an automatic article for a significant local office holder in a major city, but not every town and city in the country. (Los Angeles city council, yes; Huntington Beach city council, no.) Most local office holders do not meet NPOL, and we normally expect to see at least some regional coverage of such a person before we accept it their coverage as meeting GNG. Holders of state/provincial/equivalent or national office automatically pass NPOL, but candidates for such office do not; they have to meet GNG to get an article. -- MelanieN (talk) 04:01, 1 July 2020 (UTC)
  • Thank goodness that we have experienced editors who help defend our longstanding consensus that unelected political candidates who have never held high office are rarely notable. These editors have done outstanding work helping keep campaign brochures masquerading as encyclopedia articles off of Wikipedia. Of course, if the candidate was previously a general or a professional athlete or a movie star, they are notable for those reasons. But the vast majority of local lawyers or business people running for Congress or Parliament or state or provincial legislatures are not truly notable for a Wikipedia biography, because their coverage is routine, mostly local, run of the mill, and predictable . Such candidates should be described briefly and neutrally in an article about the election campaign, with all candidates given comparable coverage. But the POV pushers and SPAs who try to write these articles do not want neutral coverage. They see a Wikipedia article focused on their candidate to be just another component of their campaign's social media portfolio. If NPOL was gutted, there would be a dramatic increase in promotional biographies written by COI editors, and that would be a terrible burden on our volunteers who struggle to keep promotionalism out of the encyclopedia. Cullen328 Let's discuss it 03:17, 1 July 2020 (UTC)
    +1 Levivich [dubious – discuss] 03:26, 1 July 2020 (UTC)
  Like -Ad Orientem (talk) 03:27, 1 July 2020 (UTC)
Well said. - Sitush (talk) 09:03, 1 July 2020 (UTC)
Put it better than I would have ProcrastinatingReader (talk) 09:56, 1 July 2020 (UTC)

The first problem, and one of the core reasons why we deprecated the notability of unelected candidates in the first place, is that articles about unelected candidates almost always violate WP:NOTADVERT. Wikipedia is not a free public relations platform for aspiring future notables to promote themselves — but the core purpose of articles about unelected candidates is very nearly always self-promotion by the candidate or their campaign staff rather than genuinely neutral attention.

The second problem is that campaign coverage usually just makes the candidate a WP:BLP1E. That's an example of how GNG can be overridden: if a person has a small blip of coverage in one specific context, but is essentially a low or no profile topic outside of that specific context, then we often do not keep articles about them at all. We also have a rule that we are WP:NOTNEWS: we consider the enduring notability of our article topics, not just their current state of temporary newsiness.

The third problem is that as an encyclopedia that anybody can edit, we are extremely vulnerable to bad edits by anybodies who are not editing responsibly. As I mentioned in one of the AFD discussions, I really did once come across a Wikipedia article about a low-level political figure (who would not have passed NPOL) which had been edited to libel him as a cannibal pedophile who smuggled children into nuclear power plants to rape, kill and eat them — and when I checked the edit history, it had been saying that for three years. I am not making one word of that up: we really did spend three full years hosting explosively libellous claims about a smalltown municipal councillor, simply because he wasn't prominent enough that anybody had noticed the libel earlier. I dealt with it right away, obviously, but the fact that the article had spent three years saying that before I found it is still a problem. And similarly, I have also come across many articles which some random editor had completely hijacked to be about a completely different topic: a different person with the same name as the original topic, a different person with a completely different name than the original topic, their own résumé, a recipe for raisin bread, and many other kinds of disruptive editing. Again, not making any of this up: every one of those things has really happened to a considerable number of Wikipedia articles, and again sometimes went uncaught for days or weeks or months.

Our quality control model, of allowing anybody to edit any article freely and then relying on the oversight of other editors after the fact to control for bad edits, works very well on high-visibility topics because vandalism will be seen and reverted almost instantly — but there is a level of public prominence below which the wikimodel literally falls flat on its ass, simply because the article isn't generating enough traffic to guarantee that vandalism will get caught promptly. That's one of the core reasons why we have notability standards for people at all: because the structure of the project doesn't always prevent vandalism very effectively, we have to be realistic about what kinds of content we can or can't feasibly manage. For low visibility topics without sustained permanent public interest, we simply cannot guarantee the level of vigilance required to prevent this kind of thing.

And it's also not just every candidate in the United States — that gets mentioned because the United States is the country where elections are currently happening, but the US wouldn't actually get unique treatment denied the rest of the world. If we do this for the US, then we also have to do it for Canada, Australia, the United Kingdom, France, Spain, Germany, Portugal, Denmark, Switzerland, Italy, Poland, Greece, South Africa, New Zealand, Russia, Romania, and literally every other country in the world that has democratic elections at all. With the added bonus that it's not just national legislatures either, as many of those countries also have states or provinces with their own NPOL-passing subnational legislatures. In other words, hundreds of thousands of new articles per decade, about people of no enduring public interest for whom we cannot guarantee the required maintenance to ensure that their articles all stay neutral and fair and non-libellous and not converted into somebody else's résumé. That's not a recipe for a better encyclopedia — that's a recipe for disaster.

All of which is why we've always had a consensus that in order to qualify for articles without passing WP:NPOL by winning, candidates have to either show preexisting notability for other reasons that would already have gotten them an article anyway, or be demonstrably much more notable than most other candidates, in some way that would pass the ten year test for enduring significance. Candidates are not deemed to pass GNG just because some campaign coverage exists — some campaign coverage always exists for all candidates, but what all candidates don't necessarily have is a reason why their candidacy is of enduring importance that would transcend the question of whether they won or lost. Even GNG is not, and has never been, just "count up the footnotes and keep anybody who surpasses an arbitrary number" — GNG does test for things like the context of what the person is getting covered for, and GNG does deprecate some types of coverage as not notability-clinching. As I've also pointed out in other AFD discussions in the past, if all a person had to do to get a Wikipedia article was show that they had two media hits, and thus "passed GNG" regardless of whether they passed any SNGs or not, then we would have to keep an article about my mother's neighbour who got a couple of media hits a few years back for finding a pig in her front yard. So people are not automatically exempted from having to pass any specific SNGs just because some media coverage happens to exist — we are also going to evaluate the question of whether the thing the sources are covering the person for rises to the level of warranting an encyclopedia article or not. Bearcat (talk) 03:56, 1 July 2020 (UTC)

It seems User:Bearcat doesn't understand how WP:N works. It clearly says in WP:SNG that A topic is not required to meet both the general notability guideline and a subject-specific notability guideline to qualify for a standalone article. I've heard complaints before about subjects passing a WP:SNG on a technicality, yet only having trivial coverage ... but to claim that a subject meets WP:GNG over an extended period of time, but an article should be deleted because WP:SNG is not met, is stunning. Bearacst has been informed of their error on this time and time again, and yet persists in creating AFDs for subjects that overwhelmingly kept. It's time to topic ban Bearcat from AFD creation. Nfitz (talk) 07:11, 1 July 2020 (UTC)
I understand how notability works completely correctly.
As I have pointed out to you in the past, every possible source that exists is not automatically always a GNG-bolstering source. GNG is not just a number of hits, and does take into account factors such as the context of what any given piece of coverage is covering the person for — a child actor does not automatically clear GNG just because they can show one or two pieces of "local kid gets cast in bit part" pieces in their own hometown community hyperlocal, if wider coverage that would attest to the significance of their acting roles does not exist; an unelected political candidate does not automatically clear GNG just because the expected coverage of the election campaign exists, if a reason why their candidacy has attained enduring notability does not exist; a filmmaker doesn't clear GNG just because the real estate section of a newspaper once published a piece about the interior design of his condo, if he has no coverage attesting to the notability of his work as a filmmaker; I don't clear GNG just because my name has been in newspapers in non-notable contexts a few times; and on and so forth. Sources can be valid for verification of additional facts while not helping to get the subject over GNG, if they aren't covering the subject in noteworthy contexts.
We have an established consensus that candidates are not permanently notable just for running as candidates per se. To establish the permanent encyclopedic notability of a candidate, it is not enough to just show that some campaign coverage exists — every candidate can always show that some campaign coverage exists, so if that were all it took to make a candidate notable then our entire consensus that candidates are not all notable would be inherently meaningless because no candidate would ever fail it anymore. Rather, to make a candidate permanently notable enough for Wikipedia, the existing consensus is that the candidate must either (a) have preexisting notability for other reasons independent of the candidacy itself, or (b) show a credible reason that their candidacy would pass the ten year test for enduring significance, by virtue of being significantly more notable than most other people's candidacies.
If you would like to propose that we change the existing consensus around the notability of unelected candidates, that's one thing — but I am not incorrect about what the current consensus is. We consider the enduring notability of our potential article topics, not just their temporary newsiness — and that's literally also a statement right out of Wikipedia policy, not a statement of my own personal opinion. Bearcat (talk) 07:27, 1 July 2020 (UTC)
NPOL is irrelevant. It might be relevant during WP:BLP1E situations, where the person has no history ... and while that might be a possibility for someone in a riding, it's less likely for candidates for the leadership of a prominent national political party, where not surprisingly, there's a history going back decades of media coverage for the same issues, that they are stressing during their campaigns. If one is a prominent environmentalist or political activist, we don't suddenly discount GNG going back decades. I'm not sure why you are using examples that violate WP:BLP1E - which doesn't seem to be the issue in the AFDs you've been creating recently. Nfitz (talk) 08:04, 1 July 2020 (UTC)
@Bearcat: A quibble: "significant" refers to the depth of coverage, not to the importance of what someone has done. A child actor who has received enough independent and reliable coverage that addresses their career directly and in detail does deserve an article per GNG, regardless of the seriousness or importance of their roles. pburka (talk) 14:03, 1 July 2020 (UTC)
  • Perhaps, rather than relying on NPOL, which creates confusion about the role of SNGs, we should include something explicit in WP:NOT, e.g. "Wikipedia is not a campaign website". pburka (talk) 14:12, 1 July 2020 (UTC)
  • I'd love this. WP:NPOL gets brought out at AfD because the person is a politician who fails the SNG, not because the SNG disqualifies that person. If they are deleted, it's because they fail WP:NOT. They'll almost always have some sort GNG-qualifying coverage ("Candidate name announces run for office"), which is why these discussions get as heated as they do, but we don't count that coverage towards notability. SportingFlyer T·C 18:40, 1 July 2020 (UTC)
  • So it's not unreasonable for this discussion to be bought, because AfD absolutely is defining NPOL as a specific overruling of GNG. SNGs and GNG have an insanely unclear crafted set of relationships. Some are to hasten a guessing process but must also ultimately meet GNG (NSPORTS), others offer alternate routes (NPROF), some specifically state a higher requirement (NCORP) and some are unclear, and so get defined mainly by the AfD experts, of which NPOL is a clear example. What we do (yes, I back its standard execution firmly) could be alternatively construed as an ultra-hardline interpretation of ROUTINE. Ultimately, we !vote this way in order to mitigate what would be an avalanche of problematic bios. Cullen's reasoning is excellent. Policy is descriptive, not proscriptive, so I suggest we instead tweak NPOL to make it clearer that it should be executed in the same way. This is roughly "NPOL takes precedence over GNG for subjects seeking notability through its criteria. An individual that meets GNG in areas outside of NPOL's coverage may still be considered notable". Nosebagbear (talk) 12:58, 2 July 2020 (UTC)
    • I don't think that NPOL does or should take precedence over GNG, and it doesn't have to. But it should include some guidelines about how NOT should be interpreted in the context of politicians. pburka (talk) 15:26, 2 July 2020 (UTC)
    • Good luck. I got threatened with a block for suggesting that NPOL was unclear as written and should explicitly state how it takes precedence over GNG. --Ahecht (TALK
      PAGE      ) 18:07, 4 July 2020 (UTC)
  • As a point of note, NORG is specific more stricter than the GNG, so NPOL can easily set out criteria to demand more specific requirements than the GNG. In the current version of WP:N we would add to WP:SNG to add NPOL along NORG as a "more strict" case. And I do endorse an appropriate to make this a more restrictive measure. It's far too easy to find local sourcing for any candidiate in nearly any race. State/sub-national level and higher level races are important but even there you can get wonko 3rd party candidates that have no chance. --Masem (t) 15:34, 2 July 2020 (UTC)
  • Say we amend NPOL. I think it's fairly well established that trivial coverage is not useful for establishing notability, and that routine coverage is considered trivial. All we really need to add is to make explicit that the typical coverage expected of a candidate for office is in fact routine, and thus trivial, and thus does not count towards the GNG. Alpha3031 (t • c) 09:07, 3 July 2020 (UTC)
  • I think a simple clarifying statement explaining that GNG and NPOL are an “either/or” not a “both” is all that’s needed. And maybe explain what “routine coverage” is. Montanabw(talk) 17:32, 4 July 2020 (UTC)
  • I disagree with the original suggestion - for notability to occur if a candidate "receives some national coverage in Politico, NY Times, NBC, etc, will get an article." The problems are a) that it is US centric and b) that all of the information that people want to add can be developed in a page about the campaign, without the need for creating a page about the individual candidate(s). So, if Jane Doe is running for US Senate, add information about them and their policies, polls, and campaign drama to 2020 U.S. House of Representative election for the Free State of Jones and create a redirect. Until then, lets create a WP:NOT to explicitly state that Wikipedia is not a campaign brochure (although that won't really address the underlying disagreement that exists in our community about the notability of political candidates). --Enos733 (talk) 19:39, 8 July 2020 (UTC)
  • Examples
Hobit (talk) 00:31, 8 July 2020 (UTC)

Side note

Folks here may be interested in a Discussion in progress about SNGs generally: Wikipedia_talk:Notability#North8000's_description_of_how_wp:notability_actually_works_right_now

New Usergroup: Deletion rights

WITHDRAWN
Request withdrawn by OP. SuperGoose007 (Honk!) 23:42, 9 July 2020 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I propose a new usergroup: Deleters. Users with deletion rights can delete any non fully protected page, as long it is in the realm of the deletion policy. This includes deleting pages tagged for speedy deletion and administrating the result of a successful XfD. They can also view deleted pages and revisions that is in the public deletion log (i.e, material that is not suppressed). Due to the high level of trust of having deletion privileges, potential candidates must be on Wikipedia for 180 days and had made 2000 total edits to the main space. Candidates must also show involvement in deletion activities and counter-vandalism. Having rollback rights and new page reviewer rights is a plus. Misuse of deletion rights can be punished by having it or other rights being revoked or being blocked from editing. I hope you support this idea, even if it sounds a bit far-fetched. SuperGoose007 (Honk!) 22:35, 9 July 2020 (UTC)

If we can trust a person to do this, they could very likely be trusted as an administrator (also block users, protect pages...). So I suggest if you know people that could use this function, and are proven trustworthy, then consider nominating as an administrator. The difference would be the process to gain the access. Graeme Bartlett (talk) 23:32, 9 July 2020 (UTC)
@SuperGoose007: Suggestions like this to have partial-admin rights is a perennial proposal. See Wikipedia:Perennial_proposals#Hierarchical_structures for some reasons why it is not implemented. RudolfRed (talk) 23:34, 9 July 2020 (UTC)
SuperGoose007, What you're describing is the most important power granted to an admin. Deleting content is more serious than blocking an account. In short, this is a non-starter. -- RoySmith (talk) 23:35, 9 July 2020 (UTC)
  Request withdrawn SuperGoose007 (Honk!) 23:42, 9 July 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Should we change the way we nominate new administators?

Man, Looks like Wikipedia's on another crisis here. This is just the SECOND month this year that we've never had a single RFA. Looks like the RFA process needs to be changed. Hoping that this RFA drought doesn't break the record. 139.192.206.157 (talk) 04:33, 3 July 2020 (UTC)

It's not really a "crisis" since there isn't a narrow timescale for fixing it. The past couple of years have also had scarcity. Why are nominations the bottleneck and what rough path(s) would you suggest we consider to try and resolve it? This year a significant number of us have been far more active pursuing potential candidates, with some success earlier on. The discussions at WT:RFA have already agreed several of the most common factors: concerns about the hostility of the RfA process, concerns about the high thresholds in passing, feeling they don't want/have a need for the tools and a feeling they have something that would sink any candidature. Some of them might be mitigated by a change in nominating by indicating whether their fears are warranted or not etc, or offering support, but I'm at a loss of how the nomination process could significantly resolve what is a fairly limited pool of individuals. Nosebagbear (talk) 08:55, 3 July 2020 (UTC)
Perhaps the issue should be addressed from another angle. The whole strict vetting/hostility and "something that would sink any candidature" could be mitigated by having a far better path to remove the permissions, should the need arise. Then perhaps people will be more inclined to overlook relatively smaller issues. ProcrastinatingReader (talk) 00:07, 4 July 2020 (UTC)
One requirement that could be relaxed is the "need for the tools", and replace it with "would use the administrator tools". As we are volunteers we do not really need to be here. Graeme Bartlett (talk) 01:04, 4 July 2020 (UTC)
I agree that nobody actually needs admin tools, so that is certainly not something that should be used to oppose any candidate. The only need here is that non-admins need people who can block, protect and delete, because some people prevent others from building a high-quality encyclopedia. Phil Bridger (talk) 08:17, 4 July 2020 (UTC)
I agree that RFA is a disaster. I don't frequent RFA too often, but every time I drop in, I'm horrified at the combat zone it is. "Oppose because once, three years ago, the candidate did something I didn't like". I've tried to get a number of excellent potential candidates to run, and been turned down. I don't blame them. On the other hand, maybe we don't really need more admins. What we need are more people writing good content (as opposed to more UPEs and other spammer types). And more people participating in administrative functions like AfC, page patrol, XfD. Those are all vital functions, require dedication and the willingness to invest time to learn the processes, but don't require mops. -- RoySmith (talk) 01:11, 4 July 2020 (UTC)
RoySmith, I agree and disagree simultaneously. AfC, NPP and XfD needs volunteers, as do admin areas. A lot of admin areas seem backlogged, at least in my timezone, which often doesn't clear up until US daytime/evening. Copyvios frequently have backlogs of 24h or more, for example. Even AIV can have backlogs. We need more people all across the board, people creating content as well as more elves. There's no reason to make the toolset 'exclusive', if an editor is trustworthy and competent over a period of time they should have the tools so they can save time and avoid wasting time of another admin. Currently, for copyvios for example, it's effectively a case of two people (the flagger, and the admin) spending time on a single report, plus the backlog. And there aren't really so many admins when you consider about half are highly inactive, and of the remainder half are practically inactive in admin work. The issues preventing various competent editors from seeking admin permissions should be addressed. There's no reason one should have to be a saint to get access (indeed, being a saint is rather suspicious imo), or should have to put up with excessive discomfort in the process for seeking permissions allowing them to spend more of their own volunteer time helping out. ProcrastinatingReader (talk) 11:31, 4 July 2020 (UTC)
For many years the problem has been that most people here recognise that there are problems with our existing processes, both for granting and removing admin tools, but there has been no consensus on any particular proposal for improving things, with some people opposing anything other than their own pet solution. More people need to recognise that the best is the enemy of the good, and support anything that is better than the status quo. Phil Bridger (talk) 08:17, 4 July 2020 (UTC)
It is a complex issue. Yes, we have just had a second month this year without a new admin. But it is still early July, and we have already had as many successful RFAs as the whole of 2018. Wikipedia:RFA by month at first glance looks like the documentation of a huge decline in RFA since the 2003/2007 era. But we have to remember that the many changes at RFA over the years include a number of unbundlings, most notably the unbundling of Rollback in early 2008. We now have far more rollbackers than admins, and if Rollback had been unbundled a couple of years earlier we would probably have rather fewer admins today. What has saved us as a community has been the stability of the admin cadre, hundreds of admins have remained active for a decade or more, and as long as we don't introduce term limits, we are likely to have many of our current admins and returning former admins for many years to come. We aren't replacing our admins as fast as they leave, and we haven't been doing so for about a decade. This is a problem, and if we don't fix it, eventually will become a crisis. It also gives us an unhealthy social dynamic, a wikigeneration divide between those who started editing in the last decade or so and who are rare in the admin cadre and an admin cadre many of whom became admins within a few months of starting editing. I would like to see more well qualified candidates standing, I'm confident that there are many members of the community who would easily pass RFA if they stood. The truth is that RFA's reputation is much worse than the reality, as evidence for that look at Wikipedia:Successful requests for adminship, it has been a while since an RFA passed completely unopposed, but we have far more with over 90% support than we have in or near the discretionary zone. I'd encourage established active editors to take a fresh look at RFA and to run when they feel ready. ϢereSpielChequers 09:45, 4 July 2020 (UTC)
Out of curiosity, what caused the number of RfAs to drop so sharply? It can't just be due to rollback being unbundled. Rollbacker was added in 2008, but the number of RfAs didn't plummet until 2011/2012 [1] ProcrastinatingReader (talk) 11:43, 4 July 2020 (UTC)
I know that, for me at least, the Template editor (est. 2013) and Page mover (est. 2016) permissions have given me most of the tools I need to be productive on Wikipedia, and reduced much of the need for me to request adminship. I assume that File mover had a similar effect for many editors in 2011. --Ahecht (TALK
PAGE) 18:14, 4 July 2020 (UTC)

In one post (but after 10 years of analysis) here how to fix the whole RFA mess plus 10 other problems

With the RFA process broken down, right now the main criteria for who is in the admin cadre is "got in back when it was easy". And the criteria for new ones is "kept their head low" / having avoided contentious situations. Impacts have already been felt and will get worse.

The root of the problem is that the admin function conflates these two things:

  • Type #1"no big deal" tool belt functions with
  • Type #2 other "big deal" "judge" type immense powers given to these folks. These include such as being able to sanction established individual editors, close complex and contentious discussions, defaco immunity from review of 99% of their behavior, and immunity from review of bad decisions that they make) This is conferred also by policies and practices, not just by software definitions of the tool belt.

With #2 blended in it really is a very big deal and RFA rightfully a very tough process. Not "random chaos" tough like it is now, but still rightfully tough

Step 1 is to separate them. This can easily be started informally. Start a "Yoda" (my word for it) class of admins with extremely strong and thoroughly proven credentials of thoroughness, fairness, avoiding emotional responses or decision making, self-control, excellent decision-making, immense experience, immense knowledge of guidelines, policies and how Wikipedia actually works. Also a record of always taking the high road. We only need about 20 or 30 of these. Evolve to a situation where they handle the tough behavioral cases and they become a routine appeal point for bad decisions by admins. This will solve a wide range of problems and make it closer to "no big deal" and 3/4 solve the RFA problem.

The other 1/4 of the RFA problem can be solved by structuring 90% of the RFA discussion instead of the random mess that we have right now. Determine what qualities are needed, and direct 90% of the discussion to whether they have those qualities.

Sincerely, North8000 (talk) 19:57, 4 July 2020 (UTC)

North8000, In an attempt to address your 1/4 of the problem, I wrote User:Sphilbrick/RfA reform a few years ago. I think it is still a valid improvement to the process. What do you think? S Philbrick(Talk) 22:47, 11 July 2020 (UTC)
Sphilbrick, might this not have the opposite effect? SCOTUS judges are highly scrutinised. And at WT:RFA people expressed discomfort with the idea of their entire Wikipedia history being ripped apart. Splitting RfA into committees to examine every inch of a person's contributions, to avoid missing the boondoggle trip, feels like it may have the opposite effect. It feels like it'd just result in more small issues being mentioned. ProcrastinatingReader (talk) 22:58, 11 July 2020 (UTC)
ProcrastinatingReader, I do understand the concern, but I don't think in practice it would be a problem. Importantly, I would view my proposed approach as an experiment and it could be easily abandoned if it simply turned into an organized way of identifying minuscule issues that might've been missed under the old approach. One thing that happened with the current approach is that someone takes a random selection of old edits, runs across an issue where the candidate either shows some lack of knowledge or is a bit incivil to another editor, and wonders whether this might be part of a pattern. If you only look at one percent of an editor's contributions and find one problem you might think to yourself this means there are probably 100 problems. but if a group of volunteers divide up the edits and I'll look at our group and they come away with only that one incident, or maybe one other, then you are no longer concerned that there may be 100 problems and therefore not a suitable candidate, we've identified two problems and except that no one's perfect. There are other issues with the RFA process, such as the gotcha mentality, and I don't pretend this approach will solve that, I was specifically addressing the concern about the "random mess" which I do think it's a problem and can be address by taking an organized approach to the review. S Philbrick(Talk) 18:33, 12 July 2020 (UTC)
Sphilbrick I think that you have the right idea. It's not exactly how I would do it but if I left it like that then we have the norm which is nothing ever like this ever gets fixed in wikipedia. Instead we should have a small group work out a final version along those lines and then all support it. Wanna do that? Without the separation which is the other "3/4" such a plan should address it as it "is a big deal" North8000 (talk) 19:24, 12 July 2020 (UTC)
Avoiding contentious stuff and keeping your head low isn't actually needed to get you through RFA today. People have got through in part because they have been involved in contentious stuff and handled it well. One of the problems with RFA is that there are at least three "third rails", one relates to the deletion button, another to content the third to the block button. Candidates can be rejected for being over deletionist, or more rarely for being over inclusionist, for lacking sufficient referenced contributions, and for their potential to be over eager with the block button, - as you said blocking established editors. Closing complex discussions other than deletion rarely gets mentioned at RFA. There are various problems with upbundling any of these to some sort of super admin, or even to agreeing some sort of admin criteria, the heart of which is that 41% can block a candidate from passing RFA even if 59% disagree with that reason for rejecting an RFA candidate. So the people who are in the successful minority of Opposers at RFA would lose influence over who became an admin if we developed a criteria for adminship where you needed consensus to make something part of the criteria, rather than needing 41% to make it a de facto part of the criteria. Plus remember that deletion is one of the third rails, deletion is a very commonly used tool for admins, so you can't take it out of the standard admin toolset, but deletion tagging and or AFD participation is not an area where it is going to be easy to get consensus on a threshold for RFA. ϢereSpielChequers 20:43, 12 July 2020 (UTC)

The Six-Series Prime Number Sieve

This is an idea for a prime number sieve which I came across this week. I'm not sure about its authenticity, but here's how it goes:

  1. 1. Write 2, 3 on top.
  2. 2. Write 5 ( = 2 + 3) and 7 ( = 22 + 3) below 2 and 3 respectively.
  3. 3. With 5 as beginning term and common difference 6, write an AP of the form 5 + (k - 1)×6 in a column below 5.
  4. 4. Do step 3 below 7 with 7 as the beginning term.
  5. 5. Starting with 5 in the first column, remove all numbers of the form 5 + (k - 1)×5×6 [except 5 (k = 1)]
  6. 6. Do the same with the other numbers coming under 5 (let the number be 'n') , by removing numbers of the form n + (k - 1)×6×n [except the numbers at k = 1]
  7. 7. Execute steps 5 & 6 under the column of 7, starting with 7 as the first number used.

I tried this algorithm and found that only prime numbers appeared to be coming out of the sieve. What I want to know are the following:

  • Has this algorithm ever been discovered before ?
  • If not, how efficient is this algorithm ?
  • How efficient will this be once translated into a computer program ?

— Preceding unsigned comment added by Sam Ruben Abraham (talk • contribs) 05:31, 8 July 2020 (UTC)

This question is already on the maths desk, so need for us to address it here. Graeme Bartlett (talk) 06:44, 8 July 2020 (UTC)

Adding reply buttons

Hello, I think there should be added buttons like "reply" or "add a comment" so that you don't need to edit source for that, while keeping this option of course. Users will be automatically notified when their comment is answered and also you can add automatic signature.--DonGuess (talk) 19:52, 4 July 2020 (UTC)

@DonGuess: I am replying to you now using a "reply" button. They are currently being tested, but you can enable them manually by adding ?dtenable=yes to the end of the url, or by adding:
mw.loader.load( 'ext.discussionTools.init' );
to your Special:MyPage/common.js page. The only thing that it doesn't do yet (and you can share feedback about it at mw:Talk:Talk pages project/replying) is automatically notify the person you are replying to. To notify them, you still need to use {{ping|PERSON'S USERNAME}} like I did in this post. --Ahecht (TALK
PAGE) 20:43, 4 July 2020 (UTC)
Se also: WP:REPLYLINK >>BEANS X2t 08:51, 14 July 2020 (UTC)

Add a "download" button for sample code

I several articles (this one for example), some example code is featured to help understand, or provide a minimal working example. If the user wants to run it, the code needs to be copied and pasted into a new file, then saved with the proper extension. The idea here is to add a "download" button just above (or below) the implementation, that would allow the user to directly save it as a file with the proper extension (.py for python, .js for javascript ...) --Rphad (talk) 12:16, 13 July 2020 (UTC)

@Rphad: Wikipedia:What Wikipedia is not#Wikipedia is not a mirror or a repository of links, images, or media files includes source code. We do have some source code samples but they should be limited per Wikipedia:WikiProject Computer science/Manual of style#Code samples. I think a download feature for source code would send the wrong signal and encourage some users to add bundles of unwanted source code. We are an encyclopedia with six million articles and this is a tiny part of us which doesn't require a special feature when readers can just copy-paste the few actual source code samples we should have. PrimeHunter (talk) 07:47, 14 July 2020 (UTC)

New Wikipedia Sub-Category - Cybercrime Incidents

Subject : New Wikipedia Sub-Category - Cybercrime Incidents

With the enormous amount of cybercrime currently being committed, (including by large and powerful nation states), I have been wondering if it might be possible to record the incidents in one place, for people to be able to better understand the trends and to help improve computer security procedures ?

Because of the enormous number of incidents, (going back to before the creation of the World Wide Web), I think that it would be impossible for any single person to compile a list of incidents on their own, I am therefore wondering if Wikipedia could be used as a way to accumulate such a large and complex record, using many different contributors as is the standard method of Wikipedia ?

But because of the criminal nature of the subject matter, it would probably be necessary to have some barriers in place, to prevent published information from being removed or altered by unscrupulous people ?

The Wikipedia gathered information obviously should be publicly accessible and searchable, just as other Wikipedia Web pages are ?

Whilst Wikipedia already has some information about cybercrime, it far from a comprehensive or exhaustive list, so I think that what I propose would be a significant improvement.

I envisage the cybercrime section of Wikipedia as being separate from the general Wikipedia articles, and being a separate section, just as there are already some other sub sections of Wikipedia, such as for Travel or for Quotations.

While such a website might encourage cybercrime or help to make its techniques more accessible, the aim is to help people improve computer security, and make it easier for companies involved in computer security to improve their methods, and to reduce the vulnerabilities of computer users.

I hope that you will be able to help to develop this type of resource, so that the current very poor situation might improve.

Best wishes. — Preceding unsigned comment added by WikiWikiWonderful (talk • contribs) 14:19, 14 July 2020 (UTC)

@WikiWikiWonderful: Wikipedia, Wikivoyage and Wikiquote are different Wikimedia projects run by the Wikimedia Foundation. The others are not subsections of Wikipedia. The place to propose a new Wikimedia project is meta:Proposals for new projects but I don't see this getting approved. PrimeHunter (talk) 18:56, 14 July 2020 (UTC)
We do have Wikipedia:WikiProject Computer Security which is just for improving our encyclopedic articles. PrimeHunter (talk) 18:59, 14 July 2020 (UTC)

Proposal also posted here : https://meta.wikimedia.org/wiki/WikiCybercrimes — Preceding unsigned comment added by WikiWikiWonderful (talk • contribs) 09:26, 19 July 2020 (UTC)

And we also have Category:Cybercrime with many subcategories if you want to look for what is there already. Graeme Bartlett (talk) 11:58, 19 July 2020 (UTC)

Stronger policies against (undisclosed) paid editing

Leading on from this AN discussion, numerous editors stated they'd like to see changes to the paid editing policies. Some expressed a preference for banning paid editing entirely (which was recently discussed here). Perhaps a section at the idea lab will be useful to get some thoughts on appropriate policy changes to deal with paid editing problems, aside from banning it entirely, or empowering admins further to deal with UPE. Slight discussion fork, but probably more appropriate here than at AN. ProcrastinatingReader (talk) 01:00, 13 July 2020 (UTC)

  • New CSD: Perhaps a new article CSD to be able to delete products of UPE? Currently, the editor can be blocked and the article draftified, I suppose, but I don't believe it can be deleted? In most cases, it isn't even draftified, and the editors don't tend to be blocked either. There's various cases where an article is pretty obvious UPE, so a paid editing notice is placed on their talk, then they go inactive and don't get blocked, and their article sticks around or, in some cases, gets chucked into AfD at some point (which itself can be hit or miss, especially since many of these UPE articles can be notable, and sometimes aren't unambiguously G11). Perhaps a new CSD category which allows deletion of likely UPE articles? There's often a noticeable difference between non-UPE SPAs and UPE SPAs. I guess this would need more thought to meet the WP:NEWCSD criteria, particularly (1) and (2).
Another suggestion was made by MER-C for a PROD-like process, where suspected UPE articles are added to a COIN-like page, where editors can pick them up and fix them, or they can be deleted by an admin after some days (like PROD, except the submitter can't remove the tag). ProcrastinatingReader (talk) 01:00, 13 July 2020 (UTC)
I like the PROD idea more. COI detection is too messy to work as a CSD category, especially for articles that don't meet G11. signed, Rosguill talk 01:27, 13 July 2020 (UTC)
Rosguill, only concern I had with the PROD-like idea is that it shouldn't be a process where editors are encouraged (or even asked) to clean up the mess. Also, G4 should be amended to permit deletion for articles recreated which were deleted by this process, if a new article is created with practically the same content by another SPA (it shouldn't be kept live for another 7 days). And it should be applicable to drafts.
Alternative to this hypothetical process, AfD could be permitted to consider if is it likely a product of UPE, and if so, also consider criteria like is it promotional (promo that isn't quite G11 but still promo), being allowed to overlook notability in these likely UPE cases. Use a separate deletion list to feed the discussions into COIN or so.
In either system, if the article is notable, someone else can create it (likely in a less promo way). I don't think UPE should be rewarded with volunteer editors cleaning up and making encyclopaedic their mess. But I'd be equally happy with any of these solutions. Any process which allows standard policies like notability to be forgotten, and allows likely UPE content to be deleted is good imo. Since both of these processes can be contested and are transparent they won't have the same issues as a UPE CSD. And, of course, DRV could overturn. ProcrastinatingReader (talk) 02:09, 13 July 2020 (UTC)
A CSD criterion for UPE creations has failed to find consensus multiple times. Look into the CSD archives. I do not really understand the point of a PROD that does not encourage editors to fix the problems; that's just a CSD with a 7 day delay. A sticky prod without judgement on what editors might do with the page generally is more sensible. I do think allowing AFD to consider that an article is a UPE creation is probably reasonable, though I would guess that already happens in some minor degree. I don't think overriding is the correct direction though. I'm not sure ehat the best direction is. --Izno (talk) 02:51, 13 July 2020 (UTC)
Seems like much of the opposition to the CSD[2] included (a) not expanding G5 but instead making a new CSD, (b) too much discretion on what is UPE, (c) should be delayed [to allow time to disclose?]. Seems like proposal #2, if it addressed issues (a) and (c), might have had enough support to pass.
AfD can consider UPE, but it's not really an overriding reason. If the article is otherwise notable, and not complete promo, it might just be kept. Currently, policy wise, it's not clear that being UPE qualifies for deletion alone. ProcrastinatingReader (talk) 10:44, 13 July 2020 (UTC)
  • One problem is that spotting that an article is about a business or product is usually easy while spotting that an editor has an undisclosed conflict of interest can be quite hard. So it is much more practical to focua on the sorts of articles that spammers are likely to create. A Sticky Prod for currently trading businesses would solve a lot of problems, especially if the rules for removing that sticky prod were two reliable sources independent of the subject. ϢereSpielChequers 07:16, 13 July 2020 (UTC)
  • Outright prohibition wouldn't really aid the combat rate. I support either a CSD, or potentially a PRODUPE (obviously pronounced "pro-dupe") but that would depend on its setup. Even with the change to increasing numbers of freelancers (vs cohesive UPE organisations), I'm concerned that just requiring any non-submitter to remove would be near pointless. It comes with negatives but either Extended-confirmed edit filter on removing those tags, or a setup on replacement Nosebagbear (talk) 08:48, 13 July 2020 (UTC)
  • One of the key things that makes the {{copyvio}} tag sticky is that the article is manually listed at Wikipedia:Copyright problems. The spammer will need to remove both in order to stop the page from being deleted. It also says "do not restore or edit the blanked content on this page until the issue is resolved by an administrator, copyright clerk or OTRS agent." UPE tags should not be removed unless by trusted users, simply because the risk of sock/meatpuppetry is too high. Wikipedia:Copyright problems admits pages in any namespace. MER-C 09:45, 13 July 2020 (UTC)
    Another upside of the {{copyvio}} tag is that it blanks the offending content and places NOINDEX on the article, therefore stopping the content from getting into Google. MER-C 11:42, 13 July 2020 (UTC)
  • Other possible amendments to the paid editing policy are to add sections stating "disclosure is necessary but not sufficient" and forbidding content review. See User:MER-C/Paid2019. The commercial editing proposal is under discussion elsewhere. The remainder of the page is for sanctions targeted at spam-prone areas. MER-C 10:22, 13 July 2020 (UTC)
    MER-C, I quite like the spirit of the proposals at Paid2019, and the topic list. It's very comprehensive, whilst not overly broad. Plus, DRV has review ability, which aids accountability. I don't think any proposal will be effective unless enforcement measures are added, so it's nice that yours does that. My only concern is that community sanctions tend to require notification prior to any action, and violating actions have to be conducted after notification. But when you consider that paid editors tend to use disposable accounts a ban on article creation seems less helpful, and since they will probably just go inactive (or pick up another account) it seems like we won't even be able to delete the already-created article under these sanctions. eg look at Gambling.com, textbook UPE behaviour, and the paid editor has disappeared while we waste editors' time at AfD and give this article a platform for 7 days. Under Paid2019, I don't think we could've done anything to this article we haven't already done. It should've been draftified imo, but then we can't AfD it, so that in itself needs to be addressed imo. Unless admins are given more power to delete this nonsense sooner, despite reservations against giving that power, I think this is always going to be a losing battle. ProcrastinatingReader (talk) 11:04, 13 July 2020 (UTC)
    Not all spam involves creating articles, and this is where GS and general prohibitions can help. Notification is necessary only for sanctions actions which apply to users. Right now, I don't need to notify anyone if I'm going to protect an article under a sanctions regime, nor should I have to notify if I'm deleting something. It is, of course, good courtesy to do so and that good faith creations go to draft space or get kept instead of deleted immediately. I can also block spammers as a normal admin action (and indeed in the example you cite I did so yesterday). There should also be an edit filter or something that triggers a warning if certain words appear in the first few sentences of the article. MER-C 11:21, 13 July 2020 (UTC)
    MER-C, sanctions can't allow for deletion though, right? (per [3]). I'm really against the fact that this product of UPE gets a platform for 7 days in the mainspace, and editors have to waste their time at AfD on it. imo one goal in this discussion should be to create some other way for an admin to be able to delete this article. ProcrastinatingReader (talk) 11:35, 13 July 2020 (UTC)
    This proposal explicitly permits the use of deletion to enforce these sanctions. MER-C 11:42, 13 July 2020 (UTC)
    Ah, I see. Some other questions, but I'll move to the talk there re. Paid2019 explicitly. ProcrastinatingReader (talk) 11:48, 13 July 2020 (UTC)
  • ProcrastinatingReader great idea. MER-C that list of changes looks excellent. And something like the copyvio process for tagging, unindexing, and double-entering problematic PE (a good DUPE shortlink would be appropriate) seems helpful.
There is a related problem that often a disclosed PE has undisclosed supporters who back up and implement questionable proposals. We also need an estimate of the scale of PE in proportion to total editing; when it crosses a certain threshold, consensus and !voting mechansims across the project stop working. – SJ + 14:01, 15 July 2020 (UTC)

List of individual ideas to combat Undisclosed Paid Editing

I've created a summary list of various ideas to combat UPE that have been proposed, mooted, rejected and so-on.

It's currently at an add-on/idea stage, more details on which can be seen at the page. Please feel free to add your own, tweak the summaries or leave an initial comment on the idea (any that are universally panned will be filtered out before taking forward to RfC).

Many of the proposals are deliberately not fully formed, to avoid submitting an unwieldly large amount of policy thoughts all at once. Proposals passed by the community that need further details (such as a "mystery-shopper" counter-UPE method) would be expanded by those interested and resubmitted on its own.

Please invite anyone you think might be interested. Nosebagbear (talk) 15:23, 21 July 2020 (UTC)

Bot to fix minor common punctuation syntax errors

From time to time I'll find articles that have either a ref tag misplaced before a period (ex: This was what happened<ref></ref>.) or the ref tag is preceded by an extra misplaced space (ex: This was what happened. <ref></ref>) Is there a punctuation bot that can be used to hunt for and fix, upon operator confirmation, all occurrences in the articles? If not, would this be hard to create? The character strings ">." or ". <" rarely occur unless by accident. Of the two, the latter is the easier to fix, replacing ". <" with ".<". Replacing ">." would be more complex, requiring the bot to not only remove the period, but go back two "<"s, and add the period, making it ".<". TimTempleton (talk) (cont) 21:58, 21 July 2020 (UTC)

WP:AWB general fixes does all these changes already. --Izno (talk) 22:42, 21 July 2020 (UTC)
My understanding is that a bot that only makes cosmetic changes is forbidden. RudolfRed (talk) 04:12, 22 July 2020 (UTC)
This is not a cosmetic change. --Izno (talk) 12:50, 22 July 2020 (UTC)
@Izno: Thanks - that's what I was looking for. It appears that there is an option to add random pages to the list of articles to repair. I'll have to dig in some more. TimTempleton (talk) (cont) 18:20, 22 July 2020 (UTC)

Description in the Wikidata for Wikipedia desktop version

In the mobile version of Wikipedia, the description of the article contained in Wikidata is shown just below the title. Is there no possibility to import this into the desktop version? I've seen some vandalism, but the desktop version is difficult to patrol. ✍A.WagnerC (talk) 17:22, 22 July 2020 (UTC)

See Wikipedia:WikiProject Short descriptions#See the short description in desktop view — GhostInTheMachine talk to me 20:07, 22 July 2020 (UTC)
@A.WagnerC: Viewing descriptions is not currently available by default on desktop Wikipedia (the WMF is supposedly working on an "official" solution to that, but we've heard very little about when that is expected to release), but the Shortdesc helper gadget can be enabled instead and it allows you to both view and edit Wikidata and locally defined short descriptions. When enabled, it adds the descriptions to a line just below the title along with options to quickly edit, import, or export them. Notably, Shortdesc helper also doesn't break the metadata gadget like the old short description gadget did, which is also really nice. Nathan2055talk - contribs 21:13, 22 July 2020 (UTC)

How to jumpstart AfD?

The biggest problem I see with WP:AfD (probably all XfDs, but AfD is the one I pay most attention to) these days is declining participation. I certainly don't want to go back to the bad old days where a discussion consisted of 20 or 30 bare keep or delete votes with no policy arguments to back them up, but many AfDs these days are closed with just 3 or 4 participants, and that's not enough to form a real consensus. Every time I write at WP:DRV, The AfD was well attended, by today's standards, a little piece of me dies. With so few voices, it's way too easy for partisan editors to swamp the discussion and then we're right back to VfD-style popularity contests.

So, any thoughts on ways to increase AfD participation? We also need to provide education about how to intelligently evaluate articles, but for now, I'm more thinking about how to get people involved in the first place. Talk it up in The Signpost? Some sort of gamification approach with barnstars, userboxes, and awards? -- RoySmith (talk) 15:18, 29 June 2020 (UTC)

The lack of participation worries me too, for the same reason, but we want to encourage thoughtful participation, based on actually looking for sources, rather than the comments that show that the writer hasn't done anything other than glance at the article (if even that). I'm worried that any gamification would lead to people treating the game as more important than the encyclopedia, leading to such low-quality contributions. One thing that strikes me is that there are many discussions that only attract a couple of comments, but a few that attract lots. Maybe there's some way to point people who want to contribute to the poorly-attended discussions rather than have them follow the crowd to the few that are already highly-attended. Phil Bridger (talk) 15:56, 29 June 2020 (UTC)
I agree there is a problem, but I think a lot of editors (including me on my rare visits) don't bother adding to discussions with a couple of firm delete votes on what seem to be good and clear grounds, especially on articles outside their area of expertise. I suspect the questionable results are more often at discussions with an above average number of participants. Johnbod (talk) 16:11, 29 June 2020 (UTC)
A large part of it is that the AfD notice has no clear call to action. The only text that can even be remotely interpreted as such is please feel free to share your thoughts which isn't linked. I can't tell you the number of times that I've clicked on the link to the deletion policy, which is the only link in the bold first sentence, instead of to the actual discussion, which is hidden away almost as an easter egg. Something like:
might make it clearer what the reader should do and where they should do it. --Ahecht (TALK
PAGE) 16:20, 29 June 2020 (UTC)
Ahecht, I like that a lot. Right now, the link to the AfD discussion is the second link, labeled, "this article's entry". I know what that means, but your version is a lot more obvious.
But, that gets people who are already interested in that article to come discuss it. I was thinking more along the lines of increasing the pool of editors who patrol AfD on a regular basis. -- RoySmith (talk) 17:37, 29 June 2020 (UTC)
+1, I like this revision. signed, Rosguill talk 19:03, 29 June 2020 (UTC)
+2, though I think that horizontal rule is unnecessary. SD0001 (talk) 12:00, 17 July 2020 (UTC)
  • Interesting question. I think AfD currently being a big pit is a bit of a barrier. Some articles are so hopeless that saying more than "delete not notable" is just a waste of time, because it's so obvious something isn't notable (WP:KEEPCONCISE). I enjoy the AfD discussions which have interesting policy grounds and make for a good discussion, but so many in AfD are just so hopeless that it's a waste of time and not appealing to comment on. In that regard, I respect and see the need for some AfD participants who simply reply with a few words. I'm not a fan of giving more discretion to CSD, of course, so this isn't a problem easily fixed. But I think it's the nature of AfD that some AfDs will have more discussions than others. There are regularly ones with half a dozen or more responses. And there are regularly ones that get relisted 2x and still only have 1-2 responses. One other big barrier is cultural: sometimes I'm not comfortable with voting on an article that may be notable, but I wouldn't be able to assess it quickly/accurately due to language and cultural barriers. In this regard, encouraging increased participation from relevant WikiProjects, and encouraging users to participate in WikiProjects more, may be of help? ProcrastinatingReader (talk) 17:18, 29 June 2020 (UTC)
The number 1 step is to make sure Wikiproject tags are on the talk page so it gets picked up by WP:AALERTS. Headbomb {t · c · p · b} 18:49, 29 June 2020 (UTC)
  • Yes: maximising the visibility to people interested in the article topic is definitely beneficial. I think Twinkle's AfD process was recently enhanced to encourage easy "List of blah discussions" cross-posting but without wanting to add to effort, it could also be worth encouraging the nominator to add relevant projects to the Talk page as part of WP:BEFORE. AllyD (talk) 08:02, 5 July 2020 (UTC)
  • Increasing the number of PRODs might help. Most AfDs with a handful of unanimous delete comments could probably have been handled as PRODs. Possibly we could recommend using PROD for any situation where the nominator doesn't have a reason to think someone will object to deletion. Hut 8.5 18:58, 29 June 2020 (UTC)
    I don't know how much of a difference this would make in practice: in my experience, editors are MUCH more likely to remove a PROD tag than to participate in an AfD, to the point that I've seen several instances of editors who decline to participate in an AfD despite having previously removed a PROD on an article. signed, Rosguill talk 19:02, 29 June 2020 (UTC)
    PROD is a bit of a mess too. It is meant to be only for obvious, uncontroversial deletions, but often articles are nominated just because they are poor quality or poorly sourced, with no attempt to check whether the subject is notable. Aymatth2 (talk) 20:06, 29 June 2020 (UTC)
  • Recently I have been considering proposing the opposite of Hut 8.5's suggestion, as I feel that the option nowadays of a WP:SOFTDELETE AfD closure along with AfD's visibility and discussion format is better than PROD. What has been putting me off, though, is that large numbers of AfD's are rattling round multiple 7 day circuits with minimal participation. AllyD (talk) 07:12, 5 July 2020 (UTC)
  • That will make this problem a lot worse. There are currently 263 articles proposed for deletion, which equates to 2-3 days' worth of AfD logs. If we push PRODs to AfD we will just spread the limited number of participants even more. Hut 8.5 09:28, 5 July 2020 (UTC)
  • I agree with Johnbod's comment - I actually have internal rules on when not to participate, in order to avoid a pileon, and they sound like they might well be low compared to old school levels. Close-fought discussions often do build up in length (20 is rare but certainly occurs, 10 is quite common for tightknit discussions) Nosebagbear (talk) 15:04, 30 June 2020 (UTC)
  • Support the AFD template change proposals as they could see an improvement in accessibility to the discussions and therefore boost participation, imv Atlantic306 (talk) 22:46, 30 June 2020 (UTC)
  • Participating in AfD discussions involves significant effort: reading the article on an unfamiliar topic, following its basic Google search links (and repelling the various publications that dislike your adblocker, want to sent you notifications for the rest of your life, etc.!), possibly banging them through Google Translate, then considering what other search variant terms may yield better returns - all of this checking often just to confirm to yourself that you will not be being unfair to offer a delete opinion. This expends a lot of effort with little to show for it, so it is little wonder that there are articles going around multiple relists without participants. It is difficult and I doubt whether any kind of gamification can mitigate that. AllyD (talk) 07:48, 5 July 2020 (UTC)
  • Recently in AfDs I have found myself more often recommending redirects, which preserve the history and involve far less effort than a full AfD discussion. I wonder if this option is currently buried too deeply in WP:BEFORE, where it is step C4? Increasing its visibility as an option could reduce AfD workload/fatigue. AllyD (talk) 08:14, 5 July 2020 (UTC)
  • Support, the banner should be improved as Ahecht proposed. Ludost Mlačani (talk) 20:56, 13 July 2020 (UTC)
  • I recently developed a fun tool that displays all AfD nomination statements and shortdescs on one page, sorted by topic (using ORES). Check it out: User:SDZeroBot/AfD sorting. I myself have increased my Afd participation as a result of this. SD0001 (talk) 12:08, 17 July 2020 (UTC)
  • The proposed template above is a very good suggestion and we should run with it as a minimum. Also - everything about the AfD templates sucks. The first time I created an AfD was in 2006 (for real 👴 points, my first time at VfD was in 2003), but I still have to read the nomination template documentation Every. Single. Time. Fixing that won't magically improve participation, but the whole process is a deeply retrograde experience that needs to be dragged into 2020, possibly at the MediaWiki level.  — Scott • talk 17:18, 23 July 2020 (UTC)
    Scott, We have a lot of processes which require tons of manual editing, and I agree that it sucks. Fortunately, we have things like WP:TWINKLE to automate creating AfDs, and WP:XFDcloser to process them. Anybody who doesn't use those tools is just nuts, but first you need to be aware that they even exist. WP:AFDHOWTO has buried down in about the 4th paragraph, "To nominate a single page for deletion, you can use Twinkle, or follow these three steps". Commons at least has a "Nominate for deletion" link in the navbar.
    What it should do is just have the Twinkle link right up front, and the rest of the crap hidden in a collapse box labeled, "The gory details, for people who care about such things".
    WP:DYK is much the same. I dread every DYK nomination I make because I know I'll need to slog through another series of fiddly manual edits with complicated templates. The hard part should be writing the article, not doing the paperwork. -- RoySmith (talk) 01:48, 24 July 2020 (UTC)

Wikipedia award ceremony

To make things interesting let award our editors let make an award ceremony to give reward to editors. barnstars are giving any time by users. Let form an award commitee who will every year set up an award for editors. Users may vote up other users for this award and could also nominate each other. We can give award such as longest wikipedia staff and many other awards.Tbiw (talk) 09:16, 11 July 2020 (UTC)

Tbiw, you're describing something very similar to WP:EOTW. Cheers, {{u|Sdkb}} talk 20:56, 12 July 2020 (UTC)
Not really; Editor of the Week is a low-stakes, essentially slightly fancy barnstar. isaacl (talk) 22:52, 12 July 2020 (UTC)
High profile community awards are a bad idea, the amount of drama generated would far outweigh any motivational benefit. signed, Rosguill talk 01:21, 13 July 2020 (UTC)
Perhaps you meant to respond to the original post? isaacl (talk) 01:38, 13 July 2020 (UTC)
This threading felt more natural to me, I dunno. signed, Rosguill talk 01:56, 13 July 2020 (UTC)

@Rosguill talk,I get you point if award are given to section(best wiki of the year e.t.c) will discourage other. Give your barnstar(anytime), editor of the week(weekly). All awards can be presented even we can give out statistics that day. Joint award is great it boost work when a is given b will work to win it next year and their will be nominations to determine even you can nominate 100 or more for a single award and you will keep dropping until the best is chosen. It can be through a vote or selection by a proposed award committee or other. It doesn't discourage it encourage.Tbiw (talk) 08:34, 13 July 2020 (UTC)

The following discussion is closed and will soon be archived.
  Moved to propsals

Notability for experts in their field

I was wondering about notability for experts in their field whose opinions are relied upon by news sources. For example, I created an article for Samantha Vinograd who is the national security analyst for CNN. She has some other accomplishments in life but they really do not make her notable. However, I feel that since her opinions are solicited by CNN and she writes for a number of national papers, and she appears on CNN on an almost daily basis, that would be sufficient for notability. I created another one some time ago (which was deleted) for an attorney in real estate who was cited 100s of times by the NY times as their go-to expert, but he was deleted as not-notable. I think it is helpful for the general public that they know who the expert is and what they are about especially for people who are appearing in the news. Does anyone have any thoughts? Patapsco913 (talk) 17:43, 26 July 2020 (UTC)

For the stance of writing an article on WP, we'd need more than the fact that CNN /etc. use her as an expert source. That they consider these people experts suggests there should be something in their background to explain why they are experts so that would be reason to search out that sourcing to support it, but I would not go on just the basis of being named an expert by media. --Masem (t) 17:48, 26 July 2020 (UTC)
IMO "experts in their field whose opinions are relied upon by news sources" meet WP:NJOURNALIST 1: "The person is regarded as an important figure or is widely cited by peers or successors." Based on interactions with Levivich at Wikipedia:Articles_for_deletion/Samantha_Vinograd, this isn't as simple as I initially thought. "Widely cited by peers" (peers being journalists in this case) requires citations of the journalist's work to be published by multiple independent RS, whose reliability is endorsed by WP:RSP. HouseOfChange (talk) 23:04, 27 July 2020 (UTC)
Yeah but that guy Levivich is a notorious deletionist with a hardline view of non-GNG-based notability, so I'd take anything he says with a grain of salt.   To the OP, there does seem to be this class of BLP where "notability" can be established with sources that don't meet GNG but do meet an SNG (like NPROF 7 or NJOURN 1), but those sources aren't very helpful for writing an article, because they're examples of the subject's work being cited but they're not about the subject herself. Meanwhile, a Wikipedia article can be written using ABOUTSELF sources (like employer bios), but those sources aren't helpful for establishing notability. So the subject sort of falls in between. This is where is see GNG-independent SNGs like NPROF as being useful. (NJOURN isn't one of those, though.) The AFD discussion with HoC makes me wonder if NJOURN should be amended to add the words "or widely published". Just like an author who sells a lot of books is likely to be notable, a journalist who is widely published seems likely to be notable as well. Levivich [dubious – discuss] 23:24, 27 July 2020 (UTC)
Patapsco913, if you had to write an article about this person, using exclusively Wikipedia:Independent sources, would you actually be to write an encyclopeda article about this person? Or would the results sound a bit like 'got quoted in Source on foo in 2015 when she worked for X, got quoted in Source on bar in 2016, got quoted in Source on baz in 2017...'?
WP:WHYN explains why we have standards, and it's not about excluding people. It's about whether it's possible to write a neutral article. WhatamIdoing (talk) 18:41, 1 August 2020 (UTC)

Only allow mainspace edits to qualify towards being autoconfirmed

Currently, the only requirements to become autoconfirmed is to have an account for at least 4 days and 10 edits in any namespace. However, recently, I have witnessed a LTA spam nonsense edits in their user pages to become autoconfirmed and cause disruption in COVID-19 related articles. This is why I propose an additional requirement to the edit count towards becoming autoconfirmed, being that those edits have to be in mainspace. This way, more scrutiny can be put on new users' edits and make sure that they are here to build an encyclopedia. SuperGoose007 (Honk!) 00:41, 1 August 2020 (UTC)

Good idea NewsAndEventsGuy (talk) 01:20, 1 August 2020 (UTC)
This has been proposed before. It would be nontrivial to change how the software works to accommodate. I don't remember if there were other reasons the proposal was rejected. --Izno (talk) 02:53, 1 August 2020 (UTC)
I doubt that this would actually reduce the number of accounts that attempt to game autoconfirmed. Instead, what I suspect will happen is the autoconfirmed gaming will simply move to adding unnecessary commas, whitespace, and other trivial edits to the mainspace, which is problematic because now these edits are affecting reader-facing content. If the user wants to game autoconfirmed, might as well have them do it in their userspace—it's easier to spot, anyway. Mz7 (talk) 04:28, 1 August 2020 (UTC)
What Mz7 said - it's what people already do, and they'll just do more of it. Many of these 'minute changes' are grammatically incorrect too. So aside from the technical issues Izno mentions, this is likely to just lead to more crappy edits in the mainspace. Since they'll game it anyway, it's better to have the crap in userspace rather than mainspace. ProcrastinatingReader (talk) 11:52, 1 August 2020 (UTC)

Becoming an edit filter manager vs interface admin

After closing this discussion, I'd like to get ideas on the process of becoming an edit filter manager vs interface admin. They are both highly sensitive rights. The difference between them is that for edit filter manager, admins can self-grant that right at their discretion. Interface admins have to go through a community based process to be granted that right. I would like to know if they should have similar processes on granting and removing. Interstellarity (talk) 22:22, 28 July 2020 (UTC)

A relevant distinction here is security risk. It is difficult to understate just how sensitive interface administrator access is. Interface administrators have the ability to execute JavaScript code on the browsers of every single Wikipedia reader—even all at once (see MediaWiki:Common.js). A malicious interface administrator could potentially use this ability to compromise accounts, mine cryptocurrencies (see [4]), or cause a user to do things they didn't intend. From a security standpoint, interface administrator is probably the most sensitive right we have, above oversight, checkuser, and edit filter manager (perhaps second only to steward access, since stewards can make themselves intadmins). Against this backdrop, it seems reasonable that there should be at minimum a brief vetting process to ensure that those who have intadmin access truly need it. For edit filter manager, while it can lead to highly visible mistakes, historically I don't think we've had much of an issue allowing administrators to self-assign, judging for themselves whether they are competent enough to use the tool. Mz7 (talk) 01:32, 30 July 2020 (UTC)
EFM allows you to break edit filters (for the most part). IA allows you to break literally everything but Special:Preferences. --AntiCompositeNumber (talk) 02:29, 30 July 2020 (UTC)
That being said, that mail suggests the change on fawiki was reverted in 7 minutes. How long would it last on enwiki? Unless you do it at the right time of day, probably less. IA changes are reversible, and quickly. I'm guessing common.js isn't loaded on Special:UserLogin? If so, certainly doesn't appear as sensitive as, say, oversight, which allows you to go back and view any number of suppressed content. Not to mention, some overzealousness as CU is likely to get your perms revoked, but certain malicious IA behaviour on enwiki and I imagine WMF's counsel would be obligated to pursue that. Hence, I don't really think being really prickly over IA is reasonable. ProcrastinatingReader (talk) 13:44, 30 July 2020 (UTC)
We are not really picky over it, it is pretty much shall-issue. — xaosflux Talk 13:50, 30 July 2020 (UTC)
Right, I wasn't suggesting becoming more picky or more restrictive about how we grant intadmin permissions, but I did want to comment on the distinction between the permissions from a security standpoint. Think about it this way: an interface administrator can modify not just MediaWiki:Common.js, but also the personal JS pages of every Wikipedia editor, some of which aren't that closely watched. If an interface admin account is compromised, it is not implausible to imagine a situation where they add malicious JS to cause a CU to run a check as soon as they log in and send the results to a third party website controlled by the attacker, or similarly leak the details of suppressed revisions. Mz7 (talk) 14:57, 30 July 2020 (UTC)
IMO we should solve this problem by requiring standard code review procedures. That means creating a way for IA #1 to make a change (just like it happens now), but it doesn't go live until IA #2 checks it and approves it. WhatamIdoing (talk) 18:45, 1 August 2020 (UTC)
  • The problem with this discussion is that it's just proposing a solution without a problem, and it's bound to drift to various things as people have no unifying topic to speak for or against. I don't think it's different than the withdrawn discussion that quickly garnered a lot of opposes (save for the location), because the proposal was out to remedy a problem that does not exist. Instead of directly giving a solution, please state the problem of the current procedure, then later you (or preferably other people) may suggest solutions if they are convinced that the issue is indeed a problem. – Ammarpad (talk) 05:45, 2 August 2020 (UTC)

A bot to notify previous AfD participants?

I often see people express disappointment/frustration when they participate in an AfD, but aren't aware of a second AfD of the same article. I've long wondered why notifying participants of the previous discussion isn't standard procedure (if not by the nominator, then by someone else). I know that when I participate in an AfD, it typically requires at least some amount of research and thought, which would seem to position me to be helpful to a second discussion. Certainly when an AfD is plagued by SPAs/socking, that complicates things, but has anyone ever proposed a bot that would automatically notify previous participants? — Rhododendrites talk \\ 14:26, 3 August 2020 (UTC)

Rhododendrites, with the caveat that I don't spend a ton of time at AfD, this seems like it would be helpful. Take it to WP:BOTREQ? {{u|Sdkb}} talk 23:19, 3 August 2020 (UTC)
  • I am not sure of others, but for me I don't like being notified of second AfD of any article just because I participated in the first one maybe some ages ago. So please, if this ever materializes, make it explicitly opt-in, so that the message should go to people who need it.– Ammarpad (talk) 05:33, 4 August 2020 (UTC)

Navboxes and mobile devices

In a tangentially related thread (about SeeAlso sections) at Talk:MOS/layout, Izno made the comment that Navboxes do not show on mobile devices by design, and the first reason is to reduce mobile users' bandwidth. The other reason the difficulty in designing them to display well.

QUESTION - Is there an option in preferences (or script) to turn off NavBoxes when people just don't want them for any reason?

OBSERVATION - If there is no such preference option, it would be easy to provide one. And that solves the mobile device bandwidth problem.... mobile users (or anyone else) could toggle Navboxes to suit their needs.

IDEA - So the remaining question is whether enough mobile users would use NavBoxes from time to time to warrant the labor of figuring out how to display them. One way to find out would be a survey of some sort.

That's as far as my thinking went. Fire away, thanks for reading. NewsAndEventsGuy (talk) 19:36, 25 July 2020 (UTC)

There is no way to change this from the user side. They don't even come down the wire to your device at present (hence bandwidth savings). A script or style solution would require the content to come down the wire. No comment on the other issue, but good luck. The phab task of interest would be phab:T198949 probably, which is a recommendation from an SEO audit 2 years ago, but as you can see, it's an increase of 20% bandwidth to add these back as they are now. --Izno (talk) 21:05, 25 July 2020 (UTC)
I presume you're referring to mobile devices in this question, too. In which case, unfortunately no, this isn't possible without a software change to MediaWiki. Even if you use a script, it'd only work in desktop mode. ProcrastinatingReader (talk) 21:14, 25 July 2020 (UTC)

Followup questions then. I'll preface this with a disclaimer... I gave up coding a long time ago so bascially don't know what I'm talking about here. But generally, why have NavBoxes offered as Templates that force html to load, whether its wanted or not, instead of replacing NavBoxes with simple links to relevant Indices of articles or maybe Outlines of topic? Functionally, the info would still be there, it would just load as a separate page and only if the user requests it by clicking. For NavBoxes that are collapsed by default, the user has to click anyway, so that bit of inconvienence is a very little bit. But who am I kidding? I'll bet this has been hashed out before, and more than once. (I did note at the Phab Izno linked that search engine optimization rankings might suffer if this alternative was used. But I wonder how badly? I'm guessing on Featured Articles it shouldn't matter much, since they are usually pretty well linked in the main text.) NewsAndEventsGuy (talk) 21:58, 25 July 2020 (UTC)

This has not actually been hashed in any significant sense besides some community minority of people saying "we want navboxes we want navboxes" (which is not particularly helpful). On the related phab:T124168 TheDJ started some spitballing. You can maybe add your idea there. --Izno (talk) 22:08, 25 July 2020 (UTC)
Alright I'll consider jumping in there, thanks. NewsAndEventsGuy (talk) 00:27, 26 July 2020 (UTC)
NewsAndEventsGuy, I keep wondering whether (most) navboxes should exist at all. I have no reason to believe that non-editors use them. WhatamIdoing (talk) 18:35, 1 August 2020 (UTC)
Indeed, I lack sufficient nerd genes get any more interested in this. Categorization seems at least somewhat helpful, but mainly as a way to mark articles for later report generation e.g., what's hot for editors or hot for readers on one subtopic versus another. NewsAndEventsGuy (talk) 18:54, 1 August 2020 (UTC)
WhatamIdoing (WMF), do you know what it might take to get some machinery installed to investigate that question? (And for sidebars too maybe.) --Izno (talk) 21:26, 1 August 2020 (UTC)
I rarely use navibox myself as a reader or editor. I won't be surprised if a reasearch says 80% of sampled Wikipedia readers don't know or use these navboxes or if they even found them confusing. Same goes for categories. It'd be interesting to find out. – Ammarpad (talk) 05:29, 2 August 2020 (UTC)
Well, if you made all of the navbox entries pass through a redirect, then you could probably use the existing page views tools to figure out whether anyone clicks on the navbox links. SGrabarczuk (WMF), this is a perennial question, because navboxes don't show on mobile. If they're valuable, then we need to find a way to make them work on mobile. If they're not, then we might as well stop making them. Is there any chance that Reading would be interested in looking into this?
Ammarpad, I asked about the cat thing a while ago (I guessed editors we use them, but readers wouldn't), and it turns out that I was wrong and a sizable proportion of page views were from logged-out people. Whatamidoing (WMF) (talk) 04:14, 13 August 2020 (UTC)

hiding columns in a table

Over on [Opinion polling for the next United Kingdom general election] there was a discussion about how to deal with the parties which fit in the others column.

The current solution is to have some hidden text in each cell (it's the best that could be come up with at the moment). as below.

Pollster Client Dates
conducted 		Area Sample
size 		Con Lab Lib Dem SNP Green Other Lead
Ipsos MORI Evening Standard 30 Jul–4 Aug GB 1,019 45% 37% 6% 5% 5% 2%
Brexit Party on 1%
Plaid Cymru on 0%
Other on 1%
 8%

The issue with the current solution is that if you are interested in the detail of the others you would want to see all of them but as it stands you would need to press show on each row. Is there any way to have whole columns which could be hidden by default and expanded as a whole. => Spudgfsh (Text Me!) 11:28, 7 August 2020 (UTC)

Help_talk:Collapsing#Collapsible_columns seems to have discussed this a decade ago, with some sample code. I can't see that there is any existing base "collapsible columns" type code today, and while we have templatestyles we don't have templatescripts to try to shoe horn this in without adding it to the site-wide common scripts. Has anyone else worked on this lately? — xaosflux Talk 18:20, 7 August 2020 (UTC)

Editing With Evidence.

My suggestion is when a person has edited some detailed information like the established date, month etc. of a company in the Wikipedia pages. Then, just in case when someone else thinks that it's not valid etc. So, then that person who edited with that kind of information needs to provide their evidenc prooving that it's true. To be left that way on the pages. So, can you forward then implement this suggestion? Please reply. — Preceding unsigned comment added by 91.140.131.14 (talk) 18:41, 14 August 2020 (UTC)

This is already Wikipedia policy; Wikipedia:Verifiability states that "any material whose verifiability has been challenged or is likely to be challenged, must include an inline citation that directly supports the material. Any material that needs a source but does not have one may be removed". Wikipedians generally don't delete unsourced information unless they have some reason to question it; the best way for you to help would be to find a reliable source that supports the establishment date. Vahurzpu (talk) 18:38, 15 August 2020 (UTC)

Allow previewing protected pages

Allowing users to preview changes to pages they cannot edit could not only allow them to see the effects of the changes they intend to make, thus reducing imprecise, misplaced or unnecessary edit requests, but also by extension lower the workload of the confirmed users, template editors, admins, and interface admins who respond to the requests. Nardog (talk) 05:37, 8 August 2020 (UTC)

Nardog, I've definitely wanted to do this, especially when it comes to templates where the "preview on other page" feature is needed. I'm not sure what technical hurdles might exist for this, but as a wishlist item, I'd love to see it. {{u|Sdkb}} talk 07:52, 8 August 2020 (UTC)
@Nardog and Sdkb: You can get a similar effect with my advanced TemplateSandbox user script. While editing a sandbox page, it lets you do "Preview on other page" as if you were editing the real template. It also enables that feature for all pages regardless of namespace. Jackmcbarn (talk) 16:42, 8 August 2020 (UTC)
Thanks, looks like a useful tool, but it doesn't help reduce inadequate edit requests. Nardog (talk) 05:27, 10 August 2020 (UTC)
@Nardog: I may be misunderstanding your original use-case then. Can you give a concrete example of a page that needs this ability? Jackmcbarn (talk) 23:04, 10 August 2020 (UTC)
@Jackmcbarn: What I mean is unless the script is deployed for all users (including IPs), it will likely not help reduce defective or superfluous edit requests. (Also, it doesn't allow you to preview protected pages in the main namespace or interface-protected pages, does it?) Nardog (talk) 04:31, 12 August 2020 (UTC)
@Nardog: For pages in the main namespace, can't you just copy and paste the source to any arbitrary sandbox and preview it there, since they're generally not transcluded? As for interface-protected pages like MediaWiki:Common.css, it works when I try it. Here's how you can test that for yourself:
  1. Install my script if you don't already have it
  2. Copy the source of MediaWiki:Common.css
  3. Go to Special:MyPage/some sandbox that doesn't even have to exist.css and paste it in the edit box
  4. Change the rule for ".hatnote" from "font-style: italic" to "font-weight: bold"
  5. Change "Template name" to "MediaWiki:Common.css" and "Page title" to "Template:Hatnote/doc"
  6. Observe that in the resulting preview, "Example hatnote text" is now bold instead of italic
Jackmcbarn (talk) 00:07, 13 August 2020 (UTC)
@Nardog: this could be possible, but would require a feature request - I think it would be more confusing for new editors though - if they went in to the view source on a protected page, but it looked like they could edit it, and they could preview it, but not save it -- new users may think it is an actual editor and try to edit the page - then get frustrated and abandon their change instead of filing an edit request when it won't save anywhere. For non-simple changes (most changes on non-articles) we really would want a full sandbox edit and test case review in most situations. — xaosflux Talk 13:30, 12 August 2020 (UTC)
Not an expert in searching phab, but I'm pretty sure this was proposed before and declined by the devs (for the reason you mention). SD0001 (talk) 13:19, 19 August 2020 (UTC)
As a lesser implementation of this, it would be nice if mw:Extension:CodeMirror (syntax highlighting) would work if I was to try and edit a protected page. >>BEANS X2t 05:56, 20 August 2020 (UTC)

Digital Age Date

What year should the Digital Age page include as the official year of its beginning?

A/S/L is to what D/M/Y — Preceding unsigned comment added by SPiZlE (talk • contribs) 19:05, 19 August 2020 (UTC)

Seems like a question for said article's talk page? >>BEANS X2t 06:02, 20 August 2020 (UTC)

Space to request translations of Good articles?

Hello! I've been thinking about this for quite a while now. I'm curious if there's a space where I can submit requests to have English-language Good articles translated into other languages, and ideally, promoted to Good article status locally. As an arbitrary example, I just promoted Spoopy to Good article status. It would take very little time for French, German, and Spanish speakers to translate these and promote to Good status at the French, German, and Spanish Wikipedias, respectively. Is there a way to encourage translations, or submit requests, or do I just need to keep an eye out for someone who may be willing to do this work? Just seems like an easy way to increase quality content across all Wikipedias... Thanks for any help. ---Another Believer (Talk) 17:44, 21 August 2020 (UTC)

Another Believer, meta:Translation of the week is the main place I know of for every-language translation requests. They prefer short articles, though, so I'm not sure GAs would be a good fit. I've also tried adding pages to the WP:Requested articles equivalents in other languages when there's a particular language I think a page ought to be translated into. But those are more monitored in some languages than in others. {{u|Sdkb}} talk 18:55, 21 August 2020 (UTC)

Better designating the reader-facing and editor-facing areas of Wikipedia

In a recent discussion, Bsherr mentioned that Wikipedia:Contact us is a "reader-facing page". My first thought was "yes" and my second thought was "wait, we don't actually have any sort of formal designation/categorization to establish which pages are reader-facing as opposed to editor-facing". There have been some clumsy past attempts, such as Wikipedia:Reader's index to Wikipedia or {{R printworthy}}, but I think Wikipedia has long suffered from an inability to make the distinction cleanly.

This manifests, for instance, at pages like WP:Vital articles, which is ostensibly a reader-facing page (it's got a whole section at clearly reader-facing WP:Contents), but which is filled with editor-facing information like article assessments (e.g. "de-listed good article"). It also creates questions like whether or not its okay for Template:Interactive COVID-19 maps/Per capita confirmed cases to have a "view larger version" link in its caption that goes to its page, and temptations for inexperienced editors to link to WP-space from articles like Wikipedia. (If your response to that last example is "duh, editors should know never to link to WP-space from mainspace", then why does {{Citation needed}} go to Wikipedia:Citation needed, not Citation needed? My point is that this area can get blurry.)

I know that there can be some touchiness about acknowledging that readers and editors are distinct groups, so I want to be clear here that what I'm seeking to do is not to cleave off all the editor-focused parts of Wikipedia to make them totally inaccessible to readers (the idea that all readers are potential editors is perfectly true). Rather, what I hope we might be able to do by creating a formal designation would be to make sure that the bridges between the reader-facing and editor-facing parts of Wikipedia are more intentional, so that we can better guide new editors to beginner-friendly resources like the Help:Introduction series when appropriate.

I don't have any strong views about what method we might want to use to make the designation (in part since it's a technical question). The category system is one obvious candidate, but category pages themselves are an example of the nebulous ostensibly-for-readers-but-actually-filled-with-editor-stuff space. {{Maintenance category}}, with its not part of the encyclopedia language is another example of an incomplete attempt to make a distinction that would be better wrapped into a larger overarching system. Overhauling the namespaces would be another possibility. The distinction between WP: and Help: is already a mess, and as I established above the extent to which WP: is reader-facing varies widely, making it a mess just by itself. I think the best solutions would go to the level of the user interface, perhaps employing topicon symbols or other visual cues. For instance, spitballing, what if, in the same way all links to uncreated pages are red, all links to editor-facing pages had their own unique color?

There would be tons of potential applications to having a cleaner designation system. It would be useful for data collection/research purposes, print versions and other external applications, and search engine indexing, plus navigationally helpful to both readers and editors. I'm sure there are a bunch of others I haven't thought of—knowing which pages are directly part of the encyclopedia and which are not seems like something that we ought to sort out. {{u|Sdkb}} talk 07:44, 3 August 2020 (UTC)

Are there really no takers on this discussion? I know my comment above is somewhat long, but I think this is an important topic that warrants some consideration. {{u|Sdkb}} talk 07:53, 7 August 2020 (UTC)
I think people are worried by the implied scale of this. This question intersects with my standard “WP thing to ponder while waiting in a queue” which includes categories, stubs, assessments, short descriptions and the way that talk pages don’t quite work. :) — GhostInTheMachine talk to me 09:10, 7 August 2020 (UTC)
GhostInTheMachine, yeah, I won't pretend otherwise, the scale is project-wide. But I don't think it'd be an impossible task, since pretty much almost everything could be categorized automatically. And I think it's the sort of thing that, if it had been implemented in 2005, would seem perfectly normal and reasonable today. {{u|Sdkb}} talk 09:26, 7 August 2020 (UTC)
GhostInTheMachine and anyone else who thinks that talk pages don't quite work, please consider putting Wikipedia:Talk pages project on your watchlist. Whatamidoing (WMF) (talk) 04:17, 13 August 2020 (UTC)
Am I alone in thinking that Structured Discussions being rolled out to enwiki would ruin Talk pages? I could start a rant, but I don't think this is the place... >>BEANS X2t 15:16, 20 August 2020 (UTC)
@BEANS X2: Where does it say they are wanting to roll out Structured Discussions? – Majavah talk · edits 15:18, 20 August 2020 (UTC)
AFAIK it is an opt-in for your own user talk page on some other language Wikipedias. We seem to be heading towards a full rollout (in the distant future), which I find worrying. >>BEANS X2t 15:36, 20 August 2020 (UTC)
See MW:Talk pages project/replying#Step 5: All wikis. Rather unclear if it will be the default or an option. Not sure how Structured Discussions mix with the current Way. — GhostInTheMachine talk to me 15:40, 20 August 2020 (UTC)
That's not StructuredDiscussions (aka Flow), that page is talking about a completely separate tool that's similar to reply-link. New installations of StructuredDiscussions are listed in the Limits to configuration changes page on meta. – Majavah talk · edits 15:45, 20 August 2020 (UTC)
  • THe scale is probably what concerns me. The problematic effort is not designating which should be which. The biggest effort is splitting and re-writing pages that are a mix, along with a likely significant number of pages which will turn out to have legitimate reasons to be both, likely triggering disputes over that status. As to the colour, I'd find that annoying - it's the type of thing that would be helpful for non-logged in editors, except they probably wouldn't know of the split, so it wouldn't help there. Nosebagbear (talk) 15:07, 7 August 2020 (UTC)
    Yeah, that's reasonable. Forcing those discussions is somewhat the point, since it's not good for either readers or editors to have their status be so ambiguous. {{u|Sdkb}} talk 17:58, 7 August 2020 (UTC)
  • In the early days there was a considerable focus on turning readers into editors, and that persists, although we know that most don't. Our readers are pretty good at ignoring all the stuff round the edges of the screen - most long-term readers haven't grasped they can comment on a talk page. The distinction is in fact hard to draw - categories are very much for readers, but few notice them - a simple rename might help. If you really think "pretty almost everything could be categorized automatically", it doesn't inspire me with much confidence in the depth of your thinking on these issues. Johnbod (talk) 15:42, 7 August 2020 (UTC)
    @Johnbod: I brought up a bunch of examples of cases that could not be automated in my opening comment. What I mean is just that, since everything in article space and several other namespaces can be categorized automatically, as can everything in maintenance categories/etc., the pages that leaves over wouldn't require going through the entire encyclopedia the way we've had to for, say, short descriptions. But yes, in a project as big as Wikipedia, the "almost" is a lot. {{u|Sdkb}} talk 17:56, 7 August 2020 (UTC)
I absolutely don't agree that "everything in article space ... can be categorized automatically". Not at all. Better leave it there. Johnbod (talk) 18:48, 7 August 2020 (UTC)
@Johnbod: You think there are pages in the article namespace that aren't meant for readers? I'd be curious to know which. Certain redirects are really the only thing that comes to mind. {{u|Sdkb}} talk 19:41, 7 August 2020 (UTC)
No, I think I've been taking your "everything in article space ... can be categorized automatically" too literally - meaning given a WP category. "Categorized" as reader-facing, yes, sure. Johnbod (talk) 00:41, 8 August 2020 (UTC)

Please help me improve this article

Please help me improve this article based on its German version. Тёрнер (talk) 04:30, 19 August 2020 (UTC)

Maybe you should approach Wikipedia:WikiProject Ancient Egypt for more expert help. It's curious that the term Ahmosid doesn't appear anywhere in English wikipedia, is it possible that it's a term that's been phased out, only recently introduced, or only used in Germany? That wouldn't preclude it getting a page, but ought to be mentioned on that page if true. A job for somebody who knows what they're talking about - which isn't me, I'm afraid. Chuntuk (talk) 10:10, 19 August 2020 (UTC)
Second_Intermediate_Period_of_Egypt#17th_dynasty mentions the "Ahmoside kings", at least.2600:1700:EFA0:2980:40C0:BAC7:107B:5DDF (talk) 20:08, 20 August 2020 (UTC)

I think that Wikipedia: Help desk might be a better place to go than Wikipedia: Village pump if you want help with improving articles. Vorbee (talk) 14:59, 23 August 2020 (UTC)

New WikiProject/Task Force for Blanking IP Talk Pages

I had the idea of creating a WikiProject or Task Force in some WikiProject (possibly the Welcoming Committee) to blank Old IP Warnings as well as to propose new policy on when they should be blanked/how they should be blanked. Currently, this only done by an unorganized group of users. Any ideas? P,TO 19104 (talk) (contribs) 19:01, 24 August 2020 (UTC)

Flag edit for review?

So...I've been around here quite awhile now, and I'm pretty confident that I can spot a good edit versus a bad edit when looking through my Watchlist. But there are times where I look at an edit and think, "Hm...I'm not sure this is a good idea, but I don't feel confident enough to revert it," or perhaps I don't have the time needed to review the edit as carefully as I'd like. I was wondering whether it might be possible to create a mechanism similar to thanking editors for their edits, that would flag edits for review by other editors. Flagged edits could perhaps be highlighted in some manner in watchlists, and ideally any editor (perhaps any editor other than the original) would have the ability to unflag an edit if they were confident it was valid. There's probably a lot I'm not taking into consideration here, or possibly technical difficulties that would outweigh any potential benefits, but I didn't see this listed as a perennial proposal, and it seems to me that there might be some utility for it. There's obviously some potential for abuse here too, but I think that could be handled via typical protocols for disruptive editing. Thoughts? DonIago (talk) 23:43, 9 August 2020 (UTC)

Doniago, hmm, that's interesting. I could see some potential avenues for abuse, though. Consider what would happen, say, when someone adds a well-sourced/due negative fact about a politician. A partisan editor who doesn't like the fact could flag it, hoping someone else will decide to take the reputational hit by actually removing it. Others might try to remove the flag, and now you have a new thing to edit war over.
Another potential issue is that it might make people less likely to actually revert deleterious edits, if they can just mark them and then feel like they've "done something" about the edit.
Neither of these are insurmountable challenges, but they've representative of the types of considerations that would have to be worked through. Something that might be more easily feasible would be to implement an easier way of providing feedback to train the algorithm used by ClueBotNG to detect bad edits. I think there's some work being done on that at WP:WikiLoop DoubleCheck and elsewhere, but I'm not sure what stage it's at. {{u|Sdkb}} talk 00:26, 10 August 2020 (UTC)
Yeah, I can easily imagine an editor deciding to harass another editor by flagging all of their edits as well. It's very abusable, though I don't know how likely it would be to actually be abused, or what options there may be for limiting that abuse.
I'd like to think it wouldn't make editors less inclined to roll up their sleeves, but I don't know how we could establish that one way or another without putting such a system in place.
Your notes about ClueBot are interesting, but I'm not sure these are the kinds of edits that qualify as "bad" edits. As an example, there's this edit which modifies a film's reception section to mention that several film directors consider it among their favorites. If this edit mentioned one editor I'd probably just revert it on the grounds that there's no clear relevance to one director unaffiliated with the film liking it, but when there's multiple directors involved...I dunno, does that mean it's worth retaining? I'm going on vacation soon so I didn't really want to start digging into the subject, and it occurred to me that a quick-and-easy way to at least send up a flare for other interested editors might be a useful tool in such a case. Cheers! DonIago (talk) 00:54, 10 August 2020 (UTC)
(edit conflict) This could have an interesting additional use, where an editor wants others to double-check their work. For example, an editor finds a paragraph that's very difficult to follow, and significantly re-writes it for clarity, but is concerned that they may have added or dropped something subtle as a side-effect. With this, they could flag their own edit, prompting other to review. This would effectively provide the opposite of a "minor" flag on one's own edits. --A D Monroe III(talk) 00:38, 10 August 2020 (UTC)
Oh, I like that! I have had a couple of times where I was trying to edit a table or what-not and I just couldn't get it to the way I knew it was supposed to be. Being able to flag at that point may not have been the "best practice" option but could have at least drawn some attention. DonIago (talk) 00:54, 10 August 2020 (UTC)
A D Monroe III, that's also interesting. Similar to the above, it could have the possible adverse affect of making people more likely to make edits they shouldn't, knowing they can ask others to check it. {{u|Sdkb}} talk 02:11, 10 August 2020 (UTC)
I agree it's possible some people will make the wrong decision when given a new option, but it is guaranteed that people will be less able to make the right decision where the option to do so doesn't exist. Without some hard evidence, only in cases where there's an option overload does adding options demonstrably increase poor decision making; I don't see how that could apply in this case. --A D Monroe III(talk) 18:20, 10 August 2020 (UTC)
Based on some past user research, I think you'll also see some demographic skews in who uses the button (e.g., European men will be less likely to use the button than Asian editors). Whatamidoing (WMF) (talk) 04:23, 13 August 2020 (UTC
@Doniago: MediaWiki already has the WP:Tags feature. But at the moment on en-wikipedia, adding/removing tags on an edit is an action restricted to admins and bots. So basically, your proposal would be to extend the changetags right to more users (admins + rollbackers?) and create a new tag named "flagged for review"(?). All of this is trivially easy from a technical standpoint. The barrier is in establishing a community consensus for this. I'd suggest you follow up on WP:VPR. SD0001 (talk) 13:14, 19 August 2020 (UTC)
Thanks SD! It looks like there are some concerns for abuse here, but nothing we can substantiate without testing, but no showstoppers to moving it forward. I'll give it a bit more time before taking it to VPR. DonIago (talk) 14:01, 19 August 2020 (UTC)

Thanks everyone for your feedback on my idea. I've brought it to VPR here - Wikipedia:Village pump (proposals)#Flag edits for review. DonIago (talk) 14:33, 25 August 2020 (UTC)

Talk page linking with automatic link recovery after page archiving

Hi. In talk page discussions links to talk page sections (or anchors) often get broken when the corresponding talk page thread gets archived. This holds true for all fully qualified links (like this: Wikipedia:Village pump (idea lab)/Archive 32#Talk page linking with automatic link recovery after page archiving) but also for local links containing only the section header (like: #Talk page linking with automatic link recovery after page archiving) when the location of the link invocation and the link target do not happen to be archived within the same archive page.

Since I could not find anything in regard to this, I wonder if we already have a template like {{Link talk|target-page#section-header|optional-link-label}} which could be used instead of the original link (like: [[target-page#section-header|optional-link-label]]) and which would look like a normal link by default.

Example: {{Link talk|#Talk page linking with automatic link recovery after page archiving}}

However, the template would automatically sense if the link target gets broken (remotely similar to {{ill}} but for internal links to talk page sections) and then search the talk page archives to transparently (re)establish a link to the section on the corresponding archived page instead.

There are some scenarios where a connection could not be restablished reliably (f.e. if the same section header/anchor was used in multiple archived pages), but in these cases the template could display them all with a small note that the provided link or links are "guesswork"). Still, as I see it, such a template would considerably reduce the broken link problem.

Do we have something like this already (and I just did not find it)?

Or, is there some function like {{#if-exists-section-header:target-page|section-header|yes-case|no-case}} or {{#if-exist-anchor:target-page|anchor|yes-case|no-case}} that could be used in template code?

--Matthiaspaul (talk) 13:25, 13 August 2020 (UTC)

If you archive using ClueBot III it tries to fix links to archived threads. As noted in the documentation, due to the overhead it takes, it shouldn't be used for pages that are linked to a lot. isaacl (talk) 17:29, 13 August 2020 (UTC)
Thanks, I didn't know about that CB3 feature. Fixing a link once and forever is, of course, a better solution, than repeatedly trying to fix it up on demand. I meanwhile talked to Cobi and asked him if it could be a problem to enable this for a talk page with a few thousand incoming links. According to him, it isn't - the original problem was on a page with tens of thousands of incoming links.
So, it shouldn't become a problem even on many mid-frequented talk pages. (And if it does in the future, there are certainly ways to further improve the behaviour by deferring the updating of links to a really low (near-idle) priority, so that less important pages won't be checked for dangling links each time a thread gets archived, but only once in a while.)
--Matthiaspaul (talk) 14:15, 19 August 2020 (UTC)
@Matthiaspaul: What you describe is not technically possible. There is no way for any template to check if a link target is broken, or search in talk archives. However, we do have a opt-in gadget User:SD0001/find-archived-section that finds the correct target after you follow a broken link. I'd be interested to know if people would want this gadget to made a default gadget (enabled by default for everyone, including IPs). SD0001 (talk) 13:04, 19 August 2020 (UTC)
Thanks! I guess, technically there is a way for a (LUA-assisted) template to check if a section exists on another page (even without the help of a dedicated mediawiki function) by taking the whole page as input and parse it for the section header (similar to how CS1/CS2 citation templates check for the existence of the {{Use dmy dates}}/{{Use mdy dates}} templates and their |cs1-dates= parameter). However, it would be very expensive, in particular if a section header is located deep down on a page, not at the beginning. My first (and bad) assumption was that this wouldn't matter much on a talk page (because it would only happen on demand, and then the user could wait a second), but this assumption was wrong, because, unless the template would point the reader to some interim page first (and expensive actions would only be carried out on demand from there), for the template to act in a way as envisioned originally these expensive actions would always have to be carried out whenever the page containing the link is invoked - too expensive. So, your solution sounds much better. Unfortunately this too has its limitations, as it only works for browsers with JavaScript enabled (which is often disabled for security reasons). So, the best solution appears to be to have the archiving bots fix up the links when they archive a thread.
--Matthiaspaul (talk) 14:15, 19 August 2020 (UTC)
  • This has long been on my list of needed features. I wasn't aware that ClueBot could do this, nor was I aware of User:SD0001/find-archived-section. Both of these should be publicised more widely, i.e. Signpost, Tech News, etc. -- RoySmith (talk) 12:32, 23 August 2020 (UTC)
I agree wholeheartly. --Matthiaspaul (talk) 10:51, 1 September 2020 (UTC)

Reducing redundancy of lists, categories, and navboxes

To start with the obvious disclaimer: yes, there are clearly some ways in which lists, categories, and navboxes are intentionally different from each other. But beyond that, the idea put forward at Wikipedia:Categories, lists, and navigation templates that Overlapping categories, lists and navigation templates are not considered duplicative is at some level a lie we tell ourselves — all three of these things are ways of organizing information on related topics, and in a situation (which I'm sure is not uncommon) where one editor works to build a list and the other a category there is clearly some amount of wasted editor effort on duplicative work.

Given all this, I'd like to open up a brainstorming discussion about what we might be able to do to reduce the redundancy. For instance, how might we create systems that would allow someone to add a page to both a category and a list at the same time, or to automatically populate a list from a category or vice versa? In your ideal Wikipedia of 20 years from now, in what ways would you like to see these systems integrated, and in what ways do you think they're fundamentally different enough that they must remain separate? (I'm using the 20-year frame since I'm not so interested in smaller things like mobile display, which will eventually be solved.) Curious to hear everyone's thoughts. {{u|Sdkb}} talk 15:16, 27 August 2020 (UTC)

To be mildly facetious, Wikidata. --Izno (talk) 20:25, 27 August 2020 (UTC)
Sdkb, what these systems have in common, is that they are basically sequences of articles in a specific group. That is basically WikiData information. As such, you could create various widgets to browse this information depending on density and interest automatically. You could have carousels, or explosion diagrams or raw lists, depending on what works best for your screen, you, the amount of information in the article etc. It's not easy to implement, but my ideal is something that allows you to browse these relations in a more dynamic way. —TheDJ (talk • contribs) 08:51, 2 September 2020 (UTC)

I seem to recall that the question of why we have lists as well as categories has come up at Wikipedia: Village pump before, many years ago now. I am repeating myself, but I shall say again that I can understand why we have lists as well as categories. If one goes to the article Ronald Ross, one can see that he has been placed in a category "Nobel laureates in physiology or medicicne". However, placing him in this category merely tells us that he won the Nobel Prize for physiology or medicine - it does not tell us his nationality or the year he won the Nobel Prize. To find out the year he won the Nobel Prize, one would have to go to List of Nobel laureates in Physiology or Medicine. So, you can see, lists do add information which categories do not supply. I do not know about navboxes - in all the time I have been making edits to Wikipedia (which is many years now) I have not come across navboxes. I shall leave it to some one else to explain what information navboxes supply that is not supplied by categories or lists. Vorbee (talk) 08:27, 28 August 2020 (UTC)

Modified table of contents

I am not aware of how the table of contents looks on the various available skins, so the following comment will refer only to the TOC as it appears on the default skin (Vector). I have a few issues with it:

  1. The table is always completely expanded by default (meaning that every section and subsection is visible on it), which can cause it to be a bit too large. On John Adams, a featured article, the table is so big that I can not view the whole thing on my screen without scrolling. This somewhat defeats the purpose of a table of contents, which should ideally be entirely viewable all at once on a standard screen.
  2. The TOC is only viewable at a specific location in the article. Once again, on John Adams the table is not visible when the page first loads because of how long the lede is. When scrolling through the rest of the article, there does not appear to be any way to view it without scrolling back up. This makes navigating through a long article very difficult. (I'm not sure about this point. There may be a way to navigate through a page even from the middle of it, but I just haven't noticed it yet. Please let me know if this point is not correct).
  3. Lastly, as far as I can tell (this may also be incorrect) the only way to get a link to a specific section without manually writing it is to click the link on the table of contents, and then making a copy of the URL bar. This is not ideal.

I want to know how receptive the community would be to a proposal to change the table of contents. To me, the ideal TOC would be the one used on this website: Explained from First Principles. The TOC on that page address all three points that I have made. It is always visible on the side of the page, it remains collapsed with subsections only visible when viewing the super-section, and the website automatically updates the URL when viewing a particular section. Would the community be willing to discuss implementing a TOC based on that one? --PuzzledvegetableIs it teatime already? 18:28, 28 August 2020 (UTC)

Puzzledvegetable, I'm glad to see this being discussed! I'll link here from WikiProject Usability. Wikipedia's user interface overall lags well behind where it ought to be, largely because editors are inherently resistant to change. That, plus a bunch of path dependency, will probably be the biggest obstacle. Questions like what to do for edge case pages that have had a {{TOC limit}} assigned or use a {{horizontal TOC}} will need to be addressed. And of course, if the TOC replaces the left sidebar, we'd need to figure out what to do with the sidebar. Regarding the link copying, that's very important to editors and not very important to readers, but since editors tend to be regrettably self-centered, I'm sure it'll get a bunch of attention.
Overall, this would be a huge undertaking. It's in an unfortunate place where it's the sort of thing that would be best undertaken by the WMF, but also, given the WMF's current reputation among the community, would be unlikely to be accepted if it came from the WMF. The mw:Desktop Improvements Team is working on some things that may be relevant, and will hopefully eventually see the light of day. {{u|Sdkb}} talk 20:23, 28 August 2020 (UTC)
I didn't know about the Desktop Improvements Team; thanks for directing me to that. --PuzzledvegetableIs it teatime already? 20:32, 28 August 2020 (UTC)
Sdkb, it should be noted that there has long been some work going on to add something to get a link to a section. But due to all the requirements it is turning out more difficult than expected and as such has stalled a bit again. phab:T18691#6033238. Also.. I thought I was supposed to be the salty one around here ? ;) —TheDJ (talk • contribs) 08:46, 2 September 2020 (UTC)

Developing a naming convention for fictional elements

I had the idea of developing a unified naming convention for articles about fictional elements. The proposal, currently in the brainstorming phase, is at Wikipedia:Naming conventions (fictional elements). Please comment at the draft proposal's talk page. –LaundryPizza03 (dc̄) 03:55, 22 August 2020 (UTC)

And here I thought this was going to be a naming convention for Unobtainium and Bolonium. --Ahecht (TALK
PAGE) 14:10, 4 September 2020 (UTC)
I did as well, I was: disappointed, deprived of an opportunity to rant about excessive naming rules; and deprived of multiple joke possibilities Nosebagbear (talk) 11:03, 8 September 2020 (UTC)

Sorting support/oppose votes in village pump

As a sort of meta-suggestion within the village pump, I think that support and oppose votes here should be sorted like they are at WP:RfA. The need for it is evidenced in long discussions like the current one on parenthetical citations. Instead of "arbitrary breaks," there should be subsections for support/oppose with numbering to be able to tell easily how many users are on each side. Tonystewart14 (talk) 00:46, 1 September 2020 (UTC)

Tonystewart14, it depends on the discussion. Some are big enough that that should definitely happen. But for smaller ones, it's better to have things a little looser, since if they're too formalized it creates unneeded headings and makes it harder to express ambivalence/other more nuanced views. We don't always know which discussions are going to become huge, but for those that likely are, I certainly support that sort of structure over arbitrary breaks. {{u|Sdkb}} talk 03:37, 1 September 2020 (UTC)
On that, we could have a Support section, an Oppose section and a third section where everything that isn't either of the two can be. El Millo (talk) 03:41, 1 September 2020 (UTC)
RFCs are still supposed to be discussions, and even RFAs are still supposed to be. These headers usually cause users to be more likely to vote rather than discuss. --Izno (talk) 05:26, 1 September 2020 (UTC)
  • One concern I have with this is that even for medium size, it's quite helpful to have comments within, along with threaded replies, rather than out in a Discussion section (or, worse yet, doubling each to put them in each). I also back Izno's concerns. Nosebagbear (talk) 18:43, 1 September 2020 (UTC)
  • Yeah, because the "votes" are bolded (and usually pretty short, altho sometimes not) its not that hard to count up even fairly long lists of commenters. Usually there's only like ten or so anyway max. The proposal would tend to divide people into "camps" even more than currently, a little bit, at least as mindset. Also, counting numbers of "votes" is not the main way to determine the outcome -- at least, its not supposed to be, and usually isn't, unless there's a true supermajority. In RfA there are really a lot of voters so its different. Also numbers matter there more. Herostratus (talk) 19:02, 3 September 2020 (UTC)
    I agree. We normally split the "votes" only when counting the votes matters and there are more responses than are likely to be convenient to count by hand, which happens in very few discussions. WhatamIdoing (talk) 21:10, 9 September 2020 (UTC)

Different highlights in Diffs for wiki markup vs. content

I haven’t been able to find if this has already been proposed. In Diffs, it’d be great if the wiki markup, particularly the entire citations, were highlighted in a different color, than the regular content text (e.g., all newly added items are highlighted blue in diffs, but citations could be highlighted darker/lighter shade of blue than new content). This would make it easier to read the new content, vs the citations (which can be very long) and other intermingled markup.

Now where everything is the same color, users have to spend more time deciphering the diffs (e.g. content text, even single sentences, broken up by long citation markups). Or they spend additional time and effort by going to the main Article page, then search for the new content, to see it there, where it’s easier to read. In either case, considerably more time and effort is spent, and when we multiply this by all the Admins and Editors who check the diffs, it’s probably a lot of time lost. Any thoughts? Thhhommmasss (talk) 21:55, 6 September 2020 (UTC)

Try WP:WikEdDiff. --Izno (talk) 11:55, 7 September 2020 (UTC)
Thanks, looks interesting, I'll check it out Thhhommmasss (talk) 04:04, 9 September 2020 (UTC)

Have automatic "category-in-namespace" pages

It would be very helpful for maintenance and some other categories to have automatic "in namespace" sub-categories, such as "Category:Pages where template include size is exceeded/Article namespace" which would be the article pages in Category:Pages where template include size is exceeded, i.e. this list, except as a proper category instead of XML output.

I could then add this automatically generated sub-category to my watchlist instead of the main category. As it is, my watchlist gets the clutter of each move by a draft-, user-page, or other-page as it goes in or out of this category.

Also, editors who look at the categories directly would have an easy way to "filter out" the namespaces they didn't want.

If this were an automated part of Wikipedia, something like Category:base category/Article namespace, Category:base category/Talk namespace, etc. that would apply automatically to all categories, that would be even better. Of course, we'd have to rename any existing category that had a name-collision, but I would expect such collisions to be few. Since it would be an automatically-generated category, we would have to make a decision about the "content" (i.e. description page) of the category.

Alternative implementation: Provide a "in selected namespaces" filter on each category's page for people viewing the category pages directly, and a "in selected namespaces" filter for categories listed in watchlists. This likely would be more limited since it would be easier to code if the editor were forced to set a single namespace-filter that applied to all categories. In the original proposal, a user could watchlist Category:base category 1/Article namespace and Category:base category 2/Template namespace.

Thoughts? Who would find something like this useful? davidwr/(talk)/(contribs) 15:55, 14 September 2020 (UTC)

The second one can be done today in a gadget I would guess. It also has a phab ticket from 2013 (see also the child task). --Izno (talk) 17:15, 14 September 2020 (UTC)

Idea: Make the undo edit tool available to only Auto-Confirmed users

The edit tool can be used by vandals, to revert alot of edits on a page. It's kinda a big deal when a random wikipedian comes to the Nickelodeon article and reverts the page to the 2008 version (no that didn't happen). It might be a good idea to lock the undo button to people who are not Auto-Confirmed. It could also stop edit wars before they happen, if one of the person involved in the to-be edit war isn't Auto-Confirmed. Of course, I want your opinions, and see if this is a good idea. Thanks. Arsonxists (talk) 19:28, 14 September 2020 (UTC)

I don't think the "undo" is a huge concern, since edits that far back probably have "conflicting" intervening edits and can't be "undone." if you are worried about someone loading up an old page, then editing it and saving it, I'm not sure if it's feasible to prevent this. Perhaps more useful would be a tag for edits that affected more than one section which were made by a non-logged-in or non-autoconfirmed account. I haven't checked the tag list, perhaps that's already being done. davidwr/(talk)/(contribs) 19:50, 14 September 2020 (UTC)
Now that I think of it, yeah, that's not much of a concern. Might make a new idea for the more useful thing you mentioned. Arsonxists (talk) 20:00, 14 September 2020 (UTC)

Election Endorsement Notability Standards

In the 2020 Green Party of Canada leadership election, I noticed that there might be an issue of what constitutes a notable endorsement.

If I were to endorse any of the candidates, I would hope it doesn't make it onto that page, but there are some people who I really wouldn't describe as having any local importance or movement notability there. I think there may be room for an Endorsement Notability standard that applies to all elections, and propose the following:

An endorsement should be included if someone (a) has been affiliated with the party in an official capacity, (b) has held elected office in the country or voting zone, (c) is an organization that has existed since at least the start of the election cycle and has some relationship with the election issues, or (d) is a national or international name (like Rodger Waters or Greta Thumberg).

What do you think? TimeEngineer (talk) 12:55, 15 September 2020 (UTC)

As it happens, we have WP:ENDORSERFC. It looks like that was turned into a guideline at Wikipedia:Political endorsements (though I'm not sure there was actually a discussion promoting it to guideline status, it's based on the RfC, which has standing). — Rhododendrites talk \\ 16:15, 15 September 2020 (UTC)

Being able to edit your edit summaries

Tracked in Phabricator
Task T12105

It seems that this was already proposed at the VP by Juliancolton back in 2008, but I would like to bring up this idea again, but in a new way. The previous proposal would allow anyone (or maybe just admins) to edit the last edit summary that would have been made. In this idea, what if only you could edit your own edit summary if it was the last edit that was made? I think there is also more of a need for something like this than in 2008 because when using tools like Twinkle and RedWarn its not uncommon to misclick and then put in an edit summary that does not adequately describe why the revert was made. Is there a need for this? Is this possible?

Previous discussion link:[5]

Best, P,TO 19104 (talk) (contribs) 15:33, 11 August 2020 (UTC).

@P,TO 19104: so this is a bit of a turtles all the way down situation. We really expect transparency and accountability for actions, and to maintain that we would need to keep a revision history for the edit summaries as well (so we could tell what they used to say) - and then when someone makes that edit, would we want to give them an option to describe why they are making it (a summary edit summary) - and then should that also be editable? This goes all the way back to phab:T12105 from 2007 - and is not something the English Wikipedia could just implement - it would require a software feature request to develop this in to the software first. — xaosflux Talk 15:45, 11 August 2020 (UTC)
@Xaosflux: Thank you for responding. Is there a way that we could record old edit summaries that were overwritten? Could we store the old edit summaries in some page or in a user's subpage? Could we store them somewhere off-wiki to insure they don't take up too much space? I think compared to 2007 and 2008, there is more of a need for something like this because when using anti-vandalism tools really fastly it is possible to input a misleading edit summary. P,TO 19104 (talk) (contribs) 15:51, 11 August 2020 (UTC)
I see. This would be something that would require a general Media-Wiki change. Noted. I guess I give up then on this request.   P,TO 19104 (talk) (contribs) 15:57, 11 August 2020 (UTC)
I often make typos and other errors in edit summaries, usually noticing a split second after saving the edit. When they are minor (i.e. they don't affect the meaning of what I am trying to say) I just let them go and, if anyone actually notices, don't care if they think I'm an idiot. Occasionally they are significant errors, in which case I make a dummy edit to the page, such as adding a blank line, and note the fact that my previous edit summary was in error. Phil Bridger (talk) 16:44, 11 August 2020 (UTC)
And, on the point of automated tools, you shouldn't be going so fast that you make mistakes regularly. If you are making lots of mistakes in edit summaries then you are probably making lots of more important mistakes, so slow down. You are not personally and solely responsible for defending Wikipedia against vandalism, spam, etc. Phil Bridger (talk) 17:00, 11 August 2020 (UTC)
Tracked in Phabricator
Task T97013
On fiwiki there is a tag for "error in edit summary" that you can add to your own edits if you made a mistake in the summary. When adding a tag you can add a reason for tagging the edit which is shown on the tag management page. We could probably try a system like that here too. – Majavah talk · edits 19:34, 11 August 2020 (UTC)
We had originally specifically denied our editors the ability to change tags after the fact (c.f. phab:T97013) - but could enable this if we have support for it. — xaosflux Talk 21:39, 11 August 2020 (UTC)
The fiwiki tag is (or should be in my opinion) quite rarely used, and it's not really for the purpose of tagging your own mistakes (I generally try to hide my mistakes, not highlight them, but maybe that's just me). The purpose is for example to tag misleading edit summaries that can otherwise cause confusion. For example, when you start a voting page, there are certain steps that you should follow and you should also use informative edit summaries, so that the page history can be followed easily. If someone didn't follow the instructions and left a bad edit summary, usually another editor will use the tag to mark the shameful deed. It takes some effort to read the reason for the tag, so if there are a lot of tagged edit summaries, it will just cause editors to waste their time trying to find out why there are tags on them. -kyykaarme (talk) 08:30, 25 August 2020 (UTC)

I'd be against the general change, but the "error in edit summary tag" is at least a possibility. I still think it's not too big an actual issue to need resolving, but i wouldn't object if something like the above was wanted. Nosebagbear (talk) 12:11, 13 August 2020 (UTC)

  Agree with Nosebagbear. {{u|Sdkb}} talk 20:26, 15 August 2020 (UTC)
@Sdkb and Majavah: This may be pretty late, but could we go head with this proposal? I didn't see your replies. P,TO 19104 (talk) (contribs) 19:45, 24 August 2020 (UTC)
@P,TO 19104: this is the "idea lab" - so there are no time limits :D But also, we don't implement from here. Once your idea is fairly solid (You can articulate what it is you want to change, and why you want to change it) - you can list it at WP:VPR where the community can weigh in on it. If there is consensus, we can move forward - if not, status quo remains. So, based on what we've discussed so far: "Editing an edit summary" is pretty much a non-starter (even if the community wanted it). Allowing people to add (and therefor also remove or change) tags on edits is possible (by giving the a group access to (changetags)). Note, "software defined tags" (such as "mw-rollback") can't be removed (not even by admins) - but a new manual tag could be added (an edit may have multiple tags). — xaosflux Talk 19:56, 24 August 2020 (UTC)
@Xaosflux: Moving forward with the "manual tags" idea. Thanks! P,TO 19104 (talk) (contribs) 20:03, 24 August 2020 (UTC)
Another possibility to address the original request while maintaining the reasons for why we decided to not allow edit summaries to be edited would be to allow an editor to edit her/his edit summary only for a limited amount of time (perhaps 30 minutes, at most some hours) or until another edit to the article has been made by someone. Edited summaries should have a small tag indicating that they have been edited after the fact. This would allow editors to correct typos or improve wording if they are soon spotted and no other editor has "sealed" the history by applying his own changes to the article.
This is a scheme implemented in many forum softwares for contributions (rather than only edit summaries) and it works quite well.
Given that an (evil) editor could have (deliberately) provided a misleading edit summary right from the start, it cannot create more harm if s/he would change a good summary into a misleading one later on for as long as no other editor has been actually misled or noone has read the article in the new state. We can assume that a follow-up editor would have been misled if that editor based anything on the exiting state of the article (including the edit history) by editing the article herself/himself. Also, in the case that there will be no edits by other editors in a given timeframe, the very fact of an article to be live in a certain state can be seen as "sealing" its edit history, therefore, the time window for corrections should be closed automatically after some while. Keeping it open for a small amount of time, however, is acceptable because the original editor could have made her/her edit a couple of minutes or hours later as well.
--Matthiaspaul (talk) 09:15, 8 September 2020 (UTC)
I agree. right now, all edit summaries are permanent, as soon as you make them. there ought to be at least some time to revise them, if desired. --Sm8900 (talk) 14:27, 17 September 2020 (UTC)
Support appending by original editor with time-stamped changes - but not editing in any other way except by administrators. Also Support allowing administrators to hide edit summaries without revision-deleting the entire edit if the edit summary would qualify for hiding under existing revision-deletion rules had the edit itself been revision-deletable, e.g. a good edit with a BLP violation in the edit summary, or a web-link in the edit summary that links to a malware-infested web site. davidwr/(talk)/(contribs) 19:22, 17 September 2020 (UTC)
Comment - a work-around exists: I occasionally "append" to my recent edit summaries by doing a "practically null edit" where I add a space to the end of a line then put in the correct edit summary. The most common reason is that I fat-finger the "enter" key too soon, which saves the edit before I've finished typing the edit summary and I left something very important off. Sometimes I have to do it if I put something in the edit summary that is just wrong, like a mis-typed URL or wikilink. davidwr/(talk)/(contribs) 19:26, 17 September 2020 (UTC)
  • Support Editing edit summaries sounds like a good idea. Deleting small edits as well could be useful. Royal Autumn Crest (talk) 00:45, 29 September 2020 (UTC)

Killing cats

The article Barack Obama is in 70 categories.

70.

I'm talking about content categories here, not maintenance. I'd think a good rule of thumb here is that most articles should be in no more than about 2 or 3 categories, maybe 5 or 6 for really busy articles. From a brief look, biographies tend to be some of the worst offenders, but there are certainly others.

The category system might work well on a small, tightly-focused wiki, but it just doesn't scale to a general encyclopedia with millions of articles. Do we really need Category:1931 establishments in New York (state)? Does this actually serve the reader? (Hint: no).

I don't have any brilliant answers or ideas here, but I think at least some degree of recognition that there's a problem would be a first step. –Deacon Vorbis (carbon • videos) 14:44, 6 September 2020 (UTC)

Two thoughts. First is that 2-3 is insufficient for many subjects unless we get incredibly laser focused with subcategories. Is there a use to having people grouped by hometown? By job? By alma mater? By awards won? Because we're already up to probably, what, 15-20 just with those? I mean sure we coIuld have a category for "Democratic Party United States senators from Illinois who are also non-fiction writers and Harvard Law School alumni" to get the number down... The relevant question (for me) for that particular example is why the vast majority of those categories aren't moved to the category "Barack Obama". There's probably some guideline I'm not aware of.
Second thought: how many readers have you talked to who actually use categories? I regularly bring up categories when teaching new users IRL and ask if anyone has ever used them. Maybe a couple out of hundreds that I've asked, and usually just because they were organizing an edit-a-thon or needed some information about Wikipedia articles for their job. And once they know about categories most people still don't use them, because for those purposes something like a Wikidata query is more comprehensive or a WikiProject table or a curated list is more accurate. The people who care about categories are Wikipedians, and some Wikipedians care an awful lot (see WP:4000). Personally, I'd be happy if we started long-term planning for replacement by Wikidata. There's plenty that Wikidata isn't good for, but straightforward tagging is one it's much more equipped to handle than MediaWiki. — Rhododendrites talk \\ 15:09, 6 September 2020 (UTC)
I would agree with this (in particular that categories is the 2000s tool which is way outdated), except for any Wikidata-related RfC is bound to attract several dozen users voting it down with the motivation that Wikidata is evil does not matter what is being discussed. In practical terms, I just do not know how to organize this.--Ymblanter (talk) 19:17, 6 September 2020 (UTC)
NO! Don't kill the cats! All joking aside, I think that very specific categories the no one is likely going to search for should be be eliminated, but I oppose killing of categories all together, considering that some categories like Category:Candidates for speedy deletion are vital to the maintenance of Wikipedia. Goose(Talk!) 20:42, 6 September 2020 (UTC)
I can see some categories rearranged in the tree as in Category:Democratic_Party_Presidents_of_the_United_States in the category of Category:Democratic_Party_(United_States)_presidential_nominees. That would bring done the categories for Barack Obama down to 69(not intended for inside jokes).Manabimasu (talk) 01:33, 7 September 2020 (UTC)
What problem is this intending to solve? The category system might work well on a small, tightly-focused wiki, but it just doesn't scale to a general encyclopedia with millions of articles.[citation needed] The category system does scale to millions of articles. Lists, navboxes etc generally don't scale, but categories do. Cats like Category:1931 establishments in New York (state) may not be useful for the general lay reader -- they aren't intended for lay readers. It is natural for libraries and other information sources to try and organise content in as many ways as reasonable, as this aids research. It's difficult for print encyclopedias but easy for an online encyclopedia. So I just don't see any "problem" here. – SD0001 (talk) 08:32, 9 September 2020 (UTC)
@SD0001: If categories aren't intended for the reader, then they should be hidden. We even have WP:CATDEFINING, but it doesn't seem to be followed in practice. People wouldn't be in 70 categories if it were.
Really, the problem that you're asking about is that categories tend to get split into subcats in arbitrary ways when they get too large. Even worse than the 1931 example is "Office buildings on the National Register of Historic Places in Manhattan" (pulling these from Empire State Building). There should be 3 categories –
  • office buildings,
  • things in Manhattan, and
  • things on the NRHP.
And if you care about the three-way intersection, then we should have a working way to get that. But we don't (and no, PetScan doesn't count...it doesn't really even work). What if I had just wanted office buildings on the NRHP? or things in Manhattan on the NRHP? or office buildings in Manhattan? (Oh, but don't worry, it's also in "Skyscraper office buildings in Manhattan"). Then the category scheme is useless. Of course, doing things with properties like WikiData does is probably the way forward, but it would be a pretty major undertaking, and I'm not sure the collective will exists for that. So in the mean time, we have a broke, useless system. What do we do with it? –Deacon Vorbis (carbon • videos) 13:42, 9 September 2020 (UTC)
@Deacon Vorbis: What if I had just wanted office buildings on the NRHP? that's the subtree of Category:Office buildings on the National Register of Historic Places
or things in Manhattan on the NRHP? Category:Buildings and structures on the National Register of Historic Places in Manhattan,
or office buildings in Manhattan? Category:Office buildings in Manhattan.
The category you started with is a descendant of each of these categories.
doing things with properties like WikiData -- that's an alternative way of doing things which is already being done. wikidata:Q9188 has instance of = office building, location = "Midtown Manhatten", heritage designation = "place listed on the National Register of Historic Places". You can write a SPARQL query to get an intersection of one or more properties. If you're only interested in stuff that have WP articles, of course you can filter for that too.
TL;DR: Both the systems work. Please do some groundwork before making pompous claims like "we have a broke, useless system" demeaning the spectacular work done by volunteers over more than 15 years in organising all this together. – SD0001 (talk) 15:49, 9 September 2020 (UTC)
  • I find the whole category system extremely frustrating. As a computer scientist, I want to know what kind of relationship the cat graph represents. is-a? has-a? is-sorta-like? Beats me. I also want to be able to navigate the cat graph using standard tools, and to do that, I need to know what kind of graph it is. Intuitively, it's a tree, but it's actually not. It's not even a DAG. The profusion of intersecting cross-cutting cats ("Female alumni of Potrzebie University who edit wikipedia", "Women from Lower Slobbovia", "17th Century wikipedians") doesn't help. -- RoySmith (talk) 14:26, 9 September 2020 (UTC)
    It should be a DAG. If there are any cycles, I think it's reasonable to consider that an actual error. –Deacon Vorbis (carbon • videos) 14:36, 9 September 2020 (UTC)
    Deacon Vorbis, You would think so, but that doesn't seem to be the case. For example, in WP:CAT, there's a footnote that says, Mathematically speaking, this means that the system approximates a directed acyclic graph. From the point of view of somebody trying to navigate the graph programmatically, "approximates" is a synonym for "is not". Elsewhere, it says, Category chains formed by parent–child relationships should never form closed loops. Well, duh. It would be fine if there was some way to determine which edges represented parent-child (i.e. is-a) relationships, but there's doesn't appear to be.
    I once wanted to find all the music-related articles in wikipedia. I did the obvious thing; I started with Category:Music and tried to enumerate all the articles which were transitively a member of that category. Many days later, I gave it up as a lost cause. -- RoySmith (talk) 14:51, 9 September 2020 (UTC)
    Yeah, I remember a few years ago I found out that almost half all articles in the encyclopedia are somewhere in the category tree under Category:England. – Uanfala (talk) 01:48, 28 September 2020 (UTC)
    @RoySmith: isn't this is an example of GIGO? Every article in the subtree of Category:Music is "music-related", however remote the connection may be. Maybe you had something else in mind than "music-related"? For exapmple, to get a list of all songs, the subtree of Category:Musical compositions can be used instead, which doesn't seem to contain anything apart from compositions.
    That being said, I've been in the trap myself and learnt the hard way that the tree isn't acyclic -- though I don't seem to recall where or why the cyclicity was occurring. – SD0001 (talk) 16:12, 9 September 2020 (UTC)
    SD0001, I don't have the details handy any more, but what was going on was the traversal never converged. Once I realized that there were cycles, I added code to discover when I was re-visiting a node and ignore it. But that wasn't good enough. There were enough bogus edges that you would head off into the weeds when you traversed them and start discovering cats that had nothing to do with music. Sure, some of those were just bad data, but when you start with the constraints on the cat graph being as weak as "directed", it's really hard to explore it in any useful way, and it's really hard to do any useful error checkng. Imagine if I made Category:Barak Obama a subcat of Category:Barbershop music because he sang in a Barbershop quartet. Now a traversal starting from Music would suddenly be discoving all sorts of weird stuff. That's the sort of thing that was going on. -- RoySmith (talk) 17:07, 9 September 2020 (UTC)
    Would be interesting to let tsort crank on it for a while and find cycles as a project to fix. I can't figure out how to count the pages in the Category: namespace to get a handle on the order of magnitude of that task. DMacks (talk) 18:21, 9 September 2020 (UTC)
    2003278 existing category pages, plus however many redlinks with at least one page categorized in them - I can only find 273, which seems low, so maybe my logic was off. 6863520 categorizations of Category pages, i.e. edges. —Cryptic 18:46, 9 September 2020 (UTC)
    DMacks, https://quarry.wmflabs.org/query/47999. Spoiler: 2,047,712. -- RoySmith (talk) 18:54, 9 September 2020 (UTC)
    There are about 98K transclusions of {{Category redirect}}, which bots claim to fix. So that's 5% less CPU-catching-fire already. DMacks (talk) 19:04, 9 September 2020 (UTC)
    1,906,889 excluding all hard and soft redirects. But this doesn't include any red-linked cats with pages in them. – SD0001 (talk) 11:23, 11 September 2020 (UTC)
    Another more-manageable task is to clean out Special:UncategorizedCategories. It represents unreachable islands. DMacks (talk) 19:08, 9 September 2020 (UTC)
    One real problem with intersecting categories is inconsistent diffusion rules. For example, although a horror film released in 1977 belongs to Category:1977 horror films, it remains a direct member of Category:1977 films (see Template:All included) but not a direct member of Category:Horror films (see Template:Category diffuse). If one rule or the other were consistently applied to all categories, some demand for an oppositely generated view of each category (direct members plus or minus subcategory members, for whatever maintenance purpose) will always still exist. ―cobaltcigs 21:43, 13 September 2020 (UTC)
  • This guy's article is far from "busy" by any reasonable standard. He's perhaps best known for playing for 12 different professional basketball teams in 14 years, and is properly categorized as such. The above-proposed upper limit of "5 or 6" categories is totally unpracticable. Articles with that few categories tend to be permanent stubs (not that there's anything wrong with that). ―cobaltcigs 19:54, 13 September 2020 (UTC)
  • @DMacks and RoySmith: Getting a list of category cycles isn't the difficult part. I got a list of all parentcat—subcat connections from the database with just the page IDs (titles would of course make the output file unmanageably large) This doesn't seem to work on Quarry for some reason but worked fast enough (<15 mins) on the toolforge grid. Then I wrote an efficient C++ program to call out the cycles using depth-first search (runtime < 5 mins). It tells me there are 4106 cycles in all. Here are the first 5000 lines of output (cycles are shown with the page IDs only though). Now the tough part is what to do with this information? There are some cycles that contain just one page, eg. Category:Hidden categories contains itself! Some have just 2 pages: Category:Bill Gates contains Category:Gates family and Category:Gates family contains Category:Bill Gates, which seems to make sense! Then of course there are some massive cyclic chains that I don't know how to look into since the output contains just the IDs :( I guess I'll need to write some more code to make the output contain the category names so it's human-readable. – SD0001 (talk) 14:04, 15 September 2020 (UTC)
    SD0001, Cool, I'll take a closer look at that when I get a chance. Your Gates 2-cycle is endemic of one of the core problems: there's no rigid definition of what the edge relationships are. Neither of those are is-a relations, which would be fine, if the edges were labeled with what they represent. -- RoySmith (talk) 14:11, 15 September 2020 (UTC)
    It's easy: Bill Gates is a member of the Gates family, but the Gates family is not a member of Bill Gates. No need for a loop here. --Redrose64 🌹 (talk) 18:20, 15 September 2020 (UTC)
    Ah, I see converting the IDs to titles is easier done by the API rather through the database (500 IDs can be resolved in a single API call). The prettified output is here – SD0001 (talk) 20:22, 16 September 2020 (UTC)
I find categories to be highly valuable. highly. it is one of things that makes Wikipedia so valuable as a resource for research. for example, check out Category:Political charters, Category:Diplomatic conferences, Category:Clinton administration personnel,Category: Domestic implements, category: Firefighting in the United States. all of these bring together various articles and entries in a unique manner, to provide various correlations that many users might find helpful and informative. --Sm8900 (talk) 14:46, 17 September 2020 (UTC)
Sm8900, I'm not doubting you, but you could give some concrete examples of how you've used categories? I'm just trying to understand how they get used in real life, by real users. -- RoySmith (talk) 17:33, 17 September 2020 (UTC)

Script or bot to enforce rollbacks "in the spirit of WP:G5" for block-evading socks

Inspired by this discussion (permalink) and the repeated block-evasion by this IP. See Wikipedia:Banning policy#Evasion and enforcement for policy supporting undoing edits of block-evading editors.

It would be very helpful if a bot or script attempted to revert all edits by newly-blocked socks made after a given date and time, then delivered a report of which pages were and were NOT completely reverted so they could be scrutinized manually.

Even if this were an "admin-use-only" tool, the reports it generated would still be useful to non-admins editors doing cleanup work.

Any thoughts pro or con before I ask for it on Wikipedia:Village pump (technical)? Anyone want to volunteer to code it up?

On thing to be careful of: Such a script would undo edits banned editors are allowed to do, such as when the revert would re-introduce a WP:BLP issue. This is why the person running the script should do some spot-checking first to have high confidence that nearly all or all of the edits would be reverted if done by hand. For the same reason, certain name-spaces such as discussion pages should probably be skipped over and logged as "not done" by the script. davidwr/(talk)/(contribs) 18:41, 10 September 2020 (UTC)

Davidwr, I've been working on some SPI tools (https://spi-tools.toolforge.org/spi/). One of the functions is something like that. Select a SPI case, click the "G5" button, and it runs some heuristics to guess what might be G5 eligible related to that case. It's pretty rough right now. I work on it in fits and starts when the mood strikes me. -- RoySmith (talk) 18:51, 10 September 2020 (UTC)
Of course, the argument against such a script would be that some of the block-evading person's changes might be good for the encyclopedia. But I would be in favor of a ban-revert script despite the argument. One of the problems would be finding and reverting the ban-evading-edits that have been followed by unrelated changes to the same article. Basically it would involve looking at all the ban-evading edits, not just the ones which are the most recent changes to an article. Binksternet (talk) 18:56, 10 September 2020 (UTC)
True. Ideally, you would look at all edits after a specified date-and-time to see if they were created by the blocked editor under one or more specified accounts or IP addresses, then revert those you could and log successes and failures. davidwr/(talk)/(contribs) 19:17, 10 September 2020 (UTC)
There is already a mass rollback script (User:Writ Keeper/Scripts/massRollback.js) which identifies all latest-revision contribs by a user and offers to revert them. Its use has been controversial in the past, but at least one attempt to create a script more powerful than that was soundly rejected by the community as an abuse of admin tools (as I recall, that script could also automatically revdel contributions). I don't remember now which script that was but I see I also have User:Writ Keeper/Scripts/massRevdel.js in my .js, but I'm not sure what it does. Ivanvector (Talk/Edits) 16:23, 18 September 2020 (UTC)

Proposal: Move references to bottom of article (like e.g. in German WP) have external links etc above the reflist

Hi,

I mostly write in German WP, where the reflist ist pretty much the last thing in the article. I find that more convenient for the readers. Esp if the reflist is long, the external links, which quite often are great … tend to get overlooked, because they follow a million lines of small print not meant for consumption. I would suggest changing the order to having the reflist follow the external links… :-)) --Satu Katja (talk) 09:59, 13 September 2020 (UTC)

The current order is preferred because references are more part of the article than external links are. --Izno (talk) 12:22, 13 September 2020 (UTC)
Izno, To be honest, I think there's merit to the suggestion, but from a practical point of view, it would require a huge (and error-prone) robo-editing job to go back and re-shuffle 6 million existing articles, which seems like a non-starter. -- RoySmith (talk) 13:24, 13 September 2020 (UTC)
Something something separation of content and presentation something something   –Deacon Vorbis (carbon • videos) 14:36, 13 September 2020 (UTC)
True, re-shuffling 6 Mio articles is quite something, and that would have to be considered… But esp. in long articles (… and articles that cover major topics usually tend to be long) the reflist can be hunderds of refs. "WW II" has 414 refs, I never saw that there are "external links" underneath until I specifically scrolled down to counts the refs. My guess is that the majority of the readers will have the same experience… and that is quite a pity, they were put there for a purpose and it'd be great if they were seen… --Satu Katja (talk) 15:18, 13 September 2020 (UTC)
My experience of external links has been rather different. I have very rarely found any to be useful, and they are often lists of spam links or links to various social media sites owned by the article subject. And remember that references are also there to be seen. They are the most important part of any article because they are the only means by which content in the encyclopedia that anyone can edit can be seen to be reliable. Phil Bridger (talk) 15:47, 13 September 2020 (UTC)
So I think ideas like this stem from the wrong-headed view of "References" as some kind of edit war monument which no reader actually wants to see. References are part of the article, unlike the other articles listed in "See also", which in turn are more part of the website than any external links could be. That seems like a natural descending order of relevance, and was considered normal before the bury-the-refs movement. Disclaimer: However, if I were trying to promote my own external website(s) I would absolutely want my links to be floating somewhere above the first paragraph, and want the references section to be written in the smallest font possible, hidden in a scrolling collapsible box, perhaps even moved to a separate page and PGP-encrypted because fuck fact-checking anyway. ―cobaltcigs 15:55, 13 September 2020 (UTC)
Hi there, I am bit taken aback by the tonality of the replies, not by the fact that you disagree. I made a suggestion based on my experience in another WP, the German one, which is one of the largest WPs, and in which the order is the other way around: the reflist below the external links. There are obviously pros and cons for both concepts. I had heard at Wikimania in Stockholm 2019 that the English WP has become harsh and abrasive, and yes… feels true.--Satu Katja (talk) 18:36, 13 September 2020 (UTC)
I don't see anything harsh and abrasive here, but simply the fact that some editors agree with you and others disagree. If every proposal was greeted with unconditional support then we wouldn't have any discussions, but the first mover would simply always have agreement. Phil Bridger (talk) 19:59, 13 September 2020 (UTC)
I dunno, Phil. Saying that this idea would help the spammers does feel a bit harsh to me. WhatamIdoing (talk) 18:07, 16 September 2020 (UTC)
Sorry, but there's nothing harsh about it at all - it's simply people's experience of editing the English Wikipedia, which may be different from other language Wikipedias. If such a response is not to be allowed then there is no point in having any discussions. Phil Bridger (talk) 19:29, 16 September 2020 (UTC)
There's a distinction to consider between the importance of having references show up prominently when readers hover the cursor over the footnote, and having them show up prominently all together in a big chunk at/near the bottom of the page. The former is clearly very useful and important, the latter much more debatably so. {{u|Sdkb}} talk 04:07, 14 September 2020 (UTC)
Like others noted above that would be a big job moving everything around. Otherwise I kind of like the idea. I rarely browse the ref section by itself, I always go direct from the article. I do however browse the external link section since that can have some useful things. I would imagine most readers look at it that way as well. The important thing for the ref section is that it exists, not necessarily where it is on the page. Where as it can be nice to have the see also and external links more accessible. PackMecEng (talk) 20:18, 13 September 2020 (UTC)
Given that most readers aren't reading articles in their entirety from top to bottom, I actually think there is greater prominence having the external links at the end. Once people know the convention, then can jump to the bottom of the page to find the links. isaacl (talk) 16:18, 14 September 2020 (UTC)
I tend to agree with Isaacl. The very end of the page isn't necessarily the least prominent position. WhatamIdoing (talk) 18:07, 16 September 2020 (UTC)
Or use the table of contents, which is a list of wikilinks for a reason. ―Mandruss ☎ 19:56, 16 September 2020 (UTC)
As mentioned references are part of the article. Also there are often "bibliographies" "sources" etc. sections that come below a reference section. Do all of them get moved to the bottom or just the refs. I for one would not want to see the refs below a batch of ELs and categories as say at the Cary Grant article. IMO this is a solution in search of a problem and, thus, no change is needed. MarnetteD|Talk 20:16, 16 September 2020 (UTC)
  • Strongly opposed. In articles I see the EL section is typically very weak & stuffed with dead links, spam, or non-RS stuff. Also per Isaacl. Johnbod (talk) 14:55, 17 September 2020 (UTC)
  • Oppose This feels like a solution in search of a problem. I see no inherent benefit to one ordering over the other, and because of that, the proposal represents a large effort to be spent on zero net benefit. No need for it. --Jayron32 14:59, 17 September 2020 (UTC)

I like the present order of the ancillary sections at the end, because there is a logic to the order. "See also" points to material in Wikipedia; "References" points to material outside Wikipedia; "External links" points to unconnected material on the Internet outside Wikipedia; & "Further reading" points to material outside the Internet. (Okay, the last two is the order I put them in, but I've worked on less than a dozen articles that had both of those sections so which of the two should be at the end is a debatable matter.) -- llywrch (talk) 22:00, 17 September 2020 (UTC)

I'm always amazed by how different the articles you work on seem to be from those I work on, which generally have both. Nearly always this is FR then EL, as Wikipedia:Manual of Style/Layout implicitly suggests, but does not mandate. Johnbod (talk) 02:25, 18 September 2020 (UTC)

White text and templates

I decided to start development on a dark mode for the vector skin, which has white text on a black background. (The colors of links are also changed for legibility.) I noticed that various templates with a colored background make the text illegible. I was wondering if a module could be implemented to adjust the template's colors to match the user's default text color, or if the text in such templates should default to black. Alternatively, is there a way to work around this issue? To test the (pre-alpha state) dark mode yourself, go to Special:Mypage/vector.css and redirect the page to User:LaundryPizza03/nightvector.css. I'm sorry if this overlaps in scope with WP:VPT. –LaundryPizza03 (dc̄) 08:51, 14 September 2020 (UTC)

LaundryPizza03, I think you're more likely to get a useful answer at Wikipedia:Village pump (technical). WhatamIdoing (talk) 18:08, 16 September 2020 (UTC)
I have used a similar gadget, which is green-on-black - I've experienced this issue quite frequently, especially with WP:IGLOO and user signatures. -- a lad insane (channel two) 21:44, 17 September 2020 (UTC)

Idea: The Deleted Namespace (or deletionspace)

Recently, an article I was thinking about editing got deleted in the AfD process. The log is here: Wikipedia:Articles for deletion/Iron Golem (Minecraft). The article in question might pass WP:GNG after some time in development, most likely in the Draftspace. Unfortunately, I cannot easily edit this, or any other previous article, without either contacting an administrator or using a third party like Deletionpedia.
I propose a new namespace called the "Deletion Namespace" or "Deleted:". The namespace will archive deleted articles and allow them to be available after deletion. The page will function as a "morgue" of pages that have been archived but are still available for reference. They will not be editable, but instead you will be able to view source code and Wikitext. Version History will also be available to view. If you want to edit the article or revive it in order to improve it, there will be a button to do so (the normal Move button would be restricted, maybe?). This will convert the article to a draft, where it can be worked on in the Draft space until any problems that lead to the article getting deleted are resolved. Then it can be submitted in the AfC process, and potentially accepted into the Namespace. This allows articles to have a second chance at life without compromising the existence of the Articles for Deletion process.
It will essentially function like Deletionpedia, but would integrate into the namespaces for ease of use. Is this a reasonable idea? Any and all feedback is appreciated. Squid45 (talk) 20:47, 15 September 2020 (UTC)

  • Genius idea. I like it. Would be a really good porposal. Fixing a deleted article for all the other reasons mentioned in the AfD deletion would open new opportunities for pages to go "out-of-order" for a few days, then be in-order for a long time. It would also wipe Deletionpedia off the internet, which could open up alot of new editors on Wikipedia. Arsonxists (talk) 20:57, 15 September 2020 (UTC)
  • See Wikipedia:Perennial proposals#Deleted pages should be visible. davidwr/(talk)/(contribs) 21:00, 15 September 2020 (UTC)
  • This idea has a bevy of issues, but the main problem is that the whole point of deletion is to remove problematic content from public view that cannot be improved through normal editing. If an article were potentially salvageable, it would not have been deleted in the first place. If you think an article is potentially salvageable despite being deleted, what is so hard about asking an administrator to restore it to draftspace? – Teratix ₵ 00:59, 16 September 2020 (UTC)
    I find your excess of faith disturbing. On the contrary I suspect several salvageable articles are deleted every day (with the other 90% or so indeed being total shit). Browsing the deletion log to guess which titles might be worth requesting a copy of is not a reasonable strategy. The average admin would probably block you after the third unlucky guess. Separation of permissions might be the answer. ―cobaltcigs 23:04, 17 September 2020 (UTC)
    I was thinking more about articles that the salvaging editor has already seen or is otherwise familiar with (such as the scenario at AfD outlined in the original suggestion). I'm not suggesting randomly combing through deletion logs. (And in any case I'm highly skeptical the "average admin" will block editors just for making "unlucky guesses" about which content may be worth restoring). – Teratix ₵ 01:45, 18 September 2020 (UTC)

I think that all inclusionists and people who follow the original vision of free access to all human knoledge should fight as hard as possible to get articles undeleted and included in an inclusionist encyclopedia. I think instead of a deleted namespace a group of administrators should make a database of non copyright violation and non vandalism edits available to download so inclusionist encyclopedias can adopt them. There is a considerable demand for "non notable" content, look how popular sites like Fandom, Everipedia and Everybodywiki are. If you look at the archives of the deletion log and articles for deletion over the years over a million articles has been deleted from Wikipedia establishing a two tier knowledge system. I would argue Wikipedia is the biggest destroyer of knowledge since the library of Alexandria. 94.175.6.205 (talk) 11:18, 30 September 2020 (UTC)

Proposal: Per-user/IP "pending changes protection" for low-competence editors

Proposal: Per-user/IP "pending changes protection" for editors demonstrating persistent low competence as a final step before blocking or in ideal cases, as an alternative to it.

Currently, you can block an editor from up to 10 pages or from a namespace, for example, you can prevent an editor from editing articles while still allowing him to edit other pages (see Wikipedia:Blocking policy#Setting block options, "Block editing partial").

What you cannot do is make all edits by a given editor automatically become "pending changes" even on pages that do not have this protection.

I recommend this as an intermediate step for users and stable-IP editors who are on the "slow march" to being blocked due to competence-issues. It would also be useful as an alternative to or final action before imposing school-blocks, which are sometimes places on an IP address or range for the duration of the school year.

This would also be useful for established editors with a conflict of interest who have demonstrated they can edit responsibly. Currently, such editors have to make an edit request on the article's talk page. This mechanism would allow responsible-COI editors to ask permission to edit conflicted pages directly, knowing they would be reviewed before being seen by non-logged-in editors.

This proposal would require a code change so I wanted to do a straw poll and get preliminary feedback here before taking it to a wider forum. Because it will need some preliminary discussion at WT:Protection policy, a full RFC, and a code change, I don't anticipate this going live before 2022.

Thoughts? davidwr/(talk)/(contribs) 16:02, 16 September 2020 (UTC)

This seems like a good idea. It would give pending change reviewers alot more power among wikipedia. Editors that (for some reason) turned on Wikipedia and started vandalising it could be foiled with the blocks. Arsonxists (talk) 17:21, 16 September 2020 (UTC)
My concern is that it would only take a few reasonably active editors (or even slightly more somewhat active editors) to overwhelm PCR. The system is very clunky, and an absolutely nightmare when you get more than one edit to a page (if some, but not all, are non-productive edits). I've long seen there to be more potential utility for PC, but it's fiddliness detracts from that. Nosebagbear (talk) 09:30, 17 September 2020 (UTC)
I don't see this as being a major issue if it were per-user-per-page. In most cases, a "still learning...slowly gaining competence" editor would be subject to "user-based" pending changes on only the few pages he's been editing disruptively, which would probably NOT include discussion pages. If they didn't "get a clue quickly" they would find themselves blocked from editing those pages. If they did "get a clue" the per-user pending-change restrictions would be removed. davidwr/(talk)/(contribs) 19:45, 17 September 2020 (UTC)

Alexa Rankings

Make further comments at Wikipedia:Village pump (proposals)#RfC: Alexa Rankings in Infoboxes. {{u|Sdkb}} talk 19:46, 25 September 2020 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

This is a query for ideas. What to do about Alexa Rankings in infoboxes (example WebCite).

  1. Enwiki has about 7,000 instances of {{infobox website}}
  2. The Alexa numbers change monthly. In a sane world it would be retrieved via automated means but..
  3. The ranking data is proprietary (Amazon) and there is a fee to access it via API ($0.01 per site) and you get the top X number of results ie. can't specify which website to get results for. Thus if you want ranking data for a particular website in the top 1 million it is very costly.
  4. The data can be web scraped.. but when done on a regular basis and loaded into Wikipedia it would almost certainly violate a copyright or terms of use rule, if not an outright IP block.
  5. The data can be manually added to Wikipedia.. but this is done sporadically see the WebCite example (2 years old as of this post), I have seen some over 5 years out of date.

As such, we have no legal way to automate the stats updates that isn't very costly, and manual updates are sporadic. As a result the Alexa numbers quickly become outdated and perhaps worse than nothing if misleading. Relying on the community to manually update over 7,000 infoboxes with proprietary data on a regular basis is a Sisyphean job. At the same time, there is a desire for this sort of thing from the community. What to do (if anything)? -- GreenC 01:40, 17 September 2020 (UTC)

I have previously argued that this data should be removed, much for the reasoning above. (I don't know where or if this was even onwiki.) --Izno (talk) 01:52, 17 September 2020 (UTC)
Previous discussion. --Izno (talk) 01:55, 17 September 2020 (UTC)
@Izno: Excellent forgot about that discussion. Good. It looks like consensus was trending to delete Alexa, but there was no RfC "Should we remove Alexa from infoboxes" to make it official. There was some support to have a template for the top 1000 sites, but that would again run into the problems mentioned above of data being outdated and copyright/TOU. Still it might link to Alexa and any other ranking sites without displaying a rank #, users click through. Do you think a VP RfC along those lines has some chance of consensus? -- GreenC 02:56, 17 September 2020 (UTC)
I think there is a fair shot of removal with an RFC at VPPRO or maybe even the temppate in question. --Izno (talk) 14:14, 17 September 2020 (UTC)
Its a good idea to move the idea to the proposals about deleting the Alexa Rank. Pretty sure RFC consensus will be supporting with it. Arsonxists (talk) 17:46, 17 September 2020 (UTC)
@Izno and Arsonxists: would you mind looking at an RfC proposal at User:GreenC/sandbox for any changes or comments? Found new API information that allows 1,000 free queries a month which opens an additional pathway. -- GreenC 18:21, 17 September 2020 (UTC)
@GreenC: I made some edits that I think go a slightly better direction. --Izno (talk) 19:36, 17 September 2020 (UTC)
Added the summary of problems and the number of domains needing tracking. -- GreenC 20:49, 17 September 2020 (UTC)
@GreenC: I think that the RfC is pretty satasfactory and should be released. Arsonxists (talk) 21:18, 17 September 2020 (UTC)
Alexa rankings get changed every single day, but not updated here. The more obscure a website is, the less it gets updated. And because it gets a very small websitebase, the ones in position next to them only need very small amounts added or removed from their userbase to get their rank changed. Meaning that: 1) On small website's articles, their Alexa rating is rarely ever correct.2) The rating on the article can be KILOMETERS AWAY from what the actual rating is.3) And the rating only gets updated very rarely. Meaning that it's an effect where the rank changes alot, but no one is there to change it. In conclusion: Yeah, it's a good idea to erase Alexa rankings entirely. Arsonxists (talk) 16:59, 17 September 2020 (UTC)

Update New RfC now open at Wikipedia:Village_pump_(proposals)#RfC:_Alexa_Rankings_in_Infoboxes. -- GreenC 17:21, 18 September 2020 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

idea for new editing approach: "consolidationism"

I would like to think about laying out a new approach to editing in general, to be combined with the term "inclusionist." my working name for this "consolidationist," but right now that is just a suggested label. I am open to ideas on what to call this.

my idea for this approach is this; one core ideal of encyclopedic work should be greater topical overviews that are specifically designed to address and to weave together various historical topics, that already have their own entry, but which deserve some place within a larger overview for broader topics, eras, regions, historical movements, etc. right now, I am focusing on history as a topical field; we can apply this to other fields.

Two basic components for this idea, just as a start.

1) Firstly, one aspect of this is that every individual war or conflict, and other similar major historical events, should appear somewhere in a wider history of the era when that war occurred. so for example, clearly World War I already figures heavily in any overview of the era that it occurred. however, the Balkan Wars of 1911-1912 were of great importance as well, especially as a prelude to World War I and the other European conflicts. so that is just one example.
again, in general. as one core idea, we should seek to make overviews of historical eras into genuine topical overviews , and try encompass all of the smaller conflicts, events, that combined to shape that era. but again, the focus would be on building such overviews from "the ground up;" namely first would come the article on the specific conflict, event, trend, etc. itself., and then the originator would seek to add it to the broader entry for that era.
2) Secondly, on a different but related note, Wikipedia should seek to continually update its chronicle of current history, going forward. we already are a great exhaustive resource on past history. we should seek to do so on a broad scale for contemporary history as well. we already are great at generating individual articles for current events, as they occur; my point is that I would like to see some more attention to also generating and maintaining a broad historical overview for the current era, and updating it as events occur.
we already have 2020s in political history, for this purpose. I would like to suggest that we continue to make this a priority; that we focus on continuing to keep this series of decade overviews going. also, "consolidationism" would look into how to effectively adhere to WP:Notability, and to document current events, without falling into the trap of WP:Recentism. for example, several years ago, the US congress changed the Speaker of the House. No one thought to add that event to any of the overviews for that era, so I added it. obviously, we can't document everything; however, there should be some kind of standard of WP:Notability to work with here.

this is just an idea right now, so this page is the best place for it. I am not planning to move this ahead to a formal proposal right now. anything I do in the future will be shaped by whatever input I get. this doesn't need to be a formal proposal anyway; it can simply evolve, as people express ideas, interest, input, etc. etc.

ok, so what do folks here think of it? I assume the idea itself sounds rather innocuous, but feel free to call out any and all details on how we might put this into practice. whether you totally agree, or disagree, or find this interesting, or find it a little superfluous, your feedback is welcome. I appreciate it. thanks!! --Sm8900 (talk) 14:22, 17 September 2020 (UTC)

section break 1, consolidationism discussion

You should review WP:SYNTH. Writing on topics that have occurred in the past few decades at a high-level is not really possible because the experts in history have not written the texts we would need to summarize the high-level. (I've even seen 50 years thrown around as the number before historians have sorted out who won and who lost in topics other than the discrete end of a war.) That would leave us writing synthetic commentary. Which is not allowed. --Izno (talk) 15:57, 17 September 2020 (UTC)
Ok, I partly agree with you, and I partly disagree. if that were fully the case, then it would not be possible to write an overview of any current eras, topics or events,would it? and yet.... isn't Wikipedia chock full of entries on items and events that are happening now? yes, you could say that the ultimate notability of these events is not fully known or understood yet, but that only highlights my own position on this. we cannot know the future notability of events taking place now, and yet, there are those entries.
yes, I fully understand that you are saying something different, i.e., that no one can yet know how specific events or topics would fit into larger overview articles. but with respect, I disagree with that as well. we already have widely used overviews for the current era right now, as well. they just are not necessarily explicitly labeled that way. so the best examples of such current era overviews would be articles such as Presidency of Donald Trump, premiership of Boris Johnson, 2020 United States presidential election, etc etc...
in other words, articles that describe current political figures, are often actively updated when those figures do something current that is noteworthy. there is no controversy over that practice imho, and there is widespread acceptance, of the fact that these articles are edited to reflect current events that are happening now. --Sm8900 (talk) 03:51, 18 September 2020 (UTC)
Izno, interesting thought. I've made a bit of an effort in the past to shape up Human history#21st century; how do you propose we write that section, or would you have it just deleted? {{u|Sdkb}} talk 19:52, 25 September 2020 (UTC)

Sidebar on mobile

There recently was a redesign of the sidebar on the desktop version of Wikipedia at an RFC. I would like to discuss how we can improve the sidebar on mobile. This is what I think it should include at a minimum.

  • A help link
  • An introduction to Wikipedia page
  • The contents page

I welcome any other ideas on how we can improve the sidebar in mobile and once we get some ideas, we can start an RFC on how the sidebar on mobile should look like. Interstellarity (talk) 16:37, 22 September 2020 (UTC)

Diffs: Single quotes to double-quotes, how to tell?

See this diff and note |opentheme=. A change was made, but did someone change double quotes " to single quotes ''? Feels like there should be an easy way to determine this by now without having to scroll down to look at the output in the infobox. Maybe a super-script or something up in the diff area? " [DQ] '' [SQ] Cyphoidbomb (talk) 13:24, 25 September 2020 (UTC)

This is a specific case of diffs not being sufficiently distinctive in many cases. My pet peeve is somebody adding/removing a space, changing a period to a comma, etc. These can be difficult to see in the middle of a big diff. Likewise O vs 0, l vs 1, and other pairs of characters which are visually indistinguishable in many fonts. That last problem multiplies many fold when you include unicode. So, yeah, I'd like to see a redesign of the diff screen which gives you the option to drill-down into more detail, and/or more obviously highlights the changes. -- RoySmith (talk) 14:49, 25 September 2020 (UTC)
Try WP:WikEdDiff; it should catch most of those. --Izno (talk) 14:59, 25 September 2020 (UTC)
Izno, Wow, thanks. I'm going to install that. Looks like exactly what I need. Did I mention that my eyes aren't as young as they used to be, so I need all the help I can get :-) -- RoySmith (talk) 16:54, 25 September 2020 (UTC)
I actually see that change as being fairly obvious, and for once WikEdDiff does a bad job of highlighting the difference; the stock-diff looks absolutely fine to me. --Izno (talk) 14:59, 25 September 2020 (UTC)
I use vector, and they look identical to me. And WikiEdDiff, which I've had installed for years, doesn't help me out here. And, I'm guessing, it wouldn't help out newer editors if newer editors don't know that it exists. Cyphoidbomb (talk) 14:51, 26 September 2020 (UTC)
For me, the recent change to use the same monospace typeface used in the edit box as the typeface for diffs has made the difference between single quotes and double quotes clear. From the previous discussion on the technical village pump, I believe you might have overridden this change. You can follow some of the instructions in that discussion and choose any font you have available on your computer instead of the "sans-serif" font, which is configured in your browser. You can also use any of the free fonts from Google, accessing them from WMF servers instead of Google: see User:Isaacl/style/diff-mono-font.css for some fonts I have tried. isaacl (talk) 15:14, 25 September 2020 (UTC)
Your meta:User:Cyphoidbomb/global.css file has set the font used in the diff view to "sans-serif". You can pick a different font that is more suitable for you. isaacl (talk) 15:16, 26 September 2020 (UTC)
Cyphoidbomb, isaacl is correct. Two single quotes are very easy to distinguish from double quotes in a monospaced font: '' vs ", but hard in a sans-serif font: '' vs ". 62.216.206.114 (talk) 23:19, 1 October 2020 (UTC)
They look pretty different to me, with the single quotes having a large space between them. Maybe it's related to a gadget, as mentioned by others above? Isabelle 🔔 15:32, 25 September 2020 (UTC)

With regards to the WMF renaming controversy, why not rename Wikipedia?

The WMF wants this name change. That much is clear. The rank and file volunteers of the Wikipedia project have little say in the matter. That much is clear. So instead of trying to do the hard or impossible (convincing WMF not to go through with something they're already decided on), why not solve this problem with a change we actually have the power to effect: let's rename Wikipedia instead. I don't have any immediately great suggestions for names; I'll leave that to smarter people than myself. Renaming wikipedia would:

  • prevent WMF from squatting on our legitimacy
  • draw attention to the issue (we'd get plenty of news coverage for "Wikipedia changes its name, here's why", much more than you'd ever see for "Wikimedia's holding charity changes their name to align its brand strategy")
  • draw attention to the Foundation itself (front-page news coverage talking about the foundation, even in a likely negatively light as above, would serve their goals of increased visibility)
  • probably not drastically impact our searchability. Google is very good at routing around name changes of this sort, so if (silly name for example) Kumquatpedia suddenly had the editor base and activity of Wikipedia, and wikipedia was permanently redirecting there with a 302, it wouldn't take long for us to be as popular as ever on google
  • Wikipedia kind of sucks as a name. It's not easily initialized (WP sort of works but is indistinct and inelegant; "double-yoo pee" or "dubya-pee", neither of which are appealing IMO) and both the wiki- prefix and the -pedia suffix are victims of Wikipedia's own success.
  • To the extent that it reduces traffic, that seems more likely to hurt the WMF than the wikipedia project. Wikipedia is a major source of fundraising for the WMF.

2600:1700:EFA0:2980:40C0:BAC7:107B:5DDF (talk) 19:55, 20 August 2020 (UTC)

This is not the place to discuss this. The English Wikipedia has no control over the name of the WMF. Consider taking this to a relevant discussion at Meta-Wiki. P,TO 19104 (talk) (contribs) 16:56, 21 August 2020 (UTC)

Strongly oppose renaming Wikipedia. Users of the world wide web are likely to be familiar with Wikipedia, especially since it has a high Google search, and renaming it would only result in confusion. Vorbee (talk) 21:39, 1 September 2020 (UTC)

I mean, isn't it up to the Foundation what to name the encyclopedia? For good or ill. At the top of each page where it says "Wikiedpia", can regular editors change that? Or the domain name, and so forth.
The whole internet uses the Wikipedia, so if we do change the name, we could have an internet-wide open vote. On second thought though, would probably come down to race between "Encyclopedia McEncyclopediaface" and "Hitler Did Nothing Wrong", so maybe not. Herostratus (talk) 19:11, 3 September 2020 (UTC)
Well, yes, this web site's name is controlled by its owner, the Foundation, so you are right. But apart from that one obvious and probably insurmountable problem, which I'm sure the original poster here was really aware of, this is a wonderful idea, which doesn't warrant a po-faced response of "strong oppose". OP, please keep thinking laterally. Phil Bridger (talk) 19:51, 3 September 2020 (UTC)

Po-faced response of strong oppose. Phil, I'm surprised at you, are you feeling ok? I'm undecided whether this is trolling or just one of the worst proposals of the year. We are not going to abandon one of the most widely-recognized brands in world history without far better reasons than those presented, even if we had the authority to do so. ―Mandruss ☎ 20:20, 3 September 2020 (UTC)

Definitely po-faced. And I'm feeling quite all right, thanks. Had a wonderful trip to Whipsnade Zoo today with my grandson. Phil Bridger (talk) 20:30, 3 September 2020 (UTC)
  • The proposer says Wikipedia kinds of sucks as a name. However, Wikipedia is a portmanteau of "Wiki" (the Hawaiian for "informal" or "quick") and "encyclopedia". Since "Wiki" means a website that any one can edit, calling this website "Wikipedia" makes it fairly self-explanatory what it is. As for the note about Wikipedia being difficult to initialise, I do not see what is wrong with calling it "WP".

It is true that "W" is the only letter in the Latin alphabet that has more than one syllable in its name, so it would take longer to say "WP" than other possible initials, but since people are more likely to type WP or write WP than say it, I do not see a problem. Vorbee (talk) 05:56, 4 September 2020 (UTC)

I oppose renaming "Wikipedia." the current name incorporates the ideas of "wiki" and "encyclopedia." we are the world's greatest wiki, and also the world's biggest and most comprehensive encyclopedia, ever. so I don't see any reason that we should not just stick with the name that we currently have. thanks!! --Sm8900 (talk)
  • Convincing the WMF to do a Uturn is hard, but far from impossible. They have done multiple Uturns in the past when they have been under similar pressure to the current situation. Given the flak they are already receiving over the rename proposal I would say that the WMF backing down is the most likely result, it certainly isn't "hard or impossible". Renaming Wikipedia without the WMF's agreement would be hard, much harder than getting the WMF to do a uturn. Wikipedia is the site's current domain name, the WMF owns the trademark on it and the servers that host it. I can't see them agreeing to give up the Wikipedia brand unless something truly horrendous happened to the brand (in the early years of the internet I was working for a pan European company that was rebranding all its operations to use the same company name, then we discovered that someone in the US already had the domain name we wanted and was using it for a site that taught you how to grow Marijuana. So we rebranded to a completely new name). If we ever decide to fork and leave the WMF we will likely lose the Wikipedia name, again a hard project, much harder than getting the WMF to do a rebrand. The current problem is not really strategic to the WMF, some marketing person has convinced them to dilute the Wikipedia brand by widening it from an encyclopaedia to the whole Wikimedia movement. As they realise the scale of the community dislike of this I expect a Uturn. Where I think we would have a hard job persuading them to change is something really strategic to them such as the idea of having a universal code of conduct for the whole movement. ϢereSpielChequers 10:32, 6 October 2020 (UTC)

Switch to flat icons?

It has been my belief that Wikipedia looks a bit... dated. We still use skeuomorphic design in many areas of the encyclopedia from certain templates to default skins, and we still use a skin with a design that became dated in 2015.

Last time I proposed switching to flat design, I was told that my proposal was not ripe enough to be suited for an RfC. What I would like to do here is consider developing my proposal into something that may work in practice and that reflects the general consensus here.

It is good to note as well that we have switched from gradient padlocks to flat padlocks because of accessibility and contrast as well as aesthetics.

I already have an idea on what some icons could be replaced with, which can be viewed here. Because this is a major change, I think it would be good to get consensus first, which is why I am asking for input on how to develop this. I just want to develop this proposal further to see if we can make Wikipedia look more modern. Aasim 22:32, 4 September 2020 (UTC)

@Awesome Aasim: I'm still not seeing the full range of icons addressed in the draft proposal, and in order to be effective, the switch will need to be comprehensive (otherwise it'll just introduce another competing standard). I used the nutshell icon last time as an example — what do you propose to do for that at {{Nutshell}}, and for the many other icons still not included? {{u|Sdkb}} talk 19:52, 7 September 2020 (UTC)
And, as also stated in previous proposals, can you give any reason other than trendiness for this? I, for one, choose to edit Wikipedia in preference to other activities precisely because it does not bend to the latest fashion, but takes a long-term view of things. Phil Bridger (talk) 20:01, 7 September 2020 (UTC)
I feel 'flat' icons are, well, flat! The current icons are metaphorical—they link to, well, iconic, concepts. A red octagon is (in the US anyway) instantly recognized to mean "Stop"—the hand palm makes the sign universal. Any extra cues in an icon as to meaning is a plus. These cues are primary in designing a large set of icons. "Modern" is way down on the list. Icons in Wikipedia are part of a work environment. I value icons that require no more cogitation than necessary. Recognition at a glance is a good thing. Bland uniformity is not. Perhaps your proposal might gain more acceptance if the images were more distinct. — Neonorange (Phil) 22:12, 9 September 2020 (UTC)
It's actually not that bad of an idea... for example, the icons on the French Wikipedia are already flat! And, I really think that Wikipedia needs new icons, because some of them look really dated in this internet time. But, I wanna point out that in your icons, some of them (especially the warning icons) look like they were ripped straight from Windows 10. It's probably a good idea to change those. Arsonxists (talk) 17:55, 10 September 2020 (UTC)
Any change is going to cause confusion, except for the trash can (which conveys more skeuomorphic meaning than the status quo) to symbolize deletion. Most of others are either a lowercase "i" or an exclamation point "!" (which look almost the same in a sans-serif font) to very subtly indicate severity, in front of a circle, the color of which indicates who knows what. There's no point in having a dozen icons that all look alike. ―cobaltcigs 22:18, 16 September 2020 (UTC)

Aa I personally love the aesthetics of wikipedia's icons, it's reminiscent of a time when the internet was exciting, and intimate, like everybody knows your name, long before big corporations and advertisements, and tracking. People did things because they were fun! I think if we were to change the icons, the beauty of wikipedia would be gone. JazzClam (talk) 22:51, 23 September 2020 (UTC)

There is a mix in this proposal from ones I see as an improvement such as the tick for an unblock (open handcuffs would be better) to ones that I don't see as helpful such as moving from the broom to something that doesn't seem meaningful to me. I would be happy to see some icons replaced with ones that were more instantly meaningful to more people, maybe an orange jumpsuit for blocks. But the overall direction should be less abstract and more universal, not more abstract as the flat concept seems to be. ϢereSpielChequers 10:50, 6 October 2020 (UTC)

More concrete procedures of verification for new editors.

I had been spent long time here and noticed that so many new editors has been blocked as a sockpuppet or glitch in there Ip address that matches some other accused or for having same opinions and ideas about particular subject matters. What if there should be more concrete process for verification for new editors. So that they can't face unnecessary blocking without explaining themselves for once. In most case scenarios People go through lots of assumptions and presumptions here which sometimes not be the truth.

Suggested ideas.

  • 1. Photo verification
  • 2. Providing a separate name and I'd for new editors for verification when they login 1st time.
  • 3. Conducting surveys every month to ensure their interest and what they think about Wikipedia. [Example like YouTube, Twitter and Instagram].

Redcap78 (talk) 04:13, 18 September 2020 (UTC)

No. Just no... I don't think Wikipedia should be getting stuff like this. It would hurt PR, and we would also lose our <13 editors. Arsonxists (talk) 15:06, 18 September 2020 (UTC)
No. This will just cause more people to either leave or edit as IPs. Judge accounts by their actions and edits. If someone is a vandal or sockpuppet that will be determined in time. RudolfRed (talk) 00:02, 19 September 2020 (UTC)
I'm thinking of wrapping this up in a {{archive top}}/{{archive bottom}} because proposals 1 & 2 would go against wmf:Privacy policy. Regarding proposal 3: some of us - even admins - have accounts on YouTube etc. which we would prefer not to make public. --Redrose64 🌹 (talk) 09:35, 19 September 2020 (UTC)
On one side I understand the idea behind the proposal, however the verification options you've mentioned undermine core Wikipedia policies that helped to create what we have now. I'm talking about WP:Good faith and wmf:Privacy policy. Most of the IP and unregistered editors are good faith and having complicated the editing process we can loose a lot of them. This would bring more harm in my opinion.Less Unless (talk) 13:34, 4 October 2020 (UTC)

Biomedical Sciences: An idea to identify acceptable primary research for citations (in addition to citing reviews)

I am a professor at Boston University School of Medicine. I teach a class in which a semester project for each student is to create or edit a Wikipedia page.

For the health sciences, Wiki has the requirement that references must be from review articles. This makes a lot of sense, because it helps to insure the rigor of citations used in Wikipedia articles.

However…… this requirement presents a challenging barrier for my students (and many scientists). Very often, my students want to post on subjects for which there are not any reviews. Sometimes a subject is relatively new and has some high-quality primary research, but the ideas have not yet been synthesized into a review on the subject. Other times, the subject is about a topic for which there are articles, but the area has not garnered enough attention to be the subject of a review article. Yet another example is the discussion of clinical trials. Discussing clinical trials often benefits from citation of the primary research which includes critical details about the trial that are unavailable in reviews. Finally, in discussing a biomedical topic, often the primary research shows data that is not covered in reviews.

I have been pondering mechanisms that would allow Wiki editors to objectively know whether an article is sufficiently accepted in the field to allow use in a Wiki page. I have an idea that is based on number of citations:

What about if Wikipedia allows citation of primary biomedical research articles that have been cited in the biomedical literature a defined number of times. I’m not sure what that number should be, and it might very based on the field. However, my intuition is that simplicity is key, so I am thinking about a specific number of citations that would work for many (but not all) subjects. For instance, Wikipedia could allow citation of an article if Google Scholar or Web of Science shows that it has been cited in the biomedical or patent literature 100 times (the exact number would have to be discussed and refined). Thus, an editor could simply check Google Scholar or Web of Science to look at the number of times the article was cited. If it reaches the threshold (e.g., 100 citations) then it is allowed, but if it does not reach the threshold it is dis-allowed.

This approach would be very enabling for the sciences, because it would allow citations for important scientific articles, allowing more depth for Wiki articles. The use of Google Scholar or Web of Science would provide an objective source for determining if an article has been widely accepted in the field (a proxy for “scientifically rigorous” and/or “scientifically important”). The key question would be defining the threshold for the number of citations. Clinical articles tend to get more citations, whereas obscure fields (such as the study of anaerobic marine organisms) tend to get fewer citations. But perfect is the enemy of good enough.

A threshold of 30 would be more forgiving, whereas in my experience, 100 becomes less forgiving. It is also important to note that citations accrue with time, so older articles have more citations than newer articles. Thus, 100 citations might be an acceptable requirement for an article more than 3 years old, while 30 citations might be acceptable for an article published in the last 3 years. Finally, because authors cite their own work, it is important to make the number high enough so that authors can’t “cite themselves into legitimacy”.

My students are generally PhD students who like this approach because most other classes in their education encourage them to cite primary research articles, and limit citations to review articles. BrainMan2017 (talk) 20:08, 4 October 2020 (UTC)

  • We would have to be careful not to allow citation of original medical research, because Wikipedia has a policy of not allowing original research. However, if you are saying that we should have citations of medical research that has been cited a certain number of times, I think the idea is a good one - it is good to think that Wikipedia is using well-cited, academically respectable sources. Vorbee (talk) 08:55, 5 October 2020 (UTC)
Vorbee, thanks so much for your response. The focus of my comments are on original medical research that have been cited a number of times; often times these citations are in other original medical research articles or the citation in a review article does not give sufficient detail to be useful in Wikipedia. I think that Wikipedia does not currently allow citation of original research articles for biomedical research because there is not a metric for determining the strength of that original research. I am suggesting such a metric. BrainMan2017 (talk) 11:54, 5 October 2020 (UTC)
  • Hi BrainMan, thanks for your work with Wiki Ed. There are already some exceptions under WP:MEDRS for the use of primary sources, and some of the examples you gave will already qualify. However, it's exceptionally difficult to describe such sources without resulting in undue weight, and is not something I'd recommend trying for any new editor until they have a lot more experience on Wikipedia. More generally, academia tends to place far more significance on primary sources than WP, and reducing this tendency is one of the major issues among new editors from academia. In the specific case of using citation levels, the first issue that comes to mind is that it will sometimes result in serious mistakes. For example, Wakefield's MMR article has 330 citations in PubMed, and there are various ways of gaming citation counts, so I don't think such a proposal is likely to pass. While Wakefield's article is now well-known to be false, the principle still applies - I think it would be particularly likely to cause a problem with advocates in controversial topic areas trying to push their views on Wikipedia, due to said controversies being one of the ways that high citation rates can be achieved. Sunrise (talk) 16:01, 5 October 2020 (UTC)
  • I don't see that we should make any changes in this direction. As Sunrise noted, MEDRS already makes some exceptions. We do of course value when experts make contributions, but we prefer that experts show their expertise by their skilled awareness and use of sources that we prefer - existing secondary sources such as review articles and textbooks. For every real-world expert who is qualified to judge primary sources, there are amateurs, POV pushers, and "alternative medicine" COI editors who will, knowingly or unknowingly, cherry-pick primary sources they like. Allowing only primary sources over a certain number of citations only somewhat mitigates the issue, and a high risk still remains that the resulting text will have unintentional POV issues because of being written on the basis of narrowly-focused primary sources rather than review articles. Additionally, non-experts could just then claim that reviews don't exist in the area, so they just have to use whatever primary source. I notice that you mentioned "the study of anaerobic marine organisms", but stuff like that isn't covered by WP:MEDRS. Instead, WP:SCHOLARSHIP and WP:PSTS apply. Non-medical areas of science are not as strict as medical topics. Crossroads -talk- 16:57, 5 October 2020 (UTC)
  • Very often, my students want to post on subjects for which there are not any reviews. Sometimes a subject is relatively new and has some high-quality primary research, but the ideas have not yet been synthesized into a review on the subject. Then that very likely means this subject is simply not yet ready for Wikipedia. In a class, you may, as an expert, be able to filter out the wheat from the shaft, and guide your own students when it comes to primary research. But as Wikipedians, we can't do that, even though we may professionally be experts ourselves. See WP:VANPRED#Use in the real world vs use on Wikipedia, but apply the argument to primary sources instead of non-peer-reviewed ones. Headbomb {t · c · p · b} 17:12, 5 October 2020 (UTC)
  • Any quantitative metric is susceptible to being gamed, and Google Scholar in particular is vulnerable because it counts self-citations, non-peer-reviewed preprints, predatory journals, and PDFs it happens to find on random websites. I agree with Headbomb: very likely, some topics your students have chosen just aren't ready for this encyclopedia yet. Regarding the point that most other classes in their education encourage them to cite primary research articles, and limit citations to review articles, learning to adjust one's writing to the requirements of different environments is a part of being a student. XOR'easter (talk) 18:02, 5 October 2020 (UTC)
  • Wikipedia not being a journal should not be the place to report and publish novel developments that have not yet been covered by independent secondary sources. MEDRS (as it currently is) also has the advantage of preventing both undue self-promotion and pseudoscience promotion (i.e. alternative medicine proponents have their own journals). —PaleoNeonate – 18:45, 5 October 2020 (UTC)
  • If an study has been cited academically 30 or 100 times, surely some of those times are in a review. MEDRS is the application of policy, such as on reliable sources and WP:WEIGHT -- if nobody else is writing about a study, then neither should we. While selecting and reporting on the primary literature is something taught academically, it isn't what Wikipedia does. We build upon those who have done that, have have that work published elsewhere. -- Colin°Talk 19:11, 5 October 2020 (UTC)
  • I agree with Crossroads, who wrote "For every real-world expert who is qualified to judge primary sources, there are amateurs, POV pushers, and 'alternative medicine' COI editors who will, knowingly or unknowingly, cherry-pick primary sources they like." We already have a method for using a primary source that WP:MEDRS does not allow, which is to go to the reliable sources noticeboard and present an argument as to why this particular source and this particular topic is an exception to WP:MEDRS. If the argument is compelling, you will get a consensus in favor of using the source. This avoids the problem that Crossroads correctly identifies. TLDR: The present policy is not broken and does not need to be fixed. --Guy Macon (talk) 22:04, 5 October 2020 (UTC)

I would like to thank everyone for their input. I think you all make very valid points, such as the issue of "gaming" any metric and the point that some subjects are just too recent for Wikipedia. Points all noted and well-received. I wish there were a solution, but perhaps it just doesn't exist. BrainMan2017 (talk) 02:07, 6 October 2020 (UTC)

  • First, I would like to point out that WP:MEDRS is a guideline that is based on content policies applicable to all articles. The suggestions would therefore represent a change to policy, specifically reliable sources and neutrality.
The main problem with the proposal I see is that without review studies, editors cannot assess the merits of original papers.
Suppose for example that someone writes study that shows ginseng may prevent covid-19. One editor finds similar studies about ginseng and similar illnesses, another says that the methodology was incorrect, the sample size too small, etc. Normally they would then appeal to the Wikipedia people community and show a review study or a textbook that addresses these issues. But here there would be no guidelines available to anyone who lacked expertise in the subject.
So now an otherwise obscure study becomes an article in Wikipedia and persuades some people to take ginseng instead of wearing masks or staying home.
There's nothing to prevent you from setting up a separate Wiki that could report these studies. And presumably you could set content policies and provide editorial oversight.
TFD (talk) 02:46, 6 October 2020 (UTC)
  • The reason primary sources are excluded is that they are often wrong. Striking early findings rarely survive replication and meta-analysis intact. In fact, as Ioannidis notably found, most published research findings are false. Guy (help! - typo?) 10:33, 6 October 2020 (UTC)

More dates, including year

I just wanted to suggest that the information on Wikipedia would often be improved by dates added, including year, so one can get some context for reported events etc.. — Preceding unsigned comment added by 98.4.22.30 (talk • contribs) 15:00, 14 September 2020 (UTC)

  • What? I don't know what your saying. Also, sign your posts, please. Arsonxists (talk) 20:03, 14 September 2020 (UTC)
  • Ideally, articles should already be providing all context, including dates and years, that is necessary to inform a reader's understanding of events. If you believe a particular article would benefit from the addition of dates, please feel free to be bold and add them yourself. – Teratix ₵ 01:05, 16 September 2020 (UTC)
  • The dates of events, including the year, very often are added. If one looks at the many biographical articles in Wikipedia, one can see that very often, they give the dates in which the person are born and died - not just the year the person was born and the year the person died, but the dates of the year the person was born and died. Some biographical articles, it is true, do not put in the year a person was born (I think this may be especially true for potted biographies of living people) but that may just be because the Wikipedian who started the article does not know the date a person was born. I would rather a Wikipedian omit a date than put in an inaccurate date. If a Wikipedian reads a biographical article and knows the date a person was born, s/he can improve the article by putting in the date. Vorbee (talk) 08:22, 18 September 2020 (UTC)
    • Birth & death dates are harder to find for people the further back one goes in history. (IIRC, the point where more people lack one or both than have one or both is around AD 1500.) In many cases, there is some event associated with them that allows you to anchor them in time -- for example, we can be very certain that Frontinus was consul for the third time in AD 100, but the other dates of his life are all subject to dispute in various degrees -- but for some individuals, we are left with only vague guesses; some Classical poets we can only offer a date along the lines of "Hellenistic" or "Late Roman or Byzantine", & hope a new discovery doesn't force us to redate the person's floruit surprisingly out of the expected range. -- llywrch (talk) 23:13, 12 October 2020 (UTC)
  • I have just been looking at the article on the Battle of Britain and see it does give the date of the battle, but quite a way down the article. Is what the proposer saying we should have dates nearer the start of articles? Vorbee (talk) 06:43, 20 September 2020 (UTC)
    • "it does give the date of the battle, but quite a way down the article" Huh? The dates appear in the infobox and in the first paragraph of the lead. How much nearer the top do you want to go? Chuntuk (talk) 18:03, 23 September 2020 (UTC)
  • The date of the Battle of Britain is given in the third sentencce and the fifth line of the article. It could have been mentioned in the first sentence and on the first line. Vorbee (talk) 15:13, 1 October 2020 (UTC)
  • Most of the replies so far are not actually helpful. The OP just wanted to remind us that we should enrich descriptions of events with dates. While this happens sometimes, I see many articles which just give some run-up of events (sometimes providing relative time information like "a few years later", etc.) but without providing absolute dates. Thereby, they are making it very difficult for readers, who are not already familiar with a topic, to get a feeling about the historical context.
Hence, yes, I second the OP: We should remind ourselves to provide more (and more detailed) date information, if possible. --Matthiaspaul (talk) 16:58, 25 September 2020 (UTC)

Encouraging more wikilinking of author and publication pages in citations

I think it's helpful when we wikilink author names and publication names in citations, as e.g.,[1] since this gives readers an option to learn more about the source of the information in the citation and assess its reliability. I'd like to encourage this practice to become more widespread, but I'm not sure what the appropriate forums would be for (a) seeking to translate this into some sort of formal best practices guidance (I don't think we'd want to make it mandatory, since I'm perfectly fine with calling an FA an FA even if it doesn't wikilink, but I would like to see something to the effect of "it's better to have this than not"), and (b) pursuing semi-automated or automated processes for adding these links, such as making the automatic citation generating tools include them (I did make a related bot request back in 2018 that never went anywhere). Any thoughts? {{u|Sdkb}} talk 04:20, 14 October 2020 (UTC)

References

  1. ^ Goldstein, Dana (17 September 2017). "When Affirmative Action Isn't Enough". The New York Times. Retrieved April 7, 2020.{{cite news}}: CS1 maint: url-status (link)
  Agree I for one always link the author and publication if it exists, in every reference there is. El Millo (talk) 04:40, 14 October 2020 (UTC)
As linking text gives it a certain prominence, I am concerned about having a sea of links in the reference section. Perhaps some kind of gadget that would create a consolidated list of authors and source publications would alleviate this. isaacl (talk) 15:26, 14 October 2020 (UTC)

Staying ahead of the moles (as in whack-a)

 
Small sample of the moles needing a whac'ing

Wikipedia:Sockpuppet investigations/Hopeful2014 is a typical LTA case. They keep coming back on dynamic IPs from ranges that are too wide and too busy to block. Point-IP blocks get used, but it's pointless because by the time they get to SPI, the mole has moved on to another IP.

I can think of two things that might help in situations like this. I'm sure there will be objections to both, but tossing them out there just to get the conversation going. The basic idea here is to equip more people to do quicker response vandalism fighting while limiting the possibility for abuse.

First, a way to deputize non-admin but trusted editors to do focused IP blocks or article protections. Maybe that means inventing yet another user group, which any admin could make any user a member of. Or maybe piggy-back on some existing group like "pending changes reviewer". This new less-than-superpower would allow said user to semi-protect any article for up to 24 hours. Or block any IP for up to 1 hour. These actions would be logged, require an explanatory log comment, subject to review.

Second, a way to protect a group of articles by specifying a category. For the SPI in point (ping TheSandDoctor), that would have been Category:London. The problem here is it would probably be very expensive to implement (lots of database queries on every edit). But, perhaps it could be mixed with the first idea: I could give User:LondonVandalFighter the ability to issue 24-hour semi-protection on any (specific) article in Category:London. It would still be an expensive db query, but at least it's done per-protection, not per-edit.

-- RoySmith (talk) 15:15, 14 October 2020 (UTC)

@RoySmith: I think an RfC would be needed for the new group, but that sounds like an interesting idea to explore. —TheSandDoctor Talk 15:26, 14 October 2020 (UTC)
Concerning your first point, the Portuguese Wikipedia has something similar, where users with the rollback permission can also block IPs and new users for upwards to 32 hours in case of obvious vandalism. Maybe having a new group here specifically for quick blocks and page protection might work better, though. Isabelle 🔔 15:30, 14 October 2020 (UTC)
IP blocking for no more than 24 hours and page protection for no more than 1 hour, with some sort of delay before they can be done again to the same page/IP might lessen the inevitable howls of protest that this suggestion will generate. -Guy Macon (talk) 16:05, 14 October 2020 (UTC)
In the case of dynamic IPs, a block of even just 1 hour may be enough to short-circuit a vandalism spree without inconveniencing anyone else who lands on that IP - it would also give the blocker enough time to fill out a report on SPI/AIN if applicable. Paul ❬talk❭ 16:13, 14 October 2020 (UTC)
@Isabelle Belato: for ptwiki, are those limits just community policies? - it doesn't look like there is a technical control - meaning rollbackers can block or unblock anyone in anyway for any length of time (c.f. phab:T37261). — xaosflux Talk 16:54, 14 October 2020 (UTC)
w:pt:Wikipédia:Reversores suggests as such - it will be a stretch for us to approve a group that can have full access to the blocking and unblocking tool, there are some proposals to make other options available such as phab:T128328. — xaosflux Talk 17:01, 14 October 2020 (UTC)
Xaosflux: I believe it's based entirely on trust, though I never tested to see if I could block autoconfirmed editors. I imagine if something like this would be added, it should be limited by the system, so as not to increase the risk of abuse. Isabelle 🔔 17:17, 14 October 2020 (UTC)
@Isabelle Belato and RoySmith: - a system-level permission should probably be developed before we think about creating a group here - otherwise your new "blockers" group would actually be able to block and unblock anyone, including admins. Now, policy wise we wouldn't allow that and it would likely result in the violator being sanctioned - but they can always claim WP:IAR and then we would have to determine if that is acceptable. We've run in to that same problem with eventcordinators not following the policy about their expanded permissions. — xaosflux Talk 18:46, 14 October 2020 (UTC)
No disagreements here. If this is to ever go through an RfC, it would be important to limit the ability of these users via the system, instead of simply trusting them (which is what the phab you linked seem to be about). My comment was mostly about the fact that there are examples of this happening on a similar project, so one can check how useful (or not) it has been there. Isabelle 🔔 02:10, 15 October 2020 (UTC)
Isabelle Belato, Adding onto this I would also argue that if we let rollbackers do this it should be limited to full rollbackers not those who have received the right temporarily. I personally only have rollback until 1 November and would then need to re request full rollback. letting people who are essentially on a trial period for whatever reason immediately block people seems incredibly abuse ripe Asartea Trick | Treat 13:46, 17 October 2020 (UTC)
  • This seems like an idea that is far too ripe for abuse. Also isn't this basically yet another unbundling discussion, which has been RFC'd to death...Praxidicae (talk) 16:41, 14 October 2020 (UTC)
  • Semi-protecting all articles which are in a category automatically won't happen because it allows any user to semi-protect any page. Twinkle batch protection should do the same thing without the privilege escalation problem. MER-C 19:04, 14 October 2020 (UTC)
  • A BOT which makes such short blocks "on request" of editors who are on a whitelist should avoid the need to change base Wikimedia software. davidwr/(talk)/(contribs) 19:13, 14 October 2020 (UTC)
    That could technically be done, but like all bots the traditional responsibility for anything that bot does is its operator - in this case that would need to be an admin who would be responsible for ensuring that every block action complied with the policy - and that is hard to program. Now, we do have the abuse filter - and it is possible to add "BLOCK" actions to the filter, but that will need community consensus. — xaosflux Talk 19:41, 14 October 2020 (UTC)
    There would have to be a new "responsibility model" where as long as the bot did what the whitelisted editor did, the whitelisted editor would bear responsibility. The bot owner would be responsible for edits made due to bugs, just like any other bot owner of a buggy bot. davidwr/(talk)/(contribs) 20:16, 14 October 2020 (UTC)
    Xaosflux Is that necessarily true? AnomieBot force substs templates, including TfD outcomes. If I chuck in a busted template into the subster, and it substs, I'm pretty sure I'm held responsible not Anomie. ProcrastinatingReader (talk) 20:54, 14 October 2020 (UTC)
    @ProcrastinatingReader: you can't delegate responsibility. An operator could raise in defense of their bot's bad edits that they AGF in someone elses "nomination" - but that doesn't absolve them of responsibility for their edits (nor the copyright of the derivative versions they create). — xaosflux Talk 21:17, 14 October 2020 (UTC)
    Xaosflux, I don't follow. So you're saying if I put a non-TfD'd template into the TfDSubster/TemplateSubster force, and so AnomieBOT blanks the template (or turns it into garbage, whatever I set it to) across 100k pages, Anomie will formally be responsible for it? If so, what does that 'responsibility' entail, since it's not nearly the same scenario as Anomie (the operator), rather than me, putting the template in for processing. ProcrastinatingReader (talk) 21:47, 14 October 2020 (UTC)
    @ProcrastinatingReader: the operator is choosing to let you trigger their bot, it is 100% up to them - they can choose not to, they can choose to. Now, does it mean that you wouldn't be accountablefor the chain of events? No, but accountability and responsibility are not exactly the same. The responsibility for any edit belongs to the person pushing the "Publish" button on each revision (or the virtual button via an API call). This is the same if you said "Hey Xaosflux, here is a list of new users that are all spam bots, would you Special:Nuke all their pages?" I could choose to do it, or not - I could even choose to not actually check your list and just blindly do it - and I could later complain that it is really your fault if the deletions are bad - but it doesn't absolve me of the responsibility. — xaosflux Talk 21:59, 14 October 2020 (UTC)
  • If this went to phab the devs would probably say enwiki has went mental. The point of technical feasibility may be somewhat moot anyway, because this probably wouldn't (and tbh, shouldn't) pass. And if it were required it would say a lot about the process of gaining permissions. I can't see why an editor is trusted enough to make 24h protections/blocks, but not trusted enough to go to RfA? Nevertheless, I guess could be done not-so-difficultly using a bot as davidwr proposes. ProcrastinatingReader (talk) 20:57, 14 October 2020 (UTC)
    Ages ago, it was determined that any "un-bundling" that allowed editors to see deleted edits would require the editor to go through an RFA-like process to gain access to those tools. I don't think there is any similar restriction on the "block" button. In other words, I think we can provide access to the "block" button to editors without requiring them to go through hell week an WP:RFA-like process. davidwr/(talk)/(contribs) 21:42, 14 October 2020 (UTC)
    Davidwr, who determined that? The community or WMF? ProcrastinatingReader (talk) 21:44, 14 October 2020 (UTC)
    I don't remember, but I think it was at the "arbcom" or "WMF" level, in other words, as of several years ago, and presumably still today it would at least take a very long discussion and the blessings of ARBCOM to allow access to a tool that would let them see deleted revisions without going through an RFA-like process. It MIGHT require WMF approval. But it's not something as "easy" as changing a normal policy page. davidwr/(talk)/(contribs) 21:49, 14 October 2020 (UTC)
    The "RFA-like" requirement is from WMF, and it only applies to permissions that allow you to see deleted versions. WMF doesn't have any other rules for the other permissions we have bundled with admin today. — xaosflux Talk 22:01, 14 October 2020 (UTC)
    WMF legal 2014 per [6], but I'm not sure if it's still current, and I think it's just to protect the WMF from liability, and is one of the ways in which WMF hinders the project. Lev!vich 23:21, 14 October 2020 (UTC)
    Fair enough. I think the bot approach could be technically feasible, and the idea of 24h semi-protections for a trusted group doesn't seem totally absurd. Coupled (per above thread) with some community consensus making this bot a special case, i.e. "operator won't have responsibility/accountability for misuse by users, only for technical errors due to bot code". Issue then becomes how much does the right get dished out? Does it get treat as a very sensitive right (well, technically, I guess it'd be more of an AWB checklist)? Where does it lie on the WP:PERM chart w.r.t. exclusivity? Rollbacker, TE or EFH level, or higher? If it's EFH or higher, is there really a point to this compared to just going RfA? If it's rollbacker or TE level, how is accountability ensured?
    As a sidenote, RoySmith, is there a particular User:LondonVandalFighter here (I haven't read the SPIs)? Have you tried getting them to RfA? Maybe that's the easier option here, can't hurt to try? ProcrastinatingReader (talk) 00:30, 15 October 2020 (UTC)
    It's part of how Wikipedia maintains its safe harbour against copyright infringement in accordance with the Digital Millennium Copyright Act. Infringing material must be removed from public sight upon notification. If anyone can view deleted text, then the criteria for safe harbour is not met. isaacl (talk) 00:55, 15 October 2020 (UTC)
    Isaacl, regarding RfA, I've pretty much given up asking people if I could nominate them. I'm tired of getting turned down. RfA has a bad reputation, and deservedly so. Why would anybody want to subject themselves to that kind of public abuse? -- RoySmith (talk) 02:03, 15 October 2020 (UTC)
    I was just responding to Levivich's post regarding restrictions on who can view deleted material. isaacl (talk) 02:34, 15 October 2020 (UTC)
    Isaacl, Sorry, I replied to the wrong section. That was ProcrastinatingReader's comment I was actually replying to. -- RoySmith (talk) 02:52, 15 October 2020 (UTC)
  • Sharing my 4 cents:
    1. Wearing my developer hat, at first glance it would *probably* be fairly straightforward to add the more granular block permissions that this calls for (add something to BlockPermissionChecker::checkBlockPermissions or similar, @Martin Urbanec might have a better idea though) as long as there was agreement from the WMF to add the functionality
    2. Wearing my bot operator hat, DannyS712 bot III is an existing bot for effectively granting partial user rights (autopatrol for redirects). It is controlled by admins granting or removing access via a fully protected page, Wikipedia:New pages patrol/Redirect whitelist, and the bot checks that users are listed there. Since the bot operator (myself) is ultimately responsible for the bot actions, the proposal that led to the pseudo-group (Wikipedia:New pages patrol/Reviewers/Redirect autopatrol) included that users would be removed from the group at the request of the operator. Though I am not an admin, and thus would not be able to operate an admin bot, I'd be happy to help create one if there is consensus to do so.
    --DannyS712 (talk) 05:42, 16 October 2020 (UTC)
If I were the decision maker, I'd probably go with an admin bot that would perform the requested actions based on request by trusted users in a wiki page, or a toolforge tool. It's probably the simplest thing to do at this point.
If this is to be added to MediaWiki, it should be possible, but it'd require a lot of planning on how to do it.
I'd like to invite NKohli (WMF) to this discussion. She's a product manager for the Anti Harassment Team, and she would probably be able to provide some more insight :-).
Best, --Martin Urbanec (talk) 14:12, 16 October 2020 (UTC)

Refocusing

I truly appreciate all the input from everybody, but I'd like to refocus the discussion a bit. I see three things that need to be considered, in order:

  • First, do we want to give non-admins the ability to use short term semi-protection of articles and/or IP blocking to combat vandalism?
  • If the answer to that is "yes", then what specific policy do we need around that? How long can the protection/block last? How often can a given user do this? What qualifications does a user need in order to be granted this ability?
  • Lastly (if we get this far), how do we implement this in software? We seem to have jumped right to this step without really figuring out if we want the feature at all. Certainly, the realities of implementing it may dictate what's possible, but basically the policy should come first.
-- RoySmith (talk) 12:25, 17 October 2020 (UTC)
  • It is a sad reality that many people make software decisions based upon how difficult they believe the change is to implement or advocate a workaround that requires no effort at all from the programmers. This is one one the major reasons why so much software in so many areas totally sucks. "Fire is too difficult to deal with. We just need to get better at chewing our food raw". "Airplanes are way too difficult to make. We just need to make bigger and better balloons." "Telephones are too hard to do. We just need to teach every child to be proficient at Morse code." "Mobile phones are way too much work. We just need to give everyone a small, simple handheld radio and teach every child to be proficient at Morse code."
Take anything -- literally anything -- that anyone claims is too hard for the WMF developers to implement. Write up a good set of requirements (in other words, define what "done" is), and offer a $100,000 prize (0.1% of the money the WMF spends every year) to the best program that meets the requirements, and see what happens.
As long as the mentality exists to accept what is barely adequate because because it's too much trouble to create something that is insanely great, and you doom yourself to living with barely adequate software. --Guy Macon (talk) 14:36, 17 October 2020 (UTC)
  • @RoySmith: perhaps appropriately when discussing unbundling, but the "semi-protection" and "IP blocking" really should be split-up into fully distinct (though obviously linked) discussions. Nosebagbear (talk)
    • About 15 months ago, I was one of several people who got into a very late-stage discussion for what a partial unbundled SP-right would look like, along with some proposed criteria for that userright would look like. I ultimately opted against pulling the trigger because it continued to feel that only about 40% of people were in favour of even the most pared down option. I will attempt to dig both up (I should have noted it down - last time I tried to find it, it took 2 hours) Nosebagbear (talk)
    • I am firmly against even a 1-hour IP-blocking unbundling. It seems likely to cause problems, but towards a group of editors where it will be harder to check whether they were warranted (they'll be appealed vastly less, so issues will go undetected). Nosebagbear (talk) 11:16, 19 October 2020 (UTC)

Highlight edit summary field if blank upon mouse hover over "Publish changes"?

 

While forcing users to add an edit summary has been a Perennial proposal, a gentler version occurred to me. What the edit summary box is highlighted if still blank when the user's mouse cursor hovers over the "Publish changes" button? Jason Quinn (talk) 14:47, 16 October 2020 (UTC)

Currently if you hit Publish without an edit summary, it doesn't submit the first time and instead gives an incredibly subtle, barely noticeable notification on top of the main text box.[1] (Just had to try it to remind myself what it looked like). I think that on the "second chance to include an edit summary" screen it wouldn't hurt at all if the edit summary box itself was highlighted. If we do want an even gentler approach, then maybe someone should whisper the words "Edit Summary" into the night, hoping that someone hears it. --Paul ❬talk❭ 13:22, 17 October 2020 (UTC)

References

  1. ^ I am a serial edit summary leaver outer.
What you're describing happens because you've selected the option to be reminded in your preferences. That setting is off by default so not everyone will see that reminder. But on the general topic, I don't see any problem with the current practice of edit summary and I think highlight of the field would be distracting. – Ammarpad (talk) 05:49, 18 October 2020 (UTC)
Wow I have no recollection of opting into that. It is handy though - maybe it should be on as default - Paul ❬talk❭ 06:59, 18 October 2020 (UTC)
@Ammarpad. The highlight of the field would only occur if the field were empty and upon hover, in which case it's SUPPOSED to be distracted because the user is about to leave a blank edit summary. Jason Quinn (talk) 09:17, 18 October 2020 (UTC)
Sounds like a good idea. For anyone who wants to use this for themself, the following javascript on the personal common.js page will achieve it: $(function(){var r=$("#wpSummaryWidget input");$("#wpSaveWidget input").on("mouseover",function(){r.val().trim()||(window.editSumOrigBorder=r.css("border"),r.css("border","solid 2px red"))}).on("mouseout",function(){r.css("border",window.editSumOrigBorder)})}); – SD0001 (talk) 09:59, 18 October 2020 (UTC)

Thanks, User:SD0001, for your idea. I tried to modify it to work when the user edits a section (where the section's name is used as a default summary). My idea was to save the initial summary and highlight the input box when the summary is blank or initial summary hasn't changed. This worked fine unless the user has used preview. I also wanted to modify the Publish button's tooltip with a note that the edit summary hasn't been given. Jason Quinn (talk) 06:34, 19 October 2020 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(idea_lab)/Archive_32&oldid=1110547610"