TestWiki:Community portal

Community portal Welcome to the TestWiki Community portal! On this page, matters pertaining to the local TestWiki community can be discussed. Post your questions, comments, or concerns below by the big blue button to the immediate right.

New thread

Please give feedback on template:Do not archive until

Please give feedback on template:Do not archive until.Adjusted to take into account that auto-archiving will take place two weeks later.See also meta:Autoarchive.Thank you for your cooperation.--松 (talk) 15:16, 3 July 2020 (UTC)

@松: I like the Meta archive templates. These are the ones that use a bot to archive them when you tag a thread with that template, correct? In any case, I would only make one small change, by replacing the transclusions of the Template:Intricate redirect with Template:Intricate template, the actual template, so we can delete the extraneous and unneeded redirect. Other than that, seems fine to me. :) Dmehus (talk) 16:52, 3 July 2020 (UTC)

Wait, I think I'm getting confused by the two Meta templates; I would actually prefer us to drop the use of the Revibot automatic archiving as I do feel 14 days is too short and, since Revi has "de-facto retired" from the Miraheze wikis, it's unlikely it'll be setup on other wikis. My preference would be to adopt the Wikimedia Meta method of archiving whereby a different bot archives the thread when a human editor has tagged it with an applicable "okay to archive" template. Dmehus (talk) 16:55, 3 July 2020 (UTC)

@Dmehus: Thank you for the advice.The replacement is complete.I think that the proposal to Revibot itself needs the proposal to meta RfC.--松 (talk) 00:14, 4 July 2020 (UTC)

@松: Yeah, I think replacing Revibot on Meta would definitely need either a (a) local RfC or (b) some sort of community discussion on the Meta community portal. What do you think? We could possibly replace, though, Revibot on TestWiki without too much discussion, as long as we talked it over with RhinosF1 and/or Void (the two most active consuls here). By the way, are you the same Pine from Wikimedia's Outreach Wiki? Dmehus (talk) 01:15, 4 July 2020 (UTC)

@Dmehus:No, but unfortunately, the "松・Pine・Matsu" account could not be created because it has already been acquired.I'm thinking about when to reissue the suggestion requesting the introduction of this template in the Community noticeboard of meta.It might be better to collect opinions on testwiki.--松 (talk) 02:48, 4 July 2020 (UTC)
Where can I find a page on the testwiki where I can check if the template I created this time works as expected? (i.e.Where is Revibot valid page?)--松 (talk) 13:01, 7 July 2020 (UTC)
@Dmehus:I've checked TestWiki:Rightsbot and I'm worried that if Revibot doesn't exist on this wiki, I can't test how the archive works on testwiki.--松 (talk) 03:59, 8 July 2020 (UTC)

@松: I thought you were trying to design an archiving system without Revibot? As far as I'm aware, I don't think Revibot is set up on Public Test Wiki; it's just set up on Meta. Maybe I'm a bit unclear on what the end goal of this template is. If it's just about telling Revibot not to archive threads before a certain period of time, why don't we just increase the days to archive value on Meta? Dmehus (talk) 04:15, 8 July 2020 (UTC)

@Dmehus:Please　see Template:Bump(Template:Bump).--松 (talk) 07:58, 8 July 2020 (UTC)

@松:, thanks. Saw it. What did you want me to look at? That just effectively works like a relisting template by adding a timestamp to prevent a thread from being archived, no? Dmehus (talk) 13:10, 8 July 2020 (UTC)

@Dmehus:I discussed Spike and RfC rules.At that time, I came to the conclusion that I had to delay archiving the Community noticeboard during the draft period.The original template I'm creating now is supposed to be used for pages that will be archived in 2-3 days.Therefore, if we copy it to meta as it is, the archive becomes too slow.Since meta is an important wiki, you should be careful when introducing new templates.So, I'm making a beta version of the template on testWiki and requesting opinions.--松 (talk) 04:34, 9 July 2020 (UTC)

@Dmehus: I saw the voting in the CN and resumed the template creation. I changed the name to Template:This thread is protected from Revibot's automatic archive for n days for clarity of purpose.The name of this template is too long, so I think we need a redirect to a short name.We also need to rename Template:Do not archive until and Template:DNAU.I do not use English on a daily basis, so I would like to ask you, who uses English on a daily basis, for the opinion of the template name.thinks.--松 (talk) 03:29, 9 August 2020 (UTC)fix.--松 (talk) 04:57, 9 August 2020 (UTC)

@松: Why do we need to rename {{Do not archive until}} and template redirect {{DNAU}}? Couldn't we just rename to {{This thread is protected from Revibot's automatic archive for n days}} to {{Temporary prevention of automatic archiving}} and have {{TPAA}} as a template redirect? Dmehus (talk) 13:04, 9 August 2020 (UTC)

@Dmehus:Thank you for the advice.The reason we changed the name is that this template was created assuming that it will be archived by Revibot two weeks later.(i.e.If the bot settings are different, another template is required.) It seems good to set the name to {{Temporary prevention of automatic archiving}} so that we can select the bot to use instead of entering the comment as the second argument so that it can support multiple bots.--松 (talk) 14:56, 9 August 2020 (UTC)

@松: Thanks for the reply and clarification. Doesn't the template code show a parameter for defining a custom archiving time, though, with the, I think, 2= parameter? I may have misread the code (was looking quickly), but if that's not the case, perhaps we could add a custom time parameter? Dmehus (talk) 15:20, 9 August 2020 (UTC)

@Dmehus: Thanks for the reply.For the time being, the only bot running on meta is Revibot, so it may be good to maintain the current status.Regarding the time parameter, it may be difficult because there was an explanation unless it corresponds in the original template.--松 (talk) 15:46, 9 August 2020 (UTC)

@Dmehus: I am currently importing a template description page and trying to propagate the template changes to the description page.As for the section Examples, what do you think about reflecting the commented out part?--松 (talk) 02:27, 10 August 2020 (UTC)

Question

May I create a page "TestWiki:Sandbox/Filter test" to test the filter?--松 (talk) 14:52, 7 July 2020 (UTC)

@松 Yes, you may. Also, there is the page Filter test for mainspace-exclusive filters. Thanks! --TFFfan (talk) 18:54, 7 July 2020 (UTC)

@松 and TFFfan: That sounds like a good way to test abuse filters, limiting them only to a certain test page as opposed to all or certain namespaces. If you would like TFFfan to help you with that abuse filter, I'm sure that would be fine as it is limited to only a testing page (a subpage of Sandbox). Dmehus (talk) 20:00, 7 July 2020 (UTC)

@Dmehus and TFFfan: Thank you for your reply. Adjusted the filter for testing on both.--松 (talk) 03:59, 8 July 2020 (UTC)

@松 and TFFfan: Okay, thanks for the update, Pine. Dmehus (talk) 04:18, 8 July 2020 (UTC)

Suggestion

I just copied some templates from Wikipedia and imported them here for top icons and a padlock icon. This would be used if a page is protected. I want to know if I can go and add the icons to all protected pages not in the User namespace? Here are some links. Template:Pp Template:Top icon. In addition, the top icon can be used for other purposes, such as a custom one for an official policy page. I just wanted some feedback on those ideas, and I can add them and/or make more proposals as well. Thanks! --TFFfan (talk) 23:21, 7 July 2020 (UTC)

Dmehus Just pinging you for your feedback. You can remove when you get it. :) --TFFfan (talk) 23:31, 7 July 2020 (UTC)

TFFfan In theory, I like the page protection top icons as I do think they're useful and clearly show whether a page is protected. However, my concern is that in practice, on wikis where there is not a bot of some kind like AnomieBOT on English Wikipedia that checks protected pages or titles at regular intervals and automatically adds, and removes, the protected top icons, we could very easily end up in a situation (especially on a testing wiki) where we have unprotected pages with protected top icons (or vice versa). So, at this point, let's maybe hold off for now until we devise an error-free/problem-free solution? Dmehus (talk) 04:24, 8 July 2020 (UTC)

Inactive Rights Removal - 2020-07-15

The rights of the following users will be removed on or after 2020-07-22 if they do not return to activity:

• ~Squiggles~ ( talk · contribs · deleted · logs · rights · CentralAuth )
• A2093064 ( talk · contribs · deleted · logs · rights · CentralAuth ) - Now active
• AnimeBot ( talk · contribs · deleted · logs · rights · CentralAuth )
• Bonnedav-test ( talk · contribs · deleted · logs · rights · CentralAuth )
• Borschts ( talk · contribs · deleted · logs · rights · CentralAuth ) - Now active
• Brownlowe.2 ( talk · contribs · deleted · logs · rights · CentralAuth )
• Dross ( talk · contribs · deleted · logs · rights · CentralAuth ) - Not marked as inactive
• DW YoungDLS ( talk · contribs · deleted · logs · rights · CentralAuth )
• Fair0002 ( talk · contribs · deleted · logs · rights · CentralAuth ) - Now active
• Mazbel ( talk · contribs · deleted · logs · rights · CentralAuth )
• Rots61 ( talk · contribs · deleted · logs · rights · CentralAuth )
• Shadi12 ( talk · contribs · deleted · logs · rights · CentralAuth )

Thanks,

RhinosF1 (talk)

For the Consul Team

12:29, 15 July 2020 (UTC)

I’m active again, hello. pls let me keep my rights :) Fair0002 (talk) 02:29, 16 July 2020 (UTC)

@Fair0002: Welcome back. As you've made an edit and/or a log action, you're considered active. @RhinosF1: and/or his bot will verify again on the stated removal date whether anyone has been active since the notification date. So, you've done everything you needed to do, as far as my understanding goes. Dmehus (talk) 02:38, 16 July 2020 (UTC)

I have updated the list. RhinosF1 (talk) 09:33, 17 July 2020 (UTC)

@RhinosF1: I thought you were maybe going to manually update Dross back to being inactive, due to the error in the script? If not, I have Strong support toward manually removing the user due to inactivity. This request can be treated as a community proposal, and manually closed by a consul in 5-7 calendar days if no meaningful opposition. ;) Dmehus (talk) 20:22, 23 July 2020 (UTC)

 Done, pinging Void to see why the script hasn't picked Dross up. RhinosF1 (talk) 21:33, 23 July 2020 (UTC)

For anyone following this thread, Dross was rightfully deemed active by patrolling a revision earlier this month. Dmehus (talk) 22:17, 23 July 2020 (UTC)

Community proposal to Add autopatrol to Autoconfirmed implicit user group

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Done. RhinosF1 (talk) 21:15, 21 July 2020 (UTC)

---

As part of an omnibus community proposal put forward by our Consul colleague RhinosF1 several months ago related to the management of inactive administrators and bureaucrats, proposal # 2 specified that all user groups were to be removed from all inactive users who hadn't made either an edit or a log action in the preceding ninety (90) days. The reasons for removing administrator and bureaucrat due to inactivity are obvious and center around security, primarily. For the other user groups, largely, they're added for reasons of testing user group additions and removals, and, since anyone can become an administrator, they're generally unneeded and thus create extraneous clutter.

As part of recent quality assurance testing, I came across a confirmed bug (will be tracked in Phabricator shortly) in one of our deployed extensions such that when a previous administrator loses their user rights, their previously automatically patrolled revisions become unpatrolled, adding to the patrol backlog.

To reduce that backlog, I propose that we add autopatrol to the Autoconfirmed implicit user group. Indeed, RhinosF1 already effected the same change recently on Loginwiki, primarily because that system administrator-managed central coordination wiki has no user groups and no local administrators yet still creates a fair amount of edits due to users maintaining their global user pages. As there is no set end date for fixing this bug, I propose that this change be indefinite. When it's resolved, we can easily propose to remove it from the group at the community portal, should there be a need (or we could just keep it that way as there's no reason not to).

Support

1. Strong support As proposer. No reason not to. Dmehus (talk) 13:32, 15 July 2020 (UTC)
2. Support -- Regards, ZI Jony ^(Talk) 11:59, 17 July 2020 (UTC)

Comments

• It is difficult to remove the authority of Autoconfirmed, so I feel that the date before granting Autoconfirmed is too short.--松 (talk) 13:24, 17 July 2020 (UTC)

  @松: Yes, that's true, but autoconfirmed doesn't provide that many rights on Public Test Wiki. Plus, anyone can request administrator in less time than it takes to become autoconfirmed. I'd ideally like to either (a) shorten the account age for autoconfirmed from four days to one day, since bureaucrat can be granted to any trustworthy user whose account is at least 24 hours old and has made at least ten edits or (b) increase the account age for bureaucrat to four days from one day in order to simplify the wording of the eligibility requirements. But, I don't want to run too many concurrent proposals nor do I want to create confusion with this proposal that's essentially a housekeeping amendment. Dmehus (talk) 15:28, 17 July 2020 (UTC)

  From a spam standpoint, I think it's too short.--松 (talk) 01:31, 18 July 2020 (UTC)

  @松: Yeah, I get that, but we do have pretty aggressive abuse filters, local and global, and we don't really have a problem with, well, much if any automated spam on Public Test Wiki (at least I haven't seen any in the past several months since I've been here). Plus, I think it's pretty consistent with the way in which most of the Wikimedia projects grant autoconfirmed status? Dmehus (talk) 14:13, 18 July 2020 (UTC)

---

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

CircleyDoesExtracter Inactivity Exemption

Hi. I am CircleyDoesExtracter.

As I tell I casually use the rights on this wiki for testing, but they are casual.

Thus, I wish to apply for an exemption from the inactivity rule. Thanks.

CircleyDoesExtracter (talk) 13:47, 26 July 2020 (UTC)

@CircleyDoesExtracter: I'm not opposed to you being granted a temporary inactivity exemption, but you need only make one log action or edit every three months. And, you will receive an e-mail message (if you have talk page notifications enabled for your user talk page), so even just replying to the talk page notification on-wiki is enough to count you as active. Even patrolling a page revision or thanking someone for an edit should be enough to keep you as active. We're also in the process of redoing our inactivity policy going forward, but I would have no problem with granting you an inactivity exemption, if you'd still like, until the date specified by the latest most recently added exemption request. I meant to also add, you are active on Discord, as well, and keep in contact with RhinosF1 and I, so since we're both active on this wiki, both of us will keep an eye out for you and if we see you haven't made a log action or edit here in 2-2.5 months, we'll nudge you ahead of time on Discord to make one, which will also keep you active. Dmehus (talk) 13:58, 26 July 2020 (UTC)

@Dmehus: I see, but at least I got knowledge as a sysop. CircleyDoesExtracter (talk) 14:40, 26 July 2020 (UTC)

@CircleyDoesExtracter: Yeah, you definitely have a lot of experience as a bureaucrat and sysop on other wikis. As I say, I would support you being granted a temporary exemption until winter 2021 (about six months). By then, we should be able to have further clarified our policies with respect to inactivity exemptions. In any event, it will probably be moot as I will personally make sure that you do not go inactive, and {{ping}} you on-wiki and Discord to make sure you don't even go inactive. Dmehus (talk) 14:44, 26 July 2020 (UTC)

Suggestion

I've seen the Global rollback group suggestion and I thought that if each of the admins on the local wiki was able to successfully use the abuse filter, vandalism would be reduced.However, setting a abuse filter seems like a high threshold for light users.So, I thought it would be nice to create a page on this wiki with a lecture on how to set filters and a useful and simple example.I myself do not know how to set the filter.Thank you for your consideration.--松 (talk) 16:12, 29 July 2020 (UTC)

@松: We have Filter test, which can be used as a page for testing actual filters, so as to impact very few (if any) users. Feel free to improve upon that page to provide some instructions. As we fill out documentation on creating abuse filters, we'll probably want to utilize Help: namespace. Nonetheless, in regards to your suggestion, it's a good one, and I have no concerns with doing this. I'll try and work on this in the next month or so (that proposal, as written, probably will not pass, and will likely take yet another RfC in a few months to work towards having a global rollbacker group). Dmehus (talk) 18:39, 29 July 2020 (UTC)

@Dmehus: Thank you for your reply.I'm glad you could help me with my suggestions. I'm not familiar with abuse filters, so it would have been difficult to complete this suggestion myself.I thought it wasn't enough to just import the wikipedia filter usage filter description page. (If I import, could you help me edit?).I thought I would say that in RfC, but I stopped thinking it would be off-topic.--松 (talk) 23:36, 29 July 2020 (UTC)

Addendum: I have noticed that in order to perform the import, unlike the template, you have to import not only one format but all the formats. (i.e. The amount of data is too large for me to do.)--松 (talk) 23:44, 29 July 2020 (UTC)

@松: Yes, you should usually include templates transcluded on the given template when importing. Are you saying you're getting a rate limiting error? If so, would you like me to temporarily assign you the bot flag, or would you like the bureaucrat bit? Let me know by way of a reply to this thread, and I can assign the applicable right requested, linking to the diff. Dmehus (talk) 04:06, 31 July 2020 (UTC)

@Dmehus: Thank you for your reply.The page I'm trying to reference is this page.As it is, I feel that there are not enough examples, and since the translation code is inserted, it is better to remove the translation code.I also think it's better to import it into the help page.If we only need the latest version,I can probably import it.In my own private wiki(i.e.With bureaucrat and bot permissions), even smaller pages (but somewhat larger) have failed because they take too long, so I'm assuming they'll fail even with permissions.--松 (talk) 08:39, 31 July 2020 (UTC)

@松: Thanks for your reply, too. As to whether we need all revisions for CreativeCommons copyright compliance, I believe the answer is technically no (one revision is usually sufficient); however, I do like to for the purposes of attribution. I see what you mean, as it did nearly time out on me, but, with patience and, perhaps, the bureaucrat bit, I had success, and imported it to a subpage of User:松 (your userspace in a Drafts initial subpage). I opted to not include the transcluded templates with this import and, fortunately, that seemed to be helpful, as I see we only need to likely import {{int}} as {{caution}} can probably be replaced with an existing message box template we have. As well, because of that, the "translate this page" template wasn't included; however, we'll still manually need to remove the translation tags. I chose to import it into a subpage of your userspace first, as I imagine you'd like to do some fine-tuning, removing of the translation tags, and so forth. Dmehus (talk) 19:32, 31 July 2020 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘@Dmehus:Thank you very much.Great.--松 (talk) 05:45, 1 August 2020 (UTC)

Translation tags across section have been removed.With this,we can perform the work of removing the translation tag for each section.I'm going to sleep, so I'll take a break.--松 (talk) 15:15, 1 August 2020 (UTC)

 Done I finished removing the translation tag.--松 (talk) 13:59, 14 August 2020 (UTC)

@松: Wow, thanks. I started to try and help with that, but there were a lot of translation tags and tvar tags to remove, so that's appreciated. This will be useful for formulating our abuse filter help pages. Dmehus (talk) 15:58, 14 August 2020 (UTC)

Consul Request (Dmehus)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Successful RhinosF1 (talk) 14:31, 17 August 2020 (UTC)

---

I'm requesting the community's assent to promote me to Consul because, like RhinosF1's Consul request, I am the most active user here on Public Test Wiki. Indeed, it is one of my two home wikis (the other being Meta), and my total edits on this wiki represent more than 25% of my total global edit contributions across all Miraheze wikis. I am very active in actioning permissions requests at TestWiki:Request permissions, mentoring new administrators and bureaucrats, providing guidance to the same new users in the aforementioned two groups where and when appropriate, and cleaning up after the same. I am also very active on Discord and IRC and at this community portal with answering questions from potential, new, and existing administrators and bureaucrats.

Among my reasons for requesting Consul is so that I can continue with maintenance and minor copyediting to Consul-protected pages and redirects, implement a redirect categorization scheme to better manage and track our cross-namespace redirects, develop a long-planned school for new administrators and bureaucrats, and implement configuration changes in Special:ManageWiki upon their having been first discussed at this community portal. Over the medium- to longer-term, together with @RhinosF1: and other Consuls, I also plan to further develop and amend our policies, bringing them forward for discussion to this community portal for discussion and potential adoption.

I would welcome any questions any administrators and bureaucrats may have, and look forward to their supporting this request for Consul. Thanks. Dmehus (talk) 23:22, 10 August 2020 (UTC)

Support

1. Bold, italic, and underlined. Naleksuh (talk) 01:41, 11 August 2020 (UTC)

Questions for the Consul candidate

1. How will you choose when to protect a page at consul level? Personally I feel that it is overused currently. While some pages should certainly be kept away from administrators, bureaucrat protection exists for a reason. Naleksuh (talk) 01:44, 11 August 2020 (UTC)

   @Naleksuh:, thanks for the question. I think things like the MediaWiki:Common.css should be protected at Consul because of the potential for abuse or misuse as bureaucrat is still, mainly, a testing user right, albeit to users who've at least demonstrated a higher level of trust than administrator. MediaWiki:Sidebar is kind of a grey area; I get the idea behind potentially lowering that to bureaucrat, but, at the same time, I could see that end up being quickly cluttered with links to tools only one or two editors might use, so would likely want to retain that protection level. Redirects, especially those with few if any inlinks, to policy or information pages could probably be lowered, at least to bureaucrat. Pages like TestWiki:Inactivity/Exceptions should remain Consul-protected for technical reasons as it is used by the Consul-operated bot as part of a semi-automated monthly inactivity notification and removal process. Looking through pages protected at Consul level, the only two that I would say could probably be lowered would be Donate (a cross-namespace redirect to TestWiki:Donate, with few if any inlinks linking to the redirect) and Request permissions (a cross-namespace redirect from main space to project space, again also with few if any inlinks).

   But, a TestWiki:Protection policy is one of the things I'm hoping to begin drafting over the medium-term, that gives some guidelines on when to protect a page and what protection level should ultimately be used under certain conditions, the result of which I would ultimately bring forward to TestWiki:Community portal for a community discussion. Prior to bringing it forward, though, I would notify the community via that same portal page of the location of the draft, and invite the community to discuss the guidelines that should go into the draft (presumably, on the draft's talk page). Hope that clarifies. Dmehus (talk) 04:09, 11 August 2020 (UTC)

---

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

He really should have this. I mean, look at all of his hard work. --TFFfan (talk) 18:12, 18 August 2020 (UTC)

Should users be able to edit through tor?

In this log action, Dmehus revoked the torunblocked right from all registered users without warning and without consensus. As a big advocate of tor, I want the communities input on this, as to whether or not users should be able to edit through tor. TrustedInstaller (talk) 14:57, 20 August 2020 (UTC)

Support as idea creator. TrustedInstaller (talk) 14:57, 20 August 2020 (UTC)

Comment This idea has effectively been superceded by Proposal 4 as part of this community proposal, which I've now brought forward. You are encouraged to share your views, along with all members of the community. Dmehus (talk) 15:13, 20 August 2020 (UTC)

Community proposal on the future of the torunblocked

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

There is consensus here to adopt either, or both, proposals 1 and 2. Indeed, nothing in the wording of proposals 1 and 2 indicates that either proposal is a zero-sum proposition. There is a fairly clear consensus against proposal 3 and some consensus, somewhere between a rough consensus and a slightly weak consensus against proposal 4. Accordingly, proposals 1 and 2 are adopted, and the informational page will include both this discussion, as now official community policy, and customs and conventions that evolve over time in terms of suggested granting guidelines. Dmehus (talk) 15:18, 27 August 2020 (UTC)

---

Hi everyone,

Earlier this morning, following a discussion with fellow Consul @Reception123:, I took this action, which removed the torunblocked user group right from the registered, logged in users group, primarily, because this should be a right that can be granted on a discretionary basis, ideally by any bureaucrat or consul, and revoked for misuse or other discretionary reasons. We have a number of options here, so wanted to put them forward for a community vote and discussion, which will run for at least seven (7) calendar days.

Proposal 1: New Tor users user group

Proposal 1 proposes to establish a new Tor users user group that would be granted to trusted users by any bureaucrat or consul where there's a clear need. Need would be discretionary and formed through customs and conventions that evolve over time. It could be revoked by the same on a similar discretionary, common sense basis.

Support

1. Strong support As proposer. By keeping the granting and revocation discretionary, and open to bureaucrats, we allow this user group right to granted to any trusted registered community user with a clear common sense need and, similarly, we can revoke it for similar broad reasons. Dmehus (talk) 15:19, 20 August 2020 (UTC)
2. Support This seems like the best option Universal Omega (talk) 02:22, 21 August 2020 (UTC)
3. Support It makes sense to give bureaucrats this right instead of all users. Reception123 (talk) 06:01, 21 August 2020 (UTC)

   @Reception123: You may have misread. This proposal is not to give bureaucrats the right, it is to make a brand new group separate from bureaucrat. Naleksuh (talk) 00:09, 22 August 2020 (UTC)

   @Naleksuh: I did note the slight discrepancy in the rationale, but I don't think Reception123 misread the proposal. I think what Reception123 meant was that it could be granted by both Consuls and Bureaucrats, both of whom are trusted. Dmehus (talk) 00:17, 22 August 2020 (UTC)

4. Support Interesting idea, lets try it. Bonnedav (talk) 07:54, 22 August 2020 (UTC)

Oppose

1. Seems like an unnecessary new group. Since it would only be given to trusted users, it could be applied to an existing group like bureaucrat (the only exception would be if the trust level for it is higher than bureaucrat, but I'm guessing this isn't what dmehus has in mind, since he proposed bureaucrats being able to grant it). Naleksuh (talk) 02:55, 21 August 2020 (UTC)

   @Naleksuh: The idea behind the separate group is for several reasons. For one thing, not every testing administrator wants to request the bureaucrat bit, yet they're still trustworthy. Second, as I noted in the rationale, there may be times when we may not be justified in revoking bureaucrat, but where an administrator has either misused torunblocked or is otherwise no longer trusted to use that user group right. The idea behind giving bureaucrats the ability to grant and revoke this right is so that trusted bureaucrats, who engage in non-test functions and duties, such as yourself, could be able to revoke this right from administrators on a discretionary basis. Hope that clarifies. Dmehus (talk) 00:17, 22 August 2020 (UTC)

   there may be times when we may not be justified in revoking bureaucrat, but where an administrator has either misused torunblocked or is otherwise no longer trusted to use that user group right This proposal doesn't solve that, since you're proposing bureaucrats being able to grant it. Either only consuls can grant it, or we just tie it to bureaucrat and revoke the bureaucrat of people who misuse it. I'd say the second, since I can't think of any instance where a user who can't be trusted with tor could be trusted with bureaucrat. Naleksuh (talk) 01:50, 22 August 2020 (UTC)

   @Naleksuh: If a bureaucrat re-added to their account the Tor user group, for which they'd been advised the reason(s) for revoking, that would be wheel-warring and likely grounds for removal of at least the bureaucrat bit, so I did actually consider that possibility, and that's one of the reasons for why I proposed adding it as a separate user group. In other words, if we didn't quite have cause to remove bureaucrat then, we certainly would in that event, as the user was operating contrary to the restriction or right revocation that had been imposed on them. Dmehus (talk) 02:07, 22 August 2020 (UTC)

   I still think it should be tied to bureaucrat though. I don't envision a situation in which a users tor has been revoked, but they should still have bureaucrat. The only advantage to this group would be only consuls granting it, and I don't think that's a good idea and just unneeded bureaucracy. I think the best approach is to give torunblocked to bureaucrat. Naleksuh (talk) 05:33, 22 August 2020 (UTC)

   @Naleksuh: I should've mentioned that it's possible for up two of these proposals (proposals 1 and 2) to pass together. That is, proposal 1 could be implemented for the reasons articulated above, and proposal 2 could be implemented as well, for similar reasons, to reduce the need for trusted bureaucrats who wish to use Tor for testing purposes to be able to do so without adding the extra Tor user hat. Dmehus (talk) 12:31, 22 August 2020 (UTC)

   Also, where you say that the "only advantage to this group would be only consuls granting it," actually, as I outlined, bureaucrats would be able to grant and revoke this user group because we have a good number of trusted bureaucrats (including you) that engage in non-testing 'crat duties and functions, so it makes sense to empower them with this ability. Dmehus (talk) 12:34, 22 August 2020 (UTC)

Neutral/Abstain

1. Neutral I think this would the best choice if TOR started being abused, but right now I don't see that happening. TrustedInstaller (talk) 15:27, 20 August 2020 (UTC)

Proposal 2: Add torunblocked to bureaucrat

Similar to Proposal 1, but the downside is, it would only be able to be revoked by a consul and only where removal of the bureaucrat bit was justified.

Support

1. Support As proposer, as a reasonable second choice. My preference would be Proposal 1, so experienced bureaucrats can revoke it where needed and appropriate, on a discretionary basis. Dmehus (talk) 15:21, 20 August 2020 (UTC)
2. Weak support Viable option, but I still prefer proposal one Universal Omega (talk) 02:22, 21 August 2020 (UTC)
3. I think that this is the best option, if it's necessary at all. Naleksuh (talk) 02:55, 21 August 2020 (UTC)
4. Support I don't mind this option. Reception123 (talk) 06:01, 21 August 2020 (UTC)
5. Support I'm actually thinking both this and 1. Since bureaucrats can add it anyway, why not have it be part of the bureaucrat toolset, that way they don't have to all grant it to themselves. Bonnedav (talk) 07:54, 22 August 2020 (UTC)

   @Bonnedav: Good question. Absolutely, if there's support for both proposals 1 and 2, it's indeed possible for both proposals to pass, to reduce the need for trusted bureaucrats to add a second Tor user hat to their account. Dmehus (talk) 12:38, 22 August 2020 (UTC)

Oppose

1. Oppose No reason why editing via tor should be restricted to crats. TrustedInstaller (talk) 15:29, 20 August 2020 (UTC)

Proposal 3: Just eliminate torunblocked

Section heading says it all.

Oppose

1. Strong Oppose, completely goes against the global open proxies policy, albeit they can be overridden, they shouldn't be. TrustedInstaller (talk) 15:31, 20 August 2020 (UTC)

   I would like to note that this has absolutely nothing to do with the NOPP. The global policy simply says that users may not edit anonymously from open proxies, and that these are blocked upon discovery at a global level. It does not apply to this situation at all, as it doesn't in any way regulate what local wikis decide regarding editing. A local wiki could block all Tor editing as well as any anonymous editing, and it would have nothing to do with the current policy which only applies to anon editing via open proxies and nothing else. Reception123 (talk) 06:01, 21 August 2020 (UTC)

2. Strong oppose I do not believe this to be the right course of action Universal Omega (talk) 02:22, 21 August 2020 (UTC)
3. There can be valid uses to be connecting from TOR, and I want to support this, but it is also used for abuse so frequently. Weak oppose. Naleksuh (talk) 02:55, 21 August 2020 (UTC)

Neutral/Abstain

1. Neutral I am neither for or against this proposal, as, I guess, a reasonable third outcome. Dmehus (talk) 15:22, 20 August 2020 (UTC)
2.  Abstain I'm not sure what I think about this so I'm not going to take a side, but I feel that if someone really needs to be using Tor to edit, they should probably just get a global exemption. However, I don't mind if we locally give it to users. Reception123 (talk) 06:01, 21 August 2020 (UTC)

Proposal 4: Restore torunblocked to registered, logged in users group

Again, section heading says it all. I personally wouldn't support this, per my above explanation, but this gives the community an option to have its say.

Support

1. Support not only does blocking it go against the global open proxies policy, blocking tor was a really unnecessary and targeted choice, as I am the only one using it. The main problem here with changing the torunblocked right was that no one was abusing it, therefore it shouldn't have been changed. TrustedInstaller (talk) 15:10, 20 August 2020 (UTC)

   Please see my comment above regarding the incorrect claim that this in some way violates the NOPP. Reception123 (talk) 06:01, 21 August 2020 (UTC)

Oppose

1. Oppose, possibly strong, per my reasons articulated above, as proposer. Dmehus (talk) 15:24, 20 August 2020 (UTC)
2. Four tildes Naleksuh (talk) 02:55, 21 August 2020 (UTC)
3. Oppose I personally don't see why all users would need to be allowed to edit from Tor. Yes, this is a testwiki and we are more lenient but Tor can also be used to evade serious local and global locks. If there is a legitimate use for Tor, a global exemption can be requested. And even if Tor hasn't necessarily be abused yet on testwiki, that doesn't mean we need to wait for it to be abused before taking action. Reception123 (talk) 06:01, 21 August 2020 (UTC)

Neutral/Abstain

1.  Abstain I really don't have an opinion either way regarding this one. Universal Omega (talk) 02:22, 21 August 2020 (UTC)

Comments/Discussion on the Proposals before us

---

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

Inactive Rights Removal - 2020-08-24

The rights of the following users will be removed on or after 2020-08-31 if they do not return to activity:

• Geryescalier ( talk · contribs · deleted · logs · rights · CentralAuth )
• Hanatole ( talk · contribs · deleted · logs · rights · CentralAuth )
• Q-bit ( talk · contribs · deleted · logs · rights · CentralAuth )
• QueerEcofeminist ( talk · contribs · deleted · logs · rights · CentralAuth ) now active
• Tiven2240 ( talk · contribs · deleted · logs · rights · CentralAuth )
• 3oem9 ( talk · contribs · deleted · logs · rights · CentralAuth )

Additionally, the following alternate account(s), with zero edits or log actions and which showed up on the inactivity report, has had its/their user groups removed by Consul action this date.

• Syno sock ( talk · contribs · deleted · logs · rights · CentralAuth )

Thanks,

Dmehus (talk)

For the Consul Team

23:28, 24 August 2020 (UTC)

Consul Request - Naleksuh

Hey all! Similar to Dmehus' consul request, I am requesting consul as I am the second most active user here (after Dmehus) and believe I have proven myself to be trustworthy and active. I request consul so that I may help the community by importing and gaining consensus about local policies (currently we are just clinging to Wikipedia's policies, which while a fine short-term solution, we should have our own). This includes a much more rounded and polished protection policy (currently, we have way too many pages protected at Consul level, which Dmehus has also been working to fix). I also hope to clerk things such as inactivity requests and in general help the Test wiki much more as I prove myself to be constructive. If there are any questions/comments, let me know. Naleksuh (talk) 20:37, 26 August 2020 (UTC)

Comments

• Comment While I have not yet formed an opinion yet and am not necessarily opposed, I do think this may be a case of being too soon. For one thing, my own Consul request only closed a little over a week ago. In my request, I did say I was going to work on draft deletion, protection, and blocking policies, as three of the more important policies here on TestWiki. However, I am cognizant that TestWiki relies a lot on unwritten conventions and customs, as it allows us to be flexible, so am hesitant to propose to implement too many policies as one of our hallmarks is that we don't have very many rules. In terms of the pages protected at Consul level, I did remove Consul protection on two little or unused Consul-protected redirects, and had an initial look at what were Consul-protected, but couldn't see any glaring ones that needed lowering of protection levels. To be honest, as I suggested on IRC, I think we should have a community discussion on what Consul protected pages should be lowered. As far as the inactivity clerking, well, we do have @RhinosF1: who is still fairly active here. I assisted him this month with that, primarily because he's taking a very short break this week and has been so involved with the MirahezeBots project, trying to get the major version 9 release out (which completely overhauls the code, adds new functionality, and resolves known issues and/or bugs). Dmehus (talk) 20:48, 26 August 2020 (UTC)
  • Yeah, having way too many policies is a bit of a bad thing, however, if we find ourselves having to link to Wikipedia policies about things here, I would say this "somewhat" justifies a change. Not that the policies here have to be different. Some can be similar, others can be opposites, depending on what the situation is. Naleksuh (talk) 20:58, 26 August 2020 (UTC)