- The following discussion is closed. Please do not modify it.
- Most likely, new comments will not be taken into account by the new three Working Group members in their work of developing the final Recommendations. You are free however to continue discussing in the spirit of "discussing about Wikipedia is a work in progress". :)
WAS THE LAST DISCUSSION PAGE READ AT ALL?
- As a matter of urgency, can the WG state the following:
- Was every statement on the discussion page read, as required for a consultation?
- Why was there no active engagement?
- In excess of 90% of those commenting were against it. Why are the recommendations not taking that on board?
- Has it been considered the likelihood of some or all local Communities not considering this binding unless and until the concerns are actively worked with?
I've still watchlisted the old Talk Pages - please start replying to every discussion (both still on the page and archived) and then resubmit the recommendations once that's done. Nosebagbear (talk) 15:43, 21 September 2019 (UTC)
- Nosebagbear, based on this, which shows that all of the "recommendations" were to be connected at a "harmonization sprint" held during 20–22 September at a 5-star Mediterranean resort, I'd guess that the working groups had no motivation to read or engage with community feedback, despite requesting it. I'd be happy to be proved wrong, but it looks like the plan was to ignore communities. EddieHugh (talk) 13:57, 22 September 2019 (UTC)
- Apparently the Community Health members who attended were: @Philip Kopetzky, SRientjes, and Mervat:. I plan to email them and would encourage others to do so (for the love of god do so politely, no-one is convinced by screaming). Nosebagbear (talk) 14:06, 22 September 2019 (UTC)
- I agree that comminication with the working group members is essential, but it should occur here. If they do not communicate here they destroy any legitimacy and credibility they may reasonably have expected. · · · Peter (Southwood) (talk): 17:08, 23 September 2019 (UTC)
- Given the extreme lack of engaging with community discussions, when will it be the right time to start RfCs with votes of no confidence in this process? ChristianKl ❪✉❫ 11:38, 25 September 2019 (UTC)
- Dear all - the meta pages were taken into consideration and helped us put more effort into clarifying a few things that were taken the wrong way.
- On a personal note, I would also like to reiterate as a volunteer to you as volunteers that the recommendations are designed to empower communities, not force any changes upon them. They also address many issues that most of you from English Wikipedia are either not aware of within your own project or affect other projects more - I hope we can publish the survey results sometime soon to help you understand our approach. Keep in mind that these are long-term goals that will not happen overnight, but will have to be discussed in every community based on their context and what makes the most sense. Cheers, Philip Kopetzky (talk) 15:52, 27 September 2019 (UTC)
no less than two years after the initial access has been granted in the user rights log and no less than within five years
Should one of these "less"es be a "more"? — Rhododendrites talk \\ 18:16, 21 September 2019 (UTC)
Wouldn't these measures exacerbate issues of declining admin numbers?
On the projects I frequent, there are indeed challenges regarding veteran-newbie relationships. Improving resources and training for administrators/functionaries on interacting with newbies might help, but it's hard to read some of these recommendations without worrying about the issue that some see as one of Wikipedia's main existential threats: declining numbers of administrators. There are two interrelated problems: not enough people volunteering to take these roles on one hand and the community having trouble agreeing to promote those who volunteer. On enwiki, standards are exceptionally high, despite most people appreciating that we need more admins and many efforts to make it more reasonable. The process is also a miserable one to experience, and requiring that people do it on a routine basis will not reassure the reluctant. Some have suggested term limits as supporting the "it's not a big deal" view of adminship, but based on the direction things have been going for the past decade, it's hard to see it having much effect. There are some interesting ideas in here, and I entirely agree with some of the end goals, but if the existing numbers are insufficient, how would limiting their participation help? One could say it would create an urgency that would lead to changing standards/processes, but we already have broad acceptance of an urgency and not a lot of agreement on fixing it... — Rhododendrites talk \\ 18:33, 21 September 2019 (UTC)
- Maybe this is intended to go with a system of secret ballot voting, where there is no opportunity to check whether the candidate is appropriate, and with some vote stacking arranged outside of the project can lead to a takeover by a non-neutral group. I think that this recommendation is ill-advised at best, and at worst could facilitate a hostile takeover. · · · Peter (Southwood) (talk): 16:55, 23 September 2019 (UTC)
Risker, would you mind chiming in on this since you're both involved in strategy and a sysop/CU/OS on en.wiki. As written, this would basically make the existing en.wiki functionary system unworkable. There's the issue with oversight (ArbCom has to have CU/OS) and then there's the functional point that having
+oversight can be extremely helpful as a CheckUser even if the individual doesn't make assisting on the oversight team a primary focus. This seems unworkable for the largest project as written. TonyBallioni (talk) 03:34, 22 September 2019 (UTC)
- (+1); this was explicitly pointed out at the t/p of the first set of recommendations by multiple people. Did they even read the feedback? Winged Blades of Godric (talk) 12:17, 22 September 2019 (UTC)
"Separation of powers" only makes sense if the powers are separable
Echoing the above, this appears to be completely unworkable on enwiki and presumably other projects. I understand the logic of diversifying the functionary team, but doing so by dividing up the rights seems to miss the point that they're all related to each other:
- Sysop is a hard requirement for checkuser, oversight, or ArbCom, because all their jobs are extensions of normal admin tasks (e.g. blocking, revision deleting).
- One of the primary roles of ArbCom is oversight of the checkuser and oversight teams. Obviously, it cannot do this if its members don't have access to those tools themselves.
- CheckUser and oversight are essentially the same role—performing admin tasks based on nonpublic information–that are artificially separated by the specific tool used.
I think it would make more sense to combine these bits into a common functionary permission, and use that as a basis for enlarging and diversifying the pool of people that hold them. Joe Roe (talk) 13:50, 22 September 2019 (UTC)
- Can I clarify that you mean creating an "Arbitrator right" that comes with both OS/CU and a "CUOS" right with both (for non-arbs) - rather than just adding them to sysop? Nosebagbear (talk) 13:56, 22 September 2019 (UTC)
- I'd just have a functionary right that gives access to tools involving nonpublic information (currently OS and CU). Joe Roe (talk) 17:08, 22 September 2019 (UTC)
- Going off the “hard requirement” bit Joe points out: if the idea at sysop and CU/OS is too powerful, I’ll go ahead and point out that the only recent example of the WMF removing a CheckUser for cause was Special:CentralAuth/Ciphers. Ciphers was a CU but not a sysop. If separation of powers is supposed to decrease abuses, you’d expect that you wouldn’t find someone who is only a CU being a vandal sock. Instead, you find the opposite. There’s simply no correlation here. TonyBallioni (talk) 16:35, 22 September 2019 (UTC)
- Well said. If this held up, we should constantly be removing Stewards with all the chances for abuse their power grants them. Nosebagbear (talk) 16:58, 22 September 2019 (UTC)
At least in the context of English Wikipedia, the "at most two rights out of four" recommendation doesn't work at all. Historically all arbitrators have been administrators, and even if that changes at some point, certainly the majority will be. That would mean that no arbitrator could be a checkuser or an oversighter, which would not only mean throwing away valuable experience, but would also make it impossible for the arbs to fully evaluate arbitration matters that involve checkuser results or oversighted material. I also can't imagine that one could be fully engaged as a checkuser without having administrator rights (particularly being able to view deleted articles or revisions and block socks), and I believe it was found to be technically impossible to use the oversight tool without adminship. So it is difficult to envision how the revised structure would work. Regards, Newyorkbrad (talk) 16:26, 25 September 2019 (UTC)
- (@Newyorkbrad:A little nitpick, but on enwiki CheckUsers already have access to deleted revisions per en:Special:ListGroupRights. I am not so certain about Oversight; according to that special page a lot of ancillary permissions are there but the right to delete pages isn't)
- I think it was said in some discussion on enwiki that some of these recommendations might be inspired by German Wikipedia practices. Among these, last I checked dewiki CheckUsers generally do not action their results themselves but have other admins issue blocks. Perhaps that was the thinking there. Jo-Jo Eumerus (talk, contributions) 10:11, 28 September 2019 (UTC)
Why isn't steward on this list?
If the idea is to promote leadership and diversity in those ranks why is Steward not one of the listed roles that would cause a limit? Well the answer is because that presents all sorts of challenges given the obligations of stewards on the wikis they are responsible for being CU/OS on. It's a good reason. It's also the reason that this recommendation is a poorly conceived way of accomplishing the stated goal. Best, Barkeep49 (talk) 03:58, 24 September 2019 (UTC)