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

维基百科,自由的百科全书

这是本页的一个历史版本,由Sanmosa留言 | 贡献2022年4月13日 (三) 02:24 →‎修改一級行政區道路特殊收錄限制列表:​ // Edit via Wikiplus编辑。这可能和当前版本存在着巨大的差异。

此頁面探討维基百科的方針與指引


請注重礼仪、遵守方針與指引,一般問題請至互助客棧其他區知识问答提出,留言后请务必签名(点击 )。


發表前請先搜索存档,參考舊討論中的内容可節省您的時間。
公告欄
# 💭 話題 💬 👥 🙋 最新發言 🕒 (UTC+8)
1 PWVCST第二自然段 93 7 神秘悟饭 2024-03-19 17:42
2 調整交通關注度指引有關鐵路車站的要求 46 5 Sanmosa 2024-03-21 14:05
3 藝人條目綜藝節目列表討論 35 9 Kriz Ju 2024-03-29 01:22
4 是否應使用不含姓的名字做為消歧義頁面? 19 10 LuciferianThomas 2024-03-22 18:44
5 虛位元首和非實權國家領袖的任免是否有必要列入首頁? 22 9 春卷柯南 2024-03-26 16:57
6 重議刪除方針規定「多餘無用」模板模組提刪條件及確立廢棄模板模組提刪規範 73 15 Kalin8111 2024-03-29 00:03
7 建議改成跟英維一樣,簽名的長度上限為255字元而非255位元組 10 7 YFdyh000 2024-03-20 01:05
8 針對特定帳號近期發言,商榷數值計算及外部連結的事宜 3 3 Sanmosa 2024-03-19 22:18
9 ITN(R)國家/地區 元首/議會選舉結果刊登時的用詞應該要模板/規範化? 12 5 Ericliu1912 2024-03-28 10:52
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時,
請先檢查設定是否有誤

正在廣泛徵求意見的議題

以下可能與方針指引相關的主題討論需要社群廣泛關注:重新整理

維基百科格式與命名

Module talk:Citation/CS1/Configuration § 編輯請求:更正cite AV media参数显示

維基百科方針與指引

Wikipedia talk:删除程序 § RfC:是否繼續運行存廢討論的重新提交機制?

Wikipedia talk:签名 § 提议禁止在签名中插入乐谱

Wikipedia talk:徵求意見 § 徵求意見公示寫入相關方針指引

Module talk:CGroup/Korea § :Module:CGroup/Korea

Wikipedia talk:小小作品 § 修改小小作品計算50個漢字的標準

維基百科提議

Wikipedia:互助客栈/其他 § 斜坡计划的安全补丁

Wikipedia talk:仲裁委员会 § RfC:2024年2月

Wikipedia talk:IP封鎖豁免權授予者 § 添加:mw:Extension:ContactPage輔助申請

Wikipedia talk:回饋請求服務 § 将回馈请求系统用于存废讨论和存废复核

Wikipedia talk:字詞轉換處理/公共轉換組 § 思路:條目預儲公共轉換組中匹配的規則,減少載入時間

就安全投票問題訂立管理員選舉暫行規定

社群日前進行投票表決通過,決定「在未來一場管理員選舉使用安全投票(SecurePoll)」。考慮到選舉提名與安全投票開啟之間具有時差,現請社群就選舉日程,包括討論期間、投票期間等面向訂立暫行規定,優先於既有之申請成為管理人員指引。—— Eric Liu 創造は生命(留言留名學生會 2022年1月5日 (三) 14:18 (UTC)[回复]

我這裏寫個草案吧。考慮到農曆新年和動員令社群會比較忙,本次算是一次比較大型的選舉,選舉宜在二月下旬至七月進行。考慮到目前的站務積壓,目前應該以管理員數量為首要目的,畢竟最積極的蟲蟲飛消失了,其他WP:OA2021中被除權的9位也有相當的貢獻,理論上先提名曾任管理的用戶比較容易得到共識。而針對Spoll的數目而言,我個人認為一次應該避免超過5個以避免影響社群同時要關注過多的投票。因此大致草案如下:
2月15日-2月22日:曾任管理員者可以優先被提名。超出5個則暫時凍結。
2月22日起:假如提名者不足5個一般合Rfa要求者也可以參與。
2月22日-3月22日:對候選人作出提問,社群討論候選人是否合適。
3月22日至3月29日:開啟Spoll讓社群進行投票。(兩週或者提前開啟也可,另議。)
3月29日後:行政員再按投票結果得出結論。同時再考慮準備下一回的投票。4月至7月其間可以再進行另一場Rfa。
此外,也有其他問題,以此Securepoll而言,延長投票似乎不太實際。而且中立的票也難作考慮。故此可能要設立一個比較固定的標准,按以往近80%則延長投票的做法較難實行。--Ghren🐦🕐 2022年1月5日 (三) 17:55 (UTC)[回复]
此外一票兩投IA也是個問題。以往可以用文字說明支持IA但不支時Admin,但SPoll不能做到這點。--Ghren🐦🕐 2022年1月5日 (三) 17:57 (UTC)[回复]
這樣的話能不能分開spoll?有意願選介面的話多開一個,分開兩邊投。--AT 2022年1月5日 (三) 18:20 (UTC)[回复]
這很簡單,若當事人要選介面管理員,增設一問題即可。 —— Eric Liu 創造は生命(留言留名學生會 2022年1月5日 (三) 18:31 (UTC)[回复]
見下。—— Eric Liu 創造は生命(留言留名學生會 2022年1月6日 (四) 07:22 (UTC)[回复]
RfA已经不能兼RfIA了吧 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月6日 (四) 04:01 (UTC)[回复]
請注意投票結果是「未來一場」。多於一人參與會面臨要適用安全投票抑或一般投票方式的問題,且可能超出社群投票效力之範圍。故此僅建議以一人參與的情況來決定日程,這裡指的不是絕對的行事曆,而是相對的日數。之所以不直接決定往後採用,就是因為需要觀察。其實當初投票應該不要寫未來一場,而是寫「未來半年」之類的或許比較彈性一點呀。—— Eric Liu 創造は生命(留言留名學生會 2022年1月5日 (三) 18:28 (UTC)[回复]
作為參考,目前的管理員選舉,討論與投票並行,為期共十四日。在尊重既有制度、不改變實際選舉時長的情況下,個人有三種方案:
  1. 提名後立即開啟討論,為期七日,期間趕緊籌備安全投票,七日後開放投票,為期七日,總時長仍為十四日;(討七,投七)
  2. 提名後立即開啟討論,期間趕緊籌備安全投票,七日後開放投票,但同時允許繼續討論,總時長仍為十四日;(討七,討/投七)
  3. 提名後立即開始籌備安全投票,期間不得進行任何討論;安全投票開放後,同時開放討論,二者並行,為期共十四日。(討/投十四)
以上,請斟酌。—— Eric Liu 創造は生命(留言留名學生會 2022年1月5日 (三) 18:36 (UTC)[回复]
籌備安全投票本身大概需時多久?--AT 2022年1月5日 (三) 18:38 (UTC)[回复]
或許@1233會清楚?—— Eric Liu 創造は生命(留言留名學生會 2022年1月5日 (三) 18:45 (UTC)[回复]
我认为提名期和投票期搞得太紧安全投票会过于难安排。提名后不得讨论也过于高估社群的自制力。我认为投票期延长为妙。上次实际上也是延期了一周左右。当然事前预备好不是不行。但我认为安全投票的制度当初就有建议一年两场之类的意思,单纯选一个管理出来似乎效率有点低,总不行一年只出两个管理。--Ghren🐦🕗 2022年1月6日 (四) 00:20 (UTC)[回复]
七天搞起一個Spoll只怕也太難了,單是整理一份當時有人事任免資格的名單也已經用時甚久。假如共識認為一年兩場Spoll是比較合理的,日後的方案理論上應該往這個方案走,雖然這個共識沒有約束力。單問個人而言我認為第一屆還是合併數人舉行為好,但是作為第一次投票作為實驗性質也可以。--Ghren🐦🕗 2022年1月6日 (四) 00:46 (UTC)[回复]
那麼就是當初投票問題設計得不好了。為避免爭議,下一次選舉最好還是僅推舉一人。—— Eric Liu 創造は生命(留言留名學生會 2022年1月6日 (四) 07:22 (UTC)[回复]
@Ericliu1912,這東西其實是沒有任何的標準的,但是細節是可以討論的。
我認為提名後就要籌備安全投票。期間應該是可以討論的。(禁止討論其實不切實際)。
反而投票的期間則應該仍然固定為十四天,而討論則可以在開始前繼續。另外,我認同一次選舉可以牽涉不同的人選,而不需要像現在那樣,一次選舉能投票給一位候選人。(可能是投票給兩至三位候選人)。
然後「整理一份當時有人事任免資格的名單」的問題其實不難解決,可以使用python或php等不同的方式整理就可,就像是這次的投票。而且該段code理應是可以重用的。--1233 T / C 2022年1月6日 (四) 03:24 (UTC)[回复]
遇上聖誕假期或是跟其他wiki投票衝突搞不好要推遲超過14天。--Xiplus#Talk 2022年1月17日 (一) 13:53 (UTC)[回复]
窩都可以,三個方案看要哪個社群決定好就好,不要又在那這不行那也不行。--~~Sid~~ 2022年1月14日 (五) 15:52 (UTC)[回复]
如果社群認同投票不能代替討論的話,應強制討論開始一段時間後才開始投票,讓大家都能透過討論更加認識候選人。--Xiplus#Talk 2022年1月17日 (一) 13:57 (UTC)[回复]
同意。禁止讨论怎么看怎么不现实。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月14日 (五) 15:57 (UTC)[回复]
不如直接邀請他人他人提名/推薦,然後同時搞管理員/用戶查核員的SecurePoll,然後提名7天,討論7天/投票14天?(提名和投票期需要大約三天以準備投票人列表及問題),然後主頁面為WP:投票/2022年第一次安全投票。--1233 T / C 2022年2月2日 (三) 08:10 (UTC)[回复]
2022年社群願望清單調查中與此案相關之願望,大家可以去看看。—— Eric Liu 創造は生命(留言留名學生會 2022年2月2日 (三) 15:17 (UTC)[回复]

現在的最大問題在於我們無法預期安全投票籌備要多久。—— Eric Liu 創造は生命(留言留名學生會 2022年2月10日 (四) 11:25 (UTC)[回复]

所以我才提議預先指定一個提名日子,籌備安全投票的時間有太大風險。指定了就能解決所有問題。--Ghren🐦🕖 2022年2月10日 (四) 11:41 (UTC)[回复]
不就是嗎,而且還可以順便在同一時間搞CU的選舉--1233 T / C 2022年2月11日 (五) 13:53 (UTC)[回复]
根據他站社群(英維及波斯語維基百科)在去年於監管員佈告版請求監票之情況,他們在投票開始前(並非提名期開始前)大約一個月,已作出相關請求,可推斷開始投票前一個月便需作籌備。再者他們的選舉為定期進行,故如非定期進行可能需時更多。另可參考波斯語維基百科過往的籌備時間表。謝謝。--SCP-0000留言2022年2月11日 (五) 14:54 (UTC)[回复]

抱歉,但目前這個議案己經放置在這一個月有餘但討論依然不足,我唯有按波斯語維基百科過往的籌備時間表,再加上上方的一些共識寫一個流程寫出來:

  • D-Day:提名開始
  • D+3:候選人如不合條件則重新開始
  • D+7:選舉設置(導入名單、votewiki改為中文)
  • D+10:投票期(發垃圾信息
  • D+24:投票結束(改回其他語言、點票)

此外尚有數點:

  • 本次投票以一人為限,以最先得到提名而且合符投票過程要求者的優先進行選舉,其他的押後至下一次;
  • 候選人應清楚說明是否參選界面管理員,如需要選票上應該另有一列;
  • 選舉的關鍵日期應該預先決定以方便安排投票。

大概是這樣。Ghren🐦🕖 2022年2月14日 (一) 11:32 (UTC)[回复]

RfA已经不能兼RfIA,其余支持。 ——魔琴 [ 留言 贡献 ] 2022年2月14日 (一) 13:10 (UTC)[回复]
已經準備好投票頁面,細節待填。—— Eric Liu 創造は生命(留言留名學生會 2022年2月14日 (一) 15:04 (UTC)[回复]
@Ericliu1912現在依然以提出問題為宜。假如基金會對CU的要求是14天投票,其實管理另外再以七天制並不好。假如擔心過長的投票期使提名人辛苦的話可以另設冷靜期。Ghren🐦🕐 2022年2月15日 (二) 05:20 (UTC)[回复]
問題是基金會上次發了那則訊息以後就一點影子都沒有,不知道他們要做什麼。—— Eric Liu 創造は生命(留言留名學生會 2022年2月15日 (二) 06:30 (UTC)[回复]
基金會是積極不干預政策吧?但是本身Rfa其實本身都沒有太多細節可以安排吧。--Ghren🐦🕒 2022年2月15日 (二) 07:19 (UTC)[回复]
安全投票的話,要不要發通知應該是最緊要的?除此之外要投票投幾天,支持率要多少,也要斟酌。—— Eric Liu 創造は生命(留言留名學生會 2022年2月18日 (五) 06:37 (UTC)[回复]
支持率按慣例是80%。通知按其他維基做法只要公平即可,但是只為一個維基人選舉的發通知有些少拉票的感覺。投票似乎共識為14天。--Ghren🐦🕛 2022年2月18日 (五) 16:28 (UTC)[回复]


那暫定提問期為21日,留三日讓候選人回答?—— Eric Liu 創造は生命(留言留名學生會 2022年2月24日 (四) 13:05 (UTC)[回复]

21天會不會過長了?我擔心累死候選人了。我沒什麼所謂,畢竟回答與不是候選人的自由。--Ghren🐦🕘 2022年2月24日 (四) 13:14 (UTC)[回复]
@BlackShadowG@SCP-2000@Ericliu1912@Temp3600@AT。對於提問日數有什麼看法?--Ghren🐦🕐 2022年2月25日 (五) 05:40 (UTC)[回复]
那再縮短總時程,同時削減討論與提問時間?我記得之前不少人支持三週方案之類的。—— Eric Liu 創造は生命(留言留名學生會 2022年2月25日 (五) 10:49 (UTC)[回复]


我認為太長,14天投票+討論就好。--AT 2022年2月26日 (六) 05:38 (UTC)[回复]
這樣?—— Eric Liu 創造は生命(留言留名學生會 2022年2月26日 (六) 06:58 (UTC)[回复]


對。--AT 2022年2月26日 (六) 08:20 (UTC)[回复]
慢著,提問期可以再縮短些,投票期再延長點。例如5+10。--AT 2022年2月26日 (六) 08:21 (UTC)[回复]
這裡或許應該定義一下「提問」。在既有問題「之上」追問是否算是提問?如果追問也算是提問,那提問期可能要拉長一點。—— Eric Liu 創造は生命(留言留名學生會 2022年2月26日 (六) 09:24 (UTC)[回复]
為什麼要減少投票時間?這樣的話又會有人投訴為什麼不延長投票時間之類的話了,而且和CU和其他站的習慣也不一致,我看不到有很大動機去做。--Ghren🐦🕓 2022年2月26日 (六) 09:55 (UTC)[回复]
那要視乎什麼時候回答提問。另外,不能提問和投票均同時是14天嗎?--AT 2022年2月26日 (六) 10:24 (UTC)[回复]
將圖2的版本改成14天就可以達成你的需要吧。--Ghren🐦🕖 2022年2月26日 (六) 11:05 (UTC)[回复]
另外我記得1233不知道在那個tg群說只少要一周的時間,不能再縮了。--Ghren🐦🕖 2022年2月26日 (六) 11:12 (UTC)[回复]
這是在臨時提出來的情況下吧,不是說要選定一段期間舉行選舉了嗎?—— Eric Liu 創造は生命(留言留名學生會 2022年2月26日 (六) 11:46 (UTC)[回复]
我不敢肯定,但是時間越長總是越好的。@1233--Ghren🐦🕘 2022年2月26日 (六) 13:05 (UTC)[回复]
如果不選定一段時間舉行選舉,以上全部方案都難以確保能夠施行。我自己也擬過一堆方案,想了半天,還是跨不過這個坎。—— Eric Liu 創造は生命(留言留名學生會 2022年2月26日 (六) 16:25 (UTC)[回复]
這樣的話其實現在就可以去監管員佈告板找人了。反正有個固定日期定了出來,之後到D Day的時候填個人名就可以了。投票開始和投票討論時間其實不會差得很遠吧。--Ghren🐦🕛 2022年2月26日 (六) 16:45 (UTC)[回复]
現在的問題是我們連方案什麼時候能喬好都不一定,何況去找監管員。—— Eric Liu 創造は生命(留言留名學生會 2022年3月13日 (日) 10:59 (UTC)[回复]
其實只需要依舊投14,討論14,達到方針原意就可以了。現在的情況可以達到這個目的,就不用改方案了。--Ghren🐦🕖 2022年3月13日 (日) 11:04 (UTC)[回复]
讓用戶自選時間,已經「應戰」得很吃力,如果是規定用戶在選舉期活躍,則必須縮減選舉本身的規模。--Temp3600留言2022年3月13日 (日) 12:05 (UTC)[回复]
我呼吁社群关注限制RfA提问的提案,否则提问时间的制定总会在「不能及时知道」和「候选人负担太重」之间弹来弹去。 ——魔琴 [ 留言 贡献 ] 2022年2月26日 (六) 15:25 (UTC)[回复]
目前SecurePoll即将支持在投票时附加上可选的理由,中文社群可以考虑加上这一功能。 Stang 2022年3月2日 (三) 17:26 (UTC)[回复]
『可選的理由』會否讓投票變成明票?--Temp3600留言2022年3月13日 (日) 12:00 (UTC)[回复]
@Temp3600 可參考UCoC投票,他們會將理由整合成摘要來避免辨識投票者的身份,理由只有監票員才可看到。--SCP-0000留言2022年3月18日 (五) 08:39 (UTC)[回复]

所以現在有沒有任何可行的方案?我想我們需要先決定是否指定一段期間進行選舉(即不允許隨時展開),然後再據此決定時程。—— Eric Liu 創造は生命(留言留名學生會 2022年3月23日 (三) 16:41 (UTC)[回复]

達成目前討投14的目的的話,隨意即可。日期就隨意定為4月15號吧,反正這個日期具體來說什麼日子也沒所謂。--Ghren🐦🕐 2022年3月23日 (三) 17:19 (UTC)[回复]
不能隨意定,還要給社群時間提名人選。但我估計大家不可能只推選一個人,這樣得怎麼辦?—— Eric Liu 創造は生命(留言留名學生會 2022年3月23日 (三) 20:49 (UTC)[回复]
还要找合适的人选。--Lanwi1(留言) 2022年3月23日 (三) 22:02 (UTC)[回复]
現在的問題時沒有人想選(--1233 T / C 2022年3月29日 (二) 13:04 (UTC)[回复]
這不是問題。相信我。—— Eric Liu 創造は生命(留言留名學生會 2022年3月29日 (二) 15:47 (UTC)[回复]
這也不過是提前數天要求候選人要拿到一定的提名而己,然後不只一個人的話就只對最先得到足夠提名人數進行投票即可。我覺得實行上有很多種方法,然後實際上每一種差別實際上都不大,社群不應該為這些末節打轉三個月。--Ghren🐦🕙 2022年3月24日 (四) 02:45 (UTC)[回复]

  • 本次投票以一人為限,以最先得到提名而且合符投票過程要求者的優先進行選舉,其他的押後至下一次;
  • <s提名時間最早者或者;
  • 抽籤;
  • 最早得到七票(參考WP:RFDA)者,但提名票不直接算進票數,提名人的提名和投票取向不一定也不需要一致;
  • 候選人應清楚說明是否參選界面管理員,如需要選票上應該另有一列一條問題;
  • 選舉的關鍵日期應該預先決定以方便安排投票;
  • 討論、提問的時間規定在14天,以得滿足提名條件且得行政員確認一刻起算作14天,14天結束後候選人依然可以回答問題,但不應該再展開討論,也不應該提出新問題;
  • 投票時間起始點可以視乎準備人員需要提前或延後,討論時間不應該因此增加或減少;
  • 參與準備工作的人員沒有投票權(應該要避嫌吧?)被選舉權。Ghren🐦🕛 2022年3月29日 (二) 16:48 (UTC)[回复]
不給被選舉權我覺得就可以了。--1233 T / C 2022年3月31日 (四) 13:28 (UTC)[回复]
我倒是沒有所謂。--Ghren🐦🕙 2022年3月31日 (四) 14:38 (UTC)[回复]
如果沒有意見的話,就按「最早得到七票」、「參與準備工作的人員有投票權但沒有被選舉權」的方案在3天後公示就好了。--Ghren🐦🕓 2022年4月3日 (日) 08:44 (UTC)[回复]
RfA已经不能兼RfIA了……要我说多少遍…… ——魔琴 [ 留言 贡献 ] 2022年4月3日 (日) 08:58 (UTC)[回复]
@魔琴似乎最初的目的之一是因為計票困難,但是在SPoll情況下根本不可能有計票困難的情況?我覺得現行情況下似乎不需要分開,但是假如是基於速速通過的概念上,我也不介意先放一邊。--Ghren🐦🕓 2022年4月3日 (日) 09:39 (UTC)[回复]
可也。那就是四栏“IA+A”“A”“N”“O”? ——魔琴 [ 留言 贡献 ] 2022年4月3日 (日) 10:01 (UTC)[回复]
應該是
Admin:同意 中立 反對
IA:同意 中立 反對
這個樣子吧,可以提供自由度讓選民反對其中之一,或支持其一。--Ghren🐦🕕 2022年4月3日 (日) 10:09 (UTC)[回复]
哦对,我忘记了IA可以不是A。那加的应该是一行不是一列。 ——魔琴 [ 留言 贡献 ] 2022年4月3日 (日) 10:11 (UTC)[回复]
啊,地域詞地域詞,反正就是橫行或者橫列的意思(列_(資料庫) 囧rz……。--Ghren🐦🕕 2022年4月3日 (日) 10:42 (UTC)[回复]
啊呀,我不知道这也是地区词( ——魔琴 [ 留言 贡献 ] 2022年4月3日 (日) 11:06 (UTC)[回复]

公示

  • 本次投票以一人為限,以最早得到七票(參考WP:RFDA,提名票不直接算進票數,提名人的提名和投票取向不一定也不需要一致)者,而且合乎投票過程要求者的優先進行選舉,其他的押後至下一次;
  • 候選人應清楚說明是否參選界面管理員,如需要選票上應該另有一條問題;
  • 選舉的關鍵日期應該預先決定以方便安排投票;
  • 討論、提問的時間規定在14天,以得滿足提名條件且得行政員確認一刻起算作14天,14天結束後候選人依然可以回答問題,但不應該再展開討論,也不應該提出新問題;
  • 投票時間起始點可以視乎準備人員需要提前或延後,討論時間不應該因此增加或減少;
  • 參與準備工作的人員沒有被選舉權,但可以投票。

公示7日Ghren🐦🕐 2022年4月7日 (四) 05:30 (UTC)[回复]

本討論章節會維持開放,暫時不按最後意見發表時間存檔。欲讓機器人存檔,請移除本模板。留言請置於本模板上方。

Zh.WP checkuser re-introduction/重新引入中文維基百科用戶查核權限

原标题为:Zh.WP checkuser re-introduction/重新導入中文維基用戶查核權限

The members of the local Chinese language Wikipedia community and the Stewards, who currently provide CU support to Zh.WP, have indicated to the Foundation that it would be desirable to explore possibilities of reinstating local CheckUser privileges on Chinese language Wikipedia. These rights were revoked from the local community due to security concerns in 2018.

中文維基百科本地社群成員以及替中文維基百科提供用戶查核支援的全域監管員已向維基媒體基金會反映希望恢復中文維基百科的用戶查核權限。此權限基於安全考量,於2018年自本地社群移除。

As a Foundation, we strongly endorse community self-governance wherever feasible. We also realize that each community has unique challenges that require authentic approaches that tackle them. In this spirit, we would like to state that the Foundation would support reinstating local CU privileges if Zh.WP meets two conditions.

作為基金會,我們在許可範圍內強力支持社群自治;我們也同樣理解不同的社群有其特有的挑戰,亦需要用獨特的方式來應對。本著此精神,我們想聲明:若中文維基百科可以滿足下述兩個條件,基金會將會支持恢復本地社群之用戶查核權限。

First, that the local Chinese language Wikipedia community offer their commitment to uphold the global aspects that all communities with local CU privileges uphold. A critical element is policy compliance. Currently, all communities with local CheckUser privileges are required to adhere to binding policies governing the recruitment of CheckUsers and the use of the tool. The potentially elected Zh.WPs CU would need to strictly uphold the Compliance with the CheckUser Policy and Compliance with the Access to Non-Public Information Policy, including the NDA policy update 2021. The local community should in turn respect these instruments.

首先,中文維基百科本地社群必須承諾維護所有擁有本地用戶查核權限之社群的通用認知。其中一個關鍵要素為政策規範合規性。目前,所有擁有本地用戶查核權限之社群都被要求要遵守有關用戶查核者的招募及使用工具之約束性政策。未來中文維基百科中可能當選為用戶查核員之用戶必須恪守用戶查核政策與非公開個人資料存取政策,包含2021年更新之保密協議。本地社群必須尊重這些政策文件。

Secondly, the Foundation is aware that the Chinese language Wikipedia continues to have long-standing internal trust challenges unique to the local community. We are aware that the local community is confronting noteable difficulties in local collaboration both on the Chinese mainland and internationally. As a Foundation, we undertake to support the re-introduction of the local CU rights if:

再來,基金會已認知到中文維基百科持續面臨當地社群獨有的長期內部信任挑戰。我們理解本地社群在本地合作/協作上,不論是與中國大陸還是跟國際社群都窒礙難行。作為基金會,我們承諾在滿足以下情況下支持重新引入本地用戶查核權限:

  1. Elections: All Zh.WP elections for CheckUser are conducted through SecurePoll elections (two weeks), with Steward scrutiny support. Doing so would provide greater safety to both candidates and voters. Further to this, the appointment tenure for CU user rights holders on Zh.WP to be two calendar years, at the end of which re-election of CheckUsers aiming to extend their tenure via SecurePoll will be required. Doing so would enable the local community, which does not have a NDA-signing ArbCom providing added accountability for CUs, to assess whether they still have sufficient trust in their local CUs after a meaningful period of time. There will be a recall mechanism for CUs. In it, voting-eligible users can safely register their voice in case they have lost confidence in a CU in-between elections. Once registered, a concern will be valid for a year or until the next re-election. 25 valid concerns related to a CU at the same time will trigger a recall election within two months, unless said CU decides not to run for re-election. Two years overall tenure in-between regular elections is in-line with long-standing re-election practices for CUs on German and Portuguese language Wikipedias, two other large communities with local CUs but without a NDA-signing ArbComs.
  2. Training: All successful Zh.WP CU candidates to be trained in CU community best practices prior to the user rights change granting them CU rights. Doing so would ensure alignment of Zh.WP CU practices with the global community.
  3. Audits: The Foundation will regularly audit CU activity on Zh.WP for at least a year; including an evaluation after a year whether or not to continue such audits. A practical way for that is keeping the current community consensus-based requests for checks. The community would comment on requests, which can then be audited for problematic users stacking against a certain user.
  1. 選舉:所有中文維基百科之用戶查核員選舉必須透過SecurePoll秘密投票,每次選舉為期兩周,選舉期間必須有全域監管員支援監票,這樣做將有助於提供候選人及選舉人更大的安全保護。此外,當選之用戶查核員任期為兩年,在任期結束後必須要再度重新參與選舉,通過秘密投票來延長任期。這樣做將有助於社群,在缺乏簽署保密協議之仲裁委員會確保用戶查核員負責任的情況下,有一段時間去檢視和評估他們對於當地的用戶查核員是否有足夠的信任。用戶查核權限將有除權機制:有人事任免投票資格的用戶可以安全地提出自己的質疑,此質疑有效期為一年,或是到下次用戶查核員選舉之前;如果有超過25人之質疑關切,就會在兩個月內觸發罷免,除非該查核員選擇不競選連任。上述任期制度已由德語、葡萄牙語兩大有本地用戶查核權限但沒有簽署保密協議的仲裁委員會的社群採用。
  2. 訓練:在授予權限之前,所有中文維基用戶查核員候選人都將會接受用戶查核員社群的培訓,以確保中文維基上的用戶查核實踐與全球社群一致。
  3. 稽核:基金會將會定期稽核中文維基之用戶查核活動至少一年,此舉包含一年後是不是要繼續持續這樣的稽核機制等。目前針對稽核有一個實用的方式:持續目前基於社群共識作出的查核請求;社群將對這些請求發表評論,令基金會可以稽核這些評論,以便尋找針對特定用戶的問題用戶們。

Finally, the Foundation commits to facilitating the functionary-guided creation of a CU self-learning module, available in Chinese and English in the Wikimedia LMS in 2022. This will document global community best practices for the tool and its appropriate use in a local community context.

最後,基金會承諾會促成在官方公務員(functionaries)指導下創建一個用戶查核權限自我學習模組,其中英雙語版本將於2022年在維基媒體LMS供查閱,此舉將把全球社群在使用該工具的經驗以及使用方式以當地社群語言妥善記錄。

WMFOffice留言2022年1月13日 (四) 20:38 (UTC)[回复]

“當選之用戶查核員任期為兩年,在任期結束後必須要再度重新參與選舉,通過秘密投票來延長任期....”WMF欽點了這個方法,那我認為可以在sysop上長遠使用啊?--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵~ 2022年1月14日 (五) 08:30 (UTC)[回复]
不同意管理員任期制。另外我甚至反過來擔心這樣選使用者查核員會不會難產。—— Eric Liu 創造は生命(留言留名學生會 2022年1月14日 (五) 10:04 (UTC)[回复]
難產的話,若有要查核就先轉交全域監管員?--0906(回復請Ping我) 2022年1月14日 (五) 15:22 (UTC)[回复]
是的,如果难产,先转交至监管员。--夏雪若留言2022年1月14日 (五) 15:28 (UTC)[回复]
難產也要。这是御旨。--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵~ 2022年1月15日 (六) 05:51 (UTC)[回复]
我认为SRCU还有必要继续存在,鉴于社群目前的互信情况。不仅是CU员难产的问题,即使能选出CU员,社群对CU员的信任程度又有多少?到时候涉及老用户的查核可能还得监管员帮忙。另外我强烈建议CU的选举在管理员的安全投票试行一段时间后再举行。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月14日 (五) 15:34 (UTC)[回复]
我想请问训练将在哪进行,以及训练一名用户查核员需要多长时间。--BlackShadowG留言2022年1月17日 (一) 00:21 (UTC)[回复]

对于重新引入不报希望,即便引入也是CU员难产。桐生ここ[讨论] 2022年1月18日 (二) 05:11 (UTC)[回复]

  • 如果已经明确计划好要恢复查核员,那对于无法签署NDA的大陆用户应该会造成更大规模的(无论主观或客观)歧视与不公平现象。毕竟曾经出现过
这种话,而现在大陆用户连监督员都无法担任。--Yining Chen留言|签名页2022年1月18日 (二) 14:34 (UTC)[回复]
基于上方理由,(-)強烈反对引入用户查核员,而且NDA不承认中国大陆的理由也合理无法反驳,不论对于歧视还是安全原因,都应维持现状。桐生ここ[讨论] 2022年1月18日 (二) 14:46 (UTC)[回复]
我反对恢复本地CU权限的理由是大陆用户无法签署NDA以及对港台用户与居住在海外的大陆人的不信任,应该维持现状。--Lanwi1(留言) 2022年1月18日 (二) 14:57 (UTC)[回复]
既然这样,我建议自废武功,本地CU不能查有关延伸确认用户的请求,而应转交元维基;本地CU查到有关延伸确认用户的案件,应送报元维基核实。 ——魔琴 [ 留言 贡献 ] 2022年1月19日 (三) 04:19 (UTC)[回复]
所谓安全问题不是CU作出虚假结果,而是泄漏非公开数据,比如举报到香港国安处或者FBI,是编者的人身安全问题,即便CU值得信任,但是不能保证CU所在或所属的当局不会强迫CU进行查询,虽然大陆不能签署NDA,但比如香港、澳门实际上也是不安全的,要是排除这三个地方,就是一种歧视,因此不如维持现状。桐生ここ[讨论]2022年1月19日 (三) 04:38 (UTC)[回复]
我觉得目前大概两点疑虑,一点是打击报复,我觉得我的方案可以解决;一点是CU数据的安全性,大陆人不能签NDA可以保证(至少很难被中华人民共和国获得)。另外我很疑惑的一点,为什么排除港澳就是歧视,排除大陆就不是?既然现在港澳还能签NDA,我们就没必要帮WMF担心。如果真的觉得港澳不安全,那就应该跟WMF建议撤销港澳人士的NDA。没有说港澳能签NDA但做CU不安全的道理。 ——魔琴 [ 留言 贡献 ] 2022年1月20日 (四) 04:29 (UTC)[回复]
支持合资格且有意向者申请用户查核权限,反对自我矮化主權,现今转交元维基的操作过于繁琐。先前对本地CU的担忧在于中共威胁与WMC渗透,基金会行动后已不是大问题。住所不为第三方所知的大陆用户仍然可以签NDA,而上方讨论中所说的“歧视与不公平现象”并无前例。--Lt2818留言2022年1月19日 (三) 05:21 (UTC)[回复]
据我所知,User:Alexander_Misel的住所应该不为第三方所知,然而却有该笔日志(注意此日志发生在WP:OA2021之前,与OA无关)。第二点,只知道担心“中共威胁与WMC渗透”,那我们这些用户要不要担心“█国民主党和F█I威胁与H█U█渗透”?第三点,“歧视与不公平现象”没有前例,但正在发生。建议参考自基金会行动以后站内的几项所谓“决议”的流程。另:怎么看待上方在查核员尚未被废除时真实出现过的言论?只是维基人间“友好的交流”?现在为解决这种现象所做出的唯一努力就是“歧视大陆用户”吗?(可能违反WP:AGF,故自行删除)虽然基金会做出的决定改不了,这一点没错啦;但是还是很想知道类似这种“决定”的支持者是怎样思考问题的。--Yining Chen留言|签名页2022年1月19日 (三) 14:39 (UTC)[回复]
具體住址是不知道,但是具體城市他曾經在QQ群公開過,他說那天他所在的城市居民包括他本人在內被全員核酸檢測。--中文維基百科20021024留言2022年1月19日 (三) 14:27 (UTC)[回复]
我觉得住所不为第三方所知的大陆用户可以签NDA,也有大陆用户完全不愿公开自己的住址。--Lanwi1(留言) 2022年1月19日 (三) 15:43 (UTC)[回复]
即使“完全不愿公开自己的住址”,如果参加了任何线下活动,也很可能会有问题。甚至更极端的,在任何社交网站或者Zoom等地方公开了自己的照片,也有问题。更不用说真实身份早就众所周知的用户。--GZWDer留言2022年1月21日 (五) 10:07 (UTC)[回复]
个人认为连六扇门都难以找到住所的用户才满足条件。至于上述个案,原因恐怕不止于此。--Lt2818留言2022年1月20日 (四) 03:40 (UTC)[回复]
Wikipedia:河北维基人列表显示,该名用户现时住在石家庄。--Alexander Windsor谈笑风生 2022年1月23日 (日) 07:13 (UTC)[回复]
個人意見同Lt2818閣下。—— Eric Liu 創造は生命(留言留名學生會 2022年1月19日 (三) 07:41 (UTC)[回复]
除非 User:PMDdeSN 一事明了,否则(-)反对。--广雅 范 2022年1月19日 (三) 08:18 (UTC)[回复]
那看來洩露CU紀錄的事情不止一位,要是CU回歸中維的話大家應該做好心理準備。--中文維基百科20021024留言2022年1月19日 (三) 08:36 (UTC)[回复]
是什么事?没有了解过。--Tranve () 2022年1月20日 (四) 01:38 (UTC)[回复]
@TranveWikipedia:互助客栈/其他/存档/2017年10月#用戶查核不得不說的事 --Lt2818留言2022年1月20日 (四) 03:40 (UTC)[回复]
(!)意見如果本地重新獲得用戶查核權的話,可以保留元維基用戶查核請求權以處理有爭議的本地查核案。--🎋🎍 2022年1月22日 (六) 12:25 (UTC)[回复]
有爭議的话,找其他本地查核员复核较为合适,亦可找申诉专员。监管员不会有更高权威,君不见三位监管员确认之傀儡都能被抵赖掉。--Lt2818留言2022年1月22日 (六) 14:17 (UTC)[回复]
如果要找申诉专员,可能会面临举证难题,而且这难道不是对一些 处于弱势且不精通外语的中国大陆用户 的一种歧视?(除非申诉专员里出现了zh-2用户)--Yichen Ding留言|主账户2022年1月22日 (六) 14:49 (UTC)[回复]
就監管員吧,申诉专员處理效率肯定沒監管員好,不過可能要先問監管員願不願意。照規定來說,監管員不能處理有本地查核員的查核請求。--2022年1月22日 (六) 18:32 (UTC)[回复]
個人認為基金會會推動本地CU建立,然後到時監管員就不用管咱的CU請求了。除非有人跟基金會討論過可不可以維持現狀,不然我覺得樓上提的關於CU的問題要面對只是早晚而已。--2022年1月26日 (三) 23:58 (UTC)[回复]
基金會沒打算解釋一些細節麼?—— Eric Liu 創造は生命(留言留名學生會 2022年2月11日 (五) 03:39 (UTC)[回复]
包括所謂的除權機制、當選人所接受的培訓,以及定期稽核等等,基金會都沒有給出足以讓本地社群討論或訂立規範的內容。—— Eric Liu 創造は生命(留言留名學生會 2022年2月21日 (一) 12:28 (UTC)[回复]
读完了大家的讨论,我的观点也是给中维CU不够安全。原因有二,首先,WMC和中共不是我们唯二要防的信息泄露对象,前面各位点到的其他政权和团体对中维产生的潜在信息泄露威胁也不是空穴来风。其次,在没有办法向内地用户提供CU权限的情况下,也很难平衡不同地区的查核员的比例。除此以外,基金会这次给出的信息太过有限了,不知道该如何应对。Itcfangye留言2022年2月26日 (六) 06:31 (UTC)[回复]
  1. WMC和中共是特定于中文站点的担忧对象,其他实体或者未见对本地的危害迹象,或者对全域项目有影响(如NSA对维基百科的监控),不见得由监管员代替本地查核员即能消除信息泄露威胁。
  2. 未见“平衡不同地区的查核员的比例”之必要性,这与查核工作能否安全有效运行并无关联。
--Lt2818留言2022年2月27日 (日) 13:43 (UTC)[回复]
意见同上。另外,wikt:空穴來風。 ——魔琴 [ 留言 贡献 ] 2022年2月27日 (日) 15:20 (UTC)[回复]

re-meta:Special:Diff/22831347

  1. 在公告“具备投票资格的用户可以安全发表自己的声音,以防他们在 CU 选举之间失去信心。”,具体步骤是什么?
    社区需要决定什么是合格的选民。安全选举是 SecurePoll 选举。社区已经设计了不同的方式来表明在定期选举之间失去信心。例如,德语维基百科强制使用该系统
  2. “所有成功的 Zh.WP CU 候选人都将在 CU 社区接受培训”如何培训?在哪里培训? 培训一位用户查核员需要多少时间?
    全球志愿者社区和基金会需要共同开发一个培训模块。培训模块可以托管在 learn.wiki 上,总共可能需要大约 2-4 小时。
  3. 2017 年发生了一起事件,当地用户查核员公开披露了 CU 数据。我理解 T&S 出于隐私和法律原因无法发布详细信息。但事件已经解决了吗?
    默认情况下,基金会不会公开讨论其调查案件的细节或状态。
  4. 当地讨论中有一个提议,如果有复杂的案件,即使有当地的用户查核员,也可以要求 CU 管理人员调查。这个提议可以接受吗?
    这是当地社区直接与管理人员进行的对话。基金会要求尊重相关政策和标准,但当地 CU 或管理人员是否调查案件取决于当地和全球社区,而不仅仅是基金会的观点。
  5. 本地讨论中表现出对本地 CU 结果难以接受的担忧。因为语言障碍,一些本地用户的英语可能不太流利。有什么方法可以帮助当地社区成员轻松上诉?
    防止用户查核员滥用的第一层控制在于其他用户查核员。这就是为什么全球用户查核员政策总是要求有一个由两人组成的本地团队。这样总有其他人可以看到 CU 数据并且产生制衡。如果仍担心和怀疑滥用 CU 工具,可以随时将此类问题提交给申诉专员委员会,可以使用任何语言向申诉专员委员会提出问题。--WMFOffice留言2022年3月1日 (二) 03:47 (UTC)[回复]
假如連WMF出來回答了也沒人給反應的話,我唯有移走不存檔模板當大家都不想要CU了。Ghren🐦🕓 2022年3月10日 (四) 08:33 (UTC)[回复]
确实有支持也有反对……WMF也解答了一些反对票的疑惑。我们是不是可以整理一下各方观点看看有没有突破口。 ——魔琴 [ 留言 贡献 ] 2022年3月10日 (四) 23:17 (UTC)[回复]
问题是 WMF 说的不明不白:在 18 年行动之前有 6 名查核员,除去WP:CU中记载的推定离任的那几位还剩下三位。这三位到时候是直接复职还是要经过上面的 secure poll 投票?推定离任的是确实像 OS 那样已经经过邮件确认离任还是要再 lock 一次然后发邮件申请离任?从上面的讨论来看至少有两次 CU 数据泄露,站外的和站内的,但是从 18 年到现在 WMF 既不告知调查结果也没有见到 WMF 对当时的查核员做出行动。可否推断 WMF 对此事也是无结论?如何能确保将来不再发生此事?--广雅 范 2022年3月11日 (五) 15:33 (UTC)[回复]
应该是不能直接复职。 ——魔琴 [ 留言 贡献 ] 2022年3月11日 (五) 15:46 (UTC)[回复]
同魔琴君,應該不能直接複任,並需重新經過上述投票。「如何能确保将来不再发生此事?」根據WMF現有提供的資訊,應該是藉培訓、監察機制及秘密投票來確保查核員的素質,從而防止洩露事件的出現。謝謝。--SCP-0000留言2022年3月11日 (五) 16:37 (UTC)[回复]
说实话我不认为这些方法可能有用。User:PMDdeSN 虽然各人有一定猜测,但现在都没有确定是当时哪位查核员泄露的数据。如果知道的话当时就可以发起解任投票,而不用等到基金会介入。在大家都没有证据确定是谁的话安全投票无法确保社群的监督机制。而且所有查核员都签署过 NDA,新开一个一次性账号也能证明此人是清楚这种行为是严重违反规定的,因此培训能达成的功效也有限。当时此事通报基金会后基金会肯定也进行过一系列调查,但就像我之前说的,至今都没有发现有相应的 office action 出来,因此我怀疑监察机制能否达到预期。--广雅 范 2022年3月12日 (六) 13:46 (UTC)[回复]
(▲)同上。基金会在这件事上似乎除了移除中维查核权限外束手无策。很让人怀疑基金会是否真正有有效方法来避免以后出现同样的问题。不要等到刚刚恢复CU权限第一天就出现隐私泄漏事故。[開玩笑的]----Yichen Ding留言|主账户2022年3月15日 (二) 15:20 (UTC)[回复]
最糟糕的情況下,也不過就是禁止前使用者查核員競選罷了。又或者等個幾十年,所有相關人士全死光了才能選新的?我個人不希望將本地查核作業永遠丟給監管員來做。—— Eric Liu 創造は生命(留言留名學生會 2022年3月23日 (三) 16:53 (UTC)[回复]
禁止前查核员竞选也不能保证新查核员没问题吧,毕竟当时选前查核员时也没料到会出当时的事情。我本身不反对本地拿到 CU 权限,但问题是之前出的事情总得有个交代。不然现在都知道查核员自己用傀儡连基金会都没法查出来了,难保不会出现第二次第三次。还有上面提到的查核员个人私下将数据泄露给第三方的问题。--广雅 范 2022年3月24日 (四) 02:11 (UTC)[回复]
@Ericliu1912Yining Chen 近日向基金會詢問他們有沒有其他方式來應對洩漏CU數據的問題,他們的回覆可見此。另也可參考一位英維管理員的意見。謝謝。--SCP-0000留言2022年3月26日 (六) 00:26 (UTC)[回复]

若不能滿足以下兩個條件,不論誰參選用戶查核員,一律投反對票。

IP Internet
Protocol
Address
網際
協定
位址
UA User
Agent
使用者
代理
  • 私隱:現行的設置總有漏網之魚。這權限應改成不能查核IP用戶,也不能顯示註冊用戶的IP和UA,每次只能查核某註冊用戶之間的關係,均為系統過濾後的結論,類似於全域監管員的答覆,去除不必要的安全憂慮。
  • 監察:任何人都可以請求查核用戶,唯決定權在於用戶查核員。使用權限前必須通知被查核的用戶;使用權限時提供充足的理由來解釋,只有懷疑濫用傀儡的情況才需要查核;使用權限後系統應自行記錄,讓任何人都能看見。

--月都留言2022年3月29日 (二) 23:46 (UTC)[回复]

(+)支持公開查核記錄,但(-)反对關於隱私的設定更改,明顯存在對用戶查核工具的錯誤理解。監管員給予的答案均是不能簡單以編碼代替的,況且用戶查核員本身還需要(因應請求和合適情況)進行查核以延長自動封鎖(WP:CUP#1)和查核用戶請求IP封鎖例外是否與其申訴/申請所言相符才授予權限(WP:CUP#3,現在都沒有在執行)。同時(-)反对使用權限前必須通知被查核用戶,不可能預先通知LTA他們即將被查核。無論是操作上還是原理上,這些要求都是完全不合理的。--路西法人𖤐 2022年3月30日 (三) 03:07 (UTC)[回复]
用點常識就知道不可能公開查核日誌了好嗎?如果日誌上寫著已查核User:Example,然後緊接著已查核IP:1.2.3.4,那麼有點邏輯的人都知道User:Example的IP是啥了。--Xiplus#Talk 2022年3月30日 (三) 04:48 (UTC)[回复]
感謝兩位提出意見,參考RBI論述應不理會LTA,使用權限前必須通知被查核用戶,這要求或有不妥之處,故此添加删除線;縱上有用戶指出潛在泄漏資訊的威脅,過去已發生泄漏數據的事件,恢復本地社群之用戶查核權限前,私隱安全需要得到重視,不然如桐生所說維持現狀。 --月都留言2022年3月30日 (三) 05:16 (UTC)[回复]
查核日誌僅針對用戶,而IP用戶則僅標記XXX查核了「某個IP」(真的是「某個IP」)這樣即可。沒人說一定要顯示出來的。另外,執行WP:CUP#1的時候,監管員或用戶查核員封鎖個別IP的時候,不也是同樣一邊出查核結果,一邊進行{{checkuserblock}}嗎(監管員的封禁日誌)?我覺得MASK了IP就已經能符合查核日誌的私隱要求了。--路西法人𖤐 2022年3月30日 (三) 10:14 (UTC)[回复]
(+)支持查核日誌僅針對用戶,不顯示IP位址;在保證私隱沒有外泄的可能時,同意本地引入用戶查核權限。 --月都留言2022年3月30日 (三) 13:54 (UTC)[回复]
@LuciferianThomas:有時會對封鎖日誌進行監督,就是為了隱私,或是等一段時間才封鎖等緩解措施。--Xiplus#Talk 2022年3月30日 (三) 13:56 (UTC)[回复]
確實如此,那麼除對查核員及監管員外不顯示IP的查核日誌是否合理的技術性保護用戶途徑?此外,亦必須向基金會詢問不具有查核權限的用戶透過建立鏡像站而獲得類同用戶查核的資訊是否符合隱私政策。--路西法人𖤐 2022年3月30日 (三) 14:13 (UTC)[回复]
(+)支持,甚至即使不公开对IP用户的查核记录也无妨。--Yining Chen留言|签名页2022年3月31日 (四) 14:08 (UTC)[回复]
那麼應該先諮詢技術團隊跟法律團隊。--Xiplus#Talk 2022年3月31日 (四) 16:08 (UTC)[回复]
把「•公開」修改為社群「•監察」,以防止查核員濫用職權。 --月都留言2022年3月31日 (四) 16:57 (UTC)[回复]
原則上只要不公開IP和帳號之間的關係就可,或可考慮只公開查核涉及對象而不公開相關IP。謝謝。--SCP-0000留言2022年3月30日 (三) 15:56 (UTC)[回复]
“改成不能查核IP用戶,也不能顯示註冊用戶的IP和UA,每次只能查核某註冊用戶之間的關係,均為系統過濾後的結論”并不可行。用户查核工作面对的是多样且未知的情况,需要查核员接触尽可能多的原始信息,例如:
某一位疑似LTA的用户的某一笔编辑显示的IP位于北京,该IP不是校园、公司等共享IP;而另一位疑似LTA的用户5分钟后的另一笔编辑显示的IP位于广州,同样不是共享IP。那么查核员可以推断除非共享账号,否则两位用户几乎不可能是同一人。但
  1. 如果不是5分钟,而是5小时,那就有可能是这位用户坐飞机去了广州;
  2. 如果后者是校园网IP,那可能是一位在北京的用户,挂了广州某高校的VPN,这种可能性要进一步通过对该名LTA本身的了解来进一步证实或证否;
这些信息都是单纯的“查关系”所查不出来的。--Antigng留言2022年4月6日 (三) 10:00 (UTC)[回复]
鄙人才疏學淺,感謝閣下提供寶貴意見,並作出詳細解釋!不怕查出註冊用戶的關係,只怕走上門騷擾維基人;隨著資訊科技的進步,希望WMF研發工具,主要保障私隱安全,拆穿偽造民意的行為:計算地圖上不同用戶的時間、距離、位址移動,予查核員接觸這些資訊,但不能查核IP和地理位置,請問是否可行? --月都留言2022年4月9日 (六) 03:35 (UTC)[回复]
絕對不可行,不能查核IP基本上等於將整個用戶查核工具廢了,而你提出「計算地圖上不同用戶的時間、距離、位址移動」只會給用戶查核員提供如安亭所言的誤導性資訊,完全不可行。--西 2022年4月10日 (日) 05:54 (UTC)[回复]
用户查核就跟破案一样,涉及的不仅仅是“已知的未知”,更有“未知的未知”。作为管理人员我们甚至不知道未来会遇到怎样的案情,需要综合运用哪方面的信息,通过怎样推理得出什么样的结论——涉案人员并不总是按有限、既定的规律、套路出牌。要求查核员不接触IP就好像是要求探员不接触一手证据一样,这样根本没法破案。--Antigng留言2022年4月11日 (一) 15:46 (UTC)[回复]

本討論章節會維持開放,暫時不按最後意見發表時間存檔。欲讓機器人存檔,請移除本模板。留言請置於本模板上方。

提議新建交通車輛條目內容方針2

本指引為交通車輛條目內容指引,統一格式將有助於閱讀及編輯維護上的便利性,以及減少特定章節的編輯戰,目的是幫助編者建立具有一致性的條目作品。

行文結構

鐵路車輛

  • 導言:簡述車輛所屬的鐵路公司、製造商、服務路線、投入服務日期等,並精要概括正文。
  • 資訊框:一般用用{{鐵路車輛}},亦可使用{{鐵路車輛2}}。模版應照文檔填寫。
  • 概要:介紹車輛引進緣由、役緣由(如已除役之車輛)、基本概述等。
  • 規格與構造:介紹車輛基本構造、機電設備、外觀塗裝、設備規格、編組方式等。
  • 重大事故:若車輛曾經發生過重大鐵路事故可初步簡述事故經過,並使用{{main}}作主條目導向。
  • 相關條目:與條目相關的車型或車種可於此列出。
  • 參考文獻:請列明來源!報章雜誌、鐵路公司官網的車輛簡介、車輛製造商的車輛簡介與政府出國報告書都是好的來源。切記,不可使用部落格與營運單位的內部文件作為來源。
  • 外部連結:可連接其他維基計畫或是未達可靠來源門檻的百科性資源

客運/公車車輛[註 1]

  • 導言:簡述車輛製造商、車輛類型等,並精要概括正文。
  • 資訊框:一般用用{{Infobox Automobile}}。模版應照文檔填寫。
  • 概要:介紹車輛引進緣由、退役緣由(如已除役之車輛)、基本概述等。
  • 相關條目:與條目相關的車型或車種可於此列出。
  • 參考文獻:請列明來源!
  • 外部連結:可連接其他維基計畫或是未達可靠來源門檻的百科性資源

條目內容

不合適的內容

  1. 愛好者內容
    • 鐵路車輛:請不要將車輛車次運用、車號機務段分配、改造期程、交車期程等瑣碎資訊加入條目內。
    • 客運/公車車輛:請勿將領牌車號、行駛路線、停靠站牌等瑣碎資訊加入條目內。
    依據:維基百科不是不經篩選的資訊收集處-說明書
  2. 大量的短條目:通常一個較大的條目能提供對主題更有條理的介紹與背景聯繫。當大條目能做到時,請不要創建大量小條目。理想的條目是既不過大,也不過小。
    依據:維基百科的條目大小指引
  3. 過多的圖片:請勿於條目內放置各車號的照片,於資訊框模板一張代表即可,其他照片則放入共享資源並於底下納入共享資源連結導引。

備註

  1. ^ 此指大客車、巴士,不含小客車、計程車,小型車請參見汽車一節。

因討論被機器人存檔,且尚未完成討論故接續提案,部分內容已依照上次討論提議更新--🚊鐵路Railway 2022年2月20日 (日) 05:24 (UTC)[回复]

似乎沒有通知成功,重新標註一次@owennson心平星辰一片楓葉BIT0865Bus FollowerMys_721txNryaLuciferianThomasGhrenghrenSickManWP--🚊鐵路Railway 2022年2月21日 (一) 12:56 (UTC)[回复]
(+)支持,另外建議增加關注度方針。--Nrya ✰沿路看風雨漫漫 2022年2月21日 (一) 13:02 (UTC)[回复]
@Nrya閣下的意思是再額外建立關注度方針、於此方針中加入還是於NT:T中加入?--🚊鐵路Railway 2022年2月21日 (一) 13:26 (UTC)[回复]
“行文结构”的“参考文献”一条,部落格的消息确实不敢保证真实性,但是营运单位的内部文件……抱歉,中国大陆有不少地铁列车都没法不用它,参见武汉地铁DKZ8型电动车组的参考文献。--BIT0865 · Discussion · 燕房线永远的神! 2022年2月21日 (一) 13:32 (UTC)[回复]
@BIT0865噢....若將「檔案」更換成「公文」呢?呢因為臺灣的車輛條目經常出現使用短期且快速更新的內部資料編輯愛好者內容,當初使用檔案一詞是為了阻止此狀況,而這些引用屬公文電報,更改引述應該可行吧0.0--🚊鐵路Railway 2022年2月21日 (一) 14:08 (UTC)[回复]
內部文件關鍵應該是非公開的文件。公開文件是沒問題的,這種文件應該是可以網站找到,或者圖書館可以找到的,而不是那種要愛好者拍一次,再上傳才可以找到的的文獻。「武汉轨道交通一号线一期工程车辆使用维护说明书」這種文件雖然是官方的,但是理論上不外傳的吧,這樣的話其實不應該用。--Ghren🐦🕑 2022年2月22日 (二) 06:11 (UTC)[回复]
協助標註@BIT0865--🚊鐵路Railway 2022年2月23日 (三) 10:30 (UTC)[回复]
但是如果没有那本说明书的话,那个条目我可以直接提删了——因为没加说明书的内容之前条目里面确实没什么东西——很多地铁列车的小条目都有这样的遗留问题。--BIT0865 · Discussion · 燕房线永远的神! 2022年2月23日 (三) 11:32 (UTC)[回复]
还有就是,“而不是那种要爱好者拍一次,再上传才可以找到的的文献”……那我甚至可以退出维基了,请看这里的“各种 VVVF 铭牌”。--BIT0865 · Discussion · 燕房线永远的神! 2022年2月23日 (三) 11:34 (UTC)[回复]
@BIT0865若逆向搜索能搜索到可靠來源則直接使用新的可靠來源,應該很多東西都是逆向搜索找到正確的參考資料,不一定要以照片為唯一來源--🚊鐵路Railway 2022年2月23日 (三) 14:57 (UTC)[回复]
有文献可查的话,能不拍铭牌就尽量不拍,铭牌充其量用作保底,典型的例子是广州地铁A1型广州地铁A5型。但是像DKZ16的情况,① 太平湖车辆段有介绍各种铭牌的小册子,② 车辆段的小站台边上也可以经常拍铭牌;但是不用这两种方法,(在将铭牌照片传到维基共享资源之前)根本搜不到 MAP-184-75VD177,就比较为难了。--BIT0865 · Discussion · 燕房线永远的神! 2022年2月23日 (三) 15:29 (UTC)[回复]
甚至于,有时查到的某个型号也不能确定属于哪种车型。比如 MAP-184-75V208 可能属于四种车的一种,MAP-164-15V230 可能属于两种车的一种,这两个型号都是单一来源,不去问员工的话,没有其他来源协助确定,但是问员工却不巧又出现了困难。所以说白了,新车到段之前就把车底下查完真的很重要。--BIT0865 · Discussion · 燕房线永远的神! 2022年2月23日 (三) 15:35 (UTC)[回复]
大致(+)支持相關方針改動。很抱歉由於健康問題(右眼失明)本人不太有時間參與相關方針的建設。--SickManWP邀請您加入❤️邊緣人小組·🖊️簽到 2022年2月21日 (一) 15:18 (UTC)[回复]
支持。-Mys_721tx留言2022年2月21日 (一) 17:36 (UTC)[回复]
(+)支持:支持另建方針。呈上,如果中國大陸境內有此情況,那可能就採取共用大架構,另立小特別款?畢竟台灣這端出現在拿未確定是否可公開外流的台鐵內部行車電報來放此舉應不妥;圖片部分車號是指大的編組,舉例以言之,TEMU1000型全編8輛,放這8輛圖片可,但每一編組(TEMU1001+1002~1015+1016)均放或可議,畢竟適量的放圖片有助於閱讀跟版面配置,其他放共享資源;車輛車次運用、車號機務段分配、改造期程、交車期程等這些就放入學院吧,維基是阻止不了的,那就面對現實導入比較可行的維基學院吧,以上相關資源則在條目內設連結引導。消波塊留言2022年2月22日 (二) 01:47 (UTC)[回复]
这里展开说下“中國大陸境內有此情況”:
① 不少爱好者遇见新车(尤其新车)只顾着看外观,没有查证设备的意识,等到新车上线了再去查往往非常困难。
② 中国大陆没有专门介绍地铁或者铁路车辆的报刊杂志,因此情况 ① 的直接后果就是不得不求助于员工。
③ 即便是求助于员工也不能保证马上得到反馈,尤其是铁路车辆,一些动车组的裙板非常重,不是所有员工都愿意动不动打开裙板去看里面有什么。
--BIT0865 · Discussion · 燕房线永远的神! 2022年2月23日 (三) 12:21 (UTC)[回复]
@BIT0865關於第二點據在下所知有《鐵道知識》期刊,國際標準書號為ISSN 1000-0372,如北京地铁DKZ13型电动车组剛剛在下已協助增加來源。--🚊鐵路Railway 2022年2月23日 (三) 13:16 (UTC)[回复]
感谢添加文献,但是《铁道知识》似乎不如中国铁路总公司的《铁路机车概要》详细,里面应该没有记VFI-HR2420E和SVI-H116A(铭牌上有写,但是铭牌太小并且靠近车厢底板,所以站台上看不见,只能问员工)。--BIT0865 · Discussion · 燕房线永远的神! 2022年2月23日 (三) 13:30 (UTC)[回复]
@BIT0865若是反向搜索來源應該可以吧...知道型號和廠牌之後去製造商官網找相關資料。--🚊鐵路Railway 2022年2月23日 (三) 14:07 (UTC)[回复]
你想得太天真了:DKZ13的牵引系统,《日立评论》倒是详细介绍了工作原理,但是对型号只字不提,不知何故;《东洋电机技报》里有关 SFM04/04A 和 DKZ32/33/34 的情况亦如是,它们的VVVF型号全是靠格式规律插值推出来的,然后再靠铭牌确认。--BIT0865 · Discussion · 燕房线永远的神! 2022年2月23日 (三) 15:18 (UTC)[回复]
@BIT0865若查無可靠來源算原創研究,可能要改寫到維基學院了。--🚊鐵路Railway 2022年2月26日 (六) 07:39 (UTC)[回复]
補充:回復上面,問員工也算原創研究--🚊鐵路Railway 2022年2月26日 (六) 10:02 (UTC)[回复]
情况很严峻啊,我和 @LuisRichmond 很早就燕房线DKZ70型的条目讨论过原创研究的事,结果他一副无所谓的样子,我也没辙。BIT0865 · Discussion · 燕房线永远的神! 2022年2月26日 (六) 11:06 (UTC)[回复]
还有就是:DKZ4RG6023-A-M06C02VFI-HD1420B我觉得不算原创研究。--BIT0865 · Discussion · 燕房线永远的神! 2022年2月26日 (六) 16:00 (UTC)[回复]
@BIT0865若真的沒辦法符合維基方針的內容就移至維基學院吧…,臺灣近期也是有很多內容移到學院。這種找不到來源的資訊,臺灣條目也有遇過,現在大部分都移到學院了。--🚊鐵路Railway 2022年2月26日 (六) 16:53 (UTC)[回复]
現在主要討論的是條目的整體架構,若整個條目或是部分內容都沒有適合的來源,就如上的方法解決吧…0.0
這邊邀請上面同樣有回覆此問題的@Ghrenghren一起討論。--🚊鐵路Railway 2022年2月26日 (六) 17:05 (UTC)[回复]
(+)支持,方针内容全面。--一片🍁枫叶展望未来 2022年2月22日 (二) 09:37 (UTC)[回复]
(+)支持,但應為內容指引級別而非方針級別,關注度同。--路西法人𖤐 2022年2月22日 (二) 10:45 (UTC)[回复]
(!)意見 可以引导爱好者将相关内容发布至维基学院。另认为应当为内容指引而不是方针。--Yinyue200留言2022年3月30日 (三) 17:19 (UTC)[回复]

🕗 公示7日,2022年3月13日 (日) 07:52 (UTC) 結束:贊成者多數,且7日無新留言,進入公示期。--🚊鐵路Railway 2022年3月6日 (日) 07:52 (UTC)[回复]

通知@owennson心平星辰一片楓葉BIT0865Bus FollowerMys_721txNryaLuciferianThomasGhrenghrenSickManWP@Qazwsaedx--🚊鐵路Railway 2022年3月6日 (日) 08:54 (UTC)[回复]
有些部落格的內容其實不錯且有公信力(例如[1]),不能當成來源有點可惜。--Poem留言2022年3月6日 (日) 15:15 (UTC)[回复]
🕗 暫停公示:公示期間有新提議,故暫停公示並進行討論。--🚊鐵路Railway 2022年3月6日 (日) 16:33 (UTC)[回复]
暫時來說比較半吊子,觀望下。--Ghren🐦🕐 2022年3月7日 (一) 05:32 (UTC)[回复]
@Ghrenghren雖然目前尚未很完全,因鐵路條目近期較混亂,在下的想法是將最大宗的共同問題先行初步整頓,預計後面還會再提出其他車輛或細項,希望在台鐵的新車交車前先有個指引約束內容,避免與EMU900EMU3000條目一樣混亂。--🚊鐵路Railway 2022年3月7日 (一) 14:47 (UTC)[回复]
部落格本身就是用戶生成內容,出了引述觀點外幾乎完全不能用。--路西法人𖤐 2022年3月8日 (二) 02:46 (UTC)[回复]

且慢。抱歉有點久沒有登入維基百科。重點,本人想針對客運/公車車輛做些修正:
  1. 關於草案上文中的使用「資訊框」部分,若草案真的實行,代表舊有的翻掀式資訊需全部打掉重練。則請問是由何君來實施全臺近百家客運業者的條目整理呢?或是維持現狀?
  2. 再者,本人找到了關於公車客運使用車種的可靠參考來源( https://www.mvdis.gov.tw/m3-emv-mk3/freeway/query ),行政院交通部公路總局的"公路客運公司列表",應該可行吧?以屏東客運為例,則該客運的使用車種依據為此( https://www.mvdis.gov.tw/m3-emv-mk3/freeway/query?method=queryCarDetailByDisplaytag#anchor ),若此方案可行,本人可協助補充於各客運上。
  3. 移動到維基學院的問題:本人發現@鐵路君最近移動了一些客運的使用車種,但本人看見的是許多紅連,覺得跟維基百科的相互連結有大落差。


最後:可否請@鐵路1延後公示時間? -- Bus Follower留言2022年3月6日 (日) 15:42 (UTC)[回复]
Bus Follower君留言連結是公開資料,且來源為政府機關,是可靠來源。Poem留言2022年3月6日 (日) 16:09 (UTC)[回复]
@Bus Follower1.翻頁式排版不易閱讀,且不符合維基基礎格式應盡量改善,可參見第三點的存廢討論紀錄。2.雖然閣下提供的參考來源為政府機關之可靠來源,但是車牌號碼實屬瑣碎資訊與愛好者內容,非愛好者並不會想要知道車號,另外在下建立主要是針對Category:巴士型號分類中的條目。3.使用車種在下查了編輯紀錄,在下僅移動豐原客運的內容,豐原客運的鏈結剛才以修整,而使用車種應該要使用表格式而非折疊式列表,且內容過於瑣碎,請參見Wikipedia:頁面存廢討論/記錄/2021/09/05#國光客運使用車種之討討論紀錄。--🚊鐵路Railway 2022年3月7日 (一) 14:37 (UTC)[回复]


了解,本人一看討論就知道大部分用戶對這塊是不怎麽友善的...不過君的意思應該是不要把使用/歷史車種寫在維基百科上,而是改寫至維基學院,對吧?如果是這樣的話,本人可以接受。也辛苦君對豐客的整理。但是關於什麼改成表格的部分,本人覺得還是先照舊吧...雖然舊的"畸形"式折疊式列表已不建議寫在維基百科上,但還是回到原點,若由君自己更新全台客運業的條目應該有困難吧
順帶一提,有看見君想要整理Category:巴士型號的分類,不過可笑的是,台灣最常見的DAEWOO BS120CN低底盤公車條目竟然被刪除了。本人發現只要有關於「公車」的條目幾乎都被提刪,不知道這種風氣在流行什麼,且刪除的原因都是什麼關注度不足的鬼,但事實上這些公車都滿街跑,怎麼會「關注度不足」?真是感到失望。當然這不是鐵路君的錯,關於其他編者的舊有固執思念,嗯。應該永遠也不會改吧,哈哈... --Bus Follower留言2022年3月9日 (三) 13:55 (UTC)[回复]
@Bus Follower在下雖未找到提刪的討論紀錄或日誌,但從鏡像網頁的相關條目所看到的排版除了排版不符合編輯手冊,另外車輛介紹完全沒有列出任何參考文獻,若被關注度刪除據在下所知另外可能就是查無相關文獻或未提供相關文獻。在下主編的是鐵路相關的條目,公車的條目很不熟悉,也很難幫忙改善0ω0--🚊鐵路Railway 2022年3月10日 (四) 16:18 (UTC)[回复]
Wikipedia:頁面存廢討論/記錄/2021/07/23#大宇BS120CN。--Ghren🐦🕛 2022年3月10日 (四) 16:28 (UTC)[回复]

鐵路1讨论 | 貢獻) :
你好,不知道為什麼,最近才看到這個討論。作為一個大規模刪減香港巴士路線條目的編輯員(詳見九龍巴士1-30號所有路線),看到這篇討論後,發現有超過50%內容可以刪減,包括行車路線、車站、用車限制(因涉及ABc綜合)、車牌,對嗎?
這樣刪減的話還有什麼可以表述?--HK5201314留言2022年3月9日 (三) 01:04 (UTC)[回复]
鐵路1讨论 | 貢獻):
順帶一提,早前可靠來源佈告版已將一個經常被引用的香港巴士愛好者網站列入防濫用保護器內,限制編輯者引用,不知你會不會提出更多網站供限制?--HK5201314留言2022年3月9日 (三) 01:17 (UTC)[回复]
在維基百科內找不到公共交通總方針,只找到交通車輛方針,請問這里會不會跟進公共交通總方針(如車站、路線、車型)?--HK5201314留言2022年3月9日 (三) 01:36 (UTC)[回复]
個人認為香港巴士的情況與海外有非常大的差別,車型是非常多元化(特別是1990年代至2010年代初),也可以證明路線歷史的變遷。如果要強硬刪除的話,個人認為有關條目失去了應有的意義。感覺中維對“瑣碎資訊與愛好者內容”的定義無限放大,並不是好事。--Wpcpey留言2022年3月9日 (三) 01:45 (UTC)[回复]
@Wpcpey路線、車站可參見NT:T指引,用車若車型不多可參見環狀線 (台北捷運)#電聯車的方式,若車型較多可參見橫須賀線#使用車輛,在路線條目中列出車型與簡介,詳細介紹則再另外的主條目進行介紹。另外,此指引主要是針對車輛,路線已有NT:T,在路線的條目中羅列停靠站還算正常,但是再車輛的條目再次出現行駛路線的車站就顯得過於重複,用車可稍微提及行駛路線與路線簡介,但不篇幅不要太長,不然就變成不是介紹車輛而是介紹路線,車牌號碼的部分,除愛好者外,一般民眾不太會去注意,且車牌號碼只要轉讓/轉手可能就又會更換一組號碼,屬不穩定的資訊,原創研究的內容應寫到維基學院,不是百科。--🚊鐵路Railway 2022年3月9日 (三) 05:44 (UTC)[回复]
對於我來說,其實不是有特別多的可靠來源記載一個路線的用車變遷。香港來說其實來來去去都是那幾本巴士書而己,實際使用可以記載車型使用的巴士路線實際上就不多,沒必要加上這條規定。列出簡介應該沒有問題的,只要不將車型過於陳述和原創研究就沒問題了。--Ghren🐦🕚 2022年3月10日 (四) 15:04 (UTC)[回复]
@Ghrenghren:但最大的問題是,用戶HK5201314仍然認為“用車變遷”是愛好者內容而刪除。加上目前的環境,會有人花時間查看巴士書再記載車型使用嗎?而那幾本巴士書是在2000年代初出版,之後又有一段空白期。而路線使用的車輛也可以反映人口,地理環境和需求情況。香港的巴士路線用車情況不能夠與其他地方比較的。--Wpcpey留言2022年3月26日 (六) 14:09 (UTC)[回复]

🕗 延長公示7日,2022年3月21日 (一) 04:12 (UTC) 結束:經討論後新提議有其他方式可替代,故延長公示。--🚊鐵路Railway 2022年3月14日 (一) 04:12 (UTC)[回复]

User:鐵路1,有個小問題,類似香港小巴這種型式的交通會否納入?又,渡輪船隻飛機直升機之類交通可否納入?--owennson聊天室獎座櫃2022年3月22日 (二) 06:16 (UTC)[回复]
@Owennson小巴也算是大客車,見[2],只要座位10人以上都算,目前指引名稱是交通車輛,若加入可能要改成交通載具的了--🚊鐵路Railway 2022年3月22日 (二) 06:32 (UTC)[回复]
User:鐵路1,個人對地鐵使用車輛內容直接放入路線條目有異議,畢竟有可能出現幾條地鐵線共用同一個車型。而且搞模板、分類時也十分不便。還是建議一個車型一個條目較好。--owennson聊天室獎座櫃2022年3月24日 (四) 00:42 (UTC)[回复]
@owennson 捂脸這根本已經不是維基的格式準則了…。直接修正就好了,另請教有哪些條目?0W0--🚊鐵路Railway 2022年3月24日 (四) 04:02 (UTC)[回复]
那就好,不是範圍內。因為我想幫上海地鐵03A02、04A02型建立條目,這種橫跨兩線的車型是不可能也不應重定向到路線條目的。--owennson聊天室獎座櫃2022年3月24日 (四) 05:08 (UTC)[回复]
(!)意見@owennson若命名空間是模板,直接移動不留重定向後將內容更正即可,若是拆分在2個頁面的則直接除內容貼到新條目內吧。--🚊鐵路Railway 2022年3月24日 (四) 05:50 (UTC)[回复]

鐵路1讨论 | 貢獻) :
救命!原來我已有半年沒有參與香港巴士愛好者內容回退事宜,發現有大量ip用戶重新加入愛好者內容,單憑我一人之力無法處理這些內容,請問可否代為申請大規模限制ip或沒有自動確認用戶編輯交通模版及號召編輯員進行刪減?否則只好放棄數以千計的愛好者內容回退。--HK5201314留言2022年3月26日 (六) 08:53 (UTC)[回复]
個人認為“用車變遷”並不是愛好者內容,明顯是巴士路線條目基本的內容吧,根本不應該刪除。--Wpcpey留言2022年3月26日 (六) 14:09 (UTC)[回复]
@Wpcpey
當然以為用車變遷不是愛好者內容
只不過現時用車型號、車牌及車廠屬於愛好者內容。
如果單刪減上述三項內容,爭議性應該不大。--HK5201314留言2022年3月27日 (日) 06:59 (UTC)[回复]
個人認為用車型號是不可缺少的內容,特別是在香港的巴士路線,80年代至2010年代中有非常多類型的巴士在同一路線服務。其他地區和國家也沒有香港這樣的情況。--Wpcpey留言2022年3月27日 (日) 13:27 (UTC)[回复]
@Wpcpey
來源?這些內容很容易判為愛好者內容,更何況每一款巴士原則上沒有指定行駛哪條路線
舉個例,上年秋季某日西貢鄉郊發生水浸,ITtalk 報導原本派出的雙層巴士全部改為單層巴士,車款五花八門,請問這些每日不同的資料寫入合適嗎?
(&)建議
我在上面講過,不改動用車變遷,畢竟涉及歷史問題
而家IG咁多巴士記錄者,問佢哋攞幾幅相證明曾經使用相關車型咪ok囉(後以gallery形式顯示),當用車變遷就算啦(曾經),用不著寫入data16,因為沒有硬性規定一定要使用這款車,而寫得入data16的是該路線指定使用該車款。--HK5201314留言2022年3月27日 (日) 14:20 (UTC)[回复]
你說不改動用車變遷,但是閣下在去年在多條巴士條目已經刪除有關內容了。更甚的是那些巴士記錄者會願意拿出照片到維基證明嗎?特別是80年代至2010年代中那段時期。本人建議用不同年代描述主要車型(差不多5-10年為一個週期)。不需要再將資料細分到每日/每月,這樣就真是愛好者內容。--Wpcpey留言2022年3月27日 (日) 14:29 (UTC)[回复]
@Wpcpey
如果有相片會比較合適,使用文字會有紙上談兵的感覺,有作故事的可能,畢竟無法確認真偽。
況且不是有一本書講述80-00年代的用車變遷,引用isbn 應該不是問題。
如果有人在HKItalk以CC By Sa 3.0徵集照片,應該很多人支持,畢竟有推廣的可能,況且最後還要標示相片是來自相關人士的page,變相可協助他們增加page的關注度。--HK5201314留言2022年3月27日 (日) 14:42 (UTC)[回复]

有關模板的刪除理由

此前討論將《刪除方針》中的第9項刪除理由由“多餘無用的模板”更改為“多餘無用,且影響其他模板命名或者百科運作的模板”,然而此更改導致了部分用戶濫建重複模板的情形(其中一個例子),因此我認為有必要重新調整可刪除模板的情形。現提案如下:

現行條文

多餘無用影響其他模板命名或百科運作的模板

提議條文

多餘無用影響其他模板命名或影響維基百科運作的模板

以上。Sanmosa A-DWY3 2022年2月21日 (一) 13:31 (UTC)[回复]

@Ericliu1912Sanmosa A-DWY3 2022年2月21日 (一) 13:31 (UTC)[回复]
行。另外百科應該可以寫全成維基百科吧。—— Eric Liu 創造は生命(留言留名學生會 2022年2月21日 (一) 15:11 (UTC)[回复]
完成Sanmosa A-DWY3 2022年2月22日 (二) 08:54 (UTC)[回复]
兼ping原案推動者@Bluedeck閣下。—— Eric Liu 創造は生命(留言留名學生會 2022年2月21日 (一) 15:18 (UTC)[回复]
倾向同意,但是要确保无链入不是模板的删除理由,提删时要提出说明证明其多余无用。另同Ericliu1912,应写成维基百科。桐生ここ[讨论] 2022年2月21日 (一) 20:02 (UTC)[回复]
會設這個限制還不是因為有人亂提刪模板,不少模板以subst方式使用,本來就不會有固定的引用數,就有人不懂模板運作原理又看到這個規則就直接以多餘無用提刪,試問這個問題怎麼解決?是否在該準則內詳細說明多餘無用的定義,例如「0引用」不等於「無用」。--Xiplus#Talk 2022年2月22日 (二) 05:55 (UTC)[回复]
@桐生ここXiplus或許我這樣理解:「0引用」的模板與「無用」的模板是兩個集,兩者有重複的地方,但不是同一個集。我覺得可以加一個註釋說“無引用的模板不一定為無用的模板”之類的,但我不太能想到一個合適的説法,不知道在這方面能不能幫一下忙。Sanmosa A-DWY3 2022年2月22日 (二) 08:53 (UTC)[回复]
如果无用未使用可能存在部分重叠意思,或者可以换个无歧义的无意义?--Kethyga留言2022年2月23日 (三) 04:22 (UTC)[回复]
“無意義”反倒是另一個意思了。現在的問題在於“無用”與“未使用”只是部分重疊,但有人誤解成完全重疊,所以只要弄一個説明解決這個問題就可以了。--Sanmosa A-DWY3 2022年2月23日 (三) 07:57 (UTC)[回复]

当初把条文改严格的原因:1、subst模版引用数可以是0,你是看不出来是否有用的。有人想当然,提删一堆subst模版,造成很多不便。2、历史曾用模版,现在不用了的,大有人在,引用数也是0,但是都在历史里,这种模版一删,等于删除很多页面的历史。这两个问题你们觉得有道理没?总之因为此原因,模版区不是一个可以让喜欢整理电脑内容的洁癖用户每日打扫的区域。至于反复滥建模版,确实令人不舒服,但是实际上的不良影响何在?Bluedeck 2022年3月4日 (五) 08:04 (UTC)[回复]

1的根本原因是部分用戶誤解「無用」與「未使用」兩個集的關係(「未使用」的模板與「無用」的模板是兩個集,兩者有重合的地方,但不是完全重合或包含與被包含),因此正解為澄清「無用」與「未使用」兩個集的關係,加一個註釋說“無引用的模板不一定為無用的模板”之類的可能有用。2無法從根源上防止其他用戶誤用或執意使用已棄用模板的行徑(而且還要考慮到現在有用戶公然包庇那些執意使用已棄用模板的行徑的情形),不利於模板的維護(至少就Infobox而言是如此,不良影響的話請看MOS:IBT)。Sanmosa Veritas Vincit 2022年3月9日 (三) 14:01 (UTC)[回复]
Re 2: 參考en:Template:Template for discussion#Display on articles顯示小型警示文字,讓「目前」的引用能被注意,在閱讀「歷史」的引用又不太過於干擾。--Xiplus#Talk 2022年3月10日 (四) 05:19 (UTC)[回复]
這只能處理誤用的問題,而不能處理(包庇)執意使用的問題,然而(包庇)執意使用的問題才是比較嚴重與發生頻率較高的情況。Sanmosa 2022年3月11日 (五) 05:08 (UTC)[回复]
寫個bot確保加入了Xiplus所提模板的模板可以自動清理調這些不合理使用的就行了吧。--Ghren🐦🕘 2022年3月13日 (日) 13:15 (UTC)[回复]
我95%不相信这个文字会起作用的,根据我的经验,脑子里存在“看不出为什么有用 == 无用”这一等式的用户并不在少数。Bluedeck 2022年3月12日 (六) 15:17 (UTC)[回复]
但不能質疑的一點是,如果要避免用戶誤解「無用」與「未使用」兩個集的關係,加註釋比起設立為濫建模板大開門路的條文更為恰當。因此,重點其實在於註釋的行文該怎樣表達才能使用戶正確理解「無用」與「未使用」兩個集的關係。Sanmosa Avec cœur 2022年3月12日 (六) 23:27 (UTC)[回复]
就算改回舊版,我也不覺得Ping4符合刪除條件,建立者不是已經很好的展現使用的狀況了嗎?--Xiplus#Talk 2022年3月13日 (日) 01:29 (UTC)[回复]
如果相關模板使用率(注意我説的不是“連入”)極低,而且機能很明顯能夠被其他模板替代,那相關模板很明顯就是無用的。假設性的使用狀況不能用於證明模板有用。Sanmosa Avec cœur 2022年3月21日 (一) 08:47 (UTC)[回复]
什麼叫機能能被取代?那為什麼不手動輸入{{Ping}}的內容呢?沒有複雜到需要使用模板啊?那是不是{{Ping}}也能刪了?--Xiplus#Talk 2022年3月21日 (一) 08:52 (UTC)[回复]
注意我上面提到的兩個條件都需要被滿足。{{ping}}很明顯不是“使用率極低”的模板,因此不能歸入“無用模板”的屬性。Sanmosa Avec cœur 2022年3月21日 (一) 08:56 (UTC)[回复]
哪個模板剛建立的時候使用率是高的?這是在論斷每個新模板都是無用模板嗎?--Xiplus#Talk 2022年3月21日 (一) 08:59 (UTC)[回复]
我重申一次:注意我上面提到的兩個條件都需要被滿足。假設我新建立了一個新主題的導航模板,裏頭的内容很明顯是任何其他模板從未覆蓋的,所以就算它一開始使用率極低,由於不滿足“機能很明顯能夠被其他模板替代”的條件,因此仍不能歸入「無用模板」的屬性。Sanmosa Avec cœur 2022年3月21日 (一) 09:04 (UTC)[回复]
所以說{{Ping}}其實應該在它被建立的時候就迅速的被提刪,然後如同Ping4一樣被刪掉嗎?Ping模板還不是經過長時間使用才會累積引用數,它在「建立的那個時間點」「使用率極低」。--Xiplus#Talk 2022年3月21日 (一) 09:07 (UTC)[回复]
你這裏的一個邏輯謬誤是假定這裏擬定的規則可以無限追溯。在這裏談論“當初”的事情是完全沒任何意義的。Sanmosa Avec cœur 2022年3月21日 (一) 09:12 (UTC)[回复]
我沒有要讓「現在的規則」追溯「以前的情況」,但是假設這個規則在2013年就存在,那麼「以前的規則」處理「以前的情況」,Ping模板就會被刪掉。--Xiplus#Talk 2022年3月21日 (一) 09:15 (UTC)[回复]
所以我才説你有邏輯謬誤啊,這種情景下是無法進行有意義的假設的。Sanmosa Avec cœur 2022年3月21日 (一) 09:19 (UTC)[回复]
那換個時間的方向,怎麼認定Ping4未來不會變得非常多人用?--Xiplus#Talk 2022年3月21日 (一) 09:25 (UTC)[回复]
沒人推廣。試問建立人自己也沒有開始使用模板,又沒有特別在客棧特地公佈他建立模板的消息,會有多少人會真的留意到該模板?如果連該模板也留意不到的話,那就別説有沒有人用了。Sanmosa Avec cœur 2022年3月21日 (一) 13:06 (UTC)[回复]
那麼Ping4建立者自己不就使用了嗎?--Xiplus#Talk 2022年3月21日 (一) 13:08 (UTC)[回复]
有嗎?--Sanmosa Avec cœur 2022年3月21日 (一) 13:10 (UTC)[回复]
我記憶有偏差,實際上是建立者主張過去有44則留言可改為Ping4模板,至於有沒有用過我不確定。--Xiplus#Talk 2022年3月21日 (一) 13:15 (UTC)[回复]
Wikipedia:頁面存廢討論/記錄/2021/11/06#Template:Ping4,這裡有人表示有連入頁面,就是有人使用了啊。--Xiplus#Talk 2022年3月24日 (四) 04:08 (UTC)[回复]
我没有使用,但是确实提删时有链入。 ——魔琴 [ 留言 贡献 ] 2022年4月3日 (日) 11:21 (UTC)[回复]
難道每一次都建新模板都要在客棧先寫一次,我建了新模板啦,大家快點來用,難道這樣好嗎。--Ghren🐦🕙 2022年3月21日 (一) 14:12 (UTC)[回复]
@Ghrenghren但至少也要自己先開始用啊,{{CSD Link}}(部分連入現在在{{CSD Reason}}那邊,因為模板原名是{{sdr}})我也是自己先使用一會兒,然後也就多了使用率啊。Sanmosa Avec cœur 2022年3月22日 (二) 03:14 (UTC)[回复]
建了只有一個月,又怎樣判斷使用率?--Ghren🐦🕛 2022年3月22日 (二) 04:49 (UTC)[回复]
但至少也要自己先開始用啊,重點在這裏啊,連自己都沒有真的在用的模板,其他人用來又有甚麽意思?Sanmosa Avec cœur 2022年3月24日 (四) 00:05 (UTC)[回复]
這個你去問魔琴去。誰知道到底是用了被人還是沒有用--Ghren🐦🕒 2022年3月24日 (四) 07:04 (UTC)[回复]
舉一個實例,{{Ping2}}功能與{{Ping}}相差沒有多少,完全可以透過改{{Ping}}來涵蓋,但現在已經1500+使用了,而Ping4與Ping2就模板功能上情況類似,但Ping4沒有等到很多人用就刪除了。--Xiplus#Talk 2022年3月21日 (一) 09:27 (UTC)[回复]
(-)反对:即使是“无用”模板,在某些情况下也可能有用。且假若修改条文后,那只需要把所有所谓“无用,滥建的模板”都标记上{{needsubst}}不就可以一劳永逸了吗?而且从根本上来说,没有任何理由去删除这些模板。从服务器端来讲没有问题,从本地来看也几乎没有任何影响。WP:没坏别修。--Yichen Ding留言|主账户2022年3月20日 (日) 15:19 (UTC)[回复]
我認為這種事情不能一概而論,只能個別論證。我不認為可以在不就每個模板個別討論的情況下統一認定所有模板“某些情況下也可能有用”,而需要就每個模板各自分別進行論證,而且論證的有效性還需要分別獲得社群認可。Sanmosa Avec cœur 2022年3月21日 (一) 08:42 (UTC)[回复]
舉證責任還不是變成在保留那方,提刪者都不用證明「多餘無用」,只需要留下這四字就能提刪了。--Xiplus#Talk 2022年3月21日 (一) 08:49 (UTC)[回复]
我不認同“變成”這個説法,畢竟舉證責任本來就只在主張保留方。Sanmosa Avec cœur 2022年3月21日 (一) 09:00 (UTC)[回复]
確實不是「變成」,而是本來就是這種有問題的情況;說的好像提刪不需要寫理由似的。--Xiplus#Talk 2022年3月21日 (一) 09:03 (UTC)[回复]
沒辦法,畢竟一個模板(頁面)就算不是無用的,只要有其他合理的刪除理由,就算一開始的刪除理由不成立,模板(頁面)還是會被刪除,而且勇于更新页面對模板是不適用的Sanmosa Avec cœur 2022年3月21日 (一) 09:07 (UTC)[回复]
那麼除了「多餘無用」4個字,「其他合理的刪除理由」在哪?--Xiplus#Talk 2022年3月21日 (一) 09:10 (UTC)[回复]
你問我,我又能問誰?難道你覺得我會參與(或參與了)此前與此後的所有存廢討論?存廢討論期間參與的用戶提出新論點是正常不過的事情,而新論點可以是刪除理由。Sanmosa Avec cœur 2022年3月21日 (一) 09:14 (UTC)[回复]
而且,容許我在這裏重申:無用模板不利於模板的維護,因此有刪除的必要。Sanmosa Avec cœur 2022年3月21日 (一) 09:10 (UTC)[回复]
那麼現有條文「多餘無用,且影響百科運作的模板」不就完全符合您的提刪理由嗎?--Xiplus#Talk 2022年3月21日 (一) 09:30 (UTC)[回复]
如果你是這樣認為的話,那這也意味著所有多餘無用的模板都必然會影響百科運作,那一開始在條文中加入“且影響百科運作”作為限定條件也是無意義的。所以,我有必要向你問清楚一件事:“不利於模板的維護”是否“影響百科運作”的其中一種情況?Sanmosa Avec cœur 2022年3月21日 (一) 13:03 (UTC)[回复]
是。但怎樣叫做「不利於模板的維護」?--Xiplus#Talk 2022年3月21日 (一) 13:05 (UTC)[回复]
不利統一格式、不利重複使用、不利管理,諸如此類,都屬於「不利於模板的維護」,但「不利於模板的維護」是必然跟隨「多餘無用」出現的。--Sanmosa Avec cœur 2022年3月21日 (一) 13:13 (UTC)[回复]
那具體來說Ping4有什麼問題?格式跟重複利用感覺沒有,不利管理嗎?--Xiplus#Talk 2022年3月21日 (一) 13:19 (UTC)[回复]
當然是不利管理了。ping4直接copy{{ping}}或{{ping2}}的原始碼,也就是説如果未來要調整相關模板,我們要分開改4個模板,難道是有利管理的情形嗎?Sanmosa Avec cœur 2022年3月22日 (二) 03:23 (UTC)[回复]
那麼按照下方所述的預制資料盒設計不就解決了嗎?--Xiplus#Talk 2022年3月22日 (二) 03:27 (UTC)[回复]
我又不知道有多少個預制資料盒(除非我特地建一個分類來檢查,但又不是所有預制資料盒都有加{{Wraps infobox}},{{Wraps infobox}}的那個分類機制甚至還是我自己改出來的),而且我動了主模板後其實有可能還是需要對預制資料盒進行調整的。Sanmosa Avec cœur 2022年3月22日 (二) 03:57 (UTC)[回复]
所以預制資料盒是個好設計還是爛設計?--Xiplus#Talk 2022年3月22日 (二) 04:37 (UTC)[回复]
要看情況。如果是已經有比較多人用的模板,改成預制資料盒還是好設計;如果是沒甚麽人用,甚至完全沒人用的模板,改成預制資料盒就是浪費時間與資源。Sanmosa Avec cœur 2022年3月24日 (四) 00:04 (UTC)[回复]
假如我將{{ping}}前面加上{{#if:{{{ping|}}}|ping}}然後將{{ping4}}變成了{{ping|ping=1|1={{1|}}|[...]}},將ping4變成預制資料盒你能接受嗎?Ghren🐦🕙 2022年3月21日 (一) 14:18 (UTC)[回复]
預制資料盒使用的條件是原本的模板已經有一定的使用率,又難以全部替換掉的情形,所以我覺得不太行。Sanmosa Avec cœur 2022年3月22日 (二) 03:17 (UTC)[回复]

重提KirkLU方案

翻了翻近期提删模板的理由,有这样一些:

很难说这些模板“影響其他模板命名或者百科運作”,因而该项条件实际上是被忽略的。我认同Bluedeck修改条文的两个出发点,但条文中却并无体现,以使阅读者留意。在此推荐KirkLU的修改方案(此处的“合并后新提案”)。--Lt2818留言2022年3月22日 (二) 03:30 (UTC)[回复]

不反對。Sanmosa Avec cœur 2022年3月22日 (二) 03:59 (UTC)[回复]
除了已無導航作用之模板是在討論之範圍內,其他都和DP9無關。Ghren🐦🕐 2022年3月22日 (二) 05:11 (UTC)[回复]
所以不能大大方方承认这些模板“多余无用”吗?不见得要寻章摘句凑理由(DP5说的是條目,DP14为百搭的兜底条款)。--Lt2818留言2022年3月22日 (二) 05:31 (UTC)[回复]
DP5對應的方針還沒定立,但是英維沒有將其只包括在條目內。只是(such as Wikipedia articles or inter-wiki objects)而己。中維連方針成立討論都沒有討論過就別談了。--Ghren🐦🕑 2022年3月22日 (二) 06:06 (UTC)[回复]
@SanmosaLt2818(-)反对:该提案对subst相关模板依然兼容性差。例如,本人创建了一个模板{{rawsign}},用来生成一个原始签名,这个模板(乃至CAT:应被替换引用的模板)理论上(除某些特殊页面外)不会有任何页面引用,而且也几乎不可能调查该模板是否“正在(被)使用”。对于这种情况,从该提案原始目的:删除“无用模板”来说,该提案是否就无能为力了?--Yining Chen留言|签名页2022年3月25日 (五) 15:37 (UTC)[回复]
@Yining Chen我把“替換引用”的内容补充进了该修改方案,您可以看看下方提案如何。--Lt2818留言2022年3月25日 (五) 16:21 (UTC)[回复]

调整了KirkLU方案的行文,提案如下:

現行條文

9. 多餘無用影響其他模板命名或者百科運作模板

提議條文

9. 多餘無用的模板

模板未被任何页面嵌入并非提删的充分理由,如被系统界面使用与应替换引用的模版可以无嵌入。此外亦应从是否有助于主要历史版本完整呈现、是否有机会再被使用等方面考量是否仍有存在价值。

删除的部分与实践脱节,见上。增加的注释将此前修改的出发点书面化,使阅读者可知其所以然。--Lt2818留言2022年3月25日 (五) 16:17 (UTC)[回复]

建議嵌入的連結換成Wikipedia:嵌入包含。--Xiplus#Talk 2022年3月26日 (六) 00:16 (UTC)[回复]
另建議以WP:RD2的格式,換行縮排小字的方式來說明,而非使用ref,比較容易看到。--Xiplus#Talk 2022年3月26日 (六) 00:21 (UTC)[回复]
已修改。--Lt2818留言2022年3月26日 (六) 02:18 (UTC)[回复]
不過如果模板有任何嵌入還可以使用此款提刪嗎?--SunAfterRain 2022年3月26日 (六) 13:45 (UTC)[回复]
可以,模板无嵌入不是提刪的必要条件,见此例。--Lt2818留言2022年3月26日 (六) 14:36 (UTC)[回复]
现在有一个新问题,如果某人创建了一个新模板(例如{{Nwarn}}或{{ping3}}),貌似可能没有其他人会使用到,但该名用户表示自己和自己的朋友将要或已经在条目与讨论中多次使用该模板(不在用户页下创建子页面,理由之一是使用时需要输入较多的无用字符)。对于这种情况,是否应算作“无用模板”?如果在这种情况下需要“灵活决定”,那是否意味着“多余无用”这一词语范围过于模糊,不适合用于方针内?--Yining Chen留言|签名页2022年3月26日 (六) 14:06 (UTC)[回复]
“灵活决定”没啥错,存废讨论就是专门做这事的。方针规定原则即可,不需要事无巨细。“多余无用”一语源自en:Wikipedia:Deletion policy#10;何者算多余无用,还是要具体问题具体分析。--Lt2818留言2022年3月26日 (六) 14:52 (UTC)[回复]
🕗 公示7日。--Lt2818留言2022年4月2日 (六) 15:10 (UTC)[回复]
请参考下方提案。--Yining Chen留言|签名页2022年4月3日 (日) 09:50 (UTC)[回复]
我認為我這方案對於「多餘無用」給了還可以的定義,應該暫停公示。--Ghren🐦🕓 2022年4月3日 (日) 09:56 (UTC)[回复]
该小节的方案只需优于现行条文即可。如果您的方案被接受的话,那么再次修改也无妨。我对您的方案的意见会稍晚些给出。--Lt2818留言2022年4月3日 (日) 10:08 (UTC)[回复]
(-)反对。“如被系统界面使用与应替换引用的模版可以无嵌入。此外亦应从是否有助于主要历史版本完整呈现”。。。。。。怎么考虑?怎么知道一个模版是不是被subst的模版?怎么知道一个模版对历史的影响?当初就是因为这些问题都无解,才改的删除标准。你不能现在就通过“请注意一下哦”的一段告示就把这个问题绕过去了。Bluedeck 2022年4月5日 (二) 06:47 (UTC)[回复]
举个例子。假如要在VFD里面以多余无用这个理由删除模版,应该怎么举证说明这个模版多余无用?根据新版多余无用的删除标准,我认为应该首先下载整个中文维基数据库,在历史版本中检索该模版的使用情况,然后再采访中文维基百科的所有用户,询问是否subst使用此模版。显然这个标准完全无法实现。因此这不是个好标准。Bluedeck 2022年4月5日 (二) 06:52 (UTC)[回复]
很简单,凭常识。判断历史使用情况需要下载数据库吗?有{{Needsubst}}的提示在,需要采访中文维基百科的所有用户吗?况且都不是硬性条件,只是让用户在讨论存废时去考量而已。我可以一样反问:怎么知道影响其他模板命名?(先到先得岂非更好)怎么知道影响百科運作?(硬说过时图表和滥建的用户框不影响百科運作,好像也挺有道理的)
如果这都不行的话,那么我主张删除小字部分,恢复原始版本,毕竟英维的条文到现在没见谁觉得不妥。您的方案不仅在当时有Shizhao等人反对,事后亦有KirkLU、Sanmosa与在下提出修改意向,且其在实际存废讨论中遭到忽略,实难称为社群共识。即使您能阻挡本次修改,今后也一定会有人认为此条不妥而再次提案。--Lt2818留言2022年4月5日 (二) 08:38 (UTC)[回复]
公示时间再延长7日吧,看看有没有其他意見。--Lt2818留言2022年4月9日 (六) 12:43 (UTC)[回复]

Ghrenghren方案

多餘無用,影響其他模板命名或者百科運作的模板


模板(a)沒有功能[1]或所提供的功能可以被其他模板或等效方式取代,(b)又或者缺乏合理預期模板有實際用途的模板[2]


[1]

功能不只包括直接調用以使用其功能,包括但不限於:

  • 模板提供了除錯功能;
  • 模板的有助於主要歷史版本完整呈現;
  • 技術上或內容上有供後人參考價值;
  • 正文因為超出模板限制而統計資料改為放置在模板內等等。
[2]
  • 需要被subst使用的模板:(a)內容可以可以直接輸入代替,(b)引致用戶一般直接輸入;
  • Navbox:(a)包含的條目缺乏實際預期可以建立的可能性,無法預期模板有導航作用,沒有功能;
  • 其他模板:(b)模板沒有一定的使用量或者無法預期有使用量,(a)而提供的功能可代替。

我的建議是這樣。Ghren🐦🕐 2022年4月2日 (六) 17:25 (UTC)[回复]

(-)反对:“Navbox”一节过于严格。--Yining Chen留言|签名页2022年4月3日 (日) 03:03 (UTC)[回复]
預期建立也就是說這些Navbox應該的連結最少應該是綠連,或者是預期可以被建立的紅連。本來「導航模板提供導覽「現有」頁面」的功能,所以理論上最好是全部建立。以實際建立的可能性來說已經可以保留這些,而且相當於其他維基來說這樣寫已經寬得多了(「這事情可能應該開個投票處理,一了百了。除了zhwiki以外,較大規模的維基百科基本都一致認同全紅連無導航/消歧義作用這點,我認為zhwiki的情況屬於常識認知問題/差異。」sanmosa語。),另外更改了一點--Ghren🐦🕑 2022年4月3日 (日) 06:16 (UTC)[回复]
  • 上下标的结构看起来过于复杂了,难以读懂。
  • 上标[2]的三项内容性质不一致。“一般模板”讲保留条件,“需要被subst使用的模板”和“Navbox”却讲删除条件。
  • 有的词意味不明。
    • 何为“除錯功能”?产生追蹤分類是否包括在内?
    • 何为“一般模板”?我猜意指“除下方列举项外的其他模板”,但叫“一般模板”就含混不清。
  • 从设计思路上讲,该方案尝试将各种情况包罗进来,乃至出现了Navbox的特定模板名称。此类行文即使现在把漏洞都补上,也预期会带来今后的高维护量。印度宪法世界最长,代价是在七十余年间修订了105次。
--Lt2818留言2022年4月3日 (日) 11:37 (UTC)[回复]
上下標的方法主要是為了分開「多餘」和「無用」這兩個看似相同但是意義上未必一致的刪除理由。我想單純提供追蹤分類的模板只怕不能計算在內,模板沒有被使用自然難以產生追蹤分類,我指的除錯功能指的是{{1}}{{2}}之類的模板。附注二按這個情況來說不一定是需要的,最好還是另外找個輔助說明頁來寫,這樣的話主條文就不需要分開a款和b款。--Ghren🐦🕘 2022年4月3日 (日) 13:01 (UTC)[回复]
英维是写“多余或其他情况无用”(redundant or otherwise useless),不过我看中文维持“多余无用”亦可,固定搭配容易理解。--Lt2818留言2022年4月3日 (日) 13:35 (UTC)[回复]
事實上就是有上方的理解分歧才是需要更改,多餘不一定是無用的,無用不一定是多餘的。多餘和無用是並列的關係,而英維的詞語是or,也就是中維的詞語表達上不清晰而引致有上方的爭議。Navbox刪除是因為多餘而是不無用,{{動員令/11}}是無用但不多餘。但是作為成語去理解就是一個字「冗」的意思,這是一個問題。--Ghren🐦🕙 2022年4月3日 (日) 14:49 (UTC)[回复]
非也,英维条文的逻辑是redundant ⊂ useless。汉语辞典里多餘有多个义项,理解作“多出來的”抑或“不必要的”皆可。我认为此处让人快速理解为上,不必作形式化描述。--Lt2818留言2022年4月3日 (日) 15:36 (UTC)[回复]
我無法從a or otherwise b 理解出a是b的子集,即使理解出來,兩次更改條文的原因都是條文不清晰,引致不能判斷什麼是多餘引致的。在此情況下,更改無不當,不然就不會有ping4的DRV。「多餘無用」不清晰是整個討論串的前提,而沒有人按DP規則來是枝節而己。--Ghren🐦🕐 2022年4月4日 (一) 05:14 (UTC)[回复]
您可以问问熟练英语的人对此句的理解。这里有一些同样结构的语句:“glossed over or otherwise handled”“All of the books had been burned or otherwise destroyed”。更改以正确理解为前提。--Lt2818留言2022年4月4日 (一) 06:16 (UTC)[回复]
這句很明顯是「書籍要麼被燒,否則就銷毀掉」。otherwise只是排除了同時不被燒和不被銷毀的可能性,或者其他的可能性而己,而常識推理來說燒和銷毀是兩個動作。Result = burn XOR destoyed。「glossed over or otherwise handled」是Result =glossed over XOR handled,然後子集"glossed over" 和"handled"是"method"的子集,"method"減去"glossed over"形成了補集 "handled",如果強行將動詞這樣理解的話。畢竟Wikipedia:是英文维基说的!,這個理解成OR就可以了,沒必要拉到是子集不子集之類的,還是歸來說回模板問題吧。--Ghren🐦🕑 2022年4月4日 (一) 06:44 (UTC)[回复]
希望其他人来评论一下吧。我觉得无能为力。--Lt2818留言2022年4月4日 (一) 06:56 (UTC)[回复]
不對,你指的是理解成「除了多餘之外,還需是無用的模板」?似乎意思想了想也無不妥。Ghren🐦🕒 2022年4月4日 (一) 07:03 (UTC)[回复]
這樣的話應該是AB,然後假如出現了redundent 但 usefull的情況再去制造出其useless的情況?--Ghren🐦🕒 2022年4月4日 (一) 07:21 (UTC)[回复]
除了询问他人外,亦可把这两句过一下翻译工具看看结果。我认为您的理解有误。--Lt2818留言2022年4月4日 (一) 08:15 (UTC)[回复]

規範人事任免投票的提問環節

原标题为:限制RFA提问数量

限制提問數量提案

为应对暂行安全投票的日程安排问题,拆分自管理人员选举制度改革。原提案者User:Ericliu1912

修訂申請成為管理人員指引內容如下:

現行條文

參與方式 管理人員提名需要經過14天(即兩周)的投票。具人事任免投票資格的使用者可以投支持票、反對票或中立票,也可以僅發表意見、向候選人提問(候選人有權決定是否作答)。投票后票數會自動更新,如果發現錯誤可至此處手動更正票數。

提議條文

參與方式 管理人員提名需要經過14天(即兩周)的投票。具人事任免投票資格的使用者可以投支持票、反對票或中立票,也可以僅發表意見、向候選人提問(候選人有權決定是否作答)。就提問而言,每人最多可提問二題,並允許就提問開展相關討論;超過額度者,其問題將被直接刪除。禁止以多重問題或「小題」形式繞過限制,這樣將被視為遊戲維基規則投票后票數會自動更新,如果發現錯誤可至此處手動更正票數。

鉴于原提案讨论中没有对提问数量限制提出明确的反对意见,故🕗 公示7日,2022年3月6日 (日) 02:02 (UTC) 結束。--Steven Sun留言2022年2月27日 (日) 02:02 (UTC)[回复]

我想說中維的RFA問題和英維的問題根本是完全不同。中維的問題一向就是以快問快答的形式,問題短,答案也短。至現今的RFA,只有極少的參與者是真的可以做到只問兩條問題。然後,即使是不作制止,候選人依然去回答問題與否。以兩題的方式根本很難讓一個投票者去了解候選人本身,畢竟問一下會否活躍,選不選介管己經是兩條問題。我是想說,就算設這些限制,只是想問問題的人只會轉到Talk Page、電郵、TG其他地方問,然後這些情況就更難掌握。對於我而言只是削足適履的方案。此外,像User:Carrotkit/猴子孵育場這些應該怎樣算。這是六個分題,還是只是一個大問題?--Ghren🐦🕐 2022年2月27日 (日) 05:33 (UTC)[回复]
  1. 候选人一般为社群较为活跃用户,在提名前社群一般就对候选人有大体的了解。不需要通过大量提问去从头了解候选人。况且问太多的低质问题,尤其是那些与维基百科无关的问题,同样也干扰投票者对候选人的认识。
  2. 本指引应只限制投票页的提问数量。在其它地方提问只要不违反其它相关指引及方针即可(以前社群也没有在其它地方提问的习惯,而且不少人的讨论页也不经常回复别人)。但不能在投票页为其他页面的提问引流,否则视为绕过限制。--Steven Sun留言2022年2月27日 (日) 08:13 (UTC)[回复]
    實際上當然是較為活躍的才可以被社群支持,但是提名本身是深入了解主張的行為。很多候選人沒有很具體的用戶論述,引致候選人雖然在某一方(比如專心在條目的用戶)很出色,但是對站務的主張卻可能不太具體的,只靠兩條發問實在難而得知具體立場。引流視作繞過規定基本上就只能(-)反对到底了。我想說低質問題就不應該回答。--Ghren🐦🕓 2022年2月27日 (日) 08:23 (UTC)[回复]
那得問多少題?幾百題是太過分了,你「問清楚」候選人的時候他也差不多要退選。引流這種「解壓縮」手段也是不怎麼可取,表面上一兩題,事實上得造成候選人數倍的負擔。—— Eric Liu 創造は生命(留言留名學生會 2022年2月27日 (日) 15:52 (UTC)[回复]
(...) 吐槽你至少也丟個幾天再公示吧 囧rz……--SunAfterRain 2022年2月28日 (一) 10:03 (UTC)[回复]
(-)反对,就之前管理員選舉的情況來看很多人提的問題數量都遠超兩題,此提案顯然不當。--🎋🎍 2022年3月1日 (二) 03:08 (UTC)[回复]
你这什么逻辑啊?因为之前很多人提的问题数量远超两题(我承认我也超过),所以现在提出限制每个人只能问最多两个问题。你的反对理据恰恰是这个提案要针对的问题;你自己说说,你这个反驳有效吗?--MilkyDefer 2022年3月1日 (二) 14:26 (UTC)[回复]
以人為單位其實換湯不換藥,你用盡「配額」,還可以找人替你追問啊,只要不被識穿就行了。我懶得翻查原來的討論紀錄了,但去年我想過一個方案:限制問題的總數(當時設想是14條左右),設立小組/專員審查問題,然後從獲批的問題抽籤;也許還可以考慮禁止必答和選答的選項(三條必答題出外)。這樣做對候選人負擔說不定會比公示方案小,但問題是誰來審查。--春卷柯南-發前人所未知 ( ) 2022年3月1日 (二) 09:56 (UTC)[回复]
供参考:Stewards organise the elections themselves... Therefore, stewards create an election committee for every election consisting of volunteers for the following tasks...,其中包括了划去不合要求的问题。 Stang 2022年3月1日 (二) 13:47 (UTC)[回复]
🕗 暫停公示。--Steven Sun留言2022年3月1日 (二) 11:27 (UTC)[回复]
我覺得比較可行的做法是讓社群意識到候選人拒絕回答不重要或有偏謬的問題的權利是絕對的(我不説候選人拒絕回答所有問題的權利是絕對的的原因是如果相關問題屬於合理憂慮的話,我認為任何人都會想問,而且候選人的回答有助釋疑)。Sanmosa A-DWY3 2022年3月3日 (四) 05:51 (UTC) +2 [回复]
  • 被選人本來就有不回答問題的權利。問題是,怎樣避免投票者因而投下反對票。--Temp3600留言2022年3月17日 (四) 12:25 (UTC)[回复]
    根本不可能避免,尤其是假如改採安全投票形式的話,就更難以用投票理由判斷投票有效程度。(加上籌備投票程序之複雜,我已經不怎麼支持管理人員選舉採用安全投票了)—— Eric Liu 創造は生命(留言留名學生會 2022年3月17日 (四) 12:52 (UTC)[回复]
    倒不是不可能避免,但避免的方式可能會很極端:如果規定候選人只需要作答三個基本問題,並禁止任何人進行任何其他的非程序性提問,那投票人不可能因為候選人拒絕回答三個基本問題以外的問題而投反對票,因為他一開始的非程序性提問已經違反規則了。Sanmosa Avec cœur 2022年3月17日 (四) 13:52 (UTC)[回复]

規範問答環節提案

既然都+2了,我就提個反建議好了:

現行條文

參與方式 管理人員提名需要經過14天(即兩周)的投票。具人事任免投票資格的使用者可以投支持票、反對票或中立票,也可以僅發表意見、向候選人提問(候選人有權決定是否作答)。投票后票數會自動更新,如果發現錯誤可至此處手動更正票數。

  • 誰可以投票:為了確保使用者對於維基社群的運作有一定了解,僅限於符合人事任免投票資格者才能參與投票。投票者請先閱讀申請成為管理員的討論中應避免的理由
  • 誰不可以投票:未登录或未註冊使用者,以及不符合人事任免投票資格的註冊使用者不可以投票,非常新的使用者如果被懷疑是欺詐,如傀儡,則有可能會被視為無效票。
  • 加入你的投票:点击相關使用者的“在此投票”,並在相應的標題下簽上你的名字,以表明你是支持反對还是中立。與相應的標題相互矛盾的投票有可能被視為無效票。
  • 可以投中立票:中立票將不計算在有效票數中,但當投票結果處於通過標準的臨界時(如支持25票,反对6票),行政員會在評估結果時考慮中立票。
  • 為你的投票做出解釋:最好給出一個簡短的原因,尤其在投反對票時。這樣候選人及他人可以理解你的想法並給予答覆。
  • 注意尊重所有人:有時對話雙方可能愈來愈激動,甚至爭吵起來。請記住,所有人都是有感覺、情緒和自尊的。
  • 討論:詳細的討論請在意見區進行。任何人都可以討論或發表意見,包括匿名使用者。
提議條文

參與方式 管理人員提名需要經過14天(即兩周)的投票。具人事任免投票資格的使用者可以投支持票、反對票或中立票,也可以僅發表意見、向候選人提問。投票后票數會自動更新,如果發現錯誤可至此處手動更正票數。

  • 誰可以投票:為了確保使用者對於維基社群的運作有一定了解,僅限於符合人事任免投票資格者才能參與投票。投票者請先閱讀申請成為管理員的討論中應避免的理由
  • 誰不可以投票:未登录或未註冊使用者,以及不符合人事任免投票資格的註冊使用者不可以投票,非常新的使用者如果被懷疑是欺詐,如傀儡,則有可能會被視為無效票。
  • 加入你的投票:点击相關使用者的“在此投票”,並在相應的標題下簽上你的名字,以表明你是支持反對还是中立。與相應的標題相互矛盾的投票有可能被視為無效票。
  • 可以投中立票:中立票將不計算在有效票數中,但當投票結果處於通過標準的臨界時(如支持25票,反对6票),行政員會在評估結果時考慮中立票。
  • 為你的投票做出解釋:最好給出一個簡短的原因,尤其在投反對票時。這樣候選人及他人可以理解你的想法並給予答覆。
  • 注意尊重所有人:有時對話雙方可能愈來愈激動,甚至爭吵起來。請記住,所有人都是有感覺、情緒和自尊的。
  • 討論:詳細的討論請在意見區進行。任何人都可以討論或發表意見,包括匿名使用者。
  • 提問:任何人都可以向候選人提問,包括匿名使用者。請確保相關問題於維基百科或候選人在維基百科的活動而言屬重要,而且並不存在任何不當預設的謬誤,否則相關問題會造成候選人的困擾。候選人有權拒絕作答三個基本問題以外的一切問題,偏執要求候選人作答與維基百科或候選人在維基百科的活動無關或存在不當預設的謬誤的問題可被視為扰乱

以上。@Ericliu1912Jonathan5566ghrenghrenSteven SunSanmosa Veritas Vincit 2022年3月9日 (三) 14:15 (UTC)[回复]

支持概念。提出以下較細化的提問規則:
提議條文

參與方式 ... 向候選人提問 在管理員選舉中,候選人回答提問有助投票人作出是否支持此候選人成為管理員的決定。候選人自薦或接受提名時,需要回答三條基本問題(請見#流程一節)。除此之外,任何人都可以向候選人提出問題。為確保問題素質,防止程序被擾亂,問題應先在討論頁提出,若十二小時內未獲合理反對並獲得另一名具有投票權的用戶支持提出問題後,則可轉發至投票頁面的提問區。每一名具有投票權的用戶僅能支持或反對提出一條問題。提出的問題應當保持語調中立,不應明示或暗示投票立場,並應與維基百科或候選人於維基百科的活動相關,且不存在不當預設的謬誤,以確保問答環節能作為一個具建設性的對話環境。候選人有權拒絕作答三個基本問題以外的一切提問,但建議(不強制要求)說明拒絕作答及原因。在候選人回應後追加延伸問題是可接受的行為,但追加的問題必須與原先問題及候選人的回答有關;候選人同樣有權拒絕回應追加的問題。就要求候選人回應問題進行施壓,包括但不限於以選票威脅回應[a]和在候選人明確表明拒絕作答時仍反覆要求作答[b]等行為均可被視作擾亂程序的行為。

補充說明

  1. ^ 「不回應我就投反對」等類似發言屬於明確地以選票作出威脅要求候選人回應,此等行為是不被容許的。另,仍不建議作出「候選人的回答會影響我的投票決定」等雖禮貌但對問題無作用且稍有施壓意味的發言,這些發言對於問答沒有任何作用,是不需要明示的。
  2. ^ 您可以作出一次簡單、禮貌地回應請求(例:希望候選人能回答有關問題)。然而,尤其在候選人已經表明不想回應的時候,無論您的發言多麼禮貌,不斷、重複地作出有關要求也可能會有施壓的意味,請避免反覆要求回應問題。
@Sanmosa看看這樣會不會對各方都更加友善?--路西法人𖤐 2022年3月10日 (四) 03:46 (UTC)[回复]
@LuciferianThomas我還是如之前説的一樣:我不説候選人拒絕回答所有問題的權利是絕對的的原因是如果相關問題屬於合理憂慮的話,我認為任何人都會想問,而且候選人的回答有助釋疑。如果社群合理地認為某問題於維基百科或候選人在維基百科的活動而言非常重要,而且將會影響維基百科日後的運作情況,我認為任何一個或多個社群成員要求他回答是合理的,這種情況應當排除於“偏執要求作答”的情形外。我不反對禁止“威脅作出回答”,但我還是想就“威脅作出回答”的定義請求澄清:假如我提問時表示“候選人的回答會影響我的投票決定”(對,這就是原話)的話,這算是“威脅作出回答”嗎(我自己覺得這個措辭應該算是委婉)?Sanmosa Veritas Vincit 2022年3月10日 (四) 07:57 (UTC)[回复]
「候選人的回答會影響我的投票決定」不算威脅,確實符合中立語調也起碼算是禮貌,不過仍稍有施壓意味(我本來好像不是想寫威脅而是施壓,不過我當時想不起這個詞 囧rz……)。個人不建議說出來,因為這一句是沒有意義的,也不是給候選人的提問。
讓RFA不要成為一個toxic的環境是為此修訂的重點。關於社群要求作答的部分,如果候選人拒絕回答就沒有不斷要求作答的必要了,反正也不見得會改變到候選人的主意。其實我的寫法反而是想強調RFA提問的禮儀,而不是限制這個限制那個。禮貌地在討論中提到「希望能回答有關問題」的問題不大,但就算是多禮貌的說法,重複就會造成施壓,這才是我這個提議條文重心要避免的情況。候選人拒絕回答某些問題或在拒絕回答時是否提出合理理由應足以影響投票人的意見,施壓是完全不必要的行為。--路西法人𖤐 2022年3月10日 (四) 09:53 (UTC)[回复]
這樣說好像也是。而且,就算沒有施壓的意味,「候選人的回答會影響我的投票決定」這句話其實也形同廢話,因為就算提問人不説,候選人的回答本來就是大家的投票決定的合理影響因素之一(除非投票人鐵了心要支持或反對),因此我同意你修改後的版本。--Sanmosa 2022年3月10日 (四) 14:07 (UTC)[回复]
微調了字眼。--路西法人𖤐 2022年3月10日 (四) 13:27 (UTC)[回复]
@LuciferianThomasSanmosa
  1. 不建议给 支持/反对 限额。不可行。建议删去此条,转发门槛的1支持改为2支持,其余不变。
  2. 追加延伸(有这样说的吗?)问题是否需要再经过遴选?
  3. 提问的截止时间应提早一天。
  4. 个人认为新开独立页面作为提问(遴选)区可能更好。
  5. 不建议用tooltip。
  6. 为确保问题素质防止程序被扰乱。【翻译腔】
  7. 所有问题应先在讨论页提出。【无用且重复】
  8. 但建议可以不强制要求)说明拒绝作答及原因【累赘】
 ——魔琴 [ 留言 贡献 ] 2022年3月10日 (四) 16:27 (UTC)[回复]
感謝魔琴君的意見。
  1. 對支持、反對限額的作用是防止某些維基人因為不喜歡候選人而大量同意對候選人提出質疑的問題,幾個支持都沒分別,有一件事情叫組團。有限制之後組團來提出質疑性問題拉低投票人的很容易發現,因為得玩互相支持問題的套路。
  2. 我有想過這個問題,但跟上面一樣,防止灌問題。某程度上是跟限制問題數量相似,不過確實可以提出無限問題,只不過大家看到你這樣水問題有多少人會都給你全灌下去而已。
  3. 這個嘛……看上面投票時間討論成怎樣先吧。
  4. 不評論,不是不行,但好像又不太必要。
  5. 純粹是提案給你們參考字眼用,寫進指引不會包含。
後面三個您可以直接修訂,小問題(--路西法人𖤐 2022年3月10日 (四) 16:38 (UTC)[回复]
  1. 但是,这个提问是流动的。也就是说,第一天,我不知道我第13天会不会看到一个我需要去支持或反对的问题。而且如果大量灌问题,似乎也无法有效反对(当然也没人支持就是)。针对组团的事情,反对票可以解决……吧?
  1. 因为提问提出后不能直接被回答,提前一天截止可以防止提问废掉(而且上面讨论的好像只是临时)
  1. 已修改。
 ——魔琴 [ 留言 贡献 ] 2022年3月10日 (四) 23:05 (UTC)[回复]
(回覆見下,忘了ping)--路西法人𖤐 2022年3月11日 (五) 12:03 (UTC)[回复]
不知所云。假如每個有權者只能支持一條問題的話,事實上是將上邊的兩條問題收至一條,然後還再加上「十二小時」的規定約束之,四捨五入就是不要問問題。制度複雜,為候選人和投票者增加不必要的負擔。--Ghren🐦🕚 2022年3月11日 (五) 03:56 (UTC)[回复]
您的理解似乎誤會了這裡的意思。每個人仍然可以提出無限條問題,不過需要有其他用戶也覺得這題值得回答才送去問答區,不提問的當然也可以支持問題,我相信算下來會協助篩選題目的用戶數量應該比提問者數量多。A用戶可以提出五條問題,全部都是非常具有建設性的問題,態度也非常良好,那麼有另外五個個別的用戶來支持提出這些問題絕對不是難事。相反,如果B用戶提出五條沒建設性或者重複的問題,自然一條都不值得被轉過去。總而言之,這不是像上面的提案那樣按量去限制個別用戶的提問數量,而是按質去篩選題目(支持和反對題目可以看到題目是否真的值得提出)。以和平奮鬥救地球君的上次RFA有32個題目分段,且大部分發問者均提出多條問題,問題數多達百題,即使假設所有題目都是具有建設性的,不論在7天也好14天也好的提問期都明顯讓候選人不太可能招架。在這個新框架下,提問數量應比較可能控制在20至30題左右(7天提問期的話就應該15到20題左右),同一人當然仍然可以提出數道題目,但是不是每一題都具備對RFA的同等重要性,其他用戶就可以選擇說覺得哪些題目更具有重要性並支持提出有關問題,那麼就能讓最重要的議題能獲優先提問,次重要的就未必需要提出。關於魔琴的問題,我甚至覺得可以改成五天收集問題,兩天給所有延伸確認用戶篩選問題。我不覺得所有參與投票的都會跑去支持題目,這樣算下來應該能平衡流動性的問題。--路西法人𖤐 2022年3月11日 (五) 11:06 (UTC)[回复]
另一個可行方案是如上面所說,有五天收集問題(同樣容許一人多題),兩天進行問題篩選,然後僅轉發有限量的題目。甚至說,收集題目也可以匿名化,那樣就不會被「這個那個用戶提出的哦,支持/反對好了」影響。包括提問者和沒有提問的人均可兩票支持兩票反對,然後按照提問的支持率去篩選題目。這樣也可以確保題目數量對候選人而言比較可控的情況下回答具有重要性的題目。--路西法人𖤐 2022年3月11日 (五) 11:13 (UTC)[回复]
我沒有誤會這裏的意思。首先,本來每個用戶在方案一本來是可以是提出兩條問題的。但是,在新方案之下,實際上每個用戶被規定在一個問題上,只是用戶可以自由分配給誰問問題,實效來說就是一題。也就是說,實際上的問題數只會大概和投票人數之下,因為確實是有些用戶是不參與答辯的,不愛關注提問區,只是看一回就投了,然後假如是收集問題制,希望問問題的人又要以多餘的時間關注在提問之上,不然又會錯過了提問期;又或者要花時間在支持問題上,兩天支持一條問題,你實在是看得起整個社群的活動能力,中維的社群活躍度其實高度集中在百餘個用戶上,留意到與否也是一個問題。問題就是在於,在縮小題目數至一個極端的時候,實際上影響和候選人之間的交流。而且,你首先要將問題放在討論頁,然後要人支持,還需要人去確認支持的用戶是否有權,然後確定只是有一次,再放至主頁面,只是為了讓候選人回答。對於我來說就是為了換一個燈炮,然後出動了整村人,增加整倍的時間,只是為了候選人不敢果斷拒絕問題而擔心。整個方案充滿對社群的不信任。ADMIN的工作是自願的,候選人本來就沒有責任去回答所有的問題,自由權本來就應該在候選人上,而不是在社群之上。
我覺得可以探討的是沒投票權用戶提問的優次,可以像萌娘一樣明確要他們的提問是較為次要的,又或者禁止IP提問之類的。差不多IP提問都是各種傀儡,問題價值差不多就是零。--Ghren🐦🕗 2022年3月11日 (五) 12:38 (UTC)[回复]
萌娘百科那樣行得通是因為只有少數人有投票資格。在本站符合人事任免資格者眾。—— Eric Liu 創造は生命(留言留名學生會 2022年3月18日 (五) 19:11 (UTC)[回复]
即使如此,每一屆都有IP和無投權者問問題,而這些人的問題質量明顯低下。--Ghren🐦🕘 2022年3月24日 (四) 13:07 (UTC)[回复]
確實。—— Eric Liu 創造は生命(留言留名學生會 2022年4月2日 (六) 09:02 (UTC)[回复]
匿名化太難了,難不成每次都要用安全投票之類的問?--SunAfterRain 2022年3月13日 (日) 09:46 (UTC)[回复]
(沒有說必要)--路西法人𖤐 2022年3月24日 (四) 12:50 (UTC)[回复]
「所有問題均應先在討論頁提出」何也?—— Eric Liu 創造は生命(留言留名學生會 2022年3月10日 (四) 17:59 (UTC)[回复]
我猜可能是指RFA页面对应的讨论页?--Steven Sun留言2022年3月11日 (五) 02:42 (UTC)[回复]
是。--路西法人𖤐 2022年3月11日 (五) 10:24 (UTC)[回复]
我的意思是,為什麼要這樣進行?—— Eric Liu 創造は生命(留言留名學生會 2022年3月11日 (五) 16:59 (UTC)[回复]
如同Temp3600下面所言,如果維基人能夠自律,當然不用……需要的原因還是因為防止灌題而已。--路西法人𖤐 2022年3月24日 (四) 12:48 (UTC)[回复]
  • 支持上述的軟性規範。說到底,維基人如果能自律,就能減少這類難以設立有效規範的情況。另外,再次建議設立問題庫。--Temp3600留言2022年3月17日 (四) 14:42 (UTC)[回复]
  • 支持概念版。细化版或可作为指引,作方针需要评估试行再说,并且“明确要求”难以避免很多问题。“仅能支持或反对提出一条问题。”需要改掉,非常像仅有一笔投票权。--YFdyh000留言2022年4月6日 (三) 16:57 (UTC)[回复]
  • 能否由行政员和管理员作为提问主持人根据提问参与度选出10个以内相关度高的问题,同时根据提问数量也可再加选出5个以内呼声高的问题作为补充提问。不限制提问数量,不限制每个人的问题的入选数量。-- WPTO 2022年4月7日 (四) 01:19 (UTC)[回复]

本討論章節會維持開放,暫時不按最後意見發表時間存檔。欲讓機器人存檔,請移除本模板。留言請置於本模板上方。

设立站务维基

在下提议设立本站的站务用维基。前期讨论存档在此,概述如下:去年LTA模仿犯泛滥,困扰站务,故在下重提设立LTA命名空间。后由于此提议不可行,社群转而讨论设立LTA维基的可行性,部分建议认为新维基用途不宜局限于LTA,并提出站务维基的构想。另外,设立站务维基也有配合IP masking等方面的考虑。

目前站务维基设立大致需要讨论两方面内容:

  1. 是否应设立,或只作为LTA维基
  2. access的门槛和申请方式(CA志愿者认为不能SUL)

以上。 ——魔琴 [ 留言 贡献 ] 2022年3月4日 (五) 16:12 (UTC)[回复]

仍然認為沒有設立之必要。—— Eric Liu 創造は生命(留言留名學生會 2022年3月4日 (五) 18:29 (UTC)[回复]
根据雪球法则 ,(-)強烈反对--Pavlov2留言2022年3月5日 (六) 18:57 (UTC)[回复]
我上次來都沒留意到,雪球法則不是隨便拋出來就用來反對提案什麼的,你好歹也解釋一下吧。--路西法人𖤐 2022年3月15日 (二) 13:33 (UTC)[回复]
改票( ✓ )同意。sysop们辛苦了----仁爱亲诚Pavlov2 2022年3月17日 (四) 15:50 (UTC)[回复]
反破壞工具的建立刻不容緩。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️2022年3月29日 (二) 13:21 (UTC)[回复]
雞肋。不會反對,但是不值得投入心力。--Ghren🐦🕐 2022年3月7日 (一) 05:28 (UTC)[回复]
不反對,雖然上次是說有條件支持,但還是覺得必要性不大。要兩個維基之間切換以進行同一項目的維護工作偏麻煩。--路西法人𖤐 2022年3月8日 (二) 02:49 (UTC)[回复]
  • 疊床架屋很好玩?-某人 2022年3月12日 (六) 03:58 (UTC)[回复]
    • @AINHPavlov2您可能有所誤會。這是去年年初的命名空間案,當時討論的MOS、LTA和維基專題,維基專題順利成為名字空間LTA命名空间雖然公示通過,但LTA命名空间因技術限制(僅特定權限的用戶能訪問特定名字空間的擴展不會在任何維基站點部屬這跟當時WP:修訂巡查狀況很像,本地公示通過,但基金會技術人員說「此擴展不會在任何維基站點部屬」。)而無法實施,被phab人員拒絕部屬,phab:T299546而基金會技術人員則建議創立新維基來達成「僅特定權限的用戶能訪問」的等價效果(先例 https://sysop-it.wikipedia.org phab:T256545)。phab:T299590。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️2022年3月12日 (六) 04:18 (UTC)[回复]
Correction:LTA命名空间没过公示,但只是技术原因,本地在公示期间未提出其它反对意见。上次讨论站务维基的时候一片绿色,我重提一下又反应平平 囧rz…… ——魔琴 [ 留言 贡献 ] 2022年3月12日 (六) 11:58 (UTC)[回复]
不反对。--在下荷花请多指教欢迎签到2022年3月21日 (一) 12:50 (UTC)[回复]

鉴于无反对意见,且即使计入讨论FlagRev的留言也已两次触及WP:7DAYS,故🕗 公示设立站务维基,为期7日,2022年4月9日 (六) 15:35 (UTC) 結束。 ——魔琴 [ 留言 贡献 ] 2022年4月2日 (六) 15:35 (UTC)[回复]

是不是應該討論了一些基本規則才公示較妥。--Ghren🐦🕛 2022年4月2日 (六) 16:33 (UTC)[回复]
(-)反对:我不認為現階段值得建立獨立於本站的系統。—— Eric Liu 創造は生命(留言留名學生會 2022年4月3日 (日) 05:38 (UTC)[回复]
你就當作這只是一個新命名空間,只是這個「命名空間」放得比較「遠」。且本案原先就是命名空間案,但是被基金會技術人員說技術限制提出的折衷方案。—- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️2022年4月3日 (日) 06:14 (UTC)[回复]
且不認為是「獨立」只是為了做檢視權限管控。且這也是本意—- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️2022年4月3日 (日) 06:15 (UTC)[回复]
兩個站就是兩個站。分開的必要性為何?—— Eric Liu 創造は生命(留言留名學生會 2022年4月3日 (日) 14:57 (UTC)[回复]
欲设置限制检视权限只能分设一站。 ——魔琴 [ 留言 贡献 ] 2022年4月5日 (二) 01:03 (UTC)[回复]
目前(-)傾向反對,架构和细节缺乏讨论,过于模糊。历史数据迁移会是麻烦事。打算如何避免门槛过高或过低、复制泄露内容?phabricator中有人提到基于Toolforge的工具,是否有可能。--YFdyh000留言2022年4月3日 (日) 09:26 (UTC)[回复]
  • 鑑於目前出現明確反對理由,公示暫停直到共識重新產生。--拒食木瓜 2022年4月3日 (日) 13:00 (UTC)[回复]
    应该先讨论(1)放在哪里,可以是WMF production、Cloud VPS或者Toolforge;(2)用途:只用于放LTA还是其他和站务相关;(3)名称:zh-lta/zh-internal/zh-maintanence等等。明确之前不应该立即公示。--GZWDer留言2022年4月4日 (一) 18:16 (UTC)[回复]
    更关键的是,如何保障数据安全(完整性和防泄露),进入门槛是明确还是模糊审核,不然只是将数据转入看似安全的黑箱。--YFdyh000留言2022年4月4日 (一) 18:42 (UTC)[回复]
    Toolforge上放不了MediaWiki实例吧。Cloud VPS的效果可以参考一下这个站点,但存在一个比较麻烦的问题是依赖于少数社群成员的维护(换句话说如果维护者不活跃了就很麻烦)。如果是如phab提案那样放到s5的话,那整体流程可以参考意大利语那个现成的例子。另外还需要确认的是准入门槛的问题。 Stang 2022年4月5日 (二) 00:43 (UTC)[回复]

提议引入CSD:U5

在英文维基中,CSD:U5是常用于删除与维基百科无关的用户页的快速删除的理据。在中文维基中似乎缺乏相关的用户页面快速删除准则,致使部分明显违例的用户页面需要使用存废讨论,乃至多次存废讨论。

U5. Blatant misuse of Wikipedia as a web host

Pages in userspace consisting of writings, information, discussions, or activities not closely related to Wikipedia's goals, where the owner has made few or no edits outside of user pages, except for plausible drafts and pages adhering to Wikipedia:User pages#What may I have in my user pages?. It applies regardless of the age of the page in question.

Before placing this template or deleting a page under this criterion:

Read Wikipedia:User pages#Handling inappropriate content and Wikipedia:User pages#Deletion of user pages.

Consider blanking pages with a significant history unrelated to the content that is being deleted.

For draft articles that are on a user's main page and which do not otherwise qualify for speedy deletion, consider moving it to a sub-page.

机械翻译大概是这样的

U5. 公然滥用维基百科作为网络空间

用户空间中的页面由与维基百科目标不密切相关的文字、信息、讨论或活动组成,所有者在用户页面之外几乎没有进行编辑,除了看似合理的草稿和遵循Wikipedia:用戶頁

无论相关页面的持续存在的日期如何,它都适用。

在放置此模板或根据此标准删除页面之前: 阅读wp:UPNOTWP:D-UP

考虑将具有与正在删除的内容无关的重要历史记录的页面清空。

对于用户主页上的草稿文章并且不符合快速删除的条件,请考虑将其移至子页面。


引入这一CSD可能能加快部分涉及用户页面的删除争议问题的解决速度?

--Pavlov2留言2022年3月5日 (六) 19:03 (UTC)[回复]

支持引入。--Jhstriver留言2022年3月9日 (三) 02:43 (UTC)[回复]
有「刪除爭議問題」不就應該在存廢討論中討論嗎?此提案很矛盾喔。--Xiplus#Talk 2022年3月9日 (三) 07:16 (UTC)[回复]
如果這話是在2021年OA前說的話,我會同意,但現在這種情況我覺得「刪除爭議問題」未必存在。Sanmosa Veritas Vincit 2022年3月9日 (三) 13:48 (UTC)[回复]
实质上,所谓的“删除争议问题”并非争议,
本身就严重违反用户页方针的用户页面也能多次在本地得到保留,甚至AFD不通过,是某种变相的拉票或管理战的结果。--Pavlov2留言2022年3月10日 (四) 07:01 (UTC)[回复]
社群在用户(子)页面是否符合(快速)删除要求这一点上无明确共识。--东风留言2022年3月9日 (三) 08:32 (UTC)[回复]
對於被濫用的用戶空間頁面是否符合快速刪除要求並無(明確)共識的原因是從未就此進行針對性的討論。對於被濫用的用戶空間頁面是否符合刪除要求並非並無共識,至少OA後的多個AFD都已經明確支持刪除被濫用的用戶空間頁面。Sanmosa Veritas Vincit 2022年3月9日 (三) 13:50 (UTC)[回复]
部分WMC成员或非WMC成员,持续地用户页滥用,由于中文百科缺乏这方面的方针,因而多次以无共识逃避删除。这正是提出引用此类CSD的直接原因。
感谢阁下的指点--Pavlov2留言2022年3月10日 (四) 06:59 (UTC)[回复]
不明所己,這樣的話你修錯位置了。--Ghren🐦🕖 2022年3月10日 (四) 11:31 (UTC)[回复]
注意U5的適用限制:「所有者幾乎衹編輯用戶頁面,不計看似合理的草稿和遵循WP:UP的頁面。」這CSD不是用來快速處理內容有爭議的用戶頁(例如判斷是否違反WP:UPNOT之12,經存廢討論較為適宜),而是用來處理例如已因WP:NOTHEREWP:GAME(用戶頁刷編輯數)為由封禁的用戶的用戶頁,較無爭議。引入U5亦無妨,但目前此類情況似乎並未泛濫到需要專屬CSD處理(?)。引入CSD不能加快處理任何爭議,因為CSD向來衹能用於毫無爭議之處。--留言2022年3月10日 (四) 12:04 (UTC)[回复]
【1】本地化時可以調整相關適用限制。【2】有關刪除被濫用的用戶空間頁面是否有爭議這點,請參見我與Pavlov2對Xiplus於2022年3月9日 (三) 07:16 (UTC)的留言的回應。Sanmosa Veritas Vincit 2022年3月10日 (四) 13:35 (UTC)[回复]
完全認同【1】,但不贊成放寬。關於【2】,刪除被濫用的用戶空間頁面沒有爭議,但是頁面是否屬於濫用可能存在爭議;也認同對於一些頁面,「刪除爭議問題」未必存在,此時存廢討論將輕易通過,例如「OA後的多個AFD都已經明確支持刪除被濫用的用戶空間頁面」,但是,「刪除爭議問題」雖然未必存在,仍可能存在,每個頁面狀況不同,支持以存廢討論定奪,而不應加速,CSD衹應適用於完全沒有爭議的情況。--留言2022年3月10日 (四) 14:14 (UTC)(2022年3月10日 (四) 14:21 (UTC)追加說明)[回复]
我覺得中文維基百科的用戶在OA過後應該不至於如此是非不分,那些“爭議”其實從一開始也就是那些人瞎搞出來的,所以我能肯定OA過後那些“爭議”不存在。基本上會寫出那種用戶頁的人有很大一部分都是別有用心的。Sanmosa 2022年3月10日 (四) 14:33 (UTC)[回复]
https://zh.wikipedia.org/wiki/User:%E7%8E%8B%E6%BC%A2%E7%91%8B 这个就是一个经典的U5--Pavlov2留言2022年3月12日 (六) 05:07 (UTC)[回复]
這是G3/G12,尤其見「豐功瑋業」一節。--留言2022年3月12日 (六) 15:03 (UTC)[回复]
Wikipedia:頁面存廢討論/記錄/2022/03/22#User:Felixwuuuu这个讨论看得我恼火,英文维基一个U5就飞过去了。----仁爱亲诚Pavlov2 2022年3月22日 (二) 15:29 (UTC)[回复]
有这种行为的用户多吗?--Tranve () 2022年3月26日 (六) 08:42 (UTC)[回复]
多,而且倔。----仁爱亲诚Pavlov2 2022年3月27日 (日) 04:25 (UTC)[回复]
(!)意見:虽然这种想法的初衷是好的,但是一下子照搬英文维基的标准社群会难以快速适应,不过对于U5的标准首先应该有以下几个标准
1.把用户页当作个人博客网站
2.用户页仅有用户及相关人员的联系方式
3.大量的宣传性内容(如果满足G11则以G11开始删除)
4.将用户页用作角色扮演游戏,如果是明显的恶作剧则应该以G3快速删除--BuenosDías 2022年3月29日 (二) 09:36 (UTC)[回复]
不看好管理员执行该标准的一致性和友好性,速删难以追溯,所以还是存废讨论吧。--YFdyh000留言2022年4月4日 (一) 18:46 (UTC)[回复]
或者说这个速删只能提到AfD,有争议的话就煮,没争议的话收到(×)快速删除票再速删? ——魔琴 [ 留言 贡献 ] 2022年4月5日 (二) 01:12 (UTC)[回复]

绿链模板的用意,以及是否支持Wikidata?

根据WP:MOSIW,ilh的主要作用字面上看是标注原名。但是这也就是「字面上看」。实际上,现在绿链模板用法有多种解读:

  1. 作为外语扩展阅读,或引诱编辑创建条目:无论何种语言事物,尽可能链接英文维基(而非对应语言维基),毕竟懂英文的人最多。如果没有英文版,则链接其他语言。
  2. 作为权威认证,或方便维护跨语言链接:链接语言中立的Wikidata。但模板不支持Wikidata,所以链接任意维基百科(一般是英维)。
  3. 作为原文标注。标注外文顺便链接对应语言维基,对应语言维基无条目则红链括号。

我个人倾向第三种解读。比如某英国事物在英文维基按无关注度删除了,但存在阿拉伯语版条目;我是红链加注原文也不{{link-ar}}(tsl手机版效果很奇怪)。但有编辑认为能链尽链,会加阿拉伯语维基链接。所以对于这种绿链的使用目的,是否考虑重新讨论?另外各维基条目创建门槛不完全一致,加入绿色链接时,是否要像普通红链一样考量本地条目创建可能性(关注度等)?

此外很多项目有Wikidata数据,却没有任何维基百科条目。而Wikidata可以方便标注原文并添加基础的辨识信息。条文创建时Wikidata还没有开放,那是否考虑让ilh支持链接Wikidata?--洛普利寧 2022年3月10日 (四) 16:37 (UTC)[回复]

我覺得不能把所有模板裏的{{ilh}}都説成是3。就導航性質的模板而言,這跟條目內的{{ilh}}的目的是一樣的,因此屬於1的情形。Sanmosa Avec cœur 2022年3月25日 (五) 00:46 (UTC)[回复]
我的意思是,如果把ilh规定为3,那导航模板可能就不应放绿链(=红链+外语加注)。但现在导航模板里面放绿色链接是普遍情况,然而指引又没有明确表示绿色链接的意义不是3。而且加绿色链接也存在定义1或者定义2,以及主题是否能通过中维关注度审查的问题。现在我自己使用时都比较迷茫。--洛普利寧 2022年3月27日 (日) 08:26 (UTC)[回复]
同意導航模板不應放綠鏈,現在導航模板的綠鏈常常都綠到超出模板限制然後壞掉了 囧rz……—- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️2022年3月27日 (日) 08:35 (UTC)[回复]
主要是因為綠鏈為了配合站內的小工具跳出框框,因此每個綠鏈都有一段span 標籤,導致一多起來塞爆模板了。建議專為導航模板設計一個短一點的模板。或者修改小工具,讓他更智能地直接識別 將 紅鏈+括弧的跨wiki鏈 自動換成綠鏈,而非原始碼保留綠鏈。—- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️2022年3月27日 (日) 08:40 (UTC)[回复]
同意,此处另见VPT,我认为技术改进可行。绿链用法我赞成讨论,但建议将技术原因单独考虑。--YFdyh000留言2022年4月3日 (日) 09:29 (UTC)[回复]

提议为引用网络资源不填URL链接参数的行为设立警告或过滤器

今天巡查尹锡悦条目时发现有编辑照搬英文版和韩文版引入的网络资源,但是没有附上相应的网址。虽然相关问题已被本人修复,但本人觉得引用网络资源时一定要填网址,方便读者查找相关内容出处。在此提议设置警告或过滤器,提醒编辑者添加网址。--百战天虫留言2022年3月10日 (四) 16:49 (UTC)[回复]

編輯差異?--Xiplus#Talk 2022年3月12日 (六) 04:13 (UTC)[回复]
是说这篇条目的?--百战天虫留言2022年3月13日 (日) 07:10 (UTC)[回复]
對,最好再多提供幾個其他條目的。--Xiplus#Talk 2022年3月15日 (二) 04:57 (UTC)[回复]
编辑差异见这里,相关问题纽黑文也有。--百战天虫留言2022年3月16日 (三) 09:32 (UTC)[回复]
如果能提醒一下比较好,看了前面的尹锡悦,好像原编辑像是直接从视觉化编辑上复制的,也有可能不太熟悉使用 {{cite xxxx}}模板,也有些是直接用书目数据库提供的引用格式。如果用源代码模式复制参考文献比较好。--Kethyga留言2022年3月24日 (四) 13:38 (UTC)[回复]
看過了,不過ref標籤又不是僅能用在參考文獻,也可能正常輸入純文字的情況吧?應該無法用過濾器判斷。--Xiplus#Talk 2022年3月24日 (四) 13:43 (UTC)[回复]
如何判斷?是說在應用Cite web模板時沒有添加URL參數之類的操作嗎?—— Eric Liu 創造は生命(留言留名學生會 2022年3月23日 (三) 17:03 (UTC)[回复]
T:cite news允許不用填url參數(有些來源只有線下資料)-- Matt Zhuang表示有事按「此」留言 2022年4月3日 (日) 06:13 (UTC)[回复]
應該這樣說,Cite web一定要網址,但是Cite news不一定。--Ghren🐦🕒 2022年4月3日 (日) 07:19 (UTC)[回复]
技术上,{{cite web}},{{cite podcast}},{{cite mailing list}}三个模板,如果不填URL会报错。但目前的设定下,该条信息默认隐藏。如果社群觉得有必要的话,可以考虑取消隐藏,如不填URL直接红字报错提示编者。--Antigng留言2022年4月11日 (一) 15:59 (UTC)[回复]
podcast不一定有網址吧,因為電台節目不一定有回播。當然沒有回播的來源是不是好的來源是個問題。--Ghren🐦🕛 2022年4月11日 (一) 16:16 (UTC)[回复]
貌似按定义Podcast是有网址的,没有线上回播的其它视听节目来源可以用{{cite AV media}},后者不强制要求填写url。当然技术上,强制填写url的模板种类也是可以配置的。--Antigng留言2022年4月11日 (一) 16:41 (UTC)[回复]
也就是這裏方法實際上是錯誤的。簡單看了目前引用的一百例左右,基本上都有url,加上看似沒有問題。--Ghren🐦🕒 2022年4月11日 (一) 19:11 (UTC)[回复]

修改一級行政區道路特殊收錄限制列表

通過:
7日內無異議,通過。Sanmosa Avec cœur 2022年4月13日 (三) 02:24 (UTC)[回复]
下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。

擴大《一級行政區道路特殊收錄限制列表》的適用範圍

建議將《一級行政區道路特殊收錄限制列表》更名為《道路特殊收錄限制列表》、刪除“一覽表”表格中的欄位,並進行以下修改:

現行條文

本列表旨在列出所有在《道路關注度指引》上有特殊施行限制的國家一級行政區公路。本列表內的特殊施行限制的任何修改或調整應依照《道路關注度指引》的規定和WP:互助客棧/方針頁的討論共識進行。

提議條文

本列表旨在列出所有在《道路關注度指引》上有特殊施行限制的公路。本列表內的特殊施行限制的任何修改或調整應依照《道路關注度指引》的規定和WP:互助客棧/方針頁的討論共識進行。

Wikipedia:关注度 (地理特征)#道路亦將連帶修改:

現行條文

道路

跨國公路網(如歐洲高速公路亚洲公路网)、國家級公路網(如中华人民共和国国家高速公路网中华人民共和国国道、美國州際公路系統美國國道)、一級行政區(如省、州、大區,視乎各地而定)公路網[1],於一般而言,皆具有關注度;而二級或更低級行政區公路網、地區道路網、單一城鄉道路、街道、公路服務區交流道等的關注度可能會因所在地不同而亦有所不同,故而在具有以該路段為主題的可靠二手來源的前提下,可假定該路段具有關注度。

参考資料

  1. ^ 部分國家之一級行政區公路網公路具有特殊收錄限制,相關限制見《一級行政區道路特殊收錄限制列表》。
提議條文

道路

跨國公路網(如歐洲高速公路亚洲公路网)、國家級公路網(如中华人民共和国国家高速公路网中华人民共和国国道、美國州際公路系統美國國道)、一級行政區(如省、州、大區,視乎各地而定)公路網[1],於一般而言,皆具有關注度;而二級或更低級行政區公路網、地區道路網、單一城鄉道路、街道、公路服務區交流道等的關注度可能會因所在地不同而亦有所不同,故而在具有以該路段為主題的可靠二手來源的前提下,可假定該路段具有關注度。

参考資料

  1. ^ 部分國家公路具有特殊收錄限制,相關限制見《道路特殊收錄限制列表》。
增列英國公路至《道路特殊收錄限制列表》

建議將英國公路增列至《道路特殊收錄限制列表》如下:

國家 詳細施行限制 討論共識位置
 日本 日本既有的一級行政區公路(即:都、道、府或縣道)一律不自動視為一級行政區道路,而以下道路(無論是否既有的一級行政區公路)則取而代之視為日本的“一級行政區公路”:
  1. (特例)主要地方道
  2. 日本法律所規定的都市高速道路
 英国 英國各公路,除高速公路(Motorway)與A級公路(A road)外,一概不視為國家級或一級行政區級道路。雖然如此,已被編入跨國公路網的公路縱非高速公路或A級公路,仍可獲假定具有關注度。 (討論通過後新增的對應PermaLink連結)

以上。Sanmosa Avec cœur 2022年3月20日 (日) 05:34 (UTC)[回复]

建议同时检讨对日本一栏增加修订,主要是其“地域高规格道路”是否可以认定一级行政区道路。--Liuxinyu970226留言2022年3月26日 (六) 02:23 (UTC)[回复]
@Liuxinyu970226這個比較適宜分開討論,因為這次修訂的目的是要處理像英國這樣只有國家級公路而沒有一級行政區級公路的情形。Sanmosa Avec cœur 2022年3月29日 (二) 04:07 (UTC)[回复]
@Sanmosa最好还是一口气提出来一体化调整更好,因为如果这次只修订英国相关的,那么对于德法等其他欧洲国家的道路条目贡献者而言将会受到巨大震撼,很容易发生群体指责英国编辑者搞双标。--Liuxinyu970226留言2022年3月29日 (二) 04:29 (UTC)[回复]
@Liuxinyu970226我倒不是這樣認為。如果把所有事情都混同討論的話很容易讓討論失焦,而且《(一級行政區)道路特殊收錄限制列表》是對道路條目收錄施行較嚴格的限制的規定,像法國與德國沒有被(提議)列入列表的情形而言,兩國道路的收錄標準相對於現在的日本與之後的英國而言是相對寬鬆的,我合理地認為相關用戶不會求著我們讓他們寫的條目在之後會更容易被刪除。Sanmosa Avec cœur 2022年3月29日 (二) 12:01 (UTC)[回复]
已滿足WP:7DAYS的條件,現公示7日。Sanmosa Avec cœur 2022年4月6日 (三) 07:49 (UTC)[回复]
我能否認為這個限制表是優先於Wikipedia:關注度 (地理特徵)#道路。--Ghren🐦🕐 2022年4月7日 (四) 05:32 (UTC)[回复]
@Ghrenghren(忘了reply)是的,但也是本來如此。如此設定的原因可以查看既往討論。Sanmosa Avec cœur 2022年4月12日 (二) 08:47 (UTC)[回复]

本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。

已通过:
下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。

如题,原Wikipedia:管理員的離任/提請取消不活動管理員的權限中通知管理员方式含相应模板({{subst:Inactive admin}}),现该页面已被重定向到Wikipedia:行政員布告板Wikipedia:管理員的離任#長期沒有活動解任方针中未标注上述模板,每次通知需重新查找。现提议

現行條文

當达到上述条件時,該位管理員應經由以下方式得到通知:

  • 用戶對話頁
  • 其他通訊方式,如電郵、即時訊息、電話等
提議條文

當达到上述条件時,該位管理員應經由以下方式得到通知:

  • 用戶對話頁(可使用模板{{subst:Inactive admin}})
  • 其他通訊方式,如電郵、即時訊息、電話等
--东风留言2022年3月22日 (二) 07:36 (UTC)[回复]
說到口臭系列:「應將通知期設於第五個月,第六個月內仍然沒有操作的話除權。」相對地其他權限沒有通知,半年不活躍就直接除權,管理員特別通知先不談,還要6+1就太過了。--AT 2022年3月22日 (二) 10:56 (UTC)[回复]
其他權限除權之前也有通知吧。可能只是不強制?—— Eric Liu 創造は生命(留言留名學生會 2022年3月22日 (二) 11:56 (UTC)[回复]
那就差很多了,而且目前確實是滿六個月直接除權,也沒有通知的餘地,這跟管理員離任標準不一致。--AT 2022年3月22日 (二) 15:40 (UTC)[回复]
畢竟管理員是重要權限。當然我也認可提前通知、準時除權的方案,但我覺得也可以考慮學習英維,多通知幾次。—— Eric Liu 創造は生命(留言留名學生會 2022年3月23日 (三) 17:05 (UTC)[回复]
認可就行。另外,如果要通知幾次也不是不可以,不過相對地應該縮短不活躍的期限,例如三個月的話,就算每過一個月通知一次我認為也是沒有問題的。--AT 2022年3月24日 (四) 04:48 (UTC)[回复]
倒是不必縮短期限。前一個月通知一次,前一週再通知一次,這樣就應足矣。英維最近在討論一段長時間內要做一定編輯,或可交換將短時間不活躍期限略微拉長,納入之後改革的考量。—— Eric Liu 創造は生命(留言留名學生會 2022年3月24日 (四) 06:57 (UTC)[回复]
我倒是覺得不需要三催四請,從其他權限皆不通知的角度來看,提早一個月通知已經是非常容忍了。至於,交換不活躍期限,來點日誌操作的話可以考慮。--AT 2022年3月24日 (四) 11:11 (UTC)[回复]
兩次應該也說不上是「三催四請」w —— Eric Liu 創造は生命(留言留名學生會 2022年3月24日 (四) 23:35 (UTC)[回复]
哎,雖然之前沒有參與到這裏的討論,但我還是有些話想説的。「三催四請」的形容確實有點誇張,但我同樣覺得事前只通知一次,甚至不通知,都是合理的安排,畢竟我不相信能擔任管理員的用戶是不知道管理員不活躍6個月就會除權的規定的,而且現在還有復任機制。Sanmosa Avec cœur 2022年3月25日 (五) 00:40 (UTC)[回复]
現在有復任機制,除權還可以再申請,緊一點應該是相當合理了。--Ghren🐦🕛 2022年3月22日 (二) 16:30 (UTC)[回复]
上次RFR的讨论是不是无疾而终了。--东风留言2022年3月23日 (三) 02:48 (UTC)[回复]

公示7日。--东风留言2022年4月3日 (日) 16:21 (UTC)[回复]
不加我上面提到的在第五個月通知嗎?這點在上面討論應該是沒人反對的啊。--AT 2022年4月4日 (一) 14:31 (UTC)[回复]
不是很敢确定,毕竟我没有在讨论串列出提议条文。--东风留言2022年4月4日 (一) 14:57 (UTC)[回复]
反對AT的提議。缺乏顯著效益,沒壞別修。--章安德魯留言2022年4月4日 (一) 17:30 (UTC)[回复]
現在談的基礎是6+1+12,一個管理員要19個月不編輯這個權才能真正摘掉,有什麼問題呢。--Ghren🐦🕐 2022年4月5日 (二) 05:15 (UTC)[回复]
不建議節外生枝或包裹提案。先將此案通過為宜。—— Eric Liu 創造は生命(留言留名學生會 2022年4月5日 (二) 08:09 (UTC)[回复]
這是一個可以雪球的議案。--Ghren🐦🕓 2022年4月5日 (二) 08:46 (UTC)[回复]
當提案有顯著疑慮或反對意見時,就明顯不適合以雪球法則處理了。—— Eric Liu 創造は生命(留言留名學生會 2022年4月5日 (二) 14:56 (UTC)[回复]
很抱歉我縮排錯了,我指的是加上{{subst:Inactive admin}}的議案。「可」只是一個建議而沒有約束力,實際上在對話頁留下字句也無不妥,不好意思。--Ghren🐦🕚 2022年4月5日 (二) 15:10 (UTC)[回复]

本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。

提議引入活動協調員

編輯松是一種鼓勵參加者成為維基人的方式,在歐美等英語系國家盛行。雖然中文區這裡也有看到一些聚會,但除wp:動員令等恆常活動外,看似沒有舉辦過甚麼編輯松。小弟雖然(&)建議中文區也能多舉辦一些編輯松(線上或線下俱可),但為確保維基人在舉辦這類活動時得到適切的協助(尤以線下編輯松為甚),現提議參考英維引入活動協調員(英語:Event coordinator),大致如下(原文見):

  • 給予編者權限,以繞過單一IP地址建立新帳戶的數量限制
  • 容許編者臨時給予活動參加者「確認用戶」狀態,以繞過正常「須建立帳戶滿7天」的限制;參加者能直接創建新條目、移動草稿頁面至正式頁面等,詳見wp:AL

中文區頁面將容後建立,歡迎討論。--小文人(見山客棧2022年3月24日 (四) 07:03 (UTC)[回复]

技術上來説,就是大量帳號建立者附加可授權其他用戶「確認用戶」的權力(下稱「授權確認用戶權」)。我留意到此前舉行過的一些offline編輯松或編輯活動的主持人都會申請大量帳號建立者權限,因此我覺得可以討論的一點是能不能讓管理員視乎情況選擇性為適合的用戶授權大量帳號建立者權限時,同時授權「授權確認用戶權」。Sanmosa Avec cœur 2022年3月25日 (五) 00:52 (UTC)[回复]
先看看Wikipedia talk:大量帳號建立者#修訂Wikipedia:大量帳號建立者方針,賦予額外權限的討論內容。--Xiplus#Talk 2022年3月25日 (五) 03:48 (UTC)[回复]
但小弟硬是認為,既然是為參加者而創建帳戶,為何不獨立拆分一個活動協調員?英維頁面有這樣的一句話:
簡單而言,
  • 管理員自動賦予活動協調員權限
  • 其他用戶一律須透過指定頁面申請(參考英維做法
  • 活動協調員賦予編者noratelimit權限,但沒有MAC的其他權限
再看看英維對於MAC的定義:
MAC只在別人請求下才創建大量帳戶,不包括活動,當中亦有一些flag是活動協調員用不著的。--小文人(見山客棧2022年3月25日 (五) 08:29 (UTC)[回复]
如同您上面引用的enwiki方針,enwiki的WP:ACC程序是由accountcreator處理,而本地ACC程序是由管理員處理,所以本地並無需區分accountcreator和eventcoordinator的需求,向活動協調員授予accountcreator並無問題。--Xiplus#Talk 2022年3月25日 (五) 16:28 (UTC)[回复]
簡單來說,從方針跟技術上來說都是,enwiki eventcoordinator = zhwiki accountcreator,而enwiki accountcreator於zhwiki不存在對應權限。--Xiplus#Talk 2022年3月25日 (五) 16:37 (UTC)[回复]
除动员令外的编辑松参与度如何?--东风留言2022年3月25日 (五) 15:51 (UTC)[回复]
5月會舉辦非洲月,不然以非洲月測試一下?Sanmosa Avec cœur 2022年3月25日 (五) 16:07 (UTC)[回复]
此權限應該主要用於線下編輯松?—— Eric Liu 創造は生命(留言留名學生會 2022年3月25日 (五) 17:04 (UTC)[回复]
擬議的「活動協調員」權限適用於各種由維基人主持的編輯松(不包括動員令、非洲月、亞洲月等活動),不論是線上抑或線下。
簡單而言,就是那些在英維相關頁面(中文版翻譯中)所提及的那類編輯松。
  • 這裡所指的「編輯松」通常會在一個指定的時間、地點進行,並且需報名。
  • 為吸引非維基人參與,可透過非維基渠道作宣傳。
同時,(&)建議參考英維修訂大量帳戶創建者的權限設置,以與活動協調員權限有明顯分別。(為吸引更多人成為維基編者的行列,小弟不反對在中文區多弄一些線上/線下編輯松,像英語區那樣)--小文人(見山客棧2022年3月26日 (六) 14:30 (UTC)[回复]
本地就沒有大量帳戶建立者的需求啊?--Xiplus#Talk 2022年3月28日 (一) 08:22 (UTC)[回复]
現在擬議的做法是在既有MAC的基礎上,參考英維新增2種權限:
  1. 繞過「防假」(anti-spoof)機制,容許帳戶創建者建立與現有帳戶名稱相似的帳戶(override-antispoof權限)
  2. 繞過「黑名單」檢查,容許帳戶創建者建立被列入meta:Title blacklist的帳戶(tboverride-account權限)
而這兩種權限是活動協調員沒有的。透過重新劃分「大量帳戶創建者」和「活動協調員」的定位,相信本地編者日後就舉行編輯松等線下聚會而需建立帳戶時,會較為好一點。[至於大量帳戶創建者⋯倒不如留給那些不是為活動而短暫豁免限制的編者吧。]--小文人(見山客棧2022年4月4日 (一) 13:13 (UTC)[回复]
為什麼要容許建立那些帳號名稱?被系統禁止的帳號名稱通常都觸犯用户名方針,實務上都是要求更換用户名。--Xiplus#Talk 2022年4月4日 (一) 13:22 (UTC)[回复]
同样反对此两项权限——您们不应该在非特殊情况下创建这些本不应被创建的账户。另外,提案人可以看看另一条路子(不过这个更适合于线下环境)。咱觉得说的很对啊,Experience shows that encouraging participants to create their own accounts often helps them feel more engaged。如果需要部署的话这边也有不少人会帮忙的。 Stang 2022年4月4日 (一) 15:49 (UTC)[回复]
既然這些權限有問題,為何英維卻可以這樣做?你們反對了,也許在該方面已再無討論空間。
不過,IP cap是限制某些IP區段的編輯次數,即所謂的IP封禁例外。小弟強調,如果有活動協調員,可協助編輯松的進行(皆因協調員可給予參加者「確認用戶」的資格)。
簡而言之,英維編者告訴我們:活動舉辦者除了要申請IP封禁例外,亦得申請創建大量帳戶的權限,以防任何可能出現的問題。意外就是意料之外,你不可能知道會於某一刻出現參加者無法創建帳戶的情形。
修訂方案
為確保參加者自行創建的帳戶能與活動舉辦者代為創建的有著同等權限,小弟認為有必要加入活動協調員權限,如下:
  • 與MAC一樣,擁有noratelimit權限
  • 賦予協調員自行添加參與者為「活動參與者」權限(記緊,要事前問問參與者的用戶名稱!)
小弟先寫到這裡,看看大家有沒有任何意見。--小文人(見山客棧2022年4月9日 (六) 05:00 (UTC)[回复]
enwiki eventcoordinator = zhwiki accountcreator,到底哪裡不懂。--Xiplus#Talk 2022年4月9日 (六) 05:05 (UTC)[回复]
重點在於,現在的MAC可容許編者自行添加參加者自行創建的帳戶為「活動參與者」嗎?還恕小弟在這方面的了解不足。--小文人(見山客棧2022年4月9日 (六) 15:28 (UTC)[回复]
可以。--Xiplus#Talk 2022年4月9日 (六) 15:41 (UTC)[回复]
Wikipedia:大量帳號建立者#「活動參與者」權限授予準則:「大量帳號建立者可以在理論上把活動參與者權限授予任何人」,--Xiplus#Talk 2022年4月9日 (六) 16:05 (UTC)[回复]
就著中文區的情況,小弟較早時已參考英維建立wp:如何舉辦一場編輯松頁面,當中已將「活動協調員」字眼改為wp:MAC
既然大家對「活動協調員」的提案有所反對,看怕也得 撤回方案了。--小文人(見山客棧2022年4月12日 (二) 11:22 (UTC)[回复]

假如有很簡潔扼要的方法能解決繁簡轉換問題,是否有必要特地使用複雜的手工轉換標籤?

下方已詳細説明正式提案,故暫時摺疊先前討論,討論結束後存檔前再恢復。--路西法人𖤐 2022年3月24日 (四) 11:17 (UTC)[回复]

大家好。這邊在編輯冬季战争時,發現其實我們有很簡單的方法可以解決繁簡轉換:

原文
蘇聯空軍在整場戰爭中都緊握著[[制空權]]
手工轉換法
蘇聯空軍在整場戰爭中都緊握-{zh-hant:著;zh-hans:着}-[[制空權]]
更改文字法
蘇聯空軍在整場戰爭中都緊握着[[制空權]]

手工轉換法大概是現行維基百科所推薦的方法,然而這方法複雜,感覺不但會有許多類似的情況,還不利於機器語義分析。相形之下,更改文字法簡潔多了,也方便人類閱讀。假如就這種不更改就會產生繁簡顯示錯誤的情況,特別通融以簡單扼要的方法解決繁簡轉換問題,不曉得大家認為會有哪些顧慮?--Kanashimi留言2021年10月10日 (日) 07:02 (UTC)[回复]

我也覺得這樣比較方便。說實話,這跟刻意的繁簡破壞應該有差,很好辨別,不然也可以指定編輯摘要。—— Eric Liu 歡慶雙十中國國慶留言留名學生會 2021年10月10日 (日) 08:09 (UTC)[回复]
诶?原来这还是方针不允许的吗?我已经这么干了有段时间了(捂脸)--Milky·Defer 2021年10月10日 (日) 10:14 (UTC)[回复]
  • 理论上说“为了更简便的修复/避免错误的繁简转换而更改文字”可以视作繁简转换的正当理由(参WP:CST#勿手动转换条目繁简语句),不过可能会产生争议。Itcfangye留言2021年10月10日 (日) 11:37 (UTC)[回复]
  • 我认为这种理由不够尊重“不转换”,所以主张使用手工转换。--7留言2021年10月11日 (一) 10:46 (UTC)[回复]
  • 這邊發現手工轉換還可能造成參差不齊。例如上面舉的例子其實不夠完善,較完善的的確該使用{{}}裡面的-{zh-hans:着;zh-hk:着;zh-tw:著;}-。也就是說不同人可能就有不同的、有缺陷並且必須再修正的手工轉換修正方法。比較保險的應該採用更改文字法,或{{}}。然而假如正規使用這些文字轉換模板(包括簡繁轉換一對多列表、繁簡轉換一對多列表裡面所有的文字),猜測其中一些恐怕會成為使用率前百名的模板。如此恐怕會有前述效能問題。這或許不是偏好問題,而是技術性問題。--Kanashimi留言2021年10月11日 (一) 11:03 (UTC)[回复]
  • 希望有其他管理員看看是否還有其他疑慮,否則就上面討論看來,似乎應該允許此類型修正?--Kanashimi留言2021年10月11日 (一) 20:23 (UTC)[回复]
    • 如果非要点名管理员的话,那我说一下。我记得以前是不时有见到或进行此类修改的,也没见有人提出异议,虽然我不知道近些年有没有其他讨论。{{}}这类模板,我觉得只有必要在上下文比较复杂的时候使用(具体例子没想到),而不是把每一个遇到的着/著字都改成模板。另外说一点,虽然对这个案例并不适用,以前大家会单独使用里面没有东西的-{}-来提示分词,然后让系统自动转换,好像现在这么用的越来越少了,而是更倾向于在-{}-里面具体指定需要的转换效果?(直接写或者用类似{{}}的模板)我提及这个是从标题的“簡潔扼要的方法/複雜的手工轉換標籤”想到的。Liangent留言 2021年10月11日 (一) 21:21 (UTC)[回复]
  • 作为(前)繁简转换维护者来说两句:简繁转换并不是一一对应的,大多情况都是一简对多繁,而像“著”和“着”则是一繁对多简。我觉得手工把“著”改为“着”,是符合Wikipedia:繁简处理#勿手动转换条目繁简语句中要求的“正当理由”的(因此,现有规则即允许这样做)。反过来的例子会更多,比如ref group用“註”而不用“注”,表示动词时用“幹”不用“干”等等。这些一多对应的文字,的确可以为常见组合增加转换规则,但我不觉得这个能覆盖完整,而且也不是所有情况都能加规则解决,比如<ref group="註"><ref group="注">。因此,遇到了这种毛病,手改没问题,提报一下看能不能安全地将其文字组合加进全局转换则是进阶要求。--菲菇维基食用菌协会 2021年10月11日 (一) 22:15 (UTC)[回复]
    同上。Sanmosa WÖRK 2021年10月12日 (二) 14:47 (UTC)[回复]
    通商。 — 𝕏ℂ𝕠𝕞𝕙𝕘𝕙𝕒𝕝𝕝 talk 2021年10月16日 (六) 22:51 (UTC)[回复]
感謝各位的意見。感覺更改文字法應該可以算作共識了。--Kanashimi留言2021年10月13日 (三) 22:43 (UTC)[回复]
是否應該考慮明文寫入指引,作為案例?—— Eric Liu 創造は生命(留言留名學生會 2021年10月14日 (四) 13:49 (UTC)[回复]
或許在方針裡提一下比較好?--Kanashimi留言2021年10月14日 (四) 20:30 (UTC)[回复]
附議。 — 𝕏ℂ𝕠𝕞𝕙𝕘𝕙𝕒𝕝𝕝 talk 2021年10月16日 (六) 22:51 (UTC)[回复]
我也認同「现有规则即允许这样做」,支持指引加一句提醒。——遲來的HTinC23留言2021年10月23日 (六) 13:45 (UTC)[回复]
反对写入规则,选择“不转换”的用户不希望强制看到外语文字。--7留言2021年10月30日 (六) 15:25 (UTC)[回复]
又不是規定一定要這樣做,只是「除罪化」,保證不會因此觸犯方針或指引而已。偏好手工轉換者,大可繼續手工轉換。—— Eric Liu 創造は生命(留言留名學生會 2021年10月30日 (六) 20:25 (UTC)[回复]
实际效果一样,“保證不會因此觸犯方針或指引”也就意味着能够以此为理由强行把他人使用的手工转换改掉,而且有方针支持的情况下还能对3RR豁免。--7留言2021年11月1日 (一) 08:58 (UTC)[回复]
如上述討論,這或許不只是個偏好問題。您可以針對上面討論的贊同論點一一提出您的解方,如此更能說服人。--Kanashimi留言2021年11月1日 (一) 20:02 (UTC)[回复]
他就是不想處理而已,反正他也沒打算認真進行討論。--Sanmosa Ázijská Práca 2021年11月2日 (二) 08:19 (UTC)[回复]
我的主张就是当其他用户已经用手工转换时不以这种“理由”去改(等于阻止)。如果双方都坚持原来的用法,那要么先到先得,要么就不管谁坚持改都按3RR处理。如果修改前后在“不转换”下显示的文字一样,我没有意见;如果为了所谓“簡潔扼要”,代价却是强制不转换用户看到不同文字,这我无法接受。--7留言2021年11月2日 (二) 12:43 (UTC)[回复]
現在的情況就是一個合法,一個可能違法,需要明文「除罪化」;在已經有既有轉換方式之下,採納「先到先得」原則應該是沒有問題。—— Eric Liu 創造は生命(留言留名學生會 2021年11月10日 (三) 14:38 (UTC)[回复]
「選擇『不轉換』的用戶不希望強制看到外語文字」這句我看不懂,不轉換不是本來就一堆所謂「外語」文字嗎?--路西法人 2021年11月28日 (日) 16:11 (UTC)[回复]
同意。--Nrya ✰我聽見有個聲音~ 2021年10月31日 (日) 03:41 (UTC)[回复]

@Kanashimi如果要擬文說明以上這種變更的性質,您會怎麼描述?—— Eric Liu 創造は生命(留言留名學生會 2022年1月17日 (一) 02:51 (UTC)[回复]

或許可這樣:
改成:
--Kanashimi留言2022年1月17日 (一) 03:40 (UTC)[回复]
原本 改為 能否接受
修正簡體下轉換錯誤
{{subst:著}} 修正簡體下轉換錯誤
{{著}} 可以,但不推薦的修復方式。
-{zh-hans:着; zh-hk:着;zh-tw:著;}- 可以,但不推薦的修復方式。
-{zh-cn:着;zh-tw:著;}- 造成香港模式下轉換錯誤
-{zh-hans:着;zh-hant:著;}- 造成香港模式下轉換錯誤
造成簡體下轉換錯誤
{{着}} 不必要的行為
-{zh-hans:着; zh-hk:着;zh-tw:著;}- 不必要的行為
-{zh-hans:着; zh-hk:着;zh-tw:著;}- 造成簡體下轉換錯誤
-{zh-hans:着; zh-hk:着;zh-tw:著;}-{{著}}{{着}} {{subst:著}}{{subst:着}} 簡化原始碼
{{著}}{{着}} 造成簡體下轉換錯誤
錯誤用詞
其他繁簡文字可類推
朝廷辦公官署 朝廷辦公官署 修正繁體下轉換錯誤「原系」
语片言 语片言 修正繁體下轉換錯誤「只語」

提供涵蓋所有變換的表格,看看是否符合上面的共識。--Xiplus#Talk 2022年1月22日 (六) 03:22 (UTC)[回复]

唉,這表格真是太簡單明瞭了。--Kanashimi留言2022年1月22日 (六) 06:22 (UTC)[回复]
我觉得{{著}}{{着}}改成其实应该允许且鼓励。一来提高源码可读性,二来减少不必要的模版调用。--菲菇维基食用菌协会 2022年1月22日 (六) 06:25 (UTC)[回复]
感覺只要不會造成轉換錯誤,「着」比「{{}}或{{}}」略優。「著」到「{{著}}」一類可以在手頭沒有簡體輸入法時,只打括號做權宜之計。但長久來看,使用視覺化編輯器或語法凸顯工具時,模板太搶眼。--洛普利寧 2022年1月22日 (六) 06:36 (UTC)[回复]
以更改繁體以避免加入切斷標記的方法也是可以囉?例如將「一刀不剪发布影片」改成「一刀不剪發布影片」以避免「剪发」被轉換也是可以的?--Ghren🐦🕘 2022年1月22日 (六) 13:30 (UTC)[回复]
是這意思。我加上了這個例子。 --Kanashimi留言2022年1月22日 (六) 23:48 (UTC)[回复]
这个情况其实稍微有些不一样。“著=>着”和“注=>註”是那种不改字就没法修复的转换问题;而“头发”、“剪发”的转换取决于两字连续出现,这种情况加上-{}-就可以修复而无须改字。
当然,并不是说这种情况就不能改字,我觉得断词和改字都可以允许,不过略倾向于推荐断词。--菲菇维基食用菌协会 2022年1月31日 (一) 08:05 (UTC)[回复]
support. ——魔琴 [ 留言 贡献 ] 2022年1月31日 (一) 08:31 (UTC)[回复]
其實「活著」本身在繁簡體下都會正確轉換,不是好例子;應該是因為系統設定。這邊改了一下例子。假如我們把「握著」也加入系統設定,那即便在連詞的情況下,也會如您所提,只要加入「-{}-」就可以解決。當然把太多詞加入系統轉換表恐非良策就是。 --Kanashimi留言2022年1月31日 (一) 08:48 (UTC)[回复]
是可以尽可能地做连词,但这样需要有界面管理员长期维护全局转换表。相比于允许任何人发现了就能改,前者就显得不那么wiki了。--菲菇维基食用菌协会 2022年1月31日 (一) 15:47 (UTC)[回复]
那可以把{{}}的內容改成「」,並將使用方式改成{{subst:}}。--Xiplus#Talk 2022年1月23日 (日) 09:47 (UTC)[回复]
赞同。—菲菇维基食用菌协会 2022年1月31日 (一) 07:57 (UTC)[回复]
已相应修改表格。--菲菇维基食用菌协会 2022年2月8日 (二) 19:01 (UTC)[回复]
這個表格不錯,不過怎麼轉換為政策條文呢?三言兩語似乎很難說清楚。—— Eric Liu 創造は生命(留言留名學生會 2022年2月8日 (二) 16:39 (UTC)[回复]
就直接當範例貼上的話,會有什麼樣的顧慮嗎?--Kanashimi留言2022年2月8日 (二) 20:44 (UTC)[回复]
可能還是得用文字說明一下通則如何?—— Eric Liu 創造は生命(留言留名學生會 2022年3月2日 (三) 06:31 (UTC)[回复]
@Ericliu1912 更新了一下上面的通則說明。煩請看看這樣有沒有比較理想。--Kanashimi留言2022年3月2日 (三) 06:44 (UTC)[回复]
感覺可以,是否轉移至方針區公示?—— Eric Liu 創造は生命(留言留名學生會 2022年3月15日 (二) 06:32 (UTC)[回复]
Yes.--Kanashimi留言2022年3月15日 (二) 08:17 (UTC)[回复]
我的感觉是,这相当于是维基百科的“推荐用字”。即,當繁简不是一一映射的關係時,優先选择不容易產生歧义的字形。如
你维字形 简体、港澳字形 台湾字形
助词、附着
明也,标著也
你维字形 简体字形 繁體字形
疏也
灌也
你维字形 简体字形 繁體字形
犯也,求也
能事也
燥也
卦名 -{乾}-

 ——魔琴 [ 留言 贡献 ] 2022年2月9日 (三) 12:13 (UTC)[回复]

你可以這樣說。一簡對多繁的時候,繁是被推薦的;一繁對多簡的時候,簡是被推薦的。--Ghren🐦🕘 2022年2月11日 (五) 13:49 (UTC)[回复]
然。--菲菇维基食用菌协会 2022年2月13日 (日) 18:32 (UTC)[回复]

繁簡處理修訂案

第1版
現行條文

勿手动转换条目繁简语句 对于读者来说...(略)...总之手动转换条目繁简语句是没有必要的。

提議條文

勿手动转换条目繁简语句 对于读者来说...(略)...总之手动转换条目繁简语句是没有必要的。一種例外是當繁簡並非一對一轉換,且該字不與上下文形成詞彙而不適宜使用全文轉換時,為了簡便地修復錯誤的繁簡轉換,可改為不會造成轉換錯誤的用字,例如將握著改為握着,會比握-{zh-hans:着; zh-hk:着;zh-tw:著;}-更具可讀性,具體規則請參見下表。

修改前原始碼 修改後原始碼 是否允許
握著 握着 修正簡體下轉換錯誤,可使用{{subst:}}
握著 握{{著}} 可以,但不推薦
握著 握-{zh-hans:着; zh-hk:着;zh-tw:著;}- 可以,但不推薦
握著 握-{zh-cn:着;zh-tw:著;}- 造成香港繁體下轉換錯誤
握著 握-{zh-hans:着;zh-hant:著;}- 造成香港繁體下轉換錯誤
握着 握著 造成簡體下轉換錯誤
握着 握{{着}} 不必要的行為
握着 握-{zh-hans:着; zh-hk:着;zh-tw:著;}- 不必要的行為
握-{zh-hans:着; zh-hk:着;zh-tw:著;}- 握著 造成簡體下轉換錯誤
-{zh-hans:着; zh-hk:着;zh-tw:著;}-{{著}}{{着}} 簡化原始碼,可使用{{subst:著}}{{subst:着}}
{{著}}{{着}} 造成簡體下轉換錯誤
活著 活着 「活著」一詞系統能正確轉換
著名 着名 錯誤用詞
其他繁簡文字可類推
朝廷辦公官署 朝廷辦公官署 修正繁體下轉換錯誤「原系」
鸡把毛除去 鸡把毛除去 修正繁體下轉換錯誤「找只鸡」

修改自User:Kanashimi的提議條文,特別限定 1. 無法使用全文轉換 2. 僅限轉換有錯誤時 才能如此修正。原先表格部分第1、2行合併,增列「活著」一行不應轉換。請再看看目前版本有無問題。--Xiplus#Talk 2022年3月24日 (四) 10:03 (UTC)[回复]

不確定「其他繁簡文字可類推」兩行是否需要,另「隻語片言」應較常作「片言隻語」,且這是一個詞彙,應該加入轉換詞庫而非一律使用這種方式修復吧?--Xiplus#Talk 2022年3月24日 (四) 10:30 (UTC)[回复]
請當初加入此行的Kanashimi說明一下「此人原係蘇氏人馬」是什麼?或是換成別的常見句子,或移除。--Xiplus#Talk 2022年3月24日 (四) 11:49 (UTC)[回复]
改成了寺廟中的例子。 --Kanashimi留言2022年3月24日 (四) 22:26 (UTC)[回复]
@Kanashimi:那麼「片言隻語」呢?--Xiplus#Talk 2022年3月25日 (五) 03:51 (UTC)[回复]
改成定義謬誤中的用法。 --Kanashimi留言2022年3月25日 (五) 08:35 (UTC)[回复]
(+)支持容許修復一繁多簡或一簡多繁而導致錯誤轉換的修復不視作繁簡破壞。一個影響不大的小問題:我覺得應該將例子和條文分開。--路西法人𖤐 2022年3月24日 (四) 11:21 (UTC)[回复]
您的意思是例子不作為指引的一部分嗎?--Xiplus#Talk 2022年3月24日 (四) 11:32 (UTC)[回复]
不是,純粹是字句分句分段而已。格式的小問題。--路西法人𖤐 2022年3月24日 (四) 12:05 (UTC)[回复]
「可改為不會造成轉換錯誤的用字 / 例如將」這邊應該換段落的意思嗎?--Xiplus#Talk 2022年3月24日 (四) 13:49 (UTC)[回复]
是。--路西法人𖤐 2022年3月25日 (五) 04:24 (UTC)[回复]
微调了一下表述,如果有疑问请ping我。--Tranve () 2022年3月24日 (四) 11:35 (UTC)[回复]
(+)支持--Yinyue200留言2022年3月26日 (六) 06:36 (UTC)[回复]
着著的例子感觉可以换一个,握着直接塞进表里需要加的防过度转换规则几乎没有。比如改成[展體表實兌]現著?屠麟傲血留言2022年3月28日 (一) 06:22 (UTC)[回复]
偷偷問一下,「著」只有在讀「ㄓㄨˋ」的時候簡體字才跟繁體字相同,其他時候(讀「ㄓㄜ˙」、「ㄓㄨㄛˊ」、「ㄓㄠˊ」、「ㄓㄠˉ」的時候)簡體字都是「着」?--北有戰鬥陀螺留言2022年4月1日 (五) 14:04 (UTC)[回复]
第2版
提議條文

勿手动转换条目繁简语句 对于读者来说...(略)...总之手动转换条目繁简语句是没有必要的。

例外:修復繁簡一對多轉換錯誤 一種例外是當繁簡並非一對一轉換,且該字不與上下文形成詞彙而不適宜使用全文轉換時,為了簡便地修復錯誤的繁簡轉換,可改為不會造成轉換錯誤的用字。修復錯誤轉換時,應優先使用不存在歧義且不會造成錯誤轉換的字形。以下提供一組非一對一繁簡轉換且常見出現轉換錯誤的字形供參考,其他字形亦可類推。

例子:「着」、「著」
字義 建議字形 简体字形 港澳字形 台灣字形
助词、附着
明也,标著也
轉換例子
為簡化圖表:
  • -{zh-hans:着;zh-hk:着;zh-tw:著;}-以「A」表示;
  • -{zh-cn:着;zh-tw:著;}-以「B」表示;
  • -{zh-hans:着;zh-hant:著;}-以「C」表示。
修改前 →
修改後 ↓
握著 握着 握{{着}}握{{著}}
握著 需要修復 簡體、港澳顯示錯誤
握着 建議做法 無需修復 簡化代碼 建議做法
握{{着}}握{{著}} 可以但不推薦 不必要的行為 可不修復 簡化代碼 可以但不推薦
不必要的行為 可不修復
港澳顯示錯誤 需要修復
修改前原始碼 修改後原始碼 是否允許
簡化代碼
{{着}}
{{著}}
活著 活着 系統能夠正確轉換「活著」,不必要的手動轉換行為
著名 着名 錯誤用詞
這樣?@Xiplus--路西法人𖤐 2022年3月28日 (一) 09:22 (UTC)[回复]
(+)支持 目测没有可见问题。--Yinyue200留言2022年3月30日 (三) 16:51 (UTC)[回复]
感覺長到已經是{{輔助說明}}了,舉例挑一個最具代表性的就行了吧?--Xiplus#Talk 2022年3月31日 (四) 01:21 (UTC)[回复]
那麼僅保留「着」的例子就行了。--路西法人𖤐 2022年3月31日 (四) 07:05 (UTC)[回复]
(*)提醒:以下列出三组一组非一对一转换--MilkyDefer 2022年3月31日 (四) 13:21 (UTC)[回复]
我覺得還是全部用文字敘述比較好,表格放輔助說明。--Xiplus#Talk 2022年3月31日 (四) 15:59 (UTC)[回复]
附註說明也是可以。--路西法人𖤐 2022年4月1日 (五) 03:09 (UTC)[回复]
是輔助說明頁,不是附註說明。--Xiplus#Talk 2022年4月1日 (五) 04:25 (UTC)[回复]
打錯字 囧rz……--西 2022年4月3日 (日) 04:41 (UTC)[回复]
提議條文

勿手动转换条目繁简语句 对于读者来说...(略)...总之手动转换条目繁简语句是没有必要的。

一種例外是當繁簡並非一對一轉換,且該字不與上下文形成詞彙而不適宜使用全文轉換時,為了簡便地修復錯誤的繁簡轉換,可改為不會造成轉換錯誤的用字。修復錯誤轉換時,應優先使用不存在歧義且不會造成錯誤轉換的字形。例如在簡體和港澳繁體有「着」、「著」兩種字形,在臺灣正體僅有「著」字形,在原始碼輸入「着」時可由系統自動轉換成臺灣正體「著」,但反之則不會轉換,因此以台灣正體輸入「握著」一詞時無法正確轉換為簡體和港澳繁體,此時容許直接將原始碼修正為「握着」以修正轉換錯誤,如果在內文直接使用轉換規則(例如「握-{zh-hans:着; zh-hk:着;zh-tw:著;}-」)時,也允許將原始碼簡化為「握着」。更詳細的範例可參考Wikipedia:非一對一字詞轉換錯誤修正指南

@LuciferianThomas第3版,表格內容全部放到上述的獨立頁面(為{{輔助說明}})。--Xiplus#Talk 2022年4月6日 (三) 01:28 (UTC)[回复]

支持。--西 2022年4月6日 (三) 04:19 (UTC)[回复]
已建立輔助說明頁。--Xiplus#Talk 2022年4月8日 (五) 12:46 (UTC)[回复]

Afd合併遺留重定向問題

可否規定如果afd討論結果為合併的話將遺留重定向設為永久半保護?因為發生很多次新用戶將關注到合併的重定向手動回退到原本版本的事件。畢竟就算這些關注度重定向的後來關注度發生改變,以致其可以重建條目,程序上也應該是先到drv而不是直接重建。這些重定向理論上應無編輯需要-某人 2022年3月24日 (四) 11:52 (UTC)[回复]

雖然可預想數量是很多,但實際比例是多少?這個比例有高到需要從「遇到問題再保護」(保護方針要旨)變成「不論情況一律保護」嗎?--Xiplus#Talk 2022年3月24日 (四) 12:04 (UTC)[回复]
方針死的人是活的。容我反問就這樣留下來不保護意義何在?反正又沒有合理理由需要編輯。比例我不知道,但至少我自己回退的我記得的至少已經超過十幾次--某人 2022年3月24日 (四) 12:10 (UTC)[回复]
需要保護的是遭受破壞的頁面,沒有人編輯就保護根本沒道理。--Xiplus#Talk 2022年3月24日 (四) 13:46 (UTC)[回复]
現在不是因為沒有人編輯所以就保護,是因為有高機會受破壞而且沒有必要編輯所以才保護--某人 2022年3月24日 (四) 17:42 (UTC)[回复]
「高機會」所以我上面問這個機會究竟是多少,有超過50%嗎?--Xiplus#Talk 2022年3月25日 (五) 01:31 (UTC)[回复]
技術上除了半保護與過濾器外,還有沒有其他機制能阻止新用戶進行特定編輯操作的?Sanmosa Avec cœur 2022年3月24日 (四) 12:27 (UTC)[回复]
過濾器是最靈活的機制了,不然您希望有怎麼樣的機制?--Xiplus#Talk 2022年3月24日 (四) 13:47 (UTC)[回复]
沒有,我就只是想問一下技術上操作的可能性而已。我覺得真要處理這問題的話,用過濾器是不錯的選擇。Sanmosa Avec cœur 2022年3月25日 (五) 00:36 (UTC)[回复]
Wikipedia talk:删除方针/存档5#關於過濾器阻止曾被存廢覆核通過還原或存廢討論予以保留的條目再掛上notability或提刪無效 過濾器做不了才提這個方案吧。--Ghren🐦🕛 2022年4月3日 (日) 04:54 (UTC)[回复]
反對永久保護,但支持理念;建議加模板標記並使用過濾器阻擋並提示。--路西法人𖤐 2022年3月24日 (四) 12:04 (UTC)[回复]
反對永久保護,但可適當標記追蹤。—— Eric Liu 創造は生命(留言留名學生會 2022年3月24日 (四) 14:10 (UTC)[回复]
現有{{R FAILS N}}和Special:滥用过滤器/185但是印象中在關注度不足而合併時並非每次皆有使用該模板。--留言2022年3月24日 (四) 16:26 (UTC)[回复]
这滥用过滤器185真的没问题吗……从原理上--MilkyDefer 2022年3月24日 (四) 17:36 (UTC)[回复]
时刻跟踪Special:相关更改/Category:关注度重定向会不会更好些?--MilkyDefer 2022年3月24日 (四) 17:41 (UTC)[回复]
無法,準確來說應該要跟蹤該分類的「成員近期變更」而非「相關變更」,一旦頁面從分類移除,就不會出現在相關變更中,但這個修改會記錄在近期變更上。--Xiplus#Talk 2022年3月28日 (一) 07:45 (UTC)[回复]

仅含虚构内容的独立角色条目的存废问题

近我在清理角色信息框的过程中,发现中维有大量独立的ACGN角色条目只有剧情、角色特征、使用的道具等虚构视角的内容,且几乎完全没有现实世界视角的内容。于是我将这类条目全部提报存废讨论(见3月24日3月25日的存废讨论),提出的理由是其违反WP:NOTPLOT方针(“维基百科的条目并不是仅关于虚构作品情节的介绍。维基百科采用百科全书的方式描述具有关注度的虚构作品,介绍它们的受欢迎程度和它们的意义。一般情况下,简洁的情节概述是可以包含在这些介绍中的。”)。

而有讨论参与者表示,条目可以等待改善,且多数条目的其它语言版本都有现实影响的内容,可以据其扩充。但据我观察,大多数此类条目已经建立了几年甚至十几年的时间,自其创建以来就只有剧情和设定,也从来没有编者往其中加入现实影响相关的内容。因此我对是否有编者愿意改善这类条目表示怀疑。

由于影响范围较广,且可能引起大量争议,因此在此发起议题,望请求社群的意见。即:只有剧情、设定等虚构视角的独立角色条目是否应该删除或合并至角色列表条目?如果等待改善,那是否有必要设立等待的最后期限?存在此类问题,且没有编者愿意改善的条目该如何处理?--BlackShadowG留言2022年3月25日 (五) 07:10 (UTC)[回复]

為什麼要有等待最後期限?而且不是每位讀者、編者都知道具體的內容方針,遇到此類有問題的條目加上模板{{real world}}就好,如果真的想刪,每天提刪一兩個,至少要讓人有時間來改善。一天提刪幾十個,誰有那麼多時間幫忙改善?维基百科:只有情节介绍的虚构作品条目的意思很明確,如果ACGN角色条目沒有潛力可以改善,再合併或刪除,昨天你提刪的幾個條目英維就是這麼做的。--中文維基百科20021024留言2022年3月25日 (五) 07:29 (UTC)[回复]
我不认为单纯得挂上real world模板能解决问题,好几个条目real world挂了几年了也没得到任何改善。我提删的那些几十个条目基本都建立了好几年的时间,也没得到改善。有潜力改善,但没有人愿意改善的条目,除了合并和删除,还能有什么解决方法。--BlackShadowG留言2022年3月25日 (五) 07:40 (UTC)[回复]
所以就像我前面所說的,慢慢來,不要急,要提刪就爭取控制在一天1-2個,一天提刪幾十條這種做法肯定不可取。--中文維基百科20021024留言2022年3月25日 (五) 07:49 (UTC)[回复]
挂着标识好几年的条目,按着分类找都能找到一大堆,这本来是老大难没银弹的问题,我不认为这样牟然删除是银弹方案,尤其是部分条目可以确认是有办法去改善,而提案者只图省事的话,我乍看都是在GAME。——Sakamotosan路过围观 | 避免做作,免敬 2022年3月25日 (五) 07:59 (UTC)[回复]
之前有一个类似走fanpov的都被“祭旗”过一次(暂时看来,那个人暂时冷静下来了),我不介意再整理一下再“祭旗”一次。——Sakamotosan路过围观 | 避免做作,免敬 2022年3月25日 (五) 08:04 (UTC)[回复]
“Careful, Chief. You dig up the past, all you get is dirty. ”,每次都换着理由来提删,还不如感兴趣的参与改善,要不然的话,编辑是志愿性质,搞不了就别搞。——Sakamotosan路过围观 | 避免做作,免敬 2022年3月25日 (五) 07:56 (UTC)[回复]
说是有改善空间,几年了也没人改善;要提删又被说是GAME。我也不知道该怎么样才好了,看来这些方针的执行力真的是可有可无。--BlackShadowG留言2022年3月25日 (五) 08:23 (UTC)[回复]
要想執行方針前提是認同這個理念,不好的方針寧願修掉。而且中維好多方針在2000年代初直接翻譯英維來的,估計沒怎麼公示就直接通過,而英維那邊都改了,中維都不變。--中文維基百科20021024留言2022年3月25日 (五) 08:39 (UTC)[回复]
提刪的按鈕實在出現得太簡單了,刪當然是很簡單,假如一個角色有關注度的話,不太可能沒有現實的影響和評論,我覺得不應該以提刪作為迫其他編者改善。--Ghren🐦🕓 2022年3月25日 (五) 08:20 (UTC)[回复]
(!)意見具體問題具體分析,我看了一下基本上比較邊緣的(差不多就是那些在英文維基百科沒條目的)條目情況明顯比在英文維基百科有條目的糟糕。要保留其實非常簡單,就是把一些冗餘的夾雜原創研究的東西刪一下然後把英文維基的評價翻譯過來。--🎋🎍 2022年3月25日 (五) 09:47 (UTC)[回复]
我的意思是情況實在是比較糟糕的條目沒必要保留,那些明顯能按英文維基百科改善的也沒必要這麽急著拉到AFD。--🎋🎍 2022年3月25日 (五) 09:51 (UTC)[回复]
一兩個是簡單,幾十條就不簡單了。在英文維基百科沒條目的我也不反對刪除。--中文維基百科20021024留言2022年3月25日 (五) 10:00 (UTC)[回复]
經查凌曉雨蕾貝卡·錢伯斯烏蘇拉源靜香路克·天行者尤達邪惡博士菲比·布菲亞森·羅蘋李小狼木之本櫻翠迪鳥白卜庭魁剛·金蘇珊·梅耶在英文維基有質量較好的條目或在法語等版本有高品質條目,這幾個的AFD可以先停了,其他的要麽在英文維基被合併要麽在英文維基的版本也是趨向虛擬世界視角,建議討論完後繼續AFD流程。--🎋🎍 2022年3月25日 (五) 15:06 (UTC)[回复]
BlackShadowG已經暫停提刪,如果剩下的你覺得有問題的話可以明天重新提刪。--中文維基百科20021024留言2022年3月25日 (五) 15:11 (UTC)[回复]
補充:黛西公主联合军札克斯·菲爾固蛇彩女尼克·貝里克金家藩埃奇歐·奧狄托雷·迪·佛羅倫斯。--🎋🎍 2022年3月25日 (五) 16:02 (UTC)[回复]
還有一個伏地魔。--🎋🎍 2022年3月26日 (六) 08:50 (UTC)[回复]

你维挂板条目比比皆是,好多都挂了好几年,凭什么就real world要迫使我们改善?Fire Ice 2022年3月25日 (五) 08:38 (UTC)[回复]

我的意思是,你维烂条目多人所共知,有一份热发一份光很好,不要以删除为压力迫使我们去改善。(个别烂的不得了的条目除外)--Fire Ice 2022年3月25日 (五) 08:41 (UTC)[回复]
BlackShadowG大部分提刪的條目,無非缺少的是reception一節而已。即使是只有虛擬情節也不並非不能接受,除非虛擬情節是編者在胡寫,與原作劇情設定有極大出入。--中文維基百科20021024留言2022年3月25日 (五) 08:46 (UTC)[回复]
若是只有虚拟情节的条目也可以存在,那我可以理解为各位并不认同WP:NOTPLOT的理念,那这边我们可以讨论是否有必要修改这条方针,而不是等执行的时候再来一堆反对意见。--BlackShadowG留言2022年3月25日 (五) 08:51 (UTC)[回复]
滑坡是吧?我只是提出可以改善而避免提删,或者不应该利用程序来压迫其他志愿者去做“改善”,你认为这些编辑就是不尊重规则?有些太烂的,我认为可以考虑往主体条目或者对应的元素类表合并处理,但很明显这次部分条目有部分有外语条目,而且部分的质量足以用于改善条目,为了行使自己的主张,来一次过提删,我不觉得是好的行为。——Sakamotosan路过围观 | 避免做作,免敬 2022年3月25日 (五) 08:57 (UTC)[回复]
阁下对我的指控我无法接受,我把一堆不合规则的条目提删,为何就是对其他志愿者的“压迫”?对应的外语条目质量高,中维的条目不合规则,就只能改善,不能提删吗?确实,我提删条目时没有试图自己去改善,但改善只不过是避免提删的途径,我从不觉得提删不合规条目这一程序本来有什么问题。如果真要说我是在“行使自己的主张”,那我的主张就是,中维的条目,理应照中维的方针管理,外语条目的质量再高,中文条目不合规则的就应该删除或合并。--BlackShadowG留言2022年3月25日 (五) 10:11 (UTC)[回复]
我覺得問題還是出在短時、大量提刪明顯可以改善的條目,我不認為這一做法是合適的。--中文維基百科20021024留言2022年3月25日 (五) 10:31 (UTC)[回复]
除了我上面列舉的那些外,其他的改善空間都非常狹窄甚至沒有,除了少數幾個我私底下認為有點激進外,不認為提刪不合適。--🎋🎍 2022年3月26日 (六) 08:49 (UTC)[回复]
如果英維那邊都重定向的話重新再提刪好了。也可以用關注度解決,先掛個模板再說。--中文維基百科20021024留言2022年3月26日 (六) 08:54 (UTC)[回复]
我已经把没有英维条目的纯剧情中文条目重新提删。--BlackShadowG留言2022年3月27日 (日) 04:31 (UTC)[回复]
Wikipedia:Articles for deletion/Lynette Scavo英语Wikipedia:Articles for deletion/Lynette Scavo上來就是一個keep,(Keep and trim appropriately. The first four Google Scholar links all appear to be substantively about this character. One is paywalled, one is dead, but each appears from title/abstract to be on topic. )--中文維基百科20021024留言2022年3月27日 (日) 06:19 (UTC)[回复]
那正好暴露了這一方針本來就可能有問題,不然也不會有那麼多反對意見。--中文維基百科20021024留言2022年3月25日 (五) 08:58 (UTC)[回复]
英維已經沒有「仅含虚构内容」 這一點了,我不知道虛擬情節是不是當初從英維那邊搬來的,要翻一下歷史討論了。--中文維基百科20021024留言2022年3月25日 (五) 09:00 (UTC)[回复]
指正:現在還有英維en:WP:NOTPLOT,「Summary-only descriptions of works.」。--Nostalgiacn留言2022年3月25日 (五) 12:36 (UTC)[回复]
方针问题不大,如果秉承作为网络版的传统百科全书的话,让一个独立条目的主体被现实世界关注是NOTPLOT的“guideline”。但显然地通过这样来逼宫就有点“人干事”了。——Sakamotosan路过围观 | 避免做作,免敬 2022年3月25日 (五) 14:31 (UTC)[回复]
@中文維基百科20021024NostalgiacnFire-and-Ice,既然某位编辑如此“捡鸡毛当令箭”的话,只能尽量“花时间”处理部分能改善的已提报条目(原则上,能找到现实的关注,包括评价、有(可能)被现实关注的排名,基本上问题不大。如果没有的话,就真的是太糟糕了,只能往主题条目或者对应的元素列表合并),毕竟人家花了这么多时间逐个打开页面,点开TW,逐个条目复制理由来提交吧,肯定是经过深思熟虑思考过,觉得自己动手改善是劳心劳力,还不如“破坏”掉干手净脚,对不?我是个社畜和半个现充,只能摸下鱼陪下freshfish玩法棍游戏了。——Sakamotosan路过围观 | 避免做作,免敬 2022年3月25日 (五) 14:23 (UTC)[回复]
面对一篇有关注度的广告条目,我们要么删除,要么真的尽快改善。不会有人说「这篇广告条目的主题有关注度。虽然条目现在写得不好,但未来大有可为。所以我们应该应该保留这篇条目,挂上{{advert}}等其他人改善」。关注度是说明条目有写好的潜力,但我们的最终目标是将这个潜力变成现实。广告条目内容足够差,和我们的目标相左,那结果就是被处理掉,不用在这里谈什么潜力了。
对于虚构条目,我认为这也是内容品质差的问题,应该尽快处理而不是分析关注度。WP:PLOT指出要“采用百科全书的方式描述具有关注度的虚构作品”。只有虚构内容的条目无法反映角色的现实影响,是不符合百科全书的方式描述的,换句话说就是写得不好。这和广告条目一样,都是需要立即改善的。把Reception写出来,条目品质达标了,关注度也不证自明。
和广告条目相比,纯剧情条目的负面影响不很明显,但长远来看确实值得关注。上面说纯剧情条目几年没人改。然而没人改都要谢天谢地了,很多条目改完之后虚构内容越来越多、格式越来越差,现实世界内容依然没有影子,最后都没法清理。回退到最初版本,那最初版本也是WP:PLOT,也不符合标准。而且新编辑创建条目也是模仿现有内容。如果既有内容的编写方向不对,那就是把人带到沟里了。如果条目只有故事介绍,但写得不错(GA级),我认为现在也可以不处理。毕竟中文社群对纯剧情条目有一定容忍度,而且我们还有很多其他要做的事情,而且新编辑模仿优质的故事介绍也是一种学习。我担心的是,这种条目按经验往往会被粉丝改得越来越差,一方面成为负面典型,另一方面清理要浪费不少人力。
我认为这种虚构条目重定向到主条目,或者移动到草稿空间比较好。原有内容都有底子,谁想改可以接着改。直接删除我认为有点可惜,而且做法太过激进,容易引发编辑反感。--洛普利寧 2022年3月27日 (日) 06:24 (UTC)[回复]
主要问题是做法激进,而且在知道有办法改进的情况下,还是进行提删,而且还假惺惺地说可惜。我怎样看都觉得这种做法“可笑”。纯广告的条目几乎没有改善之处,甚至必要时可以提速删,不会说任何无来源,原创研究,不符合NOT的有速删的必要?而且有用户提及有BlackShadowG引入一堆没翻译内容,最后被发现后由其他人重写改善,反而倒是有时间逐个打开页面,点击TW提删,看来工具的确方便,按几下鼠标比在键盘码一大坨字还要省事。——Sakamotosan路过围观 | 避免做作,免敬 2022年3月28日 (一) 01:23 (UTC)[回复]
做法激进我承认,但我从不认为这次提删有问题。要是一篇广告宣传条目,就算英文版写得再好(就算是GA),要么就直接删除,要么就尽快改善,不会有人说“这篇条目有改善空间,所有不能删”,而且估计一天提多少篇就删多少篇;现在换成了几篇同样违反方针,根据WP:DP#14应该删除的条目就不一样了,会被人说“明显有改善空间”所有不能删,问改善给不给最后期限会被人说“迫使”他人改善,一次提太多还会被人送上AN。同样的方针,放在不同条目上标准就不一样了对吧?
把我以前写的条目拿来指责我是更想不到的,我3月初创建的俄乌战争期间对乌克兰的援助列表本来想一个晚上全部翻译完的,但由于现实生活中的一些缘故没能翻完,第二天向继续翻译时发现已经被AINH移动到草稿了。那时英文维基百科的条目本来也很不稳定,当时我就想既然已经被移动到草稿了,不如等英文条目稳定了再来翻译,就去翻译另一篇GA去了。这还能被人说是“该做的不做”更是令人想不到的。--BlackShadowG留言2022年3月28日 (一) 02:50 (UTC)[回复]
“尽快改善”,除了少数有明确迫切性限期的,例如速删、提删、关注度提报,大部分能挂修饰标识的,都没给设定明确的修葺期限,你倒是一口一个“可惜”然后转手提删,让其他编辑帮你“打工”。所以本质上你没认为自己存在问题:编辑是志愿性质,删除方针是提议能改善的尽量改善先。系统是完美的,如果存在缺陷,人是缺陷。——Sakamotosan路过围观 | 避免做作,免敬 2022年3月28日 (一) 03:21 (UTC)[回复]
就算是看上去是广告,如果有改善的空间(例如部分描述具有百科性),都会尽量修葺,除非全是黄婆麻瓜的描述,那就直接提SD,也省得讨论,而且至少少见这样大量的广告类似的条目出现。——Sakamotosan路过围观 | 避免做作,免敬 2022年3月28日 (一) 03:31 (UTC)[回复]
这种明知道有改善空间,甚至知道存在相应的编辑社群能合作处理,然后就转手提删来倒逼其他人“帮手协助”,我不认为这是好情况,可能会变成恶性现象,毕竟现状是问题条目多,处理人员少,某些编辑只需动几下鼠标,就把一堆人拖着键盘来四处奔波,显得自己业务了得。这不应该是理想的编辑合作方式。——Sakamotosan路过围观 | 避免做作,免敬 2022年3月28日 (一) 03:36 (UTC)[回复]
事件本來有更好的處理方式,能從其他語種維基得知關注度的,加上一句和現實相關的內容,讓條目有現實觀點,加一點內容不費幾分鐘。角色對應作品條目存在,或者角色列表存在,存廢提出重定向和合併也是一種恰當的處理。個人認為部分條目的WP:NOTPLOT指控也不合理,如趙靈兒(提刪時,目前版本完善了一些)的和林月如,有提到「影視作品」,角色有現實人物飾演,已經是與現實相關內容,而且也有相關演出的新聞報道,說明這個角色具有關注度(有人關注誰去飾演這個角色)。
直接提刪一大片就像明明通風只需要開窗就能解決的問題,偏偏要提出把房子拆了一樣,關注這些房子的人當然不滿。--Nostalgiacn留言2022年3月28日 (一) 02:42 (UTC)[回复]
一刀切的提刪「僅含虛構作品的劇情內容」條目,就像以「多年來一直無列出來源」為理由提刪德奧合併慕尼黑協定條目。--Mewaqua留言2022年3月28日 (一) 18:39 (UTC)[回复]
提删的应该是「只会有虛構作品的劇情內容」條目,而不是「僅含虛構作品的劇情內容」條目--百無一用是書生 () 2022年3月29日 (二) 02:47 (UTC)[回复]
如果要啟用的話是不是有專門的Category,在裡面應該要看到所有被掛上模板的條目,就像小小作品([[Category:小小作品]])那樣。--中文維基百科20021024留言2022年3月29日 (二) 03:39 (UTC)[回复]
感觉提及的讨论有点混为一谈吧?如果只就“盾之勇者成名錄角色列表 ”案例,本来Wikipedia:关注度 (虚构)Wikipedia:資料頁有相应的如何拆分建立(其中关注度是建议先开讨论,但实际上没人看这一条说明),所以对于这个情况是我建议合并回主条目。对于普遍性问题,有没有必要设修订限期,类似的原没有来源、原创内容等修饰标识都属于同样重要的问题,为什么要为这个主题的修订设立限期?所以我质疑这个规则的必要性。而且复盘了以前的讨论,主要针对Wikipedia:資料頁(包括虚构元素的列表、化学物的性质表等)的定义和处理有了决议。对于这个问题好像并没有提及?——Sakamotosan路过围观 | 避免做作,免敬 2022年3月29日 (二) 04:54 (UTC)[回复]
書生在上面提出一個很重要的指正「『只会有虛構作品的劇情內容』條目,而不是『僅含虛構作品的劇情內容』條目」。「只會有」代表沒有改善的空間,而「僅含」不能排除有可以擴充的空間。
BlackShadowG上面也列出WP:PLOTONLY(「仅关于虚构作品情节的介绍」的連結),雖然不是方針,只是論述,但是目前對相關內容的做法差不多都是按照這個原則。內文建議的做法「按照我们的删除守则,假如条目永远只能小作品,就应易名、合并,或同相关话题重构冲出小作品。三者皆不可行则应删除。」Lopullinen的相關觀點也是來自此,優先的處理方法是合併一類的操作,只有「无望扩充」才到刪除的地步。林月如之類的虛擬角色一再被提刪,保留下來的理由都是有擴充的空間,符合WP:PLOTONLY的「起码要能找到几条来源,证明这一话题受关注。换言之,找不出来源的条目会遭删除」判別方法。
個人認為不如直接讓WP:PLOTONLY變成指引好了,反正判別存留都是這個原則。--Nostalgiacn留言2022年3月29日 (二) 04:56 (UTC)[回复]
可以。--中文維基百科20021024留言2022年3月29日 (二) 05:00 (UTC)[回复]
感觉这是在射箭画靶一样,没有点明出这次大量提删存在的根本问题:是没考虑到这些“仅虚构内容”并不是“只会有虚构内容”,因为相当部分可以被改善的(轻则只需要补充现实影响的描述,重则也可以合并至相应的主体条目或列表条目),但显然地这些提删人似乎知道可以改善却还是大量提请删除(而且就是意见“删除”,而不是类似“合并”之类),我认为这就是游戏规则的问题(删除方针也说过删除前应该考虑改善的处理)。所以暂时不需要扩大讨论范围,现有的机制(例如挂修葺标识提醒,参照NOT,还有资料页、关注度等处理方法去改善)基本上足以应付。——Sakamotosan路过围观 | 避免做作,免敬 2022年3月29日 (二) 06:21 (UTC)[回复]
修改了上文一些描述。認同現有機制可以處理相關問題。另外「限期改善否則提刪」的建議,其實和{{Notability}}沒有什麼區別,最後也是對簿公堂,在存廢頁面給來源證明話題受關注。--Nostalgiacn留言2022年3月29日 (二) 07:50 (UTC)[回复]
如果设立期限,可能也会变成一个“缺陷”:以前SM就是用关注度的方法来这样搞过。所以我认为这与其他类似没来源、原创研究等的问题,既然那些也没有设立期限,这个我也不认为有着同样的迫切性。——Sakamotosan路过围观 | 避免做作,免敬 2022年3月29日 (二) 07:56 (UTC)[回复]
所以说规则是“完美”的,如果有缺陷,那就是人。提报的原则不算是太大的问题,问题是在知道可以改善的情况下,通过大量提报来“强迫”处理,而不是通过提出(既然也知道有相应的社群)让其他用户志愿协助,或者可以选择放着不管。——Sakamotosan路过围观 | 避免做作,免敬 2022年3月29日 (二) 07:59 (UTC)[回复]
如是以箝制為導向下、不認為規則「完美」或應該「完美」之於提報體系範疇,而同時是認為社羣和社區相應必要、根據時下之批量對維基內容具不可逆/不可補救之操作可能濫用,需要一定監管和其他社羣討論等之協作,以遏制相應非建設傾向有惡化之--約克客留言2022年4月3日 (日) 07:06 (UTC)[回复]
PS.请白话化。简单而言,在能改善的情况下,滥用条目(整篇的)删除程序,我不认为是合适的做法。这些情景式写法或者基于编者对作品的理解而产生的虚构元素个体条目(当然一部分是相应的规范比这些条目的存在还要晚出现或者没人留意到)是老焦油坑,清坑是好事,但没能力处理的话,没必要强硬自己去处理,或者使用不友好的编辑手段。——Sakamotosan路过围观 | 避免做作,免敬 2022年4月5日 (二) 08:02 (UTC)[回复]
反過來說,是否可以籍此次論題,探尋適當規勸濫用程序製造非建設積案之手段?畢竟有繼續違背維基協助合作之坑洞,適宜檢討回整個規制修訂之理路實施,可基於現有案例定向拆除有關規限,例如先特定禁制對一切虛構類型條目之批量霹靂提刪活動--約克客留言2022年4月5日 (二) 14:55 (UTC)[回复]
我是认为盲目删除和一味保留都值得讨论。一些条目不宜删除,是因为它的内容对未来编写有用,并不是说这它本身有多好。我认为虚构条目可以分为两类,编辑能执行三种操作:
Green tickY 内容可作为独立条目展示
Red XN 内容不宜作为独立条目展示
(○)保留
保留独立条目资格
(►)重定向
取消独立条目资格,但存留历史记录
(×)删除
删除历史记录
纯剧情条目中有些内容是未来能用到的,这删除历史记录的确不太合适。比如彩女的人物介绍品质很好,这次删除下次就要重写,而且重写都不见得能写到这般好。但是这篇条目本身是有方向性问题的:WP:PLOT明确指出,故事介绍相当于调料,现实影响才是主菜。如果一味保留,无疑会给其他编辑(尤其是新手)带来理念上的错误认知,让他们误以为这不是什么大的问题。这种条目我认为重定向是比较好的处理方式,能明确告知中文维基的编写理念,也不会让有参考价值的内容消失。(当然如果条目介绍的全是阿猫阿狗之类的小NPC,对未来编写合格条目没帮助,那删了也就删了。)
另外关于楼下说的“愛好者內容總比沒有內容好”,这点我认为正好是相反的。过度的爱好者内容一定要及时从条目中移除,千万不要给新编辑模仿的机会!如果放任不管,最终结果就是出现这种中维第一长游戏条目,编辑想动手清理都无能为力。这种条目可能有些好的内容,但保留的微弱好处抵不上错误示范的坏处。有能力清理过度内容的的是粉丝,但堆积这些不当内容的也正是粉丝。模板主要是给编辑看的,但虚构内容编辑不了解作品事很难清理的。有能力清理的是粉丝,而加入不当内容的也是粉丝;重定向倒逼粉丝重写,中间吸引认同维基编写方案的粉丝、劝退不认同维基书写风格的粉丝,我认为反而是一种良方。--洛普利寧 2022年4月5日 (二) 16:32 (UTC)[回复]
新人知道虛擬作品的寫作規範嗎?不如讓他們直接了解相關指引,這樣更好。重定向也不見得能解決這個問題,因為他們不一定知道正確寫法是怎樣的。--中文維基百科20021024留言2022年4月5日 (二) 17:04 (UTC)[回复]
新人不知道虚拟作品的写作规范,所以他们会模仿现有条目。将有问题的条目重定向,让他们看不到错误范本,或者看到错误范本的结局是重定向,这样的确能解决很多问题。而且有些新人你给他说了他听不懂(或者不理你),继续自己干自己的。这种时候要想说服他们,基本只能亲自动手重写。他们写的内容往往只能让粉丝看懂,但我不可能熟悉每个游戏,贸然修改可能会有细节错误,然后会被他喷一顿。这样想劝他们了解指引就更难了。(没错,我是被呛过好几次)而且你举写作规范,他就能举出劣质内容被保留,这让人怎么说?另外我这几年的新游戏角色列表都有在看,只见劣质列表数量和比例都是双双向上。可见保留没有让虚构内容越来越好。--洛普利寧 2022年4月5日 (二) 17:19 (UTC)[回复]
我只支持沒有潛力擴充的小人物重定向,至於比較知名的,從英文那邊把相關內容拿過來就行。遊戲角色列表和小人物本身靠通用關注度就能刪除或重定向。不過對於讓人如何用現實角度去寫虛擬人物也確實是一個不能忽視的問題。--中文維基百科20021024留言2022年4月5日 (二) 17:41 (UTC)[回复]
WP:PLOT云,「维基百科采用百科全书的方式描述具有关注度的虚构作品,介绍它们的受欢迎程度和它们的意义」。条目不管有没有关注度,不写现实世界内容就是“没有介绍它们的受欢迎程度和它们的意义”。“仅关于虚构作品情节的介绍”和“仅关于作品的现实世界介绍”都是内容缺失,但WP:NOT特别列出前者。这说明虚构条目没有现实内容是个严重的问题。
正如我开始所说,现在的问题就是条目实际品质问题,而不是发展可能性问题。中维虚构角色条目很多时候都轮不到谈关注度:把现实内容写出来条目,自然能证明有关注度;不写出现实内容,无论角色多知名条目都有严重问题;至于没有关注度,你也写不出现实内容。您轻描淡写的“從英文那邊把相關內容拿過來就行”正是现在的实际问题。如果在AfD投个保留就能自动让条目变好,我相信我比在座大部分编辑投保留都积极 维基百科:只有情节介绍的虚构作品条目说的是「假如条目永远只能小作品就重定向」,而不是“凡条目可能超过小作品,无论品质多差皆不得重定向”。该文的主旨是“虛構類條目不應止於情節介紹”,而不是“只写剧情问题也不大”。按照中文维基的状况,一味保留只会得到相反结果:编辑更加不会写现实内容。
删除能警示编者,但会失去一些比较好的内容记录,这不是一个好操作。重定向能警示编者,没有删除历史记录的副作用,扩充完可以随时恢复显示,这样我认为是最平衡的。至于保留,说“条目有严重问题,这次先放一马,要求尽快改善”也行,定了个调子我后面还有个话说。现在一些保留票像是“你可以扩充,但这不是多大问题,不扩条目品质也不差”,这让人怎么解释?--洛普利寧 2022年4月5日 (二) 19:03 (UTC)[回复]
所以到頭來還是沒有補救方案嗎?不見得不斷加高製造更多壁壘可以推進改寫和衡平之類的方向,現實問題就是這種武斷採用規限手段的事務本身就背離了友善互助之維基社區原處位置,已經是在不斷製造新矛盾而且更加難以吸引新手或者其他可能貢獻的羣體注入動力。歸根結底,要具有積極意義之衡平良策,首先必須打破審查標準極化導致之嚴苛編輯評審體系,不得強硬一統化邏輯不斷地壓縮其他共識空間,反過來需要重新鼓勵回依托不同編輯和背景理解相互補正之互惠方式、促使溝通不同編輯貢獻維基社區--約克客留言2022年4月6日 (三) 04:38 (UTC)[回复]
BlackShadowG的問題明明就是批量提刪大量條目,誰救得過來,這個問題不提,在指引那邊兜圈子,如果他只是提刪一兩個我也會從英文那邊搬東西過來。--中文維基百科20021024留言2022年4月6日 (三) 04:49 (UTC)[回复]
真把这个视为我的“问题”倒是有趣了,那我现在起每天就提删几个,问题就能解决了?纯剧情角色条目问题长期累积,总条目数量乐观估计也有600+,不从方针层面批量清理,这类条目只会越积越多,后续的编者也会继续参考这种写作模式,对中维带来很多的负面影响。--BlackShadowG留言2022年4月6日 (三) 05:22 (UTC)[回复]
如果真是每天能改善几个算几个,问题严重的直接走合并和重定向。这不就解决了问题?我认为你只是偷懒又想显摆罢了。——Sakamotosan路过围观 | 避免做作,免敬 2022年4月7日 (四) 01:15 (UTC)[回复]
如果仅仅是强调可以改善而不去改善而保留,这不是好的编辑风格(例如一堆关注度提删时挂一些链接就算了,好歹匹配内容写到条目中啊)。如果能被改善而且确实改善了,这才是好的编辑风格。有些编辑人不干事(摆烂不管)就算了,还干不人事(某些看上去像删除派、说起话像删除派,办起事来像像删除派的),那就不是好事情。——Sakamotosan路过围观 | 避免做作,免敬 2022年4月7日 (四) 01:28 (UTC)[回复]
规则的话,现有的Wikipedia:关注度 (虚构)Wikipedia:資料頁应该足够避免不合适的增量问题(这可能需要新巡查和资深编辑去“阻挡”),现有存量的话,既然能(理论上)阻止到增量,那存量只要不摆烂,还是能慢慢清下来,我看不出这样严重性的问题。——Sakamotosan路过围观 | 避免做作,免敬 2022年4月7日 (四) 01:34 (UTC)[回复]
另外写出一堆需要最后用不到的内容真不如不写。别忘了清理内容也是需要时间的。--洛普利寧 2022年4月5日 (二) 17:22 (UTC)[回复]
認為閣下單獨列舉如是,最好再斟酌一下補充衡平論述,重複單一傾向對於解決官僚化問題可能沒有意義--約克客留言2022年4月6日 (三) 04:41 (UTC)[回复]
首先容我强调,按照WP:PLOTWP:VG/ROLE的要求,大部分电子游戏虚构列表的品质不足以作为独立条目给读者展示。保留是情分,处理才是本分。
至于要清理的条目,比如英雄傳說 軌跡系列角色列表,清理需要实现“虚构内容长度在现实世界内容长度两倍左右以内”,并确保内容聚焦主线剧情。清理者必须同时熟悉编写方案和作品内容,而这样的编辑是很稀有的。只熟悉编写方案的编辑(比如我)无法分辨主线内容,不知道该清理哪些文字。非要清理也不是不行,硬着头皮玩上一百小时不喜欢的游戏便是,但有这时间清理其他条目不好吗?只熟悉作品的编辑(粉丝)……这些不合适内容的不就是他们写的吗?这不是掌握通用清理准则就能解决的事情。保留等待其他编辑改写,九成以上等于没人改写。
但是这篇条目如果今天不处理,明天就会更难清理,后天则会有更多类似的条目涌现;这就一种恶性循环。在改善条目无法落实的情况下,重定向是避免情况继续恶化的最好方法。读者来维基百科是看现实世界内容的,想看剧情的编辑应当去其他网站。大量爱好者内容只会显得我们是粉丝向网站而非综合百科。这种条目应该回归本源,不给读者呈现。另一方面,粉丝知道作品内容,只是不熟悉/不重视编写方案。通过重定向引发他对编写规则的重视,让他自己收拾自己的坑,我认为是最好的。
我巡查电子游戏新条目多年,虚构列表什么水平还是清楚的。最近又把角色列表看了一遍。不是我官僚化,我一条一条分析,得出的结论就是大部分条目的确“不适合独立开条”。
上面都是方向性的问题,至于实际看法:
  1. 没有现实内容只是缺失,不需要额外返工。粉丝内容需要清理,一增一删浪费两份人力。后者应该积极处理,这也是我一直强调的;前者不用太着急。
  2. 至少处理品质最差的一批条目,明确表示中文维基关注虚构内容品质。以后给其他编辑讲解时也能举出例子。
  3. 游戏领域角色条目(不是角色列表)多是现实内容缺失问题,需要清理的内容不多,这种条目就算被模仿也不难处理。关键还是整改角色列表。
  4. 清理内容时给编辑留言说明,编者大多是可以理解的。说不定还能把他发展成优秀的活跃编辑者。
  5. 以上内容主要针对角色列表。好吧我跑题了。
--洛普利寧 2022年4月6日 (三) 14:19 (UTC)[回复]
有改善空間的條目可不刪除,的確應該留下餘地讓人改善。但那些只有幾千字數冗贅劇情細節甚至是趣聞之類的東西在有人改善之前或可直接先行全部砍掉,只讓條目留下基本的資料。這樣在有人改善之前不會有過度佔比虛構/愛好者內容,同時留下個基礎讓人可以擴充 Iridium(IX) 2022年3月29日 (二) 16:15 (UTC)[回复]
這方面我是保留派。如果沒有人來改劇情介紹,愛好者內容總比沒有內容好。--Temp3600留言2022年3月31日 (四) 11:22 (UTC)[回复]
‘只讓條目留下基本的資料’與沒有內容分別頗大,沒有內容的話倒不如刪除
內容少自然不是一件正面的事,但至少不會反過來產生些害處,可冗贅愛好者內容就是後者
不刪除條目不是問題,但如果連冗贅愛好者內容也不允許刪除實在是有點過分--Iridium(IX) 2022年3月31日 (四) 13:08 (UTC)[回复]
認為Iridium閣下最好應該自行收回有關所謂過分的說法,並建議Iridium閣下和其他可能同一有清理過往貢獻之內容和共識之編輯,可以認真重新閱讀本案所指出之:可謂日益嚴重之強制擴大使用政策之批量重洗,是否應當得到適當限制之?本地有關一些「批量重洗工程」是對維基本地活動之重大重塑,如無特別框架等適度監管之、恐進一步壓制百科內容之發展,認為社羣應適當提案或討論等之而密切跟進,防止可能濫用政策與關聯活動等之進一步不當影響--約克客留言2022年4月3日 (日) 07:01 (UTC)[回复]
@Longway22 acg專題本來我就沒有關注,只有一次刪減過些愛好者內容,亦從沒做過任何所謂清理的行動,更從來沒支持過什麼‘日益嚴重之強制擴大使用政策之批量重洗’或‘批量重洗工程’。
本案談的是批量刪除條目,強行刪除有可能改善的條目連寫也不能寫自然‘壓制百科內容之發展’,不刪除條目而只刪除有害的冗贅愛好者內容如何‘壓制百科內容之發展’?現在是不允許你重新拓寫條目基本部分增補有益內容,還是如何?冗贅愛好者內容不適合維基也容易夾藏愛好者原創內容的問題顯而易見,你找一個幾萬字的角色列表條目大多也能發現這個問題,什麼叫濫用政策?無需要的刪除卻強行說是政策允許算是濫用政策,刪除冗贅幾萬字劇情如何叫做濫用政策?我連行動也沒行動過,你如何聯想出以上一堆與我所說東西無關的東西?
‘冗贅愛好者內容也不允許刪除實在是有點過分’這句話是有什麼問題?廣泛讀者需要這些冗贅愛好者內容?強行保留如何不是過分?看你說話一本正經之來之去,希望你能說出些更有意義的話來--Iridium(IX) 2022年4月3日 (日) 12:22 (UTC)[回复]
首先對於本編可能有定性先設之措辭表示一定歉意,希理解有關脈絡之於當前、即如Cwek閣下等上所言近似於「大拆房子」之,即函需垂注無建設可言之事幹——如理解不妥還望指正。另閣下如再自審提論、有無同樣定性先設之?如閣下鮮有涉獵關聯專案、何以立即取「有害」或非主流等之為專案處理之定奪先行?若是以取採同上提舉等先斬而後快、罔顧處理協作等繁務,恐更無助於打理專案後續。
如欲辨所謂冗贅否,非適一張大刀數門戶落地,宜遵單獨個案視之、並保證留備協作編輯於閒時空暇,以持久友善支援之議理、拔除妨擾之壁壘,方可續之而定後著--約克客留言2022年4月3日 (日) 13:00 (UTC)[回复]
我雖不太參與這專題,但自有對其觀察。愛好者內容的問題不乏討論,指引裡也有略談。愛好者內容本帶貶義,一段精簡準確闡述劇情大意、過程、結果的段落自然不會與愛好者內容拉上關係。至於具建設性與否和其意義,你可以去問問WP:OR、WP:NOT或WP:WEIGHT
我本沒說過要不分皂白全部刪除,是否冗贅編者自有判斷。愛好者內容的辨別對有點經驗的編者而言本來就顯而易見,不構成所謂的‘定奪先行’,麻煩往往只是在後續處理的問題。除非編者有意針對,不然編輯條目自然是各個單獨判斷。一篇遊戲角色如果評價部分的內容仍然全是對角色虛構層面強度或玩法的評價,對愛好者以外並完全沒有存在意義,與其留下加劇失衡不如直接砍掉。虛構劇情相對棘手,但如果是如不少角色列表裡面有綜述段落和‘各分集劇情’,前者乃必須,後者也明顯可先直接砍掉留下前者慢慢改善。如果某一大段的愛好者內容中混了組成條目的必須部分,那的確不宜直接砍除而只能等待相關編者刪減
所謂「大拆房子」,如果結構基礎早已崩壞,那留下除了構成危險外對重建毫無幫助,倒不如先完全拆除讓出空間重建。這完全並不妨礙後續條目的改善
另外你的文字越發難以解讀,請你用更為白話的方式不然有礙溝通--Iridium(IX) 2022年4月3日 (日) 15:29 (UTC)[回复]
感謝回覆,不過基於文書提法之特點、本編傾向恰恰相反,是需要避免一些所謂現有話語之制限、以鮮明指出現階段部分環境下,包括採用不合比例之霹靂手段到表面可能多數暴力等種種、都是本地急需規制之取向,否則難以容許社區繼續談論可持續之改善和發展之共識。--約克客留言2022年4月5日 (二) 14:49 (UTC)[回复]
那這番話的對象不應該是我,請你另找人討論--Iridium(IX) 2022年4月8日 (五) 11:59 (UTC)[回复]

不知道回應哪裡,所以分段。既然有人提出「保留等待其他编辑改写,九成以上等于没人改写」的觀點,回顧一下近期角色存廢導致條目改善情況,2月的時候Newbamboo 同樣以「純粹愛好者內容」提刪亞絲娜桐人,後來他自己完善了條目。3月那一批提刪(詳情請見對應條目的編輯歷史記錄),羅潔塔林月如乌苏拉基拉·大和伏地魔卢克·天行者趙靈兒等獲得了完善。「誰有空去寫」的詰問,提刪的時候,真的能吸引到一點人去寫。說到底「编辑是志愿性质」,有意向完善的人是少,但不至於沒有。每個人每天就只有24小時,又不是住在維基百科不用工作學習,很多時候心有餘而力不足,大多是「只是提刪一兩個我也會從英文那邊搬東西過來」的程度。

題外話,其實有维基百科:条目质量提升计划,不過該計劃水靜河飛。--Nostalgiacn留言2022年4月8日 (五) 10:21 (UTC)[回复]

也可能還是設定可以再優化吧,看看流程甚麼的似乎比較繁瑣,按現在檢討包括之前一些評審條目問題,到這個提刪機制的話應該可以相互再補充一些優劣部分,認為是可以按照上面本編原提出的集中處理方向,還有部分所謂「清理工作」分擔過來(應該是要砍掉一些不必要「清算」任務的說),重整化作聯繫小眾和專門科類計劃的新版面,嘗試吸引不同編輯多關注不同課類或許比簡單設定獎罰目標更具意義--約克客留言2022年4月10日 (日) 09:56 (UTC)[回复]

提议Wikipedia:格式手册/虚构成为正式指引

该论述近期已依据英维现行版本进行修订,让我们帮助它成为正式指引!--Taeas留言2022年3月25日 (五) 15:31 (UTC)[回复]

笑死了,维基百科并不隐藏、避免或努力在情节摘要或类似材料中标记破坏者,但破坏者只应在提供完整的情节以达到百科全书式的目的时才被列入,要不我们来探讨一下这个破坏者是什么呢?--MilkyDefer 2022年3月25日 (五) 16:51 (UTC)[回复]
同MilkyDefer,在改善好語文部分前程序性(-)反对。--路西法人𖤐 2022年3月26日 (六) 02:13 (UTC)[回复]
@MilkyDefer @LuciferianThomas 已将“破坏者”修改为“剧透内容”--Taeas留言2022年3月26日 (六) 03:04 (UTC)[回复]
粗看了一下,好像留意到一些怪异的术语,不知道是不是翻译有问题。另外有部分没必要的着重号,视乎在刻意地模仿en的行文,这些行文是否具有必要性?先暂时(-)反对。——Sakamotosan路过围观 | 避免做作,免敬 2022年3月26日 (六) 03:12 (UTC)[回复]
再补充,里面有一些链接到当地的指引等规则的页面,但在本地的可能是还没有进行规则化(或者还处于草稿或者不健全的),可能会导致执行起来会无规则可依或者会被扩大解释。而且仅仅靠屏蔽这些链接也不是好方法,也就是影响引用这些链接的条目的合规性。——Sakamotosan路过围观 | 避免做作,免敬 2022年3月26日 (六) 03:50 (UTC)[回复]
这类页面可以点出来,顺带一起修订。--Taeas留言2022年3月26日 (六) 03:53 (UTC)[回复]
例如:Wikipedia:格式手冊/瑣碎章節Wikipedia:条目长度Wikipedia:格式手册/列表(只有部分章节性指引)、Wikipedia:日本動漫遊戲條目指導(这个也具有指引化的潜质,但是同样也是面对同样的问题)。——Sakamotosan路过围观 | 避免做作,免敬 2022年3月26日 (六) 15:36 (UTC)[回复]
翻译可能有点问题,不过最好能将“怪异的术语”点出来。--Taeas留言2022年3月26日 (六) 03:15 (UTC)[回复]
另外,考虑到最近所发生的各种翻旧账行为,虽然这个草案的想法是很好的,但我担心这会成为鸡毛令牌,有可能完全打破现有编辑平衡(旧账愿意管才处理,新问题尽量能避免则应该避免)。——Sakamotosan路过围观 | 避免做作,免敬 2022年3月26日 (六) 03:37 (UTC)[回复]
这方面的担忧并非没有道理,不过我认为向前看还是很有必要的。--Taeas留言2022年3月26日 (六) 03:48 (UTC)[回复]
如果基于令条目质量得以冲评价的话,是有好处的。但是基于现状的话(人手、该类条目的普遍质量、编辑的普遍编写风格),把这些弄成白纸黑字就不一定是好事。或者我的想法为:为好的编写内容用规则来背书,而不是利用规则扣字眼般来地清理旧账。尤其是某些急行军一样地彰显业务了得的编辑。——Sakamotosan路过围观 | 避免做作,免敬 2022年3月26日 (六) 04:06 (UTC)[回复]
是有可能被用于清理旧账,但它对新条目的规范作用也是巨大的。--Taeas留言2022年3月26日 (六) 04:13 (UTC)[回复]
有个概念是祖父条款,按照这里的意义就是规范新条目的格式,鼓励旧条目向这个方向靠拢但不应作为删除理据。--MilkyDefer 2022年3月26日 (六) 04:18 (UTC)[回复]
这是个不错的想法,不过旧条目如何界定或许需要探讨一下。--Taeas留言2022年3月26日 (六) 04:29 (UTC)[回复]
规则问题不大,问题是有些编辑拿着“鸡毛”用这种压迫性的方式来驱使其他编辑去跟着他们的屁股去收拾残局,而没考虑过方针存在弹性的考虑或者自己尝试去改善,Wikipedia:维基百科并不需要你真的很适合他们,按照现状,“摆烂”才是常见状态,做大刀阔斧的“卫道士”不一定有益处。——Sakamotosan路过围观 | 避免做作,免敬 2022年3月26日 (六) 09:03 (UTC)[回复]
我认为直接点出如何才能让提案通过的可能性较大会更好一些。--Taeas留言2022年3月26日 (六) 15:02 (UTC)[回复]
我觉得更像是:这个指引(草案)对于改善条目质量(例如用于评级)是有好处的,但不想将它变成给某些固执的编辑递刀子。——Sakamotosan路过围观 | 避免做作,免敬 2022年3月26日 (六) 15:39 (UTC)[回复]
怎样才不算是递刀子?另外,一些编辑的做法在程序上是没有问题的。--Taeas留言2022年3月26日 (六) 15:46 (UTC)[回复]
如果不是没问题,为什么会引起其他一些编辑的反感,甚至被拉到编辑争议版上?而且这个指引草稿存在了多年,为什么突然被拉出来讨论了?规则没问题,问题是如何和怎样去使用规则。——Sakamotosan路过围观 | 避免做作,免敬 2022年3月26日 (六) 15:53 (UTC)[回复]
1.程序和一些人的主观是存在差异的。2.“存在了多年”而未成为正式指引即可成为理由。
如果愿意探讨“如何和怎样去使用规则”,我想这对提案的帮助远大于以上内容。--Taeas留言2022年3月26日 (六) 16:27 (UTC)[回复]
上次一天之內說幾十個條目是fans所以要移動到維基學院是你吧?你和BlackShadowG偶爾提一兩個是沒問題,提幾十個就是有問題,讓「改善條目」這條道路被堵死。--中文維基百科20021024留言2022年3月27日 (日) 06:07 (UTC)[回复]
甚至,BlackShadowG提刪伏地魔的時候竟然在編輯摘要說了一聲「可惜」,自己都覺得可惜還提刪,不知道你們怎麼想的。--中文維基百科20021024留言2022年3月27日 (日) 06:09 (UTC)[回复]
BlackShadowG有空去提刪怎麼不去完善自己曾經寫的半成品呢?BlackShadowG 3月初創建的俄乌战争期间对乌克兰的援助列表有大量英文未翻譯就直接發佈,幸虧被AINH發現退回到草稿,3月24日才被Yinyue200重新完善。該做的不做,提刪倒是很起勁。--中文維基百科20021024留言2022年3月27日 (日) 06:14 (UTC)[回复]
甚至BlackShadowG是知道有电子游戏群组的存在,完全可以提出来,让人逐点清理,而不是一股脑地提删。——Sakamotosan路过围观 | 避免做作,免敬 2022年3月27日 (日) 06:18 (UTC)[回复]
我觉得“可惜”是这个条目能写很多现实内容,现在写成纯剧情违反方针还得提删才觉得“可惜”。
把我以前写的条目拿来指责我是更想不到的,我3月初创建的俄乌战争期间对乌克兰的援助列表本来想一个晚上全部翻译完的,但由于现实生活中的一些缘故没能翻完,第二天向继续翻译时发现已经被AINH移动到草稿了。那时英文维基百科的条目本来也很不稳定,当时我就想既然已经被移动到草稿了,不如等英文条目稳定了再来翻译,就去翻译另一篇GA去了。这还能被人说是“该做的不做”更是令人想不到的。--BlackShadowG留言2022年3月28日 (一) 02:55 (UTC)[回复]
“规则”是“完美”的,如果有缺陷,那就是人。鉴于最近的事件,这就是缺陷所在。——Sakamotosan路过围观 | 避免做作,免敬 2022年3月27日 (日) 06:18 (UTC)[回复]
中維不是英文維基百科中文版,雖然很多都這樣做。個人對相關內容甚至連例子都照搬感到不解,「《巨蟒与圣杯》中有一些笑话和短语已经进入了流行语」,「例如,不要写『现在是公元34,500年,特朗托里亚帝国大约涵盖了半个银河系』,而要写『《空间的潮流》的背景是公元34,500年,特朗托里亚帝国大约涵盖了半个银河系』」,請改為中文使用者更容易理解的例子,謝謝。如英維的天是藍的(Wikipedia:You don't need to cite that the sky is blue),中維是维基百科:孙中山是男性无须引用
不明就裡的例子,看完之後反而更困惑。此外中維也有相當數量的GA和FA條目可以作為具體條目類型的例子,英維有舉出,中維的如何不舉出??--Nostalgiacn留言2022年3月26日 (六) 05:13 (UTC)[回复]
已更改,确保所举例子在中维皆有条目。--Taeas留言2022年3月26日 (六) 06:42 (UTC)[回复]
非原生中文作品的,大部分都有地區詞。此外,改為一些原生中文作品的例子真的很難嗎?--Nostalgiacn留言2022年3月26日 (六) 07:05 (UTC)[回复]
不难,但是使用非原生中文作品的例子对阐述指引观点并无影响。且,大部分影视类GA/FA条目为非原生中文作品。如,《E.T.外星人》为FA条目。--Taeas留言2022年3月26日 (六) 07:16 (UTC)[回复]

增補條文

這是在提刪FAIRY TAIL相關角色列表時想到的問題(這一串),當一部作品的角色列表多於一個時,無益於讀者查詢特定角色,當讀者要在某個列表內用搜尋的方式查特定角色,但那個角色被拆分到另一個角色列表時,就會找不到。以這個例子而言,要查之前還得先知道要查的對象是哪個公會的,可謂本末倒置。想到的解決方案有二(可同時施行)。其一,是允許一個作品有多個角色列表,並將該作品的所有角色(或主要角色)都建重定向至相應的列表(例如Category:犬夜叉角色重定向),但這麼做的話會產生大量重定向,維護不易,我也不打算這麼做(但也不反對);第二個方案,是我想要提議成為格式手冊的內容,一部作品只能有一個角色列表(當然可能會視特殊情況例外),如此一來可以減少某些長篇大作角色列表過於冗長繁雜的問題(附)、減少FANPOV的問題(目前多於一條列表的大多都FASPOV)、併成一條也易於讀者搜尋。 附:以死火海來說,各有各個問題

(&)建議第二个方案的“特殊情况”可能需要明确一下--Taeas留言2022年4月9日 (六) 03:46 (UTC)[回复]
就是等施行後有爭議再討論的意思。-KRF留言2022年4月9日 (六) 06:17 (UTC)[回复]
個人認為出現那麼多列表,原因是條目太長(WP:SIZE),符合ACGN的資料頁拆分標準,拆分出來的列表不斷變長,又因為條目太長(WP:SIZE)而被更細緻地拆分。--Nostalgiacn留言2022年4月9日 (六) 06:49 (UTC)[回复]

根据 Kerolf666 的提议,建议在Wikipedia:格式手册/虚构中增补以下条文

現行條文

(无)

提議條文

关于虚构作品角色列表 當一部作品的角色列表多於一個時,無益於讀者查詢特定角色。因此,一部作品只能有一個角色列表。

-Taeas留言2022年4月9日 (六) 07:07 (UTC)[回复]

不知道為何我的上面回覆會被刪掉,另外Wikipedia:格式手册/虚构本身都沒有達成共識,建議再完善全部內容後再次提交。對於增補內容個人持(-)反对態度。
只有符合規範,有足夠關注度和內容是可以拆分,隔壁英維的{{星際大戰宇宙}}已經是明證。--Nostalgiacn留言2022年4月9日 (六) 08:06 (UTC)[回复]
(-)反对一百单八将要併入水滸傳角色列表金陵十二钗要併入红楼梦人物列表?--Mewaqua留言2022年4月9日 (六) 10:49 (UTC)[回复]
現在水滸傳角色列表就實質上包含那108人,就算要合併我也不覺得有什麼問題。至於十二釵的條目,更像是介紹那個名單以及對名單整體的評價,整體結構和我上述的例子截然不同。-KRF留言2022年4月9日 (六) 17:20 (UTC)[回复]
(-)反对。「當一部作品的角色列表多於一個時,無益於讀者查詢特定角色」完全沒有任何意義,且邏輯十分詭異。讀者不會「找不到」特定角色Wikipedia:导航模板了解一下。照你的邏輯,為了避免「讀者找不到主題」所以是不是乾脆把維基百科一百四十一萬一千六百五十四篇條目全部(±)合併成一個就好?以免「讀者找不到特定題目」??你的這個邏輯實在詭異的離譜。當章節重定向导航模板是裝飾用的????-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️2022年4月9日 (六) 14:23 (UTC)[回复]
用導航模板處理的話,把角色都放進去,死火海的尺寸大概會是Template:三国演义的三倍大,確定這麼做沒問題?-KRF留言2022年4月9日 (六) 17:20 (UTC)[回复]
我覺得問題是在於應該要按角色的性質作分類,而不是按角色出現的回數,卷數,哪個系列分割。--Ghren🐦🕙 2022年4月9日 (六) 14:56 (UTC)[回复]
(-)反对,該修正案是徒增新審查編輯的口實,依現維基實際運轉之弊未見衡平下,如再為編輯增加該種「指示」執行,後效可更不堪設想。

再次审阅

欢迎对现版本Wikipedia:格式手册/虚构提出意见,以帮助其指引化。--Taeas留言2022年4月11日 (一) 14:52 (UTC)[回复]

“硕士学位论文通常未经类似评估,因此不如博士学位论文可靠,除非其具有显著学术影响。”改为“硕士学位论文通常未经类似评估,因此通常不如博士学位论文可靠。”-Fire Ice 2022年3月26日 (六) 16:50 (UTC)[回复]

提議將Wikipedia:过度分类包含主觀性的標準一節定為指引。

本節內容符合中文維基百科存廢討論的共識(見條文之例子),將其定為指引可供編者參考。--【和平至上】💬 2022年3月26日 (六) 17:32 (UTC)[回复]

行。—— Eric Liu 創造は生命(留言留名學生會 2022年3月27日 (日) 19:41 (UTC)[回复]
你那是可能违反cat,和这个主观有啥关系。Fire Ice 2022年3月28日 (一) 04:42 (UTC)[回复]
對閣下的理據感到費解。你那個例子明明是因為WP:CAT所以被反覆回退,跟這裏的主觀性有何關係?如果你是指條文裏對中立性的要求,那麼你應該提請修改WP:NPOV以及WP:CAT,因為這一章節根本對你所舉的例子沒有任何影響。基於閣下言辭中欠缺積極參與討論的態度(「明顯缺乏常識的你維明顯沒法判定何謂主觀」),以及你所舉的例子根本與本提案無關,我認為閣下的觀點並非有效的反對意見。--【和平至上】💬 2022年4月2日 (六) 12:22 (UTC)[回复]
支持。--东风留言2022年4月4日 (一) 15:55 (UTC)[回复]
(+)支持,我觉得提议条文应该已经算是常识了。--BlackShadowG留言2022年4月7日 (四) 12:31 (UTC)[回复]

再议设立删除员

第一次设立删除员的建议出现在2019年。当时的反对意见概括如下:一、删除需要管理员的核心能力,因此删除员门槛不应低于管理员。(Antigng)二、afd、drv积压的原因是讨论不充分,而不是管理员不勤奋。(Techyan)三、“会使得条目删除和其他诸如封禁用户之类的站务维护相脱节”。(Techyan)

第二次设立删除员的讨论出现在2021年。当时的反对意见概括如下:一、删除需要管理员的核心能力,因此删除员门槛不应低于管理员。(Antigng)二、“如果是因为选管理员的问题,那么应该去想办法解决管理员难选的问题”。(shizhao,安忆)三、afd、drv积压也没问题,不用专门设立删除员处理积压。(Googol19980904)

如我概括的反对意见有所遗漏,欢迎补充。我认为:一、由于rfa困难,且目前来看难以改善,二、降低afd和drv积压是有必要的,因为长久挂着afd和drv板不是个事,中文维基百科应当设立删除员。最低要求可以等同管理员,但不应成为另一个rfa,有效票要求应当降低。此外除权门槛应当降低,可以考虑30%至50%同意即可除权,即相当于设立一个高风险的专于删除的管理员职位。

前次讨论结果在WP:删除员,欢迎继续讨论!--Fire Ice 2022年3月27日 (日) 17:58 (UTC)[回复]

如果一定要設立,選舉模式和有效票應該和管理員應該一樣,可以考虑30%至50%同意即可除权,而且必須曾經多次參與過afd和drv討論才行,而且每天像機器人一樣將Wikipedia:关注度/提报中的條目提交至afd的人不算。--中文維基百科20021024留言2022年3月27日 (日) 18:09 (UTC)[回复]
而且還要考慮一個問題,刪除員萬一偷偷刪除不經過討論也沒有被提交至快速刪除的條目怎麼辦?或者刪除員不想呆在維基了,臨走前一天刪除個幾百、幾千個條目也是可以的、雖然理論上這些情況可以提出罷免或者走drv。所以這樣考慮下來刪除員不見得重要性就不如管理員。--中文維基百科20021024留言2022年3月27日 (日) 18:14 (UTC)[回复]
技术上能否设置删除限额?比如一天内不能删多于十个条目之类。Fire Ice 2022年3月27日 (日) 18:16 (UTC)[回复]
這個可以,而且要刪也是優先刪沒人有異議的條目。--中文維基百科20021024留言2022年3月27日 (日) 18:21 (UTC)[回复]
另外telegram有人提議刪除員不能删除「未提删的條目」,自己不能删除「自己提删的條目」,不知技術上是否能實現。--中文維基百科20021024留言2022年3月27日 (日) 18:28 (UTC)[回复]
無法實現。--Xiplus#Talk 2022年3月28日 (一) 07:42 (UTC)[回复]
這是有多不信任刪除員。以政策規定即可。--Ghren🐦🕓 2022年3月28日 (一) 08:34 (UTC)[回复]
「刪除員不想呆在維基了,臨走前一天刪除個幾百、幾千個條目也是可以的、雖然理論上這些情況可以提出罷免或者走drv」
I mean the same thing could be said with admin?-某人 2022年3月27日 (日) 18:27 (UTC)[回复]
是的,所以說刪除員重要性不亞於管理員。--中文維基百科20021024留言2022年3月27日 (日) 18:29 (UTC)[回复]
1.建議直接報告到meta.wikimedia.org申請全域鎖定
2.建議在meta.wikimedia.org申請恢復被破壞的內容--Rastinition留言2022年3月28日 (一) 04:54 (UTC)[回复]
「由於rfa困難,且目前來看難以改善」,都不去討論管理員選舉改革,怎麼有可能改善?社群甚至連一個安全投票的暫行規定都討論不出來,盡想著繞道,設立各種「有限度的管理員」;然而刪除或封鎖等都是管理員的核心技能,即使捨本逐末地將這其中某幾項權限分拆出來,也相當於五分之四個管理員了,我不認為可以就此特別降低遴選標準,至少相對於管理員而言。為什麼不好好討論一下如何適度調整管理員的遴選標準,或檢討一下社群在心理上對其過於「完美」的要求?—— Eric Liu 創造は生命(留言留名學生會 2022年3月27日 (日) 19:25 (UTC)[回复]
我这一段时间一直在处理存废,就我的观察,造成积压的主要原因不是关闭存废的人手不足,而是讨论不充分造成无法及时关闭讨论。所以即使有大量删除员,情况也并不会有什么改善--百無一用是書生 () 2022年3月29日 (二) 02:54 (UTC)[回复]
就怕删除员不看是否充分討論而是看自己的喜好選擇是否刪除條目,這種不合格的刪除員寧願不要。--中文維基百科20021024留言2022年3月29日 (二) 03:15 (UTC)[回复]
我的观察,恰恰和您相反:造成积压的主要原因不是讨论不充分,而是管理员缺乏决断。到现在,管理员关掉的许多存废讨论也很长时间没有新讨论了,那么为什么不能早点关掉呢?--Fire Ice 2022年4月7日 (四) 14:13 (UTC)[回复]
(+)支持设立删除员,如果担心删除员的操作有争议可以设立公示制,删除员必须公示3天后删除。还应该设立保护员,规定保护员只能保护自己未涉入编辑争议的页面,保护员可以设定或解除全保护但不能编辑全保护页面。另可参考V:WV:看守員,设立准管理员。桐生ここ[讨论] 2022年3月29日 (二) 08:09 (UTC)[回复]
如果有條目要淪落到公示才能刪除,那實際上管理員早就已經刪除了。--中文維基百科20021024留言2022年3月29日 (二) 08:30 (UTC)[回复]
不支持将管理员的权限拆分成多个用户组,与其这样,还不如多关注一下管理员选举怎么改革(这个议题OA时讨论几天后又没声音了,看来社群也没想修这个机制)。--BlackShadowG留言2022年3月29日 (二) 08:35 (UTC)[回复]
“与其……不如……”是你维很多人反对某项改良的经典句式。那么“不如”不如不起来怎么办?只好把手一摊:都怪社群不努力!--Fire Ice 2022年4月7日 (四) 14:10 (UTC)[回复]
仍不认为此举有助于改良,鄙人比较认同shizhao所说的“造成积压的主要原因不是关闭存废的人手不足,而是讨论不充分造成无法及时关闭讨论”,此外,据上方讨论,社群对删除员的要求似乎不会比管理员低太多,不太认为这个用户组能带来改善。--BlackShadowG留言2022年4月8日 (五) 11:01 (UTC)[回复]
只在技術上提出一個可能性。在這個基礎上新增一條快速刪除方針,當刪除員掛上這個快速刪除模板的時候,就可以刪除,然後寫個過濾器阻止一般用戶加上這個快速刪除模板。這樣的話可以做一個「只刪除」的偽用戶組。--Ghren🐦🕙 2022年4月7日 (四) 14:48 (UTC)[回复]
這倒是跟萌娘百科的巡查員有點像。—— Eric Liu 創造は生命(留言留名學生會 2022年4月7日 (四) 16:30 (UTC)[回复]

註:此處原有文字,因為DENY,已由西2022年4月5日 (二) 18:32 (UTC)刪除,尚祈見諒。若有異議請至互助客棧或向管理員反映。[回复]

关于中华民国籍香港居民

1949年前在内地出生的中华民国国民,在1949年前移居香港后,如果没有主动办理丧失手续,至今是否依然拥有中华民国国籍?如果是,是否意味着这些人既是中华人民共和国藉香港永久居民,又是中华民国国民?也就是说可以同时使用Wikipedia:格式手册/两岸四地用语的制定样式5和7。如果不是,这些人是否在1949年或1997年自动丧失中华民国国籍?会问这些问题是因为注意到陳日君枢机的国籍标识由中华人民共和国(香港)被改为中华民国,我认为两者似乎都是有道理的,因此根据Wikipedia:格式手册/两岸四地用语第13条像黎智英这样并列标识为佳,却又不十分确定。黎智英在出生时是中华民国国民,条目的标注是延续至今,而诸如郭沫若这样一直居住在内地的人的中华民国国籍仅标识到49年,不知道中华民国国籍法对于香港居民和大陆居民的相关规定是否不同。--立日留言2022年3月29日 (二) 17:13 (UTC)[回复]

說了很多遍了,除非他本人有公開國籍,否則不要添加國籍資訊。因為您無法保證他到底是否有其他國家的國籍或有沒有放棄所謂的原本國籍,尤其是香港有多重國籍的人多不勝數,也有很大可能已經放棄了原國籍而未有公開。--AT 2022年3月29日 (二) 17:27 (UTC)[回复]
认同需要来源,但来源的种类可能会有些模糊。现在大部分条目人物的国籍,要么和WP:孙文一样,“孙中山有中华民国国籍”应该也无需引用;要么像黎智英的几个国籍标注,中华民国和英国是引用媒体来源,其他都是引用相关法律的。我认为即使本人没有明确阐述自己的国籍,依据国籍相关法律判断国籍也是可以的,所以才希望能明确一下中华民国藉香港居民的问题。可能会写上被放弃而未公开的国籍,但总比都不写好,像香港出生的馬英九并没有明确是否持有英国国籍,但如果因此就不写中华民国国籍了对这个条目而言反而遗漏了一个重要信息。--立日留言2022年3月29日 (二) 18:38 (UTC)[回复]
這仍然是在假定,沒有排除到當事人可能已經放棄國籍的可能性,況且國籍也不是什麼重要資訊,像英維日維的馬英九條目均沒有此項目。任何憶測的資訊均應該避免,Wikipedia:孙中山是男性无须引用說的是:「「孫中山是男性」這類顯然的信息不需要引用」國籍不如性別顯然,就算是顯然易見也不代表就一定要寫進去,就像孫文是男性也不見得就一定要寫進首段或資訊框,國籍也是同一道理,更何況可能存在爭議呢。--AT 2022年3月30日 (三) 04:33 (UTC)[回复]
不认同国籍不是重要資訊--葉又嘉留言2022年4月1日 (五) 05:55 (UTC)[回复]
無論重要與否,請提出可靠來源來證實,不要假設。--AT 2022年4月3日 (日) 07:39 (UTC)[回复]
除非是台灣人來到香港定居,否則所謂中华民国籍香港居民是不是和中華民國籍大陸居民一樣沒有什麼太大意義?這類人在台灣又沒有公民權。--中文維基百科20021024留言2022年3月31日 (四) 11:35 (UTC)[回复]
主要是1949年前出生的人出生时确实是中华民国国民,但是这些人在国籍期间上应该怎么表述格式手册没有明确,如果是香港居民又更复杂了,这样其实会有潜在的中立性问题,比如为什么郭沫若标到49年而黎智英则是从48年开始一直延续,陈日君国籍写中华民国是否合适等。像AT说的不确定就不写可能更好,但是目前方针没有明确。--立日留言2022年3月31日 (四) 11:57 (UTC)[回复]
如同丘成桐 是有的--葉又嘉留言2022年4月1日 (五) 05:58 (UTC)[回复]
丘成桐在1997年前就移居美国了,这样就不涉及中华人民共和国的标识问题。不过我这里比较关注的是一直居住在香港的中华民国国民,在97年后按法律就有了中华人民共和国国籍,这样在标识上难免出现争议,到底是只标中华民国好呢,还是只标中华人民共和国(香港)好呢,还是两者都标上好呢。国籍的持续时间也是个问题。--立日留言2022年4月3日 (日) 07:23 (UTC)[回复]

提议更换Mediawiki保护标志

鉴于目前模板保护与Mediawiki保护标志相同,我与User:FoolPiasar设计与制作了一版标志:

橙色和mw图标代表Mediawiki,代表保护是由Mediawiki自动作出的。

--中维金苹果,时不时给维基人们加buff留言2022年4月1日 (五) 00:04 (UTC)[回复]

(+)支持 BuenosDías 2022年4月1日 (五) 01:12 (UTC)[回复]
可以的。--Tranve () 2022年4月1日 (五) 01:43 (UTC)[回复]
(?)疑問:这个标志中有锯齿状圆环,但是缩小到一定程度后完全看不出锯齿图案。所以为什么不直接使用光滑的圆环呢?--Yining Chen留言|签名页2022年4月1日 (五) 01:56 (UTC)[回复]
因为那样就不是mediawiki了啊(笑--InsaneGuo留言2022年4月1日 (五) 01:59 (UTC)[回复]
Telegram群里面已经有人反映了此问题,我已经上传了一版新的(由于这几个名字我全部写错了,已经提出移动请求,移动后别忘了把这里的改了)--中维金苹果,时不时给维基人们加buff留言2022年4月1日 (五) 02:07 (UTC)[回复]
(+)支持 十分好康 --InsaneGuo留言2022年4月1日 (五) 01:56 (UTC)[回复]
(!)意見一看就知道各位不记得过往讨论了吧…… --MilkyDefer 2022年4月1日 (五) 02:44 (UTC)[回复]
囧rz……--中维金苹果,时不时给维基人们加buff留言2022年4月1日 (五) 03:10 (UTC)[回复]
(+)支持Abcd715留言2022年4月5日 (二) 01:59 (UTC)[回复]
感覺可以,反正現時使用中的保護標誌並無環狀圖案,就算看成“O”也沒太大關係。Sanmosa Avec cœur 2022年4月6日 (三) 07:46 (UTC)[回复]
如果一定要这样想也不是不行,但是明明有更适合小图标的mw花瓣版本--MilkyDefer 2022年4月6日 (三) 13:02 (UTC)[回复]
是指File:MediaWiki-2020-small-icon.svg吗?我也是觉得如果能用这个标志做成保护图标效果更好。--BlackShadowG留言2022年4月7日 (四) 12:05 (UTC)[回复]
(+)支持--以上未簽名的留言由孟天皓討論貢獻)於2022年4月8日 (五) 13:31‎ (UTC)加入。[回复]
(+)支持--🍰463292 2022年4月11日 (一) 07:00 (UTC)[回复]
方針內混雜了「保護層級」(自確、延確等)、「保護類型」(編輯、移動等)和「保護原因」,「MediaWiki保護」是一種保護原因,其包括兩種保護層級為全保護跟介面管理員保護,而Wikipedia:保護方針#MediaWiki保护章節所使用的圖示指的是「介面管理員保護層級」而非「MediaWiki保護原因」(參見英文維基百科en:Wikipedia:Protection policy#Interface protectionen:Template:Protection table,圖示為),因此本提案想決定MediaWiki保護的圖示,我認為並不適合。--Xiplus#Talk 2022年4月11日 (一) 12:02 (UTC)[回复]
缺乏的是介面管理員保護層級圖示,現時借用模板保護的圖示(因為同樣都是技術工作)。--Xiplus#Talk 2022年4月11日 (一) 12:05 (UTC)[回复]

提议设立官方维基百科镜像供国内直连访问和编辑

首先提醒一下,这不是纯粹的技术问题,只有社群确定“这样做合适”之后才应该讨论技术细节。

这是我在近期乌克兰战争的背景下产生的想法。如果设立官方镜像,以下问题可以解决:

  1. 国内用户无法直连访问(不考虑少部分技术能力强的用户)
  2. 国内用户编辑必须要通过代理及申请IPBE,步骤繁琐(这是本站长期以来的痛点)

然后关于能不能实现,我问了几个技术人员,回答是“有难度但并非完全不可行”。

补充:下方我的两个发言澄清了常见的误解,请各位发言之前先看一遍,已有的问题请不要重复提出,谢谢。

以上。好久没来客栈了,总之欢迎各位留言,谢谢。--Tranve () 2022年4月1日 (五) 01:43 (UTC)[回复]

如果好不容易建起來然後就被封了怎麼辦?—— Eric Liu 創造は生命(留言留名學生會 2022年4月1日 (五) 01:47 (UTC)[回复]
当然是打一枪换一个阵地。域名封一个换一个。IP的话可以考虑用CDN,GFW一般不会封CDN的IP。--Tranve () 2022年4月1日 (五) 01:49 (UTC)[回复]
2021年维基媒体基金会针对中文维基百科的行动里面中国政府的态度还不够明确?这种跟土共打游击的玩法没啥意义,就算是CDN,CDN的IP一样有办法扬掉(github等有几个CDN服务商的IP被长期盯死了)。——Sakamotosan路过围观 | 避免做作,免敬 2022年4月1日 (五) 02:37 (UTC)[回复]
设立官方维基百科镜像,就需要走合规途径。“当然是打一枪换一个阵地。域名封一个换一个。IP的话可以考虑用CDN,GFW一般不会封CDN的IP”。这是完全不合规的做法--百無一用是書生 () 2022年4月1日 (五) 03:14 (UTC)[回复]
嗯……我想你误解我的意思了。如果你的“规定”指的是中国法律的话,那上维基百科本来就犯法了,还管它干什么?如果是基金会的相关规定,我的本意就是想现在这里沟通然后再去和基金会提意见。--Tranve () 2022年4月2日 (六) 02:11 (UTC)[回复]
这种不合CDN服务商的规定,最终结果就是CDN被GFW封掉,GFW为了封掉Twitter可是把Fastly封了,于是没有CDN会愿意为维基百科提供服务。桐生ここ[讨论] 2022年4月3日 (日) 14:33 (UTC)[回复]
为什么不合规?Fire Ice 2022年4月1日 (五) 14:23 (UTC)[回复]
多让一个人上维基百科就是意义。你维到底为十四亿人接触自由知识做了什么!?--Fire Ice 2022年4月1日 (五) 16:02 (UTC)[回复]
這些話你找習近平說更好,為什麼不讓中國人瀏覽維基百科,為什麼要把翻墻瀏覽維基百科的中國人拘留。如果要找基金會,就像我下面所說的,勸他們允許使用代理服務器的用戶直接免IPBE就能編輯。--中文維基百科20021024留言2022年4月1日 (五) 16:45 (UTC)[回复]
现在是客观条件无法改变,只能指望基金会主观努力了。--Fire Ice 2022年4月2日 (六) 12:35 (UTC)[回复]
基金会没有主观努力的必要,只要不按照中国政府的要求进行内容审查,主观努力反而会得罪中国政府,彻底被认证为境外颠覆势力,造成基金会人士或社群知名人士进入中国境内的人身安全风险。你见Facebook、Twitter、Google有主观努力和GFW打游击战吗?桐生ここ[讨论] 2022年4月3日 (日) 14:26 (UTC)[回复]
@Cwek:首先那些服务商都没有被完全扬掉,只是间歇性抽风。退一万步讲,就算你维真的被这样针对,也比现在的情况好太多了。现在可是完全不能访问啊!--Tranve () 2022年4月2日 (六) 02:13 (UTC)[回复]
是CDN服务商的部分IP。推断是路由黑洞。——Sakamotosan路过围观 | 避免做作,免敬 2022年4月2日 (六) 02:26 (UTC)[回复]
是的,阁下提出了一个可能有机会解决问题的方法,与其解决镜像站的准入标准,不如使用官方镜像站。--Pavlov2仁爱亲诚 2022年4月1日 (五) 12:55 (UTC)[回复]
與其提供中國直連不如允許中文站無需IPBE直接代理編輯更好。因為中國直連這一方式政治上走不通。代理編輯由與基金會政策違背,除非基金會願意特殊對待中文站。如果說說服中共和基金會的話,好像說服基金會相對更容易一些?--中文維基百科20021024留言2022年4月1日 (五) 16:41 (UTC)[回复]
又是閆那個消極對待開放代理的方法嗎?--Ghren🐦🕛 2022年4月1日 (五) 16:53 (UTC)[回复]
消極對待開放代理是指?--中文維基百科20021024留言2022年4月1日 (五) 17:04 (UTC)[回复]
之前Techyan等提出开放代理不应该自动封禁,而是有破坏再去封,方便大陆用户注册使用,然后Jimmy-abot就停止自动封禁开放代理。(節刪)[2021年9月]被推翻。 ——魔琴 [ 留言 贡献 ] 2022年4月3日 (日) 03:22 (UTC)[回复]
因為techyan被封禁所以那個措施就要被推翻?誰提出的?--中文維基百科20021024留言2022年4月3日 (日) 03:27 (UTC)[回复]
Wikipedia:互助客栈/其他/存档/2021年9月#重启“机器人自动封禁机房IP段的任务”的提议,和913没啥关系。--Lt2818留言2022年4月3日 (日) 03:50 (UTC)[回复]
忘记具体时间了,已经节删。 ——魔琴 [ 留言 贡献 ] 2022年4月3日 (日) 06:39 (UTC)[回复]
我只能说techyan这么做,为LTA逃脱CU大开方便之门--Pavlov2仁爱亲诚 2022年4月3日 (日) 07:57 (UTC)[回复]
我猜测肯定之前有人讨论过这个方案,但是事实上中维并没有放开IPBE,估计这么做肯定是遇到问题了。--Tranve () 2022年4月2日 (六) 14:07 (UTC)[回复]
(~)補充:澄清一下上方的误会。我的想法是我们可以像某些VPN服务商、NSFW网站和樱花动漫一样,搞一系列的官方镜像站,通过多种渠道散播其地址。如果一个被封了,就换另一个顶替。--Tranve () 2022年4月2日 (六) 02:10 (UTC)[回复]
因为是官方镜像站,所以技术上我们是可以知道访问者的真实IP的,这样就从根本上规避了IPBE的问题。
我知道这个做法比较难看,但它却是最符合中国国情的方案——对新手友好,学习成本低。想想看Help:如何访问维基百科里头有多少技术范的方案,但是又有几个新手会用呢?--Tranve () 2022年4月2日 (六) 02:22 (UTC)[回复]
维基百科条目常被引注,其链接需要长期保持可用。如果搞一系列的官方镜像站,那么每个域名都不能随意抛弃,要考虑长期维护域名的成本。--Lt2818留言2022年4月2日 (六) 04:56 (UTC)[回复]
确实有这个情况。但我觉得在镜像站里写好“引注使用原网址”,像安忆的镜像站一样,就好。总之感谢各位的意见。--Tranve () 2022年4月2日 (六) 14:06 (UTC)[回复]
官方镜像站八成不会有,“封一个换一个”不是说的那么简单的,无论是域名还是IP,很显然要考虑成本问题。树大容易招风,镜像站本就应该小众,才能降低被封的几率,官方提供镜像站做不到维持小众,而且维基百科本就受到墙的重视,要不然不至于五个IP有三个被封。--🔨留言2022年4月2日 (六) 08:56 (UTC)[回复]
成本问题我觉得WMF自己最清楚吧。到时候可以问问他们。--Tranve () 2022年4月2日 (六) 14:04 (UTC)[回复]
域名也是要钱的,同时维护镜像站也需要一定的人力。假如说每换一个域名都是没过几天就被墙,还不如干脆不搞。--🔨留言2022年4月2日 (六) 14:59 (UTC)[回复]
咱不知道基金会能不能做,咱只知道安忆的镜像站没钱了( ——魔琴 [ 留言 贡献 ] 2022年4月2日 (六) 15:42 (UTC)[回复]
还有爱发电的捐助链接(——诚挚的 ZhaoFJx 2022年4月12日 (二) 13:53 (UTC)[回复]
2020年Techyan就提过几乎相同的提案:m:Wikimedians of Mainland China/Draft proposal on establishing an official mirror site of Wikimedia projects for mainland Chinese users。--GZWDer留言2022年4月2日 (六) 20:25 (UTC)[回复]
这个似乎只是草稿,还没有正式讨论。--Tranve () 2022年4月2日 (六) 23:22 (UTC)[回复]
真要合规运营,我估计必须在镜像站删掉一些(甚至大量)“敏感内容”,这就是彻底把WP:NOTCENSOR当摆设了。--BlackShadowG留言2022年4月3日 (日) 07:23 (UTC)[回复]
用镜像站和GFW打游击战这种方式,WMF肯定是不会做的,倒是可以中维社群设立一个社群官方镜像站。WMF服务器通过捐款运营,那么社群官方镜像站也可以通过捐款运营,可以成立一个维基百科组织负责运营官方镜像站,并且可以和WMF一样在中文维基百科打募集捐款的广告,这个组织可以写入方针指引,就像WP:機械人審核小組一样。桐生ここ[讨论] 2022年4月3日 (日) 14:44 (UTC)[回复]
我觉得这个想法很好啊!--Fire Ice 2022年4月3日 (日) 14:50 (UTC)[回复]
如此镜像站运营者面临极高法律风险,相当于外国基金会注资的代理人;用户数据安全也成问题;捐款同样有法律问题。官方性质或背书的镜像站运营我认为不可行,推广亦同样需慎重低调,希望各位先想清楚。如果是通过工具或网站代理访问,面临渠道被封和IPBE、反破坏问题。--YFdyh000留言2022年4月3日 (日) 15:19 (UTC)[回复]
我们都不是WMF,谁也不能代替他们发言吧?--Tranve () 2022年4月3日 (日) 15:59 (UTC)[回复]
这个想法不错,不过还是那句话,树大招风,而且还要考虑“内鬼”的问题,如果能够确保维持小众低调,镜像站自然活得久一些,同时也能够尽最大可能节省成本。--🔨留言2022年4月3日 (日) 16:58 (UTC)[回复]
  • 要是這樣可行,google等早就做了,何必等我們提出。--Temp3600留言2022年4月4日 (一) 02:18 (UTC)[回复]
    WMF出面也不是没有可行性。一种可能合规的偷鸡办法是WMF在GFW自由港租用服务器设立缓存代理,中国大陆IP访问维基百科直接路由到这里的服务器。因为GFW自由港位于GFW之内又不受GFW管控,所以中国大陆用户应该可以自由访问维基百科。这个办法最大的问题是如何在GFW自由港租用到服务器?--百無一用是書生 () 2022年4月6日 (三) 02:41 (UTC)[回复]
    “GFW自由港”是什么东西啊。@Shizhao Stang 2022年4月6日 (三) 13:48 (UTC)[回复]
    HK?--BlackShadowG留言2022年4月7日 (四) 00:07 (UTC)[回复]
    Shizhao,你对大陆的理解有点脱节了吧,港澳都算是中国大陆境外的,一样要过墙的。——Sakamotosan路过围观 | 避免做作,免敬 2022年4月7日 (四) 01:00 (UTC)[回复]
    北京、上海等少数几个城市有专为外资服务的数据中心,这些数据中心不受GFW管控,不用过墙,同时又位于墙内。我一时不知道怎么说这个事,可以类比于中国大陆境内的自由贸易区,故以“GFW自由港”称之--百無一用是書生 () 2022年4月7日 (四) 02:01 (UTC)[回复]
    我不认为这些自由贸易区的网络和中国互联网骨干网之间不过墙(好处就是国外企业可以直接在中国大陆落地,减少过海的通信延迟,不用像中国电信主力出口都在美国西海岸或者德国,自动增加100ms加抖得要命的抖动,对于国外CDN来说会体验改善不少),而且按照一如既往的中国政府态度,内容审核是逃不过。结果就是,如果直接放在国内网络,肯定要做内容审核;放在贸易区,除了延时和丢包抖动会大幅减少,该过墙的还是过墙,和放在香港某些非专线的服务器一样没啥区别(例如移动的出口主要在香港,算上过墙延迟也在60ms左右,基本就是国内骨干网的常态)。——Sakamotosan路过围观 | 避免做作,免敬 2022年4月7日 (四) 02:20 (UTC)[回复]
    说的是墙内节点走专线做CDN?我不认为这可能通过审批/备案和稳定运行,同时高成本。安全性也很难兼顾,似乎比较安全的CloudFlare Keyless SSL非标准化。--YFdyh000留言2022年4月7日 (四) 07:55 (UTC)[回复]
    不一定要用IPLC之类的专线。只要国内能访问,不容易被GFW墙掉就可以。这点取决于基金会。--Tranve () 2022年4月8日 (五) 11:41 (UTC)[回复]
    不大可能,最常用的访问入口——域名可以被投毒或者审计控制(例如托管在中国大陆的VPS如果绑上没备案的域名提供HTTP(S)服务,VPS服务商是知道的,然后直接将机器下线)。IP可以被黑洞掉或者要求ISP接入商拔线。甚至还有TCP RST等其他技术手段。——Sakamotosan路过围观 | 避免做作,免敬 2022年4月10日 (日) 09:50 (UTC)[回复]
    取得任何物理位置在中华人民共和国(含港澳)内的服务器之掌控权对于官老爷来说可谓轻而易举,所谓的“GFW自由港”也不会例外。--🔨留言2022年4月7日 (四) 02:59 (UTC)[回复]
    就算当地政府允许,wmf本身都不会同意吧。目前wmf甚至不允许居住地在中国大陆且该信息为他人所知的用户持CU权限,以免权限遭破解;直接把服务器设在中国大陆就不怕用物理手段破解权限了么?--Antigng留言2022年4月6日 (三) 14:26 (UTC)[回复]
    @Antigng:没说要让当地政府允许啊……是基金会设立官方镜像和不允许访问维基百科的政府玩躲猫猫。--Tranve () 2022年4月8日 (五) 11:40 (UTC)[回复]
    这个讨论总是想技术上有没问题,就没有考虑过内容有没问题。从内容而言,一堆不符合中国政府意见的内容,这足以断掉满足“合规”的想法,如果把接入服务器(无论是类似现在基金会使用的准静态缓存机制,还是现在常见的动态反向代理)放在中国大陆境内互联网的,就肯定无法通过域名或者服务器接入审批,就算打游击,被端掉是迟早的事;如果放在离中国大陆近但属于“境外”的网络,例如自由贸易区和香港等,该过墙的还是和现在的一样,除了延迟减少了,没啥区别;如果搞配合内容审查的,那就和百度百科那些不就一丘之貉?简而言之,在内容问题没解决之前,技术不是主要问题。——Sakamotosan路过围观 | 避免做作,免敬 2022年4月7日 (四) 09:06 (UTC)[回复]
    果然还是绕不开内容问题。这样我能想到的最多也就是在大陆建立一个会过滤内容,只可浏览,不可编辑的镜像站(有点类似于蜻蜓计划)。这样能让更多的大陆用户看到维基百科的一些比较优质的条目,有利于吸引更多大陆用户来主站编辑,且应该也不会让维基百科沦落成百度百科那样,毕竟真的想来编辑的还是得绕开GFW的。--BlackShadowG留言2022年4月7日 (四) 12:22 (UTC)[回复]
    要不然怎么会催生出类似万维百科这样的的玩意?(或者求闻百科之类的)——Sakamotosan路过围观 | 避免做作,免敬 2022年4月8日 (五) 00:45 (UTC)[回复]
(~)補充:再次澄清上方的误会:
  1. 镜像站是否需要得到政府允许?是否需要自我审查?答案都是“否”。显然,WMF和中文维基百科社群都不会向审查妥协。设立官方镜像站本身的目的也在于规避政府的网络审查,还请各位不要搞错了。
  2. 为什么别人没有做?有人做过。我举几个例子,NordVPN、赛风和自由门等都存在大量这样的官方镜像站。
  3. WMF愿不愿意做?我们都不是WMF,我们怎么知道?这得去问他们。我已经在想办法问了,各位稍等。
  4. 最后在啰嗦一句,我在客栈发起讨论的目的仅仅是征求大家的意见,及“假定所有技术问题都可以解决,社群愿不愿意假设这样的镜像站”。具体的技术问题只有讨论得出共识和结论之后,才能由WMF解决。
以上。--Tranve () 2022年4月8日 (五) 08:03 (UTC)[回复]
cc @Antigng、@Cwek、@BlackShadowG、@Ericliu1912、@Fire-and-Ice、@GZWDer、@Ghrenghren、@Liu116。--Tranve () 2022年4月8日 (五) 08:04 (UTC)[回复]
WMF支持的話我也沒理由反對。問題是WMF不可能支持,要是WMF支持的話,我和劉醬一樣女裝 囧rz……[開玩笑的]。--Ghren🐦🕓 2022年4月8日 (五) 08:11 (UTC)[回复]
技术可行不代表实际可行,因为政策或法律上不太可行。如果不是政策或法律上的问题,为什么像“万维百科”那样搞出手工审查来筛选显示的条目和内容,不少私下的动态镜像要么想法子设限制或者躲避探测,要么就是嗝屁了(无论是无法维持运营,还是因为被发现而端了)。正如上面所说的,如果搞游击是可行的话,Google等早就可以这样玩了,如果搞内容审查可行的话,Google为什么想搞蜻蜓计划,最后还被搞黄了?技术谁不知道可行?——Sakamotosan路过围观 | 避免做作,免敬 2022年4月8日 (五) 09:14 (UTC)[回复]
既然提到我们不是WMF,那我们讨论这些就是废话。有问题请到元维基meta:Requests for comment他们反馈,最好at上WMF的法律相关工作人员。——Sakamotosan路过围观 | 避免做作,免敬 2022年4月8日 (五) 09:17 (UTC)[回复]
这些站点(NordVPN、赛风和自由门等)打游击而不是光明正大地设一个不会跑的庙,不就是因为无法解决法律合规性嘛。如果是固定的庙,被端只不过是迟早的事。——Sakamotosan路过围观 | 避免做作,免敬 2022年4月8日 (五) 09:20 (UTC)[回复]
PS.从技术而言,城墙的三板斧有的是搞你的路数。被发现和被端只是时间问题。(可以查阅一下中国大陆对维基媒体的封锁措施的演进,甚至我怀疑部分措施升级,如IP黑洞,中国大陆默认分配旧金山接入点,虽然可以通过技术来调整,但部分没分配给中国大陆的接入点IP一样黑洞掉;或者wikipedia.org的二级域,早期只是特定语区的域名投毒,后来直接整个二级域SNI RST,是不是和一些规避手段滥用有关。)——Sakamotosan路过围观 | 避免做作,免敬 2022年4月8日 (五) 09:33 (UTC)[回复]
(!)意見感觉没有必要。想想谷歌的Dragonfly计划,再想想一旦官方镜像被传播之后大陆官方会有什么反应,所以不如没有。或者不如说传播必然导致北京实施对WMF不利的举措。--Я, Якийсь Вікіпедист із КитаїU·K·R2022年4月10日 (日) 03:18 (UTC)[回复]
(~)補充关于中国大陆对维基当前的态度,在下讲一个发生在自己身上的故事,也许有参考意义。在下因为在维基编辑活跃(与政治类条目无关)而在17天前被一部分自诩为“爱国”的学生举报,8天前被大学建议进行“休学”。足可见镜像站公布后大陆会是什么反应。--Я, Якийсь Вікіпедист із КитаїU·K·R2022年4月10日 (日) 03:48 (UTC)[回复]
@A Chinese user請問是聊天的時候透露出去自己在寫維基還是在寫維基的時候被寢室室友看到了?--中文維基百科20021024留言2022年4月10日 (日) 04:04 (UTC)[回复]
在下是被人“开盒”了。寝室室友没有过激的反应。--Я, Якийсь Вікіпедист із КитаїU·K·R2022年4月10日 (日) 04:12 (UTC)[回复]
太张扬了?不过现在某些人的主观过于激进了。——Sakamotosan路过围观 | 避免做作,免敬 2022年4月10日 (日) 08:01 (UTC)[回复]
这应该在这里是题外话,有兴趣不妨移步在下讨论页。--Я, Якийсь Вікіпедист із КитаїU·K·R2022年4月10日 (日) 08:43 (UTC)[回复]
可怕,建议WP:ANON桐生ここ[讨论] 2022年4月11日 (一) 03:42 (UTC)[回复]
( ✓ )同意。--Я, Якийсь Вікіпедист із КитаїU·K·R2022年4月11日 (一) 03:45 (UTC)[回复]

帶括弧重定向去留

重定向的意義是讓讀者可以搜尋搜尋其他別名都可以搞到相應的條目,照此邏輯任何無連入括弧重定向都不會發揮到導航的作用。我的想法是把R8延伸到任何帶著括弧的重新導向都適用,看一下意見-某人 2022年4月5日 (二) 07:31 (UTC)[回复]

1.搜索建议。2.内链目标。个人建议个例/批量存废讨论,而不是全盘处理。另外,删除这些重定向只有成本而没有收益,移动产生的重定向(例中國 (電腦遊戲))改掉链入、速删掉,产生价值吗。--YFdyh000留言2022年4月5日 (二) 08:08 (UTC)[回复]
之前可能有討論過?或可翻翻相關討論。—— Eric Liu 創造は生命(留言留名學生會 2022年4月5日 (二) 08:15 (UTC)[回复]
括號連結本身己經修得麻煩了,李鵬飛已經由主條目移至李鵬飛 (香港),然後有同名香港演員,又移去(政治人物),然後有同名政治人物,又要移動。在此情況下,無用的生年括號重定向是否真的沒有必要?只怕未必。猴年馬月依然顯得出他們的作用,即使像李鵬飛這樣的例子,很長時間括號重定向沒有被使用也好,但是因為預先建立而吸引了編者使用,後人移動的時候價值上就可以修少一個,所以我不太同意說沒有連入就刪掉,重定向只有利益可言。--Ghren🐦🕓 2022年4月5日 (二) 09:15 (UTC)[回复]
中正区 (台北市)中正區 (臺北市)雪梨 (城市)悉尼這類重新導向刪除會導致輸入zh-cn、zh-tw等模式顯示標題無法跳轉,直接連結形成紅連結。其他無連入的重新導向我覺得沒甚麼用,刪除無妨。 紺野夢人 2022年4月5日 (二) 10:40 (UTC)[回复]
速删无链入可能导致一个问题,假设我觉得China (樂團)导言的"中国合唱团"更不错于是移动,链入(5项)被我或机器人改掉,然后China (樂團)作重定向速删、管理员看符合标准执行。不久后我或其他人觉得这样命名有问题,再移动回去、纠正内链。所以,没必要就别动这些重定向和内链。--YFdyh000留言2022年4月5日 (二) 15:29 (UTC)[回复]
反对删除——还有一个理由:例如李鵬飛 (香港)被移动到李鵬飛 (政治人物),后面有人又想建另一个叫李鵬飛的条目,如果重定向还在那么创建者可以知道该标题有歧义从而换一个标题写。同理,仍然有歧义的条目名称应重定向到消歧义页,以免被人误建成条目。--GZWDer留言2022年4月5日 (二) 17:09 (UTC)[回复]
可能会导致繁简转换的问题,比如传染病 (电影)全境擴散,如果删除该重定向,大陆用户就难以找到条目。--BlackShadowG留言2022年4月6日 (三) 00:09 (UTC)[回复]
这种不少,最近刚建立的异形大战铁血战士 (游戏),如果删去可能某些语言区的用户会搜索不到条目。另外还有作者笔名表字问题。--Kethyga留言2022年4月6日 (三) 08:51 (UTC)[回复]

引入A7速刪

現行條文

(無)

提議條文
A7. 明顯不會有關注度的事物

適用於任何真實存在,但根據常理明顯不可能達到關注度準則的事物。如果此主題不是非常明顯地不符合關注度應該轉交存廢討論或走30天關注度流程。

現在經常有些明顯沒有關注度的的事物立條目,例如訂閱數一百幾十的youtube channel,而這些又不一定可以套用G11 (這些情況被管理員駁回也不在少數),所以建議引入英維這條速刪準則以處理這個不足-某人 2022年4月6日 (三) 07:13 (UTC)[回复]

A7以前是有實行過(即WP:CSD#A4),但是已經被廢除。「常理明顯不可能」在以往的經驗裏經常容易引起爭議,所以才被廢除並改為現在的一律轉交存廢討論。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年4月6日 (三) 08:15 (UTC)[回复]
要不廢除關注度三十天提刪流程,覺得沒關注度直接提刪算了。--中文維基百科20021024留言2022年4月6日 (三) 08:42 (UTC)[回复]
(-)反对(!)強烈抗议廢除關注度30天流程。上次「Wikipedia_talk:关注度/存档11#关注度程序30日过长。」就引起強烈社群反彈。光是縮短30天流程就引起那麼大的七萬字社群反彈。抗議。你們故意移除30天流程等於是「惡意讓編者沒有時間尋找線下來源」這也是上次討論的結論之一或觀點之一。「條目裡面沒有來源不是刪除條目的理由,努力找找不到才是」(這句antigng說的,出處,請遵守方針),我也強烈抗議「0奈秒瞬間秒刪」、「秒刪」的行為,我無論如何都要認為這種行為極端惡意,惡意至極,維基百科又沒有最後期限,你們在趕什麼?趕火車?趕飛機?留意一下前次討論的一些觀點:「為甚麼要急於刪去條目呢?用戶也要有足夠時間改善條目,而且來源不只限於線上,線下來源需要更多時間去尋找,一兩個星期沒能抽空到圖書館,就要刪去條目嗎?何必急於刪去條目呢?;有些新手寫了條目後,要多花時間去找來源,我們要給予足夠時間讓新手有足夠時間去改善條目,急於提刪條目會嚇怕新手;巡查條目不能只看線上來源,對於已存在於條目的線下來源,巡查員也要花時間到圖書館驗證,這都需要足夠的時間;google 自己也說他們不會把所有來源都呈現在搜尋器中,而且涉及版權問題,有很多來源都不會放在線上,線上來源始終有限,大部分來源都存在於線下,我們須給予用戶足夠時間尋找線下來源;明顯不符合關注度的可以雪球提刪,何必急於刪去可能符合關注度要求的條目呢?;在沒有給多足夠改善時間,就急於提刪條目,是很容易引起爭議的;方針訂明刪除應是最後手段,維基對於提刪及刪除條目都傾向審慎的,在提刪前,應給予足夠的改善時間。」基本(!)抗议未給緩衝就提刪的行為!這是惡意行為!!—- [雪菲蛋糕] >[娜娜奇鮮果茶](留言·簽到2022年4月6日 (三) 09:21 (UTC)[回复]
想再來一次七萬字?我可以ping來當時所有人!!—- [雪菲蛋糕] >[娜娜奇鮮果茶](留言·簽到2022年4月6日 (三) 09:46 (UTC)[回复]
@A2569875,我們都很清楚您的意思,也請您避免「大喊大叫」。--🎋🎍 2022年4月6日 (三) 11:18 (UTC)[回复]
(:)回應我把部分文字弄灰了,有看起來比較「小聲」一點嗎?-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️2022年4月6日 (三) 11:21 (UTC)[回复]
鉴于执行标准不统一、“常理”标准含糊,这种还是得提存废,期间有可能被改进扩充,而不是直接被删。大量出现有G11/G3/“批量提删”讨论可用。--YFdyh000留言2022年4月6日 (三) 15:28 (UTC)[回复]
(+)支持,提删和速删之间目前是存在一些可以填补的空间。有些新建条目整个页面只有用于避开A1的寥寥几句话,且明显无法满足关注度要求,可是缺乏严格对应的速删选项。还有类似来自某某中学的学生个人传记这种...几乎每个月都能看见好几个,要说G3也未必,人家自己写的还很上头,当真是找不到完全满足的速删选项。这些条目所有人都知道明显是留不下来的,但最后全都只能走一遍关注度或者提删流程,所以A7的加入能够很好的处理这类情况。当然A7容易给人一种泛用速删选项的感觉,可能会增加管理员把关的工作量,不过我个人认为是利大于弊的。--南冥大鹏👈把我批判一番出偏差要负责👊微小的工作历史的进程2022年4月6日 (三) 22:02 (UTC)[回复]
(-)反对,应该参考之前速删A4的问题。——Sakamotosan路过围观 | 避免做作,免敬 2022年4月7日 (四) 00:58 (UTC)[回复]
(-)反对:走個存廢討論有這麼難嗎?—— Eric Liu 創造は生命(留言留名學生會 2022年4月7日 (四) 02:44 (UTC)[回复]
你说的存废讨论是不是那种,一个“雪球关注度”为理由,一堆支持删除的附和意见的那种;那有什么显著区别。 Stang 2022年4月7日 (四) 03:24 (UTC)[回复]
区别是挂7天,想拯救条目的人有时间搜集和改写,而不是任一管理员附和一下就删掉内容,其他人还得及时发现、考虑查询、存废复核。--YFdyh000留言2022年4月7日 (四) 07:58 (UTC)[回复]
区别是至少有其他人看過是不是真沒救了。--Temp3600留言2022年4月7日 (四) 09:52 (UTC)[回复]
上面有提到“提删和速删之间目前是存在一些可以填补的空间”,这个空间可以考虑引入英文站的提议删除机制,即“不开讨论,只挂模板,若干日无人反对即删;如反对再转xfd”来填补,而不是将明显浪费xfd资源的讨论直接下放到快速删除。--Antigng留言2022年4月7日 (四) 04:27 (UTC)[回复]
不過有的頁面瀏覽量並不高,即使被人看到了也有可能是純讀者,不知道如何反對,此時刪除與否似乎就取決於瀏覽量了。--中文維基百科20021024留言2022年4月7日 (四) 04:54 (UTC)[回复]
現在侵權和部份圖片快速刪除的機制事實上來說是一種提議刪除的機制,不是說不行,但是一樣都會有持續7天的時間,這似乎和提案者初衷不同。Ghren🐦🕐 2022年4月7日 (四) 05:00 (UTC)[回复]
(-)反对。User:Wing於2010年說過「快速删除应该仅仅用在非常明显的情况下,而且应该在能够不使用的情况下尽量不使用。因为快速删除没有任何讨论的过程,往往新用户不理解怎么回事就被删除了。他根本没有回应的机会。因此使用快速删除对付新用户不但非常不友好,实际上非常违反维基互动和互重的支柱。」[3] --Mewaqua留言2022年4月8日 (五) 13:19 (UTC)[回复]
@Mewaqua能適用A7的都是一百幾十個sub的youtube channel或者一個中學生的自傳,我會說正常人會知道為什麼被刪除-某人 2022年4月10日 (日) 04:36 (UTC)[回复]
(-)傾向反對:易引起爭議Abcd715留言2022年4月9日 (六) 11:08 (UTC)[回复]
阁下放心,如果中文维基能有共识引入这个,太阳就从西边升起来了。关注度是什么,中文维基一直搞不明白。引入关注度快速删除?--PAVLOV仁爱亲诚 2022年4月9日 (六) 18:11 (UTC)[回复]
謝謝您Abcd715留言2022年4月10日 (日) 07:51 (UTC)[回复]
(-)反对:爭議很大,建議走afd。--🍰487186 2022年4月11日 (一) 06:58 (UTC)[回复]
(-)反对:會有爭議。如果能將明顯速刪範圍縮減至如AINH君所解釋的(訂閱數一百幾十的youtube channel),且幾乎無相關來源來證明關注度。則(+)支持。--可愛くって かぷってしちゃうから🛎#がうる・ぐら可愛いです! 2022年4月12日 (二) 14:38 (UTC)[回复]

维基百科:關注度 (運動員)加入奧運會奪牌運動員

建議在维基百科:關注度 (運動員)中加入奧運會奪牌運動員。--中文維基百科20021024留言2022年4月8日 (五) 07:03 (UTC)[回复]

現行條文

....

提議條文

(新增一節)如果有运动员在现代夏季奥运会或冬季奥运会(包括殘疾人奧運會)上赢得奖牌,將自動擁有關注度

參考對象是英文的Wikipedia:Notability (sports)#Olympic and Paralympic Games英语Wikipedia:Notability (sports)#Olympic and Paralympic Games,提議原因是多位北京冬奧會獎牌獲得者(山本涼太永井秀昭渡部善斗布里塔妮·鮑,最後一位還是前世界紀錄保持者)被人掛上了關注度。在此告知體育領域條目參與者user:Liu116user:佛祖西来。--中文維基百科20021024留言2022年4月8日 (五) 07:03 (UTC)[回复]

有点奇怪,章节标题是组织、场馆和比赛关注度(Organizations, venues and games notability),这里却提了一下奥运会获奖运动员,而且提议条文可能与“为大国家队上场至少4场非友谊赛”重复(小组赛、半决赛、决赛之类)。不过感觉可以根据英维这句话(The guidelines on this page are intended to reflect the fact that sports figures are likely to meet Wikipedia's basic standards of inclusion if they have achieved success in a major international competition at the highest level.,大意即“本指引旨在反映某一事实:如果体育人物在最高级别的重大国际比赛中取得成功,他们就有可能符合维基百科的基本收录标准。”)添加一条基本标准(Basic criteria),这样关注度也不会局限于参加奥运会的运动员。--东风留言2022年4月8日 (五) 07:36 (UTC)[回复]
不反對,擴大到其他重要賽事也挺好。--中文維基百科20021024留言2022年4月8日 (五) 07:42 (UTC)[回复]
這是AT上一次修人物關注度留下來的Bug。Wikipedia_talk:关注度_(人物)/存檔3#續BIO各項條文的時候有一條「廣為人知、獲得廣泛高度讚譽、具有特別出色表現的運動員。」,清晰是很不清晰沒錯,但是常識推理得到奧運會獎牌不可能不是特別出色的運動員吧。上邊东风說的那那條就是被人批評說不清晰所以才刪掉的,中維的關注度寫得像法律條文一樣非A則B的風氣不知道何時來的。Ghren🐦🕒 2022年4月8日 (五) 07:45 (UTC)[回复]
AT修NT:Bio的原意是好的,但是這樣修的話按照中維的習慣得至少將英維體育關注度再搬一大堆條文出來才可以避免提刪的情況。--Ghren🐦🕒 2022年4月8日 (五) 07:52 (UTC)[回复]
我支持假定奧運獎牌得主具備關注度。不過,您說的「這是AT修人物關注度留下來的Bug。」讓我感到非常不滿。您當然有權批評相關討論考慮得不夠全面,但是不應將責任完全推卸於我身上,相關條文本身經過多人討論後才得出共識,不可能僅是我一個人修改後留下來的bug。況且,這個討論本身您自己也有參與,因此如果您要指責其存在漏洞的話,您自己也責無旁貸。我個人認為無論任何規定,後來發現有改善空間的話,去修改去就事論事就好,完全沒必要點名批評發起人,此舉毫無意義,請您重新審視一下自己的發言。謝謝。--AT 2022年4月8日 (五) 10:50 (UTC)[回复]
我不清楚為什麼會有誤會。我已經說明您的提案原意是好的,對於我來說多修議案,自然會出bug。維基的方針就像是寫程序一樣,出bug非常正常。出bug不一定是壞事。我提及閣下的名字只不過是這是最能分別出是哪一個修訂案而己。事實上我也是在兩三個月前審核某一拳擊選手的條目才發現有這個問題,當時通過的時候我也沒意識到有這個問題。我沒有批評你的意思。--Ghren🐦🕖 2022年4月8日 (五) 11:43 (UTC)[回复]
您給的存檔連結已經夠清楚了,不需要寫「這是AT修人物關注度留下來的Bug。」我看到這句的時候就覺得您好像認為我製造了bug一樣的意思,如果您沒有這樣的意思請把我的名字刪去。謝謝。--AT 2022年4月8日 (五) 12:11 (UTC)[回复]
「人在河邊走,哪能不溼鞋」,在修例後發現有問題在維基是很平常的事,也是無可奈何的,對於我來說無論是不是您製造出來的Bug道理也是差不多,即使是誰出來提案,誰制造出bug都不是合理批評用戶行為的原因,這事再平常不過。--Ghren🐦🕒 2022年4月9日 (六) 07:04 (UTC)[回复]
我記得之前英維體育相關條目的關注度基準好像修訂過,不過沒仔細確認是往什麼方向修訂。—— Eric Liu 創造は生命(留言留名學生會 2022年4月8日 (五) 08:09 (UTC)[回复]
en:Wikipedia:Village_pump_(policy)/Sports_notabilityen:Wikipedia_talk:Notability_(sports)/Association_football。--Ghren🐦🕓 2022年4月8日 (五) 08:21 (UTC)[回复]
事实上体育人物条目的关注度标准衡量,在本站即便是像我这样参与此专题编辑的要去衡量,都未必拿捏得准。记得英文版存在不少没在国际大赛拿过什么奖牌的选手条目,可能就因为参加了奥运才得以保留(不知道现在的标准变了没)……至于运动员关注度具体限定要在奥运拿到什么名次才合适我也不清楚,不过有一点我清楚的是,限定拿到前八名好过限定拿到前三。记得东京奥运我在微博上看到有博主科普日本媒体报道时时常说“入赏”一词,提到在奥运会进了前八的选手都会获得国际奥委会颁发的diploma(中文有翻译成奖状,关于奥运diploma的更多资料详见[4]en:Olympic diploma)。--🔨留言2022年4月9日 (六) 02:19 (UTC)[回复]
(~)補充:其实这个运动员关注度的指引本身不完善的地方还有很多,以前Shizhao君在相关讨论时就明确表示反对拍脑袋设定某个数字标准的指引,在我看来这个运动员关注度也不应该正式通过成为指引(只是我当时没那么多时间与精力组织语句阐述理由去反对),毕竟我们不是竞技体育业界的人士,在一些地方的具体拿捏上未必能够确保准确,而且本站的竞技体育专题本来就不如英文版那样子成熟。另外,即便这里明确到奥运奖牌得主一定有关注度,也不代表以后就不会有其他用户对奥运奖牌得主条目提报关注度,毕竟不少人都是只有在奥运世界杯进行期间才会跳出来关注下竞技体育。--🔨留言2022年4月9日 (六) 02:46 (UTC)[回复]
有了指引對方提報了也不怕。--中文維基百科20021024留言2022年4月9日 (六) 04:35 (UTC)[回复]
话说上世纪的奥运会奖牌得主,要找到当时的报道显然难度相对较大(毕竟是互联网没普及的时代)。从这角度来看的话,有相关的指引明确规定总好过没有。奥运奖牌得主甚至金牌得主挂关注度模板的情况,我以前也见到过,如果像这次这样有人能够提出合理异议阻止删除倒还好,但要是没人提出异议,甚至出现支持删除的声音,搞不好管理员真的会删掉……--🔨留言2022年4月9日 (六) 06:12 (UTC)[回复]

修訂封禁方针

原标题为:修訂封禁方针 § 标记用户页

在此提案修訂封禁方针 § 标记用户页

現行條文

标记用户页 对于已被永久封禁的用户,请根据以下程序标记此用户的用户页:

  • 若此用户名具有极端侮辱性(比如需要监督),请务必删除此用户页(如有),并对之进行白纸保护
  • 其他情况下:
    • 若此用户因滥用傀儡或被确认为他人的傀儡而被永久封禁,或在被永久封禁後被查出滥用傀儡或被确认为他人的傀儡,务必以{{sockpuppeteer|blocked}}(对于滥用傀儡的用户)或{{blocked sockpuppet|主帐号}}(对于傀儡帐号)替换原有的用户页内容(如已建立用戶頁)或建立用戶頁(如未建立用戶頁),並对之进行永久全保护
    • 若此用户因其他原因而被永久封禁:
      • 如此用户已建立用戶頁,请以{{blocked user}}替换原有的用户页内容,並对之进行永久全保护。
      • 如此用户未建立用戶頁,請对之进行白纸保护,或以{{blocked user}}建立用戶頁後对之进行永久全保护。
提議條文

标记用户页 对于已被永久封禁的用户,请根据以下程序标记此用户的用户页:

  • 若此用户名具有极端侮辱性(比如需要监督),请务必删除此用户页(如有),并对之进行白纸保护
  • 若此用户因滥用傀儡或被确认为他人的傀儡而被永久封禁,或在被永久封禁後被查出滥用傀儡或被确认为他人的傀儡,请按照傀儡方針的標記一節進行標記;但在處理有愉快犯傾向的持續出沒的破壞者強烈不建議標記為傀儡帳號以拒絕承認,封禁標記則同下方處理
  • 若此用户因其他原因而被永久封禁:
    • 如此用户已建立用戶頁,请以{{blocked user}}替换原有的用户页内容,並对之进行永久全保护。
    • 如此用户未建立用戶頁,請对之进行白纸保护,或以{{blocked user}}建立用戶頁後对之进行永久全保护。

修訂重點:

  1. 將指示指向傀儡方針,以防止指示需要多方面更新;
  2. 明文不建議標記傀儡帳號並拒絕承認

以上。--西 2022年4月8日 (五) 16:09 (UTC)[回复]

以目前SPI的情況,標記和其實差不多,畢竟一打開封鎖日誌上的封鎖原因就能看到主帳號名稱,大多數情況下看上去沒什麼分別。拒絕承認真的能減少愉快犯傾向嗎。--Ghren🐦🕛 2022年4月8日 (五) 16:47 (UTC)[回复]
DENY就是RBI的I啊。我甚至覺得這些愉快犯LTA應該全數私下提報處理,最大幅度減低其曝光度。--西 2022年4月9日 (六) 02:32 (UTC)[回复]
我正在詢問Xiplus能否修改SPIhelper工具以達成在不標記的情況下連封禁原因也不標SPI頁或是哪個的傀儡了。--西 2022年4月9日 (六) 02:34 (UTC)[回复]
假如管理员封禁傀儡理由未表明主账号是谁,{{sockpuppet|主帳號名稱|xx}}里的“主帳號名稱”应该怎么标记?--东风留言2022年4月9日 (六) 05:52 (UTC)[回复]
拒绝承认时不予标记。--Mys_721tx留言2022年4月9日 (六) 15:22 (UTC)[回复]
直接了當不標記為傀儡,如不需要刪除頁面(非G3)就直接{{blocked}}標記即可。另@GhrenghrenMys_721txXiplus已接受並修訂工具,現在不進行標記的傀儡可選在封鎖日誌上也產生不帶有SPI連結的封鎖原因:Special:Diff/71062300。--西 2022年4月9日 (六) 16:07 (UTC)[回复]
目前使用的是过滤器阻止非管理员 非查核助理标记。我个人认为可以学习英文维基,一般封锁的也都不用标记了。只有ban(禁制)的才需要标记。--PAVLOV仁爱亲诚 2022年4月9日 (六) 18:06 (UTC)[回复]
過濾器現在僅留日誌,早前有人提出異議後暫時關掉禁止了。--西 2022年4月10日 (日) 05:31 (UTC)[回复]
最初確實是設計錯誤,不排除重開禁止。--Xiplus#Talk 2022年4月10日 (日) 05:43 (UTC)[回复]
在上次错误地标记非本地存在的用户后,我意识到标记封锁本身都是没有意义的。--PAVLOV仁爱亲诚 2022年4月9日 (六) 18:09 (UTC)[回复]
不認為標記封鎖本身無意義。部分LTA目的不是愉快犯而是宣傳其觀點,這些lta如果標記會讓其他用戶更清楚其編輯傾向--某人 2022年4月10日 (日) 04:43 (UTC)[回复]
对于一些需要WMFBAN的LTA(例如KAGE),标记封锁还是有意义,有愉快犯倾向的还是不能标记。--Lanwi1(留言) 2022年4月10日 (日) 05:03 (UTC)[回复]
(?)疑問。标记用户页不是为了“方便找封禁原因”(对于傀儡的情形,“方便查主账号”),事实上由于封禁日志的存在,模板并不比日志来得更方便。但另一方面,用户页标记以后,可以很容易地通过分类从主账户(特别是LTA的主账户)查傀儡账户,进而了解该用户近期的编辑倾向。如果不标记,有两种替代选择,一是管理员人工将用户加入特定列表(例如,LTA:空间下的页面),但这等于是变相标记,也起不到提案所说的拒绝承认效果;二是依靠封禁日志,由于日志本身没有格式规范(例如,有些管理员喜欢用TW,而本人从来不用TW,只会手动填写封禁理由),只能靠手动检索,远较自动索引的分类为不便。--Antigng留言2022年4月11日 (一) 15:37 (UTC)[回复]
這也是我想問的問題。當然對於LTA自然是應該不理會的,但是標記用戶頁只不過是長長的CU的過程中的最後一個部份,如果不去進行標記的動作可以使LTA的數目減少自然是很好,但是假如平衡日後其他反破壞人員如果要從分類查找傀儡帳號的特徵傾向,我感受到可能真的會帶來不便,假如連用戶日志裏都不留下主帳號是誰:只怕不利於反破壞人員的養成。雖然現在SPI上已經有大部份LTA的記錄,但是在VIP版的上報的就似乎未必會有很好的方式檢查。--Ghren🐦🕛 2022年4月11日 (一) 16:11 (UTC)[回复]
不認同會造成極大的問題,始終建議嚴格實施拒絕承認的也就是個別數個LTA而已,也不是說全部LTA都要求不進行標記。現在要求不標記的就這五個:QCHM、HMGY、KAGE、杨锦桐(非LTA,不開也沒問題)、X43。頭兩個是模仿別人或被模仿,標記也沒太大意義(其實混雜了幾個人了),而後三者基本上到現在還是同樣的幾招,編輯特徵也非常明確,不會分辨不出來;而其餘一般持續出沒的破壞者仍然進行標記。如是要更新反破壞資訊,每次都要從以往帳號再找出來的效率極低,這些是應該精簡地記錄在適當的地方(LTA檔案頁)。另外SPI還是有存檔記錄的,要找不是沒有,這些存檔記錄隨時比分類還齊全,一堆鎖了的帳號不用處理後就放了在那沒建立用戶頁的,不也是沒能記錄。主要是不想將他們導向SPI頁讓他們看着他們那些帳號被抓就棄用哪些帳號;而且他們一般都不會去把SPI頁當成自己的事蹟簿,而是貼心為他們整理好的[開玩笑的]LTA頁。--西 2022年4月11日 (一) 17:21 (UTC)[回复]
管理員看不見你最後一句,下次不要再用了。 囧rz……Ghren🐦🕒 2022年4月11日 (一) 19:05 (UTC)[回复]
我忘了改模板了 囧rz……修好了,現在看到了--西 2022年4月12日 (二) 07:34 (UTC)[回复]
原始碼下都看到了……--紺野夢人 2022年4月12日 (二) 10:25 (UTC)[回复]
首先要他們用原始碼看。--西 2022年4月12日 (二) 10:27 (UTC)[回复]
然后去找链入页面是吗 --185.217.119.37留言2022年4月13日 (三) 01:07 (UTC)[回复]

对台和臺的共识,是否应当应用在抬和擡上

问题 对台和臺的共识,是否应当应用在抬和擡上。
问题背景 当我在查看清齦腭擦音的时候,发现原句“發音時候舌面前部擡起”,在大陆简体下是“发音时候舌面前部擡起”。我查询了一下教育部《重編國語辭典修訂本》 2021,里边称擡是抬的异体字。我本想提请繁简体转换,但是囿于可能违反社群对台和臺的共识,因此来这里提出话题。
我的观点
  1. 首先大陆简体下擡应当转化为抬。
  2. 至于在台湾正体擡和抬如何处理,社群应当有个共识。
条文现状
現行條文

此外,“台/臺”这一对字由于政治原因常常成为修改的对象,由于“台”字虽为俗写,但是在台湾已经广泛使用,因此不应该对其进行手动转换,而是应该遵循先到先得的原则,因为对这些字进行手动转换对条目没有实际的改善作用。

提議條文

--The Puki desu留言2022年4月12日 (二) 08:02 (UTC)[回复]

根據罪刑法定原則Nulla poena sine lege),基本可以確定「抬/擡」並非「台/臺」,故自然不能直接適用「台/臺」的處理辦法。不過,根據同為指引的Wikipedia:繁简处理#勿手動轉換異體字,「抬/擡」符合“在不同的地區,對哪一個字是正體的定義不一樣”的要件,因此“勿手動轉換異體字”的規定已經可以處理「抬/擡」的情況。基於上述廢除條文的提案通過與否都不會影響實際執行的效果,我建議不進行相關修改。Sanmosa Avec cœur 2022年4月12日 (二) 08:59 (UTC)[回复]
但好像台湾也是以“抬”为正体。--The Puki desu留言2022年4月12日 (二) 09:12 (UTC)[回复]
我把簡體的修復請求提報了先(Special:差异/71112756)。--紺野夢人 2022年4月12日 (二) 09:52 (UTC)[回复]

收緊小小作品

現行條文
看到小小作品怎麼辦

(...)

  • 在一個月限期內,未能有人使之成為至少50汉字的小作品,則可將該條目提交存廢討論,實際刪除與否則由存廢討論決定。
提議條文
看到小小作品怎麼辦

(...)

  • 在一個月限期內,未能有人使之成為至少50汉字的小作品,則可將該條目提交存廢討論,實際刪除與否則由存廢討論決定,如果該條目並無擴充可能則應予刪除

明文規定如果無擴充可能則應予刪除。-某人 2022年4月12日 (二) 13:21 (UTC)[回复]