維基百科:互助客棧/方針/存檔/2023年8月

專人處理IPBE和新賬號申請

以下內容為了避免討論顯示過長摺疊，任何人仍然可以發言和取消摺疊

因為IPBE申請長期積壓嚴重，所以提案由專人處理IPBE和新賬號申請的內容。

---

IPBE和新賬號申請處理員是一群志願者，通過郵件列表<待議lists.wikimedia.org>處理因為開放代理而提出的IPBE和新賬號申請。

權限包括：

• 添加用戶組：IP封禁豁免者（用於處理IPBE申請）
• 不受速率限制影響（用於處理新賬號申請）
• 移除自己賬號的用戶組：IPBE和新賬號申請處理員

此用戶組的申請條件：

• 有有意願處理IPBE和新賬號申請，了解相關方針指引，能夠友善地對待他人
• 編輯數滿1000次
• 最近一年內沒有受到封禁（不合理封禁除外）
• 在過去三個月內平均每日的編輯次數多於一次

由於該用戶組的用戶是大陸新用戶進入維基百科的一道門檻，所以他們應該被信任能夠妥善處理相關事務。此用戶組在處理相關內容時會查看到用戶的IP信息，授權時應注意用戶是否可信。

由於被IP封禁波及的新用戶只有在被授予相應權限後才能表現是否為破壞者，所以該用戶組不應該因為其授予權限的新用戶破壞而剝奪該用戶組。

---

上為草案，希望指出有無錯誤，比如是否因為和封禁申訴共用郵件列表而產生私隱問題。此提案不意圖移除管理員的相關權限。--落花有意12138 2023年7月30日 (日) 14:59 (UTC)

目前有Wikipedia:大量帳號建立者，是否可以把相關任務授權給該用戶組。英文版大量帳號建立者主要是用來處理ACC。--GZWDer（留言） 2023年7月30日 (日) 17:52 (UTC)

這樣的要求與回退員差不多，而出於私隱考量，已有移除回退員查看私密過濾器的權限的共識。涉及到IP信息，要求顯然必須更嚴格。大量帳號建立者目前用途單一且持有者僅有一人，或許可以擴展用途。——暁月凜奈 (留言) 2023年7月30日 (日) 18:05 (UTC)

對於上兩條留言的回覆請移步下方專門討論章節留言——落花有意12138 2023年7月31日 (一) 12:07 (UTC)

@暁月凜奈：您的意思是應該提高申請條件嗎？我認為這裏可以註明需要查看IP信息，然後評選時具體評判用戶可信度即可。--落花有意12138 2023年7月31日 (一) 12:28 (UTC)

已加入需要查看IP信息提醒——落花有意12138 2023年8月1日 (二) 13:19 (UTC)

好像以前管理員仍需要做一些檢查才能授權，所以需要管理員的一些權限。只是單純見單就給會不會有問題？或者需要諮詢管理員群體確認為什麼會出現擠壓，或者要考慮逐步恢復管理員的申請來擴充人手，或者督促管理員群體幹活？（論又來討論管理員活躍度的問題）——Sakamotosan路過圍觀 | 避免做作，免敬 2023年7月31日 (一) 00:57 (UTC)

等一個路過的管理員介紹處理流程--落花有意12138 2023年7月31日 (一) 13:07 (UTC)

需要做的檢查就是1.有沒有真的被封；2.要求建立的用戶名有沒有問題；3.封了的IP是不是代理封的。見就給有沒有問題？現在基本上就是見就給，但是用戶名和「有沒有封、是不是代理」還是要看一看。為什麼會積壓？除了量大，最顯著的是易疲勞，即使現在有非常非常好用的懶人工具也是這樣。允許更多人來處理會好一點，也就只會好那麼一點點。我本人就是處理一次休息幾天，連續處理幾周得休息幾周。就好像當年的模板編輯員一樣，幾周前我看了一眼，已經沒什麼模板編輯員在處理編輯請求了。--Tiger（留言） 2023年7月31日 (一) 15:06 (UTC)

那麼這個提案用戶組應該也需要有活躍度要求，比如六個月處理六十個？或者是是有時間處理申請後火速授權，干到不想干後自己除權。--落花有意12138 2023年8月1日 (二) 13:09 (UTC)

活躍度要求是出於安全考慮而必須存在的，但不應強迫用戶處理。——暁月凜奈 (留言) 2023年8月1日 (二) 14:16 (UTC)

@Tigerzeng：因為您比較了解情況，請問是否可能因為和封禁申訴共用郵件列表而產生私隱問題？在處理過程中還需要其他權限嗎？--落花有意12138 2023年8月1日 (二) 13:41 (UTC)

除非是安全考慮，否則活躍度要求只能吸引來虛榮的人。說得極端一點，多一個每月處理一個請求的人，相比沒有這個人，那每個月不是還多處理掉了一個？如果要非管理員參與這件事，那肯定要和封禁申訴分開。但是被普通IP封禁影響的人（比如很不幸住在LTA家附近的人）仍然有可能走錯地方，這些人的IP是真實的IP，肯定不能被管理員之外的人看到，這個部分要考慮周到之後再實施。--Tiger（留言） 2023年8月1日 (二) 14:18 (UTC)

明白二位的意思了，這裏不應該有處理的要求。--落花有意12138 2023年8月1日 (二) 14:30 (UTC)

修改處理範圍，僅限開放代理。——落花有意12138 2023年8月2日 (三) 13:36 (UTC)

強烈支持加速處理積壓。用戶組概念不反對。之前TG群中我提過，我是期望表單化申請+自動化處理IPBE的基本申請的，有條件的先授予後審查，再配合防濫用策略，提報和快速處理。需要明確授予和處理流程，是否要涉及IP信息，如何識別傀儡、LTA等行為。「只有在被授予相應權限後才能表現是否為破壞者」存疑，過往授予可能有不少經驗上的主觀判斷。「不應該因為其授予權限的新用戶破壞而剝奪該用戶組」存疑，那麼是否有其他快速機制能建立溝通或強制性審核、禁制。比如類似WP:機械人，要求新用戶執行有限次數的試操作，再行評估，試操作期間也可強制如草稿化、WP:AFC；LTA可能「刷編輯」繞過。--YFdyh000（留言） 2023年7月31日 (一) 01:37 (UTC)

認為可以分情況討論：如果IP只是因為開放代理封的，適用IPBE直接授予和處理員不擔責。如果有其他原因，適用給IPBE，並執行一些機制，但是具體機制有待討論。--落花有意12138 2023年7月31日 (一) 13:38 (UTC)

但目前沒有可行機制對該用戶組保密IP的同時辨別原因。您是指申請IP無破壞履歷或嫌疑，但感覺LTA能做到前者，後者需要靠主觀推斷，我覺得通通附加機制可能反而好些（不代表拒絕依判斷封傀儡）。--YFdyh000（留言） 2023年7月31日 (一) 14:33 (UTC)

都附加機制不合適。第一種情況其實就和正常註冊的新用戶一樣，不應該特殊對待。為了LTA擋住新用戶不合適。

我認為這個用戶組處理申請應該和現在管理員的方式一樣，應該允許查看IP。--落花有意12138 2023年8月1日 (二) 13:37 (UTC)

目前已經擋住了，並且一些維基人期望擋住。我覺得不嚴厲就可以，像是Tor註冊會延遲授予自確。目前我不期望有滿足基金會私隱要求且非管理員的該用戶組成員，即便有少許，我也覺得變成一個專門且閉門辦事的苦差。--YFdyh000（留言） 2023年8月1日 (二) 20:52 (UTC)

已經提出拆分郵件列表案，分割了IPBE和新賬號請求和其他封禁申訴。這樣應該可以避免IP的私隱問題。

至於附加機制，如果只是延遲自確，我覺得可以接受，但是限制編輯主條目空間之類不同意。——落花有意12138 2023年8月2日 (三) 13:36 (UTC)

m:Steward clerks本地版？--路西法人 2023年7月31日 (一) 15:24 (UTC)

修改Wikipedia:大量帳號建立者權限案

以下內容為了避免討論顯示過長摺疊，任何人仍然可以發言和取消摺疊

兩位用戶提出可以擴展Wikipedia:大量帳號建立者權限，開啟分節討論使結構清晰。

如果要擴展該用戶組的權限內容，應該添加的權限是 添加用戶組：IP封禁豁免者。該用戶組的名稱認為不用修改。如果該案通過，上述方針也要一併修改，提出草案如下：

現行條文 ……可以不受速率限制影響地創建賬戶。用戶需要不受註冊頻率限制創建帳戶時，可申請大量帳號建立權。申請時須附有理由及使用範圍（例如在實體聚會、教育專案協助建立帳號）。註冊帳號時需在原因欄位提供註冊原因，並且不可在24小時內以非申請理由註冊超過6個帳號。

提議條文 ……可以不受速率限制影響地創建賬戶和授予IPBE豁免權。用戶需要不受註冊頻率限制創建帳戶時，可申請大量帳號建立權。申請時須附有理由及使用範圍（例如在實體聚會、教育專案協助建立帳號或者協助處理IPBE）。註冊帳號時需在原因欄位提供註冊原因，並且不可在24小時內以非申請理由註冊超過6個帳號。

現行條文 長期權限與臨時權限 無論您申請的是長期權限或是臨時權限，皆必須在申請時提出合理的依據。舉例來說： 長期權限：若您為教育專案計劃主持人等因對外推廣而需大量創建帳戶的使用者，則您可以申請長期權限。 臨時權限：若您是為了處理短期計劃而需創立大量帳戶，則在該計劃執行期間，您可申請成為帳戶創建者。

提議條文 長期權限與臨時權限 無論您申請的是長期權限或是臨時權限，皆必須在申請時提出合理的依據。舉例來說： 長期權限：若您為教育專案計劃主持人等因對外推廣而需大量創建帳戶的使用者，或者志願處理IPBE申請，則您可以申請長期權限。 臨時權限：若您是為了處理短期計劃而需創立大量帳戶，則在該計劃執行期間，您可申請成為帳戶創建者。

——落花有意12138 2023年7月31日 (一) 12:07 (UTC)

不支持，不符合這個群組的使用目的，這個用戶組是給用於組織線下活動時為新人快速新建賬戶而設立的。這樣加權限純屬為胡蘿蔔找坑填。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年8月1日 (二) 00:58 (UTC)

感覺大量用戶創建者這個用戶組的用處都不是很大......相關的志願處理另設一個用戶權限組比較好。--南嶼小十233（對話 | 貢獻 | 簽名） 2023年8月2日 (三) 11:28 (UTC)

(－)反對，顯然並非此權限群組的工作，若真有這個需求，也應該另建新的權限群組。--冥王歐西里斯（留言） 2023年8月1日 (二) 09:35 (UTC)

@Cwek、S8321414：兩位是同意另一個方案嗎？望提出寶貴意見。--落花有意12138 2023年8月1日 (二) 13:55 (UTC)

以目前的狀況來說，我比較傾向贊成上面的方案。--冥王歐西里斯（留言） 2023年8月1日 (二) 14:10 (UTC)

別急着提出方案，討論才過兩天。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年8月1日 (二) 14:43 (UTC)

這個讓管理員確認，就是管理員授予LIPE時一般需要做什麼，裏面需要哪些原來在管理員組中的權限，這些權限單獨析出來有沒風險。如果做不到的話，普通用戶也無能為力，管理員的話，或者需要加把勁。（或者有人能設計一套額外的系統，允許用戶自行申請，系統掛靠一個授予管理員權限的機械人賬戶去執行操作；類似en的en:Wikipedia:Unblock Ticket Request System實現申請票單機制，不確定有沒直接授權的機制。）——Sakamotosan路過圍觀 | 避免做作，免敬 2023年8月2日 (三) 00:54 (UTC)

(－)反對，把兩件不相關的工作強行融合到一個權限中，十分沒有邏輯；即使該提議最終通過，也應當另設用戶權限組，而實在不應當簡單地將其與現有權限隨意結合。--Yiningx（留言|主賬戶） 2023年8月2日 (三) 01:27 (UTC)

拆分郵件列表

由於現在IPBE和新賬號申請和封禁申訴共用同一個郵件列表，提案用戶組不應該能查看封禁申訴，所以提出拆分郵件列表。因為開放代理提出的IPBE和新賬號申請在新的郵件列表，封禁申訴（包括非因開放代理的IPBE）在原有的郵件列表。

提出新郵件列表名稱草案：

1. wikipedia-zh-ipbe
2. wikipedia-zh-openproxy
3. ipbe-zh
4. openproxy-zh

以上。——落花有意12138 2023年8月2日 (三) 13:36 (UTC)

所以說您在急什麼（ —— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年8月2日 (三) 14:01 (UTC)

我不急，真的 :-)--落花有意12138 2023年8月2日 (三) 14:24 (UTC)

建立新用戶組提案

IPBE授予者及新賬號建立員是一群志願者，通過郵件列表<待議lists.wikimedia.org>處理因政府網絡限制（如身在中國大陸受防火長城限制）而僅能通過開放代理編輯維基百科的用戶提出的IPBE和新賬號申請。

權限包括：

• 添加用戶組：IP封禁豁免者（用於處理IPBE申請）
• 不受速率限制影響（用於處理新賬號申請）
• 移除自己賬號的用戶組：IPBE授予者及新賬號建立員

此用戶組只能處理因政府網絡限制（如身在中國大陸受防火長城限制）而僅能通過開放代理編輯維基百科的用戶的申請，不能處理其他原因的IPBE申請。

此用戶組不能為自己建立具有IPBE權限的新賬號，或授予IPBE給自己的其他賬號。

建議IPBE授予者及新賬號建立員在授予IPBE權限後一天內關注被授予者的編輯記錄。

申請條件：

• 有意願處理IPBE和新賬號申請，了解相關方針指引，能夠友善地對待他人
• 編輯數滿1000次
• 最近一年內沒有受到封禁（不合理封禁除外）
• 在過去三個月內平均每日的編輯次數多於一次
• 已成為巡查員、回退員或傀儡調查助理三個月以上

由於授予IPBE權限時應較為謹慎，所以他們應該具有一定反破壞或反傀儡經驗，能被信任能夠妥善處理相關事務。此用戶組在處理相關內容時會查看到用戶的IP信息，授權時應注意用戶是否可信。

權限的喪失：

當IPBE授予者及新賬號建立員有濫用權限的嫌疑（例如未收到申請而授予IPBE權限，使用權限幫助濫用傀儡）時，任何用戶均可以前往Wikipedia:申請解除權限舉報，由一名未參與舉報的管理員核查後決定是否移除IPBE授予者及新賬號建立員的權限。遇緊急情況時管理員可以暫時取消IPBE授予者及新賬號建立員的權限，但必須同時立即上報至Wikipedia:申請解除權限，讓其他管理員進行覆核。

由於被IP封禁波及的新用戶只有在被授予相應權限後才能表現是否為破壞者，所以該用戶組不應該因為其授予權限的新用戶破壞而剝奪該用戶組。

當IPBE授予者及新賬號建立員自身已因濫用傀儡而被封禁時，管理員應同時立即除權。

另外，當超過六個月沒有任何編輯活動時，權限將會被移除。

根據原版調整了一下條文。桐生ここ★[討論] 2023年8月10日 (四) 14:49 (UTC)

IPBE授予跟大量帳號建立不應放在一起，應該單獨授予。--冥王歐西里斯（留言） 2023年8月10日 (四) 23:34 (UTC)

@S8321414：有IP封禁的人不能註冊賬號，如果不授予大量賬戶創建權限，處理員會處理更少（不知具體是多少）--落花有意12138 2023年8月11日 (五) 10:48 (UTC)

「具有一定反破壞或反傀儡經驗」：為什麼處理權限申請需要反破壞經驗？處理兩申請只能看到郵件，而反破壞是看內容，有很大區別。

「只能處理因政府網絡限制……」：我認為無法分辨是否是此情況，尤其此用戶組沒有查核的權限。也可以要求申請人證明其居住地？具體方法想不出來。--落花有意12138 2023年8月11日 (五) 10:39 (UTC)

反破壞經驗是希望IPBE授予者在事後能關注被授予者的編輯記錄是否為破壞，或是否為傀儡。至於只能處理因政府網絡限制，是申請者說明自己是因政府網絡限制並且查詢封禁ID確實因為代理而被封禁就可以授予。如果申請者說因為我的IP上有破壞被封IP，或者查詢封禁ID發現是因為破壞而封IP，或者申請者說我不想被CU所以需要申請，就需要由管理員判斷，IPBE授予者不能處理。桐生ここ★[討論] 2023年8月13日 (日) 12:38 (UTC)

(？)疑問 好奇為什麼必須成為巡查員等權限擁有者，是為了確保有一定社群處理經驗？——順頌時祺 ZhaoFJx^{（論•編）} 2023年8月12日 (六) 02:12 (UTC)

是，也是為了確保IPBE授予者有反破壞或反傀儡經驗，因為IPBE在一定程度上可以干擾CU，在其他語言維基甚至可能需要先CU才能授予IPBE權限。IPBE授予者不因非故意授予IPBE給破壞者而取消授予者權限，但最好能夠在授予之後短期內關注被授予者編輯記錄，並且有能力發現問題及時挽回。桐生ここ★[討論] 2023年8月13日 (日) 12:51 (UTC)

授權要求非常的寬鬆不是件好事，畢竟這玩意兒可以弄出一堆可以繞過在你維被封的IP的帳號。--SunAfterRain 2023年8月13日 (日) 13:38 (UTC)

我是期望寬進（直接授權）、嚴出（有限編輯）的，但預防繞過和濫用可能很難做到。或許能配合濫用過濾器的功能來預防一部分。--YFdyh000（留言） 2023年8月13日 (日) 20:38 (UTC)

@YFdyh000：如果說要配合防濫用過濾器直接授權，某種程度上自動廣泛授權（即魔琴所說的斜坡計劃）可能還比較好一點吧，--SunAfterRain 2023年8月18日 (五) 10:27 (UTC)

不確定指哪部分，我不贊成那個計劃的反審查和身份驗證步驟。--YFdyh000（留言） 2023年8月18日 (五) 17:26 (UTC)

很擔憂這種權限的設立。以英文維基百科為例，如果使用代理編輯，一般需要先聯繫CU人員才能申請到IPBE。中維本身已弱化經該要求，而現在又要繼續降低門檻。假若該權限設立，那麼某個破壞者只需註冊多個郵箱賬號，中維的所有封禁方法對此破壞者便基本失效。畢竟過濾器能攔截的破壞只是破壞中很少的一部分。且CU的有效性也會因此受到影響。--Yiningx（留言|主賬戶） 2023年8月14日 (一) 14:06 (UTC)

@Yichen Ding：現在如果管理員勤快一點，也會出現您所說的問題，處理緩慢使得這種問題不太明顯。如果擔心破壞賬戶處理不過來，可以等待既存的用戶都核查差不多了再給新的；或者限制申請必須等待幾日才能處理。--落花有意12138 2023年8月15日 (二) 07:55 (UTC)

然而原本處理IPBE申請的人員可能只有3名（非真實情況，下同）勤快（賦權標準較低）的管理員和5名會仔細對用戶申請進行詢問的管理員，即使這幾名「勤快」的管理員速度再快，處理申請也有上限，即使賦權後發現是破壞者傀儡，管理員自己也能儘快處理，總體不會產生太大影響；而「IPBE處理員」們上任後，突然多出了30名「只能賦權，不能除權、封禁的，勤快的管理員」。如果限制申請通過速度，那又和現在沒有什麼區別——兩者都要等差不多一周才會通過。此外，就該草案本身而言，「申請時會看到IP信息」是否意味着此權限組要簽NDA？而「有濫用權限的嫌疑」更是無從查證——回退員僅因「可能向破壞者泄露過濾器信息」便被除掉相關權限；現在居然有這樣一個權限，可以直接幫助破壞者繞過封禁，難道擁有這樣權限的用戶真的一定比回退員更值得信任嗎？--Yining Chen（留言|貢獻） 2023年8月15日 (二) 14:46 (UTC)

所以如果用規則+機械人限制新IPBE賬號的權限和封禁，是否可以呢。無法完全避免LTA冒充新人，但目前規則似乎同樣依賴管理員的主觀識別+低效率批准。還可以機械人提醒處理人員批准後有多少涉及破壞，以調準批准率。--YFdyh000（留言） 2023年8月15日 (二) 14:56 (UTC)

直接給IPBE授予者一個義務，就是授予權限7天內要關注被授予者的編輯記錄，如果發現新用戶破壞可以取消自己授予出的IPBE權限(不得取消別人授予的IPBE權限)，並需立即在WP:申請解除權限請管理員複查，並提報到VIP請社群判斷是否為LTA；如果判斷自己授予的新用戶可能是傀儡，可以取消自己授予出的IPBE權限(不得取消別人授予的IPBE權限)，並提報到傀儡調查，等傀儡調查出結果後由管理員重新授予IPBE權限或封禁。--桐生ここ★[討論] 2023年8月16日 (三) 14:10 (UTC)

另外，我個人認為IPBE處理員需要比回退員更值得信任，因此申請要求應該比回退員高，甚至需要進行WP:RFA，至於為什麼要求IPBE處理員擔任回退員、巡查員、調查助理三個月也有這個原因，需要IPBE處理員已經有反破壞、傀儡的相關權限，沒有拿這些權限去做壞事，在社群中已經有一定信譽。比方說現任的傀儡調查助理，我相信他們會正確使用IPBE處理員的權限，不會故意將IPBE授予給LTA。--桐生ここ★[討論] 2023年8月16日 (三) 14:30 (UTC)

同意相關提案，畢竟有時候我連自己都也不相信，有必要做滿三個月。--Hoben7599—論 | 支持立場新聞 2023年8月18日 (五) 06:04 (UTC)

1.認為上面桐生ここ提出的方案可行。

提議條文 在合理時段內，IPBE申請處理員應該監督其授予權限者，確保其做出建設性編輯；如做出不當編輯，授予者有責處理。如達到封禁標準，授予者暫時移除IP封禁豁免權，轉交管理員處理，管理員處理後重新授予IP封禁豁免權。

那麼其權限應該加入移除用戶組IP封禁豁免者。

2.上面已經提到過根據是否是「因開放代理封禁」而分離郵件列表，處理人應該只能看到因為開放代理封禁的申請，認為此不屬於用戶私隱。

3.認為兩者的職責不同，信任也是不同的，不可相對比較。認為破壞者更可能換IP而不是申請IPBE。

@Yining Chen——落花有意12138 2023年8月17日 (四) 09:04 (UTC)

首先，foundation:Legal:Confidentiality_agreement_for_nonpublic_information中定義的「Nonpublic personal data」中包括IP信息。我不太了解這個條款是否涵蓋了該權限所涉及的權限內容。如果該權限需要候選人簽NDA，那麼應該更加謹慎地考慮該權限與用戶查核員權限的關係。建議就此事諮詢WMF法務部門。另外，「授予者只能除權自己授權的IPBE權限，而不能除別人的權限」是從技術上限制還是從方針上限制？畢竟如果惡意將一名擁有IPBE權限的用戶（現在有3064人）除權，那麼就相當於間接封禁了該用戶（而且只能通過unblock-zh尋求解封，因為被除權人無法通過站內渠道申訴），這樣大的權限甚至能和過濾器維護員相比。該用什麼措施去儘可能防止這種情況發生呢？有人可能說回退員的權限也很大，能批量回退編輯，但該權限一方面有編輯頻率過濾器限制，另一方面也無法將其它用戶封禁，總的破壞要比濫用「IPBE權限維護員」權限小得多。最後的( π )題外話：我個人認為SPI Clerk在可以預見的，相當長的一段時間內人數應該都不會再增加（除非現有成員隱退）。--Yining Chen（留言|貢獻） 2023年8月17日 (四) 10:24 (UTC)

隨着匿名編輯的IP將匿名化等推進，我傾向IPBE授予應該儘量少介入和依賴完整IP位址做判斷，用實際編輯等做判斷。如果不想等系統做開發修改，我強烈建議用管理員權限的機械人實現IPBE授予、解除乃至規則化臨時封禁，獲權用戶提報然後機械人檢測和執行（可限制頻次、條件），以及可以臨時封禁被提報或過濾器檢出的明顯破壞以等候覆查；錯誤封禁的日誌記錄可做刪除。--YFdyh000（留言） 2023年8月17日 (四) 15:37 (UTC)

反對8月17日的新建議條文，一來難以執行，二來不應有權移除權限。--路西法人 2023年8月19日 (六) 04:22 (UTC)

如果IPBE及新帳號處理員需要WP:RFA，您是否同意有權移除權限。--桐生ここ★[討論] 2023年8月19日 (六) 10:22 (UTC)

借用維護員討論中的一句話：「我相信他們能做好這些，所以我不懷疑他們會做那些。」--Yiningx（留言|主賬戶） 2023年8月19日 (六) 12:33 (UTC)

如果需要類似RFA的程序，那就不需要此權，直接選limited administrator好了。如果他們能創建大量帳號，即使有「在合理時段內」才需要的監視限制，但處理多的人就很難監視所有獲授權者的編輯是否恰當。除權等於封鎖用戶，故反對將除權的權限授予此組。--路西法人 2023年8月20日 (日) 04:17 (UTC)

反對8月17日新建議的條文，原因是IP處理者及管理員在授予權限時，所能得到資訊極少，我們甚至無法透過這名使用者的編輯情況下去判斷。

再來即便是授予後管理員及IP處理員也沒那麼多時間再去一一查看授予權限後的編輯情況，時間沒那麼多，不符合實際現況難以執行。

如果說要保證IPBE不被濫用那麼最好的情況是盡快恢復本站的Checkuser，讓本地的CU去定期隨機的查核。--~~Sid~~ 2023年8月20日 (日) 07:54 (UTC)

edit.~~Sid~~ 2023年8月20日 (日) 08:02 (UTC)

咱認為這種所謂的連坐機制是非常奇怪的，管管授予權限/協助創建帳號後，新用戶怎麼做，甚至被發現是LTA被封了都不是管管的錯——一封郵件里的信息量少得可憐，要是能從一個想要創建的用戶名看出這是什麼LTA也是神了；到了這裏提議的IPBE處理員，為什麼就應該監督其授予權限者，確保其做出建設性編輯了？回到這個用戶組的創建上，管管相比於「IPBE處理員」到底多了什麼，讓別人認為可以放心地交給她們處理賬戶請求/IPBE權限申請呢？從權限的角度來說，IPBE跟別的權限差別很大，一般要是授予，比如巡查員這種權限，那管管會掃視近來的編輯記錄和新頁面巡查的完成度，甚至會問一些問題；而IPBE完全不需要你對這個申請用戶進行什麼審查（特指一個編輯數量極少甚至剛剛創建的用戶），這也意味着，咱個人認為，IPBE處理員不需要那種「識人」的能力。要是說一個社群投票就可以解決對其是否信任的問題，我們完全可以搞社群投票，類似於BAG和CU clerk那種形式啊。如果你認為「申請時會看到IP信息」所以要簽NDA，那目前處理unblock-zh的管管不是也有沒簽署的啊；你可以理解成管管由於受到社群選舉產生所以受到高度信任，那我們這個組的產生採取類似的機制，做到選出來的人也可以高度信任，是不是就可以認為沒有這方面的顧慮了。目前對於IPBE的處理已經很寬鬆了，並不能推出「設立IPBE處理員會造成許可十分寬鬆」這種結論，設立IPBE處理員並不意味着「繼續降低門檻」，某個破壞者只需註冊多個郵箱賬號這種事情在沒有IPBE處理員的時候也沒有很好的辦法。IP Editing的推進跟本案咱感覺沒有太大的關係。 Stang^★ 2023年8月19日 (六) 18:06 (UTC)

Stang老師這段話說服我了，所以我現在支持這個IP處理員的提案，本人也非常願意協助幫忙授予受到IP封鎖影響的新用戶IPBE。--~~Sid~~ 2023年8月20日 (日) 07:44 (UTC)

「我們完全可以搞社群投票」，正如上方所說，如果搞一個社群都信任的，類似RFA的投票，我們為什麼不直接選出一個管理員？對某名用戶的信任可以劃分為不同等級嗎？「我信任這名用戶可以很好地處理IPBE權限，但我不相信他能很好地處理巡查員權限申請」，是這樣嗎？--Yiningx（留言|主賬戶） 2023年8月27日 (日) 11:02 (UTC)

對某名用戶的信任可以劃分為不同等級嗎？是。為什麼有行政員、管理員和界面管理員？他們都是需要RFA才能擔任的。而且所謂類似RFA的投票條件肯定需要比管理員的投票寬鬆。--桐生ここ★[討論] 2023年8月27日 (日) 15:39 (UTC)

新用戶組提案 版本2

IPBE授予者及新賬號建立員是一群志願者，通過郵件列表<待議lists.wikimedia.org>處理因政府網絡限制（如身在中國大陸受防火長城限制）而僅能通過開放代理編輯維基百科的用戶提出的IPBE和新賬號申請。

權限包括：

• 添加用戶組：IP封禁豁免者（用於處理IPBE申請）
• 不受速率限制影響（用於處理新賬號申請）
• 移除自己賬號的用戶組：IPBE授予者及新賬號建立員

此用戶組只能處理稱因政府網絡限制（如身在中國大陸受防火長城限制）而僅能通過開放代理編輯維基百科的用戶的申請，不能處理其他原因的IPBE申請。

此用戶組不能為自己建立具有IPBE權限的新賬號，或授予IPBE給自己的其他賬號。

申請條件：

• 有意願處理IPBE和新賬號申請，了解相關方針指引，能夠友善地對待他人
• 編輯數滿1000次
• 最近一年內沒有受到封禁（不合理封禁除外）
• 在過去三個月內平均每日的編輯次數多於一次
• 已成為巡查員、回退員或傀儡調查助理三個月以上

由於授予IPBE權限時應較為謹慎，所以他們應該能被社群信任妥善處理相關事務。此用戶組在處理相關內容時會查看到用戶的IP信息，授權時應注意用戶是否可信。

權限的喪失： 當IPBE授予者及新賬號建立員有濫用權限的嫌疑（例如未收到申請而授予IPBE權限、使用權限幫助濫用傀儡）時，任何用戶均可以前往Wikipedia:申請解除權限舉報，由一名未參與舉報的管理員核查後決定是否移除IPBE授予者及新賬號建立員的權限。遇緊急情況時管理員可以暫時取消IPBE授予者及新賬號建立員的權限，但必須同時立即上報至Wikipedia:申請解除權限，讓其他管理員進行覆核。

由於被IP封禁波及的新用戶只有在被授予相應權限後才能表現是否為破壞者，所以該用戶組不應該因為其授予權限的新用戶破壞而剝奪該用戶組。

當IPBE授予者及新賬號建立員自身已因濫用傀儡而被封禁時，管理員應同時立即除權。

另外，當超過六個月沒有任何編輯活動時，權限將會被移除。

根據Stang的回覆做出了調整，不再要求「識人」，而是要求被社群信任。桐生ここ★[討論] 2023年8月23日 (三) 07:12 (UTC)

辛苦了，可是話說要怎麼才能知道「未收到申請而授予IPBE權限」呢？普通用戶應該是看不見IPBE郵件列表罷。還是說會定期進行審查？——順頌時祺 ZhaoFJx^{（論•編）} 2023年8月24日 (四) 00:40 (UTC)

不允許「未收到申請而授予IPBE權限」的意義是：

即使是現實認識的朋友因翻牆需要IPBE，也需要先發郵件申請才能授予權限，不能直接就授予權限讓人無法查證。

至於如何知道，授予IPBE時需要進行備案，而且管理員和其他IPBE處理者可以看到郵件列表，如果發現違規可以舉報。--桐生ここ★[討論] 2023年8月24日 (四) 09:22 (UTC)

前面tiger提出需要考慮走錯的可能，即郵件列表受到非開放代理的ip封禁的豁免權請求。此非ipbeg應當處理，所以應該由有權限查看真實IP的用戶剔除，比如管管，或可以要求用戶在標題或者郵件開頭按照一個固定的機器可讀模式提供信息，自動鑑別。——正在思考的落花有意12138 2023年8月26日 (六) 14:28 (UTC)

上方積極推進提案的用戶似乎只有桐生ここ和落花有意12138，而明確表達支持意見的則很難找到（Stang？）。提案者對上方的幾條反對意見不加以回應，令本人感覺十分遺憾。為何「草案調整」及相關討論只是選擇性地考慮支持者的意見呢？難道提案人希望繞過（「無視」？）反對意見，「強行」推進提案通過嗎？--Yiningx（留言|主賬戶） 2023年8月27日 (日) 10:59 (UTC)

我應該有回應您，比如「IPBE處理員們上任後，突然多出了30名只能賦權，不能除權、封禁的，勤快的管理員」，提出了IPBE處理員有義務監督新用戶而且可以除權的想法，不過閣下沒有對此表示看法，而路西法人等人反對IPBE處理員可以除權，stang反對監督義務。新的提案是參考了多方的意見，不是只參考了stang的回應，也不是強行推進提案通過，而根據意見持續修改提案，而且上面討論也有其他人表示支持提案。--桐生ここ★[討論] 2023年8月27日 (日) 15:29 (UTC)

投票制度

絲糖提出投票，此開分節討論。

首先需要討論是否需要投票。落認同其可作為社群信任的證明，但是可能會出現參與人少和通過率低的情況。

提出如下細節問題供討論：

1. 最低參與人數的設置：太高可能沒人投票而落選，太低不能反應共識
2. 投票用時：太短可能不能反應共識，太長可能使提名人喪失熱情。我建議題名即開始投票，周期14日，同時設置一個雪球機制。
3. 是否使用安全投票

這裏提供一個草案，內容可以討論：

---

權限的獲取：

具投票權的用戶可在Wikipedia:IPBE授予者及新賬號建立員/申請提名滿足上述條件的用戶為IPBE授予者及新賬號建立員。

提名發出後

• 管理員應該核對提名人和被提名人的資格，不合資格的關閉（其他用戶也可關閉），合格的留言說明
• 用戶可討論，具投票權的用戶可投票

投票進行三日後，管理員可用雪球法則關閉明顯不受社群信任投票；進行7日後，如同意票數大於等於總票數的四分之三，管理員可以關閉投票並授權；進行14日後投票截止，管理員點票，符合以下條件的授權：

1. 票數大於8票
2. 同意票多於二分之一
3. 棄權票少於三分之一

---

以上——不甚活躍的落花有意12138 2023年8月26日 (六) 14:28 (UTC)

DYK字數約定

看有編者在Wikipedia:互助客棧/方針#追廢已上首頁的DYK的做法就現時而言是否合理？中提到「DYK這一套是從英維搬過來的」，想問下是否可以參照更新一下英維字數約定。英維約定為en:Wikipedia:Did_you_know#Eligibility_criteria：Articles must have a minimum of 1,500 characters of prose (ignoring infoboxes, categories, references, lists, and tables etc.) 。目前中文維基約定為「不少於3000位元組（註：1個漢字 = 3個字節）」。但有些沒幾句話的條目插入信息框和參考文獻後，很容易過線，用了信息框註釋<!-- -->和web.archive.org後能增加更多字節。（以下舉例條目無關dyk）

參考文獻占字符舉例：例如我用奧本海默_(電影)里第一個參考文獻測試下，單個ref就能佔用585位元組；

信息框占字符舉例：例如HTV-X1條目，一共沒幾句話，字節數卻高達11,175位元組，基本都是| declared = <!--when the operator/agency officially ended the mission-->這種無用信息框註解在佔用字節。 --桃花影落飛神劍（留言） 2023年7月20日 (四) 20:30 (UTC)

這只是基本的推薦資格吧。要登上DYK也得看條目品質如何。——WMLO※議程表 2023年7月20日 (四) 22:31 (UTC)

像最近7月的幾個通過DYK的條目，如米素爾·保利臣 （正文8句話）、尼克拉斯·施密特（正文8句話），按英維不算信息框、表格和參考文獻的標準就可能被卡掉。--桃花影落飛神劍（留言） 2023年7月21日 (五) 00:07 (UTC)

或許可以要求所有正文加起來有一400漢字。--落花有意12138 2023年7月21日 (五) 00:37 (UTC)

我覺得可以嚴格一些，同時要求不少於3000位元組（非小作品）與正文不少於1500位元組，不然如果有人寫了正文剛剛好1500位元組的條目交上來DYK，但條目被掛了小作品模板也有些尷尬。Sanmosa _{In vain} 2023年7月21日 (五) 00:53 (UTC)

現有的「不少於3000位元組（註：1個漢字 = 3個字節）」的門檻自2007年至今十幾年都沒有改過，而2007年時並不流行infobox、cite系列等等模板。就以2007年的這個約7000位元組的DYK與2023年的這個約9000位元組的DYK來比較，前者可讀的正文長度竟比後者明顯多幾倍，也許可以說DYK的長度門檻要求今天可能已經追不上通脹。至於要求正文不少於1500位元組，有沒有技術方案可以讓人清晰計算正文長度？--街燈電箱150號 開箱維修 抄錶 檢驗證明 2023年7月21日 (五) 03:01 (UTC)

JS表示：.replace( ... ).replace( ... ).replace( ... ).replace( ... )...XDDD--路西法人 2023年7月21日 (五) 03:20 (UTC)

現在的DC規則有「有效長度」的設定（自DC18起），但我不記得當時有沒有弄計算有效長度的小工具了，如果有的話，基於那個小工具改動一下應該能解決問題。@Temp3600。Sanmosa _{In vain} 2023年7月21日 (五) 04:12 (UTC)

• DC的有效長度是手算的，但有小工具可以協助去除模版等技術性字節。另同意增加正文長度要求。--Temp3600（留言） 2023年7月23日 (日) 02:46 (UTC)

(※)注意，DC的有效長度還是有算進ref跟infobox的字節數，不能直接沿用。(＋)支持以正文長度作為要求，像是不久前結束的2023年非洲月，要求便是「符合DYK標準且正文達300漢字」，可以考慮沿用。--巴波（留言） 2023年7月23日 (日) 06:50 (UTC)

300漢字（即900位元組，連1/3都沒有）未免要求太低了。現有的3000位元組在2007年已經實行，當年每個條目在不流行infobox、cite的情況下正文長度大多佔超過2/3，那麼應可預期3000位元組的原意是希望正文不應該少於2000位元組。現在提出正文至少要1500位元組已算是非常寬鬆了。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2023年7月25日 (二) 03:49 (UTC)

至少300漢字是一個社群已形成共識、可以實施的低標，再往上調高就要再繼續討論形成共識。--巴波（留言） 2023年8月5日 (六) 10:14 (UTC)

300漢字頂多衹是社群對於非洲月長度的共識，但不認為這也代表社群對於DYK長度的共識也是這麼低（像是阿薩伊塔衹有400漢字也沒有成DYK）。坦白說，我想一個DYK的字數水準，不應該連一個初中畢業生也不如吧（以港澳教育標準來看）。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2023年8月18日 (五) 13:27 (UTC)

英維有一個檢查條目是否符合DYK標準的小工具，我之前搬過來了，User:Interaccoonale/DYKcheck.js，但是它計算字數可能是按照空格算一個單詞來計算的，明顯需要改一改才能用於中維。--——🦝英特浣熊耐爾_{（留言・貢獻）} 2023年7月25日 (二) 14:51 (UTC)

我搞不定了。有沒有人知道偏好設置裏面那個字數計算小工具是怎麼實現的？--——🦝英特浣熊耐爾_{（留言・貢獻）} 2023年7月26日 (三) 02:36 (UTC)

好像是js對於基本多文種之外的字符支持有問題，我放棄。--——🦝英特浣熊耐爾_{（留言・貢獻）} 2023年7月26日 (三) 06:23 (UTC)

那個數文本的可以看腳本實現。好像是算CJK的話將Unicode的CJK範圍的字替換成「.」，其他替換空白，而算字節的話按照UTF-8的範圍分組替換為對應字節長數的「.」，然後都是統計「.」的數量就是了。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年7月26日 (三) 07:26 (UTC)

我看過了，那個小工具只統計了基本多文種平面的字符，參照堆疊溢出StackOverflow的這個帖子來看，應當是js對於輔助平面的支持有問題。--——🦝英特浣熊耐爾_{（留言・貢獻）} 2023年7月26日 (三) 07:53 (UTC)

@Cwek：所以技術上能做得到嗎？畢竟這種計正文位元組的工具要是真能弄出來，日後也不止DYK能用到。Sanmosa _{In vain} 2023年7月26日 (三) 08:51 (UTC)

看上面，他說這個工具在js實現上存在一些技術問題，不過大部分字符在Unicode的BMP的話，大概沒問題？——Sakamotosan路過圍觀 | 避免做作，免敬 2023年7月26日 (三) 09:16 (UTC)

我想了一下，認為應當可以忽略擴展區字符。--——🦝英特浣熊耐爾_{（留言・貢獻）} 2023年7月26日 (三) 10:55 (UTC)

@Interaccoonale：這樣的話，可能就有勞你製作一下那個具體的小工具了。Sanmosa _{In vain} 2023年7月26日 (三) 11:11 (UTC)

字數的部分應該已經改好了，但是它有個問題是，它計算的長度是「散文長度」（prose size），也就是說用 *、# 這樣的方式生成的列表不被計算在正文字數內，然而MOS:列表目前在中維不是共識。如果社群認為列表應當被計入正文字數內的話，這小工具還得再改改。（另外這個小工具還有檢測條目創建時間以及擴充程度是否達到DYK標準的功能，那些我稍後按照中維標準改完。）--——🦝英特浣熊耐爾_{（留言・貢獻）} 2023年7月26日 (三) 12:24 (UTC)

另外還有表格也不被計算在內，例如現在在首頁DYK上的埃瑪·基米萊寧按照這種計算方式可能被認為不達標。--——🦝英特浣熊耐爾_{（留言・貢獻）} 2023年7月26日 (三) 12:44 (UTC)

副知@Cwek：。--——🦝英特浣熊耐爾_{（留言・貢獻）} 2023年7月26日 (三) 13:01 (UTC)

@Interaccoonale：一些個人意見：（1）雖然Wikipedia:格式手冊/列表#列表的形式目前在中維不是共識，但社群一般默認以*、#點列的都是列表，所以就不內嵌於表格內的點列列表而言，只計算「散文長度」是正確的，因此這不完全是bug，你看一下金昌柱 (古生物和古人類學家)的論文列表就知道我在説甚麽了。（2）表格也不被計算在內確實是個bug，但像「正文不少於1500位元組」的要求本來也不能完全依賴小工具，如果真有人寫了列表的話，這可能需要算正文位元組數的人就表格內容手動算字數了（不過如果那個列表條目單計「散文長度」也有1500位元組的話，表格算不算好像也沒太大關係？），所以如果可以的話建議把這個bug修理一下（而且內嵌於表格內的點列列表也要算正文長度）。Sanmosa _{In vain} 2023年7月26日 (三) 13:20 (UTC)

據我所知也有很多人會在以 *、# 這樣的方式生成的列表中撰寫「散文性」內容（姑且就用這個詞吧），例如歐亞紅松鼠#文化表現及歐烏鶇#亞種，這類內容不計入正文長度私以為不甚合理。--——🦝英特浣熊耐爾_{（留言・貢獻）} 2023年7月26日 (三) 13:32 (UTC)

@Interaccoonale：那你還是想辦法讓以*、#點列的列表的內容有辦法算進去吧，但這或許也意味着DYK的正文長度最終只能手算，而完全不能依賴小工具了。要不你想辦法提供不同模式的算法，讓用戶選擇以*、#點列的列表要不要算正文長度？Sanmosa _{In vain} 2023年7月26日 (三) 13:44 (UTC)

聽起來可以，不需要用戶手動選擇模式，直接給出兩種結果即可。--——🦝英特浣熊耐爾_{（留言・貢獻）} 2023年7月26日 (三) 13:47 (UTC)

也可，但內嵌於表格內的點列列表應該在兩種算法下均計入正文長度。Sanmosa _{In vain} 2023年7月26日 (三) 22:19 (UTC)

為什麼？能給一個例子嗎？--——🦝英特浣熊耐爾_{（留言・貢獻）} 2023年7月27日 (四) 00:18 (UTC)

我想不起具體例子了，但內嵌於表格內的點列列表的作用應該是在格中再分項，這時這些分項顯然地也屬於「正文」的一部分。或許最終計算的方式應該有三種，分別是完全不計算點列列表、僅計算內嵌於表格內的點列列表，以及計算所有點列列表。另外有一點值得留意的是，一些表格並不是直接用wikitable語法來建立的，比如美國那些縣級行政區列表中的表格都是引用含wikitable語法的模板來建立的。Sanmosa _{In vain} 2023年7月27日 (四) 08:38 (UTC)

我注意到參見和外部連結以及部分參考資料用的也是點列式列表，技術上無法把它們和正文中的列表區分開。--——🦝英特浣熊耐爾_{（留言・貢獻）} 2023年7月30日 (日) 02:19 (UTC)

應當考慮提高字數（位元組）要求，惟同時應設立過渡期俾編者適應。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年7月26日 (三) 04:06 (UTC)

我覺得具體的處理方式可以是「同時要求不少於3000位元組（非小作品）與正文不少於1500位元組」的新規定於2024年1月1日才正式實行，但在社群通過此提案至2024年1月1日期間將預備實施新規定的公告放在DYK頁裏，這應該能滿足「過渡期」的需求。Sanmosa _{In vain} 2023年7月26日 (三) 08:48 (UTC)

(！)意見：如果是這樣做，那不是增加撰寫的難易度了嗎？（針對不是「從其他語言維基百科翻譯過來」的條目）--Sinsyuan FA工作室 2023年7月26日 (三) 14:12 (UTC)

其實infobox、cite於後期的大流行其實無形中降低了撰寫的難易度，現在衹是要追回舊日應有難易度罷了。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2023年7月26日 (三) 14:41 (UTC)

我不認可Cdip150的看法。我個人的意見是這樣做確有增加撰寫難度的可能性，但增加的幅度不至於大到使DYK出現優特評選化的情形。這至少能讓用戶謹慎選題，而不會為寫而寫，寫出一些用大量非正文內容堆砌條目長度的條目。Sanmosa _{In vain} 2023年7月27日 (四) 08:32 (UTC)

我想了解，是否可以統計近月通過DYK條目的正文字數，像是中位數為幾字、正文低於1500字的條目佔多少百分比？有這些數據應該有助於討論出合適的字數門檻，也避免大幅影響DYK。--巴波（留言） 2023年8月5日 (六) 10:14 (UTC)

(＋)贊成。----Cat on Mars 2023年8月6日 (日) 01:54 (UTC)

在社群通過新指引之前的這段時間，該如何對待字數明顯不足的條目呢？比如正在8月5日評選中的這一條英超夏季系列賽，總字節4209位元組，正文4句話。--桃花影落飛神劍（留言） 2023年8月6日 (日) 01:48 (UTC)

我覺得倒也不用特別針對表格進行狙擊，但真的這麽極端的情況的條目我覺得也不會有多少人會關注，一般而言只要真的符合基本要求，真過了幾個也不用過分擔心。Sanmosa _{In vain} 2023年8月6日 (日) 04:47 (UTC)

(！)意見：個人覺得假設英維要求1500字元的限制，我認為本維可以簡單採用4500位元組(以1漢字=3位元組)的限制來規定DYK標準，個人覺得假設有人覺得候選條目過了這新DYK標準還不夠有資格，自然會提出反對並指出條目過短，或是不投票(使條目淨支持不到4票)而使提名條目被否決，不用大費周章設太多規定使得新編者做了條目不敢提DYK，降低一部分用戶的編輯意願。謹此表露自己陋見，敬請見諒。--${\ce {Be + He->B+ +e- +H- +e+}}$，這是β衰變和正電子發射，請無視其他能量釋放。 2023年8月21日 (一) 07:46 (UTC)

@Cwek、Sanmosa、Cdip150：DYKCheck腳本已經按照本地DYK規則適配完畢，在自己的common.js中加入importScript('User:Interaccoonale/DYKcheck.js');即可使用，推薦在新舊Vector和Timeless下使用。目前考慮到列表和表格一般不是散文內容，因而暫未將其計入。--——🦝英特浣熊耐爾_{（留言・貢獻）} 2023年7月30日 (日) 02:44 (UTC)

感覺可以，但你的小工具似乎是計字數？這裏討論的正文要求都是以位元組計，這樣的話相當於要重新考量一個以字數計的正文要求（可能是500字？）。Sanmosa _{In vain} 2023年8月4日 (五) 15:34 (UTC)

這樣。那麼我看一下給它增加按照字節數計算的功能。--——🦝英特浣熊耐爾_{（留言・貢獻）} 2023年8月8日 (二) 09:03 (UTC)

已經加入按照字節計算的功能。--——🦝英特浣熊耐爾_{（留言・貢獻）} 2023年8月10日 (四) 16:41 (UTC)

如果要對正文字數做出限制，列表類條目撰寫的難易度可能有明顯增加。列表的正文只有導言，那就代表對於一般條目而言針對全文的字數要求，在列表條目則是在導言就需要達到。舉例而言，中華人民共和國已撤銷地級市列表這篇條目，列表內容很全面，是篇FL，但導言只有186字，無論如何都不可能達到正文字數要求。故(＆)建議將列表類條目排除在正文字數要求之外。--BlackShadowG Slava Ukraini! 2023年8月9日 (三) 13:33 (UTC)

我個人傾向列表條目的列表／表格內容也計入正文，但現時的小工具無法做到這點，因此可行做法有兩個，一個是對列表條目的引言的字數／位元組數要求下修並訂為對一般條目的字數／位元組數要求的三分之一，另一個是要求計算列表條目的字數／位元組數時須人手計算（或至少人手計算列表／表格部分）。Sanmosa _{In vain} 2023年8月10日 (四) 00:19 (UTC)

對列表條目的引言的字數／字節數要求下修並訂為對一般條目的字數／字節數要求的三分之一，據我所知，不少用戶並不擅長給列表寫一個完善的導言。此外，對於列表項很少的列表，要求寫一個長度達標的導言可能有些強人所難。

要求計算列表條目的字數／字節數時須人手計算（或至少人手計算列表／表格部分），對於行政區劃列表、物種列表等，即使把列表的內容算進字數／字節數，也不會有很多……--BlackShadowG Slava Ukraini! 2023年8月12日 (六) 03:11 (UTC)

@BlackShadowG：（1）現時小小作品的定義是50字以內，假如對一般條目的正文字數要求是500字，那列表條目的引言的字數／字節數要求就會是166⅔字，也就是3又⅓個小小作品的長度。完不完善不是重點，但「要求寫一個長度達標的導言可能有些強人所難」這點我認為你有必要具體説明一下，並舉出實例，否則我感覺我無法理解你有這個説法的原因。（2）這點我倒是可以理解，我要看看其他人是怎麽想的。Sanmosa _{In vain} 2023年8月13日 (日) 09:49 (UTC)

我指的是「對於列表項很少的列表，要求寫一個長度達標的導言可能有些強人所難」，我曾經在FLC看到過只有兩個列表項的條目，但實在沒有耐心再重新把那篇條目找出來了，對於此類列表項很少的條目，導言長度相應的就會變短，亦可能難以達到長度要求。--BlackShadowG Slava Ukraini! 2023年8月13日 (日) 14:19 (UTC)

我曾經自己送過至少兩個只有兩個列表項的條目到FLC，它們的引言長度都長於166⅔字。Sanmosa _{In vain} 2023年8月14日 (一) 23:20 (UTC)

有一說一，這種列表本身就不太合格⋯⋯ —— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年8月15日 (二) 06:54 (UTC)

再不然我把要求下修為一般條目的字數／位元組數要求的四分之一（即125字、2.5個小小作品的長度）也可。Sanmosa _{In vain} 2023年8月15日 (二) 14:26 (UTC)

那麼像是上面的英超夏季系列賽（列表外的正文有130漢字）如此單薄的內容也還是有資格了……（雖然這個實質上是非列表，但不排除會有人用這種寫法、然後將引言仿照歐洲冠軍聯賽決賽列表的形式稍為改一下就變成了列表），那我會覺得意義很小了。我跟Ericliu1912的意見類似，「列表項很少的列表」本來就不太適合DYK（在「列表項很少」的情況下仍能寫出長度很可觀的引文則另當別論），這裏又沒人叫大家要選一個先天不足而又無法靠後天努力的取材來參選，遑論強人所難。敝人還是認為列表條目的引言內容加列表內容總和最少也要500漢字才合適。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2023年8月18日 (五) 13:27 (UTC)

@BlackShadowG。@Cdip150：可以以定義的方式限制「引言」為wiki系統下的section 0，section 0外的文字一概不視為引言。説明一下，我之前送到過FLC的那兩個只有兩個列表項的條目一個引言278字，另一個引言246字，還有一個因歷史斷代的緣故而只可能有四個列表項的FL引言553字，不過好一部分的引言內容跟其他10個同類列表的引言內容重合（那11個列表都是我寫的，所以這樣做並不存在版權問題）。考慮到DYK本身意在鼓勵用戶多寫條目，我不太建議對用戶過分嚴苛。Sanmosa _{віки-віків} 2023年8月18日 (五) 15:34 (UTC)

那樣的話像是化學元素發現年表這種內容豐富的列表反而會失去資格了（序言衹有90漢字），反而製造了另類的嚴苛。而且這種限制不見得有效——衹要把全部的一般文段都不分章，全部合起來放在第0章已經能繞得過。其實列表條目內的一般文字內容與列表內容共享這500漢字的下限，我覺得已經是最平衡的做法。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2023年8月23日 (三) 16:30 (UTC)

我更傾向於列表只要滿足其中一個要求（即全文正文含表格內文字至少500字或列表引言至少166⅔字）即可，而非直接以列表引言至少166⅔字的要求取代正文至少500字的要求在列表的適用性。另外，我不認為有人會如此閑地特意鑽這些規則的漏洞，這種情況下保持假定善意顯得非常必要。Sanmosa _{віки-віків} 2023年8月28日 (一) 23:56 (UTC)

• 引言要100字以上對於某些領域的某些主題可能有困難，例如這個六維正七胞體、四維正十一胞體引言只有五十幾字，也很難再多了，不希望還得硬擠廢話去堆疊引言。這個條目我認為是符合DYK標準的，其也確實上過首頁。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年8月29日 (二) 15:48 (UTC)

  --( ✓ )同意，在某些領域(尤其是科學方面)中的條目引言文字在常見情況下不大可能很多，個人覺得與其設下一個更為強硬且複雜的DYK初步審查標準，使原本可能可以參與維基百科使用者審核的條目會直接褫奪資格，不如加強社群審核條目的力量，適當在不合資格的條目投予反對票或是直接不投支持票使條目無法獲選，因為個人相信大部人在投DYK票時候，應該會把條目先讀過一遍再投票，謹此表露自己個人陋見，敬請見諒。--${\ce {Be + He->B+ +e- +H- +e+}}$，這是β衰變和正電子發射，請無視其他能量釋放。 2023年8月31日 (四) 13:31 (UTC)