本页使用了标题或全文手工转换
Semi-protection-shackle.svg

维基百科:互助客栈/方针

维基百科,自由的百科全书
跳到导航 跳到搜索

Breezeicons-apps-48-cantor.svg

本頁提出或讨论维基百科政策、方针,请参看方針與指引方针列表
繁简处理的议题请前往字词转换讨论页
条目应当如何编辑才符合中立性原則寻求社群共识,请前往条目探讨留言。
請注重礼仪及遵守方針與指引,一般問題請至互助客棧其他區知识问答提出,留言后请务必签名(点击 Signature icon april 2018.png )。


發表前請先搜索存档,參考舊討論中的内容可節省您的時間。
公告板
# 話題 發言 參與 最新發言 最後更新(UTC+8)
1 專題命名空間(第五至六階段) 80 11 A2569875 2021-07-19 20:42
2 WP:捷徑指引草案修訂 40 5 LuciferianThomas 2021-08-04 11:03
3 再次推动破坏者(LTA)成为名字空间 50 14 Kriz Ju 2021-08-04 04:15
4 修订书籍关注度 44 8 Fire-and-Ice 2021-07-27 17:36
5 Wikipedia:格式手册#地区用词的格式(指引) 6 5 Bus Follower 2021-07-28 16:31
6 关于wp:srcu的讨论 15 7 Sanmosa 2021-07-28 19:43
7 關於歡迎新手列表簽名移除的活躍度門檻 3 2 Ericliu1912 2021-08-04 15:35
8 关于推动维基百科:不要诉诸法律威胁成为指引的提议 12 6 GZWDer 2021-07-31 10:12
9 有關快速刪除方針O7條的事宜 50 9 Z7504 2021-08-04 19:26
10 关于在Wikipedia:格式手册#條目定义句与Wikipedia:格式手册#自由链接的格式中禁止添加指向条目本身或者其重定向的链接的提案 4 3 Sanmosa 2021-07-29 11:05
11 延伸確認權限後續討論 part2 164 19 MilkyDefer 2021-08-04 14:22
12 论废除WP:1E 42 11 Sanmosa 2021-08-02 14:50
13 條目標題、內文及重新導向頁面標題中對SARS-CoV-2的變種的稱呼(第四次) 5 2 落花有意12138 2021-07-31 13:43
14 希望确认维基对YouTube/Bilibili/Tiktok等视频网站作为参考资料的标准 3 3 落花有意12138 2021-07-31 12:44
15 提議新增條目編輯員 10 8 Oldmanson 2021-07-31 21:02
16 更改模板編輯員的硬性授權條件 8 7 Xiplus 2021-08-01 20:29
17 新增快速刪除位於不恰當命名空間消歧義的準則 20 6 Sanmosa 2021-08-04 09:22
18 重提調整檔案使用守則 3 2 Sanmosa 2021-08-03 11:02
19 命名常規(方針) § 括号的使用2 27 9 Sanmosa 2021-08-04 18:43
20 关于傀儡方针的询问 3 2 羊羊32521 2021-08-04 08:04
21 关于规避cu的破坏者怎么对付 7 4 Pavlov2 2021-08-04 13:54
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時,
請先檢查設定是否有誤

專題命名空間(第五至六階段)

[編輯此導航模板]

導航模板請參閱此。導言請參閱此

第五階段:討論重新導向與捷徑的設立方式

各階段不得同時討論,前一項討論完結之後,才能進行下一段討論。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月29日 (五) 12:57 (UTC)

本案進入倒數第二個部分。現在將討論未來專題捷徑如何設立,以及原有捷徑的去留:
  • 未來是否允許建立跨WP與PJ空間的捷徑?如果需要,是否需要進一步規範?
  • 未來是否允許建立跨WP與PJ空間的非捷徑的重新導向?
  • 舊有的跨WP與PJ空間的捷徑是否需要清除連入然後(×)删除
[email protected]30000lightyearsTaiwania JustoLuciferianThomas羊羊32521BlackShadowG
請討論-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月14日 (日) 09:41 (UTC)
  • 我认为PJ空间的捷径统一规范为WPJ/PJ:XXX,将现有WP重定向全部转到PJ去。比如WikiProject:智能手机WP:SMARTPHONE直接转移到WPJ:SMARTPHONE。--LightyearsTalk·Sign#订阅维猫报喵! 2021年2月14日 (日) 11:15 (UTC)
  • 个人意见
    1. 为了避免混淆,将来应该一律禁止建立跨WP与PJ空间的捷径重定向。
    2. 目前存在的WP重定向到PJ的捷径应该全部转移到PJ,若无链入或很少链入,可考虑(×)删除;若数量过大,或者已经在讨论中被引用,则可考虑(○)保留以仅供历史参考。
    3. 同时,将PJ名字空间中所有{{shortcut}}中的捷径一律改为以“PJ”开头的捷径,不再推荐使用以WP开头的捷径。

——BlackShadowG留言维基百科20岁生日快乐! 2021年2月14日 (日) 12:57 (UTC)

同上,不然就沒必要偽命名空間了。 2021年2月14日 (日) 13:49 (UTC)
我覺得從PJ空間捷徑連出沒什麼問題,WP空間也有捷徑連至Help。PJ分拆了就不要再從WP連過去了,舊的就隨它吧。--LuciferianThomas留言 2021年2月14日 (日) 14:09 (UTC)
舊的捷徑如要批量刪除的話可能要請求管理員開刪除機器人...-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月14日 (日) 14:11 (UTC)
所以把PJ空间的{{shortcut}}全部更新,提醒将来的编者不要再用WP链接到PJ的捷径就行了。那些没有链入的WP捷径删了也无妨。——BlackShadowG留言维基百科20岁生日快乐! 2021年2月16日 (二) 02:05 (UTC)
個人意見:
  1. 原則上不允許,但社羣就個別頁面的特殊情形可以例外特許。建議以修改R2規範處理。
  2. 不允許。如出現,應清除連入並刪除。
  3. 可行。清除連入可以請求bot(WP→PJ),刪除的話我覺得開一個list,然後轉AFD即可。
以上。SANMOSA SPQR 2021年2月17日 (三) 14:40 (UTC)
既然(我認為)未來不允許建立跨WP與PJ空間的非捷徑重新導向,而且非條目命名空間的非捷徑重新導向本來就使用率低下,如果真的有人意外建立了,都不會有多少連入,清除連入也不是甚麽困難的事,而且還能避免未來的誤用。SANMOSA Σουέζ 2021年3月31日 (三) 07:43 (UTC)
Wikipedia:专题Wikipedia:专题委员会等部分页面为何还没有移动到新的名字空间?还是这些页面不应该移动?--百無一用是書生 () 2021年2月19日 (五) 02:46 (UTC)
先前討論有提到將專題介紹留在WP空間。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月19日 (五) 17:12 (UTC)
专题委员会并非专题介绍,Wikipedia:专题似乎也称不上是介绍,更像是WikiProject:首页的作用--百無一用是書生 () 2021年3月1日 (一) 02:54 (UTC)
個人認為跨WP->PJ沒差,但PJ->WP的不行-- Sunny00217  2021年2月21日 (日) 13:56 (UTC)

第五階段:小結

通過。SANMOSA Σουέζ 2021年5月21日 (五) 09:53 (UTC)
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

總結以上討論意見:

  1. 禁止建立跨WP與PJ空間的捷徑重新導向。並清理連入頁面後刪除現有跨WP與PJ空間的捷徑重新導向;同时,将PJ名字空间中所有{{shortcut}}中的捷径一律改为以“PJ”开头的捷径,不再推荐使用以WP开头的捷径。→修改R2規範
  2. Wikipedia:專題Wikipedia:專題委員會移動到PJ空間。→需探討是否留重定向
以上-- 五歲抬☎️·☘️) 2021年4月7日 (三) 06:22 (UTC)
補:R2修改內容:
現行條文

R2. 跨名字空间重定向

由条目的名字空间重定向至非條目名字空间,将用户页移出条目名字空间時遺留的重定向,或者从草稿名字空间指向非草稿名字空间的重定向。經社群同意設立的偽命名空間屬於本規則之例外。注意:有时新加入的维基人偶尔会在主条目空间誤建用户页。使用“移动”页面工具将用户页移回用户名字空间会保留页面历史,在删除遺留的重定向頁前,考虑保留一到两天;草稿重定向速删前,请确保草稿已经完成其作用,并且草稿的历史已经合适地移动到相应的正式页面。
  • 使用模板{{d|R2}}或{{d|interwk}}。
提議條文

R2. 跨名字空间重定向

包括以下幾種類型:
  1. 从条目名字空间指向非條目名字空间的重定向(包括將用户页从条目名字空间移動至用户页名字空间時遺留的重定向);
  2. 从草稿名字空间指向非草稿名字空间的重定向;
  3. 從計畫命名空間(Wikipedia)指向維基專題命名空間(WikiProject)的重定向;及
  4. 從維基專題命名空間(WikiProject)指向計畫命名空間(Wikipedia)的重定向。
經社群同意設立的偽命名空間屬於本規則之例外。
注意:有时新加入的维基人偶尔会在主条目空间誤建用户页。使用“移动”页面工具将用户页移回用户名字空间会保留页面历史,在删除遺留的重定向頁前,考虑保留一到两天;草稿重定向速删前,请确保草稿已经完成其作用,并且草稿的历史已经合适地移动到相应的正式页面。
  • 使用模板{{d|R2}}或{{d|interwk}}。

以上。SANMOSA Σουέζ 2021年4月17日 (六) 04:12 (UTC)

Module:Template:Delete/data模組的對應修改見User:Sanmosa/R2模組SANMOSA Σουέζ 2021年4月17日 (六) 04:24 (UTC)
現時有3502個WP->WPJ的重新導向,33個WPJ->WP的重新導向。--Xiplus#Talk 2021年4月17日 (六) 05:07 (UTC)
上面的結論有指明「清理連入頁面後刪除現有跨WP與PJ空間的捷徑重新導向」,所以應該需要bot,再不然發通知邀請社群協力清理也可。SANMOSA Σουέζ 2021年4月17日 (六) 11:00 (UTC)
(!)意見:“2. 将用户页移出条目名字空间时遗留的重定向”真包含于“1. 由条目名字空间指向非條目名字空间的重定向”,可以删去。另外那个看起来怪怪的,建议删去。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月20日 (二) 04:57 (UTC)
@羊羊32521:(1)1是(條目命名空間)→(非條目命名空間),2是(非條目命名空間)→(條目命名空間),2不能刪。(2)完成。SANMOSA Σουέζ 2021年4月21日 (三) 03:38 (UTC)
查CSD历史,R2最初加入于Special:Diff/284065通过将用户页移出条目名字空间而建立的重订向。 (有时新的维基人偶尔会在主条目空间创建用户页。使用“移动”页面工具将用户页移入用户名字空间会保留页面的历史,考虑在删除作为移动结果的重定向页前,保留一到两天。) 所以是说:①在主名字空间建立用户页;②将该用户页移动到用户名字空间(留重定向);③快速删除重定向页。故2亦是“(条目名字空间)→(非条目名字空间)”。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月21日 (三) 15:55 (UTC)
阁下这一改意思都变了 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月21日 (三) 15:59 (UTC)
@Sanmosa-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月24日 (六) 14:39 (UTC)
另外我认为WP→PJ可能不适合速删,上方讨论有提到
或者先开机器人把历史遗留问题解决掉 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月21日 (三) 16:08 (UTC)
容許我再多等待三日,上面的提案會稍為調整。SANMOSA Σουέζ 2021年4月21日 (三) 03:38 (UTC)
@羊羊32521:有道理。已再調整。7日後我再重行公示。SANMOSA Σουέζ 2021年4月25日 (日) 08:19 (UTC)
針對「WP→PJ可能不適合速刪」一點,我也曾經表示需要bot處理,但我認為人手逐個處理亦非不可,情況如同enwiki曾經有過的X1,分別僅在於這變成永久措施,並禁止日後同類重新導向的建立。SANMOSA Σουέζ 2021年4月25日 (日) 08:25 (UTC)
@Xiplus:請求WP->WPJ的重新導向及WPJ->WP的重新導向的具體清單。另見上。SANMOSA Σουέζ 2021年4月30日 (五) 06:00 (UTC)
@Sanmosa列表於此,另您想讓我注意什麼?--Xiplus#Talk 2021年4月30日 (五) 06:10 (UTC)
@Xiplus:關於我對速刪WP->WPJ的重新導向的意見。當然我仍然希望有bot能協助清理連入(初步構思:[[WP:AA]]→[[WPJ:BB|WP:AA]]、[[WP:AA|自定義文字]]→[[WPJ:BB|自定義文字]])。SANMOSA Σουέζ 2021年4月30日 (五) 06:15 (UTC)
看起來無問題,不過我個人是覺得有大量連入的重定向就不應刪除,這樣也不需要去修正。--Xiplus#Talk 2021年4月30日 (五) 11:43 (UTC)
注意编辑摘要里也可能引用快捷方式(虽然专题页的引用量可能不会很大)。(▲)同上有大量链入的重定向不应删除-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年5月1日 (六) 05:49 (UTC)
此類提案應該不太可能涉及「有大量链入的重定向」,如有,請另表列出。SANMOSA Σουέζ 2021年5月1日 (六) 07:57 (UTC)
应该是没有-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年5月1日 (六) 09:19 (UTC)
178萬6641個頁面需要更新,占全部頁面27%,我認為修復重新導向是不明智的。--Xiplus#Talk 2021年5月1日 (六) 10:01 (UTC)
(:)回應有些是模板連入造成的,修改模板就可能可以大幅減少。—- 五歲抬☎️·☘️) 2021年5月1日 (六) 12:31 (UTC)
我本來也是以為是模板連入造成,但再次檢查後,其實不然,可靠地估計需編輯的頁面至少在156萬以上。--Xiplus#Talk 2021年5月1日 (六) 12:44 (UTC)
@Xiplus:我要求就每個捷徑分別排查連入數,並分別區分模板連入和非模板連入。我不相信大部分此類捷徑都能產生逾100萬的連入。SANMOSA Σουέζ 2021年5月4日 (二) 05:36 (UTC)
沒辦法透過查詢連入來知道是否透過模板產生的連入,自己用搜尋功能比較準。--Xiplus#Talk 2021年5月4日 (二) 07:52 (UTC)
@Xiplus:那能不能就每個捷徑分別給出連入數?我仍然覺得此類捷徑不可能每一個都能產生逾100萬的連入。SANMOSA Σουέζ 2021年5月6日 (四) 01:50 (UTC)
Special:PermaLink/65497881。--Xiplus#Talk 2021年5月6日 (四) 02:13 (UTC)
剛才用正規表達式insource:/\[\[:?WP:MEA\|?/精準匹配結果也至少是130萬 截圖 因為正則會跑很久[1],但相信這只是特定專題這樣而已,大部分的專題連入應該都很少,有的專題甚至無連入。-- 五歲抬☎️·☘️) 2021年5月4日 (二) 06:14 (UTC)
保留這個吧,這個是{{Welcome}}/{{Welcomeip}}的連結之一,當然非常常見。提議加個豁免條款,截至通過日,除本身多於一萬直接連入的常用捷徑豁免快速刪除外其他都機械人修正唄。--LuciferianThomas留言 2021年5月4日 (二) 07:17 (UTC)
这应该要保留,不仅是大量链入,还会导致修改大量用户的讨论页 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年5月4日 (二) 10:56 (UTC)
我維持我的提案(快速刪除從Wikipedia指向WikiProject的重新導向,並由bot協助清理連入),但可以容許WP:專題/首頁的缺失條目WP:MEA這兩個例外(只有這兩個產生了逾150萬的連入,其餘都少於10萬,而且大部分估計是模板連入,即使假設全部為非模板連入也不會構成太大的工作量),但也就只有這兩個能例外,而且也不便明文規定,因此會走Liangent G15的路綫,只在模組進行限制。@A2569875XiplusSANMOSA Σουέζ 2021年5月6日 (四) 09:27 (UTC)
Module:Template:Delete/data模組的對應修改見User:Sanmosa/R2模組,已在2021年5月6日 (四) 09:33 (UTC)更新。有勞Xiplus檢查對應修改的代碼是否正常。SANMOSA Σουέζ 2021年5月6日 (四) 09:33 (UTC)

重行公示7日。SANMOSA Σουέζ 2021年5月14日 (五) 13:12 (UTC)


本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
@羊羊32521LuciferianThomas:不知道能不能找到人寫bot。不然我們也可以先根據之前就每個WP=>WPJ的捷徑分別的連入數排查出來的結果手動進行“先消除連入、後提R2”的工作,但可能會涉及模板連結跟EPWPJ=>WP的捷徑應該比較容易處理,可以不用bot。SANMOSA Σουέζ 2021年5月22日 (六) 02:46 (UTC)
我可能可以寫,但沒時間跑Bot (這一看就知道要跑很久)。 所以到時如果真沒人寫,我可以提供代碼,然後再請有時間的維基人幫忙跑bot。-- 五歲抬☎️·☘️) 2021年5月22日 (六) 03:03 (UTC)
最近現實發生一些狀況,暫無法開發Bot。@Sanmosa:,User:LuciferianThomas好像有意願接手?Wikipedia:机器用户/申请#User:LuciferianBot。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️) 2021年6月10日 (四) 11:41 (UTC)
已留意。我支持他這樣做。SANMOSA Σουέζ 2021年6月10日 (四) 14:15 (UTC)
@A2569875:可能可以先寫代碼。我已經處理好所有WPJ=>WP的捷徑了,至於WP=>WPJ的捷徑我打算先手動處理連入數少的那些,讓它們先走快速刪除程序。(話説bot是怎樣跑的,我不太清楚相關事宜,所以想學一下,之後或許能幫到一些忙)SANMOSA Σουέζ 2021年5月25日 (二) 02:22 (UTC)
Special:PermaLink/65497881更新為Special:PermaLink/65827060SANMOSA Σουέζ 2021年5月28日 (五) 07:04 (UTC)
Draft:WP-WPJ重新導向連入數量。--Xiplus#Talk 2021年6月1日 (二) 13:31 (UTC)
@Xiplus:完全沒有0連入的數據?SANMOSA Σουέζ 2021年6月1日 (二) 14:56 (UTC)
是,此列表是讓你們清理連入的,所以應該沒必要列出?--Xiplus#Talk 2021年6月2日 (三) 01:55 (UTC)
有必要列出,清理完連入還要R2速刪,0連入的重新導向的處理工作最少(但有時候檢查連入時還是會發現還有一些連入和引用)。SANMOSA Σουέζ 2021年6月2日 (三) 15:04 (UTC)
@Xiplus:實測過一下,在Module:Template:Delete/data下,只有在WP:MEA挂R2才能顯示警告字句,WP:专题/首页的缺失条目顯示不到,不知道是怎麽一回事。SANMOSA Σουέζ 2021年6月1日 (二) 13:26 (UTC)
沒看到編輯紀錄,你怎麼測的?--Xiplus#Talk 2021年6月2日 (三) 02:30 (UTC)
@Xiplus:頁面預覽功能。現在沒事了,我查了一下Mediawiki,發現我不應該用rootText,而應該用text。SANMOSA Σουέζ 2021年6月2日 (三) 15:00 (UTC)
@XiplusA2569875:話説WPBannerMeta的模板應該有隱藏的“Wikipedia:”開首專題連結,不知道是怎麽一回事,有空要fix一下。SANMOSA Σουέζ 2021年6月10日 (四) 14:15 (UTC)

参考資料

  1. ^ 圖床連結站内存档)。此正則會匹配連結到WP:MEA的內部連結或管道|連結。※註:由於/:?/有爾會導致搜索功能錯誤,因此以/:*/替代;由於/\|?/有爾會導致搜索功能錯誤,因此以/[\|\]]/替代。

第六階段:其他議題討論

各階段不得同時討論,前一項討論完結之後,才能進行下一段討論。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月14日 (日) 09:41 (UTC)

  • 以下暫時備註
  1. 方針或指引修訂(一點五階段已修改部分,如有未盡之事宜請在此提出)
    Wikipedia:互助客栈/方针#第一點五階段:內容事實修訂
    Wikipedia:互助客栈/方针#修订CSD#G14
  2. 專題主頁與專題委員會存放處
  3. WP空間中的專題介紹、Help的專題說明
  4. 專題指引存放處
  5. 未調整好的模板或模組
  6. 這幾個月的使用反饋
  7. 其他未盡之事項
-- 五歲抬☎️·☘️) 2021年5月8日 (六) 19:25 (UTC)

本章節暫時不存檔,直到部署完成。欲讓機器人存檔,請移除本模板。留言請置於本模板上方。

WP:捷徑指引草案修訂

[編輯此導航模板]

說明

捷徑指引草案的討論,源自於「偽命名空間」的討論,英語維基百科對於捷徑相關的規範及偽命名空間的設立已有成熟的執行方式。中文維基百科中的部分編輯者對於「格式手冊」、「長期破壞者」及「專題」這三個主題提出可升級成命名空間或以偽命名空間形式存在,並有正反兩方的陳述與看法。

目前較為接近共識的是「專題」提升為正式命名空間,反對者的論述已由支持者回應,且反方無進一步論述。然為求慎重,且將捷徑與命名空間等議題作系統性討論,將會執行階段修訂,以取得最大共識。

本討論的各階段分為:

  1. 專題提升為命名空間與否及其細節phab:T271612);
  2. 格式手冊及長期破壞者是否成為命名空間或偽命名空間
  3. 偽命名空間規範寫入捷徑規範內(如前項通過)或是否允許偽命名空間(如前項不通過)
  4. 捷徑規範細部討論並決定是否成為指引。

各階段不得同時討論,前一項討論完結之後,才能進行下一段討論。臺灣杉在此發言 (會客室) 2020年12月10日 (四) 05:47 (UTC)

專題命名空間通過,剩餘細節獨立討論。臺灣杉在此發言 (會客室) 2021年1月11日 (一) 11:20 (UTC)
偽命名空間和專題空間都設立了。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年3月3日 (三) 05:21 (UTC)
  • 說明剩下的第四點,有部分項目正在等待專題、格式手冊、LTA等命名空間的相關議題之討論或公示。-- 五歲抬☎️·☘️) 2021年4月21日 (三) 02:51 (UTC)
  • 說明專題、格式手冊、LTA等命名空間的相關議題之討論或公示已完成(部分已存檔)。本案將繼續進行。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️) 2021年6月17日 (四) 04:04 (UTC)

專題命名空間問題

格式手冊及長期破壞者命名空間問題

已通過:
已通過,並完成主要設定。-- 五歲抬☎️·☘️) 2021年3月24日 (三) 05:55 (UTC)
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

已移動至偽命名空間臺灣杉在此發言 (會客室) 2021年2月1日 (一) 03:47 (UTC)


完成:設定完畢,有問題請在此提出。-- 五歲抬☎️·☘️) 2021年3月24日 (三) 05:55 (UTC)

本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

捷徑細部修訂

本案進入倒數第二個部分,捷徑細節修訂。目前偽命名空間部分已成為指引,其餘部分仍須修訂。

在上次討論當中,有提及中文捷徑等相關問題,歡迎進一步討論。臺灣杉在此發言 (會客室) 2021年1月31日 (日) 07:42 (UTC)

首段建議附加維基專題空間,他們會稍後設立捷徑。--LuciferianThomas留言 2021年2月6日 (六) 04:03 (UTC)
(:)回應Wikipedia:互助客栈/方针#第五階段:討論重新導向與捷徑的設立方式討論已開始。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月14日 (日) 09:51 (UTC)
@Taiwania Justo?--LuciferianThomas留言 2021年2月21日 (日) 00:13 (UTC)
目前在忙著RFC以及其他現實生活事務,且目前還有殘餘議案等待處理,待完全告一段落後再行整理該案。--臺灣杉在此發言 (會客室) 2021年2月21日 (日) 03:46 (UTC)
不急,因為#第五階段:討論重新導向與捷徑的設立方式也還在討論。-- 五歲抬☎️·☘️) 2021年3月17日 (三) 06:43 (UTC)
上述第五階段將會在適當的時機公示。-- 五歲抬☎️·☘️) 2021年3月31日 (三) 06:50 (UTC)
上述第五階段曾於2021年4月14日 (三) 03:45 (UTC) 進入公示階段。-- 五歲抬☎️·☘️) 2021年5月4日 (二) 06:46 (UTC)
說明由於目前有些其他意見,第五階段公示暫停。-- 五歲抬☎️·☘️) 2021年5月13日 (四) 04:33 (UTC)
上方第五階段已恢復公示-- 五歲抬☎️·☘️) 2021年5月20日 (四) 06:22 (UTC)
上方第五階段已公示通過-- 五歲抬☎️·☘️) 2021年5月27日 (四) 09:36 (UTC)
說明上方第五階段已進行到技術階段Wikipedia:機器用戶/申請#User:LuciferianBot,偽命名空間亦同(半保護案視為無共識或否決),因此方針修訂的部分皆已完成。本討論可繼續進行了。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️) 2021年6月10日 (四) 11:43 (UTC)
(?)疑問@Taiwania Justo:上述殘餘議案之處理已接近尾聲,請問閣下近期有空整理此案嗎?-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️) 2021年6月2日 (三) 14:51 (UTC)
正在整理中。--臺灣杉在此發言 (會客室) 2021年6月4日 (五) 04:37 (UTC)

捷徑指引修正

依據前次討論所收集的意見,已在「捷徑的命名」段修改成可在字尾使用中文簡寫。然而其中文字上限多少字仍沒有規定,請討論。臺灣杉在此發言 (會客室) 2021年6月25日 (五) 05:23 (UTC)

以上。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年6月30日 (三) 05:51 (UTC)
(+)不反對,所以WP:貴賓室WP:VIP)可以咯 --路西法人留言 2021年7月7日 (三) 13:59 (UTC)
這兩種都可以,不過我認為字數硬上限還是要存在,主要理由就是捷徑太多字是否還能稱作捷徑?不無疑問。--臺灣杉在此發言 (會客室) 2021年7月9日 (五) 11:43 (UTC)
@Taiwania Justo:如果定死字数硬上限可能会被指责是“拍脑袋想出来的” 囧rz……-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年7月25日 (日) 14:43 (UTC)
那首先現存最長的捷徑有多少個字?(中文、英文、中英混雜分開處理)然後我們再根據現時的情況立標準就好。順帶一提:我請求把WP:貴賓室恢復了,但還是想請各位到那邊發表一下意見。SANMOSA Σουέζ 2021年8月3日 (二) 07:26 (UTC)
「捷径尽量不能有成为新的项目页的潜力」其實也沒差吧,任何維基人都可以把重定向頁改為獨立頁面。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️) 2021年7月16日 (五) 15:18 (UTC)
但是这样还要改链入-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年7月20日 (二) 07:49 (UTC)
(+)支持-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️) 2021年8月2日 (一) 15:25 (UTC)
加個「建議加入{{Shortcut description}}({{Shcd}})以解釋英文捷徑的意義(尤其為縮寫的就更需要)。--路西法人留言 2021年8月4日 (三) 03:03 (UTC)

再次推动破坏者(LTA)成为名字空间

首批伪名字空间已行月余,我希望推动LTA成为真·名字空间。好处是可以设置所有页面为NOINDEX,增设页面查看权限(体现WP:RBI),且不会被其他名字空间的设置档左右。此外,LTA与Project空间联系性不大,没有维护问题。

至于LTA页面数量少。窃以為設立名字空间没有页面数量门槛。另附先前讨论之部分内容:

以上。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月24日 (六) 14:35 (UTC)

隨著討論發展,由於確有如此需求,我不反對設LTA為真命名空間。SANMOSA Σουέζ 2021年4月25日 (日) 08:34 (UTC)
(1) wgNamespacesToBeSearchedDefault本來就預設條目空間,Wikipedia空間本來就不在列,等於LTA頁面目前就是預設關閉的,增設命名空間沒有改變現狀。 (2) 目前所有LTA頁面都透過NOINDEX魔術字來指示爬蟲不索引了,增設命名空間沒有改變現狀。 (3) 可能是好主意,但沒有有效的技術手段達成(安裝擴充功能無望,CSS相當容易繞過...等)--Xiplus#Talk 2021年4月25日 (日) 09:48 (UTC)
基於WP:BEANS,應該還是要隱藏一下(((-- Sunny00217  2021年4月25日 (日) 11:44 (UTC)
如果僅用CSS,不需增設命名空間也能達到,這樣上方所列的三個需求都不需要增設命名空間了。--Xiplus#Talk 2021年4月26日 (一) 09:21 (UTC)
會搜到重新導向頁面?SANMOSA Σουέζ 2021年4月30日 (五) 06:03 (UTC)
實際上也只有那一個例子,整體來說,重新導向應是全部都不索引的。--Xiplus#Talk 2021年5月5日 (三) 01:41 (UTC)
Sanmosa意見,如現在確實有此需求,不反對設立,反正設這個沒有WPJ那麼亂XD--LuciferianThomas留言 2021年4月26日 (一) 09:12 (UTC)
@LuciferianThomas:WPJ麻煩的是移動和模板模組處理而已,吧?-- Sunny00217  2021年4月26日 (一) 09:47 (UTC)
第三点同Xiplus。要真正实现仅特定用户组可查看,只能通过后端。在判断逻辑甚至页面内容都已经发给前端情况下…是在掩耳盗铃。--安忆Talk 2021年4月27日 (二) 11:44 (UTC)
如果目的在避免普通访客被记载方式干扰和误导,而非保密性,掩耳盗铃未尝不可。类似,具有权限要求的某些内容(如已删除版本)或功能(如回退),并不限制其他用户用别的手段做到。--YFdyh000留言) 2021年4月28日 (三) 09:56 (UTC)
只要求在表面上看不见全放在前端当然没什么问题。(另,回退不要后端鉴权吗?)--安忆Talk 2021年4月28日 (三) 12:40 (UTC)
js可以實現與回退效果幾乎等價的操作。—- 五歲抬☎️·☘️) 2021年4月28日 (三) 13:05 (UTC)
加個class?--LuciferianThomas留言 2021年4月28日 (三) 22:45 (UTC)
是可以透過LUA寫腳本讓後端不要輸出頁面內容,前端在用JS判斷權限後,再向後台要原始碼以AJAX填入內容。這樣是可以在「使用者檢視頁面」的層面達到權限控制之內容隱藏,但問題是,這個很好破解,任何人只要按下編輯就能從頁面原始碼看到內容,即使頁面被保護了,原始碼也是能夠被所有人閱讀的....(而且想破內容的人只要研究前端發送AJAX的方式照樣能得到內容,即使LUA端寫了加密校驗碼也沒用,Module空間的資訊都是能公開檢視的.....mw:Extension:Lockdown擴展的第一行也有說,不保證其「不會被繞過」...)-- 五歲抬☎️·☘️) 2021年5月19日 (三) 14:12 (UTC)
如果擴展有希望,也許可以試看看。—- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️) 2021年7月7日 (三) 07:01 (UTC)
  • 如果是追求保密性的話,倒不如放在其他網站及僅容許某些人士瀏覽。使用css和js來避免被瀏覽,尤其是LTA,在個人來看就是自欺欺人。當然如果僅是用來避免普通訪客瀏覽,這不失是個好方法,但意義不大(真的會有普通訪客特地瀏覽LTA頁面嗎?)。--SCP-0000留言) 2021年4月30日 (五) 18:46 (UTC)
我補充一個意見:我認為不需設定LTA頁面的檢視權限,但這並不影響LTA空間的設立必要性。SANMOSA Σουέζ 2021年5月1日 (六) 01:41 (UTC)
可以试试看 如果说明是反破坏用的,维基媒体会不会启用? ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年5月4日 (二) 10:59 (UTC)
(?)疑問你是指新插件?—- 五歲抬☎️·☘️) 2021年5月4日 (二) 16:20 (UTC)
Green tickY mw:Extension:Lockdown-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年5月5日 (三) 11:18 (UTC)
请问您熟悉Phab站吗,能不能帮忙提一下?-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年5月12日 (三) 04:59 (UTC)
關於其社群,不熟。 我也只提供過一次程式碼,即專題空間而已。-- 五歲抬☎️·☘️) 2021年5月19日 (三) 13:38 (UTC)
有人可以協助評估一下可行性嗎?-- 五歲抬☎️·☘️) 2021年5月27日 (四) 09:31 (UTC)
說實話,我覺得可以像SCP2000君一樣,單獨開一個wiki(就像已刪百科)且只對回退員等有反破壞類權限的用戶開放,這從根本上防止了被繞過的問題。--What color are you, Sibyl System? |欢迎订阅维猫报! 2021年5月27日 (四) 12:14 (UTC)

有个疑问。假如LTA页面不对全体自动确认用户开放,而只对有更高权限的用户开放,那么,对于想要申请权限的用户怎么考查?之前有人拿LTA建立的条目来考核一个人的巡查员申请。会不会出现死循环的尴尬场景? --Milky·Defer 2021年5月29日 (六) 13:19 (UTC)

我想可以第一次申请都是临时授权,在第二次申请的时候进行这样的考核。--What color are you, Sibyl System? |欢迎订阅维猫报! 2021年5月30日 (日) 12:19 (UTC)
@羊羊32521wikt:en:AFAICS,據我所知-- Sunny00217  2021年6月6日 (日) 12:12 (UTC)
看起來好像是要我們去meta:Tech問問?然後,同時也要跑一遍mw:Writing_an_extension_for_deployment的流程?(我不太確定。)-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️) 2021年6月6日 (日) 14:44 (UTC)
顯然是要我們去諮詢「meta:Tech」,但是我對meta:Tech不熟,誰可以去幫忙問問?-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️) 2021年6月10日 (四) 14:31 (UTC)
@羊羊32521:—- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️) 2021年6月18日 (五) 11:42 (UTC)
已在meta提问。另,User:DreamerBlue在站外提醒:
也许我们应该先试看 能不能 在不启用扩展的情况下 设立名字空间?-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年6月19日 (六) 03:41 (UTC)
(~)補充:作者已入职WMF。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年6月19日 (六) 13:51 (UTC)
(?)疑問意思是,啟用的機會提高了?—- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️) 2021年6月27日 (日) 16:06 (UTC)
DreamerBlue君是担心说,不是基金会开发的,有坏掉的风险。后来他发现作者是WMF的,所以可能没有这层考虑了。启用应该还是要走下面提到的mw:Writing an extension for deployment#Preparing for deployment……(但是首先得有社区共识)-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年6月30日 (三) 05:35 (UTC)
或許可以公示看看?—- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️) 2021年7月14日 (三) 05:48 (UTC)
不啟用擴展就沒有設立命名空間的必要性。--Xiplus#Talk 2021年7月17日 (六) 13:23 (UTC)
@XiplusWikipedia:名字空间:“[项目]名字空间提供了有关维基百科的内容信息,包括维基百科自身的信息、方针指引论述,以及维基人的讨论空间‘互助客栈’、知识问答等。”个人感觉LTA与项目名字空间的联系不是很大(比如,并没有提供有关维基百科内容的信息),而更像是与User空间相似/相反的空间:一个是正常的用户,一个是来破坏的用户。-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年7月25日 (日) 14:52 (UTC)
維基百科的反破壞資訊,怎麼會跟維基百科本身運作沒有關係?--Xiplus#Talk 2021年7月25日 (日) 15:20 (UTC)
我个人理解这里说的是“维基百科本身”。如果说LTA是“维基百科的反破坏信息”,那专题、主题也可以说是“维基百科编写/条目有关信息”,Help可以说是“维基百科的帮助信息”吧……-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年7月25日 (日) 16:00 (UTC)
專題也是從WP空間拆出去的,WP空間內也有很多幫助資訊,它們都有各自被拆分的原因,如果您想要拆分,那就提出合適的理由,我上上句是總結我已反駁的最初3個理由,上一句是反駁您認為LTA無關於WP。--Xiplus#Talk 2021年7月25日 (日) 16:28 (UTC)
  • 相較諸位熱心站友,敝人對於命名空間和相關技術工程全然不懂,僅對於限縮LTA頁面閱覽權限,表達個人看法和考量如下:
1. 限縮有心參與的熱心用戶行動和參近權限、提高相關頁面近用門檻,除了不利於擴大一般使用者參與,亦恐不利於未來反破壞人員之養成。
2. 強化相關頁面之珍稀性,不無可能反倒強化LTA努力破壞之動力以達某種收錄標準(即便他們自己未必能看到內容)。
3. 什麼人能看?或者何人為何不能看?是否某種程度限縮對於LTA身分認定、詮釋、判讀之話語權?
4. 對於LTA之認知或判讀若成為一種特權,是否可能造成更多弊端?
5. 相關頁面之近用須具備特殊權限,其內容難受公眾閱覽公評。
6. 在只有少數用戶(比如可能握有特殊站務權限的人員)能便利認知或判定LTA身分的情況下,是否亦有可能容易造成LTA身分誤判,甚而相關頁面淪為社群鬥爭工具?
竊以為,持續保持現有頁面之近用和開放性即可,人人皆可閱覽(包括那些LTA們),然而可透過頁面內容編撰、積極利用,使頁面成為益於反破壞之一環。--Kriz Ju留言) 2021年7月27日 (二) 21:34 (UTC)
@Kriz Ju:如果下方 extended confirmed 用户组能通过,且限制阅览权限的功能可以部署,您觉得如果把阅览权限限制在 extended confirmed 用户组是否可行? ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月3日 (二) 14:18 (UTC)
個人覺得是值得嘗試用於反破壞和遏制LTA的措施(其他相關複雜討論恕暫未能考量),不過還煩請各位熱心站友之後能多多協助看不到相關頁面的新用戶,不論在他們面對LTA騷擾,或是被判定為LTA需要封禁申訴時。--Kriz Ju留言) 2021年8月3日 (二) 20:15 (UTC)

修订书籍关注度

第三项改为:该书曾经改编成在数个商业剧院中播放的电影、于任何国家或地区的网络电视或有线电视台播放的电视剧、网络平台播放的网络剧

这样改编为网剧的小说也有关注度了。比如同学两亿岁,目前有网剧条目却无小说条目。--Fire Ice 2021年6月28日 (一) 20:11 (UTC)

(+)支持--蟲蟲飛♡♡→♡℃留言 2021年6月28日 (一) 22:28 (UTC)
“任何國家”應改為“任何國家或地區”(“地區”的定義參照Wikipedia:关注度 (组织)#政府部門的註釋)。SANMOSA Σουέζ 2021年6月29日 (二) 01:55 (UTC)
我對此修改有保留,(-)傾向反對,首先「網絡平台播放的電視劇」是有語病,在網絡平台播放的不會稱為「電視劇」;另一方面,如果改為「網劇」,也沒有明確定義,在YouTube(「網絡平台」)上用戶自行上傳的低成本影片能不能稱之為「網劇」?--【和平至上】💬 2021年7月1日 (四) 11:38 (UTC)
其實說網劇在規格上和電視劇一樣吧,只是說是搬上網絡媒體播放,假如是‘低成本’,沒一個正式劇組,或是發行商,甚至說不是小說官方的改編,都很明顯不是正式的網劇,而只是一種民間自製的影片吧,這種東西也自然不能代表着原書籍的關注度。(平台反而不是重點,很多正式的網劇也選擇了在Youtube上發行) Iridium(IX)留言) 2021年7月1日 (四) 13:05 (UTC)
(-)傾向反對,除了上面两条,网络平台和网络电视如何定义也是个问题。看网络平台网络电视条目,放在网络上的任何质量的剧集可能都满足条件。 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月1日 (四) 14:35 (UTC)
网络电视應該是指把電視節目放進互聯網播放的一種方式吧,可能是說那節目本身就有著類近電視劇的規格?質量應該是有保證。還有网络平台就是網頁一個更fancy的名字,不明白還能如何定義? Iridium(IX)留言) 2021年7月1日 (四) 15:04 (UTC)
奇怪,用户自制影片当然算不得网剧,根据你维定义,网络剧(英语:web series),即在互联网或率先于互联网播放的剧集。网络剧的播放一般基于视频网站的支持。另外网剧质量当然可能很烂,我们谈的不是质量,而是关注度。Fire Ice 2021年7月2日 (五) 06:48 (UTC)
“用户自制影片”和“网剧”并不存在明显的分界线。“网络平台播放的网络剧”并不能保证该剧符合关注度,更无法保证该剧改编自的书籍符合关注度。建议加上“该电影、电视剧、网络剧需符合关注度”,个人认为这样只是为关注度提供一个方便判定的标准,不能算做违反关注度不能继承的准则。 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月2日 (五) 22:48 (UTC)
之所以有人认为电视台播放的电视剧有关注度,是因为它是有可信媒体背书的;而“网络剧”有的是平台发布,有的是用户制作,前者可能是可信媒体,而后者大部分情况不是。我觉得应该从发布者和制作者来区分。——落花有意12138 回复请ping我 2021年7月2日 (五) 10:35 (UTC)
不,你维并不认为电视台播放的电视剧就有关注度了,而改编成该电视剧的小说却有关注度。Fire Ice 2021年7月2日 (五) 14:03 (UTC)
WP:虚构准则 需同步修改。 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月2日 (五) 22:48 (UTC)

另外提案

我反而想提議刪除第五條,這一條明顯抵觸了WP:NRVE中關注度不能繼承的共識。-【和平至上】💬 2021年6月30日 (三) 18:30 (UTC)
(-)反对:WP:NRVEGNG通用關注度指引的一部分,與此案無關。不同專題關注度都有不同的要求,千萬不要把GNG通用關注度指引和其他十幾個的專題關注度指引混淆。--蟲蟲飛♡♡→♡℃留言 2021年7月1日 (四) 04:02 (UTC)
請這位管理員看清楚,WP:NRVE不是GNG的一部份,GNG是WP:N的第一部份,NRVE是第二部份。能說出「WP:NRVE是GNG」令我懷疑閣下究竟有沒有看過WP:NRVE。--【和平至上】💬 2021年7月1日 (四) 11:30 (UTC)
  • WP:N就是通用關注度指引,和其他專題關注度指引無關,請勿把專題關注度指引和通用關注度指引混淆,而且最早的關注度指引是BIO,而不是GNG(2007年才有)。--蟲蟲飛♡♡→♡℃留言 2021年7月1日 (四) 11:50 (UTC)
WP:N从逻辑和现有内容来看,应当包含WP:GNG和專題關注度指引。可以考虑建立 专题关注度 的二级标题,将其明确化,并检阅复审專題关注度和WP:N的冲突抵触。 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月1日 (四) 14:22 (UTC)
已經有了,見WP:GNGRL,而且WP:N第一段已經說了:「如果某一主題符合下述的通用關注度指引,那麼我們便可認為該主題的受關注程度滿足創立條目的要求。此外,如果某一主題符合任何一項專題關注度指引之標準,則其同樣可視為具備關注度。」其他專題關注度如BIO也有類似的敍述,但不能說其他專題關注度包含GNG的。--蟲蟲飛♡♡→♡℃留言 2021年7月1日 (四) 14:28 (UTC)
这跟你所说的“WP:N就是通用關注度指引,和其他專題關注度指引無關” 自相矛盾啊。。 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月1日 (四) 14:42 (UTC)
沒有矛盾,因為WP:GNGRL本來是沒有的,因為本站的用戶沒有習慣通讀方針指引,而且同一個方針指引也沒耐性讀完,很多用戶不太瞭解方針,才有人在WP:N加了WP:GNGRL。--蟲蟲飛♡♡→♡℃留言 2021年7月1日 (四) 14:46 (UTC)
(~)補充:《通用關注度》不是唯一的收錄標準,也不應以《通用關注度》的觀念及概念去理解不同主題的關注度指引。維基收錄標準有:通用關注度、書籍、人物、地理特徵、數字、幾何圖形、發明研究、物質性質表、交通、組識與公司,這十多把尺子是同等的,條目只要符合其中一個標準就可以收錄。例如,根據地理特徵收錄標準WP:NGEO,一個地方只要有人住,就可以收錄,而無須符合《通用關注度》;《通用關注度》以外的十多個收錄標準並非要對相關的主題增加額外的要求,而是這十多個收錄標準都是獨立和同等的。--蟲蟲飛♡♡→♡℃留言 2021年7月1日 (四) 15:37 (UTC)
只有「通用關注度指引」一節的內容才是通用關注度指引,我以為這是常識。否則,難道WP:NNCWP:FAILN也不適用於其他專題關注度指引嗎?另外,我不知道你為甚麼要將你的發言裏的GNG改為通用關注度指引,因為兩者完全等義。--【和平至上】💬 2021年7月3日 (六) 16:01 (UTC)
有些用戶確實只看通用關注度指引,但作為巡查員,您應該所有專題關注度指引也要看一下。此外,WP:NNCWP:FAILN也是後來才加進通用關注度指引,前者是內容方針的簡介,後者其實是刪除方針的撮要,這兩段只是方便用戶瞭解一下還有其他方針要注意,而且不能只看這兩個章節,詳情要看可供查證、刪除、非原創等方針。此外,GNG 只是一個通用關注度指引的一個章節捷徑,方便使用者引用,因為大家都習慣了,我才用GNG來表述。而且要注意,您不能在一個指引去約束另一個指引,每個指引都是獨立的。WP:NNCWP:FAILN只能約束GNG,不能約束專題關注度指引,但WP:NNCWP:FAILN的原方針,如可供查證、刪除、非原創等方針則適用於所有專題關注度指引。--蟲蟲飛♡♡→♡℃留言 2021年7月3日 (六) 16:18 (UTC)
我的理解:WP:N≠《通用關注度》,WP:NWP:GNG和“专题关注度指引”组成,WP:N包含WP:NRVEWP:NNCWP:FAILN等内容。 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月4日 (日) 02:00 (UTC)
WP:N是《通用關注度》,就是有人加了這兩個章節,才有這個誤解。WP:NNCWP:FAILN,前者是內容方針的簡介,後者其實是刪除方針的撮要,而且不能只看這兩個章節,詳情要看可供查證、刪除、非原創等方針。WP:N不包含“专题关注度指引”,例如學者關主度指引,您在WP:N哪裏看到有論文引用量來證明關注度?而且英維的學者關主度指引已經明確說了由於GNG的限制,無法有效證明學者的關注度,才有學者關注度的出現。此外,BIO在2004年已經有了, WP:N要2007年才有,一個後出的 WP:N怎麼會包含之前和之後所有專題關注度指引,而且各關注度指引的收錄條件完全不同,GNG是方便,但不能只看GNG。WP:N是有很多章節,但都只是與GNG有關;學者關注度、BIO等也有不同章節,但也與其他關注度指引無關,您也不能用一個指引去約束另一個指引。--蟲蟲飛♡♡→♡℃留言 2021年7月4日 (日) 02:38 (UTC)
WP:N不是《通用關注度》!WP:N不是《通用關注度》!WP:N不是《通用關注度》!請容許我強調這點,並且不要再曲解指引!WP:N的引言已經明言「如果某一主題符合下述的通用關注度指引,那麼我們便可認為該主題的受關注程度滿足創立條目的要求。此外,如果某一主題符合任何一項專題關注度指引之標準,則其同樣可視為具備關注度。」,而且刪除方針根本就沒有講過關注度不足的處理方式,何來「WP:FAILN是刪除方針的撮要」,除了WP:N之外根本就沒有其他的方針或者指引頁面有講過關注度不足的處理方式,你的意思是不是以「專題關注度指引」為準的條目全部都不適用於這個刪除流程?我懇請你不要再亂解釋方針!否則我真的要質疑你作為管理員解釋方針及指引的能力。--【和平至上】💬 2021年7月8日 (四) 18:33 (UTC)
  • 首先,請您先保持基本的文明和禮儀,而且討論時不要太激動,刪除方針的刪除原因第七條已經明確說了關注度不足的的處理方法:“徹底嘗試後仍無法由可靠來源查證的條目,尤其是不符合任何關注度指引(《通用關注度指引》或者其它專題關注度指引),且已經掛相應模板30天的條目”,而且其他段落也已經詳述了處理方法,雖然用語不完全一樣。此外,WP:FAILN是後期才加進通用關注度指引的,英維那邊就沒WP:FAILN。--蟲蟲飛♡♡→♡℃留言 2021年7月8日 (四) 23:34 (UTC)
    你自己看一看WP:GNG到底是連到WP:N全文還是只有其中一節。WP:N的標題是「維基百科:關注度」,而且刪除方針也沒有寫要提報到WP:NP;那我想問問你,WP:NNC的內容是不是不適用於以「專題關注度指引」為準的條目?我不明白你到底在堅持寫甚麼,WP:N裏除了WP:GNG一節之外適用於所有條目,好嗎?難道以WP:NGEO的關注度就可以無限延伸?我希望找其他管理員解釋這一個本來應該是常識的爭論。--【和平至上】💬 2021年7月14日 (三) 11:30 (UTC)
  • 我覺得WP:NNC是廢話,可以刪去,因為條目內容怎樣寫不應看WP:NNC,而是看格式指引,因為WP:NNC裏就加了一個格式指引的連結,所以真正限制不同專題關注度指引的是格式指引、可供查證、非原創研究等方針,而不是通用關注度指引裏的一個小章節WP:NNC。此外,您的想法就像等於說WP:NBIOWP:BIO,但其實都是人物關注度指引的不同章節。--蟲蟲飛♡♡→♡℃留言 2021年7月14日 (三) 11:39 (UTC)
(+)支持 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月2日 (五) 22:48 (UTC)

新提议

第三项改为:该书已改编为电影、电视剧、网络剧,相应电影、电视剧、网络剧有关注度。

很好地解决了对改编剧集放映于质量较低的播放平台的疑虑,但是变相调高了书籍关注度的门槛,因此还需更多讨论。Fire Ice 2021年7月3日 (六) 15:56 (UTC)

其實我有一個疑問,為甚麼我們要假定相應電影、電視劇、網絡劇條目有關注度就代表原作具有關注度?如果一本書籍的條目裏面只有改編作品的內容有二手可靠來源支持(否則便可以直接使用GNG),而改編作品本身已經有另一個條目,那麼這個原作書籍的條目的存在意義是甚麼?--【和平至上】💬 2021年7月3日 (六) 16:10 (UTC)
介绍原作的角色和剧情。原作的人设和情节可能和改编作品不一样。Fire Ice 2021年7月4日 (日) 16:55 (UTC)
關注度指引的意義是尋求一個證明主題有關注度的證據,書籍當然要有關注度才有人去改編電影或電視劇,這可能比GNG更能證明關注度。--蟲蟲飛♡♡→♡℃留言 2021年7月3日 (六) 16:23 (UTC)
個人認為重點根本不是在書籍引申出來作品的關注度,它引申出來作品關注度如何,也不關原本書籍的關注度事。最重要的是有機構願意把這書籍改編成 電影,電視劇,網絡劇 等需要極大投入的作品,就證明了原本書籍一定有一定關注度而令到改編它的決定是可取的。這便是我強調引申出來作品的質素的原因,因為這樣才能保證當初引申作品的製作時的投入和嚴謹度,反向證明當初原書籍的關注度。不然的話像民間影片這些製作門槛那麼低的東西可不證明當初書籍是有關注度,而可能只是有個別小眾狂熱粉絲也能去改編吧。 Iridium(IX)留言) 2021年7月4日 (日) 04:01 (UTC)
(!)意見:仔細想了一下,建議刪去「條目有關注度」,因為有關注度,不一定有條目。--蟲蟲飛♡♡→♡℃留言 2021年7月4日 (日) 04:10 (UTC)
根據WP:7days,提案公示七天。--蟲蟲飛♡♡→♡℃留言 2021年7月17日 (六) 04:39 (UTC)
考慮到未有人有效回應SIridiuM28的意見,暫時撤回公示。--蟲蟲飛♡♡→♡℃留言 2021年7月19日 (一) 04:42 (UTC)
“SIridiuM28的意見”是什么?Fire Ice 2021年7月26日 (一) 14:16 (UTC)
  • 他意思是後面那個“有關注度”的修飾語可以刪去,因為與主體書籍的關注度無關,我覺得也有道理。--蟲蟲飛♡♡→♡℃留言 2021年7月26日 (一) 15:07 (UTC)
他的意思是要有其他限定,但没提出“其他限定”是什么,并无建设性意义。Fire Ice 2021年7月26日 (一) 15:18 (UTC)
  • 我覺得可以先刪去“有關注度”修飾語,其他未具體提出意見的可以不處理,然後我覺得算已經處理了他的意見。--蟲蟲飛♡♡→♡℃留言 2021年7月27日 (二) 00:31 (UTC)
把限定都删了,那等于没有限定,怎么能算已经处理了他的意见呢?何况“有关注度”这一限定十分合理也易于检查,还是拉过来我们再讨论下吧。Fire Ice 2021年7月27日 (二) 09:30 (UTC)
或者还是原提议,我没看出原提议有什么不合理的。Fire Ice 2021年7月27日 (二) 09:36 (UTC)

Wikipedia:格式手册#地区用词的格式(指引)

像其他标题一样,用两个等号来造这个外部链接的标题(参阅上面的“标题的格式”)。

這個「造」是什麼意思?製造?生產?Manufacture?只有我覺得不合華文語法、慣例嗎?還有「這個外部連結的標題」指外部連結章節的標題,是否有些太口語化了?

現行條文

⋯⋯但是在大多数情况,这些地址放到条目最底如此的一个标题下会更清楚:

  • == 外部链接 ==

像其他标题一样,用两个等号来造这个外部链接的标题(参的“标题的格式”)。

提議條文

⋯⋯但是在大多數情況,這些網址置於條目底部如此的一個標題下會更清楚:

  • == 外部連結 ==

像其他標題一樣,用兩個等號撰寫外部連結的標題(參的“標題的格式”)。

或者:

  • 用兩個等號編寫外部連結的標題
  • 用兩個等號產生外部連結的標題
  • 用兩個等號製造外部連結的標題
  • 用兩個等號標示外部連結的標題

謝謝! — XComhghall留言) 2021年7月17日 (六) 07:30 (UTC)

產生。--Xiplus#Talk 2021年7月19日 (一) 13:04 (UTC)
这个字并不会产生歧义,仅仅是读起来不顺口而已,因此没有问题需要修改——落花有意12138 回复请ping我 2021年7月23日 (五) 12:44 (UTC)
不顺口本身就是个问题。晦涩难懂的条文会让人不想去读。写出来的东西是给别人看的,需要考虑他人的感受。--Milky·Defer 2021年7月25日 (日) 13:34 (UTC)
@MilkyDefer:有道理。(&)建議改为“造出”。因为“产生”“制造”“标记”“得到”等都说的过去,为避免不必要的纷争,按原字扩充。这句话在Wikipedia:格式手册#因特网及地址的格式而不是#地区用词的格式。这个字在该页面的最初版本就是这样——落花有意12138 回复请ping我 2021年7月27日 (二) 09:43 (UTC)
同意XComhghall的說法「撰寫」,使用此詞會使說明專業化,其他說法真的不太像「格式手冊」會寫出來的東西,沒有語感和專業度。Bus Follower留言) 2021年7月28日 (三) 08:31 (UTC)

关于wp:srcu的讨论

wp:SRCU要求查核用户的请求必须在本地被讨论通过后才能转向元wiki,若管理员自己滥用傀儡怎么办?他或可互相直接驳回对自己的查核请求。--祝编安|pavlov2留言) 2021年7月17日 (六) 17:11 (UTC)

类似于“管理员滥权封禁怎么办”“管理员知‘法’犯‘法’怎么办”一样,这种问题在原则上是由管理员之间的相互制衡、相互制约来规避的。--Antigng留言) 2021年7月18日 (日) 15:22 (UTC)
反驳,见最近wp:ANM的争论,管理员滥权封禁和解封已经导致了两起矛盾了.--祝编安|pavlov2留言) 2021年7月18日 (日) 15:32 (UTC)
此外,为何不准许用户自行前往元WIKI提报可疑案例?元WIKI收回查核权不正是因为有人滥权吗?--祝编安|pavlov2留言) 2021年7月18日 (日) 15:34 (UTC)
(?)異議,法治非人治,如果不能把权力关进制度的笼子里,企图靠人和人互相制衡,如何评判这一体系是否有效?--祝编安|pavlov2留言) 2021年7月18日 (日) 15:37 (UTC)
@Pavlov2:贊同。元 Wiki 既已收回查核權,管理員再保留駁回、否決任何查核請求的權力,不是實際上、變相擁有甚至超過用戶查核員,及在用戶查核方面,超過元 Wiki,的權限嗎?
但是我看了下,
  1. Wikipedia: 元維基使用者查核請求不是方針或指引,不適合在 Wikipedia: 互助客棧/方針討論。
  2. 「不准許用戶自行前往元WIKI提報可疑案例」、要求先在本地討論,不是華文 Wikipedia 方針或指引的規定,是元維基監管員的要求。「監管員一般不會理會未經本地社群討論通過而直接發布到元維基上的請求」(Wikipedia: 用戶查核)。
  3. 既然是討論,管理員沒有「直接駁回對自己的查核請求」的權力。
謝謝。祝 早日康復! — XComhghall留言) 2021年7月18日 (日) 17:02 (UTC)
(-)反对,讨论中管理员可直接duck掉与自己可能相关的提报,是为一种变相驳回。--祝编安|pavlov2留言) 2021年7月18日 (日) 17:31 (UTC)
如果多人有理地反对管理员的意见,那么管理员的拒绝是无效的。管理员向来不是绝对的裁判者,管理员执行着共识。--安忆Talk 2021年7月19日 (一) 02:36 (UTC)
反对,见wp:SRCU中的最新一次鸭子测试一望而知后取消,是user:shizhao发话认为不能简单DUCK才再次提报的,如果shizhao没来呢?是不是直接就ban了?--祝编安--pavlov2留言) 2021年7月19日 (一) 04:01 (UTC)
您也可以认为不能一望而知,这并不需要管理员,Wikipedia:何谓共识#共识不是什么。--安忆Talk 2021年7月19日 (一) 04:12 (UTC)
我认为重点是提报者应该把前因后果讲明白,而不是简单的一望而知或xxx傀儡就完了。这样的话,除非管理员非常了解提报者所说的问题,否则只能是看得一头雾水,不知道是怎么回事。其实这个问题不光是SRCU,其他地方的讨论或提报中也是经常发生,造成的后果就是如果熟悉此事的管理员没有处理的话,很大程度上就搁置了--百無一用是書生 () 2021年7月19日 (一) 06:13 (UTC)
Wikipedia:元維基用戶查核請求#Windy8786是Shizhao、我和30000Lightyears重启的,即使Shizhao没看到,我俩也会重启讨论。Itcfangye留言) 2021年7月22日 (四) 00:21 (UTC)
回退管理员行动/基金会行动或被误判为破坏,我不知道普通用户敢不敢重开讨论。--祝编安--pavlov2留言) 2021年7月25日 (日) 02:34 (UTC)
zhwiki至今暫時沒有針對任何人對SRCU的編輯動作進行過基金會行動。回退管理員的操作的合理性要視乎管理員操作時使用的權限到底是管理員專有的還是普通用戶都有的;如果是後者,那你把他當成普通用戶就好,有需要就可以回退或重開。SANMOSA Σουέζ 2021年7月28日 (三) 11:43 (UTC)
如果可以讓Steward信納有特殊狀況以致請求不能先在本地被討論通過的話,請求或許也能受理,但前提是你要先說服Steward。SANMOSA Σουέζ 2021年7月28日 (三) 11:43 (UTC)

關於歡迎新手列表簽名移除的活躍度門檻

因茲事體大,根據此處討論,在此詢問社群意見:是否對移除歡迎新手列表簽名設置活躍度門檻?若決定明文設置,期間多久為宜?我是覺得通知當事人最重要,這樣未來若當事人復出,才會知道要重新申請加入簽名。—— Eric Liu 創造は生命(留言留名學生會LEP 2021年7月26日 (一) 11:30 (UTC)

要求通知,我當然可以配合。我之前處理都是6個月0編輯就移除,這當然是參考其他權限的不活躍除權門檻;另有30天少於30編輯由機器人暫時停用簽名的設計,這個門檻也是我向機器人操作者建議的,其參考自其他權限的申請資格,這個較高的標準是考量本列表目的是讓新手可以找這些人發問,其活躍度要求當然不能低,相對來說,移除門檻是低非常多。以上先予以說明。--Xiplus#Talk 2021年7月26日 (一) 11:54 (UTC)
Xiplus如果能自動化作業,並予以適當通知,我認為六個月的門檻可行。—— Eric Liu 創造は生命(留言留名學生會 2021年8月4日 (三) 07:35 (UTC)

关于推动维基百科:不要诉诸法律威胁成为指引的提议

近日出现了多起就WIKI上的编辑将其他编者诉诸现实的法律进行威胁的事件。第一是WG在交流群的事件,于媒体有报道。第二是前不久不爱思考得猪对MINQI诉诸法律威胁。 对其他编者诉诸于现实的法律威胁会破坏其他编者参与WIKI的积极性,每次诉诸法律导致一系列的后发效应,亦会降低社群之互信,增大两岸三地社群因政见带来的矛盾和分歧。 在此提意将维基百科:不要诉诸法律威胁从论述上升为指引,期待能在将来减少这类恶性事件的发生。 --祝编安--pavlov2留言) 2021年7月26日 (一) 13:53 (UTC)

我覺得此提案可以雪球關閉並丟去元維基,因為法律威脅已經超過我們處理的範圍了-- Sunny00217  2021年7月27日 (二) 01:05 (UTC)
元WIKI也不太愿意处理这类棘手的问题,都棘手。--祝编安--pavlov2留言) 2021年7月27日 (二) 07:10 (UTC)
但元維基是還能處理,本地是完全沒權力也沒能力處理-- Sunny00217  2021年7月28日 (三) 02:35 (UTC)

(※)注意不是不爱思考得猪不是对本人诉诸法律威胁而是对Jg451阁下等大部分大陆维基人。--MINQI留言) 2021年7月27日 (二) 07:57 (UTC)

哥你把话捋清楚,我怎么读不明白了。--祝编安--pavlov2留言) 2021年7月27日 (二) 09:53 (UTC)
@Pavlov2:抱歉,笔误。其威胁恐吓直接对象不是本人,而是Jg451阁下;其间接恐吓对象为所有中国大陆维基人以及可能进入中国大陆、港澳地区的维基人。--MINQI留言) 2021年7月27日 (二) 10:33 (UTC)

(&)建議1.删除“但无论如何,我们要求您采取法律行动后,不要参与编辑工作,直至法律争议得到解决为止。”一句,如果出于法律,应当由法院提出请求,并由管理员禁止编辑。2.我注意到当前页面与英文维基百科的页面有着一定差距,是否需要补充内容。3.建议作为态度指引而不是法律指引,因为后者需要多名法律人士参与。4. 建议明确“威胁”的含义 5. 维基百科的中立性与法律需要明确优先级,当法院发出有效、合法且正式的通知,而对维基百科的中立造成影响时,应当以中立为重,还是以法律为重(比如“中华民国现在的有效统治领土为台湾地区”)(前提是4的讨论结果包括上述行为)——落花有意12138 回复请ping我 2021年7月27日 (二) 09:25 (UTC)

  • 支持1和2,另3可能不需要,按英維翻譯即可。4的話就(&)建議給社群管理層一點解釋空間(這原本是ARBCOM該做的),不需要修。5的話因為維基百科設於美國,應以當地法律為準。至於其他地方的法律應該對維基沒有約束力。--請多關注評選 2021年7月28日 (三) 06:06 (UTC)
提醒一下:英文版同等方针适用范围非常窄,只限制在英文维基百科张贴法律威胁,没有限制其他项目和IRC、Telegram等站外渠道,也没有限制Special:EmailUser。--GZWDer留言) 2021年7月31日 (六) 02:12 (UTC)

有關快速刪除方針O7條的事宜

有鑒於最近的一個存廢討論,建議容許快速刪除任何六個月內無編輯的模板、模組沙盒,並納入O7條處理。條文具體修改如下:

現行條文

O7. 廢棄草稿。

任何六個月內無編輯之草稿。
僅適用於草稿名字空間
如果編者有意重新繼續編寫,可向管理員請求恢復草稿
若是編輯僅是加入或刪除存廢、速刪模板及有關操作,該次編輯應視為無編輯。
  • 使用模板{{d|O7}}。
提議條文

O7. 廢棄的草稿、模板沙盒或模組沙盒。

任何六個月內無編輯的草稿、模板沙盒或模組沙盒。
  • 僅適用於草稿命名空間模板命名空間模組命名空間
  • 若相關編輯為機械人編輯或屬維護性操作,相關編輯應視同不存在。
  • “模板沙盒”、“模組沙盒”等詞在此指在頁面名稱最末端出現“/sandbox”、“/testcases”或“/沙盒”等表示某模板或模組的子頁面為沙盒的字樣的頁面。
  • 就模板沙盒與模組沙盒而言,在提請快速刪除前,請務必先檢查並清理相關頁面的連入。
  • Module:沙盒的子頁面而言,如該子頁面遵從“Module:沙盒/(用戶名)/???”的命名格式,則不適用。
如果編者有意重新繼續編寫,可向管理員請求恢復相關草稿、模板沙盒或模組沙盒
  • 使用模板{{d|O7}}。

以上。SANMOSA Σουέζ 2021年7月28日 (三) 11:50 (UTC)

@Z7504Willy1018Sunny00217SANMOSA Σουέζ 2021年7月28日 (三) 11:51 (UTC)
  • (-)反对,怎么判定是不是沙盒?这个算吗这个呢? ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年7月28日 (三) 12:35 (UTC)
    @羊羊32521:初步擬定的判別標準是:在排除Module:沙盒的子頁面的情況下,頁面名最末端有“/sandbox”或“/沙盒”字樣的判別為沙盒。Wikipedia:沙盒Module:沙盒會自動清理,所以不快速刪除;Wikipedia:沙盒的子頁面不位於模板、模組空間,所以不處理;Module:沙盒的部分子頁面是用戶因不能在用戶空間啓用Lua子頁面而產生的,應比照用戶頁,所以也不處理(這點的額外判別標準是頁面名稱是否遵從“Module:沙盒/(用戶名)”或“Module:沙盒/(用戶名)/???”的格式)。SANMOSA Σουέζ 2021年7月28日 (三) 13:56 (UTC)
(?)疑問:像這個User:某某/沙盒,刪不刪?「模板」,還是「模板沙盒」? --蟲蟲飛♡♡→♡℃留言 2021年7月28日 (三) 14:11 (UTC)
@蟲蟲飛:此提案只會讓O7擴大適用至模板命名空間與模組命名空間,而並未有擴大適用至用戶命名空間的情形,這點“僅適用於草稿命名空間、模板命名空間與模組命名空間”一句寫得非常清楚,因此所有“User:”開首的的頁面(包括你上面説的那個頁面)是不會經新O7刪走的。換一個方式說,“模板、模組沙盒”説的是“Template:???”或“Module:???”的以“/sandbox”或“/沙盒”字樣為名的子頁面。SANMOSA Σουέζ 2021年7月28日 (三) 14:17 (UTC)
您的標題「廢棄草稿或沙盒」不準確,應改為「廢棄草稿或模組沙盒、模板沙盒」,中間也要改為“任何六個月內無編輯的草稿或模板沙盒、模組沙盒。”--蟲蟲飛♡♡→♡℃留言 2021年7月28日 (三) 14:24 (UTC)
我不認為有人會因為條文標題的概括性而忽略對條文的細則進行理解。我在調整提案後已經對“模板、模組沙盒”進行定義,因此這裏“模板、模組沙盒”沒有歧義。大標題我還是調整一下,但我維持「模板、模組沙盒」的用詞。SANMOSA Σουέζ 2021年7月28日 (三) 14:29 (UTC)
有歧義,有人有機會理解為「模板」和「模組沙盒」,但「廢棄草稿或模組沙盒、模板沙盒」就沒有歧義,方針不能貪方便,寫得不好就有歧義。--蟲蟲飛♡♡→♡℃留言 2021年7月28日 (三) 14:34 (UTC)
在有特別指明某詞彙的定義的情況下,該詞彙在文本中的定義只有一個,繼而使該詞彙在文本中無歧義。SANMOSA Σουέζ 2021年7月28日 (三) 23:41 (UTC)
  • 從另一角度說,假設您是想刪“模板”,而非“模板沙盒”,上面的句子您會怎樣表述?--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 00:17 (UTC)
    就不可能提速刪討論這個有意義嗎w-- Sunny00217  2021年7月29日 (四) 01:19 (UTC)
    之前我曾經提出過A5適用於模板的提案,所以也不至於不可能。SANMOSA Σουέζ 2021年7月29日 (四) 02:47 (UTC)
    這種情況下,“或”字應該放在最末兩個並列項之間,而不會放在現在的位置。或許這樣說:現在我的排列結構是“A或D”,“D”(這次的“D”包含頓號,但並列的對象共同修飾“沙盒”一詞)是作為一個整體與“A”並列的;如果“或”字放在最末兩個並列項之間,則排列結構會變成“A、B或C”,“B”與“C”是分別作為兩個獨立的整體與“A”並列的。SANMOSA Σουέζ 2021年7月29日 (四) 02:47 (UTC)
编辑冲突这样应该没什么问题,建议还是先检查一下目前符合条件的页面有没有被调用。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年7月28日 (三) 14:14 (UTC)
可以請求用戶提快速刪除前先檢查連入。SANMOSA Σουέζ 2021年7月28日 (三) 14:17 (UTC)
  • “若相關編輯僅是加入或刪除存廢、速刪模板及有關操作,該次編輯應視同不存在。”一句应当改为“若一笔编辑不是对页面内容的扩充、修正等对内容造成改变的善意非维护性非机器人编辑,则该次编辑在统计上文所称‘无编辑’时应当无视”。因为1.原陈述不包括破坏、回退破坏或机器人编辑等 2.“视同不存在”一词有歧义,可解释为在计算用户编辑时无视、计算总编辑数时无视等,即该词否定了该编辑的合法有效性。——落花有意12138 回复请ping我 2021年7月29日 (四) 00:09 (UTC)
    不同意落花有意12138在(2)部“否定了該編輯的合法有效性”的論調。“該次編輯應視同不存在”是在施行O7的情況下才會出現的特殊計算情況,而在無須施行O7的情況下該次編輯仍然是(視同)存在的。同意落花有意12138在(1)部的説法,已就(1)部再作調整。SANMOSA Σουέζ 2021年7月29日 (四) 03:02 (UTC)
没有什么“视同存在”,每一笔编辑都不应当被忽略,而这里的陈述可以被这样理解,便应当修改,避免有编者蓄意曲解方针(虽然这一解释可以被常识否定)——落花有意12138 回复请ping我 2021年7月29日 (四) 07:38 (UTC)
@落花有意12138:(前)我認為重要的不是用詞,而是背後的意義,只要實際上執行的效果是一樣的,那就沒有問題。(後)既然可以被常識否定,那就代表所謂的“問題”不成問題。蓄意曲解方針是游戲規則的行徑,我們不能助長。SANMOSA Σουέζ 2021年7月29日 (四) 08:21 (UTC)
@Sanmosa:1.这是一个不明显,但是容易被利用的漏洞。如果有用户利用这个漏洞,您打算如何处理?如果要搬出这个讨论串,说“方针的本意不是这样的”,那便容易被人说,是社群办事不力,使得方针有歧义。再说回来,“常识”本就模糊不清,每个人有自己的情况,造成常识的不同。 2. 您修改的版本中,“機械人編輯或屬維護性操作”依然不包括破坏。我认为这里不应该规定什么不适用,而应当规定什么适用。——落花有意12138 回复请ping我 2021年7月30日 (五) 07:33 (UTC)
(1)我思來想去,不認為這條會被人怎麽樣去利用。而且,方針指引的效力不在條文的文字上,而是在其產生時背後的討論共識,那既然在這個討論串大家是明白那句話的實際含義是甚麽的,那句話的含義就只能根據討論串中得出的含義來理解。其他人的評論本身並不會影響制定規則的程序本身的正當性。(2)此前並無任何類近的條文有類似的規定,我不認為社群能接受。另外,方針編寫上一般只會規範甚麽類型的編輯不適用,而不會規範只有甚麽類型的編輯適用。SANMOSA Σουέζ 2021年7月30日 (五) 08:39 (UTC)
(-)反对:「任何六個月內無編輯的草稿或模板、模組沙盒。」這句和正文中的「模板」有歧義,標題和正文的「模板」要改成「模板沙盒」。改了後通知一下,我可以撤回反對。--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 09:13 (UTC)
@羊羊32521Sunny00217落花有意12138:你們怎麽看?SANMOSA Σουέζ 2021年7月29日 (四) 09:36 (UTC)
一定會有用戶誤解方針,進行大量速刪,故一定要寫清楚「模板沙盒」,一定要寫死。如O7要速刪「模板」,消紅消緑是否維護性操作 ? 如是,大量模板都超過六個月無編輯。如有「模板」因此被速刪,Sanmosa是否要負相關責任呢 ?--約翰同志-條目裱糊匠留言) 2021年7月29日 (四) 11:34 (UTC)
@蟲蟲飛Comrade John:收到其他用戶的同類意見,已修改。SANMOSA Σουέζ 2021年7月29日 (四) 13:43 (UTC)
(-)反对,(1) 處理編輯請求時合併patch的編輯摘要包含了到沙盒固定版本的連結,若刪除將導致這些連結全部失效。 (2) 沙盒裡仍記載著有價值的舊版本,假設某人在沙盒測試了3個版本,最後第3個版本被合併了,卻在6個月後發現該版本有些bug,實際上第2版本才是正確的,若刪除將遺失這些資訊。 (3) 沙盒就是沙盒,跟Wikipedia:沙盒一樣,不相關的內容不理它/回退/清空/拿主頁面覆蓋就好,不需動用到刪除。 (4) 若是極端的濫用情況,不相關的測試我想目前就可以適用CSD G2刪除,不需要設立新準則。--Xiplus#Talk 2021年7月29日 (四) 12:14 (UTC)
如果某人認為G2不適用,請告訴我您的理由。--Xiplus#Talk 2021年7月29日 (四) 12:15 (UTC)
@Xiplus最一開始提出這東西的人Z7504,可能還是得他出來解話才是,我就只是一個看到一個東西,然後突發奇想提提案的人而已。SANMOSA Σουέζ 2021年7月29日 (四) 13:43 (UTC)
不過在他沒有回應的情況下,我可以做一些補充説明:(1、2)新條文有説明“如果編者有意重新繼續編寫,可向管理員請求恢復相關草稿、模板沙盒或模組沙盒”(連結連向WP:AR),而且在現在WP:AR的實務操作上,用戶可以直接找管理員讓他們直接恢復相關頁面,或為相關頁面提供歷史存檔,因此在“刪除”本身不是在MediaWiki系統直接永久刪除的情況下,連結失效或遺失資訊的問題並非如上述般嚴重。(3)這只能Z7504解話了。(4)除了G2,可能也可以G3,但如果把(3)的情況考慮在內,而Z7504的解話能讓人信服,那O7的擴大適用仍然是有必要的。SANMOSA Σουέζ 2021年7月29日 (四) 13:51 (UTC)
(1) AR無法解決固定連結失效的問題,刪除必定使連結失效。 (2) 除了前述狀況,對於一般想要了解歷史的人來說,刪除便是一個阻礙,雖然AR是一個緩解方案,但無疑造成了大家麻煩,無論是想要翻查歷史的人,或是處理刪除及AR的管理員。 (4) G2/G3都可以依情況適用至罕見狀況,我沒看到對於刪除沙盒的好處或是不刪除的壞處,廢棄沙盒只是一個狀態,廢棄本身應該不是一個問題,如果是,請說明。--Xiplus#Talk 2021年7月29日 (四) 14:03 (UTC)
(1)據我理解,一個頁面可以復原到與原名不同的名稱,因此只要AR時把該版本恢復了,那連結就不再失效(如果是直接把原頁面恢復,因為恢復時會連同所有歷史版本恢復,那恢復後連結就肯定不再失效)。(2)如果這樣説的話,那這種麻煩在Draft空間和條目命名空間是更為嚴重的。(4)那這可能也要等Z7504解話了。SANMOSA Σουέζ 2021年7月29日 (四) 14:45 (UTC)
AR恢复是新的版本 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年7月29日 (四) 15:00 (UTC)不是吗? ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年7月29日 (四) 15:04 (UTC)
標準AR的確是另建頁面,但管理員可以選擇直接恢復,再移動到其他名稱,我想Sanmosa說的應該是這種操作。--Xiplus#Talk 2021年7月29日 (四) 15:09 (UTC)
是的。SANMOSA Σουέζ 2021年7月30日 (五) 08:43 (UTC)
(1) 是這樣沒錯,那麼是不是應該把所有的沙盒都移動到AR下做為「沙盒存檔」? (2) 所以我才不想製造更多問題。--Xiplus#Talk 2021年7月29日 (四) 15:01 (UTC)
(1)這應該按需求解決,不能每一下子都說“所有的”。(2)不同意“製造更多問題”的説法,我認為就算你把這視為“問題”,頂多就只能說成“問題”仍然存在。SANMOSA Σουέζ 2021年7月30日 (五) 08:43 (UTC)
請您定義「需求」。-- Willy1018留言) 2021年7月30日 (五) 11:51 (UTC)
有人請求自然代表有需求。SANMOSA Σουέζ 2021年8月1日 (日) 01:37 (UTC)
最低的需求就是所有有在編輯摘要連結到的沙盒,但你要要求提刪前檢查有無從編輯摘要連入嗎?不可能吧。--Xiplus#Talk 2021年8月1日 (日) 12:06 (UTC)
雖然我是以「不應該刪除的理由」來反對該提案,但更重要的是「應該刪除的理由」,且目前缺乏這個理據來支持該提案。--Xiplus#Talk 2021年8月1日 (日) 12:23 (UTC)
補充:前次類似但包含範圍不完全的提案位於Wikipedia talk:快速删除方针/存档9#建議擴展快速删除方针O7的適用範圍,當時因為提出時間與O7初通過的時間相隔太短而未通過。如此提案亦未通過,請代為列入WP:常年提案SANMOSA Σουέζ 2021年8月2日 (一) 14:58 (UTC)
讓我想起更有力的反對理由了:testcases會引用sandbox,刪除sandbox將導致一堆testcases出錯。--Xiplus#Talk 2021年8月2日 (一) 15:13 (UTC)
可以在條文中指明「/sandbox」若被「/testcases」引用則不適用O7。另一方面,提案中也有“就模板沙盒與模組沙盒而言,在提請快速刪除前,請務必先檢查並清理相關頁面的連入”這樣的一句,意思是“檢查並清理相關頁面的連入”以後才能提O7。SANMOSA Σουέζ 2021年8月2日 (一) 23:57 (UTC)
同意前者,不同意後者,可能會有人為了刪除/sandbox而把/testcases清空之類的;另給個統計數據,模板空間中的所有/sandbox有57%被至少一個頁面引用,無法刪除。--Xiplus#Talk 2021年8月4日 (三) 05:24 (UTC)
不過就算規定前者,可能還是會有人去清理引用,不論是否惡意,刻意使頁面符合速刪後再來提起速刪的情況發生不少次。--Xiplus#Talk 2021年8月4日 (三) 05:26 (UTC)
@Xiplus:(前之前、後)我能夠理解你的想法,這情況和O4、R8其實是類似的,但模板沙盒和模組沙盒本來就是作測試的用途,就算被刪除,其影響未必比惡意或錯誤利用O4、R8等的影響大,甚至O7在模板沙盒和模組沙盒上的惡意利用也未必對中文維基百科造成很大的實際影響,畢竟當用戶要建立新的測試版本時,他大可以直接重建沙盒頁面。(前之後)O7本身處理的是廢棄草稿,這類頁面的刪除的目的本來就不是為了減輕伺服器負擔,因此如果可刪除的比率接近一半,條文的訂立應該還是有用的。SANMOSA Σουέζ 2021年8月4日 (三) 10:59 (UTC)
刪除廢棄草稿有那麼一點點的優點(請看當初設立討論),而刪除/sandbox我看不到任何優點,至今也沒有人提出其優點,因此拿草稿與沙盒來比擬我覺得有點落差,/sandbox反而更像WP:沙盒,而我們也不會去刪除WP:沙盒。--Xiplus#Talk 2021年8月4日 (三) 11:20 (UTC)
  • 說實話,到現在才發現這個討論。所以只問一句,連同管理員似乎都是傻了嗎?原來你們都那麼放任那些早已廢棄卻又不刪除的沙盒,你們真的認為沙盒和草稿的功用不同?真不懂上面反對的用戶是不是沒有想過廢棄沙盒(Sandbox)的問題,只會刪除廢棄草稿(Draft)。--Z7504非常建議必要時多關注評選留言) 2021年8月4日 (三) 11:26 (UTC)

关于在Wikipedia:格式手册#條目定义句Wikipedia:格式手册#自由链接的格式中禁止添加指向条目本身或者其重定向的链接的提案

条目定义句

現行條文

不要在题目上,加上方括號作链接。

提議條文

不要条目標題或其他名称上加上方括號作链接。

自由链接的格式

現行條文

我们鼓励所谓的「自由链接」:当您见到文中某些字词名称值得读者参考阅读的话,請使用[[]]代码转成内部链接。請注意不要作过多的链接,例如不要把一句的每一個词,或者通篇文章都為同一個詞作出多次的链接:只要链接该词第一次出现就够了。

符合命名常规的链接会更容易成功链到已存在的条目;即使那条目还未存在,这样的链接也能够令未来新增的条目得到正确的名字。

链接所显示的文字不一定要与目标条目的名称相同,如[[朱熹|朱子]]。但请确保读者不需按下链接也能够清楚链接的目的地。

请尽量准确地链接。如果您想链接的条目还未存在,请先搜寻一下来确定该条目真的是不存在──它实际的名称可能只是与您所想的名称相差一点。

提議條文

我们鼓励所谓的「自由链接」:当您见到文中某些字词名称值得读者参考阅读的话,請使用[[]]代码转成内部链接。請注意不要作过多的链接,例如不要把一句的每一個词,或者通篇文章都為同一個詞作出多次的链接:只要链接该词第一次出现就够了。

符合命名常规的链接会更容易成功链到已存在的条目;即使那条目还未存在,这样的链接也能够令未来新增的条目得到正确的名字。

链接所显示的文字不一定要与目标条目的名称相同,如[[朱熹|朱子]]。但请确保读者不需按下链接也能够清楚链接的目的地。

请尽量准确地链接。如果您想链接的条目还未存在,请先搜寻一下来确定该条目真的是不存在──它实际的名称可能只是与您所想的名称相差一点。

请不要在条目的任何地方添加指向条目本身或者其重定向的链接,指向其他章节的除外。

如上——落花有意12138 回复请ping我 2021年7月29日 (四) 01:11 (UTC)

目前有些條目,會用內部連結連到條目本身的某一個段落,此功能仍有需要,希望保留連結到條目中某特定段落的功能--Wolfch (留言) 2021年7月29日 (四) 01:15 (UTC)
有道理,已修改——落花有意12138 回复请ping我 2021年7月29日 (四) 01:20 (UTC)
代為微調了字眼,不影響文意。SANMOSA Σουέζ 2021年7月29日 (四) 03:05 (UTC)

延伸確認權限後續討論 part2

回退相关方针编辑:

  • 就人事任免投票资格调整部分,有关公告并未对“人事任免投票资格调整”这类重大事件有任何提及。
  • 就扩展用户级别部分,个人认为上述讨论并未达成非常显著共识。--DreamerBlue留言) 2021年7月29日 (四) 01:56 (UTC)

@XiplusLanwi1:這情況需要處理一下。SANMOSA Σουέζ 2021年7月29日 (四) 02:50 (UTC)

(!)意見:程序上沒問題,公示期沒有反對意見,已經通過了;而且提案由始至終都有大量支持。--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 03:27 (UTC)
(!)強烈抗议有心人士企圖翻案! 完全不認為目前的通過有任何問題,無疑是在惡意找碴。--(!)強烈抗议有心人士企圖翻案! 完全不認為目前的通過有任何問題,無疑是在惡意找碴。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️) 2021年7月29日 (四) 03:53 (UTC)
本人主要是注意到,就人事任免投票资格调整部分,有关公告并未对“人事任免投票资格调整”这类重大事件有任何提及,这意味着整个公示存在一个瑕疵。本人的想法也是(+)支持该案,希望能让该案重新公示通过。--DreamerBlue留言) 2021年7月29日 (四) 03:56 (UTC)
@蟲蟲飛A2569875:不好意思,但我希望兩位能留意上方確實有多個對提案本身的强烈反對意見,我不認為相關反對意見小到可以被忽略。SANMOSA Σουέζ 2021年7月29日 (四) 03:58 (UTC)
另外,容許我在這裏表達我對整個提案(包括對“人事任免投票资格”的調整)的反對意見,我認為上方的反對意見的理由合理。SANMOSA Σουέζ 2021年7月29日 (四) 03:58 (UTC)
你根本就不明白我被LTA:X43LTA:114.27聯手打到快要死掉的痛苦。長期各種亂搞,我都快精神崩潰了,現在連這個曙光都要封掉,爛死了! 爛死了! 爛死了! 爛死了! 爛死了!-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️) 2021年7月29日 (四) 04:00 (UTC)
我認為提升自動確認用戶的門檻比較實際可行。我不相信他們能熬30日或90日。SANMOSA Σουέζ 2021年7月29日 (四) 05:45 (UTC)
不要小看X43,他用帳號會刻意觀察反破壞動向微調編輯行為,導致社群無法辨認出他是X43(已有多次這樣的例子,每次都讓我焦慮到死掉);而若只用50次(就算提高到100次也沒用)的自動確認用户門檻,他很容易就能繼續破壞,且只有50-100次編輯若用X43式的奸詐狡猾心機之「刻意觀察反破壞動向微調編輯行為」阻礙社群判斷他是傀儡(見Ahri6279這隻傀儡就是這類行為)根本不會露出馬腳,而若用500次延伸確認保護,一來,在他逐漸接近500次編輯紀錄的過程中會比只有50-100次的編輯紀錄有更多樣本能分析是否露馬腳,進而在達到500次編輯前成功封禁他的傀儡,而達到相關條目(500次進階確認保護)保護的效果。—- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️) 2021年7月29日 (四) 06:23 (UTC)
@A2569875:容許我recall用戶權限的取得門檻:自動確認用戶的門檻是注冊滿7日並同時編輯滿50次,延伸確認用戶的門檻是注冊滿90日並同時編輯滿500次,也就是説就算一個用戶滿足了編輯次數的要求,他還是需要等到注冊後的一段固定的時間才能取得相關門檻。我這裏説的“提升自動確認用戶的門檻”不只是提升編輯次數的要求,也包括提升注冊滿N日的日數要求。SANMOSA Σουέζ 2021年7月29日 (四) 06:42 (UTC)
你太小看X43了;你根本不了解X43,你也根本不了解我被X43搞到快要死掉的心情,被他搞到精神科都不知道去掛號多少次了;他躲/假裝正常編輯半年以上的號多的是;建議你迴避。—- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️) 2021年7月29日 (四) 06:45 (UTC)
那我只能説用延伸確認保護應付X43也不是長久之計,因為他終有一天也會適應新的編輯模式。當然,如果你説注冊滿90日並同時編輯滿500次的用戶不會被自動授予權限,而是還是需要先去權限申請頁面申請權限的話,那用延伸確認保護應付X43則是合理的。你需要考慮這點。SANMOSA Σουέζ 2021年7月29日 (四) 06:53 (UTC)
@A2569875SANMOSA Σουέζ 2021年7月29日 (四) 05:52 (UTC)
本人认为Tokisaki Kurumi的支持意见有说服力,另外希望各位能注意Lopullinen的意见。--DreamerBlue留言) 2021年7月29日 (四) 04:02 (UTC)
@DreamerBlue:那原本的提議修改也是不恰當的,因為如果條文只在Lopullinen的情境實施,相關條文需要限制延伸確認保護的適用對象為模板空間和模組空間的頁面。如果能限制延伸確認保護的適用對象為模板空間和模組空間的頁面,並將CGroup與其他適合實施延伸確認保護的受模板保護頁面改用延伸確認保護,那我會支持如此提案。SANMOSA Σουέζ 2021年7月29日 (四) 05:52 (UTC)
能否说下您为何坚持仅让扩展保护适用于模板和模组?--ときさき くるみ 2021年7月29日 (四) 06:32 (UTC)
因為這是Lopullinen的提案,如果連帶其他東西也適用的話,那個就不是他的提案,而需要當成另一個提案分開考慮。我現在之所以反對整個提案是因為蟲蟲飛聲稱現在的提案(甚麽也能用的提案)是我的提案,但我一開始的提案就只打算將延伸確認用戶權限用於判別人事任免投票資格。SANMOSA Σουέζ 2021年7月29日 (四) 06:42 (UTC)
好的,知道了。--ときさき くるみ 2021年7月29日 (四) 07:42 (UTC)
编辑冲突 × 4)(...) 吐槽@Sanmosa:我在三天就已經問過了,見上方(另外刪除已經存檔的討論內容)。-- Sunny00217  2021年7月29日 (四) 04:02 (UTC)
(※)注意:兩次的提案後續討論都是提到有用戶沒注意到提案,但並非反對提案,因此提案的共識是明顯,可以以「後續討論」的形式讓社群注意一下通過的提案內容也好。--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 04:15 (UTC)
@蟲蟲飛:你有認真閱讀嗎?Sanmosa很明顯是反對的。-- Sunny00217  2021年7月29日 (四) 04:18 (UTC)
延伸確認權附帶投票權是Sanmosa提出的,您為甚麼會認為Sanmosa會反對自己提出的提案呢?DreamerBlue上面也說他支持提案,您之前那個後續討論也說您「不反對」--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 04:22 (UTC)
我說Sanmosa很明顯是反對的,為甚麼會有您之前那個後續討論也說您「不反對」?!-- Sunny00217  2021年7月29日 (四) 04:25 (UTC)

想吐槽的是這種公示方法,貼出來就要公示且沒貼在布告板,結果沒半個人留言,並非反對提案,謝謝-- Sunny00217 2021年7月26日 (一) 11:33 (UTC)

那句話如果是在說我的話,我完全沒説過我“不反對”提案,甚至我在2021年6月28日 (一) 00:23 (UTC)以後就沒有在那個討論串留過言SANMOSA Σουέζ 2021年7月29日 (四) 05:45 (UTC)
  • (※)注意:延伸確認權附帶投票權是Sanmosa提出的,然後其他人支持,而且在公示期沒有反對意見下通過的。--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 05:57 (UTC)

    這樣的話確實和模板保護有點重複。我有個反建議:延伸確認保護可以拿來處理人事任免投票資格。@Lanwi1。SANMOSA Σουέζ 2021年6月27日 (日) 01:18 (UTC)

    我認為當時其他人反對我那個提議,或至少並無對我那個提議表示支持。整個討論除了我自己和明確不贊同我的提議的人以外,所有人都只在討論編輯戰或LTA的問題SANMOSA Σουέζ 2021年7月29日 (四) 06:01 (UTC)
    • 當時很多人支持您的提議,如我和宇帆都大力支持,然後在公示14天期間完全沒有反對下通過。--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 06:05 (UTC)
      看漏了,我能確定你和他當時是支持我的提議的,但要注意的一點是我的提議是將延伸確認用戶權限用於判別人事任免投票資格(而且還是要把延伸確認用戶權限的獲取資格設定為人事任免投票資格)。而且,就算是僅將延伸確認用戶權限用於判別人事任免投票資格的提議,除了你們兩個外,就只有Lanwi1和Xiplus就此表達過意見,而他們兩個都是反對我的提議的,而且反對理由充分,因此也看不到有將延伸確認用戶權限用於判別人事任免投票資格的共識。把你們四個和我自己排除後,就真的沒人對我那個提議表示任何意見(包括支持意見)了,我認為應該理解成他們對我的提議不屑一顧。A2569875現在所希望做到的東西(處理LTA)並不是我一開始提議的東西。SANMOSA Σουέζ 2021年7月29日 (四) 06:13 (UTC)
    • Lanwi1和Xiplus是覺得單純以您的建議作為理據去引入這個權限是不好,然後大家都圍繞這個話題去討論,包括防lta等理據,然後公示期,Lanwi1和Xiplus都沒再反對,而且在sunny 上面的「後續討論」中,Lanwi1還明確表示(+)支持。--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 06:19 (UTC)
      Xiplus的情況應該理解為他對原提案本身並沒有任何的意見,那自然也不包含支持意見。Lanwi1方面我同意你的解讀。但就算如此,原討論串裏確實存在明顯的反對意見,我確實看不出來你有進行妥善處理。SANMOSA Σουέζ 2021年7月29日 (四) 06:30 (UTC)
      「原討論串裏確實存在明顯的反對意見」[來源請求],除了提案通過幾天後出來鬧的,哪個用戶是反對的?只有Yining Chen是提出反對,但在第二稿已經根據他的意見優化提案,而且他在第二稿公示期沒再反對。此外,我看到您已經過去phab那邊反對,我建議在下面優化提案,以形成更明確的共識,而且不建議過去那邊爭論,否則洋人覺得中維很亂,影響將來其他提案的申請。--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 07:05 (UTC)
蟲蟲飛修改此討論的名稱,由「延伸確認權限爭議 part2」改為「延伸確認權限後續討論 part2」[1],我不太贊成這樣的修改,標題是反映原來開始此一討論者的看法,不太確定目前的修改是反映了誰的看法?若只是修改者的看法,我是否也可以修改此一標題,再改為我的看法?--Wolfch (留言) 2021年7月29日 (四) 04:24 (UTC)
其實討論最早的標題是「设置新的保护类型」(原始標題),並複製已存檔的部分,在下刪掉了存檔部分並改成「延伸確認權限爭議 part2」-- Sunny00217  2021年7月29日 (四) 04:27 (UTC)
DreamerBlue本來的標題是「後續討論」,是sunny改為「爭議」的,我覺得提案人原先的標題較佳。--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 04:29 (UTC)
那我沒有意見--Wolfch (留言) 2021年7月29日 (四) 04:48 (UTC)

優化提案

提案雖然已經通過,但有用戶有疑慮,我建議可以把已經過的提案再優化,以形成更明確的共識,歡迎大家提出優化建議,已經通過的提案如下:
Wikipedia:用户权限级别#延伸確認使用者(非方針指引)[分案A]
現行條文
提議條文

一個已註冊的用戶會在註冊達90天編輯達500次後自動獲得此權限。該用戶權限允許用戶編輯受到進階確認保護的頁面。機器人以及管理員都自動擁有此權限。

Wikipedia:保護方針#延伸確認保護[分案B]
現行條文
提議條文
延伸確認保護

延伸確認保護僅允許延伸確認使用者編輯,該使用者群組會在註冊達90天並編輯達500次時自動授予給註冊使用者。

管理員僅能在頁面已被半保護,且證實半保護仍無法阻止破壞或編輯戰的頁面上使用延伸確認保護。與半保護相同,不得對尚未發生的破壞或編輯戰進行預見性保護。亦不得將延伸確認保護使用於破壞或編輯戰以外的頁面上,應直接使用全保護(對於模板或模組可用模板保護)。

Wikipedia:人事任免投票資格[分案C]
現行條文
  1. 解任投票聯署提出或上任投票開始1個月前,編輯100次或以上;在聯署提出或上任投票開始前3個月內至少有1次編輯(不包括任何用戶頁及用戶對話頁);
  2. 編輯3000次或以上,或編輯1500次條目或以上。
提議條文
  1. 解任投票聯署提出或上任投票開始4個月前,編輯500次或以上;在聯署提出或上任投票開始前90天內至少有一次編輯(不包括任何用戶頁及用戶對話頁);
  2. 編輯3000次以上,或編輯條目1500次以上。

以上。--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 06:58 (UTC)

  • 如果延伸確認引入後,可以參考英維降低自動確認的門檻,這部分可以一併討論。~~Sid~~ 2021年7月29日 (四) 07:12 (UTC)
    反对降低自确门槛。目前自确门槛已经非常低了。--Lightyears GBAW 2021年7月29日 (四) 09:19 (UTC)
需要添加延伸確認用戶組嗎?(指確認使用者這種)--Papayatrash留言} 2021年7月29日 (四) 07:26 (UTC)
@Jonathan5566:日維那邊是可以由管理員授權,也可以移除,您希望像日維那邊的做法嗎?--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 07:31 (UTC)
可以提出幾點意見:
  1. 反對系統自動特許的設置,應該要求用戶自行請求授權(這應該是你理解的“像日維那邊的做法”);
  2. “帳號已註冊1個月”過短,真的要實施的話應該維持原提案的90日;
  3. 延伸確認權保護應容許用於高風險頁面保護(描述可以參考enwiki和Lopullinen的意見,不過我不會當成是Lopullinen的提案);
  4. 基於1,反對連鎖修改人事任免投票資格;
以上。SANMOSA Σουέζ 2021年7月29日 (四) 08:09 (UTC)
(:)回應
  1. 日維那邊的做法是系統自動授權,但可以按實際需要申請,但這個是有問題,因為延伸確認應是經過長時間貢獻而獲得的,而不是申請的,而且會加重管理員負擔。
  2. 這個可以再討論。
  3. 原提案沒反對用在模板。
  4. 已經通過的提案不宜推翻,但可以討論優化,而且延伸確認權附帶投票權不是您自己提出的嗎?
以上。--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 08:42 (UTC)
(1)如果打算要用延伸確認權限防治LTA,那系統自動授權就會使延伸確認權的保護力受嚴重削弱,因為LTA可以掌握新的權限的取得模式(這點我是就A2569875描述的LTA特徵而提出的),而且並不是所有用戶都熱衷於高級權限。如果真的會加重管理員的負擔,那就只能讓更多適任的人擔任管理員。(4)zhwiki有(局部)推翻已通過提案的先例,而且我也可以選擇收回提案(這也不是我第一次收回自己的提案),反正相關條文已經被回退掉了,我覺得沒分別。SANMOSA Σουέζ 2021年7月29日 (四) 08:59 (UTC)
您提出那個案例是一個非常壞的先例,不建議動輒推翻已通過的提案;此外延伸確認權通過後,能獲得權限的人一定很多,不應搞得太複雜。--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 09:50 (UTC)
一般的申請權限的程序應該不複雜。能獲得權限的人(有權者)多不代表申請並使用權限的人(行權者)也多。SANMOSA Σουέζ 2021年7月29日 (四) 13:38 (UTC)
這個權限有別於其他權限,簡單來說就是編輯權,就如「自動確認權」,如果管理員也可以取消,就很可怕了。--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 13:59 (UTC)
在我的理解中,模板編輯員的權限也是一種編輯權,但管理員依現行方針也是可以取消的。SANMOSA Σουέζ 2021年7月29日 (四) 14:21 (UTC)
模板編輯員是一種管理員全保護權限下放給有限使用者的替代方案,必須非常可信,所以自從模板編輯員引入後,大量高危頁面就由全保護改為模板保護。但延伸確認是一個資歷性質的權限,有點像自動確認的延伸。英維也不會由管理員授權,也不會由管理員除權,也沒必要。--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 14:35 (UTC)
瞭解。但我的想法與你的想法的不同之處在於:我認為延伸確認權限也是一種權限下放,一來既然要把這權限用於防治LTA,就應該要排除任何授權予LTA的機會,因此應該只有可信用戶才能獲得權限(但不需要如模板編輯員的權限般非常可信),不然就會有讓LTA取得權限並在脆弱的“保護”中持續破壞的機會;二來部分現在施行模板保護的高危頁面會因啓用延伸確認權限而再改為延伸確認保護,我認為情況某程度上與模板編輯員類近。如果真的擔憂取消編輯權的問題,可以規定延伸確認權限只有在用戶為破壞者的情況下方可移除,其他情況(包括可導致封鎖的情況)都不能,並規定違反該規定移除用戶的延伸確認權限的管理員可以被任何用戶提出緊急除權,而不需要經過除權投票(但如果這樣的方針通過了,需要知會meta一聲,因為他們也要看zhwiki本地的規則處理)。SANMOSA Σουέζ 2021年7月29日 (四) 14:54 (UTC)
延伸確認權不是一個由管理員主觀判斷,然後授權的權限,而是經過積累經驗,系統自動授權的。而LTA如果真要三個月去獲取這個權限,一旦被發現就是永封。此外,用戶濫用此權限是封鎖,而不是除權,正如現在假如一個用戶破壞,是封鎖,而不是移除自動確認權。維基的編輯權的意義是非常大的,當此權限的相應保護引入後,意味可能有為數不少的條目被延伸保護,因此應該讓沒破壞該條目的權限擁有者,仍然有編輯權。--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 15:15 (UTC)
你之所以說“延伸確認權不是一個由管理員主觀判斷,然後特許的權限,而是經過積累經驗,系統自動特許的”是因為你自己的提案如此設定而已,可見權限是自動授權還是人手授權完全是看實際規範的方針的規定。既然現在大家就在討制定有關新權限的方針,那新權限是自動授權還是人手授權自然是可以討論的。因此,我不會説你的主張完全不能提出來,但我不會把你的主張直接當成“事實”來看待。SANMOSA Σουέζ 2021年7月30日 (五) 08:31 (UTC)
此外,要注意的是這個權限是要配合「延伸保護」,而「延伸保護」只有在半保護無法阻止的破壞或編輯戰時才能施行,那麼用戶可以有甚麼充份理據去申請此權限去繞過「延伸保護」?如果「延伸保護」可以被輕易繞過,這個保護的作用就大大減低了。--蟲蟲飛♡♡→♡℃留言 2021年7月30日 (五) 08:42 (UTC)
正是因為希望保證「延伸保護」不被LTA輕易繞過,所以我才主張應該人手授權。基本上在權限申請頁面,很多人在那邊很容易表露自己申請權限的真正目的,我們可以從中判別哪些是LTA為了進行(秘密的)破壞而申請權限的。而且,也有鑒於管理員在處理授權時有一定的靈活性,我們也很容易從中判別哪些是用戶為了維持自己所主張的頁面版本而申請權限的。SANMOSA Σουέζ 2021年7月30日 (五) 08:47 (UTC)
根據Sanmosa的意見修改了提案。至於完全由管理員授權的建議,由於管理員人手不足,要等到中維管理員數達到像英維那樣超過1000,才有足夠人手處理。--蟲蟲飛♡♡→♡℃留言 2021年7月30日 (五) 09:56 (UTC)
臨時權限有用嗎?設立目的為何?--Bookwith留言) 2021年7月30日 (五) 18:11 (UTC)
原則上管理員不應授權,考慮到用戶如果有非常充分的理據下,才可以臨時授予,而且延伸保護通常不會永久。--蟲蟲飛♡♡→♡℃留言 2021年7月31日 (六) 00:24 (UTC)
所謂的「非常充分的理據」到底是什麼?我想不到有任何合理的情形需要人手授權。--Bookwith留言) 2021年8月1日 (日) 07:45 (UTC)
例如您已經有相關權限,但您想用小號編輯受保護的條目,或者客棧被保護了,您是新手,想到求助區求助等都是合理理由。--蟲蟲飛♡♡→♡℃留言 2021年8月1日 (日) 08:25 (UTC)
蟲蟲飛:我不相信互助客棧會應用到延伸保護。至於前面的情況,根本就不該申請。--Bookwith留言) 2021年8月2日 (一) 19:08 (UTC)
第一個情況較少,但確實有LTA突破自動確認門檻繼續破壞,見第一次討論內容。第二個情況與現時用戶為小號申請確認用戶的情況相似,這不是該不該的問題,而是用戶的選擇權。--蟲蟲飛♡♡→♡℃留言 2021年8月3日 (二) 00:19 (UTC)


(+)支持90日注册条件,对人事任免投票资格的修改表示(=)中立。--Lightyears GBAW 2021年7月29日 (四) 09:23 (UTC)
如果是要管理員可以自由移除的話可以寫一隻機器人自動授權(但host的人的伺服器壓力會非常大)?-- Sunny00217  2021年7月29日 (四) 11:50 (UTC)
  • 英維那邊是系統自動授權,這個權限其實是自動確認的延伸版,而且如果管理員濫權,無理移除用戶權限,也有問題。--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 12:12 (UTC)
蟲蟲飛認為已通過的提案不適宜推翻,我倒是反對。這個提案即使優化,也不會帶來顯著的改變──我依然對提案沒有好感。--Bookwith留言) 2021年7月29日 (四) 14:49 (UTC)
如果您有甚麼意見,也可提出,讓提案更加優化。--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 15:19 (UTC)
根據30000lightyears和Sanmosa意見改為「3個月」--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 09:38 (UTC)
“3個月”的長度是不固定的,建議寫成“90日”,但對此條的大意無意見。SANMOSA Σουέζ 2021年7月29日 (四) 09:40 (UTC)
根據Sanmosa意見修改為「90日」。--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 09:44 (UTC)
  • (!)意見人事任免方面,由于管理员审批受主观因素影响,建议还是通过硬性的编辑数注册时间来确定。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年7月29日 (四) 12:54 (UTC)
(✓)同意:英維那邊也是系統自動授權。--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 13:07 (UTC)
  • (!)意見:還是覺得把這兩件綁一起是錯誤的決定。--Papayatrash留言} 2021年7月30日 (五) 04:01 (UTC)
  • 您的理據是甚麼?沒記錯,英維的投票權就是延伸確認用戶,中維沒cu,RFA等傀儡投票過去也是有的,現時刷傀儡投票帳號太容易了,而且某個lta整天在教人改ua,刷投票傀儡,已經讓全站的人都懂得改ua規避cu去刷傀儡投票了,這個問題您覺得可以怎樣解決?--蟲蟲飛♡♡→♡℃留言 2021年7月30日 (五) 04:14 (UTC)
    假設由管理員授權,道德太有彈性了。且管理員可以控制投票者,這事本身就有問題。“人事任免由於管理員審批受主觀因素影響,建議還是通過硬性的編輯數註冊時間來確定。”但反破壞的角度來說,應該由管理員授權,這樣可以某種程度防範LTA。所以這兩件事情不應纏在一起。--Papayatrash留言} 2021年7月30日 (五) 06:15 (UTC)
整體上(+)支持此提案,但如果將「解任投票聯署提出或上任投票開始1個月前,已被系統自動賦予延伸確認權限」改成「解任投票聯署提出或上任投票開始30天前,已被系統自動賦予延伸確認權限」;「聯署提出或上任投票開始前3個月內至少有一次編輯」改成「聯署提出或上任投票開始前30天內至少有一次編輯」就更好了,因為一個月可以有28/29/30/31天的,清楚說明天數可以減少爭拗,另「聯署提出或上任投票開始前3個月內至少有一次編輯」好像不能有效提升維基人的積極性(三個月就才來一次,之後又不上來)。--MCC214Sign | Contributions 2021年7月30日 (五) 15:57 (UTC)
現在還來談收緊資格限制。--Bookwith留言) 2021年7月30日 (五) 18:05 (UTC)
我也認為可以暫時不再進一步收緊,延伸確認權限已經是合理要求。--蟲蟲飛♡♡→♡℃留言 2021年7月31日 (六) 00:24 (UTC)
根據mcc214意見,把“一個月”改為“30天”。--蟲蟲飛♡♡→♡℃留言 2021年7月31日 (六) 00:30 (UTC)
乾脆順便把其他方針指引的半年、六個月也一起以同樣理由改成180天算了-- Sunny00217  2021年7月31日 (六) 04:52 (UTC)
您自己可以另行提出嘛。--MCC214Sign | Contributions 2021年7月31日 (六) 13:43 (UTC)
雖然先前有人同意人事任免投票資格可以採用延伸確認,但沒有人說明為何要(實質)提高人事任免投票資格的門檻?--Xiplus#Talk 2021年7月31日 (六) 13:45 (UTC)
那是因為過去RFA都有傀儡,而且現在的門檻確實太低,容易刷投票權。最近某個LTA也在整天教人如何改ua和刷投票權傀儡,這個問題也得解決。--蟲蟲飛♡♡→♡℃留言 2021年7月31日 (六) 13:51 (UTC)
似乎确实没有人说明为何要提高人事任免投票资格。个人调查了过去5次RFA,考虑到近期的某些RFA支持票数显然不属于正常范围(基本属于可以列入维基百科之最的范畴),且也受到了傀儡的干扰(例如CRHK128、South Africa No.1曾干扰管理员投票),我不反对提升人事任免投票资格。--DreamerBlue留言) 2021年7月31日 (六) 13:52 (UTC)
你們想要提高人事任免投票資格應分案提出,而不是綁定延伸確認權限一案,雖然某項資格要求某一權限這件事沒有問題,但前提是那個權限的資格已被確實設立,因此像7月17日通過人事投票資格參考一尚未正式確定門檻的權限這一嚴重的程序瑕疵,通過提案之人未能察覺,也未有人指出問題。我感到相當驚訝。--Xiplus#Talk 2021年7月31日 (六) 14:27 (UTC)
給你們兩個選擇, 1. 先確立延伸確認後,再開始討論人事任免投票資格。 2. 現在另案人事任免投票資格,其資格不援引延伸確認。--Xiplus#Talk 2021年7月31日 (六) 14:29 (UTC)
首次討論我就已經提出過,反對以人事任免投票資格為理由設立該權限,現在的投票資格就沒有援引任何權限,你們改成另一個沒有援引權限的門檻沒有問題。至於延伸確認用於反破壞我沒意見,我沒有同意設立,但以這點設立沒有問題,另外請把正式提議條文拿出來,而不是現在上方那個口語化的東西。--Xiplus#Talk 2021年7月31日 (六) 14:34 (UTC)
提案之前雖然已經通過,但您看我還沒改方針,因為我本來想等到延伸確認權限通過才改方針;之前模板編輯員的申請也是一樣,先通過權限申請,然後相關通過的方針才生效,但兩者都是同步進行。此外,提案顯示的就是正式條文,英文這個權限也是幾行字。--蟲蟲飛♡♡→♡℃留言 2021年7月31日 (六) 14:49 (UTC)
英文的哪個頁面交出來,我看看是不是只有這幾個字。--Xiplus#Talk 2021年7月31日 (六) 15:05 (UTC)
這一小段就是英維的延伸確認權限的描述,如果有其他意見想補上去,也可以提出來討論。--蟲蟲飛♡♡→♡℃留言 2021年7月31日 (六) 15:12 (UTC)
那麼延伸確認保護的部分呢?--Xiplus#Talk 2021年8月1日 (日) 02:15 (UTC)
延伸確認保護也是頭一小段有關,重點也已經寫在提案上了,如果有其他意見想補上去,也可以提出來討論。--蟲蟲飛♡♡→♡℃留言 2021年8月1日 (日) 02:22 (UTC)
算了你聽不懂的話,我直接改了,多說無益。--Xiplus#Talk 2021年8月1日 (日) 02:57 (UTC)
同樣地,「並在聯署提出或上任投票開始前3個月內至少有一次編輯」也要改成「並在聯署提出或上任投票開始前90天內至少有一次編輯」,另聯署的門檻也要考慮作出相應調整。所以可以先通過,但暫緩不改人物任免方針,等到權限設立了,才一併改方針。--MCC214Sign | Contributions 2021年7月31日 (六) 14:01 (UTC)
這個雪球就好了吧(-- Sunny00217  2021年8月1日 (日) 01:53 (UTC)
根據MCC214意見,修改了提案;聯署門檻可以適當時機再討論,暫時先優化了這個提案。--蟲蟲飛♡♡→♡℃留言 2021年7月31日 (六) 14:06 (UTC)
我把上方三部分分成分案A、B、C,大家可以就個別分案分別表達意見。我先說明:反對分案C,支持分案B,觀望分案A。SANMOSA Σουέζ 2021年8月1日 (日) 03:07 (UTC)

Sanmosa之前的建議

這樣的話確實和模板保護有點重複。我有個反建議:延伸確認保護可以拿來處理人事任免投票資格。@Lanwi1。SANMOSA Σουέζ 2021年6月27日 (日) 01:18 (UTC)

把延伸確認資格從500次編輯拉伸到1500次或3000次編輯是可行的,甚至如果技術允許的話,可以讓系統自動判別用戶是否符合人事任免投票資格,然後為符合資格者自動授權延伸確認用戶,授權後不符合資格者自動除權。SANMOSA Σουέζ 2021年6月27日 (日) 02:34 (UTC)

這樣做可以直接省去計票審核的程序,因為不符合資格者自己也投不了票。SANMOSA Σουέζ 2021年6月28日 (一) 00:23 (UTC)

@Sanmosa
(※)注意:分案C「延伸確認權附帶投票權」是sanmosa自己提出的,然後蟲蟲飛和宇帆等人支持,現在他在通過後才說反對自己原先的提案提議,請sanmosa說明理據﹗請注意在共識形成過程中應提出有效理據,而非單純表態。--蟲蟲飛♡♡→♡℃留言 2021年8月1日 (日) 03:31 (UTC)
請你搞清楚,我的用意是把延伸確認用戶權限的取得資格設定為原本的人事任免投票資格,而不是把後者提升到前者。我懇請蟲蟲飛立即停止其歪曲事實的表述。SANMOSA Σουέζ 2021年8月1日 (日) 03:48 (UTC)
重看留言,似乎是您自己忘了自己的話。您原意是要「1500次或3000次編輯」才獲得權限,然後我建議改第一條,然後宇帆等人支持。--蟲蟲飛♡♡→♡℃留言 2021年8月1日 (日) 04:06 (UTC)
完全沒有這回事。你從一開始提案就曲解了我的意思。宇帆等人支持的是你的提案,但你的提案和我的想法並不相同。SANMOSA Σουέζ 2021年8月1日 (日) 04:34 (UTC)
應該是說您是最先提出延伸確認權附帶投票權,但大家覺得您提出的門檻太高(1500次或3000次編輯才獲得權限),然後我根據您的方案作出修訂,然後大家支持。--蟲蟲飛♡♡→♡℃留言 2021年8月1日 (日) 04:46 (UTC)
我完全沒有這個想法。如果大家以為我有,那就是大家集體誤解。SANMOSA Σουέζ 2021年8月1日 (日) 04:57 (UTC)
無論如何,留言存檔大家都能看到。最重要的是,您是最先提出延伸確認權附帶投票權,如果您覺得具體的條件太高或太低,大家可以再討論,以形成共識,而且維基的共識過程不應只作單純的表態,最重要是說出理據;而且此提案其實已經通過了,考慮到有人說沒看公告,或公示公告不清晰,才再討論再優化方案。--蟲蟲飛♡♡→♡℃留言 2021年8月1日 (日) 05:03 (UTC)
Sanmosa沒有提出分案C。那不是Sanmosa的提案,請蟲蟲飛停止曲解。分案C是對門檻的實質提升,我保留反對意見。--Bookwith留言) 2021年8月1日 (日) 07:40 (UTC)
您誤解了上面留言,請重看。而且請不要為反對而反對,請說明您理據!--蟲蟲飛♡♡→♡℃留言 2021年8月1日 (日) 07:49 (UTC)
現時的門檻一直沒出大問題,也對投票者的經驗作出了相當的肯定。沒有需要修改。--Bookwith留言) 2021年8月1日 (日) 07:57 (UTC)
  • 可能您沒注意,最近的rfa都出現傀儡投票,而且vip也多了刷編輯數的舉報,某lta還整天教人改ua刷投票傀儡,這個問題您覺得可以怎樣解決?--蟲蟲飛♡♡→♡℃留言 2021年8月1日 (日) 08:18 (UTC)
@蟲蟲飛:我的建議是把人事任免投票資格的提升的討論與這裏的討論分開處理,其實我有一個更大膽的提案。SANMOSA Σουέζ 2021年8月2日 (一) 06:54 (UTC)
提案已經進行了一個多月,個別用戶說沒看公告,或者公告不清晰,就要把已經通過的提案推翻;現在延伸確認用戶附帶投票權的提議也是Sanmosa提出的,通過後走去phab鬧的也是samosa您,搞到洋人以為中維很亂。我不認為要這樣浪費社羣時間和資源。通過的提案其實就不應任意推翻,或者您有甚麼改善建議,您可以提出來,大家一起討論,把提案優化,而不是動輙推翻已通過的提案。或者您有甚麼優化建議,先提出來,大家討論一下。--蟲蟲飛♡♡→♡℃留言 2021年8月2日 (一) 07:05 (UTC)
我和Xiplus的態度一樣:“我不承認那是我的方案”,而且這好像也不是我第一次表明我這個態度了。SANMOSA Σουέζ 2021年8月2日 (一) 07:26 (UTC)
@Sanmosa:您的方案和我的方案是有些不同,但延伸確認權限附帶投票權是您最先提出的,您可能連自己說過的話也忘記,我把您說過話的重點貼出來給您看看,您最先的方案是:「有個反建議:延伸確認保護可以拿來處理人事任免投票資格。」「把延伸確認資格從500次編輯拉伸到1500次或3000次編輯是可行的」,但您現在不同意「500編輯」,那您希望怎樣優化?還有不同意「500次編輯」的理據是甚麼?--蟲蟲飛♡♡→♡℃留言 2021年8月2日 (一) 07:48 (UTC)
「把延伸確認資格從500次編輯拉伸到1500次或3000次編輯是可行的」的前提是社群真的同時有將進階確認用戶資格與人事任免投票資格綁定和提升人事任免投票資格的共識,那時候由於延伸確認資格=人事任免投票資格,因此「把延伸確認資格從500次編輯拉伸到1500次或3000次編輯」可以做到提升人事任免投票資格的效果。然而我看不到這樣的共識,因此我反對綁定。SANMOSA Σουέζ 2021年8月2日 (一) 13:59 (UTC)
@Sanmosa:簡單來說您自己就是沒有反對理據,而且一再反悔自己原先的提議(延伸確認權附帶投票權),其實我不明白您在反對甚麼,而且現在就是除了您和Bookwith在反對,沒有人反對,而bookwith沒有提出反對理由,而且一直拒絕回應;提案已經獲得絕大多數人支持,如果您沒有提出有效反對理據,而是單純表態,而且如果您也不打算提出改善建議,根據WP:共識:「共識不強求一致同意」,那提案就可以視為已經形成共識,稍後公示;但如果您有改善建議,歡迎您提出來,大家再討論,我也會儘量妥協。--蟲蟲飛♡♡→♡℃留言 2021年8月2日 (一) 14:20 (UTC)
我重申一次:我和Xiplus的態度一樣:“我不承認那是我的方案”,而且我質疑“提案已經獲得絕大多數人支持”的聲稱的真實性。我現在的底綫是不將進階確認用戶資格與人事任免投票資格綁定,以及將人事任免投票資格的調整分開處理,其他我都可以不反對。SANMOSA Σουέζ 2021年8月2日 (一) 15:08 (UTC)
請您重讀上面留言,我上面那句哪裏說了「方案」二字,如果您喜歡咬文嚼字,那麼「方案≠提議」,至於明確支持提案的人有:A2569875、DreamerBlue、Lanwi1、Tokisaki Kurumi、Jonathan5566 、Sidishandsome、MCC214等,之前支持的有:LuciferianThomas、Eric liu等,這不叫獲得絕大多數人支持”,叫甚麼?此外,「將進階確認使用者資格與人事任免投票資格綁定」是您最先提出的,您現在反對,理據是甚麼?上面大家已經討論過之所以這個權限與投票權綁定,是為了解決RFA的傀儡票問題,這也是您自己在第一次討論首先提出的,如果反對這個方案,您有甚麼解決傀儡投票的問題?另一方案是不綁定權限,就是條件和權限的條件是一樣的,您看這樣有沒有問題?--蟲蟲飛♡♡→♡℃留言 2021年8月2日 (一) 15:34 (UTC)
我同意分開處理。--Bookwith留言) 2021年8月2日 (一) 19:29 (UTC)
@Sanmosa:我根據您意見改了,請審閱﹗--蟲蟲飛♡♡→♡℃留言 2021年8月2日 (一) 15:54 (UTC)
@Sanmosa:請回應﹗--蟲蟲飛♡♡→♡℃留言 2021年8月1日 (日) 04:16 (UTC)
@Lanwi1Tokisaki KurumiA2569875SidishandsomeMCC214:邀請上面參與了討論的人也發表一下意見。--蟲蟲飛♡♡→♡℃留言 2021年8月1日 (日) 03:44 (UTC)
這是只邀請一個立場的用戶來參與討論嗎?這恰當嗎?--Bookwith留言) 2021年8月1日 (日) 07:33 (UTC)
  • ping的上限人數是五個人,而且前期討論主要是這些人。而且ping不是必須的,用戶應該自覺留意客棧的討論,而且客棧討論也不是面對幾個人,而是面對整個社羣。您對xiplus的方案有優化建議嗎?--蟲蟲飛♡♡→♡℃留言 2021年8月1日 (日) 07:41 (UTC)
    以現在的分案B來說,對有需要用戶人手授權是不難的。受影響頁面和用戶實際上很少。--Bookwith留言) 2021年8月1日 (日) 07:50 (UTC)
    我不承認那是我的方案。--Xiplus#Talk 2021年8月1日 (日) 10:42 (UTC)
    ping的上限是5個人,但不代表你不能用多次模板-- Sunny00217  2021年8月2日 (一) 01:01 (UTC)
好吧,提案大家都給了意見,說是誰的不重要,這是xiplus修訂差異:

Special:Diff/66876450--蟲蟲飛♡♡→♡℃留言 2021年8月1日 (日) 10:55 (UTC)

@Bookwith:如果把非編輯戰的授權條件放寬,您能否接受提案?--蟲蟲飛♡♡→♡℃留言 2021年8月1日 (日) 09:10 (UTC)
對於人事任免投票門檻的調整,我認為仍有討論空間,或者需要評估各種門檻的優劣後再作決定。--Bookwith留言) 2021年8月2日 (一) 19:24 (UTC)
  • 中維沒cu,rfa傀儡票和lta整天教人改ua避cu的問題也極為嚴重,用戶舉報傀儡刷編輯數的vip舉報也越來越多。現在只有您不同意,如果沒有更好的建議,就用現在的方案。--蟲蟲飛♡♡→♡℃留言 2021年8月3日 (二) 00:27 (UTC)
支持上述三個提案,但現在有一個可能性存在的問題:如果遇上有未符提案一要求的人申請權限,且申請獲批之後,及後才被發現進行鬼崇破壞(User:太魯閣號),那如何應對?--MCC214Sign | Contributions 2021年8月1日 (日) 09:51 (UTC)
  • 如果是lta,就直接永封,及移除權限;如果是非lta的,就是移除權限,按破壞情節決定封鎖期限。--蟲蟲飛♡♡→♡℃留言 2021年8月1日 (日) 10:09 (UTC)
    重點是當初的申請是如何獲批的。我目前還是想不到有哪些情況需要自行申請權限,蟲蟲飛在上面回覆的「新手想到客棧求助」也不合情理。我較為擔心容許人手特許後會出現一些非必要的申請,對提案構成一個漏洞。--Bookwith留言) 2021年8月2日 (一) 19:18 (UTC)
@Bookwith:我上面的回應是「第一個情況較少,但確實有LTA突破自動確認門檻繼續破壞,見第一次討論內容。第二個情況與現時使用者為小號申請確認使用者的情況相似,這不是該不該的問題,而是使用者的選擇權。」如果取消授權,您是否接受方案?--蟲蟲飛♡♡→♡℃留言 2021年8月3日 (二) 00:37 (UTC)
如果客棧最終會應用到延伸保護,那麼我會反對。至於第二點的部分,我會把它視為「沒有真正需要的申請」,不該批准及授權。--Bookwith留言) 2021年8月3日 (二) 07:09 (UTC)
所以這邊會有選擇的空間。可以選擇全數由系統自動授權,或者是需要權限的全數提交申請。--Bookwith留言) 2021年8月3日 (二) 07:11 (UTC)
@Bookwith:已經根據您的意見修改了提案,請審閱﹗--蟲蟲飛♡♡→♡℃留言 2021年8月3日 (二) 08:06 (UTC)
如果客棧不會應用到延伸保護,那麼暫時沒有大問題。--Bookwith留言) 2021年8月3日 (二) 08:14 (UTC)
@BookwithSanmosa:請兩位回應我上面的問題﹗--蟲蟲飛♡♡→♡℃留言 2021年8月2日 (一) 13:02 (UTC)
我的意思是將分案C完全自本案剝離,並另開新討論串。SANMOSA Σουέζ 2021年8月3日 (二) 03:58 (UTC)
  • 您的理據是甚麼?延伸確認權附帶投票權是您最先提出,但您一再咬文嚼字,反對您自己提出來的建議,不停糾纏於「方案」的定義,昨天也已經根據您的建議改了提案,但您還是不滿意。上面早就回應了您這個意見,提案已經討論了兩個月,已經獲得絕大多數人支持,不應該為了個別用戶,而浪費社羣的時間及資源,而且提案已經根據您的意見優化,如果sanmosa 沒有實質理據,請不要為反對而反對,而且這是WP:ONEHANDGIVES:「故意拖延或冗長辯論」。--蟲蟲飛♡♡→♡℃留言 2021年8月3日 (二) 04:10 (UTC)
    我同意將分案C完全剝離。分案C與分案A、B屬性質完全不同的提案,沒有必要捆綁式一併通過。因上方討論較少涵蓋到有關分案C的內容,假如另外一節討論修訂人事任免投票門檻,應可激發更為深入的討論。--Bookwith留言) 2021年8月3日 (二) 08:20 (UTC)
  • 不認為沒關,延伸確認在英維就是投票權,而且分案C早就通過了,沒有合理理據不應貿然推翻已通過的提案,而且這是浪費社羣時間和資源。如果要推翻,您應另行根據規定規則去提案推翻,而不是自己不喜歡就直接「否定」。中維沒有cu,rfa傀儡票和lta整天教人改ua避cu的問題也極為嚴重,使用者舉報傀儡刷編輯數的vip舉報也越來越多,這個問題必須要解決。--蟲蟲飛♡♡→♡℃留言 2021年8月3日 (二) 09:16 (UTC)
    既然提案性質不同,我希望分開通過。--Bookwith留言) 2021年8月3日 (二) 12:05 (UTC)
  • 請您按既定規則去另行重新提案!此案已經過兩個月討論,早已經通過,現在是討論怎樣優化,而不是個人喜好,而任意否定已經通過的提案,浪費社群資源和時間。如果對提案有甚麼優化建議,請您提出來討論。--蟲蟲飛♡♡→♡℃留言 2021年8月3日 (二) 12:21 (UTC)
  • 反對將C方案剝離重新討論,已經通過的方案可以優化,但沒有必要重新開啓新的討論,少數服從多數是最基本的社區規則。Sammypan留言) 2021年8月4日 (三) 04:38 (UTC)

譯名問題

  • 話說,社群究竟打算採用延伸確認、擴展確認,還是進階確認作為譯名啊?這三種我都有見過。—— Eric Liu 創造は生命(留言留名學生會 2021年8月2日 (一) 04:06 (UTC)
    進階確認吧,听起来自然一点。--Lt2818留言) 2021年8月2日 (一) 05:02 (UTC)
    之前的情況好像是簡體用“高級確認”、繁體用“進階確認”,建議沿用。SANMOSA Σουέζ 2021年8月2日 (一) 06:51 (UTC)
    • 反对繁简不统一的译名。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月2日 (一) 13:02 (UTC)
      但這東西繁簡不同的譯名是以前早就有的,你引用的頁面可能不適合。不過如果大家的意思是「進階確認」可以用的話,至少繁體的譯名可以定下來了。SANMOSA Σουέζ 2021年8月2日 (一) 13:55 (UTC)
      繁简译名不统一除了加入公共转换组,写模板的时候还要一个个手动转换,在别人的讨论页留言可能还要看看别人用什么变体,然后flow又不支持/支援字词转换……反正就是麻烦,还不如取名的时候统一。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月2日 (一) 14:11 (UTC)
      那我也推薦「進階確認」。SANMOSA Σουέζ 2021年8月2日 (一) 15:05 (UTC)
    「進階」具有濃厚階級意味,個人認為「延伸」或「擴展」都比「進階」對新手友善。簡稱而言,「延確」「進確」「擴確」好像也就「延確」最順口。--路西法人留言 2021年8月3日 (二) 01:58 (UTC)
    支持延伸確認。--Bookwith留言) 2021年8月3日 (二) 06:42 (UTC)
    同-- Sunny00217  2021年8月3日 (二) 12:31 (UTC)
    (✓)同意「延伸確認」最順口。--蟲蟲飛♡♡→♡℃留言 2021年8月3日 (二) 03:17 (UTC)

提议换一个图标

当前图标是蓝色的锁里头一个人,与半保护的图标只有配色上的差别,其意义恐难以与半保护做出区分。顺便套用C区讨论的一个论点,对于色盲/色弱人士他们难以区别这两个保护。因此我提议修改图标。个人初步想法是在人的旁边放个加号之类的东西。 --Milky·Defer 2021年8月4日 (三) 02:15 (UTC)

(+)支持:可以把圖標貼出來給大家看一下嗎?--蟲蟲飛♡♡→♡℃留言 2021年8月4日 (三) 02:40 (UTC)

干脆大家在这些选项当中选一个吧,或者有其他设计者也可提出: --Milky·Defer 2021年8月4日 (三) 06:22 (UTC)

论废除WP:1E

我未查到你维为什么要有1E。但是根据我对1E精神的揣摩,我认为,1E的本质精神是:由你维社群来判断在一次事件中受到媒体有效介绍的人物是否足以建立条目,其原则包括事件是否重大和人物在事件中是否重要。

我认为,这是不合理的。本质上,维基百科应该信任可靠来源对谁拥有关注度的判断,这就是为什么GNG是个好指引:只判断来源可靠度和是否达到有效介绍。1E让社群来判断事件是否重大和人物是否重要,社群为什么要拥有这个资格呢?可靠来源对某人进行了有效介绍,已经说明此人值得关注,社群为什么还要删掉此人的条目呢?(除了对此人的有效介绍完全和某事件联系时可以重定向外)Fire Ice 2021年7月7日 (三) 17:44 (UTC)

Fire-and-Ice看來是翻譯過來的。1E最早出現於Special:Diff/11659044,推測其複製的版本應該是en:Special:PermaLink/325814815-- Sunny00217  2021年7月8日 (四) 02:56 (UTC)
关于为什么要有1E,1E的条文是不言自明的。主要原因有两点:
第一,“维基百科不是新闻报纸,某人曾经出现在新闻中本身并不意味着此人就可以成为一篇百科全书条目的主角。”而这是在迎合上位方针对“维基百科不是新闻”的要求:
  1. “維基百科不應該提供第一手消息報導以揭發故事。維基百科不由第一手來源構成。”;
  2. “維基百科不應該提供突發新聞消息”;
  3. “即使事件值得關注,所涉及的個體可能不是。除非個體的新聞報導覆蓋了單個事件文章的泰半,我們報導個體應限於有關該事件的條目中,按整體條目重要性的比例記載。”
换言之,正是因为本站有NOTNEWS,对新闻类的条目有严于一般条目的收录准则,所以才会有此附加条件。而GNG本身并没有排斥这种附加条件的设立:
第二,“边缘关注度人物的传记会让特定事件拥有过大的比重,并可能会违背我们的中立观点方针”。这是在迎合中立性方针的要求;如果一个人物只在特定事件的背景下被可靠来源加以深入介绍,那么为这人写出的传记,看似传记实则不是传记,而是挂羊头卖狗肉的“伪传记”。这种状况,作为一部百科全书是不应当出现的。
最后,GNG只是条目收录的门槛;GNG能用于选题和选材,但不能为“材料应以何种方式呈现出来”提供指导意见。编者在GNG之外有其它的考量,完全不是一件坏事情。--Antigng留言) 2021年7月8日 (四) 03:09 (UTC)
(!)意見:@忒有钱MINQIFire-and-Ice:找了一下英维,我个人目前没什么强烈的观点,所以只是贴先例:这里有一个提删者自己表明死人不适用1E的这里还有一例是死后发现反而发现不符合保留要求的,当然自然也有死后多年反而满足了保留要求的,所以能看出来的仅仅是英维往往不是一刀切的。--ときさき くるみ 2021年7月8日 (四) 08:58 (UTC)
一、我未见这一上位方针有任何道理。二、伪传记情况完全可以重定向,不需要1E。三、我要强调,我认为“1E的本质精神是:由你维社群来判断在一次事件中受到媒体有效介绍的人物是否足以建立条目,其原则包括事件是否重大和人物在事件中是否重要。”而社群不应具有判断这两项的资格。Fire Ice 2021年7月8日 (四) 15:04 (UTC)
二我没什么太强的反对意见,三至少是略有问题的,上面的第三个例子刚好与您的第三点相反,摘抄关键段落如下:
Oppose The article should be expanded. However, his notability is clear. There are few scientists who are killed due to their involvement in the nuclear program of Iran. The reliable news sources such as huffington post, Guardian, washington post have covered it.--Seyyed(t-c) 14:29, 15 February 2018 (UTC)
Certainly his death has been covered - widely. However that is a WP:BIO1E situation. How is he notable besides his death?Icewhiz (talk) 14:43, 15 February 2018 (UTC)
--ときさき くるみ 2021年7月8日 (四) 19:10 (UTC)
没看出哪里相反?Fire Ice 2021年7月10日 (六) 10:52 (UTC
您不是认为“而社群不应具有判断这两项的资格”吗?这里最终的结果以及Icewhiz的话不正与您这句话相反?--ときさき くるみ 2021年7月10日 (六) 16:21 (UTC)
Icewhiz的论点既然是该人还需媒体关注的其他点,那就说明他认为事件不重大或此人在事件中不重要(不然即可依据1E保留)。本身说明他认为自己有判断这两项的资格。而我就是认为不应有资格。Fire Ice 2021年7月10日 (六) 18:08 (UTC)
当然,那么对于讨论的结果您又如何看呢?--ときさき くるみ 2021年7月11日 (日) 02:47 (UTC)
结果是什么,有链接吗。Fire Ice 2021年7月11日 (日) 04:41 (UTC)
当时的结果就在这几个讨论页的上方,和平时中维总结互助客栈的共识的形式基本一致。至于现在的状况您可直接点这几个条目的链接看他们到底是被重定向了还是后来又满足标准重新创建了。--ときさき くるみ 2021年7月11日 (日) 05:43 (UTC)
对于en:Mostafa Ahmadi Roshan案,管理员的裁定是重定向,我认为是符合我关于“对此人的有效介绍完全和某事件联系时可以重定向”的说法的。至于后来的重建,我也支持,因为该传记条目叙述了除死亡外的其他信息,如生平和家庭,说明媒体认为这值得关心,符合我关于让媒体来判断是否值得关注的精神。Fire Ice 2021年7月11日 (日) 08:59 (UTC)
您后半段没问题,但前半段第一次如果没有1E的话管理员很可能就不会删了,而且另外两例都被删掉了。--ときさき くるみ 2021年7月11日 (日) 14:45 (UTC)
(!)意見反對廢除,因為1E的意義在於:
  1. 可以排除例行報道中的路人甲都能立傳,如交通意外中藉藉無名的傷者。
  2. 可以保留確實具關注度的人物,例如「殺死美國總統」、「獲得諾爾文學獎」,或者「自身某些原因吸引傳媒關注」等都不適用於1E。
以上。--蟲蟲飛♡♡→♡℃留言 2021年7月9日 (五) 14:08 (UTC)
籍籍无名的伤者没有有效介绍自然不能立传,因此我没看出虫虫飞到底在反对什么。Fire Ice 2021年7月10日 (六) 10:45 (UTC)
不過考慮到有些用戶不理會來源是否「有效介紹」,也不管事件影響大小,總之看到涉及事件,就要提刪,所以取消1E也不一定是壞事,撤回反對,對此改(+)支持。--蟲蟲飛♡♡→♡℃留言 2021年7月10日 (六) 10:57 (UTC)
(+)支持废除1E。个人认为在zhwiki,1E是对关注度原则的延伸,但同时也是一种误读。此外,常用的关注度判别标准已经足以处理1E的问题,比如上方Fire Ice君提及的“籍籍无名的伤者没有有效介绍自然不能立传”。如果不能废除1E,则现时需要更改其条文,使其更加包容。—MintCandy♫ 欢迎参加浙江专题 台州专题 2021年7月11日 (日) 06:57 (UTC)
(-)反对废除1E。1E本身就有提醒社群关注WP:NOTNEWS的作用,没有必要废除,也不能废除。--DreamerBlue留言) 2021年7月14日 (三) 03:24 (UTC)
提醒NOTNEWS毫无意义。没看出存在的必要,也没看出为何不能废除。Fire Ice 2021年7月14日 (三) 05:50 (UTC)
@Fire-and-Ice:能否稍為講解一下WP:1E哪些部分是不合理的,哪些部分是和現行方針指引重複的,這樣有助我判斷廢除的合理性。SANMOSA Σουέζ 2021年7月16日 (五) 13:47 (UTC)
不合理处一:“在实质上他的生活仍然保持低调,我们应当避免为此类人物撰写条目。”没看出为什么要避免为他创建条目。只要达到可靠来源有效介绍,并且不违反NOT,就可以有条目。不过我这里已经想到一种例外情况:当我们可合理推测媒体报道违背当事人意愿时,不应该有条目。
不合理处二:“边缘关注度人物的传记会让特定事件拥有过大的比重,并可能会违背我们的中立观点方针。”什么意思?为什么会违反中立观点方针?中立观点应该是条目内的观点平衡,譬如我在地平说条目里详细介绍了地平说,难道就违反中立观点了么?
不合理处三:“倘若事件有着重大的影响,且该人物在事件中的角色举足轻重,那么则可能可以为此人创建独立条目。”如上所述,这是要社群来判断事件是否重大和人物在事件中是否重要,我完全看不出社群为什么要有这个资格。Fire Ice 2021年7月16日 (五) 13:55 (UTC)
@Fire-and-Ice:我把這被存檔的討論發還過來VPP了。看過你的解説,我認為你的論證合理,再加上上面也有人支持廢除1E,我覺得這件事情是值得進一步探討的,我正式對廢除1E的提案表示支持。不過我還是想進行一些解說:(2)“边缘关注度人物的传记会让特定事件拥有过大的比重”應該是説挂羊头卖狗肉的情形,使边缘关注度人物的传记成為實則上的特定事件的條目(當然,這並不是只會在传记條目中發生)。當然,挂羊头卖狗肉本身並不會直接導致违反中立观点方针,有時候過於深入介紹主題的一個方面的結果是條目應該更名,CSi口罩條目是一個例子,但我也能夠理解挂羊头卖狗肉的條目很多時候會被寫成宣傳某個偏見的内容的情況。(3)很同意你的觀點,我自己的看法是判断事件是否重大和人物在事件中是否重要的是來源。SANMOSA Σουέζ 2021年7月29日 (四) 06:24 (UTC)
@DreamerBlue:Fire-and-Ice上面對他提案的理由進行了解説,我認為這樣你比較好回應他的觀點。SANMOSA Σουέζ 2021年7月29日 (四) 06:44 (UTC)
本人所称的“NOTNEWS”,指的是 阁下所称的“(2)”,即如果废除1E可能导致边缘关注度人物的传记实际上成为特定事件的条目。--DreamerBlue留言) 2021年7月29日 (四) 06:48 (UTC)
@DreamerBlue:這處理不就簡單:移動條目,使條目名能表示該條目為事件條目即可,這我們一向都能做到,而且也不止一次先例。要保險一些的話,適當地調整Wikipedia:挂羊头卖狗肉的内容,並將調整後的頁面設為具備共識地位的資訊頁即可。SANMOSA Σουέζ 2021年7月29日 (四) 08:13 (UTC)
反对废除。见我先前在存废讨论中的留言,对单一事件人物宜以事记人。乔治·弗洛伊德为典型反例,没人关心他每天早餐吃啥Lt2818留言) 2021年7月29日 (四) 14:59 (UTC)
@Lt2818:見上,廢除1E並不影響“對單一事件人物宜以事記人”的大方向,如果真的要為保險計,我還有保險方案,保證不走樣。SANMOSA Σουέζ 2021年7月29日 (四) 15:03 (UTC)
我没看任何维基方针的时候就有这个概念,正好现在也有1E的成文规定。由此可见,1E类似于自然法,即使废除了,其精神也一样适用。
看到有人因GNG的缘故,将来源视作关注度唯一标准,这是不可取的。GNG倒只是人为规定。--Lt2818留言) 2021年7月29日 (四) 15:21 (UTC)
既然你都這樣說了,那就恰好證明了1E是與既有其他成文法與自然法具高度重複性的東西,因此本身並不需要獨立成文處理。如果真的還要成文處理,那把不與既有成文法重複的部分的精神放在更適合的地方成文處理即可。SANMOSA Σουέζ 2021年7月30日 (五) 08:27 (UTC)
你用同样的理由也能废除Wikipedia:文明,这更是自然法。--Lt2818留言) 2021年7月30日 (五) 09:29 (UTC)
所以我才提出保險方案,讓不與既有成文法重複而與自然法重複的部分維持成文處理。如果所有用戶都能有文明的意識,那WP:文明確然是不需要的;在假定善意的前提下,我假定所有用戶都有文明的意識,但WP:文明之所以保留是因為這是不與既有成文法重複而與自然法重複的部分維持成文處理的情形。SANMOSA Σουέζ 2021年7月30日 (五) 13:54 (UTC)
(-)傾向反對,中立问题SANMOSA已经说了,但是他的结论我不太同意,有时恐怕不是改名能够解决的,而且改名还有可能违反命名常规和非原创研究方针,而且仍然避免不了不合理比重的问题。关于“不合理处一”,所谓“生活仍然保持低调”,意思应该是指那些因某事被媒体短时间大量报道后,随着时间的消退或其他原因而不再会有媒体报道的人,他们再也不会出现在聚光灯下。这样的条目极大可能永远就停留在聚光灯关闭时的样子,是生是死恐怕都没人知道了,从而也就造成条目理论上永远无法成为特色条目。关于“不合理处三”,这只是对1E的例外说明,如果没有1E,这个自然也就没有了,如果有1E则必然需要说明一些例外情况--百無一用是書生 () 2021年7月30日 (五) 02:07 (UTC)
@Fire-and-IceSANMOSA Σουέζ 2021年7月30日 (五) 08:27 (UTC)
一、你无非是说,没有好名字,所以要删除。而我就不同了:只要内容可能调到合理比重,就不应该被1E删除。二、“从而也就造成条目理论上永远无法成为特色条目”,为什么要成为特色条目,我并未看懂。三、“有1E则必然需要说明一些例外情况”,事实是1E造成你维社群要作出判断。Fire Ice 2021年7月30日 (五) 11:10 (UTC)
我能夠理解2的部分,畢竟FA是條目最理想的狀態,不過我和Fire-and-Ice的疑惑是一樣的。SANMOSA Σουέζ 2021年7月30日 (五) 13:57 (UTC)
理论上,所有条目最终都应该成为FA或FL。如果可预见该条目无法成为FA,那么该条目必然存在问题--百無一用是書生 () 2021年8月2日 (一) 03:06 (UTC)
(-)反对,關注度只是基本中的基本,但是不代表僅有短期關注度的人物也有成為傳記的資格。 2021年8月1日 (日) 08:04 (UTC)
@Pseudo Classes:請見我與Lt2818的對答,我認為你對提案的本質存在誤解。SANMOSA Σουέζ 2021年8月1日 (日) 11:03 (UTC)
@Sanmosa:提案主旨明明就是1E為何能讓社群有判斷條目重要度的資格?然而,你們討論的是1E本身不言自明,哪來的誤解?我只(-)反对提案主旨。 2021年8月1日 (日) 12:12 (UTC)
@Pseudo Classes:所以你究竟是反對“社群沒有判斷條目重要度的資格”的statement還是“僅有短期關注度的人物有成為傳記的資格”的情況?我可以説兩者並無任何關聯。如果是後者的話,我可以保證就算廢除了1E也沒有這樣的事情,上面我已經做了很多次解釋了。如果是前者的話,那還是得請你再詳細解釋一下情況,好讓我分析一下。SANMOSA Σουέζ 2021年8月2日 (一) 06:50 (UTC)

條目標題、內文及重新導向頁面標題中對SARS-CoV-2的變種的稱呼(第四次)

前次討論位於Wikipedia talk:COVID-19條目共識#條目標題、內文及重新導向頁面標題中對SARS-CoV-2的變種的稱呼(第三次)SANMOSA Σουέζ 2021年7月29日 (四) 08:53 (UTC)

前次討論,參與前次討論的用戶基本上同意我在7月15日提出的新版修訂案,因此這裏我重新提出該版修訂案如下,並附當時一同附上的修訂案主旨:

現行條文

條目標題中對SARS-CoV-2的變種的稱呼 條目標題中如須提及SARS-CoV-2的變種,除非這次提及被包含在專有名詞內,或該SARS-CoV-2的變種的PANGO譜系註冊編號並不存在,否則應使用「〔PANGO譜系註冊編號〕譜系」格式稱呼之。即使該SARS-CoV-2的變種的PANGO譜系註冊編號並不存在,除非這次提及被包含在專有名詞內,否則仍不應使用不準確且可能有歧義的「〔地名〕〔變異重數〕(變種)〔病名/病毒名〕病毒(株)」等類近格式稱呼之。

條目內文中對SARS-CoV-2的變種的稱呼 條目內文中如須提及SARS-CoV-2的變種,除非有提及其他稱呼的必要,或該SARS-CoV-2的變種的PANGO譜系註冊編號並不存在,否則應使用「〔PANGO譜系註冊編號〕譜系」格式稱呼之。條目內文不宜使用不準確且可能有歧義的「〔地名〕〔變異重數〕(變種)〔病名/病毒名〕病毒(株)」等類近格式稱呼SARS-CoV-2的變種,若一定要使用「〔地名〕〔變異重數〕(變種)〔病名/病毒名〕病毒(株)」等類近格式稱呼,則必須括注宣告其指稱對象,且須確保為最低限度的使用。如未有共識支持,手動把SARS-CoV-2的變種的「〔PANGO譜系註冊編號〕譜系」格式稱呼替換為其他同義詞(尤其「〔地名〕〔變異重數〕(變種)〔病名/病毒名〕病毒(株)」等類近格式),将被視同破壞,唯因技術原因、修正筆誤或回退破壞等維護性編輯例外。

重新導向頁面標題中對SARS-CoV-2的變種的稱呼 重新導向頁面的標題中若出現任何並非使用「〔PANGO譜系註冊編號〕譜系」或「〔PANGO譜系註冊編號〕」格式的對SARS-CoV-2的變種稱呼,只要相關稱呼有任何可靠來源使用,該重新導向頁面不應刪除,並使用{{COVID-19重定向}}模板予以標記。如該稱呼可指代多於一種SARS-CoV-2的變種,該名稱則應建立為消歧义頁面,或重新導向至名稱近似且列出多於一種SARS-CoV-2的變種的消歧义頁面。

提議條文

條目標題中對SARS-CoV-2的變種的稱呼 條目標題中如須提及SARS-CoV-2的變種,除非這次提及被包含在專有名詞內,否則:

  1. 在該SARS-CoV-2的變種獲世界衛生組織的命名系統命名的情況下,應使用「严重急性呼吸系统综合征冠状病毒2 〔希臘字母的英文名稱〕變種」(中國大陸)、「嚴重急性呼吸綜合症冠狀病毒2型〔希臘字母的英文名稱〕變種」(香港)、「嚴重急性呼吸道症候群冠狀病毒2型〔希臘字母的英文名稱〕變種」(臺灣)或「严重急性呼吸综合征冠状病毒2 〔希臘字母的英文名稱〕變種」(新加坡)的格式稱呼之(“2”字後接“型”字不加空格,不接“型”字加空格);
  2. 在該SARS-CoV-2的變種未獲世界衛生組織的命名系統命名的情況下,如該SARS-CoV-2的變種的PANGO譜系註冊編號存在,應使用「〔PANGO譜系註冊編號〕(譜系)」格式稱呼之;
  3. 如該SARS-CoV-2的變種的PANGO譜系註冊編號並不存在,則可使用全球共享流感數據倡議組織(GISAID)譜系註冊編號(格式:「〔全球共享流感數據倡議組織(GISAID)譜系註冊編號〕(譜系)」)或Nextstrain英语Nextstrain譜系註冊編號(格式:「〔Nextstrain英语Nextstrain譜系註冊編號〕(譜系)」)稱呼之;
  4. 如該SARS-CoV-2的變種的全球共享流感數據倡議組織(GISAID)譜系註冊編號與Nextstrain譜系註冊編號亦均不存在,則可使用其他有任何可靠來源使用的稱呼稱呼之。惟即使該SARS-CoV-2的變種未獲世界衛生組織的命名系統命名,且其PANGO譜系註冊編號、全球共享流感數據倡議組織(GISAID)譜系註冊編號與Nextstrain英语Nextstrain譜系註冊編號均不存在,除非這次提及被包含在專有名詞內,否則仍不應使用不準確且可能有歧義的「〔地名〕〔變異重數〕(變種)〔病名/病毒名〕病毒(株)」等類近格式稱呼之。

條目內文中對SARS-CoV-2的變種的稱呼 條目內文中如須提及SARS-CoV-2的變種,除非有提及其他稱呼的必要,否則:

  1. 在該SARS-CoV-2的變種獲世界衛生組織的命名系統命名的情況下,應使用「〔希臘字母的英文名稱〕變種(病毒)」格式稱呼之;
  2. 在該SARS-CoV-2的變種未獲世界衛生組織的命名系統命名的情況下,如該SARS-CoV-2的變種的PANGO譜系註冊編號存在,應使用「〔PANGO譜系註冊編號〕(譜系)」格式稱呼之;
  3. 如該SARS-CoV-2的變種的PANGO譜系註冊編號並不存在,則可使用全球共享流感數據倡議組織(GISAID)譜系註冊編號(格式:「〔全球共享流感數據倡議組織(GISAID)譜系註冊編號〕(譜系)」)或Nextstrain英语Nextstrain譜系註冊編號(格式:「〔Nextstrain英语Nextstrain譜系註冊編號〕(譜系)」)稱呼之;
  4. 如該SARS-CoV-2的變種的全球共享流感數據倡議組織(GISAID)譜系註冊編號與Nextstrain譜系註冊編號亦均不存在,則可使用其他有任何可靠來源使用的稱呼稱呼之,惟仍須遵守以下有關「〔地名〕〔變異重數〕(變種)〔病名/病毒名〕病毒(株)」等類近格式的規定。

條目內文不宜使用不準確且可能有歧義的「〔地名〕〔變異重數〕(變種)〔病名/病毒名〕病毒(株)」等類近格式稱呼SARS-CoV-2的變種,若一定要使用「〔地名〕〔變異重數〕(變種)〔病名/病毒名〕病毒(株)」等類近格式稱呼,則必須括注宣告其指稱對象,且須確保為最低限度的使用。如未有共識支持,把SARS-CoV-2的變種的「〔希臘字母的英文名稱〕變種病毒」、「〔PANGO譜系註冊編號〕(譜系)」、「〔全球共享流感數據倡議組織(GISAID)譜系註冊編號〕(譜系)」或「〔Nextstrain英语Nextstrain譜系註冊編號〕(譜系)」格式稱呼之間進行手動互相替換,或手動把它們替換為其他同義詞(尤其「〔地名〕〔變異重數〕(變種)〔病名/病毒名〕病毒(株)」等類近格式),或在其他同義詞之間進行手動互相替換,将被視同破壞,唯因技術原因、修正筆誤或回退破壞等維護性編輯例外。

重新導向頁面標題中對SARS-CoV-2的變種的稱呼 重新導向頁面的標題中若出現任何並非使用「〔希臘字母的英文名稱〕變種病毒」、「〔PANGO譜系註冊編號〕(譜系)」、「〔全球共享流感數據倡議組織(GISAID)譜系註冊編號〕(譜系)」或「〔Nextstrain英语Nextstrain譜系註冊編號〕(譜系)」格式的對SARS-CoV-2的變種稱呼,只要相關稱呼有任何可靠來源使用,該重新導向頁面不應刪除,並使用{{COVID-19重定向}}模板予以標記。如該稱呼可指代多於一種SARS-CoV-2的變種,該名稱則應建立為消歧义頁面,或重新導向至名稱近似且列出多於一種SARS-CoV-2的變種的消歧义頁面。

世界衛生組織對SARS-CoV-2的變種的命名系統 現時,世界衛生組織對SARS-CoV-2的變種的命名系統的格式為「〔希臘字母的英文名稱〕變種(病毒)」。如所有希臘字母均已使用於命名SARS-CoV-2的各個變種,使世界衛生組織需要啓用新的命名系統,並導致使用原有命名系統的SARS-CoV-2的變種均出現名稱變更,則使用原有命名系統的SARS-CoV-2的變種的條目的名稱應在新的命名系統啓用後隨新的命名系統的命名方式作出名稱變更。

新版修訂案的主旨如下:

  1. 在條目名稱與條目內文敘述中改用世界衛生組織的命名系統的命名(「〔希臘字母的英文名稱〕變種(病毒)」格式)稱呼變種病毒;
  2. 允許在變種病毒未獲世界衛生組織的命名系統命名,且其PANGO譜系註冊編號並不存在的情況下,使用全球共享流感數據倡議組織(GISAID)譜系註冊編號(「〔全球共享流感數據倡議組織(GISAID)譜系註冊編號〕(譜系)」)或Nextstrain譜系註冊編號(「〔Nextstrain譜系註冊編號〕(譜系)」)稱呼變種病毒;
  3. 允許在前條的前提下,如變種病毒的全球共享流感數據倡議組織(GISAID)譜系註冊編號與Nextstrain譜系註冊編號均不存在,可使用「〔地名〕〔變異重數〕(變種)〔病名/病毒名〕病毒(株)」等類近格式以外有任何可靠來源使用的稱呼稱呼變種病毒;
  4. 允許使用「〔PANGO譜系註冊編號〕(譜系)」、「〔全球共享流感數據倡議組織(GISAID)譜系註冊編號〕(譜系)」或「〔Nextstrain譜系註冊編號〕(譜系)」以上三種格式的標題的重新導向頁面無須使用{{COVID-19重定向}}模板予以標記;
  5. 預留世界衛生組織在所有希臘字母用盡並啓用新命名系統後中文維基百科條目快速更名的空間;

以上。SANMOSA Σουέζ 2021年7月29日 (四) 08:53 (UTC)

  • 1.请给出一个“〔地名〕〔變異重數〕(變種)〔病名/病毒名〕病毒(株)”的例子,目前我没有见到这样格式的称呼 2.请提供“世界卫生组织用尽所有希腊字母”的可靠来源——落花有意12138 回复请ping我 2021年7月30日 (五) 07:54 (UTC)
    (1)方括號代表的是可有可無的詞匯的屬性,圓括號代表的是可有可無的固定詞匯。“印度雙重變種新冠病毒株”是把“〔地名〕〔變異重數〕(變種)〔病名/病毒名〕病毒(株)”中所有的可有可無的屬性詞匯與固定詞匯都全部用掉,而“印度變種病毒”則沒有。(2)我不明白你問這個問題是基於甚麽邏輯,“世界衛生組織對SARS-CoV-2的變種的命名系統”一段是對未來世界衛生組織對SARS-CoV-2的變種的命名系統出現可能的變更的預留條文,也就是説如果世界衛生組織修改了對SARS-CoV-2的變種的命名系統,但中文維基百科不能及時修改規則,那就可以根據“世界衛生組織對SARS-CoV-2的變種的命名系統”一段先行進行更新動作。SANMOSA Σουέζ 2021年7月30日 (五) 08:23 (UTC)
    已了解,(✓)同意此提案。——落花有意12138 回复请ping我 2021年7月31日 (六) 05:43 (UTC)

希望确认维基对YouTube/Bilibili/Tiktok等视频网站作为参考资料的标准

经常看到这些问题,比如这篇[2]和这篇[3]的理由。请问现在维基对这样的情况是执行什么标准?Bagida520留言) 2021年7月30日 (五) 11:45 (UTC)

(※)注意:youtube等嚴格來說不是來源,而是轉載平台。例如用戶把某電視台的專訪節日上載到youtube,我們要驗證的是電視台的專訪節目,而不是youtube的網站。--蟲蟲飛♡♡→♡℃留言 2021年7月31日 (六) 04:27 (UTC)
@Bagida520:未见有相关共识,但是可以从Wikipedia:可靠来源#采用在线或者作者自行发表的来源得到,大多数自行发表的内容均不是可靠来源,但是存在特例。您可以提案修订相关方针。另外,请不要单用“维基”指代维基百科,见WP:WIKI——落花有意12138 回复请ping我 2021年7月31日 (六) 04:44 (UTC)

提議新增條目編輯員

已經有模板編輯員怎麼可以少了條目編輯員呢?條目是維基百科最重要的一部分,往往被全保護後就因沒有管理員參與該專輯,導致長時間沒有更新,嚴重降低品質,然而延伸確認權限長時間卡關,這樣的情況我覺得不能拖太久,甚至存在性比模板編輯員重要,所以提出了條目編輯員當作備案,也可與延伸確認權限並存(因為高編輯數有時候也會參與編輯戰),草案見此(英語維基百科管理員多比較沒有這個問題)。--天蓬大元帥-會客 閱讀機器翻譯放鬆一下 2021年7月30日 (五) 13:18 (UTC)

(-)反对:未见设立必要。--Lightyears GBAW 2021年7月30日 (五) 13:38 (UTC)
同SCP-2000,反建議恢復非永久任期(有任期結束日)的管理員的制度。SANMOSA Σουέζ 2021年7月30日 (五) 13:52 (UTC)
好奇插個(?)疑問,那麼二二八事件怎麼說?真有更新的必要嗎?--Z7504非常建議必要時多關注評選留言) 2021年7月30日 (五) 14:03 (UTC)
可能有針對二二八事件的新研究和新言論、表態等,或許是真的存在更新的必要的。SANMOSA Σουέζ 2021年7月30日 (五) 14:08 (UTC)
  • (-)傾向反對,基本上不論破壞會進到全保護也只有編輯爭議了,最大宗想當然是政治,那授權條件需不需要處理此類問題及授權者的判斷標準是否中立-- Sunny00217  2021年7月30日 (五) 14:16 (UTC)
  • (-)反对,我以为这是坏笑话,中文wiki的用户乃至管理员因为政治见解争执导致的麻烦不少了。编辑战往往锁定一段时间会消失的。--仁爱亲诚——Pavlov2 2021年7月30日 (五) 14:40 (UTC)

註:此處原有文字,因為我的梯子才是坏笑话,已由仁爱亲诚——Pavlov2於2021年7月30日 (五) 14:56 (UTC)刪除,尚祈見諒。若有異議請至互助客棧或向管理員反映。

更改模板編輯員的硬性授權條件

巡查權、回退權皆要求是「最近一年內沒有受到封鎖(不合理封鎖除外)」(個人是不知道到底包不包含部分封鎖,因為設立的年代尚未有部分封鎖),然而模板編輯員只要求「最近半年內沒有受到封鎖(不合理封鎖除外)」,似乎太鬆了。因此提議:

現行條文

授權準則 如果您想申請模板編輯員的權限,請參見Wikipedia:權限申請/申請模板編輯權。由於管理員擁有模板編輯員的權限,因此管理員不需要額外獲得此權限。

模板編輯員的權限可由任何管理員授權。管理員必須要自己評估申請者的模板貢獻質量,獲得模板編輯員的權限的基本要求是:

  1. 申請者必須要註冊至少一年。
  2. 申請者至少要有1000次編輯數。
  3. 申請者至少要有150次模板及模組的總編輯數。
  4. 申請者必須在半年內沒有被封禁過。(不合理封禁除外)

另外,申請者應該要已經表現出對於權限的需求,以及熟悉處理高風險模板修改時所需的關注和責任:

  1. 申請者必須至少要在三個受保護的模板的模板測試沙盒內協助編輯。
  2. 申請者必須至少請求並已成功的對受保護的模板進行了五次重要編輯。

以上項目只是指導原則。管理員可以選擇其他替代編輯能力來證明申請者已經有處理高風險模板的責任。

提議條文

授權準則 如果您想申請模板編輯員的權限,請參見Wikipedia:權限申請/申請模板編輯權。由於管理員擁有模板編輯員的權限,因此管理員不需要額外獲得此權限。

模板編輯員的權限可由任何管理員授權。管理員必須要自己評估申請者的模板貢獻質量,獲得模板編輯員的權限的基本要求是:

  1. 申請者必須要註冊至少一年。
  2. 申請者至少要有1000次編輯數。
  3. 申請者至少要有150次模板及模組的總編輯數。
  4. 申請者必須在一年內沒有被封禁或在模板/模組命名空間被部分封鎖過。(不合理封禁除外)

另外,申請者應該要已經表現出對於權限的需求,以及熟悉處理高風險模板修改時所需的關注和責任:

  1. 申請者必須至少要在三個受保護的模板的模板測試沙盒內協助編輯。
  2. 申請者必須至少請求並已成功的對受保護的模板進行了五次重要編輯。

以上項目只是指導原則。管理員可以選擇其他替代編輯能力來證明申請者已經有處理高風險模板的責任。

以上,請討論。這根本是坑自己的提案。-- Sunny00217  2021年7月30日 (五) 14:28 (UTC)

引入部分封禁后应该把Wikipedia:權限申請#要求以及各具体权限方针的所有相关条文都理一遍。我个人觉得应该去除这些硬性要求,但说明“近一年内受到封禁(含部分封禁)者,管理员有权拒绝授予权限”。--GZWDer留言) 2021年7月31日 (六) 02:15 (UTC) +1
模板編輯員應該是比較技術性的權限。封鎖不一定代表某使用者不適任。應該要讓管理員判斷。到底爲什麼要搞這種坑自己的提案(((--Papayatrash留言} 2021年7月31日 (六) 11:17 (UTC)
相對。巡退沒什麼技術要求都要一年了-- Sunny00217  2021年8月1日 (日) 01:51 (UTC)
(+)支持:模板編輯員已經是半個管理員了,提高要求也好。--蟲蟲飛♡♡→♡℃留言 2021年8月1日 (日) 02:14 (UTC)
可比照巡退。我申請權限的時候還要自行論證5個多月前的封鎖為「不合理封鎖」。SANMOSA Σουέζ 2021年8月1日 (日) 03:12 (UTC)
這標準理應不難達成,但是有好有壞,好是管理員更方便審核,壞是封鎖不一定代表不適任,就如 Papayatrash 所述的一樣。 2021年8月1日 (日) 08:11 (UTC)
引入部分封鎖時沒有考量到這點,那麼封鎖應該就仍然包含所有種類的封鎖。--Xiplus#Talk 2021年8月1日 (日) 12:29 (UTC)

新增快速刪除位於不恰當命名空間消歧義的準則

原标题为:有關快速刪除方針條文增修的事宜

有鑒於最近的部分存廢討論(12345),建議容許快速刪除任何位於模板空間的消歧義頁面(不論是否引用消歧義模板消歧義訊息模板),並增設新條文專門處理。擬議條文具體如下:

以上。SANMOSA Σουέζ 2021年8月1日 (日) 10:57 (UTC)

@YumetoDreamerBlue羊羊32521SANMOSA Σουέζ 2021年8月1日 (日) 10:57 (UTC)
  • 建議主、使用者、草稿以外空間均適用。 紺野夢人 肺炎退散 2021年8月1日 (日) 11:05 (UTC)
  • 本人意见基本同上,但建议可以将项目空间、专题空间也纳入适用例外。--DreamerBlue留言) 2021年8月1日 (日) 12:34 (UTC)
  • 同上,再把使用說明也納入例外-- Sunny00217  2021年8月1日 (日) 15:20 (UTC)
  • 需要注意怎么定义“消歧义页”(WP:UCS?);哪些模板真的是“模板消歧义”,而哪些是“消歧义模板”[1];挂{{Disambiguation}}的模板并不都是消歧义页。适用空间赞同Yumeto,暂时看不出来项目、专题和说明有什么使用消歧义的必要。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月2日 (一) 01:27 (UTC)
    • 项目、专题空间消歧义主要是参照英文维基百科,对部分捷径/快捷方式进行消歧义。--DreamerBlue留言) 2021年8月2日 (一) 03:20 (UTC)
      那专题应该没必要吧?用主从消歧义就好了。-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月2日 (一) 11:01 (UTC)
@YumetoDreamerBlue羊羊32521:暫時把擬議編號改為G17,以順應擬議適用範圍的擴大。專案、專題與說明空間是否適用可以再討論。「消歧義頁」的定義應依循Wikipedia:消歧义給出的解釋(某程度上可以算WP:UCS,但畢竟我也給了指引連結)。特別加入了條款防止誤刪消歧義模板的情形。“掛{{Disambiguation}}的模板並不都是消歧義頁”的情形我不太清楚,可能需要進一步解釋,這樣有助於我改善提案。SANMOSA Σουέζ 2021年8月2日 (一) 06:42 (UTC)
@Sunny00217SANMOSA Σουέζ 2021年8月2日 (一) 07:05 (UTC)
{{Make Disambiguation 2}} ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月2日 (一) 11:02 (UTC)
@羊羊32521:再調整了一下。SANMOSA Σουέζ 2021年8月2日 (一) 14:01 (UTC)
另外Wikipedia:消歧义好像没有消歧义页的定义? ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月2日 (一) 11:03 (UTC)
英文原文“Disambiguation”本身就是“消除歧义”的名词,从翻译的角度其实方针叫“消歧义页”比较好。--DreamerBlue留言) 2021年8月2日 (一) 13:18 (UTC)
(✓)同意。上面提到的何为消歧义页实际不是问题,任何一名编辑,甚至读者都可以分辨出。——落花有意12138 回复请ping我 2021年8月2日 (一) 13:23 (UTC)
我還是認為使用說明也要列入-- Sunny00217  2021年8月3日 (二) 11:13 (UTC)
@Sunny00217:還請説明詳細原因。SANMOSA Σουέζ 2021年8月3日 (二) 13:14 (UTC)
基本上跟計劃頁面一樣-- Sunny00217  2021年8月3日 (二) 13:24 (UTC)
项目页面DreamerBlue君是说参考英维的捷徑消歧义(比如en:WP:DC),但个人认为使用说明应该没必要用消歧义页吧?主从消歧义应该就能解决? ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月3日 (二) 14:14 (UTC)
@Sunny00217SANMOSA Σουέζ 2021年8月4日 (三) 01:22 (UTC)

参考資料

重提調整檔案使用守則

建議修改WP:文件使用方针中的‘影片適用的使用守則’部分如下:

此外,亦建議設置過濾器,阻止加入曾被移除的影片的操作(通過Twinkle或回退功能恢復加入則不阻止),並對所有使條目同時存在多於五條影片的操作予以警告,同時對此兩類操作(無論是否已被阻止或警告)予以標籤。以上。SANMOSA Σουέζ 2021年8月3日 (二) 00:05 (UTC)

观乎存档:上一个提案的最后回复时间是6月10日,所提出的内容和本案一模一样,并没有显著的支持,反而有显著的反对(Ericliu1912等)。不知道阁下反复提出这种社群不支持的提案,意义何在?何况这也不是微调了。--DreamerBlue留言) 2021年8月3日 (二) 02:13 (UTC)
容許我調整標題。@DreamerBlue:我這次是第二次提出,我不認為是“反覆提出”,而且我認為應該給社群一次重新審視提案的機會。請留意提案也包括上面留言中“此外”後的句子,至少那部分是沒有人反對的。SANMOSA Σουέζ 2021年8月3日 (二) 03:02 (UTC)

命名常規(方針) § 括号的使用2

舊有迷思觀念澄清:這是關於命名方式,有括號也與消歧異無關,維基百科沒有任何「條目名稱有括號=消歧義」的說明,若無具體解決方法毋須發表意見,謝謝!

由於上次的討論沒結果,故在此重新討論,希望能得到一個有效的解決方法

事發經過:Iokseng於7月7日移動22個已停駛的台中市公車頁面(且無視先前的共識)至現存的台中市公車公車路線,如下:

那我與XComhghall就以上條目的命名在 User_talk:Iokseng#錯誤的重新導向衍生的問題 展開了一場討論,詳情就不再此贅述。

雖然Iokseng不滿這些條目命名的方式,但他仍保留了「台中市公車291路 (2013年)」(此條目確實是消歧異),我覺得最莫名其妙的一點是「 (2013年)」的命名方式是從哪來的,不也是從 分類討論:台中市公車路線#廢線條目名稱 來的嗎?好,那就是他承認這樣的命名方式嘛!

再來看該管理員做出這樣的移動會造成以下情形發生:

  1. 混淆讀者:此路線是否停駛應該從條目就要看的出來,不是被動的從內文不清不楚的展現。
  2. 非常不整齊:一樣是停駛路線(不管是不是消歧異)卻有兩種命名方式,以後有停駛路線該如何命名?
  3. 未經任何討論或告知:先前有加括號的名稱都是有經過討論的,他有意見卻沒有任何告知就擅自更改。

參見

若無異議將會恢復原狀--Bus Follower留言) 2021年8月3日 (二) 05:34 (UTC)

半角括号通常仅用于消歧义,是在社群长期实践当中形成的事实上的共识。这种括号的使用方式放在某专题条目中还可以试试,扩大到方针的角度就没必要了
“此路線是否停駛應該從條目就要看的出來”——本人的理解是,从标题一眼看出来——但为什么要这么做呢?似乎必要性不足。
“一樣是停駛路線(不管是不是消歧異)卻有兩種命名方式,以後有停駛路線該如何命名?”该怎么命名怎么命名,消歧义的关键词,是要找出一个区别于主条目的特征。
“好,那就是他承認這樣的命名方式嘛!”本人认为这是有问题的,2013年并非两条线路的关键区别特征,“2013年停驶”才是。
“先前有加括號的名稱都是有經過討論的”本人认为讨论确实形成了共识,但从讨论的范围来看,这种共识仅限于台中市公车的范畴,而很多人并不知道这个共识的存在。从上次讨论来看,从整个社群的角度,对于这种括号的使用方式,很多人并不买账。--DreamerBlue留言) 2021年8月3日 (二) 05:46 (UTC)
(-)強烈反对所謂「恢復原狀」,此所謂「共識」違反共識方針 § 共识的级别章節明確寫明:「部分編者在特定地方和時間所達成的共識,不能凌駕更廣泛的社群共識。例如,维基专题的参与者不能擅自决定某些通用的方针与指引不适用于该专题的条目,除非能说服更广泛的社群去同意他们的见解。」有關所謂共識顯然不當地凌駕於屬於方針級別命名常規 § 括号的使用,故可被界定為無效或無效力的共識,任何用戶因遵守方針而忽略與方針存在牴觸的「共識」均不存在問題。(例:不可能在條目參與者自行達成共識「認為」一個條目存在關注度,但實際仍然違反關注度指引而保留不符合收錄條件的條目)
根據具有「更廣泛的社群共識」的命名常規方針,條目標題中括號的使用只包含作消歧義用途(或名從主人)。觀以上列出條目,大部分顯然沒有消歧義的必要(不存在同名的條目/同號的路線),故管理員Iokseng君的移動操作是顯然符合方針要求的;而相對保留台中市公車291路 (2013年)DreamerBlue再移動至台中市公車291路 (2013年停駛))則因為實際存在同名的條目/同號的路線,而非所謂「認可命名方式」,我甚至認為如沒有出現多次停駛再重新利用同號開新路線,根本無需以年份作區別(已停駛的「台中市公車291路」只有一條),只需要以「已停駛」作消歧義已經足夠,直至未來出現兩條已停駛的同號路線才有加入年份作消歧義的需要。
閣下同時提出該等移動操作存在三個問題:
  1. 混淆讀者:此路線是否停駛應該從條目就要看的出來,不是被動的從內文不清不楚的展現」——您是否看到所有沒有需要消歧義的死者條目標題全部有加上生卒年?Yumeto君也在您在巴士維基專題發起的討論中提到「琉球國 (1879年)大韓帝國 (1910年滅亡)清朝 (1636年-1912年)俄羅斯帝國 (滅亡)蘇聯 (已滅亡)」等同類型毫無必要的消歧義例子。
  2. 非常不整齊:一樣是停駛路線(不管是不是消歧異)卻有兩種命名方式,以後有停駛路線該如何命名?」——同上,是否所有人物條目,不管有無消歧義都要加上生卒年?顯然不合理,同時更對加入內部連結造成麻煩。
  3. 未經任何討論或告知:先前有加括號的名稱都是有經過討論的,他有意見卻沒有任何告知就擅自變更。」——上方已述,你提出所謂「經過討論」的「共識」並不符合方針要求,Iokseng君無責任跟從;而Iokseng君的移動操作為建基於方針的操作,將違反廣泛共識所訂立之方針的條目標題移動至正確符合方針要求的標題無需經過另外討論,因為訂立方針時已經進行過討論了;Iokseng君更沒有義務要告知你們他的操作。
同時在閱讀您在Iokseng君討論頁的留言,閣下態度顯然不當,嚴重違反了本站的文明方針或涉嫌把維基百科當成戰場,在此對閣下作出Nuvola apps important.svg 強烈警告,若閣下再次對任何用戶作出不禮貌的行為,我或任何其他用戶均有權利將閣下的不文明行為提交至相關佈告版要求管理員處置。
以上,--路西法人留言 2021年8月3日 (二) 06:54 (UTC)
另外就閣下提出「條目名稱有括號不等於消歧義」且「此為命名方法而非消歧義」的論點,此與您所要求「區分現有及停辦路線」(您在此討論的原文:「那該怎麼區分停駛與現行路線的名稱呢」)存在顯然的矛盾,提出用以分辨(與區分同義)兩個不同的項目(存在與否)已經表示此顯然已經作為消歧義的意思了,故「這是關於命名方式,有括號也與消歧[義]無關」的說法並不成立。--路西法人留言 2021年8月3日 (二) 07:08 (UTC)
@LuciferianThomas:麻煩你把上面的第3點轉告給Jarodalien,我覺得你説得很有道理。SANMOSA Σουέζ 2021年8月3日 (二) 07:30 (UTC)
???不明白你想表達什麼。--路西法人留言 2021年8月3日 (二) 07:32 (UTC)
“將違反廣泛共識所訂立之方針的條目標題移動至正確符合方針要求的標題無需經過另外討論,因為訂立方針時已經進行過討論了”這點我很認同,但他不認同。我當時甚至還已經盡了告知的義務。雖然上面説的是氣話,但這裏的意思是認真的。SANMOSA Σουέζ 2021年8月3日 (二) 07:45 (UTC)
説回正題:(根據WP:CONLIMITED的規定)我認為LuciferianThomas説的話有道理,因此我並不主張Bus Follower的命名方式。甚至在撇除這些前提的情況下,Bus Follower的主張也是沒有道理的:這裏容許我類推一下:九龍巴士2號線是現在還在營運的,九龍巴士4號線則是早已停駛的,至於現在還在營運的九龍巴士5M線的編號曾經用在另一條早已停駛的巴士路綫上;然而這種命名方式從來沒有引起過任何問題,因此“非常不整齊”並不成立;如果因此把九龍巴士4號線改稱“九龍巴士4號線 (1983年)”明顯非常怪異。巴士路綫的命名一致性應該是現存的或最晚停駛的巴士路綫占用主條目的名字,其他相同編號的加消歧義括號進行消歧義。SANMOSA Σουέζ 2021年8月3日 (二) 07:45 (UTC)
LuciferianThomas:冷靜~~我們都心平氣和地講,您無須加註「強烈反對」「強烈警告」等無助於討論的字眼,這樣的發言無助於事情解決且這裡是「互助客棧」,若您堅持留言,本人給予尊重,請您不要再僵持於這些脫離主題的事情,謝謝... -- Bus Follower留言

我受夠了喔!!就已經復原你的留言了還想怎樣啦!變本加厲的是你,先不自請來的先「警告」抨擊,還持續做攻擊,這才叫不文明吧?有什麼好抗議的?我鄭重警告你,這場無聊的紛爭已經結束,可以不要像小孩一樣一直追究於某事物嗎? 2021年8月3日 (二) 11:07 (UTC)

「我們都心平氣和地講」您沒有。—— Eric Liu 創造は生命(留言留名學生會 2021年8月3日 (二) 11:26 (UTC)
同樓上-- Sunny00217  2021年8月3日 (二) 15:05 (UTC)
(!)強烈抗议Bus Follower修改他人留言和不文明留言的舉動,此行為嚴重違反本站規則,將予以提報至管理員佈告版請求處置!--路西法人留言 2021年8月4日 (三) 02:52 (UTC)
(!)強烈抗议(!)強烈抗议(!)強烈抗议用戶直接刪除本人沒有違反討論頁指引的言論,自己在對他人人身攻擊(12),本人按照討論頁指引予以警告竟出言不遜,行為嚴重擾亂客棧討論,已要求管理員處理!--路西法人留言 今天, 01:53 pm (UTC+8)
  • 不同意「此路線是否停駛應該從條目就要看的出來」,條目內容才是重點;至於命名問題,維基百科現行規定就是這樣處理的,路線停駛與否本身並不影響條目命名,有無因此產生的同名條目才是消歧義的重點。如果沒有,那就不用消歧義。個人完全支持Iokseng閣下的操作。(話說將這些公車線路併在同一個條目敘述然後用不同章節區分可行嗎?)—— Eric Liu 創造は生命(留言留名學生會 2021年8月3日 (二) 11:26 (UTC)
  • 還是那句話,沒經社群認證的共識都是小圈圈自嗨。 --Loving You Is A Losing Game 2021年8月3日 (二) 12:57 (UTC)
    沒經社群認證的共識都是小圈圈自嗨[來源請求]WP:IAR呢-- Sunny00217  2021年8月3日 (二) 15:08 (UTC)
方针指引是大框,个别小讨论也不能超出这个框架。IAR一来是创世条款之一,有其特殊性(另给予正式方针地位,也是不算久远的事),二来只是作为争辩的开口,但能不能买账是看情况。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年8月4日 (三) 02:50 (UTC)
這裏如果有共識的話,通過後寫入Wikipedia:條目命名一致性決議吧,畢竟這是NC:一致性的規定。SANMOSA Σουέζ 2021年8月3日 (二) 13:10 (UTC)
  • 歪个楼,我倒是觉得命名一致性很怪,不知道有没有理解错误,就是这样命名的条目多了它就突然变成方针了……而一致性决议更适合独立成新的命名常规。我建议把NC:一致性改成*拟定命名常规时的参考规则*,而不是强制规则,更不是把“约定俗成”制度化。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月3日 (二) 14:08 (UTC)
@羊羊32521:如果不是後來出現了頁面命名的亂象,用得著這樣嗎?SANMOSA Σουέζ 2021年8月3日 (二) 14:45 (UTC)
这倒是不清楚。在下去看了英维的命名常规,确实有"Consistency"列在 “A good Wikipedia article title has the five following characteristics”中,但说明了 These [characteristics] should be seen as goals, not as rules. 我觉得这才是合理的状态。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月4日 (三) 00:18 (UTC)
@羊羊32521:zhwiki又不是enwiki的中文版,“seen as goals, not as rules”的前提是社群有自律的意識。SANMOSA Σουέζ 2021年8月4日 (三) 01:21 (UTC)
經歷這次討論,我大略知道大家都有「逢括號必反」的感覺(因為許多編者都認為是消歧義),好,那如果使用「沒有括號」的標題,是否就行得通呢? -- Bus Follower留言) 2021年8月4日 (三) 04:25 (UTC)
我猜个栗子:“台中市公车16路 2016年废弃”,什么意思呢?有一个事物叫做“台中市公车16路 2016年废弃”?本质没理解一个问题,除了因为同名消歧义的需要,为什么在条目命名添加额外的信息,而且这些信息是条目正文就可以表达的,读者是不是真的需要看到这些消息,或者说这只是某些编者的一厢情愿或一己之利?——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年8月4日 (三) 05:46 (UTC)
恭喜你猜錯了,為什麼一定要加在條目後面?我的想法是加在前面,如:「已停駛的台中市公車16路」 ,但我想這已經不牽涉到消歧義,應該是由交通圈的編者來思考,不須由全部編者討論-- Bus Follower留言) 2021年8月4日 (三) 06:31 (UTC)
哦这样啊,那就请问有一个事物叫做“已停駛的台中市公車16路”?或者说參考弄個已滅亡的俄羅斯帝國已滅亡的蘇聯等。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年8月4日 (三) 07:39 (UTC)
同Cwek。容許我老實說,就算你加在前面或加在中間,其實也是有消歧義的效果的,只不過消歧義括號就只能夠加在後面而已。對標題的消歧義處理並不一定需要括號,因此現在討論的東西其實是有沒有對標題進行消歧義處理的必要,而非標題能否有括號。SANMOSA Σουέζ 2021年8月4日 (三) 10:43 (UTC)
即使考虑小圈子的问题,一个在某个角落的分类讨论得出的共识,远不及面向全站的方针或指引页面,或者一个面向大专题的指引或指导“靠谱”。(可以参考WP:ACGWikiProject:电子游戏的指引等信息,甚至命名规则也同样列出总页面WP:命名常规之中),我认为这次的问题就在这里,管理员不知道也不需要按照某个角落确立的讨论共识,对于他而言,WP:命名常规WP:消歧义更有依照意义。如果分要考虑的话,至少在对应专题有相应的单独指引页或者在全站的指引或方针页面上有列出,这样才有更多过路处理的直到有这些讨论共识的存在,才不会有意料之外的结果。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年8月4日 (三) 07:47 (UTC)

关于傀儡方针的询问

已解决:
 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月4日 (三) 00:04 (UTC)
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

已经因为持续破坏/违反傀儡政策而导致主账号被封禁后,其自主声明的傀儡账号是否也需要一并封禁? 这一问题是来自于lta:逆襲的天邪鬼,他有大量的傀儡用户未被封禁--仁爱亲诚——Pavlov2 2021年8月3日 (二) 18:05 (UTC)


本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

关于规避cu的破坏者怎么对付

已经有人持续在wp未半保护的页面不断添加规避cu的教学,是否应该知会wikimedia的技术部门找找新方法?


另,这些破坏者多出自伪基百科,如果他们在自己的地盘写规避cu教程培养出一堆真人傀儡又怎么办?--仁爱亲诚——Pavlov2 2021年8月3日 (二) 22:28 (UTC)

沒什麼辦法的。--Papayatrash留言} 2021年8月4日 (三) 00:44 (UTC)
瀏覽器能採集到的數據就那些,沒別的了。--Papayatrash留言} 2021年8月4日 (三) 02:28 (UTC)
CU等数据都是用户侧可控的,这方面的技术没啥好方法(尤其考虑到我们站点的特殊性,还大量允许使用类Proxy的地址,怀念Jimmy-bot本地批量封这些可能地址的日子……)。现在可能比较见效的,就是过滤器,因为无非经常提那些字眼,摸透了有可能截下一部分,还有就是有“无聊人”随时恭候(回退、封号、上保护),“无聊人还得靠无聊人去治”。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年8月4日 (三) 02:43 (UTC)
如果可以的话,写一个机器人或者自动编辑框架,识别出这种类似行为,自动回退,发警告,封号,上保护,一气呵成,全自动化迎击,看人可怕还是萝卜可怕。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年8月4日 (三) 03:01 (UTC)
找技術帝執行而已,基本上只要有合適的RegExp就好-- Sunny00217  2021年8月4日 (三) 03:17 (UTC)
或可尝试分词后机器学习对编辑进行分类,毕竟对面破坏上机器简单,我们难--仁爱亲诚——Pavlov2 2021年8月4日 (三) 05:54 (UTC)