TestWiki:Community portal/Archive 3

Assume good faith
Hi everyone. Please see the proposed policy Assume good faith and let me know if you have any problems with it. Otherwise, it can be set to policy page. Naleksuh (talk) 04:53, 14 September 2020 (UTC)
 * - Only due to the considerable lack of content in the policy. If were to add more content, description, etc., then based on the content I would probably change my current  to .  What do you think of the policy? BlackWidowMovie0000Editor (talk) 18:29, 26 October 2020 (UTC)
 * I have removed the support/oppose sections you added, because this is not a numerical vote. As for it being short, you are free to expand it once your block expires. Naleksuh (talk) 01:17, 27 October 2020 (UTC)
 * I am not going to expand it right now for a couple reasons. First, it is YOUR policy. You get to make it, make the decisions around it until it is ready. Also, I am really busy right now with a lot of things, sorry, but I'll get around to it as some point if I can. BlackWidowMovie0000Editor 20:32, 27 October 2020 (UTC)
 * That's fine, you don't have to expand the policy, but I would just note that it is a draft policy, and this isn't yet a community vote to adopt a finished policy, so anyone is encouraged to contribute, or not contribute, to said draft policy. It's not just up to Naleksuh, even though he did propose it for discussion. Secondly, I do find it a bit interesting that you're citing the same rationale I have given you for not being able to look at certain things you've asked me to look at it. Finally, any reason why you've chosen not to include a link to your user talk page in your signature, or was that just an oversight? Dmehus (talk) 20:42, 27 October 2020 (UTC)
 * I made that rationale up on the spot, probably remembered it from when you told me it lol. And there was no link to the talk page because I needed the block to expire to set my new signature, you'll see it in this message. Also, just a quick question. You can't upload files to loginwiki, how do you get a picture to get onto the global userpage? 22:39, 27 October 2020 (UTC)
 * You can use Miraheze Commons to upload images that can be used on any Miraheze wiki Naleksuh (talk) 23:28, 27 October 2020 (UTC)
 * Thanks! 00:12, 28 October 2020 (UTC)

Inactive Rights Removal - 2020-09-22
The rights of the following users will be removed on or after 2020-09-29 if they do not return to activity:

Thanks,
 * RhinosF1 (talk)
 * For the Consul Team
 * 14:36, 22 September 2020 (UTC)
 * ✅ per the Inactivity report. Dmehus (talk) 23:35, 1 October 2020 (UTC)

Forum error
I attempted to close a test forum topic, but got a MediaWiki exception for database query error. Anyone else experiences this? Naleksuh (talk) 06:49, 5 October 2020 (UTC)
 * When the conditions of the abuse filter are met, a database query error was displayed, but I'm not sure if it is related to this case.--松 (talk) 12:45, 5 October 2020 (UTC)
 * I haven't tried to close a forum topic, but I do get similar errors when editing a forum's description or adding forum description that exceeds 255 characters. That's likely a bug and should be upstreamed (assuming Wikimedia Phabricator handles that). I also plan on creating an upstream task to revamp the extension's error handling to instead reject the user's input where it's not acceptable (i.e., descriptions greater than 255 characters). For that reason, I don't plan on using the WikiForum extension here for anything other than strictly testing purposes, at least until most of the bugs are fixed. Dmehus (talk) 16:20, 5 October 2020 (UTC)

I'm trying to adapt an archive bot to this page and Rp, what about the time to archive?
Would you want it to be the same as meta?--松 (talk) 12:40, 5 October 2020 (UTC)
 * I do not think an archive bot is necessary here. Especially for pages like cp that should definitely be manual archive. Naleksuh (talk) 15:55, 5 October 2020 (UTC)
 * Thank you for the question. I wondered about enabling archiving on the community portal, but given the length some discussions may stay open for (usually can be closed after 5-7 calendar days, but some may need longer, to encourage participation), I tend to agree with Naleksuh here that this page should be manually archived. I must say, though, that I am generally quite happy to have Request permissions being automatically archived again, and on a shorter timeframe (14 days versus the previous 60 s d when Revibot last operated here). Dmehus (talk) 16:15, 5 October 2020 (UTC) Amended 18:04, 5 October 2020 (UTC) by Dmehus (talk)
 * 60 s as in 60 seconds? Revibot only wakes up every 24 hours (and do nothing for the rest of the day), so anything less than 1d or 24h practically becomes 24h. &mdash; revi  16:43, 5 October 2020 (UTC)
 * &mdash;revi LOL, no I meant 60d, yeah. Thanks for the head's up on my inadvertent typo. Dmehus (talk) 18:05, 5 October 2020 (UTC)
 * Thank you for the comment.Certainly, this page also seems to double as a meta RfP.By the way, if we manually archive a section that uses a ping template, wouldn't we ping it again?--松 (talk) 22:25, 5 October 2020 (UTC)
 * No. Echo requires the signature of the editor for their "ping" to function [to be precise, either one of (userpage|user talk|contribs page)], in this case Revibot, and Revibot never signs their post. &mdash; revi  14:59, 10 October 2020 (UTC)
 * Thank you for teaching me.--松 (talk) 01:11, 11 October 2020 (UTC)

Inactive Rights Removal - 2020-10-19
The rights of the following users will be removed on or after 2020-10- if they do not return to activity: Thanks,
 * ; now active
 * ; now active; subsequently resigned
 * ; now active; subsequently resigned
 * ; now active; subsequently resigned
 * ; now active; subsequently resigned
 * ; now active; subsequently resigned
 * ; now active; subsequently resigned
 * Dmehus (talk)
 * For the Consul Team
 * 14:43, 19 October 2020 (UTC)
 * Do you intend to use the rights within the near future? If you don't, you can always just ask for them back then rather than make 1 edit every few months. RhinosF1 (talk) 13:16, 21 October 2020 (UTC)
 * , I am really very busy with my personal life. If you'd like to remove then go ahead and I'll ask you once will be back to the normal. Regards, ZI Jony  (Talk) 14:17, 21 October 2020 (UTC)
 * It's sound like real life is keeping you busy, so am going to go ahead and mark this as ✅. Thank you for your service. When you're able to volunteer with TestWiki again, please rerequest rights at Request permissions or on the user talk page of any Consul. Dmehus (talk) 14:24, 21 October 2020 (UTC)
 * ✅. Dmehus (talk) 15:08, 26 October 2020 (UTC)

Proposal: Remove "autopatrolled" and "confirmed" user groups
Similar to the reason rollbacker was removed. Sysop is granted more readily than those groups, and are generally only used by sysops granting it to themselves for hat collecting. Naleksuh (talk) 22:48, 30 October 2020 (UTC)
 * The thought had crossed my mind to remove either  or  ; however, I am reluctant to do that mainly because we do get known or trusted users who come to TestWiki on occasion to test a few things, but they don't necessarily need nor want   privileges and, because   is not granted automatically by MediaWiki software until at least 10 edits are made and four days has elapsed, they don't have the user rights inherent in those groups. So these groups are mainly used not for requests but rather for administrators, bureaucrats, and consuls to grant to known or trusted users to eliminate the need to patrol their edits&mdash;much like on Meta. If administrators are hat collecting, any bureaucrat or consul can remove the unnecessary duplicate user groups after a reasonable period of time as "test done" or something like that. If they re-add the user groups, we wouldn't remove the groups again, as that wouldn't be appropriate, but instead engage with them on their user talk pages to have them provide a valid reason for the extra user groups, not including hat collecting of course. If no valid reason is provided, then we would remove the extra user group(s). Dmehus (talk) 23:31, 30 October 2020 (UTC)
 * True, it is common for established editors on other projects to then come here, which is especially an issue with confirmed. But I don't see why they couldn't simply be granted administrator then. Unlike other wikis where adminship may require an RfA process or entail obligation, that is not the case here and infact autopatrolled is harder to get than administrator. So I just don't see where it would ever come up. Naleksuh (talk) 05:56, 31 October 2020 (UTC)
 * That's true, though we do want to make administrator and bureaucrat granted only by request (ideally on-wiki, but on Discord and IRC is also acceptable per local customs and practices), mainly to prevent new administrators and bureaucrats from granting rights to users who haven't requested them. What about this idea, merging the user rights from confirmed into autopatrolled, deleting the former group? Related to that, what do you think about deleting the forumadmin user group, since the rights are all included within administrator? Dmehus (talk) 17:52, 31 October 2020 (UTC)
 * How about changing "sysop must be given on request" to "sysop must be given for a reason"? That is to say, that it being requested is a reason, that the user is trusted on other projects is a reason, but that the user simply registered is not a reason. Is that okay? Naleksuh (talk) 18:39, 31 October 2020 (UTC)
 * Hrm, that would be a major change to our existing practice, though. I'd say I'd favour merging confirmed into autopatrolled and deleting forumadmin. This would allow for the same net result of two unnecessary duplicate user groups to be deleted. If users unnecessarily add autopatrolled as obvious hat collecting, any consul or bureaucrat can simply remove the hat. I don't see a massive need to upend our existing practice just for the sake of not interfering with a user's rights log, if that was your concern against removing the duplicate hats. Dmehus (talk) 18:59, 31 October 2020 (UTC)
 * Okay, so I'd be okay with that merge. However, that's not to say it is the permanent solution, and changing the sysopship policy could still be discussed. Naleksuh (talk) 19:19, 31 October 2020 (UTC)
 * Personally, I'd like us to keep the groups. My main reason is the fact that this wiki is supposed to simulate a MediaWiki environement, and that usually includes such groups, so I believe it's useful to keep the groups and allow users to test them out. Reception123 (talk) 20:53, 31 October 2020 (UTC)
 * True, and while I was waiting for your reply, I thought of another idea, what about discussing a Hat collecting policy to formalize a procedure by which certain positions (whether consuls, bureaucrats, and/or administrators) may remove user groups from other users after a set minimum time where all user rights are contained in one or more other user groups that the subject administrator also has. It would be inspired by English Wikipedia's policy of the same name, but it would be written and adapted for TestWiki's purposes.
 * I should also mention that I did discuss this proposal with, and he reminded me that autopatrolled is a useful test group (besides testgroup) that is also part of the core MediaWiki software. One of his main reasons for creating TestWiki with was to have it as a fairly pure MediaWiki configuration. Certainly, we've added extensions over the years, and even deleted some groups, such as rollbacker and interface-admin over the years; however, we do want to keep at least some of the default non-administrator user groups, I think. Dmehus (talk) 21:00, 31 October 2020 (UTC)
 * Autopatrolled is not a default group. The only default groups are sysop, bureaucrat, bot, and interface admin. So if we are keeping groups for being default, interface admin probably should not have been removed. However, it might have a reason to remove autopatrolled in that case. Naleksuh (talk) 21:35, 31 October 2020 (UTC)

Question Regarding Reverting Edits on User Sandbox
If I test stuff on my sandbox (under the User namespace), do I still need to revert edits? R4356th (talk) 19:50, 10 November 2020 (UTC)


 * R4356th In general, no. My only concern is with protecting your sandbox then deleting your sandbox, I'd prefer you remove the protection first prior to deletion. But, no, you can actively tinker as much as you want in subpages of your userspace and no one will question you, unless you revision delete something that doesn't need revision deletion, of course. Hope that helps. Dmehus (talk) 21:01, 10 November 2020 (UTC)
 * ✅, thanks to . — Preceding unsigned comment added by R4356th (talk • contribs) 10:04, 11 November 2020 (UTC)

Superfluous page
, If you guys don't mind, can I delete Policies as it's practically a duplicate of Category:Policies? --Sabelöga (talk) 17:22, 21 November 2020 (UTC)


 * While I agree it is essentially just a disambiguation page delineating our policies, it is linked to in many locations, so, in this case, I'm going to say, no. I have no objection to, and would support, you instead preparing and marking that page for translation however. Dmehus (talk) 17:29, 21 November 2020 (UTC)
 * I'll do that then :) --Sabelöga (talk) 17:32, 21 November 2020 (UTC)

Inactive Rights Removal - 2020-11-23
The rights of the following users will be removed on or after 2020-11- if they do not return to activity: Thanks,
 * rights already removed by another Consul unfamiliar with our new-ish inactivity notification and removal protocols. Rights can be rerequested at Request permissions
 * now active
 * rights already removed by another Consul unfamiliar with our new-ish inactivity notification and removal protocols. Rights can be rerequested at Request permissions
 * rights already removed by another Consul unfamiliar with our new-ish inactivity notification and removal protocols. Rights can be rerequested at Request permissions
 * rights already removed by another Consul unfamiliar with our new-ish inactivity notification and removal protocols. Rights can be rerequested at Request permissions
 * Dmehus (talk)
 * For the Consul Team
 * 00:12, 24 November 2020 (UTC)
 * ✅, three (3) of which were inadvertently removed in good-faith by another Consul, but this formalizes the notification and removal process. In the case of Applemasterexpert, the activity that reinstated them as active was by blanking a subpage in their own userspace, which, by established conventions, is treated as a request for deletion. Since I deleted that page, it became a deleted contribution, which caused the Consul script to not recognize that as a live edit contribution and, thus, the user was not removed from Inactivity/Inactive administrators. As such, due to this technicality and in absence of a formal community proposal to clarify this, this becomes the removing Consul's discretion whether to treat a single page blanking by the user as qualifying activity or not moving forward. Dmehus (talk) 21:37, 29 November 2020 (UTC)

Propose deletion of the Forum Administrator user group.

 * The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
 * Involved closure, but since consensus was unanimous here, with no opposition, closing as successful. Dmehus (talk) 03:05, 7 December 2020 (UTC)

I propose deletion of the forum administrator user group, mostly because the rights that are granted with it are already included with the administrator user group. Justarandomliberal (talk) 14:28, 25 November 2020 (UTC)
 * 1)  LGTM. Reasonable proposal. User group is essentially redundant to the administrator, which any non-fanctioned, registered, logged in user can obtain. In fact, as I recall, I contemplated deleting this group entirely when the WikiForum extension was enabled. Dmehus (talk) 17:18, 25 November 2020 (UTC)
 * 2) Seems appropriate, I had also proposed deletion of two other groups. Naleksuh (talk) 19:01, 25 November 2020 (UTC)
 * 3) Per above. R4356th (talk) 15:16, 27 November 2020 (UTC)
 * 4) Per above HeartsDo (talk) 10:36, 29 November 2020 (UTC)


 * The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section

Regarding Testing Deletion in Special:WikiForum
If I am not mistaken, someone tried to test deletion in Special:WikiForum and deleted a category and a forum which had been there since the WikiForum extension was enabled making it impossible to create testing topics. I have created them again. From the next time, I would suggest just creating those by yourself and testing deletion. I hope this helps. Thank you. R4356th (talk) 17:26, 3 December 2020 (UTC)

Favicon
Should the favicon of this wiki be the same as the logo instead of the regular miraheze favicon? Naleksuh (talk) 02:56, 7 December 2020 (UTC)


 * It probably should be. Do you happen to know the dimensions of a favicon, so I can resize the image, upload, and set in ManageWiki? Dmehus (talk) 03:04, 7 December 2020 (UTC)
 * That's not necessary, just take the same url being used for the logo and use that for the favicon. I did that for dev wiki and it worked out fine. Naleksuh (talk) 04:50, 7 December 2020 (UTC)
 * Ah, I wasn't sure if the favicon would automatically resize, as I know the site logo has to be an exact 135x135 (or 135xx or xx135), so I'll try and make this change now then. Thanks for the good suggestion! Dmehus (talk) 14:57, 7 December 2020 (UTC)
 * This seems to be ✅ now. Thanks again. Dmehus (talk) 15:02, 7 December 2020 (UTC)
 * For me the Miraheze logo is still the fav icon. PorkchopGMX (talk) 15:10, 31 January 2021 (UTC)
 * That is very strange and shouldn't be happening. Have you tried reloading your cache for publictestwiki.com? Reception123 (talk) 15:18, 31 January 2021 (UTC)
 * I completely forgot about this, but the correct fav icon is showing up now. PorkchopGMX (talk) 13:01, 17 March 2021 (UTC)
 * Oh, okay, that's great. :) Dmehus (talk) 19:29, 18 March 2021 (UTC)

Inactive Rights Removal - 2020-12-21
The rights of the following users will be removed on or after 2020-11- if they do not return to activity: Thanks,
 * now active
 * Dmehus (talk)
 * For the Consul Team
 * 01:13, 22 December 2020 (UTC)
 * ✅. Dmehus (talk) 01:03, 30 December 2020 (UTC)

Inactive Rights Removal - 2021-01-19
The rights of the following users will be removed on or after 2021-01- if they do not return to activity:
 * now active
 * now active
 * now active
 * now active
 * now active
 * now active
 * now active
 * now active
 * now active
 * now active
 * now active
 * now active

Thanks,
 * Dmehus (talk)
 * For the Consul Team
 * 16:30, 19 January 2021 (UTC)
 * ✅. Dmehus (talk) 14:29, 26 January 2021 (UTC)

Inactive Rights Removal - 2021-02-15
The rights of the following users will be removed on or after 2021-02- if they do not return to activity:
 * now active
 * now active
 * now active
 * now active
 * now active
 * now active
 * now active
 * now active

Thanks,
 * Dmehus (talk)
 * For the Consul Team
 * 21:42, 15 February 2021 (UTC)
 * ✅. Dmehus (talk) 18:45, 21 February 2021 (UTC)

Translation not possible
Hello, I have tried to translate the main page, but I receive an error: ''The title "Translations:Main Page/2/de" has been banned from creation. It matches the following blacklist entry: " Translations:.* "'' Is anybody able to activate the translation system again? Thanks --Ameisenigel (talk) 21:55, 8 March 2021 (UTC)


 * Ameisenigel This is very strange because you're already logged in. I've referred this to Void to see if he can take a look. Dmehus (talk) 22:08, 8 March 2021 (UTC)
 * Ameisenigel Void has found the cause, and it seems it was an issue with our local title blacklist, which, arguably, seemed unnecessary, so I've now ✅ the given interface message. Please try translating now. Dmehus (talk) 22:19, 8 March 2021 (UTC)
 * Dmehus Thanks, now translating works. --Ameisenigel (talk) 23:06, 8 March 2021 (UTC)
 * Okay, ✅. Thanks again for reporting this. If I had to guess, we'd probably disabled translations by non-administrators due to poor quality machine translations and translations being done outside the translation system. Dmehus (talk) 23:15, 8 March 2021 (UTC)

Inactive Rights Removal - 2021-03-21
The rights of the following users will be removed on or after 2021-03- if they do not return to activity:
 * resigned
 * now active
 * now active
 * unneeded rights voluntarily removed from Void's alternate account
 * resigned
 * now active
 * now active
 * unneeded rights voluntarily removed from Void's alternate account
 * now active
 * now active
 * unneeded rights voluntarily removed from Void's alternate account
 * now active
 * unneeded rights voluntarily removed from Void's alternate account

Thanks,
 * Dmehus (talk)
 * For the Consul Team
 * 09:44, 21 March 2021 (UTC)
 * ✅, notwithstanding the two users who voluntarily removed their user groups above. Dmehus (talk) 14:45, 28 March 2021 (UTC)

Can my name be changed?
Hi, can I please have my name changed to Namielle please? Thank you! Theory of Eternity (talk) 12:41, 3 April 2021 (UTC)


 * See meta:Special:GlobalRenameRequest. --Anton (talk) 12:54, 3 April 2021 (UTC)

Edit request

 * The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
 * Admins can unblock themselves. – Olipino (talk) 14:20, 5 April 2021 (UTC)

. and, will anyone of you please remove or yourself from the above text. I see if users block themselves they are unable to do anything even they can't unblock themselves. I experienced this when I blocked my alternative account Flarehot and when blocked themselves. What do you people think? – Olipino (talk) 13:37, 5 April 2021 (UTC)


 * I've seen admins unblock themselves on Recent Changes, so I think it is possible for blocked admins to unblock themselves. I don't have admin powers myself, otherwise I'd test that for myself. Theory of Eternity (talk) 13:50, 5 April 2021 (UTC)


 * Hi, Consul can remove the block from itself. Admins can't, to my knowledge. Thanks --Anton (talk) 13:57, 5 April 2021 (UTC)


 * Sorry, I was wrong. The admin can unblock himself . Please see Special:ListGroupRights. Thanks. --Anton (talk) 14:05, 5 April 2021 (UTC)
 * , let me test. – Olipino (talk) 14:09, 5 April 2021 (UTC)


 * Yes, what are you going to test? --Anton (talk) 14:10, 5 April 2021 (UTC)
 * , sorry for talking your time, I'm closing this discussion because yes  can unblock themselves as listed at Special:ListGroupRights. I tested block on myself and yes, I could unblock myself. Thank you! – Olipino (talk)  14:15, 5 April 2021 (UTC)


 * The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section

Change in the Main policy
Hello fellows, the policy clearly states that  It is ok to test blocks on yourself (your own/main account), but it also states  which, in my opinion is wrong. If users create an alternative account, the underlining IP address remains same and if they block the alternative account, their main account will also get blocked and won't be able to test anything since the IP address will be same in both the accounts. This happened to me (probably on my second day here). I'd suggest to replace with -- Jusl¡t (talk) 17:25, 5 April 2021 (UTC)


 * Users can create alternate accounts, though. Nevertheless, this is fairly non-controversial, so if there's no objections, I'll close this as a non-controversial amendment after three calendar days by replacing the above with, "You may place clearly marked test blocks on yourself, on User:Example, or on any alternate accounts you create for this purpose. As a best practice, it's recommended you (a) create any alternate accounts while logged into your main account and (b) identify any alternate accounts via your local or global user page in some way." How does that sound? Dmehus (talk) 17:52, 5 April 2021 (UTC)
 * , since the IP block exemptions have been added to the  group, I have no objections. -- Jusl¡t (talk)  19:56, 5 April 2021 (UTC)
 * Olipino Okay, ✅. If you or Anton want to add the  to the Administrators page, that'd be great, but do link to my Consul action in your edit summary using  . Thanks! Dmehus (talk) 20:01, 5 April 2021 (UTC)
 * ✅ I've added  to A. -- Jusl¡t (talk)  20:13, 5 April 2021 (UTC)
 * Thanks! Dmehus (talk) 20:14, 5 April 2021 (UTC)

Inconsistency regarding requirements to request Bureaucrat
I noticed that both B and RfP list different requirements to be eligible to obtain bureaucrat. B states that a user must be a registered user for 24 hours before requesting bcrat, where as RfP states that a user must be an administrator for 24 hours before requesting bcrat. Typically I would correct this issue myself, but I do not know what the real requirement is, so I am bringing it up here in hopes that someone else can rectify the issue. Joritochip (talk) 02:55, 6 April 2021 (UTC)
 * , I think bureaucrats can only promote  to bureaucrats user right (but I may be wrong). That's why it may be necessary to be an admin for 24 hours. -- Jusl¡t (talk)  04:42, 6 April 2021 (UTC)
 * Joritochip Interesting point. In theory, I would say Bureaucrats would be correct, as one could theoretically have had a TestWiki account for more than twenty four hours but simply never requested administrator, so they've demonstrated that they're trusted. In practice, though, Request permissions' language may be the way to go. Reception123, do you have any thoughts? It is a policy page, but this a non-controversial administrative change I think we can clarify administratively as a Consul action. Dmehus (talk) 14:16, 6 April 2021 (UTC)

Suggested move
While testing, I came across the template, RfPdone. I'd suggest to move it to the new more suitable title,  or something similar. I'd also like to make a new template to use when we will add someone to the bureaucrats group to let them know about the policies. Let me know who supports this. ,, what do you think. -- Jusl¡t (talk) 13:47, 6 April 2021 (UTC)
 * It serves a different purpose than AdminAcceptRfP; however, I personally don't think it's needed, as everyone can be a TestWiki . I'm checking with Reception123 to see what he thinks. Dmehus (talk) 14:10, 6 April 2021 (UTC)
 * , you took me in the wrong way. I know it serves a different purpose. What I mean is "this template should be posted on the talk page of a person who got the  flag, to let them know about the TestWiki policies. Posting at the talk page produces a notification and a user is bound to see what it is. I know everyone can be admin but, not everyone knows about the policies. -- Jusl¡t (talk)  14:23, 6 April 2021 (UTC)
 * Yeah, I just think we don't necessarily need to be creating a user talk page message for every user who requests permissions at Request permissions. I mean, we can keep the template, but my preference would be for deletion. Arguably it would be better to encourage Bureaucrats and Consuls to use AdminAcceptRfP and BureaucratAcceptRfP at Request permissions when granting permissions, as then the diff to the completed permission's request can be included within the requesting user's user rights log, no? Dmehus (talk) 14:29, 6 April 2021 (UTC)

Inactive Rights Removal - 2021-04-18
The rights of the following users will be removed on or after 2021-04- if they do not return to activity:
 * now active
 * rights removed per requested leave of absence
 * now active
 * rights removed per requested leave of absence
 * now active
 * now active

Thanks,
 * Dmehus (talk)
 * For the Consul Team
 * 00:08, 18 April 2021 (UTC)
 * Hi, I've been busy for quite some time because of my exams. It will take me another week to return. Thanks SHEIKH (talk) 19:06, 18 April 2021 (UTC)
 * SHEIKH No problem. In any case, the act of you replying to this thread has now made you active, so I've now updated that. Dmehus (talk) 19:42, 18 April 2021 (UTC)
 * I'm taking a long break from wikis in general because I have a lot of stuff to do in real life. Remove my rights if you wish. Justarandomamerican (talk) 02:40, 21 April 2021 (UTC)
 * Justarandomamerican Alright, sounds good. When you return, please feel free to request rights at Request permissions or at my user talk page. Dmehus (talk) 02:48, 21 April 2021 (UTC)
 * ✅, notwithstanding the user who requested voluntary removal of their rights while they are on an extended wiki leave of absence. Dmehus (talk) 16:17, 25 April 2021 (UTC)