維基百科討論:申請成為管理人員/存檔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」