Policy Technical Proposals Idea lab WMF Miscellaneous 

New proposals are discussed here. Before submitting:

Discussions are automatically archived after remaining inactive for nine days.

Convert all English variant notices to editnotices

No consensus to implement - There seems to be a general preference to avoid clutter (due to potential banner blindness, etc.), whether in the article, the edit notice, or the talk page. There also were concerns noted that an edit notice would not appear on the mobile app, and also that only those with advanced permissions could edit an edit notice to add a template. There were also some isolated ideas for some technical feature additions, but none had broad consensus from this discussion. No prejudice against starting a new discussion concerning one or more of those, of course. - jc37 02:33, 26 April 2021 (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 proposal arises from an ongoing discussion at the idea lab about how to reduce the clutter of excessive talk page banners, a phenomenon that leads to banner blindness, overwhelming and confusing new editors and reducing the visibility of the more important notices.

One idea I put out that seems to have gotten particular traction is that there is no need to have English variant notices (e.g. ((British English))) appear on the talk page, rather than just as an editnotice that appears in the edit window while one is editing the article. The primary rationale is that no one is policing the English variety used on talk pages, so the only place this is needed is the editnotice. I'm therefore proposing here that we convert all existing English variant notices on talk pages to editnotices on the corresponding page. This would be done via a bot task, and once completed Module:English variant notice would be configured so that it produces an error notice if placed on an article talk page. ((u|Sdkb))talk 14:34, 10 January 2021 (UTC)[reply]

Survey (English varieties)

Discussion (English varieties)

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.

RfC on limiting minor edits

Question: Should the minor edit functionality be limited to a group of users (such as autoconfirmed or extended-confirmed users)?

This is a follow-up to this RfC on effectively disabling minor edits. As there was no consensus then, this is to establish clearer consensus regarding an alternative proposal. (This is my first time requesting comment, please let me know if I'm doing anything wrong.) Tol | Talk | Contribs (formerly Twassman) 00:02, 1 April 2021 (UTC)[reply]

Survey (minor edits)

A system where editors could tag edits as being grammar/spelling correction, style/layout issues, rv vandalism, wikilinking things, or a few other topics would serve the dual purpose of being a more useful tag for filtering/sorting purposes (maybe you want to see corrections of factual errors but not grammar/spelling corrections on your watchlist) and assist new editors who don't really know how to use edit summaries or the existing system. Said system has a slim to none chance of actually being implemented though (too busy making margins bigger) so I have to go with Option 0 for now. Chess (talk) (please use ((reply to|Chess)) on reply)Template:Z181 01:56, 3 April 2021 (UTC)[reply]
I support B with a twist, calling it Option B2, where it additionally includes Pending changes reviewers, Rollbackers and/or Patrollers (even though I've been here for 4 years and contributed more than most but still not qualifies for any of those groups) as well as bots. Autoconfirmed is too easy to get around. It could also be limited to byte size, preferably it would be clever enough to figure out when someone reverts data-rich vandalism.
I saw User:The Earwig suggesting in the earlier RfC that the minor edit feature could be blocked from a user if it's misused. I think that's a splendid idea.
User:Vaticidalprophet made an important note that the minor edit feature could be used by the poster to themselves distinguish them in their own statistics. So a compromise would be that minor edits can be marked by (auto)confirmed users but doesn't show to anyone else. Not until that user is extended confirmed will marks show, and then only marks made after the user has become extended confirmed.
User:Chess suggested that it could be replaced with another system instead, where one categorises the edit based on type, like grammar/spelling correction, style/layout issues, revert vandalism, wikilinking things, and so on. That is a terrific idea!
If nothing of this, then I lean towards a complete removal or at least limiting to administrators and bots rather than the microstep to limit it to (auto)confirmed or – heaven forbid – status quo. Even now as I checked, I discovered that two persons I spotted misusing it and pointed out for, were in fact extended confirmed users! So this feature is absolute garbage right now, worse than not having it at all. But if it stays and gets regulated, I also think minor edits should become an official guideline.
It's disheartening to see so many in favour of status quo specifically for the abuse. It's completely backwards thinking and a testimony to how broken the feature is. Even more so from the ignorant and selfish people saying there's no problem at all, implying for anyone. --Mango från yttre rymden (talk) 23:57, 2 May 2021 (UTC)[reply]

Data on usage of minor edits

Quickly sorting through the past 100 minor edits to the mainspace by human editors of each of the following categories (specific revisions available here), I have some data. Note IP (unregistered) users cannot use minor edits. I am also erring on the side of assuming an edit to actually be minor.

I had to remove ClueBot NG edits because apparently even the "Human (not bot)" checkbox doesn't exclude its edits. Tol | Talk | Contribs (formerly Twassman) 01:22, 2 April 2021 (UTC)[reply]

I think this is only half the story—where's the control sample? The information I think we need is how many minor edits in each of the categories are vandalism/bad faith/unconstructive and how many major edits in each of the categories are the same. For instance, based on what I see in my watchlist (obviously selectively biased) I would expect more than 58% of registered-and-non-autoconfirmed edits to need reverting wholesale, so that 58% of minor edits that need attention is not necessarily a flaw in the system. — Bilorv (talk) 13:18, 2 April 2021 (UTC)[reply]
Looking in each category on Recent Changes (new data), and highlighting edits tagged as reverted, 20% of minor edits by registered users were reverted, compared with 1% for autoconfirmed, and none for extended-confirmed. Tol | Talk | Contribs (formerly Twassman) 16:32, 2 April 2021 (UTC)[reply]

Option C

Apparently it isn't possible so it isn't worth debating. Oh well. Beeblebrox (talk) 20:49, 3 April 2021 (UTC)[reply]

An edit filter that detects and informs when very new users are marking edits as minor. Seems like a middle road. Beeblebrox (talk) 19:14, 3 April 2021 (UTC)[reply]

This seems unnecessary, it's already possible to filter for these on recent changes. See [1] User:力 (power~enwiki, π, ν) 19:17, 3 April 2021 (UTC)[reply]
This is impossible (with an edit filter); the ability to detect minor edits was removed years ago. However, filter 970 (hist · log) detects new users making large changes with a summary like "fixed typo". Suffusion of Yellow (talk) 19:36, 3 April 2021 (UTC)[reply]

Pop-up notice

Part of the issue we have with minor edits is that our definition of minor is not intuitive, and this means that we have to assume that people misusing the box are doing so out of ignorance, which makes it very difficult to do enforcement. I propose that, should Option A or Option B be adopted, the first time an editor checks the minor edit box, a notice pop up with a brief definition of what we mean by "minor" (perhaps similar to the wording at ((uw-minor))) that the editor would have to okay. This would ensure that everyone making a minor edit can be expected to understand what it means. ((u|Sdkb))talk 16:00, 5 April 2021 (UTC)[reply]

An extended comment/rebuttal to option 0

I, the proposer of this RFC, have seen rather many confusing option 0 responses; I will counter those here.

Tol | Talk | Contribs (formerly Twassman) 22:26, 11 April 2021 (UTC)[reply]

The problem is that many edits marked as minor by new users are not actually minor. I do not consider that a problem. TonyBallioni (talk) 22:28, 11 April 2021 (UTC)[reply]
@TonyBallioni: As I said, the watchlist function allows users to hide minor edits. With these edits, which are not minor but are marked as such, someone who hides minor edits on his or her watchlist will not see these edits even though he or she wants to. As most of these edits are by new users, I believe restricting the feature to more experienced users (who are more likely to use it correctly) is a good idea. Tol | Talk | Contribs (formerly Twassman) 22:33, 11 April 2021 (UTC)[reply]
And I disagree that what you are describing is actually problematic. Maybe it's because I've never hidden minor edits on my watchlist, but if someone makes the choice to hide them, that's on them. There's no reason to restrict it because of that. TonyBallioni (talk) 22:36, 11 April 2021 (UTC)[reply]
I agree completely with Tony. I don't know why people choose to hide minor edits on their watchlist (the only edits I hide are my own), but that's not the primary function of the flag. As has been said multiple times by multiple people, the solution to what you are seeing as a problem is to teach people how to correctly use the minor edit flag not to remove their ability to use it. Thryduulf (talk) 22:45, 11 April 2021 (UTC)[reply]
@Thryduulf: The reason to hide minor edits would be because one wants to see the substantive edits to the article but skip the minor ones. For teaching people: we do have ((Uw-minor)) for this purpose, and while I've tried to use it as much as possible, there isn't a "new users' minor edits patrol" akin to RCP to teach people about minor edits. I do agree that education on minor edits is definitely preferable to removing it from new users, but I'm not sure how to do that effectively. Now I have an idea for a bot, hmm... Tol | Talk | Contribs (formerly Twassman) 23:00, 11 April 2021 (UTC)[reply]
I agree with Tony and Thryduulf. Also, yes, you should have said this at the start of the RfC. Thanks. Mike Peel (talk) 07:22, 12 April 2021 (UTC)[reply]

Comment on mobile editing

Note that the mobile web source editor does not have a minor-edit checkbox/toggle. Mobile VE and iOS app editor do.

  1. On mobile, I have sometimes resorted to hand-typing "[minor]" in the edit summary, though you can't filter that from your watchlist.
  2. It suggests that, at the time mobile / Minerva was designed, minor-edit (along with several other features) was deemed unnecessary or too confusing for "typical" mobile users, or too cluttered for smaller screens. But the devs' thinking on that seems to have changed.

Pelagicmessages ) – (17:58 Sun 25, AEDT) 06:58, 25 April 2021 (UTC)[reply]

An observation

I do not believe that any restriction based on numbers of edits is worthwhile. For what it's worth, my approach is that I don't omit minor edits from my watchlist, but usually don't bother to check minor edits by editors who I trust to mark edits appropriately. These are not necessarily the same as editors who I usually agree with, and certainly do not correlate with numbers of edits made. I would expect most people to take a similar approach. For myself I don't believe that I ever mark non-minor edits as minor, but often forget to mark minor edits as such. Whatever system we have apart from removing minor edit functionality completely will always be vulnerable either to editors who don't know what should be tagged or to malicious editors who want to fly under tha radar, and I'm sure there are quite a few extended confirmed editors who fall into those categories, as anything based on numbers of edits is very easy to game. Phil Bridger (talk) 16:26, 25 April 2021 (UTC)[reply]

What I would support is a policy that states that minor edits have to be used sensibly. (and repeated offenses made blockable) That's vague, but on Commons I once ran into an admin who had "Mark all edits as minor" enabled in their preferences. (this option doesn't appear to exist on enwiki though) That's obviously disruptive. If use cases can be presented, maybe a proposal could be made to make minor edits a user right that can be revoked. — Alexis Jazz (talk or ping me) 16:50, 25 April 2021 (UTC)[reply]

Redesigning the featured, good, and article assessment icons

Related icons

This proposal seeks to establish consensus for new icons that appear in the upper right corner of good articles (GAs) and featured content (FC) pages to mark their status, as well as the variant icons of these (candidate, former featured/good, former candidate). For the sake of consistency, it also proposes new assessment (A-B-C-Start-Stub-List-Disambig) icons.

Background: There was recently a Village Pump proposal (here) discussing whether or not to change the FA and GA icons. Main issues brought up were the overly detailed FC icon, which causes it to render poorly as small sizes, as well as the confusing GA icon, as it also is used as a "support vote" icon. In short, Support for the proposal outnumbered opposition, 2-to-1. As such, I have created new icons that I believe alleviate these issues. I've made quite a few variants of these icons, a large number of them that can be found here: File:FA-GA icon proposal.png, but for the sake of streamlining this process, I have chosen what I believe to be the most clear and intuitive ones in the proposal. As opinions come in, we can make new proposal sets of icons.

Proposal 1

Key points:

Support (article icons)

Oppose (article icons)

Discussion (article icons)

@Pbrks: (or anyone) can you make a table of before/after for these - that has been quite helpful in similar discussion about icons. — xaosflux Talk 21:18, 2 April 2021 (UTC)[reply]
@Xaosflux: Yes, I will make them shortly. Pbrks (talk) 21:26, 2 April 2021 (UTC)[reply]
@Pbrks: do you have these as actual files that are already uploaded that can be in a normal table instead of a picture of a table? — xaosflux Talk 23:45, 2 April 2021 (UTC)[reply]

Taking a step back

I googled the words "Quality" and "Icon" and I found a lot of metals with ribbons attached to them. We can have a gold jigsaw puzzle to indicate the Featured article, and a silver jigsaw puzzle to indicate Good Article. I'm just being creative at the moment. So long as these icons shine and stand out positively, then maybe editors may support the proposal more. The dotted line forming a star isn't clear to me, and the Question mark resembles the DYK icon. I think it would be easier to use a magnifying glass over the current icons for representing re/assessment. The current Red X and Broken GA (in my humble opinion) are upsetting and can be discouraging. The red-painted cross over the featured article and the broken GA symbol is just not professional icons in my opinion and even look like there's anger involved.Blue Pumpkin Pie (talk) 20:11, 10 April 2021 (UTC)[reply]



It's regrettable that a constructive idea was shot down so quickly (less than a day!) and for such poor reasons. Sometimes it's good to discuss new ideas even if they're not immediately going to fix an urgent problem, we might uncover issues that the early knee-jerk WP:AINTBROKE crowd hadn't thought of. And frankly our FA icon at topicon resolution (where readers normally see it) looks like it was drawn on the back of a napkin with a sharpie and digitized with one of those old hand-held roll scanners, or else shrunk from its original size down to 10px and then scaled up again. Putting this blighted icon on a featured article makes the article less good. I realize it's what readers and editors are used to, but that's not a good enough reason on its own to keep it, and certainly not to shut down a discussion about it after just over 18 hours. Just a plain bordered star in the same colour would be not so much of a departure from the current icon as to be confusing, and would be a fair improvement. But I guess nobody wants to talk about improving the encyclopedia. Ivanvector's squirrel (trees/nuts) 19:22, 8 April 2021 (UTC)[reply]

I agree. Since the close mentions SNOW, I also want to point out this section of the essay saying: "It can sometimes be better to allow a few extra days even if current discussion seems very clearly to hold one opinion, to be sure that it really will be a snowball and as a courtesy to be sure that no significant input will be excluded if closed very soon." In general, I like the proposed designs for FA and GA (though agree that the good-article-grey is a bad color choice). They read much better at small sizes, are symbolically more clear (an absent star and question mark are a lot more intuitive than the existing symbols), and the style matches the recently redesigned protection icons providing a more unified design. I hope we can give these ideas more serious consideration next time around. Wug·a·po·des 23:29, 8 April 2021 (UTC)[reply]
Agreed, though the proposal in its fullest form might be seen a snow close, a lot of opposers offered sympathy for specific improvements. The latter is valuable information that could thoroughly inform future discussions, but has been halted unnaturally. Aza24 (talk) 23:34, 8 April 2021 (UTC)[reply]
I disagree - this specific proposal was correctly SNOW closed because it was very clearly never going to get a consensus. There is nothing stopping you or anyone else going back a step or two and initiating a discussion to generate a broad consensus for the need for change (which hasn't yet occurred). If there is a consensus for change, then the next step is to workshop multiple designs, implementing the results of feedback received, before presenting a small number of well developed proposals for adoption. Getting more of the same feedback on this proposal and more reminders about the lack of consensus that a need for changes exists is not going to help that. Thryduulf (talk) 17:12, 9 April 2021 (UTC)[reply]
Yes, how terrible for Wikipedia that someone with an idea wanted to talk about it, but didn't get permission from The Community first. What a sterile, needlessly bureaucratic place this is becoming. Ivanvector's squirrel (trees/nuts) 12:55, 10 April 2021 (UTC)[reply]
The one thing I'd say while this is in the spotlight is that, for any editors graphically-inclined, it'd really be helpful to have additional help with that. Wikipedia:Graphics Lab/Illustration workshop#Good article and featured article topicon redesign has been sitting around for months and hasn't yet gotten the level of engagement that I'd hope for it to get. ((u|Sdkb))talk 23:00, 12 April 2021 (UTC)[reply]
This should be re-closed per WP:DEADHORSE, its been a month already. - Knowledgekid87 (talk) 01:53, 4 May 2021 (UTC)[reply]

Consolidating help venues

Moved from Wikipedia:Village pump (policy)

AFAICS, we have a few primary help venues for questions of a general nature:

I don't know exactly what the difference between Teahouse and Help desk is (in this MP discussion other editors raised this point), possibly the former is considered useful for newbies and the latter for experienced editors? Though skimming the Teahouse and HD I don't really get the impression that these are really distinct in terms of questions asked. More importantly, my feeling is that Wikipedia:Editor assistance should probably be redirected somewhere, as that venue is completely inactive and mostly goes back to pre-2011, and WP:EAR should probably be redirected to either Teahouse or the help desk as it doesn't seem to have any distinguishing features from either. ProcrastinatingReader (talk) 16:10, 20 April 2021 (UTC)[reply]

resolved venue discussion
  • @ProcrastinatingReader: I'm missing which policy or guideline this is seeking to create or amend - perhaps a different venue would be more appropriate for this. — xaosflux Talk 17:34, 20 April 2021 (UTC)[reply]
    I think I'd meant to post this at VPR (only just realised it's at the policy pump). I'll move. ProcrastinatingReader (talk) 17:37, 20 April 2021 (UTC)[reply]

IIRC, even some of our level-one warning templates direct them there.
– Pelagicmessages ) – (12:45 Sun 25, AEDT) 01:45, 25 April 2021 (UTC)[reply]

Proposal: deprecate WP:EA/WP:EAR and close down all active templates or help pages linking to it

Proposal: Replace Main Page Help Desk link with Teahouse link

Support replacement of link....only need one and the teahouse is better at recruitment for new editors. This past year has seen a good increase in the amount of individual edits but a decrease in registration.....perhaps the Teahouse can help us fix this problem.Moxy- 23:08, 2 May 2021 (UTC)[reply]

Archive RfPP reports

I am creating a permanent archive of reports at Wikipedia:Requests for page protection. I have already done some, which can be seen at User talk:Chicdat/RfPP archives. I would like to see what the wider community of Wikipedia thinks of this. 🐔 Chicdat  Bawk to me! 10:54, 21 April 2021 (UTC)[reply]

What's the point of this? I mean, the archiving bots could be setup to create permanent, dated archives if that were deemed useful (verses the current rolling archives). But there's simply so many reports made I just don't see how it could be useful. ProcrastinatingReader (talk) 11:17, 21 April 2021 (UTC)[reply]
While protecting a page, an administrator could review other protection requests of the page to determine whether to protect or not. 🐔 Chicdat  Bawk to me! 12:23, 21 April 2021 (UTC)[reply]
I guess it'd be up to RfPP admins if they'd find that helpful, but if they think yes then it'd probably be better to WP:BOTREQ a bot to reply to RfPPs with links to permalinks of previous protection requests. Even if you did manage to compile all RfPP archives on your page (a very laborious task to do by hand), it'd take so long for that page to load and then to ctrl-f the page title that it just wouldn't be particularly effective. ProcrastinatingReader (talk) 12:51, 21 April 2021 (UTC)[reply]
I do not plan to do sixteen years of RfPP on that one page. When it reaches 500KB, I will split it. Chicdat (talk) 12:42, 26 April 2021 (UTC)[reply]

Categorizing Wikipedia Books

This is largely a follow up to Wikipedia:Village pump (proposals)/Archive 177#Deprecate linking to Wikipedia books in templates and articles where it was decided to remove links to the book namespace from articles and templates. This was because books don't serve our readers anymore with the book creator no longer working. There is still one user facing place where there is a significant amount of links to the book space and that is content categories. My proposal is to remove all content categories with articles from Wikipedia books while retaining categories like Category:Wikipedia books on Christianity. Links to other related discussions: Deletion of Template:Wikipedia book (2021) and Supress rendering of Template:Wikipedia books and remove link in sidebar (2019). --Trialpears (talk) 12:44, 23 April 2021 (UTC)[reply]

Seems like no one particularly cares about this matter (understandable). I will start removal tomorrow. --Trialpears (talk) 01:49, 1 May 2021 (UTC)[reply]

Can we come to a consensus on when it is appropriate to "rescue" live links in an article with IABot?

If you visit the history page of any article, at the top you'll see "Fix dead links". This takes you to a page on https://iabot.toolforge.org where you can use IABot's database to add archive links to the page. There is a box for "Add archives to all non-dead references (Optional)" and it's that little box that I'd like to talk about here.

As I understand it, clicking that box does not archive the page. That has already been done by the bot and stored in an off-wiki database. All it does is copy the archive links that already exist into the article en masse. Many people have taken to just going around to various articles that do not have dead links and "rescuing" all of the live sources.

The reasons why this is good: I think the main reason people think is good is because it archives all the links (i.e. misunderstanding how it works), but there's something to be said for having everything already in the article, just in case IABot goes down, stops being maintained, etc.

The reasons why this is not good: It adds significantly to the size of the page without adding any meaningful functionality. See for example, this diff which was just the most recent on my watchlist and not the largest I've seen. It adds 12k to the page with no dead links rescued. This means the page is larger, of course, but also means anyone using the source editor has to scroll through even larger citation templates. It also throws off the various tools we have to understand authorship of a page. Controversial subject, I know, but sometimes it's useful to take a look at the xtools page statistics in order to see who's been working on an article, which isn't always apparent just by looking at the most recent history. In this case, someone who simply rescued links that didn't need to be rescued is now listed as the primary author of this page. (Apologies to YoungForever, who was just trying to help here. I don't mean to single you out -- there are a lot of people who use the tool this way.) We also know that some Wikipedians are motivated by making large numbers of contributions, and I'd suggest the ability to quickly make these large, semi-automated edits at any article could also be a motivating factor for some (I've seen people, in a long string of edits, go to dozens of articles just to rescue live links).

TL;DR - If it is desirable to have all archive links in the article, a bot should do it, rather than leave it to arbitrary drive-by rescuing of things that don't need rescuing. If it's not desirable, this option either shouldn't be available to users or we should be clearer in the displayed text for that option and allow reverting if used improperly. If it is sometimes desirable to rescue links that aren't dead, what are those cases? — Rhododendrites talk \\ 14:27, 23 April 2021 (UTC)[reply]

I agree it shouldn't be done arbitrarily. It should be a step for a practice like in the final preparation for a GA/FA and subsequent maintenance once that's been achieved. (eg once 90% of the refs have archive-url's, bot-archiving the rest is not a problem). I can also see it being done for a topic where the bulk of the sourcing does exist only from web pages, such as many current event articles, but that should be some time well after the article is created where the possibility of link-rot may arise - at least if not more than a year out from creation, not in that first year for certain. --Masem (t) 14:43, 23 April 2021 (UTC)[reply]
@Masem: Just to clarify, when you say I can also see it being done where the bulk of the sourcing does exist only from web pages, are you saying that archiving those links is what should be done so that if one dies an archive can be added semi-automatically? Or that all of those links should be added directly to the article preemptively in addition to being archived by IABot off-wiki? IABot is archiving/storing them whether we use that interface or not. The question is when to move the archive links into the article text. — Rhododendrites talk \\ 14:51, 23 April 2021 (UTC)[reply]
Does the archive bot actually make the archives as it runs, even when you do not check that box? I was under the impression that it did not AManWithNoPlan (talk) 15:02, 23 April 2021 (UTC)[reply]
I'm talking about when they are added to the wikipage. We do want the backgrounding of Archive links to happen regardless, I feel, but adding those to Wikipages is where the problem lies and should only be done for polishing purposes (GA/FA) or if the article is heavily reliant on online sourcing. --Masem (t) 15:04, 23 April 2021 (UTC)[reply]
If it is desirable to have all archive links in the article, a bot should do it, rather than leave it to arbitrary drive-by rescuing of things that don't need rescuing. Rhododendrites, I agree with that. And there is another reason to add archive links: WP:EVADEGDPR. By the way, when it comes to the concern of longer wikitext (never really bothered me), this could be reduced significantly by adjusting templates. The citation template on Dutch Wiktionary for example requires no archive date and allows omitting the live URL. — Alexis Jazz (talk or ping me) 15:05, 23 April 2021 (UTC)[reply]
Years ago my proposal to automate the archive-date (based on parsing the archive-url of common archive sites) was rejected. Can't find it in the archives at the moment. I generally support reducing redundancy among fields. However, I don't support removing the url if there is an archive-url, because it makes it more confusing to scan for specific refs or update the ("where the hell is the URL itself? Oh right, it's encoded as part of another URL in a different field."). DMacks (talk) 15:57, 23 April 2021 (UTC)[reply]
DMacks, on Dutch Wiktionary it isn't common to omit live URL either and if specified the entered URL will be used. The template just doesn't make a fuss about omitting the URL. I'm not really sure if structurally omitting the live URL would be a good idea, but I wanted to mention that technically it's possible. — Alexis Jazz (talk or ping me) 17:36, 23 April 2021 (UTC)[reply]
Thanks for explaining the origin of these edits. The term "rescuing" on my watchlist kept confusing me when links were all live (it's not clear that there is any bad situation that is being remedied). DMacks (talk) 15:29, 23 April 2021 (UTC)[reply]
100% agree with OP. I used to make this mistake when I first got here: I went about to articles, checked the optional box and added all the archive links. I thought this was archiving the links. Someone at some point set me straight, and now I realize this adds a lot of unnecessary bloat to articles. It also messes up authorship stats. I am listed as a main author of Alexandria Ocasio-Cortez and Yellow vests movement but it's only because I added like 40k of archive links with one click. That optional checkbox should at least have a warning if not removed or moved somewhere else. Levivich harass/hound 16:57, 23 April 2021 (UTC)[reply]
I don't really use the IABot that much. I only used it when I come across a canceled TV series that ended already, a miniseries (only 1 season) ended already, dead person, or film that has been out for a while as the urls of the articles may not work or updated with information that may not be relevant to the articles anymore. I didn't think it is a big issue to add archive urls to live links as I seen a lot of veteran editors using the IABot to do that as well. — YoungForever(talk) 19:43, 23 April 2021 (UTC)[reply]
Assuming the information at WP:EVADEGDPR is true, I support editors (or bots) adding archive links to anything already archived on the Internet Archive (WayBack Machine) website, so long as bots are not doing so without either an editor requesting it for a particular article, or because the bot is rescuing other dead links on the articles. I don't really have an opinion one way or the other about a bot doing so for all pages without being asked to, but I wouldn't necessarily oppose it. -bɜ:ʳkənhɪmez (User/say hi!) 01:58, 24 April 2021 (UTC)[reply]

Some comments:

Between the set, adding archive links is categorically to the better. --Izno (talk) 00:15, 25 April 2021 (UTC)[reply]

We are not supposed to worry about *server-side* performance. We can still worry about adding to download and parsing times on the client side ("parsing" refers to any time added by extra parameters to the setting up of data structures that make the mouseover action happen). Fighting link rot by mindlessly adding massive numbers of archive-links doesn't enhance verifiability, when it's helpful to check for better original links (esp. when lost merely due to website reorganization), for availability of more up-to-date sources, and whether sources and text match. I would reserve IABot to, say, one-article-at-a-time usage, for those editors who don't care to learn the extra reference markup (e.g. archive-url, archive-date, url-status). Dhtwiki (talk) 14:53, 25 April 2021 (UTC)[reply]

Is everybody here saying that it's bad to include archive links when you insert a (live) reference? —Naddruf (talk ~ contribs) 17:12, 25 April 2021 (UTC)[reply]

No. We're trying to figure out whether there's consensus to add archive links to live references en masse. I don't think that would affect an individual decision to include an archive link for a particular citation. — Rhododendrites talk \\ 18:21, 25 April 2021 (UTC)[reply]

One might consider augmenting the "Add archives to all non-dead references (Optional)" capability with another option that allows the user to try and selectively add archives to specific references. I'm not sure how frequently this happens, but I have seen some "live" links that have actually died and been replaced by spam. The link is technically "live", so IABot passes over it and says something like, "no changes made" because there are no dead links. Well, I know I actually need to add an archive link to have the correct content, so I can go search the multiple archive sites for my URL, or I can take a shot at adding all archive links, and hope I get the right one. Sure everything else will get an archive link as well, but that's OK, right? Go ahead and do it. Sometimes I will search Wayback and Archive.today, but I'll tend to stop there. It depends on how lazy I'm feeling.
Anyway, this doesn't necessarily solve the proposal, but it might slightly reduce the frequency of using add all archives. -2pou (talk) 17:05, 26 April 2021 (UTC)[reply]

Growth Team en-wiki Trial

Hi all,

The Growth Team have proposed a plan for trialling the new Growth Team features to 2% of new accounts to en-wiki, after various successful trials/rollouts on other projects.

MMiller (WMF) is one of the most community responsive WMF product managers we've ever had the fortune to have, so if interested please go and drop any comments in. Nosebagbear (talk) 23:12, 23 April 2021 (UTC)[reply]

Make page movers eligible to move move-protected pages

I have finally trudged to VPR after running into this twice in as many days and with the fact such RM/TRs frequently stay open for long periods, as the area is patrolled by more PMRs than admins. I cannot consider a good reason not to have this be the case; there aren't many page movers, it's a fairly guarded perm, and any chronically move-warring PMR can get the bit yanked quickly. A surprising number of pages are under indef sysop move protection, which seems to be almost never reviewed (I ran into one where it was placed over a small-scale move war from 2008), and it's fairly inhibiting to PMRs to not be able to perform a significant subset of the page moves we were given the right to do at all. Vaticidalprophet 08:52, 26 April 2021 (UTC)[reply]

  • @Xaosflux: how would page-movers be able to move template-protected or fully-protected pages? They still need to be able to edit them to move them, which they would be unable to. I think you might be misunderstanding the proposal scope here. Elli (talk | contribs) 23:49, 26 April 2021 (UTC)[reply]
    @Elli: well part of the problem is that the proposal is quite poorly presented. There is no definition to make page movers eligible to move move-protected pages - for example they already CAN do this, provided the move-protection is a level they can move; it appears to be suggesting that some new technology is invented to allow this group to have a new permission that allows moving a page regardless of its protection level. — xaosflux Talk 00:00, 27 April 2021 (UTC)[reply]
    @Xaosflux: I'm pretty sure the proposal is to just make move-protection not apply to page movers entirely - any other editing protection would still apply. I don't see how this is really that hard to implement technologically. Elli (talk | contribs) 00:24, 27 April 2021 (UTC)[reply]

People can't create a new article on English Wikipedia

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.

Hi Wikipedia!

People can't create a new article on English Wikipedia. It doesn't appear the page that contains the link "Start the article wizard" but appears: The page x doesn't exist. You can create as a draft..."

We want to return the option for article wizard page or if not, the drafts created to have an option "Submit the draft for a review" in order to review the draft and move or not on the main articles, which this option doesn't exist on created drafts.

Thanks! — Preceding unsigned comment added by NSHPUZA (talkcontribs) 11:30, 27 April 2021 (UTC)[reply]

Once your account has been autoconfirmed (four days old and 10 mainspace edits) you can create pages in the main space. This minor throttling feature is in place to head off unregistered (IP address) and newly registered accounts from abusing the ability to create articles, which can be a cleanup nightmare. Once your account has been autoconfirmed, you can create all the articles you want; the article wizard is an optional process, as is the "Draft and review" process. Newer users (and even autoconfirmed ones) are steered through the draft-and-review process as a means to discourage the creation of a new article that is likely to be quickly deleted, often without explanation. However, once you are autoconfirmed, there is no technical barrier to creating new articles. I would recommend you don't until you learn a little bit about what makes a worthwhile Wikipedia article (see WP:42 and WP:YFA for a short, and long, version of that), but once you reach that 10 edits/4 days threshold, you'll be fine. --Jayron32 14:45, 27 April 2021 (UTC)[reply]
@NSHPUZA: Access to the article wizard should be available on any red linked page you are trying to create. For example, click here: Red link demo for NSHPUZA, and at the top of the page (Source Editor) or in the popup notice window (Visual Editor and 2017 Wikitext Editor/New wikitext mode), you should see this message in bold that sends you to the Article Wizard:
Just click the Article wizard link, and it will run you through what it looks like you are seeking. -2pou (talk) 17:14, 27 April 2021 (UTC)[reply]
I just checked NSHPUZA's contributions, and this post was tagged "(Tags: Mobile edit, Mobile web edit)". I tested a red link on my phone (in Mobile View), and it does not provide the same access to the article wizard. Perhaps that is the request? I have no idea how easy it would be to try and create an article from the wizard in mobile view, but that may be the root of the question. -2pou (talk) 17:19, 27 April 2021 (UTC)