维基百科讨论:申请成为管理人员
存檔 |
---|
|
規範人事任免投票的提問環節
原标题为:限制RFA提问数量
限制提問數量提案
为应对暂行安全投票的日程安排问题,拆分自管理人员选举制度改革。原提案者User:Ericliu1912。
修訂申請成為管理人員指引內容如下:
鉴于原提案讨论中没有对提问数量限制提出明确的反对意见,故🕗 公示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)
- 候选人一般为社群较为活跃用户,在提名前社群一般就对候选人有大体的了解。不需要通过大量提问去从头了解候选人。况且问太多的低质问题,尤其是那些与维基百科无关的问题,同样也干扰投票者对候选人的认识。
- 本指引应只限制投票页的提问数量。在其它地方提问只要不违反其它相关指引及方针即可(以前社群也没有在其它地方提问的习惯,而且不少人的讨论页也不经常回复别人)。但不能在投票页为其他页面的提问引流,否则视为绕过限制。--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)
- 根本不可能避免,尤其是假如改採安全投票形式的話,就更難以用投票理由判斷投票有效程度。(加上籌備投票程序之複雜,我已經不怎麼支持管理人員選舉採用安全投票了)—— Eric Liu 創造は生命(留言・留名・學生會) 2022年3月17日 (四) 12:52 (UTC)
規範問答環節提案
既然都+2了,我就提個反建議好了:
|
|
以上。@Ericliu1912、Jonathan5566、ghrenghren、Steven Sun。Sanmosa Veritas Vincit 2022年3月9日 (三) 14:15 (UTC)
- 支持概念。提出以下較細化的提問規則:
參與方式 ... 向候選人提問 在管理員選舉中,候選人回答提問有助投票人作出是否支持此候選人成為管理員的決定。候選人自薦或接受提名時,需要回答三條基本問題(請見#流程一節)。除此之外,任何人都可以向候選人提出問題。為確保問題素質,防止程序被擾亂,問題應先在討論頁提出,若十二小時內未獲合理反對並獲得另一名具有投票權的用戶支持提出問題後,則可轉發至投票頁面的提問區。每一名具有投票權的用戶僅能支持或反對提出一條問題。提出的問題應當保持語調中立,不應明示或暗示投票立場,並應與維基百科或候選人於維基百科的活動相關,且不存在不當預設的謬誤,以確保問答環節能作為一個具建設性的對話環境。候選人有權拒絕作答三個基本問題以外的一切提問,但建議(不強制要求)說明拒絕作答及原因。在候選人回應後追加延伸問題是可接受的行為,但追加的問題必須與原先問題及候選人的回答有關;候選人同樣有權拒絕回應追加的問題。就要求候選人回應問題進行施壓,包括但不限於以選票威脅回應[a]和在候選人明確表明拒絕作答時仍反覆要求作答[b]等行為均可被視作擾亂程序的行為。 |
- @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支持改为2支持,其余不变。
- 追加延伸(有这样说的吗?)问题是否需要再经过遴选?
- 提问的截止时间应提早一天。
- 个人认为新开独立页面作为提问(遴选)区可能更好。
- 不建议用tooltip。
- 为确保问题素质和,防止程序被扰乱。【翻译腔】
- 所有问题均应先在讨论页提出。【无用且重复】
- 但建议可以(但不强制要求)说明拒绝作答及原因【累赘】
- ——魔琴 [ 留言 贡献 ] 2022年3月10日 (四) 16:27 (UTC)
- 感謝魔琴君的意見。
- 對支持、反對限額的作用是防止某些維基人因為不喜歡候選人而大量同意對候選人提出質疑的問題,幾個支持都沒分別,有一件事情叫組團。有限制之後組團來提出質疑性問題拉低投票人的很容易發現,因為得玩互相支持問題的套路。
- 我有想過這個問題,但跟上面一樣,防止灌問題。某程度上是跟限制問題數量相似,不過確實可以提出無限問題,只不過大家看到你這樣水問題有多少人會都給你全灌下去而已。
- 這個嘛……看上面投票時間討論成怎樣先吧。
- 不評論,不是不行,但好像又不太必要。
- 純粹是提案給你們參考字眼用,寫進指引不會包含。
- 後面三個您可以直接修訂,小問題(--路西法人𖤐 2022年3月10日 (四) 16:38 (UTC)
- 但是,这个提问是流动的。也就是说,第一天,我不知道我第13天会不会看到一个我需要去支持或反对的问题。而且如果大量灌问题,似乎也无法有效反对(当然也没人支持就是)。针对组团的事情,反对票可以解决……吧?
- 感謝魔琴君的意見。
- @LuciferianThomas、Sanmosa:
- @LuciferianThomas:我還是如之前説的一樣:我不説候選人拒絕回答所有問題的權利是絕對的的原因是如果相關問題屬於合理憂慮的話,我認為任何人都會想問,而且候選人的回答有助釋疑。如果社群合理地認為某問題於維基百科或候選人在維基百科的活動而言非常重要,而且將會影響維基百科日後的運作情況,我認為任何一個或多個社群成員要求他回答是合理的,這種情況應當排除於“偏執要求作答”的情形外。我不反對禁止“威脅作出回答”,但我還是想就“威脅作出回答”的定義請求澄清:假如我提問時表示“候選人的回答會影響我的投票決定”(對,這就是原話)的話,這算是“威脅作出回答”嗎(我自己覺得這個措辭應該算是委婉)?Sanmosa Veritas Vincit 2022年3月10日 (四) 07:57 (UTC)
- 因为提问提出后不能直接被回答,提前一天截止可以防止提问废掉(而且上面讨论的好像只是临时)
- 已修改。
- ——魔琴 [ 留言 贡献 ] 2022年3月10日 (四) 23:05 (UTC)
- (回覆見下,忘了ping)--路西法人𖤐 2022年3月11日 (五) 12:03 (UTC)
- ——魔琴 [ 留言 贡献 ] 2022年3月10日 (四) 23:05 (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)
- 即使如此,每一屆都有IP和無投權者問問題,而這些人的問題質量明顯低下。--Ghren🐦🕘 2022年3月24日 (四) 13:07 (UTC)
- 萌娘百科那樣行得通是因為只有少數人有投票資格。在本站符合人事任免資格者眾。—— Eric Liu 創造は生命(留言・留名・學生會) 2022年3月18日 (五) 19:11 (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月24日 (四) 12:48 (UTC)
- 我猜可能是指RFA页面对应的讨论页?--Steven Sun(留言) 2022年3月11日 (五) 02:42 (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)
關於接下來的管理員投票
應上一次WP:500(Wikipedia:投票/是否在管理員選舉啟用SecurePoll)的共識,社群已經試行了一次安全投票(Wikipedia:申请成为管理员/和平奮鬥救地球/第5次),但是接下來社群如何進行投票是沒有充份共識的,引至出現了這種問題。因此,希望大家認真討論一下:
- 接下來的「申請成為管理員」,以及是其他管理人員職務是否使用安全投票?
- 如果決定不使用,(除了是在原地打轉之外,)如何滿足、解決「阻止拉票和人身威脅」的問題。
- 如果決定使用安全投票,如何決定程序,時間,方針對應的調整也是需要考慮的。
希望社群討論。--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)
- 就籌備時間的問題來說,一年兩次或一年一次的區別應該不大。但相較後者而言,前者可讓有意申請或提名管理員的用戶不必等那麼久。-Peacearth(留言) 2022年6月10日 (五) 20:44 (UTC)
- 一年一次應該也夠吧,但我考慮到Steward選舉的情形,也同意集中提名與統一投票期的舉措。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月5日 (日) 16:06 (UTC)
- 作為兩次安全投票監票人,覺得有些事情是要提醒社群,在作出上述決定之前是必須考慮︰
- 是否允許使用Proxy︰以本社群組成部分而言,如果使用安全投票,禁止使用Proxy幾乎等於阻斷相當一部分合資格用戶參與投票,但在投票意向隱藏之下,允許使用Proxy將會大幅度減弱監票效果。
- 臨界狀況︰因為安全投票與傳統方法差異不少,若出現傳統上臨界狀況,即75至80%時,行政員幾乎無法介入去作出決定。例如使用中立票去判斷候選人是否當選。
- 以上。--J.Wong 2022年6月5日 (日) 08:59 (UTC)
- 禁止使用Proxy幾乎相當於不讓居住在中國大陸境內的人投票,貌似免proxy使用Wikipedia比較繁瑣。--中文維基百科20021024(留言) 2022年6月5日 (日) 09:05 (UTC)
|
- 中立票之意見是否會顯示,以協助行政員判斷結果?-Peacearth(留言) 2022年6月5日 (日) 13:22 (UTC)
- 幾乎無法辨識留言是否由投中立票之用戶留下。--J.Wong 2022年6月5日 (日) 21:44 (UTC)
- 原來如此。這樣的話的確不太能用來協助判斷。-Peacearth(留言) 2022年6月6日 (一) 03:21 (UTC)
- 幾乎無法辨識留言是否由投中立票之用戶留下。--J.Wong 2022年6月5日 (日) 21:44 (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)
- vote.wikimedia.org在中国大陆不可正常访问,不用Proxy就无法投票。--Lanwi1(留言) 2022年6月5日 (日) 19:49 (UTC)
- 考慮到基金會在此前因為安全理由而要求中國大陸用戶自行請辭重要權限一事(注意當時基金會所提到的“安全理由”沒包括Proxy),我有理由認為基金會並不信任中國大陸用戶。另一方面,基金會一向並不鼓勵使用Proxy。雖然禁止使用Proxy相當於不容許身處中國大陸的人投票,我認為這是唯一保證投票安全性的辦法,而且基金會不會對此有任何意見。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月5日 (日) 15:47 (UTC)
- 我认为这是滑坡谬误。我有理由认为这个“有理由认为”的理由不充分。--YFdyh000(留言) 2022年6月6日 (一) 11:58 (UTC)
- 中立票之意見是否會顯示,以協助行政員判斷結果?-Peacearth(留言) 2022年6月5日 (日) 13:22 (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)
- 我觉得默认情况下没有必要,毕竟并不是所有活跃用户都关注人事任免。私以为可以像站内刊物那样制作一个发送名单,让用户自行选择是否订阅。--BlackShadowG Slava Ukraini! 2022年6月6日 (一) 12:20 (UTC)
- 对一部分前管理员参选不使用安全投票不会有问题吧?--Lanwi1(留言) 2022年6月5日 (日) 14:26 (UTC)
- Yining Chen(留言|签名页) 2022年6月5日 (日) 14:48 (UTC) 如果两种投票方式并行,是否应给予候选人自主选择投票方式的机会,或是由社群整理出一份“强制记名投票候选人名单”?这样看起来会不会有些不公平(无论是对采用SP的候选人或是采用普通流程的候选人)?而且这样做可能意味着社群需要准备两份投票规则。--
- 不建议让候选人自主选择,这可能导致不愿公开投票倾向(可能出于安全原因)的用户无法参与部分投票。--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)
- 修改代码能解决的问题实务上并不算是问题;wmf的技术员也是为实现社群需要功能而服务的“打工人”而已。
- 此外,单纯“只容許安全投票”并不见得能使“進行人身威脅者”“失去得悉受人身威脅者是否有投票的誘因”。且不论威胁者可能非理性地照威胁不误,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)
- 那不如在选举页面开启“投票意见”章节,使用户可自愿公布其投票意向和理由,也可回复他人的意见,但最终结果仍以安全投票的结果为准。这样既便于行政员判断临界情况,也降低了计票的难度,安全性也没有问题。--BlackShadowG Slava Ukraini! 2022年6月6日 (一) 12:38 (UTC)
- 一是如前述,可以从技术上限制普通帐户对已投票用户列表的访问,而仅允许监票行政员获取所有使用安全投票用户的名单。一旦用户出现在该名单中,站内投票自动作废;选举结束,站内外结果合并给出得票比例,监票行政员只给出站内外投票用户的总名单。这样威胁者就无从查证被威胁者有否使用安全投票进行改票。二是安全投票并不存在真正的讨论,参与者彼此看不见对方的留言,只是各说各话,难以归纳总结。此外,还不按照时间顺序排列,以至于无法识别“短期涌入大量支持/反对票”等异常情况。--Antigng(留言) 2022年6月6日 (一) 12:22 (UTC)
- “投票与理由一一对应,通过理由可以判断哪一方的意见更有力”,这点完全没有必要,只要看理由是不是合理,根本不需要知道某个理由是谁说的、是哪方说的--百無一用是書生 (☎) 2022年6月8日 (三) 01:58 (UTC)
- 好像也是。不過至少「行政員可考慮中立票」的部分可能需要稍加修訂,雖然實質上並無太大區別。-Peacearth(留言) 2022年6月10日 (五) 20:32 (UTC)
- 过去的投票之所以临界情况可以交由行政员裁决是因为投票与理由一一对应,通过理由可以判断哪一方的意见更有力;安全投票无法实现这一点。同时保留安全与非安全投票两个选项的前提下,如果最终出现了临界情况,而通过检验发现安全与非安全投票两个样本没有统计显著的差异,就可以站内非安全投票的样本进行类似的判读,决定投票延长还是直接不通过。--Antigng(留言) 2022年6月6日 (一) 10:43 (UTC)
- @Antigng:本人没能理解您的新方案是如何解决“临界状况不好判断”这一问题的。而且个人认为非安全投票与安全投票同步进行(该方案)很可能为投票增加了原本不存在的风险。--Yining Chen(留言|签名页) 2022年6月6日 (一) 10:30 (UTC)
- @Antigng:實務上不可行。安全投票是P站那邊負責的,所以那邊在投票結束後會直接給出所有參與安全投票的人的名單,進行人身威脅者還是可以知道受人身威脅者有沒有在安全投票那邊投票(而且還有考慮到被基金會除權的人包括管理員與行政員)。我主張只容許安全投票的原因是進行人身威脅者會失去得悉受人身威脅者是否有投票的誘因。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月6日 (一) 06:43 (UTC)
- 那么可以把这条信息关掉,使之对公众不可见,变成真正的安全投票。事后再让监票行政员汇总出一份结合站内外投票用户的名单,按字符先后顺序排列。--Antigng(留言) 2022年6月6日 (一) 06:37 (UTC)
- @Antigng:還有一點,由於選舉期間所有人都能夠看到了誰已經投票,所以進行人身威脅者是會知道受人身威脅者有在安全投票那邊投票的,進行人身威脅者可以威脅受人身威脅者撤回在安全投票那邊投的票。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月6日 (一) 06:34 (UTC)
- 既然安全服务器可以看见谁已经投票,那么监票的行政员只要看到该用户投票,就可以自动将站内投票忽略,从而不会引发任何问题。此外,受威胁用户可以假意于站内页面顺应威胁者的意思,但在安全服务器表达真实意见。这样TA既表达了真实意见,也不再会受到威胁者的威胁。因此“以安全服务器上的投票为准”便可解决您所提出的问题。--Antigng(留言) 2022年6月6日 (一) 06:25 (UTC)
- 順帶一說,我覺得看投票留言比看中立票更能判斷共識。以理服人嘛。--Temp3600(留言) 2022年6月7日 (二) 14:27 (UTC)
- 至少真的是不記名投票,意見那邊有說過了。而且,投票期間結束後確實無法再投票,安全投票可行性是有的。就是...維基百科有無要創建一個頁面叫做「Wikipedia:安全投票」?--Z7504非常建議必要時多關注評選(留言) 2022年6月9日 (四) 11:01 (UTC)
- 等到正式确立相关方针再建立也不迟。--Yining Chen(留言|签名页) 2022年6月12日 (日) 09:06 (UTC)
- 也是喔,不過看看獨裁社群這樣搞,好像玩不起安全投票一樣,也就是說還是有人無法接受新格式的事實,就像Wikipedia:申请成为管理员/Lanwi1/第4次一樣。如果明知選不上管理員的奉勸就別選了,以免浪費很多寶貴時間,又不代表使用安全投票就一定能選上。還有喔,喊拉票的風聲去哪了?意思是說拉票經過安全投票過的也算過囉?--Z7504非常建議必要時多關注評選(留言) 2022年6月13日 (一) 08:36 (UTC)
- 社群应该考虑拉票的问题。Lanwi第四次竞选符合先前共识(上次只说进行一次SP投票,没有说SP投票完就暂停RfA选举。 ——魔琴 [ 留言 贡献 ] 2022年6月13日 (一) 10:29 (UTC)
- 然而拉票這玩意也講過了啊,拉票是一種防不勝防的情況啊。只要有去討論過GA評選的爭議就知道了,GA評選就有出現過拉票的爭議了。為何這個獨裁社群沒有想過呢?--Z7504非常建議必要時多關注評選(留言) 2022年6月13日 (一) 11:24 (UTC)
- 问题是今后的RFA是否必须安全投票。--Lanwi1(留言) 2022年6月13日 (一) 13:42 (UTC)
- 我覺得必須。拉票問題比起投票人受威脅的問題實在微不足道。Sanmosa Gottes Sonne strahl' in Frieden 2022年6月13日 (一) 14:02 (UTC)
- 還會被人拉清單--中文維基百科20021024(留言) 2022年6月13日 (一) 14:19 (UTC)
- 我觉得这个投票非常好,但是中立票也能显示最好,而且不止管理员选举,罢免之类的也可以开启。--脳補。◕‿◕。讨论 2022年6月13日 (一) 15:31 (UTC)
- 還會被人拉清單--中文維基百科20021024(留言) 2022年6月13日 (一) 14:19 (UTC)
- 我覺得必須。拉票問題比起投票人受威脅的問題實在微不足道。Sanmosa Gottes Sonne strahl' in Frieden 2022年6月13日 (一) 14:02 (UTC)
- 问题是今后的RFA是否必须安全投票。--Lanwi1(留言) 2022年6月13日 (一) 13:42 (UTC)
- 然而拉票這玩意也講過了啊,拉票是一種防不勝防的情況啊。只要有去討論過GA評選的爭議就知道了,GA評選就有出現過拉票的爭議了。為何這個獨裁社群沒有想過呢?--Z7504非常建議必要時多關注評選(留言) 2022年6月13日 (一) 11:24 (UTC)
- 社群应该考虑拉票的问题。Lanwi第四次竞选符合先前共识(上次只说进行一次SP投票,没有说SP投票完就暂停RfA选举。 ——魔琴 [ 留言 贡献 ] 2022年6月13日 (一) 10:29 (UTC)
- 也是喔,不過看看獨裁社群這樣搞,好像玩不起安全投票一樣,也就是說還是有人無法接受新格式的事實,就像Wikipedia:申请成为管理员/Lanwi1/第4次一樣。如果明知選不上管理員的奉勸就別選了,以免浪費很多寶貴時間,又不代表使用安全投票就一定能選上。還有喔,喊拉票的風聲去哪了?意思是說拉票經過安全投票過的也算過囉?--Z7504非常建議必要時多關注評選(留言) 2022年6月13日 (一) 08:36 (UTC)
- 等到正式确立相关方针再建立也不迟。--Yining Chen(留言|签名页) 2022年6月12日 (日) 09:06 (UTC)
- 所以呢?要不要用安全投票是不是也要用安全投票決定呢?看吧都沒動靜了。--Z7504非常建議必要時多關注評選(留言) 2022年6月16日 (四) 15:43 (UTC)
- 從這個沒有動靜的看法,能否認為大家都覺得以後都要使用安全投票呢?上文除了討論兩者並行的方案外,不見明確的反對,如實在是沒有反對意見的話,不如就公示?--Ghren🐦🕕 2022年6月19日 (日) 10:28 (UTC)
- @Ghrenghren:問題是結論是甚麼,沒看出結論--SunAfterRain 2022年6月20日 (一) 00:16 (UTC)
- @SunAfterRain:我也沒看出在具體怎樣實行安全投票方面有什麼結論。但是如果可以有個初部共識決定以後都是用安全投票的話,對之下來的討論應該有幫助?--Ghren🐦🕙 2022年6月20日 (一) 02:42 (UTC)
- @Ghrenghren:如果不一次把這個討論串了結的話,我認為下一場選舉的準備時間還會拉長好幾倍(拖在討論時間)--SunAfterRain 2022年6月20日 (一) 07:39 (UTC)
- 獨裁社群最好的方式真的是能拖延就拖延,導致一個討論串可能超過10萬位元組都不為過,沒想到要不要用安全投票居然都可以那麼的墨跡。--Z7504非常建議必要時多關注評選(留言) 2022年6月20日 (一) 11:34 (UTC)
- @Ghrenghren:如果不一次把這個討論串了結的話,我認為下一場選舉的準備時間還會拉長好幾倍(拖在討論時間)--SunAfterRain 2022年6月20日 (一) 07:39 (UTC)
- @SunAfterRain:我也沒看出在具體怎樣實行安全投票方面有什麼結論。但是如果可以有個初部共識決定以後都是用安全投票的話,對之下來的討論應該有幫助?--Ghren🐦🕙 2022年6月20日 (一) 02:42 (UTC)
- @Ghrenghren:問題是結論是甚麼,沒看出結論--SunAfterRain 2022年6月20日 (一) 00:16 (UTC)
- 從這個沒有動靜的看法,能否認為大家都覺得以後都要使用安全投票呢?上文除了討論兩者並行的方案外,不見明確的反對,如實在是沒有反對意見的話,不如就公示?--Ghren🐦🕕 2022年6月19日 (日) 10:28 (UTC)
- (!)意見:(+)支持往後使用安全投票,至於有關此機制之技術性問題,竊以為應由基金會提供技術援助或解決(如投票介面、中立票、資訊顯示或隱藏、監驗票等功能設計或修訂)。個人認為,諸多站友既已花費大量時間、心力貢獻於此平台,提供平台所需之條目、站務、維運、構想、智慧等寶貴要素,甚而亦有用戶不吝捐款、出錢出力,且人事選舉相關議題紛擾已久,實應獲得有效解決。況且,中文社群亦已對相關議題發起討論至今,可謂集思廣益、盡心戮力了。綜觀站友意見,敝人斗膽表達意見和考量如下:
- 1.一切活動應以安全為優先考量。如果用戶光是上網投個票都不安全,或需承擔各種風險,甚至已經遭受到實質安全威脅,個人認為理當以自身安全為首要考量。若用戶真已感受到任何形式之人身安全脅迫(不論被迫以何種形式如何表態),敝人建議:先暫停維基百科內相關活動,必要時請求當地司法機構協助,在條件許可下向基金會具體陳情以尋求適當協助。在此之前,使用介面和機制之規劃應有所為。
- 2.投票過程中的已投票用戶名單等動態資訊不應對一般用戶公開。
- 3.投票結果若處於臨界狀態,行政員可綜合考慮用戶投票意見和理由予以裁定。
- 4.安全投票機制若能明確標註顯示「中立票」之附含意見較為理想;若最終安全投票介面仍不具此功能,且社群或具權限之監、驗票人員仍期待便於識別中立票內含之意見,竊以為於投票須知明確規範:「當用戶投下中立票,應於投票意見欄明確表達該票附具之意見或評價為『中立』,以便選舉結果之識別判讀。」即可(如投票用戶應於意見欄寫明:「中立,基於候選人....,但仍.....」;「投下中立票。平日候選人之站務表現已具XXX和OOO,往後可再加強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)
- 又没动静了。(+)支持安全投票,并认为现在就可以直接用普通投票的方式,来决定是否在以后的选举中采用安全投票。投票结束后,再讨论相关事宜也来得及。--50829!(留言) 2022年6月22日 (三) 06:13 (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)
- 我感覺把你說成同時存在的兩個「幫派」比較一下的話,就算這兩個「幫派」都真的同時存在,「反WMC的幫派」所產生的問題明顯不能與「親WMC的幫派」所產生的問題相提並論,至少「反WMC的幫派」不可能像「親WMC的幫派」一樣有羣體策劃的欺凌(包括但不限於網絡上與現實上)。Sanmosa Királyunk s a közhazát 2022年6月29日 (三) 15:25 (UTC)
- 对易被WMC排挤的候选人的而言,不在安全投票下就容易造成心理问题,但我所说的帮派指的是反WMC的。--Lanwi1(留言) 2022年6月29日 (三) 03:17 (UTC)
- 以前公開投票的時候有相互吵架的,對投反對票冷嘲熱諷的,還有我上面討論提到的有人投了反對票還會被人拉清單,就沒發現公開投票好在哪裡。--日期20220626(留言) 2022年6月29日 (三) 03:08 (UTC)
- 不,對易被幫派排擠的候選人的而言,在沒有安全投票的情況下才容易造成心理問題。請不要將以前WMCUG干預RFA的情形視而不見。Sanmosa Királyunk s a közhazát 2022年6月29日 (三) 01:56 (UTC)
- 对易被帮派排挤的候选人的而言,在安全投票下容易造成心理问题。--Lanwi1(留言) 2022年6月28日 (二) 14:57 (UTC)
- 為什麼我覺得恰恰相反?反倒是非安全投票下容易造成心理問題?(如果候選人的確有的話)非安全投票下投票會有壓力。--日期20220626(留言) 2022年6月28日 (二) 14:36 (UTC)
- 实体的话可见,现在中维帮派化太重。--Lanwi1(留言) 2022年6月28日 (二) 14:33 (UTC)
- 沒什麼屁用,就算用實體投票一樣也可以惡意投反對票。--Z7504非常建議必要時多關注評選(留言) 2022年6月28日 (二) 14:08 (UTC)
- 中國大陸使用者是否輕生率較高敝人不認為可以從這一個簡單的投票介面和主題加以驗證,而仰賴投票介面表達意見自由致影響個人生命安全和身心健康或產生可能疑慮,我認為顯然亦非健康思維和應有舉措。敝人會建議,請各位站友多多關注生活和人生的美好面向,切勿因投入任何網路相關活動致影響生活平衡。與諸位站友共勉之。--Kriz Ju(留言) 2022年6月28日 (二) 04:58 (UTC)
- 谁想轻生的话我也不知道,大陆用户轻生的可能性比港澳台用户高,因为大陆的言论管制,不能在现实生活中诉求自己的遭遇,所以更要多多关心依赖维基百科的渴望自由的大陆用户。--Lanwi1(留言) 2022年6月28日 (二) 00:36 (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)
- 如果无法决定最终“胁迫投票”和“监督拉票”最终应选那个,似乎只能考虑某种双轨并行制。Kriz案二的“双重反对”部分不是很支持。看看其他人的意见。 ——魔琴 [ 留言 贡献 ] 2022年7月1日 (五) 13:26 (UTC)
- 普通投票的缺點已經很清楚了。暫時沒有看出支持者有什麼補救辦法。--Temp3600(留言) 2022年7月2日 (六) 19:28 (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)
- 所以你覺得自己的問題是?--日期20220626(留言) 2022年7月3日 (日) 13:38 (UTC)
- 像上面这样的列出过去的问题对现在的我而言已经没有意义了,现在的我早已不想再碰像爱孟这样的封禁,在Walter Grassroot的封禁案我已经做到不想碰了。不明事理者就是不理解正常人犯错后会改进自己的行为,使自己不会再犯相同错误。--Lanwi1(留言) 2022年7月3日 (日) 18:04 (UTC)
- @Mys 721tx:那是过去的我,我从爱孟被禁制后才明白自己的问题。现在的我已经不再是2018年4月以前的我了,人是有成长的。--Lanwi1(留言) 2022年7月3日 (日) 13:36 (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)
- 上次试验通过后很快就有人提名。应该不用担心没人参选的问题。如果再次试验可以尝试一下多人同时参选。设立一周左右的提名期,通过提名的候选人集中使用安全投票选举。--Steven Sun(留言) 2022年7月13日 (三) 09:22 (UTC)
- 但是再次「試行」安全投票是否需要社群授權?—— Eric Liu 創造は生命(留言・留名・學生會) 2022年7月15日 (五) 03:19 (UTC)
- 跟上一次试验一样,再次试验。--Lanwi1(留言) 2022年7月15日 (五) 10:44 (UTC)
- 上次「試行」係經社群投票授權,這次雖然不一定要重新進行表決,但仍應得到社群共識。另外,還要多「試行」幾次,這也需要討論。—— Eric Liu 創造は生命(留言・留名・學生會) 2022年7月15日 (五) 12:00 (UTC)
- 跟上一次试验一样,再次试验。--Lanwi1(留言) 2022年7月15日 (五) 10:44 (UTC)
- 我的意见就是再次试验,问题是谁想参选?--Lanwi1(留言) 2022年7月13日 (三) 01:52 (UTC)
- 看來按這社群速度,要不我們再臨時數次試試看比較好。Ghren🐦🕛 2022年7月12日 (二) 16:25 (UTC)
- 不知道谁想参选。如果我有方案,那就让包括部分被WMF除权的在内的人集中参选,正好消除对去年的基金会行动的最大不满,即活跃的反破坏管理员被除权。--Lanwi1(留言) 2022年7月11日 (一) 16:18 (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)
- 整理一下上面的討論?--冥王歐西里斯(留言) 2022年7月24日 (日) 00:24 (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)
- 好了好了,既然都知道推进慢就不要在没意义的讨论中浪费时间了。再次试验大概相比这次试验需要调整哪些内容?--BlackShadowG Slava Ukraini! 2022年8月8日 (一) 10:55 (UTC)
- 中维不重视,所以推进就是慢。--Lanwi1(留言) 2022年8月8日 (一) 03:43 (UTC)
- 社群討論流程確實推進地有些慢,不過還輪不到您冷嘲熱諷呢。—— Eric Liu 創造は生命(留言・留名・學生會) 2022年8月6日 (六) 14:15 (UTC)
- 這獨裁社群真的在搞笑,原來過了一個多月的討論了結果還是要用安全投票嘛,都已經故意不想理會了。那請問為何沒有辦法直接6月底、7月初左右的時候就說繼續用安全投票,非要等到8月才能做出決定呢?肯定是因為維基百科已經是一個標準的「Parkinson's Law」了。搞笑的東西,原來要不要用安全投票要猶豫一個多月那麼久?--Z7504非常建議必要時多關注評選(留言) 2022年8月5日 (五) 17:59 (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)
- 根據社群所達成共識之不同,亦有可能只須微調暫行規定以繼續適用於當前之情況。—— Eric Liu 創造は生命(留言・留名・學生會) 2022年8月12日 (五) 15:46 (UTC)
- 建议安全投票暂行规定先继续实行,安全投票指引现在由于社群讨论流程慢而不宜直接制定。--Lanwi1(留言) 2022年8月12日 (五) 15:42 (UTC)
- 但若需支持多人参选,就需要修改“暂行规定”;而且中维最终还是需要一个“永久”规定。所以不如趁此机会直接制定安全投票指引。 --Yining Chen(留言|签名页) 2022年8月12日 (五) 15:19 (UTC)
调整“安全投票暂行规定”
- 如果只需要支持多人参选,则可对现“暂行规定”中“预提名”一节进行如下微调:
|
|
- --Yining Chen(留言|签名页) 2022年8月13日 (六) 03:57 (UTC)
- 別忘了修正投票資格,上次投票中發現的問題。--Xiplus#Talk 2022年8月13日 (六) 07:01 (UTC)
(+)支持--Lanwi1(留言) 2022年8月13日 (六) 05:45 (UTC)
- (~)補充:对于上方提到的投票资格,结合上一次投票的实践,建议再向暂行规定中加入如下内容:
|
- 希望能够就以上两项更改提议进行讨论并达成共识。--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)
- 关于首句“技术限制”及其后所提到的IAR,针对的都是上一次有人质疑的“基准时间问题”。毕竟依照现行Wikipedia:人事任免投票資格方针,所谓“基准时间”必须是“投票正式开始”的时间。所以把“技术限制”和“IAR”写入其中。如果要更改人事任免投票資格方针,可能需要另开讨论,整体的流程也可能会更加冗长。--Yining Chen(留言|签名页) 2022年8月14日 (日) 03:42 (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)
- 似乎确实无必要,因此参考WP:共识修改为七天。--Yining Chen(留言|签名页) 2022年8月14日 (日) 15:49 (UTC)
- 在以前也沒有限制同時進行RFA的數量,增加預提名會有什麼問題嗎?--Xiplus#Talk 2022年8月14日 (日) 15:03 (UTC)
- 考虑到上一次预提名过程进行的速度,个人认为预提名时间过长可能会使候选人的数量超过社群能有效处理的范围,进而产生其他问题。--Yining Chen(留言|签名页) 2022年8月14日 (日) 15:00 (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)
- 这个问题似乎与是否采用安全投票无关,不太清楚以前的普通投票实践中是否出现过与封禁期限有关的问题(如在RFA进行期间被解封的用户是否有投票权)?
- 依照现在草拟的方案,是(符合相关条件的)候选人在预提名进行的七天内,只要有七名用户投票支持,就算作符合标准。并未再试图设立一个“从预提名到投票数达标”的时间限制。--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)
- 「在此七天內得到七位具人事任免投票資格之使用者聯署支持」應明確說明需在這個七天內的連署才有效。--Xiplus#Talk 2022年8月20日 (六) 05:52 (UTC)
- 感谢。已整理并更新修正草案。--Yining Chen(留言|签名页) 2022年8月19日 (五) 03:26 (UTC)
- 我理解了,不過在目前提議條文看不出這個意思。我重新整理一下規定:「未來一場選舉將仿照此前的安全投票選舉流程,統一進行預提名。在第一位候選人預提名提出之時,為期七天的預提名程序即開始,在此七天內皆可提名其他候選人,願意接受正式提名並回答前述三個基本問題、在此七天內得到七位具人事任免投票資格之使用者聯署支持,且符合成為管理員之資格者,經行政員確認,皆可獲得正式提名,並將一併進行選舉,且應比照前述之一般流程另行設定個人選舉頁面。」--Xiplus#Talk 2022年8月19日 (五) 03:14 (UTC)
- “第七天才提名”,这是提名人自己的选择,即使大概率失败也与他人无关;另外,这个“七天”的期限在整体的投票过程中,只出现“一次”,或许也就是指“联合选举的提名期限”。--Yining Chen(留言|签名页) 2022年8月19日 (五) 03:01 (UTC)
- 那如果第7天才提名另一位候選人呢?另外這個7天期限是單一位候選人的期限,還是這次聯合選舉的提名期限?--Xiplus#Talk 2022年8月19日 (五) 02:55 (UTC)
- (2) 既然已经留出了7天的时间,那么在这七天内的任意一天提名都应当是可以的。毕竟时间相对较充裕,即使是在预提名第二日再提名,与第一日相比效果或许也不会相差很多。--Yining Chen(留言|签名页) 2022年8月19日 (五) 02:50 (UTC)
- (2) 不同的候選人要怎麼在同一個7天內進行預提名?提出預提名的時間本來就會有所不同,如果這個7天預提名進行到第3天,是否可再提名一個候選人?--Xiplus#Talk 2022年8月19日 (五) 01:31 (UTC)
- (1)问题,我个人认为或可以延续先前做法,但或许需要等待其他意见。(2)问题,上文的表述可能不是很清楚。并不是针对每一个候选人单独开投票,而是所有用户统一在先前计划好的的某七天内进行预提名操作,也就是说,该修正案只对下一次的安全投票选举负责;在整体的投票过程中,只会出现“一个”七天的预提名。--Yining Chen(留言|签名页) 2022年8月18日 (四) 14:09 (UTC)
- (1). 普通投票中只要能編輯投票頁就有投票權,相反來說,投票期間只要持續被封鎖(含部分封鎖)以致無法編輯投票頁,就等於無投票權,但因為安全投票需要預先設定投票權人名單,極不可能在投票過程中更改,所以才要決定判定被封鎖無投票權的規則,上次安全投票定為提名通過之時,不過與人事任免投票資格的基準時間為提名開始之時不同,我才在此提出是否要再次考慮定這個時間是否合理。 (2). 我的意思是,在第一個提名通過就會開始準備安全投票,但假設之後又有新的候選人提名通過,理應可以於同一個投票中一併投票(因為安全投票籌備需要不少時間),但若之後持續又有新的提名通過(假設每3天就有新提名通過,即第1、4、7、10、13...天都有新提名通過),那麼究竟哪些候選人能夠趕上同一個投票,哪些候選人就裁定排到下次投票(畢竟不可能無限等候後面的候選人提名通過)。--Xiplus#Talk 2022年8月18日 (四) 13:09 (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)
- 我個人認為不需要在第二部分修正案內引用「忽略所有規則」,因為特別法本就優先於普通法,而且不必另開章節,直接置於原〈安全投票暫行規定〉一節中即可:
|
|
以上。—— 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)
- 已經照辦。—— Eric Liu 創造は生命(留言・留名・學生會) 2022年8月22日 (一) 15:56 (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)
- 我前面就說過了,只需要加少少幾個字即可,「投票:...共同協助監票。在預提名開始之時具人事任免投票資格,且在被提名者...」。--Xiplus#Talk 2022年8月25日 (四) 10:51 (UTC)
- 但目前该投票流程还只是“暂行规定”,无法确定以后流程是否与现在相同(即该新增规定是否有“通用性”,或是否值得为此修改方针)。因此不应该直接修订人事任免资格方针。--Yining Chen(留言|签名页) 2022年8月25日 (四) 10:08 (UTC)
- (!)意見:那麼閣下認為要放在哪裡呢?目前看起來這是必要的修正。--冥王歐西里斯(留言) 2022年8月23日 (二) 23:45 (UTC)
- 整理上述提案内容(无关内容已省略):
|
|
- 公示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)