维基百科:互助客栈/其他
发表前请先搜索存档,参考旧讨论中的内容可节省您的时间。 |
|
- [投票] 2024年5月管理人员申请投票正在进行中,参见投票列表,欢迎踊跃参与。
- [投票] 2024年5月关于仲裁委员会的调查问卷正在进行中,参见投票页面,欢迎踊跃参与。
- [公告] 互助客栈正在对于Unblock-zh.org的各项细节征求意见。
- [公告] 再拟设立文化遗产关注度指引、将地理特征关注度指引中有关道路的部分改为在交通关注度指引中列出及修改RFA流程相关规定已经通过。
- [公告] 再拟设立国际关系命名常规为方针正在公示,如有意见请尽快提出。
- [讨论] 目前有涉及禁止在互助客栈条目探讨区发起部分类型讨论的重大政策提案仍在讨论。为确保您的意见及权益获得充分反映,请踊跃参与规范讨论发起步骤讨论。
- [讨论] 有用户正就重修破坏方针征求社群意见,请踊跃参与讨论。
- [讨论] 互助客栈方针区正在讨论电视条目播放信息增加收录准则,请踊跃参与讨论。
- [讨论] 互助客栈技术区正在讨论更改未登录用户的默认字体大小及增加外观选单及ToolsRedirect创建的繁简重定向问题,请踊跃参与讨论。
- [讨论] 互助客栈其他区正在讨论页面评级与通用评级行政层面上的统合方案及将法轮功及台湾政治订为高风险主题,请踊跃参与讨论。
- [广告] 第二十二次动员令将于7月6日至9月8日间举行,现正在提议、协调主题及募集主持人,欢迎踊跃参与!
- [广告] 维基百科非洲月现正举行,直至6月30日完结,欢迎踊跃参与!
存档 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
# | 💭 话题 | 💬 | 👥 | 🙋 最新发言 | 🕒 (UTC+8) |
---|---|---|---|---|---|
1 | 没有主题的页面如何评级 | 190 | 12 | Ericliu1912 | 2024-06-03 10:32 |
2 | 评级系统缺失问题 | 213 | 21 | A2569875 | 2024-06-01 18:55 |
3 | 管理人员申请预讨论 | 55 | 18 | Wong128hk | 2024-06-02 10:45 |
4 | 对新用户禁用内容翻译工具(续) | 32 | 13 | SCP-2000 | 2024-05-24 00:31 |
5 | Unblock-zh.org | 47 | 14 | LuciferianThomas | 2024-06-05 10:22 |
6 | 第二十二次动员令筹备讨论 | 1 | 1 | T45614631 | 2024-06-05 11:07 |
7 | 2024年非洲月筹备讨论 | 29 | 12 | Alankang | 2024-06-01 09:08 |
8 | 设立法轮功为高风险主题 | 44 | 14 | Wetrace | 2024-06-04 21:07 |
9 | 是不是创建一个披露过滤器细节的规范比较好 | 5 | 4 | Bluedeck | 2024-06-01 17:56 |
10 | 关于“Save to”和“Moved to” | 9 | 7 | Ericliu1912 | 2024-06-05 12:35 |
11 | 介绍 iOS 建议编辑:增强维基百科的移动贡献 | 1 | 1 | ARamadan-WMF | 2024-05-29 15:45 |
12 | 将“1945年后台湾政治”订为高风险主题 | 22 | 11 | Sinsyuan | 2024-06-04 15:27 |
发言更新图例 |
---|
|
|
|
|
|
特殊状态 |
已移动至其他页面 或完成讨论之议题 |
手动设置 |
当列表出现异常时, 请先检查设置是否有误 |
正在广泛征求意见的议题
以下讨论需要社群广泛关注:(重新整理)
维基专题与协作[编辑]
目前此主题无正在讨论的议题
|
没有主题的页面如何评级[编辑]
- 下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
像是包、比 (消歧义)、值 (消歧义)这种,内容并不属于任何专题管辖的页面,要如何评级?有没有办法“无专题评级”?不然在统计工具上面,这些未评级的页面都无法正常显示页面种类。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月7日 (四) 08:59 (UTC)
- 主题更多是用来评判重要度而非写作水准的吧,或许可以考虑一个通用评级,比如实际上并不应该被划到单一专题内的消歧义页。——暁月凛奈 (留言) 2023年12月7日 (四) 09:34 (UTC)
- (?)疑问@暁月凛奈:比方说创建一个专用的、通用的评级模板,无专题,不使用{{WPBannerMeta}}元模板,内部只塞“本页面获评XX级”和Special:页面评级的解析器语法,然后没有别的说明?-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月7日 (四) 09:48 (UTC)
- 我基本没有参与评级相关,我不太明白为什么条目质量一定要和专题挂钩。举个例子的话,页面李的六个链接五个是姓氏,一个是植物,被划到生物还是人文都显然不合适,而且消歧义页本来也不算做条目。或许也可以设计成,“本页面尚未划分到具体专题,欢迎协助标记”,然后消歧义页等页面用参数取消这一句。——暁月凛奈 (留言) 2023年12月7日 (四) 11:51 (UTC)
- (?)疑问@暁月凛奈:比方说创建一个专用的、通用的评级模板,无专题,不使用{{WPBannerMeta}}元模板,内部只塞“本页面获评XX级”和Special:页面评级的解析器语法,然后没有别的说明?-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月7日 (四) 09:48 (UTC)
{{WikiProject Article assessment}}
可托管没有专题支援的条目--洛普利宁 2023年12月7日 (四) 11:58 (UTC)- (:)回应PJ:条目质量评级“
这个维基专题已经废弃。
”。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月7日 (四) 12:18 (UTC)- 几乎所有专题都是废弃的,只是这个专题明面上写了而已;稍微好一点的是只有一个人参加的“个人专题”,不过这种专题基本上也是三分钟热度。如果你只是为了评级,那就不用管专题是否活跃,直接把
{{WikiProject Article assessment}}
往讨论页上贴就可以。以中维的实力来说,条目没有专题评级才应该是正常的,有评级的反而属于异端--洛普利宁 2023年12月7日 (四) 12:41 (UTC)- 没有到“
异端
”那么惨吧,根据WP:评级:“截至2022年,英文维基百科已经有超过700万条目被评级。很多其他语言版本也开始使用评级系统。中文维基百科约有38万条目接受评级。
”现在中文维基约有100万条目,100万中的38万,三成多,这样平均三个条目就有一个条目有评级啊。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月7日 (四) 13:10 (UTC)
- 模板、分类、甚至是文件也是需要评级的项目,算上去真的跟异端没两样。而挂上专题模板呈现的未评级状态能算评级吗。 --窝法乙烷 儿法梦碎 2023年12月7日 (四) 14:03 (UTC)
- (:)回应:@Milkypine:WP:评级:“
约有38万条目
”,中文维基百科条目数也才100万啊。哪有“异端
”?我还异端儿勒。另WP:评级#统计,所有挂有评级模板条目讨论页有562,943页,未填写评级的“未评级状态”之条目讨论页有182,858页,562,943 − 182,858 = 380,085。所以被评级的“条目”是38万无误,100万分之38万 = 38%。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月7日 (四) 14:33 (UTC)- @A2569875:先定义何谓异端,如果数字多就不算异端,那么日本和中国市场可以除名异端状态了。 --窝法乙烷 儿法梦碎 2023年12月7日 (四) 14:54 (UTC)
- 更不用38%是数字少的一方,对中维其余62%条目来讲,这38%就是异端。 --窝法乙烷 儿法梦碎 2023年12月7日 (四) 14:59 (UTC)
- (:)回应:@Milkypine:WP:评级:“
- 模板、分类、甚至是文件也是需要评级的项目,算上去真的跟异端没两样。而挂上专题模板呈现的未评级状态能算评级吗。 --窝法乙烷 儿法梦碎 2023年12月7日 (四) 14:03 (UTC)
- 没有到“
- 几乎所有专题都是废弃的,只是这个专题明面上写了而已;稍微好一点的是只有一个人参加的“个人专题”,不过这种专题基本上也是三分钟热度。如果你只是为了评级,那就不用管专题是否活跃,直接把
- (:)回应PJ:条目质量评级“
- {{WikiProject Disambiguation}},这个?--Kethyga(留言) 2023年12月7日 (四) 12:47 (UTC)
- 仅供参考: enwiki之前也有相关讨论,现在已由{{WPBS}}自动为这类型非条目赋予NA-、Redirect-级别的评级与重要度。请参见w:wn:Wikipedia:Bots/Requests for approval/Qwerfjkl (bot) 24。中文或许如Category:非条目级条目?--Kanashimi(留言) 2024年1月10日 (三) 06:05 (UTC)
- 本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
Random Thought: 跟进英维的WikiProject banner shell改版[编辑]
- 下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
我倒是想起一个事儿。英维最近改版了{{WikiProject banner shell}}模版(新样式在这里),新的模版可以单独给条目一个总体的品质评级,各个WikiProject可以直接继承这个quality assessment,也可以搞自己的评级。你看是不是能实现你的没有管辖之WikiProject依然可以有评级的愿望? --MilkyDefer 2023年12月7日 (四) 14:59 (UTC)
- @A2569875,附知。--MilkyDefer 2023年12月8日 (五) 09:03 (UTC)
- @MilkyDefer稍微研究了一下,跟本地系统完全不相容,根本不知道怎么改。他的评级是纯粹使用英文字母的,我们是中文,从他目前的模块架构,我看不出来哪边可以插入本地的评级模式。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月9日 (六) 07:47 (UTC)
- @MilkyDefer既然您提议了,我请求您给出可以执行的方案或建议,谢谢。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月9日 (六) 07:49 (UTC)
- 那就是我自己按照人家代码的思路重新实现一个类似的咯。上一次的ping模板改版姑且让我熟悉了一点Lua语言。--MilkyDefer 2023年12月9日 (六) 11:24 (UTC)
- 原样照办英维的codebase要动的手术很大。不过我姑且给你实作了一个长得差不多的在对应沙盒里面。--MilkyDefer 2023年12月9日 (六) 14:14 (UTC)
- (:)回应:@MilkyDefer:可是我好像没看到
{{#assessment:}}
语法。没使用{{#assessment:}}
的话也无法被系统和各类工具识别,那样也无法解决我最初提出来的问题啊⋯⋯ -- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月10日 (日) 05:09 (UTC) - (:)回应:@MilkyDefer:我把
{{#assessment:}}
加上去了,顺便调整一下让默认(模板预览)不要显示错误,你看一下这样适不适当。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月10日 (日) 17:43 (UTC)- 你自己决断。如我前面所述,我的改动只是一个临时性的方案。迟早需要重新规划这一套系统的技术编排,届时现在的变动会被新架构完全覆盖掉。--MilkyDefer 2023年12月10日 (日) 18:22 (UTC)
- (:)回应:@MilkyDefer:{{WikiProject banner shell}}目前获WP:模板保护,即使是这个临时方案也须获社群共识才得以使用。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月11日 (一) 00:05 (UTC)
- 你自己决断。如我前面所述,我的改动只是一个临时性的方案。迟早需要重新规划这一套系统的技术编排,届时现在的变动会被新架构完全覆盖掉。--MilkyDefer 2023年12月10日 (日) 18:22 (UTC)
- (:)回应:@MilkyDefer:可是我好像没看到
- @MilkyDefer既然您提议了,我请求您给出可以执行的方案或建议,谢谢。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月9日 (六) 07:49 (UTC)
- @MilkyDefer稍微研究了一下,跟本地系统完全不相容,根本不知道怎么改。他的评级是纯粹使用英文字母的,我们是中文,从他目前的模块架构,我看不出来哪边可以插入本地的评级模式。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月9日 (六) 07:47 (UTC)
- 本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
第一阶段:修改WikiProject banner shell[编辑]
- 下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
- 工程量挺大,就看谁愿意改了。(几年前可能我有兴趣,现在我就精神上支持了)--洛普利宁 2023年12月8日 (五) 14:53 (UTC)
- 目前(+)支持User:MilkyDefer的临时方案。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月11日 (一) 00:17 (UTC)
- (?)疑问:@Milkypine、暁月凛奈:您们认为暂时先用MilkyDefer的临时方案如何?暂且能解决目前问题,且朝模板的新版改进迈进中。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月11日 (一) 00:24 (UTC)
- (+)支持设立通用评级,但最好展现一下沙盒效果,现在点进去看到的文件说明还是旧版本。 --窝法乙烷 儿法梦碎 2023年12月11日 (一) 11:16 (UTC)
- (:)回应:@Milkypine:可以参考测试样例Template talk:WikiProject banner shell/testcases(评级模板的测试样例只能放讨论页,不然会有错误讯息 囧rz……;首个测试样例填了GA,所以这里可以看到这表格最下面“评级”是“优良”,表示新模板有效)-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月11日 (一) 12:15 (UTC)
- 已逾一周无新意见,视为已有初步共识。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月20日 (三) 13:23 (UTC)
- 一个小问题,见测试11,若是位于模板空间应修先显示为模板级。且依据我于Talk:医学测试结果,似乎不符合预期。-- Willy1018(留言) 2023年12月21日 (四) 06:26 (UTC)
- (?)疑问@Willy1018:Talk:医学测试结果哪边不合预期?不是都正常显示甲级吗,下面也能展开
|collapsed=yes
默认不展开也正常啊。然后无法理解测试11明明已经指定了,为何要fallback to模板级?指定级别显然优先于默认级别;未指定本来就该都没有评级。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月21日 (四) 13:29 (UTC)- 底下:互联网专题、维基百科专题、机器人学专题,应显示为A级而不是未评。-- Willy1018(留言) 2023年12月22日 (五) 03:47 (UTC)
- 如果本来就是这样设计的,当我没说吧。-- Willy1018(留言) 2023年12月22日 (五) 03:48 (UTC)
- @Willy1018:互联网专题、维基百科专题、机器人学专题的模板又没有要改版,既然他没有要改版,那么那些模板没有输入评级他是要怎么知道评级成什么?通灵吗?而且模板参数因技术限制无法跨模板互通,所以也不可能把A级信息传递进模板(实现如此传递需要mw:Extension:Variables,萌娘百科有,但中文维基没有,且相关扩展不相容于目前版本的MediaWiki)。再来,你看User:MilkyDefer的原始提案“
新的模版可以单独给条目一个总体的品质评级[…]也可以搞自己的评级。
”这代表各个专题的评级模板是自己搞自己的,每个专题的评级互相独立并不相干,因此没有输入就该维持没有输入评级的状态,本就不应该蹦出没有输入却变成A级的这种状况。再来“优先显示模板级”问题肯定也是上方误会导致的。既然你都说“如果本来就是这样设计的,当我没说吧。
”了,那么我就视为异议已排除,可以准备进行公示阶段。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月22日 (五) 04:15 (UTC)
- @Willy1018:互联网专题、维基百科专题、机器人学专题的模板又没有要改版,既然他没有要改版,那么那些模板没有输入评级他是要怎么知道评级成什么?通灵吗?而且模板参数因技术限制无法跨模板互通,所以也不可能把A级信息传递进模板(实现如此传递需要mw:Extension:Variables,萌娘百科有,但中文维基没有,且相关扩展不相容于目前版本的MediaWiki)。再来,你看User:MilkyDefer的原始提案“
- 如果本来就是这样设计的,当我没说吧。-- Willy1018(留言) 2023年12月22日 (五) 03:48 (UTC)
- 底下:互联网专题、维基百科专题、机器人学专题,应显示为A级而不是未评。-- Willy1018(留言) 2023年12月22日 (五) 03:47 (UTC)
- @Willy1018:跟您说明一下目前办理状况。已创建专门读取通用评级信息的模块Module:PJBSClass,目前我用电子游戏专题测试,测试结果见Talk:皮卡丘的测试结果,在电子游戏专题模板未输入评级时,其有确实从外层的{{WikiProject banner shell/sandbox}}读到
|class=Start
,你看这是不是你要的,如果是,则还须对Template:WPBannerMeta提编辑请求。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月24日 (日) 02:58 (UTC)- 感谢贡献,目前已复核已符合预期。-- Willy1018(留言) 2023年12月24日 (日) 05:17 (UTC)
- (:)回应:@Willy1018:但要达成您所见到的效果需要第二阶段的修改,跟{{WPBannerMeta}}配合。这样的话,我就视为您对第二阶段持(+)支持态度啰。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月24日 (日) 08:12 (UTC)
- 无异议。-- Willy1018(留言) 2023年12月25日 (一) 04:00 (UTC)
- (:)回应:@Willy1018:但要达成您所见到的效果需要第二阶段的修改,跟{{WPBannerMeta}}配合。这样的话,我就视为您对第二阶段持(+)支持态度啰。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月24日 (日) 08:12 (UTC)
- 感谢贡献,目前已复核已符合预期。-- Willy1018(留言) 2023年12月24日 (日) 05:17 (UTC)
- (?)疑问@Willy1018:Talk:医学测试结果哪边不合预期?不是都正常显示甲级吗,下面也能展开
- 一个小问题,见测试11,若是位于模板空间应修先显示为模板级。且依据我于Talk:医学测试结果,似乎不符合预期。-- Willy1018(留言) 2023年12月21日 (四) 06:26 (UTC)
- (+)支持设立通用评级,但最好展现一下沙盒效果,现在点进去看到的文件说明还是旧版本。 --窝法乙烷 儿法梦碎 2023年12月11日 (一) 11:16 (UTC)
- 此段落最后发言至今已逾七日,超过一周无新留言,且此前已形成初步共识,因此根据WP:7DAYS准备进行公示。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月1日 (一) 04:04 (UTC)
- 公示7日。公示内容见此-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月1日 (一) 04:04 (UTC)
- 本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
- 完成:已布署Special:Diff/80410249。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月8日 (一) 04:40 (UTC)
第二阶段:修改WPBannerMeta[编辑]
- 下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
@Willy1018:提到了一个很有意义的问题。如果上方的更改套用了的话,只有“表面上”给了页面通用评级,而实际上的通用评级在各个专题中并没有达成“继承评级”的效果。这是因为评级模板默认不会知道他外面包着{{WikiProject banner shell}}模板,因此,如果要让每个评级模板都能读到通用评级,需要再一个编辑请求。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月24日 (日) 05:15 (UTC)
- 预计将会使用Module:PJBSClass来读取{{WikiProject banner shell}}模板中的评级,并传递给{{WPBannerMeta}}注入进class参数。由于这需要第一阶段先通过才有用,故先 搁置,等第一阶段。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月24日 (日) 05:15 (UTC)
- 第二阶段相关讨论Special:PermaLink/80224436#回复通告-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月25日 (一) 02:56 (UTC)
- 已复核,已符合预期,再次感谢您的贡献。(搬运自Special:PermaLink/80233084)-- Willy1018(留言) 2023年12月25日 (一) 04:02 (UTC)
- 上面的共识是“
可以单独给条目一个总体的品质评级,各个WikiProject可以直接继承这个quality assessment,也可以搞自己的评级。
”,下方Wikipedia:互助客栈/其他#关于基础条目的额外提议也有多个(+)支持“对各种专题横幅不再个别指定 class,而是统一置于{{WPBS}}
”的声音,为了实现上方共识“各个WikiProject可以直接继承这个quality assessment”以及下方讨论的“专题横幅不再个别指定 class,而是统一置于{{WPBS}}”因此需要在{{WPBannerMeta}}置入读取{{WPBS}}评级值的模板,以便让专题横幅能正确识别统一置于{{WPBS}}的评级,故本修改是必要的,目前已经布署于电子游戏专题和多面体专题,运作稳定。如无异议,将会进行公示,进行全面布署。
- 预计的修改方案以及其布署链接(记得填写讨论通过的diff和客栈PermaLink版本号)。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月3日 (三) 05:00 (UTC)
相关议案
的配套修改-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月8日 (一) 05:03 (UTC)
- 想咨询一下@Kanashimi君相关修改是否有问题?—— Eric Liu 創造は生命(留言・留名・学生会) 2024年1月8日 (一) 05:53 (UTC)
- @Ericliu1912、Kanashimi:这主要是依据共识,让专题横幅能继承{{PJBS}}输入的评级值。我已经在{{多面体专题}}、{{电子游戏专题}}测试过了,没有问题。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月8日 (一) 06:00 (UTC)
- User:A2569875的努力有目共睹。只不过我原先料想的是直接改w:en:Module:WikiProject banner及w:en:Module:Banner shell,而宇帆-娜娜奇看起来很辛苦的重构了代码,并且有些参数不太一样,这样我就不太好评论了。--Kanashimi(留言) 2024年1月8日 (一) 06:12 (UTC)
- @Ericliu1912、Kanashimi:那就用测试数据来说话吧。目前我是刻意让{{多面体专题}}内部是调用Template:WPBannerMeta/sandbox/sandbox(同于Template:WPBannerMeta/sandbox,只是Template:WPBannerMeta/sandbox/sandbox里面都塞/sandbox模板以便测试效果),效果完全符合预期,十分正常,见下列测试结果(只要是调用{{多面体专题}}的,基本上都等同于这个Patch):
- Talk:二十面体对称的多面体列表:里面输入了列表级,Template:WPBannerMeta/sandbox确实读到了列表级,没有问题。
- 其他可参考Special:链入页面/Template:WPBannerMeta/sandbox/sandbox,基本上都没有问题,我检查一个礼拜了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月8日 (一) 06:16 (UTC)
- Eric Liu 創造は生命(留言・留名・学生会) 2024年1月8日 (一) 12:18 (UTC)
- @Ericliu1912:若以Wikipedia:互助客栈/其他#Random_Thought:_跟进英维的WikiProject_banner_shell改版这一案来看的话(或者说只看这一案)的话,只有{{WPBannerMeta/core}}和{{WPBannerMeta}}要更新。其他案目前还在讨论中。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月8日 (一) 12:23 (UTC)
- (~)补充:@Ericliu1912:参考这个留言Wikipedia:互助客栈/其他#MilkyDefer2023年12月9日(六)14:14(UTC),“
原样照办英维的codebase要动的手术很大。不过我姑且给你实作了一个长得差不多的在对应沙盒里面。
”考虑到最大相容性和中文维基的特殊性(如繁简问题),本地评级系统本来就跟英文维基不太相同。目前只能“按照人家代码的思路重新实现一个类似的咯。
”(by User:MilkyDefer)此外,我也不想换掉现在中文维基熟悉的Style。目前您所看到的系统都是基于MilkyDefer的修改版再把enwiki对应功能实作出来。主要功能去年年底就完工了,经过了半个多月的测试,我相信技术上不会有太大的问题。且相关函数已于电子游戏专题两万多条目进行测试,问题几乎都解决了。技术上没有问题。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月8日 (一) 12:58 (UTC)
- (~)补充:@Ericliu1912:参考这个留言Wikipedia:互助客栈/其他#MilkyDefer2023年12月9日(六)14:14(UTC),“
考虑到日后长期维护需求,我倾向请您以英文版本为基础来更新相关模板。是否能够确认有什么模板需要更新(或在互助客栈列出之类)?不过在此过渡期间,若技术上没有问题,是可以斟酌先批准既有之编辑请求。—— - @Ericliu1912:若以Wikipedia:互助客栈/其他#Random_Thought:_跟进英维的WikiProject_banner_shell改版这一案来看的话(或者说只看这一案)的话,只有{{WPBannerMeta/core}}和{{WPBannerMeta}}要更新。其他案目前还在讨论中。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月8日 (一) 12:23 (UTC)
- 这两个(Template_talk:WPBannerMeta#编辑请求_2024-01-08、Template_talk:WPBannerMeta/core#编辑请求_2023-12-28)属于案《Random Thought: 跟进英维的WikiProject_banner_shell改版》可以先进行;剩下的属于另一案(Module_talk:Class/data#编辑请求_2023-12-28、Template_talk:Class_mask#编辑请求_2024-01-05、Template_talk:Class_mask/core#编辑请求_2023-12-25、Template_talk:Class/colour#编辑请求_2024-01-05)属于案《同步各模板/块的评级值》目前正在公示,所以暂时还不用。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月8日 (一) 14:59 (UTC)
- @Ericliu1912:要改哪些模板我在客栈上其实都有列,主要在案《没有主题的页面如何评级》和案《评级系统缺失问题》的子章节里。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月8日 (一) 15:03 (UTC)
- (不用一直提及我,我有在看)—— Eric Liu 創造は生命(留言・留名・学生会) 2024年1月8日 (一) 15:11 (UTC)
- (:)回应:既然你有在看,那我就更仔细地说明这两个编辑请求(Template_talk:WPBannerMeta#编辑请求_2024-01-08、Template_talk:WPBannerMeta/core#编辑请求_2023-12-28)技术上没有问题、无疑虑的理由。这两个编辑请求加起来的编辑内容等价于我上个月在{{WikiProject Video games}}做出的这笔编辑Special:Diff/80221014。用的模块和函数完全相同,只是仅限于电子游戏专题,而这两个编辑请求加起来的编辑内容就等于布署到所有专题。电子游戏专题之所有不用编辑两个模板是因为{{WikiProject Video games}}不使用元模板,也没有/core,因此编辑一个页面就能达到效果,而所有专题共用的元模板有使用元模板/core,因此需要编辑两个模板(主模板和/core模板)才能生效。电子游戏专题共有两万多个条目,这功能布署到电子游戏专题至今已半个多月,未见什么大问题,代表已经在两万个条目测试没问题(稍早也测试了{{多面体专题}},500+条目;实际上还布署到了{{互联网专题}}、{{维基百科专题}}和{{WikiProject Robotics}}上以便让User:Willy1018已复核效果符合预期;更进一步的技术测试则在{{WikiProject_Sandbox}}及{{WikiProject Portals}}完成,均未发现任何问题;为了避免影响到Patch,测试是由{{WPBannerMeta/sandbox/sandbox}}和{{WPBannerMeta/core/sandbox/sandbox}}完成,测试方式是直接先暂时将对应模板改用{{WPBannerMeta/sandbox/sandbox}}和{{WPBannerMeta/core/sandbox/sandbox}}以观察布署后的效果),我这半个月也实际复查数百个条目,没发现任何问题,代表这两万多个条目的测试是成功的,因此认为本开发已趋于稳定,是时候可以布署到所有专题了。以上,故认为技术上没有问题,可以布署Template_talk:WPBannerMeta#编辑请求_2024-01-08和Template_talk:WPBannerMeta/core#编辑请求_2023-12-28。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月8日 (一) 15:46 (UTC)
- (~)补充:若这两个编辑请求(Template_talk:WPBannerMeta#编辑请求_2024-01-08和Template_talk:WPBannerMeta/core#编辑请求_2023-12-28)核准了,记得通知我一声,我需要在{{多面体专题}}、{{互联网专题}}、{{维基百科专题}}、{{WikiProject Robotics}}和{{WikiProject Portals}}取消布署,避免重复布署和{{WPBannerMeta}}及{{WPBannerMeta/core}}相冲。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月8日 (一) 15:55 (UTC)
- (:)回应:既然你有在看,那我就更仔细地说明这两个编辑请求(Template_talk:WPBannerMeta#编辑请求_2024-01-08、Template_talk:WPBannerMeta/core#编辑请求_2023-12-28)技术上没有问题、无疑虑的理由。这两个编辑请求加起来的编辑内容等价于我上个月在{{WikiProject Video games}}做出的这笔编辑Special:Diff/80221014。用的模块和函数完全相同,只是仅限于电子游戏专题,而这两个编辑请求加起来的编辑内容就等于布署到所有专题。电子游戏专题之所有不用编辑两个模板是因为{{WikiProject Video games}}不使用元模板,也没有/core,因此编辑一个页面就能达到效果,而所有专题共用的元模板有使用元模板/core,因此需要编辑两个模板(主模板和/core模板)才能生效。电子游戏专题共有两万多个条目,这功能布署到电子游戏专题至今已半个多月,未见什么大问题,代表已经在两万个条目测试没问题(稍早也测试了{{多面体专题}},500+条目;实际上还布署到了{{互联网专题}}、{{维基百科专题}}和{{WikiProject Robotics}}上以便让User:Willy1018已复核效果符合预期;更进一步的技术测试则在{{WikiProject_Sandbox}}及{{WikiProject Portals}}完成,均未发现任何问题;为了避免影响到Patch,测试是由{{WPBannerMeta/sandbox/sandbox}}和{{WPBannerMeta/core/sandbox/sandbox}}完成,测试方式是直接先暂时将对应模板改用{{WPBannerMeta/sandbox/sandbox}}和{{WPBannerMeta/core/sandbox/sandbox}}以观察布署后的效果),我这半个月也实际复查数百个条目,没发现任何问题,代表这两万多个条目的测试是成功的,因此认为本开发已趋于稳定,是时候可以布署到所有专题了。以上,故认为技术上没有问题,可以布署Template_talk:WPBannerMeta#编辑请求_2024-01-08和Template_talk:WPBannerMeta/core#编辑请求_2023-12-28。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月8日 (一) 15:46 (UTC)
- (不用一直提及我,我有在看)—— Eric Liu 創造は生命(留言・留名・学生会) 2024年1月8日 (一) 15:11 (UTC)
- @Ericliu1912:要改哪些模板我在客栈上其实都有列,主要在案《没有主题的页面如何评级》和案《评级系统缺失问题》的子章节里。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月8日 (一) 15:03 (UTC)
- @Ericliu1912、Kanashimi:那就用测试数据来说话吧。目前我是刻意让{{多面体专题}}内部是调用Template:WPBannerMeta/sandbox/sandbox(同于Template:WPBannerMeta/sandbox,只是Template:WPBannerMeta/sandbox/sandbox里面都塞/sandbox模板以便测试效果),效果完全符合预期,十分正常,见下列测试结果(只要是调用{{多面体专题}}的,基本上都等同于这个Patch):
- @Ericliu1912、Kanashimi:另外参见此发言,User:Willy1018已复核效果符合预期,认为修改没有问题。测试也都充分了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月8日 (一) 06:31 (UTC)
- @Ericliu1912:另外如果要接受编辑请求的话,也把Template_talk:WPBannerMeta/core#编辑请求_2023-12-28也接受吧,两者是互相配套的({{WPBannerMeta}}与{{WPBannerMeta/core}}高度相依)。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月8日 (一) 06:33 (UTC)
- 相关讨论移动到此供参考。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月9日 (二) 13:22 (UTC)
- 本议案旨在“让专题横幅能从{{PJBS}}继承评级值”是否布署到所有专题。目前已暂时通过沙盒模板测试性地布署到电子游戏专题、多面体专题、互联网专题、维基百科专题、主题专题、沙盒专题。如无异议的话,将会就“是否布署于所有专题”进行公示。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月9日 (二) 13:54 (UTC)
- 目前没有合理异议,因此仍照原定计划若2024年1月10日 (三) 05:00 (UTC)之前没有其他异议就视为已获共识。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月9日 (二) 17:48 (UTC)
- 依据此以及WP:7DAYS,时间已逾2024年1月10日 (三) 05:00 (UTC),且本篇讨论始于2023年12月7日已逾一个月,依据WP:1MONTH,因此视为已达成共识,准备开始公示。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月10日 (三) 05:37 (UTC)
- 公示7日,公示说明。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月10日 (三) 05:37 (UTC)
- 由于相依性, 公示延长至《Wikipedia:互助客栈/其他#提案已通过请求布署》布署的三日后。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月16日 (二) 15:36 (UTC)
- 《Wikipedia:互助客栈/其他#提案已通过请求布署》布署已逾时三日;公示期内位于Template_talk:WPBannerMeta#编辑请求_2024-01-08的合理意见可以通过下方议案《通用评级规范》来解决,且该议案已获初步共识并进入公示阶段(详见此说明),故可以预见该问题将被解决,故此案应可通过;但为了谨慎起见,公示再延三日,若三日内没有合理异议则视本案为通过。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月21日 (日) 13:05 (UTC)
- 本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
第三阶段:完善制度[编辑]
- 下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
在Template_talk:WPBannerMeta#编辑请求_2024-01-08中有人认为需要给通用评级订一个“能填写什么级别”的标准来避免争议,因此立了草案Wikipedia:通用评级如下:
- 若一条目没有专题或不受任何专题管辖,则其通用评级可填写任意有被{{WikiProject banner shell}}支援的级别,仅要该条目有达到该级别的标准或满足该级别的条件,都可以评。
- 若一条目仅有一个专题,其通用评级应与该专题所评的等级一致。
- 若一条目有多个专题,通常由机器人自动依照规则4进行评级,但一旦出现争议时则通用评级应以所有专题都有开设的级别为主。
- 例如:若一条目有四个专题,而有一个专题没有开设“丙级列表级”,那么通用评级就不得填写“丙级列表级”
- 对于有多个专题的条目,通用评级应填写最多专题评的那一等级。
- 例如有一个条目有四个专题,其中三个专题都评为乙级,但有一个专题评为丙级,则通用评级应填写乙级。
- 若在规则4的情况抵触规则3,则应填写与对应级别最接近的且满足规则3的级别。
- 例如有一个条目有四个专题,其中三个专题都评为“丙级列表级”,但有一个专题评为“列表级”且这个专题不开设“丙级列表级”。依据规则3,最多专题评的级别是“丙级列表级”,但有一个专题不开设“丙级列表级”,则通用评级应填写与“丙级列表级”最接近且位于该条目所有专题都有开设的级别,也就是“列表级”。
- “最接近的级别”应该向下填写,例如未启用乙级的专题,通用级别遇到规则3判为乙级的情况时,则向下填写为丙级。如果丙级也有专题未开设,就再向下填写为初级。如遇到无法评级的情况,该通用评级模板就该留空。
提议将之升为指引,不晓得各位觉得如何?@Ma3r、Kanashimi、Z7504、桐生ここ:@Kethyga、暁月凛奈、MilkyDefer、Milkypine、Willy1018:-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月14日 (日) 09:44 (UTC)
- 实作上是否能让那些没开设大宗评级(数量最多专题)的在专题横幅内设置好参数即可?这样看起来就不会因为没开设评级、被覆盖而出问题。机器人很难判别每个专题开设的评级,因此条件3会让让机器人无法自动作业。
- 仅供参考,就enwiki来说,纯粹只考虑数量最多的评级。采用特殊评级的专题横幅有特殊分类,机器人处理时不会动到其评级。--Kanashimi(留言) 2024年1月14日 (日) 10:35 (UTC)
- @Kanashimi:技术上不能读取评级模板的
|QUALITY_SCALE=
内容和/class子页面吗?如果|QUALITY_SCALE=
填subpage,读取/class子页面就能得知该专题哪些评级有启用。例如{{多面体专题}}是|QUALITY_SCALE=subpage
,所以读取Template:多面体专题/class原始码即可得到哪些级别是yes、哪些级别是no。如果|QUALITY_SCALE=
填extended则是定义于{{Class mask/extended}}的级别。未填或standard就是只使用大宗评级。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月14日 (日) 11:00 (UTC) - 如果改成“若一条目有多个专题,通常由机器人自动依照规则4进行评级,但一旦出现争议时则通用评级应以所有专题都有开设的级别为主。”机器人会不会好办一点?意为机器人填写值优先,但如果是人工评级时,才须考虑是否所有专题都有开设,且是遇到争议之时,这是为了解决“
但是如果有人说“根据Wikipedia:条目质量评级标准#非标准级别和一些专题评CL的惯例,这篇列表内容充分,尽管支援条目的专题都没有设CL级别,但既然WPBS能评CL那我就评CL”呢?所以,这个评级的定位该怎么看?您作出了如此复杂的功能,但如果因为使用规则不完善而部署而引发争议,相信这是您不愿意见到的。
”所描述的争议情境。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月14日 (日) 11:06 (UTC)- @A2569875 现在cewbot采用的方式是选出最大宗的评级(数量最多的评级),填入{{WPBS}}并且移除所有相同的评级。所有不同的评级都保留不动。不晓得这样的作业方式是否会产生问题?--Kanashimi(留言) 2024年1月14日 (日) 11:16 (UTC)
- @Kanashimi:技术上不能读取评级模板的
- 我在疗养,您自己请便。由于这个事情的业务逻辑挺复杂的,我不会拦着你用什么样的Lua。--MilkyDefer 2024年1月14日 (日) 12:48 (UTC)
- 已逾一周没有任何发言,根据WP:7DAYS,七日无新留言视为已达成初步共识,因此将准备进行公示。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月21日 (日) 12:54 (UTC)
- 公示7日-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月21日 (日) 12:54 (UTC)
公示已逾七日,公示期已过,期内无合理异议,因此提案通过。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月29日 (一) 03:28 (UTC)
- 本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
临时动议:关于基础条目的额外提议[编辑]
|vital=
参数》案。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月29日 (一) 05:36 (UTC)- 下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
- 似乎已有共识,跟随enwiki改版之后会由机器人自动完成:对各种专题横幅不再个别指定 class,而是统一置于{{WPBS}}。
- 跟随enwiki改版之后会由机器人自动完成:将{{WikiProject Biography}}的 'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等参数皆改以{{WPBS}}处理,
- 跟随enwiki改版之后会由机器人自动完成:将{{Vital article}}并入{{WPBS}}
这边最近在帮忙enwiki自动化这过程。这边将申请自动更新Wikipedia:基础条目所有子页面的图示(这部分最近测试中,已趋稳定。),以及定期维护{{WPBS}}(将各种专题横幅并入{{WPBS}}并维护 'class', 'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas'等相关参数)。不知大家对此是否有建议? --Kanashimi(留言) 2024年1月2日 (二) 09:53 (UTC)
enwiki近期改版{{WikiProject banner shell}},
- 对各种专题横幅不再个别指定 class,而是统一置于{{WPBS}}。
- 将{{WikiProject Biography}}的 'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等参数皆改以{{WPBS}}处理,
- 将{{Vital article}}并入{{WPBS}}
这边最近在帮忙enwiki自动化这过程,并且将定期维护。想请教大家对上几种改变的赞否。
另这边将申请自动更新Wikipedia:基础条目的图示(这部分最近测试中,已趋稳定。),以及维护{{WPBS}}(将各种专题横幅并入{{WPBS}})。不知大家对此是否有建议?
副知User:Ma3r、User:Ericliu1912--Kanashimi(留言) 2024年1月2日 (二) 06:11 (UTC)
- 其实个人早已注意到相关更新,只是苦于自身技术实力不足而未能协助,乐见在充分确保相容性的情况下跟进。—— Eric Liu 創造は生命(留言・留名・学生会) 2024年1月2日 (二) 06:21 (UTC)
- (+)支持全部。--Ma3r(铁塔) 2024年1月2日 (二) 06:25 (UTC)
- @Kanashimi:可是这个即将公示通过了耶Wikipedia:互助客栈/其他#Random_Thought:_跟进英维的WikiProject_banner_shell改版。这个预计会先上架,这边去年年底弄了从{{WPBS}}读取评级到专题横幅的模块Module:PJBSClass,你是要让我做白工吗?-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月2日 (二) 09:30 (UTC)
- 唉呀感谢提醒我没注意到。看起来改版是已经有共识的结果了。我把建议移到那个讨论串下好了,这边可以关闭了。--Kanashimi(留言) 2024年1月2日 (二) 09:37 (UTC)
- Eric Liu 創造は生命(留言・留名・学生会) 2024年1月3日 (三) 04:47 (UTC)
- 已迁移讨论@Ma3r、Ericliu1912:(User:Kanashimi应该已经知道了)-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月3日 (三) 05:51 (UTC)
您可以将整个讨论移到其他区( ——
- Eric Liu 創造は生命(留言・留名・学生会) 2024年1月3日 (三) 04:47 (UTC)
- 唉呀感谢提醒我没注意到。看起来改版是已经有共识的结果了。我把建议移到那个讨论串下好了,这边可以关闭了。--Kanashimi(留言) 2024年1月2日 (二) 09:37 (UTC)
- (:)回应:但上面的共识是“
可以单独给条目一个总体的品质评级,各个WikiProject可以直接继承这个quality assessment,也可以搞自己的评级。
”,代表虽然评级统一放在{{WPBS}},但仍然要允许个别专题能用自己的标准来搞自定义评级,所以应保留各专题横幅的评级参数与功能。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月3日 (三) 04:57 (UTC)
- 是的,enwiki采w:en:Category:WikiProjects using a non-standard quality scale表示自定义评级的专题,bot亦已考虑此问题,在User:Cewbot/log/20200122/configuration有此项。待zhwiki完成部署,填好User:Cewbot/log/20200122/configuration便可apply。--Kanashimi(留言) 2024年1月3日 (三) 07:08 (UTC)
- (:)回应:@Kanashimi:我指的是可能会有专题有自己的标准,导致评级值与{{WPBS}}不同的情况(如可能有些专题的乙级比较严格,导致该专题只能评丙级,但WPBS是乙级,其他专题也是乙级),而非“非标准评级”(non-standard quality)的情况。虽然两者都需要保留着各专题横幅模板的评级class参数。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月3日 (三) 07:26 (UTC)
- 是的,w:en:Category:WikiProjects using a non-standard quality scale包含您所提的这两种非正规、不继承的状况。--Kanashimi(留言) 2024年1月3日 (三) 07:47 (UTC)
- Category:使用自定义专题评级的条目,我是指“一个页面的评级”满足“不继承、非正规”的状况,不是“专题横幅自己”满足“不继承、非正规”的条件。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月3日 (三) 09:41 (UTC)
- 或许我们该用Category:使用非正规质量评级的专题横幅?至于您说的“一个页面的评级”很抱歉我不太理解,是否能举个例子呢?--Kanashimi(留言) 2024年1月3日 (三) 11:34 (UTC)
- (:)回应:@Kanashimi:Category:使用自定义专题评级的条目里面的页面就是“一个页面的评级”满足“不继承”的状况。Category:使用自定义专题评级的条目指的是“考虑一个已使用{{WPBS}}指定评级为X的条目,其有至少一个专题横幅评级值为Y,或不为{{WPBS}}指定的X”,而考察w:en:Category:WikiProjects using a non-standard quality scale分类内都是“专题横幅模板”本身,我猜它是指“允许‘不继承、非正规’评级的横幅”,而不是条目评级的“个例”;而Category:使用自定义专题评级的条目是指“已经‘不继承、非正规’评级的页面”的“个例”而非横幅模板本身。我想你有所误解,我希望是元模板都保留
|class=
参数,让专题自己决定要怎么送值,然后预社会继承,这样的话我们就不需要Category:使用非正规质量评级的专题横幅分类。也就是说,本地的状况宜以条目个例来看,而非以专题为单位来看。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月3日 (三) 11:43 (UTC)- 假如我没有理解错,您的意思是就您看来,zhwiki采用因地制宜的条目追踪Category会比较好,因此您建议的是Category:使用自定义专题评级的条目而非Category:使用非正规质量评级的专题横幅?--Kanashimi(留言) 2024年1月3日 (三) 11:49 (UTC)
- 另外这两个追踪的标的不同,一个是专题横幅,一个是条目,我建议先取消d:Q122718872的链接。--Kanashimi(留言) 2024年1月3日 (三) 11:52 (UTC)
- d:Specail:Diff/2044308721已取消。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月3日 (三) 11:56 (UTC)
- (:)回应:@Kanashimi:是的,根据我的观察,我认为中文维基环境宜用Category:使用自定义专题评级的条目(因为人手较少,很多专题都是不活跃或单人专题,因此中维的关注点以条目居多,故追踪分类追踪条目很符合逻辑),且Patch已写好,已使用少量条目测试,目前运作正常,预计会先跟上面的patch一起布署。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月3日 (三) 11:54 (UTC)
- enwiki采用这种方法的过程与部分考量可参考w:en:Template talk:WikiProject banner shell#Issue with assessments not applying to WikiProject Lists template,关乎Special:PageAssessments。就我最近的测试,有些模板如您所述
有些专题的乙级比较严格,导致该专题只能评丙级,但WPBS是乙级,其他专题也是乙级
,更有像w:en:Template:WikiProject Military history模板本身有额外采用class参数的代码,这些模板本来就该与采用一般正规评级的模板分开。因此我会建议保留Category:使用非正规质量评级的专题横幅这部分的功能,辅以Category:使用自定义专题评级的条目的patch。--Kanashimi(留言) 2024年1月3日 (三) 12:06 (UTC)- 目前的patch是对所有的专题横幅全面保留
|class=
参数,只是设置未输入时会从WPBS读取评级值,也就是默认继承,也就是说,所有专题横幅模板都可以继承或覆盖,因为是所有的横幅都可以覆盖,所以Category:使用非正规质量评级的专题横幅对于“不继承评级”没有意义。共识也有说要在最大相容的情况下布署,所以我主张要尽可能保留原本的功能,即每个专题横幅模板都能自定义评级,这是原本的情况,新共识是保留原本情况额外加上可以继承评级的功能,且符合共识的patch也就绪了,您的意思看起来好像要取消专题横幅默认都可以独立评级、不继承评级,我(-)反对如此作法,我主张应对所有专题(○)保留可覆盖评级的功能,就像你程式的类别成员函数默认都是可以继承或复写Override的啊,怎么会有默认是不准Override的情况?因此我反对默认关闭横幅不继承评级之功能,反正现在的patch已经是默认继承WPBS之评级的情况,对专题横幅元模板保留“允许不继承评级”功能无伤大雅。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月4日 (四) 04:20 (UTC)- 我了解您的意思了。enwiki现在也是默认继承,允许Override但会被列入w:en:Category:Articles with conflicting quality ratings。那边的想法似乎是除非退出,否则应采用同一评级。我建议还是保留专题横幅退出的余地,毕竟有些专题横幅就是比较特别。
- 就现在的机器人实作方法,zhwiki应该不会有问题。专题横幅模板的质量评级若与{{WPBS}}相同,将会被移到{{WPBS}}。若与{{WPBS}}不同则会保留。--Kanashimi(留言) 2024年1月4日 (四) 06:05 (UTC)
- 目前的patch是对所有的专题横幅全面保留
- enwiki采用这种方法的过程与部分考量可参考w:en:Template talk:WikiProject banner shell#Issue with assessments not applying to WikiProject Lists template,关乎Special:PageAssessments。就我最近的测试,有些模板如您所述
- 例如Talk:康威多面体里面{{WPBS}}指定了
|class=stub
,但{{多面体专题}}指定了|class=start
盖掉了{{WPBS}}的|class=stub
,因此被自动加入Category:使用自定义专题评级的条目分类。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月3日 (三) 11:46 (UTC)
- (:)回应:@Kanashimi:Category:使用自定义专题评级的条目里面的页面就是“一个页面的评级”满足“不继承”的状况。Category:使用自定义专题评级的条目指的是“考虑一个已使用{{WPBS}}指定评级为X的条目,其有至少一个专题横幅评级值为Y,或不为{{WPBS}}指定的X”,而考察w:en:Category:WikiProjects using a non-standard quality scale分类内都是“专题横幅模板”本身,我猜它是指“允许‘不继承、非正规’评级的横幅”,而不是条目评级的“个例”;而Category:使用自定义专题评级的条目是指“已经‘不继承、非正规’评级的页面”的“个例”而非横幅模板本身。我想你有所误解,我希望是元模板都保留
建好后,发现好像跟你说的不是一个东西? - 或许我们该用Category:使用非正规质量评级的专题横幅?至于您说的“一个页面的评级”很抱歉我不太理解,是否能举个例子呢?--Kanashimi(留言) 2024年1月3日 (三) 11:34 (UTC)
- Category:使用自定义专题评级的条目,我是指“一个页面的评级”满足“不继承、非正规”的状况,不是“专题横幅自己”满足“不继承、非正规”的条件。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月3日 (三) 09:41 (UTC)
- 是的,w:en:Category:WikiProjects using a non-standard quality scale包含您所提的这两种非正规、不继承的状况。--Kanashimi(留言) 2024年1月3日 (三) 07:47 (UTC)
- WPBS}}能自动判断评级的情况吗?此时,{{WPBS}}不会有输入任何
|class=
参数,也不必输入|class=
,因为它是自动判定,例如Talk:2J(请看此版本的原始码)。甚至还能传递给内层专题横幅让专题横幅继承这个“没有输入”的评级级别,例如Talk:二侧锥五角柱(请看此版本原始码)和Talk:五复合半刻面立方体(请看此版本原始码),bot有考虑到这种{{WPBS}}未输入|class=
参数,但能产生结果的状况吗?-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月3日 (三) 10:21 (UTC)- 机器人基本上不会动这种类型的 {{WPBS}}。另外依照MSGJ在w:en:Wikipedia:Bots/Requests for approval/Qwerfjkl (bot) 24的说法,“We have changed the logic so it is impossible to rate a non-article with an article quality rating.”,也就是这类型的问题会由Module:Banner shell处理。--Kanashimi(留言) 2024年1月3日 (三) 11:44 (UTC)
那您的bot有考虑到{{
- (:)回应:@Kanashimi:我指的是可能会有专题有自己的标准,导致评级值与{{WPBS}}不同的情况(如可能有些专题的乙级比较严格,导致该专题只能评丙级,但WPBS是乙级,其他专题也是乙级),而非“非标准评级”(non-standard quality)的情况。虽然两者都需要保留着各专题横幅模板的评级class参数。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月3日 (三) 07:26 (UTC)
- 整理一下目前共识:
- {{PJBS}}设立通用评级,可以统一管理同一条目的所有专题评级(已公示通过)
- 确保最大相容性的前提下跟进英文维基的相关功能
- 专题横幅看各专题意愿,评级可以选择统一放置于{{PJBS}}也可以自行输入
- 未输入评级的专题横幅以继承载于{{PJBS}}的评级值为主,会优先采用载于{{PJBS}}的评级值
- 如页面能自动判断评级则无论输入什么评级,都要以自动判断的评级为优先(原始来自这则留言,后续有在上方简单讨论);另有设置参数能复写此设置。
- 'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas'已并入{{PJBS}},但是否废除{{WikiProject Biography}}内的'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas'还有待讨论
- {{WPBS}}已经加入{{Vital article}}的所有参数,但是否要用{{WPBS}}取代{{Vital article}}还有待讨论
我有不同意见。英维的WPBannerMeta模块有很长一大坨代码都是在处理这个Vital Article的事情;具体来说,他们把校验这个Vital Article是不是真的Vital Article什么的逻辑全部写进去了。这一坨东西让可维护性和可读性(有可能还有效率)遭到了重大影响。我认为这更适合由一个外部机器人维护,而不是剥削这个已经很折磨人的Lua。 --MilkyDefer 2024年1月14日 (日) 12:53 (UTC)
- 我的建议方案是,
|vital=
参数可以存在,但是只有UI作用,由一个外部的机器人进行监察和更新操作。--MilkyDefer 2024年1月14日 (日) 12:55 (UTC)- 若能简单改enwiki的程式码来用,或许不必担心折腾的问题。另一方面假如只留UI功能的话,是否干脆维持原来的{{Vital article}}就好?--Kanashimi(留言) 2024年1月14日 (日) 13:06 (UTC)
- Module:Vital_articles都已经分成类似杂凑表查询了,有什么折腾的问题?已经高效率优化了好吗。理论上,此实现的内存开销甚至有望低于英文维基,因为英文维基只分成27个表,而中文维基是36个表,代表中文维基每个表的项目数量更少,在类似散列函数计算之后,要读取的JSON更小,表示内存用量更少,单个表项目更少表示查询更快。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月14日 (日) 13:12 (UTC)
- @Kanashimi:Module:Vital_articles#L-216基本上就是英文维基的Code,我们已经简单改enwiki的程式码来用了,您似乎有所误会,请自行对照Module:Vital_articles#L-216与en:Module:Banner_shell#L-90。而且您可以看到,本提案预计的作法已经把它下分到Module:Vital_articles去了,并不是像英文维基里全部整坨塞WPBS模块,故不存在您所提的“可维护性和可读性低”的问题,因为已经分门别类处理了:WPBS处理WPBS的任务、Vital articles处理Vital articles的任务,故上述疑虑不存在,杞人忧天。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月14日 (日) 13:14 (UTC)
- 是的,所以我想应该不至于有折腾的问题。--Kanashimi(留言) 2024年1月14日 (日) 13:17 (UTC)
- 不同意“剥削这个已经很折磨人的Lua”一说。您似乎保守过头了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月14日 (日) 13:16 (UTC)
- @MilkyDefer:而且一个页面最多只会放置一个{{WPBS}}或{{Vital article}},代表该运算始终只会做一次,一个半秒内完成的运算只算一次,是要担心什么效能问题?难道你想塞一万个{{WPBS}}或{{Vital article}}在讨论页?-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月14日 (日) 13:20 (UTC)
- 我们用实际数据来说话吧。Special:PermaLink/80500375这是随便测试6620个条目进行基础条目判别,并输出{{Vital article}}字符串。
- 这6620个条目全部运算完毕在预览模式下Lua的后台输出为:
- Lua 使用时间:6.375/10.000 秒
- Lua 内存使用状况:20,669,093/52,428,800字节
- 跑6620次花6.375秒,平均每次基础条目判断仅需花费0.00096299093秒,也就是0.96299093毫秒,连1毫秒都不到。内存用量则是20,669,093 / 6620 = 3122.2194864,平均每个基础条目判段仅需3122字节,3.1kB,而可用的内存有52MB那么多,更不用说这运算只算一次。你总共只需要 0.96 ms、3.12 kB,这甚至比其他很多模块有效率了好吗。
- 一个1毫秒内完成的运算只算一次,是要担心什么效能问题?我实在没有办法看出是要担心哪门子的性能问题。既然一个基础条目判段只需要不到1毫秒,那我认为你上面的“削这个已经很折磨人的Lua”完全是无稽之谈,完全说不过去。Lua本身的目的就是要来降低维基代码的开销的,你随便一个维基代码解析都可能比我上面那个运算来的久。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月15日 (一) 05:28 (UTC)
- 已逾一周无新留言,因此根据WP:7DAYS,七日无进一步发言视为已达成初步共识;再依据WP:7DAYS“
已获提案人正当合理的回应,且自该回应起计的3日后无进一步再回应,应视为该意见已解决。
”上方意见自最后发言起已逾三日无其他回应,因此视为该意见已解决,故将“将{{Vital article}}并入{{WPBS}}的|vital=
参数”视为已达成初步共识,预计将使用修改方案以及其布署链接和测试样例1、测试样例2,以及(±)合并{{Vital article}}到{{WPBS}},来达成这个初步共识。既然依据WP:7DAYS已达成初步共识,那么将准备进行公示。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月22日 (一) 05:31 (UTC)
- 已逾一周无新留言,因此根据WP:7DAYS,七日无进一步发言视为已达成初步共识;再依据WP:7DAYS“
- 这6620个条目全部运算完毕在预览模式下Lua的后台输出为:
- 公示7日,公示内容“将{{Vital article}}并入{{WPBS}}的
|vital=
参数”(同时执行方案①修改方案以及其布署链接和方案②(±)合并{{基础条目横幅}}及{{Cba/discuss}}到{{WPBS}}(已由修改方案涵盖)),另见此说明。(注:{{Vital article}}是重定向页,亦会更改重定向目标)-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月22日 (一) 05:31 (UTC)
- 我们用实际数据来说话吧。Special:PermaLink/80500375这是随便测试6620个条目进行基础条目判别,并输出{{Vital article}}字符串。
- @Kanashimi:Module:Vital_articles#L-216基本上就是英文维基的Code,我们已经简单改enwiki的程式码来用了,您似乎有所误会,请自行对照Module:Vital_articles#L-216与en:Module:Banner_shell#L-90。而且您可以看到,本提案预计的作法已经把它下分到Module:Vital_articles去了,并不是像英文维基里全部整坨塞WPBS模块,故不存在您所提的“可维护性和可读性低”的问题,因为已经分门别类处理了:WPBS处理WPBS的任务、Vital articles处理Vital articles的任务,故上述疑虑不存在,杞人忧天。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月14日 (日) 13:14 (UTC)
- Module:Vital_articles都已经分成类似杂凑表查询了,有什么折腾的问题?已经高效率优化了好吗。理论上,此实现的内存开销甚至有望低于英文维基,因为英文维基只分成27个表,而中文维基是36个表,代表中文维基每个表的项目数量更少,在类似散列函数计算之后,要读取的JSON更小,表示内存用量更少,单个表项目更少表示查询更快。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月14日 (日) 13:12 (UTC)
- 若能简单改enwiki的程式码来用,或许不必担心折腾的问题。另一方面假如只留UI功能的话,是否干脆维持原来的{{Vital article}}就好?--Kanashimi(留言) 2024年1月14日 (日) 13:06 (UTC)
基础条目模板合并案公示[编辑]
- 见公示声明。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月24日 (三) 03:38 (UTC)
- @A2569875:我试过了,没有什么大问题,但建议WikiProject banner shell模板中的
BOTTOM TEXT
参数可以自动废除了,不然如果还有发现这个参数的专题模板还要备注也真够麻烦的。--Z7504非常建议必要时多关注评选(留言) 2024年1月22日 (一) 05:38 (UTC)
- @Z7504:请问WikiProject banner shell模板哪来的
BOTTOM TEXT
?你是不是弄错了?WikiProject banner shell的原始码内根本没有你你提及的那种内容。你是否搞错了什么,还是误会了什么?-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月22日 (一) 05:44 (UTC)
- 还真的没有,那应该误会了。那这
BOTTOM TEXT
参数到底是从哪里来的?该废除的参数还是应该尽早废除。基本上只剩下一个(?)疑问:是不是还要写{{WPBS|class=xxx}}
才能让其强制正常显示?--Z7504非常建议必要时多关注评选(留言) 2024年1月22日 (一) 06:05 (UTC)
- @Z7504:显示什么?你是不是又误会了?本次公示是针对基础条目的参数,请问跟class到底有什么关联?-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月22日 (一) 06:12 (UTC)
- 这里就是一个活生生的例子(比如这笔和这笔),这点小bug麻烦也先改了吧,不然都还要强制输入才能确保正常显示,问题不大才对。--Z7504非常建议必要时多关注评选(留言) 2024年1月22日 (一) 06:30 (UTC)
- @Z7504:这根本不是BUG,因为你如果没有给WPBS模板输入评级,它本来就不应该显示任何评级,因为那代表“该条目没有指定通用评级”,不显示评级才是正常现象。再来是,所有维基媒体基金会旗下站点都没有布署能给跨模板传递资料的扩展,所以你输入在专题模板的class当然无法被WBPS获知,如果可以,那就是魔法或者见鬼了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月22日 (一) 06:48 (UTC)
- 还有class处理的部分根本不在本案本次公示的处理及讨论范围内,强烈抗议强迫并案处理或企图搞案外案的要求。然后还有上面说明的WPBS没有办法直接获取输入在专题模板的评级值。关于你的疑虑,等本案通过后User:Kanashimi会用机器人自动将专题模板的评级参数补给WPBS模板,故您也不需要手动给WPBS手动给评级。故您所提到的东西不予修复,因为届时他会被Kanashimi的机器人自动处理。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月22日 (一) 06:58 (UTC)
- @Z7504 我稍后会申请将数量最多之评级填入{{WPBS}}的任务,基本效果就如同您上面所列的编辑。不晓得这是不是能解决您的问题呢?--Kanashimi(留言) 2024年1月22日 (一) 06:57 (UTC)
- @Z7504:这根本不是BUG,因为你如果没有给WPBS模板输入评级,它本来就不应该显示任何评级,因为那代表“该条目没有指定通用评级”,不显示评级才是正常现象。再来是,所有维基媒体基金会旗下站点都没有布署能给跨模板传递资料的扩展,所以你输入在专题模板的class当然无法被WBPS获知,如果可以,那就是魔法或者见鬼了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月22日 (一) 06:48 (UTC)
- 这根本不是需要修复的BUG。WPBS中
|class=
参数的填写一开始就是设计要让机器人自动维护的部分,让模板自动处理此问题反而问题更多且不切实际,更适合由一个外部机器人进行监察和更新操作,因此该意见应视为对上方议案有所误会所提出的意见,同时|class=
参数的填写也与本案《将{{Vital article}}并入{{WPBS}}的|vital=
参数》毫无关联,因此应无效,若三日内没有异议或进一步回应,则视为该意见已解决。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月22日 (一) 08:40 (UTC)
- 总之全部都是Module:PJBSClass/main的问题,不镶嵌模板就无法判断,但“条目内挂了模板所以可以判断”,您如果那么清楚的话,那就直接建模板阿。标准的自欺欺人,结果居然是没动脑过的回复,被泼冷水真的刚好而已。这样如何保证里面可以不用写上比如
|class=xxx
的参数,变成{{WPBS|collapsed=yes||class=xxx
还能让它正常显示?--Z7504非常建议必要时多关注评选(留言) 2024年1月22日 (一) 23:21 (UTC)- 不需要保证,因为机器人会自动填写
{{WPBS|collapsed=yes||class=xxx
,保证的话等于和机器人抢工作,与本案背道而驰,因为该设计就是要给机器人维护的空间,如果没有正面回答此陈述将视为无效。没填写|class=
显示不一样,反而还有能分辨机器人是否填过的功能,岂不是更好? 另,(!)抗议没考量读者体验就乱讲的提案,评级是面向编者的信息,(-)强烈反对把评级写在条目里,故我认为目前的方案已是最适合的方案; 另,在此警告,在此案讨论|class=
参数已离题。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月23日 (二) 01:24 (UTC)
- 不需要保证,因为机器人会自动填写
- 总之全部都是Module:PJBSClass/main的问题,不镶嵌模板就无法判断,但“条目内挂了模板所以可以判断”,您如果那么清楚的话,那就直接建模板阿。标准的自欺欺人,结果居然是没动脑过的回复,被泼冷水真的刚好而已。这样如何保证里面可以不用写上比如
- 这里就是一个活生生的例子(比如这笔和这笔),这点小bug麻烦也先改了吧,不然都还要强制输入才能确保正常显示,问题不大才对。--Z7504非常建议必要时多关注评选(留言) 2024年1月22日 (一) 06:30 (UTC)
- @Z7504:我直接针对你最初的问题回答“
是不是还要写
”,是,所以需要手动填上。本案并不包含甲乙丙初级自动判断,公示也不包含这个部分,若你希望有甲乙丙初级自动判断请另提他案,因为不在本案处理范围内。 此外,你也无须担心“{{WPBS|class=xxx}}
才能让其强制正常显示?是不是还要写
”问题,因为下方Kanashimi已经申请机器人了,您无需手动填写,此意见可以结案了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月23日 (二) 01:44 (UTC){{WPBS|class=xxx}}
才能让其强制正常显示?
- 本公示不包含甲乙丙初级自动判断,若三日后还在要求甲乙丙初级自动判断将视为无效意见。若希望
|class=
没输入也能自动显示甲乙丙初级请另外提案谢谢,不在本案有办法处理的范围内。“这点小bug麻烦也先改了吧,不然都还要强制输入才能确保正常显示,问题不大才对
”本案是处理基础条目自动化,而不包含class有没有输入的问题,因此不在此案处理范围内,请另提他案,谢谢。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月23日 (二) 02:02 (UTC)
- 还真的没有,那应该误会了。那这
- @Z7504:请问WikiProject banner shell模板哪来的
- @A2569875:我试过了,没有什么大问题,但建议WikiProject banner shell模板中的
- 见公示声明。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月24日 (三) 03:38 (UTC)
已提出机器人作业申请,欢迎提供建议,谢谢。 --Kanashimi(留言) 2024年1月23日 (二) 01:38 (UTC)
- 您直接宣布通过就好了,不必再等三天,因为您全部都解释完毕了,拒绝再沟通。另外有关Kanashimi所提议的机器人提案,没有意见。如此的沟通是不可能会有共识的,别浪费时间了。您如果这么爱写新的条目,麻烦自己继续写条目就好,不要打扰了。因为维基百科的条目已经足够多了,如果不想写新的其实也没差。因为设立A article、B article、C article、Start article、Stub article...这些模板也会有人有意见,但“不镶嵌模板就无法判断,挂了模板所以可以判断”,怪谁啊?上面也讲了您既然自己都知道是Module:PJBSClass/main影响的,但不去考虑修订Module:PJBSClass/main,那么就有设立这个机器人的必要。--Z7504非常建议必要时多关注评选(留言) 2024年1月23日 (二) 04:36 (UTC)
- 还有一点我要声明,并不是不愿意修订module:PJBSClass/main,而是module:PJBSClass/main本来就是设计成要配合Kanashimi所提议的机器人提案而设计的,那么要做的事情显然是让机器人提案推行顺利,而不是去浪费时间修改module:PJBSClass/main。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月23日 (二) 05:06 (UTC)
公示期已到,期内无合理异议,且公示期内的意见之意见提出者已妥协,因此提案公示通过,将进行布署。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月29日 (一) 05:36 (UTC)
- 本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
{{WikiProject Biography}}参数案[编辑]
- 下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
- 《将Vital_article并入WPBS的vital参数》案已进入公示,现就是否将{{WikiProject Biography}}的'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等参数并入{{WPBS}}进行讨论。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月24日 (三) 03:41 (UTC)
- c.f. Wikipedia:机器人/申请/Cewbot/29。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月24日 (三) 03:43 (UTC)
- 本讨论开始于2024年1月2日 (二) 09:53 (UTC)(发起讨论的留言见此),当中包含了支持的意见,至今已逾一个月,因此根据WP:1MONTH“
互助客栈中的提案仅在7日内无新留言时或已讨论达30日后,方可在已取得共识的前提下公示。
”,且本段落已逾8日无新留言,已超过一周无新留言,因此根据WP:7DAYS,有人附议此案(全部支持
视为该附议包含本案),而往后将近一个月没有反对意见,因此视为已有初步共识,根据WP:1MONTH和WP:7DAYS将进行公示。(若三日无人对以上论述有异议将开始执行)-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年2月2日 (五) 09:57 (UTC)
公示到期,期内无合理异议,提案通过。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年2月13日 (二) 03:40 (UTC)
- 本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
是否废除{{WikiProject Biography}}原生的'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等参数[编辑]
- 下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
待机器人User:Cewbot/log/20200122/configuration清理完所有{{WikiProject Biography}}的'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等参数再开始讨论。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年2月13日 (二) 03:42 (UTC)
- 机器人User:Cewbot/log/20200122/configuration正在工作中。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年2月20日 (二) 08:21 (UTC)
- @Kanashimi:'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等参数并入{{PJBS}}好像未能达成共识,未看到有人支持也未有人反对,好像不符WP:共识标准?-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月12日 (二) 05:11 (UTC)
- 唉,看起来需要征集些人发表意见...--Kanashimi(留言) 2024年3月12日 (二) 05:29 (UTC)
- 机器人这个算是已经并入了吗?感觉只要{{WikiProject Biography}}能够正常运作就可以了。--Kethyga(留言) 2024年3月16日 (六) 11:07 (UTC)
- @Kethyga:根据模板全保护方针,要把参数废弃掉需要社群共识。何况这边是要一次性地弃用超过5个参数。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月16日 (六) 11:09 (UTC)
- User:Kanashimi“
唉,看起来需要征集些人发表意见
”,所以是要ping点人来吗?-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月23日 (六) 05:20 (UTC)- 找一些最近发表意见的,以及{{WikiProject Biography}}最近的编辑者编辑者问问意见。
- @Kethyga @Willy1018 @Z7504 @AT @Shizhao @Iokseng 能够给些意见吗?谢谢。--Kanashimi(留言) 2024年3月23日 (六) 06:12 (UTC)
- 目前WPBS好像只有listas参数未传递到{{WikiProject Biography}},感觉也不一定要去掉,假如其他用户添加专题模板的时候没有用{{WPBS}},但是在{{WikiProject Biography}}添加了上述的几个参数,该如何处理。--Kethyga(留言) 2024年3月23日 (六) 10:32 (UTC)
- 这种情况机器人会自动添加{{WPBS}}。--Kanashimi(留言) 2024年3月23日 (六) 11:11 (UTC)
- 目前WPBS好像只有listas参数未传递到{{WikiProject Biography}},感觉也不一定要去掉,假如其他用户添加专题模板的时候没有用{{WPBS}},但是在{{WikiProject Biography}}添加了上述的几个参数,该如何处理。--Kethyga(留言) 2024年3月23日 (六) 10:32 (UTC)
- 还是说,修改“Category:缺少listas变量的传记专题页面”的判定条件?-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月30日 (六) 08:45 (UTC)
- 看了下该分类中的条目,排序应该是正常的,应该只有{{WPBS}}中参数listas为空的时候才加入该分类。--Kethyga(留言) 2024年3月30日 (六) 10:11 (UTC)
- Category:缺少listas变量的传记专题页面分类的添加,由{{WikiProject Biography}}转移到{{WPBS}}如何?这样就不用废除{{WikiProject Biography}}的任何参数(如果废除参数没有共识)只是令{{WikiProject Biography}}不再添加Category:缺少listas变量的传记专题页面,改由{{WPBS}}判断有无传记专题模板,如果有,再根据listas变量的状况增减分类。这部分的patch已经准备好了[2],如无异议可以公示了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月31日 (日) 05:01 (UTC)
- 是否要跟英维保持一致呢,不知道是否有些人习惯将listas添加到{{WikiProject Biography}}上。--Kethyga(留言) 2024年4月5日 (五) 09:36 (UTC)
- 我觉得不用。而且Kanashimi也说机器人会自动将listas参数转移到WPBS。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月5日 (五) 09:57 (UTC)
- 应该问题不大,反正使用评级的也不多,而且BLP参数也转移过去了。--Kethyga(留言) 2024年4月6日 (六) 07:32 (UTC)
- 那我就公示《Category:缺少listas变量的传记专题页面改由{{WPBS}}加入》啰,距离提出已经一周,整个讨论超过一个月,有关意见也已解决。至于参数是否废除目前就作为尚无共识结以待续,因为这一案90%以上完成占据客栈太久了,待《Category:缺少listas变量的传记专题页面改由{{WPBS}}加入》公示若通过后就先存档,参数废除案择日再议。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月6日 (六) 08:18 (UTC)
- 应该问题不大,反正使用评级的也不多,而且BLP参数也转移过去了。--Kethyga(留言) 2024年4月6日 (六) 07:32 (UTC)
- 我觉得不用。而且Kanashimi也说机器人会自动将listas参数转移到WPBS。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月5日 (五) 09:57 (UTC)
不然这样好了,我把 - 是否要跟英维保持一致呢,不知道是否有些人习惯将listas添加到{{WikiProject Biography}}上。--Kethyga(留言) 2024年4月5日 (五) 09:36 (UTC)
- Category:缺少listas变量的传记专题页面分类的添加,由{{WikiProject Biography}}转移到{{WPBS}}如何?这样就不用废除{{WikiProject Biography}}的任何参数(如果废除参数没有共识)只是令{{WikiProject Biography}}不再添加Category:缺少listas变量的传记专题页面,改由{{WPBS}}判断有无传记专题模板,如果有,再根据listas变量的状况增减分类。这部分的patch已经准备好了[2],如无异议可以公示了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月31日 (日) 05:01 (UTC)
- 看了下该分类中的条目,排序应该是正常的,应该只有{{WPBS}}中参数listas为空的时候才加入该分类。--Kethyga(留言) 2024年3月30日 (六) 10:11 (UTC)
- User:Kanashimi“
- @Kethyga:根据模板全保护方针,要把参数废弃掉需要社群共识。何况这边是要一次性地弃用超过5个参数。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月16日 (六) 11:09 (UTC)
- 机器人这个算是已经并入了吗?感觉只要{{WikiProject Biography}}能够正常运作就可以了。--Kethyga(留言) 2024年3月16日 (六) 11:07 (UTC)
- 唉,看起来需要征集些人发表意见...--Kanashimi(留言) 2024年3月12日 (二) 05:29 (UTC)
- 本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
Category:缺少listas变量的传记专题页面改由{{WPBS}}加入[编辑]
- 下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
公示7日如上留言,内容已经准备好了[3]。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月6日 (六) 08:20 (UTC)公示期满,期内无合理异议,提案通过。将提出编辑请求。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月13日 (六) 09:03 (UTC)- @Shizhao:为什么要回退?不是公示通过了?你为何要强行阻止提案通过??你是要这个议案卡死多久???请立刻说明理由!!-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月16日 (二) 03:39 (UTC)
- 两个疑问:不用wpbs,直接用了传记专题模板的怎么办?机器人停摆了怎么办?--百無一用是書生 (☎) 2024年4月16日 (二) 06:37 (UTC)
- @Kanashimi:如果一般用户把参数加到传记专题模板,且不放置WPBS模板时,有配套措施吗?虽然你说这种情况机器人会自动加入WPBS模板,但我看你的机器人好像没法做到那么“即时”的更新?您对此情况有什么看法?-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月16日 (二) 08:01 (UTC)
- 现在应该每个礼拜会执行一次。若是有必要也可以改成每天执行。--Kanashimi(留言) 2024年4月16日 (二) 22:53 (UTC)
- 不能WPBS和传记专题模板两套参数并行么?--百無一用是書生 (☎) 2024年4月19日 (五) 03:34 (UTC)
- 现在的传记专题模板,没办法得知页面中是否已挂上WPBS。如果要并存,需要再写一个程式让传记专题模板“认知到WPBS模板存在与否”。如果传记专题模板能“认知到WPBS存在”那就可以把在无WPBS时加分类、有WPBS不加分类。所以,如果要实现的话,就必须写程式让传记专题模板能识别WPBS的存在与否。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月19日 (五) 03:56 (UTC)
- @Shizhao:en:special:diff/1156304191看起来好像还挺简单的?但需另外引入en:Template:Find page text。且此diff无须编辑{{WPBS}}即能解决问题-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月19日 (五) 04:48 (UTC)
- 现在的传记专题模板,没办法得知页面中是否已挂上WPBS。如果要并存,需要再写一个程式让传记专题模板“认知到WPBS模板存在与否”。如果传记专题模板能“认知到WPBS存在”那就可以把在无WPBS时加分类、有WPBS不加分类。所以,如果要实现的话,就必须写程式让传记专题模板能识别WPBS的存在与否。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月19日 (五) 03:56 (UTC)
- 不能WPBS和传记专题模板两套参数并行么?--百無一用是書生 (☎) 2024年4月19日 (五) 03:34 (UTC)
- (?)疑问:@Kanashimi:那么Shizhao说的“机器人停摆了怎么办”,这部分有解方吗?-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月18日 (四) 14:59 (UTC)
- 程式码开源,真出问题其他人可接手。--Kanashimi(留言) 2024年4月18日 (四) 21:46 (UTC)
- 我的意思是尽可能能够保留/提供一种不必依赖机器人(对人类友好)的方式,这样即使没了机器人也可以依靠手工维护--百無一用是書生 (☎) 2024年4月19日 (五) 03:32 (UTC)
- 现在应该每个礼拜会执行一次。若是有必要也可以改成每天执行。--Kanashimi(留言) 2024年4月16日 (二) 22:53 (UTC)
- @Kanashimi:如果一般用户把参数加到传记专题模板,且不放置WPBS模板时,有配套措施吗?虽然你说这种情况机器人会自动加入WPBS模板,但我看你的机器人好像没法做到那么“即时”的更新?您对此情况有什么看法?-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月16日 (二) 08:01 (UTC)
- 两个疑问:不用wpbs,直接用了传记专题模板的怎么办?机器人停摆了怎么办?--百無一用是書生 (☎) 2024年4月16日 (二) 06:37 (UTC)
- @Shizhao:为什么要回退?不是公示通过了?你为何要强行阻止提案通过??你是要这个议案卡死多久???请立刻说明理由!!-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月16日 (二) 03:39 (UTC)
- 管理员在尝试执行通过的提案时发现潜在问题,先前并未考虑到此问题,故此案公示结果 搁置。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月16日 (二) 07:42 (UTC)
- 本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
Category:缺少listas变量的传记专题页面方案二[编辑]
- 这个en:special:diff/1156304191可以解决上方Shizhao提出的问题,即由{{传记专题}}自行侦测是否有其他模板(包括但不限于WPBS)提供了listas参数(上方提案内的patch的重复分类之参数
|living=
也可以依此方案执行)来决定是否加入分类。这种方法只需编辑一个模板——只需编辑{{传记专题}}无须编辑{{WPBS}}——但要实行此方案须从enwiki引入一个模板:{{Find page text}},因此提请讨论。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月19日 (五) 06:30 (UTC)- 由于此案为原案的修正(原案已公示通过),且一周无人有异议,视为有初步共识。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月26日 (五) 10:15 (UTC)
- 因需引入{{Find page text}},而引入{{Find page text}}已一周无异议,视为有初步共识。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年5月4日 (六) 07:27 (UTC)
- 公示7日-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年5月12日 (日) 02:54 (UTC)
- 公示期间已过,期内无合理异议-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年5月19日 (日) 09:01 (UTC)
- 已约一周无人对“
公示期间已过,期内无合理异议
”有异议,因此公示通过,提案通过,将开始引入{{Find page text}},而引入{{Find page text}}。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年5月26日 (日) 01:38 (UTC)
- 已约一周无人对“
- 公示期间已过,期内无合理异议-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年5月19日 (日) 09:01 (UTC)
- 公示7日-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年5月12日 (日) 02:54 (UTC)
- 因需引入{{Find page text}},而引入{{Find page text}}已一周无异议,视为有初步共识。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年5月4日 (六) 07:27 (UTC)
- 由于此案为原案的修正(原案已公示通过),且一周无人有异议,视为有初步共识。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月26日 (五) 10:15 (UTC)
- {{Find page text}}引入成功。已为新方案创建Patch,Special:Diff/82875808,并且经过测试Special:Diff/82875855,测试为有效,能正确地实现本案《Category:缺少listas变量的传记专题页面改由{{WPBS}}加入》的预期效果。且由于其判定的方式,该参数得以保留,并且达到预期效果,因而解决了User:Shizhao所提出的问题。本声明放置一周,若无异议,将进行下一个阶段。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年6月1日 (六) 10:47 (UTC)
- 说实话根本看不懂相关提案,也不知道从何评价Orz —— Eric Liu 創造は生命(留言・留名・学生会) 2024年6月3日 (一) 02:32 (UTC)
评级系统缺失问题[编辑]
- (原始标题为“将{{Classicon}}与{{Class/icon}}同步”配合公告栏调整标题。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月5日 (五) 07:47 (UTC))
配合上方#Random_Thought: 跟进英维的WikiProject_banner_shell改版因此需要解决评级系统缺失问题,故提出以下议案-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月25日 (一) 09:49 (UTC)
- 预计办理流程:
- 修正评级系统被不当过滤掉的评级值: 公示通过已布署
- 让评级系统Special:页面评级均能正确接收到评级值,以便让{{WikiProject_banner_shell}}工作顺利。
- 同步各模板/块的评级值: 公示通过已布署
- 评级元模板调用了多个不同的评级值转换模板,但各评级值转换模板/块的评级值定义有所出入,将会影响{{WikiProject_banner_shell}}的运作,因此需要修正。
- 将{{Classicon}}与{{Class/icon}}同步: 公示通过已布署
- 以上都完成后,目前评级系统的图是在各评级定义模板/块不一致,且Style也不一致,为了与XTools也统一,故作出此提案。
- 一切完成之后,将会同时把评级规范立起来(即立WP:QUALITY)为指引,以便完善评级系统的所有缺失部分。
- 修正评级系统被不当过滤掉的评级值: 公示通过已布署
- 目前先做到这样,统整整个评级系统并修正评级系统缺失问题。若未来还有需要调整的会在办理过程提出,滚动式修正,欢迎发表意见。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月5日 (五) 08:06 (UTC)
第一阶段:修正评级值不同步问题[编辑]
议案1:将{{Classicon}}与{{Class/icon}}同步[编辑]
- 下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
我认为应将{{Classicon}}与{{Class/icon}}进行同步。{{Class/icon}}提供了比{{Classicon}}更多种级别的图示,如请求、未来、动态等评级的图示,{{Classicon}}都没有。而若{{Classicon}}与{{Class/icon}}合并的话,则等同于{{Classicon}}改成Module模式,需要社群共识,故发起讨论。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月25日 (一) 09:49 (UTC)
- (+)支持合并,后者({{Class/icon}})目前只有在154页上使用。-- Willy1018(留言) 2023年12月26日 (二) 01:33 (UTC)
- (?)疑问:@Willy1018:那要不要{{Classicon}}重定向到{{Class/icon}}?刚才已补充{{Classicon}}所有功能到{{Class/icon}}了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月26日 (二) 02:33 (UTC)
- 可以,但前者{{Classicon}}被全保护,只有管理员才能进行编辑,需要提{{ep}}。-- Willy1018(留言) 2023年12月26日 (二) 04:56 (UTC)
- 似乎未来之类的评级并未被整个评级系统完全支持?--百無一用是書生 (☎) 2023年12月28日 (四) 02:24 (UTC)
- (:)回应:@Shizhao:有支持,显示评级的最后一个调用是{{WPBannerMeta/qualityscale/mask}},而{{WPBannerMeta/qualityscale/mask|future}}→“未来”,但在要送入
{{#assessment:}}
的{{Class_mask}}需要设|future=yes
才有,不然会被滤掉。而要送入{{#assessment:}}
的{{Class_mask}}直接写死无法设置参数,故建议将要送入{{#assessment:}}
的mask改用{{WPBannerMeta/qualityscale/mask}},这样才能正确支援。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月28日 (四) 02:50 (UTC)
- @Shizhao:已提出编辑请求,Template_talk:WPBannerMeta/core#编辑请求_2023-12-28,处理完毕后未来之类的评级就能被支持了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月28日 (四) 04:11 (UTC)
- (:)回应:@Shizhao:有支持,显示评级的最后一个调用是{{WPBannerMeta/qualityscale/mask}},而{{WPBannerMeta/qualityscale/mask|future}}→“未来”,但在要送入
- 似乎未来之类的评级并未被整个评级系统完全支持?--百無一用是書生 (☎) 2023年12月28日 (四) 02:24 (UTC)
- 可以,但前者{{Classicon}}被全保护,只有管理员才能进行编辑,需要提{{ep}}。-- Willy1018(留言) 2023年12月26日 (二) 04:56 (UTC)
- (?)疑问:@Willy1018:那要不要{{Classicon}}重定向到{{Class/icon}}?刚才已补充{{Classicon}}所有功能到{{Class/icon}}了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月26日 (二) 02:33 (UTC)
- (+)支持,没特别的意见--Z7504非常建议必要时多关注评选(留言) 2023年12月28日 (四) 14:13 (UTC)
- 支持合并。不过纯模板实现也不错。--桐生ここ★[讨论] 2023年12月28日 (四) 21:48 (UTC)
- @桐生ここ:完全不建议模板实现。现时模板实现是使用
{{#switch:}}
,您忘了2020年初{{#switch:}}
爆炸事件Special:PermaLink/58036835#A_technical_issue_with_articles_of_French_communes导致中维崩溃的事件了吗。{{#switch:}}
的开销要高于模块实现,所以建议使用模块实现,安全又有效率。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月29日 (五) 00:06 (UTC)- 这边最近在处理基础条目与{{WikiProject banner shell}}的图示问题(Wikipedia:互助客栈/条目探讨#引入enwiki近期{{WPBS}}之改版,暨将{{Vital_article}}并入{{WPBS}}),(&)建议直接采用{{Icon}}会更通用。--Kanashimi(留言) 2024年1月2日 (二) 09:18 (UTC)
- 但我觉得要有专题专用模板。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月2日 (二) 09:33 (UTC)
- 我想采用不同模板来处理同一件事的问题是较不易维护。--Kanashimi(留言) 2024年1月2日 (二) 09:49 (UTC)
- @Kanashimi:问题是目前{{Icon}}并未完整涵盖Class/icon现有内容。改用{{Icon}}将会导致部分图是消失,或发生变化。我认为专题图示应该要统一的Style,但例如{{Icon|image}}和{{Class/icon|image}}就不一致,而且{{Icon|image}}与以下图示比较{{Class/icon|image}}、{{Class/icon|A}}、{{Class/icon|B}}、{{Class/icon|C}}明显Style严重变调,故(-)反对。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月2日 (二) 10:13 (UTC)
- 或许我们可以扩展{{Icon}}使之涵盖我们想要的范畴,例如采用
{{Icon|image_class}}
?--Kanashimi(留言) 2024年1月2日 (二) 10:20 (UTC)- @Kanashimi:我这个议案只是想先动全保护模板{{Classicon}},至少先同步图示,但您目前这样介入会导致共识乱了,连同不都做不到了,会导致花费更多“跑流程”时间,我想先同步,也做好patch了,都准备好了被你弄没了?我想先动全保护模板{{Classicon}}至少先同步图示;至于以后怎么维护可以再讨论。而且您的提议“
例如采用
”也还没有patch,先现实一点吧,不要纸上谈兵,我只想赶快同步图示,并让Style一致,评级图示是评级图示,其他图示是其他图示;评级图示就该有评级图示自己的Style,(!)抗议乱七八糟的不一致Style图示。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月2日 (二) 10:29 (UTC){{Icon|image_class}}
- 也好。那就等这个讨论结束再说吧。--Kanashimi(留言) 2024年1月2日 (二) 10:30 (UTC)
- @Kanashimi:问题2
{{Icon|image_class}}
会导致评级模板输出的值无法直接输入此模板。评级模板肯定是输出字尾没有“_class”的结果,你这样搞还要多写一个转换器,不是更难维护?-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月2日 (二) 10:33 (UTC)- 我尝试在Module:Icon/data加上下面的项目,似乎可以用?
- --Kanashimi(留言) 2024年1月2日 (二) 11:00 (UTC)
image_class = { image = "Symbol file class.svg", tooltip = "媒體文件頁", },
- @Kanashimi:我这个议案只是想先动全保护模板{{Classicon}},至少先同步图示,但您目前这样介入会导致共识乱了,连同不都做不到了,会导致花费更多“跑流程”时间,我想先同步,也做好patch了,都准备好了被你弄没了?我想先动全保护模板{{Classicon}}至少先同步图示;至于以后怎么维护可以再讨论。而且您的提议“
- 或许我们可以扩展{{Icon}}使之涵盖我们想要的范畴,例如采用
- @Kanashimi:问题是目前{{Icon}}并未完整涵盖Class/icon现有内容。改用{{Icon}}将会导致部分图是消失,或发生变化。我认为专题图示应该要统一的Style,但例如{{Icon|image}}和{{Class/icon|image}}就不一致,而且{{Icon|image}}与以下图示比较{{Class/icon|image}}、{{Class/icon|A}}、{{Class/icon|B}}、{{Class/icon|C}}明显Style严重变调,故(-)反对。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月2日 (二) 10:13 (UTC)
- 我想采用不同模板来处理同一件事的问题是较不易维护。--Kanashimi(留言) 2024年1月2日 (二) 09:49 (UTC)
- 但我觉得要有专题专用模板。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月2日 (二) 09:33 (UTC)
- 这边最近在处理基础条目与{{WikiProject banner shell}}的图示问题(Wikipedia:互助客栈/条目探讨#引入enwiki近期{{WPBS}}之改版,暨将{{Vital_article}}并入{{WPBS}}),(&)建议直接采用{{Icon}}会更通用。--Kanashimi(留言) 2024年1月2日 (二) 09:18 (UTC)
- @桐生ここ:完全不建议模板实现。现时模板实现是使用
- 此段落最后发言至今已逾七日,超过一周无新留言,因此根据WP:7DAYS准备进行公示。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月9日 (二) 12:56 (UTC)
- 公示7日-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月9日 (二) 12:56 (UTC)
- 请管理员编辑Template_talk:Classicon#编辑请求_2024-01-16。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月16日 (二) 13:19 (UTC)
- 本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
议案2:修正评级系统被不当过滤掉的评级值[编辑]
- 下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
上方User:Shizhao提到“未来级”等评级级别无法被完整支持问题,是因为送入评级系统的评级值被不当过滤掉了,即使专题上层已启用该等评级,但最终还是会被“未继承上层参数的{{class mask}}”过滤掉,这样的话就算专题启用了该等评级也没有用,都被滤掉了,根本装饰,白启用了,因此提议将送入评级系统的评级值改为{{WPBannerMeta/qualityscale/mask}}模板,见编辑请求Template_talk:WPBannerMeta/core#编辑请求_2023-12-28,修改前后的比较Special:PermaLink/80307466,可以看到原有的版本评级值大部分都被滤掉了,建议换成提议的Patch,以让“未来级”等评级级别能真正被支持。同时,我也确认值接送未来级能正确被工具识别,见右图,连图示都有,代表评级系统是支援此输出的,能正确地被读取并识别。
因此提出本动议。不晓得各位有没有异议或意见。Ping参与过相关讨论的人@桐生ここ、Z7504、Shizhao、Willy1018:,上方参与过评级讨论的也Ping一下@暁月凛奈、Lopullinen、Milkypine、MilkyDefer:-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月31日 (日) 08:29 (UTC)
- 支持。( π )题外话:台湾之星的标识现在还没改。--桐生ここ★[讨论] 2023年12月31日 (日) 10:36 (UTC)
- 资慈,我觉得行。 --窝法乙烷 儿法梦碎 2024年1月1日 (一) 14:38 (UTC)
- 此段落最后发言至今已逾七日,超过一周无新留言,因此根据WP:7DAYS准备进行公示。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月8日 (一) 2024年1月8日 (一) 14:39 (UTC)
- 公示7日-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月8日 (一) 14:39 (UTC)
- 请管理员编辑Template_talk:WPBannerMeta/core#编辑请求_2023-12-28。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月15日 (一) 14:45 (UTC)
- 本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
议案3:同步各模板/块的评级值[编辑]
- 下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
目前有多个被全保护的评级模板/块的评级值(如有的有漏掉、有的图案、颜色不一致)并不同步,因此提议同步各评级模板/块的评级值。不晓得各位有没有异议或意见。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月31日 (日) 10:30 (UTC)
- (~)补充相应的编辑请求Module_talk:Class/data#编辑请求_2023-12-28、Template_talk:Class_mask/core#编辑请求_2023-12-25和Template_talk:Class_mask#编辑请求_2024-01-05(和2023-12-25是配套的),颜色的部分:Template_talk:Class/colour#编辑请求_2024-01-05。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2023年12月31日 (日) 10:31 (UTC)
- 支持。--桐生ここ★[讨论] 2024年1月1日 (一) 09:03 (UTC)
- 就先改看看,让其他用户实际去测试这样才准,而不是每天一直喊支持。不然只是一直放沙盒而不去实际更改的话,完全不知道到底能不能测试。虽然维基百科终于有认知要将其功能“进步”,但也不应每日这样“无止尽的讨论而没有作为”才是。因此,这个讨论就不用再多说什么了。--Z7504非常建议必要时多关注评选(留言) 2024年1月1日 (一) 11:52 (UTC)
- (:)回应:@Z7504:其实我有私下找User:AT了,但他一直说影响范围太大要先讨论 囧rz…………。我当然也希望能直接改啊,不然WP:7DAYS获共识再公示7天半个月就过去了……-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月1日 (一) 12:05 (UTC)
- 还想说中文维基百科不是长期以来都对专题这个东西爱理不理的,这不就是专题模板在用的相关评级吗?为什么不直接修改让其他人测试呢?建议AT直接帮忙修改吧。因为如果要叫维基百科废除已经存在多年的专题,显然是不可能的,更没有讨论是否要废除专题的必要。--Z7504非常建议必要时多关注评选(留言) 2024年1月1日 (一) 13:45 (UTC)
- (:)回应:@Z7504:其实我有私下找User:AT了,但他一直说影响范围太大要先讨论 囧rz…………。我当然也希望能直接改啊,不然WP:7DAYS获共识再公示7天半个月就过去了……-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月1日 (一) 12:05 (UTC)
- 此段落最后发言至今已逾七日,超过一周无新留言,因此根据WP:7DAYS准备进行公示。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月8日 (一) 14:36 (UTC)
- 公示7日-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月8日 (一) 14:36 (UTC)
- 请管理员依照这则留言布署相关编辑,也就是编辑以下模板:
- 本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
提案已通过请求布署[编辑]
- 下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
- 全案公示通过,请管理员依据以下留言:
- 布署相关编辑,也就是编辑以下模板:
- 本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
评级缺失问题目前办理状况[编辑]
截至2024年1月5日 (五) 17:08 (UTC)已提出三案讨论,三案皆在等待初步共识,以便公示。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月5日 (五) 17:08 (UTC)
进度 | 讨论中 | 初步共识 | 公示中 | 部署中 | 已完成 | 后续维运 |
---|---|---|---|---|---|---|
*通用评级设立 | 已获共识 | 已通过 | 已完成 | 已完成 | 进行中 | |
*评级继承机制 | 初步共识 | 公示通过 | 已完成 | 进行中 | ||
评级值同步 | 初步共识 | 公示通过 | 已完成 | 进行中 | ||
修正过度过滤评级值 | 初步共识 | 公示通过 | 已完成 | 进行中 | ||
评级图示同步 | 初步共识 | 公示通过 | 已完成 | 进行中 | ||
完善评级系统规范 | 讨论中 | 等待中 | ||||
注:标有“*”表示是其他相关提案。 |
- 完成:在本次更新中,以下模板的评级资料已获同步:
- Template:评级
- Module:Class/definition.json
- Module:Class/data
- Module:Class/icon
- Module:Class/styles.css
- Template:Class/colour
- Template:Class mask
- Template:Class mask/core
- Template:Class mask/table
- Template:Class mask/templatepage
- Template:Articles by Quality
- Template:Articles by Quality/total
- phab:T360012(注:若下次要再更改,需要提交新工单)
第二阶段:依据先前共识将不是条目命名空间的评级分类从“XX级条目”改为“XX级页面”[编辑]
- 下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
根据先前共识,需要将不是条目命名空间的评级“XX级条目”的分类改为“XX级页面”,但因技术限制未能将“XX级条目”的分类改为“XX级页面”,因此本案已提出新的方案,依据页面命名空间添加分类,以实现该共识。具体执行方案在Template:WPBannerMeta/qualityscale/sandbox。同时将Wikipedia:条目质量评级标准移动到Wikipedia:页面质量评级标准,不知道各位有没有异议?-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月17日 (三) 04:57 (UTC)
- 副知@Ma3r、Kanashimi、Z7504、桐生ここ:@Kethyga、暁月凛奈、MilkyDefer、Milkypine、Willy1018:-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月17日 (三) 04:58 (UTC)
- 没有异议,
就是不知道会不会出现突发状况。 --窝法乙烷 儿法梦碎 2024年1月17日 (三) 11:35 (UTC)- 已在多面体专题进行测试,详见Category:分类级多面体页面、Category:模板级多面体页面,目前测试整个多面体专题尚未出现问题。待本案正式通过之后才会正式(►)移动分类页面。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月17日 (三) 11:39 (UTC)
- 没有意见,但在专题页面(WikiProject)中使用到的{{Articles by Quality and Importance}}模板应一并解决显示异常之问题(前几天似乎还有这问题,现在不知道),虽然这模板平常根本没什么人在意 囧rz……(所以没解决可能也没差吧?因为专题本来就没什么人在意了)--Z7504非常建议必要时多关注评选(留言) 2024年1月18日 (四) 14:26 (UTC)
- 首先,结尾为“XX重要度”的分类不会移动,不在本计划内,而{{Articles by Quality and Importance}}是读取结尾为“XX级XX重要度”的分类,故基本上本案不会影响{{Articles by Quality and Importance}}。再来,如果这个真的要处理,要本案通过后,分类全部清理好,分类全数移动完成后才能处理,不然现在处理数字都会变成0。故应是下一个阶段要处理的(或者共识是暂不处理),不是此案此阶段讨论范围。此外,如果是{{Articles by Quality}}的话,直接更新分类名称即可。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月18日 (四) 16:02 (UTC)
- 已逾一周无新发言,根据WP:7DAYS七日无进一步发言视为已获初步共识,如本声明无人有异议,将准备进行公示。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年1月26日 (五) 00:32 (UTC)
- 已逾十日无新发言,根据WP:7DAYS一周无进一步发言视为社群“对以上‘已有初步共识’的论述”没有异议,因此将开始公示。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年2月5日 (一) 10:00 (UTC)
- 公示7日-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年2月5日 (一) 10:00 (UTC)
- 本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
分类改名准备[编辑]
- 下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
虽Special:Diff/80961277已公示通过,但因涉及的页面众多,因此宜再进行全站公告。公告完后将进行两个阶段完成:
- 阶段1:全保护页面编辑请求:Template:WPBannerMeta/qualityscale和Template:Class
- 由于该等分类都是以上被全保护的模板自动添加的,因此需要执行以上编辑请求。等编辑请求完成后,数万个页面缓存自动清理完毕后,分类将自动从“XX级条目”改归为“XX级页面”。
- 阶段2:正式(►)移动分类页面(可能是约阶段1完成后再过一周)
- 等缓存全部清完,再将“XX级条目”分类,逐个(►)移动到“XX级页面”分类。
公告一周。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年2月13日 (二) 03:31 (UTC)
- 已提出编辑请求。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年2月25日 (日) 01:07 (UTC)
- 编辑请求已由User:Shizhao执行。 等待系统清除缓存。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年2月27日 (二) 13:22 (UTC)
- 系统缓存已清除完毕,但Wikipedia:互助客栈/求助#“Category:模板级条目”的分类是不是应该移动至“Category:模板级页面”才对?有异议,因此移动作业暂时先暂缓一周,若下周二前没有其他异议,才执行移动(本次实属折腾,明明都WP:7DAYS+公示1周+公告1周+等待编辑请求与系统清除缓存,整个流程走了超过一个月,突然冒出异议到底是啥情况,而且该异议还跟本站无关。。。)。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月4日 (一) 03:50 (UTC)
- Wikipedia:页面质量评级标准中标准级别都是针对条目的,只有非标准级别才有模板级、分类级这些评级,而且非条目命名空间的都不能评甲乙丙初之类的等级,所以评级主要针对的是条目。因此是否应当将其移回Wikipedia:条目质量评级标准,将页面评级作为扩展(专题条目类别标准→专题页面类别标准,需要修改{{Grading scheme}}),与Wikipedia:条目重要度评级标准统一。
- 此外,非条目页面不应该设置重要度,所以Category:不适用重要度条目及其子分类也应一并移动至Category:不适用重要度页面。--Kunjinkao(留言) 2024年3月8日 (五) 02:37 (UTC)
- @Kunjinkao:我提此延伸案的目的就是为了Wikipedia_talk:页面质量评级标准#WP:QUALITY_升为指引,你现在越给我搞复杂,好啊WP:QUALITY永远升不了指引都你害的。Category:XX重要度条目如果改名Category:XX重要度页面]且有的有改有的没改,那你判断统计的模板将被复杂化,这从12月折腾到现在,我已经没有心力了,中间又被Z7504搞,既然你要这样,那我不管这个案子了,你自己想办法。且公示都已经通过了,你又来个“公示通过后”异议,是什么鬼?专门故意折腾我的是不是?-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月8日 (五) 03:55 (UTC)
- @Kunjinkao:我近期没有时间也没有心力针对Module:Articles_by_Quality_and_Importance修改。“Category:不适用重要度条目及其子分类也应一并移动至Category:不适用重要度页面”Module:Articles_by_Quality_and_Importance判断将会变得复杂,如您希望“Category:不适用重要度条目及其子分类也应一并移动至Category:不适用重要度页面”请您自己提出相应模板的修改patch。如无人提出,就会如Wikipedia_talk:条目质量评级标准#总结变成就算有共识也永远不会实现,因为没人写程式。我自己的提案,我当然有义务写完与该提案相关所需的程式码,但并不意味着各种节外生枝我也需要帮忙写程式,这样根本没完没了。
- 本案先前早已公示7天通过+公告7天通过,在这之后冒出异议.....我实在不想评论如此行为。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月8日 (五) 04:11 (UTC)
- @Kunjinkao:您好,由于议案已公示通过,若您觉得议案还有不妥之处还请另起章节修正,此处不受理已通过之议案之再更改,谢谢。--SunAfterRain 2024年3月8日 (五) 04:35 (UTC)
- 我没看到
结尾为“XX重要度”的分类不会移动,不在本计划内
,以为这是提案的一部分。既然如此那就放在后面说吧--Kunjinkao(留言) 2024年3月8日 (五) 04:42 (UTC) - 至于{{Module:Articles_by_Quality_and_Importance}},先看看名称以“Category:分类级不适用”开头的所有分类、名称以“Category:模板级不适用”开头的所有分类该怎么处理吧,这总该是分类改名共识的范畴吧。但我要说明一点,我是在指出实施时出现的问题,并不代表我想推翻共识。--Kunjinkao(留言) 2024年3月8日 (五) 05:34 (UTC)
- 我没看到
- @Kunjinkao:我提此延伸案的目的就是为了Wikipedia_talk:页面质量评级标准#WP:QUALITY_升为指引,你现在越给我搞复杂,好啊WP:QUALITY永远升不了指引都你害的。Category:XX重要度条目如果改名Category:XX重要度页面]且有的有改有的没改,那你判断统计的模板将被复杂化,这从12月折腾到现在,我已经没有心力了,中间又被Z7504搞,既然你要这样,那我不管这个案子了,你自己想办法。且公示都已经通过了,你又来个“公示通过后”异议,是什么鬼?专门故意折腾我的是不是?-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月8日 (五) 03:55 (UTC)
- (►)移动作业进行中。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月12日 (二) 05:02 (UTC)
- (!)意见:绝大部分评级模板都指定了{{class}}的
category
参数,且都为“xx条目”,如此将导致非条目页面的专题横幅模板出现红链。模板参数需要考虑重新设计,比如仅使用“xx”并由模板判定后缀。--PexEric 💬|📝 2024年3月16日 (六) 12:08 (UTC)
- 本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
第三阶段:Wikipedia_talk:页面质量评级标准#WP:QUALITY_升为指引[编辑]
本案最初的初衷就是完成此共识Wikipedia_talk:页面质量评级标准#WP:QUALITY_升为指引,来完成WP:QUALITY_升为指引一事,来正式解决“评级系统缺失问题”(指引/规范未立也算是本系统的一种“缺失”)。等上方都完成,此处将继续。声明:当这些“缺失”都解决后,本人将不再碰评级系统这块了,这烫手山竽真是消磨人的精神。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月8日 (五) 04:40 (UTC)
- 可能我上面没说清楚,让你以为我是反对分类改名的,更不是什么
越给我搞复杂,好啊WP:QUALITY永远升不了指引都你害的
,不能有问题不让说是不是。总之是以下几点:- 页面重新命名为Wikipedia:条目质量评级标准:因为评级针对的是WP:条目,其它模板级、分类级这些评级都是非标准级别(WP:QUALITY就是这么写的),那么页面应当以标准评级针对的对象命名,也就是条目质量评级标准。
除非你打算搞什么甲级模板级,那不是更复杂。此外还存在Wikipedia:条目重要度评级标准,那是否要改成Wikipedia:页面重要度评级标准,总之得有一个要改 - 目前Wikipedia:条目重要度评级标准和Wikipedia:页面质量评级标准是正交的,所以有Category:分类级低重要度宗教条目这种东西的存在,那是不是得命名成Category:分类级低重要度宗教页面。既然分类级不属于标准评级,因此也不必设置重要度,引入更多复杂性,这类页面统统扔去Category:不适用重要度条目去(或者说Category:不适用重要度页面)。
- {{Grading scheme}}修改,因为Wikipedia:页面质量评级标准调用了,这个就是作为WP:指引用词统一的问题
- 页面重新命名为Wikipedia:条目质量评级标准:因为评级针对的是WP:条目,其它模板级、分类级这些评级都是非标准级别(WP:QUALITY就是这么写的),那么页面应当以标准评级针对的对象命名,也就是条目质量评级标准。
- --Kunjinkao(留言) 2024年3月8日 (五) 05:20 (UTC)
- 无论是前次讨论还是本次讨论,都没有提到重要度,因此认为重要度的那个论述怎么样,并不碍于WP:QUALITY升为指引一事。
- 此修改技术成本过大,且认为这样修改与否并不碍于WP:QUALITY升为指引一事。由于目前架构问题,该修改技术上的复杂性,不建议做此修改。除非有人能提出具体的patch ,否则我不支持也不相信此修改能够被实际执行。(当然,如果有人做patch 就另当别论)-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月8日 (五) 06:05 (UTC)
- 如果没有人有异议,你可以自行修改。
- -- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月8日 (五) 06:05 (UTC)
- 关于第一点,重要度只是顺带提及,核心是
评级针对的是WP:条目,其它模板级、分类级这些评级都是非标准级别,那么页面应当以标准评级针对的对象命名,也就是条目质量评级标准。
--Kunjinkao(留言) 2024年3月8日 (五) 06:26 (UTC)
- 关于第一点,重要度只是顺带提及,核心是
第二阶段正式完成后的第三阶段讨论[编辑]
- Wikipedia:互助客栈/其他#评级系统缺失问题已分阶段按部就班完成,可以准备进入最终阶段进行收尾:
- 已完成当时的共识Wikipedia_talk:页面质量评级标准#总结“将不是条目命名空间的评级分类从XX级条目改为XX级页面”,因此将安排Wikipedia_talk:页面质量评级标准#WP:QUALITY_升为指引重新公示。重Ping当时参与讨论的人:@Liaon98、JyunWaan、Lssrn:@Cdip150、Temp3600、Peacearth:。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月19日 (二) 10:49 (UTC)
- 当时的讨论是专题各自评级,而现在的情况是多了通用评级(WPBS)。所以时过境迁,WP:QUALITY要重新讨论了。我之前没有参与讨论,现在有不少想法:
- WPBS评级是专题评级的容器,还是一套有自己标准的独立评级?现行做法属于前者:WPBS评级继承专题的评级,且受各专题各方面的干涉,因此评级原则看似“随意”。
所以我的看法是,通用评级就该如WPBS模板所言,确实地“依照页面品质评定标准”来独立评定,而不是在各专题评级间谋求公约数。可以参考专题评级,但把专题评级当爸爸就不对了😂一篇列表WPBS获评List级而非CL级,是因为它确实没到CL级。另一篇列表获评List级而非CL级,只是因为某个参评专题不设CL级。第三篇列表和第二篇品质相似却成功获评CL级,原因竟是不设CL级的专题没有“染指”该列表。
- 承上,如果我们确定WP:ASSESS本位而非专题评级本位,那就要讨论条目的WPBS该设立哪些级别?英维的PIQA是只支持FA、A、GA、B、C、Start、Stub、FL、List、Unassessed几个经典的“标准级别”。而我们的WPBS是大杂烩:既包括BL、CL这种品质向评级,也包括Future这种非品质向评级。所以WPBS评级所支持的“标准等级”该设哪些?
- BL、CL等品质向等级有两条出路。一是如同英维,只收录广为人知的传统评级,不收录BL、CL这种额外等级;个别专题想启用就在自己的横幅上评。二是将BL、CL升格为通用评级,全体专题横幅亦自动启用BL和CL;如果个别专题自己讨论后坚持不用BL,那可以用掩码把BL改成List或B。
- 对于Future级,一篇未来级条目可以很烂(Stub),也可以比较充实(C),那Future这个等级就没有实现“评价页面质量”的作用。我能想到的用途是在话题中,用未来级作为宽限条目的标记,暂时不影响认定。但这个等级的确不够“通用”,或者说和条目所用的品质评级不是一个维度。
- 对于A级条目。英维的A级在军事史专题存活(且活得很好),但其他专题都是死的。因此英维多次讨论A级的出路,比如从PIQA里开除把A级之类。但你维是真的所有专题都不评A级;所以,把这个只有理论价值的等级从通用评级中灭了挺好。
- 上面的想法也会影响小工具的设置:包括对标准评级的契合,对各专题自定等级的支援,对非条目评级的简化(非条目空间一般人手评级无效)。
- 下文有提到“消歧义级条目/页面”。如果按照命名空间来理解,那就有一个问题:重定向在各个空间都有,那到底是叫“重定向级条目”还是“重定向级页面”?(或者两个都要,但这徒增烦恼)另一方面从实用性上看,专题统计“条目数”都是排除Disambig级的,那消歧义占据条目空间就成了bug而非feature。这次从“条目”移到“页面”更像是正名,但是后缀分家无论是技术实现上还是命名统一性上,带来的麻烦都不少。考虑将后缀统一为“页”,比如品质评级这边的“乙级条目页”“丙级列表页”“模板页”,重要度那边也可以叫“高重要度页”“未知重要度页”,这样观后缀就知道是页面评级体系在整活。
- 我明白很多内容都不在讨论范围内,但我认为之前讨论本身就是系统性不足。比如把非条目品质评级改为“XX级页面”,那为何条目品质评级和非条目重要度分类不动?是改条目和重要度分类真的弊大于利,还是单纯没有讨论过而已?作为这套系统创始者,英文版的非条目还用articles的,个中原因是否值得参考?--For Each element In group Next(留言) 2024年3月19日 (二) 16:05 (UTC)
- 下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
- 硬是等提案要准备收尾才来提意见是怎么回事?!我可以当成你是打算扰乱干扰提案通过吗?!--SunAfterRain 2024年3月19日 (二) 16:40 (UTC)
- 我几年前的主业之一就是评级理论。Wikipedia_talk:页面质量评级标准#WP:QUALITY_升为指引6年前甚至6个月前,我都会像推动MOS:FICT那样,亲自提出修改意见和方案(如WP:QUALITY第二段不符合新形式),让WP:QUALITY成为更优质的指引。但现在评级方面,我认为和这个装睡的社群去合作没有什么意义。所以我的做法就是不发言,看着这个社群未来到底走向哪里。出于对当初理想的怀念,我写下了这些明者自明的意见,但也仅此而已了。通过提案无非就是页面多个“指引”的标签;您看我用户页,就该知道我对这种“社群众评标签”有没有兴趣了。--For Each element In group Next(留言) 2024年3月20日 (三) 16:36 (UTC)
- SunAfterRain 2024年3月20日 (三) 17:12 (UTC)
- 还没有细看,但我对洛普利宁君遭到这样的对待感到很悲哀。--Temp3600(留言) 2024年3月20日 (三) 17:43 (UTC)
- 最初提案开始时说“精神上支持”后消失三个月(2023年12月8日-2024年3月19日),等到提案东西都搞好,准备收尾时,冒出千字文异议,请问这样到底哪里恰当了?—38.46.221.138(留言) 2024年3月21日 (四) 04:10 (UTC)
- 在有用的讨论串下面离题吵架实在无奈,但似乎VP环境已经如此。
- WP:CON明确指出"共识应采纳多数人的意见,并和重要少数的意见作出适当妥协。"、"共识在维基百科是持续不断的过程",对于方针修改,更再次明示"共识最终将根据支持和反对该议题的论点质量所决定"。方针中没有任何字眼要求讨论应"收尾",反而暗示了讨论本身是可以无限延长,以不断修改共识更贴合实况的。所谓扰乱更是莫名其妙。
- 回到讨论本身,如果有足以反驳洛普利宁君的理据,直接提出来就可以。如果反驳不了,甚至根本没有考虑到这一讨论角度,那显然就说明"之前讨论本身就是系统性不足",提案一方存有思考盲点,应该进一步讨论下去。
- 回到这个提案。我与八年前一样,支持将WP:ASSESS创建为指引。然而,洛普利宁的问题必须先得到回答:维基百科:通用评级与维基百科:页面质量评级标准之间有潜在矛盾。通用评级到底是独立的评级系统,还是专题评级的平均分?我对这两者没有特别的见解,但WP:ASSESS应该清楚指明这一上下级关系。
- 如果不幸某页面只有一个专题,而这个专题将页面评为"未来级"等奇怪级别,通用评级是否跟随?
- 请赐教。--Temp3600(留言) 2024年3月21日 (四) 19:45 (UTC)
- SunAfterRain 2024年3月22日 (五) 01:35 (UTC)
- 折腾了三个月,我已经没有修改评级模块的心力了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月22日 (五) 01:52 (UTC)
- Special:PermaLink/81985508#第三阶段:完善制度这里有说,一切以维基百科:页面质量评级标准为主,当专题评完后,维基百科:通用评级再取各专题WP:ASSESS的公约数,不认为有矛盾。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月22日 (五) 02:00 (UTC)
- @A2569875:如果方针是FA级,指引是GA级,那现行WP:QUALITY+维基百科:通用评级大概只有C的水平,还需要很多工作完善:
- WP:QUALITY说“评级主要由专题进行……”。那WPBS评级人是作为什么身份评的?社群成员,还是专题成员?现在WPBS开展一段时间了,相信大部分人的评级逻辑是直接对WPBS评级(而不是专门针对各个专题)。这就和“评级主要由专题进行……”矛盾。
- 有了WPBS后,就有了“社群心目中的评级”,这个评级就是WPBS的评级。这样,大部分专题出于信任社群/懒得评级,而继承了通用评级。对于旧页面,现在的做法很好——假定WPBS评级为各专题评级的公约数。不过这个做法并非必然,我们也可以取各专题的最高值/最低值,只要社群愿意信赖专题。例如英维只有WP:MILHIST真正地在评A,而其他专题是评GA或者B,此时一个做法是取A,而非众数或向下取GA/B。
- 但是下面的问题理论上和执行上都很成问题。例如维基百科:通用评级第5点要求“例如未启用乙级的专题,通用级别遇到规则3判为乙级的情况时,则向下填写为丙级……”。
- 首先,很难判定专题是否启用某个级别。机器人运行者好像都说过做不到这个事情,就更不用说人工评级了。
- 其次,如果B级是标准评级,且多数专题都评B级,那这个条目在社群心目中就是B级。我们不应该迁就特例独行的专题,否则公认的B级条目评C,那B和C还有什么可比性?应该是说,不设B级的专题应该自己收拾自己的摊子,例如专题评级继承B而表示为unassessed,或者用掩码改成C。
- 第三,现在的BL是标准评级吗?如果不是标准评级,那应该呈现在社群通用的WPBS上吗?如果呈现在WPBS上,多数编者没见过BL,他们看得懂吗?如果你认为大家能看懂,且乐见对列表细致评级,那不如将BL升格为标准评级?如果升格为标准评级,就应该预设对所有专题的class mask启用BL,否则又回到上一点专题“特立独行”的老路。
- 只有一个专题评Future,那WPBS技术上当然可以评Future(且只能评Future)。但上面BL甚至D级都是品质导向级别,那Future和他们并列(而不是attention之类的flag)是什么用意?还有,如果两个专题一个是CL,另一个是Future,而且两者都未设对方的级别,那WPBS到底听谁的?
- 上述问题可以不断打补丁解决(维基百科:通用评级就是打补丁的成果),但这并非良方。大道至简,最实际的方法是:编者以社群成员的身份,以WP:QUALITY的标准评级中的选项为依据,针对WPBS评级。专题评级理论上和WPBS独立,但实践上的评级方式是信任社群评级。然后,我们讨论WPBS具体该支援哪些级别——对于条目,我建议支援传统级别,或传统级别+BL/CL/(SL?);而Future、Merge不属于品质评估,而A级又极不活跃常常被人误解,这两类可以考虑从通用级别中除去。至于要修改的地方,无非就是修订WP:QUALITY、WPBS支援代码、class/mask预设启用代码,就像您说的,要改很简单。
- 您可能看不懂我的留言,也可能看懂了但没有观点。建议您和有实际开设特殊级别的专题联络,看看他们的意见。我可以写出蓝本,但我不想干涉这件事情,也不想在这个物是人非的地方留言。
- @SunAfterRain:
我可以当成你是打算扰乱干扰提案通过吗?!
。当然可以!您怎么想是您的权利。--For Each element In group Next(留言) 2024年3月22日 (五) 16:26 (UTC)- 你以为你维的评级模块是Module:Namespace/data这种随手改一改就好的是吧,改一次的成本有多高您可以自己改看看,不是什么看起来很简单改一改就好--SunAfterRain 2024年3月23日 (六) 03:13 (UTC)
- 我2015年到2016年大幅更改过WPBM相关子模块,比如引入bchecklist。而且如果WPBM不能满足我的需要,我也有能力手写模板。我固然不是A2569875那样的技术专家,但我也知道那些内容属于微调,哪些内容属于重炼。(那时候您似乎还没注册,如果您问一下八九年前一些关注评级的老用户,您大概会知道我都干过什么)
- 上面的问题我早在两个月前就A2569875君交流过。当时他表示现在只讨论技术问题,具体制度问题可以后议。我的意见不是技术问题——等真正的技术修改部署后,对WPBS屏蔽某些等级就OK——所以的确可以后议。A2569875当时态度很激烈,我不想影响他的心情,而且他应该是没有看懂我的意见,所以我就没有继续争论下去。另一方面如果我做主导人,和议案有关的问题无论在发哪里讨论,我都会接受;而A2569875的思路就是a讨论页不谈b问题(我不知道这是不是今日你维的讨论规矩)。我们俩电波对不上,我也不想在客栈留言,所以就直接走了。现在的论题正是“第三阶段(WP:QUALITY_升为指引)讨论”,既然是讨论(而不是走形式直接通过)那我充分陈述我对WP:QUALITY的看法很合理吧?而且讨论3月19日开始,我也没有拖到26日要结案的时候发。
- 就我看来,应该一开始就讨论WP:QUALITY评级这个哲学问题,讨论好方向之后再开始技术修改。而且有了修改体系背书,A2569875的技术修改也能一路绿灯,不用喊“折腾了三个月,我已经没有修改评级模块的心力了”。不过中维人少,评级哲学上确实没几个人能想到这么深;就像技术方面没A2569875,其他人也推不了这个提案。最后我认为本站应该以理服人,而不是靠方针指引或没讨论深度的“共识”堵嘴:能指出问题的内容标上指引也是根基不牢,有道理的论述没有标签也应该令人尊敬。--For Each element In group Next(留言) 2024年3月23日 (六) 05:29 (UTC)
- 别为你不参与讨论找借口,电波对不上不代表就可以事后再来批判,你说以理服人光是你用这个理由我就觉得你服不了人了
- 另外你觉得你的意见不是技术问题但事实就是改动不小的技术问题,光是要改动一个分类就要牵涉到多少模板模块了--SunAfterRain 2024年3月23日 (六) 05:49 (UTC)
- 您的考虑方向我很赞同。不过如果例子举成“改动一个模板就会牵涉多少分类的移动”,那会更有说服力 --For Each element In group Next(留言) 2024年3月23日 (六) 06:58 (UTC)
- 你到底在举什么...--SunAfterRain 2024年3月23日 (六) 07:28 (UTC)
- 您的考虑方向我很赞同。不过如果例子举成“改动一个模板就会牵涉多少分类的移动”,那会更有说服力 --For Each element In group Next(留言) 2024年3月23日 (六) 06:58 (UTC)
- 你以为你维的评级模块是Module:Namespace/data这种随手改一改就好的是吧,改一次的成本有多高您可以自己改看看,不是什么看起来很简单改一改就好--SunAfterRain 2024年3月23日 (六) 03:13 (UTC)
- @A2569875:如果方针是FA级,指引是GA级,那现行WP:QUALITY+维基百科:通用评级大概只有C的水平,还需要很多工作完善:
那我倒觉得您来主持好了,包含修改模板模块的部分,反正您看起来很闲可以泡在客栈陪大家一直耗。--
- SunAfterRain 2024年3月22日 (五) 01:35 (UTC)
我不管你到底对这个议题有没有兴趣,反正你现在的意思是上方内容纯粹是发牢骚你没有要干扰这个提案?!-- - 还没有细看,但我对洛普利宁君遭到这样的对待感到很悲哀。--Temp3600(留言) 2024年3月20日 (三) 17:43 (UTC)
- SunAfterRain 2024年3月20日 (三) 17:12 (UTC)
老实说我真的不懂你们这些这时候再来提意见是用什么心态再看事情的,这个提案已经放超过三个月了,又不是放一个星期就说要公示, - 我几年前的主业之一就是评级理论。Wikipedia_talk:页面质量评级标准#WP:QUALITY_升为指引6年前甚至6个月前,我都会像推动MOS:FICT那样,亲自提出修改意见和方案(如WP:QUALITY第二段不符合新形式),让WP:QUALITY成为更优质的指引。但现在评级方面,我认为和这个装睡的社群去合作没有什么意义。所以我的做法就是不发言,看着这个社群未来到底走向哪里。出于对当初理想的怀念,我写下了这些明者自明的意见,但也仅此而已了。通过提案无非就是页面多个“指引”的标签;您看我用户页,就该知道我对这种“社群众评标签”有没有兴趣了。--For Each element In group Next(留言) 2024年3月20日 (三) 16:36 (UTC)
- 硬是等提案要准备收尾才来提意见是怎么回事?!我可以当成你是打算扰乱干扰提案通过吗?!--SunAfterRain 2024年3月19日 (二) 16:40 (UTC)
- 上述争议主要是因为前期讨论不够充分所致。而近期进一步讨论已展开,因此可以视为争议已消失,引此这段“争议”先关闭,讨论主力请移动到这里来继续进行,以便凝聚共识。感谢配合。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年6月1日 (六) 10:55 (UTC)
- 本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
- 首先感谢宇凡君的努力,您辛苦了。顺便说一点离题得罪人的话:
目前方针版的种种问题,本质还是来源于青黄不接,人手不足。我所认识的宇凡更擅长技术工作和条目写作,这次他会跳出来写方针,相信真的是拖了太久,没有办法,只好自己来写了。维基百科上一代的方针修改主力开始退役,但新一代又还没有成长起来。这说来也是我们培养新人不力,总之人人都有责任就是了。
- 目前的问题如要解决,通用评级指引势必重写。问题只是要怎样重写而已。说白了,洛普利宁是反对通用评级的“由下而上”逻辑,再深挖下去,涉及专题组与社群整体之间的互动问题,对应现实生活中的中央-地方政府间,集权-分权的冲突。这样展开就显然太复杂了,我只是希望指出为什么洛普利宁会认为这个指引写得不好。
- 回到维基。尽管从宪法的观点出发,确立各子组织间的权力分立应是创建规则的第一步,但考虑到中文维基并不怎么关注这一问题,我就建议维持现状好了,省得麻烦。反正即使是下而上,要修改专题评级,直接一起修改所有专题的评级就可以(显然这就一次侵犯了数个专题的自主权,但上面说了,中维人这方面的理解力有限)。下而上的(理论上)优势当然是“各专题组可以按各自所擅长的领域,共同对跨领域的条目进行评级,会比WPBS只用一个评级员来得准确”。实际上嘛,就是懒得改。
- “WPBS评级人是作为什么身份评的”:从下而上的观点而言,没有专题组的条目评级,算是社群托管了该条目,留待专题组前来接收,等价于联合国托管理事会。最终还是需要专题组的专家前来正式评级。
- "标准评级":基于减少修改范围(懒)的因素,建议只容许使用“标准级别”来评级。也就是说,暂时放弃将BL/CL加入WPBS,待更多专题启用这些评级,更为人所熟悉后,再来讨论。future等评级则不容许更新到WPBS上去,机器人应视这些条目为“没有评级”,由人类前来处理。
- 最后,感谢@For Each element In group Next:前来,指出这些要点供大家讨论。说实话我本来也不想发言的,打了这些东西花了我一个多小时。也希望你能与我一起坚持到这项修改完结。
- 以上。--Temp3600(留言) 2024年3月23日 (六) 03:33 (UTC)
- 如果硬要扯开这个话题,我反倒支持废掉所有专辑的质量评级全部统一处理,因为你维专题参与人数实在少到除了几个大专题之外没有办法给出一个真的符合自己专题的评级标准,而且去查大专题的评级标准实际上也与通用标准没有差异,那这样给各专题评质量有什么意义?--SunAfterRain 2024年3月23日 (六) 05:54 (UTC)
- (以上没有要废掉重要度评级)--SunAfterRain 2024年3月23日 (六) 05:56 (UTC)
- 如果完全废除专题评级,将权力上移给WPBS,那就算不谈这种集权行为是否影响了专题组的自治,也需要将目前已经由专题组评级的条目改为WPBS格式,并处理评级不一致的问题。我是不太看好能搞定啦。--Temp3600(留言) 2024年3月23日 (六) 07:10 (UTC)
- @Temp3600:感谢您的解释!虽然讨论很不愉快,但至少讨论者都能理解我要引出的思考点了。现在我的任务大功告成了--For Each element In group Next(留言) 2024年3月23日 (六) 06:58 (UTC)
- 喂喂,不准跑掉( --Temp3600(留言) 2024年3月23日 (六) 07:14 (UTC)
- 所以你知道为什么我说他明显有意扰乱了吧(摊手--SunAfterRain 2024年3月23日 (六) 07:26 (UTC)
- 喂喂,不准跑掉( --Temp3600(留言) 2024年3月23日 (六) 07:14 (UTC)
随意的分段[编辑]
- 另外回应SAR的是,技术人员与行政官僚本身就是两项不同的工作,互相批评在我看来并无意义。nerd的下场,可以参考为什么苹果公司会赶走乔布斯。--Temp3600(留言) 2024年3月23日 (六) 03:37 (UTC)
- (:)回应:@Temp3600:最初的提案是Wikipedia:互助客栈/其他#没有主题的页面如何评级。起因是我遇到有条目不属于任何专题,所以如果要评级,会有困难。(所以,我的动机很简单,我本来就只是在写条目,遇到了一个问题,我来客栈讨论解方,结果折腾了三个月,途中不乏某些维基人精神攻击,提案看起来快搁浅,精力消磨没了,写条目的动力也没了。在本案开始之前,我一个月写十几个条目,本案开始之后,三个月我只写了两个条目。)。关于该问题由MilkyDefer给出的解决方案是修改{{WPBS}},于是开始讨论共识并执行,以及其配套的《评级系统缺失案》甚至还因技术需要跑了几趟phab(如phab:T360012)。因为最原始的目的《没有主题的页面如何评级》,代表其讨论页会放置空{{WPBS}},也就是没有任何专题的{{WPBS}},所以当然要能支援填写所有评级级别,包括但不限于非标准级别(为此,我还特地翻过所有专题、所有维基百科上出现过的评级级别,统整出所有专题定义的所有级别,大概40几个)。而当{{WPBS}}如果开始填入复数个专题,{{WPBS}}如果又要限制能填写的级别,程式逻辑势必变得复杂,所以我的解决方案是不改程式(你知道的,改全保护的程式不是那么简单),改立WP:通用评级指引制约,如可能也把评级系统的不同步级缺失补齐,其实目的也就只是《没有主题的页面如何评级》而已。而只是恰好Kanashimi要跑评级机器人,所以我索性再修改一下程式,跑客栈共识+公示流程,虽中间与Z7504发生争议(其实消耗了我非常多精神)但最后都通过了,而“去match Kanashimi机器人”这部分其实已经超出我原本想编写的程式内容了。后续所有技术案都通过了(过程中洛普利宁在客栈中不发一语)所以程式码当然不会包含他所期望的部分啊。维基百科是志工性质,不强迫任何人参与,既然我已经写好我想写的程式,那我为何还要在最后“可能”可以收尾的时候,帮“洛普利宁的理想”写程式?程式技术不难,但全保护和繁杂的评级系统,加上客栈不时出现精神攻击,说实在我的精力已经耗尽。我提供的任何一段程式码都没有拿到任何薪水,纯粹就是最初我想做、我想解决某些问题,但像现在这样节外生枝是否生得太夸张了?-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月23日 (六) 04:13 (UTC)
- 我想,在洛普利宁的心中,他在最初就已经您解决了你的问题:维基百科有一个万能专题
{{WikiProject Article assessment}}
,你只要将没有专题的条目通通添加到这个专题下就可以,问题立刻解决,不需要碰WPBS。我也认为这是最简单的方法。只需要跑一次机器人,把所有没有专题的条目全部加入WikiProject Article assessment,就可以了。 - 顺便一说,我自己也试过帮助条目找专题,但即便有新rater的协助,仍然很难。最大的问题是,我不知道有那些专题存在,又不知道他们的简写。如果宇凡你能改良rater,让程式可以搜索,甚至推介专题给我来选择,会很有帮助。比如有一个英国足球队条目,但还没有专题,但分类已经写了这是英国条目,rater能不能够提示我加入英国专题(或者别的什么专题?)。
- 如果不行,可以考虑一个简单一点的修改方案:当条目没有专题时,rater默认添加WikiProject Article assessment,就可以照常评级了。
- 但现在WPBS已经生出来了,总不能走回头路。但这个也不容易,一会儿再写。--Temp3600(留言) 2024年3月23日 (六) 04:47 (UTC)
- 我想,在洛普利宁的心中,他在最初就已经您解决了你的问题:维基百科有一个万能专题
- @Temp3600:这完全不是什么两种不同工作的问题,有意见之前重写模块时一起纳入考量重写就好,那时候提出我想娜娜奇也会尽可能配合的,但洛普利宁同学是喔我支持改写,人家写完都开始运行了再来抱怨。不要跟我说什么滚动式修正,他提出的意见很显然不是因为模块上线才出现的。--SunAfterRain 2024年3月23日 (六) 05:38 (UTC)
- 然后回到“Template_talk:WPBannerMeta#编辑请求_2024-01-08”。洛普利宁的批评是对的:宇帆在这次重构中,只考虑了技术层面上如何实行WPBS的改版,忽略了行政上的架构问题:所谓通用评级,由于每个条目只能有一个,客观上就有压倒原来专题评级的意味。于是这就进一步产生了通用评级与专题评级的冲突,新创建的WPBS机关在权责上如何与原来的专题委员会划分的问题。现在那些WPBS有没有CL级,未来级的问题,本质上都是没有完成项目定义就急于进入开发阶段,结果现在开发成果不完全符合要求,但是要再更改,工作量又很大,于是卡住了。
- 所以现在还是要回到那个编辑请求,解决掉1月时的问题。然后由于技术负债,问题要尽量靠行政程序解决。这就是目前的工作。
- 宇凡那时的观点,也不能说错,毕竟维基百科也没有技术可以阻止你发侵权垃圾内容对不对,但是我们有行政手段,有制度可以将侵权内容通过删除页面功能处理掉。我估计这边最后也会采用相同的方向,WPBS模版支持很多参数,但在指引中,会指明只有部分参数才可以合法使用,如果用了其他值,即使能够正常显示评级,其他人也可以回退,警告这一套。--Temp3600(留言) 2024年3月23日 (六) 08:43 (UTC)
- @Temp3600:问题就出在于,最早MilkyDefer的起草就有未来级、CL级等等,然后我还Ping了洛普利宁问他这样可不可以,但他完全没有任何答复,到头来还是只有一句“精神上支持”,我怎么知道问题在哪,直到一月开发完成才开始说这里不对、那里不对,这样我是要怎么搞。反而User:Willy1018事先指出了具体问题,我得以依照他的问题在开发阶段先行解决,并让User:Willy1018说出了“
感谢贡献,目前已复核已符合预期。
”。完成后才再修改成本比较高,一开始又不讲清楚,说完“精神上支持”然后跑掉,然后现在争议后要叫我扛责任。我这样消磨掉的精神状况可能需要去放维基假期了-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月23日 (六) 09:00 (UTC)- A2569875:首先向您道歉,我没有及时回复您的提醒,在1月份的讨论中,我也没有坚持将意见表达清楚,因为我认为您将来会用掩蔽代码的方式处理WPBS评级。我也知道了为何SunAfterRain君会将我提报到破坏区。其次感谢您完成了迄今所有的技术工作。我的意见是针对政策层面,亦即评级体系如何开展。我不参与客栈讨论,亦不会干涉指引讨论的工作;因为很多等级都是我带起来的,我这次只提出我的想法,希望让社群自行讨论如何评级等级。如果讨论结果是敲定启用或不启用某些等级而需要修改模块,而您疲于修改模块,我可以参与技术工作吗?最后就像Temp3600君所言,在下确实有责任。--For Each element In group Next(留言) 2024年3月23日 (六) 09:40 (UTC)
- @Temp3600:问题就出在于,最早MilkyDefer的起草就有未来级、CL级等等,然后我还Ping了洛普利宁问他这样可不可以,但他完全没有任何答复,到头来还是只有一句“精神上支持”,我怎么知道问题在哪,直到一月开发完成才开始说这里不对、那里不对,这样我是要怎么搞。反而User:Willy1018事先指出了具体问题,我得以依照他的问题在开发阶段先行解决,并让User:Willy1018说出了“
- (+)支持User:Temp3600提的:不当使用WPBS参数时,其他人也可以回退,警告这一套。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月23日 (六) 09:11 (UTC)
- 如果能够masking掉WPBS旳等级,待日后成熟等再开启,那自然是最好;不行的话,单改指引也算是解决了问题。--Temp3600(留言) 2024年3月24日 (日) 03:25 (UTC)
- 另外拖@MilkyDefer:出来,future grade 条目要直接沿用还是怎样处理(pia!) --Temp3600(留言) 2024年3月24日 (日) 03:33 (UTC)
- 什么叫沿用?事实上我连现在future grade的使用情况都不是很清楚,可否说明一下背景信息?--MilkyDefer 2024年3月24日 (日) 03:55 (UTC)
- @MilkyDefer:例如en:Talk:Texas_State_Highway_32按你的构想,是什么评级。背景资料....按我很初步的认识,英文WPBS的条目评级系统只容许BCStub等标准评级,但专题组可以按各自需要将条目评为future级等特殊等级。这与目前WP:QUALITY中建议的评级方案并不一致。--Temp3600(留言) 2024年3月24日 (日) 04:05 (UTC)
- 有什么……不一致吗?Future Class列在非标准等级下,并且写有“部分专题还会启用附加等级。”看上去挺一致的欸。--MilkyDefer 2024年3月24日 (日) 04:36 (UTC)
- 咦我写错了...en:Talk:Texas_State_Highway_32如果按维基百科:通用评级,它下面只有一个future-class的专题评级,那么就不能评为stub.在我看来这是问题。--Temp3600(留言) 2024年3月24日 (日) 05:01 (UTC)
- en:Template:WikiProject U.S. Roads列在en:Category:WikiProjects using a non-standard quality scale,因此此篇文章的评级没问题。我觉得WPBS的评级主要是条目整体评价,在zhwiki实施起来基本上也是这个目的。只不过 zhwiki评级似乎比较复杂,所以允许各专题自定义标准,每个专题模板都算non-standard quality scale。这部分实施起来,其精神与enwiki也相同。--Kanashimi(留言) 2024年3月24日 (日) 05:12 (UTC)
- 按英文版的评级方式是没有问题,但来到中维,维基百科:通用评级并不是英维的对等翻译。于是就有了"若一条目仅有一个专题,其通用评级应与该专题所评的等级一致。"这样的条款,影响到WPBS专注在内容评级的工作。顺带一说,这一点也和LP为什么建议全面转用英维制度,将内容评级由专题组上提到社群的精神一致。不过这样就涉及更复杂的改动,恐怕还是免了。--Temp3600(留言) 2024年3月24日 (日) 05:30 (UTC)
- 我个人觉得这一条仅限于单一专题模板采用标准评级的情况下才有效。但假如所有专题模板都属于 non-standard quality scale,则不如废掉。--Kanashimi(留言) 2024年3月24日 (日) 05:49 (UTC)
- 按英文版的评级方式是没有问题,但来到中维,维基百科:通用评级并不是英维的对等翻译。于是就有了"若一条目仅有一个专题,其通用评级应与该专题所评的等级一致。"这样的条款,影响到WPBS专注在内容评级的工作。顺带一说,这一点也和LP为什么建议全面转用英维制度,将内容评级由专题组上提到社群的精神一致。不过这样就涉及更复杂的改动,恐怕还是免了。--Temp3600(留言) 2024年3月24日 (日) 05:30 (UTC)
- @Temp3600:我觉得像Future、Current(某主题是否是新闻事件或未来事件完全取决于专题领域,例如某主题在A领域可能是一件大新闻,所以评Future,但另一个领域关它屁事所以评甲乙丙丁初之一)Merge、Need(这种通常都是向特定专题请求重定向扩充为条目的标记,无关专题就标通用评级的 重定向级吧)这些“聚焦于特定专题”的级别就让相关的专题沿用吧,然后从通用评级的标准评级撤下变成非标准评级,我想问题应该就解决了。修订的部分,我想等到下面确立哪些要设为标准评级之后,再将通用评级指引加上“只能用标准评级”之类的规范应该就能从行政手段解决了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月26日 (二) 17:36 (UTC)
- en:Template:WikiProject U.S. Roads列在en:Category:WikiProjects using a non-standard quality scale,因此此篇文章的评级没问题。我觉得WPBS的评级主要是条目整体评价,在zhwiki实施起来基本上也是这个目的。只不过 zhwiki评级似乎比较复杂,所以允许各专题自定义标准,每个专题模板都算non-standard quality scale。这部分实施起来,其精神与enwiki也相同。--Kanashimi(留言) 2024年3月24日 (日) 05:12 (UTC)
- 咦我写错了...en:Talk:Texas_State_Highway_32如果按维基百科:通用评级,它下面只有一个future-class的专题评级,那么就不能评为stub.在我看来这是问题。--Temp3600(留言) 2024年3月24日 (日) 05:01 (UTC)
- 有什么……不一致吗?Future Class列在非标准等级下,并且写有“部分专题还会启用附加等级。”看上去挺一致的欸。--MilkyDefer 2024年3月24日 (日) 04:36 (UTC)
- @MilkyDefer:例如en:Talk:Texas_State_Highway_32按你的构想,是什么评级。背景资料....按我很初步的认识,英文WPBS的条目评级系统只容许BCStub等标准评级,但专题组可以按各自需要将条目评为future级等特殊等级。这与目前WP:QUALITY中建议的评级方案并不一致。--Temp3600(留言) 2024年3月24日 (日) 04:05 (UTC)
- 什么叫沿用?事实上我连现在future grade的使用情况都不是很清楚,可否说明一下背景信息?--MilkyDefer 2024年3月24日 (日) 03:55 (UTC)
- 另另外我约略看了一下英维,看来它们已经将各专题评级整合起来,会个条目只有一个评级。这是你提出由上而下的背曔原因吗?@For Each element In group Next:--Temp3600(留言) 2024年3月24日 (日) 03:38 (UTC)
- 我也认为WPBS是社群基于标准(WP:QUALITY)对条目做出的评价。当然,社群也允许专题依照自己的标准对条目做出评价,并标记在讨论页上。某种意义上,社群评级和专题评级是“人格独立”的,这里的“上”和“下”更像依赖的上下游,而不是官大一级的上下层。然后既然专题评级是独立的,那专题就可以选择各种策略:
- 社群人多力量大,自行评级太繁杂,WPBS填啥我填啥。(看起来就像评级被废了,但其实是选择和WPBS的做法一样)如果对专题成员评级不服,要么以社群成员身份找社群吵,要么推动专题退群。这就是英维绝大部分专题的策略。
- 预设继承社群评级,但也可以自行覆盖社群评级。这就是我们现在的状态。
- 不继承WPBS的评级,只要自己的class不填就是未评级。英维的退群专题(比如有BL的WP:MILHIST、没A的WP:VG)都是这个策略。不排除有些专题是想自己搞;但也有专题是只开除掉A级,其他等级想继承社群,但因为英维技术不支持策略2而被迫退的。
- 像SunAfterRain说的,绝大多数专题用策略1就够,而且理论上标准相同的专题应该评同样的等级。个别专题有特殊的评级标准,那就采用策略2。真有专题完全不想社群插手,那就上策略3。策略1那就是纯粹的自上而下了。此外,对上游的WPBS规定好标准等级后,将非标准等级映射到标准等级(假设规定BL->List、D->Start、Current->Unassessed),也可以让机器人参考策略2和3的专题填WPBS。
- 自下而上主要还是一堆奇葩等级,逻辑上没法搞。刻度尺测量物体长度,得到的结果应该是稳定的;一次测3 cm、一次测5 cm,就说明测量错了。但如果两次测量都操作无误,那你用的大概不是尺子 WPBS本来评CL,因为来了个不支持CL的专题就改评List,两次评级都没有错,这就说明该制度不适合衡量条目品质。如果将奇葩等级改成WPBS标准评级,或者拒绝参考非标准等级,那这个制度就可行;但这基本就又成了上面的问题。--For Each element In group Next(留言) 2024年3月24日 (日) 16:21 (UTC)
- 我觉得改动WPBS最少的可能是将所有“条目品质性”(甲乙丙丁初等)和“非条目类别性”(Disambig、SIA、Template等)的级别全部设为标准评级(含少数专题另设的Bplus和D、以及很少专题用的A级等[有专题用A级,如台风之类的专题。]),“性质性”(Future、Current等)的级别全部设为非标准评级。这些“与条目品质无关”的评级就让专题自己评,不影响WPBS,就不会出现要在CL级或Future级取舍的状况了。然后各自专题不要的,自己去mask(到时全站公告一下,想接受的专题就接受,不想接受的专题就自行写mask,这样写mask的责任就不会在此次修改上)。技术上成本最小。 只不过以上作法因会将AL、BL、CL、SL也列入标准级别,代表List级别可能会变成没有任何页面会被评成List级,看是要废除List级还是保留List级在代码里,不想跟进的专题自己mask。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月25日 (一) 04:43 (UTC)
- 然后主题专题自设的Complete、Substantial、Basic、Incomplete因WPBS默认在非条目命名空间时会因“Namespace优先”而评成“主题级”,所以我想应该也问题不大。如需在WPBS中禁掉,可可以将Module:PJBSClass#L-53的一堆if陈述式注解掉。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月25日 (一) 04:57 (UTC)
- (~)补充提升为标准评级的级别:
- 典范级、 甲级、 优良级、 乙上级、 乙级、 丙级、 丁级、 初级、 小作品级、( 小小作品级待讨论,因为通常30天就被删除了或提升为 小作品级以上)、 特色列表级、 甲级列表级、 乙级列表级、 丙级列表级、 列表级、 小列表级,以及列在Category:自动评级的页面#分类索引中的所有评级(即一系列可由WPBS自动完成评级的级别)。
- 设置为非标准评级的级别:
- 您说的也是可行方案。目前启用BL、CL的专题,List基本都是当和Start对等的级别来理解;如果都接受List级=初级列表,而不用新建等级,那留着List级也OK。唯一担心的是A级,倒不是有没有人用的问题。A级是高于GA的,英维也是A级评级比GA评级规格高:GA可以随便一个外行评,A级专题内部出三个专家评,FA是包括专题专家在内的社群集体评,所以有FA>A>GA的逻辑链。但是我们的FAC/GAN和英维评级模式完全是两码事,到头会不会还是社群认GA不认A?--For Each element In group Next(留言) 2024年3月25日 (一) 14:33 (UTC)
- (~)补充提升为标准评级的级别:
- 我也认为WPBS是社群基于标准(WP:QUALITY)对条目做出的评价。当然,社群也允许专题依照自己的标准对条目做出评价,并标记在讨论页上。某种意义上,社群评级和专题评级是“人格独立”的,这里的“上”和“下”更像依赖的上下游,而不是官大一级的上下层。然后既然专题评级是独立的,那专题就可以选择各种策略:
- 先多谢各位,意见都很有见地。希望在上方再拆一个小标题。A级与GA的问题是老大难了,我想这次还是先不处理为好。A级虽然很少用,但一直都算是标准评级,现在一下子移除不太好。List级对等于初级列表长远是好主意,但要标记清楚,因为许多旧列表是list级。所以现在list级代表初级或以上的列表。或许长远要创建start list?—Temp3600(留言) 2024年3月25日 (一) 23:35 (UTC)
D级与B+级等标准讨论[编辑]
接上文宇帆君列出的等级。新级别是要写文档的,所以下列意见供参考:
- D级目前看来只有宇帆君活跃的多面体在用,其条目是介于C和Start之间。讲真,流行文化领域,因为关注粉丝向这种扣分内容,D级还是很好用的。
- 比如明星条目,内容上已经有C级该有的内容,但因为很多内容都以粉丝介绍口吻出现,需要大量清理和改写;这时评Start太可惜,就可以评D级。这基本就像多面体专题说的,“内容上可能达到C级水准,但其他方面有严重缺陷”。或者说,写条目的人擅长事实性内容,但不了解这里的格式手册,写出的东西很随意不像百科。
- 另一方面,虚构作品条目也强调要写反响等现实世界内容。一般来说,编者不写现实世界内容,就表示他不熟悉格式手册,所以条目格式、行文等方面也不会太好。这种条目又要清理又要扩充,就可以给Start。但也有从英维FA翻译一半的,条目序言完整、作品介绍也很规范,但该到制作历史和评价,他又他不翻译了。这种只用扩充不用清理的,也可以从Start抬升为D。
- 可以看到,流行文化领域这个D级主要还是可以彰显“内容杂乱/格式差”。但科学等领域大概没有“粉丝内容”,所以这个D级通常会怎么用?
- 另外有了D,是不是未来有可能对等增加DL?
- B+只有英维数学专题有用过,而且现在删了;本地没有专题实装过,只在一些理论研究中提到,所以还是要想想标准怎么订。
- 之前B+的评级标准是“条目高于B级标准”,再把B级标准抄了一遍,这就比较不良定义。GA和B的区别主要在GA还要求中立性稳定性,且文笔和格式的要求高于B。如果要搞B+,那标准大概就是“不要求中立性和稳定性,但其他方面同GA标准”?PS:B6提到的WP:JARGON和地区词在GA标准里没有体现,所以B在某些方面还高于GA;不过现在的英维已经把JARGON要求增补到GA标准里了。
- 之前有提过增设优良列表(GL)。GL和FL的主要区别可以理解为GL不管红(绿)链,且序言不用太优美;这个境界就有点像B+和GA了。不过,FL和GL应该是要有本质差异的——类似WP:GVF的comperhensive和board coverage。例如对于游戏系列,FA应该像死忠那样列出小众改编作品,而GA可以只列出重要作品。(但是很多领域列表是不是没有这种问题?)
- 小小作品更像是一个临时状态,和未评级一样是不该长期存在的。而且小小作品只是长度短,问题还没有广告、侵权等小作品更严重,所以整体统计上把小小作品拆出来的意义是?从维护追踪角度考虑,WP:PETSCAN或者Shizhao的专题机器人通告应该都很好用了。--For Each element In group Next(留言) 2024年3月26日 (二) 15:50 (UTC)
- 感谢提供意见。关于增设新评级级别,如您提出的D-List和Temp君提出Start-List以及上述提到的GL,我想作为长远目标来讨论,现阶段先不处理。一来是phab:T360012本站评级资料表更新工单根据API测试似乎已合并到主程式,而GL则是因为评选设立草案无共识所以工单中就没有申请加入该等级,所以就算现在评了GL可能也无法被某些系统正确识别,同时,一直频繁更改感觉对基金会人员也不太好意思;二来是又要改十余个全保护模板了 囧rz……。(注:如果说有了D就要对等增加DL,那为何有了GA没有对等增加GL😅 甚至图片有“特色图片”若对应FA的话,那为何没有GA对应“优良图片”、A对应“甲级图片”、B对应“乙级图片”[开玩笑的])另外您提供的D级条目用法也十分不错,我(+)附议这样子的用法,科学上可能可以用在使用了太多行话术语导致多数人看不太懂的这种情况吧;而Bplus 我这边是暂无其他想法,如果有其他维基人有什么想法欢迎补充;小小作品级是当时评级系统开发阶段进行测试时增加的级别,当时我找了几篇正文少于50字的条目但没被挂小小作品模板的“老条目”评上了此级,来试验系统能否接受输入,不过后来这些条目一些被提交AFD了、一些被扩充成小作品级了,但考虑到条目如果持续扩充也会持续升级啊,例如小作品升初级,这只是换成小小作品升小作品级而已,只是通常条目停留在 小小作品级的时间可能会非常短而已。另外,我前几个小时仔细重看了一下每个级别,发现比较有问题的应该是deferred级(中维评级系统本次更新完显示为 搁置级)经查,该级别于2015年被加入中维评级系统资料表中,但在WP:TG简单讨论并对照英文维基还有此级别的专题说明显示,该级别代表的意义是“本专题不提供评级,转介由涵盖本专题的专题提供评级”所以可能也不叫做“ 搁置级”,TG上有群友建议“转介级”,不过这种级别对上通用评级的话,基本上存在感就没了,
阿卡林~,不过UUM表示这种转介具有一定程度“重要性”,可能要讨论一下,看是要改名还是干脆就废除掉,或者以“未评级”论之类的。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月26日 (二) 16:52 (UTC) - 感谢宇凡的研究,这个转介级我都没听说过。评级级别方面,宇凡君所指的技术困难确实存在,就像我们这几天讨论了一下,又想到找到这么多评级。如果每次都去phab改,不免扰民。我初步的想法是,quality 指引的标准评级部分创建为指引,规定wpbs 目前社群认可的评级;专题评级维持论述级,方便专题修改,待有共识后再处理。至于wpbs模版,则不需修改原码,只需在模版说明页等写清楚那一些评级因尚未有广泛共识,暂不开放使用,就可以了。
- 标准级方面,我比较关注CL与乙上,大家懂不懂得评。虽说当成推广也无不可。—Temp3600(留言) 2024年3月26日 (二) 23:53 (UTC)
- 那我们现在就先以已登记于phab的级别为主,也就是我上面列出的那些以及列在Category:自动评级的页面#分类索引中的所有评级(即一系列可由WPBS自动完成评级的级别)。CL级标准之前已经订清楚了,所以我想,直接设为标准没有问题,(+)支持作为推广;比较需要讨论的会是 乙上级。我想就用洛普利宁提出的“不要求中立性和稳定性,但其他方面同GA标准”如何?@Temp3600:-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月27日 (三) 01:11 (UTC)
- Template:Grading scheme可能也有关连,描述可能需按这儿的讨论结果一拼修改。--Temp3600(留言) 2024年3月27日 (三) 04:50 (UTC)
- B+在我心中是"冲击优良但失败了"的意思(pia!)--Temp3600(留言) 2024年3月27日 (三) 09:53 (UTC)
- Template:Grading scheme可能也有关连,描述可能需按这儿的讨论结果一拼修改。--Temp3600(留言) 2024年3月27日 (三) 04:50 (UTC)
- (~)补充转介级有登记在phab上,只不过登记成了 搁置级;但如果又要去改,感觉没几天就又要去麻烦基金会技术人员好像不太好……因为2015年就这样写了,就先当历史遗留吧😅-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月27日 (三) 01:17 (UTC)
- 关于“转介级”(现称 搁置级),其也是目前中维{{WPBS}}可填的参数之一。您认为应该要如何处置呢?翻阅en:Wikipedia:WikiProject_Firearms#Quality_scale他似乎把它视为“品质等级”的一种,但实为将评级工作转介至其他专题,然而如此的做法在有{{WPBS}}时就没有存在意义了,因为转介最终就会落回给{{WPBS}}提供评级,所以英文维基{{WPBS}}实施后其有关分类就被WP:O4了(他们好像叫做en:WP:CSD#C1),那所以我们应该要把他列为“非标准级别”还是直接列为“已停用级别”即在{{WPBS}}的Doc上说不要输入此级别?-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月31日 (日) 10:08 (UTC)
- 那我们现在就先以已登记于phab的级别为主,也就是我上面列出的那些以及列在Category:自动评级的页面#分类索引中的所有评级(即一系列可由WPBS自动完成评级的级别)。CL级标准之前已经订清楚了,所以我想,直接设为标准没有问题,(+)支持作为推广;比较需要讨论的会是 乙上级。我想就用洛普利宁提出的“不要求中立性和稳定性,但其他方面同GA标准”如何?@Temp3600:-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月27日 (三) 01:11 (UTC)
- 感谢提供意见。关于增设新评级级别,如您提出的D-List和Temp君提出Start-List以及上述提到的GL,我想作为长远目标来讨论,现阶段先不处理。一来是phab:T360012本站评级资料表更新工单根据API测试似乎已合并到主程式,而GL则是因为评选设立草案无共识所以工单中就没有申请加入该等级,所以就算现在评了GL可能也无法被某些系统正确识别,同时,一直频繁更改感觉对基金会人员也不太好意思;二来是又要改十余个全保护模板了 囧rz……。(注:如果说有了D就要对等增加DL,那为何有了GA没有对等增加GL😅 甚至图片有“特色图片”若对应FA的话,那为何没有GA对应“优良图片”、A对应“甲级图片”、B对应“乙级图片”[开玩笑的])另外您提供的D级条目用法也十分不错,我(+)附议这样子的用法,科学上可能可以用在使用了太多行话术语导致多数人看不太懂的这种情况吧;而Bplus 我这边是暂无其他想法,如果有其他维基人有什么想法欢迎补充;小小作品级是当时评级系统开发阶段进行测试时增加的级别,当时我找了几篇正文少于50字的条目但没被挂小小作品模板的“老条目”评上了此级,来试验系统能否接受输入,不过后来这些条目一些被提交AFD了、一些被扩充成小作品级了,但考虑到条目如果持续扩充也会持续升级啊,例如小作品升初级,这只是换成小小作品升小作品级而已,只是通常条目停留在 小小作品级的时间可能会非常短而已。另外,我前几个小时仔细重看了一下每个级别,发现比较有问题的应该是deferred级(中维评级系统本次更新完显示为 搁置级)经查,该级别于2015年被加入中维评级系统资料表中,但在WP:TG简单讨论并对照英文维基还有此级别的专题说明显示,该级别代表的意义是“本专题不提供评级,转介由涵盖本专题的专题提供评级”所以可能也不叫做“ 搁置级”,TG上有群友建议“转介级”,不过这种级别对上通用评级的话,基本上存在感就没了,
- (有感而发)除了本子节开始的争议外,以上讨论与研究其实都满有意义和价值的,如果能提前在去年十二月,也就是我当初Ping了洛普利宁时,他就发表了这些意见,并开展了我们现在所讨论的东西,那我觉得WPBS应该会更完美。不过现在说这些都是后话了。另,跟大家说声抱歉,我当时一心只想着如何把MilkyDefer起草的临时方案开发成正式方案、如何pass所有testcases 和解决讨论页上各种问题回报(1、2等),一切考量都以技术为优先(我当时优先级最高的考量是:程式怎么写更省效能,于是出现了
mw.loadData("Module:PJBSClass/page")
用于让该功能在整个页面解析的过程只会跑一次,而不会每次调用通用评级时都跑以节省效能),却忽略了行政上的执行问题,而导致了今次的争议,我感到十分抱歉。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年3月27日 (三) 01:30 (UTC)- 所谓“话到嘴边留半句,理从是处让三分”,我觉得是挺有道理的。得饶人处且饶人嘛。(当然这得看对象,要是遇到得寸进尺的恶人,这样就行不通)
- 如果说程式码是机器运行的逻辑,那么行政可说是人类组织运作的逻辑。要做好事情,既需要机器运作畅顺,也需要众人合力。不同维基人从各自的强项出发,一起解决问题,这就是讨论的意义嘛。--Temp3600(留言) 2024年3月27日 (三) 04:47 (UTC)
- ((*)提醒:本次提案推动技术修改的两位“工程师”(User:Kanashimi、User:A2569875)都没时间写程式了...虽然我的原因是因为改到没精力了)。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月1日 (一) 02:00 (UTC)
- 维基百科:通用评级与WP:QUALITY都要弄修改草稿,行政组这边也不好当呢...--Temp3600(留言) 2024年4月2日 (二) 11:40 (UTC)
- 从这里入手,在Module:Class/conver外再套一个函数,把不支援的评级映射到未评级可行吗?--For Each element In group Next(留言) 2024年4月2日 (二) 16:31 (UTC)
- (-)反对我想保留这些自动评级Category:自动评级的页面#分类索引,不然phab白跑了。而且不想被滤的专题也会被你一刀切不当滤掉。后果不会是你想像的那么简单。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月2日 (二) 16:41 (UTC)
- 自动评级的页面基本都是非条目,那不是属于PJBS支援的范畴吗……?对于条目,如果按照上面WPBS作为独立评级的思路,那PJBS就只应接受他自己的等级。比如PJBS不支援current,那PJBS的
class
就不应该填current(如果一定要填current,那PJBSClass.getClassByPage()也应该返回未评级);所以到头来,WPBS只会告诉各个专题自己未对此页面评级。既然WPBS理论上都不会填写current,那支援current的专题就只能手填自己的class;据我所知,专题自己填写的class是优先的,那这时只要对专题模板自己的class套用Module:Class/convert规范化就OK。宇帆君的代码很模块化(不像我写代码什么东西都揉一起😂),我想这个问题应该的确不是复杂问题。当然,如果我们的总工程师说复杂,那就是复杂😂 另外,如果思路确实是要WPBS兼顾所有专题,比如PJBS评级未显示但往外传current,那这个想法就的确不成立了。--For Each element In group Next(留言) 2024年4月3日 (三) 14:16 (UTC) - 另外即使我的意见合理,宇帆君您也没有义务在近期执行技术修改(甚至没必要执行修改)。毕竟“这个想法很好,但碍于技术原因,目前无法实现;欢迎提议人自行解决”也是合理意见😂--For Each element In group Next(留言) 2024年4月3日 (三) 14:33 (UTC)
- 自动评级的页面基本都是非条目,那不是属于PJBS支援的范畴吗……?对于条目,如果按照上面WPBS作为独立评级的思路,那PJBS就只应接受他自己的等级。比如PJBS不支援current,那PJBS的
- (-)反对我想保留这些自动评级Category:自动评级的页面#分类索引,不然phab白跑了。而且不想被滤的专题也会被你一刀切不当滤掉。后果不会是你想像的那么简单。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月2日 (二) 16:41 (UTC)
- 感觉还是社群没有体系性讨论。比如日语罗马字表示方法讨论过好几次,但正经的日本格式手册却现在还推不出来。我之前不留言,基本也是感觉本站没救,什么都懒得说😂 当然只限条目编写方面;站务领域我看讨论挺热烈的。
- ((*)提醒:本次提案推动技术修改的两位“工程师”(User:Kanashimi、User:A2569875)都没时间写程式了...虽然我的原因是因为改到没精力了)。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月1日 (一) 02:00 (UTC)
B+我之前写过论述。鉴于中维的GAN机制(时间短、需求票数多,且评审者普遍社会惰性),B+当GAN预审还是很有生态位的。但是在务实上,等GAN评审素质普遍超过这个乙级评级,B+才会有得玩 耸肩
我想B+(Bplus)的标准可以用WP:WIABCA的大纲来套用WP:WIAGA:
这样B级评审时也顺手按GA(B+)提意见。--For Each element In group Next(留言) 2024年3月28日 (四) 14:20 (UTC)
WPBS级别列表[编辑]
目前{{WPBS}}能接受输入的级别大部分都是phab:T360012向P站登记的级别以级在案《第一阶段:修正评级值不同步问题》时所有评级Data模板统一同步更新的评级值列举如下(共50个。此外由于表格过长,已折叠。请单击[显示]
以展开表格):
标准类别级别 | 标准品质级别 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
非页面级 | (条目) | 典范级 | 甲级 | 优良级 | 乙上级 | 乙级 | 丙级 | 丁级 | 初级 | 小作品级 | 小小作品级 | 无级 | |
列表级 | 特色列表级 | 甲级列表级 | 优良列表级 | N/A | 乙级列表级 | 丙级列表级 | N/A | 小列表级 | N/A | ||||
非条目级 | 文件级 | 特色图片级 | N/A | ||||||||||
主题级 | 特色主题 | N/A | 完成级 | 充实级 | N/A | 简单级 | N/A | ||||||
消歧义级 | N/A | ||||||||||||
同类索引级 | |||||||||||||
重定向级 | |||||||||||||
沙盒级 | |||||||||||||
模板级 | |||||||||||||
模块级 | |||||||||||||
分类级 | |||||||||||||
草稿级 | |||||||||||||
专题级 | |||||||||||||
用户级 | |||||||||||||
使用说明级 | |||||||||||||
界面级 | |||||||||||||
非标准类别 | |||||||||||||
图书级 | |||||||||||||
音频级 | |||||||||||||
未分类级别 | 非标准级别 | ||||||||||||
N/A | 未来级 | 动态级 | 合并级 | 请求级 | 搁置级 | ||||||||
委员会级 | N/A | ||||||||||||
错误级 | |||||||||||||
未评级 | |||||||||||||
未知级 | |||||||||||||
输入其他值{{WPBS}}会输出:错误:无效的输入 |
典范 | 特色列表 | 特色图片 | 优良 | 小作品 | 列表 | 同类索引 |
消歧义 | 重定向 | 沙盒 | 模板 | 模块 | 分类 | 文件 |
草稿 | 主题 | 专题 | 用户 | 使用说明 | 界面 | 非条目 |
以下建议供行政组参考:
- 标准品质级别(可填写在WPBS):
- 标准类别级别(可填写在WPBS):
- 非标准类别级别(不应该填写在WPBS):
- 图书级[Book](曾有共识引入,但因技术原因部署无限期推迟)、 音频级[Audio](只有少数专题将File级做细分,WPBS应都填入File级)、图像级[Image]((▲)同上)、 非页面级[NAPage](只用于特殊专题)
- 非标准品质级别(不应该填写在WPBS):
- 非标准级别(不应该填写在WPBS):
- 技术性级别(不应该填写在WPBS):
- -- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月6日 (六) 03:43 (UTC)
- 感谢总结。我有一些疑问:
- Substub作为标准品质,似乎比较增加维护负担?会创建小小作品的基本都是新手,他们不懂得在讨论页挂{{WPBS}}填
|class=substub
。维护人员也都在条目页标记{{substub}}
,然后打捞人员再从Category:小小作品追踪,这就基本就没人会管讨论页。而且就算有专题模板,如果利用讨论页的分类来维护,就要从讨论页跳转到主页面,也是比较低效的。(MilkyDeferBot可以根据讨论页横幅和条目页{{substub}}
自动生成页面列表,这样也没必要用讨论页评级)此外如果substub是被人手填了,那就还要经常盯着条目,看评级是否过时。所以依靠评级模板来维护substub,感觉有种打捞一分钟,评级三十秒,性价比相当低。所以,WPBS层面统合到stub是否好些? - 正规条目都应该有品质评级,尚未评估品质的条目是Unassessed,条目空间的Disambig等特殊页面也考虑进去了。看英维也没no这个级别,所以无级别的条目会是怎样的?
- Substub作为标准品质,似乎比较增加维护负担?会创建小小作品的基本都是新手,他们不懂得在讨论页挂{{WPBS}}填
- --For Each element In group Next(留言) 2024年4月6日 (六) 05:20 (UTC)
- (:)回应 no级(无级别)是由您建档于评级系统的Special:Diff/72525905#L-149,我只是照抄,并同步到所有评级模板,以及提报到phab:T360012上。所以我也不知道具体会是什么,可能还需要咨询您(因为由您加入的)。我在整理时看到它的理解为“没有级别的”但我当时没有仔细思考什么条目或页面会“没有级别”,您能否协助回想一下当时的时代背景下,您建档No级时的想法或根据呢。 小小作品级我认为是有些条目可能加上了信息框、图片等被WP:小小作品指引PASS而保留,但正文还是不足50字的情况下可以评(我就是有用随机页面看过有很旧的页面有这种状况,但因为它是什么我没听过的小城镇的条目,我不熟就没去扩充,继续按下一个随机页面)。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月6日 (六) 05:56 (UTC)
- Classicon}}里就有no级,我也是从那里搬过去的。做页面列表的时候可能会用到no这个概念,比如这个从英维搬运的名单,no可以用来标记不挂专题横幅的条目。至于用no给条目本身评级,我倒是没见过。 最早的时候{{
- 我明白您说的小小作品级了,这和WP:SUBSTUB又是两个概念,就类似“小作品级”和“小作品”了。我是认为对这么短的条目,精确数50字感觉都浪费时间(反正多20%到60字也一样很烂😂)。如要设立这个级别,换成“正文只有一两句话(约50字以下)的条目”,这样大概看下数量级会比较实用。当然我就只是抛个砖,评级能弄下去还是靠大家,所以这还是看看其他人有什么想法吧。--For Each element In group Next(留言) 2024年4月6日 (六) 06:16 (UTC)
- 所以没有级别(no)是指未创建或已删除的条目吗(红链)?这样可能真的评不了 囧rz……,因为如果在一个红链条目的讨论页挂一个
{{WPBS|class=no}}
就构成孤立页面会被速删😂,如果是删除后创建成重定向页也不会是no级会是redirect级。所以no级可能就变成一个永远不会被填进{{WPBS}}的概念级别了。是否当作标准级别我觉得可以,毕竟您说了做页面列表的时候可能会用到no这个概念,那它应该列入标准,只不过这个标准级别可能永远不会被填入{{WPBS}}罢了。 小小作品级我也想等看看其他人的意见。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月6日 (六) 06:29 (UTC)- 其实说no这个概念也不准确。英维早把不用的图标和等级(包括bplus和no)删了,中维就各种“集大成”从来不做减法,所以留下了一堆未定义的东西。我上面的用例准确来说,是页面已经创建且可能被WPBS评级,但因为没有挂游戏专题的横幅,所以表现出未由游戏专题维护。既然游戏专题不维护,那在专题内部就不用关心页面品质;但是所有页面都有图标,你不放个东西也不好看,所以才放了个图标。或者说,语义上这里应该用
{{icon3|Wikivoyage outline icon.png|alt=未标记专题横幅}}
,但因为偷懒才用了{{class/icon|no}}
;毕竟从分类中根本抓不到no级,这里还是if判断页面已创建但未标游戏横幅,为True才拉到这个分类的。--For Each element In group Next(留言) 2024年4月6日 (六) 06:52 (UTC)
- (:)回应: @洛普利宁:我知道什么东西可能是无级别条目了,大概是Category:维基百科纲要,这些条目基本是点列式(如战争纲要),让人了解“主题纲要”之用。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月21日 (日) 01:31 (UTC)
- 纲要也有完整和不完整的区别。这个相当于列表,也有级别。写得完整点的纲要就是CL/BL。--For Each element In group Next(留言) 2024年4月21日 (日) 03:35 (UTC)
- 其实说no这个概念也不准确。英维早把不用的图标和等级(包括bplus和no)删了,中维就各种“集大成”从来不做减法,所以留下了一堆未定义的东西。我上面的用例准确来说,是页面已经创建且可能被WPBS评级,但因为没有挂游戏专题的横幅,所以表现出未由游戏专题维护。既然游戏专题不维护,那在专题内部就不用关心页面品质;但是所有页面都有图标,你不放个东西也不好看,所以才放了个图标。或者说,语义上这里应该用
- 所以没有级别(no)是指未创建或已删除的条目吗(红链)?这样可能真的评不了 囧rz……,因为如果在一个红链条目的讨论页挂一个
- (:)回应 no级(无级别)是由您建档于评级系统的Special:Diff/72525905#L-149,我只是照抄,并同步到所有评级模板,以及提报到phab:T360012上。所以我也不知道具体会是什么,可能还需要咨询您(因为由您加入的)。我在整理时看到它的理解为“没有级别的”但我当时没有仔细思考什么条目或页面会“没有级别”,您能否协助回想一下当时的时代背景下,您建档No级时的想法或根据呢。 小小作品级我认为是有些条目可能加上了信息框、图片等被WP:小小作品指引PASS而保留,但正文还是不足50字的情况下可以评(我就是有用随机页面看过有很旧的页面有这种状况,但因为它是什么我没听过的小城镇的条目,我不熟就没去扩充,继续按下一个随机页面)。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月6日 (六) 05:56 (UTC)
- 感谢总结。我有一些疑问:
等级标准小结[编辑]
- 洛普利宁在上文提到的“PJBS之PJBSClass.getClassByPage()”自动评级(小勘误:自动评级实由PJBSClass/main.getClassAuto()和PJBSClass.getAutoClass()共同完成,前者以页面状态和挂有模板判断、后者只看Namespace),这些评级会根据页面挂的模板、子页面名称、页面状况和所在命名空间等进行自动评级。这些评级分为两类:不可被
|class=
参数复写的评级以级可被|class=
参数复写的评级。 - 这些级别有:
- 上文提到,目前不在WP:QUALITY中的级别都需要补上文档,因此我起了以下草稿供参考:
- (注:如果有需要修改可以直接编辑本表格,无须经过我的同意(不被视为修改他人留言))
- (注2:下表只列出目前未出现于WP:QUALITY的级别)
- (注3:由于表格过长,已折叠。请单击
[显示]
以展开表格)- 预计种类分成三类:标准级别(描述条目品质)、标准类别(描述页面种类)、非标准级别(专题自定的东西)
预计种类 | 级别 | 代码 | 评级方式 | 标准 | 详细标准 | 读者感受 | 编辑建议 |
---|---|---|---|---|---|---|---|
标准级别 | 特色列表级 | FL | 手动 | 条目通过正式评审,现为特色列表。 | (载于WP:特色列表标准) | 专业水准。它完整覆盖所属范围,通常能提供一个完整的列表,并为每一项提供有用的信息。 | 除非列表所列之主题有了项目变动或所属范围有新发展,否则不应大量增改内容;可能需要改进文法、列表格式,让列表整体更加优美。 |
特色图片级 | FM | 图片、文件或其他媒体通过正式评审,现为特色图片。 | (载于Wikipedia:特色图片标准) | 读者能从该图像、音频、视频或其他媒体以令人信服的方式说明该主题,使观看者想要了解更多。且这个媒体能很大程度的让读者更了解文章的内容或主题。 | 通常不需要对媒体文件做出任何改动,除非能提升分辨率或其他外观品质。可能可以改进对于该特特图片的描述文字或对应题目中的文法,让特色图片能更好地发挥其价值。 | ||
甲级列表级 | AL | (WP:QUALITY已有内容) | |||||
乙上级 | Bplus | 条目已基本完成,有当选优良条目的潜质,经相关专题、讨论页或其他管道评审,确认符合乙上级条目标准。 | 无明显问题,对几乎所有读者都实用。基本达到(未必完全符合)专业百科全书水准。 | 或需相关领域的编者和格式专家修改。可提名WP:同行评审以厘清与优良条目的差距,并进行改善。 | |||
乙级列表级 | BL | (WP:QUALITY已有内容) | |||||
丙级列表级 | CL | (WP:QUALITY已有内容) | |||||
丁级 | D | 条目有所发展,较初级条目更为完整,但仍有重要内容缺失。条目可能在内容方面达丙级水准,但因行文、结构等问题无法获评丙级。 | 条目有些不错的内容,也列出了些许可靠来源,但与丙级条目对比仍有明显缺陷。例如条目未遵循百科文风,文字条理性不足,大量内容仅面向特定圈子(如爱好者内容、科学专业术语或内容)。 | 条目有较多百科全书资讯,但可能也伴随较多难以理解的内容。读者可收获一定的资讯,但可能感到条目章法混乱、某些内容不易理解,难以通读全文。 | 仍需扩充资讯,且或需大幅清理与重组内容。 | ||
列表级(作初级列表使用) | List | 符合独立列表的要求,较小列表更为完整,但未能达到丙级列表的水准。列表中的可靠来源可能引用充分,也可能不充分。尚未细分为甲、乙、丙级的列表也可能暂时归为此类。 | 列表有些有用的内容,但是在许多方面仍有不足,通常缺乏参考资料。列表内容可能不适合百科全书,不符合格式手册的要求。但是列表必须满足最基本的内容方针和独立列表的基本要求,诸如关注度、生者传记,并提供足够符合可供查证要求的来源。初级的列表应无快速删除之虞。 | 已经列出了一些有意义的内容,但对于多数读者仍属不足。 | 应当尽快提供可靠来源,并需大幅更动和组织内容。此外也可改善语法、别字、写作风格、术语的使用。 | ||
小列表级 | SL | (WP:QUALITY已有内容) | |||||
小小作品级 | Substub | 对主题非常基本的描述,但正文不足50字。 | 条目有基本定义,但正文只有一两句话(约50字以下)的条目。其可能有信息框、图片或参考文献。如正文不足50字的条目也缺乏信息框、图片或参考文献,则其可能会被提请删除。 | 有意义内容极少,可能跟典解释差不多。 | 应当尽快将正文扩充至50字以上。 | ||
无级 | No | 尚未创建或已被删除的条目。通常用于创建条目清单时标记不存在页面的级别。 | N/A | 由于条目不存在,因此读者无法获得任何信息。 | 如该主题有创建条目的需求,可以视情况创建条目。 | ||
标准类别 | 同类索引级 | SIA | 由{{WPBS}}程式自动给予级别 | 任何同类索引条目(SIA)页面都属于此类。这些是关于一组具有相同(或相似)名称的特定类型项目的清单文章。 | 挂有{{SIA}}模板的页面 | 读者能找到特定类型项目的文章。 | 请注意,同类索引条目对名称和主题都有要求,即索引项目必须属性相同且名称相似。比如地震列表不是同类索引条目,但以X为名的地震列表就因满足同名、同主题两项条件,属于同类索引条目。 |
沙盒级 | Sandbox | 社群认可用于测试的页面。 | 挂有沙盒标示模板的页面,或模板、模块的/sandbox子页面 | 这个页面的内容可能因为测试原因而频繁变动,可能对任何读者都不实用。 | 无建议。 | ||
草稿级 | Draft | 任何草稿都属于此类。这些通常位于Draft命名空间中,但也可能位于User命名空间中。 | N/A | 这可能是一个发展中的条目,因此可能有一些有意义内容,但对于多数读者仍属不足。 | 任何编辑或者增加内容都会有帮助。应当尽快增加有意义的内容。并尽快推动完成WP:AFC流程,解决相关问题以便成为正式条目。 | ||
专题级 | Project | 任何维基专题相关页面。 | N/A | 专题页面主要是面相编者的信息,对读者而言可能没有有用信息。 | 编者应确保内容能反映专题或社群共识。 | ||
用户级 | User | 任何属于User命名空间的页面 | N/A | 可能有些有用的信息,也可能只包含特定编者的立场。 | 应遵守Wikipedia:用户页规范。 | ||
使用说明级 | Help | 任何属于Help命名空间的页面 | N/A | 读者能找到维基百科相关功能的使用说明。 | 编者应当确保说明内容不过时。 | ||
界面级 | Interface | 任何属于MediaWiki命名空间的页面 | N/A | 定义界面的显示方式,可能对任何读者都不实用。 | 任何对系统界面的修改都应反映社群共识。有时会因技术需求或其他原因由维基媒体基金会职员进行修改。 | ||
非标准级别 | 搁置级 | Deferred | 只能手动给定 | 代表本页面的评级作业转介给涵盖该页面主题的其他专题。 | 任何编辑都可以在有开放此级别的专题指定此评级,但不能评于通用评级。应谨慎使用此评级,并且仅在其他专题完全覆盖此专题导致冗余的情况时使用。 | 由于对应专题没有提供级别,因此实际情况可能会有所不同。 |
- @Temp3600:您看看这些信息对行政组作业有没有帮助?(请单击
[显示]
以展开表格)-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月5日 (五) 10:48 (UTC) - 感谢宇帆君的总结。我大胆做了一些调整,说明如下:
- --For Each element In group Next(留言) 2024年4月5日 (五) 13:54 (UTC)
- 已经五天无新意见了,我先把资料整理进WP:QUALITY。如到时还有讨论出新结论也可以再修改。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月10日 (三) 03:22 (UTC)
页面评级与通用评级指引调整[编辑]
- 非常感谢娜娜奇。但我因为现实原因(pia!)暂时不能积极参与讨论。我预计会于19-21日的周末发言,这段时间麻烦诸位了。--Temp3600(留言) 2024年4月12日 (五) 11:29 (UTC)
- 约略看过没有问题。在格式上有一点想法: 每个类别还是找一个例子,当参考。另外,会否用Template:Guideline section,只将标准评级立为指引会较好?如果专题组日后创立新评级供内部使用,便无须经VP共识修改评级表,而可自行加入。不过倒过来,如果自行加入评级会弄坏模版,那么还是经VP讨论,协调好再修改较好。这方面我不清楚,请给意见。--Temp3600(留言) 2024年4月12日 (五) 11:58 (UTC)
- Class_mask/core}}中,目前还没标准化的级别做“开放”即可(不必改程式,只要改类似config(设置)的东东),而专题自建级别已有相应功能,无须动到核心模板,示例见{{WikiProject_Example}},因此完全无需更动本次系列模板/模块或任何程式码的核心,故自行加入评级不至于会弄坏模版。常见的专题非标准评级我觉得可以在WP:QUALITY提,在章节标题标注“本段不是指引”应该就可以了,就不必走VP共识了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月12日 (五) 15:49 (UTC)
- 先抱歉晚了许多上来...生活艰难QQ。
- 如果如此,那么标准级别一节立为指引就可以,并在非标准级别一节清楚列明专题可以如何自行加入新评级(好像在模版说明里已经写好?那么就只需要提供链接)。--Temp3600(留言) 2024年5月5日 (日) 07:27 (UTC)
届时,如果确定该等级都标准化的话,仅需要将{{
- Class_mask/core}}中,目前还没标准化的级别做“开放”即可(不必改程式,只要改类似config(设置)的东东),而专题自建级别已有相应功能,无须动到核心模板,示例见{{WikiProject_Example}},因此完全无需更动本次系列模板/模块或任何程式码的核心,故自行加入评级不至于会弄坏模版。常见的专题非标准评级我觉得可以在WP:QUALITY提,在章节标题标注“本段不是指引”应该就可以了,就不必走VP共识了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月12日 (五) 15:49 (UTC)
- 约略看过没有问题。在格式上有一点想法: 每个类别还是找一个例子,当参考。另外,会否用Template:Guideline section,只将标准评级立为指引会较好?如果专题组日后创立新评级供内部使用,便无须经VP共识修改评级表,而可自行加入。不过倒过来,如果自行加入评级会弄坏模版,那么还是经VP讨论,协调好再修改较好。这方面我不清楚,请给意见。--Temp3600(留言) 2024年4月12日 (五) 11:58 (UTC)
- 非常感谢娜娜奇。但我因为现实原因(pia!)暂时不能积极参与讨论。我预计会于19-21日的周末发言,这段时间麻烦诸位了。--Temp3600(留言) 2024年4月12日 (五) 11:29 (UTC)
对于Wikipedia:页面质量评级标准(以及Wikipedia:通用评级)还有一些逻辑上的考量:
- 英文版的页面en:Wikipedia:Content assessment翻译过来是内容评级。其内涵理论上包括评级流程、评级标准等多个部分。而中文版的标题是“页面质量评级标准”,一只介绍标准本身,二又强调品质评级。而当前页面是从古早期英维版翻译过来,现在两边都改了很多,这就很微妙了。所以页面是否要改名“Wikipedia:页面评级”?
- 如果从标题强调质量评级来看,页面似乎应该将“标准质量评级”(≈条目)和“标准类别级别”(≈非条目)分设为两个大节。说约等于是因为特色图片属于非条目但又要评估品质,而同类索引(SIA)是自动评级但理论上属于条目。
- 对于条目品质评级部分,是否需要流程图辅助说明?(比如写入指引页,或放在论述页给个连接)
- 如何表述“通用评级”与“专题评级”的关系?从目前的讨论来看,可能还需要一个页面(可能是Wikipedia:页面评级)厘清:
- 社群和专题都可以各自独立地对页面评级。评级结果登记于条目讨论页顶部。
- 通用评级由社群编者评估,对社群负责。本页刊载的等级标准为通用标准,即适用于WPBS的通用评级。
- 专题评级由专题自行解释,但因为专题评级一般直接继承通用评级,所以也还是这套标准。部分专题可能自选启用或关闭级别,也可能重新诠释通用级别,这些内容具体在专题评级页刊载。
我希望听听其他编者的意见,所以暂时不会积极回复。--For Each element In group Next(留言) 2024年4月14日 (日) 15:17 (UTC)
- 那我再Ping一次讨论开头的那些人吧:@Liaon98、JyunWaan、Lssrn:@Cdip150、Temp3600、Peacearth:。还有User:KanashimiPing的那些人@Kethyga @Willy1018 @Z7504 @AT @Shizhao @Iokseng 能够给些意见吗?谢谢。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月14日 (日) 15:34 (UTC)
- 周末来研究 --Temp3600(留言) 2024年4月14日 (日) 15:47 (UTC)
- 只讲这一句,其余不说了:“WPBS模板目前看来机器人执行上是没什么问题的。另外,有些分类基本用不到(例如 同类索引级),不予评论”。反正评级功能没什么大问题,个人认为就不用再浪费时间在这种没问题的上面,不打扰了。--Z7504非常建议必要时多关注评选(留言) 2024年4月18日 (四) 13:45 (UTC)
- 之前说过了,自动评级“有挂模板就能判断”,既然{{同类索引}}模板存在,就能被自动判断,且分类里确实有东西,故不认同“用不到”一说(例三碘化物 (索引)既非消歧义也不是列表),真用不到的话,分类早就O4了。就这样,我也不想就这个话题继续(真要较劲的话,{{导论}}也有模板存在,病毒v.s.病毒 (导论),也可以搞出 导论级[Introduction][甚至是 纲要级[Outline]](如马来西亚v.s.马来西亚纲要)],但因为导论也有品质,不像同类索引偏点列式,所以导论类条目就共用条目的甲乙丙丁初级)。哪壶不开提哪壶,我们在讨论评级时的规范,而你在讲机器人能不能工作,这完全两码子事,而且显然现在贸然增减或弃用一个级别存在技术上的复杂性和已报上phab且工程师已完成作业还要频繁去phab“吵他们”、“烦他们”显然不是一个好的做法(这点Temp3600讲过了不再赘述)。仍然主张维持放所有能自动判断的级别设为标准级别。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月18日 (四) 13:57 (UTC)
- 然后,有点离题了,建议聚焦在页面评级与通用评级指引逻辑上的考量。WPBS能使用哪些评级的议案已经公示通过,且能使用,机器人和系统自动评级的部分正 正常工作著,故不必再浪费时间讨论。从行政组的工作切入讨论起来比较重要-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月18日 (四) 14:26 (UTC)
- 基于此,上面Ping的人已经有一个给出答复了(Z7504)。其他人我再重Ping一次。@Liaon98、JyunWaan、Lssrn、Cdip150:@Temp3600、Peacearth、Kethyga、Willy1018:@AT、Shizhao: 能够给些意见吗?谢谢。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么(☎️·☘️) 2024年4月19日 (五) 15:28 (UTC)
- 所以现在是什么情况?2402:7500:579:89C4:84ED:51FA:80FD:F1D1(留言) 2024年4月26日 (五) 05:52 (UTC)
- ( π )题外话 我终于见识到条目重要度评级标准的存在感有多低了。L'Internationale, Sera le genre humain! 2024年4月27日 (六) 14:52 (UTC)
- 这其实是一个很不幸的情况......条目评级与条目评审是本站的QC,QC坏了,本站其他的管治水平也可想而知。--Temp3600(留言) 2024年5月5日 (日) 07:20 (UTC)
- ( π )题外话 我终于见识到条目重要度评级标准的存在感有多低了。L'Internationale, Sera le genre humain! 2024年4月27日 (六) 14:52 (UTC)
- 才发现通过了一整个指引。—— Eric Liu 創造は生命(留言・留名・学生会) 2024年4月27日 (六) 15:20 (UTC)
- @A2569875:注意到阁下修改了{{Grading scheme}},添加了一些新的评级,但这些评级全部成为了默认选项。个人认为对于一些小型专题来说,可能不需要这么多类评级。建议把部分评级改为非默认的选项,只需把对应评级
|trigger=
参数的默认值yes
移除即可。——BlackShadowG Slava Ukraini! 2024年5月3日 (五) 01:34 (UTC)
- en:Wikipedia:Content assessment 有较多的内容,我认为这是因为他们是这个制度的来源地,所以有关于制度的历史流变等可以写。中维目前只是引入的制度,还没有社群的经验,因此没有这部分的本地经验可以立为指引,而只能写一些硬规定。我认为这暂时不是问题,如日后成熟,自然可以再将这些段落引进,指引名字也可以更改。“页面质量评级标准”就暂时只写标准,待评级流程成熟后,就可以加入这一部分的指引。
- 同意将“标准质量评级”与“标准类别级别”分立为两个三级标题。这是一项不涉及本质的结构修改,不难。
- 流程图最好有,但要有人来画...
“通用评级”与“专题评级”的关系:这是我最早就想改写的部分。既然“通用评级”只可填标准评级而专题评级可以填其他自定义评级,那么维基百科:通用评级就需要至少修改"若一条目仅有一个专题,其通用评级应与该专题所评的等级一致。",最好是重新理顺这一部分的逻辑。
- 整理目前的讨论,建议"机器人会根据该页面最多专题评等的评级等级作为通用评级"继续保留,但机器人应检查这会否导致WPBS被评为非正式级别,如发生这种情况,那么机器人则跳过该条目(可以考虑加入"需要手动进行WPBS评级"的分类),留待人类前来。
- 同意"社群和专题都可以各自独立地对页面评级"的基本策略。这样就解决了list级的问题。即使专题的评级只有list级,WPBS仍可以手动评为更准确的CL/BL等细分级别。由机器人自动评的list级也与这个逻辑没有冲突。
- 长远的最终方向是,WPBS作为条目的内容评级,专题评级则为某一方面提供额外的信息,类似tag.但这个需要将目前的评级逻辑反过来,我猜一两年也无法完成,就写在这而已。--Temp3600(留言) 2024年5月5日 (日) 08:10 (UTC)
修订案[编辑]
- 虽然我累得(今天)打不完整个修订案,但至少可以生出一个大纲...--Temp3600(留言) 2024年5月5日 (日) 08:28 (UTC)
维基百科:通用评级[编辑]
- 解决“通用评级”与“专题评级”的关系。断开两者的上下级关系。
- 通用评级只限填写标准评级。
- 介绍一些其他功能,例如专题可以自行加入评级,不过这些不属于WPBS的范围,将它们指示到其他页面去。
维基百科:页面质量评级标准[编辑]
- 对应通用评级的改动,明确两者间的关系。即: QUALITY负责规定那些级别属于标准评级,及提供评级的参考。也提供其他非标准级别的介绍。通用评级指引则负责通用评级的流程,由社群负责,为条目的质量提供评级,而专题级模版级等请不要来找WPBS.
- 结构调整,将“标准质量评级”与“标准类别级别”分立为两个三级标题。
T: Grading scheme[编辑]
- 为所有标准类别补上例子。
后续讨论[编辑]
关于 rater.js 脚本[编辑]
前面的讨论貌似没有涉及到老版本的rater.js脚本(User:Chiefwei/rater aka en:User:Kephir/gadgets/rater)。貌似enwiki那边已经废弃了老版本的rater.js,并且由Evad37推出了新版的rater.js(en:User:Evad37/rater)。我再考虑将新版本引入并做本地化,不知道目前是否已经有类似的工作了?--Ceba_robot 才不是机器人! 2024年2月16日 (五) 17:57 (UTC)
- 有见到Ericliu1912和YFdyh000两版。--Cookai饼块🍪(💬留言) 2024年2月16日 (五) 18:17 (UTC)
- 妥了,看起来YFdyh000的目前跟上游已经同步,还是不要做重复工作比较好(--Ceba_robot 才不是机器人! 2024年2月16日 (五) 18:24 (UTC)
- 我也跟进
借鉴了,至少现在用哪一个版本都不会落后。—— Eric Liu 創造は生命(留言・留名・学生会) 2024年3月4日 (一) 11:51 (UTC)
- 我也跟进
- 妥了,看起来YFdyh000的目前跟上游已经同步,还是不要做重复工作比较好(--Ceba_robot 才不是机器人! 2024年2月16日 (五) 18:24 (UTC)
- 目前仍有大量站内页面链接至User:Chiefwei/rater,建议更新。--Temp3600(留言) 2024年3月3日 (日) 07:57 (UTC)
- 还真不知道rater.js有这东西,但这个社群对于专题过往都是冷漠处理的,没想到近几个月开始变得重视了。没差,评级功能不要影响到就好,多说可能无益。--Z7504非常建议必要时多关注评选(留言) 2024年4月18日 (四) 13:47 (UTC)
管理人员申请预讨论[编辑]
工单准备[编辑]
这里有一点需要注意的内容。首先,根据Wikipedia:征求意见/2024年管理人员制度改革#议案2B:处理合并选举规则不清晰问题,新投票界面应包含类似“管理人员选举无当选限额,各候选人分开计票,支持票不限于一票”的指引。其次需要考虑到Wikipedia:征求意见/2024年管理人员制度改革#议案2A:合并选举存废中所讨论的可否拆分。同时,根据上方讨论关于WT:ARBCOM#问卷的说法,同时包含关于仲裁委员会的调查问卷(不是选择,而是填文字回答):
管理人员解任在多大程度由仲裁委员会处理?
- 甲、仲裁委员会按调查事实及方针指引,直接作出除权决定。
- 乙、由仲裁委员会调查事实并发布管理人员操守报告,确认存在违规事实后,才转交社群决议除权。
- 丙、仲裁委员会完全不参与管理人员解任。
欢迎讨论。0xDeadbeef (留言) 2024年4月3日 (三) 12:42 (UTC)
- 请问这个是指提交给仲裁委员会的案件,还是所有RFDA案件?--桐生ここ★[讨论] 2024年4月3日 (三) 14:48 (UTC)
- 路西法人的意见是所有RFDA经过ARBCOM,我的意见是RFDA和ARBCOM不互相影响。这个问题或许也可以添到工单上。--0xDeadbeef (留言) 2024年4月4日 (四) 00:52 (UTC)
- 赞同你的意见“RFDA和ARBCOM不互相影响”,支持添加到工单上。--桐生ここ★[讨论] 2024年4月4日 (四) 03:44 (UTC)
- 这需要另行草拟问题。我觉得此问题本身可以先加上定语,只涵盖由仲裁委员会经手处理者(也就是原本社群提出者另议),以避免混淆。—— Eric Liu 創造は生命(留言・留名・学生会) 2024年4月4日 (四) 09:35 (UTC)
- 赞同你的意见“RFDA和ARBCOM不互相影响”,支持添加到工单上。--桐生ここ★[讨论] 2024年4月4日 (四) 03:44 (UTC)
- 路西法人的意见是所有RFDA经过ARBCOM,我的意见是RFDA和ARBCOM不互相影响。这个问题或许也可以添到工单上。--0xDeadbeef (留言) 2024年4月4日 (四) 00:52 (UTC)
- 可附上相关讨论链接。—— Eric Liu 創造は生命(留言・留名・学生会) 2024年4月4日 (四) 09:35 (UTC)
- 我还是比较同意上方说Eric Liu说
如果只是希望给意见,那还不如改成通告,直接请大家去讨论页留言互动,而不是事后再个别整理几条留言。
的说法。这样附上留言的方式不便于详细展开讨论。--Ghren🐦🕐 2024年4月4日 (四) 17:24 (UTC)- 如是者,我不清楚你们这个问卷调查是是不是要匿名征求意见。如果答案为是,可考虑加入工单;如是答案为否,我建议在管理员选举的说明中提及+MMS即可。--春卷柯南-发前人所未知 ( 论功行赏 ) 2024年4月4日 (四) 22:35 (UTC)
- 据说是匿名征求意见--0xDeadbeef (留言) 2024年4月5日 (五) 01:37 (UTC)
- Why not both?匿名收集意见方便整合各方观点,也撇除了发言者身份的观感,方便往后只针对观点讨论;MMS内引导亦可即时邀请更多用户参与相关讨论。--路西法人 2024年4月5日 (五) 01:42 (UTC)
- 我想即使是在一般的页面讨论,也应该要做到“整合各方观点”和“对事不对人”这两件事吧。匿名收集意见不是完全对以上两点没有帮助,只是作用很少而已。--Ghren🐦🕒 2024年4月5日 (五) 07:13 (UTC)
- 不试试怎么知道有没有帮助呢?what's the worst that can happen?没有人提意见?没有有价值的意见?那又怎样。结果出来整合一下大家的意见,再公开讨论也还好吧。--0xDeadbeef (留言) 2024年4月5日 (五) 10:26 (UTC)
- 我想即使是在一般的页面讨论,也应该要做到“整合各方观点”和“对事不对人”这两件事吧。匿名收集意见不是完全对以上两点没有帮助,只是作用很少而已。--Ghren🐦🕒 2024年4月5日 (五) 07:13 (UTC)
- 如是者,我不清楚你们这个问卷调查是是不是要匿名征求意见。如果答案为是,可考虑加入工单;如是答案为否,我建议在管理员选举的说明中提及+MMS即可。--春卷柯南-发前人所未知 ( 论功行赏 ) 2024年4月4日 (四) 22:35 (UTC)
- 根据phab:T358067的时间轴,此次管理人员选举的投票时间只能够在5月初开始。我们有可能需要更新一下投票时间。--1233 (T / C) 2024年4月9日 (二) 06:51 (UTC)
- 依据现行指引,获得正式提名之时,必须立即置申请子页面,且一定要在四月二十八日前完成安全投票筹备。显然此规定无法实现,弹性过低,事后大概需要一并检讨。至于是次申请的处理方法,我认为可以经全体被提名者同意(或至少予以知会),请行政员宣告因现行规定窒碍难行,延后讨论期及投票期。—— Eric Liu 創造は生命(留言・留名・学生会) 2024年4月11日 (四) 12:33 (UTC)
- 副知@Manchiu、UjuiUjuMandan、ASid、ATannedBurger、SickManWP。—— Eric Liu 創造は生命(留言・留名・学生会) 2024年4月11日 (四) 12:34 (UTC)
- 本人已于昨晚宣布退选,故私以为不用为本人创建RFA子页面。我认为现时可以为四位候选人创建RFA子页面,这样就能提早进入发问环节,争取更多时间让社群了解候选人的观点及立场。--维基病夫邀请您加入❤️边缘人小组·🖊️签到 2024年4月11日 (四) 12:38 (UTC)
- 支持先进入提问期。--桐生ここ★[讨论] 2024年4月11日 (四) 16:10 (UTC)
- 但提早进入,也提早结束,我认为申请应反映社群最新共识变动,所以越迟开始越好。无论如何,在大家还没商定期限以前,都不应该径行开始。—— Eric Liu 創造は生命(留言・留名・学生会) 2024年4月11日 (四) 16:28 (UTC)
- 个人认为可延长提问期以增加关注度。理论上当前条文为
在被提名者经行政员确认获得正式提名之时起二周内,任何用户都可以发表意见,包含提问及讨论等
,不过考量到此条自2006年以来就已设立,个人认为此根据自由意志的二周
提问期限(若不是因自由意志所设立,我也很有兴趣知道为什么不是)已无法实际符合当前RFA的状况,包括因SecurePoll所导致的各种选举过程延宕的情况。 - 个人会希望提问期可从设立RfA子页面开始至投票前一到二周结束,而之所以留空一到两周的目的是作为缓冲并希望候选人能回答完所有问题。嘛,当然,这个提案很有可能会导致候选人需要答题的数量变多,但可通过其他措施如限制问题数量至一人三问或其他方式来进行改善。--(☎)dt 管理员竞选中 2024年4月14日 (日) 07:41 (UTC)
- 个人认为可延长提问期以增加关注度。理论上当前条文为
- (及@AT)—— Eric Liu 創造は生命(留言・留名・学生会) 2024年4月11日 (四) 16:28 (UTC)
- 再副知其他行政员@Ffaarr、Jimmy Xu、Kegns、Shizhao、Wing、Wong128hk。—— Eric Liu 創造は生命(留言・留名・学生会) 2024年4月11日 (四) 18:56 (UTC)
- 本人已于昨晚宣布退选,故私以为不用为本人创建RFA子页面。我认为现时可以为四位候选人创建RFA子页面,这样就能提早进入发问环节,争取更多时间让社群了解候选人的观点及立场。--维基病夫邀请您加入❤️边缘人小组·🖊️签到 2024年4月11日 (四) 12:38 (UTC)
- 千村狐兔(留言) 2024年4月11日 (四) 15:09 (UTC) 已知悉。辛苦。-
- 感谢告知,辛苦了谢谢。--~~Sid~~ 2024年4月11日 (四) 15:43 (UTC)
- 副知@Manchiu、UjuiUjuMandan、ASid、ATannedBurger、SickManWP。—— Eric Liu 創造は生命(留言・留名・学生会) 2024年4月11日 (四) 12:34 (UTC)
- @Ericliu1912 @Shizhao @ATannedBurger 距离五月不足两周了,本人认为应该开始讨论期(最好是4月21日),直到投票准备就绪为止。铁胶壹名 2024年4月18日 (四) 08:36 (UTC)
- 依据现行指引,获得正式提名之时,必须立即置申请子页面,且一定要在四月二十八日前完成安全投票筹备。显然此规定无法实现,弹性过低,事后大概需要一并检讨。至于是次申请的处理方法,我认为可以经全体被提名者同意(或至少予以知会),请行政员宣告因现行规定窒碍难行,延后讨论期及投票期。—— Eric Liu 創造は生命(留言・留名・学生会) 2024年4月11日 (四) 12:33 (UTC)
- @Manchiu @UjuiUjuMandan @AT @ASid @ATannedBurger 行政员已完成申请资格复核,现已创建对应的选举页面(Manchiu、UjuiUjuMandan、AT、ASid、ATannedBurger),唯根据上面的讨论,提问时间尚未开始。铁胶壹名 2024年4月14日 (日) 07:11 (UTC)
- 辛苦了--(☎)dt 管理员竞选中 2024年4月14日 (日) 07:16 (UTC)
- 今天已经是4月23日(UTC+8),各候选人的RFA界面也都已经完成设立,本讨论自一周前已无更新内容。若按照工单中所述,4月26日直接进入投票期,是否意味着提问时间将与投票期重合?还是说社群有其他关于提问期及投票期之决议?--SheltonMartin留言|签名 2024年4月23日 (二) 02:03 (UTC)
- @阿南之人 @SheltonMartin 根据phab:T358067,U4C的投票目前为第一优先级(由4月26日到5月9日),考虑到讨论期一般开启七天,如开启太长时间的话会给参选的人带来不必要的压力,则最早讨论期应由5月3日开启,在中维选举在U4C选举之后立即开始的情况下。--0xDeadbeef (留言) 2024年4月23日 (二) 12:23 (UTC)
- (而U4C的投票还要点票这个事情,我建议先等U4C的投票点票结束再考虑什么时候开启讨论。)--0xDeadbeef (留言) 2024年4月23日 (二) 12:26 (UTC)
- 1. 请社群讨论,是否有必要在揭示板或其他地方对讨论期及投票期的时间节点作出更清晰的说明?
- 2. 先前有编辑提出延长讨论期的动议,社群是否考虑付诸讨论?
- 3. 建议明确后续管理人员任免投票的时间节点(如在某月第某周开启),对中维的大部分用户而言,U4C的投票能有多大限度影响中维的管理人员任免存疑,而且似乎也没有看到各语言维基需避开U4C或类似选举的规定或先例。
- 以上。--SheltonMartin留言|签名 2024年4月24日 (三) 00:27 (UTC)
U4C的投票能有多大限度影响中维的管理人员任免存疑
- votewiki在U4C投票期间是英文,而一般中维投票时会改为中文。你要觉得大家能看着英文投票就没事。- 别的语言维基又不用SecurePoll。--0xDeadbeef (留言) 2024年4月24日 (三) 08:17 (UTC)
- @Manchiu、UjuiUjuMandan、ASid、ATannedBurger:不然设五月一日至十四日为正式讨论期,十五日至二十八日为投票期?—— Eric Liu 創造は生命(留言・留名・学生会) 2024年4月24日 (三) 07:57 (UTC)
- 可--(☎)dt 管理员竞选中 2024年4月24日 (三) 08:02 (UTC)
- OK。 --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月24日 (三) 08:39 (UTC)
- 已更新选举页面。铁胶壹名 2024年4月24日 (三) 09:43 (UTC)
- @阿南之人 @SheltonMartin 根据phab:T358067,U4C的投票目前为第一优先级(由4月26日到5月9日),考虑到讨论期一般开启七天,如开启太长时间的话会给参选的人带来不必要的压力,则最早讨论期应由5月3日开启,在中维选举在U4C选举之后立即开始的情况下。--0xDeadbeef (留言) 2024年4月23日 (二) 12:23 (UTC)
- 好。辛苦诸位。-千村狐兔(留言) 2024年4月24日 (三) 23:30 (UTC)
- @Manchiu @UjuiUjuMandan @ASid @AT @ATannedBurger 今天讨论+提问时间正式开始。请各用户和候选人做出准备。L'Internationale, Sera le genre humain! 2024年5月1日 (三) 03:32 (UTC)
- SCP-0000(留言) 2024年5月13日 (一) 15:32 (UTC)
- 那么提问环节是相应延长?已有候选人表示提问压力甚大…-千村狐兔(留言) 2024年5月14日 (二) 09:45 (UTC)
- 本人认为停止提问,但可以继续在意见区讨论。L'Internationale, Sera le genre humain! ✏️ 2024年5月14日 (二) 09:51 (UTC)
- 提问环节的长度是有规定的,我认为不宜延长。同意上面的见解。Sanmosa 全方贫工之联合 2024年5月14日 (二) 09:54 (UTC)
- 无论如何,感谢千村狐兔(留言) 2024年5月15日 (三) 02:31 (UTC) SCP-2000君辛劳。-
- 既然社群无异议,现暂定5/29 - 6/12举行,谢谢。--SCP-0000(留言) 2024年5月15日 (三) 06:06 (UTC)
- 提问,若5/29 T&S仍未回复,投票期是否会继续延长?--SheltonMartin留言|签名 2024年5月16日 (四) 05:25 (UTC)
考虑到设立选举的准备尚未完成(投票者列表相关 query 仍在执行,且 T&S 仍未回复),个人建议投票期由5/15延迟至两周后,即5/29举行?副知候选人。谢谢。-- - 那么提问环节是相应延长?已有候选人表示提问压力甚大…-千村狐兔(留言) 2024年5月14日 (二) 09:45 (UTC)
- SCP-0000(留言) 2024年5月18日 (六) 01:56 (UTC)
- 知悉,辛苦!-千村狐兔(留言) 2024年5月18日 (六) 02:25 (UTC)
- 知悉,有劳通知。--J.Wong 2024年5月27日 (一) 01:04 (UTC)
T&S 回复称可在 5/29 - 6/12 期间举行选举。另外,由于运动宪章批准投票于 6/25 开始,技术上行政员不能作出延长选举一周的做法。副如候选人及监督员。谢谢。-- - @AT @ATannedBurger @ASid @Manchiu @UjuiUjuMandan 再次通知候选人,投票已经于8:00开始。虽然是我八点二十多补上投票链接的 L'Internationale, Sera le genre humain! ✏️ 2024年5月29日 (三) 00:39 (UTC)
这里有两个问题。第一、征求意见内容实际上并未经公示通过,措辞亦有商榷之虞(包含上方早已提出之若干意见,以及事后他人提出翻译腔问题等),由于程序不够完备而无法及时调整;且此次投票本因故延长,还有更多时间(一个多月)准备,既非匆忙间不能顾及者,则更不应该如此才是。本人要求严正检讨改进程序问题。第二、有人无法投票,或许是因为合格选举人名单过时而未更新。此为极严重之差错,请社群立即协助处理。—— Eric Liu 創造は生命(留言・留名・学生会) 2024年5月29日 (三) 06:40 (UTC)
- @Ericliu1912、RiceKing: 已请求增加至投票者列表。--SCP-0000(留言) 2024年5月29日 (三) 06:57 (UTC)
- @RiceKing: 已增加,请问能否正常投票?--SCP-0000(留言) 2024年5月29日 (三) 07:41 (UTC)
- @SCP-2000@Ericliu1912:现在可以了,感谢二位!--Rice King 信箱 · 留名.边缘人 2024年5月29日 (三) 07:41 (UTC)
- 这边也问一下协助设立选举的相关用户@SCP-2000、阿南之人:候选人自己选举的投票是否和上次一样,在最后结算的时候减一票支持以抵销候选人投给自己的票?--(☎)dt 管理员竞选中 2024年5月30日 (四) 13:13 (UTC)
- @ATannedBurger:与监督员 Wong128hk 讨论中。--SCP-0000(留言) 2024年5月30日 (四) 13:28 (UTC)
- 见目前投票页是分立,所以为什么会有候选人投票予自己之情况?
- 理论上,结算时可以将特定用户之选票删去。--J.Wong 2024年6月2日 (日) 02:45 (UTC)
对新用户禁用内容翻译工具(续)[编辑]
原讨论存档见此:Wikipedia:互助客栈/其他/存档/2024年3月#对Phabricator的回应
以下为Pginer-WMF的最新回应:
Perfect. I think we can plan to introduce these changes. We plan to introduce these in iterations.
- Limit publishing into the main namespace to "extended confirmed users" only.
- Get input from the community on the effects, for the community to decide whether to make the restriction more/less strict.
- Make machine translation non-default.
In this way we can have a better understanding on the effect of each of the changes and how to adjust them.
简单而言,他们将作出以下更改:仅允许延伸确认用户将翻译发布到主命名空间,并愿意之后依社群意见将限制调整成更严格 / 宽松;以及机械翻译设为非默认选项。
SCP-0000(留言) 2024年3月23日 (六) 13:27 (UTC)
考虑到他们的提议与过去讨论的共识(即禁止翻译发布到主命名空间及机翻设为非默认)相近,如果一周后没有任何异议,即视为社群同意他们的提议。副知所有曾参与讨论的编者。谢谢。--- 没问题。--日期20220626(留言) 2024年3月23日 (六) 13:33 (UTC)
- 应该可以。--冥王欧西里斯(留言) 2024年3月23日 (六) 14:20 (UTC)
- 挺好,我收到了邮件但都忘了这事了。--MilkyDefer 2024年3月23日 (六) 15:01 (UTC)
- 好。 -Lemonaka 2024年3月23日 (六) 16:56 (UTC)
- 非常好。——Aggie Dewadipper 2024年3月23日 (六) 19:55 (UTC)
- 他们愿意退让是可以就此参考他们的意见啦--SunAfterRain 2024年3月24日 (日) 14:16 (UTC)
- 赞同。--桐生ここ★[讨论] 2024年3月24日 (日) 16:51 (UTC)
既然已有多人同意此更改,且正如上方提到他们的提议与过去的共识相近,故依照 WP:SNOW 视社群同意他们的提议,并已在 phab 反映社群的意愿。谢谢。--SCP-0000(留言) 2024年3月24日 (日) 14:29 (UTC)
- 不反对如此配置。但扒了三个有使用内容翻译工具的直出主条目空间的成品(中国的动物福利和权利、自由意志民主党人、杰克逊·欣克尔 ),我还是觉得禁用了可能更好。 囧rz……——Sakamotosan路过围观 | 避免做作,免敬 2024年3月25日 (一) 08:15 (UTC)
- 目前方案通过后第一个条目不会直接输出到主空间,因为作者的编辑数量还达不到延伸用户的级别。所以至少挡掉三分之一了,不错了。--日期20220626(留言) 2024年3月25日 (一) 08:20 (UTC)
- 如果可以,不知能否帮忙整理使用内容翻译而有问题的条目?这样方便与基金会沟通时,有相关例子可供他们参考及研究。谢谢。--SCP-0000(留言) 2024年3月25日 (一) 16:44 (UTC)
- 感觉被G13的多少都是内容翻译的条目。。。—-Aggie Dewadipper 2024年3月25日 (一) 18:39 (UTC)
- 偶尔也有非内容翻译的条目被挂G13。--日期20220626(留言) 2024年3月25日 (一) 22:26 (UTC)
- 感觉被G13的多少都是内容翻译的条目。。。—-Aggie Dewadipper 2024年3月25日 (一) 18:39 (UTC)
- @SCP-2000:用RTRC找主条目空间、新建页面(因为原生最近更改不方便找新建页面)、标签为“内容翻译”、“内容翻译2”的,应该会存在不少。例如找到一篇乔安娜·斯丁格蕾(oldid=82028905)。好像最近多了一批没用户页的新用户在用这个系统来翻译,而且首次格式质量都存在或多或少同类问题(包括斜体、数字间空格、参考注脚之间空格或者参考复制的一些格式暴露(<cite>这种)、缺少参考列表,部分还有格式紊乱、模板丢失)虽然这些问题是新页面巡查员应该去做的事……——Sakamotosan路过围观 | 避免做作,免敬 2024年3月26日 (二) 02:15 (UTC)
- 根据提案,新用户已经无法通过内容翻译直接在主空间生成条目。--日期20220626(留言) 2024年3月26日 (二) 03:31 (UTC)
- 只是提供收集说服来源的方法。当然希望拉高下限能挡住一部分借助该系统粗制滥造的低质量翻译条目。——Sakamotosan路过围观 | 避免做作,免敬 2024年3月26日 (二) 13:15 (UTC)
- 根据提案,新用户已经无法通过内容翻译直接在主空间生成条目。--日期20220626(留言) 2024年3月26日 (二) 03:31 (UTC)
- 另外,感觉User:New user message不会对不是以本项目注册的新用户发自动欢迎的(例如找到的User:赛博崔会遇见电子铝黄瓜吗、User:Art4cn),有可能导致新用户缺乏对格式规则的了解。——Sakamotosan路过围观 | 避免做作,免敬 2024年3月26日 (二) 02:26 (UTC)
- 这个改配置即可,可以在其创建本地账号时发送。个人认为至少其有一个编辑在发送会好些?(改配置噩梦)--Hualin🎗️希望の星は青霄に昇る Commons|Talk 2024年3月30日 (六) 22:34 (UTC)
- What the hell is that? -Lemonaka 2024年3月30日 (六) 01:21 (UTC)
- In general, Content translation will redirect users to their chosen language of wiki, even if they use it on zhwiki. So I don't think it's the content translation's fault, but I have no idea how they can do that :)--SCP-0000(留言) 2024年3月30日 (六) 07:45 (UTC)
内容翻译现已缩紧[编辑]
(注:复制自WP:互助客栈/消息#内容翻译现已缩紧,原由User:MilkyDefer发布。)
自4月10日(三)起,只有拥有延伸确认权限的用户可以使用内容翻译功能将页面发布到主条目空间。这次调整是因应近期多发的粗滥翻译问题所做出的。延伸确认权限自动授予注册满90天且编辑满500次的编者,以及管理员。
请巡查员和所有编者留意这次更改后,翻译条目的品质是否有改善。其结果会决定是否采取下一阶段的措施:将“从原文开始”设置为默认翻译选项。
SCP-0000(留言) 2024年4月11日 (四) 17:11 (UTC)
副知所有曾参与讨论的编者。谢谢。--- phab:T349959#9711650,疑似未生效。--碟之舞📀💿 2024年4月14日 (日) 07:50 (UTC)
- 不过好像数量并不多。--日期20220626(留言) 2024年4月14日 (日) 07:58 (UTC)
- 原因也大致抓到了,Special:PermanentLink/82270024#L-111应该能当临时补丁--SunAfterRain 2024年4月14日 (日) 14:35 (UTC)
- 并没有生效:Special:用户贡献/EitanVel。上面的patch有管理员review下么?--Tim Wu(留言) 2024年4月19日 (五) 01:36 (UTC)
- @SunAfterRain Not applied till now, Special:Contributions/Hueydome88E92 -Lemonaka 2024年4月21日 (日) 10:52 (UTC)
- phab:T349959#9734223 patch backports in today. 虽然我是不知道他们说的移植后仍然有问题是什么意思,毕竟我刚才看的结果确实有正确拦截到了...--SunAfterRain 2024年4月23日 (二) 12:39 (UTC)
- 确实还没有修正,如火腿黄油三明治。--SCP-0000(留言) 2024年4月24日 (三) 03:51 (UTC)
- phab:T349959#9734223 patch backports in today. 虽然我是不知道他们说的移植后仍然有问题是什么意思,毕竟我刚才看的结果确实有正确拦截到了...--SunAfterRain 2024年4月23日 (二) 12:39 (UTC)
- 目前为止未见有非延伸确认用户能发布条目至主条目空间,似乎已被修正。另外,现时仅限制发布权限,而没有限制使用机翻的权限,草稿仍大机会存在翻译质素低下的问题,烦请各位注意翻译条目的品质有否改善。如果一个月后没有任何意见,则会让此讨论自动存档。副知所有曾参与讨论的编者。谢谢。--SCP-0000(留言) 2024年5月23日 (四) 08:15 (UTC) 补丁已于5/15部署,
- 一月似过久,二周何如?—— Eric Liu 創造は生命(留言・留名・学生会) 2024年5月23日 (四) 12:20 (UTC)
- 两星期未必足够观察其变化及影响,且此讨论非急需结案或关闭。--SCP-0000(留言) 2024年5月23日 (四) 16:31 (UTC)
Unblock-zh.org[编辑]
很久以前讨论过的一个项目,也就是unblock-zh的网站版,我最近给他做出来了,如果对测试版软件感兴趣的话,请去 https://unblock-zh.org 这里去看看。(注意测试版软件,你的用户最后很可能被删掉!)
附带一个教学视频 https://www.youtube.com/watch?v=IImfyNnRB4M
目前站外用户申请账户的方式是Wikipedia:账号请求发送邮件,其实也没有太不方便。但是这个途径我觉得还是更直观一点,比邮件列表好用一点,尤其是管理员处理的时候。我的想法是网站可以和邮件列表并存,或者以后达成互联。欢迎提出意见。Bluedeck 2024年4月29日 (一) 04:05 (UTC)
- PS. 已经收到tigerzeng的意见,允许用户自定义提供的IP地址字段,以解决部分代理的问题。Bluedeck 2024年4月29日 (一) 04:22 (UTC)
- 超 英 赶 美 —— Eric Liu 創造は生命(留言・留名・学生会) 2024年4月29日 (一) 08:09 (UTC)
- 我最期待的画面出现了。--AT 2024年4月29日 (一) 09:14 (UTC)
- 好吧,终于把这个弄出来了——是蓝桌弄的?那就不出奇了。 赞——Sakamotosan路过围观 | 避免做作,免敬 2024年4月29日 (一) 09:29 (UTC)
- 非常好UX。至于是否方便了用户,我好奇能否在合理的范围内收集一些统计数据作对比,这样最有说服力。--碟之舞📀💿 2024年4月29日 (一) 14:10 (UTC)
- 另外这个工具让我想到了我很久之前做的维基媒体服务器连通性面板。--碟之舞📀💿 2024年4月29日 (一) 14:37 (UTC)
- 非常好软件。
- 不必要的功能建议:1.通过遍历封禁日志的摘要有无对应模板,显示是否是ip封禁。2.通过接口调用在界面一键创建账户(和授予ipbe?)
- 另外问一下数据托管在哪里?将来投入使用的话需要作为存档使用,所以数据需要备份好。--落花有意12138 2024年4月29日 (一) 14:42 (UTC)
- 一键创建账户/授予PIBE的话,有两种途径。第一,管理员通过oAuth授权unblock-zh.org,通过管理员账户操作,然后从本地日志看来,操作者是管理员。第二种途径是,成立一个机器人账户,比如名叫 unblock-helper-abot,并且赋予机器人管理权限,然后通过机器人操作,并在摘要里说明是根据哪个管理员的指令操作的。让我来决定的话,我倾向于使用第二种方式,因为我希望尽量不要向第三方授权我自己的账户,但是第一种方式的日志更加清晰。请问一下其他人的想法。Bluedeck 2024年4月29日 (一) 17:39 (UTC)
- 使用OAuth可以只需要简单的身份识别获得权限,用于确认是不是登录系统的对应是wiki的哪个用户。然后代理操纵的机器人可以标记操作人员的wiki用户名(通过前面获得的信息)。——Sakamotosan路过围观 | 避免做作,免敬 2024年4月30日 (二) 02:33 (UTC)
- 如果不改变单管理员授权模式,我倾向于第一种,这样和原先的工作模式保持一致,便于查询。
- mw:OAuth/For_Developers称应用做的操作会有标签。--落花有意12138 2024年4月30日 (二) 11:04 (UTC)
- 在这里没有看到可以使用oauth给用户添加组别的选项,那么也是说IPBE的授予只能透过abot进行了。Bluedeck 2024年5月1日 (三) 21:41 (UTC)
- 的确只能这样。——Sakamotosan路过围观 | 避免做作,免敬 2024年5月2日 (四) 03:40 (UTC)
- 咱好像记着这种权限似乎不需要特别勾上某个选项就默认拥有,您要不尝试一下? Stang★ 2024年5月8日 (三) 01:14 (UTC)
- 真的假的,在授权的时候不声明却可以操作改变用户组这么重要的操作?如果是真的那也是个bug吧 Bluedeck 2024年5月11日 (六) 08:40 (UTC)
- 在这里没有看到可以使用oauth给用户添加组别的选项,那么也是说IPBE的授予只能透过abot进行了。Bluedeck 2024年5月1日 (三) 21:41 (UTC)
- 用API能查IP有没本地封或者全域封,好像不是必要。——Sakamotosan路过围观 | 避免做作,免敬 2024年4月30日 (二) 02:26 (UTC)
- 一键创建账户/授予PIBE的话,有两种途径。第一,管理员通过oAuth授权unblock-zh.org,通过管理员账户操作,然后从本地日志看来,操作者是管理员。第二种途径是,成立一个机器人账户,比如名叫 unblock-helper-abot,并且赋予机器人管理权限,然后通过机器人操作,并在摘要里说明是根据哪个管理员的指令操作的。让我来决定的话,我倾向于使用第二种方式,因为我希望尽量不要向第三方授权我自己的账户,但是第一种方式的日志更加清晰。请问一下其他人的想法。Bluedeck 2024年4月29日 (一) 17:39 (UTC)
- 赞 赞 赞 牛逼--Dnaimfz(留言) 2024年5月11日 (六) 04:04 (UTC)
- 管理员布告板抄送一份通知链接至此?—— Eric Liu 創造は生命(留言・留名・学生会) 2024年6月1日 (六) 08:43 (UTC) 话说可给
- wikitech:Help:Cloud VPS?如果有,为什么不选择部属在该处?--SunAfterRain 2024年6月4日 (二) 09:30 (UTC) 想好奇请问是否有考虑过部属在
试运行[编辑]
在过去的几周里,我增加了最后的一些的功能,分别是1)按日期搜索排列工单;2)邮件回复模板;3)管理员删除工单、删除消息界面;4)用户改名功能。我想知道大家觉得还缺少哪些网站本身的功能(邮件服务器、机器人授予IPBE除外)。如果感觉差不多了,那么可以进行试运行。试运行期间,再对可能发现的新的功能需求进行补充。试运行的提议正在进行公告。如果通过,将会将网站首页文字改为试运行,并暂时移除一些只具有展示效果的链接,然后在用户无法注册的提示页面加入网站的链接,这些操作大概最多需要一天就能完成。在试运行决议通过前,如果对网站有任何问题,欢迎在此讨论。Bluedeck 2024年5月13日 (一) 23:30 (UTC)
- 功能方面,个人认为管理员不应该有删除工单的能力,这个应该由维护者来做,比如遇到spam/扰乱性工单就打上相应的标签,若干天后自动删除;可不可以出个statistics大概写一下某月某人处理了多少工单之类的;反spam方面怎么样,你觉得需要加个recaptcha吗;模板建议是放到Github或者类似公开的地方,需要改的人发pr;可以考虑加一个link/merge功能么,比如一个用户就一个问题发了多个ticket,这个时候可以把它们关联起来;感觉可以把login改的小一点,或者让非管理人员意识到不需要登录就可以发ticket。
- 另外就是建议放到toolforge或者cloud VPS上。顺便问个问题,你觉得这个系统需要承担unblock-zh最原始的封禁申诉职能吗 Stang★ 2024年5月14日 (二) 01:47 (UTC)
- 谢谢提议!简短回应:
- 删除工单就是为了应对扰乱才设计的功能。删除之后可以恢复或检视。(UI需要另外添加)工单的永久保留或删除问题在下面讨论。
- 反spam:UTRS目前是阻止同一个IP地址多次发送工单。但是我的方案不记录IP地址,无法阻止。我可以考虑一下记录ip地址的hash,并由此进行rate limit。我个人完全不喜欢captcha,除非不得已,我可能会考虑上captcha。在此之前我会尽量用其他手段处理spam问题。我有一些asymmetric proof of work的方法能防止自动化的spam。如果有人无聊到要手工spam,那么唯有记录IP并进行区段查封这一个办法。(但是这样一来,不就把本身的目的给击败了??)
- 邮件模板:我不会放在github,毕竟不是每个管理员都会开PR,我简单的开一个用户页面存储目前的模板,谁想添加,给我留个言即可。邮件模板都是非常简单的纯文字模板。当然,如果你喜欢用gh,那么在前端的repo里有一个文件,你也可以直接PR这个文件。
- link/merge:race condition太多,最多做成stack overflow/github issues那样,“标记为#109的duplicate。关闭”这种解决方案。
- login改小:我肯定会让新用户看到不login就能发工单,这是一个重要的因素。
- statistics:这个我一定会做,因为这会让处理工单变得很有趣,我的设想是做一个leaderboard,能够激发人们对于处理工单的无限潜能,哈哈哈哈。
- Hosting:toolforge不能满足我的要求,CloudVPS不熟悉。将来打算支持图片上传,需要一个能挂载S3的环境,另外多区域host允许你把服务器托管在东京/首尔/LA。目前,服务器托管在Vultr的新泽西区上面。
- 这个网站做成网站的形式,是为了新用户方便的注册+IPBE(也就是unblock-zh-ipbe的功能)。处理被长期封禁的用户在邮件列表中50-100封邮件那么长的申诉,并不是网站初衷。如果有人就是要在网站上申诉,管理员也选择在网站上处理,那我不会站出来阻止,但是如果网站上出现了对维基百科历史有一定意义的讨论内容,我觉得有应当抄送一份到邮件列表。
- Bluedeck 2024年5月14日 (二) 04:12 (UTC)
- update: 已经增加了查看和恢复已删除工单的功能。Bluedeck 2024年5月19日 (日) 06:40 (UTC)
另外还有两个别的需要讨论的问题:
- 工单是否永久保存?永久保存是目前的默认,而且邮件列表也是永久保存的。但是我觉得比如挂上“处理结束”标记90/180天之后永久删除相关信息这个是更安全的做法,想征求一下大家的意见。
- 开源:从一开始我就设想开源。这个项目有4个repo,其中3个可以在最近开源。一个需要我检查一下有没有API Key之类的物品遗落在代码中,然后才能开源。请期待。
- 共同参与:如果您想共同参与开发,或者参与对服务器的运维,欢迎在这里提出来。Bluedeck 2024年5月14日 (二) 04:49 (UTC)
- 感谢贡献,整体非常完善。如有需要可以协助维护。--Borschts™ 欢迎外带一碗罗宋汤 2024年5月14日 (二) 13:32 (UTC)
- 存档应保留,只是可以限制普通用户存取。另外,也应考虑先行在站内撰写说明页面,或补充现有方针与指引不足,以便利用。—— Eric Liu 創造は生命(留言・留名・学生会) 2024年5月14日 (二) 15:05 (UTC)
- 注意到两点可以改善:
- 无法创建账号者不应提供“我不想提供邮箱”的选项,创建账号时需填写对方电邮地址才能安全发送临时密码。如果不想提供邮箱则难以协助创建账号。
- 需要添加提示文字,若不提供IP地址则申请有可能不获受理(始终审批IPBE时需要验证用户是否使用proxy)。
- --路西法人 2024年5月15日 (三) 07:52 (UTC)
- 我脑海中预想的不提供邮件的处理方式:网站生成一个强的随机密码并记录在工单中,用户通过随机密码登录。优点:用户不需要邮箱地址。缺点:不提供邮箱的用户等于需要不断的刷新页面查看处理进度,是一个糟糕的体验。对于管理员,需要复制粘贴网站生成的密码来创建账户,也是多了一个步骤。上面我只是说明了操作的可行性,至于这个功能是否保留,可以继续讨论决定。对于第二点,IPBEG如果有这个要求,那我完全可以添加这个提示文字(甚至可以在维基百科设置一个页面,比如Template:Unblock-zh/strings/new-ticket-notice,然后网站可以反映这个页面的任意文字。)Bluedeck 2024年5月19日 (日) 06:22 (UTC)
- 我的想法是只要有任何第三方人员可以接触到任何密码的方案都是不安全的,尤其在发送邮件时在此类第三方网站留存临时密码亦是相当危险的;即使我信任你会尽力保障网络安全,但显然不安全的操作应尽可能完全避免。邮件、代理IP地址等都尚算不太危险的信息,密码真的不行。--路西法人 2024年5月21日 (二) 01:25 (UTC)
- 我想了一下觉得你说得很有道理。如果有的用户收到临时密码后不加更改,那么等于这个用户的密码永远的挂在一个所有管理员都能看到的地方,是不妥的。我已经把界面改成如果请求账户,必须提供邮箱,否则无法提交。Bluedeck 2024年5月21日 (二) 01:50 (UTC)
- 我的想法是只要有任何第三方人员可以接触到任何密码的方案都是不安全的,尤其在发送邮件时在此类第三方网站留存临时密码亦是相当危险的;即使我信任你会尽力保障网络安全,但显然不安全的操作应尽可能完全避免。邮件、代理IP地址等都尚算不太危险的信息,密码真的不行。--路西法人 2024年5月21日 (二) 01:25 (UTC)
- 我脑海中预想的不提供邮件的处理方式:网站生成一个强的随机密码并记录在工单中,用户通过随机密码登录。优点:用户不需要邮箱地址。缺点:不提供邮箱的用户等于需要不断的刷新页面查看处理进度,是一个糟糕的体验。对于管理员,需要复制粘贴网站生成的密码来创建账户,也是多了一个步骤。上面我只是说明了操作的可行性,至于这个功能是否保留,可以继续讨论决定。对于第二点,IPBEG如果有这个要求,那我完全可以添加这个提示文字(甚至可以在维基百科设置一个页面,比如Template:Unblock-zh/strings/new-ticket-notice,然后网站可以反映这个页面的任意文字。)Bluedeck 2024年5月19日 (日) 06:22 (UTC)
- 一些minor的建议:about一页,Puzzle Globe似可译为“拼图球”,Wikibooks译名应为“维基教科书”非“维基图书”。不提供邮件的提示,“一串30几位的工单”应作“三十几位”。login界面没有明显的返回按钮,侧栏也消失了。lookup界面可以考虑加注工单号和邮箱择一提供即可。 ——魔琴[身份声明 留言 贡献 新手2023] 2024年5月21日 (二) 03:01 (UTC)
- 另外我在想让其选择点选提交IP的选项是否也应该把UA也提供给审核用户检阅(方便反破坏比对)。--路西法人 2024年5月23日 (四) 07:54 (UTC)
- 统一回复。1)login界面有意如此设计。2)必须同时输入工单号和邮件,否则任意人士可以通过广泛查询邮件探知私密工单。3)UA信息只有CU才能访问,所以显然不能提供。另外就算用户主动提供了,那么IPBE处理者拿什么进行比对呢?毕竟你又看不到LTA的UA。Bluedeck 2024年5月27日 (一) 06:11 (UTC)
- 2) 啊那就是提前提示创建工单时未提供电子邮箱的须放空? ——魔琴[身份声明 留言 贡献 新手2023] 2024年5月27日 (一) 06:29 (UTC)
- 没有提供电邮的工单号会比较长,所以我可以改一下软件,让这种工单号不论是否输入电邮都能够正常查询。这样可以不破坏界面简洁易用。Bluedeck 2024年5月29日 (三) 06:45 (UTC)
- 2) 啊那就是提前提示创建工单时未提供电子邮箱的须放空? ——魔琴[身份声明 留言 贡献 新手2023] 2024年5月27日 (一) 06:29 (UTC)
- 统一回复。1)login界面有意如此设计。2)必须同时输入工单号和邮件,否则任意人士可以通过广泛查询邮件探知私密工单。3)UA信息只有CU才能访问,所以显然不能提供。另外就算用户主动提供了,那么IPBE处理者拿什么进行比对呢?毕竟你又看不到LTA的UA。Bluedeck 2024年5月27日 (一) 06:11 (UTC)
繁体支援[编辑]
这个网站估计主要的受众是大陆梯子人士。但是,由于很多管理员是繁体用户,那么我就增加了一系列的繁体支援,但是都是Google翻译的。请繁体管理员看看管理界面的翻译如果有很不和谐的地方,请指出来。如有需要,网站可以支援香港、台湾和澳门繁体的分别翻译。Bluedeck 2024年5月30日 (四) 08:15 (UTC)
- 感谢蓝桌照顾繁体用户,但我目前查看似乎有一些界面仍然是简体中文的,例如新建工单的部分,另查台湾的教育部字典,work order这个词在台湾可以翻译为“工令”、“工作命令”、“工作通知单”或“工作单”等,就是没有查到称之为“工单”之翻译,惟我日常生活中前开所有词汇均较为少见,平常类似功能之提交申请平台反而被称之为“电子表单”,这部分可能需要更多繁体用户来指出正确的翻译。--小过儿(留言) 2024年5月30日 (四) 15:30 (UTC)
- 新建工单的繁体化已经完成。关于工单这个用语的翻译,我参考了一下asus的网站,叫做“请求支援”、“搜寻案件”。不知道这算不算合适的翻译。如果觉得“案件”听其来正确,那么我就把繁体语言的工单改称案件。Bluedeck 2024年5月30日 (四) 23:49 (UTC)
工单的永久删除[编辑]
目前没有这个功能。不过,根据欧盟GDPR要求,在用户请求的情况下,应该提供一种方法永久移除其个人信息。我想让管理员能够在工单上添加一个标记,被标记的工单约一个月后真正的删除。删除真正执行前可取消。这种删除只应该在特别的情况下进行(也就是用户请求)。(也可以单独只允许行政员执行真正删除,但是我觉得管理员已经足够可信,并且还有一个缓冲期间。)Bluedeck 2024年5月31日 (五) 23:04 (UTC)
- 这个功能不错。( π )题外话:我想知道维基百科不能删除账号是否符合GDPR,以及即使OS似乎也不是真删除,这是否符合GDPR。有人去举报一下是不是基金会就会实现这个功能了。--桐生ここ★[讨论] 2024年5月31日 (五) 23:25 (UTC)
- 应该是不符合的,而且显示未登录用户ip这个似乎也有一定问题。然而我们要团结一致,不要把基金会举报给欧盟。Bluedeck 2024年6月1日 (六) 05:34 (UTC)
让 IPBEG 在 Unblock-zh 上获得和管理员一样的权限[编辑]
因为我觉得 IPBE 也是一大痛点,所以我觉得让 IPBEG 能够一起帮助处理会大有裨益。现在抛出几个方案讨论:
- 让IPBEG组和管理员同在unblock-zh.org/zhwp下有一样的(或者接近的)权限。
- 像邮件列表一样,单独新建 unblock-zh.org/zhwp-ipbe空间。
- 网站面向用户的界面不改变,根据用户是否需要 IPBE,自动将工单分发至 zhwp 或 zhwp-ipbe
- 网站设计改变,入口页面一分为二,用户需要自己选择是投递给zhwp还是zhwp-ipbe
- 不支持 IPBEG。
我觉得,从用户体验的角度,不希望入口一分为二。另外,不管选择 1 还是 2,都需要一段时间来修改网站的代码,但是 2 所花时间会更久一点,并且会增加日后维护的工作量(主要是会出现两套表单同步的问题)。关于用户隐私,由于 IPBEG 是签署 NDA 的,应该视为可信人员,所以我比较倾向 1。Bluedeck 2024年6月1日 (六) 09:25 (UTC)
- 设立IPBEG的本意就是许可IPBEG处理该类申请邮件,理论上可以说已有社群共识支持选项2,但已有共识未必支持选项1。IPBEG不能处理unblock-zh上非申请IPBE的工单。我是认为,一般而言封禁申诉本应都是在公开场合发起,申诉内容多数都应该可被所有用户查看,实质需要使用邮件申诉封禁的仅有无法编辑讨论页的情况。如你所言,IPBEG本有签署NDA,就算看了也不应该会造成什么问题(虽然能避免最好)。如果是最后采用最简化的选项1,那我觉得您可以最低限度在处理人员的界面中加入标签工单的功能,让IPBEG能明确标记跟他们职务无关的申请,从IPBE队列隐藏,仅能由添加标记的IPBEG(直至工单标签被管理员确认)及管理员查看。--路西法人 2024年6月2日 (日) 11:58 (UTC)
- 如果要让IPBEG不能看到非IPBE工单,那应该执行方式2更优。如果执行方式2,那么管理员、行政员也应该自动获得zhwp-ipbe空间权限,并进行工单自动分发。Bluedeck 2024年6月3日 (一) 08:34 (UTC)
- 不是“不能看到”,而是“不再跟IPBE有关的就没必要继续显示在同一队列,令其他正在处理IPBE申请的用户不小心点进去”。“看到”大概是不会有什么大问题的。--路西法人 2024年6月5日 (三) 02:22 (UTC)
- 如果要让IPBEG不能看到非IPBE工单,那应该执行方式2更优。如果执行方式2,那么管理员、行政员也应该自动获得zhwp-ipbe空间权限,并进行工单自动分发。Bluedeck 2024年6月3日 (一) 08:34 (UTC)
第二十二次动员令筹备讨论[编辑]
2024年非洲月筹备讨论[编辑]
原标题为:关于第三次非洲月
- 下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
去年非洲月在6月举行,取得了不少条目贡献,本人有意在今年同期继续举办非洲月,不知各位意向如何?
另Ping去年的主持人和活跃参与者@A Chinese ID@Tokisaki Kurumi@Newbamboo@Allervous@Alankang@Oscar0123@Baomi@BrianBYBYBY@AOrdinaryEditor@桃花影落飞神剑@T45614631@Nostalgiacn,如有打扰非常抱歉。——Aggie Dewadipper 2024年5月4日 (六) 22:04 (UTC)
- (+)支持虽然我很好奇为什么今年也会是6月而不是5月。--Allervous初音ミクのセーラー服 2024年5月4日 (六) 22:07 (UTC)
- 同上,我也想问。不过整体上是支持办的(虽然个人今年六月较忙恐生不出完整条目)。--WiTo🐤💬 2024年5月5日 (日) 00:42 (UTC)
- (+)支持在哪个月都好--苞米(☎)💴 2024年5月5日 (日) 00:45 (UTC)
- (+)支持,但可惜今年各方面压力都比较大,在下确已经抽不出时间来参加了;深感抱歉。-- 2024年5月5日 (日) 15:45 (UTC)
- (+)支持,预祝成功。----FradonStar|八闽风云 2024年5月7日 (二) 00:56 (UTC)
:目前来看似乎没有反对意见,那暂定非洲月于6月1日0:00至6月30日23:59(UTC)举行,考虑到时间较为紧迫就先擅自在底下开始主持人招募了。话说在6月举办应该是没人想起来 囧rz……。——Aggie Dewadipper 2024年5月6日 (一) 06:34 (UTC)
- 今年就算了,不过来年或可考虑合并动员令与非洲月,集中有限的编辑量能。—— Eric Liu 創造は生命(留言・留名・学生会) 2024年5月12日 (日) 02:56 (UTC)
主持人招募[编辑]
烦请有意担任本年非洲月主持人者在下方留言示意。招募期暂定于5月20日 00:00 (UTC)结束。——Aggie Dewadipper 2024年5月6日 (一) 06:34 (UTC)
- 来了。今年比较没有空写条目,但打杂,帮忙看条目还是可以的--A.K. 留言※签名 2024年5月6日 (一) 07:17 (UTC)
- 以及,我本人也有意主持此次活动。——Aggie Dewadipper 2024年5月7日 (二) 00:59 (UTC)
我,今年我暑假不用做事--August0422(留言) 2024年5月7日 (二) 08:29 (UTC)- 阁下之前参加过非洲月吗...--人间百态,独尊变态(讨论) 2024年5月12日 (日) 08:11 (UTC)
- 这位阁下(的账号)今年年初才开始编辑,是一定没有的。--WiTo🐤💬 2024年5月12日 (日) 08:48 (UTC)
- 阁下之前参加过非洲月吗...--人间百态,独尊变态(讨论) 2024年5月12日 (日) 08:11 (UTC)
- 6月中旬过后大概有时间,争取一下 ——魔琴[身份声明 留言 贡献 新手2023] 2024年5月14日 (二) 01:36 (UTC)
- 行,我也兼一下非洲月主持人吧,毕竟当初办非洲月就是我提议的,另一方面我有当亚洲月主持人的经验。Sanmosa 人人皆王 2024年5月17日 (五) 15:06 (UTC)
- @Dewadipper:后续如何处理?Sanmosa 人人皆王 2024年5月20日 (一) 11:41 (UTC)
- 先前几次文化月都没有对主持人有遴选,如果没有反对意见我认为目前四名自荐者(AlanKang、魔琴、Sanmosa和我本人)可直接默认为本次非洲月的主持人。——Aggie Dewadipper 2024年5月20日 (一) 21:24 (UTC)
- 不反对。那相关页面是否也可以直接设置?Sanmosa 人人皆王 2024年5月21日 (二) 02:31 (UTC)
- 应该是可以的。不过我近期忙于期中考试,可能要到24日左右才有空设置页面。—-Aggie Dewadipper 2024年5月22日 (三) 04:47 (UTC)
- Wikipedia:维基百科非洲月/2024页面开好了,请查看内容是否需要调整。fountain 五月初已申请,申请时填写的主持人为 Dewadipper君与我,由于我不是管理员,无法调整参数。--A.K. 留言※签名 2024年5月22日 (三) 09:50 (UTC)
- 主页面看上去没大问题。fountain用不用我重新开一个?按道理如果fountain是你自己动手开的话,你应该是可以调整相关设置的。Sanmosa 人人皆王 2024年5月22日 (三) 10:45 (UTC)
- fountain我是按照m:Wikipedia_Asian_Month/Fountain_tool/zh所述方式开设,当初我送出后变成draft,过几天后就通过了,如该页面所述“管理员审批过程”、“更改设置”必须拥有Wiki-project管理员权限才能更改。目前我在fountain的非洲月2024页面上可进入设置页面,但无法更改。--A.K. 留言※签名 2024年5月23日 (四) 00:12 (UTC)
- @Alankang:那我重新开一个吧,不知道链接是否有效。Sanmosa 人人皆王 2024年5月23日 (四) 09:18 (UTC)
- @Sanmosa:您开的那一个还无法读取,应该还在draft状态(可能是需要管理员核准),我开的这个 fountain的设置页面 已请Eric Liu 君帮忙添加您与魔琴君,您可以查看一下设置是否合适。--A.K. 留言※签名 2024年5月24日 (五) 06:24 (UTC)
- 还需要在Template那边勾选automatically add template,模板名称WAfM talk 2024,放置位置设置为讨论页。Sanmosa 人人皆王 2024年5月24日 (五) 09:36 (UTC)
- 已完成。--A.K. 留言※签名 2024年5月26日 (日) 13:19 (UTC)
- 还需要在Template那边勾选automatically add template,模板名称WAfM talk 2024,放置位置设置为讨论页。Sanmosa 人人皆王 2024年5月24日 (五) 09:36 (UTC)
- @Sanmosa:您开的那一个还无法读取,应该还在draft状态(可能是需要管理员核准),我开的这个 fountain的设置页面 已请Eric Liu 君帮忙添加您与魔琴君,您可以查看一下设置是否合适。--A.K. 留言※签名 2024年5月24日 (五) 06:24 (UTC)
- 不熟悉fountain更改设置的设置,但是之前办的活动改主持人时是确实是直接重开一个的() ——魔琴[身份声明 留言 贡献 新手2023] 2024年5月24日 (五) 10:55 (UTC)
- @Alankang:那我重新开一个吧,不知道链接是否有效。Sanmosa 人人皆王 2024年5月23日 (四) 09:18 (UTC)
- fountain我是按照m:Wikipedia_Asian_Month/Fountain_tool/zh所述方式开设,当初我送出后变成draft,过几天后就通过了,如该页面所述“管理员审批过程”、“更改设置”必须拥有Wiki-project管理员权限才能更改。目前我在fountain的非洲月2024页面上可进入设置页面,但无法更改。--A.K. 留言※签名 2024年5月23日 (四) 00:12 (UTC)
- 主页面看上去没大问题。fountain用不用我重新开一个?按道理如果fountain是你自己动手开的话,你应该是可以调整相关设置的。Sanmosa 人人皆王 2024年5月22日 (三) 10:45 (UTC)
- Wikipedia:维基百科非洲月/2024页面开好了,请查看内容是否需要调整。fountain 五月初已申请,申请时填写的主持人为 Dewadipper君与我,由于我不是管理员,无法调整参数。--A.K. 留言※签名 2024年5月22日 (三) 09:50 (UTC)
- 应该是可以的。不过我近期忙于期中考试,可能要到24日左右才有空设置页面。—-Aggie Dewadipper 2024年5月22日 (三) 04:47 (UTC)
- 不反对。那相关页面是否也可以直接设置?Sanmosa 人人皆王 2024年5月21日 (二) 02:31 (UTC)
- 先前几次文化月都没有对主持人有遴选,如果没有反对意见我认为目前四名自荐者(AlanKang、魔琴、Sanmosa和我本人)可直接默认为本次非洲月的主持人。——Aggie Dewadipper 2024年5月20日 (一) 21:24 (UTC)
- 本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
设立法轮功为高风险主题[编辑]
(注:依据方针原则上应至少讨论14天,但被提前关闭。6月3日后,后面有多位用户仍在下面讨论,还请先保留讨论串。)
- 下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
设立原因及原方案请见Wikipedia talk:高风险主题#设立新兴宗教为高风险主题。
法轮功页面自2005年起,已经被反反复复保护超过40次以上;讨论页也无幸免、打辩论的经典副本。
范围:
Template:法轮功、Category:法轮功
具体措施:
- 当有自动确认用户参与争议时将条目提升至延伸确认保护
- 编辑时需恪守Wikipedia:中立的观点、Wikipedia:文明、Wikipedia:可靠来源、Wikipedia:生者传记
- 管理员应当对无法遵守者实施合理编辑限制
- 法轮功及李洪志页面实施不限期半保护、回退零容忍编辑限制,以便有效阻止编辑战
--Benho7599 | Talk 2024年5月26日 (日) 02:10 (UTC)
- (+)强烈支持,并建议将回退零容忍扩张至李洪志等关联条目。就最近讨论来看参与各方难以形成共识,导致编辑战频发。—Aggie Dewadipper 2024年5月26日 (日) 17:12 (UTC)
- 李洪志实际上似乎也十分需要0RR--Benho7599 | Talk 2024年5月28日 (二) 15:27 (UTC)
- (+)支持。从讨论页上连篇累牍的争执可以看出,法轮功是风险最高的政治相关主题之一。--CuSO4 · 龙年大吉 2024年5月26日 (日) 19:52 (UTC)
- (+)倾向支持WP:1RR 代替WP:0RR -Lemonaka 2024年5月27日 (一) 06:50 (UTC)
- Skeptical toward whether 1RR would work. The current issue is that participating editors do not seek for consensus at all.--Aggie Dewadipper 2024年5月28日 (二) 05:20 (UTC)
- 不反对。Sanmosa 人人皆王 2024年5月28日 (二) 11:50 (UTC)
- 第一条任何条目都适用,不用写出来。--Cmsth11126a02 (留言) 沈伯洋是被大陆国民党立委扯衣服导致头部落地的! 2024年5月29日 (三) 04:51 (UTC)
- 需要先确定具体范围有多大,法轮功相关条目可不少。—— Eric Liu 創造は生命(留言・留名・学生会) 2024年5月29日 (三) 17:29 (UTC)
- 我暂时想到的范围是法轮功、法轮功的成员、法轮功的联系组织、与法轮功关系高度密切的人与组织。Sanmosa 人人皆王 2024年5月29日 (三) 23:39 (UTC)
- 分类:法轮功?--Cmsth11126a02 (留言) 沈伯洋是被大陆国民党立委扯衣服导致头部落地的! 2024年5月30日 (四) 13:40 (UTC)
- @Cmsth11126a02、Ericliu1912:范围暂定是Template:法轮功、Category:法轮功--Benho7599 | Talk 2024年5月31日 (五) 10:21 (UTC)
- 还要加上其他直接涉及对法轮功评价的条目(比如目前在EWIP吵的中国大陆宗教相关内容)。——Aggie Dewadipper 2024年5月31日 (五) 17:13 (UTC)
- @Cmsth11126a02、Ericliu1912:范围暂定是Template:法轮功、Category:法轮功--Benho7599 | Talk 2024年5月31日 (五) 10:21 (UTC)
- (+)支持,(&)建议可以先在互助客栈相关版面发起更具讨论度的共识讨论,以解决最近的编辑争议(如维基百科:管理员布告板/编辑争议#Marvin 2009)并为该例争议确立共识标准以及为未来可能的讨论页内争议(鉴于基本上并非寻求共识的情况)创建某种程度上从互助客栈引入共识的参考解决方案。Sinet(讨论) 2024年5月30日 (四) 22:48 (UTC)
已通过,创建Wikipedia:高风险主题/法轮功。-Mys_721tx(留言) 2024年6月3日 (一) 03:00 (UTC)
- 注:根据WP:CTOP注释一根据雪球法则一周结案。-Mys_721tx(留言) 2024年6月3日 (一) 03:22 (UTC)
- 本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
- (!)意见+(?)疑问-(1)没有注意到有这里有此讨论,没有挂在“法轮功”条目页通知。早上,在下在“法轮功”条目讨论页回应交流时,突然看到条目被半保护等。讨论留言仅到5月31日,近期参与条目讨论的用户似乎并不知道、未能参与,是否应该在相关条目、例如主要条目上有个通知。(2)在下对于设立高风险主题的问题,认为需要更多的讨论为宜。Wetrace欢迎参与WP人权专题 2024年6月3日 (一) 03:36 (UTC)
- (?)疑问--共识并未达成。程序不符合方针规范,讨论区8天刚过就遭关闭,但方针要求“维持开放最少两周”。
- 依据WP:高风险主题---任何延伸确认用户可在互助客栈其他板发起及参与指定高风险主题及相关编辑限制的讨论。提案人必须论证主题之风险,并建议合适的编辑限制措施。讨论发起一日内应于公告栏张贴通知。讨论一般维持开放最少二周,若社群取得共识[a]即可由管理员结案,通过者并应创建主题子页面(例如“维基百科:高风险主题/<主题>”)。
- 这次讨论仅进行8天,违反“讨论一般维持开放‘最少二周’”的规范。
- Benho7599从5月26日UTC时间2点左右在互助客栈张贴,最后一笔留言在5月31日,管理员Mys 721tx在6月3日UTC时间3点左右关闭,讨论只进行“刚满8天”就遭到关闭、称达成共识。在下Wetrace在法轮功条目讨论页留言后不久,就看到管理员Mys 721tx关闭讨论,并列为“高风险主题”。----在下于6月3日UTC时间3点多,在互助客栈留言表示,认为需要更多的讨论为宜、近期参与条目讨论的用户不知道、是否应该条目讨论页通知有此讨论。
- “讨论发起一日内应于公告栏张贴通知”,请问是否有放在“公告栏”?“公告栏”是指哪里?是否能有效的让常参与的相关参与用户知晓,表达意见?----讨论包含发起人,仅7人(更正,10人)留言。
- 管理员Mys 721tx称“根据雪球法则一周结案”,雪球法则不是方针、不是指引。尤其在只有7人(更正,10人)在5/26-31留言,许多人恐怕并未知晓来表达意见。
- 【后面有 重新整理这部分,这里就画线、不用重复看。】
发起理由、范围、方式都值得商榷。试举几例- 发起人理由称,2005年以来“法轮功”条目页面保护40次----这是“19年”的时间,而且也要看看保护的原因。
- 涉及条目范围恐怕过大,将“分类:法轮功”都纳入,是不是都需要呢?由于涉及范围大,条目的风险,论证是否足够?依据方针,“提案人必须‘论证’主题之风险,并建议合适的编辑限制措施。”
- 发起讨论人的理由写到“设立原因及原方案请见Wikipedia talk:高风险主题#设立新兴宗教为高风险主题”。点入后里面提到“不熟悉方针的新手/IP用户可能会根据自己的立场加入不符合编辑方针的内容”---这其实可以先通过“半保护”就可大幅改善处理。
- 且例如,要求对条目0RR,也会大幅影响WP:修改、回退、讨论循环的合理进行。留言中也有用户提出不同意见。
此前,用户违反3RR、人身攻击屡屡违反文明方针,在下列出明确证据举报后,管理员并未处理。从落实现有方针来改善,也是重要的作法。Wetrace欢迎参与WP人权专题 2024年6月4日 (二) 00:11 (UTC)
- (?)疑问--共识并未达成。程序不符合方针规范,讨论区8天刚过就遭关闭,但方针要求“维持开放最少两周”。
- 讨论一般维持开放最少二周,若社群取得共识[a]即可由管理员结案。
- [a]:若讨论发起七日后已有大量用户参与且非常明显近乎完全一致则可考虑提早结案。
- 讨论一般维持开放最少二周,若社群取得共识[a]即可由管理员结案。
- 可以看到上述讨论完全一致支持,适用雪球法则,而且一般来说在客栈讨论已经非常醒目,无需使用RFC、FRS或在其他讨论页通知。--桐生ここ★[讨论] 2024年6月4日 (二) 00:22 (UTC)
- (-)反对-“讨论一般维持开放最少二周,若社群取得共识[a]即可由管理员结案。”从方针来看,“开放至少两周”+“若社群取得共识”,两者皆为要件。方针中也并未规范“雪球法则”,这会不会架空了方针?管理员8天即关闭讨论、并且在条目页面半保护,引起在下注意到,发现原来正在进行此讨论,在下随即来此讨论页留言表达异议,认为需要更多时间讨论、并是否应在条目讨论页采取方式让参与编辑的用户知悉、Wetrace欢迎参与WP人权专题 2024年6月4日 (二) 00:33 (UTC)
- 你这个真的叫错误解读方针,和Gluo88那个不一样。--桐生ここ★[讨论] 2024年6月4日 (二) 00:56 (UTC)
- Gluo88 是什么事?在下不清楚。Wetrace欢迎参与WP人权专题 2024年6月4日 (二) 01:03 (UTC)
- 你看他日志。--桐生ここ★[讨论] 2024年6月4日 (二) 01:16 (UTC)
- Gluo88 是什么事?在下不清楚。Wetrace欢迎参与WP人权专题 2024年6月4日 (二) 01:03 (UTC)
- 你这个真的叫错误解读方针,和Gluo88那个不一样。--桐生ここ★[讨论] 2024年6月4日 (二) 00:56 (UTC)
- (-)反对-“讨论一般维持开放最少二周,若社群取得共识[a]即可由管理员结案。”从方针来看,“开放至少两周”+“若社群取得共识”,两者皆为要件。方针中也并未规范“雪球法则”,这会不会架空了方针?管理员8天即关闭讨论、并且在条目页面半保护,引起在下注意到,发现原来正在进行此讨论,在下随即来此讨论页留言表达异议,认为需要更多时间讨论、并是否应在条目讨论页采取方式让参与编辑的用户知悉、Wetrace欢迎参与WP人权专题 2024年6月4日 (二) 00:33 (UTC)
- 此外,按照以往案例,将在世人物传记订为高风险主题为4人支持,八九民主运动为6人支持,加密货币及区块链为6人支持,搜索引擎优化与营销为3人支持,因此支持人数按照以往案例来说并不低。--桐生ここ★[讨论] 2024年6月4日 (二) 00:38 (UTC)
- 桐生您好,该附款的要件是“七日后已有‘大量用户参与’且‘非常明显近乎完全一致’则可考虑提早结案”,而不是“支持人数”。Wetrace欢迎参与WP人权专题 2024年6月4日 (二) 12:53 (UTC)
- (!)意见-桐生您好,这样的支持人数,是不是很可能反映了这样的讨论,“公告”机制上的不足?方针要求“讨论发起一日内应于‘公告栏张贴通知’。”Wetrace欢迎参与WP人权专题 2024年6月4日 (二) 00:46 (UTC)
- 2024年5月26日已经在公告栏通知。--桐生ここ★[讨论] 2024年6月4日 (二) 00:52 (UTC)
- 谢谢桐生贴出。Wetrace欢迎参与WP人权专题 2024年6月4日 (二) 13:07 (UTC)
- (!)意见
- 方针要求“讨论发起一日内应于‘公告栏张贴通知’。”从方针要求“公告栏张贴通知”、讨论“开放最少两周”,显示是让社群有充分注意、讨论。
- 方针写到“讨论一般维持开放最少二周,若社群取得共识[a]即可由管理员结案”。在[a]附注,“制定讨论的共识不强求一致同意,但也不是点票。制定讨论的共识需考量所有用户提出的理据和观点。若讨论发起七日后已有大量用户参与且非常明显近乎完全一致则可考虑提早结案。”
- (1)将此重要讯息写在 [a]附注,在公示效果上是否适当?在下高度保留,如果认为有此需要,应写入本文。且使用上应相当谨慎。
- (2)a[附注]写到“七日后已有大量用户参与”---但是“七日后已有大量用户参与”---加发起人仅7人留言(更正:含发起人10人-仍难属“大量用户”),属于“大量用户参与”吗?这样的认定,恐怕出现很大的恣意性空间,是否宜更审慎。 实际上大幅压缩了方针“讨论一般维持开放最少二周”。
- (3)当管理员到去对条目半保护等,在下发现此讨论,就过来留言表达 需要更多时间讨论。Wetrace欢迎参与WP人权专题 2024年6月4日 (二) 00:58 (UTC)
- 关于2(1),方针既然已经这样写,说明管理员执行的没问题,即使写入了正文,也不会影响本次执行结果。--桐生ここ★[讨论] 2024年6月4日 (二) 01:05 (UTC)
- (?)疑问--“讨论一般维持开放最少二周”,[a]附注“七日后已有大量用户参与”---加发起人仅7人留言(更正:10人-仍难属“大量用户”),属于“大量用户参与”吗?这样的认定,恐怕出现很大的恣意性空间,是否宜更审慎。否则,这样的作法,实际上大幅压缩了方针原则性的“讨论一般维持开放最少二周”。---在下实在疑惑:既然鼓励用户“踊跃参与”表达意见,7人(更正:含发起人10人-仍难属“大量用户”)能算是维基社群的“大量用户参与”吗?Wetrace欢迎参与WP人权专题 2024年6月4日 (二) 01:08 (UTC)
- (!)意见-桐生您好, (1)7人讨论(更正:含发起人10人-仍难属“大量用户”),很难说是“已有大量用户参与”,因此“考虑提前结案”更应该审慎。在这样情况下,应当遵循方针“讨论一般维持开放最少二周”。何况,当管理员要提前结案,在下就来此表达不同意见,认为需要更多时间讨论了。(2)即便在这7人的讨论中,也对于内容、方法等有些意见,这些疑问还存在。讨论应当持续进行。Wetrace欢迎参与WP人权专题 2024年6月4日 (二) 01:32 (UTC)
- (?)疑问--“讨论一般维持开放最少二周”,[a]附注“七日后已有大量用户参与”---加发起人仅7人留言(更正:10人-仍难属“大量用户”),属于“大量用户参与”吗?这样的认定,恐怕出现很大的恣意性空间,是否宜更审慎。否则,这样的作法,实际上大幅压缩了方针原则性的“讨论一般维持开放最少二周”。---在下实在疑惑:既然鼓励用户“踊跃参与”表达意见,7人(更正:含发起人10人-仍难属“大量用户”)能算是维基社群的“大量用户参与”吗?Wetrace欢迎参与WP人权专题 2024年6月4日 (二) 01:08 (UTC)
- 2024年5月26日已经在公告栏通知。--桐生ここ★[讨论] 2024年6月4日 (二) 00:52 (UTC)
- 此外,按照以往案例,将在世人物传记订为高风险主题为4人支持,八九民主运动为6人支持,加密货币及区块链为6人支持,搜索引擎优化与营销为3人支持,因此支持人数按照以往案例来说并不低。--桐生ここ★[讨论] 2024年6月4日 (二) 00:38 (UTC)
- 通过公示又推翻的又不是一次两次,@Wetrace所以您的看法是? ——魔琴[留言 贡献] 2024年6月4日 (二) 02:05 (UTC)
- (!)意见-魔琴您好,如上表述的意见,在下以为,这一讨论并未完成、参与者少、留言讨论少、现有的留言也有分歧意见未获充分讨论,并不符合“已有大量用户参与”的“考虑提前”关闭的情况。提前关闭并不合适,应依据方针开放至少14天的讨论。Wetrace欢迎参与WP人权专题 2024年6月4日 (二) 02:16 (UTC)
- 我觉得提前结案没有问题,如果您反对提案或者有异议的话可以继续讨论,寻求达成新的共识 ——魔琴[留言 贡献] 2024年6月4日 (二) 02:22 (UTC)
- 魔琴您好,在下以为,此一讨论应该依据方针持续14天,不宜提前关闭。7人讨论(更正:含发起人10人-仍难属“大量用户”),很难说是“已有大量用户参与”,且也存在些具体不同意见。Wetrace欢迎参与WP人权专题 2024年6月4日 (二) 02:25 (UTC)
- @Wetrace:我个人认为管理员的操作反映了共识。如果您认为现在不应该结案,那您具体的意见是什么呢?如果您也没有意见没必要再等吧? ——魔琴[留言 贡献] 2024年6月4日 (二) 09:31 (UTC)
- 魔琴您好,在下以为,此一讨论应该依据方针持续14天,不宜提前关闭。7人讨论(更正:含发起人10人-仍难属“大量用户”),很难说是“已有大量用户参与”,且也存在些具体不同意见。Wetrace欢迎参与WP人权专题 2024年6月4日 (二) 02:25 (UTC)
- 我觉得提前结案没有问题,如果您反对提案或者有异议的话可以继续讨论,寻求达成新的共识 ——魔琴[留言 贡献] 2024年6月4日 (二) 02:22 (UTC)
- (!)意见--魔琴您好,在下上面已经具体提出了一些具体疑问,例如范围、作法、是否需要,等等。在下认为,应该至少讨论14天Wetrace欢迎参与WP人权专题 2024年6月4日 (二) 11:24 (UTC)
- (!)意见--(1) 7人讨论(更正:含发起人10人-仍难属“大量用户”),能算是“已有大量用户参与”而提前关闭讨论?在下以为,对于维基“高风险主题”方针的解读、执行应严谨,不然,如果今天改一点、明天变一点,会不会似乎变相成了潜规则、被利用的漏洞?那么,不仅对条目争议不利,恐怕还可能增加了对新方针的误导、纠偏的争议或后遗症。(2)或许提案人本意想有助于解决问题,但解决问题,需要避免的情况是,会不会反而增加了问题复杂性。如果依据过去的主要方针不能解决问题,是执行方针的问题吗?或者什么? 如果需要 新设的“WP:高风险主题”方针,就一个议题设置为高风险主题,要形成共识,那么方针规定“至少讨论14天”,其实也意味可能需要更多讨论时间,毕竟这不是局部小问题的探讨,而可能是影响长久的,过程不宜粗糙的解读操作,理应更多人参加较细致的讨论,不宜简单过去。Wetrace欢迎参与WP人权专题 2024年6月4日 (二) 11:18 (UTC)
- (!)意见-魔琴您好,如上表述的意见,在下以为,这一讨论并未完成、参与者少、留言讨论少、现有的留言也有分歧意见未获充分讨论,并不符合“已有大量用户参与”的“考虑提前”关闭的情况。提前关闭并不合适,应依据方针开放至少14天的讨论。Wetrace欢迎参与WP人权专题 2024年6月4日 (二) 02:16 (UTC)
- (!)意见-魔琴您好,与魔琴、发起人Hoben7599、参与的各位交流。对于本案,实质面,在下在上面列举部分意见与疑虑,再整理如下,提供参考,感谢耐心阅读:
- 此讨论的,发起理由、范围、方式,有些值得商榷处,试举几例提出交流
- 发起人理由称,2005年以来“法轮功”条目页面保护40次----这是“19年”的时间,而且也要看看保护的原因。
- 涉及条目范围恐怕过大,将“分类:法轮功”中的条目都纳入,相关条目,是不是都需要呢?涉及范围大,条目的风险,论证是否足够?依据方针,“提案人必须‘论证’主题之风险,并建议‘合适’的编辑限制措施。”
- 发起讨论人的理由写到“设立原因及原方案请见Wikipedia talk:高风险主题#设立新兴宗教为高风险主题”。点入后里面提到“不熟悉方针的新手/IP用户可能会根据自己的立场加入不符合编辑方针的内容”---(1)这其实可以先通过“半保护”就可大幅改善处理。(2)发起人建议,对两个条目的方案是“不限期半保护+0RR”,但是,0RR不得回退,会不会反过来 让这些“不符合编辑方针的内容”不被回退,而限制了正常的编辑与反破坏?这会不会影响,很常见的WP:修改、回退、讨论循环的合理进行。在前面的讨论中,也有用户提出对0RR的不同意见。是不是需要再商榷?
- 方案中,“‘当有自动确认用户参与争议’时将条目提升至延伸确认保护”---“当有自动确认用户参与争议”---这要如何判断?
- 发起人的方案,要求“恪守Wikipedia:中立的观点、Wikipedia:文明、Wikipedia:可靠来源、Wikipedia:生者传记”-----疑问:如果要方案,是不是该有相当关键核心的WP:可供查证? 要有WP:不要人身攻击?
- 此外,从落实现有方针来改善,也是重要的作法。此前,有用户在相关条目上,违反3RR、人身攻击屡屡违反文明方针,在下列出明确证据举报后,不知为何管理员并未处理。Wetrace欢迎参与WP人权专题 2024年6月4日 (二) 12:06 (UTC)
- 此讨论的,发起理由、范围、方式,有些值得商榷处,试举几例提出交流
- (!)意见-魔琴您好,与魔琴、发起人Hoben7599、参与的各位交流。对于本案,实质面,在下在上面列举部分意见与疑虑,再整理如下,提供参考,感谢耐心阅读:
- (!)意见-查阅Wikipedia:高风险主题,各个讨论期间,此前都在14天以上。
- 法轮功主题---讨论期,2024年 5/26~6/3,8天。
- Wikipedia_talk:高风险主题/在世人物传记--讨论期 2023年8/30~9/13,约14天。
- Wikipedia_talk:高风险主题/台湾海峡两岸关系及政治地位---2023年8/30~9/18,约19天。
- Wikipedia_talk:高风险主题/加密货币及区块链--2023年 9/27~10/19,约22天
- Wikipedia_talk:高风险主题/反对逃犯条例修订草案运动--2023年8/30~11/24,约25天。
- Wikipedia_talk:高风险主题/八九民主运动--2023年 11/7~12/19,约42天。
- Wikipedia_talk:高风险主题/医学--2023年10/9~11/22,约43-44天。
- Wikipedia_talk:高风险主题/搜索引擎优化与营销---2023年 8/31~10/27,约57天。
是不是创建一个披露过滤器细节的规范比较好[编辑]
我希望知道,披露某个编辑的哪个字眼触发过滤器,是否是可以的。比如说,披露“黑人警察”四个字触发过滤器是可行的吗?披露“收购”触发过滤器也是可行的吗?如果认为这种程度的披露是可以接受的话,我觉得我运用权限就能有更多的自由。我申请过滤器助理的原因之一就是处理这种情况。--MilkyDefer 2024年5月27日 (一) 16:25 (UTC)
- 又或者说,我以后是否可以依照“您编辑中的XXX字样触发了过滤器YYY中用以阻挡ZZZ等类似字眼的过滤规则”的句式来回应。此外,此等消息是否真的要闹到客栈长篇大论后才能披露,以闹取胜?--MilkyDefer 2024年5月27日 (一) 16:30 (UTC)
- @MilkyDefer:理论上我们可以认为助理(及管理员)任职要求是能够判断是否合理披露此类信息?或是社群在此处明确授权助理(及管理员)有权如此做。—— Eric Liu 創造は生命(留言・留名・学生会) 2024年5月29日 (三) 07:06 (UTC)
- 判断哪些细节透露出来会导致过滤器无法发挥预期作用大概是不会有具体标准的,但判断起来并不困难。只有部分破坏者了解过滤器并主动试探,而这时生效的往往还有其它的判断规则。关键字是比较容易误伤、公开部分影响较小的,这种情况自行判断即可吧。——暁月凛奈 (留言) 2024年5月29日 (三) 07:46 (UTC)
- 我披露了“黑人警察”是因为这个规则已经被撤销了。而且由于这是一个编写极有缺陷的规则,就算没有被别人撤销,我也会撤销它,因此我觉得这并不算披露细节。Bluedeck 2024年6月1日 (六) 09:56 (UTC)
关于“Save to”和“Moved to”[编辑]
现时{{Save to}}和{{Moved to}}模板提供将讨论移动至多个讨论页的选项,然而有用户指出这有“若有人添加留言,则变成讨论闹多胞”的问题。我想Move to的逻辑能否修改成存档至一主页面,然后在其他页面提供“X处有和本条目相关讨论的”的导引,或者以{{#section-h:主页面|讨论标题}}
的形式在其他页面存档。谢谢。Ghren🐦🕒 2024年5月28日 (二) 07:15 (UTC)
- (+)赞成:像重定向到某条目一样可以集中讨论,然而反对强制限于主页面讨论。 -- 月都 ※ 2024年5月28日 (二) 10:12 (UTC)
- @Ghren:你说的是否{{save to}}?Sanmosa 人人皆王 2024年5月28日 (二) 11:49 (UTC)
- 标题指的是“Moved to”,不知何故被重定向至“Vmp”模板。不过“Save to”也可一并加上。Ghren🐦🕗 2024年5月28日 (二) 12:08 (UTC)
- 不支持,这两个模板几乎都是用在存档的情况,要配合集中讨论制度另开模板比较好,另您这完全没考虑导引失效的问题--SunAfterRain 2024年5月28日 (二) 13:13 (UTC)
- 两者的定位不同吧,saveto是给存档时方便机器人迁移到指定的讨论页存档(saveto一般不接续讨论),moveto是现在的讨论迁移到新的页面去继续(搭配movefrom,讨论一般可以接续)。——Sakamotosan路过围观 | 避免做作,免敬 2024年5月29日 (三) 00:45 (UTC)
- @Ghren:事实上更应该搭配关闭讨论模板,明确指出这是已经关闭的讨论,这样即可以免除造成重复讨论的责任(别人坚持要继续那也不关原始讨论参与者的事了)。实际上一般条目讨论页也是如此,这跟有没有强制规定讨论地点根本无关(兼答共识方针修订某理由)。—— Eric Liu 創造は生命(留言・留名・学生会) 2024年5月29日 (三) 04:09 (UTC)
- 同意,机器人存档时自动加上{{archive top}}即可。——BlackShadowG Slava Ukraini! 2024年6月2日 (日) 00:32 (UTC)
- 不过我问过维护机器人Jimmy Xu,他的意见比较消极。—— Eric Liu 創造は生命(留言・留名・学生会) 2024年6月5日 (三) 04:35 (UTC)
- 同意,机器人存档时自动加上{{archive top}}即可。——BlackShadowG Slava Ukraini! 2024年6月2日 (日) 00:32 (UTC)
介绍 iOS 建议编辑:增强维基百科的移动贡献[编辑]
你好,我是阿玛尔·拉马丹,是基金会应用团队的高级运动传播专员。我很高兴与大家分享一些消息。
我们将一个新功能引入 iOS 维基百科应用程序,名为“建议编辑”。该功能旨在增强 iOS 设备上的移动编辑,使您等用户更简单地贡献于维基百科。建议编辑已经在 Android 应用程序以及维基百科的移动和桌面版本上可用,我们很高兴地将其带到 iOS,首先是图片推荐。
您是否曾想过为特定维基百科文章评估图片?现在,有了 iOS 建议编辑,您就可以做到。 “添加图片”任务会为没有图片的文章建议一张图片。无论您身在何处,都有机会评估图片,并确定其是否适合包含在文章中。如果图片不适合该文章,您可以提供反馈原因。如果看起来合适,您可以继续编辑文章以添加图片、图片标题和替代文本。
我们很高兴地宣布,iOS 建议编辑,现已发布到所有维基。我们鼓励您尝试一下,并了解您如何可以直接从您的 iOS 设备丰富维基百科内容。有关该功能的更多信息可以在项目页面上找到;我们计划很快添加更多的贡献类型,因此请订阅该页面以获取最新信息,或者我们邀请您观看该功能的视频演示;演示脚本已经翻译成您的语言。感谢您成为维基百科社区的一员,我们期待看到这一新功能在未来的影响。
--ARamadan-WMF(留言) 2024年5月29日 (三) 07:45 (UTC)
将“1945年后台湾政治”订为高风险主题[编辑]
原标题为:将“台湾政治”订为高风险主题
台湾政治类内容长期遭受破坏及编辑战影响,当中不乏管理员下场参与编辑战,近期的社会运动导致的破坏及编辑战更是反映有需要增加一定限制。由此,我提议新增“台湾政治”高风险主题,涵盖“1945年后台澎金马地区内政外交有关的人物、组织及事件”(不包括已有主题的海峡两岸关系及台湾政治地位),实施以下编辑限制:
- 编者须严格遵守可供查证、中立的观点、生者传记等核心方针指引;
- 管理员可对扰乱编辑(包括破坏、编辑战及其他不当编辑,或在讨论时发表任何针对政治地位的诉诸人身、不文明行为和假定恶意的言论)实施标准编辑限制措施。
- 以下条目因长期遭受破坏及编辑战影响而提请实施编辑限制措施:
- 中华民国(目前已按WP:CTOP/CSRPS主题不限期保护,不需改变保护状态)
- 中国国民党(目前已按WP:CTOP/CSRPS主题不限期保护,而最近的保护是因台湾本地政治引发的破坏,不需改变保护状态但应从CSRPS剔除)
- 民主进步党:不限期半保护
- 台湾民众党:不限期半保护
- 二二八事件:不限期半保护+回退不过一
- 太阳花学运:不限期半保护
- 其他建议的编辑限制措施:
- 2024年立法院改革争议、青鸟行动及子条目:不限期半保护+回退不过一,至事件结束解除;解除全保护以回退限制取代(因事件急速发展,全保护仅会限制条目更新)
--路西法人 2024年5月30日 (四) 12:48 (UTC)
- “有关的个体”范围太大(难道合一行动联盟、中国民主党也要涵盖?),建议改为“有关的主要政党”。--Cmsth11126a02 (留言) 沈伯洋是被大陆国民党立委扯衣服导致头部落地的! 2024年5月30日 (四) 13:49 (UTC)
- “有关的个体”默认仅须遵守三大核心方针,如果起争议的话也应该按此高风险主题处理即可。--路西法人 2024年5月30日 (四) 16:07 (UTC)
- 台湾政治相关内容范围太大,建议缩小。—— Eric Liu 創造は生命(留言・留名・学生会) 2024年5月30日 (四) 13:57 (UTC)
- 或得将“海峡两岸关系及台湾政治地位”更名为“海峡两岸关系及台湾政治”,然后直接将上该条目列入管制范围。—— Eric Liu 創造は生命(留言・留名・学生会) 2024年5月30日 (四) 14:03 (UTC)
- 英维能把1992年后美国政治整个纳入高风险,1949年后台湾政治除了年分外显然不会比1992年后美国政治广多少,真的难以说是“范围太大”。海峡两岸的高风险主题核心在于两岸间的WP:NPOV、MOS:CS4D,而此建议高风险主题的核心则在于台湾本地政党间的内容,两者显然属于不同的范畴,不适宜合并处理。--路西法人 2024年5月30日 (四) 16:11 (UTC)
- 上边既然包括了二二八,那倒不如将年份拉到1945年。反正只差四年。--Ghren🐦🕓 2024年5月31日 (五) 08:42 (UTC)
- 太习惯1949这个年份了 囧rz……已修订年份。--路西法人 2024年5月31日 (五) 09:54 (UTC)
- 1945-1949期间哪有台澎金马地区这种东西( ——魔琴[身份声明 留言 贡献 新手2023] 2024年5月31日 (五) 10:15 (UTC)
- 我主要不想特地标明政权名字是为了涵盖未来任何变化。45-49年台湾的议题到现在还是争议相当大,写“45-49年间台湾本岛及49年后台澎金马地区”也比较别扭吧(((小范围地有点奇怪大概也问题不大。--路西法人 2024年5月31日 (五) 11:11 (UTC)
- 其实真要说的话,“外交”一词也能起争议,所以我觉得确实是别较真词汇了。—— Eric Liu 創造は生命(留言・留名・学生会) 2024年6月1日 (六) 17:12 (UTC)
- 我主要不想特地标明政权名字是为了涵盖未来任何变化。45-49年台湾的议题到现在还是争议相当大,写“45-49年间台湾本岛及49年后台澎金马地区”也比较别扭吧(((小范围地有点奇怪大概也问题不大。--路西法人 2024年5月31日 (五) 11:11 (UTC)
- 那末“1945年后台澎金马地区内政外交有关的个体和事件”或应改为“1945年以后与台澎金马地区内政及外交有关的人事物”较为通顺。—— Eric Liu 創造は生命(留言・留名・学生会) 2024年6月1日 (六) 17:10 (UTC)
- 比较少会“物”,更多是“人组成的组织”,形容做“物”有点奇怪吧。--路西法人 2024年6月1日 (六) 17:24 (UTC)
- “人物、事件及组织”?—— Eric Liu 創造は生命(留言・留名・学生会) 2024年6月3日 (一) 02:30 (UTC)
- 比较少会“物”,更多是“人组成的组织”,形容做“物”有点奇怪吧。--路西法人 2024年6月1日 (六) 17:24 (UTC)
- 1945-1949期间哪有台澎金马地区这种东西( ——魔琴[身份声明 留言 贡献 新手2023] 2024年5月31日 (五) 10:15 (UTC)
- 太习惯1949这个年份了 囧rz……已修订年份。--路西法人 2024年5月31日 (五) 09:54 (UTC)
- 上边既然包括了二二八,那倒不如将年份拉到1945年。反正只差四年。--Ghren🐦🕓 2024年5月31日 (五) 08:42 (UTC)
- (+)支持,至于上面提到的范围太大的问题,目前我是不这么觉得啦,毕竟那些条目目前也没有长期受破坏与编辑战影响,自然并无适用更严格编辑限制措施的必要。--冥王欧西里斯(留言) 2024年5月31日 (五) 01:44 (UTC)
- (+)支持--Benho7599 | Talk 2024年5月31日 (五) 06:41 (UTC)
- (+)支持--CaryCheng(留言) 2024年6月2日 (日) 16:45 (UTC)
- 那些表态支持统一的台湾艺人,当作"台湾政治相关"吗?--北极企鹅观赏团(留言) 2024年6月4日 (二) 00:21 (UTC)
- 受到破坏的页面好像不是很多?——暁月凛奈 (留言) 2024年6月4日 (二) 02:37 (UTC)
- 若人物条目遇政治表态相关的破坏或编辑战,那么就适用高风险主题的措施;若破坏或编辑战与政治表态无关,那么则不视作高风险主题的编辑限制。--路西法人 2024年6月4日 (二) 05:23 (UTC)
- 人物条目通常适用“WP:CTOP/BLP”(尽管有无政治表态),如果因为政治表态而在短时间内有多则编辑,应该只要临时半保护就好了(至少3个月)。--Sinsyuan✍️🌏🚀 2024年6月4日 (二) 07:27 (UTC)