Requests for Comment/CU and OS local policy

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

Going to close this as it's more or less a repeat of a recently closed RfC (close titles, close enough proposals). Secondly, half of these proposals are invalid or assume things about current practices in general. 1. Wiki bureaucrats will never be given access to CU/OS by default, as this would give a very large group of users access to something that is considered personal information and would violate the privacy policy. 2. The groups aren't currently restricted to stewards and sysadmins, they are restricted to local groups that stewards don't have access to by default. 3. The rights may be requested by anyone but you need to demonstrate a need for the rights and convince Stewards (who are responsible for the rights themselves and the delegation of rights, per the approved policy) that they are not sufficient to handle the requests and that the rights should be delegated. -- Cheers, NDKilla ^{( Talk • Contribs )} 04:11, 9 January 2017 (UTC)

---

Something that MatthewPW, Amanda and myself have stood up for since day 1 is the ability for wiki founders to be able to use CheckUser and Oversight without needing to be a full-out steward. Now that Miraheze has an offical privacy policy, I think that the time has come to draft a policy regarding the local use of these rights. I have drafted a couple of proposals to get things started, but users are welcome to add more. Please share your thoughts on this, but please do not post insulting comments.

Assignment

Proposal 1

The CheckUser and Oversight tools will remain only assignable by stewards and sysadmins, but wiki founders can request access to these tools at any time. These requests will be granted unless there is an unforeseen reason why they should not be handed out, and such a reason must be made explicitly clear in a decline statement.

Comments

 Abstain Personally, I would go for proposal 2, but this would work as well. --- DeltaQuad (talk contribs email), 22:27, 8 January 2017 (UTC)

 Strong oppose Speaking as a wiki founder, wiki founders have no business having access to CheckUser or Oversight. The easiest way to prevent a breach of personal information is to never have that information in the first place. --Robkelk (talk) 01:45, 9 January 2017 (UTC)

 Support So the founders can handleits own problems. H1 (talk) 02:08, 9 January 2017 (UTC)

Proposal 2

Defaulting to the bureaucrat group, but being restricted to the "founder" group if it exists, the technical permission will be granted to allow the appropriate users to assign themselves to the checkuser and oversight groups. This would basically be the "userrights" permission, just disallowing self-granting of steward rights.

Comments

 Strong support This would be the ideal scenario. --- DeltaQuad (talk contribs email), 22:27, 8 January 2017 (UTC)

 Strong oppose Speaking as a wiki bureaucrat, bureaucrats have no business having access to CheckUser or Oversight. The easiest way to prevent a breach of personal information is to never have that information in the first place. --Robkelk (talk) 01:45, 9 January 2017 (UTC)

 Strong support Yay it good. Ideal. H1 (talk) 02:10, 9 January 2017 (UTC)

Proposal 3

The bureaucrat group (by default) on local wikis would have implicit access to these rights included in their other permissions.

Comments

 Oppose This could cause some security issues if a bureaucrat account was ever to be compromised. --- DeltaQuad (talk contribs email), 22:27, 8 January 2017 (UTC)

 Strong oppose Speaking as a wiki bureaucrat, bureaucrats have no business having access to CheckUser or Oversight. The easiest way to prevent a breach of personal information is to never have that information in the first place. --Robkelk (talk) 01:45, 9 January 2017 (UTC)

 Weak oppose No. I think that the bureaucrat is not, but the rights of the founder is "yes". H1 (talk) 02:16, 9 January 2017 (UTC)

Proposal 4

EDITED TO REFLECT COMMENT BY Void|Whispers
Status quo: These tools remain available only to Stewards and sysadmins. Do not "have the rights handed out locally" unless there is demonstrated need, and then only to a member of the community elected by the community.

Comments

 Strong support There are laws against disclosing personally-identifying private information to people who have no business knowing that information. The easiest way to prevent wiki founders and bureaucrats from disclosing personally-identifying private information is for them to never have that information in the first place. --Robkelk (talk) 01:45, 9 January 2017 (UTC)

• FYI: the current policy is that if a wiki has the need for these permissions, and if the community has elected a member of said community to use the tools, then they will be granted these tools. The reason the tools have not been used outside of Stewards/sysadmins is because there has never been the need for it. -- Void ^Whispers 02:21, 9 January 2017 (UTC)

 Strong support: For two reasons. One, unless I am guilty of a criminal act, engaging in a business transaction for which personal information is required to verify my identity for transfer of funds, legally required to disclose such information for purposes of employment or fulfilling some other form of contract, or some other cause for which people need my identity under legally proscribed conditions, there is no need whatsoever to force people to dox themselves just so someone running a wiki can feel better. Thus, I can foresee no other reason change policy on this matter whatsoever, unless one falls under this trope, and even if they do, unless they can legally compel me to put myself in a condition to disclose my identity, I will NOT dox myself to make anyone happy if I do not have to, and no one else should be compelled to give up their legal right to privacy just so someone can sleep at night, which is not a good reason to ever change the current policy. Second, if we are supposed to toss our legal right to keep our private lives aside, then I expect the parties who want this to do so first, and even then I reserve the right to keep mine to myself unless I can be legally compelled to divulge that information. GethN7 (talk) 04:02, 9 January 2017 (UTC)  Strong oppose This is totally contradictory to the purpose of even having this discussion. --- DeltaQuad (talk contribs email), 02:17, 9 January 2017 (UTC)

 Comment: Without an option to say "no", the discussion is not worth having. --Robkelk (talk) 02:30, 9 January 2017 (UTC)

The last thing I will say this evening is that remember this is all your personal opinion. You need to stop speaking like you are sure the entire community will agree with you. It is impossible to know whether or not anyone will agree with me (what a concept!) --- DeltaQuad (talk contribs email), 02:33, 9 January 2017 (UTC)

 Strong oppose I think that local can be "an Independent" to solve localproblems. H1 (talk) 02:19, 9 January 2017 (UTC)

Revocation

Proposal 1

These rights can be removed from a local user by a steward or sysadmin without warning if clear abuse is identified.

Comments

 Strong oppose Warnings should always be given. --- DeltaQuad (talk contribs email), 22:39, 8 January 2017 (UTC)

 Strong support If for some reason these rights are going to be given, they need to be removed as soon as that those rights are being used to violate laws against disclosing personally-identifying private information. Anything else would put Miraheze at legal risk. --Robkelk (talk) 01:45, 9 January 2017 (UTC)

 Strong oppose Per DeltaQuad H1 (talk) 02:20, 9 January 2017 (UTC)

Proposal 2

Same as proposal 1, but only after a warning has been given to the user in question.

Comments

 Abstain This would work, but I would prefer to see proposal 3. --- DeltaQuad (talk contribs email), 22:39, 8 January 2017 (UTC)

 Strong oppose This would take too long, and personal privacy rights of the editors should come before somebody's desire to violate those rights unless the operation of Miraheze as a whole is at risk. --Robkelk (talk) 01:45, 9 January 2017 (UTC)

 Abstain Per above H1 (talk) 02:22, 9 January 2017 (UTC)

Proposal 3

If any user suspects abuse, that user must open a local community discussion on the affected wiki, and should post a link to it either on the global Stewards' noticeboard and/or the community portal. If the majority of the local community agrees that abuse has occurred, the rights will be stripped by a steward or sysadmin.

Comments

 Strong support This would be the ideal scenario. --- DeltaQuad (talk contribs email), 22:39, 8 January 2017 (UTC)

 Strong oppose This would take too long, and personal privacy rights of the editors should come before somebody's desire to violate those rights unless the operation of Miraheze as a whole is at risk. --Robkelk (talk) 01:45, 9 January 2017 (UTC)

 Strong support Per above H1 (talk) 02:24, 9 January 2017 (UTC)

Monitoring usage

Note: This section only applies to the use of checkuser rights. It does not apply to oversight.

Proposal 1

A custom Miraheze feature will be developed that allows stewards and sysadmins to view a global checkuser log.

Comments

 Support This is ideal, although it is a lot of time and effort. --- DeltaQuad (talk contribs email), 22:39, 8 January 2017 (UTC)

 Abstain I expect that Stewards already have this ability without using a custom feature; there's no point duplicating it. --Robkelk (talk) 01:45, 9 January 2017 (UTC)

 Abstain Per Above H1 (talk) 02:25, 9 January 2017 (UTC)

Proposal 2

Stewards and sysadmins can monitor the local logs once a month or so, but when assigning rights for this purpose, they must give the reason "checking the log" or something similar as the userrights summary.

Comments

 Abstain I really don't have any strong feelings on this. --- DeltaQuad (talk contribs email), 22:39, 8 January 2017 (UTC)

 Strong oppose This would interfere with the Stewards' ability to maintain Miraheze as a whole. --Robkelk (talk) 01:45, 9 January 2017 (UTC)

 Strong oppose per Above H1 (talk) 02:28, 9 January 2017 (UTC)

---

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