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.
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)[reply]
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 Wellertalk10:52, 2 April 2019 (UTC)[reply]
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)[reply]
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)[reply]
We already have the "on this day" section of the mainpage. I don't see a problem in having some birth centenaries there. ϢereSpielChequers10:59, 4 April 2019 (UTC)[reply]
I don't think that would be necessary. It's a bad idea, sure, but it is coherent and "makes sense" and archiving it as weird might be a bit gravedance-y IMO. John M Wolfson (talk) 02:50, 23 April 2019 (UTC)[reply]
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 Mishehu12:28, 14 April 2019 (UTC)[reply]
This clearly wouldn't be suitable for a Wikipedia article, and there's little point in piling on the "oppose" votes, but it strikes me that the production of such a list would be useful as an exercise for someone who wants to learn how to extract data from Wikidata and then do something with it. The results could certainly be published on someone's personal web site, or I'm sure that there's an open wiki somewhere that would welcome such a list. Phil Bridger (talk) 17:38, 23 April 2019 (UTC)[reply]
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.
Proposal: Halt the mass deletion of non-spam portals and focus on achieving consensus on portal guidelines
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)[reply]
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)[reply]
Here is a shortlist of legacy portals up for deletion by in the last 36 hours:
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)[reply]
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)[reply]
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)[reply]
@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:MFDLegacypac (talk) 19:26, 14 April 2019 (UTC)[reply]
@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
MFD:Mass-created portals based on a single navbox 1390 portals based on a single navbox. That one took me about 20 hours of research, all on more drive-by creations by the topic-banned spammer @The Transhumanist. About 70 editors have commented, and last time I checked, support for deletion was running at ~7:1
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?
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)[reply]
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)[reply]
@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 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)[reply]
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)[reply]
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)[reply]
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)[reply]
I'm posting partly to keep this discussion on the page because it's still very germane, with more portals still being brought to MfD every day. We are now back to about the same number of portals as we had before the big WP:ENDPORTALS RfC a year ago. I would like to see a time-limited moratorium on this deletion campaign, which features a small core of editors who go "delete, delete" on every one, based on constantly shifting arguments. Among these arguments, two appear to me spurious. {1) The constant references to "forking", a concept which in Wikipedia has applied to articles, not pages of other types. Replacing "fork" by "alternative presentation with more visual appeal" would be more fitting. (2) The argument from page views. Obviously articles currently get far more page views than portals on the same topic, because a reader doing a standard Wikipedia search on a broad topic is presented with the article, not the portal. They have to plough through what is often an exceedingly long and detailed article before maybe reaching at the very end a link to a portal. They haven't seen portals, so have never rejected them.
This is not a vote to eternally keep poor-quality pages that no-one wants. It's a vote for a breathing space, for a last chance to justify the role of well-constructed portals on Wikipedia, this time going not for quantity but quality, and to explore how readers who could benefit from a portal can be offered it, without obstructing those who do want to go straight to the article. To get back to the "main page for a broad topic" idea and leave behind the all-or-nothing polarisation of recent times: Bhunacat10 (talk),19:02, 27 April 2019 (UTC)[reply]
Add automatic disclaimers on mirrors?
Fairly often, I notice things like these disclaimers
This is a Wikipediauser page. This is not an encyclopedia article or the talk page for an encyclopedia article. If you find this page on any site other than Wikipedia, you are viewing a mirror site. Be aware that the page may be outdated and that the user whom this page is about may have no personal affiliation with any site other than Wikipedia. The original page is located at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals).
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)[reply]
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)[reply]
@Xaosflux: that's to show the namespaces in case someone wants to know which exists if they disagree with my list above, or thinks others should be covered. Headbomb {t · c · p · b}16:41, 25 April 2019 (UTC)[reply]
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 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 as 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
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 and the Tor block. 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.
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. -FASTILY19:43, 21 April 2019 (UTC)[reply]
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)[reply]
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 that hardly any are. The rest can get re-blocked or rangeblocked. Thousands 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)[reply]
Seems like a great (and hopefully simple) task for some of our adminbot operators. The particular scope and rationale here are compelling. ~ Amory(u • t • c)00:40, 22 April 2019 (UTC)[reply]
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)[reply]
Note: I count(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)[reply]
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)[reply]
Support The belief that a person would be waiting apprehensively on a an 11+ year block to be rescinded just so they could start vandalizing Wikipedia again boggles the mind. I can't find any good reason to keep even a single one of these active. IF one of these thousands of indeffed IPs starts causing problems, they can be blocked on a short-term basis as the problems come up. --Jayron3218:45, 22 April 2019 (UTC)[reply]
Support. I foresee few negative ramifications to this snowball, and those that arise can be handled the same way we currently handle new problems. I would suggest just unblocking all existing IP blocks prior to (say) 2009 (and deleting their talk pages if they hadn't been edited since then, while we're botting about.) --jpgordon𝄢𝄆 𝄐𝄇 23:34, 22 April 2019 (UTC)[reply]
Support. Some proxies, webhosts, etc may need to be reblocked after the mass-unblocking, but they probably shouldn't have been indefinitely blocked anyway. NinjaRobotPirate (talk) 20:54, 23 April 2019 (UTC)[reply]
This is a good point. I've taken a look through and not found any. The case was in 2009, and mostly outside the range here, but also, all the blocks recorded appear to have already expired many years ago. I'll continue to look into this however. -- zzuuzz(talk)20:47, 24 April 2019 (UTC)[reply]
I take your point that the ban probably persists, however those IPs are probably experiencing the same situation that this proposal is addressing - IP addresses get reassigned. -- zzuuzz(talk)21:00, 24 April 2019 (UTC)[reply]
Support Most f these IPs have probably been re-assigned long ago. It's not worth reviewing them all individually, I think an admin bot or script is fine, with the possible exceptions noted above. If they return to disruptive editing reblocking is easy. Beeblebrox (talk) 22:17, 24 April 2019 (UTC)[reply]
In terms of timing, it's nice to see that these may finally be dealt with, but there's no great rush - we've waited 10+ years and a few days here or there won't make any difference. In terms of logistics, I'd be happy to take Anomie up on their offer to run the bot. We would only need to finalise an agreeable log summary. Exceptions, ie blocks to remain, may also be proposed of course, but if there are any they should probably just get re-blocked either before or after. -- zzuuzz(talk)19:18, 27 April 2019 (UTC)[reply]
Support, with the exception of the Scientology ones, per A little blue Bori. Most of these have likely been reassigned since then, and a review of them, if nothing else, won't hurt. —Javert2113 (Siarad.|¤)19:25, 27 April 2019 (UTC)[reply]
I've looked through both the blocklist and the record of blocks at the arbitration case, and as far as I can see there are no relevant Scientology blocks remaining in place at this time. -- zzuuzz(talk)20:12, 29 April 2019 (UTC)[reply]
Support - We shouldn't be making indefinite IP address blocks unilaterally in my opinion. There's no point in keeping these old blocks at all, and this process will help us to turn the page and look forward instead of backward. ~Oshwah~(talk)(contribs)15:35, 4 May 2019 (UTC)[reply]
Massive support I see these IPs with incredibly long blocks listed on the Database Reports and I have to ask what exactly are we blocking? Seriously, you think some vandal from 2007 will return 12 years later to post "poop" on some article? Enough, lift the blocks. All we are doing is preventing potential editors from joining the project. LizRead!Talk!01:00, 5 May 2019 (UTC)[reply]
SupportIP addresses tend to change, and people do too. many of the abusers are students, who no longer attend the institutions that are blocked. --rogerd (talk) 01:20, 5 May 2019 (UTC)[reply]
Support - Even today, I think we tend to underrate the meaning of "indefinite" on a project with this kind of longevity. Much more so back in the wild west days when these blocks were made. -- Scott Burley (talk) 01:43, 5 May 2019 (UTC)[reply]
I can't really think of a situation where an IP needs to be blocked indef. IPs change hands all the time on multiple levels. SQLQuery me!01:50, 5 May 2019 (UTC)[reply]
Who cares about an IP banned in 2011 after fewer than 20 edits?[4] You can bet your bottom dollar this person is no longer at this address. — JFGtalk05:43, 5 May 2019 (UTC)[reply]
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.
Grant proposal to build a way of surveying, assessing and integrating large amounts of open license text into Wikipedia
I think that there is huge potential in the ability to use existing text written by experts in Wikipedia, the volume of available content is huge. There are over 13,000 open access journals and many organisations make their websites available under open license e.g UNESCO’s 1.5 million page website will soon be available under CC BY-SA.
However we lack a way to systematically survey, assess and integrate large amounts of open license text into Wikipedia, which is going to take a lot of work to design. I’ve been working with an intern at UNESCO to put together a grant proposal for her to do the research and work with the community to design and create this tool, we would really appreciate your endorsements and suggestions, if you’d like to be involved please mention this in your endorsement.
I think we first ought to know whether it's a good idea to use Wikipedia as a testing ground for this. Just because some text is under an open license does not mean that it belongs here (may be too preachy, too technical, too detailed etc.). Jo-Jo Eumerus (talk, contributions) 16:36, 22 April 2019 (UTC)[reply]
At a first glance I can see some problems with this proposal. Such content will usually conform to the verifiability policy of Wikipedia, but much will not conform to the other basic content policies of neutral point of view and no original research. I would have thought that this statement is pretty obviously true, but I may find time to expand on my reasoning if it is contested by a significant number of people. The other problem is social rather than content-related. There are many Wikipedia editors who object to any content that is automatically or semi-automatically generated from other sources, but prefer things to be specifically written for Wikipedia by a human, a version of the not invented here position, so it would be difficult to get such content past Wikipedia's largely self-appointed gatekeepers. Phil Bridger (talk) 17:45, 22 April 2019 (UTC)[reply]
Thanks for your thoughts, to be clear this proposal is to create a kind of central organising space, not to create a process for importing open license text into Wikipedia, which we have already done at Help:Adding open license text to Wikipedia. I think that this section on adapting text for Wikipedia addresses some of these concerns and makes explicit what should be considered e.g 'no original research', 'neutral point of view' etc. If you have any suggestions on how this could be improved please do say. Thanks again, John Cummings (talk) 20:14, 22 April 2019 (UTC)[reply]
I would look more kindly on your proposal if your approach to Wikipedia editing was a bit less arrogant than that demonstrated by this edit, where you changed my correct indentation to incorrect indentation. Phil Bridger (talk) 20:30, 22 April 2019 (UTC)[reply]
Hi @Phil Bridger:, I'm sorry, I thought that you had made a typo (I have always understood that a new message has an additional : at the start) and I was trying to be helpful for readers to follow the conversation. John Cummings (talk) 21:52, 22 April 2019 (UTC)[reply]
Well, that just demonstrates your arrogant approach to editing. If someone does something that goes against what you have always thought then you should not immediately assume that you are right and the other person is wrong. How could we possibly distinguish what is a reply to what if we didn't follow WP:INDENT? It's not rocket science. You should get such basics right before making much more complex proposals. Phil Bridger (talk) 20:43, 24 April 2019 (UTC)[reply]
Wikisource might be interested in this, and potentially Commons for image files, but I can't for an instant imagine such a proposal flying on Wikipedia itself. Neutral Point of View is an utterly non-negotiable core principle of Wikipedia, and such things as UNESCO’s 1.5 million page website are vanishingly unlikely to comply with it. (Things that just consist of raw data would comply with NPOV, but in turn wouldn't be appropriate for Wikipedia as we don't host source material ourselves, we only summarise other sources' interpretation of the source data.) While there are still a few pages left from the early days of Wikipedia when we imported some public domain sources as placeholders on topics on which we don't have an article, virtually all of those pages are non-compliant with what Wikipedia aims to be, and we encourage people to rewrite such pages when we find them. Out of curiosity, can you actually give any examples of articles where "adapting text for Wikipedia" has actually been successful? While I don't doubt the good intentions of whoever wrote Help:Adding open license text to Wikipedia, it reads to me like it's been written by someone with no understanding of how Wikipedia operates or of what Wikipedia actually does. ‑ Iridescent21:20, 24 April 2019 (UTC)[reply]
I agree with Iridescent - the best place for this is Wikisource. It certainly doesn't work for Wikipedia; from a quick look, most of the UNESCO website is a primary source; that is, suitable (probably) for references, but not as articles. Most of the UNESCO pages aren't referenced sufficiently (if at all) to be acceptable as articles. Wikisource is where they could go, though, should Wikisource be willing to take them. I'm going to be honest, I think your "help" page is probably off the mark; adding material that met licensing requirements but wasn't referenced was pretty much deprecated back when I started editing. Certainly large dumps of materials wouldn't be accepted today the way they were back in the 2000s. Risker (talk) 21:47, 24 April 2019 (UTC)[reply]
Some of it, such as this page, might have some usable content, and it could be sourced to the UNESCO page that it copies, since that would not be an unreasonable source for writing basic descriptions of UNESCO-designated places. Those short descriptions look a lot like a decent short stub, and would not be out of place as the lede to a somewhat better article.
The English Wikipedia probably doesn't need this particular text (i.e., I assume that we already have longer articles on all of these locations), but at least some of the pages might be usable. WhatamIdoing (talk) 22:52, 26 April 2019 (UTC)[reply]
I think it will be great to have Twinkle on mobile version of Wikipedia. Users who edits by a smartphone or tablet including me always have to switch to desktop version to use Twinkle. We need to keep in mind that Desktop version of Mediawiki is not optimised for mobile users. Therefore some users face a lot of difficulties when editing by a smartphone or tablet. I think a lightweight version of Twinkle would be good for mobile version. Sincerely, Masum Reza☎10:21, 24 April 2019 (UTC)[reply]
This isn't exactly what you asked for, but if you set your skin to MonoBook and enable the responsive mode you get a pretty usable mobile skin that works with Twinkle. --XenonNSMB (talk, contribs) 12:57, 25 April 2019 (UTC)[reply]
VideoWiki tutorial for the tool made with the tool
A few of use have been making video scripts that than compile into videos using the WP:Videowiki tool. We are wanting a "Video" namespace for these scripts to help with a number of functionalities. Examples of already created video scripts include:
@Doc James: Your post seems more like a statement than a proposal, at least to me. Are you informing us about this VideoWiki or proposing to add a new namespace on English Wikipedia to hold them?. – Ammarpad (talk) 08:37, 2 May 2019 (UTC)[reply]
@Ammarpad:: I believe @Doc James was trying not to be "promotional" about VideoWiki and stated ongoing facts while bringing the "video" namespace ask up, consequently the bare language. The "Video" namespace will really be helpful in bring collaboratively edited videos under one roof and allowing us to build the gadgets for the "video" namespace. Pratik.pks (talk) 10:42, 2 May 2019 (UTC)[reply]
clear is a deprecated HTML attribute. If these are automated in some way, and that's the required text, you should consider using a different signal.
That aside, I also am unclear; I do not think we should have a new namespace for these. If you want to host them in all in the same place, your current approach seems reasonable. --Izno (talk) 20:16, 2 May 2019 (UTC)[reply]
User:Ammarpad As stated "We are wanting a "Video" namespace for these scripts"
Not sure what you are referring to about clearUser:Izno?
Having them in their own namespace will allow additionally functionality like allowing people to have just this group of articles show in their watch-list. Doc James (talk · contribs · email) 22:09, 2 May 2019 (UTC)[reply]
This functionality does not strike me as needed for this set. The middle-product is a list of pages from what I can see that are project-space; I would recommend categorizing them and then using Special:Recentchangeslinked. The end product is videos, and you can do the same with those. There is also a significant semantic overlap with the File namespace, which will cause confusion for many people. You really don't need a new namespace.
clear is a deprecated HTML element. That means it may not work the way you want after some significant period of time; browsers may deprecate or remove recognition of the clear functionality. My point was that if the script that creates these pages relies on that exact line being present, you may not have desirable pageviewing at some point. There are other ways to do this (e.g. <br style="clear: both;"/> or {{clear}}) that you might consider using which should continue to be useful long into the future. --Izno (talk) 13:31, 3 May 2019 (UTC)[reply]
You presume much if you believe that VE would be turned on in any other space. You could move them, but that would definitely causes issues and not likely have consensus. IMO, you're chasing a car you don't need to. You still have not illustrated particular need for a new namespace. --Izno (talk) 00:58, 4 May 2019 (UTC)[reply]
Wait until VideoWiki gets more popular. It just started this year and might fizzle out and leave us with a junk namespace. I don't think it will, but I still say that we wait until VideoWiki sticks and becomes a lasting part of Wikipedia. John M Wolfson (talk) 22:17, 2 May 2019 (UTC)[reply]
Thanks User:John M Wolfson. That is certainly reasonable. Once we have more than a hundred or a few hundred videos we can come back :-) The one problem will be the amount of work required to do the move. The more video scripts the more work I imagine... Additionally we want to have visual editor usable on the scripts and moving a namespace would allow that. We are also wanting to enable a gadget to bring further functionality within Wikipedia, specifically we want to bring in the Videowiki player. Doc James (talk · contribs · email) 22:24, 2 May 2019 (UTC)[reply]
Comment I'd like more information about the technology used for the text to speech in these videos. -- GreenC23:34, 2 May 2019 (UTC)[reply]
User:GreenC it is an off the shelf text to speech reader.
@Doc James: Thanks! It is high quality, Amazon explains it. About the only thing they might do is a Terms of Service request for attribution, but not seeing any evidence of such a TOS. Can Amazon be documented for people curious how it works? -- GreenC07:10, 3 May 2019 (UTC)[reply]
Editing workflow Videowiki One note, the workflow being used is to convert the TTS output to webm, and upload it to commons, where editors can decide if they want to use the videos in articles. This allows for offline use, but it also means the vast majority of views will be of webm recordings; not of the actual TTS output which limits costs. I've made a graphic of the workflow to the right. In Amazons FAQs they address this type of use. "Q. Can I use the service for generating static voice prompts that will be replayed multiple times? Yes, you can. The service does not restrict this and there are no additional costs for doing so." Ian Furst (talk) 10:57, 3 May 2019 (UTC)[reply]
Move video scripts to "Video:Name"
Moving to "Video:Name" will allow those working on video scripts to use visual editor without any changes required by the WMF. Looking for consensus for such a move.
Support. COI, as the main content creator with Videowiki, but I'd like to ask for consideration towards a namespace. The link between script<>Videowiki player<>commons_webm<>WP_article depends on a uniform naming protocol, so that each entity can find the 'call'. So far we're up to 20 videos, but with multiple languages that means roughly 100 named urls. If there is consensus, it would save a lot of work down the road in not having to re-point various elements. Wrt current space (Wikipedia:Videowiki/...), it doesn't allow VE. Many of these article sections have 50 characters of "script" with 400 characters of references. VE makes it much easier to change script (there is a lot of punctuation changes to make the TTS engine sound more human), especially for < veteran editors, like myself. A list of scripts, videowiki player links, and commons webm files can be found here to see the issue. Ian Furst (talk) 02:47, 5 May 2019 (UTC)[reply]
Note that the proposal stated here is not for a namespace, but to put them into the main article namespace with "Video:" as a pseudo-namespace. Among other things, that means these would show up when people search for articles, use Special:Random, and so on. If other-language wikis were to follow, they would still likely use localized versions of the word "Video", while a true namespace could always have English "Video" available as an alias. I don't know if that distinction makes a difference to you. Anomie⚔13:51, 5 May 2019 (UTC)[reply]
A video namespace does not exist (As written, this is not a proposal to create one, only to move the pages.), so they would be in the main (article) namespace. Since they are not articles, they don't belong there. — JJMC89 (T·C) 23:32, 4 May 2019 (UTC)[reply]
As this proposal is to use "Video" as a pseudo-namespace, I oppose. Adding a namespace is extremely easy:
Establish consensus for the new namespace on this page.
File a task in Phabricator with the Wikimedia-Site-Requests tag, similar to T156621. Side note, I'd recommend using namespace numbers 130+131, which could become the new "standard" VideoWiki namespace number if other wikis want to do the same thing.
For the record, I have no opposition to the creation of a true namespace for these scripts, only to the use of a pseudo-namespace. Anomie⚔13:51, 5 May 2019 (UTC)[reply]
Oppose. I do not think we need to establish a separate namespace for videos regardless of their creation method, as I have already laid out multiple times above. --Izno (talk) 03:06, 5 May 2019 (UTC)[reply]
Discussion
Use of Caucasian
Hello
I would like to propose several things in relation to the use of the term Caucasian on Wikipedia.
First of all, I would love to see the pages Category:People of Caucasus descent and Category:American people of Caucasus descent be renamed to Category:People of Caucasian descent and Category:American People of Caucasian descent, because Caucasian is the term to refer to people from the Caucasus. You can't be of Caucasus descent anymore than you can be of England descent or United States descent.
When deciding whether to link ot the page Caucasian race or Peoples of the Caucasus when referring to Caucasians, don't automatically assume the Blumenbach definition of Caucasian of Caucasian, a definition perpetuated by North American English speakers. I'm not saying not to ever link to the race page, I'm saying make sure that this is what you mean when you go to link to the race page.
I wish I could submit a form myself on th epage for the categories, which for whateve rreason Wikipedia doesn't let me link. However, I am blind and Wikipedia's editor is messing with my JAWS screen-reader. I don't think you guys want to see like brackets or dashes in the proposal on the talk page.
So hence why I am coming here, so I know that eyes will see it, and that I can maybe get help with the proposal form.
I also do need to bring forward the issue of what we mean when we use Caucasian, especially in these times where cultural and racial identity are at the forefront.
thanks.
Nahom.
199.101.62.21 (talk) 15:28, 2 May 2019 (UTC)[reply]
"American People of Caucasian descent" would create a dab problem since 'Caucasian' is most commonly understood to mean white people. Maybe it could be called "American People of Caucasian (Caucasus) descent", but the correct usage of Caucasian vs Causasus is so obscure to most people even the dab might cause some confusion eg. someone will want "American People of Caucasian (Serbia) descent" (a white Serb-American) based on a mistaken understanding of what the terms mean. It might be easier to leave it as is and have an explanation at the top of the cat page. If you feel strongly about it, and want to open a sort of vote taking discussion with the community the page is WP:CFD and if you want someone to open the discussion on your behalf due to the wall of text confronting a screen reader let me know. -- GreenC21:51, 3 May 2019 (UTC)[reply]
I agree that "Caucasian" to mean white should be deprecated if it isn't already, but that's the vast majority of what that word means in the U.S., being much more notable than people literally from the Caucasus, an area of the world many Americans might not know exists. As such, "American People of Caucasian descent" would cause many more problems with semantics than it would technically solve with grammar. However, User:GreenC is right in that a CfD would be in order. John M Wolfson (talk) 23:21, 3 May 2019 (UTC)[reply]
RfC: Removing locally-defined links to Commons categories if they match the Wikidata sitelinks
When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.
Should we remove locally-defined links to Commons categories where they can be provided through the Commons category sitelinks on Wikidata instead? Thanks. Mike Peel (talk) 18:09, 4 May 2019 (UTC)[reply]
Proposal
While we have been using interwiki links from Wikidata to provide the sidebar links to other language Wikipedias for the last few years, we are still mostly using locally defined links in sister project templates. In an RfC in August 2018, starting to use Wikidata to provide these links in the case of Commons categories was conditionally allowed, with the requirement to return to the community after further testing, which leads to this follow-up proposal.
Since the previous proposal, the following things have changed:
{{Commons category}} and {{Commons category inline}} have been rewritten to use the Commons category sitelinks in preference to Commons category (P373) from Wikidata: this means that they automatically update when a category is moved, providing that the category name has not been locally defined. These sitelinks are maintained by Wikimedians that edit Wikidata and Commons, as they are also used to display information from Wikidata in Commons categories. They can only be added if the category exists, which significantly reduces any risk of vandalism.
Pi bot now checks through those tracking categories to update the links to categories that have been redirected to the Commons category that is sitelinked from Wikidata, or don't exist but there is a Commons category sitelink on Wikidata that we can use instead - or if that fails, and the category doesn't exist or have any redlinked category inclusions, then it removes the commons category link. This is ideally a temporary measure, though.
As the next step, I propose to bot-remove the locally-defined Commons category names from the categories and pages in Category:Commons category link is on Wikidata, where they match the Commons sitelinks from Wikidata. If this proposal is accepted, then I will submit a bot request for approval to do this using Pi bot. This change should have no immediately visible effect, but any future changes to the category names on Commons would automatically be updated here. This would not affect any locally-defined Commons category links that are not on Wikidata.
I think we have cases when one article has two commonscat templates pointing to two different categories. I suggest that these cases be kept. If there is only one commonscat template, I agree with the proposal to remove it. Whereas we do have vandalism instance at Wikidata, in which case the sitelink disappears or is invalid, we have way more cases of commonscat templates pointing out to redirects just because the Commons category was moved and the template has not been updated.--Ymblanter (talk) 18:24, 4 May 2019 (UTC)[reply]
@Ymblanter: In cases where there are multiple commonscat templates in one article, this proposal would only remove the local text from the one that matches the sitelink. I can add an exception to avoid those cases if that's what we want to do, though. With that type of vandalism, that would be a cross-project problem to fix, and it would be caught by tracking categories both here and on Commons. Thanks. Mike Peel (talk) 18:39, 4 May 2019 (UTC)[reply]
Note: I count(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)
