Status as of 13:06 (UTC), Sunday, 28 April 2024 ()
- The final decision has been posted and announced.
- The initial implementation period has concluded and the updated procedure has come into effect.
- Any editors interested in the ongoing implementation process are invited to assist at the implementation talk page.
- To be notified about updates, subscribe to the update list.
|
The revision process will be conducted in four phases:
The revision process was managed by drafting arbitrators designated by the Arbitration Committee ( CaptainEek, L235, Wugapodes). |
 | Welcome to the Proposed Decision talk page. On this page, we invite you to provide feedback on the proposed decision. Unlike a typical proposed decision phase, the clerks are not currently enforcing sectioned discussion (i.e. each participant commenting only in their own section). However, the Committee reserves the right to begin doing so if the need arises. Before any votes are cast on the proposed decision, the community will have a five-day period (until November 18) in which to provide comment on this talk page. During this time, the proposed decision will undergo further linguistic and stylistic revisions and arbitrators may post additional proposals and amendments. |
I strongly urge the committee not to select the proposed alternative, "arbitrated topics". I think it would be better to use a name that is applicable when either the arbitration committee or the community has identified a problem area for which it is authorizing additional measures. isaacl ( talk) 22:27, 13 November 2022 (UTC)
- Frankly that's a point in its favor to me. I think making it easier to tell what is owned by the community and what is owned by arbcom specifically is useful.
Barkeep49 (
talk) 22:28, 13 November 2022 (UTC)
- I do think that would blunt the effectiveness, though. What would community-authorized discretionary sanctions become? Still just discretionary sanctions? (The official documentation for all GS still uses "discretionary sanctions".) KevinL (aka L235 · t · c) 22:31, 13 November 2022 (UTC)
- In my opinion, we should seek to simplify the avenues for applying sanctions by placing them under the same framework, with the arbitration committee having a role in designating problem areas. It's much easier for editors if the same procedure can be followed, regardless of who identified the problem area. The procedure will be easier to write when one term can be used, instead of "X or Y". The only time I think the difference matters is if someone wants to make a case for removing the designation. I think the greater conciseness in documenting the day-to-day operating procedures is more beneficial, though.
isaacl (
talk) 22:49, 13 November 2022 (UTC)
- I mean that's kind of what we have now isn't it? These things grew in tandem and we have a mess. The community can decide it wants to use this tool in its tool kit and continue to have community passed sanction areas. Or it could decide, as it has with desysoppings, that it wants ArbCom to be the only place for these things to happen. It's not ArbCom's responsibility to fix the community's tool (if it's even broken). However, I'm strongly in favor of giving the community access to AE - as I think that encourages the syncing of language you desire. But in terms of clarity I will say that AT gives far more clarity than hindrance imo compared to CT.
Barkeep49 (
talk) 01:00, 14 November 2022 (UTC)
- Right now, we have community-authorized discretionary sanctions that are described as like being the arbitration committee discretionary sanctions, and so editors have to read those instructions and mentally substitute the concept of community-authorized discretionary sanctions. It would be nice if the only point of divergence was who identified the problem area where additional admin actions are available, and then the rest of the procedure would be independent of who identified the area. For daily editing, it doesn't matter who identified the area. isaacl ( talk) 02:22, 14 November 2022 (UTC)
- I mean that's kind of what we have now isn't it? These things grew in tandem and we have a mess. The community can decide it wants to use this tool in its tool kit and continue to have community passed sanction areas. Or it could decide, as it has with desysoppings, that it wants ArbCom to be the only place for these things to happen. It's not ArbCom's responsibility to fix the community's tool (if it's even broken). However, I'm strongly in favor of giving the community access to AE - as I think that encourages the syncing of language you desire. But in terms of clarity I will say that AT gives far more clarity than hindrance imo compared to CT.
Barkeep49 (
talk) 01:00, 14 November 2022 (UTC)
- "Contentious topics" is a good name because it clearly communicates to outsiders what this whole system is really for. "Hey, you're editing in a controversial area, so the rules are stricter". The average person doesn't need to know or care about whether a sanction is community-authorized or arbcom authorized. I can still see the need to disambiguate, so maybe some kind of subpage type syntax along the lines of "Contentious topics/community" and "Contentious topics/arbitration" would work well? The redirects
WP:CTC and
WP:CTA don't seem to be actively used and are pretty catchy.
Chess (
talk) (please use
{{ reply to|Chess}}on reply) 22:48, 13 November 2022 (UTC) - Though I anticipate opposing that specific change as well, to me they are separate discussions. It's a cart before the horse problem to agree to the one name in support of agreeing to allow some overlapping use of the machinery the community and ArbCom each have to enforce decisions made by those bodies in regard to conduct in those areas. And I don't see it as a meaningful objective of its own to try to merge the language the two groups use when dealing with such contentious topics as rise to contention on Wikipedia. (It might be valuable, but it's not its own objective at the end of the day for this discussion, for me at least.)
- Regarding the name specifically, I am not a fan of arbitrated topics specifically, I am a fan of avoiding turning the words contentious topics into a term of art of the same kind as notability has been for a decade and a half and the associated confusion for everyone involved. (You can see more at my
removed comment, though I might do some further copy-pasting of a lengthy comment I left on arbwiki.) I personally wanted to avoid splitting a vote between CT and something else on the something else side, so I did suggest to the drafters to propose only one alternative. I anticipate most arbs voting on any particular name will differentiate most on the line of how much a name used is a term of art or even something completely opaque versus how much it overloads some common-sense meaning of the same phrase (while there might be reasons to keep DS, I haven't seen anything to indicate ArbCom is willing to keep the old name i.e., I anticipate everyone will vote in support of changing the name). There's only so many colors we can paint the bikeshed though, and no real clear winners at the consultation besides AT and CT. We could post all of those proposed there (or those in some response to this discussion) and do some
ranked choice voting if we really must. --
Izno (
talk) 22:53, 13 November 2022 (UTC)
- Not blue, not terquois, not lapis, we need to paint it cerulean. Barkeep49 ( talk) 22:55, 13 November 2022 (UTC)
- I appreciate that the committee isn't responsible for aligning community procedures with its procedures. I'm simply requesting that the committee choose a name that helps enable documentation to be streamlined. isaacl ( talk) 23:05, 13 November 2022 (UTC)
- @
Izno: I'm in favor of "restricted topics" for the new name as suggested by
Tryptofish. It addresses the term of art concern you have while also addressing Isaacl's concerns. No one raised any objections to it during the review, so I figured it would've gotten more consideration here (or at least a vote). –
MJL
‐Talk‐
☖ 21:21, 15 November 2022 (UTC)
- "Restricted topics" has the same problem as "discretionary sanctions" in that it suggests that restrictions on the editing of the topic are already in place (rather than simply being an authorization for editor and page restrictions to later be placed). Additionally, it has the disadvantage of using the same word as a different concept: the actual "page restrictions" that are imposed under this procedure. Best,
KevinL (aka
L235 ·
t ·
c) 21:26, 15 November 2022 (UTC)
- @
KevinL: Restrictions on the editing topic are actually already in place, though. There's (ideally) a higher bar for editor behavoir according to
WP:AC/DS#guide.expect.
The problem of restriction already referring to page enforcement actions, then just rename that topage limitations
. It has the same meaning more-or-less (if anything it probably describes page enforcement actions more accurately). – MJL ‐Talk‐ ☖ 22:26, 15 November 2022 (UTC)
- @
KevinL: Restrictions on the editing topic are actually already in place, though. There's (ideally) a higher bar for editor behavoir according to
WP:AC/DS#guide.expect.
- "Restricted topics" has the same problem as "discretionary sanctions" in that it suggests that restrictions on the editing of the topic are already in place (rather than simply being an authorization for editor and page restrictions to later be placed). Additionally, it has the disadvantage of using the same word as a different concept: the actual "page restrictions" that are imposed under this procedure. Best,
KevinL (aka
L235 ·
t ·
c) 21:26, 15 November 2022 (UTC)
- As I discuss at length on
WP:AN#Sanctions: discretionary, general, standing (
permalink), the inversion and intersection of the terms Discretionary / General between and within and across
Wikipedia:Arbitration Committee/Discretionary sanctions and
Wikipedia:General sanctions, is worded confusingly and counterintuitively. I couldn't even imagine how opaque that might seem to newer users if I, one of the most active admins in both areas, continue to be baffled by this overlapping terminology (and have been for, like, forever).
El_C 13:27, 14 November 2022 (UTC)
- Personally, I hear you, and count it as a major plus for "contentious topics" that it can describe both the ArbCom and community versions of current-DS. Best,
KevinL (aka
L235 ·
t ·
c) 15:41, 14 November 2022 (UTC)
Like. Glad to hear it. Once this happens, the terms Discretionary sanctions and General sanctions (no Standing orders, please!) will actually have a clear meaning within both.
El_C 17:17, 14 November 2022 (UTC)
- Personally, I hear you, and count it as a major plus for "contentious topics" that it can describe both the ArbCom and community versions of current-DS. Best,
KevinL (aka
L235 ·
t ·
c) 15:41, 14 November 2022 (UTC)
Process related comment This seems like an extremely short time for comment or interactive discussion after a process that's taken quite a long time to get to this point. Many thoughtful, longstanding editors don't even log on during a given 5 day period. Does Arbcom really want to review only the comments of editors who are online every day and have the time to digest and offer comments on this important matter? After all the time it took to get to this point, what does that accomplish? It would be constructive to ensure that a broader range of editors can comment on and/or endorse the ultimate outcome. It would greatly strengthen the community's faith in the result. How about December 10? SPECIFICO talk 15:27, 15 November 2022 (UTC)
- @
SPECIFICO two thoughts as to why it's not as bad (perhaps) as you're thinking. This draft has only minor changes from the version that was up for 30 days of community consultation in October. Also for the first 5 days Arbs aren't to make votes. However, I expect it will take at least a week for Arbs to have the discussion and do the voting necessary, during which time the community can certainly continue to leave feedback.
Barkeep49 (
talk) 15:35, 15 November 2022 (UTC)
- Thanks for the quick reply. My impression, however, was that late in the comment period last time there were some very different approaches put forward. I have not yet read all of the current draft, but at first glance, I was disappointed to see what appears -- I'll be blunt -- to be rather inconsequential tweaks to flawed processes that are familiar and comfortable for the small mumber of Admins and Arbs who volunteer to do this difficult enforcement work. While we all appreciate that effort, I think we can do a lot better than the current dreaft. For example, I thought the proposal by @
AGK:, which came late in the last comment round, set forth a fundamentally simpler and more effective approach. I don't see much of that reflected in the proposed draft. I don't see much cost in leaving the comment open for sustained discussion. If nobody agrees with me, would be fine. It will end here.
SPECIFICO
talk 16:42, 15 November 2022 (UTC)
- Glad I could resolve your process comment. Moving onto your thoughts on substance, speaking only for myself I gave a lot of thought to AGK's suggestion, as was shown by my engagement with the proposal. Ultimately I don't think it improves what is being put forth here for reasons I expressed at the proposal. Barkeep49 ( talk) 16:52, 15 November 2022 (UTC)
- The community can take the lead in modifying its procedures to give administrators more authority to deal with poor editor behaviour in problem areas. By doing so, it can take ownership over the procedures, obsolete the arbitration committee discretionary sanctions procedure, and thus simplify the entire process. With years of experience with discretionary sanctions, I think the community may be ready to revisit what tools it provides to administrators.
isaacl (
talk) 17:45, 15 November 2022 (UTC)
- I think that is what's needed. More active discretionary actions subject to review. How that would be implemented by the community is beyond my knowledge of procedure, and I'd be interested to hear about it if you are ever so inclined. As a case in point, consider what happened in the recent incident concerning @
Tamzin and
Volunteer Marek: a bad sanction was swiftly and civilly reversed with arguably less time and effort than if the issue had been brought to the AE board for a pile-on.
SPECIFICO
talk 17:53, 15 November 2022 (UTC)
- I'm not sure that's a good argument for discretionary actions, since those in favour of expanding their use generally seem to favour using the arbitration enforcement noticeboard (the thought being that pile-ons are more common at the incidents noticeboard than the arbitration enforcement noticeboard). I'm not sure if you're asking about ideas of what should be in a proposal, or about the steps to get a proposal approved. But in either case, a discussion at the idea Village Pump may be a good place to start. isaacl ( talk) 21:43, 15 November 2022 (UTC)
- I think that is what's needed. More active discretionary actions subject to review. How that would be implemented by the community is beyond my knowledge of procedure, and I'd be interested to hear about it if you are ever so inclined. As a case in point, consider what happened in the recent incident concerning @
Tamzin and
Volunteer Marek: a bad sanction was swiftly and civilly reversed with arguably less time and effort than if the issue had been brought to the AE board for a pile-on.
SPECIFICO
talk 17:53, 15 November 2022 (UTC)
- Thanks for the quick reply. My impression, however, was that late in the comment period last time there were some very different approaches put forward. I have not yet read all of the current draft, but at first glance, I was disappointed to see what appears -- I'll be blunt -- to be rather inconsequential tweaks to flawed processes that are familiar and comfortable for the small mumber of Admins and Arbs who volunteer to do this difficult enforcement work. While we all appreciate that effort, I think we can do a lot better than the current dreaft. For example, I thought the proposal by @
AGK:, which came late in the last comment round, set forth a fundamentally simpler and more effective approach. I don't see much of that reflected in the proposed draft. I don't see much cost in leaving the comment open for sustained discussion. If nobody agrees with me, would be fine. It will end here.
SPECIFICO
talk 16:42, 15 November 2022 (UTC)
I like the ability to use a single name for both DS and 'GS', because they're basically the same thing minus who authorises/revokes them and (currently, which is a disadvantage) where reports/appeals happen. I'm not sure about "contentious topics" -- yes, they tend to be contentious, but there are (correctly) plenty of contentious topics without a DS authorisation. So I guess they're technically "designated contentious topics", but that's a mouthful so I guess we drop the first word in most usages. I'm worried this phrasing will lead to more requests for "CT authorisation" at AN, which will pass because the topic is contentious, but without showing that extra tools are actually needed to curtail disruption, or that the topic is any more disrupted than most topics on Wikipedia. ProcrastinatingReader ( talk) 21:41, 15 November 2022 (UTC)
In addition to my previous comments on editnotices: most editors won't benefit from an editnotice on a page that doesn't have any page-specific restrictions, as their editing behaviour is in full compliance with recommended behaviour. I do not feel that increasing the banner blindness problem on a very broad set of articles for very little benefit is a good tradeoff. isaacl ( talk) 22:58, 13 November 2022 (UTC)
-
WP:THEYCANTHEARYOU is also relevant here.
RAN1 (
talk) 23:21, 13 November 2022 (UTC)
- Whether or not someone is able to see an editnotice is a factor in considering awareness of page-specific restrictions. In the case where an editnotice is simply informing editors that the page is in scope of a designated problem area, the editor has to be individually alerted in order to be considered aware of the designation, so the editnotice isn't a factor in considering awareness.
isaacl (
talk) 23:35, 13 November 2022 (UTC)
- That's why the editnotices are for
"optional use" by administrators when needed. Do you think that will cause more harm than good? If so, I'm open to dropping it, but I'd like to hear why you think so (even if we limit its use to administrators, for example). Best,
KevinL (aka
L235 ·
t ·
c) 15:49, 14 November 2022 (UTC)
- As I mentioned previously, I don't know if the state of affairs has changed, but it had been the case that no editnotices were present on pages affected by committee-authorized discretionary sanctions without page-specific restrictions. (COVID-19 is the one area across all the discretionary sanctions topics with editnotices, with one admin feeling strongly about having them; this area had been under community authority back then.) Thus in practice (up to that point last year at least) administrators had not seen a need to use editnotices (outside of COVID-19). I think there are too many pages that can be affected without much benefit (in essence, the editnotice just says keep behaving the way you're supposed to behave on all pages, problem area or not; and editors still have to be individually alerted), particularly if it just adds to the banner blindness problem and makes all editnotices less useful. isaacl ( talk) 16:48, 14 November 2022 (UTC)
- The way the sentence is currently framed, it could be read to say that edit notices are optional only if there are no restrictions on the page. Is that intended? If it is intended, mandatory might be a valuable add to the second part of the sentence.
- I also agree with Isaacl that edit notices and even talk page notices just contribute to banner blindness in the large. So if that influences whether an edit notice is required for a page restriction.... :)
Izno (
talk) 23:56, 19 November 2022 (UTC)
- Done, and clarified in the page restriction text too. Page restrictions have always required editnotices (see Wikipedia:Arbitration_Committee/Discretionary_sanctions#Page_restrictions) so I don't think that will be a controversial clarification. Best KevinL (aka L235 · t · c) 01:35, 20 November 2022 (UTC)
- That's why the editnotices are for
"optional use" by administrators when needed. Do you think that will cause more harm than good? If so, I'm open to dropping it, but I'd like to hear why you think so (even if we limit its use to administrators, for example). Best,
KevinL (aka
L235 ·
t ·
c) 15:49, 14 November 2022 (UTC)
- Whether or not someone is able to see an editnotice is a factor in considering awareness of page-specific restrictions. In the case where an editnotice is simply informing editors that the page is in scope of a designated problem area, the editor has to be individually alerted in order to be considered aware of the designation, so the editnotice isn't a factor in considering awareness.
isaacl (
talk) 23:35, 13 November 2022 (UTC)
Regarding this comment: although appearance is one contributing factor to banner blindness, I think frequency of use is a more significant one with editnotices. That's not something that can be easily dealt with centrally. I'm not suggesting they be prohibited (we've already had an RfC saying admins should be able to decide when they want to put editnotices on an article for which discretionary sanctions have been authorized), but as I mentioned in the previous discussion, I think they should be discouraged. Perhaps some discussion of the banner blindness issue can be placed in the documentation. isaacl ( talk) 21:24, 29 November 2022 (UTC)
Maintaining an equivalent of Template:Ds/aware
Extended content
|
|---|
|
The current section on Awareness has a couple of oversights that could be addressed. The first is that
WP:AWARENESS links to
WP:Raising awareness which isn't about discretionary sanctions. The second is that the proposed wording gets rid of the current
Template:Ds/aware, which allows a user to signal on their talk page they are
WP:AWARE of restrictions and no longer have to be spammed with notices. |
Extended content
|
|---|
|
One of the big pain points the various discussions to date have shown to discourage new admins from joining DS (or whatever) patrol is that nuisance that is logging. Not that it's unnecessary (or non-useful), but as far as I can tell, while the text about logging is different, the actual "how to log" hasn't significantly changed. I could be wrong - please let me know if so. If I'm correct, is there the possibility of, say, a script that could support such? I realise that "you, editor, make this script by order of ArbCom" is not one of their powers, but some influence to encourage it might be a possibility? Nosebagbear ( talk) 23:10, 13 November 2022 (UTC) |
Extended content
|
|---|
|
The template should link to
I dislike the idea of bots and/or automated process deciding who should receive an alert, but don't have an issue with them being delivery that way to people a human has identified as benefiting from an alert. Disallowing automated delivery is significantly preferable to allowing automated selection. Thryduulf ( talk) 23:28, 13 November 2022 (UTC)
I still don't understand the point of awareness/alerts. Sure, awareness for page/topic-wide restrictions (like 1RR) should be necessary, because you can't expect people to behave differently to what's considered accepted wiki-wide (e.g. 3RR) without telling them what different behaviour is expected of them (e.g. don't revert more than once on this page). But for discretionary sanctions? I don't see the point. After getting an alert which "suggests nothing wrong with your behaviour" what are you supposed to do to avoid being sanctioned? It seems to me like your options are to either stop editing in the area, or continue editing and potentially get sanctioned. So basically, I don't see what the point of the alert is. Can one of the drafters explain this to me? (courtesy to L235) ProcrastinatingReader ( talk) 21:41, 15 November 2022 (UTC)
|
- My biggest concern about awareness is that as a user, wanting to make sure someone is aware, it needs to be easy for me to determine whether I should alert them or not. I do not want to be stuck in the situation of "I must alert them in order to complain, but woe unto me if I alert them and they were already aware." It should be obvious one way or the other. In particular, if there are four different ways they might be aware, checking all of them can be troublesome. I haven't been following this process particularly carefully. Will the above situation still come up? Adoring nanny ( talk) 14:11, 22 November 2022 (UTC)
Extended content
|
|---|
|
- The option for administrator's revoking or changing a contentious restriction out of process to receive a sanction other than desysopping (but still allowing for desysopping) should be explicitly available.
Thryduulf (
talk) 23:28, 13 November 2022 (UTC)
- I think may is doing enough work here, but I wouldn't hate an adjustment.
Izno (
talk) 23:42, 13 November 2022 (UTC)
- "May result in sanctions up to and including desysop" isn't the worse thing in the world I guess but I personally would be hard pressed to see the current wording as "may either deysop or do nothing" as the only options available.
Barkeep49 (
talk) 00:49, 14 November 2022 (UTC)
- On the other hand, I think it might be possible for ArbCom to do more than just desysop an admin who changes a restriction out of process, which would make both old and suggested texts meh.
Izno (
talk) 23:25, 19 November 2022 (UTC)
- After consideration, my preference is for keeping the current text. I imagine we wouldn't do more than desysop just for changing a restriction out of process but under the right circumstances we would desysop just for changing a restriction out of process. Best. KevinL (aka L235 · t · c) 23:20, 20 November 2022 (UTC)
- On the other hand, I think it might be possible for ArbCom to do more than just desysop an admin who changes a restriction out of process, which would make both old and suggested texts meh.
Izno (
talk) 23:25, 19 November 2022 (UTC)
- "May result in sanctions up to and including desysop" isn't the worse thing in the world I guess but I personally would be hard pressed to see the current wording as "may either deysop or do nothing" as the only options available.
Barkeep49 (
talk) 00:49, 14 November 2022 (UTC)
- I think may is doing enough work here, but I wouldn't hate an adjustment.
Izno (
talk) 23:42, 13 November 2022 (UTC)
Extended content
|
|---|
|
I don't know if I like the wording "if and only if" - that has a specific meaning in logic that I'm not sure applies here (and I'm not sure I correctly understand the specific meaning). -- SarekOfVulcan (talk) 15:09, 1 December 2022 (UTC)
- @
SarekOfVulcan: Thanks for writing. I'm happy to revise it if a revision would lead to a substantial increase in clarity. The current wording conveys that for an administrator to have the authority to revoke a restriction, it is necessary and sufficient to meet one of the three conditions in the bullet points. In other words, if one of the criteria is met, the authority exists; otherwise, the authority does not exist. That's why the term "if and only if" is used (see
Necessity and sufficiency and
If and only if). Can you point to the unclarity there? Best,
KevinL (aka
L235 ·
t ·
c) 17:51, 1 December 2022 (UTC)
- Eh. The Iff description confused me, but I think Necessity and sufficiency clarified that the wording as it is should work. Thanks for double-checking. -- SarekOfVulcan (talk) SarekOfVulcan (talk) 18:01, 1 December 2022 (UTC)
Extended content
|
|---|
|
Extended content
|
|---|
|
Clarify whether in the event of an editor unambiguously taking action without logging that action within a reasonable period, the log may or may not be updated by any other [editor/uninvolved editor/admin/uninvolved admin]. (My preference allow logging by anyone). Thryduulf ( talk) 23:28, 13 November 2022 (UTC)
|
Extended content
|
|---|
|
The only real suggestion I have atm is that what is currently note d ( |
Extended content
|
|---|
|
The WP:TBAN template at {{ AE sanction/topicban}} is almost as inaccessible as the WP:ARCA template at {{ Arbitration clarification request}} (which says a lot). I don't think I've ever used that template as intended. I mostly just go to WP:AE, find one that was already posted, then adjust it accordingly to whatever the given particulars are. Maybe work on making that (those) more accessible...? El_C 13:34, 14 November 2022 (UTC)
|
Extended content
|
|---|
|
One of the unwritten best practices arrived at WP:AE years ago was that timed WP:TBANs are usually useless (barring some exceptions). This is similar to the unwritten best practice arrived at WP:RFPP years ago against preemptively protecting DS pages (again, barring some notable exceptions). This was a major reason in myself coming to the realization that, and criticism of, many (most?) Committee members being out of touch as to what actually goes on on the ground floor of day-to-day DS enforcement. So, please update me, it that proposal still a thing? Thanks! El_C 13:44, 14 November 2022 (UTC)
|
Extended content
|
|---|
|
The whole process to date can be summarised as follows. We had a consultation. Questions were framed around the existing superstructure of DS, which is like having a statutory reform consultation that poses questions only about the sections of the statute that you're trying to reform. (I accept that four general questions were asked, but the arbitrators have drawn limited conclusions from those.) Despite the consultation's limiting methodology, a consensus view still shone through, that the system isn't working and is overly complicated. We've now ended up with an extremely complicated minor update to the system that, according to prosesize.js, reduces the existing system by only 28 words. The drafting arbitrators are now happily voting on the replacement system. Does this reform really go far enough? It might be better now to have further rounds of consultation, or to ask the community to design a replacement system. AGK ( talk) 20:27, 15 November 2022 (UTC)
|
Regarding the term consensus: I agree that consensus is the base term, encompassing all types of consensus ("X consensus"). I think "clear consensus" conveys the idea of a substantial agreement among most participants as well as a significant number of participants. I don't think the term "rough consensus" should be broken down further than "a consensus that is not a clear consensus". There is a flexibility underlying English Wikipedia's consensus traditions that is lost if the concept is tiered, which is going to result in arguing over how to codify the different categories. isaacl ( talk) 17:21, 28 November 2022 (UTC)
I'm relatively new to this part of Wikipedia, and had I not read ACE2022 candidates' election statements, I'd never come to know that there is all this review going on right now. Is it too late to suggest a name? As I believe something like Safeguarded topics ( WP:SGT/ WP:ST) would be a better fit? I read Izno and feel convinced that "contentious topic" might not be that great of a term to be honest. As someone raised in Phase II page, it is too generic of a term and have an existing meaning beyond the ArbCom enforced sanctions. And "arbitrated topic" might not really be understandable to those unfamiliar with the ArbCom, and can never be extended to GS areas per Wugapodes. I believe SGT would be plain English, understandable to non-native speakers, but not too plain, and extensionable to GS. It conveys its meaning quite well, that a certain topic area is safeguarded from vandalism, etc. Consider reading the proposal page, but with every instance of CT replaced by SGT. I feel like it fits very well in there. — CX Zoom[he/him] ( let's talk • { C• X}) 21:42, 29 November 2022 (UTC)
@
Barkeep49: re feels like we're adding "wikilaw" for something no one has asked for
I believe the idea of bots delivering alerts received community consensus in RfC in the past, but was rejected by ArbCom. So I'm not sure it's something no one has asked for, per se. It's to be expected you won't keep hearing about it if you turned it down already.
ProcSock (
talk) 13:36, 30 November 2022 (UTC)
- I'm not aware of that community consensus. Do you have a link?
Barkeep49 (
talk) 14:51, 30 November 2022 (UTC)
-
Wikipedia:Village_pump_(proposals)/Archive_152#Bot_to_deliver_Template:Ds/alert but it seems I'm misremembering the discussion/timeline slightly, in whether it had a community consensus in favour or not. Seems the RfC never got an uninvolved close since ArbCom
acted with a motion a few days after the RfC was started.
ProcSock (
talk) 18:47, 30 November 2022 (UTC)
- I feel like absent that motion the 60%+ might have been enough to find consensus. So thanks it's still helpful and I'm going to slightly modify my stance. But that discussion still shows one of my concerns - I think getting bot notification right is going to be hard to do. Barkeep49 ( talk) 19:04, 30 November 2022 (UTC)
-
Wikipedia:Village_pump_(proposals)/Archive_152#Bot_to_deliver_Template:Ds/alert but it seems I'm misremembering the discussion/timeline slightly, in whether it had a community consensus in favour or not. Seems the RfC never got an uninvolved close since ArbCom
acted with a motion a few days after the RfC was started.
ProcSock (
talk) 18:47, 30 November 2022 (UTC)
Cite error: There are <ref group=lower-alpha> tags or {{efn}} templates on this page, but the references will not show without a {{reflist|group=lower-alpha}} template or {{notelist}} template (see the
help page).
Status as of 13:06 (UTC), Sunday, 28 April 2024 ()
- The final decision has been posted and announced.
- The initial implementation period has concluded and the updated procedure has come into effect.
- Any editors interested in the ongoing implementation process are invited to assist at the implementation talk page.
- To be notified about updates, subscribe to the update list.
|
The revision process will be conducted in four phases:
The revision process was managed by drafting arbitrators designated by the Arbitration Committee ( CaptainEek, L235, Wugapodes). |
| Welcome to the Proposed Decision talk page. On this page, we invite you to provide feedback on the proposed decision. Unlike a typical proposed decision phase, the clerks are not currently enforcing sectioned discussion (i.e. each participant commenting only in their own section). However, the Committee reserves the right to begin doing so if the need arises. Before any votes are cast on the proposed decision, the community will have a five-day period (until November 18) in which to provide comment on this talk page. During this time, the proposed decision will undergo further linguistic and stylistic revisions and arbitrators may post additional proposals and amendments. |
I strongly urge the committee not to select the proposed alternative, "arbitrated topics". I think it would be better to use a name that is applicable when either the arbitration committee or the community has identified a problem area for which it is authorizing additional measures. isaacl ( talk) 22:27, 13 November 2022 (UTC)
- Frankly that's a point in its favor to me. I think making it easier to tell what is owned by the community and what is owned by arbcom specifically is useful.
Barkeep49 (
talk) 22:28, 13 November 2022 (UTC)
- I do think that would blunt the effectiveness, though. What would community-authorized discretionary sanctions become? Still just discretionary sanctions? (The official documentation for all GS still uses "discretionary sanctions".) KevinL (aka L235 · t · c) 22:31, 13 November 2022 (UTC)
- In my opinion, we should seek to simplify the avenues for applying sanctions by placing them under the same framework, with the arbitration committee having a role in designating problem areas. It's much easier for editors if the same procedure can be followed, regardless of who identified the problem area. The procedure will be easier to write when one term can be used, instead of "X or Y". The only time I think the difference matters is if someone wants to make a case for removing the designation. I think the greater conciseness in documenting the day-to-day operating procedures is more beneficial, though.
isaacl (
talk) 22:49, 13 November 2022 (UTC)
- I mean that's kind of what we have now isn't it? These things grew in tandem and we have a mess. The community can decide it wants to use this tool in its tool kit and continue to have community passed sanction areas. Or it could decide, as it has with desysoppings, that it wants ArbCom to be the only place for these things to happen. It's not ArbCom's responsibility to fix the community's tool (if it's even broken). However, I'm strongly in favor of giving the community access to AE - as I think that encourages the syncing of language you desire. But in terms of clarity I will say that AT gives far more clarity than hindrance imo compared to CT.
Barkeep49 (
talk) 01:00, 14 November 2022 (UTC)
- Right now, we have community-authorized discretionary sanctions that are described as like being the arbitration committee discretionary sanctions, and so editors have to read those instructions and mentally substitute the concept of community-authorized discretionary sanctions. It would be nice if the only point of divergence was who identified the problem area where additional admin actions are available, and then the rest of the procedure would be independent of who identified the area. For daily editing, it doesn't matter who identified the area. isaacl ( talk) 02:22, 14 November 2022 (UTC)
- I mean that's kind of what we have now isn't it? These things grew in tandem and we have a mess. The community can decide it wants to use this tool in its tool kit and continue to have community passed sanction areas. Or it could decide, as it has with desysoppings, that it wants ArbCom to be the only place for these things to happen. It's not ArbCom's responsibility to fix the community's tool (if it's even broken). However, I'm strongly in favor of giving the community access to AE - as I think that encourages the syncing of language you desire. But in terms of clarity I will say that AT gives far more clarity than hindrance imo compared to CT.
Barkeep49 (
talk) 01:00, 14 November 2022 (UTC)
- "Contentious topics" is a good name because it clearly communicates to outsiders what this whole system is really for. "Hey, you're editing in a controversial area, so the rules are stricter". The average person doesn't need to know or care about whether a sanction is community-authorized or arbcom authorized. I can still see the need to disambiguate, so maybe some kind of subpage type syntax along the lines of "Contentious topics/community" and "Contentious topics/arbitration" would work well? The redirects
WP:CTC and
WP:CTA don't seem to be actively used and are pretty catchy.
Chess (
talk) (please use
{{ reply to|Chess}}on reply) 22:48, 13 November 2022 (UTC) - Though I anticipate opposing that specific change as well, to me they are separate discussions. It's a cart before the horse problem to agree to the one name in support of agreeing to allow some overlapping use of the machinery the community and ArbCom each have to enforce decisions made by those bodies in regard to conduct in those areas. And I don't see it as a meaningful objective of its own to try to merge the language the two groups use when dealing with such contentious topics as rise to contention on Wikipedia. (It might be valuable, but it's not its own objective at the end of the day for this discussion, for me at least.)
- Regarding the name specifically, I am not a fan of arbitrated topics specifically, I am a fan of avoiding turning the words contentious topics into a term of art of the same kind as notability has been for a decade and a half and the associated confusion for everyone involved. (You can see more at my
removed comment, though I might do some further copy-pasting of a lengthy comment I left on arbwiki.) I personally wanted to avoid splitting a vote between CT and something else on the something else side, so I did suggest to the drafters to propose only one alternative. I anticipate most arbs voting on any particular name will differentiate most on the line of how much a name used is a term of art or even something completely opaque versus how much it overloads some common-sense meaning of the same phrase (while there might be reasons to keep DS, I haven't seen anything to indicate ArbCom is willing to keep the old name i.e., I anticipate everyone will vote in support of changing the name). There's only so many colors we can paint the bikeshed though, and no real clear winners at the consultation besides AT and CT. We could post all of those proposed there (or those in some response to this discussion) and do some
ranked choice voting if we really must. --
Izno (
talk) 22:53, 13 November 2022 (UTC)
- Not blue, not terquois, not lapis, we need to paint it cerulean. Barkeep49 ( talk) 22:55, 13 November 2022 (UTC)
- I appreciate that the committee isn't responsible for aligning community procedures with its procedures. I'm simply requesting that the committee choose a name that helps enable documentation to be streamlined. isaacl ( talk) 23:05, 13 November 2022 (UTC)
- @
Izno: I'm in favor of "restricted topics" for the new name as suggested by
Tryptofish. It addresses the term of art concern you have while also addressing Isaacl's concerns. No one raised any objections to it during the review, so I figured it would've gotten more consideration here (or at least a vote). –
MJL
‐Talk‐
☖ 21:21, 15 November 2022 (UTC)
- "Restricted topics" has the same problem as "discretionary sanctions" in that it suggests that restrictions on the editing of the topic are already in place (rather than simply being an authorization for editor and page restrictions to later be placed). Additionally, it has the disadvantage of using the same word as a different concept: the actual "page restrictions" that are imposed under this procedure. Best,
KevinL (aka
L235 ·
t ·
c) 21:26, 15 November 2022 (UTC)
- @
KevinL: Restrictions on the editing topic are actually already in place, though. There's (ideally) a higher bar for editor behavoir according to
WP:AC/DS#guide.expect.
The problem of restriction already referring to page enforcement actions, then just rename that topage limitations
. It has the same meaning more-or-less (if anything it probably describes page enforcement actions more accurately). – MJL ‐Talk‐ ☖ 22:26, 15 November 2022 (UTC)
- @
KevinL: Restrictions on the editing topic are actually already in place, though. There's (ideally) a higher bar for editor behavoir according to
WP:AC/DS#guide.expect.
- "Restricted topics" has the same problem as "discretionary sanctions" in that it suggests that restrictions on the editing of the topic are already in place (rather than simply being an authorization for editor and page restrictions to later be placed). Additionally, it has the disadvantage of using the same word as a different concept: the actual "page restrictions" that are imposed under this procedure. Best,
KevinL (aka
L235 ·
t ·
c) 21:26, 15 November 2022 (UTC)
- As I discuss at length on
WP:AN#Sanctions: discretionary, general, standing (
permalink), the inversion and intersection of the terms Discretionary / General between and within and across
Wikipedia:Arbitration Committee/Discretionary sanctions and
Wikipedia:General sanctions, is worded confusingly and counterintuitively. I couldn't even imagine how opaque that might seem to newer users if I, one of the most active admins in both areas, continue to be baffled by this overlapping terminology (and have been for, like, forever).
El_C 13:27, 14 November 2022 (UTC)
- Personally, I hear you, and count it as a major plus for "contentious topics" that it can describe both the ArbCom and community versions of current-DS. Best,
KevinL (aka
L235 ·
t ·
c) 15:41, 14 November 2022 (UTC)
- Like. Glad to hear it. Once this happens, the terms Discretionary sanctions and General sanctions (no Standing orders, please!) will actually have a clear meaning within both.
El_C 17:17, 14 November 2022 (UTC)
- Personally, I hear you, and count it as a major plus for "contentious topics" that it can describe both the ArbCom and community versions of current-DS. Best,
KevinL (aka
L235 ·
t ·
c) 15:41, 14 November 2022 (UTC)
Process related comment This seems like an extremely short time for comment or interactive discussion after a process that's taken quite a long time to get to this point. Many thoughtful, longstanding editors don't even log on during a given 5 day period. Does Arbcom really want to review only the comments of editors who are online every day and have the time to digest and offer comments on this important matter? After all the time it took to get to this point, what does that accomplish? It would be constructive to ensure that a broader range of editors can comment on and/or endorse the ultimate outcome. It would greatly strengthen the community's faith in the result. How about December 10? SPECIFICO talk 15:27, 15 November 2022 (UTC)
- @
SPECIFICO two thoughts as to why it's not as bad (perhaps) as you're thinking. This draft has only minor changes from the version that was up for 30 days of community consultation in October. Also for the first 5 days Arbs aren't to make votes. However, I expect it will take at least a week for Arbs to have the discussion and do the voting necessary, during which time the community can certainly continue to leave feedback.
Barkeep49 (
talk) 15:35, 15 November 2022 (UTC)
- Thanks for the quick reply. My impression, however, was that late in the comment period last time there were some very different approaches put forward. I have not yet read all of the current draft, but at first glance, I was disappointed to see what appears -- I'll be blunt -- to be rather inconsequential tweaks to flawed processes that are familiar and comfortable for the small mumber of Admins and Arbs who volunteer to do this difficult enforcement work. While we all appreciate that effort, I think we can do a lot better than the current dreaft. For example, I thought the proposal by @
AGK:, which came late in the last comment round, set forth a fundamentally simpler and more effective approach. I don't see much of that reflected in the proposed draft. I don't see much cost in leaving the comment open for sustained discussion. If nobody agrees with me, would be fine. It will end here.
SPECIFICO
talk 16:42, 15 November 2022 (UTC)
- Glad I could resolve your process comment. Moving onto your thoughts on substance, speaking only for myself I gave a lot of thought to AGK's suggestion, as was shown by my engagement with the proposal. Ultimately I don't think it improves what is being put forth here for reasons I expressed at the proposal. Barkeep49 ( talk) 16:52, 15 November 2022 (UTC)
- The community can take the lead in modifying its procedures to give administrators more authority to deal with poor editor behaviour in problem areas. By doing so, it can take ownership over the procedures, obsolete the arbitration committee discretionary sanctions procedure, and thus simplify the entire process. With years of experience with discretionary sanctions, I think the community may be ready to revisit what tools it provides to administrators.
isaacl (
talk) 17:45, 15 November 2022 (UTC)
- I think that is what's needed. More active discretionary actions subject to review. How that would be implemented by the community is beyond my knowledge of procedure, and I'd be interested to hear about it if you are ever so inclined. As a case in point, consider what happened in the recent incident concerning @
Tamzin and
Volunteer Marek: a bad sanction was swiftly and civilly reversed with arguably less time and effort than if the issue had been brought to the AE board for a pile-on.
SPECIFICO
talk 17:53, 15 November 2022 (UTC)
- I'm not sure that's a good argument for discretionary actions, since those in favour of expanding their use generally seem to favour using the arbitration enforcement noticeboard (the thought being that pile-ons are more common at the incidents noticeboard than the arbitration enforcement noticeboard). I'm not sure if you're asking about ideas of what should be in a proposal, or about the steps to get a proposal approved. But in either case, a discussion at the idea Village Pump may be a good place to start. isaacl ( talk) 21:43, 15 November 2022 (UTC)
- I think that is what's needed. More active discretionary actions subject to review. How that would be implemented by the community is beyond my knowledge of procedure, and I'd be interested to hear about it if you are ever so inclined. As a case in point, consider what happened in the recent incident concerning @
Tamzin and
Volunteer Marek: a bad sanction was swiftly and civilly reversed with arguably less time and effort than if the issue had been brought to the AE board for a pile-on.
SPECIFICO
talk 17:53, 15 November 2022 (UTC)
- Thanks for the quick reply. My impression, however, was that late in the comment period last time there were some very different approaches put forward. I have not yet read all of the current draft, but at first glance, I was disappointed to see what appears -- I'll be blunt -- to be rather inconsequential tweaks to flawed processes that are familiar and comfortable for the small mumber of Admins and Arbs who volunteer to do this difficult enforcement work. While we all appreciate that effort, I think we can do a lot better than the current dreaft. For example, I thought the proposal by @
AGK:, which came late in the last comment round, set forth a fundamentally simpler and more effective approach. I don't see much of that reflected in the proposed draft. I don't see much cost in leaving the comment open for sustained discussion. If nobody agrees with me, would be fine. It will end here.
SPECIFICO
talk 16:42, 15 November 2022 (UTC)
I like the ability to use a single name for both DS and 'GS', because they're basically the same thing minus who authorises/revokes them and (currently, which is a disadvantage) where reports/appeals happen. I'm not sure about "contentious topics" -- yes, they tend to be contentious, but there are (correctly) plenty of contentious topics without a DS authorisation. So I guess they're technically "designated contentious topics", but that's a mouthful so I guess we drop the first word in most usages. I'm worried this phrasing will lead to more requests for "CT authorisation" at AN, which will pass because the topic is contentious, but without showing that extra tools are actually needed to curtail disruption, or that the topic is any more disrupted than most topics on Wikipedia. ProcrastinatingReader ( talk) 21:41, 15 November 2022 (UTC)
In addition to my previous comments on editnotices: most editors won't benefit from an editnotice on a page that doesn't have any page-specific restrictions, as their editing behaviour is in full compliance with recommended behaviour. I do not feel that increasing the banner blindness problem on a very broad set of articles for very little benefit is a good tradeoff. isaacl ( talk) 22:58, 13 November 2022 (UTC)
-
WP:THEYCANTHEARYOU is also relevant here.
RAN1 (
talk) 23:21, 13 November 2022 (UTC)
- Whether or not someone is able to see an editnotice is a factor in considering awareness of page-specific restrictions. In the case where an editnotice is simply informing editors that the page is in scope of a designated problem area, the editor has to be individually alerted in order to be considered aware of the designation, so the editnotice isn't a factor in considering awareness.
isaacl (
talk) 23:35, 13 November 2022 (UTC)
- That's why the editnotices are for
"optional use" by administrators when needed. Do you think that will cause more harm than good? If so, I'm open to dropping it, but I'd like to hear why you think so (even if we limit its use to administrators, for example). Best,
KevinL (aka
L235 ·
t ·
c) 15:49, 14 November 2022 (UTC)
- As I mentioned previously, I don't know if the state of affairs has changed, but it had been the case that no editnotices were present on pages affected by committee-authorized discretionary sanctions without page-specific restrictions. (COVID-19 is the one area across all the discretionary sanctions topics with editnotices, with one admin feeling strongly about having them; this area had been under community authority back then.) Thus in practice (up to that point last year at least) administrators had not seen a need to use editnotices (outside of COVID-19). I think there are too many pages that can be affected without much benefit (in essence, the editnotice just says keep behaving the way you're supposed to behave on all pages, problem area or not; and editors still have to be individually alerted), particularly if it just adds to the banner blindness problem and makes all editnotices less useful. isaacl ( talk) 16:48, 14 November 2022 (UTC)
- The way the sentence is currently framed, it could be read to say that edit notices are optional only if there are no restrictions on the page. Is that intended? If it is intended, mandatory might be a valuable add to the second part of the sentence.
- I also agree with Isaacl that edit notices and even talk page notices just contribute to banner blindness in the large. So if that influences whether an edit notice is required for a page restriction.... :)
Izno (
talk) 23:56, 19 November 2022 (UTC)
- Done, and clarified in the page restriction text too. Page restrictions have always required editnotices (see Wikipedia:Arbitration_Committee/Discretionary_sanctions#Page_restrictions) so I don't think that will be a controversial clarification. Best KevinL (aka L235 · t · c) 01:35, 20 November 2022 (UTC)
- That's why the editnotices are for
"optional use" by administrators when needed. Do you think that will cause more harm than good? If so, I'm open to dropping it, but I'd like to hear why you think so (even if we limit its use to administrators, for example). Best,
KevinL (aka
L235 ·
t ·
c) 15:49, 14 November 2022 (UTC)
- Whether or not someone is able to see an editnotice is a factor in considering awareness of page-specific restrictions. In the case where an editnotice is simply informing editors that the page is in scope of a designated problem area, the editor has to be individually alerted in order to be considered aware of the designation, so the editnotice isn't a factor in considering awareness.
isaacl (
talk) 23:35, 13 November 2022 (UTC)
Regarding this comment: although appearance is one contributing factor to banner blindness, I think frequency of use is a more significant one with editnotices. That's not something that can be easily dealt with centrally. I'm not suggesting they be prohibited (we've already had an RfC saying admins should be able to decide when they want to put editnotices on an article for which discretionary sanctions have been authorized), but as I mentioned in the previous discussion, I think they should be discouraged. Perhaps some discussion of the banner blindness issue can be placed in the documentation. isaacl ( talk) 21:24, 29 November 2022 (UTC)
Maintaining an equivalent of Template:Ds/aware
Extended content
|
|---|
|
The current section on Awareness has a couple of oversights that could be addressed. The first is that
WP:AWARENESS links to
WP:Raising awareness which isn't about discretionary sanctions. The second is that the proposed wording gets rid of the current
Template:Ds/aware, which allows a user to signal on their talk page they are
WP:AWARE of restrictions and no longer have to be spammed with notices. |
Extended content
|
|---|
|
One of the big pain points the various discussions to date have shown to discourage new admins from joining DS (or whatever) patrol is that nuisance that is logging. Not that it's unnecessary (or non-useful), but as far as I can tell, while the text about logging is different, the actual "how to log" hasn't significantly changed. I could be wrong - please let me know if so. If I'm correct, is there the possibility of, say, a script that could support such? I realise that "you, editor, make this script by order of ArbCom" is not one of their powers, but some influence to encourage it might be a possibility? Nosebagbear ( talk) 23:10, 13 November 2022 (UTC) |
Extended content
|
|---|
|
The template should link to
I dislike the idea of bots and/or automated process deciding who should receive an alert, but don't have an issue with them being delivery that way to people a human has identified as benefiting from an alert. Disallowing automated delivery is significantly preferable to allowing automated selection. Thryduulf ( talk) 23:28, 13 November 2022 (UTC)
I still don't understand the point of awareness/alerts. Sure, awareness for page/topic-wide restrictions (like 1RR) should be necessary, because you can't expect people to behave differently to what's considered accepted wiki-wide (e.g. 3RR) without telling them what different behaviour is expected of them (e.g. don't revert more than once on this page). But for discretionary sanctions? I don't see the point. After getting an alert which "suggests nothing wrong with your behaviour" what are you supposed to do to avoid being sanctioned? It seems to me like your options are to either stop editing in the area, or continue editing and potentially get sanctioned. So basically, I don't see what the point of the alert is. Can one of the drafters explain this to me? (courtesy to L235) ProcrastinatingReader ( talk) 21:41, 15 November 2022 (UTC)
|
- My biggest concern about awareness is that as a user, wanting to make sure someone is aware, it needs to be easy for me to determine whether I should alert them or not. I do not want to be stuck in the situation of "I must alert them in order to complain, but woe unto me if I alert them and they were already aware." It should be obvious one way or the other. In particular, if there are four different ways they might be aware, checking all of them can be troublesome. I haven't been following this process particularly carefully. Will the above situation still come up? Adoring nanny ( talk) 14:11, 22 November 2022 (UTC)
Extended content
|
|---|
|
- The option for administrator's revoking or changing a contentious restriction out of process to receive a sanction other than desysopping (but still allowing for desysopping) should be explicitly available.
Thryduulf (
talk) 23:28, 13 November 2022 (UTC)
- I think may is doing enough work here, but I wouldn't hate an adjustment.
Izno (
talk) 23:42, 13 November 2022 (UTC)
- "May result in sanctions up to and including desysop" isn't the worse thing in the world I guess but I personally would be hard pressed to see the current wording as "may either deysop or do nothing" as the only options available.
Barkeep49 (
talk) 00:49, 14 November 2022 (UTC)
- On the other hand, I think it might be possible for ArbCom to do more than just desysop an admin who changes a restriction out of process, which would make both old and suggested texts meh.
Izno (
talk) 23:25, 19 November 2022 (UTC)
- After consideration, my preference is for keeping the current text. I imagine we wouldn't do more than desysop just for changing a restriction out of process but under the right circumstances we would desysop just for changing a restriction out of process. Best. KevinL (aka L235 · t · c) 23:20, 20 November 2022 (UTC)
- On the other hand, I think it might be possible for ArbCom to do more than just desysop an admin who changes a restriction out of process, which would make both old and suggested texts meh.
Izno (
talk) 23:25, 19 November 2022 (UTC)
- "May result in sanctions up to and including desysop" isn't the worse thing in the world I guess but I personally would be hard pressed to see the current wording as "may either deysop or do nothing" as the only options available.
Barkeep49 (
talk) 00:49, 14 November 2022 (UTC)
- I think may is doing enough work here, but I wouldn't hate an adjustment.
Izno (
talk) 23:42, 13 November 2022 (UTC)
Extended content
|
|---|
|
I don't know if I like the wording "if and only if" - that has a specific meaning in logic that I'm not sure applies here (and I'm not sure I correctly understand the specific meaning). -- SarekOfVulcan (talk) 15:09, 1 December 2022 (UTC)
- @
SarekOfVulcan: Thanks for writing. I'm happy to revise it if a revision would lead to a substantial increase in clarity. The current wording conveys that for an administrator to have the authority to revoke a restriction, it is necessary and sufficient to meet one of the three conditions in the bullet points. In other words, if one of the criteria is met, the authority exists; otherwise, the authority does not exist. That's why the term "if and only if" is used (see
Necessity and sufficiency and
If and only if). Can you point to the unclarity there? Best,
KevinL (aka
L235 ·
t ·
c) 17:51, 1 December 2022 (UTC)
- Eh. The Iff description confused me, but I think Necessity and sufficiency clarified that the wording as it is should work. Thanks for double-checking. -- SarekOfVulcan (talk) SarekOfVulcan (talk) 18:01, 1 December 2022 (UTC)
Extended content
|
|---|
|
Extended content
|
|---|
|
Clarify whether in the event of an editor unambiguously taking action without logging that action within a reasonable period, the log may or may not be updated by any other [editor/uninvolved editor/admin/uninvolved admin]. (My preference allow logging by anyone). Thryduulf ( talk) 23:28, 13 November 2022 (UTC)
|
Extended content
|
|---|
|
The only real suggestion I have atm is that what is currently note d ( |
Extended content
|
|---|
|
The WP:TBAN template at {{ AE sanction/topicban}} is almost as inaccessible as the WP:ARCA template at {{ Arbitration clarification request}} (which says a lot). I don't think I've ever used that template as intended. I mostly just go to WP:AE, find one that was already posted, then adjust it accordingly to whatever the given particulars are. Maybe work on making that (those) more accessible...? El_C 13:34, 14 November 2022 (UTC)
|
Extended content
|
|---|
|
One of the unwritten best practices arrived at WP:AE years ago was that timed WP:TBANs are usually useless (barring some exceptions). This is similar to the unwritten best practice arrived at WP:RFPP years ago against preemptively protecting DS pages (again, barring some notable exceptions). This was a major reason in myself coming to the realization that, and criticism of, many (most?) Committee members being out of touch as to what actually goes on on the ground floor of day-to-day DS enforcement. So, please update me, it that proposal still a thing? Thanks! El_C 13:44, 14 November 2022 (UTC)
|
Extended content
|
|---|
|
The whole process to date can be summarised as follows. We had a consultation. Questions were framed around the existing superstructure of DS, which is like having a statutory reform consultation that poses questions only about the sections of the statute that you're trying to reform. (I accept that four general questions were asked, but the arbitrators have drawn limited conclusions from those.) Despite the consultation's limiting methodology, a consensus view still shone through, that the system isn't working and is overly complicated. We've now ended up with an extremely complicated minor update to the system that, according to prosesize.js, reduces the existing system by only 28 words. The drafting arbitrators are now happily voting on the replacement system. Does this reform really go far enough? It might be better now to have further rounds of consultation, or to ask the community to design a replacement system. AGK ( talk) 20:27, 15 November 2022 (UTC)
|
Regarding the term consensus: I agree that consensus is the base term, encompassing all types of consensus ("X consensus"). I think "clear consensus" conveys the idea of a substantial agreement among most participants as well as a significant number of participants. I don't think the term "rough consensus" should be broken down further than "a consensus that is not a clear consensus". There is a flexibility underlying English Wikipedia's consensus traditions that is lost if the concept is tiered, which is going to result in arguing over how to codify the different categories. isaacl ( talk) 17:21, 28 November 2022 (UTC)
I'm relatively new to this part of Wikipedia, and had I not read ACE2022 candidates' election statements, I'd never come to know that there is all this review going on right now. Is it too late to suggest a name? As I believe something like Safeguarded topics ( WP:SGT/ WP:ST) would be a better fit? I read Izno and feel convinced that "contentious topic" might not be that great of a term to be honest. As someone raised in Phase II page, it is too generic of a term and have an existing meaning beyond the ArbCom enforced sanctions. And "arbitrated topic" might not really be understandable to those unfamiliar with the ArbCom, and can never be extended to GS areas per Wugapodes. I believe SGT would be plain English, understandable to non-native speakers, but not too plain, and extensionable to GS. It conveys its meaning quite well, that a certain topic area is safeguarded from vandalism, etc. Consider reading the proposal page, but with every instance of CT replaced by SGT. I feel like it fits very well in there. — CX Zoom[he/him] ( let's talk • { C• X}) 21:42, 29 November 2022 (UTC)
@
Barkeep49: re feels like we're adding "wikilaw" for something no one has asked for
I believe the idea of bots delivering alerts received community consensus in RfC in the past, but was rejected by ArbCom. So I'm not sure it's something no one has asked for, per se. It's to be expected you won't keep hearing about it if you turned it down already.
ProcSock (
talk) 13:36, 30 November 2022 (UTC)
- I'm not aware of that community consensus. Do you have a link?
Barkeep49 (
talk) 14:51, 30 November 2022 (UTC)
-
Wikipedia:Village_pump_(proposals)/Archive_152#Bot_to_deliver_Template:Ds/alert but it seems I'm misremembering the discussion/timeline slightly, in whether it had a community consensus in favour or not. Seems the RfC never got an uninvolved close since ArbCom
acted with a motion a few days after the RfC was started.
ProcSock (
talk) 18:47, 30 November 2022 (UTC)
- I feel like absent that motion the 60%+ might have been enough to find consensus. So thanks it's still helpful and I'm going to slightly modify my stance. But that discussion still shows one of my concerns - I think getting bot notification right is going to be hard to do. Barkeep49 ( talk) 19:04, 30 November 2022 (UTC)
-
Wikipedia:Village_pump_(proposals)/Archive_152#Bot_to_deliver_Template:Ds/alert but it seems I'm misremembering the discussion/timeline slightly, in whether it had a community consensus in favour or not. Seems the RfC never got an uninvolved close since ArbCom
acted with a motion a few days after the RfC was started.
ProcSock (
talk) 18:47, 30 November 2022 (UTC)
Cite error: There are <ref group=lower-alpha> tags or {{efn}} templates on this page, but the references will not show without a {{reflist|group=lower-alpha}} template or {{notelist}} template (see the
help page).