This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
I propose that users be granted the technical ability to remove themselves from any groups they are in. Doing so is a clearly non-controversial action: no one could seriously argue that a user should have a right they don't want to have, and therefore there is no reason an admin should need to step in. {{3x|p}}ery (talk) 01:11, 3 March 2019 (UTC)
Just to be clear: the coding already exists for this as $wgGroupsRemoveFromSelf, so this is just a request for a config change. {{3x|p}}ery (talk) 01:14, 3 March 2019 (UTC)
Meh, there's never a backlog on this. It shouldn't be much of an issue if we want to deal with this, but suggest not allowing it for "confirmed", "extendedconfirmed" (because this will just lead to people breaking themselves and wasting admin time) or any of the functionary groups (like admin, checkuser, etc) where there is usually something bigger going on. I really don't care if pagemovers or the like ungroup themselves too much - so long as they don't clog up PERM asking for access back. — xaosfluxTalk 01:25, 3 March 2019 (UTC)
(
talk
) 01:26, 3 March 2019 (UTC)
You must not be very creative if you haven't saddled an editor you are annoyed with with pending changes. Natureium (talk) 01:48, 3 March 2019 (UTC)
I think there are too many ramifications if CU/OS are included in this proposal (the stewards do need to know when the rights are removed). Including admin/crat in this proposal is not a great idea either, as this could lead to more hasty ragequits. --Rschen7754 01:38, 3 March 2019 (UTC)
Support - Proposal seems entirely reasonable and it should be easy enough (technically) to accomplish. I agree that it should only apply to permissions which an admin can grant., and I believe it should include the ability to reinstate oneself into a group which they had removed themselves from (perhaps inadvertently)?--
John Cline: That latter thing isn't possible with the current code. {{3x|p}}ery (talk
) 01:56, 3 March 2019 (UTC)
That's also a bad idea: 1) User messes up, removes permission to avoid scrutiny/ANI/etc. 2) User regrants it to themself later. ~ Amory(u • t • c) 01:58, 3 March 2019 (UTC)
Meh seems like a pointless feature in most cases. If I'm a filemover, and stop wanting to be involved with filemoving, I can just... you know... not move files anymore.
Also meh. We don't regularly remove perms from blocked or banned or inactive users without a reason, so there's no harm. It's not like there's a flood of users requesting removal. ~ Amory(u • t • c) 02:02, 3 March 2019 (UTC)
Triple meh. It only takes a couple mins to post on the talk page of an admin asking them to remove a perm. Some admins are even friendly. Natureium (talk) 02:05, 3 March 2019 (UTC)
May I ask everyone exactly why applying this to admins and crats is somehow a worse idea than applying it to lower-permission groups. {{3x|p}}ery (talk) 02:22, 3 March 2019 (UTC)
Could there be a problem with groups that editors are added to for the community's benefit rather than their own? The only one I can think of is autopatrolled. Certes (talk) 03:03, 3 March 2019 (UTC)
@Certes: sysop :D thank you, thank you, I'm here all week. — xaosfluxTalk 03:29, 3 March 2019 (UTC)
You're quite right, and that applies to many other bits too! Perhaps "modify the community's interaction with Wikipedia rather than the editor's" would have been more accurate. Certes (talk) 11:33, 3 March 2019 (UTC)
The log comment for removal is on occasion useful. ("
Cryptic
03:20, 3 March 2019 (UTC)
Support if and only if it's made explicit that anyone removing a bit in this fashion is banned from re-requesting it for a significant period, to prevent frivolous requests. I can see no obvious benefit to this—the security issues that lead some people to temporarily relinquish CU or admin status when they're on vacation don't apply to event coordinator, rollbacker etc—and I can certainly see backlogs shooting upwards as people have minor tantrums, strip themselves of filemover or whatever, and then change their mind and ask for it back three days later. It's not as if we have an enormous queue of people lining up to hand in their New Page Reviewer bit that's taking too much time to deal with by normal means. ‑
Iridescent
15:13, 3 March 2019 (UTC)
In that case, it's clear we don't really need this. As the only thing certain here is; there would be more requests for regaining the rights after accidental/testing/just for fun/ragequit removals. Making it "explicit" (even in 'frightening capital letters') can never be as effective as the technical limitation. I have not yet seen the benefit of this. –Ammarpad (talk) 16:57, 3 March 2019 (UTC)
Solution in search of a problem - it really is beyond me why we'd need to solve how to do this. It also might come with some potential negatives (mentioned above) without countermanding positives. Nosebagbear (talk) 14:04, 4 March 2019 (UTC)
Oppose for now No reason has been given as to why anyone would want to do this, or why existing processes can't handle it. Anomie⚔ 02:33, 5 March 2019 (UTC)
Oppose. Implications of this are unclear. Needs further experimenting in Test Wikipedia. –MJL‐Talk‐☖ 02:39, 5 March 2019 (UTC)
What, exactly, needs to be tested? The implementation of $wgGroupsRemoveFromSelf? Nope, that config variable is already in use at Wikidata, so it's already been tested. The social effects of this change? I don't see how that can be tested at testwiki? {{3x|p}}ery (talk) 02:42, 5 March 2019 (UTC)
Support in principle but in reality, is an epidemic of editors seeking to remove their userrights that are being prevented from doing so because they don't have the ability? More importantly, are editors hampered in their editing without the ability to remove userrights? --Blackmane (talk) 02:47, 5 March 2019 (UTC)
Oppose What's the purpose of this? How is what we have now currently broken? Nihlus 02:50, 5 March 2019 (UTC)
Meh, pretty much per Headbomb - If you don't wanna filemove or rollback or anything else then simply.... don't ...., A solution looking for a problem IMHO. –Davey2010Talk 19:51, 5 March 2019 (UTC)
This may not serve an obvious and pressing need, but the end effect, if implemented with forethought and insightful clue, is better project administration; there should always be an above baseline appeal for doing things smarter and better when the bottom line is exactly such a choice. Aside that: the monkey wrench in retaining a right you don't and won't often use is that it almost exactly fits the implied definition of hat collecting which is an aspersion capable of hindering an admin hopeful's one day chance of succeeding an RfA. That's a very real consequence one should fully consider before blindly following
Oppose. There is no need to create the possibility for additional concerns at
WP:PERM, for example, if one accidentally or removes their user rights without due consideration (per Ammarpad). I don't see how enabling this would be an improvement over voluntarily resigning user rights or simply not using them. ComplexRational (talk
) 03:01, 6 March 2019 (UTC)
There is one situation that might warrant this. There is a browser extension that when activated on a given page, will open up every link in a new tab. It is not a good idea to use this when viewing your watchlist if you have the rollback right (it has happened), so it would be sensible to self-revoke rollback before using that extension. --Redrose64 🌹 (talk) 12:12, 6 March 2019 (UTC)
If someone knows enough about the consequences to remove the rollback right from themselves then they know enough to disable such an extension when viewing their watchlist. I haven't counted (it would take too long) but I would guess that that such an action would open at least a thousand tabs for me, which would cause me lots of problems even without rollback.
Support for all permissions below sysop, and all those granted automatically, because why not? It won't hurt anything, and there are at least a couple of valid use cases identified in this discussion. But if the userright is one that is granted (or not) based on individual community discussions, or is one that stewards need to keep track of, it is a bad idea to let users disable those permissions on their own. Ivanvector (Talk/Edits) 13:26, 6 March 2019 (UTC)
Just thinking about it some more, users should be able to suspend their userrights if they want to, for testing or whatever else, and maybe this should go for admins too; if so then rights suspensions should be separately logged. If a user's rights are removed, they should not be able to restore them. I don't know if that's compatible with the software. Ivanvector (Talk/Edits) 14:53, 7 March 2019 (UTC)
Oppose drama fuel for those who want to make unnecessary noise of their retirement. – Finnusertop (talk ⋅ contribs) 14:48, 7 March 2019 (UTC)
@Finnusertop: Silently removing one's own group instead of publicly requesting removal by an admin or bureaucrat is increasing noise? ~ ToBeFree (talk) 01:16, 17 March 2019 (UTC)
@ToBeFree: I doubt everyone will use this "silently" without any accompanying drama. I don't think we need to see rants like "I'm gonna remove all my permissions", "See, I just removed all my permissions" etc. Especially when it's instant and you don't need to pause, take a deep breath, and craft a politely worded message to an admin or bureaucrat. – Finnusertop (talk ⋅ contribs) 13:31, 17 March 2019 (UTC)
Oppose. Not needed. If users wish to resign permissions, a sysop or bureaucrat would be happy to do so. --Jayron32 15:02, 7 March 2019 (UTC)
Meh. One does not necessary need to use their user rights and one can always ask Admin to remove perms. There is nothing to fix as there is nothing broken.
talk
) 15:24, 7 March 2019 (UTC)
Meh leaning Oppose as a solution in search of a problem. --AntiCompositeNumber (talk) 14:59, 11 March 2019 (UTC)
Oppose Programming resource is scarce, there are a bunch of useful things that we can't get the Foundation to do, we shouldn't give them any excuse to do things that have no benefit when they could do useful things like autosigning on talkpages or reducing edit conflicts. Plus there are userrights such as Autopatrolled that are useful for the community to have appropriate editors have. ϢereSpielChequers 20:54, 12 March 2019 (UTC)
This doesn't require any programming, it's just a config change, the code already exists. {{3x|p}}ery (talk) 20:55, 12 March 2019 (UTC)
There was a recent case of a user asking for rights to be removed on their account at
talk
) 19:53, 14 March 2019 (UTC)
Oppose. People can simply stop using advanced permissions if they don't want to, and, if they must have them removed, that's not an urgent issue. I can see there being much more work for admins in restoring permissions to people who change their minds than would be saved by this change.
Oppose per Finnusertop, especially for users with more-advanced normal rights, e.g. filemover, as someone might use a Bismarck-style resignation threat to get his way. ("If you don't stop doing X, I'll resign my filemover right and you'll have to do all the work yourself!") If you're forced to get admin assistance, you'll give the other party a chance to demonstrate your bad faith, or you'll demonstrate it yourself. Nyttend (talk) 02:45, 18 March 2019 (UTC)
Since my concern is over the social effects of self-removal and consequent right-restoration discussions in controversial situations, together with the lack of an existing problem, I could easily favor Ivanvector's self-suspension idea. I have a second account that I can use for testing, but it's inconvenient to log out and log into it, do my testing, log out and log back into this one, and report the results (especially if I forgot and have to repeat the process). If I could temporarily suspend my rights, it would be more convenient, and I can envision this being particularly useful for accidental rollbackers. If you don't wanna filemove or rollback or anything else then simply.... don't This is true with many user rights, but I've seen a number of cases where someone said I have to use my phone for the next couple of weeks, and the screen's small enough that I keep hitting the rollback link by mistake, so please remove my right. If such a person could self-suspend his rollback right and self-restore it when he wanted it back, it would be easier for him, there wouldn't be any opportunity for abuse (you can't make a resignation threat if you can always reverse yourself) or for a nasty should-this-right-be-restored discussion, and you wouldn't have to wait for an admin's help. My only concern is the programming effort required; unlike self-remove, I can imagine that self-suspend wouldn't merely be a configuration change. Nyttend (talk) 12:02, 23 March 2019 (UTC)
I think you'd need twice as many flags, for example replacing "rollbacker" by "rollbacker permitted" and "rollbacker active". Alternatively, each flag could take three values: "not permitted", "permitted but suspended" and "active". Certes (talk) 12:10, 23 March 2019 (UTC)
I can't envision a situation in which anything but rollbacker would be needed for publicly displayed user groups or user-rights logs, since all that matters is whether the user has the right to use this tool. Are you addressing the programming-effort bit and meaning that the software would need all those options internally? Nyttend (talk) 12:22, 23 March 2019 (UTC)
Possible alternatives to your logging out of your main account and logging in with a test account is to open a private browsing window and log in there (or, if you already use private browsing for your main account, to open a normal window), or if your test is not browser-specific, to use a different browser. isaacl (talk) 12:59, 23 March 2019 (UTC)
Another option if you're using Chrome is to have multiple user profiles: one for your main account and another for your test account (that's what I do). Galobtter (pingó mió) 14:01, 23 March 2019 (UTC)
On a side note, Firefox too allows multiple user profiles, but the basic install needs to be tweaked to permit side-by-side browser windows with different profiles running, so if that deters you or you don't need to test in Firefox, using Chrome is easier. isaacl (talk) 14:09, 23 March 2019 (UTC)
Add the "cite magazines" citation template to RefToolbar on Wikipedia's Edit pages
@Izno: Those go to the same page. @Ylevental: The name of the template is cite magazine, there is no "s" since each use of the template can handle only one magazine at once. --Redrose64 🌹 (talk) 14:40, 24 March 2019 (UTC)
New Bot
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Hello,
Per WP:BOTREQ, I am asking for the community's opinion on whether a bot should be could do the following:
Pick ~30 editors from a page who are not already part of the mailer and invites them to the project. The bot would keep a check list of users that have been seen in the mailer before so it doesn't welcome users that have left and that it's welcomed before. There are a few ways and invite could work:
The users are manually invited from that lists
The bot creates a mass message template to post and send to them.
The bot sends the message itself.
The bot will also clean the mailing list of extremely inactive users.
The bot would be supervised and monitored through an IRC Status Feed.
Question... what is the “mailer”? I see you linked it to the Apple Inc. Wikiproject... is it something unique to that project? Blueboar (talk) 10:55, 24 March 2019 (UTC)
So I gathered... but is it unique to Wikiproject Apple Inc., or is it something broader? Is the goal of the bot to get more people to join that project? Or what? Blueboar (talk) 15:31, 24 March 2019 (UTC)
Blueboar, The mailer is created by us to inform people of how the project is going. The bot will be finding people that aren't listed as getting the mailer and never have done. RhinosF1(chat)(status)(contribs) 17:10, 24 March 2019 (UTC)
Having "been seen" in the mailing list before isn't sufficient, it should also keep track of anyone that has been invited, to prevent re-invites. — xaosfluxTalk 14:38, 24 March 2019 (UTC)
I wonder how this list is generated, since it seems to be where the bot will pick random editors to invite.? – Ammarpad (talk) 15:19, 24 March 2019 (UTC)
Oppose: please do not use a bot to spam editors with non-critical messages; that is discourteous, disruptive, and annoying.—Trappist the monk (talk) 16:14, 24 March 2019 (UTC)
Why would you think that I hadn't read the entirety of your post? To answer your question, I would prefer neither. Please do not use a bot to spam editors with non-critical messages.
That is not what you wrote in your initial post. Option 1 is a continuation of the opening sentence. You are asking:
whether a bot should [or could] ... [1] pick ~30 editors ... who are not already part of the mailer and [invite] them to the project?
The answer to that question is no. There is nothing manual about that prospective bot operation. Further, if inviting is done manually, then there is no need for a bot, right?
Oppose. This is a very niche project, so it's normal that few people are actually interested in taking part. We don't (correct me if I'm wrong because I haven't checked) have projects for particular brands of washing machine or household paint, so why would you expect many people to be interested in a project for one brand of computer/phone? If anyone wants to drum up support for the project and its newsletter then this should be done by a human actually determining whether an editor has expressed a genuine interest in the topic, rather than a bot working off a list of editors who happen to have made a few edits to articles of interest to the project, when many of these edits are things such as vandalism reverts or the addition of categories that are no evidence of any interest in the subject matter.
Phil Bridger, That's why part 1 has human oversight as part of the request and just the bot reviewing the list. I could set the bar higher. Can you suggest a good way to locate top contributors as I'm not 100% sure that [2] works which is what I was originally going to use works properly or how to change the parameters on the active editors list? RhinosF1(chat)(status)(contribs)
18:56, 24 March 2019 (UTC)
The whole point of my comment was that this determination needs to be made by a human being, not a bot. Please listen to what people are saying and realise that this is something that a human being can determine much better than a bot.
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.
Reviving
WP:LOBU
Maybe this isn't the right place to post this, if it isn't, please direct me to somewhere better, but my request for a speedy deletion review in
WP:LOBU
. I wasn't very active on Wikipedia back when the page was removed, and I understand the main concern about it was that essentially it just served to antagonize the banned users or act as a way to punish people outside of simply denying them. There was also a concern that the page only encouraged people to be banned and thus become "part of Wikipedia history".
While I do have a personal attachment to the page: I spent a large amount of time in high school reading it while on the bus while I was headed to school (I was an odd child), the primary reason I want it to come back is that there have been times that I've seen that users have been banned, and I have no clue why. It is really frustrating when that happens and the only way to figure out why is happened would be to scour Wikipedia for the discussion which led to the banning. On the other hand, the page was definitely too heavily editorialized. Opinions about the severity of someone's actions which ultimately resulted in a ban should not be expressed on the Project Namespace.
Maintaining a list of banned users might satisfy a few curious passers-by but not really. Only complex cases result in a ban and a link to one page would generally not be sufficient to explain the background. A likely result is that people would start good-faith discussions like this one which have nothing to do with improving the encyclopedia or the community. People would want to ask questions about ancient cases and would decorate entries with commentaries, while others would revert them to reduce the glorification, giving more drama. Ultimately,
WP:DENY is the only tool available and reverting, blocking and ignoring is best. Johnuniq (talk
) 23:38, 21 March 2019 (UTC)
@
WP:LOBU was still around, but I don't think there was any policy about what the ban reason should say. If the article specifically said as a heading "ONLY link to the page that ultimately resulted in the user's banning. Do NOT enter any more information" I think it'd be good enough to prevent them. As far as asking questions about ancient cases and such, maybe limit the list to being only bans in the past year. Rockstonetalk to me!
@DannyS712: -- I've done that, but I notice that a lot of times they don't have anything explaining the ban reason, usually it's just "This user is banned", and nothing more, unless you crawl through the talk page history of the user and investigate further, and even then sometimes nothing is found. Rockstonetalk to me! 00:26, 22 March 2019 (UTC)
@Rockstone35: are there cases when these aren't recorded in the Special:Log/block? For instance User:Buzzard74 contains no explanation on the user page or the edit summary that added the ban, but the block log identifies the reason (vandalism-only account, in this case). I know, technically bans are distinct from blocks (but usually work in tandem). I suppose records of blockless bans are scattered around various noticeboards. – Finnusertop (talk ⋅ contribs) 06:07, 23 March 2019 (UTC)
Blocks are logged by the software when they are imposed, there's no way around it. Bans are not settings that the software provides, so cannot be logged in the same way. So we maintain a wiki page like Wikipedia:Editing restrictions. --Redrose64 🌹 (talk) 15:07, 23 March 2019 (UTC)
Why list those, but not list bans? Rockstonetalk to me! 22:46, 24 March 2019 (UTC)
Have you read
WP:BAN, third paragraph (the one beginning Bans are different from blocks? They are not the same thing, the way that they are imposed is completely different - one is part of the MediaWiki software (and so may be logged), the other is not (and so cannot be). --Redrose64 🌹 (talk
) 23:17, 24 March 2019 (UTC)
Nope. Seems some sort of name and shame venture. There are cases where things are done discreetly and this will deflect unnecessary attention onto those cases. ∯WBGconverse 06:20, 23 March 2019 (UTC)
I've been on both sides of this discussion, back before it was deleted I was one of the people trying to clean it up and organize it better. It was a big job, and would be even bigger now. Keeping it up to date, including removing those no longer banned, was basically not getting done. At this point an actual comprehensive list of all banned users would be well over 1,000 names, some of whom were banned a decade or more ago and never returned. At this point I have question the utility of having and maintaining such a list for the sole purpose of satisfying people's curiosity about why persons on the list were banned. If you're that curious it generally is not that hard to find a banning discussion, it's often noted right in the block log.
talk
) 17:04, 23 March 2019 (UTC)
Visual editor
Hi people of English Wikipedia, I am a user from the Portuguese Wikipedia that wants to give a suggestion here of something the we, the portuguese users, have in our Wikipedia and you don't have here. The name of it can be translated to Visual editor (in our language: Editor visual), it basically is a different way to edit articles in the Wikipedia and it would be awesome to have it here. I will explain how it works, unlike in yours, our Wikipedia (the Portuguese one) have two different options of editing the articles: the normal version that you already have here (you go to this option there if you press Editar código-fonte) and the suggested visual editor that you don't have here (you use it if you press the button Editar [edit in portuguese is Editar]), with the Visual editor you can edit a article and see it in the same time, if you guys go to Portuguese Wikipedia, you will see the diference, I think the Visual editor would be good to beginners of english Wikipedia and for people that don't like or understand the normal way of editing.Xavier1824 (talk) 02:12, 23 March 2019 (UTC)
@Xavier1824: we already have the visual editor, but its just not enabled in all namespaces. Go to a random article, and in the editor click on the pencil icon in the upper right corner to change the editor. --DannyS712 (talk) 02:31, 23 March 2019 (UTC)
I saw it now, thanks for the notice, I though you didn't have that because I am used to see it in a namespace. Sorry for bothering.Xavier1824 (talk) 02:36, 23 March 2019 (UTC)
Xavier1824 there's a long story behind this, but I'll try to keep it short. In 2011 the Foundation published an official strategy to deprecate wikitext. They have partially backed off on that plan, but at least some staff continued to work to undermine/deprecate/hide/kill/sabotage wikitext. In particular, someone at the Foundation decided that having two edit links (wikitext and visual) was "too confusing". They initiated a project to convert all wikis to have just one edit link. When I saw that project I asked if they were going to try to deploy a Visual default for the one-and-only edit link. I was told No, they wouldn't do that without asking the community first. Half a year later they started deployment of the Single Edit Tab, here at English and a small number of other wikis. Visual Editor was the default for the one-and-only edit link. To get the wikitext editor you had to use the "switch editors" option within the Visual editor. People here angrily rejected the Visual default. I had to bring the issue to the Executive Director to get any response at all. Then another editor had to write a hack for the site-wide javascript which would override the Visual default. At that point the staff member had little choice, they changed English Wikipedia to use wikitext as the primary editor and Visual as the secondary editor. Their original plan was to deploy Single Edit Tab to all wikis (with a Visual default). However they suddenly stopped deployment of Single Edit Tab when the Visual-default plan failed. So now English is one of the only wikis with Single Edit Tab, and you need to use the switch-editors option inside the wikitext editor to get to the secondary editor. This is the exact opposite of what the staff member was trying to do. Note: If you go to Special:Preferences#mw-prefsection-editing you can set Editing-mode to "show me both editor tabs" or "always give me the visual editor if possible". That will give you links to both editors, or it will set the one link to Visual. Alsee (talk) 10:53, 23 March 2019 (UTC)
@Xavier1824: If you want to use Visual Editor on pages in other namespaces (I find it useful for WP:requested articles), you can go to the web address, find the part that says ?action=edit and change it to ?veaction=edit. It's not officially supported, so there may be bugs. — pythoncoder (talk | contribs) 16:38, 25 March 2019 (UTC)
Mandatory edit summaries
I'm getting a little tired of dealing with people who can't be bothered to use edit summaries. It's a little understandable from newcomers, but the people I'm seeing issues from are veteran editors or editors who have been actively around here long enough to know. Many tensions today could probably be avoided if people would use edit summaries to communicate effectively so other editors don't have to try to figure out why they made the change that they did. We can't read minds. When it's something like changing "the boy carries it's their toy" to "the boy carries its his toy", it's easy to figure out why that edit was made since it's a correction, but hardly any edits without summaries are actually like that. As such, I think we should have mandatory edit summaries. It's not 100% foolproof as I'm sure we'll have people who may just put a period in there so you can post something, but it'll definitely help. It's one thing not to use edit summaries when you're replying to someone on your talk page or when you're working on pages within your own sandbox, it's another not to use them on live articles. Amaury (talk | contribs) 16:21, 21 March 2019 (UTC)
<pedantry>Changing "the boy carries it's toy" to "the boy carries its toy" isn't a correction, it's just a different mistake; "the boy carries his toy" is a correction.</pedantry> Cabayi (talk) 18:56, 21 March 2019 (UTC)
@Cabayi: Bad example that I didn't realize then, but my point should still be understood. I've changed it above. Amaury (talk | contribs) 19:00, 21 March 2019 (UTC)
I wouldn't go so far as to make it mandatory but I try to use edit summaries and I appreciate it when others do so. I've turned on Preferences → Editing → Prompt me when entering a blank edit summary. Should that setting become the default for new editors and/or mandatory for IPs? Certes (talk) 17:02, 21 March 2019 (UTC)
Perhaps pointing out the preferences setting in the welcome messages would go some way to encouraging its use? (sorry about the pedantry) Cabayi (talk) 19:08, 21 March 2019 (UTC)
Making it mandatory won't make any difference. They'll just type a dot, or some random letters like "bgvvjkjh" and we'll be none the wiser. Some users have "Add two new dropdown boxes below the edit summary box with some useful default summaries" enabled and we still get hundreds of edits with an ES of "fixed typo" when clearly it wasn't anything of the kind. If they don't want to add a valid edit summary, there's not much that we can do to make them. BTW does anybody know what
WP:ESL. "No summary", perhaps? That's just as bad as a blank. --Redrose64 🌹 (talk
) 20:43, 21 March 2019 (UTC)
"No steganography"? (Look at their deleted contribs. WTF?) —
Cryptic
14:59, 22 March 2019 (UTC)
Redrose64 is correct. The editors who put just a dot would be almost exactly the same as those who omit editsums today—and they would resent being forced to type that dot. For newer editors, who may not be aware of the need for edit summaries, we can post {{uw-editsummary}} on their UTPs and hope they form the habit early. We can also add a userbox like this one to our user pages. ―Mandruss☎ 03:52, 22 March 2019 (UTC)
Something isn't necessarily any better than nothing, either. Edit summaries like "
Cryptic
14:56, 22 March 2019 (UTC)
Beats copying the comment into the edit summary, thereby saving people the "effort" of looking at the diff (and giving one's comments greater visibility than others, inconsistent with the spirit of
WP:SHOUT). Editsums have far less utility in talk spaces than in articles. But I digress. ―Mandruss☎
21:35, 22 March 2019 (UTC)
I feel like some social technologies would be more useful than programming here. For example, if we had some two-letter abbreviations that everyone accepted means "just continuing what I was doing last edit", "fixing what I just messed up last edit", "here's another source with more about this section" etc. Wnt (talk) 11:15, 23 March 2019 (UTC)
Technology that spots "/LE" in the edit summary box and converts it to "just continuing what I was doing last edit" shouldn't be hard. That way only the author needs to memorise the abbreviations, not the reader, and it may be possible to customise personal abbreviations. We already have that after a fashion: when I type in a few letters, it suggests previous summaries I wrote with that substring, though the automatic section link breaks it unless previous edits were to similarly named sections. Certes (talk) 11:51, 23 March 2019 (UTC)
I tried searching for such a proposal, but I didn't find one.
I'm an avid reader and occasional editor of Wikipedia. My two native languages are Albanian and Italian, but I am fluent in English and prefer reading every article in the "international language". Nonetheless, I stumble upon Italian articles now and then and I couldn't avoid noticing a great feature the Italian Wikipedia has and the English one does not. Article Peeking, for lack of a better name, means hovering with your mouse on a linked article to read a preview of that article. It works flawlessly and it always satisfies my need to know more about a specific word I read in an article, without distracting myself and starting to read a new article every few minutes without finishing the previous one.
I found a Firefox add-on that promises to do just that. It's called Wikipedia Peek and has good reviews but I'd prefer taking care of my privacy, and this add-on does not guarantee that. I don't want it to "Access my data for all websites" and "Access browser activity during navigation", among other things. I'd really love if the Wikipedia programmers added this feature natively to our beloved English Wikipedia.
Perhaps, this proposal has already been added with a different name/term and that's the reason why I couldn't find it. I'd love to know more about your opinions on this proposal.
Anonymous readers have this on by default, amusingly. For logged in users, you need to opt in. See Cryptic's comment. See also mediawikiwiki:Page Previews. --Izno (talk) 01:03, 22 March 2019 (UTC)
Cryptic, Izno, anyone else: Do you want this enabled by default? It feels weird to give people a tool and then have it disappear when they create their accounts. I can nudge that team if you think it's a good idea. Whatamidoing (WMF) (talk
) 20:58, 26 March 2019 (UTC)
@Whatamidoing (WMF): Opt out for new accounts makes more sense, yes. Though if I recall, doesn't the gear icon allow you to turn it off? --Izno (talk
) 21:01, 26 March 2019 (UTC)
For new accounts only, please; there's no way to tell whether an existing account with both previews and popups disabled has them disabled because they don't know about them, or because they know about them and turned them off on purpose and will be quite irate to have them forced back on again. —
Cryptic
21:37, 26 March 2019 (UTC)
Indeed; I don't have the discussion at hand, but I thought this is what was decided when it came up? For all these reasons, and not to muck with long-term editors who, perhaps, do more editing than reading. ~ Amory(u • t • c) 23:41, 26 March 2019 (UTC)
Thanks a lot
Cryptic
. You truly made me a big favour :)
Love your username by the way.
Take care.
-OrangeRaver
accessible captcha verification
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
This seems to be going offtopic and in circles now, time to close it.
The captcha accessibility issue is tracked in Phabricator at T6845. Whatamidoing (WMF) says her team is trying to work on it. Continued assertions here that it needs to be fixed are not likely to change the situation.
An RFC structured as a !vote would probably be more useful to show community support for raising the priority of the Phab task than a discussion that largely consists of one IP user repeating themselves at length, although Whatamidoing (WMF) might have better ideas than that. Ask her on her talk page if you'd like.
Volunteer developers are also free to take on the task, but do be aware it's not an easy problem.
The IP knows the options currently available to them: create an account, or continue to deal with captchas (which includes waiting until developers implement a non-visual captcha). They have offers of help in achieving the former, if they wish. Continued complaining here that they shouldn't be limited to just those options is not going to change the situation.
The issue of possible other identities or past misbehavior of this IP user belongs elsewhere (
Hello
I'm Ahab, a blind IP user.
I use a screen-reader called JAWS for Windows.
Currently, to do an in-line citation on Wikipedia I have to post external offwiki links, which triggers a captcha to filter out spam.
This would not be a problem but for the captcha system being exclusively visual with no accessible option.
Now you ask, "well why not just have your girlfriend Harriet read the captchas to you, can't you just do that?" Maybe, if she wasn't on the road all the time. This isn't just for me, this is for other blind IP users who get rather put off by their edits being constantly reverted by those either unable or unwilling to take the link fro mthe edit summaries I and other blind users provide. Take for example, Kether Donohue, where I edited the page to reflect a google books result I found that states she voices Ethel in Kappa Mikey, not Lily. A few users reverted it telling me to cite, which with the current captcha system is not doable for me.
So I propose either of the two following sollutions:
1. A more accessible captcha system with an audio option be put into place.
2. A group of editors start a page where blind users can come to a page, in a similar forwmat to
noticeboards
on wikipedia, and the users can look at the summaries of the edit and put the links in for the blind users.
This way you aren't shutting out a plethora of legitimate users who want to add sources, but can't due to the visual captcha.
I hope you guys get back soon.
Hello 199..., the immediate solution for you would be to create an account - this will allow you to bypass most CAPTCHA challenges. — xaosfluxTalk 18:10, 26 March 2019 (UTC)
Apparently my e-mail was associated with another account, I did get hacked in 2015
I tried creating an account in 2016 before I moved to Canada. Something does hav eto be done for I Pusers, not everybody can or will create an account
199.101.61.34 (talk) 18:35, 26 March 2019 (UTC)
An email address is not required to create an account, you can go to Special:CreateAccount right now and make one. After 4 days and 10 edits you won't get CAPTCHA's anymore. You can even use the same email you used before. I understand this isn't a global fix for CAPTCHA's for the sight impaired, just a possible way to possibly help you quickly. — xaosfluxTalk 18:38, 26 March 2019 (UTC)
(after edit conflict) It is not acceptable to expect a blind user to create an account in circumstances where a sighted user would not have to. I am sure that you,
Xaosflux said "immediate solution". He is helping with this particular users "immediate" problem, not solve it forever for everyone. That would be the Phab ticket. -- GreenC 18:51, 26 March 2019 (UTC)
(
Phil Bridger: I agree, just working within our current limitations. Even if we had audio or other accessible CAPTCHA's I'd still recommend an account to anyone regularly editing (regardless of ability) so they can avoid having to continuously answer challenges. — xaosfluxTalk
18:58, 26 March 2019 (UTC)
Also something should be done for other users.
Alls I'm asking for is either a different captcha system or else a group of users to help us with citations so I'm not dealing with reverts like what happened at Kether Donohue199.101.61.34 (talk) 18:42, 26 March 2019 (UTC)
If you ever need to, feel free to post on my talk page and I'll try to help you out by adding to source for you. Thanks, --DannyS712 (talk) 20:50, 26 March 2019 (UTC)
Pinging User:Graham87, who knows how to work around this. Note that CreateAccount requires solving a CAPTCHA.
199.101, I am really sorry that you got "bit" by this bug. Please accept my apologies. Solving the CAPTCHA problems is something my team has been pushing for for a long while now. A proper solution would work not only for people using screen readers, but also for people who can't type in English. I have been told that this would require multiple years of effort by a dedicated team, and we have not yet been successful in getting that major commitment prioritized. We'll keep trying, though. This is a serious problem that needs to be solved.
As an immediate workaround, the CAPTCHA system shouldn't be triggered unless the http:// or https:// prefix is present. So you might consider adding just the "www.example.com/specific-page" part of the source you're relying on. That might reduce the likelihood of people reverting you. Whatamidoing (WMF) (talk) 21:18, 26 March 2019 (UTC)
As I said the last time you brought this up, you can email me at grahamwpgmail.com with your desired username to have an account created with no captchas. I had never heard of a restriction about one email address per account; in fact I have just created an account, Graham87 the tester (talk·contribs), with my current email address with no problems. Any admin can help you the way I can by creating an account for you and adding the confirmed userright. Graham87 01:34, 27 March 2019 (UTC)
I do love the idea of an account, but I can only edit when I am here or when I have free time.
I have a few weeks off.
Harriet and I work for a group that helps disabled people around the world, her andI help fellow blind people in poor countries, and we're going to Mozambique, Zimbabwe and Angola on the 3rd and aren't back until May 30th. We have a couple weeks in between assignments, where I have time to contribute to Wikipedia, but you will notice lots of times where I am not present at all.
I got no problem with having an account, but what's going to happen is I am going to forget my password because I'll be busy in Africa and the Caribbean for most of the year, then I'll end u pcreating account after account and somebody's going to ping me for socpuppetry, and what not. So yes, I'd love to have an account, but given that I a monly free during some parts of the year, is there any point? thank you for the idea though, I will think hard about it.
Meanwhile something needs to be done for IP users, because shutting us out and saying "Create an account create an account!" isn't always going to help.
thanks.
199.101.61.34 (talk) 09:07, 27 March 2019 (UTC)
Another reason to get an account that is particularly relevant to blind editors is that the default
skin, Vector, has annoying dropdown boxes that can sometimes make it difficult to find certain Wikipedia features (they're not as bad as they used to be, but I still don't like them). For this reason I use the older Monobook skin and have also disabled the " Enable responsive MonoBook design" preference so that everything ends up being in a consistent location that I can easily get to with access keys. Graham87
12:14, 27 March 2019 (UTC)
Those are good features to know. It'll be better for me when I get back form Southern Africa for me to figure this all out as while I do have just under a week there are other things I have to do before Harriet and I take off. Internet I hear is not good in Mozambique, Zimbabwe and Angola after what happened.
199.101.61.34 (talk) 13:15, 27 March 2019 (UTC)
It is not necessary to furnish a URL to cite a book. If you were able to find something on Google Books, you should have plenty of information to cite the book without linking in to a website. Check out {{Cite book}} and associated templates. 2600:8800:1880:FC:5604:A6FF:FE38:4B26 (talk) 18:21, 27 March 2019 (UTC)
That's a good point. When I find a source via Google Books I tend not to link the result, because if I do I often find that the link becomes unavailable and then some well-meaning editor removes the reference as a dead link, even though it has full bibliographical information.
Phil Bridger: Have you tried the Wikipedia citation tool for Google Books? Among other things it optimises the URL so it is as short as possible, which probably reduces the chance of dead links. Graham87
I will look into that. I do think something should be put in place for IP blind users so that they can do the captcha, but just add an audio option. It shouldn't always depend upon them creating an account when a sighted person can just walts in with a good let's say BBC source, cite it and enter the captcha, then boom! all good.
It's not right that I have to create an account when others can use IP addresses. yes accoutns are a quick fix but should not be the only option. forcing me to create an account to avoid the captchas just doesn't seam right. No I'm not deminishing Graham's suggestion I love it, but "create an account!" just seams like a way to say, "well we hear you but the status quo is good enough, " when I'm trying to say it's not good enough. The captcha system needs to be updated from a 2010 style version to at least a 2015 style one that has an audio captcha option. Many other sights have what's called recaptcha, which has an audio option. Wiki is way way way way way outdated in terms of this, and I blame what I call status quoists that say "good enough, leave it alone, just create an account".
I may end u pcreating an account even though I really do not want to to be honest, I know I'll forget the password and I don't want to create an account. The reason for not wanting an account is because I have no idea how active I will be.
Remember, I take trips with Harriet where we go to Africa, the Caribbean and the Ukraine and other such places. Before February we were in Indonesia for about 4 months. I may or may not have edited form IP addresses in Indonesia, I have no idea. I'm usually out with other disabled people helping them out. I don't want to name our organization but we're not here in Canada or in the UK all that much, even though I now reside here.
That is why I do not want to create an account, not because it's a bad suggestion, but because I don't know how active I will be. Looking through various discussions over the years has turned me off of having an account, because I've seen people that are sporadically active, like me, get accused of being single-purpose accounts. (an/i really dammages Wiki's reputation with me). I've been taken to an/i when I edited from some UK IPs because they thought I was single purpose, liek back in 2016 or something like that.
What about blind users who have situations like mine, where they aren't overly active but still wish to contribute.
We can't all just edit wikipedia actively like a lot of you guys can. Yes you guys have offwiki lives too, but some of our lives are so busy that we'd rather edit as IP users because it's easier, we don't have to remember more passwords, and what not. Especially wit hsporadicly active users like me.
Honestly, the reason for my activity over the past month o rso is because I have more time off this year, but not much.
So it's better to have a recaptcha with an audio option than it is to force sporadic users to create accounts or else deal with impossible expectations and accusations of original research.
Sorry about the ramble. I just hope you guys know where I am coming from. Accounts sound great to me, but I don't want one due to me not knowing how much I'll use it if at all. Liek I said, while I got until the 3rd before we fly out, I do have to use that time preparing. It's not easy trying to make other disabled people in poorer countrys' lives easier, it's taxing.
Something should be done for all blind IP users, and I mean soon.
sorry for the rant, and thanks for the suggestions. I'll get back to you about the account in late may early June when I'm back.
tha
199.101.61.34 (talk) 20:33, 27 March 2019 (UTC)
Do we whitelist obviously spam-free sources such as the BBC so that anyone can add them without enduring a Captcha? Although it's not a solution and we need to do more, that might help. Certes (talk) 20:53, 27 March 2019 (UTC)
Most of what you are asking about (changing the CAPTCHA type) isn't something we have much control over here on the English Wikipedia, it is a multi-project issue and is being tracked in the phabricator records above. One thing we can do is whitelist certain known reliable websites so they bypass CAPTCHA's. The list of these is found here: MediaWiki:Captcha-addurl-whitelist. If you have suggestions for additions you can make them on the talk page of that page. Google Links won't be added there, but as listed above if you are citing a book, you should cite the book using its ISBN, not a google link anyway. Sites such as BBC are already included in that list. — xaosfluxTalk 21:00, 27 March 2019 (UTC)
I really hope something is done, because while I am not opposed entirely to creating an account, I do not want to create an account, and don't feel that I should be forced to, given I am sporadically active when I am in Canada or the UK.199.101.61.34 (talk) 21:28, 27 March 2019 (UTC)
My thanks to those of you who are working on this. I'm not sure why the IP won't file an edit request on the talk page for the article. I do think all of you should be aware of this IPs activities. First was
verify
their source as yet. Research by 2600:8800:1880:FC:5604:A6FF:FE38:4B26 has turned up the fact that this person has also edited as
two of which were blocked. I also note that they claimed to be from Yemen in the Kim Esty thread but also said they were native to Papua New Guinea in this edit. I have no problem with other editors continued
WP:AGF and if the info for the article can be sourced and changed that is great. I just think proceeding with caution would be a good thing as well. MarnetteD|Talk
01:02, 28 March 2019 (UTC)
I started a section on my talkpage where people can duke out whether I am these other 3 users or not.
I do see some similarities with the users between me and them, notably that the 23 IP and I are both blind. As per what I saw from the 199 IP addresses, I don't know what their problem is with the United States. I know mine is the war in Yemen, where I was born and grew up.
I am waiting for an admin I am speaking with to respond to this, so I suggest that we move that discussion to my talk page, dear MarnetteD.
Don't go around supposedly doing your exposé on people because it looks like you are just spreading things.
This issue is an important one, the one about the captchas as it does present a proble mt ousers who cannot see.
I wish I could see but I can't.
thanks, and please, go to my talk page and discuss my so-called history there.
thanks.
199.101.61.34 (talk) 02:14, 28 March 2019 (UTC)
I think it's best to have discussions in the one place rather than have them associated with a transient IP address. Yeah, I do have my suspicions too. Nahom, a name previously used by supposedly the same person, is a Mormon name, not an Arab one. Wiktionary lists Ahab as a very rarely used name ... and there's the song "Ahab the Arab". Graham87 02:23, 28 March 2019 (UTC)
I agree that we seriously need to fix out CAPTCHA and other accessibility problems. I know this isn't SPI, but frankly I can't be bothered opening one at the moment so I'll just mention this. I would caution spending too much time helping out this particular editor as I'm seeing a lot of similarities between this editor and Wikipedia:Sockpuppet investigations/Comet Egypt. Comet Egypt was originally called User:Nissae Isen's Man. I would note that a similar IP Special:Contributions/199.101.61.70 was identified as a sock back of Comet Egypt in 2016. I'd also note that Comet Egypt also stated they were blind and had an interest in voice actors of anime or cartoon series. My memory is people had trouble believing a lot of what Comet Egypt claimed about themselves e.g. Wikipedia:Administrators' noticeboard/IncidentArchive664#attempt to tone user down. Of particular interest is that the above IP editor just a few days ago claimed to have recently moved to Canada [3]. Yet Comet Egypt also seemed to edit from Canadian IPs and said they were from Canada [4] back in 2010 Nil Einne (talk) 05:07, 28 March 2019 (UTC)
@Nil Einne: Wow ... I did some more digging, and found this ... um, whaaaaaat? Graham87 07:03, 28 March 2019 (UTC)
Alright listen up, and listen real ultra super good. Anything prior to June of 2018 is not me, if itis a Canadian-based account. thisis Cuddlyable3 all over again.
While I was in the UK, I was accused of being a user called Cuddlyable3, they did some checks and guess what, negative.
Why do I get the feeling this is the same crap different country?
As for my name, I was named for my grandfather.
I want these gross accusations either explained or retracted immediately.
While I would love to be able to, I am not sending Wikipedia my birth cirtificates and immigration papers to prove that I am a Yemen-born UK immigrent who came to Canada in June 2018. I shouldn't have to go to such lengths to prove who I am. also let's for a moment say I was any of these Canadian users that I some how hid for ages, this page describes why you shouldn't always make wild claims as it's rather hurtful. I am genuinely hurt by these accusations because all I want is to be a good Wikipedian. No matter whether I am editing from the UK or here or even on the road when I go to Africa next week, I want to be a good Wikipedian without being accused of bull crap like this. Sorry for the language, but am I not entitled to be a bit annoyed when i have to go through this accusation crap all over again? First I was cuddlyable3, now I'm comet egypt. There had better be a really good explanation for this because otherwise you guys will have not only shut out a possible good editor from Wikipedia, but you also will have driven him away forever. Just some food for thought.
199.101.61.34 (talk) 09:30, 28 March 2019 (UTC)
199.101.61.34 (talk) 09:30, 28 March 2019 (UTC)
let's leave the socpuppet accusations here:
I can't speak for anything from Canada prior to June 2018, ok? done.
Back to th epoint of the discussion:
The captcha syste mfor Wikipedia, while necessary, is both out of date and inaccessible. It needs to be fixed so that other blind users much like myself who wish to make good faith citations won't be reverted or barred from editing.
Wikipedia is meant to be inclusive not exclusive, I hope.
199.101.61.34 (talk) 10:56, 28 March 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.
One thing is that the more shortcut you have, the more clashes you have with legitimate titles. For instead, someone could make a song named "
b
}
17:38, 9 March 2019 (UTC)
@
Hildeoc, Xaosflux, and Headbomb: technically, its fairly straight forward to create new "real" shortcuts ([5]). While I am not proposing that we create W, U, T, or H, I think there may be some benefit to creating CAT: as a real shortcut. Thoughts? --DannyS712 (talk
) 22:33, 17 March 2019 (UTC)
CAT:X instead of Category:X? I don't think that would be useful. Writing "Category" is not difficult and introducing new jargon does not seem worthwhile. Johnuniq (talk) 23:03, 17 March 2019 (UTC)
I don't think this is very useful. We do have a few XNSR's for CAT already but I can't see readers needing this. — xaosfluxTalk 00:07, 18 March 2019 (UTC)
Proposal to distribute print versions of Wikipedia
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Over the last decade, the Wikimedia Foundation has worked to ensure all humanity has access to Wikipedia. To aid in these efforts, I am proposing that we produce a print version of the English Wikipedia and distribute copies to any person or institution that requests them free of charge. My proposal has three main benefits:
A print version will be much easier to browse since no internet connectivity or technology is required to access it.
It is much harder for an authoritarian government to block access to millions of sets of print encyclopedias than it is for them to block access to a single website, so my proposal will fight censorship and promote the free exchange of ideas.
A print encyclopedia requires no electricity to view, so my proposal is environmentally friendly.
I truly believe that this proposal will allow unprecedented access to the sum of all human knowledge and vastly improve the human condition; never again will people be denied access to information on pre-WWI dreadnaughts, interstate highways, episodes of the Simpsons and obscure towns in Germany. Now, I know this may sound crazy but
Your signature has a beautiful date in it. --Izno (talk) 01:24, 1 April 2019 (UTC)
It doesn't work. I typed print Wikipedia into the command box top right, and all I got was this article. Certes (talk) 01:31, 1 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.
What links here option
I propose to allow a feature in the "What links here" to have the option to exclude pages where the only link is through a template. This would make it easier to clean up after a page move, so that only the pages that might need to be changed are shown. RedPanda25 17:05, 2 April 2019 (UTC)
This has been requested for many years; see phab:T14396. – Ammarpad (talk) 17:21, 2 April 2019 (UTC)
Good to know it's being considered at least then. RedPanda25 18:19, 2 April 2019 (UTC)
I'm wondering if it would be possible to implement multi-tier referencing in articles, using reflist for the important/major facts and, say, "refminor/reflist-minor" for the other items? As an example, the article List of bus routes in Melbourne should include a lot more references. Noting operators should be fairly easy with grouped listings (i.e. routes X/Y/Z are all operated by A, and so on), but the claims specific to each route should also be referenced to specific pages. However, if that was done currently the reference list would probably balloon out from 32 to about a thousand, and finding information quickly would be a lot harder.
The Arbitration Committee has resolved by motion that:
Pursuant to the arbitration policy's section on "Ratification and amendment", the Arbitration Committee resolves that the following change to the arbitration policy will be submitted for formal ratification by community referendum:
The final paragraph of the "Conduct of arbitrators" section of the arbitration policy is amended as follows:
Any arbitrator who repeatedly or grossly fails to meet the expectations outlined above may be suspended or removed by Committee resolution supported by two-thirds of all arbitrators excluding:
The arbitrator facing suspension or removal, and;
Any inactive arbitrator who does not respond within 30 days to attempts to solicit their feedback on the resolution through all known mediums of communication.
This amendment to the arbitration policy will enter into force once it receives majority support, with at least one hundred editors voting in favour of adopting it. Until this amendment is ratified, the existing arbitration policy remains in effect.
Display links to core content policies in editing interface
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)
Descriptive IP Welcomes
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.
RhinosF1, funny you mention that because I literally just created one last night for this exact reason. –MJL‐Talk‐☖ 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)
Added to page. –MJL‐Talk‐☖ 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.
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)
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 listRhinosF1(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
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)
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)
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)
Proposal: remove "reupload-own" from non-confirmed users
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:
Non confirmed user wants to upload something
Someone manually confirms the user
The manual confirmation is removed or expires, but the user hasn't been autoconfirmed yet
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. — xaosfluxTalk 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.
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 (talk • contribs) 16:23, 16 April 2019 (UTC)
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.--
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'.
Not only a gross misuse of this page, but it does look a lot like bad faith. Regrettably there is no account, so no accountability. One thing is without question, there is no potential benefit to leaving this open any longer. ―Mandruss☎ 19:13, 27 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'm not sure if I'm posting this in the right place or not. I've been a long time reader of wikipedia. I do not contribute much since I am not a great writer, but wikipedia is lucky to have others who truly are. There is one editor here that I believe deserves recognition,
user:BullRangifer. I have learned so much from his editing on political articles, especially from his contributions to the dossier article. He goes above and beyond to research the lies of Donald Trump and inform the world of them through wikipedia. I believe wikipedia's main purpose is to fact check. When public figures spread misinformation, we must tell the truth and ot been proven that Donald Trump lies more than anyone else. That is why need to document every lie he tells. Gone are the days when a president could be considered a reliable source. Unfortunately we do not have a president that can be trusted and BullRangifer knows this better than anyone else. Does wikipedia have some type of editor of the year award that I can nominate him for?70.89.22.217 (talk
I make no comment about your views in general, but must point out that the statement that "we do not have a president that can be trusted" does not apply to all of us editors. We are not all American, or otherwise citizens of countries that have a president, trusted or not.
Wikipedia is not meant to show political bias, so recognising editors because they support our political
WP:POV is not really something we would want to do. Nor is Wikipedia's main purpose to check fact; it is to create a summary of all human knowledge online. Clearly checking the veracity of statements and ensuring balance are key to that. Bermicourt (talk
) 18:40, 27 April 2019 (UTC)
I don't know whether this thread is sincere, or is some weird sort of trolling, but it is certainly a bit over the top in its praise and doesn't belong here. If you want to thank BullRangifer then
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.
Further discussion of recent RfC on organisation vs organization
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.
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. Number57 16:02, 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. Number57 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)
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
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.
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). Number57 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.
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. Number57 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,
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[6][7][8] 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)
Update: I've reversed the close of the said RfC; editors who are interested may continue commenting there. I'll probably also go ahead and re-mention this at CENT. Thanks, Lourdes 07:33, 18 April 2019 (UTC)
^"An RfC should last until enough comment has been received that consensus is reached, or until it is apparent it won't be."
Bring back Wikipedia:Featured portals?
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)
This is a good idea, but frankly the way things are going there soon won't be any portals left to feature. Even the manually-maintained ones are being MFD'd individually or in small groups. Unless the situation stabilises there's no point spending any time on portal improvement. Bermicourt (talk) 18:30, 22 April 2019 (UTC)
Twinkle for mobile
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,
☎
10:21, 24 April 2019 (UTC)
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)
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.
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
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)
@Headbomb: {{namespaces}} isn't a disclaimer - what do you want to do with that? — xaosfluxTalk 15:40, 25 April 2019 (UTC)
@
b
} 16:41, 25 April 2019 (UTC)
Ah OK! Thought it was part of 'these disclaimers' :D — xaosfluxTalk 17:24, 25 April 2019 (UTC)
Grant proposal to build a way of surveying, assessing and integrating large amounts of open license text into Wikipedia
Hi all
Over the past few years I’ve been working on ways to make it easier to reuse open license text from external sources in Wikipedia.
I’ve created very easy to use instructions and a metrics tool for open license text (much like our tools for image views)
.
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)
At a first glance I can see some problems with this proposal. Such content will usually conform to the
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
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)
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:, 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)
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
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.
Iridescent
21:20, 24 April 2019 (UTC)
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)
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)
Comments here are written on water - over at the actual proposal there are currently 15 supports & 2 neutral-ish. Just saying. Johnbod (talk) 01:41, 27 April 2019 (UTC)
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)
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 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 [9]Legacypac (talk
) 11:55, 14 April 2019 (UTC)
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)
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:MFDLegacypac (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
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?
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 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[10].
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)
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: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
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
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)
Article on ages which famous people would be today?
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)
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
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 Wellertalk 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)
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)
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)
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)
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.
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 about some indefinite IP blocks
APPROVED
Sometimes it even snows in May (yes, checking from my window, it does). Unanimous support. — JFGtalk 05:48, 5 May 2019 (UTC) (non-admin closure
)
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.
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 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)
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)
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)
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 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)
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)
Support This is a well thought out and convincing proposal. gnu57 12:41, 22 April 2019 (UTC)
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. --Jayron32 18:45, 22 April 2019 (UTC)
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)
Support Incredible that we have to have the converstaion though...ten years later. ——SerialNumber54129 17:55, 23 April 2019 (UTC)
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)
Yes, please. There's very little point now in keeping those old blocks after so much technological progress — on the Internet, at least. theinstantmatrix (talk) 04:38, 24 April 2019 (UTC)
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)
As far as I know the remedy hasn't be superseded or replaced, so those IPs (and any new ones they've gained in the interim) should probably be blocked. —A little blue Boriv^_^vBori! 20:52, 24 April 2019 (UTC)
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)
Open proxies aren't blocked indefinitely today. The actual restrictions say that Church of Scientology IPs should be blocked as if they were open proxies. * Pppery *has returned 21:52, 24 April 2019 (UTC)
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.
talk
) 22:17, 24 April 2019 (UTC)
Comment Someone should check to see
if the temperature's dropping. (NOTE:I mean that as in this proposal doesn't seem to have a chance at failing, rather than passing.) I guess the main thing to do is figure out logistics if that'll be an issue. John M Wolfson (talk
) 01:45, 27 April 2019 (UTC)
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)
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)
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)
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)
Support. Kevin (aka L235·t·c) 23:57, 4 May 2019 (UTC)
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)
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)
Strong support. 10 years is quite a long period for online. And re-blocks are cheap if the problem returns. OhanaUnitedTalk page 01:35, 5 May 2019 (UTC)
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)
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)
There's a complete list of the IPs in question at This quarry. There are around 20,000 of them. SQLQuery me! 02:15, 5 May 2019 (UTC)
Support -- with the exception of those IP addresses who were banned.. Of which, the banned wikipedia users category lists only two: User talk:128.90.64.1 and User talk:82.71.49.124. Other than that, they all should be lifted. Rockstonetalk to me! 04:53, 5 May 2019 (UTC)
Who cares about an IP banned in 2011 after fewer than 20 edits?[12] You can bet your bottom dollar this person is no longer at this address. — JFGtalk 05:43, 5 May 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.
New "Keyholder" user right allowing for those who have it to edit fully protected pages
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I would like to propose a new user right that allows a user to edit fully protected pages. This user right will be granted to editors who feel held back by their inability to edit fully protected pages, but do not desire to become an admin. InvalidOSFile:Pixel Art Chat Bubble.png 17:28, 6 May 2019 (UTC)
What benefit would this serve? The entire point of full protection is that nobody—not even admins except in exceptional circumstances—should be editing those pages. ‑
Keep in mind that without significant software changes,the ability to edit protected pages is the same as the ability to set protection levels on pages from a technical aspect. (See also phab:T71607). — xaosfluxTalk 17:48, 6 May 2019 (UTC)
Concur with those above me (although I edit-conflicted with the signature warnings). Although admins can edit a fully-protected page, it's normally interpreted as a direction that nobody should edit the page until some underlying dispute is resolved. But such a dispute normally also has many eyes on it and is not long-lasting, so requesting unrelated changes through {{edit fully-protected}} requests should be a relatively minor compromise. Ivanvector (Talk/Edits) 17:51, 6 May 2019 (UTC)
I'm just going to withdraw, close per
talk
) 18:08, 6 May 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.
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
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)
"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. -- GreenC
21:51, 3 May 2019 (UTC)
'Caucasian' meaning 'white' has a very American sound to me and Wiktonary largely agrees with me: wikt:Caucasian. Thincat (talk) 22:20, 3 May 2019 (UTC)
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)
Many terms that were originally a reference to a specific region have since taken on broader meaning. We talk about "vandalism" all the time on Wikipedia, but no one is complaining that we're being unfair to Vandals. --Ahecht (TALK PAGE) 17:58, 6 May 2019 (UTC)
Wikipedia is a non-American site too, I am an Eritrean-born Londoner who moved to Canada, never been to the U.S. and know only one American from Texas, and she's a history prof.
I will cnotact Green righ tnow, in th eprocess of that righ tnow.
How about if we put the explanation on th eAmerican people of Caucasus descent page, and change the people of Caucasus descent to people of Caucasian descent with an explanation.
thanks.
199.101.62.21 (talk) 01:06, 6 May 2019 (UTC)
Wikipedia:Nobody reads the directions. But perhaps a phrase like "the Caucasus mountain region" or "The Caucasus region of Eastern Europe" would be clear enough? WhatamIdoing (talk
) 06:04, 6 May 2019 (UTC)
It's unfortunate that in the US this term is essentially stripped of it's actual meaning and used to refer to any person of European/white descent, although I think that use is less common than it once was. This creates a strong possibility of it being misapplied to persons who are in no way descended from the people of that region. Therefore, right or wrong, I think it may be best to leave things as they are simply to avoid having to fix it 10,000 times when it is misapplied.
talk
) 20:30, 7 May 2019 (UTC)
I can't speak for the rest of the world, but in the U.S. "Caucasian" has a de facto primary meaning of "ethnically white". This creates an awkward linguistic issue, but we just have to deal with it as best we can. I support retaining the current category titles as the best available solution. Alsee (talk) 15:58, 8 May 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.
The "Article" tab on a redirect Talk page should go to the article, not to its redirect target.
The "Talk" and "Article" tabs should be a toggle: click one, and it should go to the other. Practically anywhere else in the encyclopedia, this is the case: if I'm on a Talk page of some article or project page, and click the "Article" or "Project page" tab, I go to the accompanying article, or Project page. Not so with redirect Talk pages, however. If I'm at Talk:This is a redirect page and I click the "Article" tab, it does not go back to the article, it goes to the target of the redirect. Not what I wanted. If I want the target page, I know how to get there.
I'd like to see this behavior changed. My guess is, a large majority of the time, someone on a Talk redirect page clicking the Article tab, wants to go back to the redirect article, not to the redirect target. If there's some legacy reason to keep this as the default behavior, then please at least offer an option in
ping
}} please.
Hi, @Mathglot: I believe this belongs to where you first posted it; that is VPT, as it's more a technical decision than a social one. This is not something ideal for a preference setting but you can ask at Wikipedia:User scripts/Requests if someone is willing to write some script for this. The task phab:T5324 was asking the same thing and was declined because if this is implemented there's no way to go directly to the target page without manually editing the URL, among other reasons. – Ammarpad (talk) 04:34, 9 May 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.
Add BibLaTeX citation entry to MediaWiki:CiteThisPage-content
Hi there, forgive me if I posted it in the wrong thing or if I repeated something. But my proposal is that if we have a page "Template:ABC", then {{ABC}}, {{abc}}, or even {{AbC}} should link to "ABC". Basically we don't check capitalization when transcluding or subsituting templates.
Sometimes I type things wrong (for example, the
WikiCat userbox). If I use the search bar, typing "Template:ABC" and "Template:abc" automatically redirects to "Template:ABC", but for transclusion, it does not. – Ben79487
04:31, 15 May 2019 (UTC)
This is in the realm of "not going to happen". --Izno (talk) 12:48, 15 May 2019 (UTC)
Page names are not case sensitive except for the first letter of the title and (except in the mainspace) the first letter of the main part of the title after the namespace name. To make transclusions work differently, or to make the Template: namespace work differently, is unlikely to happen. In cases where a particular letter would be likely to be uppercase where it should be lowercase, we have redirects (for example, {{
Automatic Taxobox}}->{{Automatic taxobox}}); however, we don't create these except where we believe them to actually be necessary. עוד מישהוOd Mishehu
13:39, 16 May 2019 (UTC)
Removing case-sensitivity on second and subsequent letters would create difficulties where we already have two (or more) templates whose names differ only in capitalisation yet have very different functions. For instance {{
Esp}} which now redirects to {{ESp}} but until about five years ago it had another purpose, it's been moved to {{E-sp}}. --Redrose64 🌹 (talk
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.
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)
@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)
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)
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)
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)
thanks for the {{clear}} info. I'll implement. Ian Furst (talk) 13:36, 3 May 2019 (UTC)
Some functionality like VE does not work in Wikipedia space. I guess we could move these to "Video:" which would be in main space but not sure if that would cause concerns User:Izno. Doc James (talk · contribs · email) 21:25, 3 May 2019 (UTC)
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)
It might come to talk pages per the recently completed consultation. But yes hope springs eternal.Doc James (talk · contribs · email) 22:51, 4 May 2019 (UTC)
You can actually use VisualEditor in any namespace if you add a "veaction=edit" parameter to the URL bar. I find it useful for Requested Articles. Actually, that's the only thing I use VE for. Let me add that to my user script ideas list... —pythoncoder (talk | contribs) 21:32, 7 May 2019 (UTC)
Support This would actually be better than the initial option IMO. Even though we have none articles in article space such as "lists" and "timelines" this route is not ideal for the video scripts. Doc James (talk · contribs · email) 22:04, 5 May 2019 (UTC)
support very good idea--Ozzie10aaaa (talk) 12:45, 8 May 2019 (UTC)
support Would a a tidy way of keeping track of them and an easy way to ensure that they are VE-editable by users who don't know the secret veaction=edit trick. T.Shafee(Evo&Evo)talk 07:32, 9 May 2019 (UTC)
Support videos for
WP:MAINSPACE articles. Only a handful of people are working on this. They will be mostly for medical-related articles at this point. They won't be for all articles. QuackGuru (talk
) 15:19, 9 May 2019 (UTC)
I will support any step that gets us closer to being able to produce documentary films under the Wikimedia banner, and this is definitely a step in that direction. bd2412T 15:07, 10 May 2019 (UTC)
Support A very nice idea to implement.
here
12:22, 11 May 2019 (UTC)
Support I really found it beneficial especially in the medical and scientific topics.--Avicenno (talk) 17:05, 13 May 2019 (UTC)
Support Why not.. let's try something out, can't hurt us. —TheDJ (talk • contribs) 07:20, 15 May 2019 (UTC)
Oppose creation of Video: namespace
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)
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)
wait: first this is a brand new technology with no demonstrated adoption yet; we need to understand how the community responds. Second: what about Commons? Shouldnt we be making these in a platfrom that supports the translation extension? What happens when English Wikipedia, yet again, adopts something and then refuses to shift to the more collaborative international space where it would benefit many more communities? I think its great to start running this experiment on enwiki, but if you want it to scale: it needs to be in a robustly international, scalable solution that is responsibly multilingual and inclusive from the start.Sadads (talk) 08:47, 7 May 2019 (UTC)
User:Sadads. Thank you for the feedback. The tool is being built with the express intent of reaching the non-english speaking minimally literate. Our motivation, is that there is strong evidence getting information from project medicine pages into the last mile of developing nations will save lives. Cholera and Dengue fever are both good examples. Once a script is created in english, it is being translated multiple times. The Videowiki player text-to-speech engine supports 21 language (plus several variants). This means the translator can publish their translated script (and link in the 'Languages' sidebar), and the video is ready within minutes to post on the local (non-english) page. Where a language is not supported by TTS, there is an easy way to overdub which will be shown in the history of the script. Part of the reason we're looking for a permanent home, is ensuring support for many languages means there are many links. E.g the script points to the player, the player points to the commons webm, the webm points to the article, then the article needs to point back to the script. For each language. As the number of scripts grows, the number of links connecting each piece grows by roughly ^4. Ian Furst (talk) 09:51, 7 May 2019 (UTC)
@Ian Furst: I think the problem with your solution, is that we are holding the information on different pages: so if you update one video, its very hard for the other languages to update to meet the changes made in that language. Whereas if we did the videos on a multilingual Wiki (i.e. Commons or Meta-- but probably Commons because its designed to distribute content), we could use the Translation extension -- or any subsequent multilingual-support that WMF provides via structured data, etc-- to make it sustainable and maintainable. Forking the videos on every single wiki, requires a much higher standard of maintainence that makes sense on big language wikis (i.e. enwiki or frwiki) but not on smaller languages where the communities have very limited capacity/attention for content maintenance. This is in part of the reason why English Wikipedia doesn't adopt or understand globally useful Wikidata content, while smaller wikis are gobbling it up -- leading to a huge knowledge gap that the core parts of the English Wikipedia community continues to ignore, because of their refusal to contribute to Wikidata.... I don't think your current approach makes sense because it fractures the community, rather than encouraging it to work together. Sadads (talk) 10:29, 7 May 2019 (UTC)
@Sadads: I'm a bit of a newbie, so if you could expand on this I'd appreciate it. At some point, there needs to be a script for the video, with links to any media. The Videowiki player pulls the text, media, and attributions from that single resource (the 'script'). Are you saying that if the script is hosted on Commons it lends itself to easier multilingual support? E.g. not just english to others, but others to english? If you have time, would appreciate the details. Ian Furst (talk) 11:56, 7 May 2019 (UTC)
I do not think Commons would be a good place. These scripts are collaboratively editable content. Not every language should have an exactly similar script just like not every language should have an exactly similar Wikipedia article. Have figured out how to get Content Translation to work. Not seeing the translation extension as suitable. Doc James (talk · contribs · email) 13:02, 7 May 2019 (UTC)
Oh - it's a machine translation of the text. I agree that this is not desirable. We've figured this out with the Hindi translations - what works in one language does not work in another (as a direct translation, or even the level of detail on certain slides). With that said, I now understand the benefit to text on .svg images - we need to make sure the player can add a white background to transparent slides so they're properly supported.Ian Furst (talk) 13:28, 7 May 2019 (UTC)
No, hosting them on Commons has nothing to do with machine translation. I think Doc James is suggesting that it would be more suitable to make the scripts localized via the Content Translation tool rather than hosting them on Commons where they could be localized via the Translate extension. Kaldari (talk) 23:15, 7 May 2019 (UTC)
User:Kaldari that is correct. And now that I see we are able to use Content Translation were the scripts are now, no significant need for a new name space at this point in time. Doc James (talk · contribs · email) 11:52, 8 May 2019 (UTC)
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)
Oppose. For one thing, free videos belong on Commons, not here. Collaboratively edited content, if multimedia, are appropriate on Commons; if there's a language-related problem, just upload a different copy for each language. Text dumps don't belong there, but scripts for Commons-hosted videos would be fine there. COM:SCOPE says "no raw text dumps" but then says However, Commons can be used to host such material if included in a shareable media file that is of use to one of the other Wikimedia Foundation-hosted (WMF) projects, so scanned copies of existing texts that are useful to other WMF projects (e.g. to serve as the basis of a reliable, verifiable source) are in scope. Also allowed are files which embody something of value over and above raw text. For example, files consisting of scans of out-of-copyright books, newspapers and the like which preserve original font, layout, embedded images and the like are within scope. Captions for Commons-hosted multimedia content are definitely embodying something of value over and above raw text. Aside from that issue...we already have the File: namespaces for pictures, sound recordings, PDFs, and videos. Why do we need a separate namespace for a few videos with a specific subject? Namespaces exist to separate pages that serve distinct technical functions, not to separate similar pages with unrelated topics. Nyttend (talk) 22:15, 7 May 2019 (UTC)
Agree completely free video belongs on Commons and that is were the videos go. What we are discussing is collaboratively editable video scripts. Doc James (talk · contribs · email) 01:33, 8 May 2019 (UTC)
Exactly. Please move the scripts with the videos, because otherwise they'll get moved by someone else and then speedy deleted under the transwiki criterion. Nyttend (talk) 04:58, 8 May 2019 (UTC)
The videos are on Commons. The scripts are here. The scripts do not work on Commons for a whole bunch of reasons. Doc James (talk · contribs · email) 11:42, 8 May 2019 (UTC)
Wait per John M Wolfson. I support this once the need has been demonstrated, but that hasn't happened yet. —烏Γ(kaw)│ 00:13, 08 May 2019 (UTC)
Oppose as premature. This initiative appears to be in its infancy and doesn't have widespread community support yet. We can revisit this matter in the future. -FASTILY 22:36, 8 May 2019 (UTC)
Oppose as outside the scope of Wikipedia. This is an encyclopedia,
not youtube. We are not the only place to collaboratively edit things, there are sister projects such as Commons, WikiBooks, and WikiVersity which all allow collaborative editing but whose mission is more in line with the goals of this project. If none of those are suitable then one can always propose a new sister project tailored to this mission. Just because these scripts create videos that may be used on Wikipedia does not mean they need to be hosted on Wikipedia. Wugapodes[thɑk][ˈkan.ˌʧɹɪbz]
16:47, 9 May 2019 (UTC)
Oppose per my comments below -- Colin°Talk 17:47, 9 May 2019 (UTC)
Oppose I think the whole concept is flawed, let alone creating a separate namespace for it. Examples that I saw had awful subtitling. They were useless for me, as a deaf person unless I paused every second or so. I can sort of understand a spoken wiki (blind people) but videos like the ones I saw some months ago are neither beneficial to the blind nor the deaf, and I suspect they're a tad difficult to edit but (I realise the contradiction) wide open to vandalism that is less likely to be spotted. - Sitush (talk) 18:26, 9 May 2019 (UTC)
Too soon: This new stuff is just getting out the door, we don't want it to be misused. Let policy and criteria for videos develop before we make a separate namespace. Kirbanzo(userpage - talk - contribs) 14:56, 10 May 2019 (UTC)
Not yet - this may be a good goal to work towards, but there are serious issues to work out before we implement it. Blueboar (talk) 13:20, 11 May 2019 (UTC)
Oppose, outside the scope of Wikipedia. This sort of content should be on Commons or another alternative outlet. Stifle (talk) 11:04, 13 May 2019 (UTC)
Strongest possible oppose, way outside the scope of Wikipedia. Generated videos might be in scope on Commons, but collaboratively edited scripts should probably be either in a new project, or on Wikiversity. rchard2scout (talk) 14:31, 14 May 2019 (UTC)
Oppose, if we want to have a video namespace, do it on Commons. (They have a featured media of the day!) – Ben79487 04:33, 15 May 2019 (UTC)
Oppose Too many issues. I foresee this going the way of WP:Books, which has its own rarely-updated namespace of crap. feminist (talk) 10:00, 15 May 2019 (UTC)
Oppose If it isn't broken, don't fix it. It's unneeded, and the new system could be easily confused. If it has to be done, at least trial it for a year in someone like Commons or WikiVersity. Then per all the above, we can come back to this after a year or so and see if it justifies another namesapce. The Duke 22:20, 15 May 2019 (UTC)
Oppose as per John M Wolfson. Could not agree more. — Preceding unsigned comment added by T2Bean (talk • contribs) 06:17, 18 May 2019 (UTC)
Move video scripts to Pseudo-namespace
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 as proposer. Less preferable than the one above. But will make it easier for more people to get involved. Doc James (talk · contribs · email) 10:19, 4 May 2019 (UTC)
Support. Makes it easier to distinguish and calculate stats. OhanaUnitedTalk page 01:37, 5 May 2019 (UTC)
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)
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)
support per above three editors--Ozzie10aaaa (talk) 12:47, 8 May 2019 (UTC)
support why not. namespace or pseudo space, it makes not difference to me in this phase. —TheDJ (talk • contribs) 07:21, 15 May 2019 (UTC)
Oppose pseudo-namespace
They are not articles. — JJMC89 (T·C) 21:42, 4 May 2019 (UTC)
That is correct, they are scripts that are collaboratively editable which than generate video. Thus why the proposal is to label them "Video:" Doc James (talk · contribs · email) 22:49, 4 May 2019 (UTC)
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)
Lists and timelines are not articles either... Doc James (talk · contribs · email) 22:00, 5 May 2019 (UTC)
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.
There's no need to worry about "changes required by the WMF" here, step 1 is by far the hardest one. Anomie⚔
23:36, 4 May 2019 (UTC)
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)
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)
Oppose until I see any convincing rationale that the File namespace is unsuitable — Martin (MSGJ · talk) 22:02, 6 May 2019 (UTC)
Oppose As noted above, the file namespace works for videos. Moreover, the pseudo-namespace would be confusing — we shouldn't have a significant number of pages called
Oppose. Pseudo-namespaces are almost always bad ideas. —烏Γ(kaw)│ 00:14, 08 May 2019 (UTC)
Oppose. Putting videos in Mainspace is a bad workaround for a problem that was created less than a month ago, and which can surely be addressed in a better way. For one thing, the Foundation appears to be seriously considering officially enablinge VE for all pages as part of the on-going Talk pages consultation 2019. Alsee (talk) 15:39, 8 May 2019 (UTC)
Oppose per above, and per my reasoning in the above section. -FASTILY 22:36, 8 May 2019 (UTC)
Oppose pseudonamespaces are just generally bad ideas for all the reasons above. Under no circumstances do these belong in article space. Wugapodes[thɑk][ˈkan.ˌʧɹɪbz] 16:56, 9 May 2019 (UTC)
Oppose per my comments below -- Colin°Talk 17:47, 9 May 2019 (UTC)
Oppose for the same reasons I gave regarding an actual namespace. Far too many issues for this to be moved over at present. - Sitush (talk) 18:28, 9 May 2019 (UTC)
Oppose per what I said above. feminist (talk) 10:00, 15 May 2019 (UTC)
Oppose I would support this if it was possible to create pseudo namespaces outside of article space but videos and their scripts do not belong in article space and this is not yet developed enough for a namespace of its own Abote2 (talk) 16:41, 18 May 2019 (UTC)
Discussion
Comment I'd like more information about the technology used for the text to speech in these videos. -- GreenC 23:34, 2 May 2019 (UTC)
User:GreenC it is an off the shelf text to speech reader.
The legal opinion on the copyright of the output is that it remains with those who wrote the underlying text.[14]
Additionally as the underlying text is CC BY SA the output text must also be CC BY SA.[15]Doc James (talk · contribs · email) 23:55, 2 May 2019 (UTC)
@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? -- GreenC 07:10, 3 May 2019 (UTC)
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)
@User:Anomie makes a good point. To make a informed decision, can you/(anyone) make a pros v. cons of 3 options (a) "as is" (b) "pseudo-namespace" and "video namespace". One of the biggest reason why we want are unhappy with the present (as is) solution is that Visual Editor isn't available which makes (a) content creation harder, (b) it is not accessible for inexperienced editors. --Pratik.pks (talk) 00:46, 6 May 2019 (UTC)
I refactored the discussion to make it more clear what proposals were being discussed where. If you feel where I placed your comment is not an accurate reflection of your position, please feel free to move it where you feel it fits. I'm pinging @John M Wolfson and Sadads: I created a new "oppose" heading under which I placed your comments and so you especially may want to review the refactoring. I'll also ping the others involved: @Doc James, OhanaUnited, Ian Furst, JJMC89, Anomie, Pppery, Izno, and MSGJ:Wugapodes[thɑk][ˈkan.ˌʧɹɪbz] 20:59, 7 May 2019 (UTC)
@Doc James: I'm struggling to see what function this has that can't be better served using Commons. Why should we host the video locally, when we have a regime in place to use them on all projects in all languages, along with a translation regime for both video content, subtitles, and references? True, we don't strictly have a standard format for referencing on Commons, but it seems like we could much more easily make one, along with making a translation space that is language specific, and could swap languages based on user settings using existing template formats. GMGtalk 00:18, 8 May 2019 (UTC)
@GreenMeansGo: the videos go on commons. What we are discussing however are the video scripts. This is collaboratively editable content. We are not wanting exact translations between languages of the scripts. We are wanting each language to be able to decide what text they use as well as what images or media files they use within each video. Doc James (talk · contribs · email) 01:42, 8 May 2019 (UTC)
@GreenMeansGo: From an accessibility perspective, the one realization I've had is that the videos need to be custom for each language. A straight machine generated translation doesn't (often) work well. If that is accepted, is there still a benefit to Commons? E.g. will the same Commons url host 20 different videos which can be selected from the languages menu? Where are you thinking about hosting the script which organizes the text and media? Ian Furst (talk) 01:27, 8 May 2019 (UTC)
Well @Doc James:@Ian Furst:, I'd preface this by saying that I am in no way a technical expert. Having said that, by "translation regime" I don't mean a process of machine translation. What I mean is a preexisting community of human translators (including a level of user access that doesn't exist on monolingual projects at all). I also mean a level of preexising technical support for multilingual work. For example, I don't leave a new user a "Spanish welcome message" on Commons; I leave them "a welcome message" and they see it in whatever language they speak. They don't even need to be aware of it, because it's automatically set according to their home project.
Again, I don't know the technical details of the script you've set up here, but it doesn't seem that it would be intuitively difficult to combine it with the use of multilingual templates so that we keep the sources, the description and the media all together on the file's description page. As far as I'm aware, the referencing function is native to Mediawiki, and exists even on projects that don't use it. So that much would just be a matter of importing individual citation templates, as has been done over time at Wikiquote.
Another issue is the attribution. The media you have here locally links "down" to the media on Commons, but it doesn't appear that the source media links "up" to the video, whereas Commons already has a preexisting method of doing that. You have attribution but it's messy and duplicative. You also have verifiability, but it's similarly messy, with the sources housed on an entirely different project from the media itself.
Beyond that, if this requires a technical implementation, such as the creation of a new name space, then I don't see why we should use our efforts at a local implementation that would need to be duplicated across hundreds of local projects, when we could have a single global implementation. GMGtalk 12:47, 8 May 2019 (UTC)
User:GreenMeansGo With User:pythoncoder providing me details on how to get Content Translation (CX) working on these scripts I am happy to withdraw this proposal. Being able to use CX was the main justification for the proposal in the first place.
When you say "the media you have here locally" User:GreenMeansGo to what media do you refer? The videos are on Commons such as here. And what do you mean here "the sources housed on an entirely different project from the media itself" What "source" are you referring too? The text for the videos is derived from English Wikipedia. The scripts contains media from Commons but so do standard Wikipedia articles.
How is the attribution duplicative? Each media file is attributed. Each component can have a different license so we list each. Do you have suggestions for a more condensed method?
With respect to "the source media links "up" to the video" this is indeed something that still needs to be build. The tool that will accomplish this will be a bot on Commons. Doc James (talk · contribs · email) 13:02, 8 May 2019 (UTC)
As far as I'm aware, the referencing function is native to Mediawiki, and exists even on projects that don't use it. Completely doesn't matter, but the referencing function is actually provided by mw:Extension:Cite; but it is indeed enabled on every Wikimedia wiki. Galobtter (pingó mió) 13:04, 8 May 2019 (UTC)
@Doc James: What I mean (and probably didn't express very well) is that you have two attributions, one on the English Wikipedia page here and one on the Commons file page. The attribution here is the link to the file description on Commons (which runs into copyright issues if piped elsewhere), but you also have to attribute it to the source media on Commons or risk it being deleted there. So you have to attribute everything twice. If the "source" of the video (the..."stuff" it is drawing from on en.wiki in order to generate the video) was housed on Commons, then you already satisfy the attribution simply by making the "source stuff", and every time the video is changed you don't have to change the attribution on two different pages, on two different projects.
As far as the sources, the sources are housed here locally yes. But that presents a non-trivial barrier for example, a user coming from de.wiki to Commons, finding a video, and then having to come to en.wiki to find the sources. It's a long standing problem anyway of users finding themselves on Commons and not realizing that they've left their local project in the first place. Also en.wiki is not exactly "renowned" for being a "friendly place" to people who show up and don't speak the local language (outright hostile is probably a better description). So if someone is trying to translate it and has to ask a question in German, they're pretty much SOL, and are going to just as likely get booed back to de.wiki by the locals.
Again, without the detailed technical expertise, I don't see why each file on Commons couldn't have a corresponding "source template" housed on Commons, placed on the file description. This main source template would then have sub pages for each language, just as the the main welcome template on Commons has sub pages for /en, /de, /ar, and so on. The sub page for Template:Wikipedia-VideoWiki-Typhoid fever.webm/Source/en would itself house the markup that is currently locally kept at Wikipedia:VideoWiki/Typhoid fever. The template itself would satisfy the attribution requirement merely by existing, without the need for the unwieldy mess at c:File:Wikipedia-VideoWiki-Typhoid_fever.webm#Licensing. GMGtalk 13:34, 8 May 2019 (UTC)
There are two parts to attribution of the creators. One is for the text of the script and the other is of the images. One is attributed on WP the other is attributed on commons and within the video itself. With respect to supporting multi lingual translation of medical content, we have done fairly well here on EN WP Wikipedia:WikiProject_Medicine/Translation_task_forceDoc James (talk · contribs · email) 13:47, 8 May 2019 (UTC)
Question: is there any reason why this should be limited/focused on medical topics? feminist (talk) 09:53, 12 May 2019 (UTC)
Why is this being proposed as a request for namespace when in fact what needs to be discussed is whether Wikipedia should host such article-summary-videos at all and whether the proposer's and creator's claims of "collaboratively edited videos" is accurate. Without a community debate on this, the creation of a new namespace seems very premature. These videos were previously discussed at Wikipedia talk:WikiProject Medicine/Archive 122#Video Wiki where various false claims were made.
The creator of VideoWiki (Pratik.pks) calls these "collaboratively edited videos" -- Let's be clear: the video content is not "collaboratively edited". The VideoWiki system links a collection of existing images and videos hosted on Commons, with effects and transitions applied. The only thing that can be collaboratively edited is the narration. Creation of actual video content remains very hard and non-collaborative.
The main pusher of these videos on Wikipedia is Doc James, who previously had a personal collaboration with a commercial video training company (Osmosis) that imposed 300+ videos onto medical articles. These videos contained factual errors and failed our policy requirements on verifiability. The video content could not be community edited and each video contained promotional material advertising the training company. When the inclusion of these videos were challenged by editors knowledgeable about the article subjects, Doc James edit warred to maintain them. They were eventually all removed after an RFC.
When James previously introduced the VideoWiki to the medical project (Wikipedia talk:WikiProject Medicine/Archive 122#Video Wiki) he dishonestly used the example at Acute visual loss. This is actually a commercial video (https://medskl.com/module/index/acute-visual-loss) by yet another commercial training video company (MEDSKL) in private collaboration with Doc James. The video was released with a free licence so James chopped it up into segments, uploaded them to Commons, and replaced the human narrator with the VideoWiki narration. He then created the article Acute visual loss with text similar to the commercial video narration. This was then promoted as an example of "the easy creation of videos from scripts". What became very apparent is that these professional quality videos are not "easy to create" but require professional tools and real artistic talents.
The videos are in fact glorified PowerPoint slideshows with tedious robot narration. It is fine to listen to Alexa for a few seconds while she reads out the lead sentence of a Wikipedia article. It becomes tiresome to do this for several minutes. The slideshows generally repeat images already present in the article, combined with some cheesy stock images of people holding test tubes.
The narration scripts are article forks. So not only do you have to watchlist the main article but also the narration article. This doubles the exposure to vandalism, and is especially a concern while/if few people actually watchlist those narration scripts.
The slides used for the video are especially vulnerable to vandalism. Most media files on Commons are watchlisted by one user: the uploader. If an image is maliciously overwritten then it may be noticed by anyone looking at the article that uses them. But if the slide is part way through the video, then nobody will notice unless they look at the narration page (which won't appear on your watchlist as being changed) or watch the whole video.
Every time the narration text or choice of slide images is "collaboratively edited" someone needs to publish a new video on Commons overwriting the existing one. COM:OVERWRITE specifically forbids overwriting files with edits that may be considered contentious and are not of the most trivial and minor nature. You can remove a dust spot in the sky or straighten a horizon, but if anyone on Wikipedia thinks you can start "collaborating" or "fighting" over video content hosted on Commons, then I have news for you. All parties blocked. And indef blocks for anyone persisting. Commons is not a collaborative editing project: it hosts stable media files.
When source images do not fit the 16:9 aspect they are stretched (for example the start of the Polio video). This and other restrictions of the image format may lead to editors modifying existing in-use images to suit the video, thus disrupting the other uses such as thumbnails.
The quality of the end product is really dire. When similar videos, taking Wikipedia text & images and creating a slide-show + robot narration, started appearing on YouTube, they were recognised as a cheap con to try to earn a few $$ off of Wikipedia content alongside advertising. They would show up in your search results but after watching and listening for a few seconds, you realised you'd be conned and clicked back. James has previously highlighted the viewer stats for such videos, as proof that they are useful, failing to realise that the stats only show people falling for the con and accidentally watching a few seconds. Youtube banned monetising such videos and discourages their creation.
James has made claims that a WMF survey asked for more Rich content (multimedia). These and the other commercial videos are offered as examples of meeting that request. However, WMF did not discover exactly what is meant by "Rich content (multimedia)" and so claiming that "A robot-narrated article summary with slide show" meets that need is challengable to say the least. FWIW I think we could do with lots more very short video clips that illustrate something (e.g. a child with polio walking) but it could also be interactive media. For example Body mass index could include a calculator for users to find out their own BMI.
James and Pratik.pks claim some people are "visual learners" and so Wikipedia should serve that need for people who don't want to (or can't) read a lot of article text. The problem with this is that the concept of "visual learner" is pseusoscientific nonsense thoroughly debunked. We have no evidence that anyone benefits from the narrated-slide-shows James has created. When a blind user of Wikipedia was asked for their opinion, they said they were of no use and screen readers already provide the narration required.
When James says "A few of us" he really does mean a few. James, Pratik.pks and Ian Furst. That's not exactly a community. Really this needs to extend beyond Doc James and his wiki friends before it can realistically be considered. The fact that it has failed to engage wider editor involvement suggests James and Pratik have developed a half-baked "solution" to a problem Wikipedia does not have.
@Colin: You are entitled to dissent and make criticisms of VideoWiki as a tool. However, going personal (especially the petty attack/portrayal of James) is not cool. I will not reply to your claims (which are derived either from assumptions or from half baked understanding of VideoWiki's features). We will have an Rfc on adoption of VideoWiki (when it is ready), and please feel free to criticize it all you want that time. I will definitely get back to all your points. Pratik.pks (talk) 16:56, 8 May 2019 (UTC)
Pratik.pks, my comments about James aren't just random personal attack or off-topic complaints. They are directly relevant to James current promotion of your VideoWiki tool. The conflict-of-interest promotion of Osmosis videos, the edit warring to force them onto medical articles where editors did not want them and found faults in them, the dishonest claims that Osmosis videos could be edited by the community, and the dishonest presentation of your VideoWiki tool using professionally created video material are all documented facts. You persist in using the phrase "collaboratively edited videos" when it has been previously demonstrated that the "video" content is not collaboratively editable. That's just not cool, in my book. Further, I don't think either you or James really understand Commons and how hostile the reaction will be there if this was ever to grow beyond a few wikifriends mucking about. You have created a "slide-show with robotic text-to-speech narration", which is a long way from the sort of quality video I can get when I turn on my TV or find a decent YouTube channel. This isn't what Wikipedia is about. -- Colin°Talk 22:08, 8 May 2019 (UTC)
Excellent arguments. As much as I like visualization, the Video namespace means slipping into
WP:NOTREPOSITORY and the existing media content has proved itself sufficient for supplementing text. Brandmeistertalk
14:19, 8 May 2019 (UTC)
I've a few thoughts on the comments above:
Re: Osmosis videos - the whole videowiki system is a vital part of addressing the shortfalls of the osmosis videos - that they were not easily editable. There is a clear need for an integrated open source video editor so that video clips / images / text can be combined and edited (indeed there is also a need for a user-friendly, integrated image editor, even if it's only for cropping images). Existing videos could be similarly trimmed into sections and re-combined in VideoWiki. For users that don't want videos in the leads or later sections, it should be possible to include a preferences setting.
Re: the inclusion of video summaries of the abstract: Wikipedia has had full spoken articles since at least 2005, and this sort of platform would be considerably easier to edit and update than full-length articles, let alone edit videos that are currently on Wikipedia as single blocks.
I agree videowiki attempts to address the problem that the narration of externally created videos is not practically editable or referenced. But it does so with a robot voice, which is not engaging for periods longer than seconds. Fundamentally, though, it does nothing about the generation of engaging video (visual) content. There are commercial packages that create the "doodle videos" used for teaching but there is no open-source equivalent and such tools need to come with freely-licensed clip-art libraries or else used by very talented artists. Then there's the question of how would one make such video-creation and modification a collaborative process. So we have no community method of creating and maintaining videos. Just a way to combine existing media into a slide-show and add robot narration. The idea of using a "Video" namespace is part of the dishonesty along with claims for "collaboratively edited videos" -- the video part of these audio-visual media files is not collaboratively edited at all. There might be a place somewhere in the Wikimedia universe for this project, but it isn't Wikipedia. -- Colin°Talk 18:06, 9 May 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.
Perhaps "religion" should just be changed to "predominant religion". Vorbee (talk) 17:44, 25 May 2019 (UTC)
I want to clarify. I think the Religion syntax field could stay or could be changed. However more precisely a comment <!---->next to the “Religion” field syntax could clarify what should be put down. For example, the field “native name” in the Former Country syntax |native_name = <!--Name in a modern syntax of native language(s). Leave blank if name is only in English. Separate with line breaks or use Template:Plainlist. If language uses Latin characters, place name(s) in italics.-->Manabimasu (talk) 00:02, 26 May 2019 (UTC)
New WikiProject or it's all the same
Hi all! Nice to be on here. I am very very interested in the history of the RMS Titanic and her passengers and crew. There are multiple articles about the Titanic, my question is, is there an existing Titanic WikiProject? and if not, should it be created? Feel free to give your opinion whatever it is. Kind regards. Best wishes. --LLcentury (talk) 17:31, 26 May 2019 (UTC)
LLcentury, While I'm sure there are a number of articles, that strikes me as a narrow scope for a Wikiproject. Have you considered a task force?
I have interest in women's basketball, and wanted a place for like-minded editors to visit but I wasn't ready to turn it into a full-blown Wikiproject, so I created the women's basketball task force which is a joint venture of three relevant wiki projects. S Philbrick(Talk) 18:44, 26 May 2019 (UTC)
Sphilbrick, Thanks so much!, I just joined the WikiProject and proposed the creation of the task force. Multiple thanks! --LLcentury (talk) 18:55, 26 May 2019 (UTC)
Make italic-title pages show up in italics on watchlists, what links here, and user contributions pages
We have a template to make article titles that should be italicized (e.g, The Merchant of Venice, Citizen Kane, The Dark Side of the Moon, Roe v. Wade) show up at the top of the page in italics. I think that it would be potentially useful for this presentation to extend to watchlists and what links here, and user contributions pages, so that editors looking at these pages can immediately tell that the article being referenced is one that is supposed to have an italic title, and in particular can immediately tell whether a page has a descriptive title because it is actually describing something, or because it is a media name that has been titled that way by the author. bd2412T 21:10, 25 May 2019 (UTC)
No, we already use italics to denote redirects. It would be confusing. --Redrose64 🌹 (talk) 21:39, 25 May 2019 (UTC)
Isn't it kind of confusing to use italics to denote redirects where the redirects themselves do not have italic titles - but redirect targets might? bd2412T 22:02, 25 May 2019 (UTC)
{{
DISPLAYTITLE:
}}. This is not only used to italicise, it can also set a different font (colour, face, size, variant, weight etc.), this is done on a per-page basis. So if a watchlist displayed edits to fifty different pages, each one of those fifty pages would need to be opened in order to extract the display title.
For redirects, they don't need to be opened: the page name table has a flag for whether or not the page is a redirect. You can see this in action by going to e.g. Category:Living people - each italicised entry is a redirect. --Redrose64 🌹 (talk) 22:24, 25 May 2019 (UTC)
Isn't that just keyed to the existence of #REDIRECT on the page? I don't see how this would technically be so different from keying to an instance of {{Italic title}} on the page. bd2412T 22:29, 25 May 2019 (UTC)
It isn't keyed to text on the page; it's keyed to tjhe page's status as a redirect. This is technically different from keying it to a {{DISPLAYTITLE}}. עוד מישהוOd Mishehu 12:47, 28 May 2019 (UTC)
I think it is best for a watchlist to show the canonical page title, which at present is a plaintext title without any formatting. isaacl (talk) 18:51, 26 May 2019 (UTC)
Agree. Additionally, this is not something we can do here on enwiki; it would require a software development task to render all of these pages with whatever their display titles are - and on some isntallations display title is not restricted and can have all sorts of nastiness in it. — xaosfluxTalk 15:51, 28 May 2019 (UTC)
User:Bahamut0013, once a Wikipedia administrator, passed away in 2011. He has three draft essays in his userspace, which I gather he had in mind to move to Wikipedia space when they were completed. I thought perhaps the community might want to look at these and determine whether any or all of them should be moved to Wikipedia space.
To the extent that these might be improved, I believe that it is within the spirit of Wikipedia for any editor who sees fit to adopt one of them and shepherd such improvement. Cheers! bd2412T 02:11, 30 May 2019 (UTC)
I liked CSIOR and moved it to Wikipedia space. I've made a few changes so it makes sense outside user space as well. I've struck it. Wugapodes[thɑk][ˈkan.ˌʧɹɪbz] 23:41, 30 May 2019 (UTC)
I really wish it would be possible to respect Bahamut's wishes that his essays remain in userspace. Risker (talk) 00:58, 31 May 2019 (UTC)
I don't think we can say that we knew what his wishes were. He made these pages, possibly with the intent of eventually moving them to project space. Sometimes people do that. He knew as well as any seasoned editor that content created in any space on this platform can be edited by anyone. If what he wrote is useful to the community, then we should maximize its accessibility to the community. bd2412T 01:05, 31 May 2019 (UTC)
And if eventually contested in project space, they of course could be moved to user space honorably... —PaleoNeonate – 03:25, 31 May 2019 (UTC)
I would hope that if moved to project space, this would reflect the consensus of the community, so they could stay there. bd2412T 04:01, 31 May 2019 (UTC)
Consensus of the community? Seriously, we have two people saying "yeah, let's take the personal essays of a deceased Wikipedian, written 8 or more years ago, and make them formally recognized Wikipedia essays." I'm sorry, I did work with Bahamut, and I'm pretty certain if he wanted them in Wikipedia space, he would have put them there. Risker (talk) 05:26, 31 May 2019 (UTC) Looking further, it's clear that he saw them as personal essays where he actively opposed others inserting information into them, which means that anything done after his death (except for routine maintenance) was probably done against his initial wishes. He hadn't edited any of these three personal essays for months if not years prior to his death. Please reconsider. Risker (talk) 05:42, 31 May 2019 (UTC)
I agree with bd2412 that like any good editor, bahamut0013 likely understood that while we respect a user's personal space, ultimately userpages belong to the wider community (see e.g.
WP:UP#OWN). Because of the license, I could have just copied and pasted the text instead of using the move function, but that's substantially more work for the exact same outcome. I think the essay has value to the community and others may want to work on it (there have been subsequent edits after my move in fact), so I moved it to project space so that changes bahamut0013 could not revert don't get added to an essay that would appear to be his personal opinion. In the wiki spirit, we should take his good ideas and build upon them, not fossilize them. Wugapodes[thɑk][ˈkan.ˌʧɹɪbz]
I suggest making it possible to thank IP edits, because there is a chance that the IP user still uses the same IP address, so the next time the IP editor opens Wikipedia, (s)he will be shown a “thank you”. The editor might be more motivated when receiving acknowledgement. –Chanc20190325 (talk) 18:12, 1 June 2019 (UTC)
The inability to thank IPs is a feature, not a bug. Many IPs are dynamic, and in some English-speaking countries like the UK IP addresses are hyper-dynamic (a single editor can easily go through a dozen different IP addresses in a day). Since on the balance of probabilities, any editor reading Wikipedia from a given IP address won't be the same person who last edited using that address, allowing the thanking of IPs would just confuse editors who would wonder why they were being thanked for edits they had nothing to do with. Remember, all someone has to do is read Wikipedia to get the thanks notification. ‑
Iridescent
18:19, 1 June 2019 (UTC)
Some UK ip addresses are dynamic, many or most not. The probability of 2 incarnations of the same ip number both editing WP is pretty low, I'd have thought. Many of the dynamic ones are the very long ones - the short ones tend to be static I think. Johnbod (talk) 18:31, 1 June 2019 (UTC)
Iridescent
19:08, 1 June 2019 (UTC)
(adding) Regarding Wikipedia, "most are not [dynamic]" is definitely incorrect. Mobile has overtaken desktop, and every mobile edit (or view) is by definition on a dynamic IP. ‑
Iridescent
19:10, 1 June 2019 (UTC)
Non-logged-in editors (I wish we didn't use this term "IP editors" because everyone edits using IP) have talk pages. If the address appears to be used by the same editor consistently then you can leave a message there saying "thank you for this edit", preferably with a personalised sentence or two that will make it much more valuable than a boilerplate message.
A proposal for WikiJournals to become a new sister project
Over the last few years, the WikiJournal User Group has been building and testing a set of peer reviewed academic journals on a mediawiki platform. The main types of articles are:
Existing Wikipedia articles submitted for external review and feedback (example)
From-scratch articles that, after review, are imported to Wikipedia (example)
Original research articles that are not imported to Wikipedia (example)
As it says at the very top of that page, WP:VEF is no longer monitored by WMF staff. All of the replies that begin with "User agent:" in small type use VisualEditor's feedback link (inside its "?" menu), and it'll take a Phab task to get those sent to MediaWiki.org. (Doable; it's just a config change, but someone's got to do it.) The mw.org feedback pages use Flow, so people will see replies via Echo/Notifications, so that needn't be a concern.
Iridescent, AIUI the WMF doesn't have any particular need to have anything VE-related on this wiki any longer. Presumably stuff should be kept around in archives, etc., as usual, but if you merged and (soft-)redirected a lot of pages elsewhere, I don't think anyone would care. Whatamidoing (WMF) (talk
) 05:21, 3 June 2019 (UTC)
RfC: Apollo 11 anniversary and the Main Page
Please comment on the discussion at
WT:TFA about the Main Page for 50th anniversary of Apollo 11. --- Coffeeandcrumbs
03:33, 8 June 2019 (UTC)
Category:Aristocrats
In a
aristocrats"). The main things to notice are that it does not have a clear distinction between living and dead nobility, and its used for nobility the people and nobility the idea, so the category is overused in those two big ways. Any comments? -ApexUnderground (talk
) 23:54, 7 June 2019 (UTC)
Aristocracy is probably better due to such confusion, although "nobility" and "aristocracy" are used in that context in approximately the same frequency in the US (which admittedly doesn't have one). – John M Wolfson (talk • contribs) 19:21, 8 June 2019 (UTC)
I seem to agree, but others seem to prefer the other one (hence the CFD link).-ApexUnderground (talk) 19:25, 8 June 2019 (UTC)
Names of articles on
subreddits
The current articles on subreddits on subreddits follow the format /r/[subreddit]. This makes no sense to me as they are pronounced r slash [subreddit] and are displayed as r/[subreddit] on
I've had a look at both MOS and prior VP discussions and didn't see anything clear on this. I'd like one of the MOS brigade and/or one of the active reddit page writers to provide their thoughts because there might be some specific reason. You are definitely right as to the standard usage/naming (in effect, COMMONNAME). Nosebagbear (talk) 12:45, 6 June 2019 (UTC)
Speculating: one reason may be that without the initial slash DISPLAYTITLE or {{
lowercase}} is needed in order to prevent the title from showing as R/[subreddit], and because that code does not affect the WP URL or how the article appears in categories, those will always have the R if an initial slash is not used. (check out how r/changemyview
now looks in its categories.) 14:49, 10 June 2019 (UTC)
I've seen both used on Reddit (for example, the /r/subreddit form links just as well as r/subreddit in the code) and the coding issue here is a legitimate concern. Typical readers don't necessarily browse categories, though, so I feel like that's less of an issue. I don't mind either way. -A lad insane(Channel 2) 18:32, 10 June 2019 (UTC)
IIRC, it used to be (on Reddit) that only /r/subreddit links worked. r/subreddit links were introduced later (a couple of years ago). That's why /r/ links are still used in many places, and both are equally valid. From what I can tell, most official documentation produced by Reddit uses /r/ links, but even they are not completely consistent. rchard2scout (talk) 11:00, 11 June 2019 (UTC)
As from my observation, I've seen both of /r/ and r/ being used across Reddit so I think I will wait for other comments.--
here
17:27, 12 June 2019 (UTC)
Allow bureaucrats to quickly re-sysop admins temporarily de-sysoped by WMF for carrying out out community consensus
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I propose the adoption of the following policy:
If a Wikipedia administrator is temporarily relieved of their administrator status by the Wikimedia Foundation for carrying out an administrative action for which local consensus had been established, their administrator status may be restored by any Wikipedia bureaucrat without further process, upon request from that editor immediately upon expiration of any period of de-adminship specified by the Wikimedia Foundation.
For no particular reason, I just think this would be good policy to have around in case the WMF happens to de-sysop an admin for carrying out a consensus-based action, and specifies a time limit for the expiration of this penalty. bd2412T 19:31, 12 June 2019 (UTC)
Adminship on this project is a measure of the community (and the Arbitration Committee)'s trust in an editor, not a measure of the Wikimedia Foundation's trust in that editor. Thus, unless there's some indication that the office-desysopped admin has lost the community's trust (which is clearly not the case for both of the admins the WMF desysopped recently), then there is no cloud and their admin rights should be restorable on request. * Pppery *it has begun... 01:41, 12 June 2019 (UTC)
There is no recent consensus that is contrary to this proposal. bd2412T 19:55, 12 June 2019 (UTC)
I misread the proposal. If you are suggesting people should be immediately resysoped after a temporary desysop by an office action, the I oppose. They should have to go through RFA to see if they still have the trust of the community like anyone else who loses their admin priviledges. AdA&D 20:02, 12 June 2019 (UTC)
Oppose as written above, at the very least I'd want to see the person that access will be added to acknowledging that they want the access added to their account, such as a request at BN. — xaosfluxTalk 19:53, 12 June 2019 (UTC)
Additionally, the "time limit" could be anything - "temporarily for 10 years" is still "temporary", and the editor could no longer be other wise fit or eligible. As a bright line, I'd only want to see something like this applied for short term (i.e. less than 1 year) events. — xaosfluxTalk 19:55, 12 June 2019 (UTC)
Oppose Local consensus cannot be determined in one or two days. There was no consensus in the case with Floq, which IMO shows bad decision making and has made me lose confidence. In addition, the reasons for WMF to be involved at all apparently have to do with legal and safety issues which we should not get involved with. I encourage discussing the issue with WMF, but for us to just reverse everything we don't like is wrong. Megalibrarygirl (talk) 19:58, 12 June 2019 (UTC)
Oppose per Xaosflux, but would support if "upon request from that editor" were added. SeraphimbladeTalk to me 20:03, 12 June 2019 (UTC)
Support Xaosflux’s version as a partial defense against WMF idiocy. —pythoncoder (talk | contribs) 20:11, 12 June 2019 (UTC)
@BD2412: this same discussion was pretty much already started at WT:ADMIN, I suggest combining these. — xaosfluxTalk 19:51, 12 June 2019 (UTC)
Restored this comment that was summarily removed by User:Anne_drew_Andrew_and_Drew with a reason of "nah". If you object, just say so. — xaosfluxTalk 20:18, 12 June 2019 (UTC)
Whoops, an honest mistake. Edit conflict or something. AdA&D 20:55, 12 June 2019 (UTC)
Since this affects me, I thought I'd comment. I was fully aware that this would likely result in my desysop, so I don't think I deserve the admin bit back, and I'm happy to defer to whatever the en.wiki community decides. A couple of notes:
WMFOffice's description of how I get the bit back after a month is unclear. I suspect because they don't know how en.wiki works. They say "a RfA can be opened once 30 days elapse, and the community may decide on the request at that time in such or another way" (emphasis mine). I interpret this as saying that any process the community decides on is OK. But I might be biased.
If they actually meant that an RFA is required, I don't think WMFOffice should be able to specify how I get the bit back after a temporary desysop expires. If they wanted it permanent barring a new RFA, they should have made it permanent. If the consensus of the en.wiki community is that no RFA is required, I will not be following that particular specification in WMFOffice's sanction (if that's what they meant).
I do not plan to ask for my bit back until (a) Fram is unbanned, or (b) Fram's ban is confirmed by an en.wiki process
If it is determined here that an RFA is required, I will probably just remain a non-admin. That may change depending on circumstance and how I feel after a month. But right now I feel too old to go thru that shit again.
Perhaps those who confidently throw around the accusation that I'm just interested in "protecting an abuser" will notice a pattern in the words I choose to highlight here.
Oppose This would not be helpful - it would only increase tensions in any situation where it is invoked, rather than leading to a solution. Mike Peel (talk) 20:53, 12 June 2019 (UTC)
Good in principle but oppose This puts a huge interpretation task on the 'crat to interpret "local consensus" and "temporarily" and make the resultant decision to override WMF. If WMF does stuff that is so stupid that a quick override decision by a single 'crat is called for, that's pretty crazy. North8000 (talk) 20:58, 12 June 2019 (UTC)
To be clear, I'm fairly sure the proposal is for what to do after the WMF desysop expires. --Floquenbeam (talk) 21:10, 12 June 2019 (UTC)
Oppose. Wheel-warring with WMFOffice is a horrible display of poor judgement, especially when it is done in defense of someone banned by the WMF for "harassment and/or abusing others", based on evidence you are not party to. If the Office didn't desysop, presumably ArbCom would have, which is a cloud. If you think they still have the community's confidence, send them through RfA. ~ Rob13Talk 21:12, 12 June 2019 (UTC)
Unnecessary A "temporary desysop of X days" is by definition temporary, ie, the Office or bureacracts (as the case may be) are obliged to restore the bit at the end of the period unless Office/Arbcom decide to up the penalty in the meantime. Barring that last scenario, we don't need an RFA; we don't need the admin to be "carrying out an administrative action for which local consensus had been established"; and we don't even need the ex-admin to place a request. Compared with a time-defined block, the only difference is that the the available interface (afaik) does not allow for a pre-scheduled change of user-permissions and therefore the mechanical action of restoring the bit needs to be carried out by persons with the technical ability. But this should not blind us to the fact that the decision to restore the bit has already been made by the authority who imposed the "temporary desysop of X days". Abecedare (talk) 21:30, 12 June 2019 (UTC)
Symbolic "support". I realize that this is never going to happen, but I want to express my support for the idea that this desysop was handled abysmally by the WMF. --Tryptofish (talk) 12 minutes ago
Comment restored after unexplained rollback by Mojo Hand -- AdA&D 21:37, 12 June 2019 (UTC)
Oppose - If for some reason an admin has been desysoped by the WMF, even temporarily, it is likely that they have done somethig that may call into question the community's trust. If they haven't, they should be able to pass an RfA, StudiesWorld (talk) 21:41, 12 June 2019 (UTC)
This is not true. Floquenbeam's unblock of Fram clearly did not indicate a loss of the community's trust. * Pppery *it has begun... 23:11, 12 June 2019 (UTC)
I don't trust him worth a damn, at the moment, and based on conversations I've had with others who are trying not to wade into things, a good many others don't as well. If you believe Floq has the community's trust, why are you (supporters collectively, not just literally you) so afraid to put that to the test at RfA? ~ Rob13Talk 04:37, 13 June 2019 (UTC)
Support. Benjamin (talk) 23:08, 12 June 2019 (UTC)
Support – If the community loses trust in an admin, we have ways to handle that. Maybe they aren't very good ways, but that's not the issue here. The community grants adminship indefinitely to trusted editors without condition except that they keep the trust of ArbCom and the community. RFAs do not expire. We do not require admins to have or keep the support of the WMF, and our policy should assume good faith on the part of admins even where the WMF concludes they were wrong, unless the ArbCom or the community does too. This is different from some other types of desysoppings in that it doesn't mean either has changed its mind, and it should be treated like other desysoppings of admins we still trust. To respond to some points above, I don't think many people would disagree that holding more RFAs is not likely to decrease tensions. It is not wheel-warring to undo an action after it was intended to expire. I think we can assume that when an office action expires, the WMF has determined that there are no legal or safety implications we should be concerned about with undoing the action. KSFT(t|c) 00:29, 13 June 2019 (UTC)
Oppose seems reactionary and poorly thought through. If we want to resysop Floq, we have
Oppose this seems unnecessary and vague. It was clearly meant to apply to Floquenbeam, except that it doesn't seem to clearly apply to Floquenbeam without further discussion. As I explained in detail here [16] it's thoroughly unclear if Floquenbeam was even carrying out a consensus based action. Nil Einne (talk) 03:13, 13 June 2019 (UTC)
Support T&S shouldn't be fiddling with advanced permissions, temporary measures, or local sanctions. They should have only the one tool that they have ever needed for their legitimate purpose of ToU enforcement of serious, legally necessary sanctions: the global permanent ban. And that should be appealable to Jimbo, a remit he may delegate on a case-by-case basis to specific projects' arbcom-equivalent body, if he so chooses. EllenCT (talk) 03:15, 13 June 2019 (UTC)
Oppose. The proposed policy does not explain how to determine whether "local consensus had been established". Many editors associate the term local consensus with
WP:CONEXCEPT prohibit overriding office actions, and any policy of this nature should require community-wide consensus, not just local consensus. — Newslingertalk
07:05, 13 June 2019 (UTC)
Oppose - I'm concerned that this might be an example of hard cases make bad law. Evidence and discussion is in a very dribbling sense. Thirdly, RfAs have a much wider footprint - they're watchlist advertised. It wouldn't be unreasonable for some individuals to say they weren't aware - at least in the case of "unaware of the idea of resyopping an admin without an RfA", even if they were aware of the initial issue. Personally I suggest an alternative, not needing a rule change (obviously assuming Floq's criteria had been met). Start the RfA 24 days after his desysop - allowing a close as soon as it's finished. Nosebagbear (talk) 09:11, 13 June 2019 (UTC)
Oppose any change to policy, as on the rare occasions this situation will arise, each case will be different. ‑
Iridescent
09:27, 13 June 2019 (UTC)
Oppose per Iri. Hard cases make for bad law. ∯WBGconverse 09:36, 13 June 2019 (UTC)
Oppose We need a full RFA to decide if such admins should have their tools restored. —
Oppose Per others. An RfA is really the best method to determine if the actions that lead to the desysop are truly supported by community consensus. --AntiCompositeNumber (talk) 11:58, 13 June 2019 (UTC)
Oppose We must have very different definitions of "clearly". I'm not seeing clarity or consensus here. Hawkeye7(discuss) 12:55, 13 June 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.
gmail.com with your desired username to have an account created with no captchas. I had never heard of a restriction about one email address per account; in fact I have just created an account, Graham87 the tester (talk · contribs), with my current email address with no problems. Any admin can help you the way I can by creating an account for you and adding the confirmed userright. Graham87 01:34, 27 March 2019 (UTC)
Resolved
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)
