跳转到内容

维基百科讨论:封禁申诉

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

应该建立

此页面应该建立，而且现在互助客栈关于建立此页面的讨论也已经大致通过。—人神之间摆哈龙门阵 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”