跳转到内容

维基百科讨论:保护方针/存档5

页面内容不支持其他语言。
维基百科，自由的百科全书

提议删去延伸确认保护中要求先半保护的限制

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2023年1月22日 (日) 08:14 (UTC)。

已通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

在LTA:X43中，因已经可以直接确认半保护无效，管理员直接采用了延伸确认保护，引发了一定争议，但在本事件中管理员行为并无过错，是依照常识的正确判断，且有效的阻止了破坏，因此当方针与正确的行为相悖的情况下，我认为如果要使管理员的行事更合规，应对WP:ECP进行类似于如下的修改：

现行条文

管理员仅能在页面已被半保护，且证实半保护仍无法阻止破坏或编辑战的页面上使用延伸确认保护。与半保护相同，不得对尚未发生的破坏或编辑战进行预见性保护，亦不得将延伸确认保护使用于破坏或编辑战以外的页面上，应直接使用全保护（对于模板或模块可用模板保护）。

提议条文

管理员在执行延伸确认保护时破坏情况应比要执行半保护时相对严重，且不得对尚未发生的破坏或编辑战进行预见性保护，亦不得将延伸确认保护使用于破坏或编辑战以外的页面上，应直接使用全保护（对于模板或模块可用模板保护）。

鄙人拙见，只是抛砖引玉，可能还需要更好的措辞。 -- Xi_Ying • Talk 2022年12月24日 (六) 02:58 (UTC)

(＋)支持提案本质但语句不通顺，建议条文：

管理员仅能在页面已被半保护，且证实半保护仍无法阻止可在被未达延伸确认状态的自动确认用户持续破坏或编辑战的页面上使用延伸确认保护。与半保护相同，不得对尚未发生的破坏或编辑战进行预见性保护，亦不得将延伸确认保护使用于破坏或编辑战以外的页面上，应直接使用全保护；于模板或模组可使用模板保护。

除了持续出没的破坏者外，自动确认用户作出的破坏和编辑战不见得必定比非自确严重。--路西法人 2022年12月24日 (六) 04:02 (UTC)
(＋)支持路西法人的版本，英维另外写了一页辅助说明页来补充，或许可以拿过来用。--冥王欧西里斯（留言） 2022年12月26日 (一) 01:42 (UTC)
我们没有ArbCom没用啊……--路西法人 2022年12月28日 (三) 03:12 (UTC)
还是觉得路西法君提案可以再修改一下，“未达延伸确认状态的自动确认用户”很像有点累赘。会不会“非延伸确认用户”就已经足够呢？--J.Wong 2022年12月26日 (一) 03:33 (UTC)
感谢J.Wong君提问。我有考量过这点，“非延伸确认用户”包含连自动确认都不到的用户，仅由非自确用户作出的破坏或编辑战显然不适用延伸确认保护，故只能厘清为“未达延伸确认状态的自动确认用户”。--路西法人 2022年12月26日 (一) 04:11 (UTC)
（还有个小bug，延伸确认实装时已成为管理员的用户是没有延确flag的，所以“非延确”或“未延确的自确”也包括一部分管理员 ——魔琴 [ 留言 贡献 新手2023计划 ] 2022年12月28日 (三) 06:05 (UTC)
管理员破坏或编辑战就完全是另一回事了（（（--路西法人 2022年12月29日 (四) 07:29 (UTC)
@LuciferianThomas：(！)意见:可考虑定为“管理员可在自动确认用户持续破坏或编辑战的页面上使用延伸确认保护。”如此优雅、洁炼之文段，岂不美哉。——WMLO（留言） 2022年12月28日 (三) 23:01 (UTC)
逻辑错误，延伸确认用户也是自动确认用户。延伸确认用户持续破坏或编辑战的页面上使用延伸确认保护吗？您维的一部分人那么喜欢抓字眼，不能留bug给人抓。--路西法人 2022年12月29日 (四) 02:09 (UTC)
话说我原本也是觉得可以简化措辞，幸好我有事先随机选了一位延伸确认使用者确认延伸确认使用者必定同时为自动确认使用者，才没轻易发言惹出笑话来。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年12月29日 (四) 04:49 (UTC)
延伸确认使用者的编辑次数与注册天数要求都比自动确认使用者更高，因此前者必然包含后者。是说为什么自动确认使用者是隐含使用者群组，延伸确认使用者就不是了……。--冥王欧西里斯（留言） 2022年12月29日 (四) 06:35 (UTC)
离题讨论，用户自己对号入座后鲁莽指控他人讥讽。--路西法人 2022年12月31日 (六) 18:27 (UTC)
@Ericliu1912：首先我个人不会将有关言论称之为“轻易发言所惹出的笑话”（见其他不文明行为#讥讽一段），这只是简练与谨慎之间的分歧而已。用Wp:常识角度考虑，假使真的有人使用诸如“啊！延确也是自确，所以您维这样是不对的！”我想大抵会被视作游戏维基规则，从而再吃一个封禁。应对延确破坏，在不考虑逻辑错误的前提下，自然是使用全保护。——WMLO（留言） 2022年12月30日 (五) 09:50 (UTC)
我这儿的“轻易发言惹出笑话来”当然是指自己，毕竟只有严以律己才能严以待人。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年12月30日 (五) 14:52 (UTC)
@Ericliu1912： 很遗憾您在膺任管理员不到三个月的时间，便用了之前一些人的伎俩。无论是先前您为我的失误移动致以维基感谢，抑或“轻易发言惹出笑话来是指自己”，讥讽便是讥讽。不会因您的辩称而有改变。——WMLO（留言） 2022年12月30日 (五) 17:51 (UTC)
啥？另外是“膺”，不是“鹰”。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年12月30日 (五) 17:55 (UTC)
(＋)支持和(！)意见：由于考量方针规范之整体性，以及不同保护层级之层次（“延伸确认保护”是“半保护”的强化保护层级，而管理员使用“延伸确认保护”前，必先理解“半保护”的概念和使用条件），且综合考量针对长期破坏者的实务判断（如Wikipedia:互助客栈/其他#对管理员执行延伸保护的提醒的情形），个人建议条文为：

管理员仅能在页面已被半保护，且证实半保护仍无法阻止可在经证实半保护难以发挥效用破坏或编辑战的页面上使用延伸确认保护。与半保护相同，不得对尚未发生的破坏或编辑战进行预见性保护，亦不得将延伸确认保护使用于破坏或编辑战以外的页面上，应直接使用全保护；于模板或模组可使用模板保护。

个人意见，供参。--Kriz Ju（留言） 2022年12月29日 (四) 20:13 (UTC)
@Kriz Ju：不支持以如此含糊的方式表达，仍然存在可以被抓bug的可能性。--路西法人 2022年12月30日 (五) 02:37 (UTC)
若如此，那么Wikipedia:互助客栈/其他#对管理员执行延伸保护的提醒的情形如何是好？往后是否反倒对管理员掣肘呢？如果严格要求必须先进行半保护，才能进一步提升为延伸确认保护，特定破坏者的情形除了难以应对以外，上述Wikipedia:互助客栈/其他#对管理员执行延伸保护的提醒提及的管理作为是否合乎程序可能就有疑虑了。--Kriz Ju（留言） 2022年12月30日 (五) 18:31 (UTC)
您的提案正正无法解决会被人抓bug说要先半保护的问题。请你从头到尾将前面的留言和建议再读一遍。--路西法人 2022年12月31日 (六) 00:58 (UTC)
关键就是，到底靠什么来证实半保护无效，那显然是管理员的直接判断，而不只是一定要先半保护，得知这一点之后的改法就应该换为支持管理员用常识而非程序来执行延伸保护了。-- Xi_Ying • Talk 2023年1月1日 (日) 01:04 (UTC)
这正是为何必须清楚写成“未达延伸确认状态的自动确认用户破坏或编辑战”。--路西法人 2023年1月1日 (日) 03:10 (UTC)
OK，敝人无甚意见，好读实用即可。--Kriz Ju（留言） 2023年1月2日 (一) 16:51 (UTC)
(＋)支持议案。--FK8438祝您剩蛋快乐（签名）🎄🎄 2023年1月5日 (四) 08:36 (UTC)
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

建议修改保护方针降低转换组模组的保护门槛

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2023年3月4日 (六) 08:14 (UTC)。

已通过：
7天公示期内没有反对意见。--Billytanghh 讨论 欢迎参与亚洲月 2023年3月1日 (三) 02:50 (UTC)
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
Wikipedia:保护方针
现行条文

模板保护

模版保护
模版保护
方针快捷方式

受到模板保护的页面只能由管理员或模板编辑员编辑。但只能用于模板命名空间及模块命名空间。模板保护只适用于被引用的页面超过5,000的高风险模板，也由于风险因素，模板保护相当于全保护。

此保护级别是为了取代仅是高风险模板而受到的全保护而设立。较低风险的模板不适用模板保护，仅能使用半保护。

延伸确认保护

延伸确认保护
延伸确认保护
方针快捷方式

受到延伸确认保护的页面允许延伸确认使用者编辑，该使用者群组会在注册达90天并编辑达500次时自动授予给注册使用者。

管理员可在被未达延伸确认状态的自动确认用户持续破坏或编辑战的页面上使用延伸确认保护。与半保护相同，不得对尚未发生的破坏或编辑战进行预见性保护，亦不得将延伸确认保护使用于破坏或编辑战以外的页面上，应直接使用全保护（对于模板或模组可用模板保护）。

提议条文

模板保护

模版保护
模版保护
方针快捷方式

受到模板保护的页面只能由管理员或模板编辑员编辑。但只能用于模板命名空间及模块命名空间。模板保护只适用于被引用的页面超过5,000的高风险模板，具体的适用条件由高风险模板指引所规定，也由于风险因素，模板保护相当于全保护。

此保护级别是为了取代仅是高风险模板而受到的全保护而设立。较低风险的模板不适用模板保护，仅能使用半保护或延伸确认保护。

延伸确认保护

延伸确认保护
延伸确认保护
方针快捷方式

受到延伸确认保护的页面允许延伸确认使用者编辑，该使用者群组会在注册达90天并编辑达500次时自动授予给注册使用者。

管理员仅可在下列情况使用延伸确认保护：

  1. 被未达延伸确认状态的自动确认用户持续破坏或编辑战的页面
  2. 高风险模板指引规定的特定模板及模组

与半保护相同，不得对尚未发生的破坏或编辑战进行预见性保护，亦不得将延伸确认保护使用于上列条件以外的页面上，应直接使用全保护（对于模板或模组可用模板保护）。

Wikipedia:高风险模板
现行条文

基于下列情况可以考虑使用模板保护：

  • 被引用的页面达到5,000+
提议条文

基于下列情况可以考虑使用模板保护：

  • 被引用的页面达到5,000+，但保存转换组语法的模板及模组[1]除外

基于下列情况可以考虑使用延伸确认保护：

  • 被引用的页面达到5,000+的转换组语法模板及模组[1]

参考资料

  1. ^ 1.0 1.1 大致上为Special:前缀索引/Template:CGroup/及Special:前缀索引/Module:CGroup/，但不包含Template:CGroup/list、Module:CGroup/core等非转换组语法页面。

现时机器人会自动将引用超过5000的模板和模组作模板保护，但亦因此使编辑较多条目使用的转换组模组构成不便。由于模板编辑员人数有限，建议修改保护方针，降低转换组模组的保护门槛至延伸确认保护： --Billytanghh 讨论 欢迎参与亚洲月 2023年2月11日 (六) 10:35 (UTC)

您认为模板编辑员过少，既然制定了模板编辑员并下放原本的全保护模板，那为何不是让想要编辑的人去取得权限呢？现时模板编辑员的授权准则是针对要取得永久权限的使用者所制定，缺乏是否能授权临时权限的共识及指导原则，若能建立取得临时权限的标准，不是能在风险较小的情况下解决积压问题吗？--Xiplus#Talk 2023年2月11日 (六) 11:36 (UTC)
所以说改成高级半保护，让擅长写条目的人去编辑。当然增加便利性会牺牲安全性，但我认为中维负担的起这个代价。毕竟之前转换组一直都是半保护，也没有出过什么事情。模板编辑员是技术职务，而转换组恰恰可以说和技术一点关系都没有，这样看起来很奇怪。或者像我上次说的，新建一个转换组空间，利用“模板保护只能用于模板命名空间及模块命名空间”把5,000引用量自动模板保护的规则架空掉。--洛普利宁 2023年2月11日 (六) 16:22 (UTC)
另外en:Template:WPVG announcements引用量10万才只是延伸确认保护，这要放中维都全保护了。只能说中维逢5,000使用量自动模板保护的教条机制本身就有问题。--洛普利宁 2023年2月11日 (六) 16:33 (UTC)
保护日志显示在2018年有4000引用量的时候也被模板保护了，是为了开放编辑才特许单一页面，而且该模板不使用于条目，对一般读者来说不可见，应不能与转换组比拟，--Xiplus#Talk 2023年2月13日 (一) 03:19 (UTC)
所以说引用量并不是问题，只要有经常编辑的需求，就是十万用量也会放开。而且转换组第一语法简单、第二需要经常变动、第三每条规则只会影响少量含有相关字眼的条目，这导致转换组亦不能同一般模板类比。模板保护实行前多年的实践证明，一般用户就能维护得很好。--洛普利宁 2023年2月14日 (二) 13:06 (UTC)
我不太同意Xiplus的看法，想要编辑的人会受制于其他因素而无法取得权限，因为模板编辑权限涉及的也不止转换组。我还是觉得将所有现时实行模板保护的转换组改为延伸确认保护没那么扰民。Sanmosa Συ γάρ μοι και μοίρα εί και τύχη - Μπαλόνια πρέπει καταστραφούν 2023年2月14日 (二) 08:06 (UTC)
支持。“基于下列情况可以考虑使用模板保护：被引用的页面达到5,000+”，方针说的是“考虑”而非“必须”，我认为转换组可以不在考虑范围之内。高风险模板指引举出的例子都是恶意破坏或低编辑数用户操作，而转换组的语法很规范，借助过滤器完全可以避免很多破坏式编辑。对于转换组高引用问题，我认为用延伸确认保护防御最实际，毕竟鬼祟破坏练个500次编辑的号可是不容易的。既然英维能用延伸确认保护来执行模板保护，那中维没理由非要坚持不能。
PS：如果真要想破坏，找几个引用量4,800的半保护模板乱搞便是。而如前面所说，延伸确认保护+过滤器基本可以解决破坏式编辑。剩下的就是善意编辑错一条规则，然后影响几篇、几十篇条目；而且会编辑转换组的都是老编辑，这种错误的可能性很低。既然我们能承担前者造成的后果，那没理由不能接受后者。--洛普利宁 2023年2月11日 (六) 14:23 (UTC)
支持为转换组加例外，但建议在一定引用数以上的还是用模板保护，毕竟像Module:CGroup/IT这种破万引用（约一万六千个条目）的贸然更改不是件好事--SunAfterRain 2023年2月13日 (一) 10:28 (UTC)
  • 恕直言，想申请也不给的东西，有什么好讨论的？直接编辑请求还比较快吧？反正都懒的管理了对吧？现在这个讨论和专题完全大同小异嘛。延伸确认使用者也不代表就是免死金牌不会被封禁的，以前就讲过了。之所以会被拿出来讨论，这完完全全就是因为根本没有人想管理字词转换处理而衍生出来的一系列问题嘛。请问现在还有人敢申请模板编辑权限吗？独裁的社群，永远不会进步。在前阵子的不留重定向讨论也讲过了，比如常见的theory/model系列，称“理论”或者“模型”都是有人用的），更别提一堆都有使用{{noteTA}}的条目了。那这样为何要“不留重定向”？巡查豁免权有跟没有一样。现在这个讨论，和{{noteTA}}不就是一系列大同小异的问题吗？有什么值得讨论的呢？所以合理判断，说“模板编辑员也是有跟没有一样”完全正确嘛，独裁社群就是喜欢把简单的事情复杂化。--Z7504非常建议必要时多关注评选（留言） 2023年2月13日 (一) 15:42 (UTC)
  • 七天内没新留言，由于大多数参与发言的用户对下调转换组保护门槛没太大异议，现原案公示七天。--Billytanghh 讨论 欢迎参与亚洲月 2023年2月21日 (二) 13:38 (UTC)
    已征询提案人Billytanghh对条文做出修改，理由如下：
    1. 高风险模板指引也有引用量相关规定，需一同修正
    2. 将更详细的规定移到属于子法的高风险模板指引较为合适，也避免一个规定置于两处而在后续修订产生分歧
    3. 未来若要开放更多的模板/模组使用延伸确认保护，只需修订高风险模板指引一个页面即可
    该条文参考自Sanmosa的2022年提案。--Xiplus#Talk 2023年2月21日 (二) 14:48 (UTC)
不反对相关调整，并对相关调整表示欢迎。Sanmosa Συ γάρ μοι και μοίρα εί και τύχη 2023年2月22日 (三) 04:18 (UTC)
不反对，但是编辑者要为自己的编辑负责。 2023年2月23日 (四) 05:23 (UTC)
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

保护及半保护模版是否该说明保护原因与期限？

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2023年11月18日 (六) 08:14 (UTC)。

编辑一个条目，在编辑模式下说这是半保护。好，那就去找找半保护的原因，不要再犯……呃……找不到……

好，不要管原因，耐心等到保护期间结束吧，保护到何时呢？……呃……没有……

啊，模版上说到讨论页留言。……嗯，虽然不知道什么时候才会有人去看，但还是试试好了……呃……讨论页也半保护，还很嘲讽的留同一个模版连到讨论页，递回很好玩吗你们……

所以大家明白为什么有人一发言就骂人了吗？因为被玩弄了啊。

还有，不要再建议去注册了。注册完还是遇到一样问题，只是半保护换成保护而已。况且要有归属感才能引人注册。设置连环的墙给人一撞再撞再来说注册完就可以穿墙对于增加注册意愿来说一点帮助都没有好吗？该做的是在保护或半保护模版上放上确切的理由与时限，不是要人猜，用递回方式嘲讽人好吗？你理由写个我爽，时限写个无限期，都还没现在这么令人生气。

还有，过滤器也有类似要人猜的问题，更过分的是有时还限制猜的次数。不过这是另个议题了。一般编辑都鼓励编者写摘要了，有权保护条目过滤词句的人比一般编者更省事更无责是吧？嗄？

2603:8000:500:FB00:E9B1:8E88:12C3:26A1（留言） 2023年9月25日 (一) 04:01 (UTC)--2603:8000:500:FB00:E9B1:8E88:12C3:26A1（留言） 2023年9月25日 (一) 04:01 (UTC)

一般看历史记录、日志中保护分项（对于没移动过的话一般容易找到）可以找到。——Sakamotosan路过围观 | 避免做作，免敬 2023年9月25日 (一) 06:17 (UTC)
如果可以的话，能否说一下是哪个条目或者页面连同讨论页一并保护？——Sakamotosan路过围观 | 避免做作，免敬 2023年9月25日 (一) 06:23 (UTC)
大概有十几篇条目是这样的待遇。 --MilkyDefer 2023年9月25日 (一) 08:08 (UTC)
@Cwek：仔细看了一下，我觉得这位IP指的非常有可能是条目原神相关争议和讨论页Talk:原神相关争议。参见WP:RFPP。
考虑到我跟那位搞破坏的IP长达一个小时的27RR拉锯战，我坚决反对现在解除这个条目的保护。--MilkyDefer 2023年9月26日 (二) 09:38 (UTC)
就案例的话，没必要解除保护。如果就是否显示更详细保护信息的话，可以看看，不过有点偏技术向了。——Sakamotosan路过围观 | 避免做作，免敬 2023年9月27日 (三) 01:37 (UTC)
保护模板能否提供直接连至保护日志的连结？-- Matt Zhuang表示有事按“此”留言 2023年9月25日 (一) 09:16 (UTC)
可以考虑，引用logid（如果对应到保护日志记录），不过需要工具（例如TW）适配和人员指导注意；另外也要考虑像标题黑名单的“保护”（刚刚技术版展示了这个情况 囧rz……）需要添加说明。——Sakamotosan路过围观 | 避免做作，免敬 2023年9月25日 (一) 09:41 (UTC)
也可以考虑写小作文让mw直接显示被保护的理由--SunAfterRain 2023年9月26日 (二) 10:05 (UTC)
保护日志写得很明白了吧。不过您是怎么从讨论页连到讨论页的？讨论页的“无法编辑”提示没有连到讨论页的链接。“您可以申请解除保护、登录或创建账号”最后那个创建账号可以删了，创建了也没用。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年9月26日 (二) 17:52 (UTC)
那么请问太阳倒数在保护日志的什么地方？当撞上半保护模板时要怎么连过去？如果已经不熟悉这部分了，登出一下，用IP用户的身份按一下编辑不就明白了吗？而上面乱猜还猜错的，了解到被迫去猜的感觉了吗？嗄？2603:8000:500:FB00:4185:1AB2:EF32:8391（留言） 2023年9月28日 (四) 06:22 (UTC)
MediaWiki:Titleblacklist-semiprotected的“该保护使用标题黑名单实施。”不太容易加说明。“您可以和其他人讨论此页。”应该适时禁用，或者正则允许编辑讨论页。“.*[数数]”等影响条目会不会太多。--YFdyh000（留言） 2023年9月28日 (四) 07:13 (UTC)
“您可以和其他人讨论此页。”一句应该在标题黑名单正则能cover到talk page的时候禁用（比如换一个提示叫Titleblacklist-semiprotectied-talkpagedisabled）2023年9月30日 (六) 13:13 (UTC)-- ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年9月30日 (六) 13:13 (UTC)
原来还是标题黑名单的问题……但提示信息已经提到会涉及标题黑名单的“保护”。——Sakamotosan路过围观 | 避免做作，免敬 2023年9月28日 (四) 07:49 (UTC)
很多人不懂正则表达式。并且没有后续流程指引。--YFdyh000（留言） 2023年9月28日 (四) 16:14 (UTC)
所以回到主题，到底要不要大发慈悲的说一下太阳倒数这四个字到底怎么个犯忌？什么机缘下封的？要怎么样才不会重蹈覆辙？到底要封到什么时候？不想给理由能不能至少写个我高兴？不想给期限可不可以至少说是无限期？连讨论页都保护起来可不可以别还摆个您可以和其他人讨论此页嘲弄人？
至少至少至少，太阳倒数在那堆正则表达式的哪一行？有没有注解？有没有人可以修？有没有人想去修？有没有？有—没—有？
再叫我猜，我就要猜是因为最红最红的红太阳才封掉太阳倒数。而且若对维基百科没有爱，早就在这一大堆啰唆之前先好好散布自家的猜想了。所以不要再留些隐语叫人猜了。猜测久了会变猜疑，猜疑久了就变猜忌。到最后各位就会看到有人一上来就莫名其妙的大发脾气，然后各位就很正义的把人给封了。各位一定都遇过这种事。再这样搞下去的话，以后一定还有，莫谓言之不预。2603:8000:500:FB00:691B:A1A:9F86:CE39（留言） 2023年10月5日 (四) 05:39 (UTC)
WP:VPT#神秘的半保护页面，标题黑名单就是这样，没日志。--桐生ここ★[讨论] 2023年10月5日 (四) 06:31 (UTC)
  • “太阳倒数这四个字到底怎么个犯忌？”因为标题含有“数”或者“数”。
  • “什么机缘下封的？”因为WP:X43。
  • “不想给理由能不能至少写个我高兴？”这种规则都是因为破坏者太多了才设立的，就好像清洁工看见垃圾太多了会高兴吗？
  • “要怎么样才不会重蹈覆辙？到底要封到什么时候？”我问一下当时添加规则的管理员。
    • @Xiplus：.*[數数]于2022年加入，既然这位匿名用户回报有误报，是否可以改用过滤器监视呢？这样至少可以留记录。
--砜中嘌呤的白磷萃取 打谱 2023年10月6日 (五) 15:34 (UTC)
这部电影还有其他中文译名，可不可以就用改名的方式避掉“数”呢？至于这种滥杀无辜的一字式封法有多么正义，没这边的事就不用费神解说了。反过来说，如果还要这样封下去，这边就会继续想出自以为是的理由及看来可笑的解方来与已经烦不胜烦的管理员互惹对方生气。2603:8000:500:FB00:F883:820D:283A:460（留言） 2023年10月7日 (六) 05:21 (UTC)
所以，问了没？究竟打算封到何时？
是打算装死到底呢？还是打算实质永封，享受大权在握的感觉？
许多人喜欢以到留言页致欢迎词以表示善意。不过，容我直说，留言一堆所展现的善意，这么一搞就全搞掉了。而所引起的恶感，现在还在生利息。拖得越久，利息越多。某人正在积压引人恶言相向的怒气啊，到底明不明白？一定要逼到别人破口大骂再来强力封号来展现其大权在握吗？我不是想讲话难听，但是多久了？多久了啊？2603:8000:500:FB00:4AC:331C:9232:C206（留言） 2023年10月14日 (六) 05:06 (UTC)
为什么不改名？因为条目命名先到先得。半保护不是全部禁止编辑，反制破坏也不是什么享受大权在握的感觉。我们巴不得破坏者统统改邪归正，反正当站务也没工资拿。成为自动确认用户或者提编辑请求都不是挟泰山以超北海的事，我们完全无意阻止你去做编辑。—-Aggie Dewadipper 2023年10月16日 (一) 17:50 (UTC)
太阳倒数被破坏了吗？没有，所以这不是反制破坏，这是滥杀无辜。不但页面禁止编辑，连讨论页都禁止编辑，而模版还要人到讨论页讨论，有够嘲讽，还要说不是全部禁止编辑来加深嘲讽吗？当站务没工资拿，难道编条目就有？故意讲这个是讲给谁听？改正滥杀无辜不是挟泰山以超北海的事。这边想出了个克难的办法还硬说不行，那提出个未受破坏的条目不受所谓反制破坏波及的好方法好吗？
要不然就改个24小时再改回去也行。其实也用不着那么久，但考量到时区不同，大家保留点弹性。
或者就死赖着不改也行，就说要封多久就好。写个五百年都可以。什么都不留就是故意要永封。你想想现实世界中有谁封什么东西能永封的？什么权力比这还大？
一开始就别逼着人往极端方向走才是正本清源之道。把人逼急了或逼着注册或逼着求人编辑再称之为邪再去巴不得改邪归正，是否...算了，我话到嘴边留半句了。只要求列出要封多久而已，过分吗？2603:8000:500:FB00:9D42:91A5:A7E9:1CA5（留言） 2023年10月18日 (三) 05:36 (UTC)
既然有黑名单，自然有白名单机制：MediaWiki:Titlewhitelist，如果觉得可能误判，找这个。——Sakamotosan路过围观 | 避免做作，免敬 2023年10月26日 (四) 07:29 (UTC)
所以，回到主题，是否该说明保护原因与期限？如果没有写明原因，别人要怎么去猜测能否放进白名单？还不是宁错杀不错放？我有没有说错大家的心态？还是就该巴巴的等到最初这么做的管理员，看他什么时候爱上线，什么时候爱说明，还记不记得当初封的时候是什么原因什么心情？你写程式都要加注解，正则式爱加就加，目的与期限留给别人猜？--2603:8000:500:FB00:9106:C749:44D3:6931（留言） 2023年11月3日 (五) 18:47 (UTC)
两方面的问题：技术上这种保护有手工页面控制和通过标题黑名单控制，后者一般需要配置文件或编辑摘要中注明原因（当然有没明确注明就要看管理员的操作习惯），一来前面有人提及添加相应模式的来源，二来技术上后者没能力显示出明确的原因（不同于前者是有必须填写的原因和控制记录），三来为防止误判还有白名单机制（如果能确认到是后者机制导致的话）。如果有问题，可以提出来，让其他管理员协助处理（判断后者的限制是否还有必要而保留，或者是误判的话加白名单处理先）。——Sakamotosan路过围观 | 避免做作，免敬 2023年11月8日 (三) 02:42 (UTC)
取自“https://zh.wikipedia.org/w/index.php?title=Wikipedia_talk:保護方針/存檔5&oldid=80313788”