跳转到内容

维基百科讨论:封禁申诉

页面内容不支持其他语言。
本页使用了标题或全文手工转换
维基百科，自由的百科全书

应该建立

[编辑]

此页面应该建立，而且现在互助客栈关于建立此页面的讨论也已经大致通过。—人神之间摆哈龙门阵 2008年11月9日 (日) 09:06 (UTC)[回复]

作为创建者，我也认为应该建立。Alonso McLaren (留言) 2008年11月9日 (日) 09:13 (UTC)[回复]

附議！—汪汪 2008年11月9日 (日) 09:28 (UTC)[回复]

請問人神，甚麼時候大致通過了，我看到的是原來的討論無疾而終罷了。要是先斬后奏，建立了之后再談合理性的話，這和搶建條目有甚麼不同？我不是說這個頁面不應建立，而是要有決議要建立時才建立。—唐吉訶德的劍(風車之戰)十步殺一人 2008年11月9日 (日) 09:30 (UTC)[回复]
这个页面的名称容易引起误会，因为没有说明是针对封禁的申诉，维基百科另有未翻译完成的Wikipedia:封禁申诉，但其内容是英文维基中遇到错误封禁后如何申诉的指引。—Ben.MQЖ留言Ж 2008年11月9日 (日) 09:41 (UTC)[回复]
是否可以发起一个投票，以确定是否建立条目，然后进行编辑工作，或者使用某个/temp页面编辑出一个大概的样子，然后投票？—Ben.MQЖ留言Ж 2008年11月9日 (日) 09:43 (UTC)[回复]
从理论上，建立一个条目是不需要投票的，只要使它成为相关方针或者指引才需要。不过对于此条目，鉴于已经有了Wikipedia:封禁申诉，我觉得应该删除，但是至少不能速删，因为不符合速删的标准。—人神之间摆哈龙门阵 2008年11月9日 (日) 10:12 (UTC)[回复]
根据Wikipedia:修改和创建方针，先行创建条目是合理的。在下以为，在翻译本条目目前对错误封禁的申诉内容后，加入针对因破坏/傀儡/攻击/用户名等等理由被封禁的申诉方式，然后指引被封用户使用其子页面Wikipedia:封禁申诉/申诉提出请求。最后交由社群确立其为方针指引—Ben.MQЖ留言Ж 2008年11月9日 (日) 10:10 (UTC)[回复]
先把英文翻译过来，有个底子，也可以让我们在英文版的基础上讨论修改，便于节约人力和时间。—菲菇＠维基食用菌协会 2008年11月9日 (日) 10:26 (UTC)[回复]

投票

[编辑]

申诉问题至关重要.翻译完成后就进行投票.不能再拖下去了Alonso McLaren (留言) 2008年11月11日 (二) 01:54 (UTC)[回复]

强烈要求建立申诉制度

[编辑]

本主題或以下段落文字，移動自Wikipedia:互助客栈/方针。

很多人被封禁后无法辩驳。应该给他们一个机会，为此我创建了Wikipedia:申诉 希望改革政策，允许被封用户在Wikipedia:申诉上进行申诉，这样就不需要使用傀儡了。Alonso McLaren (留言) 2008年11月9日 (日) 08:53 (UTC)[回复]

我也希望這樣，但是目前還沒有共識要建立這樣一個制度的時候，你是不應該建立Wikipedia:申诉的。—唐吉訶德的劍(風車之戰)十步殺一人 2008年11月9日 (日) 09:00 (UTC)[回复]
要取得這種共識，應該不難吧，一直聽見有人提，另外還有誰是在具體行動的么？沒人去推動這個事情，永遠不會有任何進展—我是火星の石榴 (留言) 2008年11月10日 (一) 06:32 (UTC)[回复]
在下刚刚准备着手翻译Wikipedia:封禁申诉中残留的英文部分，但是发现里面的内容有很强的地区性，而且在中文维基找不到Autoblock的相关内容，所以不敢贸然动手了……希望有对封禁系统和工作原理比较熟悉的老用户伸出援手……—Ben.MQЖ留言Ж 2008年11月10日 (一) 07:34 (UTC)。[回复]
自动封禁就是当一个注册用户被封禁后，他最近所使用的IP地址亦会被隐匿性地（即在日志中不显示出IP地址，只显示出系统给的编号）封禁1天。在这一天内，使用被封禁IP地址编辑维基百科的非管理员及以上权限的注册用户均会被禁止编辑。—菲菇＠维基食用菌协会 2008年11月10日 (一) 09:13 (UTC)[回复]


真的應該要ㄧ個完善的申訴制度。維基要成為百科還有很大的進步空間。--Outlook8.1（留言） 2014年12月11日 (四) 13
54 (UTC)

非管理员处理封禁申诉

[编辑]

本主題或以下段落文字，移動自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2017年7月29日 (六) 08:42 (UTC)。[回复]

例如User:B dash的这一笔编辑，处理了一个封禁期已过的封禁申诉。然而封禁申诉模板上写有“管理员已对此封禁决定作出复检，并有以下结论：”，会否导致误解？例如误以为处理人是管理员？

进一步讲，是否允许非管理员用户根据方针拒绝封禁申诉？（接受申诉肯定不行，没法调整封禁设置）--Tiger（留言） 2017年7月18日 (二) 09:02 (UTC)[回复]

显然的不应该吧，User:B dash有些太自作主张吧。——路过围观的Sakamotosan 2017年7月18日 (二) 09:47 (UTC)[回复]
这不算拒绝吧...人家只是标记此封禁已到期而已。不过这里偏个题，现在到底有什么事情是必须管理员（或者更高权限持有人）才可以处理呢？有一些的东西个人认为没必要非在管理员名下才可以进行，比如关闭（存废）讨论、投票完毕的结果公布、查核结案之类的。-- Stang 2017年7月18日 (二) 12:39 (UTC)[回复]
确实有一些可以不用管理员处理，WP:合并请求目前正是这种状态。但有一些东西可能没那么简单。比如自行结CU（这位用户也做过），就可能导致查核员还没看到就被自动存档了。封禁申诉也类似，一旦被处理，就不会出现在Category:封禁申诉里，也没有记录显示处理人。我注意到Simon君的封禁申诉被处理还是因为之前看到了，后来消失，从我自己的贡献记录进入讨论页，才看到结果。--Tiger（留言） 2017年7月18日 (二) 13:23 (UTC)[回复]
我原先觉得这样没什么问题，但是Tiger的论述很有道理，这样的域应该保留由管理员处理为好。Bluedeck 刘晓波 2017年7月19日 (三) 01:33 (UTC)[回复]
別搶管理員的工作。--小躍（撈出記錄） 2017年7月19日 (三) 05:39 (UTC)[回复]

有关 unblock-zh 邮件列表可能潜在的“黑箱”制度

[编辑]

本主題或以下段落文字，移動自Wikipedia:互助客栈/其他。执行者：Jimmy-bot（留言） 2017年10月22日 (日) 08:42 (UTC)。[回复]

诸位好。近来有几名维基新手加入 QQ 群，抱怨自己发送给 unblock-zh 邮件列表申请 IPBE 的邮件迟迟得不到回复。我用新手发送给 unblock 的邮箱反查邮件，发现这些新手的邮件并没有投递到订阅 unblock-zh 的各个管理员手上，遂对 unblock-zh 的收发信策略做了一些测试，发现如下状况：

  • 会丢弃邮件中的 HTML 部分，只留 plain text（纯文本）。目前邮件客户端普遍会同时发送相同内容的 HTML 和 plain text；部分客户端只会发送 plain text；但有一部分客户端只发送 HTML 排版过后的邮件。（当然这也视乎用户自己的设置。）对于部分只有 HTML 的邮件，在经过 unblock-zh 转发后，邮件就会如这里所示，全篇邮件一个文字都没有。这一设置在 unblock-zh 后台是可调的，但普通管理员没有权限。除非遇到下条所示情况：
  • 对于字符编码不是 UTF-8 的邮件，会把能转换成 UTF-8 的邮件全部转成 UTF-8。有些有些编码能正常处理，但有些不能。对于能处理的，其到达收件箱后效果如下：
但是无法处理的，其方式如下：
对于不能处理的编码，unblock-zh 在转发时全文保留了原来的 plain text 内容，并在后面加上了自己使用 UTF-8 编码的提示。
但是，使用这种方式同样可以接收 HTML 邮件。比如在其他邮件列表里有这样的例子：
上面的这种方式显然更加适合 unblock 的需求。原先的 HTML 格式被完整地保留了下来，即使 unblock-zh 无法处理此类字符编码，也可以发送到每个邮箱后手动解决乱码问题。
维基媒体计划上所有的邮件列表是基于一个叫 mailman 的程序，包括 unblock-zh 。其他的邮件列表可以做到，unblock-zh 也可以。
  • 有些邮箱是自带坑的。比如上面 #2 中，unblock-zh 没有把所有邮件内容转成 UTF-8 的原因不是因为不支持原邮件使用的 GB 2312 ，而是因为原来邮件用的实际上不是 GB 2312 ，而是 GBK 或 GB 18030，但是发信客户端非得把 charset 那一项写成 GB 2312，mailman 无法解码内容，只得原文保留。#2 的邮件是使用 Outlook/Live/Hotmail 的网页版客户端发出去的。通常的客户端都能正常读取，但并不见得所有的都能读出来。

当然，上面的内容还只是我自己的猜测。我不敢保证自己的叙述和推断全部正确，因为我自己也看不到 unblock-zh 的设置到底是什么。这也正是我开这一讨论想要说明的：现在 unblock-zh 的体系有严重的漏洞。unblock-zh 的管理员不同于维基百科站内的管理员、邮件进入 unblock-zh 需要经过少数几人的审批，这使得 unblock-zh 存在内部黑箱的情况成为可能。——我指出 unblock-zh 存在漏洞，但我没说过有人一定利用过这个漏洞。下面逐条详叙：

  • unblock-zh 是一个邮件列表。邮件列表是早期互联网中网民进行讨论的重要工具之一，但随时间流逝，邮件列表的重要性大不如前。在通常的邮件列表中，订阅该列表的成员使用通过回复他人邮件的方式来进行类似论坛跟帖式的交流。邮件列表的服务器会将所有发送到该邮箱的邮件转发给所有订阅了该列表的成员。邮件列表对于维基百科意义重大。Shizhao 等早期管理员不是通过社群讨论，而是利用邮件列表讨论成为管理员的。
    • 用 unblock-zh 举例子。所有中文维基百科上的管理员“订阅”了该列表。所有发送给 unblock-zh - at - lists.wikimedia.org 这个邮箱的邮件都会被转发给该邮件列表所有的成员，也就是中文维基百科的所有管理员。外面的人若要进行封禁申诉，直接发送邮件到该邮箱里，所有的管理员理论上都能收到一份该邮件的拷贝。在其中一个管理员回复申诉请求后，会抄送一份到 unblock-zh 。抄送的邮件也会被转发给所有成员。这样，当成员（也就是管理员）看到了抄送过来的回复后，就知道该请求已经有人回复了。如果管理员之间需要讨论封禁事宜，管理员也可以直接发送邮件到 unblock-zh ，其他管理员也都能看到。其他的管理员若是想要就该封禁案发表观点，直接回复该邮件，并把回复的邮件发送到 unblock-zh 中，所有其他管理员也会收到由 unblock-zh 邮件列表转发来的回复。
    • unblock 不能算是“用于讨论问题的邮件列表”。对于讨论问题的邮件列表，通常只有该列表的订阅者才会向邮件列表中发送邮件来商讨事宜。但是 unblock-zh 每天都要接收大量邮件列表外的邮箱发送过来的请求。因此，为了提升讨论质量，部分邮件列表会通过限制订阅、限制只允许订阅者发送邮件、所有外来邮件都需要经过列表管理员审批，审批通过后才会转发给所有订阅者的形式来控制讨论质量。论坛可以删除帖子，但邮件送达后没有撤回的余地。因此很多邮件列表都很注重其中邮件的质量。让邮件仅以 plain text 发送、限制 HTML 元素使用也是通常邮件列表为保证讨论质量会开启的设置项。但是，unblock-zh 某种意义上作为中国大陆新手参与维基百科的必经之路，却因为上面提到的诸多限制，导致相当一部分新手的申诉邮件无法正常收取。
  • 众所周知，unblock 是允许所有管理员成员加入、获取内容的。管理员不应该泄露其中的申诉请求。但是同样地，凡是有意向进行封禁申诉的邮件，都应该投递给所有订阅了 unblock 的管理员。然而，目前 unblock 仍然在预先审查邮件，只有审查通过的才会发送给所有管理员。前面提到了，通常邮件列表审查邮件是出于为了把关内容的考虑，unblock-zh 审查邮件，依 Kegns 的说法，是为了减少垃圾邮件 。但是，就目前可知的情况来看，unblock-zh 所有具有审查邮件权限的人，只有 Jimmy Xu、Kegns、Mys 721tx 三人。无论审查者是谁，只要人数有限、没有公开征求他人意见，客观上就存在黑箱操作的可能。最重要的不是现在审查邮件的这三位是否正在（或者曾经）黑箱操作，而是大多数管理员没有这方面的意识，根本没有意识到自己在 unblock 里看到的邮件可能有故意或者无意漏掉的、甚至故意删掉的。
    • 另一方面，就是垃圾邮件存在误判的可能。在 QQ 上跟我联系的一个新手在邮件发送三天后都没有回应。用其邮箱、邮件标题等信息去翻存档，发现根本没有收到这封邮件。当时我直接给他批复了 IPBE ，并开始调查此事。但次日，他的邮件就收到了。可能是某名列表管理员最开始误判了这封邮件，后来其他人复核后发现有一封邮件被误作垃圾邮件，于是重新放行，这才导致了延后四天收到邮件的情况。
    • 最后，就是对真正的 spam 和滥用申诉者反映可能不即时。尽管滥用 unblock 发邮件的行为非常少见，但不是没有发生过。这时候就只能让唯一能修改设置、屏蔽 spammer 的成员，也就是 Jimmy Xu 出面屏蔽。
  • 尽管 Jimmy Xu 在一封 2014 年的邮件里面说“欢迎其他有意向参与者联系”（大意），但实际上新上任的管理员甚少了解此事，更不要说主动参与邮件审查事务了。

总结一下：由于技术原因导致部分新手邮件进入 unblock 困难、耽误新手参与维基；unblock 现在邮件审查机制不透明、人手不足，进一步导致新手和其他申诉邮件延误；目前管理员普遍缺乏对 unblock-zh 以及其他邮件列表的认识，unblock-zh 的“上层”管理者架构不透明、缺乏监督。

所以，我们要做什么？首先，私以为所有社群成员都有权利知道这一点——每个人都有可能遭受管理员的不当封禁，unblock-zh 作为封禁申诉渠道，保证其透明是有必要的；其次，我们要改进 unblock-zh 的后台设置——不一定全部照上面说的改，但一定要保证比现在更友好；最后，有关列表管理员和具有审核权限者，也需要在社群公开化，保证人手充足、不会有邮件因为审核者个人原因而被延误甚至拒绝。

望诸位发表意见。

--Techyan（留言） 2017年8月16日 (三) 14:14 (UTC)[回复]

（纯属抛砖引玉啦）改成全开放的ticket系统，所有出入信息全透明。实现方法有很多，其中之一：在GitHub上开一个项目，然后滥用github的issue系统来处理我们的查封。对于隐私资料，则仍然寄给unblock，或者直接寄给管理员邮箱。头脑风暴建议，没有细想。Bluedeck 2017年8月16日 (三) 19:31 (UTC)[回复]
我的建议：1.如果编码问题导致mailman接收出错的话，应该想mailman反映或者调整配置来修正。2.对于申请LIPE或新账号的，可以考虑使用新的邮件列表处理，将配置调松以方便接收不合规格的邮件，或者OTRS也可？3.管理员应该要加入unblock-zh，而且强调或教育如何使用（需要弄一份邮件列表使用手册）。——路过围观的Sakamotosan 2017年8月17日 (四) 02:39 (UTC)[回复]
（可能有问题）4.进入unblock-zh的邮件先进入一个队列，所有op都能分拣但不能删除。在区分是垃圾邮件后所有“垃圾邮件组”，可以被删除和不用转发，是正常邮件则放入另一队列，可以转发。不过删除应该有记录并可恢复，以防误删或故意删。以此减少审核人员过少而导致可能的暗中操作问题。——路过围观的Sakamotosan 2017年8月17日 (四) 02:43 (UTC)[回复]
如果使用OTRS系統，那就必須要所有管理員都是OTRS志工，但目前申請OTRS志工與申請管理員的管道不一樣，而且目前OTRS沒看到有規定管理員必定為OTRS志工。臺灣杉在此發言 (會客室) 2017年8月17日 (四) 08:15 (UTC)[回复]
OTRS也是一套系统，只是OTRS直接沿用软件名作为该工作组的称呼，例如以前bugzilla，我的意思是使用OTRS系统在建立一个基于mail-ticket的unblock组。——路过围观的Sakamotosan 2017年8月18日 (五) 08:37 (UTC)[回复]
英文版是仿效OTRS弄了個UTRS。--Temp3600（留言） 2017年8月17日 (四) 17:51 (UTC)[回复]
全透明的最大问题是会有人恶意扰乱（例如骂人，泄露隐私等），这些东西一旦被搜索引擎索引会有不好的影响。当然可以设置成不索引，但是另外建立一套全透明的系统并不比完全使用用户讨论页申诉好（想想为什么要剥夺用户的用户讨论页编辑权限）。另外我们完全可以fork一个英文版的UTRS，但是好不好用不好说。--GZWDer（留言） 2017年8月18日 (五) 20:36 (UTC)[回复]
我覺得改良mail-list會是比較簡單的做法。UTRS要請人寫代碼才行﹐不知要弄得何年何月。--Temp3600（留言） 2017年8月21日 (一) 14:56 (UTC)[回复]
哈哈哈哈，我开玩笑的而已，不会真的搞到2049年去。Bluedeck 🤔 2017年8月21日 (一) 19:47 (UTC)[回复]

对于互联网上的“gb2312”混杂gbk、gb18030不能解码，按照WHATWG/W3C的《编码》（技术建议；TR）应该算是bug了。《编码》里面说得很明确，gb2312、gbk、gb18030一律用一个gb18030和gbk并集的解码器理解。——Artoria2e5编 讨论要完整，回覆请用ping。 2017年8月23日 (三) 00:55 (UTC)[回复]

phab:T173894. 剩下那个 HTML 问题请改设置。--Artoria2e5编 讨论要完整，回覆请用ping。 2017年8月23日 (三) 01:12 (UTC)[回复]

“Dark Hoel！Terrible！”--113.97.43.185（留言） 2017年8月29日 (二) 06:41 (UTC)[回复]

認同應對unblock-zh機制進行檢討。unblock-zh已是實施8年多的申訴機制，現在是合適時機去處理解決當中之缺陷。如郵件審批可能會因審核員不足而延宕，造成封禁申訴無法及時處理。--千村狐兔（留言） 2017年8月30日 (三) 09:23 (UTC)[回复]

有关 Jimmy Xu 对 unblock-zh、IRC 的管控权独揽问题

[编辑]

在与其他一些管理员通过站外渠道沟通交流后，我得知 Jimmy Xu 目前拥有中文维基百科 unblock-zh 邮件列表和 Freenode 上名为 #wikipedia-zh 的 IRC 频道的最高管控权。考虑到上面只介绍了 unblock 存在的问题，没有提到 IRC ，下面再对 IRC 存在的问题作一些介绍：

IRC 群组里的权限共有三级。最高级者，可以踢出、禁言其他 IRC 频道里的成员。但是，能够赋予其他用户高级权限的权限，在 #wikipedia-zh 上却只有 Jimmy Xu 一人拥有。这不是什么大事，因为中文维基站内的所有管理员都拥有操控一个能够踢人、禁言的机器人的权限，一旦有人扰乱，可以直接通过操纵机器人来进行维护操作，管理员通常不需要更高的权限。但由 Jimmy 一人独揽权限的情况仍然客观存在，且据一名维基人的说法，Jimmy 曾有意地不给他人更高权限。考虑到 Jimmy Xu 最近并不活跃，若是 IRC 频道出现一些意料外的状况，处理起来将非常耗时。因此 IRC 的问题与 unblock 一并在此提出。

至于 unblock 邮件列表，在我上面这段论述写完之后又出了一些新的状况：因为三名审核员都没有即时审核、放行邮件，导致 unblock 中邮件曾出现至少五天的断流，期间所有申请 IPBE 的新手、封禁申诉等都在极端情况下等了五天才送达——而目前有数名管理员活跃在 unblock 上，一旦邮件送到了各个管理员手中，往往只需要数小时就能答复，时间全部浪费在了审核员上。

Jimmy Xu 作为中文维基曾经非常活跃的技术管理员，如今已经不甚活跃，他独揽中文维基两大系统的最高权限，并在需要做出改进时不愿动作。Jimmy Xu 没有对上文在下的指控做出回应，在下已于 Jimmy 的用户讨论页做出通知，希望 Jimmy 出面解决目前存在的问题。对于 unblock ，在下拟邀请数名最近比较活跃的管理员作为审核员（或考虑无审核员实行一段时间）；同时请 Jimmy 按照上面的提示进行设置调整，或指明不进行调整的理由；另请另一名维基人兼任 unblock-zh 的管理员。对于 IRC ，则请 Jimmy 给有意者授予相关权限。

--Techyan（留言） 2017年9月6日 (三) 13:26 (UTC)[回复]

Unblock-zh的問題比較嚴重，亦確實希望可以引入更多管理人員，令封禁申訴電郵可以更快速到達各管理員電郵。至於IRC，據系統回報，目前共有三個群主，除了Jimmy，還有Ben.MQ及Liangent。兩人均擁有群主權限。不過兩人亦是近來都不甚活躍。這個可以再與Jimmy討論。--J.Wong 2017年9月6日 (三) 13:50 (UTC)[回复]
真凶啊，又是在对历史遗留问题不求甚解自己揣测。本来哪位想审信找我要一下密码就行了，技术问题也没什么不能解决的。你倒好，也不来对话页也不找-owner，非要费劲写这么多来“指控”还不通知本人？邮件列表一直都欢迎比Techyan更懂协作的管理员参与管理。--Jimmy Xu 论 2017年9月6日 (三) 14:52 (UTC)[回复]
啧啧啧，态度好差，有则改之无则加勉。人家提个意见你懂你就回答好来。人家写的问题也是很客观的，你还要讽刺人家不懂。要么弄个考试，你跟他一起考试？不要这样，有耐心就回答，没耐心就不要干了，把自己耗在那里有什么意思来。--SP RailwayGuest 2017年9月11日 (一) 10:41 (UTC)[回复]
(！)意見：我认为Jimmy Xu阁下不宜继续独揽权限。去年我当选管理员之后不久的一段时间，Jimmy Xu阁下就一直在irc对我“训政”，而我惧怕他是群主，如果为逆他会被踢走，就常常只能顺从他的意志处理站务。当时作为新管理员，我感到很困扰。门可罗雀的霧島診所欢迎光临维基Q群：170258339神社的羽毛飘啊飘 2017年9月7日 (四) 01:30 (UTC)[回复]
关于IRC，从未出过什么问题，折腾它干嘛--百無一用是書生 (☎) 2017年9月7日 (四) 01:33 (UTC)[回复]
@霧島聖：都管理员了还怕踢走。。。。怎么感觉和新手用户一样啊--百無一用是書生 (☎) 2017年9月7日 (四) 01:35 (UTC)[回复]
当时在irc的确还算是半个新人没错。门可罗雀的霧島診所欢迎光临维基Q群：170258339神社的羽毛飘啊飘 2017年9月11日 (一) 10:11 (UTC)[回复]
“伟”光正的时昭陛下，您对irc一窍不通，所以就别在这里乱讲了，即使是维基百科管理员，irc群主一样能踢。建议时昭陛下继续专攻您的滥权大业，切记说多错多，伤害您“伟”光正的巨人（mo）形象。黑暗雄鹰·给我留言·请关注管理人员和资深用户的人身攻击行为 2017年9月7日 (四) 01:49 (UTC)[回复]
(！)意見：请理解管理员也是人，管理员也不可能什么都知道，有问题，完全可以友好的指出，我相信一般维基人都能够正确的对待问题，请保持善意，这样的讽刺对于解决问题并没有帮助。--人神之间摆哈龙门阵 2017年9月11日 (一) 03:54 (UTC)[回复]
(！)意見：制度有問題就談制度，人手有不足就談人手，而不應該是借題發揮攻擊管理員濫權。--Mewaqua（留言） 2017年9月7日 (四) 02:54 (UTC)[回复]
能踢就能踢呗（我当然知道能踢），不做错事为何要怕被踢？--百無一用是書生 (☎) 2017年9月7日 (四) 03:13 (UTC)[回复]
Jimmy Xu口中“更懂协作的管理员”，事实上似乎完全不能领会最基本的维基方针，哎。。。 上海灘維基悍將  守望者傳奇  2017年9月10日 (日) 11:42 (UTC)[回复]
希望阁下也能就事论事，大家一起建设好维基才是正道啊。--人神之间摆哈龙门阵 2017年9月11日 (一) 04:27 (UTC)[回复]
“大家一起建设好维基才是正道啊”，人神之间竟然对爱孟说了这么一句话，呵呵呵呵，大家来看看哦，黄鼠狼给鸡拜年了！113.116.171.81（留言） 2017年9月11日 (一) 07:16 (UTC)[回复]
那位什么人神之间啊。Jimmyxu讽刺别人不懂的时候，你也回应一个呀。你表面的公平好歹也要做一做。否则你就不要起劲说别人不就事论事了。我觉得Jimmyxu这种不积极参与社群服务的行为，是应该要有其他人参与进来，否则站务都要停顿了。我们不是为了证明某个人很重要，才设立这个unblock的机制的，然后就放一个管理员在那里。还是开放的好，怕什么，多加两个人天塌不了。--SP RailwayGuest 2017年9月11日 (一) 10:53 (UTC)[回复]
请参考我下面说的，我同意加更多的人，乃至不需要审查。另外，大多数的参与是根本无需谁批准的，同样如我下面所说，请呼吁其他管理员积极参与回应unblock。--人神之间摆哈龙门阵 2017年9月11日 (一) 18:01 (UTC)[回复]
人神之间，您忘了我是谁了？ （打个比方而已，请勿以后面那句话再给别人扣“人参公鸡”之罪名，谢谢！）好比说：杀人犯看到被害人可以装不认得了？ 上海灘維基悍將  守望者傳奇  2017年9月12日 (二) 15:34 (UTC)[回复]
如果你都知道比喻不恰当或会被误会，就请不要做出类似的比喻。作为一个维基人，我在维基上的留言是基于其他人留言的内容，而和那句话是谁说得没有关系。我相信很多维基人都是这样做的，我也希望阁下也能做到如此。--人神之间摆哈龙门阵 2017年9月12日 (二) 23:15 (UTC)[回复]
如果现在人神之间的账号是本人操纵，那么显然前方的比喻是合理的；如果该账号已经不在本人手里，那么现在的表现不出意外。 上海灘維基悍將  守望者傳奇  2017年9月13日 (三) 11:50 (UTC)[回复]

先談unblock-zh：我沒搞過mailman，當然也沒權限存取unblock-zh。不過從上面的論述可以看出一點：unblock-zh的控制者，或者說維護者，他們現在並不活躍，無法及時受理郵件，也不能及時解決技術故障。再概括一點就是人手的問題（其他問題主要還是由人手問題衍生出來的）。

最近一年內，社群已經有數位能夠保持活躍、已經或者有能力掌握相關技術的管理員，例如User:WhitePhosphorus、User:Alexander Misel、User:Techyan、User:A2093064、User:Bluedeck等，因此是時候解決問題了。我建議從以下兩方面來解決問題：

  1. 開放unblock-zh的技術控制權限，使這些熟悉技術的管理員能夠及時調整設定，修正技術層面的問題。同時也可以預防和及時應對其他技術故障。
  2. 不再實行審核制度，或者推選數位（至少是unblock-zh上活躍管理員數量的一半吧，我覺得）值得信任的管理員作為審核員，以防信件積壓。

這樣的話就不會因為Jimmy Xu或其他人在現實生活很忙而無法及時處理維基的事情了。

unblock-zh是中文維基重要的工具之一，我們不能讓它因為無人及時處理故障而癱瘓，所以自己太忙的話多派一些維護者就行了，而且只會有好處不會有壞處。雖然我們完全可以做新系統，但是從目前情況來看這樣做並不現實。如果能把技術型管理員派進去進行修理，使得unblock-zh的技術問題能夠得以修正，我們何苦重新造輪子呢？ --逆襲的天邪鬼（留言） 2017年9月7日 (四) 04:03 (UTC)[回复]

近大半年來都在IRC掛機，或者容我說兩句吧。首先，在下不知霧島君所經歷的是什麼情況，不過現時IRC社群已經通過WP:IRCPOL，縱然有人可能不承認，但至少大半年來都沒發生過什麼Jimmy君獨攪大權，恣意妄為之事，因為正如在下上面所言，IRC群尚有另外兩位群主及社群相當活躍。基本上，現在在下作為IRC OP，亦隨時可以把其他群管踢走，不用等Jimmy君出手。但無原無故誰會去動手踢人？別說得好像昨日剛踢完一個群管似的。現在唯一困難之處，大概是因為三位事務繁忙，未能及時為新當選管理員授予群管地位。就此，在下建議把群主權力授予User:WhitePhosphorus等常駐可信用戶。在下相信此舉足可解決IRC問題。--J.Wong 2017年9月7日 (四) 06:12 (UTC)[回复]

事情在客棧掛這麼些天，有沒有進展了？反正，假如我是unblock維護者，一方面我肯定不打算讓事情有機會在客棧上面出現，另一方面，即使真的上了客棧，看到之後也該有所動作，不給你們在客棧評論的機會。--逆襲的天邪鬼（留言） 2017年9月11日 (一) 03:13 (UTC)[回复]
请善意推定，管理员只是拥有系统权限的维基人，并不是和普通维基人对立的关系（尽管我知道有些事情可能导致了这样的看法），但我还是希望大家能够善意推定，就事论事。--人神之间摆哈龙门阵 2017年9月11日 (一) 03:54 (UTC)[回复]
人神之间：“我们要善意推定！”；永康师傅：“要建设民主法治！”；才厚将军：“要坚持反腐强军！”，既视感啊既视感，XD。。。113.116.171.81（留言） 2017年9月11日 (一) 09:04 (UTC)[回复]
  • 我不常在IRC，但是对于unblock-zh我可以发表一些个人意见。我去年下半年一直在处理日常unblock-zh的请求，尽量保证在收到请求的1-2天内处理，具处理详情可以见我的贡献记录。去年底也在参加北美维基会议的时候见到了JimmyXu本人，并当面讨论了关于unblock-cn的情况。会议后一直太忙，未向社群反馈此事，这可以算是我的一点疏忽。正好趁此机会向大家汇报一下：
我觉得这个问题没什么恶意，就是质询一下。难道做的好不好还不让人评论了？和平解决是什么意思，就是大家睁只眼闭只眼咯？装睡？--SP RailwayGuest 2017年9月11日 (一) 12:25 (UTC)[回复]
很简单，提出解决方案（加人手或者做调整），at人过来问是否还存在技术原因。非要用点煽动的字眼，好像嫌事不够大的样子，我觉得这就不太好了。——路过围观的Sakamotosan 2017年9月11日 (一) 12:44 (UTC)[回复]
用的词，那是语言艺术的问题。事情大了么？怕什么？人家也是想让社群注意到事情的重要性，出发点是好的。要让人说话，不要都做拍手党。要拍手谁不会啊，如果心理素质差，不想被质询，没有被质询的觉悟，那我觉得还是做个普通编辑好了。那就没人来质询你，那多舒坦。这里是客栈，是提出问题的地方，不是开表彰大会的地方。人家才提了那么点点意见，你怎么就急眼了。别急，又没说你，着什么急。--SP RailwayGuest 2017年9月11日 (一) 12:51 (UTC)[回复]
(＆)建議用词的问题的确是语言艺术的问题，但是我建议提议需要对事不对人。比如这件事情，可以说是现在unblock-zh可能缺乏一个开放的审核机制，这个我严重同意。但是推到JimmyXu独断专权上我个人觉得不太合适。如果有人事先和他讨论过，而他拒绝交流，这样描述也还行，问题是之前并没有人直接和JimmyXu讨论这个问题。很多问题人手不够是客观存在的，而之前很多工作集中于一两个人，并不是他们愿意独断专权，而是人手不够的直接后果，希望大家能够理解这一点。更多的管理员愿意加入维护是一个好事情，我个人非常赞成！--人神之间摆哈龙门阵 2017年9月11日 (一) 18:29 (UTC)[回复]
用词当然很重要，就是有些人喜欢挑用词问题来发难的。本来可以不用说重口气，非要加多几程重。——路过围观的Sakamotosan 2017年9月12日 (二) 00:55 (UTC)[回复]
所以啊，汉语言一定要学好。这是我们的母语，我们有这个责任和义务，把语言学习给搞上去。孔子有云：“不学诗，无以言”，那就证明了语言的重要性。现在的很多人就是觉得语文么，都会说的，不需要认真学，所以说的话往往词不达意。楼上这个问题讲的很好，对于大家都起到了督促的作用。--SP RailwayGuest 2017年9月12日 (二) 15:25 (UTC)[回复]
(：)回應人神之间：有人提出Jimmyxu独断专权的事情，本质上还是爱护他的，指出问题，对不对的话可以讨论嘛，先提出来。你看这样一讨论不是效果很好嘛。顺带把语言问题也搞明白了。大家爱护关心Jimmyxu的发展，那才会提这些意见。用《私人订制》里的那句话，“越是经常批评您的领导才是真正爱护你的。不跟你拍桌子了，对你客气了，也就不拿你当自己人了。现在谁跟谁随便交心呐”。--SP RailwayGuest 2017年9月12日 (二) 15:33 (UTC)[回复]
(：)回應如果是出于爱护，我表示感谢，但是我建议下次用一个更好的方法，比如先和对方直接交流，如果无效，再这样说也来得及。其次，我也很高兴能把语言问题搞明白了，希望以后大家都能用很合适的语言来处理类似事件，这样也有助于大家能更好的为维基百科做出贡献。最后，如何和人交流是一个动态的，我不认为一个方法就能包治百病，但至少我相信在维基里，保持善意肯定是最基本的需求。--人神之间摆哈龙门阵 2017年9月12日 (二) 23:22 (UTC)[回复]
不对呀，爱护的是Jimmyxu怎么你来感谢了，太客气了，不用谢啊。方法有好有坏，最重要么就是能不能说清楚问题，再客气方法再好，说不清楚问题总归也是不行的。语言问题是个漫长的过程，用词的准确需要慢慢的磨练出来，不能急于一时。自古像苏学士、欧阳文忠公都是日积月累才写出了振聋发聩的文章。像贾岛，更是为了僧推还是僧敲月下门纠结了半天，甚至撞上了韩愈的坐骑。所以说，语言的矛盾将持续并且长期持续在维基里，大家都要有耐心。当然，语言问题中不能包含骂人这个成分，这已经超出了语言用词的问题了。是关乎个人修养和家庭教育的因素了，反映了一个人的世界观、人生观和价值观。在对于语言问题大容忍的情况下，我们对于骂人还是要零容忍。尤其是管理员更不能骂人，否则给外人感觉维基编辑的素质都不高了，这样不好，百弊而无一利。最后，大家都是善意的，没有恶意啊，就是说话难听点，但是心都是好的。最后还是希望大家逐渐提高文学水平，毕竟汉语是我们的母语，语言工作还是很重要的。--SP RailwayGuest 2017年9月14日 (四) 00:46 (UTC)[回复]
完全同意阁下一个观点，对于骂人还是要零容忍的，特别是在没有交流的情况下无端的对其它维基人扣帽子这种行为，个人觉得在维基百科上还是越少越好。--人神之间摆哈龙门阵 2017年9月15日 (五) 06:15 (UTC)[回复]
那你的手下烏拉跨氪他們罵人罵了那麼多次，每一次罵人都很嚴重，你不照樣視而不見了嘛。 上海灘維基悍將  守望者傳奇  2017年9月15日 (五) 14:09 (UTC)[回复]
被轉移至此的218.19.207.157於2017年9月13日 (三) 11:07 (UTC)的留言是回應User:守望者愛孟於2017年9月12日 (二) 15:19 (UTC)的留言。--Mewaqua（留言） 2017年9月13日 (三) 13:26 (UTC)[回复]
谢谢Mewaqua发现的及时，否则其它维基人就看不到这一段被某人删除的留言了。--人神之间摆哈龙门阵 2017年9月13日 (三) 22:48 (UTC)[回复]
“人神之间”账号露出了很多明显破绽，因为该账号不知道人神之间和我在过去的大量通信往来。我已经知道是谁在背后控制了，可以了。 上海灘維基悍將  守望者傳奇  2017年9月14日 (四) 11:12 (UTC)[回复]
如果不和你争论便是不知道过往以及有破绽的话，我也只能呵呵了，这种推理谁也只能甘拜下风。既然阁下已经解封，就多做点贡献，少参加这种无谓的争论，更不要随意的删除其他维基人的留言。--人神之间摆哈龙门阵 2017年9月15日 (五) 06:15 (UTC)[回复]
更不要随意的删除其他维基人的留言[來源請求]，被我看破了所以著急上頭了？你叫別人“少參加這種無謂的爭議”，那你自己現在和我對話是在幹嘛？我說你也是怪可憐的，堂堂一個管理員，非要借別人的賬號來參加討論。你加入維基也已經快十年了吧，人家十年磨一劍，你怎麼十年了還是毫無改變呢？十年前就不屑承認自己的身份（home town），非要假裝自己是某個東部大城市的人，到今天也不敢堂堂正正用自己的賬號來討論，非要借個馬甲。你的姓氏说明了你的祖先是很霸气很有地位的，希望你不要数典忘祖。行了，我和你繼續廢話真是多餘，我寫條目去了，拜拜，希望你好自為之。 上海灘維基悍將  守望者傳奇  2017年9月15日 (五) 14:09 (UTC)[回复]
哎...你要怎么想我也改变不了，只是还好你的想法并不能改变事实。不争论最好，你能专心写条目更好的，拜拜。--人神之间摆哈龙门阵 2017年9月15日 (五) 16:18 (UTC)[回复]
反正呢，我记得两年前的时候，人神之间这个账户传闻被盗号，然后从头到尾，人神之间都没出现，都是AddisWang一手搞的，如果人神之间不玩了，把账户给了AddisWang，然后再折腾也不是不可能的。爱孟你要拿出点干货来才行啊。黑暗雄鹰·给我留言·请关注管理人员和资深用户的人身攻击行为 2017年9月22日 (五) 05:26 (UTC)[回复]

我觉得这次发起讨论的几位是出于社群较为长远的发展考量，是很好的一个议案，请各位回归讨论正题：如何解决“目前Jimmy Xu对Unblock和Irc管控的权限独揽”的问题，撕别的话题没意义。谢谢合作。实在想撕请到横线上面去撕，横线下面请讨论正题。如发现继续撕其他关联不大的事情，丑话说在前头：恕无礼，我将把关联不大的其他内容移动到横线上面。 上海灘維基悍將  守望者傳奇  2017年9月11日 (一) 15:30 (UTC)[回复]

  • 赞成横线下不讨论与这个提议无关的内容，理论上整个互助客栈都不应该讨论与相关提议无关的内容。关于unblock-zh的问题，根据我上面说的，我支持放开unblock的审核权，甚至于不审核。其它各位还觉得有什么需要补充的？其次，更大的问题是维护人手的问题，我在此呼吁更多的管理员加入对unblock的处理，否则等待时间难免加长。--人神之间摆哈龙门阵 2017年9月11日 (一) 18:07 (UTC)[回复]
  • 必须注意WP:IRC并非中文维基百科官方群，任何站内的讨论对IRC无效，任何IRC上的讨论也对站内无效。站内遵守方针指引，IRC遵守WP:IRCPOL，所以在这里讨论IRC的问题是没有意义的。--Antigng（留言） 2017年9月12日 (二) 01:19 (UTC)[回复]

具体规划

[编辑]

首先，我希望 Jimmy Xu 能够按照上方论述的要求对 unblock-zh 的后台设置做出必要的改动。否则请给出理由。除此之外，我提名在 unblock-zh 上很活跃的 A2093064、Wcam、WhitePhosphorus、Antigng、Alexander Misel 和我自己为列表的主持人（moderator）。考虑到 unblock 应该对所有管理员开放，因此如有其他希望担任主持人的管理员，也请在下面留言提出。如果上方提到的被提名人愿意接受，也请在下面留言表态。--Techyan（留言） 2017年9月11日 (一) 18:21 (UTC)[回复]

  • (＋)支持，我已经在JimmyXu用户页留言表达了这个意思。同时我也报名，希望能加入维护列表。--人神之间摆哈龙门阵 2017年9月11日 (一) 18:32 (UTC)[回复]
    请查收邮件。--Jimmy Xu 论 2017年9月11日 (一) 18:46 (UTC)[回复]
    谢谢Jimmy，我已加入维护列表，如果还有JimmyXu未联系到的管理员，麻烦请直接前往Jimmy的对话页请求密码。--人神之间摆哈龙门阵 2017年9月11日 (一) 19:03 (UTC)[回复]
    这Jimmy和人神之间唱双簧也太直接了，(－)反对如此unblock管理权还是按Jimmy个人意志决定，同样反对目前unblock继续被非华人地区人士垄断的情况。另外也没有证据证明人神之间是被社群信任的管理员，该用户曾经利用unblock黑箱，制造过社群的重大争议性性封禁——京沪线和爱孟的封禁事件，因此不信任该用户。unblock邮箱列表管理权应该由社群讨论或投票决定，要求撤回目前无共识的授权。从当下讨论的情况看，也没有一个人表示信任人神之间。若Jimmy Xu和人神之间等人执意完小圈子控制，那么我(＆)建議其他管理员另立新的受社群信任的unblock邮件列表，并考虑让社群选出若干非管理员用户作为观察员，监督unblock运作。门可罗雀的霧島診所欢迎光临维基Q群：170258339神社的羽毛飘啊飘 2017年9月12日 (二) 00:39 (UTC)[回复]
    (：)回應首先，管理员本身就是受社群信任的维基人。其次，我否认使用过unblock黑箱操作，所有unblock邮件往来都是可以查证的，任何在任管理员均可以查询。第三，没有任何人要小圈子控制，就像上面所述，任何管理员都可以找Jimmy拿到密码。当然，如果有维基人愿意开发，我完全支持开发一个新的unblock邮件列表，多总比不够的好。--人神之间摆哈龙门阵 2017年9月12日 (二) 01:14 (UTC)[回复]
    你也可以问拿钥匙的，问不到大可以再来问责。而且也有一些新当选的管理员加入，除非你觉得那些也是不可信的。——路过围观的Sakamotosan 2017年9月12日 (二) 01:01 (UTC)[回复]
    人神之间确实不被信任，该用户曾经以伪造的聊天记录作为“证据”，逼迫本人道歉认错，骗我说“道歉就解封”，结果我在没有任何违规的情况下，为了避免撕逼，违心地被他逼迫得道歉了，但他马上出尔反尔，拿我的“道歉”进一步作为给我扣罪名的“证据”，给本人和其他用户的心灵造成了极大的创伤。人神之间本来就是以玩“unblock黑箱”出名的，而他和本讨论所质疑的Jimmy Xu以及长期打压社群发展的AddisWang都关系很好（所谓近朱者赤近墨者黑，人神之间曾经为AddisWang冲锋陷阵，带头打压大陆维基社群，现在还是老样子），而人神之间脱离中文维基社群也已经很久了，甚至出现过6个月来“打一次卡”的情况[1]，所以该用户取得Unblock管理权显然不合理。另外，从来没有所谓“是个管理员就永远被信任”的道理。请其他受社群信任的管理员站出来维护，取得Unblock管理权限，维护方针，谢谢！ 上海灘維基悍將  守望者傳奇  2017年9月12日 (二) 15:19 (UTC)[回复]
    我认为维基百科最好的一点，就是所有的贡献和编辑都有迹可循，所有unblock邮件列表也都是对所有管理员公开的。有心想要了解事件详情的维基人，我相信他们能从编辑历史以及各种存档中了解到清晰的来龙去脉并作出自己的清晰判断。另外相信了解我的维基人都应该知道我对大陆维基社群的态度和贡献。最后，我非常赞同你的最后一点，我也希望更多的管理员前来加入维护unblock。--人神之间摆哈龙门阵 2017年9月13日 (三) 22:55 (UTC)[回复]
  • 愿意接受。--1=0，欢迎加入WP:維基百科維護專題 2017年9月12日 (二) 01:16 (UTC)[回复]
    请查收邮件。--Jimmy Xu 论 2017年9月12日 (二) 02:19 (UTC)[回复]
    已收到Jimmy Xu关于unblock-zh管理接口的邮件。--1=0，欢迎加入WP:維基百科維護專題 2017年9月12日 (二) 02:41 (UTC)[回复]
"观察员"是一個很好的提議。可是會不會太複雜?--Temp3600（留言） 2017年9月12日 (二) 01:31 (UTC)[回复]
也许我是最好作为观察员的，因为我曾经多次被Unblock黑箱作业/伪造的证据所害。 上海灘維基悍將  守望者傳奇  2017年9月12日 (二) 15:19 (UTC)[回复]
我還是傾向增加審核員的數目。設立觀察員，又要寫個新的方針，行政上會多出不少工序。--Temp3600（留言） 2017年9月12日 (二) 17:36 (UTC)[回复]

鸡米许阁下是好像除了在互助客栈上留了几个请查收邮件的言之外别的一句话都没说？请问上面那些阁下修改的设置改没改？让Temp3600等人好像都去你讨论页上留言了还当看不到？还有techyan说了和我自己，为什么没见阁下联络techyan赋权？揭了某些人的老底就把当事人给搞得火气和针对性这么大。。--黑暗雄鹰·给我留言·请关注管理人员和资深用户的人身攻击行为 2017年9月12日 (二) 05:51 (UTC)[回复]

附议--雲間守望 · 留言💬 2017年10月2日 (一) 06:35 (UTC)[回复]
所以问题到底解决没解决？—拖到机器人存档就是胜利（留言） 2017年10月12日 (四) 01:29 (UTC)[回复]

增加unblock-zh票据工单系统站点的意见调查

[编辑]

本主題或以下段落文字，移動自Wikipedia:互助客栈/其他。执行者：Jimmy-bot（留言） 2018年2月8日 (四) 00:42 (UTC)。[回复]

目前我们的站外查封申诉以邮件列表的形式处理。我作为处理的管理员不太喜欢邮件列表这个系统。我想弄一个类似英文维基百科UTRS的票据工单系统，并加以美观的设计。

我认为这样做的好处有几个：用户界面可用性增加（对管理员和用户都是这样）、可以自定美观的用户界面、安全性增加（全程HTTPS、HSTS）、可以让用户自行选择那些信息可以公开，哪些信息需要保密、增加条理性，等等。

虽然如此，不知道大家的想法如何。因为建立这个系统这个工作量不小，我怕建出来了没人用，或者大家可能提出我還沒有想到的問題。所以我现在这里问一下。

若您感兴趣技术细节：User:Bluedeck/etc/sandbox/box1515612315922

另：这个系统可以和当前的邮件列表系统并行运作。

Bluedeck 2018年1月10日 (三) 14:11 (UTC)[回复]

好大一个坑。为啥不host在toollabs？--百無一用是書生 (☎) 2018年1月11日 (四) 03:20 (UTC)[回复]
因为听说性能太糟糕而且申请条件苛刻所以懒得申请，反正我手头有空转的服务器资源，所以就自己host。Bluedeck 2018年1月11日 (四) 03:25 (UTC)[回复]
工单系统的数据备份会怎么做？--菲菇＠维基食用菌协会 2018年1月11日 (四) 03:27 (UTC)[回复]
OS-wise snapshot、根目录手动gzip、SQL dump、API 导出。Bluedeck 2018年1月11日 (四) 03:36 (UTC)[回复]
网站必须开设在wmf的服务器上。如果有这个系统的话，这个系统应当被认为是官方性质的申诉系统。开在wmf的服务器下，维护服务器的终极权限掌握在wmf的手里，这与系统的官方性是相称的。相反，如果在个人服务器上架设网站，维护服务器的终极权限掌握在特定用户手里，没有人有权监督该站的运行，这可能会导致问题。--Antigng（留言） 2018年1月11日 (四) 08:59 (UTC)[回复]
这个要求（或者这个要求的精神）是出自哪里的，wmf有过主动维护toollabs上搭载的非wmf的服务的情况嘛？Bluedeck 2018年1月11日 (四) 14:46 (UTC)[回复]
“wmf有过主动维护toollabs上搭载的非wmf的服务的情况嘛”，出于技术原因强制终止部分出问题的程序，这样的案例比比皆是。--Antigng（留言） 2018年1月11日 (四) 15:26 (UTC)[回复]
原来如此。Bluedeck 2018年1月11日 (四) 17:57 (UTC)[回复]
理论上有官方性质的系统不应该放在wmf控制以外的地方；toollabs申请很简单，性能虽然糟糕但是做这个功能够了。--哪位维基人能够一下打死五个？ 2018年1月11日 (四) 15:41 (UTC)[回复]
已经从tooladmin申请了membership，那么，我试试这个VPS。如果可以，我就在这里host。另外还发了邮件问问WMF的想法。Bluedeck 2018年1月11日 (四) 16:48 (UTC)[回复]
  1. WMFLabs上的东西原则上不允许存储隐私内容，而WMF运营的mailman跟WMFLabs是相互独立的；
  2. 自建服务器缺乏保障隐私的方式；
  3. 自建服务器难以保证稳定；
  4. 看了下你的sandbox，拖库了怎么办？最起码没看到这方面的考虑，好歹也得hash几遍；
  5. 带这么个系统就意味着跟随配套的所有教程（站内的以及站外的，比如你们经常用的那个解决IP封禁问题的截图等）、指南（WP:IPBE等）、模板（T:Block review等）、用户页面（MediaWiki:Blockedtext等）都得改；
  6. 如果不能保证稳定性，并试图用邮件列表作为备用选项的话，那么上面这些就准备天天改吧；
  7. 同上，反而增加新手使用成本；
  8. 会有很多人用？快去查查今天unblock里面总共才几封邮件
  9. 这玩意上线第一天就来帮你进行一下压(D)力(D)测(o)试(S)
  10. 顺便心疼你花了的域名钱
  11. 这么有钱的壕直接上keyless SSL多好（笑）

--Techyan（留言） 2018年1月11日 (四) 19:06 (UTC)[回复]

如果建好了之后反而增加使用成本的话那我太失败了，我肯定是为了让使用更容易才建设这个的。sandbox里的数据结构是让你知道结构而已。安全方面，user.secret = SHA256(server_salt(m)), m=SHA256(client_salt(passphrase))，其中m的计算在客户端进行。稳定性方面，和服务器关系不大，现在哪个服务器不是99.999 uptime，关键是内存泄漏和exception别飞出去，这是我要解决的问题。最后我在这里问的是如果我做的好，大家用不用。如果我做出一堆垃圾来，那当然没人会去用 : /，你不用担心我做出垃圾之后逼着大家使用.... Bluedeck 2018年1月11日 (四) 20:35 (UTC)[回复]
是啊那你准备怎么解决#5、#6的问题？一般那VPS的uptime能上三个九就怪了，母鸡关几十分钟维个护都不带提前通知一声的；更何况机器稳定又怎么样，zhmrtbot都坏了多少次了
反正我感觉你如果实在闲就搞，但我个人不是很支持。并且技术上的讨论结束了之后不意味着社群就同意用这个东西（部分）替代现在的unblock机制了。--Techyan（留言） 2018年1月12日 (五) 16:50 (UTC)[回复]
“并且技术上的讨论结束了之后不意味着社群就同意用这个东西（部分）替代现在的unblock机制了。”，我问的目的调查一下就是做出来之后社区用不用，不用我就不做了，不是为了讨论技术。“更何况机器稳定又怎么样，zhmrtbot都坏了多少次了”，所以说了不是机器的问题，而是软件的问题。还有，为了防止误会，再强调一遍，我调查的问题是：如果我做的东西好用，大家用不用，而不是如果我做出一个成天掉线的服务，还会硬要大家迁移到这上面。Bluedeck 2018年1月12日 (五) 20:51 (UTC)[回复]
是啊，我知道你的问题是这个，但是现在很明显没人在研究到底是用还是不用，反而都去计较技术方面的问题了。没什么人愿意出来研究到底用不用的原因一方面是话题被带跑了（锅当然我也得背）；另一方面则是现在没个成品，或者一个像样的雏形，大多数人也很难定夺。这么说也只是提醒你一下，按照现在的讨论，完全有可能你做出来了东西但是社群不肯用。毕竟现在没有人明确地说支持。顺便，#5和#6的问题还希望解释一下，把话题往正道上带一带。--Techyan（留言） 2018年1月13日 (六) 12:19 (UTC)[回复]
  1. 5，那就改呗，用模版改，这样只有改第一次比较费时。#6：上线之后肯定先腾出一段时间做稳定性测试啥的，没问题才投入使用。Bluedeck 2018年1月13日 (六) 20:26 (UTC)[回复]
直接用wiki账号认证登录不就好了--百無一用是書生 (☎) 2018年1月12日 (五) 03:44 (UTC)[回复]
我研究一下api。Bluedeck 2018年1月12日 (五) 16:18 (UTC)[回复]
老實說，我覺得unblock-zh不便性讓不少管理員卻步，不太願意處理（至少我是這樣）。如果有更人性化的系統的話，處理上也比較容易。—AT 2018年1月12日 (五) 16:58 (UTC)[回复]
不能做一个建立在邮件列表之上的人性化的系统吗，而不是重新做一个新的系统出来。——꧁༺星耀晨曦༻꧂（留言） 2018年1月12日 (五) 17:45 (UTC)[回复]
是吧，我也是这么想的，但是邮件列表能做的事情不多。只能美化一下界面，而且没有很多人用我这个模版。Bluedeck 2018年1月12日 (五) 21:12 (UTC)[回复]

真要搞的话不如重启引入OTRS系统的讨论。--云间守望（对话） 2018年1月13日 (六) 10:53 (UTC)[回复]

备注：在下十分信任Bluedeck的技术水平，只是考虑到隐私问题，建议还是放在维基媒体计划的服务器上。--云间守望 2018年1月13日 (六) 11:34 (UTC)[回复]
实际上这个系统的隐私和邮件列表的隐私没有区别，都是隐私内容所有管理员可见。Bluedeck是开发者兼管理员，所以本来就可见隐私内容。要说的话由于传输层安全的使用，这里只比邮件列表安全，而不是反过来。Bluedeck 2018年1月13日 (六) 20:33 (UTC)[回复]
什么叫好用什么叫不好用，没有一个客观的标准。空对空讨论“如果我的东西好用你们用不用”可能意义并不大，就像讨论“如果有一个完美的智能管理员机器人你们用不用”那样。所以还是建议先做出一点东西来再开展进一步的讨论。项目拿风险投资的时候也不是单纯有一个概念就可以的。--Antigng（留言） 2018年1月13日 (六) 14:27 (UTC)[回复]
讨论的目的是为了知道有没有除了易用性之外的原因而会让大家不想使用的。比如上面有人提到的隐私问题，政策问题或者需求问题。如果有这样的问题存在，大家可以提出来，如果我觉得非技术性障碍太多，可以提前拉到，就是这个意思。Bluedeck 2018年1月13日 (六) 20:24 (UTC)[回复]
三个问题：
  1. 想不想使用：普通用户不会太关注这个问题，除非经常被封需要申诉；经常处理unblock的管理员讨论讨论就好了。
  2. 放在哪里：如果决定要做，把系统放在wmf控制的服务器上是比较合理的，而非个人的服务器，以免有一天这个人变成了破坏者。
  3. 实现方式：OTRS是不是有现成的代码？可以把邮件对接到这个系统里，这样对于用户来说既可以邮件也可以上系统，而管理员有个统一的处理界面？
--哪位维基人能够一下打死五个？ 2018年1月16日 (二) 14:03 (UTC)[回复]

您好像沒有在維基文庫發送此通知，是否是因為該系統不適用於維基文庫？--Midleading（留言） 2018年1月21日 (日) 10:07 (UTC)[回复]

可以使用的，我忘记了：/ Bluedeck 2018年1月21日 (日) 20:12 (UTC)[回复]
这是意见调查，完成时产品还没有做出来呢，产品完成后才需要公告吧。Bluedeck 2018年1月28日 (日) 21:50 (UTC)[回复]

建立封禁申诉的本地共识

[编辑]

本主題或以下段落文字，移動自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2024年4月28日 (日) 08:14 (UTC)。[回复]

早在2008年就提出要建立本地的封禁申诉指引，但之后数年就再也没有任何进展了，尽管已经有相关内容扩充。为了使解封更为程序化，以便后续有被封用户更好了解封禁申诉指引，我提议再次建立封禁申诉的本地共识，将此内容列为正式的指引，最好参照英文指引作进一步扩充（可以让路君先参考一下）。--Shwangtianyuan 不忘初心 牢记使命 2024年4月2日 (二) 16:08 (UTC)[回复]

認為可以詳加討論。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年4月2日 (二) 19:10 (UTC)[回复]
封鎖申訴是跟執行封鎖/解封相對獨立的議題，也是需要一個獨立的方針，我分拆一下討論議題。另外我合理相信這倆議題不會小，@Shwangtianyuan：要不要考慮移去方針討論頁走RFC？--路西法人 2024年4月3日 (三) 04:56 (UTC)[回复]
大體上認同增修的方向。Sanmosa Szégyen a futás, de hasznos 2024年4月3日 (三) 07:51 (UTC)[回复]
在封鎖申訴、解除封鎖等事宜上，務必明確限制被封鎖人在申訴期間及解封過後的部分言行舉止。過往已經出現過好多次在管理員認定封鎖理據妥當但用戶已不需要再被封鎖的情況下，獲解除封鎖的用戶後續宣揚「原封鎖理據欠妥」的觀點騷擾管理員，WMLO如此（站內行為）、Wpcpey如此（在站外宣揚擾亂觀點）、近期解封的Chinuan12623（申訴期間）亦是如此。
我認為有必要在給予解封機會的同時說清楚解除封鎖僅是因為給予機會改善，而非認定原先封鎖不妥。管理員在解除封鎖時應清楚說明「接受申訴」是基於「原封鎖理據錯誤」、「給予改善機會」（即認定原封鎖理據合理）還是「原封鎖例句失效」（改為認定行為合理，但在原規則下確實違規）。第二種情形下，若獲解除封鎖錯誤宣揚自己行為無誤或管理員封鎖有誤的觀點，應視為「不認為自己有錯，即仍有繼續擾亂行為風險」而恢復封鎖；第三種情形下四處宣揚「管理員封鎖有誤」（即便管理員原先封鎖符合當時規則），亦應視為騷擾管理員、對管理員假定惡意再被封鎖。--路西法人 2024年4月3日 (三) 09:12 (UTC)[回复]
我覺得你這裏提到的第三種情形可能還要視乎當時的規則本身是否合理。如果當時的規則是因為本身不合理而修訂的話，那再修訂落實前對該規則的處理應該適用IAR，因此在這種情形下把說「管理員封鎖有誤」的人直接視為騷擾管理員、對管理員假定惡意可能不妥當。但是，如果當時的規則並非因為本身不合理而修訂的話，那我贊同提議的舉措。Sanmosa Szégyen a futás, de hasznos 2024年4月3日 (三) 10:24 (UTC)[回复]
管理員按照當下方針執行封鎖，那麼就不能說是管理員的封鎖有誤，那是方針的問題不是管理員的問題，管理員只負責執行方針。管理員不需也不應為方針指引過時而被指責「有誤」。把方針的問題歸在管理員身上顯然毫不合理。這也是為什麼我認為在任何情況下，就算方針改了，也不能因此追溯認定管理員當時判斷有誤，因為這是方針寫的。被解封用戶說「當時方針設計有問題」是完全合理的，但說成「當時管理員封鎖有問題」則顯然是在追究錯誤的責任。--路西法人 2024年4月3日 (三) 10:31 (UTC)[回复]
如果你在2024年4月3日 (三) 09:12 (UTC)提議的說明獲加入至WP:封禁申诉的話，我傾向認為“被解封用戶說‘當時方針設計有問題’是完全合理的”這點需要被明確，但是請容許我對於“管理員按照當下方針執行封鎖，那麼就不能說是管理員的封鎖有誤”這句話持一定的保留意見。如果所有（或大部分）管理員都很清楚當時的規則顯然有誤的話，那管理員完全可以根據IAR選擇不執行當時的規則，在這種情況下管理員明知規則顯然有誤但依舊執行，損害的是維基百科社羣的和諧，因此說依顯然有誤的規則執行封鎖的管理員完全沒有責任是不合理的，但我認同這種情況下主要的責任在於不合理的規則而非管理員，而我也認同在這種情況下把主要責任歸結給管理員可以視為騷擾管理員、對管理員假定惡意。Sanmosa Szégyen a futás, de hasznos 2024年4月3日 (三) 10:41 (UTC)[回复]
根本不應該會出現全部人都知道規則有誤但沒人提出修改該規則的情況。「有誤」跟「社群不再認同」是兩回事，管理員按照當下方針執行「當下社群相對不認同的方針」是不可以追究管理員責任的，「不認同方針」不是不執行方針的合理理由，不認同就該獲取共識修改方針，管理員執行這些方針不能被追責。如果方針本身有誤，而管理員刻意鑽這個漏洞去作出常人都能判斷不符合總體利益的封鎖操作，這叫WP:GAME。
此處僅是針對被封鎖人宣揚此類觀點，但理論上任何其他用戶亦應受類似的管轄（構成輕率指控），防止任何人單純因不滿管理員操作而借別人的口來騷擾管理員。--路西法人 2024年4月3日 (三) 15:12 (UTC)[回复]
雖然未必會出現全部人都知道規則有誤但沒人提出修改該規則的情況，但這不意味有人提出修改該規則後該規則就必定能成功修訂（比如WP:OA2021前蟲蟲飛經常性地阻撓大部分WP:7DAYS的修訂提案通過，因此在7DAYS成功獲修訂前，已經有若干管理員在執行7DAYS上應用了IAR，比如KirkLU），你這裏混淆了「提出修訂」和「執行修訂」兩種情形。我認為桐生ここ下方所言也局部代表了我的意見，而基於WP:5P5，我認為社羣應該要求管理員使用常識，而非要求管理員教條式地執行方針。Sanmosa Szégyen a futás, de hasznos 2024年4月4日 (四) 00:01 (UTC)[回复]
此外，我有必要澄清一點：我説的是“有誤”而不是“過時”，我考量的是當時的條文本身的合理性，而不是條文的時效性。Sanmosa Szégyen a futás, de hasznos 2024年4月3日 (三) 10:42 (UTC)[回复]
我覺得分三種
  1. 責任在用戶，管理員給予改善機會。用戶不應去控訴管理員。
  2. 責任在管理員，管理員解除錯誤的封禁。用戶可以控訴管理員。
  3. 方針不合理，管理員依照社群討論解除封禁。在於社群要求管理員是使用常識，還是教條式的執行方針，如果是前者，那麼管理員也有少量責任，如果是後者，管理員沒有任何責任。
--桐生ここ★[讨论] 2024年4月3日 (三) 15:13 (UTC)[回复]
回@Sanmosa、桐生ここ：「使用常識」最大的問題出在社群往往會鑽這個漏洞，事無大小都訴諸常識。比如苗君除權案中，WMLO及Cangjie6在禁制方針討論中，曾有用戶在吵「允許提報對方違反禁制應是常識」，但最終發現根本與常識沾不上邊，甚至在過往討論中有非常明確且更有力的論點去否定該想法。正是因為社群用戶總在不合意時訴諸常識，並試圖以此將責任歸咎於管理員，我才強烈反對將「常識」列為追究管理員責任的條件。
在這個討論中「要求使用常識」的「常識」其實根本不「常識」：「方針有社群共識支持」和「管理員負責執行方針指引」是絕對的常識，「管理員認為方針有問題所以不執行」這叫酌情而不是常識。只要方針是這樣寫，理論上應該有當初設立時的道理，在假定善意原則下，應假定方針有社群共識支持，如此管理員執行有社群共識支持的方針指引不能被追究責任。管理員自然有使用常識的義務，在使用常識的背景下錯誤理解方針，這個情況下管理員固然有一定責任；但在沒外人干預的背景下管理員執行假定有社群共識的方針，這可不可以成為追究管理員合理執行方針指引的責任。「社群要求管理員」怎樣怎樣往往只會變成一個經常被鑽的漏洞。--路西法人 2024年4月4日 (四) 02:01 (UTC)[回复]
不認同這個見解。我就拿DYKC一度存在的“所有投票須附理由”規則來説吧，在改成現在的“支持票不須附理由”前，簡單規定為“所有投票須附理由”的原因是對於再更之前“投票理由未涉及條目如何滿足DYK推薦資格的票無效”的規則如何理解的爭議，2015年時因為社羣無法就“涉及條目如何滿足DYK推薦資格”的定義達成共識而不再要求投票理由需要“涉及條目如何滿足DYK推薦資格”，但這也造成了2015年至2019年間大部分的DYK支持票都清一色寫上了「符合標準」、「達標」之類的字眼。然而，就算看回2015年的討論背景，即使維持要求投票理由需要“涉及條目如何滿足DYK推薦資格”，我說的問題依然存在，因為無論是2015年前的規則還是2015年至2019年間的規則都是希望能“遏制水票”，但如我在2019年的討論所説的，“寫‘符合標準’當作理由並不能遏止水票。大家有目共睹，2015年方案是一個徹底的失敗”。在這種情況下，“只要規則是這樣寫，理論上應該有當初設立時的道理”這個條件是被滿足了，但不見得那樣寫的規則實際上就肯定那麽有道理。Sanmosa Szégyen a futás, de hasznos 2024年4月4日 (四) 02:32 (UTC)[回复]
（還有，DYKC規則的這個例子可能也某程度上反駁了LuciferianThomas所説的“不可能存在‘所有人都知道某個方針有問題卻不去修’的情況”。）Sanmosa Szégyen a futás, de hasznos 2024年4月4日 (四) 02:43 (UTC)[回复]
所以管理員執行這個看似明顯有問題的方針怎麼了？IAR是管理員基於自己判斷而作出特別情況，你只能要求管理員按照當下方針、程序行事，但你不可以在修改方針前要求管理員「必須IAR按照你認為的常識行事」。在方針修訂前，任何不成文的規定都只是IAR或者「慣例」，稱不上「常識」。--路西法人 2024年4月4日 (四) 03:06 (UTC)[回复]
見下。此外，我還是這句話：個別用戶認為的「個別用戶認為的」與真正的「個別用戶認為的」也是不等同的，在一有人提出“按常識行事”時直接把他打成他要求“按照（僅）他認為的常識行事”並不妥當。Sanmosa Szégyen a futás, de hasznos 2024年4月4日 (四) 05:20 (UTC)[回复]
「常識」本來就是不一致的，唯一一致的標準是方針指引。如果連執行方針指引都應被質疑行為動機，甚至追究責任，我相信就會出現過往Tigerzeng所說的問題。當時他也清楚指出，應由社群擔起指示管理員操作的責任，制定、修訂方針顯然是一種方式，而不應該是期待管理員行使任何形式的「裁量權」去IAR不執行方針。現在在你的想法下，符合某些人意思的就是常識，不符合同樣那些人意思的就不符合常識、需要追究，顯然就的確是「按照（僅）他認為的常識行事」。--路西法人 2024年4月4日 (四) 13:01 (UTC)[回复]
我提7DAYS的例子主要是希望説明存在社羣希望指示管理員進行恰切的操作，但被現行（或當時實行）的規則阻撓的情形，這種情況下管理員應該合理判斷社羣到底希望指示甚麽給管理員。我認為你這裏對我的觀點的總結與我的實際想法並不相符。Sanmosa Szégyen a futás, de hasznos 2024年4月4日 (四) 15:20 (UTC)[回复]
簡而言之：個別用戶認為的常識不等於是常識，常識是指「客觀上所有正常思維的人都能得出相同的結論」的才叫「常識」，但我確信不可能存在「所有人都知道某個方針有問題卻不去修」的情況，即使有也是社群的問題而非執行方針的管理員的問題。--路西法人 2024年4月4日 (四) 02:03 (UTC)[回复]
你還是沒有回應我説的7DAYS的例子，而且你還是混淆了「提出修訂」和「執行修訂」這兩種不同的情形。我並不是想要抬杠，但我認為你應該也清楚個別用戶認為的“個別用戶認為的”與真正的“個別用戶認為的”也是不等同的。Sanmosa Szégyen a futás, de hasznos 2024年4月4日 (四) 02:40 (UTC)[回复]
方針修訂前的IAR正是真正「個別用戶認為的」情況。方針修訂前，執行原有有漏洞方針是基本要求，不按條執行是個人意志。7DAYS的例子我不熟悉，無法作出評價，但顯然禁制方針中一經體現社群經常出現「個別用戶認為的常識」而非真的常識的情況。管理員有權IAR，但按條執行是他們的責任也是理論上方針僅容許他們做的事，按條執行是不可能追責。--路西法人 2024年4月4日 (四) 03:12 (UTC)[回复]
請參閱WP:訴諸常識：當形成某一立場或解釋某一行為時，要根據已有的共識、社群基本原則、百科全書的利益作為立論之基礎，而不是你的個人常識。方針指引再怎樣，還是社群共識通過的，管理員執行就有他的道理。en:malicious compliance是不能追責的，因為他確實遵守了社群共識通過的方針。管理員遵守了（目前社群廣泛不認同也好、就質疑者不認同也好的）方針指引就還是遵守方針指引，問題在於方針指引，不在管理員。社群可不要習慣自己的問題全卸在管理員身上，管理員按照方針行事這才是最廣泛、最必須的「常識」。--路西法人 2024年4月4日 (四) 03:18 (UTC)[回复]
請務必謹記WP:IAR方針是說「如果有規則妨礙您恰當地改進或維護維基百科，請忽略該規則」而不是「你必須忽略該規則」。管理員不忽略「某些人認為不合常理」的方針是道理，行使IAR是情理。請分清楚道理和情理。
這裏說不能追責是說管理員遵守方針指引下不能被追責，如果管理員運用IAR脫離方針指引框架的決定有問題，當然就是管理員本人的問題；但管理員遵守、不忽略方針，是道理、是方針、是原則。--路西法人 2024年4月4日 (四) 03:26 (UTC)[回复]
依舊不認同，請參閲v:枪口抬高一厘米，要是社羣確實打算追責的話，那社羣已經有足夠的正當理由去這樣做了。Sanmosa Szégyen a futás, de hasznos 2024年4月4日 (四) 05:18 (UTC)[回复]
維基百科無此方針、無此共識，這不是常識。--路西法人 2024年4月4日 (四) 12:29 (UTC)[回复]
按你的邏輯，「按照（僅）他認為的常識行事」是不可取的，然而你現在做的事情不就正是在要求我「按照（僅）你認為的常識行事」嗎？我不認為單憑你説一句“這不是常識”，然後這就不是常識了。Sanmosa Szégyen a futás, de hasznos 2024年4月4日 (四) 15:11 (UTC)[回复]
既然你已經完全認定了你自己所想的（包括「槍口抬高一厘米」的概念）就是常識，那麼我無話可說。我有說「維基百科無此方針、無此共識」，所以才「不可能構成社群內的『常識』」，但你決定選擇性閱讀並說出「單憑（我）説一句」這樣的話，那我只能說你根本沒在理解「常識」是什麼，而是仍然將自己所想的視為常識。--路西法人 2024年4月5日 (五) 01:39 (UTC)[回复]
還是這句話：我認為你這裏對我的觀點的總結與我的實際想法並不相符。如果你實在無法妥為總結我的觀點的話，你並不用勉強自己這樣做。Sanmosa Szégyen a futás, de hasznos 2024年4月5日 (五) 02:39 (UTC)[回复]
我是完全難以理解上方兩名用戶的思維。管理員方針訂明管理員「唯能實現社群討論所得的共識」，這說明「執行方針」是他們行使權限時唯一能做的事，僅有在管理員本身認為方針不合理時自主行使忽略規則的權利時才會存在例外情況。WP:IAR是說「如果有規則妨礙您恰當地改進或維護維基百科，請忽略該規則。」為什麼現在可以被扭曲成「如果社群認為規則不合理，你必須忽略該規則」？在規則不合理時，討論修訂的責任在於社群，管理員沒責任無視社群不認同的方針，既然沒責任何來追責？
我觀察到的情況是，當管理員按照方針執行職務，如果不合某些用戶的意思就叫做「請使用常識」。這完全是事後孔明的表現，卻完全忽略了管理員本身是按照方針指引給予的權利行事，就算有問題也是出在方針上。Sanmosa指出7DAYS和DYKC，若有人反對、阻攔修訂討論，不就代表那不是「常識」了嗎？如果阻攔的意見是毫無道理的，現行的方針自然已經保護提案人可以忽略這些意見；若阻攔的意見是真的有道理、甚至有其他方針指引支撐的，那完全稱不上常識。--路西法人 2024年4月4日 (四) 03:47 (UTC)[回复]
所以您的解答已说明是后者，管理员需要当一个方针执行机器人。--桐生ここ★[讨论] 2024年4月4日 (四) 04:11 (UTC)[回复]
然而我不認同這個見解。如果管理員僅僅是執行方針指引的機械人的話，那我找個訓練有素的AI來代替管理員執行方針指引也無不可，不過這樣把管理員非人化真的好嗎？Sanmosa Szégyen a futás, de hasznos 2024年4月4日 (四) 05:12 (UTC)[回复]
此外，針對“若有人反對、阻攔修訂討論，不就代表那不是‘常識’了嗎”這個説法，我想提以下兩點：
  • 根據我之前的觀察，社羣其實不乏脫離實際情形思考的法條主義者，然而法條主義並不是常識。WP:共识#什么是共识甚至也開宗明義地説了“共識應當考慮到所有正當合理的意見”，如果我們無視了“正當合理”這個元素來判斷一件事情是否“常識”，這是非常危險的舉措。
  • 上面我提到的7DAYS雖然符合“有人反對、阻攔修訂討論”的條件，但OA2021與此後7DAYS修訂的成功通過恰好反映了“有人反對、阻攔修訂討論”不能代表那不是“常識”，甚至在此期間除我以外有很多用戶都多次反映修訂前的7DAYS的不合理之處，那當時真正的“常識”到底是甚麽我認為值得大家思考。
Sanmosa Szégyen a futás, de hasznos 2024年4月4日 (四) 05:32 (UTC)[回复]
用戶被禁制跟其過往參與討論期間的觀點是否有效並不衝突，被禁制後他的觀點仍然可以是有效觀點，只是他無權再繼續推動他的觀點，「後來他被禁制後議案獲得通過，所以他的論點是無效的」是完全不恰當的。除非他是因為exactly那一個論點被判斷為擾亂，他的論點則仍然是有效論點，綜上自然不會因他被禁制、議案通過，所以存在常識。你最近才因exactly這一個「因人廢言的傾向」吃過禁制，現在又故態復萌了？--路西法人 2024年4月4日 (四) 12:36 (UTC)[回复]
7DAYS的情況是在蟲蟲飛被禁制前已經有（除我以外的）用戶明確表達過當時7DAYS的規定與蟲蟲飛對當時7DAYS的規定的理解的不合理之處，這甚至是在7DAYS的原始規定一開始通過的時候就已經有的了，具體你可以看WT:共识在2020年至2021年間的存檔紀錄（畢竟你自己在上面也承認你不熟悉7DAYS的具體情形），因此我反對你把我對於OA2021前的情況的陳述打成“因人廢言”。我相信你很清楚輕率魯莽地指控他人行為不當屬於不文明行為，而且我也不是第一次跟你説這點了。Sanmosa Szégyen a futás, de hasznos 2024年4月4日 (四) 15:09 (UTC)[回复]
你動輒就稱蟲蟲飛「對方針理解錯誤」，卻是裝作看不到目前方針加入的註釋的原先提案中除了蟲蟲飛還有多人提出合理異議理據，顯然不存在「常識」，也只是恰好多數異議者後來因其他擾亂行為被封鎖、禁制，提案最終才得以通過。你所指「（用戶被禁制）後修訂獲通過反映有人反對不代表不是常識」則是將「是不是常識」和「修訂通過」關聯至「用戶被禁制」下，實際是你連你自己因人廢言了也不知道。
你所指「有人反對、阻攔修訂討論」不能代表那不是「常識」即你認為「有人反對仍可以代表存在常識」、上方也是一來就說「對方理解錯誤」，就算撇除用戶禁制的因素，你認為你的修訂提案「存在常識」，即反對的人都沒有你所謂的「常識」嗎？你從頭到尾在引用WP:常識，卻只選擇性引用符合你利益的部分，完全無視同一章節下WP:訴諸常識要求不要以個人常識去評斷他人行為、引用方針與指引比起訴諸常識更為有效，甚至將訴諸常識視作失禮行為。
WP:IAR方針只是容許在合適情況下忽略方針，而沒有賦予要求他人忽略方針的權利，更沒有賦予要求他人使用自己所認為的常識的權利。--路西法人 2024年4月5日 (五) 01:36 (UTC)[回复]
「有人反對、阻攔修訂討論」本身不構成「不是常識」的充分條件，此外你這裏還是忽略了我上面提及到的「共識應當考慮到所有正當合理的意見」。我有必要特別聲明我這裏所說的「正當合理」應該由社羣按不同情況作判別（故此我不能僅因你自己一個人說「還有多人提出合理異議理據」、「顯然不存在常識」就必須相信「還有多人提出合理異議理據」、「顯然不存在常識」就是實情），因此你把我所說的總結為「要求他人使用（我）自己所認為的常識」並不妥當。要是我真的「要求他人使用（我）自己所認為的常識」的話，我大可以直接說你上方說的東西全部不符合常識，而用不着在下方請求其他人的意見，我之所以沒有做前者的事情正是因為我自己並不贊同「要求他人使用（我）自己所認為的常識」。既然現在我們在做的事情是訂立方針指引，那我們倆在上面說的話都不能作準，這一切還是要看接下來社羣的討論共識如何。Sanmosa Szégyen a futás, de hasznos 2024年4月5日 (五) 02:49 (UTC)[回复]
@桐生ここ、LuciferianThomas：要不這樣：既然這裏對於“社羣要求管理員是使用常識，還是教條式的執行方針”這點，以至於“方針不合理，管理員依照社群討論解除封鎖”的情況下管理員是否存在一定責任有不一致的意見，那不妨就邀請更多用戶來就著這點深入討論，看看社羣到底是怎樣的看法，畢竟現在我們在做的事情就是訂立方針指引，這本來就需要廣泛的社羣共識基礎。（具體要邀請哪些用戶，我暫時沒有想法，可能可以放Bulletin請求用戶關注。）Sanmosa Szégyen a futás, de hasznos 2024年4月4日 (四) 15:32 (UTC)[回复]
這裏也ping發起討論的@Shwangtianyuan與有參與討論的@Ericliu1912。Sanmosa Szégyen a futás, de hasznos 2024年4月4日 (四) 15:37 (UTC)[回复]
一般而言，方針與指引即代表社群共識，內容通常也符合常識。所以我並沒有見到「使用常識」及「教條式執行方針」存在根本衝突。至於後者，我想這本質上是基於「忽略所有規則」而為之處置，同時也能促進社群變更共識，修訂方針與指引（其實前者也一樣——所謂「使用常識」去「凌駕」方針與指引，也不過就是「忽略所有規則」一種體現）。其實無論如何，管理員都應該就任何操作負責，但這所謂「負責」顯然僅限於操作本身，而不應該超出其他管理員自身無法控制的因素之外。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年4月4日 (四) 15:40 (UTC)[回复]
@Ericliu1912：那甚麽是“管理員自身無法控制的因素”？給個定義吧？再不然舉例説明也可以。Sanmosa Szégyen a futás, de hasznos 2024年4月4日 (四) 15:42 (UTC)[回复]
我稍微思考一下，明日再回覆，今日先休息了。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年4月4日 (四) 15:43 (UTC)[回复]
雖然還沒想到具體案例，但我認為所謂不可抗力因素，可以是不涉及管理員操作本身（例如線下現實社會動態），或管理員操作當下無法知悉或未經嚴格查證難以明悉（例如某人曾因故在站外透過社群媒體與他人合理溝通，但站內管理員不見得知道）者。若有額外想法，或再補充。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年4月7日 (日) 08:44 (UTC)[回复]
@Ericliu1912：容我再追加一條問題：你既然提到你並沒有見到「使用常識」及「教條式執行方針」存在根本衝突，那作為現行方針的「忽略所有規則」可以如何「教條式執行」？Sanmosa Szégyen a futás, de hasznos 2024年4月9日 (二) 15:34 (UTC)[回复]
那應該是唯一不適合「教條式」執行的準則吧？畢竟該政策本身的宗旨就是有必要時可以不「教條式」執行其他政策（這裡說的自然是前面所說的例外情況，而不是常態），是以為「維護百科全書」所為之最終手段。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年4月10日 (三) 03:07 (UTC)[回复]
若然社羣真的要求管理員教條式地執行方針，那「忽略所有規則」就會事實上失效，因為一定會有人想把所有的例外情況都給排除掉。Sanmosa Szégyen a futás, de hasznos 2024年4月11日 (四) 02:41 (UTC)[回复]
至於方針合理且責任在用戶，以及方針合理且責任在管理員這兩種情形，我認為這裏應該已經存在共識了，也就是責任在用戶時用戶不應控訴管理員，而責任在管理員時用戶可以控訴。Sanmosa Szégyen a futás, de hasznos 2024年4月4日 (四) 15:34 (UTC)[回复]
Eric Liu說的不錯，提出了另一種觀點。
其實無論如何，管理員都應該就任何操作負責。
而且，責任是否在用戶其實也不是一個人能決定的，因此用戶有權利在任何時候提出討論，但在任何時候都不應該騷擾管理員。--桐生ここ★[讨论] 2024年4月5日 (五) 03:10 (UTC)[回复]
我並不反對這個意見，但我認為這裏討論的是甚麼情形能被認定為「騷擾管理員」。Sanmosa Szégyen a futás, de hasznos 2024年4月5日 (五) 03:24 (UTC)[回复]
舉例來說：
  • 提出申訴不算
  • 不斷的Ping管理員算
  • 發起一次討論請大家評理不算
  • 反覆的對同一個問題發起討論算
  • 在社群一些人認為管理員有錯的情況下，提出RFDA不算
  • 在沒有任何人支持，一意孤行的提出RFDA，意圖報復或施壓管理員算
  • 其他WP:HA、WP:PA等行為算
--桐生ここ★[讨论] 2024年4月5日 (五) 03:52 (UTC)[回复]
你這裏說的「申訴」和上面說的「控訴」具體上有沒有甚麼差別？「在社群一些人認為管理員有錯的情況」有沒有任何例外情形？Sanmosa Szégyen a futás, de hasznos 2024年4月5日 (五) 04:25 (UTC)[回复]
申诉是进行封禁申诉
控诉是在客栈公审管理员--桐生ここ★[讨论] 2024年4月5日 (五) 05:37 (UTC)[回复]
感謝澄清。Sanmosa Szégyen a futás, de hasznos 2024年4月5日 (五) 08:17 (UTC)[回复]
@Shwangtianyuan：你還打算原案推動嗎？Sanmosa Szégyen a futás, de hasznos 2024年4月17日 (三) 13:00 (UTC)[回复]
没有打算了。--Shwangtianyuan 不忘初心 牢记使命 2024年4月17日 (三) 13:04 (UTC)[回复]
@Shwangtianyuan：那我給個建議：從enwiki現版重新翻譯一次。Sanmosa Szégyen a futás, de hasznos 2024年4月18日 (四) 05:45 (UTC)[回复]
可以这么做，英文版的话，指引内容更为完善些，我当时就是这么想的，以英文现行版本为基础。但是某些内容可能与中维其他方针指引不符，所以我还没有翻译。--Shwangtianyuan 不忘初心 牢记使命 2024年4月18日 (四) 05:58 (UTC)[回复]
检索自“https://zh.wikipedia.org/w/index.php?title=Wikipedia_talk:封禁申诉&oldid=82426784”