Általános viselkedési szabályzat/Végrehajtási irányelvek/Felülvizsgálati megbeszélések

Általános viselkedési szabályzat

• Piszkozat
• Átdolgozott végrehajtási irányelvek
• Koordinációs Bizottság (U4C) szervezet
• Projekt áttekintés
• Gyakran ismételt kérdések
• Képzési modulok

Az Általános Viselkedési Szabályzat (UCoC) Felülvizsgálati Bizottsága az Az Általános Viselkedési Szabályzat Végrehajtási Irányelvei javításainak meghatározása érdekében a következő kérdésekkel kapcsolatban kérünk hozzájárulást a bizottság felülvizsgálatához. Ezeket a javítási területeket a közösségi viták és az irányelvekről szóló 2022. márciusi közösségi szavazás során benyújtott észrevételek alapján lettek meghatározva.

Ha az irányelvekkel kapcsolatban ezeken a területeken túlmenően bármilyen aggályod van, akkor használd az Általános viták területét. Ezúton is köszönjük, hogy időt és energiát fordítasz arra, hogy közös közösségi területeinket mindenki számára biztonságosabbá tedd.

Képzés

Aktuális üzenet

A Wikimédia Alapítványnak a helyi közösségek és tagszervezetek útmutatásával képzést kell kidolgoznia és megvalósítania a közösségi tagok számára, hogy képesek legyenek azonosítani, kezelni és csökkenteni az UCoC megsértése által okozott károkat, különösen a zaklatást és a hasonló magatartási problémákat.

Az Általános viselkedési szabályzat elismerésére és betartására kötelezett személyeknek képzésen kell részt venniük, hogy biztosítsák a végrehajtás közös megértését. A közösség más tagjai is részt vehetnek ezen a képzésen, amennyiben ezt kívánják.

Kérdés

A tervezet készítőinek szándéka, hogy segítsék biztosítani, hogy a helyi közösségek hatékonyan szabályozzák magukat a biztonságos együttműködés érdekében minden wikin és a közösségek között, az UCoC által meghatározott közös minimális elvárások és - ahol alkalmazható és indokolt - az ezen túlmutató helyi projektszabályok alapján. Néhányan aggályaiknak adtak hangot a jelenlegi nyelvezettel kapcsolatban. Megoldható-e jobban a képzés?

Megbeszélés (Képzés)

• Any training should be community-led, not WMF-led. For a dozen reasons, including multilingualism, regional robustness, and developing shared capacity for finesse. Proposed text, also shorter and to the point: : "The WMF should help communities develop and implement workshops to help community members identify, address, and mitigate harms caused by harassment and similar conduct issues. Functionaries expected to uphold the Code of Conduct will be encouraged to participate periodically in such workshops to align the understanding and interpretation of the Code across the movement."

–SJ talk  21:50, 25 May 2022 (UTC)

• DWI is right. Reading complex text shifts the window of how one thinks in the moment :) I do think the idea that this is a dynamic document, regularly revisited (whether in 'training' or otherwise) and placed into context, is worth mentioning. [I'd prefer this whole doc be named 'implementation guidelines', since "how does a broad community implement a shared sense of 'conduct'" is more interesting for a self-governing network than "who drops the hammer on this part of the mechanism"] Perhaps something like:

  "Communities may periodically run workshops to help improve community health, including reviewing this code of conduct and how it is applied. The WMF can help with such workshops and with incorporating feedback into future revisions or clarifications of the Code." –SJ talk  19:12, 26 May 2022 (UTC)

I say keep it simple: Drop trainings completly. Also: Guidelines that are so complex that you need training to understand them, are an indicator the problem is the guidelines. Der-Wir-Ing ("DWI") talk 16:32, 26 May 2022 (UTC)

SJ's and DWI's suggestions are both more sensible than what we currently have. Either would be fine by me. Andreas JN466 17:53, 26 May 2022 (UTC)

FWIW, the statement above about drafter's intent is incorrect but the drafters were asked about the language too late to actually make changes so the inaccurate statement remains. Barkeep49 (talk) 14:35, 28 May 2022 (UTC)

• If nothing else the requirement that advanced permission holders have to take the training should be removed. This is well outside what people would consider reasonable and frankly isn't going to happen - most people in those permission groups (several thousand) will simply refuse and will resent whoever told them they had to take this training. If the requirement was actually enforced, by removing permissions from anyone who won't take the training, or refusing to give advanced permissions to anyone who hasn't done it, then it would cause major damage to projects. If you want to have this training then it should be optional and it should ideally be developed by communities themselves. However I do agree that the UCoC should be sufficiently transparent that people don't require training to understand and/or enforce it. Hut 8.5 13:02, 29 May 2022 (UTC)

  One of the most important principles of English Wikipedia is accountability. While obviously the details of CheckUser-based actions may be private, the basic expectation is that anyone who performs an enforcement act should be able to explain the reasons to the community who did not pass any enforcement training. This means the enforcement rules should be simple enough that such training not be required. 93.172.252.36 06:54, 30 May 2022 (UTC)

  And we especially shouldn't be using the term "attend training", as this implies an in-person (or at least scheduled) process that would present an undue burden to many editors. "Participate in training" might be better. -- Ahecht (TALK
  PAGE) 17:23, 1 June 2022 (UTC)

• I think you need to define "Individuals required to acknowledge and adhere to the Universal Code of Conduct" within the enforcement guidelines. As it stands, it is entirely unclear who is being required to attend training. ONUnicorn (talk) 01:17, 1 June 2022 (UTC)

• I'm pretty sure that's a reference to the people listed in the "Affirmation of the UCoC among certain groups" section, which includes admins. Hut 8.5 18:01, 3 June 2022 (UTC)

• This is completely unreasonable and is not going to work. I will vote against any version of the document which mandates training for advanced rights holders.--Ymblanter (talk) 18:51, 2 June 2022 (UTC)

  And so will I. There are too many mandatory requirements for a volunteer-driven project. Looks like we are drifting towards a "police state". I seriously fear the enforcement turning into prosecution. Lozman (talk) 17:14, 29 June 2022 (UTC)

Its section title "Recommendations for UCoC training for community members" gotta go. You cannot mandate someone to do something when it is just a recommendation. Or you can replace "mandate" in the main text with "recommend" although I'm not sure who is recommending the training to whom. --Rotten Apple777 (talk) 21:53, 2 June 2022 (UTC)

• As Hut 8.5 writes, I can't see most admin-level permission holders being prepared to "attend training"; a smaller group of ArbCom members and checkusers perhaps. Espresso Addict (talk) 00:32, 3 June 2022 (UTC)
• The group in WM that has most dramatically and repeatedly proven its incapability of handling behavioral guidelines in a fair and appropriate manner, is the WMF. Their insensitivity to the basic principles of fair play and justice has several times threatened to spit or destroy the movement. The most notorious recent instance is of course their actions leading to Wikipedia:Arbitration/Requests/Case/Fram. The most far reaching is the attempt to legislate not just the principles of conduct (which is a reasonable movement-wide function), but the details of enforcement (as in the proposals leading to the present discussion), in conjuction with their attempt to supersede the actions of established WP communities with effective ArbComs., and simultaneously deal with those communities insufficiently large or representative to yet be fully responsible. Of course we're discussing here the details of language in the hope of harmonizing their proposals with current good practice; it would have been enormously better to avoid details and exhaustive lists of misbehavior, and let the communities work it out as it applies to them.

This does not mean I trust all the individual community procedures. Based on my 5 years at enWP arbcom, I continue my advice to never go there, for it too is subject to over-specific and ill-devised action combined with equally frequent refusal to take direct actiion when needed and rely instead on platitudes. But at least this affects only its own WP, and the members are elected in a single straightforward and direct manner. DGG (talk) 08:27, 3 June 2022 (UTC)

• "it would have been enormously better to avoid details and exhaustive lists of misbehavior, and let the communities work it out as it applies to them." <— A fine point. Let's shift these documents in that direction through this and future edits, simplifying and streamlining here while inviting communities to work out their own approaches. –SJ talk  16:55, 3 June 2022 (UTC)

• I am personally quite happy to attend a training session; at worst, it would be a waste of time (god knows I've seen a lot of poorly crafted "diversity training" sessions, but that's neither here nor there). However, a considerable number of advanced rights holders that I know have made it quite clear they would rather resign than attend a mandatory training. Losing this group is not going to aid the goals the UCoC claims to have; quite the contrary.
  I would strongly recommend offering resources for people interested in accessing them, and doing nothing further. You cannot program sensitivity into a person unwilling to learn it; you certainly cannot do so via a two hour video lecture. Those advanced rights holders interested in educating themselves about internet harassment will do so; those who aren't cannot be compelled, and it is not in the movement's interest to jettison them in response. Vanamonde93 (talk) 17:42, 4 June 2022 (UTC)

• I agree with Vanamonde for the most part about programming sensitivity into a person unwilling to learn it, but will add that in some cases, it isn't necessarily unwillingness but rather a personality disorder that impedes proper social interaction. Anonymity makes that nearly impossible to know, and certainly doesn't offer much guidance in responding to it. I can certainly relate sympathetically to other female editors who have been/still are targets of classic bullying, hounding and/or mistreatment, especially in topic areas that are influenced by subjectivity and epistemic differences. While I support WMF's involvement and understand some of the actions that were taken in the past, I tend to agree with what others opined that training should be a decision made with input from the respective communities. At the same time, I question the efficacy of such training. I am a volunteer trainer for NPPSCHOOL and have had excellent results, but that is more about learning WP:PAG, not behavioral issues. Also, none of the aforementioned takes alliances into consideration; therefore, it can be, and in many instances is, a rather complex situation. Perhaps some of our WMF team members would consider training with some of the community's trainers in an effort to have a better understanding of where the behavioral issues tend to surface. Just an idea. Atsme^📞📧 21:00, 4 June 2022 (UTC)

• These sorts of trainings have unfortunate connotations of long, dull, bureaucratic, mandatory seminars in the corporate world. At their worst, such seminars are a complete waste of time or even breed resentment that exacerbates existing problems in workplace culture. The UCoC trainings, however, are as yet formless. Perhaps they will be short, perhaps they will be tailored to communities, perhaps they will be modular to allow people to take just the ones they want, perhaps they will be designed to be tolerable. I don't know what work has been done on them already; I suspect none, but there are so many layers to this process I may have just missed it. The key at this stage is, IMO, securing a reasonable process for their creation, testing, feedback, and implementation. I know nobody wants yet another "process" in this process-o-processes, but it's an important part of the overall project, and I don't think there's any rush.
  In my view, the best role for the WMF would be to distill some bare minimum standards from all of these discussions and create a baseline version of the training for communities to use by default. For those communities which want to develop their own training that meets those bare minimum standards, provide them with lots of resources (e.g. paid designers/consultants) to accomplish the task.
  I'd like to disagree with comments above (and which I've seen elsewhere) that either "we don't need training" or "if training is needed, the guidelines are too complex". The UCoC isn't just about guidelines; it's about people. It's about being better able to handle extremely sensitive and extremely complicated phenomena like harassment. We shouldn't expect admins, et al. to be psychologists or social workers, but that doesn't mean there isn't room for improvement in the way we support folks dealing with emotionally intense situations (I'd include people accused of violating UCoC in that category, btw). Yes, some of it is going to be bureaucratic, inevitably, but it's also about making sure people understand what recourse they have, what resources are out there, not falling into communication pitfalls that make things worse, etc.
  One more thing: Any training should also make it very clear what's not expected of admins. Many admins do not get involved with complicated/intense behavioral issues. Some people tend to a particular area of the project and rarely even interact with other people -- and that's perfectly fine. I could see those folks being intimidated by this prospect of UCoC/training and responding negatively to the idea that they will be pushed outside of their comfort zone. As volunteers, I find that completely reasonable. So part of the training is, yes, about the UCoC and how it works, but also to make clear that if you signed up to clear administrative backlogs, you're not suddenly going to be drafted into the conduct police, so how about e.g. a module on "here's how to pass this off to someone else" or the like. — Rhododendrites ^talk \\ 18:28, 5 June 2022 (UTC)
• Almost all large communities have already developed their own rules of conduct. For all of those communities, the UCoC principles are not new per se. The novelty is perhaps in the form they have expressed. Therefore, why advanced users, without any charge of violation of the rules, periodically passing strict qualifications within their own communities and often having years of prior experience, should benefit from bureaucratic training sessions on topic they know very well, possibly provided in a language they are not familiar with, and by trainers having less experience and poor mastery of peculiarities of that local community? Has WMF assessed how many administrators will resign to avoid these, quite shaming, mandatory remedial courses, clearly conflicting with the voluntarism that so far dove any action in projects? And how WMF is verifying that volunteers forced to be exposed to those training sessions will have an adequate level of comprehension of contents, or will take care of it in their activities within the projects? --Nicolabel (talk) 14:43, 6 June 2022 (UTC)
• SJ and DWI both make a strong range of correct points here. 1) Any mandatory training (especially as required by a group other than their local community) is likely to lose us many admins/functionaries. 2) The Community, not the Foundation, should be the dominant party on deciding training content and method. At a minimum, absolute veto power. 3) Speaking for myself, I despise training that tries to teach me stuff I know, or is obvious. Unless you have a way to ensure the training doesn't waste my time (in which case, go make your millions), don't require it. Nosebagbear (talk) 20:37, 6 June 2022 (UTC)
• Did the folks on this committee just totally forget that we are all volunteers around here? You want to make anything mandatory, you need to pay for it. I've held numerous advanced permissions for over a decade and not a single one of them had mandatory anything, now you're going to tell us that we are all now saddled with this new responsibility, whether we like it or not, and there is mandatory training. I thought perhaps in the revision process you all would have the sense to back down on this point and I'm sorry to see that's not the case. It is my intent, should this become an actual rule, to refuse to take the mandatory training, and to encourage other advanced permission holders to refuse. We won't quit our duly-elected community positions, and we won't take your mandatory training. We'll see who blinks first, all you have to threaten us with is to fire us from jobs we don't get paid to do. Beeblebrox (talk) 19:56, 16 June 2022 (UTC)
• Generally speaking, I agree with Beeblebrox. I certainly would have no issue if training were made available for those who would like it, but it should be optional—we're volunteers, not employees. I honestly don't imagine the WMF could offer any training which would teach me anything that fifteen years' experience as an admin hasn't, and I will not be attending any "mandatory training" unless you're planning to pay me for my time. Seraphimblade (talk) 05:27, 19 June 2022 (UTC)
• I agree with many previous commenters that mandatory training is completely unacceptable. The WMF should only go so far as to provide training materials; it will then be up to the communities to either use them as-is or adapt them if necessary (or neither). Silver hr (talk) 16:49, 3 August 2022 (UTC)

• The English Wikipedia (and many other Wikipedias) has strong rules about "No legal threats". Unfortunately many wikipedians do not understand what constitutes a "legal threat".

I suggest that any administrator who takes an action that has a legal dimension (such as en:WP:NLT) should show evidence of having at least some legal knowledge (for example, having received credit for at least one law-related module at college level) and that such evidence should be noted on their user page BEFORE they take any such action. If the number of admins who are able to deal with such situations is small, they might well develop techniques that will calm a situation rather than inflame it. Such a technique might include blocking a user until they have given a satisfactory response to a few simple questions such as "Who exactly are you going to sue?" and "In which court?" etc. If privacy is an issue, responses could be made by e-mail to the administrator concerend. If the hot-headed editor realises that he has been "shooting his mouth off" about an issue that he does not really understand, he could well be re-instated after a proper appology. If on the other hand there is a genuine problem, the administrator is better equiped to deal with it. Martinvl (talk) 17:23, 3 August 2022 (UTC)

Megerősítés

Aktuális üzenet

Az alábbi személyeknek nyilatkozniuk kell (aláírt nyilatkozat vagy más, később meghatározandó formátum útján) arról, hogy tudomásul veszik és betartják az általános viselkedési szabályzatot.

A fent felsorolt felhasználóknak a jog vagy szerep megszerzésekor, valamint minden újraválasztáskor, megújításkor vagy meghosszabbításkor, a már meglévő felhasználóknak pedig ezen iránymutatások megerősítését követő rövid időn belül kell elvégezniük a megerősítést, kivéve a megújítás előtt nem álló jogokkal rendelkező jelenlegi, haladó jogtulajdonosokat, akiknek nincs meghatározott határidő a megerősítés elvégzésére. Ezen irányelvek ratifikálását követő egy év elteltével, felülvizsgálat esetén megváltoztatható. A megalakulást követően az U4C eljárásokat fog kidolgozni e megerősítések megkönnyítésére.

Kérdés

Míg a Wikimédia platformok minden felhasználója minden szerkesztéskor elfogadja a Felhasználási feltételek betartását, a tervezők szándéka itt az volt, hogy kielégítsék azt a vélt igényt, hogy az irányítási pozícióban lévők megértsék és kövessék az UCoC-ot (vagy az azon túlmutató helyi projektszabályokat) saját viselkedésükben, valamint a magatartással kapcsolatos bármely irányítási intézkedésükben. Néhányan aggodalmuknak adtak hangot a jelenlegi megfogalmazással kapcsolatban. Milyen előnyei és hátrányai vannak ennek a megerősítésnek, és hogyan lehet a legjobban megfogalmazni az önkéntes közösségi önirányítás megerősítése érdekében?

Megbeszélés (Megerősítés)

• Noone should be required to affirm anything. Remove these paragraphs entirely. We have no such pledges in the movement, and should not start now. The UCoC, like the existence of other global and local policies, is an applicable policy that community members are expected to abide by, and functionaries are expected to be familiar with. As with other policies, choosing not to comply may lead to losing some community privileges, but all should be free to question it or argue against it, in general or in specific cases. The U4C has a hard enough job without having to create procedures for and oversee such a thing. –SJ talk  21:50, 25 May 2022 (UTC)
  • If desired, a substitute sentence might read "[user groups + functionaries] are expected to be familiar with the CoC and to help others (who may be less familiar) abide by it.   –SJ talk  21:50, 25 May 2022 (UTC)

  I agree: Just remove this. Der-Wir-Ing ("DWI") talk 16:35, 26 May 2022 (UTC)

  +1. Andreas JN466 17:53, 26 May 2022 (UTC)

  Absolutely. Ymblanter (talk) 18:52, 2 June 2022 (UTC)

  Yes please. Remove this for good. No-one should have to affirm anything (except employees). Lozman (talk) 17:18, 29 June 2022 (UTC)

• Again, doing this is going to create substantial resentment amongst the people who have to do it (thousands of people), some of whom will refuse. What benefit do we get from this which justifies that? This affirmation is obviously redundant anyway. Possibly we could change the places were people agree to abide by the Terms of Use to say that they agree to abide by the UCoC as well. Hut 8.5 13:13, 29 May 2022 (UTC)

  Everyone does agree to the UCOC. You did so just now by publishing your comment. By clicking "Reply", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL. Or By saving changes, you agree to the Terms of Use,...

  Following the link to the Terms of Use, you go to section 11. Resolutions and Project Policies and find The Wikimedia Foundation Board of Trustees releases official policies from time to time. Some of these policies may be mandatory for a particular Project or Project edition, and, when they are, you agree to abide by them as applicable. Following that link, you'll find 2021-02-25: Resolution:Update to Universal Code of Conduct Timeline and 2020-12-09: Resolution:Approval of a Universal Code of Conduct Der-Wir-Ing ("DWI") talk 13:34, 29 May 2022 (UTC)

• Agreed, remove that section. Wikis are not going to en-masse implement affirmations like this.--Snævar (talk) 08:25, 2 June 2022 (UTC)

• I do think a very high proportion of admins would simply resign if required to explicitly affirm any text from the Foundation, almost independent of the wording. Espresso Addict (talk) 00:38, 3 June 2022 (UTC)
• I agree with Espresso Addict. We're expected to adhere to policy without signing a document; the same principle should apply here. Vanamonde93 (talk) 17:45, 4 June 2022 (UTC)

• Fundamental question: what are the functional, actionable differences between a signed affirmation and a less formal agreement baked into e.g. the definition of adminship? Are there legal differences that may apply to individual actors as well as organizations (like affiliates)? I'm not asking about intention with this question, but the effect. What kind of exposure does this create? — Rhododendrites ^talk \\ 01:27, 6 June 2022 (UTC)

• Does the current formulation implies that users (volunteers) with advanced permissions, such as administrators, should disclose their real identities to subscribe that declaration? In other terms, does it implies that any role - for paid persons (staff) as well as for volunteers - in any WMF project wouldn't be anymore compatible with anonymity or the underage condition? Should it be the case, I will expect that a large part of current volunteers will resign, the remaining ones will feel a higher vulnerability and higher workload, perspective volunteers to be appointed with special permissions will be difficult to be found, so implying a lesser suitability for the role in new recruits, and the general service to the project will be worsened. Since everyone is already responsible for the actions he/she performs, irrespective of the formal signing off of the UCoC, I am skeptical that any addition of bureaucracy would be in the interests of the WMF projects. --Nicolabel (talk) 14:07, 6 June 2022 (UTC)

  The text says through signed declaration or other format to be decided. They probably had the process in mind how CUs and OS sign the confidentiality agreement: By editing a page with your account. Confidentiality agreement for nonpublic information/How to sign. But according to the text, it is unsure how ("to be decided") Der-Wir-Ing ("DWI") talk 14:55, 6 June 2022 (UTC)

• Expresso Addict has it - the affirmation could literally be "admins affirm that pancakes are a superior food" and we'd likely still lose some. I think this is particularly the case that we look at everything we've done as editors and admins, making content (our actual purpose) blocking problems, up to and including death threats...and now we're asked to make an affirmation that we won't be arseholes. I don't think it's a "loyalty oath" as so many name it, but I still found it offensive to be asked. Nosebagbear (talk) 20:44, 6 June 2022 (UTC)

I will go over the list of people who are "required" to affirm the UCoC with the current draft one by one:

• All Wikimedia Foundation staff, Board members, Wikimedia affiliate board members, staff and contractors;
  • For Wikimedia Foundation staff and contractors (Why are staff mentioned twice?), make it part of employment/contact process.
  • For Board members and Wikimedia affiliate board members, make it part of swearing in after election, re-election, renewal or prolongation.
• All advanced rights holders;
  • Remove this group.
• All members of any project’s high-level decision-making body;
  • For members of any project’s high-level decision-making body, make it part of conditions to join such a decision-making body.
• Any individual who wants to use the Wikimedia Foundation trademark in an event; this includes, but is not limited to, events branded with Wikimedia trademarks (such as by including them in the event's title), and representation of the Wikimedia organization, community, or project at an event (such as, but not limited to, a presenter or a booth operator);
  • Leave it as as is.
• Any officer of a Wikimedia affiliate or aspiring Wikimedia affiliate (such as, but not limited to: an individual, or group of individuals, who is seeking to promote and/or collaborate a Wikimedia sponsored event, group, study, either on or off-wiki in a research setting).
  • Leave it as is.

My understanding is that the UCoC will be incorporated in or displayed alongside with the Terms of Use every time we post something online via the Wikimedia servers. And we will supposedly be agreeing the Terms of Use and the UCoC every time we click on the submit button. Why do advanced rights holders, who participate in Wikimedia projects almost exclusively online via the Wikimedia platforms, have to affirm the UCoC? That's redundant. People who have to affirm the UCoC separately are those who participate/engage in Wikimedia suctioned off-wiki (=not using Wikimedia online platforms) events and meetings. --AppleRingo777 (talk) 14:59, 14 June 2022 (UTC)

• Forced promises are the most worthless promises. I will not do this, and I'm not alone. If a large percentage of advanced permission holders refuse, you will have to override all the local communities and fire us from our positions. This is what you are facing if this insane provision goes through. There's no way it ends that doesn't make this committee and the WMF look awful, so it'd be better if you just dropped this idea. Beeblebrox (talk) 20:00, 16 June 2022 (UTC)

Comment One more reason why we should drop all advanced rights holders (volunteers) from the groups of people who are required to affirm the UCoC is: It is NOT enforceable.

As we can see, Beeblebrox is not the first person I came across who states that he/she/they will not sign the affirmation. What are we going to do with those advance right holders who refuse to sign the affirmation? No sane local community will punish or expel those advance right holders just because they refuse to sign the affirmation. I don't think that the U4C would have the guts to do so either. If they do, I'm sure someone will start a campaign against such committee members so that they would be voted out. How about the Office Actions? I don't think the WMF would have an appetite for punishing or expelling advance right holders just because they refuse to sign the affirmation, either. If they do, there will be a riot or two.

Since there will be no consequences of not signing the affirmation, I would think there will be a whole lot of advance right holders who would refuse to sign. However, I don't think anything would happen to them by refusing it. Thus, this will be unenforceable for advance rights holders.

For other people who are listed in this section of the guidelines, that's a different story. They might lose their job, contract, committee/board membership, permission to hold an event etc. even though the guidelines do not provide a penalty phase in them.

What is a point of having the unenforceable item in the enforcement guidelines? --AppleRingo777 (talk) 21:38, 17 June 2022 (UTC)

• I will not be doing any "affirmation" of this stuff. It doesn't matter whether I agree with it or not; I would not even sign a forced affirmation that two plus two equals four. And while I agree with the general "don't be a jerk" stuff in UCoC, I don't agree with several parts of it (or at least with certain reasonable interpretations of parts of it), so I would essentially be asked to lie. Seraphimblade (talk) 20:41, 19 June 2022 (UTC)

Why not just add some text in certain places like Special:Block? Just like there is a licensing disclaimer just below the edit summary? I do sympathize with the intent of this provision, as on most small wikis there is zero training or oversight of the admin tools. But the logistics of making all admins affirm something are impractical. --Rschen7754 21:46, 19 June 2022 (UTC)

• The short version: I won't sign anything that I would describe as an "affirmation". There are other things I could sign, assuming of course that a well-attended RFC on the English Wikipedia supports the idea of signing. Dank (talk) 16:30, 29 June 2022 (UTC)

  RFC ... RFC ... what was that again? Ah yes, that is what volunteers used to do before there were "committees" deciding things for them. Andreas JN466 16:50, 29 June 2022 (UTC)

• It would probably be best to strike out this provision altogether and just treat the UCOC like any other site-wide policy, such as the terms of use. This policy will create a waste of time for thousands of administrators and functionaries, so it is better to just make the UCOC a site policy. 2601:647:5800:1A1F:AD3F:66E6:B1C0:3D9E 18:31, 19 July 2022 (UTC)

As someone who lives in a formerly communist country, the concept of having to swear an oath of allegiance to the One True PartyWMF raises serious flags. Silver hr (talk) 17:00, 3 August 2022 (UTC)

A magánélet és a jogszerű eljárás közötti egyensúly megteremtése

Aktuális üzenet

Ha az U4C döntésének alátámasztásához több információra van szükség, és az adatvédelmi politika elvárásain belül maradva, valamint a vádló vagy a vádlott indokolatlan sérelmének minimalizálása mellett, a megfelelő eljárás folytatása mellett, a magas szintű döntéshozó szervek és közösségek felkérik a vádlottak véleményét.

Kérdés

A tervezet kidolgozóinak szándéka egyrészt a bántalmazást átélt személyek biztonságának és méltóságának védelme, másrészt a helytelen magatartással vádolt személyek meghallgatáshoz való joga. A bántalmazás vagy zaklatás bejelentésének kivizsgálása során mi a legjobb egyensúly a problémákat bejelentő személyek magánélethez való jogának és a titoktartás igényének, valamint a bejelentő személyek azon igényének, hogy a bejelentett viselkedéssel kapcsolatos álláspontjukat ismertethessék?

Vita (A magánélet védelmének és a tisztességes eljárásnak az egyensúlya)

• Please replace "accusee" with "accused" everywhere. Any time the Committee passes judgement restricting the accused, they should have the right to be heard. Complaints can be anonymized or aggregated in communicating with the accused. (if there are specific exceptional cases you can imagine where this would not be appropriate, please list one or two so that we can discuss them; else don't create this standard up front but provide a way for the Committee in the future to flag cases that might merit exceptions to this.) –SJ talk  21:50, 25 May 2022 (UTC)

  This sentence is like a very long worm: Once you found the end, you already forgot the start. See also section below "Readability and translatability".

  Also, this sencence says only "When more info is needed". So when an Admin thinks he doesn't need more info, then he can immediatly block a user, declining the blocked user to defend?

  The guideline should be, that everyone gets the possibility to defend at least before a final decision. That gives the possibility of immeidate action/blocks in case of some urgency, but then the blocked user has to get after that the possibility to change that decision later. Der-Wir-Ing ("DWI") talk 16:46, 26 May 2022 (UTC)

  +1 to both Sj and DWI. Andreas JN466 18:03, 26 May 2022 (UTC)

• Constructively combining the above: While the policy as a whole could be 2x shorter, this is one place where an extra few sentences may be appropriate. –SJ talk  18:41, 26 May 2022 (UTC)

  "Community members have both an expectation of privacy and a right to be heard. Those sanctioned by the committee have a right to be heard before a final decision, though immediate temporary action may be taken in cases of urgency. Those asking for sanctions have an expectation of privacy; in cases where the committee declines sanctions they may not notify the accused, in other cases they may anonymize or aggregate details of complaints, to preserve the privacy of either party."

  • @Sj: I have to disagree with the proposal above. For any sense of fairness, you need the actual diff, or off-wiki problematic action/statements, in order to be able to provide a full defence. If you're just accused of, say, hounding someone (perhaps one of the newly formalised "okay in single nature, problematic as a recurring pattern" types given in the UCOC policy text) that's going to be a contextual heavy case, with both the individual actions and pattern up for review. For the anonymisation/aggregation to hold, then the detail needed is lost - you'd need to know the actual edits to be able to bring up all the relevant info and memories. The RTBH actually has two aspects - being heard and knowing the charge/accusation. Having the former without the latter is insufficient. Nosebagbear (talk) 09:49, 3 June 2022 (UTC)
    • I might add "where there is a risk of retaliation or other harm" after the last sentence in my proposed text. But I'm afraid that this may be common rather than rare, which is why I suggest "may ... where" rather than "may not ... except where". Your longer proposal (framed either way) seems fine as a separate linked document, I don't think that level of detail should be in a core slow-to-update overview. –SJ talk  16:55, 3 June 2022 (UTC)

      @Sj even as a general concept statement, I would say yours would lead to anonymisation in the vast majority of cases. In regards to evidence, which I actually view as the more core aspect of RTBH, that basically "Appreciable threat of off-wiki retaliation or socking". If your proposal had something along the lines of except for those two cases then while I'd prefer the safeguards of more detail I'd include it. As it is, I'd be reticent to do so, as I'd be concerned it would be accepted but not provide any difference in practical terms. Nosebagbear (talk) 15:16, 6 June 2022 (UTC)

• There should be an off-wiki, private method of reporting UCOC violations. This is to minimize retaliation by the accused party or their supporters. If the reporting party is uninvolved in the conflict, their identity should not be revealed at all. Maybe have an email address for the U4C? As long as the accused gets a chance to defend themselves, there won't be many problems. Adrianmn1110 (talk) 19:15, 5 June 2022 (UTC)

• @Adrianmn1110 so the case of non-involved reporting bodies having a means of reporting without identification is not unreasonable - however an email route to the U4C would be a poor mechanism given that the U4C would be the first port of call for almost no conduct cases. Let's say you were reporting an en-wiki issue, would they then be responsible for reporting any case to the correct noticeboard? For the smallest wikis, how will they handle it then - determine if there is a board with enough participation to discuss it or if it needs a global sysop to handle it. This is what the platform is supposed to deal with, but even it will need to deal with these issues to not cost community time. Nosebagbear (talk) 14:58, 6 June 2022 (UTC)

• @Nosebagbear Thank you for your feedback. I think your argument about saving community time could use some improvement. Hypothetically, let's say you report a UCOC violation on SomeLocalWiki, but the entire wiki refuses to fix the problem. In that case, you'd need a way to report to the U4C. Your report would be made no matter what, so there's no time wasted by choosing email. If you make a premature report to the U4C (through email or on-wiki), they could just ask you to report locally first. Reading between the lines, you seem to be implying that only the highest-ranking officials on any wiki should be able to escalate cases to the U4C. But that would not be practical or ethical. What if local wiki officials are corrupt, and they want to protect certain editors from sanctions? Certainly, they're not going to report their favored member to the U4C. (Please see the Kubura Case, which ended with a global ban). Overall, I think the pros outweigh the cons of having a U4C email address. Adrianmn1110 (talk) 19:50, 6 June 2022 (UTC)

• @Adrianmn1110 that's not what I propose at all, and would prefer you to not read between the lines of my comment in such a drastic incorrect fashion. In fact, I'm confident that the U4C will have an email, both for process stuff but also for x-wiki cases involving private evidence, that they are arb-com equivalent for (not merely a court of final resort). No, my issue was that your methodology had zero facets included for everything below "the entire wiki refuses to fix the problem". You say "there's no time wasted by choosing email", but there's time wasted even if they immediately just tell you to go local. There's even more wasted if the U4C need to figure out whether you have exhausted the local conduct pathways, and yet more if they need to figure out the specific local pathway for you to next take. Nosebagbear (talk) 20:34, 6 June 2022 (UTC)

• @Nosebagbear None of that makes not having an email address better than having one. Even if all reports were made on-wiki, there's always a risk that people will make premature reports to the U4C. "...your methodology had zero facets included for everything below 'the entire wiki refuses to fix the problem.'" Because it's obvious that everything below that level would be handled locally. See the first paragraph of this section. Adrianmn1110 (talk) 01:21, 7 June 2022 (UTC)

• As I noted in my previous comment I said there almost certainly would be an email. But because we're in a "how to change the text" discussion, lines such as "There should be an off-wiki, private method of reporting UCOC violations" would need to be phrased as "There should be an off-wiki, private method of reporting U4C-level UCOC violations" to avoid indicating you want a change from the current text. In practical terms, this would also seem a little odd. Unless every level of the process has an in-place anonymisation function, we'd know that ExampleEditor1 had submitted it to the Community conduct board. When the case then went to the MCDC level, most would probably assume it was them there...even if, in fact, it was DiffExampleEditor2 who had taken that final step. Nosebagbear (talk) 08:22, 7 June 2022 (UTC)

• In your first reply, you said, "...an email route to the U4C would be a poor mechanism given that the U4C would be the first port of call for almost no conduct cases." This gives the impression that you're strictly against having an email address for the U4C. But you shouldn't be... because on-wiki and email reports both carry risk of time being wasted. "But because we're in a 'how to change the text' discussion, lines such as 'There should be an off-wiki, private method of reporting UCOC violations' would need to be phrased as 'There should be an off-wiki, private method of reporting U4C-level UCOC violations' to avoid indicating you want a change from the current text." This page is for more than just suggesting changes. As the opening paragraph states, this page is for "input on the following questions for the committee's review". Input also includes agreement, and agreement lets people know what they should not change. Furthermore, the Enforcement Guidelines say nothing about U4C being the only body to have a private method of receiving reports. My original statement, exactly as written, still reflects what's already in the current text. "Unless every level of the process has an in-place anonymisation function, we'd know that ExampleEditor1 had submitted it to the Community conduct board. When the case then went to the MCDC level, most would probably assume it was them there...even if, in fact, it was DiffExampleEditor2 who had taken that final step." That's a necessary risk in my opinion. Without an off-wiki, private method of reporting to the U4C, DiffExampleEditor2 might be too scared to report at all. That's why I said "minimize", not "eliminate", when I talked about retaliation. Adrianmn1110 (talk) 01:30, 8 June 2022 (UTC)

• Though I don't think it's quite ideal yet (but don't as yet have an alternative), SJ's text is an improvement on the current language. — Rhododendrites ^talk \\ 01:42, 6 June 2022 (UTC)

RTBH for non-English speakers

I wrote this before, and I write this again. RTBH should be extended to non-English speakers. How accused can defend himself/herself sufficiently when he/she doesn't understand English, the de fact official language of Wikimedia global communication, and/or can't articulate in English? AppleRingo777 (talk) 14:19, 6 June 2022 (UTC)

@AppleRingo777 what form do you see this being in actual changes - perhaps that anyone involved in a U4C case, or dealing with a global sysop, should have the right to someone who can translate text between the two languages? Nosebagbear (talk) 08:30, 7 June 2022 (UTC)

@Nosebagbear: Thank you for asking. I've been questioning myself what is the best way to illiterate this concern. Unfortunately, I have not come up with a good proposal yet. I wish the WMF to provide the language assistance at least to the accused if requested by them, but I'm not sure if the WMF is willing to do so as it actually adds, if I'm correct, legal liabilities to the WMF.AppleRingo777 (talk) 15:21, 10 June 2022 (UTC)

A RTBH Proposal

• RTBH, throughout the discussion on the EG talk page and the limited call discussion time allocated to it has two main prongs: (1) the accused knowing both the specific charge(s) and the specific evidence & (2) the accused having a chance to respond to accusations prior to any action being taken.

It is the former that directly collides with a right to anonymity, but merely providing the latter as a right is useless. Being approached for one's position is useless without the ability to provide targeted, responsive, answers to any accusations. The two clearly aren't synonymous, and have differing logical exceptions. — The preceding unsigned comment was added by Nosebagbear (talk) 15:51, 28 May 2022 (UTC)

RTBH proposal - full text
Overarching safeguards The following points would be the minimum standing safeguards (communities could provide more, as always), except as limited by the later exceptions: The accused is entitled to know the full details of the accusation against them, and the evidence on which those accusations are justified. This information should be provided in the language of the project the accusation is tendered on. The accused is entitled to be offered a reasonable chance to respond to accusations prior to any non-warning sanction being levied. Right to prior reply: exceptions Absolutely! While there will always be edge cases, the following categories would be logical exclusions from a guaranteed right to a reasonable opportunity to reply prior to sanctions being levied (communities could of course still choose to offer the rights for some of these): Vandalism and equivalent levels of disruptive editing Threats of harm (including aspects such as wilful doxxing) and egregious personal attacks Legal threats Edit warring generating sanctions less than 72 hours Socking Right to hear evidence: exceptions Then there is the much narrower category of cases where the accused should not have the right to hear all the evidence against them. Inclusions: Socking - where the accused is a repeat offender and evidence is likely to aid their future socking Cases where a clear indication that the accused would (and could) retaliate off-wiki Right to later reply: ongoing misconduct Finally, there would definitely be cases where providing a right to be heard prior to sanctions would be non-viable, outside of the exceptions listed. In short, this could be summarised as "cases with likelihood of ongoing/recurring misconduct". Communities would be left the right to define where this line would be drawn. But in cases where someone was sanctioned prior to a right to be heard, then any appeal should require a specific decision for a block to remain (that is a "no consensus" would revert any sanction).

Proposal for including the right to be heard in the enforcement guidelines

My idea would be to replace the current phrase with this:

Right to be heard: Before a decision is taken against a community member, the decision-making body informs them about the alleged violation and allows them to tell their side of the story. In urgent cases and in cases of on-wiki vandalism and trolling, a preliminary decision can be taken without informing and hearing a community member if the right to be heard is granted in an appeals process.

Maybe I should repeat why adding a strong right to be heard to the enforcement guidelines is important: The right to be heard is a centuries-old principle of treating someone fairly after they have been accused of misconduct. Imposing sanctions or even banning a community member without hearing them can create harmful mistrust in the Universal Code of Conduct and the decision-making bodies.

What are your thoughts? Are there constellations in which the proposed rule would not work to the benefit of the affected community members? Thank you, --Gnom (talk) 23:10, 10 July 2022 (UTC)

 Support This looks like a good way of writing things. I would however add the words which are shown in bold:

Right to be heard: Before a decision is taken against a community member, the decision-making body informs them about the alleged violation together with the supporting evidence and allows them to tell their side of the story. In urgent cases and in cases of on-wiki vandalism and trolling, a preliminary decision can be taken without informing and hearing a community member if the right to be heard is granted in an appeals a follow-up process.

I have chosen the wording follow-up process to emphasise that this is part of the initial hearing and that once the follow-up has been completed, appeals by the member concerned will follow the same procedure regardless of whether action was taken on as a result of a preliminary hearing or a full hearing. Martinvl (talk) 10:09, 13 July 2022 (UTC)

Olvashatóság és fordíthatóság

A szavazás során elhangzott közösségi észrevételek alapján a testület Közösségi Ügyek Bizottsága is felkérte a bizottságot, hogy találjon könnyebb megfogalmazást az irányelvekhez. Ezt a szempontot a fenti kérdésekre adott észrevételek és ötletek mellett figyelembe fogják venni.

• Glossary: Please move the link to the "definition on Meta" so that the text "definition on Meta" becomes blue/clickable and the heading becomes black. That's because the "definition on Meta" is what's being linked, and the link target isn't obvious at the moment. ToBeFree (talk) 19:36, 2 June 2022 (UTC)
• Incorrect description list syntax: In the section "Enforcement by types of violations", HTML description list syntax (Wikicode ";" at the beginning of the line) is misused to stylize headings. Use heading syntax, as correctly done in the "Selection, membership, and roles" section, instead. ToBeFree (talk) 19:36, 2 June 2022 (UTC)
• "System issues" and "systematic issues": Please check if you mean "systemic issues" instead. ToBeFree (talk) 19:36, 2 June 2022 (UTC)

 Support Change back to "systemic". Taylor 49 (talk) 20:24, 19 July 2022 (UTC)

Move the definitions back to the document instead of linking. If a major change occcurs at meta (for example the group "stewards" decommissioned or split), the Enforcement Guidelines will have to get updated, exactly as it would be the case with outsourced definitions and linking to meta. Taylor 49 (talk) 20:24, 19 July 2022 (UTC)

Defining the term "functionaries"

• Include the definition of "functionaries" in the Glossary. If it cannot be defined, it should not be used in the guidelines. --AppleRingo777 (talk) 19:05, 26 June 2022 (UTC)

  @AppleRingo777: See en:WP:FUNCT. According to that page, functionaries are CU/OS and ArbCom (former) members. In this context, I think the word refers to community users who are CU and/or OS on at least one wiki. NguoiDungKhongDinhDanh 19:26, 26 June 2022 (UTC)

Hi @NguoiDungKhongDinhDanh: Thank you for your reply. As you pointed out, that's the definition for the English version of Wikipedia...one wiki. My understanding is that there are some wiki whose definition for the functionaries does not correspond to the definition provided by the enwiki. Aren't we trying to enforce the UCoC that includes the concept of "inclusiveness"? --AppleRingo777 (talk) 19:50, 26 June 2022 (UTC)

@AppleRingo777: I found another definition at Enforcement draft guidelines review: Users with advanced permissions, such as, but not limited to: administrators, bureaucrats etc. NguoiDungKhongDinhDanh 19:58, 26 June 2022 (UTC)

Oh wow. So now the administrators are part of functionaries. I bet there would be many admins who would not like that. Thank you for pointing that out.--AppleRingo777 (talk) 20:11, 26 June 2022 (UTC)

I see the word functionarie several times:

• WHO is responsible for enforcing the UCoC? - Designated community functionaries and bodies -( such as, but not limited to administrators or Arbitration Committees)
• Local and global functionaries should understand how UCoC enforcement works
• Code enforcement is a responsibility of designated functionaries and bodies with technical or decision-making power, such as, but not limited to: local sysops, stewards, Arbitration Committees (ArbComs) and their members, event safety coordinators, the Universal Code of Conduct Coordinating Committee (U4C), and the Wikimedia Foundation.
• Designating functionaries will be done, whenever possible, by local communities....
• Local and global functionaries who implement policies, codes, rules, and regulations on the Wikimedia spaces, both online and offline, are supposed to understand the management of the code enforcement function and the process.
• A training process for users and staff, developed by the Wikimedia Foundation with the input from the functionaries, to learn how to apply due processes and understand the UCoC in practice
• Advanced rights holder [Definition]: user who holds administrative rights above typical editing permissions, generally elected through community processes or appointed by Arbitration Committees. This includes, as a non-exhaustive list: local sysops / administrators, functionaries, global sysops, stewards.

The last part seems inconsistent to me. Der-Wir-Ing ("DWI") talk 20:19, 26 June 2022 (UTC)

The word functionaries also appears in the UCoC. The definition of the word in the UCoC and the guidelines should be consistent too. Otherwise, we will end up with unenforceable enforcement guidelines, won't we? --AppleRingo777 (talk) 21:07, 26 June 2022 (UTC)

┌───────────────────┘
Pinging @MNadzikiewicz (WMF), who made this edit, @Xeno (WMF), who created Universal Code of Conduct/Enforcement guidelines, and @Vermont, as a Phase 2 drafting committee member. NguoiDungKhongDinhDanh 21:42, 26 June 2022 (UTC)

Generally speaking, functionaries refers to bureaucrats, suppressors, and checkusers, as well as stewards. Periodically global sysops are considered functionaries; depends on the use case. If there are instances of the term in the revised version of this document, I'll make sure to discuss a specific definition with the rest of the committee. Best, Vermont 🐿️ (talk) 23:55, 26 June 2022 (UTC)

In the list above, this definition would be quite limiting: Responsible for code enforcement are only crats, suppressors and CUs but not regular Admins? Der-Wir-Ing ("DWI") talk 08:09, 27 June 2022 (UTC)

The 'functionaries' confusion was mentioned in an earlier report: the term "functionary" can be confusing as might refer to 1) a general class of users that administrate (as used in the UCoC); 2) arbitration committee members (as used globally, in a more restrictive sense); or 3) subscribers to the "functionaries-en" mailing list on English Wikipedia. I agree adding it to the glossary to make it clear which users to which it refers would be ideal. Xeno (WMF) (talk) 13:05, 27 June 2022 (UTC)

Hi Xeno. Please add 4) bureaucrats, suppressors, and checkusers, as well as stewards (per Vermont's post above); 5) CU/OS and ArbCom (current and former) members per en:WP:FUNCT to your list. Please also note that those two additional definitions do not include administrators (sysops). Thus, I don't think many sysops interpret that many provisions that are referring to functionaries in the UCoC and the draft guidelines apply to them. Any clarification and clear communication are helpful. Thank you in advance.--AppleRingo777 (talk) 15:18, 27 June 2022 (UTC)

One more thing I would like to ask you to clarify is: what's a difference between "functionaries" and "advance rights holders" if you are defining "functionaries" as 1) a general class of users that administrate (as used in the UCoC)," please? --AppleRingo777 (talk) 16:32, 27 June 2022 (UTC)

The very reason why we need to clarify the definition of the word "functionaries" is so that we will know exactly who will be subjected to the following article of the UCoC:

• 3.2 – Abuse of power, privilege, or influence
  • Abuse of office by functionaries, officials and staff

--AppleRingo777 (talk) 20:51, 1 July 2022 (UTC)

IMHO, the word functionary should not be tied to particular classes of user, but is a function of what the user does in certain circumstances. In civil society, a jailer is a functionary. He might be the person who locks you up, but he does not have the authority to order you to be locked up - that authority lies with the judge - the jailer merely does what he is told to do. In the case of Wikipedia, an administrator is acting as a functionary when they are renaming a file at the request of a user, but they are not acting as a functionary when they are assessing the quality of a complaint made by one user against another user. Martinvl (talk) 13:37, 18 July 2022 (UTC)

Then, can anyone potentially be a functionary? For example, we generally should not modify other people's comments on a talk page or the Village Pump at my wiki. A newbie posts something at the Village Pump, but it doesn't display in a way he/she intended it should be (can be an inter-project link or format or whatever). Then, he/she requests someone to edit for him/her. I, a non-advance-rights-holder, see his/her request and fix it for him/her. Now am I a functionary? I didn't have the authority to modify his/her post. However, I was merely performing the newbie's request, who has the authority for modifying his/her comment.--AppleRingo777 (talk) 16:11, 19 July 2022 (UTC)

In the context of the UCoC, the word functionary applies to users who exercise privilleges not available to the normal user. For example, if I were to lock you up in a cell against your will, then in most societies I would be charged with kidnap. If however, a judge instructed me, in my capacity as a jailer, to lock you up, then I am a functionary as I do not exercise my own viewpoint. Martinvl (talk) 13:45, 25 July 2022 (UTC)

Privileges like rollback, move pages, patrol, IP-excemption,... Or privileges like admin and steward? Or even more than this? Der-Wir-Ing ("DWI") talk 16:57, 25 July 2022 (UTC)

Then, ArbCom members are NOT functionaries, are they? They exercise their own viewpoint and make judgements.--AppleRingo777 (talk) 00:05, 26 July 2022 (UTC)

Abuse of Power

The current text lacks safeguards against an abuse of power by the Wikimedia Foundation. As past discussions shows, communities and individuals needs protection against it. Habitator terrae (talk) 15:01, 3 June 2022 (UTC)

Universal Code of Conduct/Policy text/Revision discussions#Abuse of office by functionaries, officials and staff Der-Wir-Ing ("DWI") talk 17:20, 3 June 2022 (UTC)

Of course, but I think, there must also be an explicit process, about how to enforce something against the Foundation to stop a potential abuse of power by it. Habitator terrae (talk) 17:31, 3 June 2022 (UTC)

• While I certainly agree that WMF should exercise caution relative to potential abuse, there are greater concerns over the abuse of power by project administrators. I am quite familiar with en.WP and am happy to provide whatever assistance WMF needs to help them further understand what takes place, and how it leads to abuse. Atsme^📞📧 21:12, 4 June 2022 (UTC)

  On the other hand the WMF itself can abuse its powers. E.g. their ombuds commission this year removed the rights of two checkusers, because they missunderstood the English Policy, with one removal was tacking place at a time, while the checkuser was with a surgery in a hospital.

  Habitator terrae (talk) 18:59, 5 June 2022 (UTC)

  Or in other words: How can an institution stop abuse of power, if the power of this institution itself is without limits? Habitator terrae (talk) 21:26, 5 June 2022 (UTC)

Enforcement Officer

I think there is problem with the language that there are special persons, which are specially responsible for enforcement, because in fact this are volunteers (only with more abilities). Habitator terrae (talk) 15:01, 3 June 2022 (UTC)

Thank you. I am looking for a simple button when a page is being vandalized repeatedly. In today's Google doodle, the Wikipedia page should correctly read as this version, https://en.wikipedia.org/w/index.php?title=Oskar_Sala&oldid=1098979095. I don't think it is helpful to revert to this version without looping in someone who could give the time for whatever progressive discipline the community agrees is appropriate. Peace. Jplvnv (talk) 11:41, 18 July 2022 (UTC)

Általános megbeszélés

Hierarchical headings

Can we add tiered numbers (hierarchical headings) for the guidelines? It's much easier for us when we have to refer a paragraph or a sentence in the guidelines during our discussions. -- Rotten Apple777 (talk) 18:48, 2 June 2022 (UTC)

Scope of U4C

Current text:

The U4C shall have jurisdiction for final decision making:

1. Where no local structure exists to address a complaint;
2. Where local structures are unable to handle a case;
3. Where local structures themselves decide to escalate a case to the U4C committee for final decision making;
4. For severe systematic issues, that cannot be handled by existing enforcement structures, such as, but not limited to, cases of local structures counteracting the UCoC, UCoC violations spanning multiple Wikimedia communities or projects, or cases involving a large number of individuals. The U4C itself or the U4C building committee will impose detailed rules for acceptance of such cases.
5. Where the case is referred to the U4C by the Wikimedia Foundation and accepted at the U4C’s discretion

This section is phrased awkardly, especially condition #4. It seems like the U4C can't sanction users who are allowed by functionaries to violate the UCOC, but it can sanction functionaries who refuse to enforce the UCOC. That's probably not what the authors intended, but that's what it reads like. I propose adding a sixth condition to the list above:

6. Where local structures, for whatever reason, do not stop someone from violating the UCoC.

This looks similar to condition #2, but it's not. Condition #2 says "unable to handle a case". Condition #6 would allow the U4C to sanction users who were allowed by rebellious functionaries to violate the UCOC. Adrianmn1110 (talk) 08:10, 4 July 2022 (UTC)

This bit deserves some attention as well: "The U4C itself or the U4C building committee will impose detailed rules for acceptance of such cases." If so, those rules shouldn't be too restrictive. Otherwise, some people who need help would be turned away. Adrianmn1110 (talk) 08:10, 4 July 2022 (UTC)

Are "rebellious functionaries" the kind that did not block the guy who "was being uncivil" towards you, resulting in you threatening him, resulting in you being blocked indef on en wiki? Or are you refering to other rebellious functionaries? Der-Wir-Ing ("DWI") talk 10:06, 4 July 2022 (UTC)

Answer: Both. Your question is useless because it has nothing to do with the UCOC or its Enforcement Guidelines. You clearly struggle at reporting events accurately. I "threatened" to report someone for being rude and condescending to someone else, not for refusing to block another user. Looks like I've hurt your feelings by using the phrase "rebellious functionaries", even though I was neither talking about you nor stereotyping functionaries. Adrianmn1110 (talk) 21:00, 4 July 2022 (UTC)

@Adrianmn1110 6. Where local structures, for whatever reason, do not stop someone from violating the UCoC. this definition would, for example, have the U4C take over (say) the Icewhiz remit. A case where despite major efforts by arbcom, Checkusers, and regular editors alike, there continue to be UCOC breaches, although most (not all, with one notable instance coming to mind) being dealt with quickly. Adding in U4C wouldn't help, but would be scoped by this change.

Far more frequently, the point is where the Community believes it has (or the person is not violating the UCOC), and does so in good faith. Now where such problems were systematic they can be handled per condition 4. But your condition would have numerous "not-guilty" verdicts challenged up under this criteria. Both removing the final-court nature of an arbcom and costing huge amounts of U4C time. Nosebagbear (talk) 18:55, 6 July 2022 (UTC)

@Nosebagbear: Your concerns are reasonable, but I don't agree that adding in the U4C would be unhelpful. The U4C can share an ArbCom's workload, especially if that ArbCom is busy with other cases. Unfortunately, ArbComs aren't perfect (and neither is the U4C, to be fair). Some "not guilty" verdicts may be made with less-than-good reasoning. In those cases, the U4C needs authority to act. Anyone reading this is probably asking, "So why should I be more skeptical of ArbComs than I am of the U4C?" Good question. It's because at least one ArbCom has made some questionable decisions.[1][2] They can be lenient to some uncivil users while being strict to others who've committed the same offense at a similar severity. And finally, thanks for being calm and reasonable. Adrianmn1110 (talk) 04:06, 8 July 2022 (UTC)

I'm really not in the mood of reading an entire arbcom case. What's the problem? What was the "questionable decision"? Der-Wir-Ing ("DWI") talk 10:24, 8 July 2022 (UTC)

In my first link, two editors were shown to have a long history of incivility, both towards other people and to each other. Even though their conduct was equally severe, only one of them got banned. My second link can be ignored. I scrolled down too fast and read the wrong subsection for ArbCom's decision to decline. Adrianmn1110 (talk) 01:13, 10 July 2022 (UTC)

@Adrianmn1110 I fear that doesn't really answer any of the issues I raise. Pointing out cases when an Arbcom may have made errors (and, I'd note, that 8 year old examples serve no benefit - please provide recent ones) can't demonstrate we should be less sceptical of the U4C who inherently have thus far made zero correct decisions.

I would say that sharing workload doesn't require a topdown decision - if an ArbCom wants to authorise the U4C to share some work because they're being overwhelmed then the arbcom can decide to do so. That's fine - it's in the same vein that communities delegated handling certain types of case to T&S. Out of interest, are any of the current arbcoms particularly hit by workflow - I wouldn't know for, say, fa-wiki's arbcom etc, so

And your response still needs to address the main facet - how to stop this leading to the vast majority of not guilty judgements being reheard again (most arbcom cases not being the first time a conduct issue is heard). Nosebagbear (talk) 12:23, 8 July 2022 (UTC)

@Nosebagbear: "8 year old examples serve no benefit - please provide recent ones" Please say exactly how recent you want my examples to be. Then, explain why you chose that cutoff date. "Pointing out cases when an Arbcom may have made errors can't demonstrate we should be less sceptical of the U4C who inherently have thus far made zero correct decisions." They've also made zero incorrect decisions. "I would say that sharing workload doesn't require a topdown decision - if an ArbCom wants to authorise the U4C to share some work because they're being overwhelmed then the arbcom can decide to do so." It doesn't need to be a top-down decision, but that doesn't mean it should never be. If condition #6 is included, U4C could share ArbCom's workload without waiting for ArbCom's permission. Not waiting for permission saves time. "Out of interest, are any of the current arbcoms particularly hit by workflow[?]" I'm not sure, but by acknowledging the possibility of overwork, I'm avoiding the assumption of bad faith. EnWiki's ArbCom has declined at least five cases where evidence against the accused party was solid.[3][4][5][6][7] If they're not overworked, then they're corrupt or have sub-optimal judgment. I prefer not to make the latter two assumptions. "how to stop this leading to the vast majority of not guilty judgements being reheard again" We wouldn't be able to stop it, but the U4C could. Not-guilty verdicts that should've been guilty would have a chance to be reheard. Some correct not-guilty verdicts might also be reheard, but I think most people should accept that risk, and here's why: One of the U4C's duties is to correct systemic issues,[8][9] but condition #4 only lets them do half the job, if at all.

• If, and I mean if, local functionaries give false-but-believable reasons for not enforcing the UCOC, the U4C would have a hard time sanctioning them. The only other way to correct systemic problems would be to sanction users who were allowed to violate UCOC. That's what the proposed condition #6 is for.
• It makes no logical sense to sanction an enabler, but not the offender who was enabled. Offenders should be found more guilty than enablers because they directly committed an offense.

Adrianmn1110 (talk) 01:13, 10 July 2022 (UTC)

@Adrianmn1110 - I believe 3 years is the longest term length any arbcom has, so let's use that as the timeband. That the U4C have made zero incorrect decisions is irrelevant here - you'd never be able to generate a statistically reliable (let alone practically reliable) comparison that suggested they were better. Without knowing U4C's process I'm not sure how it could be stated to save time, thus too the issues of systemic vs solo cases.

To focus on your key point that (en-wiki's) arbcom must be either overworked, corrupt, or have sub-optimal judgement to reject a case where there is significant evidence against the accused party I'd reply that your reasoning lacks a key fourth option. I've (re)-read the first four - citation 7 I'll need to go find the actual wiki case page to review. ArbCom takes cases with evidence where Community action has not and cannot reasonably prove sufficient.^ , even if we took every case request to show sufficient evidence, that wouldn't mean ArbCom should hear it. Nosebagbear (talk) 12:45, 10 July 2022 (UTC)

@Nosebagbear: "I believe 3 years is the longest term length any arbcom has, so let's use that as the timeband." Here you go: [10][11][12]. You've already read two of them.

"That the U4C have made zero incorrect decisions is irrelevant here - you'd never be able to generate a statistically reliable (let alone practically reliable) comparison that suggested they were better." I confess to having no good rebuttal for that.

"Without knowing U4C's process I'm not sure how it could be stated to save time, thus too the issues of systemic vs solo cases." Even if the U4C's process for accepting cases were slow, it would be faster if they didn't have to wait for permission from an ArbCom.

"ArbCom takes cases with evidence where Community action has not and cannot reasonably prove sufficient." If that's true, I would have no choice but to describe ArbCom's judgment as being sub-optimal. It's always possible that Community action can prove reasonably sufficient, but that doesn't mean it's probable. You could have ninety-nine failed Community efforts to fix a problem, and the one-hundredth attempt could still be successful. Waiting for the moment when Community action can't fix a problem means waiting until the source of the problem dies from old age. (I'm not being snarky; I meant what I wrote literally.)

And, of course, not including condition #6 would neuter U4C's ability to fix systemic issues with UCOC enforcement. Most functionaries who refuse to enforce the UCOC out of spite are not likely to admit it openly. They'll give convincing excuses. Thus, U4C will have to sanction the actual violators instead of their enablers. Adrianmn1110 (talk) 03:57, 12 July 2022 (UTC)

@Adrianmn1110 - regarding point about faster/slower - it would be slower if the U4C case takes longer than the Arbcom case would have taken, even including any delay. As it would appear likely that no arbcom is going to hear a case if the U4C is simultaneously hearing it.

Regarding your latter point, this would of course be correct if an arbcom were actually operating off a "99th (or whatever obviously flawed large number) times the trick" method to avoid ever hearing a case. That would be clear sign of a systematic failure.

But en-wiki's doesn't (other arbcoms may be different, including not requiring prior community review) - it requires a sign that the community has tried to resolve it, failed, and no indication that a future attempt would turn out differently. In practical terms, this normally comes in the form of at least one ANI (or equivalent) discussion and, where relevant, a followup or review discussion from that. Where someone can't show that and further indication of sanctionable behaviour in the same nexus, it's unlikely to be accepted. The FPS case request is a good example of this. Nosebagbear (talk) 17:16, 13 July 2022 (UTC)

@Nosebagbear: "it requires a sign that the community has tried to resolve it, failed, and no indication that a future attempt would turn out differently." That's quite different from what you said before. What you're saying now means, "The accuser must prove that their Community has not shown that the Community can resolve this issue." You previously said, "ArbCom takes cases with evidence where Community action has not and cannot reasonably prove sufficient." What you said before means, "The accuser must prove that their Community cannot resolve this issue." I was responding to what you said before, not after. It's easy to prove that a Community hasn't solved a problem, but it's impossible to prove that they can't. Please see my previous reply if you don't know why it's impossible. Please pick the claim you want to stick with. My next reply depends on your next reply. Adrianmn1110 (talk) 01:34, 15 July 2022 (UTC)

The latter is a more formal (drawn from the policy line "To act as a final binding decision-maker primarily for serious conduct disputes the community has been unable to resolve;"). Because, as your correctly noted earlier, someone could interpret that as ruling out almost all case requests, I also gave the actual practical interpretation used - which is for cases not involving an admin (only arbcom can remove admin userrights) a case request must show that the community has tried to resolve it and failed, and that there isn't indication of a future community process that may do so. The "indication" would usually be something like an ongoing conduct case or an RfC to resolve the underlying problem etc etc.

I should note that we may want to hat (put into a expandable/collapsable box) this discussion between the two of us, as length-wise, it's starting to dominate this page. Nosebagbear (talk) 10:49, 15 July 2022 (UTC)

┌─────────────────────────────────┘
In three of the most recent declined case requests I cited, the accused party had at least one ANI that ended with no sanction or warning for them.[13][14][15] Admittedly, the two declined Fram requests did not.[16][17] But as you noted, requested cases of alleged sysop misconduct are an exception to the standard DR policies. All aforementioned incidents showed no indication of being resolved by the community. "Interactions at GGTF"[18][19] ended with Carol Moore getting a much heavier sanction than Eric Corbett, whose conduct was no less (or only slightly less) severe. All these cases met the criteria for acceptance, yet most were declined. For the one that was accepted, the final remedies are highly questionable. "we may want to hat (put into a expandable/collapsable box) this discussion between the two of us, as length-wise, it's starting to dominate this page." No objections from me. Adrianmn1110 (talk) 20:31, 16 July 2022 (UTC)

Human Rights Impact Assessment

It may be useful to know that admin training regarding harassment was one of the priority recommendations in the Wikimedia Foundation Human Rights Impact Assessment ("Develop and deploy training programs for admins and volunteers with advanced rights on detecting and responding to harassment claims"). This is a 2020 report by an external consultancy firm that has only been published by the WMF this week. See Talk:Wikimedia Foundation Human Rights Impact Assessment for a complete list of recommendations – some of which have already been implemented, others of which have not. --Andreas JN466 19:51, 13 July 2022 (UTC)

Shared ArbComs

This is another thing that used to be in the draft at some time but vanished from there later. If there is no ArbCom, then there is nobody to enforce anything. There are wikis besides English wikipedia. A single sysop cannot be the ArbCom, the stewards extremely rarely want to, and if the U4C receives this task at some time, then it is likely that they will have 17'000'000 queued cases one hour after the reporting interface is opened. I have a private proposal about this challenge. Taylor 49 (talk) 20:34, 19 July 2022 (UTC)

Concerning the workload ot U4C, you only can guess. But chances are high it will be eiter overworked or underworked. Usually you try and then later fix the problem.

Else I don't see a big problem. On de-wiki there is approximatly one Arbcom request per month. That's not much. Der-Wir-Ing ("DWI") talk 22:53, 19 July 2022 (UTC)