跳转到内容

维基百科讨论:申请成为管理人员/存档8

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

Zh.WP checkuser re-introduction／重新引入中文维基百科用户查核权限

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2022年5月15日 (日) 00:14 (UTC)。

原标题为：Zh.WP checkuser re-introduction/重新导入中文维基用户查核权限

The members of the local Chinese language Wikipedia community and the Stewards, who currently provide CU support to Zh.WP, have indicated to the Foundation that it would be desirable to explore possibilities of reinstating local CheckUser privileges on Chinese language Wikipedia. These rights were revoked from the local community due to security concerns in 2018.

中文维基百科本地社群成员以及替中文维基百科提供用户查核支援的全域监管员已向维基媒体基金会反映希望恢复中文维基百科的用户查核权限。此权限基于安全考量，于2018年自本地社群移除。

As a Foundation, we strongly endorse community self-governance wherever feasible. We also realize that each community has unique challenges that require authentic approaches that tackle them. In this spirit, we would like to state that the Foundation would support reinstating local CU privileges if Zh.WP meets two conditions.

作为基金会，我们在许可范围内强力支持社群自治；我们也同样理解不同的社群有其特有的挑战，亦需要用独特的方式来应对。本着此精神，我们想声明：若中文维基百科可以满足下述两个条件，基金会将会支持恢复本地社群之用户查核权限。

First, that the local Chinese language Wikipedia community offer their commitment to uphold the global aspects that all communities with local CU privileges uphold. A critical element is policy compliance. Currently, all communities with local CheckUser privileges are required to adhere to binding policies governing the recruitment of CheckUsers and the use of the tool. The potentially elected Zh.WPs CU would need to strictly uphold the Compliance with the CheckUser Policy and Compliance with the Access to Non-Public Information Policy, including the NDA policy update 2021. The local community should in turn respect these instruments.

首先，中文维基百科本地社群必须承诺维护所有拥有本地用户查核权限之社群的通用认知。其中一个关键要素为政策规范合规性。目前，所有拥有本地用户查核权限之社群都被要求要遵守有关用户查核者的招募及使用工具之约束性政策。未来中文维基百科中可能当选为用户查核员之用户必须恪守用户查核政策与非公开个人资料存取政策，包含2021年更新之保密协议。本地社群必须尊重这些政策文件。

Secondly, the Foundation is aware that the Chinese language Wikipedia continues to have long-standing internal trust challenges unique to the local community. We are aware that the local community is confronting noteable difficulties in local collaboration both on the Chinese mainland and internationally. As a Foundation, we undertake to support the re-introduction of the local CU rights if:

再来，基金会已认知到中文维基百科持续面临当地社群独有的长期内部信任挑战。我们理解本地社群在本地合作／协作上，不论是与中国大陆还是跟国际社群都窒碍难行。作为基金会，我们承诺在满足以下情况下支持重新引入本地用户查核权限:

  1. Elections: All Zh.WP elections for CheckUser are conducted through SecurePoll elections (two weeks), with Steward scrutiny support. Doing so would provide greater safety to both candidates and voters. Further to this, the appointment tenure for CU user rights holders on Zh.WP to be two calendar years, at the end of which re-election of CheckUsers aiming to extend their tenure via SecurePoll will be required. Doing so would enable the local community, which does not have a NDA-signing ArbCom providing added accountability for CUs, to assess whether they still have sufficient trust in their local CUs after a meaningful period of time. There will be a recall mechanism for CUs. In it, voting-eligible users can safely register their voice in case they have lost confidence in a CU in-between elections. Once registered, a concern will be valid for a year or until the next re-election. 25 valid concerns related to a CU at the same time will trigger a recall election within two months, unless said CU decides not to run for re-election. Two years overall tenure in-between regular elections is in-line with long-standing re-election practices for CUs on German and Portuguese language Wikipedias, two other large communities with local CUs but without a NDA-signing ArbComs.
  2. Training: All successful Zh.WP CU candidates to be trained in CU community best practices prior to the user rights change granting them CU rights. Doing so would ensure alignment of Zh.WP CU practices with the global community.
  3. Audits: The Foundation will regularly audit CU activity on Zh.WP for at least a year; including an evaluation after a year whether or not to continue such audits. A practical way for that is keeping the current community consensus-based requests for checks. The community would comment on requests, which can then be audited for problematic users stacking against a certain user.
  1. 选举：所有中文维基百科之用户查核员选举必须透过SecurePoll秘密投票，每次选举为期两周，选举期间必须有全域监管员支援监票，这样做将有助于提供候选人及选举人更大的安全保护。此外，当选之用户查核员任期为两年，在任期结束后必须要再度重新参与选举，通过秘密投票来延长任期。这样做将有助于社群，在缺乏签署保密协议之仲裁委员会确保用户查核员负责任的情况下，有一段时间去检视和评估他们对于当地的用户查核员是否有足够的信任。用户查核权限将有除权机制：有人事任免投票资格的用户可以安全地提出自己的质疑，此质疑有效期为一年，或是到下次用户查核员选举之前；如果有超过25人之质疑关切，就会在两个月内触发罢免，除非该查核员选择不竞选连任。上述任期制度已由德语、葡萄牙语两大有本地用户查核权限但没有签署保密协议的仲裁委员会的社群采用。
  2. 训练：在授予权限之前，所有中文维基用户查核员候选人都将会接受用户查核员社群的培训，以确保中文维基上的用户查核实践与全球社群一致。
  3. 稽核：基金会将会定期稽核中文维基之用户查核活动至少一年，此举包含一年后是不是要继续持续这样的稽核机制等。目前针对稽核有一个实用的方式：持续目前基于社群共识作出的查核请求；社群将对这些请求发表评论，令基金会可以稽核这些评论，以便寻找针对特定用户的问题用户们。

Finally, the Foundation commits to facilitating the functionary-guided creation of a CU self-learning module, available in Chinese and English in the Wikimedia LMS in 2022. This will document global community best practices for the tool and its appropriate use in a local community context.

最后，基金会承诺会促成在官方公务员（functionaries）指导下创建一个用户查核权限自我学习模组，其中英双语版本将于2022年在维基媒体LMS供查阅，此举将把全球社群在使用该工具的经验以及使用方式以当地社群语言妥善记录。

WMFOffice（留言） 2022年1月13日 (四) 20:38 (UTC)

“当选之用户查核员任期为两年，在任期结束后必须要再度重新参与选举，通过秘密投票来延长任期....”WMF钦点了这个方法,那我认为可以在sysop上长远使用啊?--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵～ 2022年1月14日 (五) 08:30 (UTC)
不同意管理员任期制。另外我甚至反过来担心这样选使用者查核员会不会难产。—— Eric Liu 创造は生命（留言．留名．学生会） 2022年1月14日 (五) 10:04 (UTC)
难产的话，若有要查核就先转交全域监管员？--0906（回复请Ping我） 2022年1月14日 (五) 15:22 (UTC)
是的，如果难产，先转交至监管员。--夏雪若（留言） 2022年1月14日 (五) 15:28 (UTC)
难产也要。这是御旨。--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵～ 2022年1月15日 (六) 05:51 (UTC)
我认为SRCU还有必要继续存在，鉴于社群目前的互信情况。不仅是CU员难产的问题，即使能选出CU员，社群对CU员的信任程度又有多少？到时候涉及老用户的查核可能还得监管员帮忙。另外我强烈建议CU的选举在管理员的安全投票试行一段时间后再举行。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月14日 (五) 15:34 (UTC)
我想请问训练将在哪进行，以及训练一名用户查核员需要多长时间。--BlackShadowG（留言） 2022年1月17日 (一) 00:21 (UTC)

对于重新引入不报希望，即便引入也是CU员难产。桐生ここ★[讨论] 2022年1月18日 (二) 05:11 (UTC)

  • 如果已经明确计划好要恢复查核员，那对于无法签署NDA的大陆用户应该会造成更大规模的（无论主观或客观）歧视与不公平现象。毕竟曾经出现过
这种话，而现在大陆用户连监督员都无法担任。--Yining Chen（留言|签名页） 2022年1月18日 (二) 14:34 (UTC)
基于上方理由，(－)强烈反对引入用户查核员，而且NDA不承认中国大陆的理由也合理无法反驳，不论对于歧视还是安全原因，都应维持现状。桐生ここ★[讨论] 2022年1月18日 (二) 14:46 (UTC)
我反对恢复本地CU权限的理由是大陆用户无法签署NDA以及对港台用户与居住在海外的大陆人的不信任，应该维持现状。--Lanwi1(留言) 2022年1月18日 (二) 14:57 (UTC)
既然这样，我建议自废武功，本地CU不能查有关延伸确认用户的请求，而应转交元维基；本地CU查到有关延伸确认用户的案件，应送报元维基核实。 ——魔琴 [ 留言 贡献 ] 2022年1月19日 (三) 04:19 (UTC)
所谓安全问题不是CU作出虚假结果，而是泄漏非公开数据，比如举报到香港国安处或者FBI，是编者的人身安全问题，即便CU值得信任，但是不能保证CU所在或所属的当局不会强迫CU进行查询，虽然大陆不能签署NDA，但比如香港、澳门实际上也是不安全的，要是排除这三个地方，就是一种歧视，因此不如维持现状。桐生ここ★[讨论]2022年1月19日 (三) 04:38 (UTC)
我觉得目前大概两点疑虑，一点是打击报复，我觉得我的方案可以解决；一点是CU数据的安全性，大陆人不能签NDA可以保证（至少很难被中华人民共和国获得）。另外我很疑惑的一点，为什么排除港澳就是歧视，排除大陆就不是？既然现在港澳还能签NDA，我们就没必要帮WMF担心。如果真的觉得港澳不安全，那就应该跟WMF建议撤销港澳人士的NDA。没有说港澳能签NDA但做CU不安全的道理。 ——魔琴 [ 留言 贡献 ] 2022年1月20日 (四) 04:29 (UTC)
支持合资格且有意向者申请用户查核权限，反对自我矮化主权，现今转交元维基的操作过于繁琐。先前对本地CU的担忧在于中共威胁与WMC渗透，基金会行动后已不是大问题。住所不为第三方所知的大陆用户仍然可以签NDA，而上方讨论中所说的“歧视与不公平现象”并无前例。--Lt2818（留言） 2022年1月19日 (三) 05:21 (UTC)
据我所知，User:Alexander_Misel的住所应该不为第三方所知，然而却有该笔日志（注意此日志发生在WP:OA2021之前，与OA无关）。第二点，只知道担心“中共威胁与WMC渗透”，那我们这些用户要不要担心“█国民主党和F█I威胁与H█U█渗透”？第三点，“歧视与不公平现象”没有前例，但正在发生。建议参考自基金会行动以后站内的几项所谓“决议”的流程。另：怎么看待上方在查核员尚未被废除时真实出现过的言论？只是维基人间“友好的交流”？现在为解决这种现象所做出的唯一努力就是“歧视大陆用户”吗？（可能违反WP:AGF，故自行删除）虽然基金会做出的决定改不了，这一点没错啦；但是还是很想知道类似这种“决定”的支持者是怎样思考问题的。--Yining Chen（留言|签名页） 2022年1月19日 (三) 14:39 (UTC)
具体住址是不知道，但是具体城市他曾经在QQ群公开过，他说那天他所在的城市居民包括他本人在内被全员核酸检测。--中文维基百科20021024（留言） 2022年1月19日 (三) 14:27 (UTC)
我觉得住所不为第三方所知的大陆用户可以签NDA，也有大陆用户完全不愿公开自己的住址。--Lanwi1(留言) 2022年1月19日 (三) 15:43 (UTC)
即使“完全不愿公开自己的住址”，如果参加了任何线下活动，也很可能会有问题。甚至更极端的，在任何社交网站或者Zoom等地方公开了自己的照片，也有问题。更不用说真实身份早就众所周知的用户。--GZWDer（留言） 2022年1月21日 (五) 10:07 (UTC)
个人认为连六扇门都难以找到住所的用户才满足条件。至于上述个案，原因恐怕不止于此。--Lt2818（留言） 2022年1月20日 (四) 03:40 (UTC)
Wikipedia:河北维基人列表显示，该名用户现时住在石家庄。--Alexander Windsor谈笑风生 2022年1月23日 (日) 07:13 (UTC)
个人意见同Lt2818阁下。—— Eric Liu 创造は生命（留言．留名．学生会） 2022年1月19日 (三) 07:41 (UTC)
除非 User:PMDdeSN 一事明了，否则(－)反对。--广雅 范★ 2022年1月19日 (三) 08:18 (UTC)
那看来泄露CU纪录的事情不止一位，要是CU回归中维的话大家应该做好心理准备。--中文维基百科20021024（留言） 2022年1月19日 (三) 08:36 (UTC)
是什么事？没有了解过。--Tranve (✉) 2022年1月20日 (四) 01:38 (UTC)
TranveWikipedia:互助客栈/其他/存档/2017年10月#用户查核不得不说的事 --Lt2818（留言） 2022年1月20日 (四) 03:40 (UTC)
(！)意见如果本地重新获得用户查核权的话，可以保留元维基用户查核请求权以处理有争议的本地查核案。--🎋🎍 2022年1月22日 (六) 12:25 (UTC)
有争议的话，找其他本地查核员复核较为合适，亦可找申诉专员。监管员不会有更高权威，君不见三位监管员确认之傀儡都能被抵赖掉。--Lt2818（留言） 2022年1月22日 (六) 14:17 (UTC)
如果要找申诉专员，可能会面临举证难题，而且这难道不是对一些 处于弱势且不精通外语的中国大陆用户 的一种歧视？（除非申诉专员里出现了zh-2用户）--Yichen Ding（留言|主账户） 2022年1月22日 (六) 14:49 (UTC)
就监管员吧，申诉专员处理效率肯定没监管员好，不过可能要先问监管员愿不愿意。照规定来说，监管员不能处理有本地查核员的查核请求。--（☎） 2022年1月22日 (六) 18:32 (UTC)
个人认为基金会会推动本地CU建立，然后到时监管员就不用管咱的CU请求了。除非有人跟基金会讨论过可不可以维持现状，不然我觉得楼上提的关于CU的问题要面对只是早晚而已。--（☎） 2022年1月26日 (三) 23:58 (UTC)
基金会没打算解释一些细节么？—— Eric Liu 创造は生命（留言．留名．学生会） 2022年2月11日 (五) 03:39 (UTC)
包括所谓的除权机制、当选人所接受的培训，以及定期稽核等等，基金会都没有给出足以让本地社群讨论或订立规范的内容。—— Eric Liu 创造は生命（留言．留名．学生会） 2022年2月21日 (一) 12:28 (UTC)
读完了大家的讨论，我的观点也是给中维CU不够安全。原因有二，首先，WMC和中共不是我们唯二要防的信息泄露对象，前面各位点到的其他政权和团体对中维产生的潜在信息泄露威胁也不是空穴来风。其次，在没有办法向内地用户提供CU权限的情况下，也很难平衡不同地区的查核员的比例。除此以外，基金会这次给出的信息太过有限了，不知道该如何应对。Itcfangye（留言） 2022年2月26日 (六) 06:31 (UTC)
  1. WMC和中共是特定于中文站点的担忧对象，其他实体或者未见对本地的危害迹象，或者对全域项目有影响（如NSA对维基百科的监控），不见得由监管员代替本地查核员即能消除信息泄露威胁。
  2. 未见“平衡不同地区的查核员的比例”之必要性，这与查核工作能否安全有效运行并无关联。
--Lt2818（留言） 2022年2月27日 (日) 13:43 (UTC)
意见同上。另外，wikt:空穴来风。 ——魔琴 [ 留言 贡献 ] 2022年2月27日 (日) 15:20 (UTC)

re-meta:Special:Diff/22831347

  1. 在公告“具备投票资格的用户可以安全发表自己的声音，以防他们在 CU 选举之间失去信心。”，具体步骤是什么？
    社区需要决定什么是合格的选民。安全选举是 SecurePoll 选举。社区已经设计了不同的方式来表明在定期选举之间失去信心。例如，德语维基百科强制使用该系统。
  2. “所有成功的 Zh.WP CU 候选人都将在 CU 社区接受培训”如何培训？在哪里培训？ 培训一位用户查核员需要多少时间？
    全球志愿者社区和基金会需要共同开发一个培训模块。培训模块可以托管在 learn.wiki 上，总共可能需要大约 2-4 小时。
  3. 2017 年发生了一起事件，当地用户查核员公开披露了 CU 数据。我理解 T&S 出于隐私和法律原因无法发布详细信息。但事件已经解决了吗？
    默认情况下，基金会不会公开讨论其调查案件的细节或状态。
  4. 当地讨论中有一个提议，如果有复杂的案件，即使有当地的用户查核员，也可以要求 CU 管理人员调查。这个提议可以接受吗？
    这是当地社区直接与管理人员进行的对话。基金会要求尊重相关政策和标准，但当地 CU 或管理人员是否调查案件取决于当地和全球社区，而不仅仅是基金会的观点。
  5. 本地讨论中表现出对本地 CU 结果难以接受的担忧。因为语言障碍，一些本地用户的英语可能不太流利。有什么方法可以帮助当地社区成员轻松上诉？
    防止用户查核员滥用的第一层控制在于其他用户查核员。这就是为什么全球用户查核员政策总是要求有一个由两人组成的本地团队。这样总有其他人可以看到 CU 数据并且产生制衡。如果仍担心和怀疑滥用 CU 工具，可以随时将此类问题提交给申诉专员委员会，可以使用任何语言向申诉专员委员会提出问题。--WMFOffice（留言） 2022年3月1日 (二) 03:47 (UTC)
假如连WMF出来回答了也没人给反应的话，我唯有移走不存档模板当大家都不想要CU了。Ghren🐦🕓 2022年3月10日 (四) 08:33 (UTC)
确实有支持也有反对……WMF也解答了一些反对票的疑惑。我们是不是可以整理一下各方观点看看有没有突破口。 ——魔琴 [ 留言 贡献 ] 2022年3月10日 (四) 23:17 (UTC)
问题是 WMF 说的不明不白：在 18 年行动之前有 6 名查核员，除去WP:CU中记载的推定离任的那几位还剩下三位。这三位到时候是直接复职还是要经过上面的 secure poll 投票？推定离任的是确实像 OS 那样已经经过邮件确认离任还是要再 lock 一次然后发邮件申请离任？从上面的讨论来看至少有两次 CU 数据泄露，站外的和站内的，但是从 18 年到现在 WMF 既不告知调查结果也没有见到 WMF 对当时的查核员做出行动。可否推断 WMF 对此事也是无结论？如何能确保将来不再发生此事？--广雅 范★ 2022年3月11日 (五) 15:33 (UTC)
应该是不能直接复职。 ——魔琴 [ 留言 贡献 ] 2022年3月11日 (五) 15:46 (UTC)
同魔琴君，应该不能直接复任，并需重新经过上述投票。“如何能确保将来不再发生此事？”根据WMF现有提供的资讯，应该是藉培训、监察机制及秘密投票来确保查核员的素质，从而防止泄露事件的出现。谢谢。--SCP-0000（留言） 2022年3月11日 (五) 16:37 (UTC)
说实话我不认为这些方法可能有用。User:PMDdeSN 虽然各人有一定猜测，但现在都没有确定是当时哪位查核员泄露的数据。如果知道的话当时就可以发起解任投票，而不用等到基金会介入。在大家都没有证据确定是谁的话安全投票无法确保社群的监督机制。而且所有查核员都签署过 NDA，新开一个一次性账号也能证明此人是清楚这种行为是严重违反规定的，因此培训能达成的功效也有限。当时此事通报基金会后基金会肯定也进行过一系列调查，但就像我之前说的，至今都没有发现有相应的 office action 出来，因此我怀疑监察机制能否达到预期。--广雅 范★ 2022年3月12日 (六) 13:46 (UTC)
(▲)同上。基金会在这件事上似乎除了移除中维查核权限外束手无策。很让人怀疑基金会是否真正有有效方法来避免以后出现同样的问题。不要等到刚刚恢复CU权限第一天就出现隐私泄漏事故。[开玩笑的]----Yichen Ding（留言|主账户） 2022年3月15日 (二) 15:20 (UTC)
最糟糕的情况下，也不过就是禁止前使用者查核员竞选罢了。又或者等个几十年，所有相关人士全死光了才能选新的？我个人不希望将本地查核作业永远丢给监管员来做。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年3月23日 (三) 16:53 (UTC)
禁止前查核员竞选也不能保证新查核员没问题吧，毕竟当时选前查核员时也没料到会出当时的事情。我本身不反对本地拿到 CU 权限，但问题是之前出的事情总得有个交代。不然现在都知道查核员自己用傀儡连基金会都没法查出来了，难保不会出现第二次第三次。还有上面提到的查核员个人私下将数据泄露给第三方的问题。--广雅 范★ 2022年3月24日 (四) 02:11 (UTC)
@范、Ericliu1912、Yining Chen： 近日向基金会询问他们有没有其他方式来应对泄漏CU数据的问题，他们的回复可见此。另也可参考一位英维管理员的意见。谢谢。--SCP-0000（留言） 2022年3月26日 (六) 00:26 (UTC)

若不能满足以下两个条件，不论谁参选用户查核员，一律投反对票。

IP Internet
Protocol
Address 		网际
协定
位址
UA User
Agent 		使用者
代理
  • 隐私：现行的设置总有漏网之鱼。这权限应改成不能查核IP用户，也不能显示注册用户的IP和UA，每次只能查核某注册用户之间的关系，均为系统过滤后的结论，类似于全域监管员的答复，去除不必要的安全忧虑。
  • 监察：任何人都可以请求查核用户，唯决定权在于用户查核员。使用权限前必须通知被查核的用户；使用权限时提供充足的理由来解释，只有怀疑滥用傀儡的情况才需要查核；使用权限后系统应自行记录，让任何人都能看见。

--月都（留言） 2022年3月29日 (二) 23:46 (UTC)

(＋)支持公开查核记录，但(－)反对关于隐私的设定更改，明显存在对用户查核工具的错误理解。监管员给予的答案均是不能简单以编码代替的，况且用户查核员本身还需要（因应请求和合适情况）进行查核以延长自动封锁（WP:CUP#1）和查核用户请求IP封锁例外是否与其申诉／申请所言相符才授予权限（WP:CUP#3，现在都没有在执行）。同时(－)反对使用权限前必须通知被查核用户，不可能预先通知LTA他们即将被查核。无论是操作上还是原理上，这些要求都是完全不合理的。--路西法人⛧𖤐 2022年3月30日 (三) 03:07 (UTC)
用点常识就知道不可能公开查核日志了好吗？如果日志上写着已查核User:Example，然后紧接着已查核IP:1.2.3.4，那么有点逻辑的人都知道User:Example的IP是啥了。--Xiplus#Talk 2022年3月30日 (三) 04:48 (UTC)
感谢两位提出意见，参考RBI论述应不理会LTA，使用权限前必须通知被查核用户，这要求或有不妥之处，故此添加删除线；纵上有用户指出潜在泄漏资讯的威胁，过去已发生泄漏数据的事件，恢复本地社群之用户查核权限前，隐私安全需要得到重视，不然如桐生所说维持现状。 --月都（留言） 2022年3月30日 (三) 05:16 (UTC)
查核日志仅针对用户，而IP用户则仅标记XXX查核了“某个IP”（真的是“某个IP”）这样即可。没人说一定要显示出来的。另外，执行WP:CUP#1的时候，监管员或用户查核员封锁个别IP的时候，不也是同样一边出查核结果，一边进行{{checkuserblock}}吗（监管员的封禁日志）？我觉得MASK了IP就已经能符合查核日志的隐私要求了。--路西法人⛧𖤐 2022年3月30日 (三) 10:14 (UTC)
(＋)支持查核日志仅针对用户，不显示IP地址；在保证隐私没有外泄的可能时，同意本地引入用户查核权限。 --月都（留言） 2022年3月30日 (三) 13:54 (UTC)
@LuciferianThomas：有时会对封锁日志进行监督，就是为了隐私，或是等一段时间才封锁等缓解措施。--Xiplus#Talk 2022年3月30日 (三) 13:56 (UTC)
确实如此，那么除对查核员及监管员外不显示IP的查核日志是否合理的技术性保护用户途径？此外，亦必须向基金会询问不具有查核权限的用户透过建立镜像站而获得类同用户查核的资讯是否符合隐私政策。--路西法人⛧𖤐 2022年3月30日 (三) 14:13 (UTC)
(＋)支持，甚至即使不公开对IP用户的查核记录也无妨。--Yining Chen（留言|签名页） 2022年3月31日 (四) 14:08 (UTC)
那么应该先咨询技术团队跟法律团队。--Xiplus#Talk 2022年3月31日 (四) 16:08 (UTC)
把“•公开”修改为社群“•监察”，以防止查核员滥用职权。 --月都（留言） 2022年3月31日 (四) 16:57 (UTC)
原则上只要不公开IP和账号之间的关系就可，或可考虑只公开查核涉及对象而不公开相关IP。谢谢。--SCP-0000（留言） 2022年3月30日 (三) 15:56 (UTC)
“改成不能查核IP用户，也不能显示注册用户的IP和UA，每次只能查核某注册用户之间的关系，均为系统过滤后的结论”并不可行。用户查核工作面对的是多样且未知的情况，需要查核员接触尽可能多的原始信息，例如：
某一位疑似LTA的用户的某一笔编辑显示的IP位于北京，该IP不是校园、公司等共享IP；而另一位疑似LTA的用户5分钟后的另一笔编辑显示的IP位于广州，同样不是共享IP。那么查核员可以推断除非共享账号，否则两位用户几乎不可能是同一人。但
  1. 如果不是5分钟，而是5小时，那就有可能是这位用户坐飞机去了广州；
  2. 如果后者是校园网IP，那可能是一位在北京的用户，挂了广州某高校的VPN，这种可能性要进一步通过对该名LTA本身的了解来进一步证实或证否；
这些信息都是单纯的“查关系”所查不出来的。--Antigng（留言） 2022年4月6日 (三) 10:00 (UTC)
鄙人才疏学浅，感谢阁下提供宝贵意见，并作出详细解释！不怕查出注册用户的关系，只怕走上门骚扰维基人；随着资讯科技的进步，希望WMF研发工具，主要保障隐私安全，拆穿伪造民意的行为：计算地图上不同用户的时间、距离、位址移动，予查核员接触这些资讯，但不能查核IP和地理位置，请问是否可行？ --月都（留言） 2022年4月9日 (六) 03:35 (UTC)
绝对不可行，不能查核IP基本上等于将整个用户查核工具废了，而你提出“计算地图上不同用户的时间、距离、位址移动”只会给用户查核员提供如安亭所言的误导性资讯，完全不可行。--路西法人 2022年4月10日 (日) 05:54 (UTC)
用户查核就跟破案一样，涉及的不仅仅是“已知的未知”，更有“未知的未知”。作为管理人员我们甚至不知道未来会遇到怎样的案情，需要综合运用哪方面的信息，通过怎样推理得出什么样的结论——涉案人员并不总是按有限、既定的规律、套路出牌。要求查核员不接触IP就好像是要求探员不接触一手证据一样，这样根本没法破案。--Antigng（留言） 2022年4月11日 (一) 15:46 (UTC)
用户查核的学问较为艰涩。 --月都（留言） 2022年4月15日 (五) 16:10 (UTC)

就安全投票问题订立管理员选举暂行规定

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2022年5月17日 (二) 16:14 (UTC)。

第一阶段

已通过：
  • 本次投票以一人为限，以最早得到七票（参考WP:RFDA，提名票不直接算进票数，提名人的提名和投票取向不一定也不需要一致）者，而且合乎投票过程要求者的优先进行选举，其他的押后至下一次；
  • 候选人应清楚说明是否参选界面管理员，如需要选票上应该另有一条问题；
  • 选举的关键日期应该预先决定以方便安排投票；
  • 讨论、提问的时间规定在14天，以得满足提名条件且得行政员确认一刻起算作14天，14天结束后候选人依然可以回答问题，但不应该再展开讨论，也不应该提出新问题；
  • 投票时间起始点可以视乎准备人员需要提前或延后，讨论时间不应该因此增加或减少；
  • 参与准备工作的人员没有被选举权，但可以投票。
Ghren🐦🕗 2022年4月14日 (四) 12:53 (UTC)
下列讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

社群日前进行投票表决通过，决定“在未来一场管理员选举使用安全投票（SecurePoll）”。考虑到选举提名与安全投票开启之间具有时差，现请社群就选举日程，包括讨论期间、投票期间等面向订立暂行规定，优先于既有之申请成为管理人员指引。—— Eric Liu 创造は生命（留言．留名．学生会） 2022年1月5日 (三) 14:18 (UTC)

我这里写个草案吧。考虑到农历新年和动员令社群会比较忙，本次算是一次比较大型的选举，选举宜在二月下旬至七月进行。考虑到目前的站务积压，目前应该以管理员数量为首要目的，毕竟最积极的虫虫飞消失了，其他WP:OA2021中被除权的9位也有相当的贡献，理论上先提名曾任管理的用户比较容易得到共识。而针对Spoll的数目而言，我个人认为一次应该避免超过5个以避免影响社群同时要关注过多的投票。因此大致草案如下：
2月15日-2月22日：曾任管理员者可以优先被提名。超出5个则暂时冻结。
2月22日起：假如提名者不足5个一般合Rfa要求者也可以参与。
2月22日-3月22日：对候选人作出提问，社群讨论候选人是否合适。
3月22日至3月29日：开启Spoll让社群进行投票。（两周或者提前开启也可，另议。）
3月29日后：行政员再按投票结果得出结论。同时再考虑准备下一回的投票。4月至7月其间可以再进行另一场Rfa。
此外，也有其他问题，以此Securepoll而言，延长投票似乎不太实际。而且中立的票也难作考虑。故此可能要设立一个比较固定的标准，按以往近80%则延长投票的做法较难实行。--Ghren🐦🕐 2022年1月5日 (三) 17:55 (UTC)
此外一票两投IA也是个问题。以往可以用文字说明支持IA但不支时Admin，但SPoll不能做到这点。--Ghren🐦🕐 2022年1月5日 (三) 17:57 (UTC)
这样的话能不能分开spoll？有意愿选界面的话多开一个，分开两边投。--AT 2022年1月5日 (三) 18:20 (UTC)
这很简单，若当事人要选界面管理员，增设一问题即可。 —— Eric Liu 创造は生命（留言．留名．学生会） 2022年1月5日 (三) 18:31 (UTC)
见下。—— Eric Liu 创造は生命（留言．留名．学生会） 2022年1月6日 (四) 07:22 (UTC)
RfA已经不能兼RfIA了吧 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月6日 (四) 04:01 (UTC)
请注意投票结果是“未来一场”。多于一人参与会面临要适用安全投票抑或一般投票方式的问题，且可能超出社群投票效力之范围。故此仅建议以一人参与的情况来决定日程，这里指的不是绝对的行事历，而是相对的日数。之所以不直接决定往后采用，就是因为需要观察。其实当初投票应该不要写未来一场，而是写“未来半年”之类的或许比较弹性一点呀。—— Eric Liu 创造は生命（留言．留名．学生会） 2022年1月5日 (三) 18:28 (UTC)
作为参考，目前的管理员选举，讨论与投票并行，为期共十四日。在尊重既有制度、不改变实际选举时长的情况下，个人有三种方案：
  1. 提名后立即开启讨论，为期七日，期间赶紧筹备安全投票，七日后开放投票，为期七日，总时长仍为十四日；（讨七，投七）
  2. 提名后立即开启讨论，期间赶紧筹备安全投票，七日后开放投票，但同时允许继续讨论，总时长仍为十四日；（讨七，讨／投七）
  3. 提名后立即开始筹备安全投票，期间不得进行任何讨论；安全投票开放后，同时开放讨论，二者并行，为期共十四日。（讨／投十四）
以上，请斟酌。—— Eric Liu 创造は生命（留言．留名．学生会） 2022年1月5日 (三) 18:36 (UTC)
筹备安全投票本身大概需时多久？--AT 2022年1月5日 (三) 18:38 (UTC)
或许@1233会清楚？—— Eric Liu 创造は生命（留言．留名．学生会） 2022年1月5日 (三) 18:45 (UTC)
我认为提名期和投票期搞得太紧安全投票会过于难安排。提名后不得讨论也过于高估社群的自制力。我认为投票期延长为妙。上次实际上也是延期了一周左右。当然事前预备好不是不行。但我认为安全投票的制度当初就有建议一年两场之类的意思，单纯选一个管理出来似乎效率有点低，总不行一年只出两个管理。--Ghren🐦🕗 2022年1月6日 (四) 00:20 (UTC)
七天搞起一个Spoll只怕也太难了，单是整理一份当时有人事任免资格的名单也已经用时甚久。假如共识认为一年两场Spoll是比较合理的，日后的方案理论上应该往这个方案走，虽然这个共识没有约束力。单问个人而言我认为第一届还是合并数人举行为好，但是作为第一次投票作为实验性质也可以。--Ghren🐦🕗 2022年1月6日 (四) 00:46 (UTC)
那么就是当初投票问题设计得不好了。为避免争议，下一次选举最好还是仅推举一人。—— Eric Liu 创造は生命（留言．留名．学生会） 2022年1月6日 (四) 07:22 (UTC)
@Ericliu1912，这东西其实是没有任何的标准的，但是细节是可以讨论的。
我认为提名后就要筹备安全投票。期间应该是可以讨论的。（禁止讨论其实不切实际）。
反而投票的期间则应该仍然固定为十四天，而讨论则可以在开始前继续。另外，我认同一次选举可以牵涉不同的人选，而不需要像现在那样，一次选举能投票给一位候选人。（可能是投票给两至三位候选人）。
然后“整理一份当时有人事任免资格的名单”的问题其实不难解决，可以使用python或php等不同的方式整理就可，就像是这次的投票。而且该段code理应是可以重用的。--1233 （T / C） 2022年1月6日 (四) 03:24 (UTC)
遇上圣诞假期或是跟其他wiki投票冲突搞不好要推迟超过14天。--Xiplus#Talk 2022年1月17日 (一) 13:53 (UTC)
窝都可以，三个方案看要哪个社群决定好就好，不要又在那这不行那也不行。--~~Sid~~ 2022年1月14日 (五) 15:52 (UTC)
如果社群认同投票不能代替讨论的话，应强制讨论开始一段时间后才开始投票，让大家都能透过讨论更加认识候选人。--Xiplus#Talk 2022年1月17日 (一) 13:57 (UTC)
同意。禁止讨论怎么看怎么不现实。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月14日 (五) 15:57 (UTC)
不如直接邀请他人他人提名/推荐，然后同时搞管理员/用户查核员的SecurePoll，然后提名7天，讨论7天/投票14天？（提名和投票期需要大约三天以准备投票人列表及问题），然后主页面为WP:投票/2022年第一次安全投票。--1233 （T / C） 2022年2月2日 (三) 08:10 (UTC)
2022年社群愿望清单调查中与此案相关之愿望，大家可以去看看。—— Eric Liu 创造は生命（留言．留名．学生会） 2022年2月2日 (三) 15:17 (UTC)

现在的最大问题在于我们无法预期安全投票筹备要多久。—— Eric Liu 创造は生命（留言．留名．学生会） 2022年2月10日 (四) 11:25 (UTC)

所以我才提议预先指定一个提名日子，筹备安全投票的时间有太大风险。指定了就能解决所有问题。--Ghren🐦🕖 2022年2月10日 (四) 11:41 (UTC)
不就是吗，而且还可以顺便在同一时间搞CU的选举--1233 （T / C） 2022年2月11日 (五) 13:53 (UTC)
根据他站社群（英维及波斯语维基百科）在去年于监管员布告版请求监票之情况，他们在投票开始前（并非提名期开始前）大约一个月，已作出相关请求，可推断开始投票前一个月便需作筹备。再者他们的选举为定期进行，故如非定期进行可能需时更多。另可参考波斯语维基百科过往的筹备时间表。谢谢。--SCP-0000（留言） 2022年2月11日 (五) 14:54 (UTC)

抱歉，但目前这个议案己经放置在这一个月有余但讨论依然不足，我唯有按波斯语维基百科过往的筹备时间表，再加上上方的一些共识写一个流程写出来：

  • D-Day：提名开始
  • D+3：候选人如不合条件则重新开始
  • D+7：选举设置（导入名单、votewiki改为中文）
  • D+10：投票期（发垃圾信息）
  • D+24：投票结束（改回其他语言、点票）

此外尚有数点：

  • 本次投票以一人为限，以最先得到提名而且合符投票过程要求者的优先进行选举，其他的押后至下一次；
  • 候选人应清楚说明是否参选界面管理员，如需要选票上应该另有一列；
  • 选举的关键日期应该预先决定以方便安排投票。

大概是这样。Ghren🐦🕖 2022年2月14日 (一) 11:32 (UTC)

RfA已经不能兼RfIA，其余支持。 ——魔琴 [ 留言 贡献 ] 2022年2月14日 (一) 13:10 (UTC)
已经准备好投票页面，细节待填。—— Eric Liu 创造は生命（留言．留名．学生会） 2022年2月14日 (一) 15:04 (UTC)
@Ericliu1912：现在依然以提出问题为宜。假如基金会对CU的要求是14天投票，其实管理另外再以七天制并不好。假如担心过长的投票期使提名人辛苦的话可以另设冷静期。Ghren🐦🕐 2022年2月15日 (二) 05:20 (UTC)
问题是基金会上次发了那则讯息以后就一点影子都没有，不知道他们要做什么。—— Eric Liu 创造は生命（留言．留名．学生会） 2022年2月15日 (二) 06:30 (UTC)
基金会是积极不干预政策吧？但是本身Rfa其实本身都没有太多细节可以安排吧。--Ghren🐦🕒 2022年2月15日 (二) 07:19 (UTC)
安全投票的话，要不要发通知应该是最紧要的？除此之外要投票投几天，支持率要多少，也要斟酌。—— Eric Liu 创造は生命（留言．留名．学生会） 2022年2月18日 (五) 06:37 (UTC)
支持率按惯例是80%。通知按其他维基做法只要公平即可，但是只为一个维基人选举的发通知有些少拉票的感觉。投票似乎共识为14天。--Ghren🐦🕛 2022年2月18日 (五) 16:28 (UTC)


那暂定提问期为21日，留三日让候选人回答？—— Eric Liu 创造は生命（留言．留名．学生会） 2022年2月24日 (四) 13:05 (UTC)

21天会不会过长了？我担心累死候选人了。我没什么所谓，毕竟回答与不是候选人的自由。--Ghren🐦🕘 2022年2月24日 (四) 13:14 (UTC)
@BlackShadowG@SCP-2000@Ericliu1912@Temp3600@AT。对于提问日数有什么看法？--Ghren🐦🕐 2022年2月25日 (五) 05:40 (UTC)
那再缩短总时程，同时削减讨论与提问时间？我记得之前不少人支持三周方案之类的。—— Eric Liu 创造は生命（留言．留名．学生会） 2022年2月25日 (五) 10:49 (UTC)


我认为太长，14天投票+讨论就好。--AT 2022年2月26日 (六) 05:38 (UTC)
这样？—— Eric Liu 创造は生命（留言．留名．学生会） 2022年2月26日 (六) 06:58 (UTC)


对。--AT 2022年2月26日 (六) 08:20 (UTC)
慢著，提问期可以再缩短些，投票期再延长点。例如5+10。--AT 2022年2月26日 (六) 08:21 (UTC)
这里或许应该定义一下“提问”。在既有问题“之上”追问是否算是提问？如果追问也算是提问，那提问期可能要拉长一点。—— Eric Liu 创造は生命（留言．留名．学生会） 2022年2月26日 (六) 09:24 (UTC)
为什么要减少投票时间？这样的话又会有人投诉为什么不延长投票时间之类的话了，而且和CU和其他站的习惯也不一致，我看不到有很大动机去做。--Ghren🐦🕓 2022年2月26日 (六) 09:55 (UTC)
那要视乎什么时候回答提问。另外，不能提问和投票均同时是14天吗？--AT 2022年2月26日 (六) 10:24 (UTC)
将图2的版本改成14天就可以达成你的需要吧。--Ghren🐦🕖 2022年2月26日 (六) 11:05 (UTC)
另外我记得1233不知道在那个tg群说只少要一周的时间，不能再缩了。--Ghren🐦🕖 2022年2月26日 (六) 11:12 (UTC)
这是在临时提出来的情况下吧，不是说要选定一段期间举行选举了吗？—— Eric Liu 创造は生命（留言．留名．学生会） 2022年2月26日 (六) 11:46 (UTC)
我不敢肯定，但是时间越长总是越好的。@1233--Ghren🐦🕘 2022年2月26日 (六) 13:05 (UTC)
如果不选定一段时间举行选举，以上全部方案都难以确保能够施行。我自己也拟过一堆方案，想了半天，还是跨不过这个坎。—— Eric Liu 创造は生命（留言．留名．学生会） 2022年2月26日 (六) 16:25 (UTC)
这样的话其实现在就可以去监管员布告板找人了。反正有个固定日期定了出来，之后到D Day的时候填个人名就可以了。投票开始和投票讨论时间其实不会差得很远吧。--Ghren🐦🕛 2022年2月26日 (六) 16:45 (UTC)
现在的问题是我们连方案什么时候能乔好都不一定，何况去找监管员。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年3月13日 (日) 10:59 (UTC)
其实只需要依旧投14，讨论14，达到方针原意就可以了。现在的情况可以达到这个目的，就不用改方案了。--Ghren🐦🕖 2022年3月13日 (日) 11:04 (UTC)
让用户自选时间，已经“应战”得很吃力，如果是规定用户在选举期活跃，则必须缩减选举本身的规模。--Temp3600（留言） 2022年3月13日 (日) 12:05 (UTC)
我呼吁社群关注限制RfA提问的提案，否则提问时间的制定总会在“不能及时知道”和“候选人负担太重”之间弹来弹去。 ——魔琴 [ 留言 贡献 ] 2022年2月26日 (六) 15:25 (UTC)
目前SecurePoll即将支持在投票时附加上可选的理由，中文社群可以考虑加上这一功能。 Stang★ 2022年3月2日 (三) 17:26 (UTC)
‘可选的理由’会否让投票变成明票?--Temp3600（留言） 2022年3月13日 (日) 12:00 (UTC)
@Temp3600： 可参考UCoC投票，他们会将理由整合成摘要来避免辨识投票者的身份，理由只有监票员才可看到。--SCP-0000（留言） 2022年3月18日 (五) 08:39 (UTC)

所以现在有没有任何可行的方案？我想我们需要先决定是否指定一段期间进行选举（即不允许随时展开），然后再据此决定时程。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年3月23日 (三) 16:41 (UTC)

达成目前讨投14的目的的话，随意即可。日期就随意定为4月15号吧，反正这个日期具体来说什么日子也没所谓。--Ghren🐦🕐 2022年3月23日 (三) 17:19 (UTC)
不能随意定，还要给社群时间提名人选。但我估计大家不可能只推选一个人，这样得怎么办？—— Eric Liu 創造は生命（留言・留名・学生会） 2022年3月23日 (三) 20:49 (UTC)
还要找合适的人选。--Lanwi1(留言) 2022年3月23日 (三) 22:02 (UTC)
现在的问题时没有人想选（--1233 （T / C） 2022年3月29日 (二) 13:04 (UTC)
这不是问题。相信我。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年3月29日 (二) 15:47 (UTC)
这也不过是提前数天要求候选人要拿到一定的提名而己，然后不只一个人的话就只对最先得到足够提名人数进行投票即可。我觉得实行上有很多种方法，然后实际上每一种差别实际上都不大，社群不应该为这些末节打转三个月。--Ghren🐦🕙 2022年3月24日 (四) 02:45 (UTC)
  • 本次投票以一人为限，以最先得到提名而且合符投票过程要求者的优先进行选举，其他的押后至下一次；
  • <s提名时间最早者或者；
  • 抽签；
  • 最早得到七票（参考WP:RFDA）者，但提名票不直接算进票数，提名人的提名和投票取向不一定也不需要一致；
  • 候选人应清楚说明是否参选界面管理员，如需要选票上应该另有一列一条问题；
  • 选举的关键日期应该预先决定以方便安排投票；
  • 讨论、提问的时间规定在14天，以得满足提名条件且得行政员确认一刻起算作14天，14天结束后候选人依然可以回答问题，但不应该再展开讨论，也不应该提出新问题；
  • 投票时间起始点可以视乎准备人员需要提前或延后，讨论时间不应该因此增加或减少；
  • 参与准备工作的人员没有投票权（应该要避嫌吧？）被选举权。Ghren🐦🕛 2022年3月29日 (二) 16:48 (UTC)
不给被选举权我觉得就可以了。--1233 （T / C） 2022年3月31日 (四) 13:28 (UTC)
我倒是没有所谓。--Ghren🐦🕙 2022年3月31日 (四) 14:38 (UTC)
如果没有意见的话，就按“最早得到七票”、“参与准备工作的人员有投票权但没有被选举权”的方案在3天后公示就好了。--Ghren🐦🕓 2022年4月3日 (日) 08:44 (UTC)
RfA已经不能兼RfIA了……要我说多少遍…… ——魔琴 [ 留言 贡献 ] 2022年4月3日 (日) 08:58 (UTC)
@魔琴似乎最初的目的之一是因为计票困难，但是在SPoll情况下根本不可能有计票困难的情况？我觉得现行情况下似乎不需要分开，但是假如是基于速速通过的概念上，我也不介意先放一边。--Ghren🐦🕓 2022年4月3日 (日) 09:39 (UTC)
可也。那就是四栏“IA+A”“A”“N”“O”？ ——魔琴 [ 留言 贡献 ] 2022年4月3日 (日) 10:01 (UTC)
应该是
Admin：同意 中立 反对
IA：同意 中立 反对
这个样子吧，可以提供自由度让选民反对其中之一，或支持其一。--Ghren🐦🕕 2022年4月3日 (日) 10:09 (UTC)
哦对，我忘记了IA可以不是A。那加的应该是一行不是一列。 ——魔琴 [ 留言 贡献 ] 2022年4月3日 (日) 10:11 (UTC)
啊，地域词地域词，反正就是横行或者横列的意思（列_(数据库)） 囧rz……。--Ghren🐦🕕 2022年4月3日 (日) 10:42 (UTC)
啊呀，我不知道这也是地区词（ ——魔琴 [ 留言 贡献 ] 2022年4月3日 (日) 11:06 (UTC)

公示

  • 本次投票以一人为限，以最早得到七票（参考WP:RFDA，提名票不直接算进票数，提名人的提名和投票取向不一定也不需要一致）者，而且合乎投票过程要求者的优先进行选举，其他的押后至下一次；
  • 候选人应清楚说明是否参选界面管理员，如需要选票上应该另有一条问题；
  • 选举的关键日期应该预先决定以方便安排投票；
  • 讨论、提问的时间规定在14天，以得满足提名条件且得行政员确认一刻起算作14天，14天结束后候选人依然可以回答问题，但不应该再展开讨论，也不应该提出新问题；
  • 投票时间起始点可以视乎准备人员需要提前或延后，讨论时间不应该因此增加或减少；
  • 参与准备工作的人员没有被选举权，但可以投票。

🕗 公示7日。Ghren🐦🕐 2022年4月7日 (四) 05:30 (UTC)

本讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

第二阶段

已解决
指引修正草案通过。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年5月14日 (六) 16:04 (UTC)
下列讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

这边有两个建议：一、建议删除“其他的押后至下一次”：此次选举应当独立于日后之选举，采用“排队”制度徒生枝节；二、建议删除“参与准备工作的人员没有被选举权，但可以投票”：从上方讨论结果看来，没有必要做此限制。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年4月14日 (四) 12:55 (UTC)

另外看起来通过的只是大纲，还得讨论具体如何修订申请成为管理人员指引。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年4月14日 (四) 13:14 (UTC)

要求就此案作出部分细化规则的讨论，尤其是投票资格的部分。以现有方针而定，所有符合“解任投票联署提出或上任投票开始120天前，编辑至少500次；并在联署提出或上任投票开始前90天内至少有1次编辑（不包括任何用户页及用户对话页）”及“编辑至少3000次，或编辑条目至少1500次”两项条件之一的用户即可进行投票。然而，昨天跟其他维基人讨论的时候发现一个现有规则与安全投票实行之间的BUG，就是在旧有制度下，'被禁制编辑维基百科空间的用户（包括被封禁）因不能编辑投票页面而无权投票，但在接下来的安全投票中没有相关规定，未有任何规则明文规定阻止被禁止或封禁用户进行投票或不计算他们的投票，是为严重投票规则漏洞，不应因实行安全投票而让本身不可能投票的用户进行投票或灌票影响投票结果。@Ericliu1912、Ghrenghren：两位昨天跟我在站外的讨论中已经听过我提出这个了，另外再ping@Temp3600、BlackShadowG、魔琴、SCP-2000、AT、Stang、1233。--路西法人 2022年4月15日 (五) 14:33 (UTC)

(＋)支持禁止被封用户参与安全投票，禁制的话需要再考虑一下范围，例如仅限于被禁制编辑WP空间的用户。--AT 2022年4月15日 (五) 15:35 (UTC)
上面的讨论：我认为参与准备工作的用户应当自愿放弃被选举的权力（或者直接由管理员组织选举）。
另外其他讨论我是同意结论的：谁能够实质在管理员选举中投票，才能够在securepoll投票。--1233 （T / C） 2022年4月15日 (五) 15:37 (UTC)

Ghrenghren、​AT、​魔琴、​Xiplus和BlackShadowG1233、​Yining Chen、​SCP-2000、​Temp3600和StangLanwi1经过检视，建议在申请成为管理人员指引“流程”一节下增加“安全投票暂行规定”一节，说明扞格情形：

提议条文

执行结果 （略）

安全投票暂行规定 根据社群2021年12月的共识，未来一场管理员选举将使用安全投票（SecurePoll）系统。

未来一场使用安全投票系统的管理员选举将按照以下程序进行，不适用前述之一般流程：

  1. 提名或自荐：使用者可以提名自己为管理员，也可以提名另一个使用者为管理员。
  2. 检验冷静期：当管理员被提名者先前之管理员选举未通过或中途退选时，自投票终止或退选之时起，三个月（90日）内不应再次提出申请。在表态时谢绝提名者不受此限制。
  3. 投票过程：
    • 预提名：由于未来一场选举之被提名者以一人为限，应当在互助客栈其他区集中进行预提名作业；愿意接受正式提名并回答前述三个基本问题、最先得到七位具人事任免投票资格之使用者连署支持，且符合成为管理员之资格者，经行政员确认，即获得正式提名，将优先进行选举，并应比照前述之一般流程另行设置个人选举页面。若最先获得足够连署支持者未能符合前述要求，则应依序递补以决定获正式提名者。
    • 发表意见：在被提名者经行政员确认获得正式提名之时起二周内，任何使用者都可以发表意见，包含提问及讨论等。二周后，被提名者仍可以回答问题，而其他使用者则不应再提出新问题或继续展开讨论。与此同时，应尽速筹备安全投票。投票时间之起始点可以视乎实际准备情况需要提前或延后，惟发表意见之时间长短不应有所增减。
    • 投票：安全投票开启后，应至少持续二周，并应有至少二位管理人员与其他监管员共同协助监票。具人事任免投票资格，且在被提名者经行政员确认获得正式提名之时未被封锁或禁制编辑维基百科命名空间的使用者可以投下支持票、反对票或中立票。投票期间，投票者可以随时改变自己的决定，其态度按投票截止时为准。选举之有效票比照前述之一般流程仅包括上述可投票者所投的支持票及反对票，中立票属无效票，仅将在临界情况下被考虑。
    • 计票和评估：投票结束后，应由协助监票之管理人员计算出得票比率，并会同行政员根据前述之一般流程标准判断投票是否达成共识。
    • 执行结果：若投票通过，行政员或监管员将赋予被提名者管理员权限；不通过则做出相应的操作。

以上，还请诸位斟酌。安全投票时程为暂定值，请确认是否要延长为十四日。此外，针对上方提到的参与准备工作人员之被选举权问题，解方是直接交由管理人员负责（实际上本来也就应该如此），这样就不用担心了。或者也可以比照此前之安全投票，由二位现任监督员（皆为管理员）与其他监管员共同监票。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年4月18日 (一) 05:58 (UTC)

“专门页面”是一人一页？似乎跟后述的“个人选举页面”是不同页面？为何不在同一页就好？或是比照解任投票在互助客栈连署？--Xiplus#Talk 2022年4月18日 (一) 07:13 (UTC)
“专门页面”是一个同时供多人连署之集体页面，“个人选举页面”则与之前一般流程格式相同。这是考虑到以往选举都是以个人为单位，才有此设置。预提名部分确实可以改成在互助客栈连署，这样就不用另设专门页面。已对草案进行相应修订。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年4月18日 (一) 08:11 (UTC)
那就直接规定在互助客栈连署吧？--Xiplus#Talk 2022年4月24日 (日) 02:31 (UTC)
已经调整草案内容。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年4月25日 (一) 05:19 (UTC)
“被提名者应清楚说明是否参选界面管理员”不适当，前面已有人提过2021年RFA指引修订，同时参选管理员跟界面管理员是两场选举而非一场选举，与“未来一场使用安全投票系统”违背。不然应要求管理员跟界面管理员的连署专门页面、个人选举页面应分开，但允许投票合并（以长远来看，如果有多人短期同时参选，容许合并投票的意思）。--Xiplus#Talk 2022年4月18日 (一) 07:20 (UTC)
Xiplus目前指引内仍然有提到“一票两投”制度，如此看来是一场选举决定是否赋予两个权限。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年4月18日 (一) 08:06 (UTC)
看起来是当初修订时遗漏那一段了，哎呀。已经删除草案中相关内容，至于指引相关内容也应该需要删除。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年4月18日 (一) 08:07 (UTC)
我理解当初是因为计票困难的问题，才引起了争议决定要分开，假如以Spoll不可能有计票困难的问题，应该拆分的理由不存在。如此看来单独以一次投票只选出一个管理员也太没有效率。Ghren🐦🕕 2022年4月18日 (一) 10:53 (UTC)
当初投票之问题决定确实是过于仓促。这教训相信您我都记得了。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年4月18日 (一) 12:26 (UTC)
预提名通过，或者不通过算是算冷静期之内，我个人认为应该不算。而且目前“与此同时，应尽速筹备安全投票”一句的意思也就是先有预提名的程序，然后再筹备安全投票的意思？--Ghren🐦🕒 2022年4月18日 (一) 07:24 (UTC)
预提名顾名思义并非正式选举，自然不算入往后选举之冷静期；基本是这样。当然也可以现在就开始筹备投票，但时程则较难预料。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年4月18日 (一) 08:11 (UTC)
如果不计入冷静期，将无法阻止反复进行预提名。--Xiplus#Talk 2022年4月18日 (一) 08:35 (UTC)
这次预提名也就只办一次吧。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年4月18日 (一) 08:54 (UTC)
那本次预提名失败后是否能立即启动另一个正式（旧版/现行）选举？--Xiplus#Talk 2022年4月18日 (一) 10:05 (UTC)
我本来的的建议就是押后至一下场选举，不然每次都重复预提名，程序复杂，而展开下一场选举的问题，假如社群缺乏共识的话，直接以Spoll一场一场办，或者回归旧版似乎也不是确切而好的方案。应该是社群有共识的话再继续为宜。当然我不相信社群可以短时间内有共识。--Ghren🐦🕕 2022年4月18日 (一) 10:49 (UTC)
您没有回答到我的问题，我说的是预提名拿不到7票的人是否就是提名失败？然后提名失败又不计入冷静期，而Spoll只进行一次，所以之后（在新规未出来前）回归现行选举规则，那是否可以直接发起新的现行选举？--Xiplus#Talk 2022年4月18日 (一) 12:09 (UTC)
我理解的是，即使预提名拿到7票，如果前面己经有合适的人选得到行政员认可，依然是预提名失败。因此，应该是说，没有实际进行投票的用户不应该开始算他们的冷静期。如果是这样的话，只要社群重新煮个方案出来，这些用户重新参与RFA应该是没有问题的。--Ghren🐦🕘 2022年4月18日 (一) 13:01 (UTC)
另外在新规则出来前Spoll只进行一次，所以“押后至下一场选举”也不存在，其余预提名非最先达到7票者都应该是直接转换成现行选举制。--Xiplus#Talk 2022年4月18日 (一) 12:11 (UTC)
意见(▲)同上。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年4月18日 (一) 12:17 (UTC)
这是暂行规定，此次选举结束后，观其成效，再行表决是否正式采行安全投票。未来选制也可能不同（考虑到此次限制重重，大概肯定会不同），所以才建议此次选举独立，不与未来之选举相干涉。坚持押后，将造成许多无谓之程序问题。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年4月18日 (一) 12:20 (UTC)
你说得也不无道理，对于上述修订没有保留“押后至下一场选举”没有特别的意见。--Ghren🐦🕗 2022年4月18日 (一) 12:57 (UTC)
我认为预提名不必受冷静期限制，一方面此与正式提名不同，一方面这次只选一人，若强行对他人施加冷静期，可能对参选意愿起反面作用。但相对地，在社群表决采行安全投票与否之前的空窗期，也不应该立即进行额外的常规选举。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年4月18日 (一) 12:23 (UTC)
我前面的意见都是以多次执行Spoll为考量，如果举行一次Spoll后，如果条文会重新拟定的话，这个问题我可以那时候再提出。--Xiplus#Talk 2022年4月18日 (一) 13:20 (UTC)
"反复进行预提名"在本次试验选举的问题应不大，估计参选的位子会直接被替补掉。--Temp3600（留言） 2022年4月18日 (一) 13:38 (UTC)
回归旧版不算是一个很好做法。--Temp3600（留言） 2022年4月18日 (一) 11:07 (UTC)
Temp3600？—— Eric Liu 創造は生命（留言・留名・学生会） 2022年4月18日 (一) 12:17 (UTC)
我指下下次选举的选制。--Temp3600（留言） 2022年4月18日 (一) 13:30 (UTC)
预提名是否也可能存在拉票问题？--Yining Chen（留言|签名页） 2022年4月23日 (六) 13:44 (UTC)
预提名的票数按理是不应该算在票数里，而且应该是够七票就马上停止提名，应该没什么拉票动机。--Ghren🐦🕙 2022年4月23日 (六) 14:07 (UTC)
希望正式投票的时长能延长到14日，可以给更多周活跃用户思考投票的机会。另外，预提名有时长需求吗？比如最长14天？--50829! Talk · 496,625,183 2022年4月25日 (一) 03:47 (UTC)
已经调整草案内容；至于预提名时长应该没有需要强制规定，就顺其自然地举行吧。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年4月25日 (一) 05:19 (UTC)
应该是只进行两周，不多不减比较好，不然有对其他候选人不公之感。--Ghren🐦🕐 2022年4月25日 (一) 05:24 (UTC)
是在互助客栈/其他中进行预提名吗？--50829! Talk · 496,499,192 2022年4月26日 (二) 14:47 (UTC)
哪个候选人愿意当实验品啊？--Lanwi1(留言) 2022年4月27日 (三) 04:26 (UTC)
所以我才觉得预提名时长应该是“至少二周”，不设置上限，以免经过二周了仍然得不出人选。至于地点，互助客栈其他区应该就行了，我已修正草案。其实我也可以当实验品啊XD —— Eric Liu 創造は生命（留言・留名・学生会） 2022年4月27日 (三) 04:42 (UTC)
先等相应方针讨论完了再找候选人也不迟吧。--50829! Talk · 496,375,715 2022年4月28日 (四) 01:05 (UTC)
@Lanwi1：如果没人愿意当实验品，可以拿我去当。--~~Sid~~ 2022年5月2日 (一) 14:28 (UTC)
愿意当实验品的人也有我……也希望互动。--Lanwi1(留言) 2022年5月3日 (二) 04:52 (UTC)
看来决定谁当试验品还需进一步讨论，甚至需要举办一次竞选了 囧rz……--50829! Talk · 495,556,801 2022年5月7日 (六) 12:34 (UTC)
那啥，这不就是预提名的作用吗XD
不过，倒是可以尝试引进英维的管理员申请咨询制度（或可称作“假投票”），这种制度可供有潜力之候选人试试水温，并从社群看法中找出自身可改进之处。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年5月7日 (六) 16:57 (UTC)
个人选举页面还是设置在Wikipedia:申请成为管理人员的子页面吗？--50829! Talk · 496,375,237 2022年4月28日 (四) 01:13 (UTC)
没错，这就跟过往一样。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年5月3日 (二) 01:00 (UTC)

@Ericliu1912：如无其他问题，最后一次对条文修订之日是4月25日，超过了7天之限，可以公示。Ghren🐦🕐 2022年5月7日 (六) 17:14 (UTC)

公示草案七日。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年5月7日 (六) 17:15 (UTC)
通过。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年5月14日 (六) 16:04 (UTC)
本讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

规范人事任免投票的提问环节

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2022年6月9日 (四) 08:14 (UTC)。

原标题为：限制RFA提问数量

限制提问数量提案

为应对暂行安全投票的日程安排问题，拆分自管理人员选举制度改革。原提案者User:Ericliu1912。

修订申请成为管理人员指引内容如下：

现行条文

参与方式 管理人员提名需要经过14天（即两周）的投票。具人事任免投票资格的使用者可以投支持票、反对票或中立票，也可以仅发表意见、向候选人提问（候选人有权决定是否作答）。投票后票数会自动更新，如果发现错误可至此处手动更正票数。

提议条文

参与方式 管理人员提名需要经过14天（即两周）的投票。具人事任免投票资格的使用者可以投支持票、反对票或中立票，也可以仅发表意见、向候选人提问（候选人有权决定是否作答）。就提问而言，每人最多可提问二题，并允许就提问开展相关讨论；超过额度者，其问题将被直接删除。禁止以多重问题或“小题”形式绕过限制，这样将被视为游戏维基规则。投票后票数会自动更新，如果发现错误可至此处手动更正票数。

鉴于原提案讨论中没有对提问数量限制提出明确的反对意见，故🕗 公示7日，2022年3月6日 (日) 02:02 (UTC) 结束。--Steven Sun（留言） 2022年2月27日 (日) 02:02 (UTC)

我想说中维的RFA问题和英维的问题根本是完全不同。中维的问题一向就是以快问快答的形式，问题短，答案也短。至现今的RFA，只有极少的参与者是真的可以做到只问两条问题。然后，即使是不作制止，候选人依然去回答问题与否。以两题的方式根本很难让一个投票者去了解候选人本身，毕竟问一下会否活跃，选不选介管己经是两条问题。我是想说，就算设这些限制，只是想问问题的人只会转到Talk Page、电邮、TG其他地方问，然后这些情况就更难掌握。对于我而言只是削足适履的方案。此外，像User:Carrotkit/猴子孵育场这些应该怎样算。这是六个分题，还是只是一个大问题？--Ghren🐦🕐 2022年2月27日 (日) 05:33 (UTC)
  1. 候选人一般为社群较为活跃用户，在提名前社群一般就对候选人有大体的了解。不需要通过大量提问去从头了解候选人。况且问太多的低质问题，尤其是那些与维基百科无关的问题，同样也干扰投票者对候选人的认识。
  2. 本指引应只限制投票页的提问数量。在其它地方提问只要不违反其它相关指引及方针即可（以前社群也没有在其它地方提问的习惯，而且不少人的讨论页也不经常回复别人）。但不能在投票页为其他页面的提问引流，否则视为绕过限制。--Steven Sun（留言） 2022年2月27日 (日) 08:13 (UTC)
    实际上当然是较为活跃的才可以被社群支持，但是提名本身是深入了解主张的行为。很多候选人没有很具体的用户论述，引致候选人虽然在某一方（比如专心在条目的用户）很出色，但是对站务的主张却可能不太具体的，只靠两条发问实在难而得知具体立场。引流视作绕过规定基本上就只能(－)反对到底了。我想说低质问题就不应该回答。--Ghren🐦🕓 2022年2月27日 (日) 08:23 (UTC)
那得问多少题？几百题是太过分了，你“问清楚”候选人的时候他也差不多要退选。引流这种“解压缩”手段也是不怎么可取，表面上一两题，事实上得造成候选人数倍的负担。—— Eric Liu 创造は生命（留言．留名．学生会） 2022年2月27日 (日) 15:52 (UTC)
(...) 吐槽你至少也丢个几天再公示吧 囧rz……--SunAfterRain 2022年2月28日 (一) 10:03 (UTC)
(－)反对，就之前管理员选举的情况来看很多人提的问题数量都远超两题，此提案显然不当。--🎋🎍 2022年3月1日 (二) 03:08 (UTC)
你这什么逻辑啊？因为之前很多人提的问题数量远超两题（我承认我也超过），所以现在提出限制每个人只能问最多两个问题。你的反对理据恰恰是这个提案要针对的问题；你自己说说，你这个反驳有效吗？--MilkyDefer 2022年3月1日 (二) 14:26 (UTC)
以人为单位其实换汤不换药，你用尽“配额”，还可以找人替你追问啊，只要不被识穿就行了。我懒得翻查原来的讨论纪录了，但去年我想过一个方案：限制问题的总数（当时设想是14条左右），设立小组/专员审查问题，然后从获批的问题抽签；也许还可以考虑禁止必答和选答的选项（三条必答题出外）。这样做对候选人负担说不定会比公示方案小，但问题是谁来审查。--春卷柯南－发前人所未知 ( 论功行赏 ) 2022年3月1日 (二) 09:56 (UTC)
供参考：Stewards organise the elections themselves... Therefore, stewards create an election committee for every election consisting of volunteers for the following tasks...，其中包括了划去不合要求的问题。 Stang★ 2022年3月1日 (二) 13:47 (UTC)
🕗 暂停公示。--Steven Sun（留言） 2022年3月1日 (二) 11:27 (UTC)
我觉得比较可行的做法是让社群意识到候选人拒绝回答不重要或有偏谬的问题的权利是绝对的（我不说候选人拒绝回答所有问题的权利是绝对的的原因是如果相关问题属于合理忧虑的话，我认为任何人都会想问，而且候选人的回答有助释疑）。Sanmosa A-DWY3 2022年3月3日 (四) 05:51 (UTC) +2
  • 被选人本来就有不回答问题的权利。问题是，怎样避免投票者因而投下反对票。--Temp3600（留言） 2022年3月17日 (四) 12:25 (UTC)
    根本不可能避免，尤其是假如改采安全投票形式的话，就更难以用投票理由判断投票有效程度。（加上筹备投票程序之复杂，我已经不怎么支持管理人员选举采用安全投票了）—— Eric Liu 創造は生命（留言・留名・学生会） 2022年3月17日 (四) 12:52 (UTC)
    倒不是不可能避免，但避免的方式可能会很极端：如果规定候选人只需要作答三个基本问题，并禁止任何人进行任何其他的非程序性提问，那投票人不可能因为候选人拒绝回答三个基本问题以外的问题而投反对票，因为他一开始的非程序性提问已经违反规则了。Sanmosa Avec cœur 2022年3月17日 (四) 13:52 (UTC)

规范问答环节提案

既然都+2了，我就提个反建议好了：

现行条文

参与方式 管理人员提名需要经过14天（即两周）的投票。具人事任免投票资格的使用者可以投支持票、反对票或中立票，也可以仅发表意见、向候选人提问（候选人有权决定是否作答）。投票后票数会自动更新，如果发现错误可至此处手动更正票数。

  • 谁可以投票：为了确保使用者对于维基社群的运作有一定了解，仅限于符合人事任免投票资格者才能参与投票。投票者请先阅读申请成为管理员的讨论中应避免的理由。
  • 谁不可以投票：未登录或未注册使用者，以及不符合人事任免投票资格的注册使用者不可以投票，非常新的使用者如果被怀疑是欺诈，如傀儡，则有可能会被视为无效票。
  • 加入你的投票：点击相关使用者的“在此投票”，并在相应的标题下签上你的名字，以表明你是支持、反对还是中立。与相应的标题相互矛盾的投票有可能被视为无效票。
  • 可以投中立票：中立票将不计算在有效票数中，但当投票结果处于通过标准的临界时（如支持25票，反对6票），行政员会在评估结果时考虑中立票。
  • 为你的投票做出解释：最好给出一个简短的原因，尤其在投反对票时。这样候选人及他人可以理解你的想法并给予答复。
  • 注意尊重所有人：有时对话双方可能愈来愈激动，甚至争吵起来。请记住，所有人都是有感觉、情绪和自尊的。
  • 讨论：详细的讨论请在意见区进行。任何人都可以讨论或发表意见，包括匿名使用者。
提议条文

参与方式 管理人员提名需要经过14天（即两周）的投票。具人事任免投票资格的使用者可以投支持票、反对票或中立票，也可以仅发表意见、向候选人提问。投票后票数会自动更新，如果发现错误可至此处手动更正票数。

  • 谁可以投票：为了确保使用者对于维基社群的运作有一定了解，仅限于符合人事任免投票资格者才能参与投票。投票者请先阅读申请成为管理员的讨论中应避免的理由。
  • 谁不可以投票：未登录或未注册使用者，以及不符合人事任免投票资格的注册使用者不可以投票，非常新的使用者如果被怀疑是欺诈，如傀儡，则有可能会被视为无效票。
  • 加入你的投票：点击相关使用者的“在此投票”，并在相应的标题下签上你的名字，以表明你是支持、反对还是中立。与相应的标题相互矛盾的投票有可能被视为无效票。
  • 可以投中立票：中立票将不计算在有效票数中，但当投票结果处于通过标准的临界时（如支持25票，反对6票），行政员会在评估结果时考虑中立票。
  • 为你的投票做出解释：最好给出一个简短的原因，尤其在投反对票时。这样候选人及他人可以理解你的想法并给予答复。
  • 注意尊重所有人：有时对话双方可能愈来愈激动，甚至争吵起来。请记住，所有人都是有感觉、情绪和自尊的。
  • 讨论：详细的讨论请在意见区进行。任何人都可以讨论或发表意见，包括匿名使用者。
  • 提问：任何人都可以向候选人提问，包括匿名使用者。请确保相关问题于维基百科或候选人在维基百科的活动而言属重要，而且并不存在任何不当预设的谬误，否则相关问题会造成候选人的困扰。候选人有权拒绝作答三个基本问题以外的一切问题，偏执要求候选人作答与维基百科或候选人在维基百科的活动无关或存在不当预设的谬误的问题可被视为扰乱。

以上。@Ericliu1912、Jonathan5566、ghrenghren、Steven Sun。Sanmosa Veritas Vincit 2022年3月9日 (三) 14:15 (UTC)

支持概念。提出以下较细化的提问规则：
提议条文

参与方式 ... 向候选人提问 在管理员选举中，候选人回答提问有助投票人作出是否支持此候选人成为管理员的决定。候选人自荐或接受提名时，需要回答三条基本问题（请见#流程一节）。除此之外，任何人都可以向候选人提出问题。为确保问题素质，防止程序被扰乱，问题应先在讨论页提出，若十二小时内未获合理反对并获得另一名具有投票权的用户支持提出问题后，则可转发至投票页面的提问区。每一名具有投票权的用户仅能支持或反对提出一条问题。提出的问题应当保持语调中立，不应明示或暗示投票立场，并应与维基百科或候选人于维基百科的活动相关，且不存在不当预设的谬误，以确保问答环节能作为一个具建设性的对话环境。候选人有权拒绝作答三个基本问题以外的一切提问，但建议（不强制要求）说明拒绝作答及原因。在候选人回应后追加延伸问题是可接受的行为，但追加的问题必须与原先问题及候选人的回答有关；候选人同样有权拒绝回应追加的问题。就要求候选人回应问题进行施压，包括但不限于以选票威胁回应[a]和在候选人明确表明拒绝作答时仍反复要求作答[b]等行为均可被视作扰乱程序的行为。

补充说明

  1. ^ “不回应我就投反对”等类似发言属于明确地以选票作出威胁要求候选人回应，此等行为是不被容许的。另，仍不建议作出“候选人的回答会影响我的投票决定”等虽礼貌但对问题无作用且稍有施压意味的发言，这些发言对于问答没有任何作用，是不需要明示的。
  2. ^ 您可以作出一次简单、礼貌地回应请求（例：希望候选人能回答有关问题）。然而，尤其在候选人已经表明不想回应的时候，无论您的发言多么礼貌，不断、重复地作出有关要求也可能会有施压的意味，请避免反复要求回应问题。
@Sanmosa：看看这样会不会对各方都更加友善？--路西法人𖤐 2022年3月10日 (四) 03:46 (UTC)
@LuciferianThomas：我还是如之前说的一样：我不说候选人拒绝回答所有问题的权利是绝对的的原因是如果相关问题属于合理忧虑的话，我认为任何人都会想问，而且候选人的回答有助释疑。如果社群合理地认为某问题于维基百科或候选人在维基百科的活动而言非常重要，而且将会影响维基百科日后的运作情况，我认为任何一个或多个社群成员要求他回答是合理的，这种情况应当排除于“偏执要求作答”的情形外。我不反对禁止“威胁作出回答”，但我还是想就“威胁作出回答”的定义请求澄清：假如我提问时表示“候选人的回答会影响我的投票决定”（对，这就是原话）的话，这算是“威胁作出回答”吗（我自己觉得这个措辞应该算是委婉）？Sanmosa Veritas Vincit 2022年3月10日 (四) 07:57 (UTC)
“候选人的回答会影响我的投票决定”不算威胁，确实符合中立语调也起码算是礼貌，不过仍稍有施压意味（我本来好像不是想写威胁而是施压，不过我当时想不起这个词 囧rz……）。个人不建议说出来，因为这一句是没有意义的，也不是给候选人的提问。
让RFA不要成为一个toxic的环境是为此修订的重点。关于社群要求作答的部分，如果候选人拒绝回答就没有不断要求作答的必要了，反正也不见得会改变到候选人的主意。其实我的写法反而是想强调RFA提问的礼仪，而不是限制这个限制那个。礼貌地在讨论中提到“希望能回答有关问题”的问题不大，但就算是多礼貌的说法，重复就会造成施压，这才是我这个提议条文重心要避免的情况。候选人拒绝回答某些问题或在拒绝回答时是否提出合理理由应足以影响投票人的意见，施压是完全不必要的行为。--路西法人𖤐 2022年3月10日 (四) 09:53 (UTC)
这样说好像也是。而且，就算没有施压的意味，“候选人的回答会影响我的投票决定”这句话其实也形同废话，因为就算提问人不说，候选人的回答本来就是大家的投票决定的合理影响因素之一（除非投票人铁了心要支持或反对），因此我同意你修改后的版本。--Sanmosa   2022年3月10日 (四) 14:07 (UTC)
微调了字眼。--路西法人𖤐 2022年3月10日 (四) 13:27 (UTC)
@LuciferianThomas、Sanmosa：
  1. 不建议给 支持/反对 限额。不可行。建议删去此条，转发门槛的1支持改为2支持，其余不变。
  2. 追加延伸（有这样说的吗？）问题是否需要再经过遴选？
  3. 提问的截止时间应提早一天。
  4. 个人认为新开独立页面作为提问（遴选）区可能更好。
  5. 不建议用tooltip。
  6. 为确保问题素质和，防止程序被扰乱。【翻译腔】
  7. 所有问题均应先在讨论页提出。【无用且重复】
  8. 但建议可以（但不强制要求）说明拒绝作答及原因【累赘】
 ——魔琴 [ 留言 贡献 ] 2022年3月10日 (四) 16:27 (UTC)
感谢魔琴君的意见。
  1. 对支持、反对限额的作用是防止某些维基人因为不喜欢候选人而大量同意对候选人提出质疑的问题，几个支持都没分别，有一件事情叫组团。有限制之后组团来提出质疑性问题拉低投票人的很容易发现，因为得玩互相支持问题的套路。
  2. 我有想过这个问题，但跟上面一样，防止灌问题。某程度上是跟限制问题数量相似，不过确实可以提出无限问题，只不过大家看到你这样水问题有多少人会都给你全灌下去而已。
  3. 这个嘛……看上面投票时间讨论成怎样先吧。
  4. 不评论，不是不行，但好像又不太必要。
  5. 纯粹是提案给你们参考字眼用，写进指引不会包含。
后面三个您可以直接修订，小问题（--路西法人𖤐 2022年3月10日 (四) 16:38 (UTC)
  1. 但是，这个提问是流动的。也就是说，第一天，我不知道我第13天会不会看到一个我需要去支持或反对的问题。而且如果大量灌问题，似乎也无法有效反对（当然也没人支持就是）。针对组团的事情，反对票可以解决……吧？
  1. 因为提问提出后不能直接被回答，提前一天截止可以防止提问废掉（而且上面讨论的好像只是临时）
  1. 已修改。
 ——魔琴 [ 留言 贡献 ] 2022年3月10日 (四) 23:05 (UTC)
（回复见下，忘了ping）--路西法人𖤐 2022年3月11日 (五) 12:03 (UTC)
不知所云。假如每个有权者只能支持一条问题的话，事实上是将上边的两条问题收至一条，然后还再加上“十二小时”的规定约束之，四舍五入就是不要问问题。制度复杂，为候选人和投票者增加不必要的负担。--Ghren🐦🕚 2022年3月11日 (五) 03:56 (UTC)
您的理解似乎误会了这里的意思。每个人仍然可以提出无限条问题，不过需要有其他用户也觉得这题值得回答才送去问答区，不提问的当然也可以支持问题，我相信算下来会协助筛选题目的用户数量应该比提问者数量多。A用户可以提出五条问题，全部都是非常具有建设性的问题，态度也非常良好，那么有另外五个个别的用户来支持提出这些问题绝对不是难事。相反，如果B用户提出五条没建设性或者重复的问题，自然一条都不值得被转过去。总而言之，这不是像上面的提案那样按量去限制个别用户的提问数量，而是按质去筛选题目（支持和反对题目可以看到题目是否真的值得提出）。以和平奋斗救地球君的上次RFA有32个题目分段，且大部分发问者均提出多条问题，问题数多达百题，即使假设所有题目都是具有建设性的，不论在7天也好14天也好的提问期都明显让候选人不太可能招架。在这个新框架下，提问数量应比较可能控制在20至30题左右（7天提问期的话就应该15到20题左右），同一人当然仍然可以提出数道题目，但是不是每一题都具备对RFA的同等重要性，其他用户就可以选择说觉得哪些题目更具有重要性并支持提出有关问题，那么就能让最重要的议题能获优先提问，次重要的就未必需要提出。关于魔琴的问题，我甚至觉得可以改成五天收集问题，两天给所有延伸确认用户筛选问题。我不觉得所有参与投票的都会跑去支持题目，这样算下来应该能平衡流动性的问题。--路西法人𖤐 2022年3月11日 (五) 11:06 (UTC)
另一个可行方案是如上面所说，有五天收集问题（同样容许一人多题），两天进行问题筛选，然后仅转发有限量的题目。甚至说，收集题目也可以匿名化，那样就不会被“这个那个用户提出的哦，支持／反对好了”影响。包括提问者和没有提问的人均可两票支持两票反对，然后按照提问的支持率去筛选题目。这样也可以确保题目数量对候选人而言比较可控的情况下回答具有重要性的题目。--路西法人𖤐 2022年3月11日 (五) 11:13 (UTC)
我没有误会这里的意思。首先，本来每个用户在方案一本来是可以是提出两条问题的。但是，在新方案之下，实际上每个用户被规定在一个问题上，只是用户可以自由分配给谁问问题，实效来说就是一题。也就是说，实际上的问题数只会大概和投票人数之下，因为确实是有些用户是不参与答辩的，不爱关注提问区，只是看一回就投了，然后假如是收集问题制，希望问问题的人又要以多余的时间关注在提问之上，不然又会错过了提问期；又或者要花时间在支持问题上，两天支持一条问题，你实在是看得起整个社群的活动能力，中维的社群活跃度其实高度集中在百余个用户上，留意到与否也是一个问题。问题就是在于，在缩小题目数至一个极端的时候，实际上影响和候选人之间的交流。而且，你首先要将问题放在讨论页，然后要人支持，还需要人去确认支持的用户是否有权，然后确定只是有一次，再放至主页面，只是为了让候选人回答。对于我来说就是为了换一个灯炮，然后出动了整村人，增加整倍的时间，只是为了候选人不敢果断拒绝问题而担心。整个方案充满对社群的不信任。ADMIN的工作是自愿的，候选人本来就没有责任去回答所有的问题，自由权本来就应该在候选人上，而不是在社群之上。
我觉得可以探讨的是没投票权用户提问的优次，可以像萌娘一样明确要他们的提问是较为次要的，又或者禁止IP提问之类的。差不多IP提问都是各种傀儡，问题价值差不多就是零。--Ghren🐦🕗 2022年3月11日 (五) 12:38 (UTC)
萌娘百科那样行得通是因为只有少数人有投票资格。在本站符合人事任免资格者众。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年3月18日 (五) 19:11 (UTC)
即使如此，每一届都有IP和无投权者问问题，而这些人的问题质量明显低下。--Ghren🐦🕘 2022年3月24日 (四) 13:07 (UTC)
确实。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年4月2日 (六) 09:02 (UTC)
匿名化太难了，难不成每次都要用安全投票之类的问？--SunAfterRain 2022年3月13日 (日) 09:46 (UTC)
（没有说必要）--路西法人𖤐 2022年3月24日 (四) 12:50 (UTC)
“所有问题均应先在讨论页提出”何也？—— Eric Liu 創造は生命（留言・留名・学生会） 2022年3月10日 (四) 17:59 (UTC)
我猜可能是指RFA页面对应的讨论页？--Steven Sun（留言） 2022年3月11日 (五) 02:42 (UTC)
是。--路西法人𖤐 2022年3月11日 (五) 10:24 (UTC)
我的意思是，为什么要这样进行？—— Eric Liu 創造は生命（留言・留名・学生会） 2022年3月11日 (五) 16:59 (UTC)
如同Temp3600下面所言，如果维基人能够自律，当然不用……需要的原因还是因为防止灌题而已。--路西法人𖤐 2022年3月24日 (四) 12:48 (UTC)
确实有理。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年4月14日 (四) 19:45 (UTC)
  • 支持上述的软性规范。说到底，维基人如果能自律，就能减少这类难以设立有效规范的情况。另外，再次建议设立问题库。--Temp3600（留言） 2022年3月17日 (四) 14:42 (UTC)
    我的意见同Temp3600君。--~~Sid~~ 2022年5月23日 (一) 02:42 (UTC)
  • 支持概念版。细化版或可作为指引，作方针需要评估试行再说，并且“明确要求”难以避免很多问题。“仅能支持或反对提出一条问题。”需要改掉，非常像仅有一笔投票权。--YFdyh000（留言） 2022年4月6日 (三) 16:57 (UTC)
  • 能否由行政员和管理员作为提问主持人根据提问参与度选出10个以内相关度高的问题，同时根据提问数量也可再加选出5个以内呼声高的问题作为补充提问。不限制提问数量，不限制每个人的问题的入选数量。-- ★WPTO★ 2022年4月7日 (四) 01:19 (UTC)
  • 或许提问者可以尝试用邮件功能向候选人提问，这样提问和回答都是私密的。即使候选人不回答提问者的问题，也只会影响相应提问者的投票决定，不会影响更多人。可能可以减轻候选人的负担。--50829! Talk · 494,976,576 2022年5月14日 (六) 05:44 (UTC)
  • 根据到目前的实践来看，尚无任何一名管理员候选人在不回答任何问题的情况下当选。是否可以规定候选人必须回答的问题数量，如必须回答所有问题中任意的30%，其余问题则可以忽略？--Yining Chen（留言|签名页） 2022年5月19日 (四) 15:04 (UTC)
    我想就是因为如此，才不会有候选人敢不回答任何问题的。个人以为并无必要设置答题数量低标。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年5月20日 (五) 01:25 (UTC)
  • 抛砖: 每个人可以以自己的名义问一条问题；如希望问更多问题，则需按某种方式进行预筛选。--Temp3600（留言） 2022年5月20日 (五) 17:13 (UTC)
  • (！)意见：(＋)支持概念版主要内容。敝人路经此地，斗胆对此议题表达个人想法，先说结论：
  • 每位用户可发问两回（含追加提问一回）。
  • 若提问人一次提出超过三个问题，以前三题作为该提问人优先关注命题（亦即一回共 X 题，X不设限，候选人仍可视情况自由作答）。
  • 提问人不得于选举问答过程中表达个人投票意向，或另行突显特定题目与投票意向之“因果、要约或对价关系”，违者视为放弃该次选举提问机会且企图扰乱选举。
  • 仅具投票资格用户可有效发问。
窃以为，不同用户皆有各自使用或参与之需求和偏好，“选举提问”亦然。候选人须面对的是所有站友的各种需求，参选门槛之实务呈现亦已为社群关注命题。在综合考量“需求媒合”、“意见表达”、“成本节制”、“公评观感”、“声量平衡”等因素下，个人尝试提出具体建议和考量如下：
1.仅“具投票资格用户”可于参选问答页面对候选人有效发问。窃以为，为维持提问过程之公正性、有效性，理想上每位站友的提问内容应于“检视候选人素养和热忱”、“增进对候选人的理解”，以及“表达用户个人意见与观感”之间获取平衡，且在理应严谨之选举过程中，对自身参与其中之公开、有效发问负责。因此，个人认为既然要公开提问，以分身、傀儡及单一用途账号甚至各式IP发言，并非负责之举，且徒增社群成员间互不信任。讲白了，真的想行使参政权利、发问考核甚至反对候选人，为何我们不应为自己的发言某种程度“具名”呢？而为鼓励尚不具投票资格用户获取参近之相关权利（如果能算鼓励的话），不开放于选举问答页面公开提问。
2.“需求媒合”：个人在此尝试提出此观念，让“提问人真正最关注的首要需求或优先事项”和“参选人可能最擅长或能够提供的服务”直接进行媒合，亦即期许提问用户对自身使用、参与或关注之“需求”和候选人的理念、技能、服务之“供给”，促进有效媒合。毕竟，即便在站务实务中，管理人员亦时间与心力有限，未必能满足所有用户的不同需求；既然如此，个人认为参选问答过程亦然。
如果单一站友已愿意付出时间、心力提出多项问题，应可不吝明确列出自己的优先关注事项，让参选人可优先应答，其他题目视情况自行拣选作答；如果参选人对前三题以外的题目行有余力，又或者对于前三题的回答自觉不足，自可多多作答以满足提问人需求，只是此时为顾及不同提问型式之公平性，不宜无限制追加发问、不断延伸（比如：现行制度下，敝人或可以IP或傀儡认真提出15个问题，对其中11个问题延伸提问，再对其中8个问题追加发问，最后针对2题尝试深入探讨；问答完以后，再以问A嫌B、挑C拣D之思路加以点评，最后公开表态“依候选人的表现，我真的投不下去”（其实可以直接投反对票就好了（笑））。虽然候选人面对这种情况，可以不理会，直接放弃争取这一票（或更多票），然若任何用户或账号、IP皆可依此模式“自由发问”（而且能够问完就跑，来无影、去无踪，完全免责（笑）），试问这种模式或过程对于社群考评参选人、公共事务风气甚至将来的平台发展有何增益呢？也就是说，窃以为提问人需自行在“对较少事项展开可能的深入探讨”和“更多甚至海量发问可合理期待获取的回复”间有所选择。对此，个人建议用户单回发问超过三题时，明订以前三题代表提问人优先选题。
3.“意见表达”：就个人观察，我认为有心的站友们显然可透过对候选人提问的型式、数量、难易、内容等面向，试图表达自己对候选人的观感或立场，这一点即便将来持续采行匿名投票机制，仍可维持下去（虽无法公开确认个别用户提问情形和投票意向间的因果关系）。既然如此，对于提问型式适当约定，似乎不妨碍用户透过发问表达个人意见之自由。况且，提问人可直接对问答内容在“不透露个人投票意向”的前提下，提供意见或作出点评，应已具相当的个人适当表达空间了。
4.“成本节制”：承上，故对于管理人员选举和社群参与者各方投入之时间、心力等成本，甚而各种有形或无形（如社群争议、地域冲突、团体争斗等引发之信任问题）之耗损，窃以为或须有所节制。
5.“公评观感”：承上，即便候选人能自行选择是否或如何答题，以及投入多少心力应答，惟若对于用户提问毫不设限，提问人仍可试图“技巧性”在参选页面对任何观者营造出候选人“心力不足、能力欠佳、缺乏人望、居于弱势甚至诚意不够”之观感；而一般候选人往往为了避免此事，自依循往例尽可能对于所有提问兵来将挡、完整作答。虽某种程度上，参选提问本属社群论政攻防之一环，但这种现象（或手法）已明显无谓筑高参选门槛，且对于考核候选人站务能力甚而来日表现之有效性实有待商榷，说穿了其实就是造成整个社群不时进行负面选举的结果罢了。
6.“声量平衡”：个人在此尝试提出此想法。此指“提问用户于选举过程中，透过发问所呈现出的个人表达力道或强度声量”。不可讳言，在选举期间，大量发问之用户于社群的公众领域具备显著之存在感或关注度，即便使用IP提问亦然（个人认为甚至更引人注意）；又或者有些站友由于平日投入耕耘、积极贡献，于社群中具备某种程度之意见代表性，或可谓意见领袖。这里敝人斗胆挑战一事：如果在选举问答过程中，每位用户的提问在“选举制度”上皆具相同有效性和代表性，为何在“实质结果”上却可尝试于选举页面表现出相较他人显然更高甚至极高之数量、篇幅（如：比其他用户高出好几倍的提问数量），甚而不须为自己的发言承担任何责任呢（如：使用傀儡账号甚至IP）？会否这也可能成为竞选攻防中对社群无甚增益之“有为者亦若是”？
以此而言，我认为，若真要在选举过程中呈现或反映社群成员于意见分量或代表性之“现实状况或需求”，又或者有站友希望能热切提出相较他人明显更多的关注论题，那么是否干脆在制度上明确承认并非所有人于选举过程中的意见声量相同，采行某种用户彼此间授权、委托发问甚或“选举人或提问人制度”？若否，在参选问答的个人表达声量之体现上，是否应适当约定或克制呢？
以上为个人意见，文长言冗请见谅，供参。--Kriz Ju（留言） 2022年5月30日 (一) 00:29 (UTC)

关于接下来的管理员投票

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2022年9月15日 (四) 16:14 (UTC)。

应上一次WP:500（Wikipedia:投票/是否在管理员选举启用SecurePoll）的共识，社群已经试行了一次安全投票（Wikipedia:申请成为管理员/和平奋斗救地球/第5次），但是接下来社群如何进行投票是没有充份共识的，引至出现了这种问题。因此，希望大家认真讨论一下：

  1. 接下来的“申请成为管理员”，以及是其他管理人员职务是否使用安全投票？
    1. 如果决定不使用，（除了是在原地打转之外，）如何满足、解决“阻止拉票和人身威胁”的问题。
    2. 如果决定使用安全投票，如何决定程序，时间，方针对应的调整也是需要考虑的。

希望社群讨论。--Ghren🐦🕓 2022年6月5日 (日) 08:11 (UTC)

@Lanwi1、1233、中文維基百科20021024、Z7504、Yining Chen、AT、Ericliu1912、Sanmosa、Outlookxp。--Ghren🐦🕓 2022年6月5日 (日) 08:14 (UTC)
支持2，免得自己支持或反对被人议论纷纷。和平奋斗救地球的选举流程应该没什么大问题吧，一些人提名+正式投票。--中文维基百科20021024（留言） 2022年6月5日 (日) 08:20 (UTC)
@Ghrenghren：（我倒是觉得你先等Steward公布了正式投票结果以后才开这讨论串比较好，但现在开也不要紧）我觉得之后继续使用安全投票是必然的事情，虽说不可能阻止拉票，但不使用也阻止不了，而且人身威胁问题明显是基金会与社群极度关注的问题，必须优先处理，而且我也不认为基金会方面会容许社群在人身威胁问题上开倒车。我觉得程序可以比照Wikipedia:申请成为管理员/和平奋斗救地球/第5次来拟定，这样能省却不少麻烦。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月5日 (日) 08:28 (UTC)
问题没法根除的情况下就选最好的一种解决方案。--中文维基百科20021024（留言） 2022年6月5日 (日) 08:44 (UTC)
（我是本来是这样打算的，但是有些人比较心急。）--Ghren🐦🕓 2022年6月5日 (日) 08:45 (UTC)
我个人支持继续采用安全投票。不过基于安全投票需要筹备的时间相对较长，因此建议集中提名，一次过投，这样比较有效率，比如可能一年两次提名期之类的。--AT 2022年6月5日 (日) 08:57 (UTC)
一年一次应该也够吧，但我考虑到Steward选举的情形，也同意集中提名与统一投票期的举措。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月5日 (日) 16:06 (UTC)
就筹备时间的问题来说，一年两次或一年一次的区别应该不大。但相较后者而言，前者可让有意申请或提名管理员的用户不必等那么久。-Peacearth（留言） 2022年6月10日 (五) 20:44 (UTC)
事实上频率还可以更高。没有必要把选管理员搞得像在选监管员一样。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年6月11日 (六) 13:52 (UTC)
作为两次安全投票监票人，觉得有些事情是要提醒社群，在作出上述决定之前是必须考虑︰
是否允许使用Proxy︰以本社群组成部分而言，如果使用安全投票，禁止使用Proxy几乎等于阻断相当一部分合资格用户参与投票，但在投票意向隐藏之下，允许使用Proxy将会大幅度减弱监票效果。
临界状况︰因为安全投票与传统方法差异不少，若出现传统上临界状况，即75至80%时，行政员几乎无法介入去作出决定。例如使用中立票去判断候选人是否当选。
以上。--J.Wong 2022年6月5日 (日) 08:59 (UTC)
禁止使用Proxy几乎相当于不让居住在中国大陆境内的人投票，貌似免proxy使用Wikipedia比较繁琐。--中文维基百科20021024（留言） 2022年6月5日 (日) 09:05 (UTC)
避免（可能的）不正确信息造成误导，折叠。--东风（留言） 2022年6月8日 (三) 11:34 (UTC)
在登录账户的情况下使用proxy投票会有什么问题吗？--中文维基百科20021024（留言） 2022年6月5日 (日) 09:07 (UTC)
表现为部分投票用户使用IP相同或相近，有傀儡的可能。--东风（留言） 2022年6月5日 (日) 10:50 (UTC)
过往情况下不是有投票有资格限制嘛，那安全投票可以自动阻止不符合资格的人投票吗？而且以前投票的时候不也没有限制proxy。--中文维基百科20021024（留言） 2022年6月5日 (日) 11:06 (UTC)
但过去是明票，投票意向跟编辑纪录都是一览无遗……--J.Wong 2022年6月5日 (日) 11:18 (UTC)
让监管员把参与投票的人都CU一遍？--中文维基百科20021024（留言） 2022年6月5日 (日) 11:22 (UTC)
不太明白……--J.Wong 2022年6月5日 (日) 11:43 (UTC)
维基百科:用户查核，总不见得不让中国用户投票吧。--中文维基百科20021024（留言） 2022年6月5日 (日) 12:14 (UTC)
对投票用户全部进行查核理论上可行，因为即使存在相同或相近IP，使用设备存在差异也会生成不相关 不相关，但这无疑给监管员增加了（极大）工作量，我感觉他们的回应可能不会很积极。--东风（留言） 2022年6月5日 (日) 12:24 (UTC)
那正好可以借着这个机会把查核权要回来。--中文维基百科20021024（留言） 2022年6月5日 (日) 12:26 (UTC)
@中文維基百科20021024：Wikipedia talk:申请成为管理人员/存档7中有说明基金会对于恢复zhwiki用户查核权的要求：以安全投票进行选举、用户查核员任期制（任期为2年）、基金会定除权机制（直接看连结吧，我懒得打出来了）、强制接受基金会培训、基金会定期稽核。我觉得先处理好管理员选举问题以后才处理恢复用户查核权的事情会比较有说服力。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月5日 (日) 15:54 (UTC)
真的建议两位先去了解一下什么是secure poll，然后再来讨论。--J.Wong 2022年6月5日 (日) 12:45 (UTC)
我对代理这部分的理解是这样的，那可能并不正确。--东风（留言） 2022年6月5日 (日) 13:23 (UTC)
中立票之意见是否会显示，以协助行政员判断结果？-Peacearth（留言） 2022年6月5日 (日) 13:22 (UTC)
几乎无法辨识留言是否由投中立票之用户留下。--J.Wong 2022年6月5日 (日) 21:44 (UTC)
原来如此。这样的话的确不太能用来协助判断。-Peacearth（留言） 2022年6月6日 (一) 03:21 (UTC)
安全投票的缺点是禁止使用Proxy的话就几乎等于不让居住在中国大陆境内的人投票，行政员也几乎无法介入去作出决定。--Lanwi1(留言) 2022年6月5日 (日) 13:56 (UTC)
vote.wikimedia.org在中国大陆似乎可以正常访问，但大陆用户可能很难适应在投票前先关闭代理，如要禁用可能很多用户会误操作。此外，这次安全投票也有可选填的投票附言，临界状况下行政员也许可以根据这些意见进行判断？但安全投票似乎很难延长，所以行政员可能只能判当选或落选，而没法延长投票了？--BlackShadowG Slava Ukraini! 2022年6月5日 (日) 15:04 (UTC)
vote.wikimedia.org在中国大陆不可正常访问，不用Proxy就无法投票。--Lanwi1(留言) 2022年6月5日 (日) 19:49 (UTC)
只受到IP污染罢了，hosts半直连。--Liuxinyu970226（留言） 2022年6月21日 (二) 07:35 (UTC)
考虑到基金会在此前因为安全理由而要求中国大陆用户自行请辞重要权限一事（注意当时基金会所提到的“安全理由”没包括Proxy），我有理由认为基金会并不信任中国大陆用户。另一方面，基金会一向并不鼓励使用Proxy。虽然禁止使用Proxy相当于不容许身处中国大陆的人投票，我认为这是唯一保证投票安全性的办法，而且基金会不会对此有任何意见。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月5日 (日) 15:47 (UTC)
我认为这是滑坡谬误。我有理由认为这个“有理由认为”的理由不充分。--YFdyh000（留言） 2022年6月6日 (一) 11:58 (UTC)
还需要决定是否通知选举人投票事宜。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年6月5日 (日) 10:27 (UTC)
我觉得默认情况下没有必要，毕竟并不是所有活跃用户都关注人事任免。私以为可以像站内刊物那样制作一个发送名单，让用户自行选择是否订阅。--BlackShadowG Slava Ukraini! 2022年6月6日 (一) 12:20 (UTC)
同意--0906（回复请Ping我） 2022年6月7日 (二) 14:34 (UTC)
对一部分前管理员参选不使用安全投票不会有问题吧？--Lanwi1(留言) 2022年6月5日 (日) 14:26 (UTC)
Lanwi1如果两种投票方式并行，是否应给予候选人自主选择投票方式的机会，或是由社群整理出一份“强制记名投票候选人名单”？这样看起来会不会有些不公平（无论是对采用SP的候选人或是采用普通流程的候选人）？而且这样做可能意味着社群需要准备两份投票规则。--Yining Chen（留言|签名页） 2022年6月5日 (日) 14:48 (UTC)
不建议让候选人自主选择，这可能导致不愿公开投票倾向（可能出于安全原因）的用户无法参与部分投票。--BlackShadowG Slava Ukraini! 2022年6月5日 (日) 15:07 (UTC)
支持继续使用安全投票。但继续使用安全投票可能意味着社群需要对RFA方针的全部内容进行讨论并重写。关于Proxy，在以往的投票中也未能有很好的方法来排除傀儡干扰（但在实际投票中，似乎是因为投票要求较高，所以很少见到过滥用傀儡投票），因此反对排除使用Proxy的用户。--Yining Chen（留言|签名页） 2022年6月5日 (日) 14:48 (UTC)
重写方针是比较简单的部分；甚至不需要废除既有之全部内容，只需要能够反映采用安全投票的现实即可。当然根据相关讨论，人事任免资格方针也得修一下了。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年6月5日 (日) 16:29 (UTC)
我要特别声明一点：我反对任何容许以旧投票方式进行选举的方案，并行方案也不行。只有安全投票能保证投票人的人身安全，因此只能统一使用安全投票。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月5日 (日) 15:49 (UTC)
PS提一句，如果Proxy是非公开的话，那是不是容许的范围，因为meta:No open proxies提到“Publicly available proxies (including paid proxies) may be blocked for any period at any time.”，现有的IP的Proxy封锁似乎也是基于怀疑是VPS常用的AS来判断（是否包括Proxy探测不能确定），如果存在Private Proxy（只有一个用户专用的Proxy），那应该不属于meta:No open proxies的情况？——Sakamotosan路过围观 | 避免做作，免敬 2022年6月6日 (一) 02:32 (UTC)
如果考虑利用CU排查的话，结合安排安全投票的配置和CU工作的效率，可以这样安排：每个两个月集中安排一次投票（CU默认保留3个月的数据，每个月开一次密度可能过高，取一个中间值），投票完毕后由CU进行事后复核，先按用户名查一次，再集合IP信息反向查一次，并且结合IP的whois等信息排除掉普通用户和private proxy类（IP是属于VPS但只有一个用户）的用户，剩下的大量集中特定VPS的可以考虑为明确的Publicly proxy。这些数据也最好记录在cuwiki中作为日后复查。CU将怀疑在Publicly proxy的用户名单交给行政员，再结合投票结果，决定是否排除这些用户的投票，然后再宣布正式的投票结果？——Sakamotosan路过围观 | 避免做作，免敬 2022年6月6日 (一) 02:32 (UTC)
除了“让候选人自主选择”之外另一个选项是“让投票人自主选择”。愿意承担风险者可以沿用既有投票方式，但须列明合理理由；不愿承担风险者可以去安全服务器投票。若重复投票，以安全服务器上的投票为准。这样遇到临界情形也有判别共识的依据。--Antigng（留言） 2022年6月6日 (一) 05:51 (UTC)
此外避免“社群在人身威胁问题上开倒车”的关键在于要有良好的预防和应对“人身威胁”的站内机制。仅仅在管理人员选举层面各种加码并无助于从根源上解决问题，就算没有管理人员选举也有条目争议封禁争议等其它类型的争议，没有上述这种机制，样样都可能引发“人身威胁”。--Antigng（留言） 2022年6月6日 (一) 06:01 (UTC)
不行，我觉得受人身威胁者也会被威胁不得到安全服务器投票，所以不可容许安全服务器投票以外的任何投票方法。另外，提醒一下大家安全投票机制只会让大家知道谁已经投了，而没人知道谁怎么投。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月6日 (一) 06:03 (UTC)
既然安全服务器可以看见谁已经投票，那么监票的行政员只要看到该用户投票，就可以自动将站内投票忽略，从而不会引发任何问题。此外，受威胁用户可以假意于站内页面顺应威胁者的意思，但在安全服务器表达真实意见。这样TA既表达了真实意见，也不再会受到威胁者的威胁。因此“以安全服务器上的投票为准”便可解决您所提出的问题。--Antigng（留言） 2022年6月6日 (一) 06:25 (UTC)
@Antigng：还有一点，由于选举期间所有人都能够看到了谁已经投票，所以进行人身威胁者是会知道受人身威胁者有在安全投票那边投票的，进行人身威胁者可以威胁受人身威胁者撤回在安全投票那边投的票。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月6日 (一) 06:34 (UTC)
那么可以把这条信息关掉，使之对公众不可见，变成真正的安全投票。事后再让监票行政员汇总出一份结合站内外投票用户的名单，按字符先后顺序排列。--Antigng（留言） 2022年6月6日 (一) 06:37 (UTC)
@Antigng：实务上不可行。安全投票是P站那边负责的，所以那边在投票结束后会直接给出所有参与安全投票的人的名单，进行人身威胁者还是可以知道受人身威胁者有没有在安全投票那边投票（而且还有考虑到被基金会除权的人包括管理员与行政员）。我主张只容许安全投票的原因是进行人身威胁者会失去得悉受人身威胁者是否有投票的诱因。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月6日 (一) 06:43 (UTC)
  1. 修改代码能解决的问题实务上并不算是问题；wmf的技术员也是为实现社群需要功能而服务的“打工人”而已。
  2. 此外，单纯“只容许安全投票”并不见得能使“进行人身威胁者”“失去得悉受人身威胁者是否有投票的诱因”。且不论威胁者可能非理性地照威胁不误，TA还完全可能“理性地”要求被威胁者在安全服务器进行投票，并出示投票的截图才放过。采用本人提出的方案，被威胁者遇到这种情况可以简单、假意地在站内投票。毕竟证有（投票）容易，证无（投票）难，威胁者有办法迫使被威胁者出示“在安全服务器进行投票”的证据，却没有办法迫使被威胁者出示“没有私下里去安全服务器投票、改票”的证据的，除非进行监视、非法拘禁等。--Antigng（留言） 2022年6月6日 (一) 06:53 (UTC)
    安全投票是可以改票的，被威胁者即使被要求放出投票的截图也可以重新再投一次，因此进行人身威胁者无法得知受人身威胁者在安全服务器的投票意向，当然监视、非法拘禁是另当别论。--BlackShadowG Slava Ukraini! 2022年6月6日 (一) 09:55 (UTC)
有理。但至少本人提出的方案相较于“只容许安全投票”不会更利于威胁者对被威胁者展开威胁。
试行的方案，只容许安全投票的场景下：威胁者可以威胁投票人参加安全投票并出示截图等证明，也可以威胁投票人不投票；投票人可以分别采取“事后改票”、“秘密参与安全投票”的方式应对；
本人的方案，容许投票人选择安全与非安全投票的场景下：威胁者可以威胁投票人参加投票并提供证明，也可以威胁投票人不投票；投票人可以分别采取“在站内假意投票，事后去安全服务器表达真实意见”、“秘密参与安全投票”的方式应对；
有安全服务器“托底”，两方案的安全风险应该是相当的。而本人的方案更利于解决Wong128hk提出的临界状况不好判断的情形。--Antigng（留言） 2022年6月6日 (一) 10:06 (UTC)
@Antigng：本人没能理解您的新方案是如何解决“临界状况不好判断”这一问题的。而且个人认为非安全投票与安全投票同步进行（该方案）很可能为投票增加了原本不存在的风险。--Yining Chen（留言|签名页） 2022年6月6日 (一) 10:30 (UTC)
过去的投票之所以临界情况可以交由行政员裁决是因为投票与理由一一对应，通过理由可以判断哪一方的意见更有力；安全投票无法实现这一点。同时保留安全与非安全投票两个选项的前提下，如果最终出现了临界情况，而通过检验发现安全与非安全投票两个样本没有统计显著的差异，就可以站内非安全投票的样本进行类似的判读，决定投票延长还是直接不通过。--Antigng（留言） 2022年6月6日 (一) 10:43 (UTC)
我觉得这会增强点票的难度。此外，由于同时使用两种投票方案需要比对重复票数，使用安全投票的用户的名单需要公开以便核对，这样就使威胁者可以要求被威胁者不投票。如果只使用安全投票，可以不公开投票的用户名单，以确保安全性。--BlackShadowG Slava Ukraini! 2022年6月6日 (一) 12:06 (UTC)
此外，我觉得即使是安全投票某种程度上也可以让行政员裁决临界情况：虽然用户的投票意向不会公开，但所有用户的投票附言会打乱顺序后公开，私以为行政员可以依据用户留下的意见来做出判决。--BlackShadowG Slava Ukraini! 2022年6月6日 (一) 12:10 (UTC)
一是如前述，可以从技术上限制普通帐户对已投票用户列表的访问，而仅允许监票行政员获取所有使用安全投票用户的名单。一旦用户出现在该名单中，站内投票自动作废；选举结束，站内外结果合并给出得票比例，监票行政员只给出站内外投票用户的总名单。这样威胁者就无从查证被威胁者有否使用安全投票进行改票。二是安全投票并不存在真正的讨论，参与者彼此看不见对方的留言，只是各说各话，难以归纳总结。此外，还不按照时间顺序排列，以至于无法识别“短期涌入大量支持/反对票”等异常情况。--Antigng（留言） 2022年6月6日 (一) 12:22 (UTC)
那不如在选举页面开启“投票意见”章节，使用户可自愿公布其投票意向和理由，也可回复他人的意见，但最终结果仍以安全投票的结果为准。这样既便于行政员判断临界情况，也降低了计票的难度，安全性也没有问题。--BlackShadowG Slava Ukraini! 2022年6月6日 (一) 12:38 (UTC)
对于将已投票名单改设置为对公众不可见的提案表示支持。但对于“投票意见”的部分，个人看法同Shizhao在下面说的，当前投票时已容许用户发表意见，已足以供大众及行政员判断是否合理，而无需知道该意见提出者是否投了支持/反对/中立票、更不需要知道是哪位特定用户所做出的。-Peacearth（留言） 2022年6月10日 (五) 20:40 (UTC)
这会不会就是共识制？--J.Wong 2022年6月12日 (日) 04:53 (UTC)
“投票与理由一一对应，通过理由可以判断哪一方的意见更有力”，这点完全没有必要，只要看理由是不是合理，根本不需要知道某个理由是谁说的、是哪方说的--百無一用是書生 (☎) 2022年6月8日 (三) 01:58 (UTC)
好像也是。不过至少“行政员可考虑中立票”的部分可能需要稍加修订，虽然实质上并无太大区别。-Peacearth（留言） 2022年6月10日 (五) 20:32 (UTC)
1.一切活动应以安全为优先考量。如果用户光是上网投个票都不安全，或需承担各种风险，甚至已经遭受到实质安全威胁，个人认为理当以自身安全为首要考量。若用户真已感受到任何形式之人身安全胁迫（不论被迫以何种形式如何表态），敝人建议：先暂停维基百科内相关活动，必要时请求当地司法机构协助，在条件许可下向基金会具体陈情以寻求适当协助。在此之前，使用界面和机制之规划应有所为。
2.投票过程中的已投票用户名单等动态资讯不应对一般用户公开。
3.投票结果若处于临界状态，行政员可综合考虑用户投票意见和理由予以裁定。
4.安全投票机制若能明确标注显示“中立票”之附含意见较为理想；若最终安全投票界面仍不具此功能，且社群或具权限之监、验票人员仍期待便于识别中立票内含之意见，窃以为于投票须知明确规范：“当用户投下中立票，应于投票意见栏明确表达该票附具之意见或评价为‘中立’，以便选举结果之识别判读。”即可（如投票用户应于意见栏写明：“中立，基于候选人....，但仍.....”；“投下中立票。平日候选人之站务表现已具ＸＸＸ和ＯＯＯ，往后可再加强AAA，....”）。
5.若设立选举投票事宜通知机制，可供用户自由选择订阅。
6.其他技术性事项回归安全投票机制所具功能，具投票资格用户应皆可合规投票。
7.投票期间若发生异常或灌票现象，窃以为应可由具监、验票权限之站务人员核查处置。
8.现行投票页面上方已有“意见”区，欲发言、讨论、评论之站友应已有适合之区域，可供品评论议；站务人员选举中“讨论交流或评论表达以形成共识”之机制，窃以为此区块应可具相当之功能，与“实际投票功能或机制”并行不悖。若有其他考量，或可对于“意见”区之规划再行增补调整。
9.对于中立票之意义或代表性，过往已有相关讨论及争议，似悬而未决。敝人初步考古后认为，所谓中立票实则未必“中立”，观诸过往中立票之具体意见和内容，所显露之实质意向往往“偏向反对或不甚支持”（除去先置板凳、卡个位、看风向、只求个参与或真的没意见等未带实质意见内容者），亦即当投票用户对参选人感到不太满意或至少不够满意的情况下，仍希望参与投票并借此加以评价，以对候选人表达“委婉反对”、“尚待加强”之意见或评价；窃以为讲白了，其实几乎就是偏向“不太支持”。用户特地至此投下这一票，若对于候选人真毫无个人立场或意见偏好，又何必如此费力呢？个人认为其实就是不太支持参选人，可能基于种种考量，而不直接投下反对票，仅透过参与以表达意见或在投票结果临界时期待发挥效用。若实行安全投票机制，行政员应仍可依据投票用户留下的意见做出裁定，而投下中立票之用户亦应明确其自身投票性质；否则，所谓“中立票”之存在意义甚至可供深入讨论了。
以上为个人意见，供参。--Kriz Ju（留言） 2022年6月20日 (一) 06:01 (UTC)
又没动静了。(＋)支持安全投票，并认为现在就可以直接用普通投票的方式，来决定是否在以后的选举中采用安全投票。投票结束后，再讨论相关事宜也来得及。--50829!（留言） 2022年6月22日 (三) 06:13 (UTC)
还不是有人不知道普通投票和安全投票的差别吗？这种讨论都可以一直没动静，基本上不用玩了，既然完全说服不了人还要考虑选管理员？最后恐怕就是互相投反对、浪费时间而已的奇葩社群。--Z7504非常建议必要时多关注评选（留言） 2022年6月22日 (三) 15:30 (UTC)
  • 以上似乎对于使用安全投票没有明确的反对意见。下一步应该讨论投票的举行时间（定期举办或有人提名就举办）和修订相关方针指引了。至于投票流程，个人认为暂行规定的“发表意见”至“执行结果”部分可以继续沿用。--Steven Sun（留言） 2022年6月23日 (四) 02:31 (UTC)

投票方式的共识

因为上方讨论过于冗长，因此在此开一个小节进行整理。希望能够推进讨论的进行。目前主要问题集中在以下两点：

  • 使用安全投票后，无法考虑中立票的意见；
  • 是否应转而使用安全投票与普通投票并行的方式。

但就目前共识而言，似乎并没有出现明确的反对使用安全投票的意见。是否可以认为大家已就“在接下来的投票中继续使用安全投票”这一点达成共识，并可以进行公示？或是需要举行投票来做出决定？另外，就以上两点问题，是否也可以通过举行另一场与此前类似的投票来进行选择？--Yining Chen（留言|签名页） 2022年6月23日 (四) 15:10 (UTC)

  • 为何要并行呢？总之总有人搞不清楚何谓安全投票和普通投票的差别嘛，现在这个独裁社群连以后要不要实施安全投票都可以无法做决定了，真的无法说服大众，扯。请问如果要并行，那票是不是可以两边投阿？--Z7504非常建议必要时多关注评选（留言） 2022年6月23日 (四) 16:53 (UTC)

我认为安全投票的缺点是成本比普通投票高，也就是说安全投票太消耗精力。--Lanwi1(留言) 2022年6月25日 (六) 23:56 (UTC)

我最担心的是有人利用安全投票来恶意投反对票，最坏的结果是候选人退出维基甚至是轻生，所以对一部分候选人而言，普通投票好一些。--Lanwi1(留言) 2022年6月27日 (一) 17:00 (UTC)

(！)意见：不好意思，敝人不确定候选人轻生是否指特定人士；若然如此，我强烈建议精神状态不佳的站友敬请审酌衡量自身身心状态，以个人安全和健康为重，如果的确身心状态不佳，请立即停止所有维基百科相关活动，并寻求适当心理或医疗协助。况且，若用户心神状态确实如此，显然不适合参与人事选举等较可能产生火花之社群活动，亦敬请站友多多关心身边的社群用户。--Kriz Ju（留言） 2022年6月27日 (一) 19:03 (UTC)
谁想轻生的话我也不知道，大陆用户轻生的可能性比港澳台用户高，因为大陆的言论管制，不能在现实生活中诉求自己的遭遇，所以更要多多关心依赖维基百科的渴望自由的大陆用户。--Lanwi1(留言) 2022年6月28日 (二) 00:36 (UTC)
中国大陆使用者是否轻生率较高敝人不认为可以从这一个简单的投票界面和主题加以验证，而仰赖投票界面表达意见自由致影响个人生命安全和身心健康或产生可能疑虑，我认为显然亦非健康思维和应有举措。敝人会建议，请各位站友多多关注生活和人生的美好面向，切勿因投入任何网络相关活动致影响生活平衡。与诸位站友共勉之。--Kriz Ju（留言） 2022年6月28日 (二) 04:58 (UTC)
没什么屁用，就算用实体投票一样也可以恶意投反对票。--Z7504非常建议必要时多关注评选（留言） 2022年6月28日 (二) 14:08 (UTC)
实体的话可见，现在中维帮派化太重。--Lanwi1(留言) 2022年6月28日 (二) 14:33 (UTC)
为什么我觉得恰恰相反？反倒是非安全投票下容易造成心理问题？（如果候选人的确有的话）非安全投票下投票会有压力。--日期20220626（留言） 2022年6月28日 (二) 14:36 (UTC)
对易被帮派排挤的候选人的而言，在安全投票下容易造成心理问题。--Lanwi1(留言) 2022年6月28日 (二) 14:57 (UTC)
不，对易被帮派排挤的候选人的而言，在没有安全投票的情况下才容易造成心理问题。请不要将以前WMCUG干预RFA的情形视而不见。Sanmosa Királyunk s a közhazát 2022年6月29日 (三) 01:56 (UTC)
对易被WMC排挤的候选人的而言，不在安全投票下就容易造成心理问题，但我所说的帮派指的是反WMC的。--Lanwi1(留言) 2022年6月29日 (三) 03:17 (UTC)
我感觉把你说成同时存在的两个“帮派”比较一下的话，就算这两个“帮派”都真的同时存在，“反WMC的帮派”所产生的问题明显不能与“亲WMC的帮派”所产生的问题相提并论，至少“反WMC的帮派”不可能像“亲WMC的帮派”一样有群体策划的欺凌（包括但不限于网络上与现实上）。Sanmosa Királyunk s a közhazát 2022年6月29日 (三) 15:25 (UTC)
亲WMC的帮派和反WMC的帮派不是同一类型，WMC的目的是获得地位，反WMC的帮派的目的是守住地位并排除WMC，此外还有一部分人的态度太强横，让人难以亲近。这两个帮派的区别是反WMC的帮派的地位比亲WMC的帮派高，我还认为有地位的违规者的危害比没地位的高。--Lanwi1(留言) 2022年6月29日 (三) 16:05 (UTC)
以前公开投票的时候有相互吵架的，对投反对票冷嘲热讽的，还有我上面讨论提到的有人投了反对票还会被人拉清单，就没发现公开投票好在哪里。--日期20220626（留言） 2022年6月29日 (三) 03:08 (UTC)

中文维基百科过去有人事任免时的集体行动，今后也不会完全消失。个人的观察是此类集体行动受胁迫的成分少，人情的成分多。公开投票下，此类集体行动藏不住，谁重人情而眛事实，清清楚楚。倘若前几年WMC活跃时就启用了安全投票，想必只会掩盖而非制止媚世者的不当行为。至于上面说到的身心健康问题，也不止和人事任免相关，维基百科上有各种各样的事情会招致攻击；个人领教过WMC群组内的肆意谩骂，和人事任免无关的亦有很多。仅把RfA换成安全投票，恐怕治标不治本。上面讨论中支持安全投票者多，但本人的意见不同，供诸君参考。--Lt2818（留言） 2022年6月29日 (三) 06:16 (UTC)

对，过去的拉票和在RfA时恶意投反对票基本上以人情的成分居多，例如以看不顺眼为由恶意投反对票。按照中维的现状，安全投票就是治标不治本，一切根源就是心怀不轨的人，WMC拉票的动机也包括对心怀不轨的人感到不满。--Lanwi1(留言) 2022年6月29日 (三) 09:46 (UTC)
我不支持完全采用安全投票而直接弃过往的投票方式不用，二者各有利弊。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年6月29日 (三) 17:09 (UTC)
那么哪些情况下使用安全投票，根据候选人意愿吗？--日期20220626（留言） 2022年6月29日 (三) 17:15 (UTC)
(！)意见：窃以为若技术可行，折衷方法或可考虑为“双轨并行”，两边界面重复投票者计属废票，且该用户视为扰乱选举。若候选人于表态参选时指定选择个人偏好之特定形式（不论“公开具名”或“安全匿名”形式），于七名用户投下反对该候选人指定形式之反对票后，亦即相当于同时投下“反对候选人和其指定形式”之反对票（相当于双重反对），则回归双轨并行制。之所以为七名反对者，敝人取自“罢免连署投票”之门槛；而同时反对候选人乃至出具理由反对其偏好形式，可见反对用户对于参选人之“强烈反对或不信任”，以致其偏好之投票形式皆反对（此时投下之七票反对票为公开投票），此时则回归双轨并行。个人意见，供参。--Kriz Ju（留言） 2022年6月29日 (三) 20:39 (UTC)
如果无法决定最终“胁迫投票”和“监督拉票”最终应选那个，似乎只能考虑某种双轨并行制。Kriz案二的“双重反对”部分不是很支持。看看其他人的意见。 ——魔琴 [ 留言 贡献 ] 2022年7月1日 (五) 13:26 (UTC)
上面就讲过了嘛，这社群连看都没在看，还在双轨投票并行制？完全说服不了人就说了吧，真是有够扭捏的。--Z7504非常建议必要时多关注评选（留言） 2022年7月1日 (五) 15:57 (UTC)

若有什么人适合普通投票，大概以非被罢免的前管理员以及部分被WMF除权的前管理员居多，这些前管理员没有严重违规行为。--Lanwi1(留言) 2022年7月3日 (日) 04:04 (UTC) 

 2016-08-20T17:44:49 Lanwi1 讨论 贡献 封禁解封了守望者爱孟 讨论 贡献 （封禁申诉）
--Mys_721tx（留言） 2022年7月3日 (日) 13:27 (UTC)
@Mys 721tx：那是过去的我，我从爱孟被禁制后才明白自己的问题。现在的我已经不再是2018年4月以前的我了，人是有成长的。--Lanwi1(留言) 2022年7月3日 (日) 13:36 (UTC)
所以你觉得自己的问题是？--日期20220626（留言） 2022年7月3日 (日) 13:38 (UTC)
我当时的问题是擅自解封，现在因为在爱孟事件中吸取教训，所以在Walter Grassroot事件中未犯相同错误。--Lanwi1(留言) 2022年7月3日 (日) 13:47 (UTC)
像上面这样的列出过去的问题对现在的我而言已经没有意义了，现在的我早已不想再碰像爱孟这样的封禁，在Walter Grassroot的封禁案我已经做到不想碰了。不明事理者就是不理解正常人犯错后会改进自己的行为，使自己不会再犯相同错误。--Lanwi1(留言) 2022年7月3日 (日) 18:04 (UTC)

我(＋)支持采用安全投票。“无法考虑中立票的意见”称不上是个问题，要想发表意见，可以去相应的RFA页面。“双轨并行”意味着仍要承受部分传统投票的缺点，我觉得没有必要；如果用户愿意，他们也可以在RFA页面表达支持或反对的意见。--CuSO4 2022年7月7日 (四) 04:23 (UTC)

如果要继续使用安全投票，是因为试验还没结束，需要“Key person”（指有影响力的关键人物）参选才能证明安全投票的效果。--Lanwi1(留言) 2022年7月11日 (一) 11:19 (UTC)

要不然就再“试行”几次？—— Eric Liu 創造は生命（留言・留名・学生会） 2022年7月11日 (一) 13:48 (UTC)
不知道谁想参选。如果我有方案，那就让包括部分被WMF除权的在内的人集中参选，正好消除对去年的基金会行动的最大不满，即活跃的反破坏管理员被除权。--Lanwi1(留言) 2022年7月11日 (一) 16:18 (UTC)
看来按这社群速度，要不我们再临时数次试试看比较好。Ghren🐦🕛 2022年7月12日 (二) 16:25 (UTC)
我的意见就是再次试验，问题是谁想参选？--Lanwi1(留言) 2022年7月13日 (三) 01:52 (UTC)
上次试验通过后很快就有人提名。应该不用担心没人参选的问题。如果再次试验可以尝试一下多人同时参选。设立一周左右的提名期，通过提名的候选人集中使用安全投票选举。--Steven Sun（留言） 2022年7月13日 (三) 09:22 (UTC)
多人同时参选最好，我已经想好提名谁了。--Lanwi1(留言) 2022年7月13日 (三) 09:42 (UTC)
但是再次“试行”安全投票是否需要社群授权？—— Eric Liu 創造は生命（留言・留名・学生会） 2022年7月15日 (五) 03:19 (UTC)
跟上一次试验一样，再次试验。--Lanwi1(留言) 2022年7月15日 (五) 10:44 (UTC)
上次“试行”系经社群投票授权，这次虽然不一定要重新进行表决，但仍应得到社群共识。另外，还要多“试行”几次，这也需要讨论。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年7月15日 (五) 12:00 (UTC)

(！)意见：可以采用双轨制，但普通投票只能投带有意见的中立票，而且不能重复投。这相当于行政员只考虑没有使用安全投票的使用者的意见。Acetophenone（留言） 2022年7月14日 (四) 18:19 (UTC)

(＋)支持完全使用安全投票，并可在对应的 RFA 页面发表意见。--冥王欧西里斯（留言） 2022年7月12日 (二) 09:24 (UTC)

看样子要继续使用安全投票了，安全投票暂行规定是否需要修改？--Lanwi1(留言) 2022年7月20日 (三) 10:08 (UTC)

如果社群就相关议题达成共识，我可以协助调整规定内容。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年7月20日 (三) 13:01 (UTC)
整理一下上面的讨论？--冥王欧西里斯（留言） 2022年7月24日 (日) 00:24 (UTC)
我觉得要讨论的议题至少有：安全投票是否与原投票方式并行；以及如何修改安全投票暂行规定以应用于未来之申请等。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年7月31日 (日) 07:43 (UTC)
如果此次决定要再次试验，建议在此前试行的基础上放开人数限制，即提名期达到票数要求即可参选。--Yining Chen（留言|签名页） 2022年7月24日 (日) 01:02 (UTC)
暂时支持再次试验，意见同Yining。 ——魔琴 [ 留言 贡献 ] 2022年8月1日 (一) 06:37 (UTC)
这独裁社群真的在搞笑，原来过了一个多月的讨论了结果还是要用安全投票嘛，都已经故意不想理会了。那请问为何没有办法直接6月底、7月初左右的时候就说继续用安全投票，非要等到8月才能做出决定呢？肯定是因为维基百科已经是一个标准的“Parkinson's Law”了。搞笑的东西，原来要不要用安全投票要犹豫一个多月那么久？--Z7504非常建议必要时多关注评选（留言） 2022年8月5日 (五) 17:59 (UTC)
社群讨论流程确实推进地有些慢，不过还轮不到您冷嘲热讽呢。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年8月6日 (六) 14:15 (UTC)
中维不重视，所以推进就是慢。--Lanwi1(留言) 2022年8月8日 (一) 03:43 (UTC)
好了好了，既然都知道推进慢就不要在没意义的讨论中浪费时间了。再次试验大概相比这次试验需要调整哪些内容？--BlackShadowG Slava Ukraini! 2022年8月8日 (一) 10:55 (UTC)
目前看起来大概就还要不要保留传统投票吧？但上面的讨论看起来似乎比较倾向仅供表达意见，不做投票用。--冥王欧西里斯（留言） 2022年8月8日 (一) 11:47 (UTC)
安全投票暂行规定看起来不需要修改，只需要多人参选。--Lanwi1(留言) 2022年8月9日 (二) 04:38 (UTC)
但若需支持多人参选，就需要修改“暂行规定”；而且中维最终还是需要一个“永久”规定。所以不如趁此机会直接制定安全投票指引。 --Yining Chen（留言|签名页） 2022年8月12日 (五) 15:19 (UTC)
建议安全投票暂行规定先继续实行，安全投票指引现在由于社群讨论流程慢而不宜直接制定。--Lanwi1(留言) 2022年8月12日 (五) 15:42 (UTC)
根据社群所达成共识之不同，亦有可能只须微调暂行规定以继续适用于当前之情况。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年8月12日 (五) 15:46 (UTC)
微调有可能，但不知道要等到什么时候才有共识。--Lanwi1(留言) 2022年8月12日 (五) 16:48 (UTC)

调整“安全投票暂行规定”

如果只需要支持多人参选，则可对现“暂行规定”中“预提名”一节进行如下微调：
现行条文

预提名：由于未来一场选举之被提名者以一人为限，应当在互助客栈其他区集中进行预提名作业；愿意接受正式提名并回答前述三个基本问题、最先得到七位具人事任免投票资格之用户联署支持，且符合成为管理员之资格者，经行政员确认，即获得正式提名，将优先进行选举，并应比照前述之一般流程另行设置个人选举页面。若最先获得足够联署支持者未能符合前述要求，则应依序递补以决定获正式提名者。

提议条文

预提名：未来一场选举将仿照此前的安全投票选举流程，统一在互助客栈其他区进行预提名。在第一位候选人预提名提出之时，为期七天的预提名程序即开始，在此七天内皆可提名其他候选人。在此七天内，愿意接受正式提名并回答前述三个基本问题、得到七位具人事任免投票资格之用户联署支持，且符合成为管理员之资格者，经行政员确认，即获得正式提名，并将统一进行选举，且应比照前述之一般流程另行设置个人选举页面。依照社群2022年4月的共识，此次预提名不受前次“检验冷静期”限制。

--Yining Chen（留言|签名页） 2022年8月13日 (六) 03:57 (UTC)
别忘了修正投票资格，上次投票中发现的问题。--Xiplus#Talk 2022年8月13日 (六) 07:01 (UTC)

(＋)支持--Lanwi1(留言) 2022年8月13日 (六) 05:45 (UTC)

(～)补充：对于上方提到的投票资格，结合上一次投票的实践，建议再向暂行规定中加入如下内容：
提议条文

投票资格 由于技术限制，依照Wikipedia:忽略所有规则，此次安全投票的投票资格要求与Wikipedia:人事任免投票资格之规定稍有差异。符合以下两项之至少一项条件者有权投票：

  1. 投票预提名开始120天前，编辑至少500次；并在预提名开始前90天内至少有1次编辑（不包括任何用户页及用户对话页）；
  2. 编辑至少3000次，或编辑条目至少1500次。

另外，被全站无限期封锁、全域锁定；预提名结束前被封锁、禁制维基百科命名空间的用户不得参与投票。

其余要求请参考人事任免投票资格、申请成为管理人员等方针指引。

希望能够就以上两项更改提议进行讨论并达成共识。--Yining Chen（留言|签名页） 2022年8月13日 (六) 14:13 (UTC)
这是技术说明文件，不是指引应有的行文。指引可以规定工具应遵守的程序或功能，但不应规定仅能使用特定工具。--Xiplus#Talk 2022年8月14日 (日) 03:12 (UTC)
候选人的部分，我之前提供的列表是通用版本，因此不会排除候选人，但只要将这份列表再根据各别RFA进行处理，就可以排除候选人，在指引内写“由于技术限制”显然是不对的。--Xiplus#Talk 2022年8月14日 (日) 03:13 (UTC)
机器人和多重账号的部分，都是傀儡方针规定无投票权的范围，但因为机器人账号是技术上可自动排除的投票权人，所以才在自动列表上直接排除，但这不代表未被排除的就有投票权，一切都还是要看傀儡方针和其他方针的规定，因此在指引内复述是不必要且不正确的。--Xiplus#Talk 2022年8月14日 (日) 03:18 (UTC)
另外我不懂为何要提到IAR？制定规则的时候就不应该制定一个已经预期会有错误的规则，导致之后必须援引IAR。--Xiplus#Talk 2022年8月14日 (日) 03:34 (UTC)
关于首句“技术限制”及其后所提到的IAR，针对的都是上一次有人质疑的“基准时间问题”。毕竟依照现行Wikipedia:人事任免投票资格方针，所谓“基准时间”必须是“投票正式开始”的时间。所以把“技术限制”和“IAR”写入其中。如果要更改人事任免投票资格方针，可能需要另开讨论，整体的流程也可能会更加冗长。--Yining Chen（留言|签名页） 2022年8月14日 (日) 03:42 (UTC)
直接继承人事任免投票资格方针并定义基准时间不就好了？例如“投票：...在预提名开始之时具人事任免投票资格...”--Xiplus#Talk 2022年8月14日 (日) 03:50 (UTC)
还有资格为何一个是预提名结束，另一个是开始？--Xiplus#Talk 2022年8月15日 (一) 01:22 (UTC)
已解决。--Yining Chen（留言|签名页） 2022年8月15日 (一) 03:16 (UTC)
考虑之后重拟一案。另外预提名作业之期限何以定为三日？—— Eric Liu 創造は生命（留言・留名・学生会） 2022年8月14日 (日) 11:13 (UTC)
考虑到上一次预提名过程进行的速度，个人认为预提名时间过长可能会使候选人的数量超过社群能有效处理的范围，进而产生其他问题。--Yining Chen（留言|签名页） 2022年8月14日 (日) 15:00 (UTC)
在以前也没有限制同时进行RFA的数量，增加预提名会有什么问题吗？--Xiplus#Talk 2022年8月14日 (日) 15:03 (UTC)
似乎确实无必要，因此参考WP:共识修改为七天。--Yining Chen（留言|签名页） 2022年8月14日 (日) 15:49 (UTC)
目前看起来就这样了，还有什么要改的吗？--冥王欧西里斯（留言） 2022年8月14日 (日) 23:31 (UTC)
@Xiplus、S8321414、Ericliu1912、Lanwi1：若无进一步意见，是否可以在近几日对此更改进行公示，或是如Ericliu1912所言，由其重拟一案？--Yining Chen（留言|签名页） 2022年8月18日 (四) 10:38 (UTC)
目前修改的条文应该还可以，暂时没看到重拟一案的必要。--冥王欧西里斯（留言） 2022年8月18日 (四) 11:36 (UTC)
封锁对投票资格的影响检查时间点仍然定在通过提名之时没有问题吗？例如是否也改成提名开始之时或这段区间都算？--Xiplus#Talk 2022年8月18日 (四) 12:00 (UTC)
另外打算再次进行实验的理由是要支持多人参选，但目前规定看起来并没有针对多人这方面做出规范，例如在多长时间段内通过预提名的候选人可以“合并进行选举”。--Xiplus#Talk 2022年8月18日 (四) 12:01 (UTC)
  1. 这个问题似乎与是否采用安全投票无关，不太清楚以前的普通投票实践中是否出现过与封禁期限有关的问题（如在RFA进行期间被解封的用户是否有投票权）？
  2. 依照现在草拟的方案，是（符合相关条件的）候选人在预提名进行的七天内，只要有七名用户投票支持，就算作符合标准。并未再试图设立一个“从预提名到投票数达标”的时间限制。--Yining Chen（留言|签名页） 2022年8月18日 (四) 12:54 (UTC)
    (1). 普通投票中只要能编辑投票页就有投票权，相反来说，投票期间只要持续被封锁（含部分封锁）以致无法编辑投票页，就等于无投票权，但因为安全投票需要预先设定投票权人名单，极不可能在投票过程中更改，所以才要决定判定被封锁无投票权的规则，上次安全投票定为提名通过之时，不过与人事任免投票资格的基准时间为提名开始之时不同，我才在此提出是否要再次考虑定这个时间是否合理。 (2). 我的意思是，在第一个提名通过就会开始准备安全投票，但假设之后又有新的候选人提名通过，理应可以于同一个投票中一并投票（因为安全投票筹备需要不少时间），但若之后持续又有新的提名通过（假设每3天就有新提名通过，即第1、4、7、10、13...天都有新提名通过），那么究竟哪些候选人能够赶上同一个投票，哪些候选人就裁定排到下次投票（毕竟不可能无限等候后面的候选人提名通过）。--Xiplus#Talk 2022年8月18日 (四) 13:09 (UTC)
    (1)问题，我个人认为或可以延续先前做法，但或许需要等待其他意见。(2)问题，上文的表述可能不是很清楚。并不是针对每一个候选人单独开投票，而是所有用户统一在先前计划好的的某七天内进行预提名操作，也就是说，该修正案只对下一次的安全投票选举负责；在整体的投票过程中，只会出现“一个”七天的预提名。--Yining Chen（留言|签名页） 2022年8月18日 (四) 14:09 (UTC)
    (2) 不同的候选人要怎么在同一个7天内进行预提名？提出预提名的时间本来就会有所不同，如果这个7天预提名进行到第3天，是否可再提名一个候选人？--Xiplus#Talk 2022年8月19日 (五) 01:31 (UTC)
    (2) 既然已经留出了7天的时间，那么在这七天内的任意一天提名都应当是可以的。毕竟时间相对较充裕，即使是在预提名第二日再提名，与第一日相比效果或许也不会相差很多。--Yining Chen（留言|签名页） 2022年8月19日 (五) 02:50 (UTC)
    那如果第7天才提名另一位候选人呢？另外这个7天期限是单一位候选人的期限，还是这次联合选举的提名期限？--Xiplus#Talk 2022年8月19日 (五) 02:55 (UTC)
    “第七天才提名”，这是提名人自己的选择，即使大概率失败也与他人无关；另外，这个“七天”的期限在整体的投票过程中，只出现“一次”，或许也就是指“联合选举的提名期限”。--Yining Chen（留言|签名页） 2022年8月19日 (五) 03:01 (UTC)
    我理解了，不过在目前提议条文看不出这个意思。我重新整理一下规定：“未来一场选举将仿照此前的安全投票选举流程，统一进行预提名。在第一位候选人预提名提出之时，为期七天的预提名程序即开始，在此七天内皆可提名其他候选人，愿意接受正式提名并回答前述三个基本问题、在此七天内得到七位具人事任免投票资格之使用者联署支持，且符合成为管理员之资格者，经行政员确认，皆可获得正式提名，并将一并进行选举，且应比照前述之一般流程另行设定个人选举页面。”--Xiplus#Talk 2022年8月19日 (五) 03:14 (UTC)
    感谢。已整理并更新修正草案。--Yining Chen（留言|签名页） 2022年8月19日 (五) 03:26 (UTC)
    “在此七天内得到七位具人事任免投票资格之使用者联署支持”应明确说明需在这个七天内的连署才有效。--Xiplus#Talk 2022年8月20日 (六) 05:52 (UTC)
    已尝试修改文本。--Yining Chen（留言|签名页） 2022年8月20日 (六) 10:10 (UTC)
我认为没有意见也不需要重拟一案。--Lanwi1(留言) 2022年8月18日 (四) 13:04 (UTC)
我也认为没问题----脳補｡◕‿◕｡讨论 2022年8月19日 (五) 13:42 (UTC)
预提名地点“互助客栈其他区”为何被删掉了？--Xiplus#Talk 2022年8月20日 (六) 05:50 (UTC)
操作疏忽，现 已解决。--Yining Chen（留言|签名页） 2022年8月20日 (六) 10:10 (UTC)
我个人认为不需要在第二部分修正案内引用“忽略所有规则”，因为特别法本就优先于普通法，而且不必另开章节，直接置于原〈安全投票暂行规定〉一节中即可：
现行条文

（略）

  1. （略）
  2. （略）
  3. 投票过程：
    （略）
    • 投票：安全投票开启后，应至少持续二周，并应有至少二位管理人员与其他监管员共同协助监票。具人事任免投票资格，且在被提名者经行政员确认获得正式提名之时未被封锁或禁制编辑维基百科命名空间的使用者可以投下支持票、反对票或中立票。投票期间，投票者可以随时改变自己的决定，其态度按投票截止时为准。选举之有效票比照前述之一般流程仅包括上述可投票者所投的支持票及反对票，中立票属无效票，仅将在临界情况下被考虑。
    （略）

（略）

提议条文

（略）

  1. （略）
  2. （略）
  3. 投票过程：
    （略）
    • 投票：安全投票开启后，应至少持续二周，并应有至少二位管理人员与其他监管员共同协助监票。符合以下二项中至少一项条件，且在预提名结束前未被封锁或禁制编辑维基百科命名空间的使用者可以投下支持票、反对票或中立票：
      1. 投票预提名开始120日前编辑至少500次，并在预提名开始前90日内编辑至少1次（不包括任何使用者页面及使用者讨论页面）；
      2. 编辑至少3,000次，或编辑条目至少1,500次。
    投票期间，投票者可以随时改变自己的决定，其态度按投票截止时为准。选举之有效票比照前述之一般流程仅包括上述可投票者所投的支持票及反对票，中立票属无效票，仅将在临界情况下被考虑。
    （略）

（略）

以上。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年8月21日 (日) 06:23 (UTC)

建议将差异部分上色，如此会更为清楚。--冥王欧西里斯（留言） 2022年8月22日 (一) 03:01 (UTC)
已经照办。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年8月22日 (一) 15:56 (UTC)
也就是说，这次会修正暂行规定的“预提名”与“投票”两条没错吧？--冥王欧西里斯（留言） 2022年8月22日 (一) 23:30 (UTC)
(－)倾向反对将限制条件嵌于流程正文当中。因为或许会使正文重点内容不够突出，格式上个人认为似乎也稍显不协调。--Yining Chen（留言|签名页） 2022年8月23日 (二) 14:42 (UTC)
(！)意见：那么阁下认为要放在哪里呢？目前看起来这是必要的修正。--冥王欧西里斯（留言） 2022年8月23日 (二) 23:45 (UTC)
如我在上文所写，另开一节（原暂行规定中有关的要求内容当然需要删掉，但上文未写出）。--Yining Chen（留言|签名页） 2022年8月24日 (三) 11:00 (UTC)
我不认为投票资格应该单开章节放置，这样比重反而不均；将其置于既有之流程中毫无问题，至多以注释处理也就已经足够。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年8月24日 (三) 13:10 (UTC)
另一种方法是直接修订人事任免资格方针，这样不仅不会破坏原暂行规定比重，甚至一大部分条文都不用改了（“具人事任免资格者”可以直接沿用）。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年8月25日 (四) 03:24 (UTC)
但目前该投票流程还只是“暂行规定”，无法确定以后流程是否与现在相同（即该新增规定是否有“通用性”，或是否值得为此修改方针）。因此不应该直接修订人事任免资格方针。--Yining Chen（留言|签名页） 2022年8月25日 (四) 10:08 (UTC)
我前面就说过了，只需要加少少几个字即可，“投票：...共同协助监票。在预提名开始之时具人事任免投票资格，且在被提名者...”。--Xiplus#Talk 2022年8月25日 (四) 10:51 (UTC)
支持这个表述。--Steven Sun（留言） 2022年8月25日 (四) 11:39 (UTC)
这样不错。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年8月25日 (四) 14:54 (UTC)
(＋)支持 --Yining Chen（留言|签名页） 2022年8月26日 (五) 02:34 (UTC)
整理上述提案内容（无关内容已省略）：
现行条文
  • 预提名：由于未来一场选举之被提名者以一人为限，应当在互助客栈其他区集中进行预提名作业；愿意接受正式提名并回答前述三个基本问题、最先得到七位具人事任免投票资格之用户联署支持，且符合成为管理员之资格者，经行政员确认，即获得正式提名，将优先进行选举，并应比照前述之一般流程另行设置个人选举页面。若最先获得足够联署支持者未能符合前述要求，则应依序递补以决定获正式提名者。
  • 投票过程：
    • 投票：安全投票开启后，应至少持续二周，并应有至少二位管理人员与其他监管员共同协助监票。具人事任免投票资格，且在被提名者经行政员确认获得正式提名之时未被封锁或禁制编辑维基百科命名空间的使用者可以投下支持票、反对票或中立票。投票期间，投票者可以随时改变自己的决定，其态度按投票截止时为准。选举之有效票比照前述之一般流程仅包括上述可投票者所投的支持票及反对票，中立票属无效票，仅将在临界情况下被考虑。
提议条文
  • 预提名：未来一场选举将仿照此前的安全投票选举流程，统一在互助客栈其他区进行预提名。在第一位候选人预提名提出之时，为期七天的预提名程序即开始，在此七天内皆可提名其他候选人。在此七天内，愿意接受正式提名并回答前述三个基本问题、得到七位具人事任免投票资格之用户联署支持，且符合成为管理员之资格者，经行政员确认，即获得正式提名，并将统一进行选举，且应比照前述之一般流程另行设置个人选举页面。依照社群2022年4月的共识，此次预提名不受前次“检验冷静期”限制。
  • 投票过程：
    • 投票：安全投票开启后，应至少持续二周，并应有至少二位管理人员与其他监管员共同协助监票。在预提名开始时具人事任免投票资格，且在被提名者经行政员确认获得正式提名之时未被封锁或禁制编辑维基百科命名空间的使用者可以投下支持票、反对票或中立票。投票期间，投票者可以随时改变自己的决定，其态度按投票截止时为准。选举之有效票比照前述之一般流程仅包括上述可投票者所投的支持票及反对票，中立票属无效票，仅将在临界情况下被考虑。
公示7日，2022年9月5日 (一) 14:45 (UTC) 结束。--Yining Chen（留言|签名页） 2022年8月29日 (一) 14:45 (UTC)
(＋)支持--Ghren🐦🕑 2022年8月30日 (二) 18:02 (UTC)
(＋)支持。--Kriz Ju（留言） 2022年8月31日 (三) 23:14 (UTC)
(＋)支持--Lanwi1(留言) 2022年9月1日 (四) 03:56 (UTC)
公示期间无异议，通过。按照此前的流程，现在可以开始准备进行预提名，并可以联系Phab准备安全投票相关事宜。--Yining Chen（留言|签名页） 2022年9月5日 (一) 14:55 (UTC)

表格修复

因为安全投票的问题，表格出现很多错误，目前我正在想办法修复。已经修复每人的名字前有等号的问题--0xDeadbeef（留言） 2022年9月24日 (六) 08:59 (UTC)

修改权限申请要求

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2022年10月18日 (二) 08:14 (UTC)。

目前在对权限（包括管理人员）的申请中，普遍存在这样一句话：“……最近一年内没有受到封禁（不合理封禁除外）……”。个人认为此处应修改为“封禁和编辑禁制”，因为这两者是非常相似的东西。部分编辑禁制技术上是通过“部分封禁”(partial block)实现的，而部分编辑禁制则是一种受影响用户和管理员之间的承诺（如果违反了这种承诺，将有更严厉的禁制）。 Stang★ 2022年9月20日 (二) 21:17 (UTC)

像是Wikipedia:编辑禁制纪录中春卷柯南、Bagida520情况的互动禁制要怎样处理（Special:diff/63555442）。如果因为有人因为这种程度的编辑禁制而不能选管理员的话，我感觉有问题。--Ghren🐦🕗 2022年9月21日 (三) 12:49 (UTC)
如果某两人之间存在着必须通过明确记录在案的“禁制”才可以解决（或缓解）的问题，咱认为你不能确保这样的人在沟通方面没有不可忽视问题。题外话，感觉这个处理略重。 Stang★ 2022年9月21日 (三) 14:00 (UTC)
我认为还是改为“最近一年内受到封禁或禁制者，管理员有权拒绝其权限申请”，不应该把封禁记录作为硬性标准。--GZWDer（留言） 2022年9月21日 (三) 14:24 (UTC)
你这话说的就跟如果我过去一年是清白的，管理员无权拒绝我获得权限一样。虽然从纯逻辑学来说我这句话作为刚才那句话的否命题，其真假跟原命题无关，但是不能排除会有人这么认为。--MilkyDefer >Keep calm and carry on. 2022年9月21日 (三) 16:17 (UTC)
个人感觉没有必要硬性规定，编辑禁制的情形各异，比较复杂。--YFdyh000（留言） 2022年9月21日 (三) 17:38 (UTC)

为使用者查核员选举导入安全投票机制并修正被选举资格

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2022年11月18日 (五) 16:14 (UTC)。

基于先前基金会对本地使用者查核权恢复的回应进行提案，有几处进行修正：

修正WP:CU

现行条文

申请资格 （前略）

一般情况下，被提名候选人应具备以下条件（非正式条件）：

  • 连续担任管理员3个月或以上；
  • 按照维基方针和守则使用管理员权限，没有破坏规则或滥用权限；
  • 积极行使管理员义务。

资格取消 具有用户查核资格的用户帐号，如果超过半年没有活动，用户查核资格将被取消。

（后略）

提议条文

申请资格 （前略）

一般情况下，被提名候选人应具备以下条件（正式条件）：

  • 应具有调查助理资格达半年或以上；
  • 其具备管理员权限资格一年或以上；
  • 按照维基方针和守则使用管理员权限，没有破坏规则或滥用权限；
  • 积极行使管理员义务。

资格取消 具有用户查核资格的用户帐号，如果超过半年没有活动，用户查核资格将被取消。使用者查核员的任期为两年，期满后其使用者查核员资格应取消，而连任则仅限一次并应重新办理选举。有人事任免投票资格的用户可以安全地提出自己的质疑，此质疑有效期为一年，或是到下次用户查核员选举之前；如果有超过25人之质疑关切，就会在两个月内触发罢免，除非该查核员选择不竞选连任。

（后略）

修正WP:CUP

现行条文

取得权限 只有监管员、部分维基媒体基金会职员、申诉专员和极少数的用户有权获得用户查核权限。除了申诉专员外，用户只能获得本地权限。

（后略）

提议条文

取得权限 只有监管员、部分维基媒体基金会职员、申诉专员和极少数的用户有权获得用户查核权限。除了申诉专员外，用户只能获得本地权限。在授予权限之前，所有中文维基用户查核员候选人都将会接受用户查核员社群的培训，以确保中文维基上的用户查核实践与全球社群一致。

（后略）

修正WP:RfA

现行条文

安全投票暂行规定 根据社群2022年9月的共识，未来一场管理员选举将使用安全投票（SecurePoll）系统。

未来一场使用安全投票系统的管理员选举将按照以下程序进行，不适用前述之一般流程：

  1. 提名或自荐：使用者可以提名自己为管理员，也可以提名另一个使用者为管理员。
  2. 检验冷静期：当管理员被提名者先前之管理员选举未通过或中途退选时，自投票终止或退选之时起，三个月（90日）内不应再次提出申请。在表态时谢绝提名者不受此限制。
  3. 投票过程：
    • 预提名：未来一场选举将仿照此前的安全投票选举流程，统一在互助客栈其他区进行预提名。在第一位候选人预提名提出之时，为期七天的预提名程序即开始，在此七天内皆可提名其他候选人。在此七天内，愿意接受正式提名并回答前述三个基本问题、得到七位具人事任免投票资格之用户联署支持，且符合成为管理员之资格者，经行政员确认，即获得正式提名，并将统一进行选举，且应比照前述之一般流程另行设置个人选举页面。依照社群2022年4月的共识，此次预提名不受前次“检验冷静期”限制。
    • 发表意见：在被提名者经行政员确认获得正式提名之时起二周内，任何使用者都可以发表意见，包含提问及讨论等。二周后，被提名者仍可以回答问题，而其他使用者则不应再提出新问题或继续展开讨论。与此同时，应尽速筹备安全投票。投票时间之起始点可以视乎实际准备情况需要提前或延后，惟发表意见之时间长短不应有所增减。
    • 投票：安全投票开启后，应至少持续二周，并应有至少二位管理人员与其他监管员共同协助监票。在预提名开始时具人事任免投票资格，且在被提名者经行政员确认获得正式提名之时未被封禁或禁制编辑维基百科命名空间的用户可以投下支持票、反对票或中立票。投票期间，投票者可以随时改变自己的决定，其态度按投票截止时为准。选举之有效票比照前述之一般流程仅包括上述可投票者所投的支持票及反对票，中立票属无效票，仅将在临界情况下被考虑。
    • 计票和评估：投票结束后，应由协助监票之管理人员计算出得票比率，并会同行政员根据前述之一般流程标准判断投票是否达成共识。
    • 执行结果：若投票通过，行政员或监管员将赋予被提名者管理员权限；不通过则做出相应的操作。
提议条文

安全投票暂行规定 根据社群2022年9月的共识，未来一场包含使用者查核员在内的管理人员选举将使用安全投票（SecurePoll）系统。

未来一场使用安全投票系统的包含使用者查核员在内的管理人员选举将按照以下程序进行，不适用前述之一般流程：

  1. 提名或自荐：使用者可以提名自己为包含使用者查核员在内的管理人员，也可以提名另一个使用者为包含使用者查核员在内的管理人员。
  2. 检验冷静期：当包含使用者查核员在内的管理人员被提名者先前之包含使用者查核员在内的管理人员选举未通过或中途退选时，自投票终止或退选之时起，三个月（90日）内不应再次提出申请。在表态时谢绝提名者不受此限制。
  3. 投票过程：
    • 预提名：未来一场选举将仿照此前的安全投票选举流程，统一在互助客栈其他区进行预提名。在第一位候选人预提名提出之时，为期七天的预提名程序即开始，在此七天内皆可提名其他候选人。在此七天内，愿意接受正式提名并回答前述三个基本问题、得到七位具人事任免投票资格之用户联署支持，且符合成为相对应的管理人员之资格者，经行政员确认，即获得正式提名，并将统一进行选举，且应比照前述之一般流程另行设置个人选举页面。依照社群2022年4月的共识，此次预提名不受前次“检验冷静期”限制。
    • 发表意见：在被提名者经行政员确认获得正式提名之时起二周内，任何使用者都可以发表意见，包含提问及讨论等。二周后，被提名者仍可以回答问题，而其他使用者则不应再提出新问题或继续展开讨论。与此同时，应尽速筹备安全投票。投票时间之起始点可以视乎实际准备情况需要提前或延后，惟发表意见之时间长短不应有所增减。
    • 投票：安全投票开启后，应至少持续二周，并应有至少二位管理人员与其他监管员共同协助监票。在预提名开始时具人事任免投票资格，且在被提名者经行政员确认获得正式提名之时未被封禁或禁制编辑维基百科命名空间的用户可以投下支持票、反对票或中立票。投票期间，投票者可以随时改变自己的决定，其态度按投票截止时为准。选举之有效票比照前述之一般流程仅包括上述可投票者所投的支持票及反对票，中立票属无效票，仅将在临界情况下被考虑。
    • 计票和评估：投票结束后，应由协助监票之管理人员计算出得票比率，并会同行政员根据前述之一般流程标准判断投票是否达成共识。
    • 执行结果：若投票通过，行政员或监管员将赋予被提名者相对应的管理人员权限；不通过则做出相应的操作。

以上提请社群讨论。--🍫巧克力～✿ 2022年10月24日 (一) 04:37 (UTC)

别着急，修改CU选举机制的必要条件是社群同意重新引入CUer，而这件事看起来没那么容易 ——魔琴 [ 留言 贡献 ] 2022年10月24日 (一) 04:53 (UTC)
这部分我觉得可以先修方针，等之后社群确定要正式重启，前置工作与改动范围也不会那么大。--🍫巧克力～✿ 2022年10月24日 (一) 05:00 (UTC)
问题：
  1. “应具有调查助理资格达半年或以上”：街灯惨被失去选CU资格。而且还变成了必要条件，没有必要吧。
  2. RFA还有很多问题要修。比如这处就是一例。现在讨论也急了一点。
  3. 先说服社群需要CU再搞这个提案。
--Ghren🐦🕛 2022年10月24日 (一) 04:54 (UTC)
  • 事实上，“应具有调查助理资格达半年或以上”可以调整成为管理员、行政员或调查助理这三个条件并列则一即可，是可以视情况修正的。
  • 每一次投票当然也会有事前讨论与事后调整，这部分并不影响CU权限导入安全投票机制的问题，也因为是扩大套用，之后选举流程在调整的过程中也会因为涵盖范围大而更有弹性一些。
  • 如同我上面说的，这部分我觉得可以先修方针，等之后社群确定要正式重启，前置工作与改动范围也不会那么大。
--🍫巧克力～✿ 2022年10月24日 (一) 05:09 (UTC)
不同意将“非正式条件”改为“正式条件”。调查助理的资历可以是“加分”，但不应该强制纳入权限之申请门槛。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年10月24日 (一) 05:27 (UTC)
现行条文

申请资格 （前略）

一般情况下，被提名候选人应具备以下条件（非正式条件）：

  • 连续担任管理员3个月或以上；
  • 按照维基方针和守则使用管理员权限，没有破坏规则或滥用权限；
  • 积极行使管理员义务。

资格取消 具有用户查核资格的用户帐号，如果超过半年没有活动，用户查核资格将被取消。

（后略）

提议条文

申请资格 （前略）

一般情况下，被提名候选人应具备以下条件（非正式条件）：

  • 其具备行政员、管理员等管理人员或调查助理权限资格一年或以上；
  • 按照维基方针和守则使用管理人员权限，没有破坏规则或滥用权限；
  • 积极行使管理人员义务。

资格取消 具有用户查核资格的用户帐号，如果超过半年没有活动，用户查核资格将被取消。使用者查核员的任期为两年，期满后其使用者查核员资格应取消，而连任则仅限一次并应重新办理选举。有人事任免投票资格的用户可以安全地提出自己的质疑，此质疑有效期为一年，或是到下次用户查核员选举之前；如果有超过25人之质疑关切，就会在两个月内触发罢免，除非该查核员选择不竞选连任。

（后略）

以上。--🍫巧克力～✿ 2022年10月24日 (一) 05:33 (UTC)

讨论

此处原有文字已被原作者（User:Yining Chen）移除。2022年10月24日 (一) 07:48 (UTC)
为什么“连任则仅限一次”？所以在你的方案下每个CUer都只能最多当四年？——〚 玖宸 〛 2022年10月24日 (一) 12:32 (UTC)
理论上可以当二任，间隔一任然后再参选，之后以此类推。不过个人觉得似乎是没有必要这样规定。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年10月25日 (二) 00:45 (UTC)
有关这部分设计是参考基金会回应当中有关连任的释疑，那考量到长时间的任期处理高敏感隐私政策对社群来说可能不是那么的健康，所以才提出限制连任的部分，那当然中间经过休息期，如刘酱所述，间隔一任然后再参选，之后以此类推，这样是没有太大的问题的。--🍫巧克力～✿ 2022年10月25日 (二) 04:44 (UTC)
若社群信任当事人处理某些隐私事务而赋予其使用者查核权限，那么禁止维基人连任使用者查核员是否代表这种信任是有所谓“有效期限”的，还是会过了一段时间便“突然不信任”当事人？就此而言，我不甚认同该等规定。基金会之所以没有限制使用者查核员连任，相信与此理据也不相差太远；任期制本身就是一种确认社群对当事人信任之机制。而实际上来说，社群中是否有充足之人选可使吾人信任，多到能够特地错开任期、轮流“值班”的地步？这也是一个问题。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年10月25日 (二) 08:39 (UTC)
不同意只能连任一次，做的好为什么要强迫炒鱿鱼？基金会的回应最多只是希望定期评核，怎么也不是在说永久担任是不健康的。我反倒支持担任调查助理几个月作为必要条件，这样才能更有效验证是否对调查程序十分了解，不必为街灯或者其它前度查核员大开绿灯。--Opky9407（留言） 2022年10月25日 (二) 11:47 (UTC)
(－)强烈反对clerk能够在不担任管理员的前提下选举成为用户查核员。若用户查核员选举只需“担任clerk满一年”即可参选，那岂不是意味着在中维，对用户查核员的要求甚至不如管理员？在中维尚有CU权限时曾出现过

“至少3个管理员，说过：把自己的管理员账户给我。但都被我拒绝。我回答：等你们什么时候混成CUer了，再把账户给我。现在CUer才是王道。管理员虽然也重要，但可CUer相比差得远。”

——KOKUYO（转述）
这种言论。假若在这种社群环境下依然继续降低用户查核员的标准，那该如何才能确保社群的信息安全，避免第二次事故发生？简而言之，个人不认为“连管理员都尚未担任”的用户有资格担任CUer。这样的用户可能并不值得社群信任。--Yining Chen（留言|签名页） 2022年10月26日 (三) 14:32 (UTC)
身为助理的我同样(－)强烈反对助理担任一段时间即可成为用户查核员。真的不可以。--路西法人 2022年10月31日 (一) 03:30 (UTC)
说句好笑的，成为查核助理并不能行使管理员义务，也就是助理这个问题事实上是不存在的（--1233 （T / C） 2022年11月8日 (二) 12:15 (UTC)
可以考虑任期制（参照全域监管员选举办法，任期一到需要接受社群重新审核资格，另可考虑让行政员来决定审核共识），不过设定连任次数(－)反对。我认为被提名人应该同时有clerk经验和管理经验，而不是只需要clerk就好。--（☎）dt 2022年10月31日 (一) 03:56 (UTC)
为减少后续的任何法律问题，我认为应当在查核员选举的资格上要求用户必须在查核员选举前签署并出现在这个列表上（非公开信息/Confidentiality Agreement）。--1233 （T / C） 2022年11月8日 (二) 12:11 (UTC)

管理人员选举的后续讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/其他。执行者：Jimmy-bot（留言） 2022年11月23日 (三) 08:14 (UTC)。

有关上下文，请参看上一次讨论和社群进行的第二次尝试。这个讨论串可能开的有点早，但是希望早点提出来可以多收到一些意见和建议。希望在本次讨论中可以明确这些问题：

  1. 管理员选举是否长期使用安全投票机制；如是并希望定期进行，每次选举应发生在什么时候，间隔如何。
  2. 其他的需要社群投票的用户组（如界面管理员/行政员/监督员）是否都需要使用安全投票机制。
  3. 安全投票进行中和结束后的监票人员应如何确定；作为参考，目前的监票人员是两位监督员（同时是签署了NDA的行政员）
  4. 安全投票的性质决定了其相对较难执行“延长投票期”的操作，如果出现了临界情况，应如何处理。
  5. （补一个问题）安全投票是否需要隐藏投票人列表（voter-privacy=1）。现时设置为显示，如果设置为隐藏，将只有监票人可以看到谁投了票。

欢迎关注并给出意见。 Stang★ 2022年10月24日 (一) 12:48 (UTC)

补上了第五个问题。A Chinese user、​Yining Chen、​Sidishandsome和神秘悟饭 Stang★ 2022年10月25日 (二) 10:10 (UTC)
  1. (＋)支持长期使用安全投票机制。一个季度一次选举？或者一年？1、4、7、10月份也许不错。（这几个月份的节假日比较多，参与度和关注度也许更高）
  2. 需要。原因和上一次讨论中Sanmosa君给出的原因一致，即“只有安全投票能保证投票人的人身安全，因此只能统一使用安全投票”。
  3. 我认为在既有行政人员中进行轮值（或者讨论决定）似乎是可以的选择。
  4. 不是很了解安全投票平台的功能；是否可以继承原有票形表单另建投票页面继续投票？
拙见如上。-- （☎|♼） 2022年10月25日 (二) 03:45 (UTC)
如果一年进行四次安全投票选举，而每次选举都像此次管理员选举一样有10名甚至十名以上候选人，那么恐怕有一些问题会比较难处理，而且很可能与各类全域选举事务相冲突。--Yining Chen（留言|签名页） 2022年10月25日 (二) 06:04 (UTC)
基本上我觉得以后出现这状况的机会不多，你维可以活跃的人很多没错但能选的人不多，再扣掉不愿意选的候选人其实能选的就那些了，这次只是因为很久没RFA，所以能够选且愿意选的人过去都没机会出来选，这次才会有高达十位的候选人。--~~Sid~~ 2022年10月25日 (二) 06:12 (UTC)
想法(▲)同上。如果一年3次，我倾向于1、7、10月；如果一年2次，则倾向于4、10两月；如果一年1次，则倾向于10月。-- （☎|♼） 2022年10月25日 (二) 10:50 (UTC)
(～)补充针对第5个问题的看法：投票人列表应该隐藏。原因同2。我担心会有人根据名单去抓人问为什么还不投票；也有可能是多虑了。-- （☎|♼） 2022年10月25日 (二) 10:51 (UTC)
对问题5，我赞成投票期间应该隐藏列表。投票结束后可以去除时间、打乱顺序公开，参考附言形式。公开时机的上限和下限可能应确定。--YFdyh000（留言） 2022年10月25日 (二) 10:57 (UTC)
1. (＋)支持长期使用安全投票。定期选举适用于任期有限定的职位，不知为何提出，但此非反对。
2. 民选都需要安全投票。精英陪审判决则不然，可再商决。--神秘悟饭 2022年10月25日 (二) 04:38 (UTC)
4. 所谓临界情况，是因为此前的记名投票导致投票即开票，边投票边开票，引致催票、逼票等扰乱选举的乱象而产生的调和。现在不复存在此类乱象，亦应取消人为判断临界的空间，只以硬性标准判断。高于或达到某一标准即当选，低于则落选。不过80%对于有纷争的社群而言标准太高。敝人主张，人数达标及支持票≥80%，即成为长期管理员；人数达标及支持票≥70%而＜80%，即成为有半年试用期的管理员；支持票＜70%，即落选。半年试用的管理员在到期前二周举行续任选举，人数达标及支持票≥70%即转为长期管理员，＜70%则到期解任。--神秘悟饭 2022年10月25日 (二) 04:52 (UTC)
你说的这个咱觉得不错“人数达标及支持票≥80%，即成为长期管理员；人数达标及支持票≥70%而＜80%，即成为有半年试用期的管理员；支持票＜70%，即落选。半年试用的管理员在到期前二周举行续任选举，人数达标及支持票≥70%即转为长期管理员，＜70%则到期解任。”话说半年的临时管理员有点太短了咱推荐改成一年。咱非常支持长期使用安全同票，应该说所有涉及高级权限的选举都采用安全投票。--~~Sid~~ 2022年10月25日 (二) 05:17 (UTC)
我也纠结过一年还是半年，一年已经超出不少比例的用户的平均活跃期，对于纠错、对于如此高权限的人而言似乎太久。社群若认为一年为宜，亦可。--神秘悟饭 2022年10月25日 (二) 06:13 (UTC)
半年对考验和发挥能力应已足够。固定周期的续任选举，我有点担心选举前夕、期间改变行事风格或畏于行事。建议选举前开启两周的讨论区，允许指出、回应和讨论评议，不拘泥于问答形式；制止或分流过于离题、细节的讨论；至选举结束时关闭。--YFdyh000（留言） 2022年10月25日 (二) 11:10 (UTC)
能让原来当不了管理员的人分担干半年的活，即使间接导致他在两三个星期之内畏手畏脚也值得。开放讨论区可以考虑。--神秘悟饭 2022年10月25日 (二) 12:03 (UTC)
我是指“续任选举”，比如续期前几周停止参与任何争议性操作或讨论，继而保证上任长期管理员、避免选举前结仇/被指不当。--YFdyh000（留言） 2022年10月25日 (二) 12:22 (UTC)
我也是指“续任选举”。即使此人在续任选举前避免介入争议，也能为争取续任而分担不少没有争议的活。正因可能得罪人，我将长任门槛从80%下调到70%。--神秘悟饭 2022年10月25日 (二) 12:44 (UTC)
我对“忍半年”得以“长期”后执行争议性行为，有些担心。不过现有制度似乎没有更好。--YFdyh000（留言） 2022年10月25日 (二) 13:00 (UTC)
(＆)建议：有一妙计，可鼓励试用管理员解决争议：结合精英“预审”与选民选举。“预审”在续任选举前举行，由不兼任管理员的行政员、用户查核员、回退员、巡查员组成陪审团，对谋求续任的试用管理员在解决争议方面的表现进行公开讨论和一人一票的实名审决。若陪审团中80%或以上认为其在解决争议方面表现上佳，则其民选续任门槛为60%；若陪审团中60-80%（不含80%）认为其在解决争议方面表现上佳，则其民选续任门槛为65%；若陪审团中不到60%认为其在解决争议方面表现上佳，则其民选续任门槛维持70%。“预审”应在续任选举开始前完成并公布审决结果。“预审”由试用管理员自选是否举行，并非必要，放弃“预审”者则维持70%的续任门槛。而必要的选民讨论可与陪审团“预审”同时开始、分页办理，以减少成本。--神秘悟饭 2022年10月26日 (三) 01:13 (UTC)
个人很难理解这样的方案有何意义。如果大家认为“试用管理员”能够很好地处理相关问题，那么显然这名“试用管理员”在成为管理员前就已熟悉相关流程，且经常参与相关程序（相信很少有人会去处理自己不熟悉流程的问题）。那么大家自然会在最初时依照其贡献为其投票支持。为何要单独抽离出一个“预选投票”，把本已解决的有关问题重新提出，使其更加复杂呢？--Yining Chen（留言|签名页） 2022年10月26日 (三) 09:43 (UTC)
仍然不同意所谓“管理员任期制”。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年10月25日 (二) 12:04 (UTC)
如果解任或“行为纠正”流程依旧艰难，我目前赞成任期制以评估管理员行事是否有公信度。--YFdyh000（留言） 2022年10月25日 (二) 12:24 (UTC)
(～)补充对下文回应。我所指的任期，偏重“长期管理员”的任期评议。如上任后支持率降低，但未有大风波不会走上解任程序。对票数稍有不足是否要允许实践，我的观点是可以考虑、中立，取决于站内需求。--YFdyh000（留言） 2022年10月25日 (二) 15:03 (UTC)
(＋)赞成简化解任程序。--神秘悟饭 2022年10月26日 (三) 00:46 (UTC)
不知阁下所指的“管理员任期制”是否指我提议的“得70-80%支持票者试用”。此提议只适用于过不了原有当选门槛，即原来当不了管理员的人；对于既有管理员和今后达到长任当选门槛的人没有影响。顾及80%的门槛难以下修，才有此计。参选者也可在选前（参选时）声明不接受试用期，低于长任当选门槛即落选；行政员对此不赋权。--神秘悟饭 2022年10月26日 (三) 00:43 (UTC)
(－)反对“任期制”。管理员的权限很高，是否能够担任管理员应该从其日常参与站务及其编辑来进行判断，而不应该是以“实践”进行判断。( π )题外话：此前相关问题似乎曾在互联群讨论过。--Yining Chen（留言|签名页） 2022年10月25日 (二) 14:34 (UTC)
请见(▲▲)同上上10月26日 00:43 (UTC)的答复。--神秘悟饭 2022年10月26日 (三) 00:45 (UTC)
5. (＋)赞成隐藏投票人列表。但本人投票记录及时日应对本人可见，以免陷入忘记投过哪一个或被盗投而不自知的困境，不知技术上可否实现。--神秘悟饭 2022年10月25日 (二) 12:09 (UTC)
赞成。目前似乎已投过票的投票界面，默认显示为“中立”票被勾选？我看到感觉很诧异。--YFdyh000（留言） 2022年10月25日 (二) 12:23 (UTC)
因为发起的账号希望针对5个项目得到回应，回应如下(不再扩充解释或回复)
  1. (－)反对定期举行
  2. (－)反对在只有试办1次的情形下大范围使用安全投票，安全投票仍是试验性质
  3. 办理投票需要试验性质安全投票时，每次办理前讨论执行细节
  4. 不延长投票，如果票数相等，重新投票。办理投票前讨论执行细节
  5. 隐藏或显示都可以，但建议设置与真人傀儡、LTA、PROXY相关的技术障碍减少投票结果被操作的可能
--Rastinition（留言） 2022年10月25日 (二) 12:25 (UTC)
(！)意见 已是二次试行了吧。是否定期不置评，但如有共识可以继续“试验”、长期试验。讨论细节没问题，目前我不反对每次都预先确认乃至调整细节。重新投票不赞成（耗时耗力、未加充分讨论说服力不强），但如何评定暂无想法。赞成，个人想法是投票名单打乱顺序后公示一周，然后计票（或最终核定票数），期间监票人员也做检查（乃至接收署名/匿名意见？）。--YFdyh000（留言） 2022年10月25日 (二) 12:53 (UTC)
  • 有另一个问题，预提名期间，投票“联署”支持被提名者的用户，从常识来推断，基本上都会在后续的投票（如果有）中为候选人投支持票。如果继续采用预提名制，这部分用户的安全该如何保证？是否有用户顾虑相关问题而不敢参与预提名联署？--Yining Chen（留言|签名页） 2022年10月25日 (二) 14:38 (UTC)
    为非定期的上任/解任联署开安全投票，也许有技术问题？“联署区”允许反对乃至中立意见计入以开启投票，不确定是否可行，似乎不靠谱，且也许有违共识机制。--YFdyh000（留言） 2022年10月25日 (二) 15:08 (UTC)
    应当明确，如果联署与投票冲突，以投票结果为准。--高文海（留言） 2022年10月26日 (三) 06:20 (UTC)
    以投票为准是显然的，但此处所议是联署仍非匿名的问题。--YFdyh000（留言） 2022年10月26日 (三) 17:40 (UTC)
    联署没有必要匿名吧。如果他真心支持候选人自然不存在安全问题；如果他是被胁迫联署的，他完全可以在投票环节做正面表态然后投反对票，反正谁也不知道；再进一步讲，如果问题严重到对投票人员进行人身控制的程度，那么就不能在站内来解决这个问题了。--高文海（留言） 2022年11月8日 (二) 01:16 (UTC)
    “真心支持候选人自然不存在安全问题”未懂，联署投票有同等乃至更大的压力，影响着是否有人联署、是否开启后续投票。联署包括上任和解任等。--YFdyh000（留言） 2022年11月8日 (二) 03:00 (UTC)
  • (！)意见：
  1. 继续使用安全投票机制。但是不需要定期举行，因为预期后续不会像这样需要消化积压选举。
  2. 管理员、行政员由于潜在的安全威胁，需要继续实行安全投票。用户查核员也需要引入安全投票。但是界面管理员、监督员不需要安全投票，因为这两个权限的争议和威胁都不大，没必要将流程复杂化。
  3. 由本地行政员商议决定。如果连点票都能闹争议，说明行政员们也该OA2021式集体下岗了。
  4. 严格按数字判断，不再做弹性决策。从以往来看，争议比较大的临界情况是有团体进行恶意操作，而这种恶意操作可以分两种情况讨论：（1）临近投票结束时恶意灌票：换用新系统后，无法通过安全投票系统来识别出这种情况，所以无法采取什么对策；（2）向特定用户胁迫或施加压力投票：换用新系统后，即使被胁迫投票，也可以在不被发现的情况下默默改票，所以可以认为最终投票都是本人意志。
    换用新系统后，排除以上两种恶意操作，可认为其他投票（包括中立）都是正常操作，因此可以严格遵守80%的规则，不需要行政员来做决策。
  5. 建议隐藏名单，等社群一致认为站内安全威胁消失之后再恢复。
--高文海（留言） 2022年10月26日 (三) 02:24 (UTC)
就第四条，目前设置公开投票名单和日期，所以仍可识别灌票和换票，只是看不到投了什么，但仍能猜疑为何去投。如果隐藏名单，则仅监票人可见。--YFdyh000（留言） 2022年10月26日 (三) 17:43 (UTC)
监督员怎么会不需要使用安全投票，这个权限是要签订保密协议的。--~~Sid~~ 2022年11月8日 (二) 14:15 (UTC)
未看懂。--YFdyh000（留言） 2022年11月8日 (二) 14:42 (UTC)
@YFdyh000：他的第二点说界面管理员和监督员不需要使用安全投票，奇怪的是行政员没有签订NDA保密协议的权限组都需要使用安全投票，相反的有签订NDA保密协议的权限组却不需要使用安全投票?--~~Sid~~ 2022年11月12日 (六) 13:19 (UTC)
逐个回应：
  1. (＋)支持长期使用安全投票机制，并希望定期进行，显然安全投票从筹备方式而言是需要提前准备的，很难做到以前那样一个自荐RFA就立刻开一次投票。选举可以安排在一个季度一次，每次选举跟本次一样先进行预提名，再开设正式选举。
  2. 需要，但界面管理员除外，因为界面管理员选举似乎没有管理员选举那样容易引发安全威胁和拉票等问题。行政员/监督员的职责和权力比管理员更高，因此也应该使用安全投票。
  3. 同U:A Chinese user，监票人员可在行政人员中轮值。
  4. 临界情况可与原先一样交由行政员处理，但行政员可能没法做出延长投票的决定，因此应该直接宣布入选或落选（可以由行政员集体做出决定，也可在行政员中进行投票决定）
  5. 建议隐藏投票人列表，未见公开投票人列表有何优点，相反隐藏投票人列表可以最大程度降低安全威胁。
--BlackShadowG Slava Ukraini! 2022年11月6日 (日) 13:51 (UTC)
监票人员是要签订NDA的吧...如果要让行政员去监票不就都要签吗?--~~Sid~~ 2022年11月12日 (六) 13:20 (UTC)
(－)反对由行政员进行监票。社群在选举行政员时并未考虑其可能会处理隐私相关信息。--Yining Chen（留言|签名页） 2022年11月13日 (日) 02:39 (UTC)
检索自“https://zh.wikipedia.org/w/index.php?title=Wikipedia_talk:申请成为管理人员/存档8&oldid=75359284”