置顶公告:【置顶】关于临时开启评论区所有功能的公告(2022.10.22) | 【置顶】关于本站Widget恢复使用的公告
  • 你好~!欢迎来到萌娘百科镜像站!如需查看或编辑,请联系本站管理员注册账号。
  • 本镜像站和其他萌娘百科的镜像站无关,请注意分别。

萌娘百科討論:提案/已通過提案/關於進一步規範討論空間的提案(2022.01.16)

萌娘百科,萬物皆可萌的百科全書!轉載請標註來源頁面的網頁連結,並聲明引自萌娘百科。內容不可商用。
跳至導覽 跳至搜尋

序言

當前提案包含對萌娘百科:討論區管理方針的修訂完善(全文替換)與對萌娘百科:提案中頁面格式的進一步規範(修訂)。高三的維護人員對不起了,我之後還有一個提案,得先進行這個了( —— ほしみ 2021年12月27日 (一) 15:59 (CST)

正文

討論區管理方針

本頁面是針對萌娘百科的討論區而制定的管理方針,針對討論頁面的論述請參見萌娘百科:討論頁面,評論區管理政策請參見萌娘百科:評論區管理方針中的相關內容。

萌娘百科的討論區是萌娘百科的一部分,可分為公共討論頁(包含Talk、萌娘百科 talk、Template talk等)與用戶討論頁(User talk)。

  1. 用戶應參照本方針進行發言或討論;
  2. 管理員巡查姬應當處理不符合方針的內容。

內容

  1. 涉及到以下內容的討論應當被維護人員刪除並警告:
    1. 危害國家及社區安全的敏感信息;
    2. 淫穢色情內容;
    3. 無關廣告類內容;
    4. 欺詐連結/釣魚木馬/捐款購買連結等內容;
    5. 其他由維護人員討論後主觀認定的特殊情形;
    • 一般情況下,維護人員應使用{{InvalidSpeech}}標記刪除發言。
  2. 討論頁上的多項內容原則上需大體符合時間順序,包括:
    1. 同一討論頁上的多個話題;
    2. 對同一條發言的多條回復;
    3. 同一話題下的多條直接非回復性發言。
  3. 原則上不允許用戶修改或刪除他人或自己的討論內容,以下情況除外:
    1. 使用刪除線划去自己的發言或投票;
    2. 修復自己近期發言的排版或錯別字;
    3. 在您發言後且無他人參與當前討論串前的一小段時間內繼續編輯您的發言以稍作改進,但不得改變初次發言中的原意;
    4. 對特定討論頁的格式進行排版優化;
    5. 為未簽名用戶的討論補標發言者名稱與時間戳;
    6. 移除假造其他用戶發言的簽名並補標發言者名稱與時間戳;
    7. 對導致界面排版錯誤的發言進行必要修復,以維護討論區秩序。但不應改變發言者表述內容;
    8. 對討論串進行合理的剪切移動。且應同時使用{{movedto}}與{{movedfrom}}進行標記;
    9. 其它政策文件中許可的行為(如萌娘百科:提案允許提案發起人修訂提案);
    10. 行政員特別許可的頁面維護行為(如Cewbot[更多]對話頁貢獻上傳歷史封鎖及歷史被刪貢獻移動日誌巡查日誌使用者權限及日誌使用者查核失效錨點的維護需要增刪討論頁內容)[改 1]
    11. 其它由維護人員討論後主觀認定的特殊情況。
  4. 用戶在討論頁的發言應當文明友善。
  5. 用戶不應當在討論頁加入其它名字空間專用的分類。
  6. 用戶在討論頁發言後應當簽名,簽名須符合簽名之規定[改 2]
  7. 無需創建無有效討論內容的討論頁以下討論頁允許進行存廢處理[改 3]
    1. 符合萌娘百科:方針#應當被立即刪除的內容之規定或本節第一條提到的情形;
    2. 空白討論頁面;
    3. 無鏈入的討論頁重新導向(如移動殘留等);
    4. 機器人創建的、使用完畢的維護用頁面(如Cewbot[更多]對話頁貢獻上傳歷史封鎖及歷史被刪貢獻移動日誌巡查日誌使用者權限及日誌使用者查核失效錨點的維護需要增刪討論頁內容);
    5. 新用戶將評論誤發送至頁面討論頁。
    • 此處的新用戶指發言前未獲得自動確認使用者用戶組的編輯者。若其創建了新討論頁,維護人員可選擇刪除頁面;若僅添加了新發言,則應使用{{InvalidSpeech}}進行標記。
公共討論頁

在上述規範的前提下,

  1. 涉及到以下內容的討論應當使用{{hide}}等模板隱藏(原則上應當由維護人員操作):
    1. 完全亂碼類內容;
    2. 人身攻擊/侮辱/刻意冒犯他人的內容;
    3. 無關於當前討論串的內容;
    4. 錯誤發送至討論頁的評論;
    5. 其他降低討論質量的內容。
  2. 萌娘百科討論:討論版的子頁面,特別允許:
    1. 非維護人員使用{{RemovedMAR}}移除標記為「無人回復」的{{MarkAsResolved}};
    2. 維護人員刪改或是使用{{RemovedMAR}}移除{{MarkAsResolved}};
    3. 維護人員直接刪除用戶重複發送的整個討論串。
  3. 編輯戰原則上應當在公共討論頁解決;
  4. 在符合萌娘百科政策的前提下:
    • 任何用戶不得阻止他人參與公共討論;
    • 公共討論頁的討論結果具有一定的效力,亦可提出反對討論串。
用戶討論頁

在內容遵守萌娘百科整體規範及上述規範的前提下,

  1. 用戶在自己的討論頁內:
    1. 允許自行適當裝飾、排版自己的討論頁,但不允許自動播放音視頻;
    2. 在特殊情況下應當使用{{help}}以請求幫助。但不應濫用以擾亂秩序;
    3. 允許存檔或刪除用戶留下的整個討論串,視為已讀該留言;
      • 當存檔或刪除維護人員留下的警告留言或模板時,視作已讀該警告(註:模板:忍耐是有限的無法被用戶自行刪除);
    4. 除必要的頁面保護外,不應進行將頁面用作沙盒等行為導致他人無法正常討論;
    5. 當出現頁面過長或過度裝飾等影響頁面加載的情形,導致他人查閱、討論受阻時,用戶應當存檔或刪除過期討論串、減少不必要的裝飾;
      • 此條規定在有多名維護人員認定或其他用戶於操作申請版提出申請時啟動;
      • 若認定情形屬實,維護人員應當首先提醒用戶處理,用戶一周內無響應則應協助處理;
    6. 用戶討論頁不應重新導向至用戶子頁面之討論頁。
  2. 用戶可以在他人討論頁內:
    1. 留下歡迎信息模板:
      • 用戶可以為自己發放或在留言需要新建他人討論頁時發放此類模板;
      • 除前一條所述情形外,僅有維護人員可以為有編輯記錄的用戶發放此類模板;
      • 發放此類模板時應通過模板參數或是簽名標明發放者,且須符合#簽名一節之1、2條之規定;
      • 除既有的{{welcome}}、{{歡迎}}外,不再允許新增歡迎信息模板;
      • 禁止向他人發放自定義歡迎模板或展開模板原始碼以規避此條限制。
    2. 進行正常交流對話;
    3. 發送維基友愛
  3. 維護人員可以在用戶討論頁進行警告:
    1. 留置警告提示時,應含有「疑似維護人員留下警告」標籤(維護人員留言內容或摘要包含「警告」2字,則會自動觸發濫用過濾器進行標籤)。
    2. 可放置或移除自己放置的{{忍耐是有限的}}模板。

  • 若出現違反上述規範的行為,維護人員應立即處理並提醒或警告。若警告無效,維護人員可視情形按用戶封禁政策之規定進行處理。
  • 特別地,若用戶對其他用戶進行人身攻擊,拒絕停止相應行為或無悔改意願,封禁時長可按方針規定的一年內第二次、第三次進行次數累計、時長累加。

簽名

用戶在討論區的簽名(即「~~~~」),須遵守以下規定:

  1. 在發言簽名;
    • 若在頁面中相互不連續的多個位置均新增了內容,應多次簽名。[增 1]
  2. 能夠正確地區別出您和其他用戶:
    1. 包含指向您的用戶頁、用戶討論頁和(或)貢獻頁的內部連結(以上三個中的一個或多個);
    2. 不允許偽造他人簽名,不允許添加除已公示的分身帳戶之外的前一條所述之連結;
    3. 不允許包含不實的用戶組信息(含冒充維護人員)。
  3. 包含討論區規定使用的時間戳:
    1. 內容一節第3條中的可修改情況與歡迎信息模板的特別規定外,任何發言必須添加時間戳;
    2. 不允許使用{{unsigned}}代替簽名;
    3. 在需要機器人維護的特定討論區,有符合格式要求的簽名須符合以下格式要求[改 4](含原始碼及實際顯示):
      • 參考格式:【四位年份】年【月份,無前導零】月【日期,無前導零】日 (【星期數】) 【小時,前導零】:【分鐘,前導零】 (【時區,僅接受CSTJSTUTCUTC+[1-12]UTC-[1-12]】)
      • 樣例:2021年1月14日 (四) 05:14 (CST)
      • 正則表達式(不符合此正則表達式的不被認為是可接受的時間戳):
        /[1-9]\d{3}年(?:0?[1-9]|1[012])月(?:0?[1-9]|[12]\d|3[01])日 *(?:[((](?:[金木水火土日月]|(?:星期)?[一二三四五六日])[))])? *(?:[01]\d|2[0-3]):(?:[0-5]\d)(?::[0-5]\d)? *[((]([CJ]ST|UTC(?:[+-](?:[1-9]|1[012]))?)[))]/ ,參見 regexr 上的演示
  4. 萌娘百科:方針#破壞行為一節之規定外,還須符合以下內容規範:
    1. 不應存在未使用替換引用(subst:)而直接嵌入的任何頁面;
    2. 不應包含模塊、templatestyles或Widget;
    3. 除不帶參數且非高開銷的系統變量外,不應包含任何魔術字;[增 2]
    4. 外部連結僅允許萌娘百科及其姊妹站點的連結。
  5. 須符合以下排版要求:
    1. 實際顯示不含有閃爍或動態的樣式、圖像;
    2. 實際顯示的顏色不應過於刺眼、難以識別或設置過低的不透明度[改 5]。其中,連結的顏色不應與默認文本顏色相同或近似連結應與默認文本有視覺上的區分[改 5]
    3. 實際顯示不含有影響排版或難以辨認的,過大或過小的字體;
    4. 原始碼不應多於1000位元組,且實際顯示長度不影響界面排版;
    5. 原始碼不包含可能影響排版的代碼(如實際顯示不應具有跨行之功能不含有主動跨行功能的代碼[改 5])。;
    6. 原始碼不包含語法錯誤的代碼。
  6. 允許簽名中使用符合規範的圖像:
    1. 允許使用不多於2個位於萌娘百科及其姊妹站點的圖像(通常以<img>標籤形式引用img.moegirl.org.cn開頭的外鏈);
    2. 圖像高度或寬度須小於等於50px,且不影響頁面排版;
    3. 除圖像外的媒體文件禁止使用;
  7. 未出現多名維護人員(3人或以上)認定明顯不合適的其他情況。

  • 若出現違反上述規範的簽名,維護人員應立即提醒或警告。若提醒後該用戶仍不予理睬、我行我素,維護人員可視情形按萌娘百科:方針#用戶封禁政策之規定進行處理。
  • 用戶違反簽名規範時,維護人員應移除該簽名中的不當部分,或將其簽名整體替換為{{unsigned}}或標準簽名(即「[[User:用户名|用户名]]([[User_talk:用户名|讨论]])20XX年X月XX日 (〇) XX:XX (CST)」格式)。

存檔

討論版存檔

為防止萌娘百科討論:討論版的子頁面過長,導致頁面加載、提交編輯等行為過於緩慢,以下為討論版存檔機制:

  • 機器人存檔機制:
    • 討論串已結束討論(被標記{{MarkAsResolved}}後指定時間)或10日無新發言,則將討論串進行剪貼存檔。
    • 在原討論頁(萌娘百科討論:討論版的子頁面)僅保留討論串標題,並懸掛{{Saved}}模板進行標記。
    • 萌娘百科討論:討論版的子頁面中,保留標題、內容存檔的討論串,其標題將於每月1日刪除。
  • 存檔頁面命名:
  • 其它存檔機制:
    • 群組資訊版的存檔由維護人員手動進行。
    • 註銷帳戶申請版的存檔由管理員手動進行。
    • 在特定情況下,維護人員亦可對討論版進行手動存檔。
用戶討論頁存檔

當用戶選擇對用戶討論頁上的討論串進行存檔時:

  • 不允許將討論串存至本站用戶討論名字空間(User talk)以外的位置。
  • 須採用子頁面存檔固定連結存檔的方式進行存檔。
  • 允許用戶自行申請刪除子頁面存檔。[增 3]

其它

  1. 在特定情況下,管理員可使用濫用過濾器以幫助討論區的管理。
  2. 如若管理員巡查姬多次在討論區進行違規管理操作,視作對萌娘百科的破壞,按照方針中的相關內容進行處理。
  3. 免責聲明:參見萌娘百科:免責聲明

提案

  1. 廢除Talk:提案頁面(改為至方針頁面的重新導向),將Talk:提案#過往政策討論頁面這一節移入萌娘百科:提案末尾(參考萌娘百科:快速提案);
  2. 修訂正式提案一節:
    • 提案頁面發起位置修訂為「萌娘百科_talk:提案/討論中提案/XXXX」,下同;
  3. 修訂提案格式一節:
    • 「如果出現了提案頁面超限的情況,則將「提案正文」一節移入子頁面(萌娘百科_talk:提案/討論中提案/XXXX/提案正文)」變更為「若提案發起時正文字節數超過3w字節,提案發起人可選擇將「提案正文」一節移入對應的Project頁面(萌娘百科:提案/討論中提案/XXXX)」;
  4. 修訂提案存檔一節:
    • 「每份提案存檔都要在頁面名後面加上投票結束日期(日月年格式)」後插入「若提案未進入投票階段,則添加提案終止日期」;
    • 移動所有提案存檔至【萌娘百科_talk】名字空間。

修訂注釋區

  1. 依照#關於簽名放置位置的限制之意見添加。
  2. #對簽名規定中表述的調整中的意見總結,新增對魔術字的明確限制。
  3. 補充存檔刪除相關規則。

  1. 移動相關內容至存廢政策。
  2. 移動至簽名一節。
  3. 修改這一小節為存廢處理政策,並從公共討論頁移動至內容一節。
  4. 同步現有討論區管理方針簽名一節中的內容。
  5. 5.0 5.1 5.2 #對簽名規定中表述的調整進行調整。


討論區

關於簽名放置位置的限制

建議增加對討論區簽名放置位置的限制:

  1. 簽名必須放置在自身新增內容的末尾,一般不應換行。
  2. 新增內容為塊狀元素時允許換行。
  3. 當在一次編輯中,在頁面中相互不連續的多個位置均新增了內容,應插入多個簽名,放置位置限制同其他規定。
  4. 簽名應具有上下文辨識度,下一點的這類位置不應放置簽名。
  5. --サンムル討論) 2021年12月27日 (一) 16:25 (CST)
第1點的話我認為不宜過嚴限制,除了塊狀元素外,如果發言包含多行,那簽名前換行也很可能是有利於觀感的。「一般不」這樣模糊點我覺得也不是不可以,別限太死就行。
第3點強烈支持,見過不止一次了……
第4點沒看太懂,但我覺得不是太大的問題,可以不管。
——C8H17OH討論) 2021年12月27日 (一) 22:28 (CST)
我覺得或許可以限制簽名時多次換行的行為,比如實際顯示為【內容】+【空一行及以上】+【簽名】,見過幾次;另外除了3可能不需要限的太死吧大概 —— ほしみ 2021年12月28日 (二) 01:17 (CST)
第2點"新增內容為塊狀元素時允許換行",當前這邊的機器人或許能解析,但是不保證其他的工具也都能正常運行,故恐怕有疑慮。 --Kanashimi討論) 2021年12月31日 (五) 06:50 (CST)
第2點是考慮排版問題嗎?如果是我感覺改為內容末尾為塊狀元素時可以換行更好,這個角度考慮是簽名緊接著塊就容易影響。
第3點對由本人操作導致的不連續很好,但由非本人操作導致的討論內容不連續(比如不同的人在用戶A不同的討論段回復,導致用戶A每段之間不連續了)該如何處理簽名?(畢竟目前好像也只有查閱該討論串該級縮進末尾簽名是誰的辦法了......)——6116G討論) 2022年1月1日 (六) 16:57 (CST)
由於切割其他人的發言是非常不禮貌的行為,這種情況下應當恢復發言的原貌,並提醒對發言進行切割的用戶。——From 引夢者濁華(討論) 2022年1月1日 (六) 19:42 (CST)
額......比如萌娘百科討論:2021年方針修訂專案/最終決定權的討論#最終決定權的同意率與事後質詢這一章的兩段這種情況,是否也算切割?——6116G討論) 2022年1月1日 (六) 23:27 (CST)
對,您應該多次簽名。不然很難找到誰說了什麼。—— ほしみ 2022年1月2日 (日) 00:08 (CST)
好的,我以後將考慮得更周到,在多段連續討論可能引起將來他人回復切割的地方也會簽名。——6116G討論) 2022年1月2日 (日) 20:35 (CST)

U:YOONHA~1.PAR關於時間戳的意見

  1. 時間戳整體是否允許個性化? (如: 將時間戳同時封裝進簽名中和前面的用戶名等信息一同使用字體等樣式, 使用時鍵入 ~~~)
  2. 「星期數」 為中文語境下才會有的說法 (在星期日這種情形下這甚至也不是數字), 可能需要替換為更為合適的敘述; 考慮到機器人現在支持了JSTUTC時區, 那麼可否容許類似於月火水木金土日以及Mon Tue Wed Thu Fri Sat Sun的星期序列存在?
  3. 承上一點, 歸根結底星期這一參數是否為機器人維護之必要參數? 若無必要可否自行去除? (參考: 英文維基百科討論中通常不加星期幾)
  4. 全形括號符合中文版式, 時間戳反而使用半角符號會使得排版不倫不類, 除非所有討論當中統一使用半角符號, 包括特製的句號頓號等, 故可否通融在時間戳中使用中文的全形括號

_USER:YOONHA~1.PAR(暫定簽名, 留言頁。 )2021年12月27日 (一) 10:06 (UTC)

不行,可能影響多個擴展對簽名的解析,包括影響計畫中的討論擴展對簽名的解析。另,由於討論擴展的需求,可能需要對簽名進行更嚴格的限制,例如在默認簽名中增加用戶貢獻頁面的連結等。具體以運維方升級mw版本/安裝擴展時的附加需要為準。—— ほしみ 2021年12月27日 (一) 18:19 (CST)
本人認為現存之幾點均不存在破壞機器人維護操作的意圖 (僅年月日、 時間以及時區為機器人維護所需要的參數), 對這些擴展做出合理的更動並無技術難點。 還請允許本人暫且反對此案。 _USER:YOONHA~1.PAR (暫定簽名, 留言) 2021年12月27日 (一) 10:43 (UTC)
1、可,時間戳可被包含在任何元素內,只要其原始碼符合格式且不被其他內容截斷即可;
2、這個表述我也找不到更合適的;已允許月火水木金土日,但考慮到萌百是中文社區,不支持英文版本;
3、可去除;
4、時間符號根據國家標準GB/T 7408-2005《數據元和交換格式 信息交換 日期和時間表示法》規定應使用半角的連字符、冒號和斜線,括號是可以使用全形括號的。
可接受的時間戳的正則表達式:/[1-9]\d{3}年(?:0?[1-9]|1[012])月(?:0?[1-9]|[12]\d|3[01])日 *(?:[((](?:[金木水火土日月]|(?:星期)?[一二三四五六日])[))])? *(?:[01]\d|2[0-3]):(?:[0-5]\d)(?::[0-5]\d)? *[((]([CJ]ST|UTC(?:[+-](?:[1-9]|1[012]))?)[))]/ ,參見 regexr 上的演示。——From AnnAngela the Bureaucrat (Talk) 2021年12月29日 (三) 12:02 (CST)
十分感謝,辛苦了。_USER:YOONHA~1.PAR(留言)2021年12月29日(三)07:42:34(UTC)
這邊現在採用的是 /([12]\d{3})年([[01]?\d)月([0-3]?\d)日 \(([日一二三四五六])\)( [0-2]?\d:[0-6]?\d)(?: \(([A-Z]{3})\))?/gseealso --Kanashimi討論) 2021年12月31日 (五) 06:32 (CST)
那麼理論上應該需要取交集了... 問問@AnnAngela的意見。—— ほしみ 2021年12月31日 (五) 11:22 (CST)
建議@Kanashimi整合一下上面那個正則,可以考慮加個?以及非捕獲組。——From AnnAngela the Bureaucrat (Talk) 2021年12月31日 (五) 12:44 (CST)
這邊採用的是萌娘百科自動簽名(4個或5個波浪符號)使用的日期和時間格式。像是"金木水火土日月"、秒或jst似乎沒被使用? --Kanashimi討論) 2021年12月31日 (五) 17:18 (CST)
「金木水火土日月」感覺應該考慮的是萌百是中文社區,很少會有日本時區的人的樣子。沒有jst好像確實是個問題。秒的話有沒有其實都無所謂了,畢竟人類也感知不到。--木織元討論) 2022年1月16日 (日) 06:05 (CST)

關於提案正文的位置

首先把提案從Talk移動到Project_talk空間我一把子(+)支持。然後關於提案正文的位置,我很早前就提出過把提案正文放到非討論頁的建議,有便於檢查是否只有發起人修改、便於參與者查閱提案正文變更情況、便於投票期間添加保護等種種好處,同時還能保證對提案正文的修改免受討論頁方針的規制(#內容第3.9條的舉例)和Cewbot的煩擾。我個人激進的想法甚至是要求所有提案正文都放在Project頁的;現在至少給了可以放Project頁的機會,但我在想能不能把字數要求也去掉,給提案發起人更大的選擇權。——C8H17OH討論) 2021年12月27日 (一) 22:23 (CST)

主要是考慮到有些不太長的提案,如果再單獨開頁面,反而對點進來閱讀的人不太友好,不過我(+)支持增加一些允許單開頁面的情形,但是暫時沒有啥想法( —— ほしみ 2021年12月28日 (二) 01:15 (CST)

關於討論頁方針部分條文邏輯的非實質性意見

#內容第3.10條和#公共討論頁第3.3條算是近期實踐中發現的新問題,寫入方針我覺得(+)是好的,不過我覺得條文順序可以調整一下,可以把「失效錨點的維護需要增刪討論頁內容」和「新用戶將評論誤發送至頁面討論頁」都各自算作單獨的一條「可以刪除討論內容的特殊情況」放到#內容第3條里或者在#公共討論頁里單開一條,因為前者已經是方針明文許可的了、不需要作為「行政員特別許可的情況」,而後者在「無需創建無有效討論內容的討論頁」(「什麼時候應該刪討論頁」)里又多規定了只移除內容的說明。總之都是條文邏輯上的問題,不算是實質性意見。另外,{{InvalidSpeech}}需要寫個文檔( ——C8H17OH討論) 2021年12月27日 (一) 22:23 (CST)

應該改好了。{{InvalidSpeech}}已經降低過保護等級了,那文檔就交給你了( —— ほしみ 2021年12月29日 (三) 11:55 (CST)

對簽名規定中表述的調整

#簽名一節:

  1. 「除萌娘百科:方針#破壞行為一節之規定外,還須符合以下內容規範」中需不需要增加對於解析器函數、系統變量、狀態開關的限制?(如果限制了,U:Bhsd的簽名將會不符合規定)
  2. 對於「實際顯示的顏色不應過於刺眼、難以識別或設置過低的不透明度。其中,連結的顏色不應與默認文本顏色相同或近似。」
    • 「過低的不透明度」已被「難以識別」包含,無需此句;
    • 「連結的顏色不應與默認文本顏色相同或近似」這句可以改為「連結應與默認文本有視覺上的區分」,因為顏色不是能提示連結的唯一方法。
  3. 「顯示不應具有跨行之功能」的「跨行」不妥。正常的文本在到達邊界時也會跨行。「主動換行」或許更好。

 あめろ 討論 2021年12月29日 (三) 13:46 (CST)

關於第一條,我建議是不允許狀態開關、可變的系統變量、包含運算與邏輯判斷的解析器函數等。—— ほしみ 2021年12月29日 (三) 15:30 (CST)
(-)反對 這條發言為什麼我沒有收到提示?我覺得只需要禁止狀態開關就行了,因為會改變整體頁面的屬性。其他魔術字未見限制的必要性。——移動版用戶 Bhsd 2021年12月30日 (四) 22:29 (CST)
另外關於連結的提示,我認為需要加上不能僅通過:hover、:active等偽類樣式,而是必須默認樣式就與默認文本形成區分。——移動版用戶 Bhsd 2021年12月30日 (四) 22:36 (CST)
抱歉!我以為加上用戶頁連結和簽名就可以給對方提醒了,看來下次得好好用{{Reply to}}了。簽名的4.2 「不應包含模塊、templatestyles或Widget」可以限制偽類的使用。 あめろ 討論 2021年12月30日 (四) 22:44 (CST)
有道理,是我傻了。——移動版用戶 Bhsd 2021年12月30日 (四) 22:51 (CST)
用戶頁連結和簽名確實可以給用戶提醒吧?我在下一行試一下。
@Bhsd 我倒是認為沒計算完的解析器函數也不好,比如不少人直接用模板替換展開,展開後出現冗餘的if、ifeq、switch等內容也應該移除。
連結提示我認為可以改為「連結應與默認文本有視覺上的直接區分」,具體情況具體判斷就好。—— ほしみ 2021年12月30日 (四) 22:48 (CST)
考慮到討論內容可能事後會被移動,有些解析器函數可能替換與不替換的效果會不同——移動版用戶 Bhsd 2021年12月30日 (四) 22:51 (CST)
可以給個例子嗎?我認為至少用switch達成每個頁面不同簽名等效果應該在簽名被解析前完成,而不是簽名發出來之後的原始碼仍包含此類解析器函數。—— ほしみ 2021年12月30日 (四) 22:55 (CST)
先說可變的系統變量吧,PAGENAME、NAMESPACENUMBER等在發生討論內容移動時可能含義就會發生改變。而如果if、switch之類的分支用到了這些系統變量,那展開與否也會不同。——移動版用戶 Bhsd 2021年12月30日 (四) 23:05 (CST)
如果是簽名提交之後仍保有if、switch之類達成每個NAMESPACENUMBER有不同簽名效果這種情況,我還是覺得不該有,不論簽名是否被移動。這是簽名而不是討論內容啊( —— ほしみ 2021年12月30日 (四) 23:12 (CST)
那就限制解析器函數和帶參數的系統變量,但不限制不帶參數的系統變量吧。如果僅限制部分解析器函數,感覺除非列出一個限制表,否則會含糊不清。如果可以接受的話,我也嘗試修改下簽名。——移動版用戶 Bhsd 2021年12月30日 (四) 23:22 (CST)
我覺得應該沒問題吧,解析器函數這一塊或許可以採用白名單的方式(?。另附加限制一個高開銷的系統變量。—— ほしみ 2021年12月30日 (四) 23:30 (CST)
我記得不帶參數的時候系統變量沒有高開銷的吧?居然還真有!CASCADINGSOURCES。——移動版用戶 Bhsd 2021年12月30日 (四) 23:40 (CST)
雖然沒全面測試過,但採用這些 magic words可能造成工具失常,恐須謹慎。尤其若未來想引入維基百科回覆工具的話。 --Kanashimi討論) 2021年12月31日 (五) 07:00 (CST)
根據MW:Help:DiscussionTools/Why can't I reply to this comment?,只要用戶連結和時間戳符合要求即可。——移動版用戶 Bhsd 2021年12月31日 (五) 23:36 (CST)
這邊曾遇過用戶連結與日期之後還接一大串、接了兩個相異用戶連結與日期的,有時不太好判斷。 --Kanashimi討論) 2021年12月31日 (五) 23:46 (CST)
這已經和魔術字毫無關係了吧……——移動版用戶 Bhsd 2021年12月31日 (五) 23:58 (CST)
您說的對。建議第三項主動換行改成換行字元,並且添加上已使用者連結與日期做結,這樣或許會更方便判斷。 --Kanashimi討論) 2022年1月1日 (六) 05:05 (CST)

換成「字元」的話,<div></div>算不算換行字元呢? あめろ 討論 2022年1月1日 (六) 13:23 (CST)

這邊可以處理這個例子,但是不保證其他的工具也都正常。我想大多數工具都是檢查最後一行最後一個使用者連結與日期。 --Kanashimi討論) 2022年1月1日 (六) 15:15 (CST)
簽名裡帶div怎麼著都會換行吧,這已經被其他的規定阻止了。—— ほしみ 2022年1月1日 (六) 15:26 (CST)

是否有必要增加關於{{重置縮進}}的使用相關內容

參考Special:差異/5531636/5532561,是否有必要對{{重置縮進}}的使用增加強制性規範?針對討論串前方縮進符超過一定數量因分段導致討論串錯位的情況,要求必須添加{{重置縮進}}?且考慮到討論版的易用性,該義務不應由所有參與討論的用戶負責,而應由維護組成員負責?(當然其它用戶自行添加也無所謂)--北湖3討論) 2021年12月30日 (四) 10:49 (CST)

(+)帶條件同意 支持增加規範,但是要規定多少我估計會造成討論負擔。或許一個非強制的「縮進影響觀感,以及討論串由於縮進錯位」會略微好一點。
剛好這一段上面那個下樓梯式的無限縮進可以試著通過重置縮進試試? -- 滿身瘡痍の花落丿天使 2022年1月1日 (六) 11:22 (CST)
重置縮進目前一般是作為「排版」的一種,所以首先任何編輯者都可以在適當情況下進行;至於是否需要引入強制性的要求,我個人覺得(=)不是很必要( ——C8H17OH討論) 2022年1月1日 (六) 23:38 (CST)
(▲)同上 願意排版,就調整一下,不太適合強制。更何況之後可能要引入的討論擴展沒這個東西,不適合寫入方針。—— ほしみ 2022年1月2日 (日) 00:07 (CST)
意見(▲)同上,此乃隨緣。—— Eric Liu 創造は生命(留言 2022年1月3日 (一) 06:43 (CST)

關於自動存廢處理的小提醒

像是空白討論頁面、無鏈入的討論頁重新導向(如移動殘留等)、cewbot使用完畢的維護用頁面,這些其實可用機器人幫忙處理,這樣也能減少人力。 --Kanashimi討論) 2021年12月31日 (五) 06:44 (CST)

如果閣下願意接手工作,那也挺好的。應該有不少任務可以從隔壁借鑒過來用。—— Eric Liu 創造は生命(留言 2022年1月3日 (一) 06:44 (CST)
這邊可以試試。 --Kanashimi討論) 2022年1月3日 (一) 07:10 (CST)

投票區

正在加載中……
  • 投票開始時間: |
  • 投票結束時間: |
  • 投票總用時 7 天,正在計算中……

已經快一周沒有新的發言了,考慮到今天是周末,就先開票了。@AnnAngela蓝羽汇弗霖凯Lyhic星海子Sivlovski玄微子AkizukiSaitouHlwan03Luenshi007Bbrabbit宇文天启平塚八兵衛空翊サンムルVcfch843875618HetmesAskalana不是液氮红石小蝈XzonnC8H17OHChko08022003Bete1geuseLeranjun一位史蒂夫小乃LUO1PTsanconBYin公的驱逐舰泠佛.西尾哈鲁卡Siw19981998Wenzuxiaot珞珝SinonJZHSytus沼泽Bob1301あめろDaigui屠麟傲血贯井羽优的草莓胖次—— ほしみ 2022年1月9日 (日) 13:03 (CST)

補ping參與討論的自動確認使用者@KanashimiBhsdEricliu1912北湖3YOONHA~1.PAR6116G花落丿天使—— ほしみ 2022年1月9日 (日) 13:05 (CST)

管理員

同意
  1. (+)同意 我覺得這次應該沒啥問題了吧。—— ほしみ 2022年1月9日 (日) 13:07 (CST)
  2. (+)同意 總體上沒有問題,希望移動提案存檔的時候能跑個批量替換或者留個重新導向。——From 引夢者濁華(討論) 2022年1月9日 (日) 15:17 (CST)
  3. (+)同意 提案沒有跟隨移動到萌百討論空間確實是當年偷懶了,現在補上也行。——From AnnAngela the Bureaucrat (Talk) 2022年1月9日 (日) 21:53 (CST)
  4. (+)同意 沒有認為不妥的地方。——絲毫沒有存在感的某藍色管理員討論) 2022年1月12日 (三) 14:20 (CST)
  5. (+)同意 通篇沒有和現行慣例差別較大的地方,幾個變動希望能落到實處。--Thus Spoke Sivlovski.討論」 2022年1月13日 (四) 19:10 (CST)
  6. (+)同意 總體來看沒啥大問題。--Lyhic討論) 2022年1月14日 (五) 14:09 (CST)
反對
棄權

巡查姬

同意
  1. (+)同意 好。--由使用者樂然)撰於 2022年1月9日 (日) 13:13 (CST)
  2. (+)同意 善。——From 泠佛. (討論) 2022年1月9日 (日) 13:15 (CST)
  3. (+)同意 可我還是覺得提案應該和提案討論投票分離啊,放在mgp空間的話已經可以實現這個條件了。—— 屠麟傲血討論) 2022年1月9日 (日) 13:35 (CST)
  4. (+)同意 跟之前那個沒區別吧,那我就不看了閉眼投同意了。--Patroller 珞珝 [與我對線] 2022年1月9日 (日) 14:07 (CST)
  5. (+)同意 同意 --MnO43- 2022年1月9日 (日) 14:17 (CST)
  6. (+)同意 我該去改簽名了--FIGHT AGAINST OMICRON! ·P. W. T. 2022年1月9日 (日) 14:30 (CST)
  7. (+)同意 無意見-- 小乃討論) 2022年1月9日 (日) 14:47 (CST)
  8. (+)同意 沒有問題。--Vcfch843875618討論) 2022年1月9日 (日) 14:51 (CST)
  9. (+)同意 吼。--By CHKO (Talk) @ 2022年1月9日 (日) 15:05 (CST)
  10. (+)同意 無異議。 --空翊留言) 2022年1月9日 (日) 15:19 (CST)
  11. (+)同意 冇問題。--94 42 233 2001-8 J-JREDiscussion) 2022年1月9日 (日) 15:30 (CST)
  12. (+)同意 路過隨票。 -- 宇文西修ิิۣۣۖۖۖ特拉瑟 2022年1月9日 (日) 15:58 (CST)
  13. (+)同意 今天執行相關處理的時候才意識到舊有方針的缺陷,樂見修訂。—— 這是一張遺漏的二餅請聯繫失主) 2022年1月9日 (日) 17:04 (CST)
  14. (+)同意 我的簽名合格否?——From猿渡宇希單推人 貫井羽優的草莓胖次討論·貢獻) 2022年1月9日 (日) 17:09 (CST)
  15. (+)同意 沒問題。——bob1301討論) 2022年1月9日 (日) 19:29 (CST)
  16. (+)同意 沒什麼可說的,因為沒有意見。—— DaiGuitalk」 2022年1月9日 (日) 21:58 (CST)
  17. (+)同意 感覺還行。——芳文廚一位史蒂夫 討論·貢獻 請問您要單推一隻小浣熊嗎? 2022年1月9日 (日) 23:06 (CST)
  18. (+)同意 無異議。——★Sytus~Talk 2022年1月10日 (一) 00:55 (CST)
  19. (+)同意 完善了討論制度和提案制度,不戳。--SinonJZH(๑•̀ω•́๑)(討論) 2022年1月10日 (一) 12:20 (CST)
  20. (+)同意 沒有異議。--bbrabbitからの評論 #討論# 2022年1月10日 (一) 16:01 (CST)
  21. (+)同意 無異議。——From 西尾哈魯卡 (討論) 2022年1月10日 (一) 16:39 (CST)
  22. (+)同意 沒有異議。--野生的阿卡喵突然出現了並召喚出了她的紙箱!討論) 2022年1月10日 (一) 16:44 (CST)
  23. (+)同意 沒有意見。--以上言論來自於巡查姬007君 _(:3 」∠)_討論) 2022年1月10日 (一) 19:30 (CST)
  24. (+)同意 行。 あめろ 討論 2022年1月10日 (一) 19:42 (CST)
  25. (+)同意 無異議-- Welcome to the Hotel California 2022年1月10日 (一) 22:30 (CST)
  26. (+)同意 放置提案的名字空間更改以及簽名放置位置的限制兩點讓我基本滿意,其他點靜等實行效果。--サンムル討論) 2022年1月11日 (二) 09:52 (CST)
  27. (+)同意 無異議。—— 冬月下的二重奏 LUO1P 2022年1月11日 (二) 12:54 (CST)
  28. (+)同意 無異議。--Bete1geuse討論) 2022年1月11日 (二) 13:06 (CST)
  29. (+)同意 善哉--已經是一條死魚的HetmesAskalana 2022年1月11日 (二) 16:56 (CST)
  30. (+)同意 支持。——「今日も一日がんばるぞい!」(沼澤討論) 2022年1月13日 (四) 11:01 (CST)
反對
棄權

參與討論的自動確認使用者

同意
  1. (+)同意 這個折中可以接受。——移動版用戶 Bhsd 2022年1月9日 (日) 16:25 (CST)
  2. (+)同意 就汴了一句,看著應該沒啥問題 -- 滿身瘡痍の花落丿天使 2022年1月9日 (日) 16:37 (CST)
  3. (+)同意:加油!—— Eric Liu 創造は生命(留言留名 2022年1月9日 (日) 18:41 (CST)
  4. (+)同意 無異議——北湖3討論) 2022年1月9日 (日) 22:59 (CST)
  5. (+)同意 可以。——6116G討論) 2022年1月10日 (一) 22:00 (CST)
反對
棄權

▼ 該投票無效,原因:無票權。
  1. (+)同意 雖然看完了也學不會不過反正逐步精簡改進總是好的。--木織元討論) 2022年1月16日 (日) 11:17 (CST)
▲ 該投票無效,原因:無票權。

無票權用戶

同意
  1. (+)同意 無異議--TNLHKsign|talk 2022年1月9日 (日) 14:44 (CST)
  2. (+)同意 那必然是進行一個同意的投——甜的白蘿蔔(討論) 2022年1月9日 (日) 17:17 (CST)
  3. (+)同意 感謝各位大佬的工作。_USER:YOONHA~1.PAR(留言)2022年1月9日(日)09:42:10(UTC)
  4. (+)同意 誇張點說,賞心悅目。 From 庫德里爾 (討論) at  2022年1月15日 (六) 09:23 (CST)
  5. (+)同意 實話實說,這次沒啥問題了。--流浪者-瀧澤さくね討論) 2022年1月16日 (日) 08:19 (CST)
反對
棄權

計票與結論

根據萌娘百科:提案:具有投票權的用戶為:【管理員】、【巡查姬】、在討論階段參與了提案討論的已註冊達30天、遵守方針的活躍【自動確認使用者】。在提案有至少2位管理員參與投票時,【投票有效】。

  1. 投票開始時共有6名參與站務的管理員;其中,
    • 5(+)同意
    • 0(-)反對
    • 0(∅)棄權
    • 1人未投票 (弗霖凱)。
  2. 投票開始時共有35名正式巡查姬;其中,
    • 30(+)同意
    • 0(-)反對
    • 0(∅)棄權
    • 5人沒有參與投票(Hlwan03,不是液氮,Xzonn,C8H17OH,公的驅逐艦)。
  3. 共有5名有票權的自動確認使用者參與了投票;其中,
    • 5(+)同意
    • 0(-)反對
    • 0(∅)棄權
    • 另有1人投了無效票。
  4. 另有5位無票權用戶發表了意見。

當前提案有5位管理員投同意或反對票,大於等於要求的2名,該提案投票有效

統計計票結果,全部投票之同意:反對票數量為 40:0,【同意】票數大於【反對】,且管理員的【同意】票數不小於【反對】,【提案通過】。—— ほしみ 2022年1月16日 (日) 13:45 (CST)