Page MenuHomePhabricator

Proposal to create acl*oversight and acl*checkuser ACL projects
Closed, InvalidPublic

Assigned To
None
Authored By
TheresNoTime
Oct 17 2018, 7:46 PM
Referenced Files
None
Tokens
"Dislike" token, awarded by Krenair."Like" token, awarded by stwalkerster."Like" token, awarded by Rxy.

Description

It would be useful to have ACL projects for current oversighters/checkusers, so that privacy/security related tasks which are relevant to the group (such as T207085) can be viewed by the functionary group without having to manually add them.

I propose:

  • acl*oversight, which we can keep up to date with users who currently hold oversight on any project
  • acl*checkuser, which we can keep up to date with users who currently hold checkuser on any project

I don't mind maintaining that list, along with the help of some other stewards etc.

Per 'Project management#Types of Projects' I believe this will need to be discussed - I hope the benefits are relatively clear, and welcome any suggestions or comments.

Event Timeline

This seems like it would be pretty useful.

Security tasks are generally kept to a limited audience of MediaWiki developers plus a few other people. We created an ACL for stewards because there was a repeated need to add them to individual tasks, and they're already an incredibly trusted group of people who are relatively well known to developers, and are familiar with our workflows.

I don't think adding all oversighters and all checkusers to individual security tasks is a good idea. There's no need for everyone to be CC'd to T207085. A few of them? Sure.

I would suggest nominating one to two people as liasons for each group who can be cc'd as necessary and inform other oversighters/CUs about the presence of bugs that are pertinent. In the past we've done it informally.

@Legoktm on reflection, I'm agreed entirely i.r.t "I don't think adding all oversighters and all checkusers to individual security tasks is a good idea" - there are a few other cases where general, non-security tasks are of immediate interest to the greater CU/OS community, but I'm not sure using an acl* project would be useful there.

Appears that this task can be closed...

Krenair subscribed.

per requestor

In T207323#4687063, @Samtar wrote:

@Legoktm on reflection, I'm agreed entirely i.r.t "I don't think adding all oversighters and all checkusers to individual security tasks is a good idea" - there are a few other cases where general, non-security tasks are of immediate interest to the greater CU/OS community, but I'm not sure using an acl* project would be useful there.

I would suggest watching the CheckUser, MediaWiki-Revision-deletion, and/or Stewards-and-global-tools projects depending on what you want.