打开主菜单

维基百科讨论:保護方針

修改保護方針编辑

提議將「移除明显且无争议地违反法律方针的内容,如明显的侵权内容、儿童色情等。」改為「確保頁面符合任何方針與指引。」爭議的定義是「我不同意你的意見」,甚至如果破壞者不同意我們的意見,都屬於爭議,而這時是不是不能反破壞?故提議修改方針,確保頁面符合任何方針與指引。--M.Chan 2018年3月20日 (二) 09:07 (UTC)

刪掉且无争议地不就好了?如果改成那樣就失去了本來的意義。--【和平至上】💬📝 2018年3月20日 (二) 09:19 (UTC)
破壞行為除了違反法律方針外,亦會違反其實方針。--M.Chan 2018年3月20日 (二) 12:56 (UTC)
  • (-)反对“删掉且无争议”;(-)反对“改为确保符合任何方针与指引”。大多数全保护都是因编辑争议带来的,所谓编辑争议,即是不同用户对同一内容是否符合规则有不同的合理看法。管理员也是普通用户,在遇到争议问题时,也会有自己的看法。但是,管理员绝不能在争议问题上仅凭自己的看法,在未经讨论的情况下修改全保护页面中引起争议的内容,相反,应当提出编辑请求,并取得共识。编辑请求这条路永远是敞开的,“不能反破壞”之说不能成立。维基百科没有最后期限,除了违反法律方针的内容,其他内容任何内容,哪怕事后被证明违反内容方针的内容,作为当前版本临时存在一段时间,没什么大不了的。想想我们处理WP:G3的时候,也没允许管理员在没挂模板的情况下删页面。用户给破坏页面挂上G3模板,就好比在被保护的页面提出编辑请求。如果按照上面两位的说法,删掉“无争议”或者扩大到“确保符合任何方针与指引”,无疑会给管理员带来权力寻租的空间。去年在某个页面普通编辑战,全保护以后,管理员之间继续编辑战。我们可以设想一下,如果按照上面两位这种改法,管理员可以说“我要想办法确保页面符合(我自己理解的)方针要求,因此我可以在全保护以后继续回退而不违反方针”。这怎么可以?
  • 另见Wikipedia_talk:保護方針#检讨页面保护方针

--Antigng留言) 2018年3月21日 (三) 11:15 (UTC)

  • 「不同用戶對同一內容是否符合規則有不同的合理看法。」就是方針指引規定未明的情況,已經不算是違反方針。--M.Chan 2018年3月26日 (一) 08:28 (UTC)
    • 方针指引定明的的要求也不是完全客观的。--Antigng留言) 2018年3月27日 (二) 07:51 (UTC)

兩項事實修改编辑

最近有兩項就《保護方針》及《自傳方針》事實修改,特此通知。七日內如有異議則再議,不然存檔。--J.Wong 2018年4月9日 (一) 11:09 (UTC)

  • 基本上無異議,不過《保護方針》那个的「User」字眼可以把「U」字改大楷,那样似乎看得舒服一點。ŚÆŊŠĀ 2018年4月9日 (一) 12:46 (UTC)

@Wong128hk:七日己過,應已通過,請複查下, 謝謝你--Z7504非常建議必要時多關注評選留言) 2018年4月16日 (一) 23:15 (UTC)

修訂編輯戰及保護方針编辑

應《編輯禁制方針》,已對《編輯戰方針》及《保護方針》作出修訂。謹此通知。如有異議,歡迎提出。--J.Wong 2018年5月16日 (三) 14:18 (UTC)

修訂保護方針编辑

模板編輯員编辑

Wikipedia:保護方針#永久或半永久保护中的“transcluded”是什么意思?编辑

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

原文:“保护MediaWiki的名字空间,以及transcluded的页面,这些页面会影响所有用户的系统界面。”这个单词我没有查到,有些(?)疑問。--相信友谊就是魔法User:萌得不能再萌CuSO4正在努力提高知识水平 2018年6月29日 (五) 12:43 (UTC)

Wikipedia:嵌入包含,已修改。--Xiplus#Talk 2018年6月29日 (五) 13:06 (UTC)
  • 問題已經修整。--J.Wong 2018年6月29日 (五) 13:29 (UTC)

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

1RR的疑問编辑

管理員會否在某些條目實施1RR的限制?--219.79.127.130留言) 2018年6月10日 (日) 10:39 (UTC)

  • 不清楚。如用戶要求在其User talk應用1RR,管理員會奉行。Sæn起舞弄清影 2018年6月10日 (日) 11:16 (UTC)
  • 暫時沒有,不過可以探討一下可行性。--1233( T / C 2018年6月10日 (日) 12:40 (UTC)
  • @Sanmosa:我想該IP是指將1RR原則應用在特定條目中。--B dash留言) 2018年6月10日 (日) 13:00 (UTC)
  • 这不就是英文维基百科条目保护时限制拓展验证用户以上吗?--云间守望上海地铁25周年 2018年6月10日 (日) 13:05 (UTC)
  • @1233B dashWQL:我們或許可以嘗試把1RR或2RR應用於被半保護的條目上。Sæn起舞弄清影 2018年6月10日 (日) 13:14 (UTC)
  • 針對用戶於某頁或某主題回退次數,管理員可藉實施編輯禁制調低次數。但就全體用戶於某頁面回退次數而言,根據《編輯戰方針》,權力在社群,需要社群達成共識方可實施。--J.Wong 2018年6月10日 (日) 17:22 (UTC)
    • 本人正有此意討論之。Sæn起舞弄清影 2018年6月11日 (一) 04:01 (UTC)

以下是本人建議的Wikipedia:保護方針#半保护的新條文:

現行條文

半保护 ...(略)... 讨论页存档保护 ...(略)... 编辑提示保护 ...(略)...

提議條文

半保护 ...(略)... 讨论页存档保护 ...(略)... 编辑提示保护 ...(略)...

受半保護頁面的特殊處理
除非被保护页面是高风险页面、讨论存档保护或出于用户请求,否则凡页面受半保護,原有「回退不過三原則」即被收緊至「回退不過一」,即:凡有用戶在受半保護的页面出现兩次或更多次的回退,无论每次针对的是否是同一段内容,都构成违反“回退不过一”原则。该原则按人计算,不按编辑次数计算;由多重帐号所做的回退按同一人计算。

以上。Sæn起舞弄清影 2018年6月12日 (二) 02:33 (UTC)

  • 我寧願是討論出來的1RR而非方針要求--1233( T / C 2018年6月12日 (二) 11:33 (UTC)
  • あれ~,我沒參與討論呀。到現在我還沒遇到被人回退或是進入編輯戰的情形,不太清楚。應該是影響不到我的條例,無意見。吉太小唯留言) 2018年6月12日 (二) 11:56 (UTC)
对此疑问:
  1. “除非被保护页面是高风险页面、讨论存档保护或出于用户请求”的模糊地带,用户请求(讨论页/用户讨论页/WP:VIP)而被半保护的被破坏页面被排除?因用户请求而被半保护的受匿名用户破坏页面,对注册用户编辑争议也收紧到1RR?
  2. 违背1RR视同3RR封禁?封禁或可预见争议前是否需要警告以提醒收紧到1RR。是否能用技术手段自动悬挂相关提醒(如js识别和插入编辑提示)。
  3. WP:3RR中的不视为一次回退,在条文中未显著彰显。--YFdyh000留言) 2018年6月12日 (二) 12:44 (UTC)
  • 為什麼要這樣收緊?近期發生了什麼事呢?--Temp3600留言) 2018年6月12日 (二) 15:43 (UTC)
  • 在英文維基中,1RR一般只用在易有爭議的條目,例如Donald Trump,並目需要經社群討論及同意才可實行。不建議向所有半保護的條目實行1RR。--B dash留言) 2018年6月12日 (二) 16:01 (UTC)
  • 在下看到相關建議條文後的第一個看法就是YFdyh000君列出的第3點。另請Sanmosa君詳細解釋提出1RR的原因,在下到現在亦未能理解閣下提出1RR議案的原因。坦白一點的說:在下的疑惑在於「凡頁面受半保護」和「原有『回退不過三原則』即被收緊至『回退不過一』」兩句之間的關係在哪兒。為什麼頁面被半保護後需要執行1RR?-- FrancoT 會議廳 訪客簽名區 2018年6月12日 (二) 17:39 (UTC)
  • Sanmosa君,可有回應?--B dash留言) 2018年6月13日 (三) 08:40 (UTC)
  • 或許我稍後另提一案。Sæn起舞弄清影 2018年6月13日 (三) 09:07 (UTC)

第二版编辑

現行條文

半保护 ...(略)... 讨论页存档保护 ...(略)... 编辑提示保护 ...(略)...

提議條文

半保护 ...(略)... 讨论页存档保护 ...(略)... 编辑提示保护 ...(略)...

受半保護頁面的特殊處理
凡受半保護頁面经共识協定,原有「回退不過三原則」即被收緊至「回退不過一」,即:凡有用戶在受半保護的页面出现兩次或更多次的回退,无论每次针对的是否是同一段内容,都构成违反“回退不过一”原则。该原则按人计算,不按编辑次数计算;由多重帐号所做的回退按同一人计算。在实施受半保護頁面的特殊「回退不過一」时,与「回退不過三原則」一样,下述行为并不视為一次回退:
  • 回退自己的编辑(“自我回退”)。
  • 回退在自己用户空间中的编辑,前提是你必须遵守用户页指引。
  • 回退明显的破坏行为,即指任何一个假定他人的编辑出于善意用户都会认为是破坏的编辑,例如清空页面或是添加攻击性语言。
  • 移除明显侵犯著作权,或是毫无疑义违反合理使用方针的内容。
  • 移除明显违反维基百科服务器所在地——美国佛罗里达州法律的内容,例如儿童色情内容或盗版软件。
  • 移除涉嫌诽谤、非中立、无来源或来源不充足,违反生者传记方针的争议材料。對於刪除何種內容可享有生者傳記方針豁免而不受回退不過三限制可能會存有爭議。遇有不清晰或有爭議,則建議先行提報至互助客棧,而非依賴前述豁免。
  • 为了确保在首页展示的典范条目优良条目的质量而进行的回退操作,给予用户一定的自由空间。

以上,@1233B dashShugochara13456Wong128hkWQL五位大鑒。Sæn起舞弄清影 2018年6月13日 (三) 11:27 (UTC)

有共識就好了。--1233( T / C 2018年6月14日 (四) 01:06 (UTC)
  • 我的問題一樣:最近發生了什麼事,導致需要收緊?--Temp3600留言) 2018年6月14日 (四) 05:40 (UTC)
  • 有沒有可能用到這條文的範例?就我理解,半保護是IP與IP(或用戶)編輯戰,如果半保護,IP便不能繼續RR,但如果是兩用戶編輯戰,會直接進全保護不是嗎?吉太小唯Don't Say Lazy.TALK) 2018年6月14日 (四) 06:31 (UTC)
    • @Shugochara13456我提案用來坑自己的WP:BAN已經通過,衆滥权管理員可以設置abusefilter防止用戶编辑。Sæn起舞弄清影 2018年6月15日 (五) 09:41 (UTC)
  • (-)反对. 1RR相关的内容不应该放在这个章节下边,这个章节是讲述如何保护页面的,而不是如何编辑被保护页面的/--Antigng留言) 2018年6月14日 (四) 10:02 (UTC)
    • @Antigng:如果換成放在WP:1RR之下呢?(詳細條文見下)Sæn起舞弄清影 2018年6月15日 (五) 09:27 (UTC)
  • (-)反对,1RR不應只限於半保護的頁面,不過個人(+)支持推行1RR。--B dash留言) 2018年6月14日 (四) 13:14 (UTC)
    • @B dash:本例是參照英文維基百科條目保護時限制拓展驗證用戶以上的1RR。或許閣下可以舉例什麽情況之下也可以應用1RR。Sæn起舞弄清影 2018年6月15日 (五) 09:27 (UTC)

第三版编辑

現行條文

编辑战的处理 ...(略)...

“回退不过三”原则 ...(略)...

其他回退规则 ...(略)...

提議條文

编辑战的处理 ...(略)...

“回退不过三”原则 ...(略)...

其他回退规则 ...(略)...

经共识议定实行回退不過一的页面

凡任何頁面经共识協定,原有「回退不過三原則」即被收緊至「回退不過一」,即:
凡有用戶在经共识议定实行回退不過一的页面出现兩次或更多次的回退,无论每次针对的是否是同一段内容,都构成违反“回退不过一”原则。该原则按人计算,不按编辑次数计算;由多重帐号所做的回退按同一人计算;与「回退不過三原則」一样。在实施经共识议定的「回退不過一」时,例外情況与「回退不過三原則」一样。

以上。Sæn起舞弄清影 2018年6月15日 (五) 09:32 (UTC)

  • 对我来说,这还是没有理顺保护与WP:1RR的关系。为什么“受半保护”是1RR的必要条件?--Antigng留言) 2018年6月17日 (日) 13:48 (UTC)
  • 管理员不应该在全保护的页面上互相回退,是考虑到管理员权限而对应的熟知方针的义务。但是从权限的来源来说,自动确认用户更多地是为了排除滥用而设置的门槛,而不是一种授予的权限。因此,自动确认用户不应该负有比未登录用户更多的义务。半保护只是排除未确认用户编辑而已,因此本人认为要求自动确认用户在半保护页面上1RR是不合适的。 --达师 - 370 - 608 2018年6月19日 (二) 15:44 (UTC)
  • 至少我暂时没看到实施1RR的意义何在。云间守望 2018年6月20日 (三) 17:40 (UTC)
  • @Antigng:这是參照英维進階確认保护而设的,但我还是就地改成3A版好了。@Hat600WQL:承上,已就地修改提案,现时提案就是取決于社羣是否认为某页实行1RR有意义了。Sæn起舞弄清影 2018年6月21日 (四) 10:00 (UTC)
  • 还是没有理清楚。Sanmosa君可否自己阐述一下1RR空降zhwp的意义和必要性?-- Hal 2018年6月21日 (四) 10:14 (UTC)
    • 其实3RR本来就是0RR的折衷,1RR就是促使爭议各方在发生大型争议时必须讨论。不要和我说「WP:沒坏」,在英维extended confirmed protect还是有些用的。SænI'll find a way, or I'll make one. 2018年6月24日 (日) 06:27 (UTC)
      • 我认为是3RR而不是更少的原因是,3RR容易发现和及时制止。而1RR很难发现,多回退一次就会被封禁,反而让冲突双方没有机会讨论,不利于问题解决。 --达师 - 370 - 608 2018年6月24日 (日) 16:19 (UTC)
  • 以下是我对英文维基得extended confirm 30天500参数段落的了解,只有很少数ec protect 的页面实施1rr,这包括
  1. 仲裁委员会裁定的条目,大多与美国政治,或以色列巴勒斯坦冲突,或者是blp.参考ARBPIA/BLP
  2. 社区同意的条目,需要在管理员版提出,也需要得到共识。参考AN或AN/I。

其余的ECP篇章是3rr的。但是英文维基一般不注重rr数,2rr也可能被封,因为编辑战2rr也经常在英文维基提告3rr版,参考ANEW.希望我的观察对讨论有所帮助,如果没有请无需理会,抱歉了--Cohaf留言) 2018年6月25日 (一) 00:52 (UTC)

  • 所以現在是「凡任何頁面經共識協定」,而不是「被半保護的頁面」,可以實行1RR。例如兩岸關係條目,如有需要,可1RR。SænI'll find a way, or I'll make one. 2018年6月25日 (一) 10:40 (UTC)
    • 在英文的维基是这样做的,去看看现在的管理员通告板,拳击项目正在讨论总1rr。这是所谓的群体处分community sanctions。通常是用于非常多编辑战且争议很多的条目。这是仲裁委员会给于社区的权利。但是要在条目清楚警告后,且用户得到通知后才能够惩罚,该条目通常只是4/10保护,因为全部用户多是ec的用户。还有就是需要在讨论页得到共识后才改。--Cohaf留言) 2018年6月25日 (一) 11:02 (UTC)
我也不是非常了解英文维基的一切做法,如果有需要可以向Alex Shih请教,他是英文维基的仲裁员也是管理员。--Cohaf留言) 2018年6月25日 (一) 11:08 (UTC)
  • (-)反对:如果有用戶進行破壞,是否又不能超過一次回退?--屈原蟲留言 2018年6月25日 (一) 12:06 (UTC)
  • (※)注意:如果此指引一旦落實,很容易被封禁;當有人破壞時,誰肯去回退?(動輒得咎)--屈原蟲留言 2018年6月25日 (一) 12:11 (UTC)
  •   說明破坏回退请不要编入1rr内--Cohaf留言) 2018年6月25日 (一) 12:14 (UTC)
  • (!)意見:其實有時是否「破壞回退」,每個人都有不同的解讀,你認為你在反破壞,轉頭就被封禁了。你看回退員雖多,有多少人敢輕用這權限去反破壞?--屈原蟲留言 2018年6月25日 (一) 12:20 (UTC)
英文版处理回退的问题时通常都是不用回退功能,而是总撤消功能,而且在哉要中说明是破坏,并要求用户在讨论面讨论。如果该用户还是不停,报告管理员告状,不再回退。但是他人还是可以回退的,通常如果大多数用户连续回退,就知道坏人是谁了。英文由个 arbitration enforcement ae 板处理这些回退,或者是aiv.我对于1rr毫无看法,只是把英文版的条文翻译到这里而已--Cohaf留言) 2018年6月25日 (一) 12:29 (UTC)
  • 把3rr縮到1rr,其實就是收窄用戶的編輯權限,擴大管理員可以封禁用戶的範圍。大部分管理員都是公正,除非你得罪了管理員,否則管理員不會輕易以這個「合理理由」把你封禁。--屈原蟲留言 2018年6月25日 (一) 12:37 (UTC)

小總結编辑

  • 本人認為並不一定要把1RR納入方針或指引,純粹探討可行性而已。若有用戶認為某條目需要實行1RR,可至WP:VPD提議,達成共識後便可要求管理員實行。--B dash留言) 2018年6月28日 (四) 05:02 (UTC)

(+)支持无需多说什么,同上,但是希望无需像英文版本这么繁琐--Cohaf留言) 2018年6月29日 (五) 15:02 (UTC)

方針小修改︰保護方針编辑

已通過:

先修訂後審議完成,展示已越七日,下列全部修訂通過。--J.Wong 2018年7月5日 (四) 02:15 (UTC)

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


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

增加模板保護编辑

暫時擱置,待模板編輯員的條款全部通過後再提。--B dash留言) 2018年7月16日 (一) 04:35 (UTC)

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

現行條文

“历史只读” ...(略)...

提議條文

“历史只读” ...(略)...

模板保護

模板保護是一個只有管理員及模板編輯員可編輯的保護級別,比全保護稍低。該保護等級通常用於高風險模板模組,該保護等級也可用於其他編輯率極高的頁面。

這個保護級別用於取代非編輯爭議的高風險全保護頁面,模板保護應該用於高風險因素的模板(除了原本就應該被全保護的模板),低風險模板不應被模板保護,理由是模板編輯員的存在,模板保護並非用於使所有模板變得不可編輯。

編者可使用{{Editprotected}}來請求管理員或模板編輯員編輯受模板保護的頁面。

承上,若決定設立模板編輯員,亦需要加入模板保護。--B dash留言) 2018年6月26日 (二) 09:47 (UTC)

暂时挂住,如果TPE整体通过的话,再作为附带条款补充。——路过围观的Sakamotosan | 避免做作,免敬 2018年6月27日 (三) 01:27 (UTC)
如果TPE没启用的话,这个级别和全保护基本重合吧。——路过围观的Sakamotosan | 避免做作,免敬 2018年6月27日 (三) 02:38 (UTC)
  • (-)反对,一如过往讨论所述,无设立该权限的必要。--Antigng留言) 2018年7月1日 (日) 09:09 (UTC)
  • (=)中立 该组成员需要被足够信任又非管理员,以及社群信任他不会径自乱搞、搞乱模板,这不太常见,且一般可以活跃管理员审核、处理取代。是否需工作人员新增权限,是否有技术困难。我认为管理员兼任模板编辑员/小组成员可以满足社群的编辑需求,并更好做到负责任地修改。--YFdyh000留言) 2018年7月2日 (一) 00:06 (UTC)
  • 我高度懷疑有那些熱心用戶有能力擔此要職。--Temp3600留言) 2018年7月3日 (二) 13:52 (UTC)
  • 同意,實在不是很多用戶懂得Lua語言,甚至連提案人和支持提案的人也可能不懂。--219.79.96.183留言) 2018年7月4日 (三) 14:34 (UTC)
  • 我倒想知道Template_talk:Infobox_settlement有管理員肯處理了嗎?沒有人肯處理的話為何不肯放手讓其他用戶處理?JC1 2018年7月6日 (五) 17:55 (UTC)
    • 還是沒有管理員處理嗎?有人和議,經他人code review,還有甚麼原因管理員拒絕處理?如果這是厭惡性工作的話,為甚麼不願放權?JC1 2018年7月9日 (一) 13:37 (UTC)
":為什麼人口密度的連結被移除了?--Xiplus#Talk 2018年7月9日 (一) 14:01 (UTC)" 因為仍有問題未被解決。--Temp3600留言) 2018年7月9日 (一) 14:54 (UTC)
如果我不在這裏提出的話會有管理員留意嗎?我對上一次編輯是5月23日,一個多月來沒有管理員處理正常嗎?那麼要Category:維基百科編輯被保護頁面請求來有甚麼用?JC1 2018年7月9日 (一) 15:30 (UTC)

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

連鎖保護的圖示编辑

User:ShamrockwikieditUser:CopperSulfate均替連鎖保護加入圖示,但遭User:Xiplus反對,故在此討論應否就連鎖保護加入圖示。--B dash留言) 2018年7月15日 (日) 09:05 (UTC)

從未看過該圖示被使用,該檔案也未用於保護標誌模板或是相關介面訊息。--Xiplus#Talk 2018年7月15日 (日) 09:42 (UTC)
也没见过。同xiplus。--Cohaf (请多多关注技术管理员课题)留言) 2018年7月15日 (日) 09:57 (UTC)

更新Wikipedia:保護方針的图示编辑

達成共識:

明顯有共識支持更新WP:PP的圖標,此討論完結。--B dash留言) 2019年1月8日 (二) 09:18 (UTC)

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

保护类型 之前 灰钩 色钩 维数 WQL 图例 willy 小老虎
全保护
本地模板全保护
模板保护(本地無此保護等級)
半保护
创建保护
移动保护
文件保护
待审变更保护(本地無此保護等級)
延长确认保护(本地無此保護等級)
基金会保护
嵌套保护(本地之前未曾使用圖示)
  • 参考英文维基百科更新,图例原作者是User:XYZtSpace。新的图示相比原来单纯的有色锁,增加了类型符号,更加便于辨认,应该不会有人反对。有人愿意给

 全保护,以是中文“全”字制作中文图例嘛? --by viztor 2018年11月14日 (三) 03:29 (UTC)

  • enwiki的变更理由除了好看以外,大多聚集于是新图示可以帮助色盲人士的一点上。by viztor 2018年11月14日 (三) 05:54 (UTC)
  • 确实仅有颜色区别,并不利于区分不同的保护类型。以我自己为例,我常常需要看历史记录或源代码才能确知保护类型,如果使用了小图标的话。对于最常用半/全保护来说,以英文字符作为图标也可,中文的话,想象中应该会更加直观。--Tiger留言) 2018年11月14日 (三) 06:05 (UTC)
  • 试着翻译了两个,其他的我觉得不用动。但是我估计带上汉字的话可能会模糊。   --Mend My Way 2018年11月14日 (三) 08:45 (UTC)
  • 本地沒有為連鎖保護賦予一個圖示,未在任何地方使用,且其保護等級其實等同於全保護。--Xiplus#Talk 2018年11月14日 (三) 11:42 (UTC)
连锁主要是系统给首页的(首页没必要挂这个),其他地方的确很少见连锁保护。——路过围观的Sakamotosan | 避免做作,免敬 2018年11月15日 (四) 00:50 (UTC)
说明页似有相关图示。不过确实有连锁保护的页面,私以为区分清楚直接保护和连锁比较好,不过这不在此议题范围内,如果有相关模板就一并更新了吧by viztor 2018年11月15日 (四) 03:22 (UTC)
先前有一次要使用但無共識,若大家想要使用該圖示,可在本次討論順便加入。--Xiplus#Talk 2018年11月15日 (四) 06:39 (UTC)
(+)支持:新图标挺漂亮的,不过如果有中文版就更好了。--XL-028留言) 2018年11月15日 (四) 02:02 (UTC)
我又增加了一套之前英文版提出的另一套图标方案。个人认为这套图标颜色单一,视觉效果要比新提出的那一套更为明确,如果加上示意图标可能会更好。另外,看到做出的两个中文标识的图标,感觉“全”字还能勉强看清,“模”字需要非常仔细看才能看清,反而减低了视觉效果--百無一用是書生 () 2018年11月15日 (四) 03:32 (UTC)
这个似乎是源自wikidata。by viztor 2018年11月15日 (四) 03:51 (UTC)
同意shizhao的说法。--Mend My Way 2018年11月15日 (四) 08:32 (UTC)
  • 加上了一個本地模板全保護所用的圖示。--Xiplus#Talk 2018年11月15日 (四) 06:39 (UTC)
@Xiplus:阁下是在说WP:保護方針上所述的MediaWiki保护?~ viztor 2018年11月15日 (四) 07:09 (UTC)
鄙人在尝试编辑MediaWiki:Common.css的时候,似乎也没有出现MediaWiki保护的对应标识,怀疑是上古时代遗留的模板,更新之后就没有了,是否考虑废除?不过似与此题无关。参见en:Wikipedia_talk:Protection_policy#RfC_on_new_padlock_design~ viztor 2018年11月15日 (四) 07:13 (UTC)
User:viztor其實該圖示主要還是用模板全保護,見Template:Pp-template。--Xiplus#Talk 2018年11月15日 (四) 07:17 (UTC)
User:Xiplus仔细找了一下,似乎没有发现有在使用pp-template且以红色显示的模板。似乎pp-template会被pp-meta嵌入,所以似乎无法简单通过链入页面找到。不过其类型似乎就是全保护层级,没有要求其他的用户组权限。~ viztor 2018年11月15日 (四) 07:33 (UTC)
通过文件的引用仔细查看了一下,发现“本地模板全保護”图示引用很多,但在方针中的模板保护图示似乎并未使用,怀疑是当初模板误用图示。~ viztor 2018年11月15日 (四) 08:08 (UTC)
User:viztor這些頁面的部分是使用紅色標誌。--Xiplus#Talk 2018年11月15日 (四) 10:37 (UTC)
User:Xiplus粗略看过上述页面,发现很多使用了此模板的并没有使用红色标志,不知为何。参考Special:链入页面/File:Padlock-red.svgSpecial:链入页面/File:Padlock-pink.svg发现红色锁大量使用,而原模板的粉色锁并未使用,感觉新版可以直接以红色模板保护锁替换。 ~ viztor 2018年11月15日 (四) 19:22 (UTC)
該模板會自動偵測保護等級選用圖示。--Xiplus#Talk 2018年11月16日 (五) 03:16 (UTC)
  • 如果能更換那些鑰匙並增加英文代號,會(+)支持--Z7504非常建議必要時多關注評選留言) 2018年11月17日 (六) 03:08 (UTC)
  • 色钩不错。吐槽一下,看习惯了旧图标,新图标虽然显然更加实用但是可能需要认认路……--Super Wang💗团结、友谊、进步WAM2018 2018年11月17日 (六) 13:59 (UTC)
  • (+)支持更换为灰钩+WQL方案。扁平化大势浩浩汤汤顺之者昌逆之者亡维基百科的图标是不是也该换换了。只靠颜色进行分辨太费劲而且对色觉缺陷者不友好。另外汉字大法好,有这样的意音文字的书写系统优势应该好好利用。--Ngguls) 2018年11月19日 (一) 13:47 (UTC)
    • @Ngguls:根据前面的说法,新设计的颜色体系就是为了对色觉缺陷者友好的....--百無一用是書生 () 2018年11月21日 (三) 02:46 (UTC)
      • 只有锁里的文字和图形才是对色盲色弱患者友好的吧……如果采用WQL的文字法,恐怕还要繁简体各来设计一套图标。--Super Wang💗团结、友谊、进步WAM2018 2018年11月21日 (三) 04:53 (UTC)
        • 为什么模板的图标也是圆环?和基金会保护的图标傻傻分不清。--140.180.249.178留言) 2018年11月21日 (三) 15:46 (UTC)
        • 另经查,“全”各地用字相同,“模”右上草头写法有差。--140.180.249.178留言) 2018年11月21日 (三) 15:50 (UTC)
  • 個人支持Minimalist version.--1233( T / C 2018年11月22日 (四) 07:55 (UTC)
 
完整版(2018年11月28日 (三) 11:59 (UTC) by Sunny00217
  • (+)支持用WQL+灰鈎版,但建議半保護也改用漢字。--【和平至上】💬📝 2018年11月22日 (四) 11:14 (UTC)
  • 还是这样,搞一个新的版本,原来的还是保留,参数设置里头搞一个选项,就能够满足要新版本的人的意愿,看不习惯的也可以有旧的看,个人倾向WQL版本。--Cohaf (向我留言/我的贡献) 2018年11月22日 (四) 15:30 (UTC)
    • 提议不错,不过不太确定有没有人会做。~ viztor 2018年11月25日 (日) 03:11 (UTC)

似乎现在(1)更换基本是有共识。待议事项:(2)是否用中文的版本,分歧似乎是中文会太小所以不清晰,简繁有不同。(3)模板保护和本地模板保护(等同全保护,使用Mediawiki保护方针的图标)区别?~ viztor 2018年11月25日 (日) 03:11 (UTC)

  •  的「模」字筆劃多看不太清楚。(?)疑問話說圖示有分繁簡嗎?-- Sunny00217 --維基餐廳開幕了,歡迎參觀。 2018年11月25日 (日) 09:31 (UTC)
    • 實際應該是比較大的,所以應該比較清楚。--【和平至上】💬📝 2018年11月27日 (二) 15:29 (UTC)
      • 有嗎?-- Sunny00217 --維基餐廳開幕了,歡迎參觀。 2018年11月28日 (三) 11:59 (UTC)
      • 错了,实际显示就是这个大小,所以我也不建议模板保护用这个字符版图标。--Mend My Way 2018年11月28日 (三) 14:20 (UTC)
  • 最近製作了    Willy1018(留言) 2018年11月28日 (三) 17:28 (UTC)
    • (-)傾向反對:那三個很像拼圖,維基百科不是拼圖吧  囧rz...--Z7504非常建議必要時多關注評選留言) 2018年12月2日 (日) 14:47 (UTC)
    • User:Z7504其靈感來自File:CiteGadgetButton.png,故因此我設計為模板保護的標示。 Willy1018(留言) 2018年12月2日 (日) 17:09 (UTC)
    • 感觉不太好,在分辨率很低的情况下,这种稍显复杂的图示比汉字更加难以辨识。--Ngguls) 2018年12月6日 (四) 04:32 (UTC)
      • 支持以此为基础进行优化。以拼图作为模板模块的图示算是一种惯例吧(?),相比汉字版本私以为这个更清楚~ viztor 2018年12月21日 (五) 15:40 (UTC)
  • 看了幾次,如果真要改會(+)傾向支持WQL版本,但建議將WQL版本其它還沒做出來的圖示全部做出來,有中文字的鎖比較實際些(比如半保護可以寫「半」)--Z7504非常建議必要時多關注評選留言) 2018年12月7日 (五) 02:02 (UTC)
    • 如果顶上显示图标只有20px大小的话,带上字符会非常非常不清晰,尤其是没有模板样式重新适配(这样子的话可以请界面管理员适配Retina屏幕,用2倍大小的图片)的情况下,我建议锁🔒符号上最好不要有字符。--云间守望 2018年12月9日 (日) 14:47 (UTC)
      • 其实因为更新后图标是svg矢量格式,所以不需要进行人工适配高分屏。~ viztor 2018年12月21日 (五) 15:42 (UTC)
  • (+)傾向支持色钩--苞米() 2018年12月8日 (六) 09:46 (UTC)
  • (+)支持灰钩去掉里面的符号。--№.N留言) 2018年12月9日 (日) 05:53 (UTC)
    • 這就是更換現有的顏色鎖而已[開玩笑的],那這樣不如不要改--Z7504非常建議必要時多關注評選留言) 2018年12月11日 (二) 00:12 (UTC)
      • 我不觉得这样子改等于没改,我提出的本来就没有偏离扁平化这一方向(如果原来那种被你说成扁平化那我没话说了),我希望去掉所有符号是因为我觉得如果上面一定要写东西,统一都用符号更好,英文有不好辨认的弊端,中文有标识太小就难看清楚的弊端,那就只有将全保护、模板保护和基金会保护都换成符号,然而问题就是除了模板保护外我们似乎没找到合适的符号来代替英文字母,所以我就觉得不如不要符号啰。--№.N留言) 2018年12月11日 (二) 03:59 (UTC)
        • 其实全保护的标识可以不要,如果其他的标识都有,也可以达成区分效果。基金会保护由于目前基本没有使用,可以先行更新其他图示后再详议。~ viztor 2018年12月21日 (五) 15:36 (UTC)
  • (+)支持,新版本标识更好看更简洁,建议所有语言版本全部更换。--Shwangtianyuan 呼吁孟晚舟早日释放 2018年12月11日 (二) 17:20 (UTC)
  • 支持使用灰鈎+Willy方案,另外全保護圖示裏面的中文字可以去掉,這樣仍然能辨識不同保護級別。Sæn 2018年12月22日 (六) 07:36 (UTC)
    • 另外也建議把中文維基的本地高風險模板全保護改為英文維基的模板保護,但只改名和改顏色,骨子裏的東西不變(應該相差也不大)。Sæn 2018年12月22日 (六) 07:40 (UTC)
本讨论也进行了一个多月了,看讨论状况似乎对于更换图标是支持的,但是对于“钩应为彩色还是灰色”、“锁内是文字、字母还是图标”存在较大的分歧。个人认为可以开一次投票来解决这个问题,不知各位怎么想。 Stang 2018年12月23日 (日) 02:44 (UTC)
  • (+)支持个人觉得WQL比现在的好看多了,而且既然我们这里是中文维基百科,锁里用中文也应该是理所应当,不过考虑到其他国家的用户可能会前来查阅资料,个人倾向还是用英文字母吧(或者都用也可以,也就是一次加上两个标志,一个英文的一个中文的) 来自一个 温暖的小胖子 ,还有, 胡萝卜 是我CP!(x 2018年12月23日 (日) 06:20 (UTC)
  • (+)支持汉字方案。这是中文维基百科,得有点中文特色--黑暗雄鹰 2018年12月23日 (日) 22:14 (UTC)
    • 不過這樣一來,繁簡字會有爭議。User330.tim留言) 2018年12月25日 (二) 14:52 (UTC)
  • 说实话,用户体验、页面设计搞投票真的不太合适。--百無一用是書生 () 2018年12月25日 (二) 02:28 (UTC)
    • 我也覺得。User330.tim留言) 2018年12月25日 (二) 14:53 (UTC)
      • 为什么? Stang 2018年12月26日 (三) 16:54 (UTC)
  • 我認為圖標應該是最好的方法:使用英文的話,就和中文維基百科的語言不符合;使用中文,就要做繁簡兩套,而且繁體在筆劃顯示上可能過於複雜;圖標則不存在這兩種問題。至少這對任何人而言,既不是meat,也不是poison。Sæn 2018年12月31日 (一) 03:41 (UTC)
    • 繁简不是问题。选用字形一致的字即可。模板的模字都不是问题。--云间守望 2018年12月31日 (一) 03:58 (UTC)
  • (+)支持 图标,灰钩方案。因为保护图示上面加符号更多是为了帮助色盲人士,因此简便即可,我认为并不需要专门显示出中文的特色。灰钩纯属于个人偏好。另外有两个(?)疑問
    • 模板保护(全保护)的定义貌似很乱。在WP:PP上面它不算作一种保护类型,却有一个图标来标识它;主要介绍这种保护的貌似是高风险模板,又主要从背景谈,还加上哪些应该全保护,应该半保护的说明。再加上看这个Template:Protection_Templates,我本就不太懂方针与指引指引的区别,现在更晕了。如果改了图示,不妨把保护方针及其相关内容也改动一下(前面 Xiplus 和 viztor 有讨论过类似的问题)
    • 还是模板保护。又做了一个图示,那么这种类型的图示候选就有这么多种:
  • Template,灰钩

  • Template,色钩

  • 维数

  • 板,WQL,by User:Sunny00217

  • 图标一,by User:Viztor

  • 图标二,by User:willy1018

  • 图表三,by User:小老虎3018

    • 这个设计源于模板常见的用法:{{...|...}}。另外我觉得全保护可以变成唯一一个没有符号的保护图示,因为最基本,且易区别。——小老虎3018留言) 2018年12月31日 (一) 16:55 (UTC)
    也可以看一下fawiki也正在討論 Willy1018(留言) 2018年12月31日 (一) 17:29 (UTC)
    • 波斯语维基的讨论里给出的全保护和基金会保护图标我觉得可以参考一下。--№.N留言) 2019年1月2日 (三) 14:05 (UTC)
    • 我觉得可以用两套。一套带图标的用在消息框里,一套不带图标的用在右上角。带图标的图形放在右上角太小可能不利于辨识,而放在消息框中图形较大,辨识明显(两套图标在设计风格上应该统一,已达到辨识目的)--百無一用是書生 () 2019年1月3日 (四) 02:26 (UTC)
    • 目前討論結果是不是趨向灰勾作為圖案基底? Willy1018(留言) 2019年1月4日 (五) 09:10 (UTC)
    • 图标扁平化当然是好事。(!)意見:俗话说,一图胜千言,我个人更倾向于用简单易懂的图标或被普遍接受的字符而不是汉字,英文等文字来做新图标中间的标志。——明年年初,中美合拍的西游记即将正式开机,文体两开花,请大家多多支持! 2019年1月5日 (六) 13:52 (UTC)

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

    圖標細節的討論编辑

    待續:

    已過一周,但似乎有用戶提供其他選擇,故另開一新討論以獲取更多意見。 补充:就两方案而言。投票结果支持灰钩(英文维基采用版本)7人,倾向2票。汉字符号4票,倾向2票。--B dash留言) 2019年1月16日 (三) 04:19 (UTC)

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

    承上討論,主要的爭論點只剩下採用灰鈎WQL版本(漢字)的灰鈎,及欠缺本地模板全保護的新圖標,現先就先否採用漢字版本的灰鈎投票,為期一週,必要時可延長。--B dash留言) 2019年1月8日 (二) 09:32 (UTC)

    投票需要一定的发起条件,结束时间,公告栏公示……啊…… Stang27 2019年1月9日 (三) 05:06 (UTC)
    已经按照要求发起投票Wikipedia:投票/更新Wikipedia:保护方针的图示 -- VulpesVulpes825 (留言) 2019年1月13日 (日) 19:43 (UTC)
    事实上WQL的方案也是算是灰钩。唯一的不同在于是用图标标示还是中文标示。还是希望将来针对这个问题发起一个更正式点的投票,不过如果是发起正式的投票,可能应该提供更多选择,因为投票往往参与发表意见的人会更多。--№.N留言) 2019年1月9日 (三) 14:05 (UTC)
    所以兩個方案都是灰鉤?下方意見有很多都與灰鉤相關,若二者皆是的話就都沒有意義了。—— Eric Liu留言留名學生會 2019年1月10日 (四) 11:53 (UTC)
    怎么第一个方案会是叫“英文字”呢?这里应该表明是图标或是原版灰钩。--№.N留言) 2019年1月11日 (五) 00:37 (UTC)

    建議明確、詳細說明版本內容(要取個好一點的名字)並放置示例圖片,然後重啟投票;因為兩者似乎都採用灰鉤,但底下特定支持者的理由有八成都是因為該版本有灰鉤⋯⋯—— Eric Liu留言留名學生會 2019年1月11日 (五) 04:02 (UTC)

    版本采用 全保护 模板保护 半保护 创建保护 移动保护 文件保护 待审变更保护 延长确认保护 基金会保护 嵌套保护
    灰钩版本 (与英文维基保持一致)
    WQL版本 (全汉字)

    -已补充对比表格 --VulpesVulpes825 (Talk) 2019年1月13日 (日) 19:04 (UTC)

    採用灰鈎版本编辑

    1. (+)傾向支持,漢字有繁簡爭議及顯示問題。--B dash留言) 2019年1月8日 (二) 09:36 (UTC)
    2. (+)支持灰钩,同时认为锁里面全部用图标标示或者都不标示比用中文或者英文字母好。模板保护内的图标中文维基百科这边已经有设计方案了(然而没决定用哪个),至于全保护和基金会保护里面的图标,波斯语维基百科 commons、fawiki等的讨论给出了不错的方案可供参考。--№.N留言) 2019年1月8日 (二) 13:08 (UTC)刚刚又了解了下感觉这两个图标未必是波斯语原创,可能是commons原创的。--№.N留言) 2019年1月9日 (三) 14:23 (UTC)
      (~)補充:大家别忘了英文版用的“基金会保护”里面的图标就是字母“O”。--№.N留言) 2019年1月9日 (三) 14:12 (UTC)
      (~)補充:对于全保护,我支持使用 ,模板保护支持willy的方案 ,而基金会保护支持 。--№.N留言) 2019年1月15日 (二) 00:17 (UTC)
    3. (+)支持灰鈎+Willy(或Viztor灰鈎化,Viztor那個的符號我比較喜歡)+全保護圖示沒有字符(我的意見近似Liu116,全用符號就可以);其實簡體中文字的筆劃也可繁複的,還要縮小顯示,不同於郵票(郵票就是先放大四倍設計,然後再縮小印刷的,「放大四倍」是一個保險線),這方面我有些顧慮。Sæn請支持近期特色列表評選 2019年1月9日 (三) 09:27 (UTC)
      备注:汉字版本的标志放大了远不止四倍来设计。--云间守望 2019年1月9日 (三) 09:51 (UTC)
      所以我的顧慮更大。Sæn請支持近期特色列表評選 2019年1月9日 (三) 13:36 (UTC)
    4. 其實兩個都反對,沒壞別修,但是真要二選一的話per B dash,(+)傾向支持灰鈎版本-某人 2019年1月9日 (三) 11:11 (UTC)
      User:AINH這個提案並不是「沒壞別修」,而是希望能做到色盲友善。Sæn請支持近期特色列表評選 2019年1月9日 (三) 13:36 (UTC)
      明白,但不改變我的立場-某人 2019年1月9日 (三) 13:39 (UTC)
    5. (+)支持,很多維基都是以此設計為主,已經改變或正在討論fr、fa、commons和en等,目前以灰鈎版本設計居多。 Willy1018(留言) 2019年1月9日 (三) 13:04 (UTC)
      我支持全保護用fa維基所討論的 ,半保護用 ,基金會保護用  Willy1018(留言) 2019年1月14日 (一) 06:24 (UTC)
    6. (+)支持:这几个符号能看懂,也好分别,因此支持符号标识(字母T可能要改一下,O可以看作圆->源->基金会,诡异推测)+全保护无符号。话说,貌似上面都是灰钩的支持?——小老虎3018 留言❄ Flow🗫 2019年1月10日 (四) 16:25 (UTC)
      推论错了,应该是:「O」→「黑洞」→「基金會」,因為我們不知道基金會會做些甚麼出來 Sæn請支持近期特色列表評選 2019年1月11日 (五) 04:43 (UTC)
      “O”有点像基金会或维基百科的标志。--WindowPain留言 | 贡献 2019年1月12日 (六) 15:33 (UTC)
    7. (+)支持:漢字筆畫太多,相信英文字較易辨識。 - まっすろな未来 2019年1月11日 (五) 05:14 (UTC)
    8. (+)支持:一圖勝千言;並支持Willy+全保護沒有字符。--2015leon·) 2019年1月12日 (六) 07:07 (UTC)
    9. (+)支持:最好連英文字都不用,全靠圖案。--Temp3600留言) 2019年1月13日 (日) 17:31 (UTC)
    10. (+)傾向支持除了全保护以外其他都能够通过内部图标简单和快速反映出其具体作用 VulpesVulpes825 (Talk) 2019年1月13日 (日) 18:48 (UTC)
    我更加倾向于这种混合版本
    全保护 模板保护 半保护 创建保护 移动保护 文件保护 待审变更保护 延长确认保护 基金会保护 嵌套保护
    这样既保持简约风格也保证了中文特色,模版采用@Willy1018:因为这是目前正在测试中的模版可视化编辑2017 维基文本编辑器所显示的图标。VulpesVulpes825 (Talk) 2019年1月13日 (日) 18:48 (UTC)
    1. 我个人倾向不还,这个比较接近不换,支持。--COHAF ■ 2019年1月14日 (一) 17:08 (UTC)

    採用WQL版本编辑

    1. (+)支持:我得支持一下自己创作的。放大字号后(见上表),看不看得清的问题已经被解决的差不多了。本地通常以全保护替代一般的模板保护,即使有模板保护,模字在非衬线字体下繁简差异小到可以忽略不计,其他字繁简无区别。--云间守望 2019年1月8日 (二) 10:58 (UTC)
    2. (+)傾向支持:辨识度尚可,文字比图标更直观。--WindowPain留言 | 贡献 2019年1月8日 (二) 16:37 (UTC)
    3. (+)傾向支持,其實只要對站務略熟悉的都大致看得懂標誌的意義,中文不中文其實都沒差,因此我支持地方特色中文標示。另外,對不熟悉站務的人來說,如果採用純顏色,不點進去詳細連結的話其實都是看不懂的。—— Eric Liu留言留名學生會 2019年1月9日 (三) 10:59 (UTC)
    4. (+)支持,1.中文维基不是其他维基的中文版,不要管其他版本怎么用。2.如果用户不懂英文,就看不懂到底是何种保护。--超级王谨贺中文维基导游创立5周年暨突破3000篇旅行指南 2019年1月10日 (四) 11:25 (UTC)
    5. (+)支持,我看好这个版本。意思明确,对新手友好。--1=0欢迎加入WP:維基百科維護專題 2019年1月12日 (六) 03:21 (UTC)
    6. (+)支持:中文维基百科就用中文,而且表达直观明确。--XXXOTC留言) 2019年1月12日 (六) 03:45 (UTC)
    7. 使用中文直观、一目了然。--dqwyy (talk) Guihai Fengyin 2019年1月15日 (二) 02:16 (UTC)

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

    引入模板编辑员和模板保护编辑

    申请人决定撤回申请。原因:目前看来即使有模版编辑人这个职位,可能没有多少人真的会申请。与其继续讨论这个可能没有很多人会申请的职位,先将保护方针内的模板块编辑申请的参考变成正式方针比较妥当。请前往这里继续缩小范围后的讨论-- VulpesVulpes825 (留言) 2019年2月26日 (二) 01:39 (UTC)

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

    我知道这个问题在2018年6月讨论过很多次,具体请参见Wikipedia:常年提案,但我觉得现在是时候重新开始讨论这个问题了,而且我也认为我的观点已经覆盖了之前绝大多数的争议点。

    目前的问题: Category:維基百科編輯全保護頁面請求中关于全保护模板的申请积压的越来越多。并且中文维基百科上很多人没有遵循先沙盒后并入的模板快编辑。

    问题背景: 有管理员说过,{{editprotected}}的瓶颈在达成修改共识,不是没有人去执行这样的共识可以不经讨论修改全保护页面的只有五类情形。而这五类情形所涉的ep请求没有一类是积压的。但现在的问题是管理员经常不理睬一些添加新参数或者增加翻译或者修改bug的编辑申请,这些通常无需共识就可以修改。现在的情况已经严重到明显达成共识的编辑申请也很长时间没有管理员理睬。比如说模块讨论:Template:Delete/data,这个的共识和编辑请求在2/3在本板块达成,然后到现在也没有管理员处理这件事情直到2/11才解决。还有比如Template_talk:湖南卫视我是歌手参赛选手中的姓名编辑请求这个简单的事情也很长时间没有管理员编辑。并且中文维基百科上很多人在编辑大于1000条目引入的模板时直接快速多次在正式模板上进行热编辑,这样做会导致服务器需要多次清除所有使用此模板的条目的缓存,会对服务器造成很大的负担。现在很多高风险模板因为全保护导致无法及时引进新技术,导致年久失修。更加令人绝望的是{{乐意处理EP的管理员}}中的名单里面只有2个管理员,所以所有的EP申请估计猴年马月都没人来解决。

    我的观点:

    1. 引入模板编辑员以便快速处理除站务模板以外的模板编辑申请。模板编辑员可以帮助管理员减少积压工作并且将重心放在更重要的地方。而且模板编辑员专精模板编辑也会是一些模板的主要编辑者,可以比管理员更快找出修改位置并且进行修改,而且可以直接可以使得其他维基人提出需求可以不用提供沙盒版本,模板编辑员可以根据需求自己写。这样就可以防止类似不然就等我有空时我再自己写,那就别抱怨太慢处理了的事情。(注意,这并不代表模板编辑员对其模板拥有Wikipedia:条目所有权)。
    2. 关于模板编辑步骤
      1. 我觉得模板管理员应该在删除参数,新代码会导致明显外观样式,需要合并/删除其他模板保护级模板, 和完全重构代码并且新代码会造成外观和参数变换的情况下需要详尽讨论。无论这些修改是由其他维基人提出或者模板编辑员提出,这些都需要在讨论页上写出修改计划公告后引导讨论至互助客栈。在互助客栈中需要在公告栏邀请讨论并且在互助客栈的技术板块开始讨论,讨论后需要存档回模板/块讨论页。在获得共识或者沉默共识(7天无人回应)后才能修改。修改后必须更新模板/块文档以便反应更新。
      2. 在其他维基人在讨论页提出的编辑申请中如果不属于前面提到的需要详尽讨论的范畴(比如请求添加参数、添加功能、添加或修改信息、合并非模板保护和全保护级的模板),可以在已经获得共识或者沉默共识(3天无人回应)后编辑模板。这个也适用于模板编辑员。模板编辑员也需要在进行无需详尽讨论范畴的修改时在讨论页上写出修改计划公告,并且得到共识或者沉默共识(3天无人回应)后编辑模板。这些讨论无需在互助客栈进行,也不需要在互助客栈公告栏提出。
      3. 模板编辑员在添加参数消歧义(模板快的简繁转换需要手动加入),修复bug, 重构代码但不会造成样式变化或者参数变化的时候在经过沙盒和测试样例后可以直接无需获得共识直接进行修改,但必须在编辑摘要写出编辑了什么。
    3. 关于模板讨论: 如果讨论中有反对者,反对者需要提出具体反对意见(比如说这样做会导致这个参数出现问题),而不是单纯反对(比如说就是不要合并)。为了反对而反对对于讨论没有任何帮助。如果一段时间后(3-5天后)再一次回应反对者后如果反对者不再作出任何回应,且修改不属于需要详尽讨论范畴的话,反对者建议将会变成废票。
    4. 引入模板保护:关于模板保护的等级,我认为500+开始半保护, 5000+以上开始进行模板保护(超过这个数目的话快速热编辑会严重造成服务器负担),1,000,000+进入全保护(在这个阶段的模板/块已经十分成熟,编辑请求也不会很频繁,也就无需模板编辑员进行协助编辑请求), 站务模板保持原样,站务模板可以根据管理员考虑进行模板保护或者全保护。
    5. 关于模板编辑员的授权指引: 我觉得目前Wikipedia:模板編輯員#授權指引比较合适。
    6. 关于滥权行为: 我认为目前Wikipedia:模板編輯員#濫權行為的描述比较合适。

    根据以上观点,我提议在引入模板编辑员和模板保护的时候修改或增加以下条文

    Wikipedia:高風險模板

    現行條文

    这个指引是Wikipedia:保护政策的延伸。其目标旨在保护所有应被维基百科社群认定为高风险模板模块。这些模板和模块应该只被管理员修改,修改之前需要在模板讨论页得到共识。

    (略) 哪些是高风险模板

    保护提议不需要主动反映在一份模板列表上,高风险模板的认定程序,可能是依据个别的共识、由管理员所执行的一套标准、或是基于Wikimedia开发者的请求。

    (略)

    不同條件下的保護方式

    使用全保護的條件:

    • 能見度高的模板及模組
    • 常用,且結構很簡單
    • 連結的頁面達到一定的數量(500+可先半保護,若超過5000+則應考慮全保護)
    • 使用率很高的系統管理站務模板

    另外,基於下列情況,必須使用永久半保護的條件為:

    • 結構複雜的模板及模組(特別是訊息框相關模板,在英文維基上,連結頁面超過一定數量時會被全保護)
    • 維基百科工具模板
    • 使用率較低的管理或站務模板
    提議條文

    这个指引是Wikipedia:保护政策的延伸。其目标旨在保护所有应被维基百科社群认定为高风险模板模块。处于模板保护的模板和模块应该只被模板编辑员和管理员修改,按照这些指南完成修改。处于模板保护的模板和模块应该只被管理员修改,修改之前需要在模板讨论页得到共识。

    (略)

    哪些是高风险模板

    保护提议不需要主动反映在一份模板列表上,高风险模板的认定程序,可能是依据个别的共识、由管理员所执行的一套标准、或是基于Wikimedia开发者的请求。目前中文维基百科上认为链接到5,000+页面的模板默认为高风险模板

    (略)

    使用永久全保护的条件:

    • 連結的頁面達到1,000,000+
    • 使用率很高的系統管理站務模板

    基於下列情況可以考虑使用模板保護的條件:

    • 連結的頁面達到5,000+
    • 能見度高的模板及模組
    • 結構複雜的模板及模組(特別是訊息框相關模板)
    • 維基百科工具模板
    • 使用率較低的管理或站務模板

    連結的頁面低于5,000的可以根据情况使用永久半保護

    Wikipedia:保護方針#頁面保護类型

    現行條文
    提議條文

    模板保护 受到模板保护的页面只能由管理员或模板编辑者编辑。但只能用于模板名字空间模块名字空间。模板保护只适用于高风险模板,也由于风险因素,模板保护相当于全保护。

    这是一个保护级别,它取代了由于是高风险模板而非内容争议而受到全保护。 低风险模板不适用模板保护,顶多是半保护。

    重定向不接受模板保护,只能使用其他保护。

    Wikipedia:保護方針#编辑被保护的页面

    現行條文

    编辑被保护的页面

    (略)

    针对仅因高风险而保护的模板和模块,管理员在处理编辑请求时,应参考此页面所述情况,分别酌情采取立即处理、等待数日无人反对后处理、要求提请至WP:VPT讨论等措施。因管理员未必擅长模板编辑,提出请求者应在沙盒和测试样例中仔细检查待编辑内容,并对其负责。若编辑内容破坏了模板功能,任何管理员均可即时回退是次编辑。

    提議條文

    编辑被保护的页面

    (略)

    针对处于模板保护等级的模板和模块,管理员和模板编辑员在处理编辑请求时,应参考此页面所述情况,采取立即处理、获得共识或者沉默共识后处理和将要求提请至WP:VPT进行详细讨论。编辑请求可以是请求合并沙盒版本也可以是无包涵代码请求。合并沙盒版本将在无争议情况和无问题情况下立即执行。无包涵代码请求在被通过后会由管理员和模板编辑员进行模板编辑,在完成编辑后会回复申请者。如果编辑内容破坏了模板/模块功能,任何管理员和模板编辑员均可即时回退是次编辑。

    Wikipedia:保護方針#比较中的表格更改至

      匿名用户新用户 自動確認用戶確認用戶 模板编辑员 管理员
    无保护 可编辑,不可移動 可编辑及移動
    半保护 不可编辑及移動 可编辑及移動
    模板保护 不可编辑及移動 可编辑及移動
    全保护 不可编辑及移動 可编辑及移動
    移動保护 可编辑,不可移動 可编辑及移動
    半保護 + 移動保护 不可编辑及移動 可编辑,不可移動 可编辑及移動

    不是所有管理员都会模板/块编辑,也不是所有模板编辑员想成为管理员。作为模板编辑员的我只想维护模板,不希望卷入站务事宜。即使这次引入也失败了,我也希望至少管理员在引入失败后多多关注模板编辑申请。-- VulpesVulpes825 (留言) 2019年2月11日 (一) 05:10 (UTC)


    • (+)支持:不過關於第2點,在下認為在討論頁上並不明顯,如有必要應該建立公告頁面。另外,對於不影響原機能的增加功能行為,必須在模板文件頁上更新資訊。--MeritTim留言-給予警告 2019年2月11日 (一) 10:02 (UTC)
      • 同意阁下意见,我将会修改我的观点以便反应这些些问题。-- VulpesVulpes825 (留言) 2019年2月12日 (二) 00:40 (UTC)
    • (!)意見:參見Wikipedia:常年提案-Zest 2019年2月11日 (一) 10:35 (UTC)
    • 這裏我有一個建議,就是在一定時間過後如果反對修訂者沒有再作出任何回應,而修改也不會導致技術問題的話,管理員就可以直接修訂。ΣανμοσαThe Trve Lawe of free Monarchies 2019年2月11日 (一) 13:04 (UTC)
      • 已添加至我的观点。-- VulpesVulpes825 (留言) 2019年2月11日 (一) 22:22 (UTC)
        • 順帶一提:我這個意見在沒有模板編輯員的情況下也可實施,應該也能減少積壓問題。ΣανμοσαThe Trve Lawe of free Monarchies 2019年2月12日 (二) 00:19 (UTC)
    • (!)意見:三天无人回应似乎有些短。七天是不是更好一些?--Techyan留言) 2019年2月12日 (二) 00:27 (UTC)
      • 要不就是重大编辑给7天,非重大编辑给3天。拖时间太长也没意思。-- VulpesVulpes825 (留言) 2019年2月12日 (二) 00:40 (UTC)
    • 大致上(+)支持,不過有關第四項,現時建議500+引用半保護,5000+全保護;建議新增模板保護時仍沿用上述標準,即5000+模板保護,個人認為1,000,000+引用全保護。--B dash留言) 2019年2月12日 (二) 02:44 (UTC)
      • 也是,1000+就开始模板保护的话处理申请太麻烦了。-- VulpesVulpes825 (留言) 2019年2月12日 (二) 03:37 (UTC)
    • 我提几点意见:
      1. 慎用“必须如何如何”这类字眼,例如“必须写编辑摘要”,有时可能就是忘了,又没法任意修改编辑摘要。
      2. 以我的观察,EP长期未得到解决,常常是管理员因各种原因不确定是否应该更新模板,例如争执激烈,要改的东西不确定是否有问题,模板太过复杂需要很多时间测试和修改,用户提出的意见过于含糊。
      3. 模板和模块的复杂程度与所需技术技能也完全不一样,会写模板的未必会lua语言。是否需要分开考虑?
    • --百無一用是書生 () 2019年2月13日 (三) 03:15 (UTC)
      • 我将会根据阁下的意见一个一个回复
        1. 关于必须,这是为了使得方针能够明确指引模板编辑人所需要在编辑前需要做的事情。这些必须十分重要,比如阁下所说的“必须写编辑摘要”,有时可能就是忘了,阁下可以通过在参数设置中的编辑一栏勾选 未输入编辑摘要时提醒我 就可以防止忘记写编辑摘要。模板的编辑摘要十分重要,这可以让其他人知道您这次更改了什么。如果不写的话直接看模板差异需要阅读一定时间才能知道改了什么。这也是github需要在push前先commit的原因。写编辑摘要是写代码的好习惯。
        2. 阁下所说的争执激烈,这就是需要在互助客栈达成共识。关于要改的东西不确定是否有问题,模板太过复杂需要很多时间测试和修改,这就是为什么需要模板编辑员的原因,模板编辑员专注这些测试,这样可以让管理员专注他/她/它们的其他积压工作。关于阁下所说的用户提出的意见过于含糊,这也是正常现象,您不能指望所有人都能够懂得术语,比如将第几行的东西改成什么。我处理过的申请就有XXX出现问题了,能不能看一下,或者增加XXX功能。而且现在很多模板编辑长时间得不到解决更主要的就是管理员其他事情太多了。比如我在前面说的模块讨论:Template:Delete/data,一个明显获得共识的编辑需要超过7天才能回复而且要求申请人自行写。
        3. 关于模块复杂程度,我认为先把模板编辑员和模板保护这个东西先确定下来再说。这个事情都没弄好就开始细分我觉得有点急了。而且精通模块的编辑员也会精通模板,而只会模板的编辑员可以专注模板,分不分没有关系。
      • -- VulpesVulpes825 (留言) 2019年2月13日 (三) 04:44 (UTC)
        • 回應模块讨论:Template:Delete/dataTemplate:Editprotected:「請求時請列明理由及內容」,要求申請人提交內容並無不當,申請人不會寫可以找其他會的人寫,寫完之後再來申請,難道申請人不會,管理員就會了嗎?Wikipedia:保護方針#编辑被保护的页面:「因管理員未必擅長模板編輯,提出請求者應在沙盒和測試樣例中仔細檢查待編輯內容,並對其負責」。管理員不會寫模板一樣可以處理相關的編輯請求,只要有人給出要編輯的內容以及測試樣例,任何管理員應該都能知道這個編輯是能夠運作的,不會弄壞模板。若是還能有其他人協助複查,那麼管理員只需要簡單的複製貼上,根本不用幾分鐘就能處理完。簡而言之,編輯請求是請求編輯這個動作,而不是請求編輯的內容。--Xiplus#Talk 2019年2月13日 (三) 05:54 (UTC)
          • 所以就更应该增加模板编辑员啊(这个事情就是最好的例子了),让会模板的人根据模糊请求写出沙盒然后合并,协助加快处理编辑申请啊?这就是这个职位的初衷啊,让会模板的人处理这些事情然后让管理员去关注其他积压工作啊?而且模块讨论:Template:Delete/data中已经写明了所有讨论和结果和需要更改的内容都在互助客栈了,而且过了多天才有管理员回复要沙盒。-- VulpesVulpes825 (留言) 2019年2月13日 (三) 06:14 (UTC)
          • 还有内容从来没有说一定要是代码,最简单的编辑请求可以只需解释想要什么就可以了(比如请添加Location Map)。代写代码的人只会在这个简单请求通过后才会进行编写,否则编写完然后被拒绝等于浪费时间。既然这样的话,那我提议和这个提议一起的配套修改条文,您可以在我的观点下方看到这个修改提议。-- VulpesVulpes825 (留言) 2019年2月13日 (三) 09:50 (UTC)
            • User:VulpesVulpes825回應「簡單請求通過後才會進行編寫」:這樣來說模板類編輯應該有4個步驟:1. 提出請求主旨(例如增加一個參數) 2. 獲得修改主旨的共識 3. 提出修改的實際代碼 4. 獲得代碼的審核/修改共識。在您看來提出編輯請求應該在步驟2之後,而我認為應該在步驟3之後。模块讨论:Template:Delete/data這個例子正是卡在步驟2之後,而且還沒有人提出編輯請求和代碼(我覺得您舉這個例子並不合理,管理員不一定會關注客棧,簡單來說就是管理員沒有接獲編輯請求)。我對於設立這個用戶組能否改善這個問題仍然抱持懷疑,但我不反對該提案就是了。--Xiplus#Talk 2019年2月13日 (三) 13:54 (UTC)
              • 我在顶上的观点如果根据管理员阁下的步骤的话就是:需要详细讨论的编辑申请在互助客栈提出1和3,在获得2和4后由模板编辑员或者管理员完成操作。如果是不需要详细讨论的编辑申请(比如请求添加参数、添加功能、添加或修改信息、合并非模板保护和全保护级的模板)进入1,然后通过2后如果申请人不会模板/块由模板编辑员或者管理员完成3和4(差不多就是模板编辑员在编辑模板的时候等于拥有巡查豁免权)。小的bug修改等等在模板编辑员自己完成沙盒和测试样例后直接Merge,无需进入任何步骤。这样子直接加快所有申请并且照顾不会模板编辑的申请人。主要是中文维基百科上真的没几个人维护模板了,如果所有小修改都需要有人代写然后还要有第三个人共识的话我真的不知道怎么找到第3个人。这种感觉可以用设计行业的甲方和乙方一样,申请人作为甲方提出要求,模板编辑人根据要求改模板。-- VulpesVulpes825 (留言) 2019年2月13日 (三) 15:23 (UTC)
              • 还有关于管理員不會寫模板一樣可以處理相關的編輯請求,只要有人給出要編輯的內容以及測試樣例,任何管理員應該都能知道這個編輯是能夠運作的,不會弄壞模板。若是還能有其他人協助複查,那麼管理員只需要簡單的複製貼上,根本不用幾分鐘就能處理完。,模板不是简单复制黏贴就能搞定的事情,有些从沙盒复制到正式版需要增加或者删除的。比如阁下帮忙解决的{{Infobox station}}的编辑请求,我已经明确说明了要复制沙盒版本53134293,而管理员阁下复制的是[[Special:Permalink/53145107|由User:Nissangeniss贡献的沙盒版本53134293]],53134293没有经过测试。阁下直接的复制黏贴直接导致此模板用于检查未知参数的模块:Check_for_unknown_parameters直接失效。这个小失误更加体现了需要引入模板编辑员(我没有任何责怪阁下的意思,小错误时有发生是正常的,人类可不是完美的)减轻管理员的积压工作量,特别是帮助不会模板管理员处理这些事情以免出错(我也没有任何质疑阁下对于模板的编辑能力,阁下能够快速回复我并且处理模板申请我已经很高兴了)。-- VulpesVulpes825 (留言) 2019年2月15日 (五) 02:10 (UTC)
                • User:VulpesVulpes825我沒有直接複製貼上,您提供的版本既沒有包含noteTA和Documentation,還多出了template sandbox notice,所以我是分段複製過去的。錯誤的noinclude位置早就存在了,我只是沒有調整到而已。--Xiplus#Talk 2019年2月15日 (五) 02:45 (UTC)
                  • 等一下,我是按照Wikipedia:模板的沙盒和测试样例上面的要求添加{{template sandbox notice}},而且沙盒版本不是不应该有Document吗?关于noteTA,noteTA能够在模板中运行吗?我已经好几次要手动解决转换问题了。-- VulpesVulpes825 (留言) 2019年2月15日 (五) 02:59 (UTC)
                    • 該頁面沒有說要添加template sandbox notice,其說明為「把 Template:A 中的全部原始碼(包含noinclude中的代碼)複製到 Template:A/sandbox 中。然後保存 Template:A/sandbox」,因此Documentation等也應該包含,若是有Documentation,就會自動顯示template sandbox notice了,不需額外加入。另外noteTA的部分,可以在模板使用,但不能透過該模板嵌入條目頁,所以應該包含在noinclude內。--Xiplus#Talk 2019年2月15日 (五) 03:06 (UTC)
                      • OMG,我错了。我本来是打算建立sandbox2然后开始编写代码的,结果准备在sandbox上正式开始写的时候忘记这个事情了(如果在sandbox上写不需要加,但是在页面名称非sandbox上写要添加)。关于noteTA,我得到时候把模板内的语言全部调整至简体中文了,否则noteTA不工作了。还有关于noteTA,如果写noinclude的话就模板就不能使用noteTA了,让阁下删除模块:Check_for_unknown_parameters周边的noinclude就是这个原因。-- VulpesVulpes825 (留言) 2019年2月15日 (五) 03:20 (UTC)
                      • 我已经在沙盒测试过了,将noteTA noinclude模板将不会理睬公共转换组,一定要把它放在includeonly里面才行。-- VulpesVulpes825 (留言) 2019年2月15日 (五) 03:27 (UTC)
    (-)反对: 我沿用上一次的論證:
    • 前提1: 對高風險模板的任何更改都必須進行審計。
    • 前提2: 「審計」意味必須由提出修改以外的人完成。
    • 結論1:任何對高風險模板的更改,都應至少有一人提出,一人和應,才可以更改。
    • 前提3:目前政策下,如有人和應,可以視為獲得修改模板的共識。
    • 前提4:目前有許多EP,連一個和應的人都沒有。
    • 結論2:模板修改員無法處理這些沒有人和應的修改。
    • 結論3:增加模板修改員無助處理問題。
    • 歡迎討論。--Temp3600留言) 2019年2月13日 (三) 07:13 (UTC)
    (:)回應User:Temp3600请阁下至少先看一下我的观点。除了重大修改以外高风险模板的修改没有必要每次都需要审计,比如修改Bug,添加参数之类的根本就没必要审计。即使审计了,阁下要求的「審計」意味必須由提出修改以外的人完成,那么到底谁有资格审计?熟悉模板编辑的人?那不就等于模板编辑员了吗?而且按照阁下说法就是提出修改的人提出编辑申请,然后模板管理员和應并且完成修改,这就完成了阁下的前提1,前提2和结论1需要的过程(阁下没说和應的人不能完成修改,而且Template_talk:Infobox station这个高风险模板管理员就没有按照阁下的结论进行操作,这就说明了阁下的结论可能管理员都不认同)。关于前提3和4,这就是模板管理员所要处理的事,和應并且修改,这就导致结论2以已经解决。关于结论3,Xiplus已经在上面引用了Wikipedia:保護方針#编辑被保护的页面: 因管理員未必擅長模板編輯,提出請求者應在沙盒和測試樣例中仔細檢查待編輯內容,並對其負責,这就是为什么增加模板管理员的问题,解决因某些管理员因不擅长模板编辑导致编辑请求不被回复。-- VulpesVulpes825 (留言) 2019年2月13日 (三) 07:40 (UTC)
    審計這件事情不需要權限。目前的問題是寫代碼和審代碼必須由兩個人完成;假設提出修改的人不懂寫,由模板编辑员代寫了,那他就不可以審計自己寫的代碼。如果提出修改的人已經寫好代碼了,那模板員和應並修改,的確會快一些,但我不認為這是目前EP積壓的主因。
    • 至於另一個核心爭議:「重大修改以外高风险模板的修改没有必要每次都需要审计」,我依然認為再小的修改也要審計——改錯了怎辦?這個是價值觀之爭,無解。我將這一點交給社群決定。--Temp3600留言) 2019年2月13日 (三) 07:58 (UTC)
    User:Temp3600我已经在我的观点说过了,修改需要经过沙盒Fork然后测试样例然后再Merge。而且為再小的修改也要審計就相当于你在公共空间上洗手间还需要向周围的人说声我要上洗手间然后等到有人和应才能去。大家都不是3岁小孩了。而且模板编辑员的要求就是他/她/它们的技术可靠,而且更改都应该在沙盒Fork然后测试样例然后再Merge,在测试样例阶段就可以发现问题了。关于目前的問題是寫代碼和審代碼必須由兩個人完成阁下已经完全误解模板编辑员的职责了,模板编辑员就是判断编辑请求是否合理和是不是需要详尽讨论然后根据需求修改代码。模板编辑员允许使用此权限进行维护,回答合理的编辑请求,并对于模板,模块,以及编辑提示做出合理并无争议的小编辑。他们也被允许在“测试沙盒”中首次进行这些编辑之后,存储更复杂或有争议的编辑。他们的技术以及可靠性,是编者们经过讨论后的共识。不是所有人会模板,要求所有人编辑请求都要将具体哪个位置添加哪个代码写出是不可能的。编辑请求通常就是能不能增加X参数或者功能,请求解决故障。模板编辑员回答这些合理编辑请求后根据编辑请求再写代码。中文维基百科都已经没几个人维护模板/块了,还要第二个人审查向哪里找人啊?虽然这句话可能不。好听,但是有这个职位的英语维基百科就是这个处理方法。我觉得阁下已经误解了编辑请求了,编辑请求不是只有代码才算请求。而且编辑请求都没有通过就开始写代码不是更加浪费所有人的时间吗?写好,测试好然后告诉你编辑请求不合理不是浪费帮助写代码的人的时间和精力吗? -- VulpesVulpes825 (留言) 2019年2月13日 (三) 08:20 (UTC)
    問題:编辑请求不合理是指功能方面(例如模板增加一個功能但沒有共識)還是代碼方面(代碼出錯)?--Xiplus#Talk 2019年2月13日 (三) 14:08 (UTC)
    比如删除参数未获共识,更改样式未获共识,增加参数可以通过{{plainlist}}直接在现有参数增加而不是建立1-n参数,增加的参数违反WP:NOTCATALOGWP:NOTDIRECTORYWP:NOTGUIDEWP:NOTTRAVEL,和提供沙盒版本对应的测试样例有数据丢失和排版错误。-- VulpesVulpes825 (留言) 2019年2月13日 (三) 15:23 (UTC)
    我也认为不可能事事审计,而且还要事前审计。本来wiki的精神之一就是相信用户能做得够好,所以信任模板编辑员也是应有之义。而且任何细致的检查也无法保证100%不出差错,对模板而言,保证不出大问题我认为就足够了。仔细看了VulpesVulpes825的解释,我倾向(+)支持这个方案。另外,如果有顾虑的话,或许不妨只允许修改模块,模板先放一放,不知如何?毕竟从技术上而言,模块要比模板复杂的多,所需的技术技能也要高得多,而中文版会lua又愿意写lua的相比编辑维护模板的人来说,更是少之又少(曾经有几次想修lua,但是看到那么长的代码,就放弃了.....),所以我认为目前模块是最需要人手的,模板还能忍。所以不妨先从最短板的地方做起?--百無一用是書生 () 2019年2月14日 (四) 02:53 (UTC)
    除了語法出錯,其他需要討論的都應該先行討論,而不是立即提出編輯請求,或是編寫代碼,所以不應該有寫完代碼提出編輯請求後遭到拒絕的情況。--Xiplus#Talk 2019年2月14日 (四) 14:11 (UTC)
    这也是我一开始的观点,除了bug修复以外都需要讨论,小的修改在模板/快讨论页,大的修改在互助客栈。我之所以为什么提出模板编辑员的原因是可以直接在完成共识后由模板编辑员完成代码编写与合并,加快共识(包括沉默共识)的处理进度,很多小编辑没必要需要管理员审查,管理员的积压工作已经够多了,小编辑也要就有点用大炮打蚊子了。-- VulpesVulpes825 (留言) 2019年2月14日 (四) 17:51 (UTC)

    • 方针具体条文再看看还有没有要改改的?例如第一个里面建议把“中文维基”改为“中文维基百科”,这个讨论串就要存档了...--及时雨 [ 谈笑风生或批判一番 / 微小贡献 ] 2019年2月22日 (五) 11:51 (UTC)

    (!)意見:还需要具体明确以下几点

    1. 方针中用字应该是模板而非模版吧❓已修改 
    2. 用户组名称:模板编辑还是MediaWiki:Group-templateeditor中为模板编辑者,讨论中为模板编辑员,如果讨论确认为模板编辑员,这里的界面文字该去哪里改 
    3. 添加限制级别:InitialiseSettings.php的wgRestrictionLevels中添加'zhwiki' => array( '', 'autoconfirmed', 'templateeditor', 'sysop' ), 
    4. 用户组权限:
    • 模板编辑员
      • 编辑受保护的模板(templateeditor) 
      • 覆盖标题或用户名黑名单(tboverride) 讨论中未涉及,但似乎尚无必要,若认为有必要请提出
      • 启用双因素验证(oathauth-enable)  讨论中未涉及,但可能有必要,请讨论
      • 删除自己的账户的用户组:模板编辑员  类似的高风险用户组界面管理员并没有删除自己用户组的权限
    • 管理员权限中添加
    U:94rain, 方针用字已经修正。MediaWiki:Group-templateeditor需要叫管理员进行修改。目前英语维基目前没有开启模版编辑员的双因素验证,但这个值得讨论。但这个提案算得到共识了吗? -- VulpesVulpes825 (留言) 2019年2月23日 (六) 23:23 (UTC)
    引入应该是可以?但是还要敲定细节,不知道以上的异议是否已经解决,特别是小修改是否需要审计的讨论似乎还没有明确的结果,但模板保护等级和模板编辑员似乎可以先报P站部署起来了?另外英维确实是开启了2FA,见en:Special:ListGroupRights--及时雨 [ 谈笑风生或批判一番 / 微小贡献 ] 2019年2月24日 (日) 03:37 (UTC)
    U:94rain如果阁下也支持的话,应该就可以算得到共识了吧,即使有两位表示反对的情况下有5人支持。-- VulpesVulpes825 (留言) 2019年2月24日 (日) 18:03 (UTC)
    • (-)反对。先声明利益冲突
    • 正如之前说的,“{{editprotected}}的瓶颈在达成修改共识,不是没有人去执行这样的共识”。仅仅通过举两个个案并不足以推翻这一论点,您必须通过确切的统计数据,证明“已经有明确的修改共识”,但是“因为没有管理员执行”的编辑请求占有可观的比例,才能论证您的观点。现实情况是:1、当前涉及模板的编辑请求中,没有一样经过讨论并且获得明确的修改共识;2、当前积压的大部分编辑请求,皆是涉及编辑争议的棘手请求。如果没有必要,那么就不需要引入一项新功能。
    • 模板编辑员这个方针的核心就是编辑模板的权限。正如上边的讨论中所述,无论是将普通用户的构想转化为实际可执行的编辑,还是检查代码进而表态支持或反对,都不需要任何权限。因此诸如“模板编辑员回答这些合理编辑请求后根据编辑请求再写代码”这样的论证是无效的——你必须提出充分的论据证明“引入权限本身”(乃至后续的“更改高风险模板的保护方式”)会给维基带来显著的改善——然而我并没有看到这一点。
    • 全保护的高风险模板,按照定义通常至少有5000条目引用。相较而言,绝大部分机器人作业申请所涉的条目都不足这个数目。在那里我们尚且要求“必须有另一个了解相关技术的维基人”审查,编辑高风险模板时要求至少有另一个维基人审查代码,进而表态支持/反对,完全不是一个过分的要求。在现实世界中,很多开放源代码的项目都使用git维护,通常说来,开发者可以在trunk版本直接做出修改,但是把这些修改搬回待发行的分支版本时,则通常必须讨论乃至投票,绝无所谓“利用沉默共识”一说。
    • “增加/删除参数”并不必然属于简单而无争议的修改。实际情况是,有一些机器人,比如User:Jimmy-bot标记存废讨论的积压投票时,会直接进行字符匹配。这种情况下不要说增加参数,哪怕是更改两个标签的顺序,都会对这些机器人的工作造成致命的打击。
    • (新观点)在理论上,引入审查小组明显有利于提高机器人的审批速度。然而现实情况是,本站在采用BAG机制以前和以后,机器人审批的速度并无显著的提高。现在讨论的模板编辑员(前面说过)从理论上都不足以保证能够显著提高模板的编辑速度,我就更加有理由怀疑这种提案的实际效果了。--Antigng留言) 2019年2月24日 (日) 16:37 (UTC)
    (:)回應, User:Antigng我已经在之前说过了,有管理员说过,{{editprotected}}的瓶颈在达成修改共识,不是没有人去执行这样的共识可以不经讨论修改全保护页面的只有五类情形。而这五类情形所涉的ep请求没有一类是积压的。但现在的问题是管理员经常不理睬一些添加新参数或者增加翻译或者修改bug的编辑申请,这些通常无需共识就可以修改。现在的情况已经严重到明显达成共识的编辑申请也很长时间没有管理员理睬。还有当前涉及模板的编辑请求中,没有一样经过讨论并且获得明确的修改共识,那么为什么管理员在没有明确共识的时候就同意和完成修改了呢?自己不按照这个标准然后叫别人按照这个标准真的很可笑。还有仅仅通过举两个个案并不足以推翻这一论点,您必须通过确切的统计数据,真的自己去看看Category:已處理的維基百科編輯被保護頁面請求,我都看不下去了。自从2017年后管理员对于EP编辑回应(不管修改不修改,只要管理员回应了我都算努力过了)的处理时间越来越长。例子还有很多,比如Template_talk:Lang#編輯請求_3用了一个半月才有人回复。Template_talk:Infobox_settlement#2017年12月4日在提供沙盒版本后花了七个月,对,七个月才有人回复。
    • 关于但是把这些修改搬回待发行的分支版本时,则通常必须讨论乃至投票,绝无所谓“利用沉默共识”一说,阁下自己都在Template_talk:Infobox_settlement#编辑请求_4中使用沉默共识了,自己用了还在这边说不准用我真的不想在说什么了。而且阁下说用的git维护适逢不恰当,git维护至少可以让大量关于此项目的贡献者加入团队然后协助解决merge,模版编辑员就是类似这类角色(开发者或者大量贡献者)。现在中文维基百科就是类似git,然后把开发者全部不给权限,然后只有管理员(而且很多都不关心或者会模版),这样怎么可能像git一样快速回应呢。
    • 关于“增加/删除参数”并不必然属于简单而无争议的修改。为什么有管理员在Template_talk:Infobox_writer#编辑请求_3中就没有经过任何明确共识就增加了5个参数呢?
    总结就是嘴上说要这样要那样,真正自己做的的时候就各种违反自己的这些“规则”。引入模版编辑员就是为了加快模版EP处理速度,帮助管理员编辑模版,以免出现类似Template_talk:Infobox_officeholder#關於Infobox_officeholder模板中这种管理员乱搞的事情。-- VulpesVulpes825 (留言) 2019年2月24日 (日) 17:49 (UTC)
    • “那么为什么管理员在没有明确共识的时候就同意和完成修改了呢”,“为什么有管理员在Template_talk:Infobox_writer#编辑请求_3中就没有经过任何明确共识就增加了5个参数呢?”这么做是全部是违反保护方针的。按照方针,能直接编辑的就五类情形。包括您指出的我的做法也是违反方针的,我必须向社区诚恳地道歉。但是,经常有管理员违反方针不是倒行逆施扔掉方针的理由——经常有管理员或者回退员使用回退权限回退明显的非建设性编辑,难道就意味着我们可以不要回退方针,想怎么用权限就怎么用?“从来如此,便对么?”
    • “真的自己去看看Category:已處理的維基百科編輯被保護頁面請求,我都看不下去了。自从2017年后管理员对于EP编辑回应(不管修改不修改,只要管理员回应了我都算努力过了)的处理时间越来越长。例子还有很多,比如Template_talk:Lang#編輯請求_3用了一个半月才有人回复。Template_talk:Infobox_settlement#2017年12月4日在提供沙盒版本后花了七个月,对,七个月才有人回复。”,第一,这不叫统计。第二,您举的例子,没有一例是有明确的修改共识然而管理员迟迟不修改的——恰恰相反,这些请求并没有得到其它编者的背书,要么没回应,要么有回应反而提出了质疑。因此这恰恰支持我的观点:编辑请求长时间完不成,完全可能是因为缺乏其它用户的讨论,而不是有充分的讨论但管理员长时间不执行
    • “git维护至少可以让大量关于此项目的贡献者加入团队然后协助解决merge,模版编辑员就是类似这类角色(开发者或者大量贡献者)。现在中文维基百科就是类似git,然后把开发者全部不给权限,然后只有管理员(而且很多都不关心或者会模版),这样怎么可能像git一样快速回应呢。” 上面说过了,讨论投票和移动权限是独立的两个问题。“没有移动的权限”并不意味着“开发者不可以参与讨论或投票支持/反对某笔修订”;因此不给熟悉模板的用户权限,在逻辑上并不意味着“他们将不能参与模板编辑”
    • “引入模版编辑员就是为了加快模版EP处理速度,帮助管理员编辑模版”,总而言之,您提出的论据并不足以证明引入这一权限能显著加快模板的编辑速度。--Antigng留言) 2019年2月24日 (日) 18:20 (UTC)
    USER:-Zest这就是目前的问题,Wikipedia:模板編輯員#修改或讨论这个只是参考,目前还不是共识。Antigng管理员目前根据其回答应该是反对目前的Wikipedia:模板編輯員#修改或讨论。我在我的提案中对这个步骤进行了更多解释。-- VulpesVulpes825 (留言) 2019年2月24日 (日) 21:50 (UTC)
    “这种情况下不要说增加参数,哪怕是更改两个标签的顺序,都会对这些机器人的工作造成致命的打击。”我不认为这有什么问题,有问题的是机器人,而不是修改的用户--百無一用是書生 () 2019年2月25日 (一) 02:26 (UTC)

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

    Wikipedia:模板編輯員#何時需要討論模板修改事宜部分正式引入到Wikipedia:保護方針#编辑被保护的页面编辑

    这个议题是缩小之前引入模版编辑员的讨论范围。

    七日公示內無人提出任何意見;通過。Σανμοσα子罕言利與命與仁 2019年3月12日 (二) 10:14 (UTC)

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

    目前的问题和背景:即使Wikipedia:保護方針#编辑被保护的页面中写明针对仅因高风险而保护的模板和模块,管理员在处理编辑请求时,应参考此页面所述情况,分别酌情采取立即处理、等待数日无人反对后处理、要求提请至WP:VPT讨论等措施。但是由于参考页面并未得到共识,导致目前多为管理员对模板块的编辑申请所采取的行动不一致,比如Template_talk:Infobox_settlement#编辑请求_4Template_talk:Infobox_writer#编辑请求_3。并且有些管理员选择无视此段,且认为酌情采取立即处理、等待数日无人反对后处理、要求提请至WP:VPT讨论等措施全部是违反保护方针

    我的观点:既然保护方针已经写明了请参考,然而参考内容不是方针等于没有。所以应该将Wikipedia:模板編輯員#何時需要討論模板修改事宜的全部内容引入到Wikipedia:保護方針#编辑被保护的页面中成为方针的一部分,而不是参考。关于增加内容您可以在下面的比较条文中查看差异。-- VulpesVulpes825 (留言) 2019年2月26日 (二) 02:16 (UTC)

    現行條文

    编辑被保护的页面 在编辑被保护的页面上,管理员应当特别小心,并于共识和任何相关的指导方针相一致。在任何情况下,管理员应首先确保相应问题已经在讨论页提出,且已取得共识。

    在下列特殊情况除外:

    • 移除明显且无争议地违反法律方针的内容,如明显的侵权内容、儿童色情等。
    • 加入任何保護模板,如{{pp-vandalism}}、{{pp-dispute}}、{{pp-template}}等。
    • 加入准确性无争议和中立性中立的链接,或类似对条目当前状况免除责任的声明。
    • 若页面出现编辑争议需要全保护,管理员可以在执行保护之后,由保护的管理员本人将页面回退到争议发生前的较早版本,如果在争议之前有一个清晰的点。
    • 更正拼写错误和输入错误。

    在编辑持久和半持久保护的页面时需要特别注意。在几乎所有情况下,管理员不应对因法律原因而保护的页面单方面地进行实质性的修改。由于MediaWiki名字空间的页面的可见性和重要性,对于这些页面的修改应该极其谨慎,并且只有那些充分理解修改的后果的管理员才可以修改。

    针对仅因高风险而保护的模板和模块,管理员在处理编辑请求时,应参考此页面所述情况,分别酌情采取立即处理、等待数日无人反对后处理、要求提请至WP:VPT讨论等措施。因管理员未必擅长模板编辑,提出请求者应在沙盒和测试样例中仔细检查待编辑内容,并对其负责。若编辑内容破坏了模板功能,任何管理员均可即时回退是次编辑。

    提議條文

    编辑被保护的页面 在编辑被保护的页面上,管理员应当特别小心,并于共识和任何相关的指导方针相一致。在任何情况下,管理员应首先确保相应问题已经在讨论页提出,且已取得共识。

    在下列特殊情况除外:

    • 移除明显且无争议地违反法律方针的内容,如明显的侵权内容、儿童色情等。
    • 加入任何保護模板,如{{pp-vandalism}}、{{pp-dispute}}、{{pp-template}}等。
    • 加入准确性无争议和中立性中立的链接,或类似对条目当前状况免除责任的声明。
    • 若页面出现编辑争议需要全保护,管理员可以在执行保护之后,由保护的管理员本人将页面回退到争议发生前的较早版本,如果在争议之前有一个清晰的点。
    • 更正拼写错误和输入错误。

    在编辑持久和半持久保护的页面时需要特别注意。在几乎所有情况下,管理员不应对因法律原因而保护的页面单方面地进行实质性的修改。由于MediaWiki名字空间的页面的可见性和重要性,对于这些页面的修改应该极其谨慎,并且只有那些充分理解修改的后果的管理员才可以修改。

    针对因高风险而保护的模板和模块,管理员在处理编辑请求时,应根据以下情况采取相应措施:

    需讨论达成社群共识

    会显著改变该模板或相关模板的功能和显示的编辑,尤其是删除被使用过的功能和参数,都应在互助客栈技术区详细讨论,达成共识后再提出编辑请求,否则应直接拒绝。如:

    • 嵌入该模板的另一高风险模板出现显著变化,或另一任意模板失效。
    • 模板的外观和结构出现显著变化,包括手机版显示的变化。例如:將資訊框的顏色改為粉紅色,表格显示变为段落显示等。
    • 大幅度改动模板功能,包括新增参数和删除曾被使用过的/正被其他页面使用/常用(也就是说弃用不算常用)参数。
    • 将模板的功能使用模组改写。

    需进行公示

    一些会轻微影响使用方式和外观显示的编辑,如代码重构和视觉优化,需在提交编辑请求后等待七天,无争议方可进行修改。如:

    • 添加影響使用方式和外观显示的參數。例如:将命名参数和编号参数相互对应,添加允許外觀上可見到更改差異的任何參數(例如:一個資訊框的顏色參數)。
    • 從外觀上能夠被注意到的,对模板布局的小編輯,例如:交換資訊框中幾個參數的順序,或稍微調整某個部件的顏色。
    • 添加明显无争议的微小参数和功能,例如:italic=yes(改為斜體)和 noprint=yes(不可列印),或是使用维基数据。
    • 稍微影響模板外觀的編輯,例如:使用nowrap<br/>CSSHTML参数或外观类模板。
    • 将说明类模板上的过时信息进行更新。

    可立即进行

    不对模板的使用方式和外观显示做任何修改的有意义的编辑可由管理员确认请求后立即操作。如:

    • 修正明顯的標記錯誤或不會影響模板实际效果的編輯,例如:添加易于阅读代码的注释。
    • 编辑被隱藏分類,或是不该出现在模板本身或被嵌入页面的分类,且无明显争议。
    • 編輯沒有可見效果的CSS類或代码。
    • 在模版末尾后添加{{Documentation}}以便增加说明文档。

    申请编辑被保护的页面

    非管理员的用户可以根据提示,使用{{editprotected}}模板来请求对一个被保护页面的编辑。

    针对仅因高风险而保护的模板和模块,请求者需要给出沙盒版本,以及模板的测试样例并仔细检查其提交的草稿。若没有沙盒版本和测试样例,管理员可直接拒绝编辑请求。需讨论达成社群共识的编辑申请需要提供更新后的说明文档。如果申请者无法提供沙盒版本,可以在互助客栈技术区请求他人协助编写沙盒版本。编辑完成后,若修改内容破坏了该模板或嵌入该模板页面的功能和显示,任何管理员均可回退本次编辑,并在讨论页注明。


    讨论区编辑

    • 大致(+)同意,但也建議同時顧及類似Wikipedia:互助客栈/条目探讨#Template:TalkendH新增「允許合併」參數的情況,如果已經在先前有共識,即使是得出共識後才掛{{editprotected}},除非有可能造成技術問題,否則也應毋須另行討論,直接執行(尤其是在先前討論有列出patch的情況下)。ΣανμοσαThe Trve Lawe of free Monarchies 2019年2月26日 (二) 11:00 (UTC)
    • “针对仅因高风险而保护的模板和模块”之前的部分有修改吗?我似乎没看出差别,建议如果是修改了原来已经存在的条文,用{{新增條文}}和{{删除条文}}显示差异,新加入的就不必了。--及时雨 留言 2019年2月26日 (二) 13:05 (UTC)
    • 这部分内容貌似是将原页面的内容基本复制过来了?也看到有部分修改,但感觉描述仍不太简洁。

    针对因高风险而保护的模板和模块,管理员在处理编辑请求时,应根据以下情况采取相应措施:

    需讨论达成社群共识

    会显著改变该模板或相关模板的功能和显示的编辑,尤其是删除被使用过的功能和参数,都应在互助客栈详细讨论,达成共识后再提出编辑请求,否则应直接拒绝。如:

    • 嵌入该模板的另一高风险模板出现显著变化,或另一任意模板失效。
    • 模板的外观和结构出现显著变化,包括手机版显示的变化。例如:將資訊框的顏色改為粉紅色,表格显示变为段落显示等。
    • 大幅度改动模板功能,包括新增参数和删除曾被使用过的/正被其他页面使用/常用(也就是说弃用不算常用)参数。
    • 将模板的功能使用模组改写。

    需进行公示

    一些会轻微影响使用方式和外观显示的编辑,如代码重构和视觉优化,需在提交编辑请求后等待七天,无争议方可进行修改。如:

    • 添加影響使用方式和外观显示的參數。例如:将命名参数和编号参数相互对应,添加允許外觀上可見到更改差異的任何參數(例如:一個資訊框的顏色參數)。
    • 從外觀上能夠被注意到的,对模板布局的小編輯,例如:交換資訊框中幾個參數的順序,或稍微調整某個部件的顏色。
    • 添加明显无争议的微小参数和功能,例如:italic=yes(改為斜體)和 noprint=yes(不可列印),或是使用维基数据。
    • 稍微影響模板外觀的編輯,例如:使用nowrap<br/>CSSHTML参数或外观类模板。
    • 将说明类模板上的过时信息进行更新。

    可立即进行

    不对模板的使用方式和外观显示做任何修改的有意义的编辑可由管理员确认请求后立即操作。如:

    • 修正明顯的標記錯誤或不會影響模板实际效果的編輯,例如:添加易于阅读代码的注释。
    • 编辑被隱藏分類,或是不该出现在模板本身或被嵌入页面的分类,且无明显争议。
    • 編輯沒有可見效果的CSS類或代码。

    使用和处理编辑请求

    非管理员的用户可以根据提示,使用{{editprotected}}模板来请求对一个被保护页面的编辑。

    针对仅因高风险而保护的模板和模块,请求者需要给出模板文档的更新版本,以及模板的测试样例(如果需要)并仔细检查其提交的草稿。若没有更新文档和必要的测试样例,管理员可将不重要的编辑请求搁置。编辑完成后,若修改内容破坏了该模板或嵌入该模板页面的功能和显示,任何管理员均可回退本次编辑,并在讨论页注明。

    • 描述可能还是不太完善,但睡觉要紧。和上文相比,有几个需要讨论的地方:模板除了在技术区进行讨论,是否还有可能在条目探讨区?第二大点直接设置为公示,公示几天,要在显眼的地方(而不是请求更改分类)公示吗?模板中的维基数据是什么?另外可能有争议的地方用新增条文给出。
    • 还有一个和讨论可能无关的小问题,条目历史里面的模板使用,显示的时候会受后续模板调整的影响吗?——小老虎3018 2019年2月26日 (二) 17:09 (UTC)
      • 使用维基数据的模板有{{Authority_control}}、{{官方网站}},这类模板修改时主要是要考虑到先前页面中使用模板自带参数的情况(如果调用维基数据可不带参数),要设置若自带参数则不调用维基数据。页面历史里面的模板使用,显示的时候会受后续模板调整,所以之前很多铁路模板合并然后提删我是建议都改成重定向。模板讨论理论上是在条目探讨的,“本页面是条目、模板、主题相关的探讨”,我的设想是在条目探讨之外另行设置一个“页面探讨”,毕竟条目探讨板块实在太长了,其中的模板讨论不少--及时雨 留言 2019年2月27日 (三) 03:31 (UTC)
        • @94rain:感谢解惑。其实条目讨论和其他几个活跃的讨论区内容长度差不多,就是有些时候几个模板的样例一放上去就显得长了不少;如果考虑页面讨论,则可将模组、帮助、站务而非方针(如新条目创建相关)这些内容放进去,条目讨论就专注于条目和分类。另外关于页面历史,能否考虑给所有历史版本存一个完全解析嵌入的版本以供显示,从而解决旧版兼容问题;但这样可能会导致服务器存储内容爆炸。——小老虎3018 2019年2月27日 (三) 16:20 (UTC)
      • 我除了请求者需要给出模板文档的更新版本若没有更新文档和必要的测试样例,管理员可将不重要的编辑请求搁置之外都同意。更新文档都得在完成EP后才能更新。在沙盒内通常是直接挂{{Document}}来链接目前的说明文档,这样{{Document}}会自动挂沙盒提示模版。而且管理员可将不重要的编辑请求搁置中的不重要可以让管理员根据这条拒绝掉代码重构和所有需进行公示和可立即进行的EP。我强烈建议删除这段话。关于互助客栈详细讨论,我建议在技术区,而且我也建议将所有模版讨论移动到技术区,否则条目探讨区讨论内容太多了。还有如果阁下同意的话,能否容许我将阁下的新描述移动到我的提案内?-- VulpesVulpes825 (留言) 2019年2月28日 (四) 17:33 (UTC)
        • 更新文档应该要提前给出来,否则怕等请求接受后原编辑者已经忘了这事,有参数更改还得要其他人花时间写文档。第二句话确实不严谨,就删掉吧。模板除了技术更多的还是配合条目内容的显示,有争议需要达成共识的地方一般不会是代码怎么写……所以我还是偏向于创立一个“页面探讨”区?移动过去没问题。(回复时请ping我,谢谢)——小老虎3018 2019年3月1日 (五) 16:28 (UTC)
          • 或許這樣,我指定一個doc更新版的標題命名格式:Template:Example/doc/更新草案2019,這樣會不會好些?另:不太支持没有doc更新版時管理员可将不重要的编辑请求搁置,但支持沒有patch時可搁置,因為實在太多人都忽略了patch的重要性(patch可以直接顯現修改是否有問題)。Σανμοσα子罕言利與命與仁 2019年3月2日 (六) 09:43 (UTC)
            • 我建议使用Template:Example/sandbox/doc/就可以了。我觉得除了需讨论达成社群共识的修改需要更新版说明文档,其他两个应该都可以不需要。我觉得应该所有模版块EP都要patch。-- VulpesVulpes825 (留言) 2019年3月2日 (六) 17:44 (UTC)
        • User:小老虎3018我建议修改成这样:针对仅因高风险而保护的模板和模块,请求者需要给出沙盒版本,以及模板的测试样例(如果需要)并仔细检查其提交的草稿。若没有沙盒版本和测试样例,管理员可直接拒绝编辑请求。需讨论达成社群共识的编辑申请需要提供更新后的说明文档。如果申请者无法提供沙盒版本,可以在互助客栈技术区请求他人协助编写沙盒版本。编辑完成后,若修改内容破坏了该模板或嵌入该模板页面的功能和显示,任何管理员均可回退本次编辑,并在讨论页注明。-- VulpesVulpes825 (留言) 2019年3月2日 (六) 19:35 (UTC)
          • (:)回應:没有问题,“如果需要”的范围可以细化到若涉及外观和参数的修改,范围为显著修改和一般修改而不包括轻微/显而易见的类型。另外这整个段落可以考虑改为编辑被保护的页面使用和处理编辑请求。——小老虎3018 2019年3月4日 (一) 15:19 (UTC)
            • (:)回應User:小老虎3018我觉得还是强制提供测试样例比较好。这样管理员可以方便确认小修改没有出现显示问题,大修改可以看出到底参数和外观被改的怎么样了。我同意阁下将标题改为编辑被保护的页面使用和处理编辑请求。我在等个2天,如果没有异议就进入7天公示了。-- VulpesVulpes825 (留言) 2019年3月5日 (二) 01:05 (UTC)

    哎,不是公示结束以后才{{archive top}}吗。——小老虎3018 2019年3月6日 (三) 17:39 (UTC)

    @VulpesVulpes825:七日已過,可以更新條文了。Σανμοσα子罕言利與命與仁 2019年3月12日 (二) 10:14 (UTC)


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

    提议修改保护方针编辑


    通过,且修订完成。--泡泡小号028留言) 2019年5月9日 (四) 05:14 (UTC)

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

    保护方针

    現行條文

    中文维基百科的页面保护类型包括:

    • 全保护:阻止所有非管理员编辑页面;对于文件,一般用户则不能够上传新的版本。
    • 半保护:阻止所有匿名用户以及自动确认用户、非確認用戶辑页面。
    • 白纸保护:阻止某一页面(一般是被删除的页面)被创建。
    • 移动保护:阻止某一页面被移动
    • 文件保护:阻止文件被恶意上传,但是图像描述页并不会被保护。
    提議條文

    中文维基百科的页面保护类型包括:

    • 全保护:阻止所有非管理员编辑页面;对于文件,一般用户则不能够上传新的版本。
    • 半保护:阻止所有非自動確認用戶、非確認用戶编辑页面。
    • 白纸保护:阻止某一页面(一般是被删除的页面)被创建。
    • 移动保护:阻止某一页面被移动
    • 文件保护:阻止文件被恶意上传,但是图像描述页并不会被保护。

    匿名用户是非自动确认用户的子集,我认为无需重复提及。大家觉得怎么样?--泡泡小号028留言) 2019年4月26日 (五) 14:57 (UTC)

    (!)意見先不講方針合理不合理,就是技術上也做不到。--蟲蟲飛♡♡→♡℃留言 2019年4月26日 (五) 15:26 (UTC)
    另外其实确认用户也可以也可以编辑半保护页面,见Special:群组权限。--及时雨 留言 2019年4月27日 (六) 09:34 (UTC)
    確認用戶方面已事實性修訂。另(+)支持去除「匿名用戶」此多餘子集。Σανμοσα y=0 regardless the value of x 2019年4月27日 (六) 12:41 (UTC)
    (?)疑問:即使方針指引通過,ip技術上應該還是不能編輯半保護的頁面;相反,如果技術上可行,為甚麼要允許ip編輯受半保護的頁面?--蟲蟲飛♡♡→♡℃留言 2019年4月27日 (六) 13:17 (UTC)
    这个提案的意思应该是:IP属于非自动确认用户,无需多言?--及时雨 留言 2019年4月27日 (六) 15:45 (UTC)
    @蟲蟲飛:您是否理解有误,只是字词修订,并无规则变化。“非自动确认用户”是包含IP用户的,他们无法被“自动确认”。--YFdyh000留言) 2019年4月27日 (六) 16:36 (UTC)
    支持修订,重复。“匿名用户”本身也是歧义、多义的,平常应该称IP用户或未注册用户。--YFdyh000留言) 2019年4月27日 (六) 16:36 (UTC)

    此提案将公示七天,若无合理异议,则视为通过。--泡泡小号028留言) 2019年5月1日 (三) 04:03 (UTC)

    • (?)疑問@泡泡小号028:那「非確認用戶」這句也可以刪除吧?--Z7504非常建議必要時多關注評選留言) 2019年5月3日 (五) 13:47 (UTC)
      • @Z7504:不可以,确认用户是类似自动确认用户的另一种用户权限级别,两者都有编辑半保护页面的权限。若删除,则确认用户对半保护页面的编辑将“不合法”。--泡泡小号028留言) 2019年5月6日 (一) 00:58 (UTC)

    通过。--泡泡小号028留言) 2019年5月8日 (三) 00:58 (UTC) 修改完成。--泡泡小号028留言) 2019年5月8日 (三) 02:07 (UTC)


    本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
    回到项目页面“保護方針”。