跳转到内容

维基百科讨论:申请成为管理人员/存档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”