Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
 Policy Technical Proposals Idea lab Miscellaneous 

New proposals are discussed here. Before submitting:

« Archives, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158

Descriptive IP Welcomes[edit]

Hello all, I'd like to copy the 'problem user welcome templates' in twinkle and make versions that can be used for IP users as they're quite limited.

Does anyone have any ideas or want to help on them?

I'd start by copying the user ones to my sandbox then add the needed information about creating accounts etc.

Pinging @Amorymeltzer: so you can advise on adding them to Twinkle. Thanks, RhinosF1(chat)(status)(contribs) 18:30, 11 March 2019 (UTC)

  • RhinosF1, funny you mention that because I literally just created one last night for this exact reason. –MJLTalk 20:24, 11 March 2019 (UTC)
    MJL, I'm happy for anyone to but at some point (tommorow), I'll create a list of welcome templates for users that we have and compare it to IP ones. If you want to start the use User:RhinosF1/Welcome/list to create it. RhinosF1(chat)(status)(contribs) 20:27, 11 March 2019 (UTC)
  • I've started a project page at User:RhinosF1/Welcome RhinosF1(chat)(status)(contribs) 20:33, 11 March 2019 (UTC)
    plus Added to page. –MJLTalk 21:26, 11 March 2019 (UTC)
    MJL - I've changed to a Templateable so we can track templates easier that need to be done. RhinosF1(chat)(status)(contribs) 21:34, 11 March 2019 (UTC)
  • I'm sure that any such welcome message, whether to a registered or unregistered editor, would be much more likely to have its desired effect if it was actually written by a human being addressing the particular concerns about the edit in question rather than done by template. Phil Bridger (talk) 21:02, 11 March 2019 (UTC)
    There's some truth there but a template also contains carefully crafted prose which convey a message better than I have the time or skill to do every time I use it. Often I expand the template then customise its output to get the best of both worlds. Could we do anything to make that process easier and more attractive? Certes (talk) 21:19, 11 March 2019 (UTC)
    WP:TW allows use to add custom messages at the end Certes. RhinosF1(chat)(status)(contribs) 21:23, 11 March 2019 (UTC)

I've now looked through the templates, I'd appreciate if anyone offered to help out with them. There's 2 Registered user ones missing and 8 IP ones to create and there's also 8 templates that exisit but are not in twinkle per my list RhinosF1(chat)(status)(contribs) 16:40, 12 March 2019 (UTC)

Hello, When creating User:RhinosF1/Welcome/list for the above thread, I noticed an inconsistency in naming formats for the registered user welcome templates. Which format is preferred? How should they be capitalised? - answer poll using both letter and number RhinosF1(chat)(status)(contribs) 17:04, 12 March 2019 (UTC)

  • A) all one word no spaces - Example: welcomelaws
  • B) Dashes between words -Example: welcome-laws
  • C) Spaces in between words- Example: welcome laws
  • 1) Capital at start
  • 2) Each Word Capitalised
  • 3) all lowercase

Poll[edit]

  • B and 1 - To match anon ones and seems to be most used. Excluding for abbreviations (like COI) where they should remain capitalised. RhinosF1(chat)(status)(contribs) 17:09, 12 March 2019 (UTC)
  • D and 4 - allow all. There is no need for consistency. It’s the links that matter, not the style in which they are formatted. Blueboar (talk) 18:57, 12 March 2019 (UTC)
    Blueboar, I'm mainly suggesting this so they're easy to remember and find. RhinosF1(chat)(status)(contribs) 19:03, 12 March 2019 (UTC)
  • Oppose We do not need to vote on this. Natureium (talk) 20:32, 12 March 2019 (UTC)
    Natureium, As I said above having consistency will make it easier to locate templates. RhinosF1(chat)(status)(contribs) 20:57, 12 March 2019 (UTC)
  • B3. This is actually quite helpful as it would end the guessing game around welcome templates when using them manually. As a technical matter 1 and 3 are the same though. —pythoncoder (talk | contribs) 13:29, 12 April 2019 (UTC)

Discussion (Descriptive IP Welcomes)[edit]

Why do we need separate templates for IP editors and registered users? Couldn't the template code itself detect where it is being used? Let's not create a copy of each template if there is a more elegant solution. Updating copies of essentially the same content is tedious and error-prone. ~ ToBeFree (talk) 02:52, 17 March 2019 (UTC)

Article on ages which famous people would be today?[edit]

Someone noted to me today that if Bruce Lee had not died age 32 he’d be 78 now. Would it be okay to have an article listing ages which famous people who died young would be today? Seem to recall seeing this sort of thing reported in the news from time to time. And such an article in a book of lists. Hyperbolick (talk) 16:11, 1 April 2019 (UTC)

Most of the coverage is trivial. I wouldn't have an article on such a list. --Izno (talk) 16:20, 1 April 2019 (UTC)

Because the people may still be alive, this was done at List of people who disappeared mysteriously: post-1970 - the code to keep the ages (somewhat) accurate may be of interest, in case you want to create a list somewhere of favorite people. I don't think it should be a mainspace article. -- GreenC 16:54, 1 April 2019 (UTC)

We haven’t even got an article on dying young. Hyperbolick (talk) 16:57, 1 April 2019 (UTC)
Would that include everyone person for whom we have an article? A list full of thousands of names? It seems a terrible idea and I don't see how it could meet our notability criteria. Doug Weller talk 10:52, 2 April 2019 (UTC)
Ponce de León would be 397 (and may well be). Randy Kryn (talk) 03:22, 3 April 2019 (UTC)
I would agree this wouldn't seem very appropriate for an article; as @Doug Weller: notes, the numbers are potentially very large. For what it's worth, there are approximately 10-11,000 people who a) have English Wikipedia articles; b) were born in or after 1940 (so would be no older than 80 now); c) died at 40 or younger. Even skimming that down to just "particularly notable" people, however defined, would be a lot... Andrew Gray (talk) 18:37, 2 April 2019 (UTC)
Without commenting on the value or otherwise of the concept, from a technical standpoint it could be implemented via collapsible multi-column lists by birth year? Anothersignalman (talk) 03:11, 3 April 2019 (UTC)
How old would Methuselah be now? --Redrose64 🌹 (talk) 18:49, 4 April 2019 (UTC)
  • OPPOSE anything like this. It's trivia, trivial, and non-encyclopedic. GenQuest "Talk to Me" 09:38, 4 April 2019 (UTC)
  • We already have the "on this day" section of the mainpage. I don't see a problem in having some birth centenaries there. ϢereSpielChequers 10:59, 4 April 2019 (UTC)
  • Oppose per WP:INDISCRIMINATE. MarnetteD|Talk 18:51, 4 April 2019 (UTC)
  • Oppose as irrelevant to the goal of the encyclopaedia. —A little blue Bori v^_^v Bori! 00:19, 6 April 2019 (UTC)
  • I found this idea to be very weird and strange in many respects. It should probably be archived at Wikipedia:Unusual requests. – Ammarpad (talk) 16:04, 6 April 2019 (UTC)
  • Oppose for dead people - your age is only relevant in any way during your lifetime. The "age" of a dead person at any time after his/her death is trivia, not encyclopedic. Current ages should only be reported for people who we consider to possibly be alive. עוד מישהו Od Mishehu 12:28, 14 April 2019 (UTC)
  • Oppose Quite trivial, IMO. John M Wolfson (talk) 01:54, 19 April 2019 (UTC)

Bring back Wikipedia:Featured portals?[edit]

Should we Bring back Wikipedia:Featured portals that ended in 2017? as I think it would be a good idea to feature portals that are high quality and it may help improve the quality of portals Abote2 (talk) 11:23, 7 April 2019 (UTC)

  • I would be open to this idea as a motivation for people to improve portals. See Wikipedia_talk:Featured_portals#Tagged_as_historical for why it was marked historical; it seems this bold tagging was not without opposition but no formal proposal was made. —pythoncoder (talk | contribs) 13:03, 8 April 2019 (UTC)
  • If you can demonstrate that there are significant numbers of portals that meet the Featured Portal Criteria and are not already listed at Wikipedia:Featured portals I would support re-starting the project. However, the project was moribund when closed in 2017; as explained then, it had been a year since any new FP was proposed; which means that at this point it will have been 3 years since any portal has met the standards. That's a long-ass time. Also, I will note, that while undiscussed, the lack of objection in the 2 years since it happened speaks volumes. If it went away and no one noticed that means it was a good decision, if it went away, people noticed, but no one cared, that also means it was a good decision. I think if we revisit the FP concept, we would need to demonstrate first that there are unpromoted portals that need to be added to the list. --Jayron32 14:12, 8 April 2019 (UTC)
  • Rather pro froma to so-called 'end it'. It's like 'ending' other extra things on Wikipedia, either a group decides they want to do it or group does not (see, eg. Signpost where the only thing that keeps it going is some people want to do it). If there is a group, there is nothing preventing them from saying, such and such portal meets such and such criteria. Alanscottwalker (talk) 15:22, 8 April 2019 (UTC)
    • Honestly I’m amazed the Signpost is still alive (and that’s coming from someone who’s been writing it for a year now). I suppose you’re right—where there’s a will, there’s a way. —pythoncoder (talk | contribs) 16:30, 8 April 2019 (UTC)
  • Perhaps this proposal should be put on hold while the whole TTH business is still getting sorted. John M Wolfson (talk) 01:55, 19 April 2019 (UTC)

Display links to core content policies in editing interface[edit]

I think the editing interface should display a reminder about our core content policies on mainspace and draftspace articles. The editing notice MediaWiki:Editpage-head-copy-warn already has a reminder about verifiability, but (1) doesn't link to WP:Verifiability itself and (2) omits the other key content policies. As a result, it's easy to forget that all three content policies apply and should be interpreted together, and that they are the core policies. As I have suggested here, this could be achieved by adding a banner to Template:Editnotices/Namespace/Main.

Do you agree that a core content policies banner should be displayed on all mainspace and draftspace pages? If so, what should the banner look like? Qzekrom 💬 theythem 19:54, 10 April 2019 (UTC)

Banner blindness already prevents most casual editors from reading them. The non-casual editors already know them. --Izno (talk) 20:46, 10 April 2019 (UTC)

Proposal: remove "reupload-own" from non-confirmed users[edit]

The proposer has withdrawn this. —pythoncoder (talk | contribs) 13:31, 12 April 2019 (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'd like to proposal that non-confirmed users not have the reupload-own right. This right allows users to Overwrite existing files uploaded by oneself. It should be removed because non-confirmed users don't have the upload right. It is useless to be able to overwrite files uploaded by oneself if no such files can be uploaded. Thoughts? --DannyS712 (talk) 20:36, 11 April 2019 (UTC)

And this matters because ... * Pppery * survives 21:38, 11 April 2019 (UTC)
... because its confusing to be have a right that you will never be able to use. --DannyS712 (talk) 21:51, 11 April 2019 (UTC)
@DannyS712: - can you demonstrate some cases where new editors have found this issue confusing? I seriously doubt more than a handful ever spot they have the right while still unconfirmed. This seems like a solution in search of an issue. Nosebagbear (talk) 22:35, 11 April 2019 (UTC)
@Nosebagbear: I mean I was confused when I first joined (I've used mediawiki software elsewhere before, so when I couldn't create a page in the main namespace I went to go look at the rights I had and was confused). I get your point though - this was just a suggestion, and it'll probably only impact a few users. --DannyS712 (talk) 22:37, 11 April 2019 (UTC)
No, this isn't worth touching the configuration for. And there is an existing use case for it:
  1. Non confirmed user wants to upload something
  2. Someone manually confirms the user
  3. The manual confirmation is removed or expires, but the user hasn't been autoconfirmed yet
  4. The user wants to refresh their own upload
So it could be possible to have this rare edge case used, and the configuration causes no issues how it is. — xaosflux Talk 22:39, 11 April 2019 (UTC)
Okay. I see that there is a benefit to this right that I hadn't realized, so nevermind. --DannyS712 (talk) 22:43, 11 April 2019 (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.

Wikidata links for non-notable people[edit]

I've proposed that we limit the use of the {{Interlanguage link}} template for creating Wikidata-only links for non-notable people. If you have an opinion, please express it at Template talk:Interlanguage link#Lots of wikidata links for non-notable people (not here). Thanks! Kaldari (talk) 01:30, 13 April 2019 (UTC)

Proposal: Halt the mass deletion of non-spam portals and focus on achieving consensus on portal guidelines[edit]

In response to WP:ENDPORTALS the community demonstrated that "there exists a strong consensus against deleting or even deprecating portals at this time." Despite this, there are currently dozens of portals being put up for deletion with repetitive, often quite subjective and thin justification at Wikipedia:Miscellany for deletion which seems to fly in the face of the community's intent for portals. These are not the 1500 or so portals, mass-created by The Transhumanist that are subject to an ongoing discussion, but include portals manually created and manually maintained by dedicated editors working under the relevant Wiki project. The current portal guidelines are not useful since they have been amended and counter-amended without consensus by editors with strong views for and against.

My proposal is that, having agreed in principle to keep portals, the community should halt further deletion of portals (with the exception of those mass-created by TTH for which agreement appears likely) and, instead, seeks consensus on portal guidelines including those covering the approval process and criteria for new portals, maintenance standards and criteria for deletion (which may just be the inverse of criteria for creation). Bermicourt (talk) 08:14, 14 April 2019 (UTC)

Please identify a couple of portals that are believed worth saving and where the portals are or have been at MfD. Johnuniq (talk) 09:49, 14 April 2019 (UTC)
First, there is no mass deletion of older portals. There is some long overdue cleanup going on of old narrow scope and/or unmaintained portals
Second, he is annoyed a couple of his German region portals were brought to MfD and is now posting various places to stop the clean up.
Check out WP:MFD So far over 1100 portals have been deleted and around 1900 are being discussed for deletion now. The vast majority are the mass created variety usually based on a nav box, which offer no benefits and many disadvantages to the reader who is better served by the article.
The MFDs are applying the very permissive existing WP:POG that the portal spammers modified but ignored. While WP:ENDPORTALS did not delete the entire space there was a pretty clear message that clean up was required. Instead of cleanup on the 1400+ portals they had, the WikiProject fought deletion of even the worst ones. Then they added 4200 more portals on all kinds of random and WP:POG breaching topics. Whenever some portal was brought for discussion the portal fans cried the same story "we need time to develop new guidelines". That story no longer holds water. Anyone is welcome to propose an RFC for new guideline but I suggest it tighten the existing guidelines given the way the MFDs are going. Anyone is welcome to check out the completed debates under Feb, March and April here [1] Legacypac (talk) 11:55, 14 April 2019 (UTC)
  • Here is a shortlist of legacy portals up for deletion by in the last 36 hours:
Wikipedia:Miscellany for deletion/Portal:Halo (2nd nomination)
Wikipedia:Miscellany for deletion/Portal:Stamford (2nd nomination)
Wikipedia:Miscellany for deletion/Portal:Prehistory of Antarctica (3rd nomination)
Wikipedia:Miscellany for deletion/Portal:Prehistory of North America
Wikipedia:Miscellany for deletion/Portal:The Beach Boys
Wikipedia:Miscellany for deletion/Portal:Prehistory of South America
Wikipedia:Miscellany for deletion/Portal:Mitt Romney
Wikipedia:Miscellany for deletion/Portal:Glee
Wikipedia:Miscellany for deletion/Portal:Green Day
  • No. There's still a lot of crud in portal namespace that needs to go. CoolSkittle (talk) 16:47, 14 April 2019 (UTC)

It's a bit disconcerting for me to read that User:Legacypac doesn't think there's a mass deletion going on. That user has put by my count about 84 portals up for deletion themselves--since Friday. That user is historically opposed to all portals ("Portals are so 15 years ago, the internet moved on a long time ago.") so he or she is nominating them all, one by one. Other users are also nominating large numbers too: for example User:BrownHairedGirl ("My ideal solution would be too keep about 20 major portals(art/science/etc plus continents), and delete the rest. But given the unhelpful binary nature of this proposal, I'd prefer outright deletion to either keeping them all or to having 1500 MfD debates."). These users didn't get their way in the RFC so now they seem to be using this moment to accomplish their objective. BusterD (talk) 14:37, 14 April 2019 (UTC)

Sorry I've been falling down on the job. Spent time with the family this weekend. I'll do some more bundles soon. Rationals for deletion are posted on each nom - please go vote there. Legacypac (talk) 19:26, 14 April 2019 (UTC)
  • Meanwhile, over at WikiProject:Portals, we're having some discussions about reverting the automation and trying to figure out a way to keep many of these. We don't normally delete pagespace because it's a stub, isn't maintained or is getting low page views. We expect that we have adequate server space for things to move forward eventually. I feel like these mass deletions of legacy portals are being forced down our throats by editors largely opposed to the concept of portals. BusterD (talk) 14:47, 14 April 2019 (UTC)
Calm down, @BusterD. 8 portals out of the ~1500 which predate the portalspamning is not mass deletion. --BrownHairedGirl (talk) • (contribs) 14:43, 14 April 2019 (UTC)
I am completely calm. I offered a shortlist, not an exhaustive one. On the other hand one editor nominating 84 pages for deletion since Friday would be considered way out of line for normal AfD, and that's not counting the dozens BrownHairedGirl has put up in this recent period. There's a mass deletion going on. 184 items up for deletion as of this datestamp, mostly legacy portals. BusterD (talk) 14:54, 14 April 2019 (UTC)
@BusterD - I can't track your numbers. We had about 1899 portals up for deletion last I looked and only a few were old titles, many of them restarted with nothing from the old portal preserved.You can see what is up for deletion at Category:MFD Legacypac (talk) 19:26, 14 April 2019 (UTC)
@BusterD, for the last year, the portals project did nothing to even stop the flood of portalspam unleashed by The Transhumanist. Several other editors also created significant numbers of the useless automated portals.
Project members and outsiders who dissented were brushed aside and/or shouted down. The whole thing spiralled until it escalated into a shitstorm.
In the aftermath of that, several editors have begun doing what the portals project itself should have been doing: opening MFD discussions to delete the spam. Overwhelmingly, the outcome is to delete them. And it also notable that the work of both analysis and MFD nomination is overwhelmingly being done by editors who were not part of the Portals Project.
Along the way, the scrutiny is casting more eyes on many other portals, which predate the spam. It turns out that as noted at the ENDPORTALS RFC, many of the pre-spam portals are abysmal: narrow topics, unused, ill-maintained, all contrary to the long-term guidance at WP:POG, that portals should be about "broad subject areas, which are likely to attract large numbers of interested readers and portal maintainers". So those are now being nominated for deletion too, and unsurprisingly many of them are being deleted.
I have not changed my view expressed at ENDPORTALS that there should be many fewer portals. However, I accept that the delete-all proposal has been clearly rejected, and the community has not made a decision on whether to adopt my goal of having only few dozen major portals. So I am not trying to pre-empt any discussion on that. I am just working within the existing guidance at WP:POG.
The removal of portals which do not meet that core WP:PG requirement should have been an ongoing maintenance task of the Portal Project. Instead, the crud was left to pile up and rot, with the inevitable result that it is now coming under scrutiny by outsiders ... and years of backlog of crud is finally being tackled.
BusterD refers to the the dozens BrownHairedGirl has put up in this recent period, i.e. nominated at MFD. So I have checked through my WP+space contribs list to create a full list of all my MFD nominations in the past 7 days. Note how they are all carefully researched; some of them took hours to prepare.
BHG's MFD nominations in the last 7 days
aka The Outrage Which hath caused much grief and despair unto User:BusterD
Sat 13 April
Fri 12 April
Wed 10 April
Tue 9 April
Sun 7 April
So come on, BusterD. Please tell me which of those nominations is so outrageous that you have to come to a drama board to complain about it?
And then tell me what you and the other portals fans are doing to clean up the mountain of portalspam by TTH and his assistants? Or to clear out the pile of abandoned unused, narrow-topic portals which has built up over years of neglect the portals project?
It's long past time for the portals fans to stop whining and sniping and maligning and obstructing, and to actually help in the cleanup. --BrownHairedGirl (talk) • (contribs) 15:54, 14 April 2019 (UTC)

Please remember that nominating a page for discussion at MFD is not an actual deletion... it is only a discussion about whether the page should be deleted. If you don’t think a nominated page should be deleted, go to MFD and explain why you feel that way. Blueboar (talk) 15:28, 14 April 2019 (UTC)

I'm not interested in discussing the merits of individual nominations on this talk page. Like the OP, I am interested in the remarkable number of portals nominated in the recent period. So many and so quickly that a reasonable conversation can't be had by editors with any sort of life AFK. This resembles a bum's rush and gives the appearance of coordination. I think the OP makes a valid point. BusterD (talk) 16:05, 14 April 2019 (UTC)
@On the contrary, BusterD, you specifically singled me out as a miscreant creator of too many MFDs. I have shown above why I believe that is false: please have to courtesy to read and respond to m]y reply.
You have now escalated to an unsubstantiated allegation of co-ordination. All the discussions I have had about this have been on Wikipedia, apart from the harassing emails I received a month ago from SMcC.
I have posted at WP:AN, WP:ANI, at WP:WPPORT, and the only userpage discussions I have participated in have been at User talk:Legacypac#Please_stop_adding_portal_pages_to_MfD_nominations_opened_by_others and some sections below. There is no plot.
I am getting very sick of all these bad faith, unfounded allegations from portal fans. Instead of helping tackle the real substantive problems, they are making unevidenced smears like this one, or telling outright lies such as the one I rebutted today at an MFD[2].
It's long past time for BusterD and others to accept that it is very easy for any editor to see the widespread problems in portalspace, and to understand that no conspiracy is needed for editors to apply basic policies and guidelines and help in the cleanup. -BrownHairedGirl (talk) • (contribs) 16:34, 14 April 2019 (UTC)
I am therefore preparing the second batch. I am still list-naming, but it looks likely to be over 1100 pages. That's less than the 1,308 in the second set which in added to the first nomination and the withdrew, because some of the set have already been taken to MFD. --BrownHairedGirl (talk) • (contribs) 18:57, 14 April 2019 (UTC)

Oppose this proposal. The key words in the WP:ENDPORTALS closing statement are at this time. We are no longer at this time: this is a new time, and between then and now no one, in my opinion, did anything that improved the set of portals: no substantive changes to the guideline, no work on community consensus building, nothing. These deletion discussions are not WP:ENDPORT2; they are topic-by-topic, open, guideline-based discussions, a good number of which have closed as keep. I also object to "These users didn't get their way in the RFC so now they seem to be using this moment to accomplish their objective"; seems like a failure to WP:AGF, and I for one did not participate in the RfC, don't yet believe Portals should be ended, and resent being tarred with any brush. UnitedStatesian (talk) 00:29, 15 April 2019 (UTC)

    • Comment. Who says a so-called "new time" has started? Just you? And, as you yourself say your WP:POV is that "no one did anything to improve portals" but that flies in the face of reality. A huge amount of work was done to improve portals - new tools were created and new systems of monitoring portals were developed. Unfortunately the good was balanced by the bad; along with their enthusiasm to improve portals, the portaleers also discovered they could create portals with no human intervention, so hundreds of low-quality unhelpful portals were created. That had to be halted and I have supported that. With regard to your comment that there "no work on community consensus building" that's also untrue. One effort that I was involved in was work with @BrownHairedGirl: to try and frame a question that sought consensus from the community about portal numbers and standards. That didn't in the end materialise, but there was a will from editors representing a spectrum of views to take this forward in a constructive way. As for the deletion discussion being guideline based, the guidelines are past it; WP:ENDPORTALS demonstrated that. In any case, they are far too vague - allowing editors to choose what "broad subject areas" means. They also ignore valid points raised by editors during the discussion that portals are not just another article that is justified by pageviews - firstly they are not in mainspace and secondly if that were the sole justification for them then half the articles on Wikipedia wouldn't qualify either. So if you want good, balanced coverage of a topic, properly curated portals are a tremendous aid. The reason there are so many blue links on decent, manually maintained portals is that editors actively use them to create many of the articles. In my case I've created over 5,000 new articles on Wikipedia and have used portals extensively to shape priorities and achieve balanced coverage of a topic. By contrast, the recent mass of auto-created portals doesn't meet that remit at all and I am a strong supporter of deleting them. They are of limited utility and only do a disservice to other, decently created and maintained portals, which are earning their pay. Of course, there's always more to do, but we don't want to throw out the baby with the bathwater. Yes, bin the auto-created portals that took no effort to create, but let's not wilfully destroy human-maintained portals that serve a purpose while there is still no agreement on what constitutes an acceptable portal. HTH.Bermicourt (talk) 16:53, 16 April 2019 (UTC)
  • Comment I created something at User:John M Wolfson/Portals for Creation a while back, and while it didn't seem to generate much buzz maybe it might help in the future. John M Wolfson (talk) 02:01, 19 April 2019 (UTC)

The 'WikiReporter Barnstar'[edit]

Hi All,

I believe there should be a specific barnstar for those who do excellent reporting on a live event. I understand the a minor barnstar is a de facto form of this however I believe that this is worthy of its own reward. The logo could be something along the lines of a red barnstar saying 'BREAKING NEWS'.

Its just an idea but I think it's worth it.

Thanks, Muffington (talk) 19:39, 15 April 2019 (UTC)

There is {{The Current Events Barnstar}}, although I don't think it's great that it uses the Wikinews logo. the wub "?!" 01:21, 18 April 2019 (UTC)

Wikipedia African Month[edit]

Hello,

For information, a Wikipedia African Month was launched on Wikipedia in French. If you also want to organize this event, I suggest you to contact @Ле Лой: for the tool (tools.wmflabs) and @Furfur: for the logo. In addition, we have set the African month in May for the Africa Day.

Thank you & best wishes, 16:23, 16 April 2019 (UTC)~. — Preceding unsigned comment added by Aabbccddeeffabcdef (talkcontribs) 16:23, 16 April 2019 (UTC)

Ping Ле Лой and Furfur --DannyS712 (talk) 23:44, 16 April 2019 (UTC)

Rewrite of Template:Bar chart[edit]

I am proposing to upgrade the template Bar chart, to use an Lua script at Module:Bar chart. The script uses graphs instead of the divs which are used now. The script gets rid of data limitations, enabling users to use as many bars as they like. The module is coded to work in the same way as the old template. I have changed the sandbox to use the template. Testcases can be seen at Template:Bar chart/testcases.

Template:Bar chart/bar will become obsolete with this change. I am proposing this here, since the talk page of the template does not have enough watchers.--Snaevar (talk) 09:49, 17 April 2019 (UTC)

You might like to post at WT:WikiProject Templates or WT:Lua (the latter if wanting help with the module). Have you seen Module:Chart? Johnuniq (talk) 10:54, 17 April 2019 (UTC)
... and Module:Graph (used by Template:Graph:Chart). It would make more sense to merge some of those modules instead of creating even more. * Pppery * has returned 12:40, 17 April 2019 (UTC)

Further discussion of recent RfC on organisation vs organization[edit]

This RfC has been reopened; further input should take place at >>>the original point of discussion<<<
Resolved: Reopened.

I note the recently closed "RfC" on organization vs organisation. I dispute this as a settled Wikipedia policy. There has been minimal promotion of this discussion which has a limited number of editors commenting on what can be a huge change. It is being now used as a settled policy, where it suddenly adversely affects a lot of wikipedia, and strikes me as potentially thought of cultural vandalism. It feels like someone has tried to sneak quite a major change through the back door, and that if this needs to be done properly we should just poll every active editor on wikipedia for usage. My personal preference is to have no standardisation, however forcing everyone to use "-ize", is not fair on a lot (and perhaps the majority) of English users where "-ise" is the proper variant. I have cross-posted to the Village pump policy section. - Master Of Ninja (talk) 15:36, 17 April 2019 (UTC)

This was advertised with a central notice, so I don't know what further promotion you had in mind. And it is only applicable to the names of categories, not to article content, so statements such as "adversely affects a lot of wikipedia", "cultural vandalism", "sneak quite a major change through the back door" and 'forcing everyone to use "-ize"' are hyperbole - this is a change in one small area that most people won't even notice. Phil Bridger (talk) 15:53, 17 April 2019 (UTC)
The discussion ran for two weeks, was centrally advertised where all such discussions occurred, and had the participation of in excess of 40 people, which is quite high for such a discussion. It also wasn't closed until 2 days after the last comment, so the discussion had gone moribund, and at the time had little further interest. It also is narrowly defined. Your characterisation that "it forces everyone to use "-ize"," is not an accurate characterization, and so I don't feel it needs any further defense against your attacks. --Jayron32 15:59, 17 April 2019 (UTC)
It's a bonkers change, and fundamentally at odds with WP:ENGVAR. I agree that this should have been far more widely advertised. Number 57 16:02, 17 April 2019 (UTC)
Where? Phil Bridger (talk) 16:05, 17 April 2019 (UTC)
Perhaps WikiProjects covering articles where "organisation" is used in category trees, or at least on the national WikiProjects of countries where "organisation" is the common spelling? Not so long ago I was forced to advertise a proposed change to election/referendum article naming format on ALL national WikiProject pages when someone objected to the original outcome of the RfC, claiming it hadn't been advertised widely enough. Number 57 16:14, 17 April 2019 (UTC)
I'd agree with this that I don't think it was advertised widely enough. - Master Of Ninja (talk) 16:52, 17 April 2019 (UTC)
Where was it centrally advertised? The first time I saw it was that a large number of categories were trying to get speedy moves via this change. And I don't think it is a change in a small area that most people won't notice - it's very noticeable. - Master Of Ninja (talk) 16:52, 17 April 2019 (UTC)
It was centrally advertised using the system that we have for such centralised notices. Phil Bridger (talk) 17:05, 17 April 2019 (UTC)
This RFC only affects category naming, not article content. Since 99% of editors and 99.99999% of readers will never even be aware of it, describing it as "a huge change" and "cultural vandalism" is ridiculous hyperbole. Get over it. ‑ Iridescent 16:11, 17 April 2019 (UTC)
Perhaps hyperbole, however I think most people will know well that category naming will then eventually be moved over to the articles in a case of "mission creep" for lack of a better term. I don't think "getting over it" is helpful - it is a noticeable change that I object to, and it feels like that it wasn't advertised widely so it could get pushed through. - Master Of Ninja (talk) 16:52, 17 April 2019 (UTC)
  • I for one look at my watchlist several times on a typical day, and the fact that this proposal was being discussed slipped past me. I would use "organization" myself, but I think it's bizarre that the community would think it appropriate to micro-legislate an exception to WP:ENGVAR for this single word (and only in the context of categories). I would be in favor of re-opening the discussion and making sure this is really what people want to do. --Trovatore (talk) 18:17, 17 April 2019 (UTC)
  • This discussion was advertised in the place that has since 2005 been "used to draw attention to discussions regarding policies, guidelines or other matters that have a wide impact and on which a broad consensus is needed". If you, and others, don't look there then that is your problem, not Wikipedia's. And, as User:Jayron32 said, over 40 people participated in the discussion. If you want to influence such things then you should participate in the discussion, not whinge afterwards when it doesn't produce the result that you want. Watchlist notices are for "announcements, such as for ArbCom elections, etc.", not discussions, per Wikipedia:Centralized discussion. Phil Bridger (talk) 19:12, 17 April 2019 (UTC)
How arrogant! It's absolutely Wikipedia's job to ensure discussions are drawn to the attention of interested parties and if it fails to, pointing it out is not 'whingeing'. This debate certainly wasn't well advertised for such a sweeping change; the first I knew of it was when category names started changing. It totally flies in the face of WP:ENGVAR and is another step on the way to a Wikipedia that doesn't reflect the real world. Bermicourt (talk) 19:58, 17 April 2019 (UTC)
How is putting a discussion on a central notice not ensuring "discussions are drawn to the attention of interested parties"? It's the highest level of advertising that we have. Phil Bridger (talk) 20:02, 17 April 2019 (UTC)
No it isn't – the highest level is the notifications you get above the watchlist, or notices on multiple WikiProjects. Fewer than 500 editors watch the centralised discussion template, whilst over 1,000 watch the Australia, New Zealand and UK Wikipedian noticeboards (to whom this discussion would have been especially relevant). Number 57 20:21, 17 April 2019 (UTC)
I already explained above, with a link to where it is explained, that watchlist notifications are for something else. And don't just look at how many people watch the template, but look at how many people watch the pages where it is transcluded. I don't usually like the term, because it is usually used by people who want to deny other people privileges that they demand for themselves, but this insistence that people should be personally informed in a non-standard way rather than watch the standard place for centralised discussion strikes me as blatant snowflakery. Phil Bridger (talk) 20:31, 17 April 2019 (UTC)
It doesn't matter how many people watch the page where a template is transcluded as they don't see the changes made to the template. And I don't see how anyone here is insisting that anyone be informed in a non-standard way. Notifying WikiProjects is the most standard way that I'm aware of. The snowflake comment is pathetic and degrades your point. Number 57 20:46, 17 April 2019 (UTC)
Notifying WikiProjects is the standard way of flagging up parochial concerns that may only be of interest to editors in one particular topic area. The standard way to flag general concerns such as this, with a Wikipedia-wide impact, is by a central notice and a village pump discussion, as explained at, once again, Wikipedia:Centralized discussion. I don't see how my snowflake comment is either pathetic or degrading - it illustrates the attitude of people who think they have a right to be informed separately from the long-agreed consensus procedure. Phil Bridger (talk) 21:00, 17 April 2019 (UTC)
I've never heard of village pump or centralized discussion so clearly this is not a well known forum of discussion. The objections to this disastrous proposal should not only be considered for the impact on topics about countries that use -ise, this also adversely affects articles that are not geographically specific. Onetwothreeip (talk) 22:23, 17 April 2019 (UTC)
  • re start, the nomination gives no indication of any notices being put anywhere to attract a broad discussion, especially from those impacted by the change. The closure also acknowledges that the change will be unpopular and pokes fun at the use of ise - ize. To me starting a new discussion clearly before damage is done is appropriate, site notice and project notices to draw in input from those who will be impacted. I also thing the closing admin should give weight to the intangible knowledge of the individual, that others should refrain from borderline bullying comments after every vote they disagree with. Gnangarra 01:37, 18 April 2019 (UTC)
I agree. It was in direct conflict with our policies on use of Enlglish variants and needed to advertised in the Wikiproject Australia and similar where the use of “organisation” is normal and correct. To those who say it is an unimportant change, then let’s swap them all to use “organisation” then. Kerry (talk) 02:28, 18 April 2019 (UTC)
  • I closed the discussion. I don't like the use of "z" in categories and feel it is predominantly biased against, well, "me"; and I hated closing it against my point of view. Yet, the discussion was well-publicised (if you don't follow CENT or the Village Pump or the RfC counter, don't blame others for not coming to your home and ringing your bell). RfCs don't need to be even publicised. The fact that they are RfCs mean that people who follow relevant requests for comments boards will comment. Further, the fact that I suddenly see a lot of opposing parties allows me space and reasonable doubt to explore issues in canvassing. Using your own narrow logic, you cannot use this forum to decide whether to re-open the RfC. In real terms, have another RfC with the questions – Was the previous RfC not publicised enough? And if yes, should the RfC be opened up or re-started? In summary, I hate the original RfC's premise and consensus; but I'm not going to re-open it for such a reason that it wasn't publicised. Lourdes 02:44, 18 April 2019 (UTC)
    • As I suspected, Number 57, your action of leaving messages on selective Australian, New Zealand and UK noticeboards[4][5][6] in order to garner comments on this discussion is clearly not good form. I repeat to all the new opposing editors who clearly have come here based on Number 57's selective messaging – if you all have an issue with the publicity given to the previous RfC, then open another RfC asking the community that very question (about whether they agree that the previous RfC was not publicised well), and make sure you publicise your RfC beyond your three noticeboards, and see how the community responds to it. The discussion here, with or without canvassing, will not result in the previous RfC's close being overturned. Thanks, Lourdes 03:13, 18 April 2019 (UTC)
    • @Lourdes: The only concern I have with the close is that it is customary for RFCs to run 30 days or so, yet you closed this within about 2 weeks. Given the vast number of pages and edits involved, I would feel and I think most would feel more comfortable with a longer-running RFC. --Izno (talk) 03:35, 18 April 2019 (UTC)
      • Izno, hi. Per Wikipedia:Requests for comment#Length, there is no custom for RfCs to run for 30 days.[a] The bot that covers RfC removes the tag in 30 days as that is the maximum it considers for any RfC. I closed the RfC on 17th April after consensus was one-sided and editors had stopped commenting. The last comment in the RfC was on 15 April and then it went silent. This was after 40 plus editors had commented during the previous fortnight when it was open. If there is a view that the RfC's consensus would have changed, had it been open for sometime more despite there being no fresh participation in the RfC in close to 48 hours, then that is a new view being put out here; which is different from the publicity argument being placed above. Thanks, Lourdes 05:21, 18 April 2019 (UTC)
        • Hi Lourdes, I see you're only a newbie ;) so you may not be aware that prior to this edit on 26 March 2017, 30 days was considered the default length for an RfC so there definitely was a custom of running RfCs for 30 days. I expect that there are many people who still believe this to be the case. While the wording has changed, and not for the better IMHO, the same has always applied, i.e. that RfCs may and are closed when necessary. An RfC with a clear outcome doesn't need to run the full 30 days but something as controversial as a language war should run the full 30 days at least, and more if necessary. --AussieLegend () 09:56, 18 April 2019 (UTC)
  • Hi Aussie, yes, I see the diff you're referencing. Thanks for the same :) Lourdes 12:12, 18 April 2019 (UTC)
I'm responding to the notice at the Australian board, unaware of this discussion and supposed to mowing the lawn. The close to a US bias against your own 'pov', which is presented as merely a UK et al bias, is what? A demonstration of impartiality? There were sound reasons to avoid this going either way, and especially to the less universally acceptable spelling. The support was pretty much votes by people who comment in response to request for comments, asking Australians and others who are familiar with both american and english usage will produce a different outcome I'm guessing. Applying spelling that was developed for regional usage and regularization of language is a poor choice, it is promoted elsewhere (and on wikipedia) by inflexible mechanisms of a hegemony and not by the inherent nature of the language as 'she is spoke'. cygnis insignis 05:54, 18 April 2019 (UTC)
  • Mildly, it wouldn't have hurt to let this RfC run a bit longer given Engvar is occasionally a hot topic and the change affects a fair few categories. There seem to be plenty of editors (me included) who were unaware that this was being discussed - that's our fault for not being Village Pump regulars, but in the spirit of collegiality it would be good to give latecomers a voice. However, agree that complaining about it here won't overturn the result (unless the closer unilaterally reverses themselves, which they're clearly not going to do). Suggest a new RfC, with notification both centrally and to various Wikiprojects on both sides of "s-z" linguistic divide. -- Euryalus (talk) 06:20, 18 April 2019 (UTC)
Nope, I'll probably reverse the close and let it be as the new argument put forward by Izno is also well taken by me. Lourdes 07:26, 18 April 2019 (UTC)

Notes[edit]

  1. ^ "An RfC should last until enough comment has been received that consensus is reached, or until it is apparent it won't be."

TfD of Template:Blocked user[edit]

I've started a TfD for Template:Blocked user at Wikipedia:Templates_for_discussion/Log/2019_April_17#Template:Blocked_user. Advertising it here as I suspect more comment beyond the usual TfD crowd is warranted. TonyBallioni (talk) 17:56, 17 April 2019 (UTC)

Add automatic disclaimers on mirrors?[edit]

Fairly often, I notice things like these disclaimers

Wikipedia data structure
Subject namespaces Talk namespaces
0 (Main/Article) Talk 1
2 User User talk 3
4 Wikipedia Wikipedia talk 5
6 File File talk 7
8 MediaWiki MediaWiki talk 9
10 Template Template talk 11
12 Help Help talk 13
14 Category Category talk 15
100 Portal Portal talk 101
108 Book Book talk 109
118 Draft Draft talk 119
446 Education Program Education Program talk 447
710 TimedText TimedText talk 711
828 Module Module talk 829
2300 Gadget Gadget talk 2301
2302 Gadget definition Gadget definition talk 2303
-1 Special
-2 Media

posted on user/user talk pages. (Obviously, replacing http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals) with http://en.wikipedia.org/wiki/User_talk:Example or whatever.)

Is there a way to automate this for pretty much anything that would be confused on a mirror site? I'm thinking every namespace, except for 'content' namespaces

  • Article
  • Book
  • Category
  • File
  • Module
  • Portal
  • Template

should get those notices, Everything else (including all talk pages), would get the disclaimer. With similar things happening in in other languages / sister projects. Headbomb {t · c · p · b} 17:31, 20 April 2019 (UTC)

  • Support if technologically feasible. (Also, sorry to come off as ignorant here, but are the mirrors done by the WMF?) John M Wolfson (talk) 18:03, 20 April 2019 (UTC)
    • Mirrors are set up by third parties based on data dumps, usually. I'm not really sure how this should or could be implemented, something like a WP:CENTRALNOTICE that gets suppressed here, but displayed there? I'm sure the WMF techheads could have some ideas about this. Headbomb {t · c · p · b} 18:18, 20 April 2019 (UTC)
      • Fair enough, I guess we'll have to wait to hear from them. John M Wolfson (talk) 18:21, 20 April 2019 (UTC)

Proposal about some indefinite IP blocks[edit]

I'd like to propose that we lift some indefinite IP blocks. To keep this relatively uncontroversial and problem-free, and for reasons I'll detail below, I'd like to specifically propose lifting all indefinite blocks on individual IP addresses placed in 2008 or before. All of them. I don't want to discuss range blocks - we can revisit that topic another time.

I've chosen 2008 at the cut-off because this is when policy really changed to discourage indefinite IP blocks. It's over ten years ago. Before then the blocks were fairly reckless in respect of the long term issues. You could make a case that some of the blocks made in the last decade are still relevant, but they are of a size where they can be reviewed on an individual basis. Indefinite IP blocks are rarely made in modern times, and they are often mistakes or undone relatively quickly.

Someone might be able to provide some current statistics for the number of blocks grouped by the year they were made, but some provided in 2014 are:1

2004 - 112
2005 - 3305
2006 - 9833
2007 - 4284
2008 - 2793
2009 - 54
2010 onwards - fewer and fewer

1 Wikipedia:Village_pump_(policy)/Archive_112#RFC:_Indefinitely_blocked_IP_addresses

You can't pretend that's a rational distribution. I've spent some time reviewing and undoing some of these blocks over many years (as have others), and I'd estimate that something like 1% merit even a second thought, never mind a continuing block. In the last few hundred reviews, I've not found a single block which should not be lifted. Any potential reasons to keep them blocked are extremely limited. I've come to the conclusion that almost all of these IPs should and probably will be unblocked anyway, but what I propose is that we lift them all, regardless, en masse. This is basically just a time-saver. Reviewing these blocks has been discussed multiple times over the years, and progress gets occasionally made, but the workload is just too much for qualified people to review them individually. I could continue reviewing and unblocking them, but there are better things I could be doing.

Lifting the blocks has the benefit that more people will be able to edit without hindrance. It will also save requests to OTRS, UTRS, ACC, and CAT:UNBLOCK, and also allow us to keep on top of the remaining indefinite blocks.

I'd like to be clear that there is a risk that a small number of still-dodgy IPs might be unblocked. Some IPs will still be assigned to webhosts, and some open proxies may still be open on the same address. In a few cases there might even be the same vandal on the same address - ten years older. I think this risk is small. Hardly anyone will be on the same address after a decade. Even fewer will want to continue vandalism. Any schools will have seen all their students and most of their staff leave. Most open proxies will have been shut down. It's almost certain that all zombie and HTTP proxies (and some of the vandals) will be deceased after ten years. Most remaining webhosts (and schools) will have improved their policies and technologies and/or reassigned the IPs.

This small risk is mitigated by several other factors since the blocks were made. We have introduced the edit filter. The spam and title blacklists are much improved. We have near real-time monitoring of proxies and vastly improved reporting mechanisms. We have ProcseeBot. We have global blocks and a decent grasp of range blocks. We have some leet admins, checkusers, and stewards prepared to swiftly block these IPs if necessary. Finally, the abuse from all these IPs combined is probably less than we see from a regular ISP like T-Mobile or BT on a regular basis. All of these IPs will have a block log shorter than 3 years and at the very most 7 years of editing, followed by 10 years of being blocked - most have not edited at all.

What do you say? -- zzuuzz (talk) 19:18, 21 April 2019 (UTC)

  • Good proposal. tl;dr IPs are dynamic by nature and are reassigned without warning. I can imagine it'd be discouraging for a new editor trying to contribute, only to find themselves caught in an irrelevant block. A healthy dose of common sense and IAR should be applied: unblock the IPs. -FASTILY 19:43, 21 April 2019 (UTC)
  • Support Actually, I have been meaning to propose about the same (with the unblocking being done by a bot) for some time. However, I think that only block reasons with "proxy|proxies" in them should be unblocked. This is the list of indefinitely blocked IPs without those blocked for being proxies, showing a only a hundred or so that can and probably should be manually reviewed (school blocks with OTRS tickets etc).(Wikipedia:Database reports/Indefinitely blocked IPs is the list of all indefinitely blocked IPs (warning to peeps: very large page, and open it without MediaWiki:Gadget-markblocked.js enabled if you want the page to load reasonably).) It certainly makes a lot of sense to unblock individual IPs; while ranges can be stably assigned to one host, a single IP but not the range being a proxy etc for 10 years seems next to impossible, and if the whole range is a proxy it's likely been blocked. Galobtter (pingó mió) 19:56, 21 April 2019 (UTC)
  • Support, subject to checking that they aren't open proxies. עוד מישהו Od Mishehu 20:08, 21 April 2019 (UTC)
    This kind of misses the point of the proposal, unless you have a handy method to do this. There is no reliable method for determining that an IP is not an open proxy. The best you'll get is human expertise, and I can tell you after diligently reviewing a lot of them is that hardly any are. The rest can get re-blocked or rangeblocked. Thousand of new proxies appear every day. A handful being unblocked are not going to make any significant difference. -- zzuuzz (talk) 20:17, 21 April 2019 (UTC)
  • Strong support, any still-problematic IP addresses can be reviewed and if necessary reblocked individually. John M Wolfson (talk) 20:11, 21 April 2019 (UTC)
  • Support Timesaver=good. GenQuest "Talk to Me" 23:58, 21 April 2019 (UTC)
  • Seems like a great (and hopefully simple) task for some of our adminbot operators. The particular scope and rationale here are compelling. ~ Amory (utc) 00:40, 22 April 2019 (UTC)
  • Absolutely support. Thanks, zzuuzz for bringing this here; it's something I've argued in less obvious places for (literally) years. There's no reason for the majority of these blocks anymore, if there ever was a reason for them. Quite honestly, we might want to do something that prevents indefinite blocks of IPs, perhaps limiting them to a maximum 3 or 5 years (which seems to be the maximum leasehold on IP addresses in most countries). Risker (talk) 01:12, 22 April 2019 (UTC)
  •  Note: I could (using this query) 20031 such blocks (including 33 few false positives) - can I suggest that, if this proposal passes, an admin bot implement it, to make it easier? --DannyS712 (talk) 01:36, 22 April 2019 (UTC)
  • Support Well thought out, well described. There's no reason to automatically keep 11+ year old IP blocks. North8000 (talk) 12:18, 22 April 2019 (UTC)