Wikipedia:Village pump (proposals)/Archive 167

 You are invited to join the following discussions:

• Wikipedia talk:Introduction#Proposal: Redirect this page and WP:Tutorial to Help:Introduction
• Wikipedia talk:Welcoming committee#Let's get rid of Wikipedia:Welcoming committee/Welcome to Wikipedia.

Sdkb (talk) 08:21, 13 March 2020 (UTC)

The

You'd need to take any proposed change to the unified mark (the combined death star logo and "The Free Encyclopedia") up with the WMF. It's

Iridescent

12:24, 16 April 2020 (UTC)

@

Iridescent: That link doesn't go anywhere. * Pppery * _{it has begun...}

13:45, 16 April 2020 (UTC)

Link fixed ‑ 

Iridescent

15:09, 16 April 2020 (UTC)

Whats the status on the font? If (and I do mean if, I have no strong feelings on it) we wanted 'The free encyclopedia' could we not just use the resized globe trademark and print underneath? Only in death does duty end (talk) 19:09, 16 April 2020 (UTC)

That wording and typeface are specified in the WMF's Visual Identity Guidelines; it would need to go up to them. ‑ 

Iridescent

19:25, 16 April 2020 (UTC)

• I'm going to have to query what problem we're really trying to fix - are significant amounts of people of people actually viewing it as incongruous? Nor am I inclined to think that consistency is obligatory either with other projects on it or a need for it to match other titles in Wikipedia - the wording under the logo is substantively different to a content title, if nothing else. Nosebagbear (talk) 20:53, 16 April 2020 (UTC)

Hi everyone,

A lot of editors in Wikipedia live in regions where free speech is considered illegal. Many editors don't want their private information to be exposed. It has come to my attention that certain users who have 'checkuser' permission are able to see our private information like our location, type of the device that we are using, IP addresses, etc. Some of those 'checkusers' could be working for governments.

To stop misusing the checkuser tool, I am proposing that editors get a notification that includes the username of the checkuser everytime or most of the time they are checked. The notification will appear on the notification button. I don't mind if instead of automatic notification, the notification will be a message on the talk page (possibly using a standard notification template).

Why this is helpful

1. This will limit the misuse of the tool.
2. I think we are all concerned about our privacy, we don't want unknown users in Wiki to see our private information.
3. A lot of editors live in areas where saying stuff can put you in jail or even kill you, checkusers are not known people and could be government agents.--SharʿabSalam▼ (talk) 13:10, 13 April 2020 (UTC)

Not a good idea IMO - a lot of checkusered people engage in harassment when they are called out, and we already have processes (such as the Arbitration Committee and the meta:Ombudsman commission) that monitor the use of the checkuser tool. I don't see how such a notification would work better than these, and it would invite retaliatory behaviours. Jo-Jo Eumerus (talk) 13:18, 13 April 2020 (UTC)

Agree that this isn't a good idea. CU's also have to sign a confidentiality agreement that is legally binding upon being granted the privileges. CU's are subject to Stewards and, as seen by the recent Bbb23 case, Arbcom, whose members are generally known to WMF and are also CU's themselves. Given there are legal ramifications involved in these rights, I don't think any sort of guideline that is developed locally will have anywhere near the same sort of teeth. Blackmane (talk) 13:24, 13 April 2020 (UTC)

I don't see how checkuser notification would invite "retaliatory behaviours" more than a 24 hours block for editwarring etc. I think editors should get a notification every time their private information gets exposed. By the time this would become normal and editors won't be angry if they got a notification. They would be angry if it was unreasonable which is why I want this notification so that unreasonable checks stop.--SharʿabSalam▼ (talk) 17:00, 13 April 2020 (UTC)

This seems like a solution in search of a problem - there are simpler ways for a government to figure out your identity than the long process of creating a persona which becomes sufficiently trusted to gain checkuser. Also, keep in mind that the data available to a checkuser is exactly the same as the data which any website operator can pull out of their access logs.

talk

) 17:11, 13 April 2020 (UTC)

@

Creffett: There are certainly governments which are playing the long game when it comes to things like this. I'm not supporting this particular proposal, but a healthy dose of paranoia when it comes to government surveillance is a good thing. We have had long-time admins exposed for socking. I would be surprised if we didn't currently have admins today who are agents of governments. Getting CU approval is a much higher bar than passing an RfA, and they are subject to greater ongoing scrutiny, but it's also a more valuable target so reasonable to believe more effort would be put into obtaining it. A 10-year project is not beyond major governments. -- RoySmith (talk)

17:54, 13 April 2020 (UTC)

talk

) 18:07, 13 April 2020 (UTC)

@

Creffett: momentary confusion. You mean SKS, not SKS :-) -- RoySmith (talk)

18:33, 13 April 2020 (UTC)

Ha! Correct. I should see if the keyserver has been written about enough for me to make an article...

talk

) 18:40, 13 April 2020 (UTC)

A government doesn't need to start from scratch; they simply need to slip an existing checkuser a few bucks. –Deacon Vorbis (carbon • videos) 17:16, 13 April 2020 (UTC)

If we're going down the bribery route, why not bribe a sysadmin? Pulling logs that way wouldn't be tracked by the software, and you might be able to get some kind of monitoring software onto the backend servers. We could go down the rabbit hole all day on this, of course, my point is that I think there are other threat vectors which are more likely than a government-controlled/subverted CU.

talk

) 17:41, 13 April 2020 (UTC)

This is claptrap. The point is to limit, not to completely stop governments from taking our data because that's unrealistic. This is like if Facebook said, we aren't going to take measures to protect your data from governments, organisations, etc. They can steal your data by paying money to Facebook employees.--SharʿabSalam▼ (talk) 18:01, 13 April 2020 (UTC)

(edit conflict) Any website can pull your data but they can't identify who is the editor. For example, an editor who writes stuff about the Saudi government which the Saudi government doesn't like, the Saudi government won't be able to pull the data of the editor unless they have someone who is a checkuser in Wikipedia, who works for them and gets money from them. There is no other way to know for sure that the data belongs to the editor except if they have a checkuser in Wikipedia.--SharʿabSalam▼ (talk) 17:22, 13 April 2020 (UTC)

If you think the Saudi government or the likes of Saudi government won't bother do that then see the case of this Twitter user Turki bin Abdulaziz al-Jasser, he was tortured to death by the Saudis and the Twitter office in Dubai was the one that leaked his data.[1]. This is a Twitter poster, not Wikipedia editor. I assume that Wikipedia is more powerful than Twitter.--SharʿabSalam▼ (talk) 17:36, 13 April 2020 (UTC)

They literally had employees in Twitter company.[2] Do you really think there is no chance they have checkusers in Wikipedia? They probably have.--SharʿabSalam▼ (talk) 17:40, 13 April 2020 (UTC)

There seems to be a lot of misunderstanding here about what Checkuser does. It's not some magic tool that allows elite superusers to pry into editors' souls; it gives a small handful of vetted and monitored users—all of whom are bound by legally-binding agreements regarding how it's used—to see some very limited information in very limited circumstances. Just to put things in perspective, this is what CU results actually look like. The most any hypothetical hostile intelligence agency could find out about you is which browser you're using and (assuming you're not using a VPN) what your IP address is; yes, if someone edits from work it theoretically could reveal their employer, but if someone is editing something so sensitive that a hostile government is taking an interest, they almost certainly shouldn't be doing so from work in the first place (and the system administrators at their workplace are more likely than Wikipedia checkusers, by a factor of about a million, to be the ones to call them out on any problematic edits). "Checkuser is not magic" isn't just some mantra we say to reassure people; it's the straightforward truth. ‑ 

Iridescent

19:00, 13 April 2020 (UTC)

I know what checkusers can see. I am saying that every time or most of the time an editor gets checked he/she should be notified. Checkusers should send a notification to the editor who got checked.--SharʿabSalam▼ (talk) 19:18, 13 April 2020 (UTC)

I appreciate this has been closed, but I'm going to comment regardless to explain why "notifying averyone who's been the subject of a checkuser" not only won't happen but can't happen. Every time the Checkuser tool is used, it generates at least two checks; firstly the check on the account to determine which IP address(es) they're using, and secondly the check on the IP(s) to see if other accounts have also been using it. Were we to post talk page notifications, we'd essentially be publishing both the IP address, and a list of every other editor editing on a similar IP range, for every editor who's ever been accused of sockpuppetry (e.g., were someone to see a "you have been checkusered" notification pop up on my talk, all they would need to do is look at the contribution history of whoever posted the notification to see which other notifications were posted at the same time, and they'd immediately have a full list of all IP addresses I'd used in the past three months and every other editor to use any of those addresses). The legal and ethical implications of this would be severe, to the extent that even if we somehow did get community consensus to start doing this, WMF Legal would immediately veto it. ‑ 

This is why I said it should be a notification in the notification button. I don't mind if it was a notification in the talk page but I wouldn't support posting it in the IP talk page.--SharʿabSalam▼ (talk) 09:33, 14 April 2020 (UTC)

Currently we have checkusers who could be government agents. The WMF should take measures in assuring the privacy of editors in this site. I believe if users are notified every time their data gets exposed, this would make it less likely that their privacy would be exposed without any valid reason (like in the recent case of Bbb23).--SharʿabSalam▼ (talk) 09:39, 14 April 2020 (UTC)

I'm not terribly opposed to the proposal, though I suspect (and am starting to imagine) there are disadvantages, and possible privacy problems, somewhere along the line. However I think you should drop the government agent part of your proposal. There is no way you can tell whether anyone, anywhere, is being run by a government agency, even if you were to be in possession of their supposed full name address and profile photo. For the record, I am not one. But let's assume you received a notification that you were checkusered by 'one of the team'. What would you do with this information? -- zzuuzz ^(talk) 10:02, 14 April 2020 (UTC)

For the record, I am not one....sounds like the type of thing a government agent would say - burn the witch! Nosebagbear (talk)

• I'm inclined to concur with zzuuzz - what do you do with this information? Either the information is already public (if you keep an eye on SPI, at least), or there is a significant chance they won't be able to tell you because, post-check, it turns out you aren't involved and they can't explain without bleeding private information of others. Nosebagbear (talk) 20:59, 16 April 2020 (UTC)

Thompson8964 (talk) 20:32, 14 April 2020 (UTC)

Technically every article on Wikipedia needs editing, an article is almost never "complete". We already have a random page button. 331dot (talk) 20:34, 14 April 2020 (UTC)

Thompson8964, I don't know if there are links anywhere, but we do already have Special:RandomInCategory. For example, Special:RandomInCategory/Wikipedia articles needing copy edit will bring you to a random page that needs copyediting. In the meantime, you could add those links to your user page so that you can access them easily. Gaelan 💬✏️ 20:36, 14 April 2020 (UTC)

TAFI used to be on the Main Page before it was removed. Perhaps you can bring that back up in the appropriate forum. – John M Wolfson (talk • contribs

) 03:30, 18 April 2020 (UTC)

The category structure, with Category:Articles as its root, puts a largely hierachical structure on top of our encyclopedic content. It is a rather tree-like graph, ideally a directed acyclic graph but, I expect, with the occasional cycle. Not all nodes in that graph are relevant for the purpose, but I think it can serve as the basis for a navigation tool. If we tag the nodes that are not relevant for the purpose (e.g. Category:Wikipedia pages referenced by the press) and add snappy one-line descriptions for each relevant node, we are already halfway.  --Lambiam 15:46, 18 April 2020 (UTC)

Is

Iridescent

17:32, 18 April 2020 (UTC)

Strict hierarchies are inappropriate for Wikipedia's work; there was a categorization scheme on the Main Page in 2001-2002ish but this has since been removed, as have subpages in the mainspace. Wikipedia:Contents/Outlines is a survivor, as are portals, but overall there are no plans to have a large-scale categorization scheme (nor should there be IMO). – John M Wolfson (talk • contribs) 18:05, 18 April 2020 (UTC)

Thanks, interesting context. I would point out in defence of structured hierarchy, though, that those for smaller 'families' of articles (like the Finance side panel example I gave above) seem to be popular/work well- or are they more controversial than I imagined? If there is no consensus/appetite for a Propaedia-scale mega-structure or hierarchy, is there an argument for improving consistency/coverage of these smaller side panels and/or is there anywhere on WP with a list or collection of all side panels across the site for those who nevertheless crave some degree of categorisation? Thanks.JH1977 (talk) 18:14, 18 April 2020 (UTC)

Re your earlier "nothing to distinguish between the relative importance of articles" - there's

WP:VITAL and assessment of importance by wikiprojects. I don't think we need another scheme of importance ratings of articles. Re "all side panels" see Category:Navigational boxes. DexDor ^(talk)

20:28, 18 April 2020 (UTC)

Some of the arguments above basically state that something along the lines of Propædia is useless for Wikipedia. It appears to me that for the same reasons it should then be useless for the Encyclopædia Britannica. I don't know if it is; I haven't used it. I do know, though, that it may be hard to find information on a topic if you don't know the appropriate terminology, and therefore also no plausible article name. It may also be hard to get a broad overview of a topic; sometimes the main article on a topic omits to mention important subtopics. Finally, no one has suggested to make use of an importance rating of articles. But when using categories as the basis for a navigation tool for structured access to topics, some categories are really irrelevant and unhelpful to the user.  --Lambiam 21:02, 18 April 2020 (UTC)

There is a Wikipedia-wide assessment of importance of certain articles at

WP:VITAL, and a search engine (either Wikipedia's or Google's) could help to conjure up a given term based on a description, which is where I've learned many terms on my own. – John M Wolfson (talk • contribs

) 22:44, 18 April 2020 (UTC)

Thanks

WP:VITAL Level 1 article, or similar?) Thanks also for the link to the Navigational Boxes categoryJH1977 (talk

) 06:01, 19 April 2020 (UTC)

@JH1977: That's a great question. I'm going to turn this into a new sub-section to try to focus attention on it.

I've thought about this a bit recently with regard to the left sidebar redesign. For one thing, Wikipedia:Contents badly needs a redesign. That may include merging it with Wikipedia:Featured content, but it could also involve better emphasizing the vital articles there. The random article tool could also be involved. I do kinda like how it gives you a sense of e.g. just how many Wikipedia articles are about tiny towns, but it'd also be nice to have random article buttons that sampled only from vital articles (or only from featured content). {{u|Sdkb}} ^talk 07:21, 19 April 2020 (UTC)

Try e.g. Special:Randomincategory/All Wikipedia level-2 vital articles. That takes you to the talk page, but perhaps there could be a way to make it automatically switch to the article page. DexDor ^(talk) 10:25, 19 April 2020 (UTC)

@DexDor: yeah, I've been trying that, but I can't get it to play nice with Village pump (proposals)/Archive 167, which is needed to switch to the page link itself. Will ask at the VPT, and add a button to WP:Contents once I get it working. {{u|Sdkb}} ^talk 00:32, 20 April 2020 (UTC)

Try Special:Randomincategory/Main topic articles instead; slightly different list, goes to the articles. UnitedStatesian (talk) 03:24, 20 April 2020 (UTC)

Do we include all five levels of VITAL, or just the first, say, two? – John M Wolfson (talk • contribs) 18:52, 19 April 2020 (UTC)

@John M Wolfson: Level 1 is so small it's not super useful; if linking to that level, better to just list out the full 10. Levels 3, 4, and 5 could each have their usefulness. In my ideal vision, there's an option for each of them at the contents page, along with options for good articles, featured articles, and truly all articles. There can only be one link on the sidebar, though (unless we get advanced enough to be able to have a sub-menu that opens when one hovers over the random article link, which would be amazing but seems beyond our current capacity). And the nice thing about the sidebar link is that you can click it as many times as you want in rapid succession, whereas a link at the contents page takes you away from the button every time you click it. {{u|Sdkb}} ^talk 00:32, 20 April 2020 (UTC)

 You are invited to join the discussion at Wikipedia talk:Requested moves#Reconsidering the 7-day waiting period. {{u|Sdkb}} ^talk 10:48, 22 April 2020 (UTC)

There's a practice that I like to engage in which I think would make a good guideline for the community as a whole, which I call paying actions forward. The basic idea is that if an editor takes an action that will require the work of others to resolve, that editor should undertake some of the work that helps resolve similar actions taken by others. For example:

If you open a deletion discussion in some XfD space, find another deletion discussion in that space and take some action towards resolving another discussion.

If you are an administrator or an XfD closer, find a pending discussion to close.

If you are not someone who can close a discussion, find a pending discussion to which you can contribute an opinion which will help form a consensus (or solidify the absence of consensus).

Similarly, if you open a move request, find another move request and take some action towards resolving the request.

I believe that adopting a guideline supporting this practice, even if it is merely advisory rather than a mandate, would help prevent backlogs from growing in these areas, because editors who were generating a larger share of the work would then feel more of an obligation to generate a larger share of the resolutions. BD2412 T 23:56, 16 April 2020 (UTC)

That's how

WP:DYK works. You get a few freebies, but after that, for every nomination you make, you're required to review somebody else's. Seems to work well. -- RoySmith (talk)

00:44, 17 April 2020 (UTC)

Yes, something like that but less coercive. BD2412 T 00:58, 17 April 2020 (UTC)

I like the spirit of it, and think an essay would do the trick. My worry with giving it the force of guideline or policy is that it would disincentivize nominations which we really don't want. — Wug·a·po·des​ 01:04, 17 April 2020 (UTC)

If that's effective at DYK, it's because it's required. Relatively few editors will do more than required merely because of some non-binding "advisory", particularly when they see few others doing it. Anyway, you would have to define which areas are to be covered by the advisory, and that's a subject for

WP:VPI. ―Mandruss ☎

01:07, 17 April 2020 (UTC)

• I very much like this idea. It would make for a great essay.
  WP:SOFIXIT. Levivich ^{[dubious – discuss}
  ] 16:04, 17 April 2020 (UTC)
  • Done.
    Wikipedia:Pay Actions Forward. BD2412 T
    17:23, 19 April 2020 (UTC)
• Like King of ♥ ♦ ♣ ♠ 06:16, 19 April 2020 (UTC)
• A very good idea for an essay. As a guideline (in the sense of a behaviour norm that the community expects editors to follow) it goes against
  WP:NOTCOMPULSORY. Ivanvector (^Talk/_Edits
  ) 17:50, 19 April 2020 (UTC)
  • I'd like to find some middle ground there, such that those who make a lot of XfD or RM-type nominations get nudged with increasing firmness towards helping out on the other end. BD2412 T 19:10, 19 April 2020 (UTC)
    • Sounds good to me. The editors who engage in drive-by behaviors - as in only doing XFD/RM noms without weighing in on other noms or throwing up droves of maintenance template tags without actually doing any of the fixing-up, etc. - to me they're a drag on the project. Yeah. Nudged with increasing firmness sounds good to me. Shearonink (talk) 19:40, 19 April 2020 (UTC)
      • That exactly the reason why I have my doubts about this. Editors who make unresearched drive-by nominations will also make unresearched drive-by comments in other discussions if they are encouraged to do so.
        Phil Bridger (talk
        ) 19:51, 19 April 2020 (UTC)
        • We could try it out and see what happens. BD2412 T 19:59, 19 April 2020 (UTC)
    • As an outside perspective, I quite strongly approve of the RM system and other similar processes, because I am (and I imagine many others are) simply not
      WP:BOLD enough. —⁠烏⁠Γ ^(kaw
      ) │ 21:21, 19 April 2020 (UTC)
• Absolutely terrible idea - articles get nominated for deletion because people feel they don't belong - including articles that are copyvios or breaches of our BLP policy - this proposal would keep these damaging articles here for longer and it would strengthen the idea that Wikipedia's decision making processes are just for the privileged elite.Nigel Ish (talk) 19:58, 19 April 2020 (UTC)
  • @Nigel Ish: Can you explain how speeding up the resolution of discussions and reducing backlogs would "keep these damaging articles here for longer"? BD2412 T 20:00, 19 April 2020 (UTC)
    • I would have thought that was pretty obvious. It would discourage people from nominating pages for deletion if they don't have the time or the wish to participate in other discussions.
      Phil Bridger (talk
      ) 20:03, 19 April 2020 (UTC)
      • The proposal discourages people who are not regulars from getting involved as it effectively discounts their opinion and encourages the system to be gamed to dismiss new people getting involved and attack them - giving the way people behave, it will be gamed and abused, just as things like WP:BEFORE are gamed and abused. This will merely make AfD and the like to be closed shops - what we want is to make it easier for more editors to get involved and not get attacked.Nigel Ish (talk) 20:13, 19 April 2020 (UTC)
        • Suppose the proposal was reworked to avoid discouraging anyone from getting involved, and only encouraging people who are already involved to a certain degree to become more involved? BD2412 T 20:21, 19 April 2020 (UTC)
• Oppose - if people are making good XFD/RM noms then that's good (regardless of what other wp edits they make); if people are (repeatedly) making bad XFD/RM noms then they should be encouraged to stop doing that. Division of labour works well in wp (different editors specialise in doing different tasks). In the real world we don't generally say that someone can only do one voluntary activity (e.g. being a special constable) if they also do another voluntary activity (e.g. being a prison visitor). Also, if something like this was put into practice it'd spawn a whole bueurocracy of monitoring, warnings, appeals etc. DexDor ^(talk) 20:16, 19 April 2020 (UTC)
  • Interesting. Suppose the proposal was reworked to expressly avoid any mention of monitoring, warnings, or appeals, and to merely focus on encouragement? BD2412 T 20:19, 19 April 2020 (UTC)
    • Then that would be very different to the "those who make a lot of ... nominations get nudged with increasing firmness towards ..." idea proposed above. DexDor ^(talk) 20:46, 19 April 2020 (UTC)
• Write an essay, not a guideline. I'd also suggest a softly, softly, written one, as I feel that would be vastly more effective than any alternate mechanism. We don't need AfD etc with DYK mechanisms (the only other place that might benefit could be something like GAN, though the drive is working well recently) Nosebagbear (talk) 08:14, 20 April 2020 (UTC)
• Part of the problem here is that RFA has become such a constipated process. It used to be that prolific deletion taggers would eventually run for adminship, if their deletion tagging was OK they would then usually get the deletion button if there were problems with their deletion tagging they would be reminded of that. If we could persuade a few more prolific deletion taggers to run at RFA we wouldn't need to talk about reciprocity. But if we are talking about it, then it is worth gently encouraging those who start AFD and MFD discussions to take part in a few that others have started, if only to maintain their calibration - the process of taking part in AFDs that others have started, checking for sources and !voting keep or delete accordingly is a good way to set your AFD tagging threshold in line with community norms. As for template bombers, I'm sure somewhere we have a userbox or something for editors who aim to remove as many article maintenance templates as we add, it would be good if such an essay encouraged taggers to aim for the situation where their Wikipedia editing skills had grown to the point that they resolved more such problems than they added. ϢereSpielChequers 08:40, 20 April 2020 (UTC)
• Oppose any kind of compulsion or "nudging with increasing firmness". We want to encourage newer editors (or editors unsure of the nuances of our labyrinthine deletion policies) to start XfD discussions when they're unsure, rather than start slapping inappropriate CSD/PROD tags around or wade into deletion debates without understanding the relevant policy. Unless I'm seriously misunderstanding the proposal, this would have completely the opposite effect in that we'd be de facto ordering people who aren't familiar with how deletion works to take part in deletion debates regardless. This would likely result in a flood of "keep, it exists" and "delete, I've never heard of it" comments, which would both make more work (not less) for the closing admins, and lead to increased bad feeling when people are told to comment on deletion debates, comment in good faith, and are then told their opinions aren't valid. With the exception of a couple of serial deletion-taggers—who can be and are dealt with at ANI as straightforward disruptive editors—"people who nominate things for deletion without participating in deletion debates" are somewhere around number one million on "List of current issues affecting Wikipedia". (I assume none of the people saying that the quid-pro-quo system at DYK is some kind of model have actually looked at DYK lately? It's a straightforward trainwreck of people promoting obvious errors without bothering to fact-check it for themselves, in the rush to get that all important QPQ checkmark. I don't know if he still does, but
  Iridescent
  08:57, 20 April 2020 (UTC)

  I did indeed used to keep tabs on the error rates, there was typically something wrong with around 20% of material promoted. I'm not allowed to discuss this specifically at all thanks to restrictions but I can assure people that QPQ is just about the worst idea ever implemented around some parts. The Rambling Man (Stay indoors, stay safe!!!!) 09:07, 20 April 2020 (UTC)

• Comment – I think there's a compromise to be had by broadening the encouragement to include "repayment" in any appropriate area, even if it's a different area than the one the "request" is made in. I think the common thread between nominating an article for AFD, starting an RFC, or tagging an article, is that each of those is a solicitation for volunteers to spend their time addressing some issue, e.g. by !voting, closing, or clearing a tag. As I understand it, the principle behind
  cn}} tag–whatever the editor feels comfortable doing. It can be in the same topic area or a different topic area, but the point is, if you add to "the queue" in one area, help clear "the queue" somewhere else–wherever you can. Levivich ^{[dubious – discuss}
  ] 05:29, 22 April 2020 (UTC)
  • No edit should be made to wp just to "respond to other editors' solicitation of editor time". Every edit should be to improve wp - either directly (e.g. by adding information to an article) or indirectly (e.g. by making a useful contribution to a discussion). DexDor ^(talk) 11:30, 22 April 2020 (UTC)
    • Thankfully, they're not in any way mutually exclusive. Your edit above this one, for example, both responded to an editor's solicitation of editor time, and improved the encyclopedia. Responding to editors' requests for editor time is improving the encyclopedia. It's the basis of collaborative editing. Levivich ^{[dubious – discuss]} 12:51, 22 April 2020 (UTC)

After having had to update

All the best, Naypta ☺ | ✉ talk page | 13:00, 24 April 2020 (UTC)

Concern was raised at

I'd love to hear people's thoughts on this, and for anyone who can to improve further on my work! Hopefully this should encourage people to contribute, but to contribute positively. | Naypta^✉ opened his mouth at 21:36, 23 April 2020 (UTC)

I actually like this quite a bit; thanks for the work Naypta! I'll give more thorough feedback later, but in general I think this accomplishes the goal of clearly warning editors while helping them learn how to not accidentally cause problems. — Wug·a·po·des​ 21:58, 23 April 2020 (UTC)

@Sdkb: You've helped redesign a lot of stuff, any thoughts on this? — Wug·a·po·des​ 23:36, 23 April 2020 (UTC)

Thanks for the ping Wugapodes, this is certainly up my alley. I definitely agree that there's room to make the notice more welcoming. Here is my sense of how a good faith new user might interact with the current notice: "Okay, this is a strong warning, it looks like bad things will happen to me if I don't comply with the right rules. But what are these rules? *clicks on "Wikipedia policy and editorial norm" link, which goes to the WP:List of policies directory* Yikes! There's no way I'm going to learn all these policies. I'll just give up and hope someone else makes the change."

The fundamental thing we're trying to convey is "do not disrupt this page or you will be blocked", so that's what I think should go after the colon. Everything else is details/disclaimers. For being more welcoming, I could see us including a link to

WP:BRD

, which is probably the most pertinent norm.

And I like the idea of including a link to talk for editors who aren't confident enough after reading the message to make an edit directly. It should probably go to the article's talk page rather than the user's talk page. {{u|Sdkb}} ^talk 00:12, 24 April 2020 (UTC)

I think

WP:RECKLESS makes clear that we want them to edit, but to be careful while doing it, which is the point of (especially COVID) discretionary sanctions. — Wug·a·po·des

​ 00:19, 24 April 2020 (UTC)

Yeah,

WP:COMMONSENSE goes to a subsection of the what IAR means page, so maybe not. We don't need a link to explain common sense (it's an intuitive concept), so maybe just write something like "constructive edits are welcomed". {{u|Sdkb}} ^talk

00:56, 24 April 2020 (UTC)

Hi Sdkb and Wugapodes, this is all some great thinking. I've updated Proposal 1 with some of these ideas - could you take a look? Cheers! | Naypta^✉ opened his mouth at 08:05, 24 April 2020 (UTC)

I think it does a better job explaining the restrictions. I don't think it's less scary, if that's the main intent, though. "You may be blocked if you do not." in big, red letters is more intimidating that the previous message, which has no red letters and smaller text. (Plus combined with the previous sentence, it is saying you may be blocked for not reading the notice carefully.) Personally, though, I don't mind a more scary introduction, in order to draw attention. I suggest rewording it to something like "You must read this notice carefully before editing. You may be blocked if you fail to comply." (I also don't like "click here" as it is contrary to best practices for web pages, but I appreciate it can be useful when dealing with less technically-inclined editors.) isaacl (talk) 23:46, 23 April 2020 (UTC)

Agree. The red text looks more alarming to me than the previous version. It has a better overall explanation though. --Gtoffoletto (talk) 00:07, 24 April 2020 (UTC)

@Isaacl and Gtoffoletto: I made some changes to address these concerns, do you have any further feedback? I tried to make it less alarming but still firm. The "click here" bit is still in there, only because I do think it's more obvious for new editors who may just skim it. — Wug·a·po·des​ 00:33, 24 April 2020 (UTC)

Personally, I don't like It is very important that edits on this page and similar pages strictly comply with Wikipedia policy. because it's important for all pages. I still think it's more scary, but that's OK to me.isaacl (talk) 03:34, 24 April 2020 (UTC)

@Isaacl: That's entirely fair, I was thinking that when writing it initially, but couldn't see any other way of getting it across! I've taken some new ideas from Proposal 2 and this discussion into Proposal 1 - could you take another look? Cheers :) | Naypta^✉ opened his mouth at 08:05, 24 April 2020 (UTC)

Strong Oppose: There isn't much of a difference. The problem I see is about a "huge red warning talking about discretionary sanctions, a phrase a new user has almost certainly never heard before but sounds very legal and scary, I imagine would be very offputting to a new user." and to get rid of it. All your proposal does is literally that. I don't know what new user {{

replyto}} Can I Log In's (talk) page

would react to either one of those two, but this proposal only renforces the "huge red warning" that you say you want to get rid of. 00:53, 24 April 2020 (UTC)

@Can I Log In: Hi, thanks for your contribution! I added that text to try and encourage people to read the notice, but I can see why that might seem to have the opposite impact to what I've written :) Sdkb had some great ideas in proposal 2 to refine that text, replacing it with "You will be blocked if you disrupt this page" rather than the more generic form - what do you think? | Naypta^✉ opened his mouth at 08:05, 24 April 2020 (UTC)

The goal I see is to try to get something like

replyto}} Can I Log In's (talk) page

15:31, 24 April 2020 (UTC)

• I just
  WP:MEDRS, etc. {{u|Sdkb}} ^talk
  02:09, 24 April 2020 (UTC)

  I like directly warning that disrupters may be blocked. I prefer the phrasing in the first proposal that starts with listing the problematic behaviours by editors. This puts the focus on the editors reading the edit notice, which I think makes it easier for them to relate to the message, rather than reading about what administrators ("whoever they are", a neophyte may think) may do. isaacl (talk) 03:39, 24 April 2020 (UTC)

  @

  the remedies use specific language to spell out what's considered disruptive, and I don't want anyone to be able to try wikilawyer their way out of a violation. {{u|Sdkb}} ^talk

  07:01, 24 April 2020 (UTC)

  I've pinged you both earlier replying to things in this thread, but I've updated Proposal 1 with some of these ideas. I think proposal 2 looks great, the only things which I thought it was missing which were present in proposal 1 was the slightly greater level of guidance for new users, who are likely to be editing COVID-related pages, and also a link to

  WP:MEDRS which I strongly think should be in there. Take a look and let me know what you think! | Naypta^✉

  opened his mouth at 08:05, 24 April 2020 (UTC)

• Also, since we're at the Village Pump where we can/should discuss more than just COVID-19, the general template for discretionary sanction edit notices is at
  Template:Ds/editnotice (I think), and our discussion here should probably result in changes to it. {{u|Sdkb}} ^talk
  02:13, 24 April 2020 (UTC)

  Agreed - personally, I think whatever changes are made here, similar changes should be made over there. I do think we need to be slightly careful with that though, as there may be some circumstances where the harsher and less friendly wording really is apt, for very persistent vandalism etcetera. Perhaps two or more different versions of the DS editnotice ought to exist. | Naypta^✉ opened his mouth at 08:05, 24 April 2020 (UTC)

  I can see cases where you would want two versions to work with, but very persistant vandalism would already have led to their being booted. But use of 1 after GF or at least not wilfully damaging versions, and the other after an instance of vandalism (or similar) would make sense. Nosebagbear (talk) 09:35, 24 April 2020 (UTC)

  @

  edit notice which displays while you have the edit window open for a page. {{u|Sdkb}} ^talk

  18:22, 24 April 2020 (UTC)

  @Sdkb:, ah apologies on my behalf. That makes somewhat more sense. I suppose you'd get some edge cases (across the excessively growing hoard of COVID articles/GS articles) where both are applying, but that might be an unavoidable issue. I realise implementation isn't dictated by you, but would you suggest usage be considered by the most common issue or the aggressive one (i.e. if at least 20% of the issue is persistant vandalism, put that)? Nosebagbear (talk) 18:58, 24 April 2020 (UTC)

  @Nosebagbear: My preference is to have two notices, one for each use case. That's what I've done in proposal 2 — the general notice (top) is targeted at good faith editors seeking advice, whereas the GS notice (bottom) is targeted as disruptors. {{u|Sdkb}} ^talk 19:04, 24 April 2020 (UTC)

• Okay I've criticized Proposal 1 and 2 for having a "huge red warning talking about discretionary sanctions, a phrase a new user has almost certainly never heard before but sounds very legal and scary, I imagine would be very offputting to a new user." and being like
  replyto}} Can I Log In's (talk) page
  15:31, 24 April 2020 (UTC)

  I was making a

  replyto}} Can I Log In's (talk) page

  19:02, 24 April 2020 (UTC)

  I agree that the purpose of this notice is to be the "bad cop" in a sense. I'm not sure proposal 3 does that better than the other two, though. And that's why I moved

  WP:MEDRS is absolutely good advice that we should be plugging to editors of COVID-19 pages, but my sense is that it's not what people are getting blocked for. Counterintuitively, I think moving it to the less flashy notice will actually cause more people to read it, since as noted above, most good faith editors (who know that they are good faith) are going to disregard the general sanctions notice after they read the first line and realize it's not targeted at them. {{u|Sdkb}} ^talk

  18:30, 24 April 2020 (UTC)

Sorry, the nested bulleted and unbulleted items above have skipped some levels and there isn't an obvious way to fix that without changing the order of some posts, so I'm starting afresh. Intentionally disruptive editors already know they're flouting norms of behaviour and can be sanctioned for that (depending on their familiarity with Wikipedia, they may not be aware that the authorization of general or discretionary sanctions enables a more rapid response to occur). So I don't believe the initial sentence in proposal 3 will help, nor the repeated exhortation at the end. And it still has red letters, whereas the current notice has none (that doesn't bother me, but supposedly it's one of the criticisms that proposal 3 is addressing). isaacl (talk) 19:15, 25 April 2020 (UTC)

Proposal: Allow wikilinks and other wikimarkup from tooltip text to be displayed on WP image pages

Moved to

WP:VPT § Proposal: Allow wikilinks and other wikimarkup from tooltip text to be displayed on WP image pages

 – per discussion below. Naypta ☺ | ✉ talk page

| 20:19, 26 April 2020 (UTC)

Proposal: Abolish the vital articles project

Per

WP:SNOW. --AntiCompositeNumber (talk

) 20:14, 28 April 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 think the vital articles project should be abolished. Firstly, the project is not very active so there aren't many people watching over it. Secondly, we already have a list of articles tailored to all languages: meta:List of articles every Wikipedia should have. I don't think it makes much sense to have articles important in each particular language anymore. I think we should just rely on one list going forward. Interstellarity (talk) 20:42, 25 April 2020 (UTC)

Transcluded to Wikipedia talk:Vital articles and Wikipedia talk:WikiProject Vital Articles * Pppery * _{it has begun...} 20:46, 25 April 2020 (UTC)

• Oppose on this sole reasoning as the basis. I've just gone through
  WP:VA#Language (28 articles), we can see that the vital articles project has made the determination that Indo-European languages are a focal point at level 3 of vital importance, with only 3 non-Indo-European languages appearing - whereas this clearly would not be the case on, for instance, Chinese, Japanese or Arabic Wikipedia; for good reason, as on those wikis Indo-European languages are not likely to be as important a research interest as they are on Indo-European language wikis. In short, I'm not sure the project is inactive enough to merit its killing off, and as languages are inherently a point of cultural difference, what's "vital" will vary across the different wikis, so I'm not sure replacing it with a metawiki alternative is the right approach even were there to be insufficient numbers of people. Naypta ☺ | ✉ talk page
  | 21:20, 25 April 2020 (UTC)
• Oppose. The English Wikipedia's Vital Articles list/project is actually much more active than the Meta-Wiki list is, so that seems like a rather silly reason to abolish it. And the two lists serve different purposes. The Meta list is a list of articles that every language version of Wikipedia should have, while the English list is a list of the articles that are the most vital for the English Wikipedia to improve the quality of. Rreagan007 (talk) 23:57, 25 April 2020 (UTC)
• Oppose. As a member of
  Wikipedia:Today's articles for improvement/Nominations). Much of that usefulness is conditional on bots working properly to add talk page boxes, update article ratings, etc., and although there's been some activity on that lately, I think some features may still be broken. There are also ways we could make better use of the lists, such as by improving the random page tool to have an option to link to Vital Articles at a given level (currently stalled here), and automated tools we could develop to help us catch missing articles. Overall, what I think is needed is just a bit of innovation and a little less focus on the debates, but we don't need to get rid of it. {{u|Sdkb}} ^talk
  05:29, 26 April 2020 (UTC)
• Oppose. Outlines of core knowledge are useful for readers and editors. Language-specific lists are needed especially outside the natural sciences and mathematics. The project is not inactive. --Thi (talk) 07:16, 26 April 2020 (UTC)
• Moral Support playground for non academic sorting of articles.----Moxy 🍁 13:24, 26 April 2020 (UTC)
• Oppose pointless closure of an active project, which (for editors) helps identify Wikipedia-wide articles that need attention and (for readers) which articles one ought to read to gain knowledge about the world and specific topics.
  b
  } 14:41, 26 April 2020 (UTC)
• Oppose - it is a useful (and long term) project. Maybe in the future Vital Articles, WP 1.0 and WikiProject importance assessment are all superseded by a superior alternative. Until then, I see no reason to kill Vital Articles. --MarioGom (talk) 17:04, 26 April 2020 (UTC)
• Moral support I think that VA tries really hard but in the end I've found it to be a pointless and subjective criterion. buidhe 22:17, 26 April 2020 (UTC)
• Oppose. The project is a useful device for establishing a hierarchy of subjects. BD2412 T 18:06, 28 April 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.

Topic Questions as Content Suggestions

I have a suggestion I think folks might find useful. Sometimes I find an article that covers the area of my question, but it does not answer my specific question. I wish that I could post a question/missing information post to a topic to help those maintain the content make it a more complete article.

Along with the (Read, Edit, View History) tabs there could be another tab where logged in readers could leave comments or questions. It should be made clear that this is not a discussion forum where quick responses would be expected. When contributors make changes in the Edit tab, they could subscribe to posts on the comments tab.

I write a fair amount of documentation for my company. I do get those “what about this?” questions. I am happy to get those questions, and I say “thank you, I’ll add that.”

HTH

- Dan Jameson

Hi Dan, that's the goal of

Help:Talk pages. You should always feel free to leave thoughts on how to improve an article there. — Wug·a·po·des

​ 01:13, 29 April 2020 (UTC)

@Danjam47: — Wug·a·po·des​ 01:13, 29 April 2020 (UTC)

Publicizing an RfC - Gothic architecture.

This article is twice the size any article ought to be. It furthermore harps on excessively on ecclesiastical Gothic - misleadingly titled "cathedrals" - to the exclusion of other types and uses of this type of architecture. This discussion deserves a new page, under Gothic Churches, which would also discuss those Gothic churches that are deemed cathedrals. I have requested the split, but the article also has numerous other issues and faults. It is primarily the doing of two editors, whose edits and additions dwarf the content added by anyone else, and the article, which is a popular one, and its talk page, require attention from other editors for balance and objectivity. — Preceding unsigned comment added by GPinkerton (talk • contribs)

Adding an old datestamp, since this was undated and needs to be archived (RfC has expired). {{u|Sdkb}} ^talk 17:25, 12 April 2020 (UTC)

Can we discuss (again) allowing subtitles on Wikipedia pages?

Hello,

I've been editing pages for bee species in both enwiki and frwiki and I noticed that frwiki allows you to add subtitles. This is handy for species since both the common name and the scientific name can be captured at the top of the page (e.g., Blatte germanique and Andrène à deux taches).

Subtitles on frwiki can be added using the (template:Sous-titre/Taxon). I was wondering if the enwiki community was interested in developing a similar template for this site? I know that adding subtitles to pages has been discussed in the past (Archive_79#Subtitles_on_Wikipedia) but I'm just wondering if there's interest in continuing this discussion.

Looking forward to your thoughts on this. --

talk

) 17:35, 28 April 2020 (UTC)

One thing that's new since the previous discussion is

WP:WikiProject Short Descriptions. It's not exactly subtitles, but has a somewhat similar effect for mobile. {{u|Sdkb}} ^talk

17:48, 28 April 2020 (UTC)

More generally, thinking about this, I have some reservations. The purpose of a title is to convey the topic of the page, and in almost all cases that's possible to do fine without a subtitle. In the ones where a disambiguation is necessary (e.g. Turkey (bird)), I don't think there's any major usability barrier, and for species names, the one missing from the title is incorporated in the first line/infobox anyways, so it's not hard to find. Overall, this would be a major undertaking, and I'm not sure I see a clear benefit to make it worthwhile. I do appreciate the suggestion, though — it's good to keep brainstorming ideas like this! {{u|Sdkb}} ^talk 20:33, 28 April 2020 (UTC)

Frwiki isn't really a software component, it is just a template javascript hack to put text up above the normal window, so it isn't great for accessibility. — xaosflux ^Talk 19:03, 28 April 2020 (UTC)

It strikes me that the amount of time and effort that it would take to build in a feature properly into MediaWiki to produce these kind of subtitles would be better used in making infobox templates better such that the information that would be conveyed by the subtitle, and more, would be better displayed to the end user. I'd be very interested in hearing any scenario in which subtitles do something a good infobox can't - it might well be there are loads, but they don't immediately come to me. Naypta ☺ | ✉ talk page | 21:36, 28 April 2020 (UTC)

I'm not really up for this given the negative aesthetic impact, above discussion, and the fact that short descriptions exist. – John M Wolfson (talk • contribs) 05:15, 30 April 2020 (UTC)

I don't know if it's just my device, but it seems there could be a problem with how the template works in the mobile view. As mentioned, there is already a "subtitle" provided by Mediawiki: the Wikidata short description. In the desktop view the template subtitle is right below the article title fr:Blatte germanique, but in the mobile view Blatte germanique that spot is occupied by the short description, and the template subtitle is much lower and below a tool box. In the Android mobile app the template subtitle is shown awkwardly below the first paragraph of the lead. -kyykaarme (talk) 09:30, 1 May 2020 (UTC)

A bot to remove stub templates from non stub articles and to update the talk page tags

Discussing this with

Encyclopædius

10:05, 29 April 2020 (UTC)

• Support automation, however I doubt that a specific threshold is going to fly. It would be possible, and only slightly more complicated, to use a moving threshold: for instance, remove the stub tag if the article has grown by over 100 % and over 1000 characters since being tagged. Nemo 11:00, 29 April 2020 (UTC)
• Comment The problem that immediately strikes me with this is that this would require us to have a much stricter version of
  WP:STUBDEF - because effectively, this bot would be setting one. To do that, I think, requires very strong community consensus - because it has quite broad-ranging implications for what we describe as a stub. Not that that's inherently not a reason to do it - and I have a great deal of sympathy with the issue you take with the current approach, which basically boils down to "you know it's a stub when you see it" - but it does need a lot of thinking about, I think. What makes a stub a stub may be greatly different across articles, and I'm not sure that a pure measurement of text length is a good way of dealing with it. Naypta ☺ | ✉ talk page
  | 11:03, 29 April 2020 (UTC)

Yes, every article is different. But if an established editor removes a stub tag after an expansion I think it would be easy to get a bot to recognise that it is no longer a stub and update the talk page. Of course it could have been expanded to B class and wrongly assessed as start, but you know what I mean, we need something at least to sort much of this mess out and the false listings. I think pretty much universally 1.5 kb of prose is accepted as no longer a stub, if there was a bot to measure readable prose and remove stub tags from them all and update the talk pages to start class that would solve a lot even if there might be some questionable individual cases.†

Encyclopædius

11:58, 29 April 2020 (UTC)

To start with, a bot which scans all of the articles in the subcategories of

Encyclopædius

12:02, 29 April 2020 (UTC)

@

Encyclopædius: you would have to specify how the bot would determine what is "readable prose". Those of us who regularly edit articles about genera, families, etc. of organisms often have to re-add stub templates to articles that consist of almost nothing but a list of subtaxa (e.g. a list of species in a genus article). The list can be long, but this doesn't stop the article being a stub. Length alone is not a deciding factor. Peter coxhead (talk

) 13:39, 29 April 2020 (UTC)

Encyclopædius

14:53, 29 April 2020 (UTC)

• Comment Can we break down the problem. It is a good idea to let a bot remove the stub tag from substantial articles. What it does next is contentious. Possibly the simplest solution is to tag it with Lengthy article automatically destubbed.

It does not become a Start Class article if it has no independent references- or if the reference does not support the text. I have been destubbing UK schools. Using the length criteria, repeating the content of the lead in the new section 'Description' I can change a length of 600 to 1500- and its still a stub, and conversely I can reduce a 'Start' to a stub. But I also see substantial, referenced articles that have incrementally built up that are still catted as stubs. (Teachers genetically won't self-assess articles they have improved without firm criteria- I am sure that applies to other professionals) That is where the bot could be helpful.

It is certainly 'picking the low hanging fruit' to use English place names as examples, and unfair not include tables in the length criteria- encyclopedias do need lists of elected councillors. Look at Pratt's Bottom that is padded with unsourced material to qualify- but the bulk of the info is in the table- so is not counted. Still a lengthy article detector bot is a good idea- the question is what does it do next?

If it is going to run- I am sure it could add some useful analysis to the talk page. You guys are the experts- but my favorites are, missing infobox, missing image, missing source- relies solely on primary related sources, sources possibly too dated to be of use. Editors ploughing though the new backlog lists we have created will at least have a clue to the issues before committing them selves.ClemRutter (talk) 15:44, 29 April 2020 (UTC)

Lengthy book articles with no references are considered Stubs by WikiProject Novels and WikiProject Children's Literature; and if they are written by a woman, then WikiProject Women Writers also considers them to be Stubs (e.g. for purposes of the WPWW talkpage template classification). In this case, adding an infobox or a photo won't change the class, but adding four non-bare references will. For more context,

Encyclopædius and I have been discussing destubbing here, User talk:Rosiestep#Using ORES for destubbing. cc: EpochFail. --Rosiestep (talk

) 16:36, 29 April 2020 (UTC)

An unsourced 3 kb prose article should never be classified as a stub, I suggest a new category, "unsourced start".†

Encyclopædius

17:09, 29 April 2020 (UTC)

@

Iridescent

19:03, 29 April 2020 (UTC)

I have a bold counter-proposal. Why not use ORES predictions directly? ORES can predict what quality level an article currently is and it's pretty accurate. We could use the predictions directly to track status and progress. For when ORES makes a mistake, I'd like it to be simple to override ORES' prediction. E.g. if the talk page assessment is greater than ORES' prediction or it matches some criteria for freshness, use the talk page assessment. What do you think? --EpochFail (talk • contribs) 17:45, 29 April 2020 (UTC)

Here's an example query that uses the databases available to bots to generate a the predicted quality of articles tagged by the project WikiProject Women writers: https://quarry.wmflabs.org/query/44457 --EpochFail (talk • contribs) 18:46, 29 April 2020 (UTC)

predicted_assessment	COUNT(*)
Stub	1846
Start	7309
C	9844
B	2694
GA	658
FA	97

@

Encyclopædius

19:20, 29 April 2020 (UTC).

EpochFail, nice! (a) Recommendation #1: Can this table be presented with links; and if I click the link for 1846 Stubs, it'll give me another table which has links for each of the 1,846 stub articles? (b) Here User:WP 1.0 bot/Tables/Project/Women writers we see that there are 36,865 talkpages with the WPWW talkpage template, but the above table totals 22,448. Do you know why that is? --Rosiestep (talk) 20:44, 29 April 2020 (UTC)

Rosiestep It could definitely be formatted more clearly. I think we'll need a bot to produce it. I wonder if WP 1.0 bot might be extended for this. I think the reason for the difference in count is likely that many of the articles in the set haven't been edited in a long time. We started storing article quality predictions in the database about a year ago. Any article that hasn't been updated in the last year won't have a prediction. We could back-propagate the quality predictions to get full coverage. That part I can certainly help with if we get interest from a bot dev. --EpochFail (talk • contribs) 20:09, 30 April 2020 (UTC)

EpochFail, IMO, back-propagating for full coverage makes sense. Let's see if a dev comes along who's interested in taking this on... maybe at this month's Hackathon? --Rosiestep (talk) 20:34, 30 April 2020 (UTC)

• Leaning oppose, as I do not think that "not-a-stub" is a call that a bot can make, but I would support generating a list of stub-tagged articles that have grown substantially since being tagged for quick human review. We had a project like that before once, where we listed several thousand articles that had gone the longest without human attention, sorted by factors such as article length and number of human editors. I believe we sorted through that list pretty quickly. BD2412 T 21:03, 29 April 2020 (UTC)
• Oppose I like stub templates and always add them when I start an article. Their good points include:

1. they are attractive to the eye, typically having an appropriate icon and a simple easy-to-read message
2. they encourage readers to pitch and help expand the article without being too preachy or pushy
3. they go at the foot of the article so they don't get in the way
4. they help classify the article

These features make them better than the obnoxious banner tags which you find at the head of many articles. Rather than removing them perhaps we could enhance them. If an article has grown past stub stage then maybe the template could auto-detect this and adjust its message accordingly? We still want readers to help develop articles until they are perfect. The classifications which get buried in the project templates on the talk pages could be echoed so that the reader can see and understand the level of the article. Andrew🐉(talk) 22:50, 29 April 2020 (UTC)

@

Encyclopædius

16:10, 3 May 2020 (UTC)

Yes, I read the proposal and I still oppose it. Andrew🐉(talk) 16:43, 3 May 2020 (UTC)

• Oppose. This idea engineers the editor out of Wikipedia. Stub assessment is probably one of the most important tasks for early-to-middle Wikipedians. It is subjective, it involves topic assessment, many will be better AfD-ed or merged than reclassified, and doing these things is a learning process for editors. Instead, have a bot identify probable cases for reclassification, but leave it for a human to make the decision. —SmokeyJoe (talk) 23:02, 29 April 2020 (UTC)

The important thing

Encyclopædius

11:13, 30 April 2020 (UTC)

• Support ORES isn't perfect, but it's pretty good for this specific task. Unsourced articles should be deleted on sight in my opinion. buidhe 09:31, 30 April 2020 (UTC)
• Support We already do this at MilHist. The Bot can easily determine whether an article is a stub or not; this is purely objective. The hard part is the determination of B class, which generally requires human input. Hawkeye7 (discuss) 11:46, 30 April 2020 (UTC)

Question: What is the metric used at MilHist to determine stub vs not-stub? Blueboar (talk) 13:10, 30 April 2020 (UTC)

• Recommendation #2: Using the Rater feature, if I rate all the talkpage templates of an article to better than Stub-class, and if the article is tagged as a Stub, I get a pop-up message that says:

Ratings saved successfully.

Note that the article appears to be

tagged as a stub.

But currently, the converse isn't happening so it's my recommendation for someone to create a pop-up message for that: if I rate all the talkpage templates of an article to Stub-class, and if the article is not tagged as a Stub, give me a pop-up message that says:

Ratings saved successfully.

Note that the article appears to not be

tagged as a stub.

Plus, it would be nice if these pop-ups weren't limited to appearing only if an editor is using the Rater feature, e.g. if the pop-ups also appeared when an editor manually edits the talkpage templates. --Rosiestep (talk) 15:01, 30 April 2020 (UTC)

• Weak support There's a lot of stubs and not enough people doing stub sorting. Early-to-middle tenure editors can still benefit from checking the bot's work, and it will help them prioritize the other aspects of page patrol like AfD and cleanup tagging. — Wug·a·po·des​ 19:26, 30 April 2020 (UTC)

• Recommendation #3 A bot assesses and make changes which are clearly not stub articles (i. e. more than 2,500 prose characters) and the bot creates a page/list for human review (like orphaned free files, or STiki). When you get a thousand of pages at one place, which may not be stub, it becomes easier. --Titodutta (talk) 16:35, 3 May 2020 (UTC)

Propose changes to WP:Community portal

If, after three days, the discussion has remained focused on the proposer rather than the proposal, consensus will not form; there is nothing substantive for it to form from. ——SN54129 05:42, 4 May 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 would like to propose some changes to various components of the top portion of Wikipedia:Community portal. I posted this for discussion at the talk page there, but I was not able to get any discussion going there, at all.

Below is my draft for changes to the top portion of the page. this draft includes the portion of the page from the top of the page, down to the large pictorial navbar

Please note, I also have some ideas for the small navbox at the top; namely, to add just some more links, e.g. to Wikipedia:Goings-on,etc, as described below. Below is a separate draft, for the small navbox.

• Add a link to Wikipedia:Requests for comment
• moved small nav box upwards from the bottom of the page, to be right beneath the main pictorial bar of links.

* Draft for upper portion of page: User:Sm8900/Drafts/community nav box

• • Changes made:
    • Changed opening text, changed to bullet-point format.
    • Added a link to Wikipedia:News
  • Nav box from bottom of page
    • Removed links to WP:News and WP:Goings-on, to avoid showing the same links unnecessarily in multiple places.
• Draft for small navbox at top: User:Sm8900/Drafts/Header navbar community
  • Changes made:
    • added a link on its own row, to Wikipedia:About
    • added a link, to Wikipedia:Goings-on

I appreciate any feedback. I would like to move ahead with this, if possible. I am open to any and all ideas, feedback, comments, etc on this. thanks!!! -- Sm8900 🌎 17:27, 30 April 2020 (UTC)

If you haven't garnered any support from your previous four post about the same thing last week and the week before .....perhaps best to assume support is simply lacking. Very hard to move forward when suggestions are suggested and ignored.--Moxy 🍁 20:41, 30 April 2020 (UTC)

Hi Moxy. it is good to have your response here. just to clarify, I did sincerely follow your suggestion; I removed the duplicate links, to WP:Goings-on, and to WP:News. so this proposal was meant to directly accord with your points on that. If you prefer, I will restore WP:Goings-on to its original place, and remove the new links that I added to WP:Goings-on, and to Wikipedia:About. Would that make this proposal more amenable? I did ask for your input on the ideas tab, as to which you prefer. I would be glad to follow your suggestions in either respect. I will be glad to modify my draft. I appreciate your response; your reply was truly helpful in helping me to perceive some of the points needing to be addressed. thanks!! --Sm8900 🌎 00:21, 1 May 2020 (UTC)

Sorry, I don't see most of these as positive changes. You'll have a better chance if you propose them individually as pieces than in one giant chunk. To address a few specifically: There's no need for the top to be bulleted (it's already short). Adding WP:About isn't appropriate since that page is for readers, not editors. News is already covered on the portal further down, and the Signpost is really the main item, so if there's a link it should just be there (WP:Goings-on is certainly not very active). {{u|Sdkb}} ^talk 05:35, 2 May 2020 (UTC)

@Sdkb: I agree with you. Based on your helpful suggestion, I have narrowed my proposal to the two items below. does this sound okay? I appreciate your help.

• Add a link to Wikipedia:Requests for comment, on pictorial nav bar..
• move small nav box upwards from the bottom of the page, to be right beneath the main pictorial bar of links.

thanks. ---Sm8900★ 🌎 02:41, 3 May 2020 (UTC)

Readers will expect to find the nav box at the bottom of the page per

MOS:LAYOUT, and RfCs are already linked to from the "Discussions and collaborations" section. {{u|Sdkb}} ^talk

02:50, 3 May 2020 (UTC)

Phil Bridger (talk

) 17:17, 3 May 2020 (UTC)

no, I agreed to stick to a centralized discussion process when making any such proposals. —-Sm8900★ 🌎 21:55, 3 May 2020 (UTC)

No, you agreed "

Iridescent

22:10, 3 May 2020 (UTC)

I would appreciate if you would please refrain from making personal comments here. I did not make any personal comments to you. To answer your inquiry above, I agreed only to cease presenting a proposal in any venue other than the central venue for discussing such proposals. . I did not agree to just to stick to content creation and normal editing for a while … and to cease with the 'grand ideas' and problem-solving for a bit". the specific issue raised in that colloquy was posting a proposal at several pages for wikiprojects. I agreed to not do so in the future. your characterization here of my approach here is not accurate. I appreciate your attention to my response. thanks. ---Sm8900★ 🌎 22:55, 3 May 2020 (UTC)

Just for the record, I would like to note that I have posted a reply to Iridiscent at their talk page. I am copying and pasting a portion of that reply below, in order to publicly respond, and to hopefully provide a response that will be helpful, constructive, and substantive in a manner to enable future discussions here to proceed in a positive, constructive, civil and helpful manner. I appreciate the help and understanding of all participants here. thanks.

Hi. I appreciate your note to me at Village Pump. I understood that you were posing a question to me, and I provided a response, which I hope was responsive and helpful. also, you stated that I "feel this constant need to propose grand redesigns of Wikipedia and constantly act like the only opinions of any value are those of people who agree with you." I am not aware of any area or venue that I am acting in that manner in any way at the present time, or at any time in any edit over recent weeks. In any future interactions, I would appreciate if we could please address each other in a positive and constructive manner, and avoid any personal comments, or any comments on individual actions that are tangential to the current topic, and obviously seek to observe

WP:Civil

in every respect. I do sincerely appreciate and respect your desire to make Wikipedia a better place.

thanks. ---Sm8900★ 🌎 23:14, 3 May 2020 (UTC)

Sm8900 - You've got tons of energy, to be sure. GoodDay (talk) 00:01, 4 May 2020 (UTC)

thanks!! I appreciate your note to me above, GoodDay. thanks. ---Sm8900★ 🌎 00:15, 4 May 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.

Is there a way that a thank tag can be added to the Recent Changes page?

Tracked in Phabricator
Task T90404

I'm making a proposal that a thank tag be placed to any edits that appear on the Recent Changes page.

Respectfully, Thanoscar21 (talk) 13:25, 5 May 2020 (UTC)

There is a task for it (

t/c

) 13:30, 5 May 2020 (UTC)

Thank you for your time! Thanoscar21 (talk) 14:03, 5 May 2020 (UTC)

Thanoscar21, there's now a script for this at User:Enterprisey/rc-thanks. Enterprisey (talk!) 14:48, 5 May 2020 (UTC)

Thanks! Thanoscar21 (talk) 14:51, 5 May 2020 (UTC)

Proposal for a bot to update backlinks when pages are moved, merged or otherwise become redirects

In a discussion earlier over at the talk page for the ongoing RfA, we came across a scenario where, partially as a result of backlinks not being updated after a page move, content was kept in a way that was incorrect in an article for a fair while. I'm more than sure this isn't the only similar case like that, or even the most severe case, and it set me thinking what we could do to help fix that.

Don't get me wrong, inevitably a bot will never fully replace human backlink reviewers. I'm explicitly not suggesting that this should replace the indication for people who move pages to check Special:WhatLinksHere and to go through and update the links manually. However, inevitably, people will sometimes forget to do so - I bet I probably have in the past, as did the user moving the page in the scenario that I mentioned above. As a result, I'd like to propose a bot that can clean up whatever falls through the cracks.

I know this is technically possible because I've already written the code, but I wanted to make sure there was consensus that this was a good idea before it goes to

WP:BRFA

. Questions of technical implementation (which I think are best left over there, if and when we get there) aside, the basic process of what the bot would do is as below: