跳转到内容

维基百科讨论:管理员布告板

页面内容不支持其他语言。
维基百科,自由的百科全书

动议合并一些有关求助的页面

[编辑]

发现中文维基百科的有关求助、讨论的页面太过分散,导致其中一部分页面长时间无人问津,问题得不到解决。尤其是Wikipedia:新手求助。把所有页面统一起来,便于管理,也便于查看。我认为可能存在这种问题的页面有:

不知大家有何看法? --Techyan留言2014年3月21日 (五) 12:34 (UTC)[回复]

我从不知道这些页面的存在。在中文维基百科本身讨论不多的情况下,合并这些小分页非常合理。支持。钢琴小子 打个招呼 查看贡献 2014年3月21日 (五) 23:33 (UTC)[回复]
Wikipedia:管理员通告板其实用作管理员群的交流以及用户寻找管理员帮助的地方应该还是有用的。毕竟一些只与管理员有关的问题,实在没必要放到互助客栈上来--百無一用是書生 () 2014年3月31日 (一) 01:39 (UTC)[回复]

提议规范管理员通告板(VIP,ANM,AN3)的处理程序、时限和方式

[编辑]

众所周知,中维目前用户争议经常导致用户被提报到以上页面。被提报后,除了非常明显的案例之外,管理员经常对投诉进行“冷处理”:查阅近期ANM存档,绝大部分章节的“处理”栏目均为空白。虽然用心良好,但事实上,冷处理导致争议不断延烧,对社群和谐不利,也无助形成一套“习惯法”令社群明白具争议行为可以接受的界线在哪里。是故,本人在此提议在管理员通告版中引入《申请解除权限方针》中关于管理员裁决举报的规定,以鼓励管理员发挥更明确的争议裁决和指引作用。

具体如下。

每宗举报通常处理时限为7天(参照AFD),然非硬性限制。原则上,被举报一方有权进行答辩,但在事实清楚和/或紧急情况下,管理员可直接采取制裁行动。遇到复杂情况,需进一步讨论者,可延长讨论时限。

根据被举报行为的严重性,管理员可作如下回应:

  1. 驳回:举报不成立,不采取任何行动。
  2. 提醒:被举报者行为有所不妥,容易引起争议,但尚未违规,则由管理员作正式提醒。
  3. 警告:被举报者行为的确违反方针或指引,但尚不必进行制裁,则作出正式警告。
  4. 禁制:对被举报者实施编辑禁制或互动禁制。
  5. 暂时封禁:在管理员决定的期限内完全禁止被举报者编辑。
  6. 永久封禁

反复提出不成立的举报视为扰乱行为,可招致编辑禁制。

(引入自RFDR方针)管理员做决定时,应考虑所有用户的发言。进行禁制或封禁的有效理据包括但不限于蓄意犯规、草率行事、执于己见、没有悔意等。

(复审规定)有待进一步讨论。本人倾向规定不服禁制、封禁应使用已有的渠道进行申诉,而不服“驳回”、“提醒”、“警告”处理的用户可在同一页面就同一事件重新举报一次,由另一位管理员处理。另外,任何管理员均可推翻之前管理员的决定,但须有充足的理由。


-- Classy Melissa (批判一番) 2020年7月14日 (二) 13:26 (UTC)[回复]

看起来不错,暂时(+)支持 --  Sunny00217  2020年7月14日 (二) 14:14 (UTC)[回复]
大体(+)支持,一个疑问:如果是被举报用户不服“提醒”、“警告”处理怎么办? DRIZZLE (按此给我留言 2020年7月14日 (二) 14:21 (UTC)[回复]
(!)意见有关操作似乎为向管理提供进一步指示,应当详实讨论不同指示之细节。其中一点,现草拟之有关基本是指定针对被提报对象,认为依据实际不同个案,并不恰当。对于争议之涉及可有两方或之上、乃至多方事务,而有关事宜也会因应不同变化,而有机会于其他程序上处理。基于考虑到实际运作之问题,应仅略微强调有关决断适用于任何牵涉争议案之对象。
而决断应仅列明,基于提交与查核争议之编辑记录、案中发言理据、交叉比对争议中对象与争议外不同记录理据等而作出,并指示可以以第三方角度优先给予争议之协作意见、以便促成一定共识。而现提出之3到6项内容,不建议在草拟指引中优先与明确指示,除非有足够分权制衡机制统合于之(如本地一直无法成行的WP:仲裁委员会),否则此等指示极易变相令管理超合理权限。——约克客留言2020年7月14日 (二) 15:07 (UTC)[回复]
  • @Longway22:谢谢您的意见。此提案并没有给管理员授予新的权力;3-6项都是管理员已经可以做的行动,草案也没有规定在哪些情况必须使用此类措施,所以我不太明白为何会“令管理超合理权限”。此草案的用意之一是给管理员在封禁以外多几个回应举报事件的选择(1-3),正可以帮助调解争端:若涉及争端的用户可以这么想:“我不同意某人的行为,但尊重管理员的独立判断和终局判决,故此事不再追究”,对社群争议解决就颇有帮助。至于对管理员的权力制衡,一个是有上诉机制,另一个是任何管理员如见明显不合情理的处理,都可以迳自推翻(有充足理据避免车轮战/管理战就好),私以为已符合合理制衡的维基惯例。 Classy Melissa (批判一番) 2020年7月15日 (三) 00:43 (UTC)[回复]
  • 再加一点吧:“如阁下用户名列于下方,并认为对方亦有不当,请于同段提出,将对方用户名并列于标题,毋须开设新提案。敬请合作。管理员对所有涉及争端的用户都可以作出相同或不同的处理。(一事不再理原则)除非出现有说服力的新证据,不得就同一用户的同一行为作出重复举报。 Classy Melissa (批判一番) 2020年7月15日 (三) 01:04 (UTC)[回复]
(+)支持--Starry🌟Home🏠 2020年7月14日 (二) 16:26 (UTC)[回复]

小工具

[编辑]
(!)意见:其实VIP的xiplus小工具已经罗列了很多不同的处理方式,我觉得比提案更可取。相反,我觉得与其定立规则,不如邀请技术大帝为ANM,AN3也设计一个小工具,这样我觉得更实用。--虫虫飞♡♡→♡℃留言 2020年7月15日 (三) 13:36 (UTC)[回复]
(!)意见(▲)同上。--安全体验TM 2020年7月15日 (三) 13:56 (UTC)[回复]

────────────────────────────────────────────────────────────────────────────────────────────────────@蟲蟲飛:close-anm已更新(并移动至User:Classy_Melissa/gadgets/close-anx.js),改了一些细节和bug,同时支援ANM和AN3两个页面。DRV的在写了,不日即可完成。 Classy Melissa (批判一番) 2020年7月16日 (四) 01:34 (UTC)[回复]

Classy Melissa提报到错的地方的提报应该获得转介或由管理员提示提报者转介。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月16日 (四) 01:09 (UTC)[回复]
@Sanmosa:我建议是若提报错地方,任何其他用户均可自行移动至对的页面。 Classy Melissa (批判一番) 2020年7月16日 (四) 01:23 (UTC)[回复]
Classy Melissa现在本来就可以这样移动(我很久以前就做过了),但这有机会导致编辑战和提报战(例如提案人坚决认为那个是破坏,不让人移动到AN3或ANM,然后把移动的人都给提报了,这最近我看到其他人有发生)。另一方面,如果没人移动的话,管理员还是有责任完成这个工作,而不是直接驳回,不然就和冷处理没分别。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月16日 (四) 01:29 (UTC)[回复]
@Sanmosa:那我考虑一下要不要修改close-vip等小工具,增加自动移动的功能。 Classy Melissa (批判一番) 2020年7月16日 (四) 01:37 (UTC)[回复]
好的,不过没这个功能暂时也无大碍(反正我没有在用)。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 2020年7月16日 (四) 01:41 (UTC)[回复]
我想了一下,这不是技术问题,不应用技术手段解决。不如规定,若管理员转交到anm或an3,同一事件就不得重复在vip提出。 Classy Melissa (批判一番) 2020年7月16日 (四) 06:07 (UTC)[回复]

因应WP:行政员布告板的设立,想提出一些关于WP:管理员布告板的问题:

  1. WP:管理员布告板/其他现时用作提报非破坏性的不当行为,但此命名可能引导用户直觉认为该布告板是用作向管理员提报其他所有事项。早前WP:管理员布告板/编辑争议因用词不准确已经更名(原为“/3RR”),是否应该讨论和考虑WP:管理员布告板/其他的命名是否准确恰当?个人认为以该页的用途而言,更名为WP:管理员布告板/用户不当行为更为恰当。
  2. 续上,en:Wikipedia:Administrators' noticeboard用作与管理员团队整体之通讯。是否整体而言更适合回归该主页?英维常见在AN主页的提报包含处理页面争议、管理员使用权限处理事项的相关疑问和争议(例如最近的保护争议)、请求处理积压等等。现在不少这类型的通讯在中维分散在不同页面,有的在本板(互助客栈其他板),有的在条目探讨板(我比较好奇,这个板哪里“互助”了,根本就是RfC的集中板而已啊?为何不好好启用RfC在条目讨论页处理,非得在“客栈”讨论后又存回条目讨论页?),有什么事情又要ping一堆管理员,为何不集中在WP:管理员布告板主页进行通讯呢?是否应该重启布告板主页?

以上。--路西法人 2021年11月28日 (日) 16:56 (UTC)[回复]

(~)补充对布告板系统的相关意见和问题:
  1. WP:申请解除权限使用率颇低,今年至今11个月整才41宗(平均一个月才四宗)被提报滥用权限、13宗请辞或弃用无用权限(平均一个月仅一宗)、14宗已封禁或除权用户复审(平均一个月仅一宗)。提报滥用权限的41宗基本上很容易出现一案两审(因为WP:ANM的存在),基本上全部并回ANM都可以;请辞或弃用无用权限可并至重新设立的WP:管理员布告板主页(如同请辞管理员并回WP:行政员布告板;已封禁或除权用户复审则应透过JS提醒管理员被永久封锁用户有权限需要移除,遗漏者亦可透过WP:管理员布告板主页提醒管理员处理。
  2. WP:互助客栈/条目探讨板基本上就是RfC的简化+混乱板。RfC设好还用不用这板?(可能直接重定向至RfC主页更好)
  3. WP:已删除内容查询不知道为何连结至英维en:Wikipedia:Requests for undeletion,不是应该连至WP:存废复核请求吗?
  4. 请求处理管理员积压有时候真的不知道为何会挂在公告栏,有用吗?
  5. 互助客栈除了求助板以外还真的没哪个板是“互助”的,本质上就没有半点是互助的讨论空间,我觉得去掉互助两个字其实并无不可,直接“客栈”就足够了,这样就不会有“互煮客栈”这个称号了呢~[开玩笑的]
其他用户怎么看呢?Ericliu1912--路西法人 2021年11月30日 (二) 09:21 (UTC)[回复]
申请解除权限可并入管理员布告板;互助客栈条目探讨区不适合并入集中讨论;已删除内容查询之跨语言连结问题系本地与英维存废讨论类型不同所致,并无修正必要。—— Eric Liu 创造は生命(留言留名学生会STE 2021年11月30日 (二) 10:42 (UTC)[回复]
“互助客栈条目探讨区不适合并入集中讨论”能否解释?--路西法人 2021年11月30日 (二) 11:03 (UTC)[回复]
我认为集中讨论比较适合用来做政策意见收集,或短期密集讨论;互助客栈条目探讨区行之有年,运作良好,有长期需求,未见有必要为切换而切换。况且集中讨论目前实施起来其实并不算多成功。—— Eric Liu 创造は生命(留言留名学生会STE 2021年11月30日 (二) 16:59 (UTC)[回复]
enwiki的undeletion限于索取已删除资料、复还过期草稿和未讨论而删除的页面,经XfD讨论删除的页面跟我们一样是要走DRV的。把Wikipedia:已删除内容查询连结到undeletion是正确的。--无聊龙·留言·贡献 2021年12月8日 (三) 05:52 (UTC)[回复]

好像不够关注,搬过来看看。--路西法人 2021年12月8日 (三) 04:17 (UTC)[回复]

“其他”改名为“不当行为”。补充:是不当行为四个字。桐生ここ[讨论] 2021年12月8日 (三) 04:22 (UTC)[回复]

那么阁下对于其他讨论点(重启管理员布告板主页、申请解除权限并入管理员布告板、互助客栈名称)等有没有意见?--路西法人 2021年12月8日 (三) 05:20 (UTC)[回复]
支持重启主页,互助客栈没坏别修,互煮也挺好的[开玩笑的]。不支持解除权限并入管理员布告板,认为解除权限和申请权限应该并入WP:用户权限级别的子页面。桐生ここ[讨论] 2021年12月8日 (三) 05:50 (UTC)[回复]
“不当行为”是否宽泛了些?破坏,编辑战都可以算是不当行为。--东风留言2021年12月8日 (三) 09:40 (UTC)[回复]
可以“其他不当行为”。桐生ここ[讨论] 2021年12月8日 (三) 10:17 (UTC)[回复]
我个人向来支持以“/其他不当行为”命名。—— Eric Liu 创造は生命(留言留名学生会STE 2021年12月8日 (三) 13:43 (UTC)[回复]

推一推:就重启WP:管理员布告板主页和WP:管理员布告板/其他移动至WP:管理员布告板/其他不当行为 公示7日,2021年12月21日 (二) 18:47 (UTC) 结束。--路西法人 2021年12月14日 (二) 18:47 (UTC)[回复]

我会支持重启,但要先界定管理员布告板之处理范围,例如“除当前的破坏、编辑争议或其他不当行为以外之管理员工作相关事务”之类的。—— Eric Liu 创造は生命(留言留名学生会 2021年12月14日 (二) 19:32 (UTC)[回复]
基本上就是没有布告板的管理员通讯或事务。--路西法人 2021年12月15日 (三) 10:05 (UTC)[回复]
这样的话Jason22案就文体四开花了, 囧rz……,请求处理积压你希望是怎样提出来了,一般也是极短的一句而己,要搞也最多是搞个积压报告板。此外,重启布告板后要不要处理申请解除权限你好像没说到,实际上也就是让几个问题儿多个骂战的地方,很难真的让管理员值得关注的问题放上主页。--🐦C🕛 2021年12月19日 (日) 04:19 (UTC)[回复]
用户问题应该那三版就已经要处理到了,管理员布告板说明了是供“没有独立布告板的通讯事务”。通常比较少通讯或事务直接联络管理员我觉得不代表该板没有设置的意义,基本上还是要有的,与其在不同议题上@管理员请求协助处理问题,倒不如在一个统一板上联络管理员,这也包含类似早前的长期全保护等问题,管理操作复核请求也应该属于合理置于此页的内容,包括错误保护、移动、封锁等需要通讯管理员的事务应当适合此页。例如过滤器错误封锁用户,其他比较资深的用户发现了也可以透过此板通知所有管理员(此前没有任何公开通告的途径,只能透过单独或私下联络管理员处理的问题)。--路西法人 2021年12月21日 (二) 04:37 (UTC)[回复]
管理复核的数目我并不认为会有相当多的数目要引致独立另开一页的需要,毕竟这三四个月内实际上能上AN的案件大概也只有五六宗左右 ,而且针对除权的问题,也似乎是比较功能性的,实际上有三分之一是IPBE的问题的话,实际上这些案件根本不需要这样高的关注度,而在AN处理。其他不当问题也不容易定明,我注意到11月#3RR更名以来似乎案件有减少的问题,似乎大家可能将其当成内容争议处理页之类的,变成提报到ANO之类的地方,可能APO更名后都有这样的问题。--Ghren🐦🕖 2021年12月21日 (二) 11:22 (UTC)[回复]
我不认同此布告板的使用率代表此布告板不适合存在,如果要比较,行政员布告板远比管理员布告板的使用率低,但不代表没有设立的需要。在存在行政员布告板的情况下,设管理员布告板供通讯作用。就连英维管理员布告板主页实际符合使用作用的使用率也不怎么高,但设置了总是会方便社群通讯用。另外,因为公告栏存档比较快,管理员很可能一个月的维基假期已经落后了一些关于管理的方针指引更新,管理员布告板也不只是用作“布告”问题用的,原翻译“通告板”应该能让你更加理解为何要设置此板。--路西法人 2021年12月21日 (二) 11:56 (UTC)[回复]
使用率和其他页面重复是当初社群共识Wikipedia:对管理员的意见和建议,如果看回存档,就会发现你希望处理的事务是相当相似的。WP:BN使用虽然低,但他所处理的事务是明显不宜放在其他页面所处理的,这是两件事情。而且开了之后变成有些拉票案之类的又会多开花的情况。假如一些管理方针指引更新,管理是应该去看公报而不是依靠WP:AN上的更新。我估计成立之后只会像WP:ANOWikipedia:对管理员的意见和建议变成对管理员个人投诉和封禁重审之类的页面,新手不知道去哪然后放在AN也是个问题,事实是中维的报告板就是报告板,很少有通告用途。最大问题还是什么能放上去的问题。申请解除权限的问题你好像还没有回。WP:VPO#有关被全域禁制用户的用户讨论页或者WP:VPO#请求撤销User:Guyiming所有的破坏性编辑之类可以放上去吗?管理才可动的模板应该在WP:VPTWP:VPD还是WP:AN呢?总之还有很多细节问题。假如只是空泛定义为所有在其他页面不合的事务的话,抱歉不能支持。--Ghren🐦🕓 2021年12月22日 (三) 08:19 (UTC)[回复]
@LuciferianThomas--Ghren🐦🕚 2021年12月26日 (日) 15:56 (UTC)[回复]
你在这个尴尬公示接近结束时才提出的反对要我怎样处理 囧rz……--路西法人 2021年12月27日 (一) 02:00 (UTC)[回复]
社群都是这样,不公示就不反对,其实我是之前太忙留意不了,浪费阁下心血不是我的原意。--Ghren🐦🕚 2021年12月27日 (一) 15:44 (UTC)[回复]
@Ghrenghren:因阁下仅对重启主页的部分提出反对,而并未对其他板更名的部分提出反对意见,我将该部分先视为通过,重启主页的部分再继续进行讨论和征求其他用户的意见。--路西法人 2022年1月2日 (日) 05:52 (UTC)[回复]
是的,可以去找个管理来更名。--Ghren🐦🕑 2022年1月2日 (日) 06:37 (UTC)[回复]
LuciferianThomas这边建议找Xiplus。—— Eric Liu 创造は生命(留言留名学生会 2022年1月9日 (日) 12:22 (UTC)[回复]
经站外找过了,他说得等机械人操作者修改机械人,这部分已经通知了对方了。--路西法人 2022年1月9日 (日) 13:42 (UTC)[回复]
@LuciferianThomas:目前有无进展?—— Eric Liu 创造は生命(留言留名学生会 2022年1月24日 (一) 12:59 (UTC)[回复]
首先,个人认为一般情况下,尤其对于需要面向大众或市场的用品、产品或任何设计而言,最符合人性直觉的使用介面最方便、最容易上手,也最能增进使用者正面体验;对网站而言,若浏览动线或使用介面叠床架屋、复杂繁浩,使用者无法简单找到需要的功能或页面,实在称不上好设计(如某些政府机关网站(笑))。
以此而言,敝人窃以为正因一般使用者会在有站务需求时直觉找上“管理员布告板”寻求协助,故将管理员权限所辖之站务汇聚统整于此,实属名正言顺、理所当然,自无必要刻意“反直觉”或让人难以辨识,不然为何要反直觉呢?除非你想整新来的使用者,或担心被使用者发现“原来你是管理员”(笑)。
其次,就此布告板之用途和定位而言,窃以为是“汇聚媒合管理员站务供给与需求”之处,而此页面的使用者应同时包含管理员团队和一般使用者,因此理想上应含括站务协助申请、联系管理员或让管理员彼此联系、相互支应(当然视管理员自愿提供之方式或投入之心力而定)等功能。而不属于须劳烦管理员团队才能处理的站务,如目前“维基百科:请求管理员帮助”页面所示之相关内容,分割留置原处即可。
若依此而言,个人建议将“维基百科:管理员布告板”的页首文字改为:“管理员布告板是专门申请处理必须透过管理员才能协助解决的问题之页面,若用户有其他站务需求,请参阅“维基百科:请求其他站务协助”,或迳至“维基百科:互助客栈”发起讨论。”即可。而通常置于页尾的小模板栏位和字样亦可能须视情形连动编修一番。
最后敝人提醒,不论如何异动发展,众站友(含管理员团队)自然自适、量力而为即可。
以上为个人意见,供参。--Kriz Ju留言2022年1月9日 (日) 13:35 (UTC)[回复]
大部分同意,但唯一不同意就是把所有站务都聚集在该处,小维基尚可这样运作,大维基就是太多提报难以处理才改为分拆部分布告板专门处理不同事项。--路西法人 2022年1月11日 (二) 04:53 (UTC)[回复]
我们已经拆分了各种业务出来,其实中文维基百科虽然不能算小维基,但也没大到哪里去XD —— Eric Liu 创造は生命(留言留名学生会 2022年1月11日 (二) 13:28 (UTC)[回复]

个人在处理站务时,常常遇到自己或他人需要联系或通告管理员之情况,但有时私下联系并不得体,且有碍于往后存档之查询,而全然仰赖互助客栈其他区亦非良策。去年社群曾有讨论,惟无下文。考虑到长期需求确实是存在的,现请求重启管理员布告板主页面,用于讨论与协调管理员相关事务,惟不包含编辑争议其他使用者之不当行为在内。副知参与上次讨论之@GhrenghrenKriz JuLuciferianThomas桐生ここ無聊龍。—— Eric Liu 創造は生命(留言留名学生会 2022年4月30日 (六) 02:55 (UTC)[回复]

只要它不要办得好像一个用户行为终审法庭一样的地方其实就应该没有问题。提醒积压之类,互相交流的理论上应该不会有问题,但是假如日后又成为用户互相举报之场所,只怕管理员不会有心思去管这些玩意。单纯作为管理员之间交流,请求管理员协助的页面就好。--Ghren🐦🕐 2022年4月30日 (六) 05:19 (UTC)[回复]
比方说像是合并条目的请求,或是与本站管理员相关的通告等,我认为都是可以上布告板的,符合该页面宗旨的。至于使用者之间互相举报,毕竟多半适用于上述例外子布告板的范围,分流便是。—— Eric Liu 創造は生命(留言留名学生会 2022年4月30日 (六) 11:38 (UTC)[回复]
合并条目不是已经有WP:合并条目了,这种情况可能将合并条目放宽点改成合并编辑历史也可以比较好。--Ghren🐦🕐 2022年5月1日 (日) 05:54 (UTC)[回复]
合并历史是移动请求而非合并请求,另外有{{Histmerge}},但未有相关程序也不广为人知。--Xiplus#Talk 2022年5月1日 (日) 05:58 (UTC)[回复]
emmm...确实。相关的情序比较含糊而不清晰,也难怪大家都走去管理员的讨论页问。--Ghren🐦🕑 2022年5月1日 (日) 06:31 (UTC)[回复]
规定长讨论应尽快{{moveto}}到适当页面会有用吗,比如讨论达3天或3人,且移动无需避嫌。条目讨论页可能是冷却争执的好地方?而客栈可能有更多关注度。--YFdyh000留言2022年5月1日 (日) 06:38 (UTC)[回复]
支持,WP:ANO偏向“举报”,需要一个“讨论”的板块,也可用来寻求管理员帮助,请求合并页面历史/移动flow页等等。看了客栈其它版近半年存档,这些也适用:关于Unblock-zh邮件列表的一些事、WP:AR积压、条目名含间隔号_需管理员代劳、请求xxx管理员解释其近期言行的详细原因 --及时雨 留言 2022年5月2日 (一) 22:01 (UTC)[回复]
请求xxx管理员解释其近期言行还应该是移到VPO讨论比较好,合并页面历史和移动Flow也看来是移动请求做的。--Ghren🐦🕛 2022年5月7日 (六) 16:16 (UTC)[回复]
对于这种话题,管理员布告板亦可作为集中分流之处。总好过四散在各种布告板、讨论页、互助客栈而难以收拾吧。—— Eric Liu 創造は生命(留言留名学生会 2022年5月7日 (六) 17:03 (UTC)[回复]
我总觉得社群是戒不掉将向某指定的管理员作出请求的毛病。假如确实有四散在各种布告板的问题,这说明可能相近的布告板可能太多了。虽说这次我不反对,但是我还是不看好新手能搞请什么要找管理员,什么不用找管理员。--Ghren🐦🕐 2022年5月8日 (日) 05:11 (UTC)[回复]
若在看完请求管理员帮助页面之后还是不知道什么时候要找管理员,那大概还是真的去找管理员比较好。—— Eric Liu 創造は生命(留言留名学生会 2022年5月9日 (一) 12:01 (UTC)[回复]

公示建议七日。—— Eric Liu 創造は生命(留言留名学生会 2022年5月7日 (六) 17:09 (UTC)[回复]

通过。—— Eric Liu 創造は生命(留言留名学生会 2022年5月14日 (六) 17:20 (UTC)[回复]

如题,一直以来Wikipedia:新闻动态候选#错误回报区作用不明显,用户提出错误或修改意见后少有管理员能够依照改正,且错误回报区无存档位置,不利于部分情况下的文字查证。现初步提议将错误回报区移动至Wikipedia:管理员布告板,移动后实际用途和范围并未变更(均为管理员处理),且可以进行存档。不知其他人意见如何。--东风留言2022年12月6日 (二) 14:50 (UTC)[回复]

如果能有其他管理员去介入,我觉得很好。如果其他管理员有顾忌而不想碰那里,就没必要。--YFdyh000留言2022年12月6日 (二) 17:59 (UTC)[回复]
就这段时间新闻动态的更新来看,是有其他“非常驻”管理员进行处理的。--东风留言2022年12月8日 (四) 03:29 (UTC)[回复]
是否可以直接在新闻动态候选的提名处?--Kethyga留言2022年12月7日 (三) 00:00 (UTC)[回复]
为什么不移到Wikipedia talk:首页?--GZWDer留言2022年12月7日 (三) 18:52 (UTC)[回复]
可能在其他地方关注度不够?--Kethyga留言2022年12月8日 (四) 08:41 (UTC)[回复]
我一直以为错误回报有存档,结果竟然没有喔?—— Eric Liu 創造は生命(留言留名学生会 2022年12月10日 (六) 07:40 (UTC)[回复]
新闻动态候选有存档,错误回报没有。--~~Sid~~ 2022年12月14日 (三) 02:12 (UTC)[回复]
基本上我个人的想法是只要有存档,提报放哪儿都没差。—— Eric Liu 創造は生命(留言留名学生会 2022年12月20日 (二) 12:41 (UTC)[回复]
同意提案。ITN错误回报区的报错需要管理员快速解决,理应有更大的能见度。--PATLABOR 英格拉姆Ingram Talk 2022年12月14日 (三) 20:35 (UTC)[回复]
(=)中立,不管黑猫白猫,跑得快的就是好猫。--FK8438祝您剩蛋快乐签名)🎄🎄 2023年1月4日 (三) 08:10 (UTC)[回复]

@Easterlies:看来应是有共识?—— Eric Liu 創造は生命(留言留名学生会 2022年12月30日 (五) 08:18 (UTC)[回复]

讨论人数在我看来不算很多,再加上不算什么大型共识,参与者还是多点为好。--东风留言2023年1月1日 (日) 16:02 (UTC)[回复]
不过这部分主要是管理员在处理,似乎不需要非常广泛的共识?只是要做好通知措施,避免提报者跑错地方。—— Eric Liu 創造は生命(留言留名学生会 2023年1月12日 (四) 02:28 (UTC)[回复]
我又想了想,或许留在新闻动态候选比较好?流量确实比较高。—— Eric Liu 創造は生命(留言留名学生会 2023年1月13日 (五) 04:23 (UTC)[回复]
流量高可以只在布告板放捷径,处理效率/能力不高就允许在布告板发布然后存档/记录到候选。--YFdyh000留言2023年1月13日 (五) 06:47 (UTC)[回复]

编辑请求 2023-10-26

[编辑]

请求已拒绝

提交的Wikipedia:新条目推荐/候选的条目,最后以无人投票的结果来结束,请问能否再次提交?--125.230.32.250留言2023年10月26日 (四) 03:38 (UTC)[回复]

未完成,无效请求--百無一用是書生 () 2023年10月26日 (四) 08:36 (UTC)[回复]

尊敬的管理员

[编辑]

尊敬的管理员先生,您们好,我是香港导演会的研究员,因见到黄真真导演的原页面,出现颇多内地网民的中伤和欠缺公允、偏颇的文字,故尝试进行修改,并增加所有修改内容的链接出处,但我不太懂使用维基编辑版面,故被一些编辑当作恶意修改,我希望得到管理员的帮忙,我已经将内容及出处链接均大幅度补充,仍然被删除,请问该怎么处理: 此为增加所有资料来源的版本, https://wiki.zwnes.eu.org/w/index.php?title=%E9%BB%83%E7%9C%9F%E7%9C%9F&oldid=82502420

再次感谢。--Kakagoing留言2024年5月4日 (六) 01:38 (UTC)[回复]

请你阅读你自己的对话页空间,你的编辑存在复数议题
WP:外部链接
WP:版权
WP:BLP
WP:原创总结(尝试综合复数来源或连结得出原始材料并未明确提及的内容)--Rastinition留言2024年5月4日 (六) 01:50 (UTC)[回复]

订阅通知之不合适

[编辑]

由于我们中文维基只有二级标题(== 二级标题 ==)才有订阅通知的功能。所以大量使用三级标题(=== 三级标题 ===)WP:ANIWP:AN3WP:AIVWP:UAA都只有一项订阅按键,即订阅后所有各人的信息都通知。跟WP:VPWP:AFD的处理不同,没有多项订阅按键,可以只订阅某几项主题。

鉴于存档也不会用到二级标题,直接存三级标题;原来二级标题的功能也完全能用监视功能代替;我建议把以上WP:ANIWP:AN3WP:AIVWP:UAA的三级标题都换成二级标题。--☥⚕20204622⚚⚘𒀯космос♾ 2024年6月11日 (二) 09:49 (UTC)[回复]

Wikipedia:管理员布告板/不当用户名是列项记录,没有使用标题区分。WP:ANIWP:AN3WP:AIV则有一个二级标题作为总章节,不确定是个格式需要或者被包含时的需要。(暂时找到Wikipedia:管理员积压工作里面的统计Module:AdminBackLog依赖代码格式)——Sakamotosan路过围观 | 避免做作,免敬 2024年6月11日 (二) 11:27 (UTC)[回复]
我觉得这个应该可以让wmf支援就是了,--SunAfterRain 2024年6月11日 (二) 13:01 (UTC)[回复]
我建议过,基金会似乎对此缺乏意愿。--YFdyh000留言2024年6月11日 (二) 16:20 (UTC)[回复]
在哪里建议过?--SCP-0000留言2024年6月11日 (二) 17:00 (UTC)[回复]
找不到了。也可能只在中文维基讨论过。--YFdyh000留言2024年6月12日 (三) 05:08 (UTC)[回复]
最主要就是 怎么说呢 这种格式的东西一改下去一定一堆小工具机器人直接崩掉...--SunAfterRain 2024年6月12日 (三) 15:36 (UTC)[回复]

管理操作复核的议题

[编辑]

原标题为:提议设立请求封禁机制以及扩大AARV的使用

提议设立请求封禁机制以及扩大AARV的使用

[编辑]

我建议社群考虑设置类似“请求封禁”的机制,即对于非纯破坏行为,有共识后再执行封禁,而非管理员独自判断引起争议。

对于解封请求,我建议扩大WP:AARV的使用,申请人可以选择请求任何一名用户协助提出AARV,由社群进行判断封禁是否适当。

提请各位讨论,有关方针条文也请踊跃发表。--桐生ここ[讨论] 2024年6月14日 (五) 07:53 (UTC)[回复]

Ping有对提案发表意见的人@日期20220626ChiuHsiao1221ShwangtianyuanHYHJKJYUJYTTY。--桐生ここ[讨论] 2024年6月14日 (五) 07:55 (UTC)[回复]
本人是(+)支持,社群考虑设定类似“请求封锁”的机制,确实能解决很多不必要争议,非纯破坏行为,至于解封请求,建议扩大WP:AARV的使用,我也支持,--HYHJKJYUJYTTY留言2024年6月14日 (五) 08:10 (UTC)[回复]
本人亦是倾向(+)支持。针对某位编辑账号的封禁无异于是在维基百科范围类对某人“执行死刑”。既然现实里文明国家的死刑都有复核和救济制度,那我认为维基社群也应该考虑。除了机器人账号或纯粹破坏行为外,针对其他行为的封锁账号行为要给于“拟被封所账号者”一个申诉和申请复核的渠道。--Chiu Hsiao (✉️Message) 2024年6月14日 (五) 08:20 (UTC)[回复]
原则上同意扩大AARV,但实际执行上对社群整体正确解读及执行方针有极大疑虑。在社群本身已经存在失能、有不少用户连最基本的方针指引都愿意无视的情况下,我不认为当前的社群整体而言有足够能力作出完全合乎方针指引及背后原则理解,以此判读管理人员的管理行为是否恰当。光是社群中仍对于“不限期”错误理解为“永久”或“比其他更重”的观点(WP:不限期不等于永久才是正确理解)已经反映社群缺乏判读封锁是否恰当的能力。在多个解封案例中,多名用户未有真的分析封锁理据、没有考量方针指引要求、未有从执行人的视角去看事件,甚至只是因为跟管理人员的个人恩怨就直接提出反对,反映社群缺乏作此判断的能力。原则上AARV是一件好事,但实际需要达到的效果目标及需要的技巧跟担任仲裁员无异;而仲裁委员会都尚会是社群经选举选上去的一群人,AARV的参与社群却是未经社群检视资质的用户技能参与,粗暴点说就是平民版仲裁,跟仲裁委员会的公信力还要差个天差地别
请求封锁有极度严重社群程序官僚化及暴民政治的风险,如同上方所述,社群整体而言本身缺乏正确判读什么情况适合或不适合封锁的能力,也往往主张采取不足以阻截扰乱编辑的措施。请求封锁涉及管理员权限,又是由谁来判读共识又是一大问题:社群本身缺乏判读共识的能力(永远只会点人头而不看论据强弱),管理员自己判读共识又产生一个会起疑的点,简单来说就是没解决任何问题,还产生了更多的问题的提案。--西 2024年6月14日 (五) 09:57 (UTC)[回复]
反对引入仲裁制度的人,却提案引入一个目标近似仲裁的机制,但这机制极度取决于社群能力(惟社群已经展现其失能),却也完全没有仲裁要求的严谨。在社群缺乏有关判断能力、扭曲理解方针、无视方针原则的行为获得控制前,AARV就只是一个跟当前RFDA没分别,只会制造更多争议的体制。--西 2024年6月14日 (五) 10:27 (UTC)[回复]
那这么说吧,蓝桌的调查报告很好,如果封禁非纯破坏用户前,要求管理员写一份调查报告呢?--桐生ここ[讨论] 2024年6月14日 (五) 11:11 (UTC)[回复]
包括所有差异链接,逐条说明为什么违反方针,决定量刑多久,决定量刑的理由。如果当事人怎样做可以获得原谅和解封。或者遭不限期封禁者,多久之后提出申诉可以考虑解封。--桐生ここ[讨论] 2024年6月14日 (五) 11:17 (UTC)[回复]
管理员在封锁理据中已经提供理由和对应的diff即可视作已提供封锁报告。如果处理每一个非破坏用户都需要这样写的话,用意是好但极度官僚,手续过多可能导致愿意处理此类封锁的管理员越来越少,反而变成放任了这些扰乱者继续搞事。不过,我是同意可以要求管理员在执行不限期封锁时在封锁讯息下写出不限期封锁的考量,并在有可预见的改善可能(即不属VOA、SPA或再次封锁的用户)情况下提供WP:不限期不等于永久的说明,并写说需要对方了解什么方针指引即可获得解封(第二次机会)。
至于详细的封锁报告,则应是在AARV或仲裁的情形下提供。惟发起AARV的门槛过低,除了担忧AARV参与者素质外,还担忧会被滥用以针对特定管理员,制造毫不必要的工作量。--西 2024年6月15日 (六) 00:24 (UTC)[回复]
你维管理员封禁此类人士已经圣母到极致,若是再加调查报告这种减速带我看你维是不想请捣乱的人离开了?--0xDeadbeef (留言) 2024年7月6日 (六) 16:16 (UTC)[回复]
Wikipedia:管理员布告板/编辑争议Wikipedia:管理员布告板/其他不当行为已经复杂到我不愿意碰了,再弄这个的话更不会没事去看了....--百無一用是書生 () 2024年6月17日 (一) 02:14 (UTC)[回复]
社群针对此议题是不是讨论过不少次了?为什么我感觉几个月以前才有一次。—— Eric Liu 創造は生命(留言留名学生会 2024年6月14日 (五) 12:50 (UTC)[回复]
基本上这种制度是聊胜于无,比起现在的情况肯定是利大于弊。但也要指出,管理员执行封锁操作时,理论上已经要确定当事人违反本站政策,“独自判断引起争议”可以是对管理员裁量权的事后合理质疑,但不是限制管理员行使封锁权限的前提。—— Eric Liu 創造は生命(留言留名学生会 2024年6月14日 (五) 12:52 (UTC)[回复]
支持,帮助明确共识。但裁量权目前还是得有。--YFdyh000留言2024年6月14日 (五) 14:24 (UTC)[回复]
理解提案的用意,乐见其成。但在实践上可能会如路西法人君所说产生更多问题,或许会造成另一个管理员布告板。明白提案及用户对管理权运用的忧虑。-千村狐兔留言2024年6月14日 (五) 15:53 (UTC)[回复]
注:此留言已被原作者(User:月都)移除。
我觉得也应该探讨一下为什么管理员们不愿意碰WP:ANMWP:AN3,如果ANM、AN3都不愿意碰,再开一个AARV事实上只会让管理员的事情变更多,我想这某种程度上并没有解决问题,反而多了另一个问题,再提醒一下管理员也是"志愿者"。
社群愿意的话亦可探讨为什么管理员越来越不活跃,还有什么方法吸引管理员回来帮忙扫地,或是另外寻求一条出路解决这个问题。--~~Sid~~ 2024年6月17日 (一) 13:04 (UTC)[回复]
额外补充我并不是要反对提案,只是不希望社群设立之后却没有达到预想的效果。--~~Sid~~ 2024年6月17日 (一) 13:05 (UTC)[回复]
以“有共识后再执行封锁”来处理“管理员独自判断”的潜在弊端可能不符比例原则,我更倾向于引入类似助言日语助言的机制,要求管理员在执行不限期封锁前应先取得至少一位未涉事的第三方用户的同意,以确保所有不限期封锁的执行都不违反比例原则。Sanmosa Snipe–Clam Grapple 2024年6月18日 (二) 13:35 (UTC)[回复]
我认为这个方法可行。--~~Sid~~ 2024年6月18日 (二) 14:59 (UTC)[回复]
少打字,修正留言。~~Sid~~ 2024年6月18日 (二) 15:00 (UTC)[回复]
不合适。破坏者还要助言?说这是明显例外吧,但又有什么应该是例外呢?到头来还是要争吵。如此官僚主义弊病过重,我想事后复查比事前在那边极其复杂地商榷认定界线要容易得多。另外我还是要指出,理论上若管理员是依据社群讨论通过的方针与指引执行封锁,就是在确保社群共识得到实践;故除理据不清之外,通常不能说管理员“未依共识”执行封锁,至多是对方针与指引认知有争议。—— Eric Liu 創造は生命(留言留名学生会 2024年6月18日 (二) 17:46 (UTC)[回复]
啊,我忘了提及“非纯破坏行为”的前设。Sanmosa 蚌埠 2024年6月19日 (三) 05:47 (UTC)[回复]
支持@Sanmosa的助言机制,这个方法应该可行。--桐生ここ[讨论] 2024年6月20日 (四) 19:20 (UTC)[回复]
有点怀疑“未涉事的第三方用户”的评判可能出现争议,并可能使部分用户有意避嫌、延后表态(私下抱团沟通)。--YFdyh000留言2024年6月21日 (五) 11:57 (UTC)[回复]
关于“私下抱团沟通”,根据WP:共识,仅建议不应私下讨论维基百科相关的事项,个人建议需更改这段的用词至严禁私下讨论维基百科相关的事项,并配合利益申报 (如该名编辑者曾在外站讨论,则应当“涉事用户”处理并应主动向社群申报),否则的话也没有意思。关于最近私下讨论的例子,就是路西法人的共识议案,完全将跳过了共识形成过程便产生共识,此不合程序公义。如果之后AARV容许私下抱团沟通,那只好反对。
.
维基外的讨论。我们不鼓励编者在其他网站、论坛、聊天工具、电子邮件或其他本专案外的地方讨论。这些讨论在“维基内”决定共识时是不予考虑的,并在它们被揭发后会引发猜疑和不信任情绪。尽管我们需要在维基外讨论少数问题以顾及隐私,但绝大多数维基百科相关的事项都应在维基百科上讨论,这样它们将对所有参与者可见。”--唔好阻住我爱国留言2024年6月21日 (五) 12:40 (UTC)[回复]
我觉得与其在客栈提案(现行写法),不如改置管理员布告板的子布告板(可命名为“管理操作复核”),集中处理涉及高阶权限的使用行为。既有之“其他不当行为”子布告板,则继续留作解决普通使用者争议之处。—— Eric Liu 創造は生命(留言留名学生会 2024年6月24日 (一) 01:09 (UTC)[回复]
(+)支持。--桐生ここ[讨论] 2024年6月29日 (六) 21:17 (UTC)[回复]
诚如书生君所言,本站处理相关问题之场所一向不缺——Wikipedia:管理员布告板/编辑争议Wikipedia:管理员布告板/其他不当行为。所以这个与前列两者分别何在?固然多一人一起讨论如何行使权限,未尝不可。但本站有足够人手么?在下甚是疑惑。本提案立意良善,但欠缺具体系统设计。坦白说,就是怕管理员滥权,但又没有给管理员足够配套。然后,调查事情不一定要管理员权限,所以又有多少人有能力且愿意担起此责?--J.Wong 2024年7月1日 (一) 13:46 (UTC)[回复]
我只是特别羡慕ja有这个;对于解封,en有这个,看起来都是和气的达成了共识,不知道为什么在zh,最后都是客栈吵得不可开交,甚至上RFDA解决。--桐生ここ[讨论] 2024年7月1日 (一) 14:12 (UTC)[回复]
立意就是希望大家多用AARV,最后不用走到RFDA这一步。--桐生ここ[讨论] 2024年7月1日 (一) 14:28 (UTC)[回复]
所以这次有提出过使用吗?有空间容许第三方审核及说话的馀地吗?--J.Wong 2024年7月2日 (二) 05:46 (UTC)[回复]
其实这次事件当中是见到Bluedeck有意愿作出独立调查,但本站社群之中,竟然未见有人愿意伸出援手。
然后就去羡慕这个,羡慕那个……
纵观整个讨论,在下见到大家更关心程序,数够票就下一步,甚少理会双方所言是否在理,能否经得起第三方审核。如果这点不变,开再多讨论空间,阁下都只能继续羡慕。--J.Wong 2024年7月2日 (二) 05:57 (UTC)[回复]

将管理操作复核设置为管理员布告板的子布告板

[编辑]

如题,见上方讨论,将管理操作复核设置为管理员布告板的子布告板,将作为集中处理涉及高阶权限的使用行为。桐生ここ[讨论] 2024年6月29日 (六) 21:23 (UTC)[回复]

或者是直接指定管理员布告板本身也行吧?要评估一下流量。—— Eric Liu 創造は生命(留言留名学生会 2024年6月30日 (日) 04:13 (UTC)[回复]
应该不行,管理员布告板本身没法提供那些AARV的规则。再说管理员布告板本身也没有人会去用,目前貌似只是一个为存在而存在的东西。--桐生ここ[讨论] 2024年6月30日 (日) 07:32 (UTC)[回复]
其实也可说是“制造”用途⋯⋯ —— Eric Liu 創造は生命(留言留名学生会 2024年7月1日 (一) 19:21 (UTC)[回复]