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. — xaosflux ^Talk 01:25, 3 March 2019 (UTC)

(edit conflict)When one is proposing a change or a new rule, it is always helpful to identify what problem is being solved by the proposal. Users being forced to retain user rights they don't want isn't and hasn't ever been a problem that I'm aware of. Beeblebrox (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 (talk) 01:49, 3 March 2019 (UTC)

  (edit conflict) @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. Headbomb {t · c · p · b} 01:53, 3 March 2019 (UTC)

  You have a valid point that users can just stop using their rights, but regardless of that it does sometimes happen that users request that an admin remove them from certain groups (See User_talk:Swarm#Hello, would you be able to remove my templateeditor rights. for one example), so it isn't entirely pointless. {{3x|p}}ery (talk) 01:58, 3 March 2019 (UTC)

• 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. — xaosflux ^Talk 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. ("ExampleUser (talk | contribs | block) changed group membership for ExampleUser from extended confirmed user, rollbacker to extended confirmed user (completely voluntary temporary relinquishment, not under any sort of cloud at all, not faced with any sort of torches or WP:PITCHFORKS for edit warring, nothing to worry about when I ask for it back in a month)). Granted, one could find a sufficiently-gullible admin to remove sans comment, though I'd hope they'd at least glance at the requester's talk page first. —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. –Davey2010^Talk 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 Headbomb's tongue in cheek advice to simply stop editing in such manner that the permission would otherwise allow.--John Cline (talk) 16:35, 9 March 2019 (UTC)

• Oppose. There is no need to create the possibility for additional concerns at WP:ANI or 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. Phil Bridger (talk) 20:05, 14 March 2019 (UTC)

• 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. CASSIOPEIA^(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 WP:AN and it was dealt with in a matter of minutes, so I'm still unclear on what problem would be solved by making this change. I can see needless problems arising from it, but I can't see what actual benefit to the project there is here. Beeblebrox (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. Phil Bridger (talk) 20:05, 14 March 2019 (UTC)
• 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)

By default, there is "cite web", "cite news", "cite book", and "cite journal" under the cite tab on RefToolbar 2.0. Example: https://en.wikipedia.org?pojem=User:Ylevental/sandbox&action=edit

However, magazines are a popular medium of information, so "cite magazines" should be added to the options.

I tried proposing it on Phabricator and it was closed (https://phabricator.wikimedia.org/T219083) Additionally, is it better to propose it here or on Wikipedia:Village pump (technical)? Ylevental (talk) 00:24, 24 March 2019 (UTC)

Wikipedia talk:RefToolbar or WT:RefToolbar/2.0. --Izno (talk) 00:52, 24 March 2019 (UTC)

@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)

www.astronomia.sk | www.biologia.sk | www.botanika.sk | www.dejiny.sk | www.economy.sk | www.elektrotechnika.sk | www.estetika.sk | www.farmakologia.sk | www.filozofia.sk | Fyzika | www.futurologia.sk | www.genetika.sk | www.chemia.sk | www.lingvistika.sk | www.politologia.sk | www.psychologia.sk | www.sexuologia.sk | www.sociologia.sk | www.veda.sk I www.zoologia.sk