User talk:RhinosF1/Archive 4

__NOINDEX__

AC tool
Hi Rhinos. What is that AC tool. I searched meta, but couldn't get any results or documentation. --Magogre (talk) 05:20, 14 December 2021 (UTC)


 * Account creation tool. It's a google form users can submit if they can't get past reCaptcha. ~ RhinosF1 - (chat)· acc· c -  07:50, 14 December 2021 (UTC)

Re
I understand your concern about my translations, but they are all from the language I understand respecting namespace names, etc, but I will assure you that there is nothing wrong. But because you're want to block me out? I've changed my behavior a lot in the last few weeks! YellowFrogger (✉ Talk  ✐ Edits ) 17:11, 16 December 2021 (UTC)


 * If you need to use a translator on a systematic basis then you do not understand the language well enough to be translating between them without review. ~ RhinosF1 - (chat)· acc· c -  17:13, 16 December 2021 (UTC)
 * I invite you to view all my contributions translation. And, my behavior may have improved this past week, but even so I will be cautious and understand all of your concerns and those of other sysops so I don't misbehave. Thank you for the warning. YellowFrogger (✉ Talk  ✐ Edits ) 17:57, 16 December 2021 (UTC)

Read this
Could you read this? There have been some replies to it. You told me I should use TemplateStyles but in reality TemplateStyles doesn't support javascript. <span style="display:inline-block;border:2px solid #bfff00;border-radius:8px;background-image:linear-gradient(to bottom right, #75ff75, #ffff80)"> Anpang 📨 08:15, 23 December 2021 (UTC)


 * I've seen it. I'd still like you to consider if they are other ways you can do it as adding template specific code to the common files isn't great. ~ RhinosF1 - (chat)· acc· c -  10:03, 23 December 2021 (UTC)

Hello
Hi Rtyoip (talk) 06:10, 26 December 2021 (UTC)

Test
Test ~ RhinosF1 - (chat)· acc· c -  15:43, 2 January 2022 (UTC)

Request
I request that you delete the following page:
 * 1

Thanks, --YellowFrogger (Talk — ✐) 00:55, 6 January 2022 (UTC)

About #23615
hi, the 23615 request wiki, you can not agree him request?--Msnhinet8 (talk) 11:10, 22 March 2022 (UTC)
 * No. Why on earth was it created? ~ RhinosF1 - (chat)· acc· c -  11:12, 22 March 2022 (UTC)
 * I'd like to know this as well. --Raidarr (talk) 18:22, 22 March 2022 (UTC)
 * i think resist him.--Msnhinet8 (talk) 23:57, 22 March 2022 (UTC)
 * but he the future can again request wiki, so...--Msnhinet8 (talk) 23:59, 22 March 2022 (UTC)
 * Can you further elaborate on this? I was unable to understand this statement. Agent Isai  Talk to me! 00:30, 23 March 2022 (UTC)
 * They were probably saying that it's good the wiki was (re)reviewed and declined appropriately and that the user in question (ElizavetaRazgon) can request another wiki in the future. --  Joseph  TB  CT  CA   00:39, 23 March 2022 (UTC)
 * I do not believe that's what he meant. Request #23615 was declined by RhinosF1 and then approved by Msnhinet8 half an hour later as a "perfect" request. Agent Isai  Talk to me! 00:52, 23 March 2022 (UTC)
 * Actually, looking at #23615, my only issue, and it's a minor one, is that the wiki requestor created a duplicate wiki request rather reopening an existing request. To clarify RhinosF1's incorrect comment on the request, Content Policy does not prohibit companies from having wikis, but rather, it depends how the company will use the wiki and for what purpose. It's a bit vague, but it looks to me to be a private wiki for Russian Starbucks franchise operations, for employees to share internal training procedures, staff scheduling, and other strategies. We have never prohibited these type of wikis, or public or private commercial documentation wikis, company product information wikis, etc. They just can't hawk goods or services from their wiki, accept any kind of monetary forms of payment, or have paid advertising on their wikis. As I said elsewhere, I personally would've approved it as a "good" request, but it's conceivable in this case how some wiki creators might've approved it as either an okay-ish or perfect request. I could also see declining it as needing more information. What I cannot see is declining it per Content Policy. That action is not correct. Dmehus (talk) 01:15, 23 March 2022 (UTC)
 * I disagree. We allow commercial wikis so end users & communities can document things or for fundraisers. I don't think the our rules should nor is it intended for them to allow private staff manuals for large corporations. My main issue with is there lack of communication though given they had just spoke to me on IRC.  ~ RhinosF1 - (chat)· acc· c -  07:22, 23 March 2022 (UTC)
 * I agree that it's clearly inappropriate for a wiki creator to simply bypass another creator's objections or questions and create the wiki anyway. If a wiki creator disagrees with another and thinks the wiki should be approved, they should discuss with that wiki creator rather than just create it because they wouldn't have done it themselves. As for the commercial issue, I think it's complicated but I personally wouldn't necessarily think a 'staff manual' would be 'commercial'. Reception123 (talk) ( C ) 13:23, 23 March 2022 (UTC)
 * I don't get why Msnhinet8 would blindly approve wiki requests as "perfect", despite some of them have not having any details, but in any case, this, in my humble opinion, should be looked at carefully. And, this isn't an attack against you, but this is pretty disrespectful to a lot of us wiki creators, like myself and a few others that you would have to approve the wiki, despite some being declined for a legitimately good reason. I've made several other mistakes when reviewing certain aspects of wiki requests, like approving some certain wikis without thinking about it at first. I think personally you should re-review what wiki creators should do when doing some type of quality control check. I do partially agree with half of what the other users are saying, and I might add the fact that there was some concerns about your questionable actions back in December. I myself, am concerned about you as well. DarkMatterMan4500 (talk) (contribs) 14:52, 23 March 2022 (UTC)
 * Reception123, I do not believe it is necessarily inappropriate for a wiki creator to simply take an action that differs from another wiki creator. Ideally, they could, and perhaps should, discuss with the other wiki creator, but it's not, and has never been, required. Nor should it be. Communication in English for Msnhinet8 is...difficult at the best of the times, never mind the time zone difference. I also don't think it would be fair to make the wiki requestor wait through all of that, time zone changes and wiki creator back and forth, but as you said, private staff training manual wikis have always been acceptable, so in this case, the decline be Content Policy was the incorrect action. If RhinosF1 had declined as needing more information, that would've been a conceivable outcome, just as approving it would've also been a conceivable outcome. Dmehus (talk) 03:10, 24 March 2022 (UTC)
 * I must admit Rhinos, I don't see what justification under our policies there is to prohibit businesses from having operational wikis (manuals and such), especially for private purposes. The Content Policy is explicit regarding commercial promotion, but it does not go out of its way to prohibit the use case described above. The fact Msn ignored the action/advisory with no justification whatsoever remains an issue though. --Raidarr (talk) 20:43, 23 March 2022 (UTC)
 * raidarr, exactly right regarding the former. As to the latter, see my reply above on why discussion with other wiki creators can and perhaps should be encouraged, but should not be required prerequisite. We've always had more liberal and more conservative wiki creators; I think it would be a detriment to the Miraheze wiki approval process if we tried to legislate this too much, or required the wiki requestor to wait through a back-and-forth between wiki creators. If one wiki creator feels comfortable approving and a previous one declined, that's okay, so long as, collectively, their net good approval/decline ratio is sufficient. Dmehus (talk) 03:14, 24 March 2022 (UTC)
 * Likewise I feel that wiki creators directly contradicting each other or having too much of a liberal/conservative gap is not a good look for the platform, or for the user experience encountering such inconsistency. Agency is permitted and encouraged indeed, but too much deviance - especially to the degree where a wiki creator's practices range out to little to no communication and decidedly non standard approval metrics - is a point too far for me. Likewise further if a wiki creator asks, it opens a door of communication that ought to be followed through, and not doing so resulting in open unresolved conflict is another blow on the overall end experience as well as for the consistency of the platform. I believe the approach you've taken here ranges into too liberal ultimately, and it is an issue to be discussed. As for the case at hand, I think there is at least one case where the net good approval/decline ratio is not consistent. So there remains a thing to be discussed. --Raidarr (talk) 15:27, 24 March 2022 (UTC)
 * RhinosF1, with regard to the latter, please see my replies above on why that's never been required. With regard to the former, by way of this example, that's an example of a wiki used by a commercial entity that is perfectly acceptable&mdash;it's even a public wiki, too, but it's not selling any goods or services. It's just providing support FAQs and documentation for a commercial accounting software. Dmehus (talk) 03:16, 24 March 2022 (UTC)

April's Fool Day
Silicona (talk) 07:50, 1 April 2022 (UTC)


 * Just kidding! You are not blocked. Silicona (talk) 07:51, 1 April 2022 (UTC)
 * Is pranking admins with a serious template an appropiate prank? Kinda seems a little off to me... ApexAgunomu (talk) 08:21, 1 April 2022 (UTC)


 * Hello! Yes, it's better you don't such pranks. Thanks! AlPaD (talk) 11:55, 1 April 2022 (UTC)

Twitter
. ~ RhinosF1 - (chat)· acc· c -  18:23, 15 April 2022 (UTC)

This edit
Regarding this edit, are you saying that Matomo user accounts have a separate two-factor authentication token/mechanism than MediaWiki two-factor authentication? If that's the case, that's fine.

As to the latter part of your comment, this is something that perhaps should be clarified, as one SRE team member has been still undertaking account recovery procedures, but I can assure you that Trust and Safety has the jurisdictional lead over user account data, including account recovery, removal, etc., as it's in scope of the Data Request Process together with the Privacy Policy and is in keeping with discussions I've had with Reception123 on IRC. Dmehus (talk) 06:01, 30 May 2022 (UTC)


 * Yes, on the first point. There's no link between any other services 2FA and the 2FA on the primary central auth cluster. Both myself & Reception123 have done them, on Owen's guidance that it was our authority. (Note: the word decisions is used as I'm covering both password & 2FA resets but in both cases the standard of proof is high and for passwords rarely met.) ~ RhinosF1 - (chat)· acc· c -  06:05, 30 May 2022 (UTC)
 * Looking at the two-factor authentication log, I'm not seeing where Reception123 has indeed recovered a user's account or otherwise disabled a user's two-factor authentication status. The standard of proof is indeed quite high, yes, but the jurisdictional lead is the Trust and Safety team, so you should be referring such requests to the Trust and Safety team. That's not to say SRE is not necessarily involved at all in account recovery procedures; indeed, some tasks require their involvement. For example, changing a user's registered e-mail address would need SRE's involvement, but that should be as directed by the applicable Trust and Safety team member following the Trust and Safety team having verified the user to their acceptable standards. Based on my conversations with Reception123, if SRE needs to be engaged (i.e., to update an e-mail address, change a password, etc.), they may well wish to retain the ability to undertake their own due diligence as well, and that's fine. Dmehus (talk) 06:15, 30 May 2022 (UTC)
 * I'll speak to Owen later in the week. ~ RhinosF1 - (chat)· acc· c -  06:16, 30 May 2022 (UTC)
 * I've spoken to Owen about this as well, and for greater clarity, have spoken to Reception123 as well and he agrees with me there's little need for SRE to play the lead role given the nature of account recovery and related to user account data being a Trust and Safety responsibility. I also understand you were rather upset when Reception123 significantly updated the Tech:Security policy page here, to reflect the shared role between SRE and Trust and Safety as it relates to security-related matters. I would rather suggest you be more willing to be cooperative, collaborative, and open to a shared jurisdiction across teams. It should serve you well in your career. Dmehus (talk) 06:22, 30 May 2022 (UTC)
 * I'm not having a public debate. This is going via Owen. My issues with the security policy are of completely different reasons. I have no issues with you taking the process over. I have openly said in multiple places how much I dislike it because it mainly involves telling users they've lost access to their account and a lot of digging to find the slightest hint. I just don't believe the guidance we've had reflects that you're Trust & Safety are currently in charge of it. ~ RhinosF1 - (chat)· acc· c -  06:26, 30 May 2022 (UTC)
 * I am not "in charge" of anything. I said Trust and Safety, which includes Owen. It's fine for Trust and Safety to delegate certain account recovery or user verification functions to SRE, whether to disable a user's two-factor authentication status on behalf of Trust and Safety or because the Trust and Safety team member was otherwise unavailable, or because Trust and Safety lacks the necessary access (i.e., password or e-mail reset). In any case, I think the clarification will be helpful. Dmehus (talk) 06:32, 30 May 2022 (UTC)
 * I've corrected the unclear wording but this conversation will stop here on-wiki and carry on via Owen. ~ RhinosF1 - (chat)· acc· c -  06:36, 30 May 2022 (UTC)