Page MenuHomePhabricator

Remove permissions from Wikifunctions staff once the community has their permanent admins and crats
Open, Needs TriagePublic

Description

Not now, but after community elected their own bureaucrats. This eventually need to be done, since Wikifunctions staff is currently a very dangerous group.

  • Remove from Wikifunctions staff ability to grant/remove Administrators, Bureaucrats
  • Remove from Wikifunctions staff ability to grant/remove Functioneers, Maintainers, Administrators and Bureaucrats to themselves and add all rights of these four groups plus translation admin to it (before T338027 we need to manually copy the rights)
  • Wikifunctions staff continues to be able to add/remove Wikifunctions staff, and add/remove Interface administrators to own account
  • Whether to remove from Wikifunctions staff ability to grant/remove Functioneers, Maintainers is TBD

Event Timeline

Bugreporter changed the task status from Open to Stalled.Aug 7 2023, 5:43 PM

What do you mean with "very dangerous group"?

There are very few user group that can remove bureaucrat (such as stewards), and currently staffs are de facto "super bureaucrats" (compare https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/New_user_group_for_developers).

That's true, and there is indeed more power in this group than a sustainable project should have. We will and always have explicated that we will retreat from those rights as soon as the community organises itself. I find the term "very dangerous group" unnecessarily aggressive and polarising, and would like to ask for a more collaborative spirit going forward.

There is no interest and no plan to retain those rights in the medium term.

Just curious, is there anything specific this task is stalled on as of now? Is it Wikifunctions moving to the "General Availability" stage?

In any case, I've provided some information regarding how Stewards could assist Wikifunctions at https://www.wikifunctions.org/wiki/Wikifunctions:Project_chat#Let's_forward_user_group_requests_to_Stewards,_and_not_WMF. Crosslinking, as it might be helpful while discussing this task.

Just for transparency I started a discussion on the project chat "Do wikifunctions staff still require bureaucrat?" which relates to this somewhat.

@Bugreporter You note in the description that this should be done only after WF has its own Bureaucrats, but with WF Staff no longer holding the bureaucrat group and stewards currently managing all advanced rights on WF, is there any reason for this to still be stalled. Would it be a good time to mark as open and update the description to reflect these onwiki changes and to get started with removing this ability?

Currently Wikifunctions staff are able to add bureaucrats to any users, and I am proposing to change this only after the community has their own ones.

I see, I think my question and through process was more: Is there any reason that we need to wait for WF to have crats (This probably won't happen any time soon) and currently crat perms hold no benefit over the staff group so there is no reason for any WF staff user to grant crat to any user considering any community elected crat would be added through stewards instead of through WF staff therefore making the ability for WF staff to add the bureaucrat group entirely useless at this point. If an unexpected circumstance was to occur where a WF staff required crat for whatever reason, I don't see why an expedited request at meta:stewards/requests would not be able to handle such an event. So why not just open this task now?

Wikifunctions staff member speaking here. :) The Wikifunctions staff team is not using their additional rights (nor the right to appoint/remove someone) by their own decision, because we want to empower the community as much as possible, and to let community members decide on all relevant community matters. The only right staff members are actively using is the one of appointing Functioneers, but this task also will be given to the community after the limited release period will end.

One solution to this can be that we explicitly state in the Wikifunctions staff editing policy that staff can keep their additional rights, with the explicit clause that they can use them only in case of a project-threatening emergency. We can even put a temporal limit to the clause, saying that this applies until the project is in limited release. This would be very similar to what happened on Wikidata in the first year of the project: I was there as a volunteer since the beginning, and I remember that staff agreed not to use their rights, except in case of emergency, that luckily never got to happen. When the project got more stable, the user group was stripped of the remaining rights.

Anyway, staff will always follow community consensus, and I want to make clear that this issue makes no exception.

Jdforrester-WMF changed the task status from Stalled to In Progress.Mar 7 2024, 5:09 PM
Jdforrester-WMF assigned this task to DVrandecic.

Reopen. Wikifunction staffs can still add/remove sysops and crats to their own account, so it is still not the final state I proposed. Though I will not suggest to change the de facto (i.e. remove the ability) until Wikifunctions has crats elected by community.

Pppery renamed this task from Remove ability for Wikifunctions staff to grant/remove admins and bureaucrats once community has their permanent ones to Remove permissions from Wikifunctions staff once the community has their permanent admins and crats.Nov 27 2024, 5:09 AM