TestWiki:Community portal

__NEWSECTIONLINK__

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. User: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)


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