维基百科:互助客栈/方针
）。
 |
发表前请先搜索存档，参考旧讨论中的内容可节省您的时间。 |
| |||||||||||||||||||||||||||||||||||||
公告栏
- [公告] 维基共享资源中有关台湾全景自由的说明有所更改，通知本地社群并征询可能的异议或意见。拍摄当地美术作品的照片可能不能再上传。
- [公告] 连接号一字线改用em dash已获通过。
- [讨论]
关注度指引更名事宜正进行集中讨论，敬请踊跃参与。 - [讨论] 互助客栈方针区正在讨论提议限制在维基百科使用ChatGPT及类似工具、重修封禁方针及禁制方针、建议将WP:EVENT升格为社区正式指引及FA/FL/FP的命名问题，敬请踊跃参与。
- [讨论] 互助客栈其他区正在讨论废弃的子模板是否应该被提删乃至于删除及共享资源重命名文件窗口bug，敬请踊跃参与。
 存档 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| # | 💭 话题 | 💬 | 👥 | 🙋 最新发言 | 🕒 (UTC+8) |
|---|---|---|---|---|---|
| 1 | 整理引导新手的相关页面 | 47 | 17 | Tokisaki Kurumi | 2023-03-22 00:08 |
| 2 |  关注度指引改名事宜
|
1 | 1 | LuciferianThomas | 2023-01-20 16:10 |
| 3 | 提议限制在维基百科使用ChatGPT及类似工具 | 82 | 39 | Shizhao | 2023-03-28 17:10 |
| 4 | 连接号一字线的符号选择 | 63 | 17 | Lt2818 | 2023-03-27 21:03 |
| 5 | 重修封禁方针及禁制方针 | 65 | 8 | LuciferianThomas | 2023-03-22 21:58 |
| 6 | 重提草稿化讨论 | 38 | 9 | S8321414 | 2023-03-28 12:15 |
| 7 | 建议将WP:EVENT升格为社区正式指引 | 20 | 11 | 百战天虫 | 2023-03-23 14:47 |
| 8 | “A地－B地关系”是不是该用短横线？ | 10 | 7 | Sanmosa | 2023-03-28 20:10 |
| 9 | 有考虑把“特色列表”改成“典范列表”吗？ | 16 | 10 | Ephemeral Days | 2023-03-28 22:19 |
| 10 | 提议将AI或深度学习技术生成的文章列为不可靠来源 | 12 | 11 | Ephemeral Days | 2023-03-28 22:25 |
| 11 | 政府单位“限阅”文件得否在撰写条目时引用 | 1 | 1 | Ericliu1912 | 2023-03-22 04:44 |
| 12 | 使用ChatGPT等软件来辅助编写维基百科是否允许？是否需要标注？ | 5 | 2 | Shizhao | 2023-03-28 22:05 |
| 发言更新图例 |
|---|
|
|
|
|
|
| 特殊状态 |
| 已移动至其他页面 或完成讨论之议题 |
| 手动设置 |
| 当列表出现异常时， 请先检查设置是否有误 |
整理引导新手的相关页面编辑
目前用以帮助新人的页面实在庞杂。WP:欢迎、WP:入门、H:简介和WP:参与贡献内容都大差不差；WP:新手上路感觉也可和WP:第一印象等分享感受的页面合并；H:从这里开始是不是另一种WP:新手简明指南呢；WP:线上训练整得不明不白，又出来了WP:维基百科大历险。这些页面看似相同，实际偏向主题各不相同，但是新手看来只会感到困惑；且目前想快速编辑的新手也很难直接找到有用的帮助，是否应该参照英维在侧边栏放入引导页面的链接呢，比如H:简介。--甘糸（留言） 2022年11月7日 (一) 02:57 (UTC)
- 很搞笑的事情是主页上的“人人可编辑”链接转到WP:欢迎，左右两边都是navbox，各种鲜艳晃眼的色彩。反观英维就好看得多了。--0xDeadbeef（留言） 2022年11月9日 (三) 10:27 (UTC)
- WP:欢迎其实完全可以被H:简介取代。--BlackShadowG Slava Ukraini! 2022年11月9日 (三) 13:34 (UTC)
- 有一种上世纪网页的美，花花绿绿，要是再来点滚动屏就更像了[开玩笑的]----诚挚的 ZhaoFJx（论•编） 2022年11月14日 (一) 14:49 (UTC)
- 怕搞混的话，就在最上方放“论述”也行吧！ 2022年11月15日 (二) 06:55 (UTC)
- 建了个协作页面：WikiProject:维基百科发展/新手2023，个人觉得创建条目相关页面也需要优化整理。 ——魔琴 [ 留言 贡献 ] 2022年11月18日 (五) 09:08 (UTC)
- 认同有改革之必要，以确实分流。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年11月25日 (五) 18:18 (UTC)
- 下面有必要挂{{不存档}}吗？这应该是一个比较长期的工作，如果没有用户有意帮忙整理这些页面，似乎讨论串开着意义也不太大。--BlackShadowG Slava Ukraini! 2022年12月6日 (二) 12:21 (UTC)
- 老实说，目前wikiedu.org已经备有学生和教师的线上训练，但全都是英文版。
- 虽然说保留本地版本的线上训练是没问题的，但小弟粗略看过了一下，还有不少页面有待创建…--飘流书生（见山 · 客栈 · DC20） 2022年12月20日 (二) 15:26 (UTC)
- 看了这些文章我脑子已经晕了……
- 这里以读者看到页面的顺序，介绍一下我的思路，这是一个力求页面数最少的方案，读者在入门之前只需要看WP:关于和WP:参与贡献两个页面。
- 读者应该可以从首页进入WP:关于和WP:参与贡献（或者下面第三点提到的合并后的页面）。手机版主页也应该要有。
- 把WP:参与贡献的内容移动到WP:关于，后者应该包含维基百科简介、邀请加入的广告，顺便求他们捐款。（不过WP:参与贡献的界面做得不错，删了有点可惜）
- 把WP:欢迎和WP:新手入门/主页合并（我觉得WP:参与贡献才是最佳名称）。邀请读者注册账户，同时明显给出中国大陆用户无法编辑和注册的解决方案。此处开始给出求助方法（互助客栈）。第二页WP:新手入门/介绍开始入门。
- 继续往下，新手入门的其他部分不变。H:简介的那一堆按钮可以考虑放到新手入门里。
- 大概这样吧，之后再补充。--HSUZR（留言） 2023年1月2日 (一) 15:39 (UTC)
- 补充一下，我这种方案有两个缺点。一是会使WP:关于文字太多、过于臃肿；二是WP:欢迎起到了分流效果，把人分为可能想加入维基百科的人和普通读者，而这种方案让分流效果没了。如果让WP:关于来分流，它会变得更臃肿。--HSUZR（留言） 2023年1月2日 (一) 15:56 (UTC)
- 个人感觉WP:欢迎和Wikipedia:新手入门/主页都需要存废，但二者在中维确实影响巨大。关于分流，可以将想编辑的转到H:简介，普通读者阅读WP:关于就行。WP:参与贡献和WP:关于倒是改版成英维的形式比较好。--PexEric 💬|📝 2023年1月24日 (二) 07:10 (UTC)
- 感觉WP:参与贡献的东西太多了，而且分页里面还有一堆链接，我都懒得看
囧rz…… ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年2月27日 (一) 18:02 (UTC)
新手编辑疑难支援编辑
不另开新文，话说咱们应另行创建一个供新手询问有关编辑事宜的地方（感觉既有的wp:VPD不太适合）。参考英维，新手大多所问的，均与一些编辑上的疑难有关。
而事实上，英维在其IRC免责声明页上有这样一句：
| “ | Help is provided by volunteers, so it might take a few minutes before someone replies to your question. Try leaving the chat window open for a bit. If you don't get a reply before you need to leave, consider asking your question at the Teahouse instead. | ” |
故此，我们需要在既有站外疑难解答群的基础上，另行创建一个站内版本，为新手编者提供询问疑难的另一渠道。暂时茶馆页面已成雏形，有兴趣可以看看。另可(＆)建议将wp:RD按不同主题分拆，欢迎讨论。—飘流书生（见山 · 客栈 · DC20） 2022年12月19日 (一) 04:25 (UTC)
- 对于茶馆，个人持正面态度，惟担忧加剧叠床架屋之局面；对于知识问答，个人强烈推荐停止使用结构式讨论，此技术非常不利于查询及追溯过往话题。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年12月20日 (二) 13:23 (UTC)
- 天灭结构式讨论，加载起来巨慢，而且还不能查找 ----顺颂时祺 ZhaoFJx（论•编） 2022年12月21日 (三) 14:44 (UTC)
- 那么WP:VPA呢？ ——魔琴 [ 留言 贡献 新手2023计划 ] 2022年12月31日 (六) 06:28 (UTC)
- 标准答案是Wikipedia:互助客栈/求助，然而不太方便。--Temp3600（留言） 2023年1月8日 (日) 15:19 (UTC)
新人小工具配置指南编辑
刚刚突然想到，新人其实欠缺很多常用小工具，必须先学习配置.js，有些实用小工具甚至连资深用户也未必了解。有否可能编制一份新人小工具配置指南?--Temp3600（留言） 2023年1月17日 (二) 11:32 (UTC)
- 这让我想起U:AT/js……啊，好像咕咕了
——魔琴 [ 留言 贡献 新手2023计划 ] 2023年1月17日 (二) 12:37 (UTC)
- @Temp3600：你是指怎样安装小工具的教程还是怎样使用小工具的教程？（虽然我感觉两个教程都能编制一下就是了）Sanmosa Συ γάρ μοι και μοίρα εί και τύχη 2023年1月17日 (二) 12:39 (UTC)
- 我刚刚去翻了一遍自己启用的小工具和用户脚本，实话说，我其实没注意到有小工具对新人而言帮助很大。目前小工具以协助维护工作居多，比如最常用的TW、Rater、HotCat、DisamAssist、HotDefaultSort都是协助维护工作的，对于刚学会编辑的新人而言帮助其实不算很大。--BlackShadowG Slava Ukraini! 2023年1月18日 (三) 11:38 (UTC)
- 先教“如何自动填充cite模版”。--Temp3600（留言） 2023年1月19日 (四) 14:35 (UTC)
- 是指Help:如何引用来源中提到的Wikipedia:参考文献工具列/2.0吗？印象中这个工具好像是默认启用的。--BlackShadowG Slava Ukraini! 2023年1月20日 (五) 04:02 (UTC)
- 新版编辑器更突出自动引用网址功能，我认为应该推荐新手使用。若担心可视化编辑器的一些问题，可使用（2017）源代码编辑器。—— Eric Liu 創造は生命（留言・留名・学生会） 2023年1月24日 (二) 12:25 (UTC)
- 先教“如何自动填充cite模版”。--Temp3600（留言） 2023年1月19日 (四) 14:35 (UTC)
- 总觉得让新手用这些工具不太妥当，有点担心玩火上身或者不慎破坏之类的？像{{cite}}这些模板现在都可以用可视化编辑器来填充，别的工具大部分也是是锦上添花（？）——顺颂时祺 ZhaoFJx（论•编） 2023年1月20日 (五) 15:39 (UTC)
这串又没动静了……我个人建议是整理出来两个页面，其中一个侧重编辑的直接塞在左侧栏里。毕竟就算有14亿+人说中文，中维活跃用户甚至比不上德维的一半……--ときさき くるみ 2023年2月17日 (五) 22:36 (UTC)
- 不知道有多少是被 Wikipedia:IP封禁豁免 挡住的，如果可以在该拦截处能统计一下就好了。--Kethyga（留言） 2023年2月23日 (四) 14:27 (UTC)
本讨论章节会维持开放，暂时不按最后意见发表时间存档，直至集中讨论结束。欲让机器人存档，请移除本模板。留言请置于本模板上方。
提议限制在维基百科使用ChatGPT及类似工具编辑
最近几个月爆火的ChatGPT可以按照人类的提示生成文本，并且能根据人类的意见进行修改。但其生成的文本常常似是而非，看上去没有问题而实际上却含有事实错误，因此如果在条目中大量使用，可能会具有非常恶劣的影响。
StackOverflow已经禁止使用ChatGPT生成的内容，因此，中文维基百科社群是否应该跟进？
可行的方案：
- 完全禁止使用ChatGPT生成的内容编写条目；
- ChatGPT生成的内容须经过人工审阅确认无问题之后才允许出现在条目中。
相关链接：
- Temporary policy: ChatGPT is banned - Meta Stack Overflow
- Should ChatGPT be used to write Wikipedia articles? - Slate
以上。--Diskdance 2023年1月28日 (六) 01:42 (UTC)
- 原则上支持，但不论是禁制还是审阅如何自动分辨为需要审核或禁止？人工难以审核每一个新页面和版本差异确认没有AI编写内容。--路西法人 2023年1月28日 (六) 01:47 (UTC)
- 不认为您的方案可行。ChatGPT等工具并不像Google Translate那样输入和输出总是相同，很容易受到用户的影响，不是能够直接禁止的。社群似乎也不具备人工审核每一笔编辑的能力。若要求使用此类工具的用户主动声明倒是可以，但也定然不是所有用户都会主动声明。同时，用户也可能是生成后自行润色，将其质量提升到可接受的标准后再发布。—— 月_樱_雪 (留言) 2023年1月28日 (六) 01:54 (UTC)
- 1不实际可行，缺乏有效检测手段。2在当前意义不大，条目本应被巡查，没有必要“歧视”。如有滥建、批量创建发生，按寻常规则处理即可，判断是否出自AI及质量如何没有依据。对要求申报表示支持，参考机器人、有偿编辑等方针，但落实存难度会变成君子协定。--YFdyh000（留言） 2023年1月28日 (六) 03:09 (UTC)
- 这是恶意推定，我不知道使用ChatGPT造成何种破坏或者违法哪一方面的规则。--Cat on the Mars 2023年1月28日 (六) 03:56 (UTC)
- 这个时候就得搬出User:0xDeadbeef在英维举出的例子了。以下是使用ChatGPT生成的关于Rust for Linux的条目片段（方便不懂相关领域的编者，部分术语我自己添加了内链）：
Rust for Linux是向Linux内核项目提交的一系列补丁的总称，这一系列补丁让Rust语言可以用于编写内核组件。该项目始于2017年，由一群对将Rust用作系统底层开发感兴趣的志愿者发起。
Rust for Linux is a series of patches to the Linux kernel that adds the Rust programming language as a second language for writing kernel components. The project was started in 2017 by a group of volunteers who were interested in exploring the use of Rust for low-level systems programming.
早先的补丁是与Linux内核维护者以及开源群体一同合作开发而成的。这些补丁聚焦于将Rust的内存安全以及并行特性带入内核当中，同时提供对已有的C语言代码基础的相容性。
The initial patches were developed in collaboration with the Linux kernel maintainers and other members of the open-source community. They focused on integrating Rust's memory safety and concurrent programming features into the kernel, and on providing compatibility with the existing C codebase.
在2018年，这些补丁被合并至Linux内核代码库当中，令Rust成为第一门除C语言之外，获官方支持可以用作编写内核组件的语言。对于Rust语言社群来说是里程碑式的成就，展示了Rust语言可以胜任内核级别编程的需求。
In 2018, the patches were merged into the mainline Linux kernel, making Rust the first programming language other than C to be officially supported for writing kernel components. This marked a significant milestone for the Rust community, as it demonstrated the language's ability to handle the demanding requirements of kernel-level programming.
自Rust语言加入至Linux内核之中起，Rust for Linux项目持续发展，当前聚焦于改善Rust在内核中运作的兼容性以及效率。该项目还吸引了其他操作系统开发者的注意力，令他们对将Rust语言用作内核级别编程所带来的潜在优点感兴趣。
Since its inclusion in the Linux kernel, the Rust for Linux project has continued to evolve, with ongoing work on improving the compatibility and performance of Rust in the kernel. It has also attracted the attention of other operating system developers, who are interested in exploring the potential benefits of using Rust for kernel-level programming.
- 我就问一句，这么有模有样的段落你能发现这里面捏造了好几个关键事实吗？你们还觉得这不会造成破坏吗？ --MilkyDefer 2023年1月28日 (六) 09:12 (UTC)
- 注：我自己能注意到的捏造事实如下
- Rust for Linux项目起始于2020年，不是片段中宣称的2017年；
- Rust for Linux项目代码合并至Linux内核是在2022年，不是片段中宣称的2018年；
- 当前Rust for Linux还没有达到有闲心改善兼容性和效率的地步，当前只有最基础能让编译顺利通过的部分。
- 有这么方便的工具那些喜欢搞鬼祟破坏的LTA们简直笑开花了啊。 --MilkyDefer 2023年1月28日 (六) 09:16 (UTC)
- 我认为鉴于ChatGPT的现状，应该将它按对待人类新手的方式处理，事实上就内容而言我们也无法区分新手和机器人之间的区别，何况你站已经封禁了绝大多数代理网段，仅仅凭借实验内容无法证实其破坏性或者真的有人会用来破坏，加上理论上ChatGPT还在使用旧的数据集，分辨拙劣过时内容远远比分辨是否是高级AI作品更加具备可行性也更加重要，暂时没有必要就这件事因“人”立法，如果需要修改方针必须证明现有方针在哪一方面无法满足你的需求（包括劣质训练集，还不如去改进你站存废积压）。--Cat on the Mars 2023年1月28日 (六) 09:38 (UTC)
- 再新手也不会写出金玉其外败絮其中的内容，真正的新手是写出来读出来就像是新手。你说的这不是新手，是破坏者。--MilkyDefer 2023年1月28日 (六) 09:44 (UTC)
- 你维的毛某人浪迹天涯多少年了，这种抓不出来其他更是抓不到，你维有长过记性了吗，我说过不要因人立法，不是因为一会儿折毛，一会儿ChatGPT，封个把人就能解决的事情，ChatGPT就我的实际体验还不具备单独作案的能力，我刚刚想要让他搞点引用都得费神很久，像这么一大段无来源内容理所应当就是劣质内容，巡查员应该有自己的判断。----Cat on the Mars 2023年1月28日 (六) 10:01 (UTC)
- 本人基本同意CatOnMars的观点。--0xDeadbeef（留言） 2023年1月28日 (六) 10:17 (UTC)
- 至少举例中如果缺少来源（或者来源能通过编辑者审阅并确认过的话），还是能区分出行文问题。需要注意但不至于需要规例。——Sakamotosan路过围观 | 避免做作，免敬 2023年1月29日 (日) 00:41 (UTC)
- 你维的毛某人浪迹天涯多少年了，这种抓不出来其他更是抓不到，你维有长过记性了吗，我说过不要因人立法，不是因为一会儿折毛，一会儿ChatGPT，封个把人就能解决的事情，ChatGPT就我的实际体验还不具备单独作案的能力，我刚刚想要让他搞点引用都得费神很久，像这么一大段无来源内容理所应当就是劣质内容，巡查员应该有自己的判断。----Cat on the Mars 2023年1月28日 (六) 10:01 (UTC)
- 再新手也不会写出金玉其外败絮其中的内容，真正的新手是写出来读出来就像是新手。你说的这不是新手，是破坏者。--MilkyDefer 2023年1月28日 (六) 09:44 (UTC)
- (！)意见 我认为把可供查证做好就能避免大部分问题。--Taeas（留言） 2023年1月28日 (六) 12:10 (UTC)
- 提问：ChatGPT是否会造成目前方针无法处理的破坏？如果有，是否说明目前的方针存在漏洞？--Steven Sun（留言） 2023年1月29日 (日) 03:44 (UTC)
- (＋)支持，MilkyDefer给出的例子已经很明显了，用于破坏实在是太过简单。--BlackShadowG Slava Ukraini! 2023年1月29日 (日) 04:27 (UTC)
- 支持禁止，列入行为方针即可。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年1月29日 (日) 04:32 (UTC)
- 我是持怀疑态度。首先是无法检测、无法证明。任何一段文字，就算GPT检测器说是GPT写的，你无法看到那个人把这段文字从GPT复制下来贴上了。第二，ChatGPT用法多种多样，不应该所有用法都不能用。我特别喜欢叫他帮我找错别字，和从其他语言翻译成中文。应该还有很多无破坏性的例子。Last but not least，现有规则已经可以cover ChatGPT造成的破坏。难道现在加一条说ChatGPT做好事也不行？--Gqqnb（留言） 2023年1月29日 (日) 13:01 (UTC)
- 我倒是有点想开了，维基百科又不是检查你们做大学作业，有些学校会怀疑是不是你自己写的，你只要写出来了，巡查员检查过了，我管你是怎么写的。我不明白有些人的逻辑，只要这种东西能够用来破坏，“很容易用来破坏”，那这种东西就一定要禁止，是不是你家做菜以后都不要拿刀了。且不论枪支弹药的道德属性，枪支弹药尚且可以用在正道，炸药都可以弄出个诺贝尔奖，你维连ChatGPT的影子都没有看到，便十分“有头有尾”有罪推定宣判ChatGPT死刑，似乎认定了默认利用AI的都是坏人一样，每个人在你维用一次ChatGPT就好像从你维的大厦下面偷一块砖，连基本的“假定善意”都丢掉了。借用鲁迅的一句话，“岂但乡下人之于雷峰塔，日日偷挖中华民国的柱石的奴才们，现在正不知有多少”，而这等这种视若无睹的理所应当更是令我更是匪夷所思。----Cat on the Mars 2023年1月29日 (日) 13:26 (UTC)
- 感觉类似机翻：内容提交人自己知道润色就OK；当然对初次参与维基百科的人，最保守的说法还是“禁止机翻”。--洛普利宁 2023年1月29日 (日) 13:31 (UTC)
- 我倒是有点想开了，维基百科又不是检查你们做大学作业，有些学校会怀疑是不是你自己写的，你只要写出来了，巡查员检查过了，我管你是怎么写的。我不明白有些人的逻辑，只要这种东西能够用来破坏，“很容易用来破坏”，那这种东西就一定要禁止，是不是你家做菜以后都不要拿刀了。且不论枪支弹药的道德属性，枪支弹药尚且可以用在正道，炸药都可以弄出个诺贝尔奖，你维连ChatGPT的影子都没有看到，便十分“有头有尾”有罪推定宣判ChatGPT死刑，似乎认定了默认利用AI的都是坏人一样，每个人在你维用一次ChatGPT就好像从你维的大厦下面偷一块砖，连基本的“假定善意”都丢掉了。借用鲁迅的一句话，“岂但乡下人之于雷峰塔，日日偷挖中华民国的柱石的奴才们，现在正不知有多少”，而这等这种视若无睹的理所应当更是令我更是匪夷所思。----Cat on the Mars 2023年1月29日 (日) 13:26 (UTC)
- 翻译指引有一句“请勿使用机器翻译翻译条目”，在后面加一个“或人工智能机器人”之类的，赋予禁止使用相关工具之许可法源就行了。—— Eric Liu 創造は生命（留言・留名・学生会） 2023年1月29日 (日) 14:21 (UTC)
- 但提案不限于翻译，也包含创作。不过，如果创作后能做到可供查证，感觉没太大问题。--YFdyh000（留言） 2023年1月29日 (日) 14:38 (UTC)
- “机器人方针适用于所有用以编辑维基百科的计算机程序或脚本，包括全自动、高速运作以及协助编者的工具。”
- 按我的理解，现行机器人方针完全适用于AI程序，要改也轮不到翻译指引。----Cat on the Mars 2023年1月30日 (一) 09:23 (UTC)
- 确实，一时间没有想到。不过两边都写亦无大碍，或可相呼应。—— Eric Liu 創造は生命（留言・留名・学生会） 2023年1月31日 (二) 03:06 (UTC)
- 我们来关注这么一个问题。对于一个编辑经验不足的新编者而言，创建条目时候的提示信息都有哪些呢？关注度、非广告宣传、著作权、参考文献、WP:NOT，以及一个指向“其他”的链接。不论是机翻还是ChatGPT都没有足够可见的提示。巡查员一看，不行，从犄角旮旯里翻出一个方针的一个犄角旮旯的句子出来，新手直接炸毛了。--MilkyDefer 2023年2月3日 (五) 13:37 (UTC)
- 你应该去改F&Q而不是去改方针，现在的方针指引堪比屎山代码，我觉得与其改机器人方针内容，还不如改名字一目了然，以前叫他机器人，其实只是自动化程序，以后必然还会有AI程序，它这名字早就已经赶不上时代了。----Cat on the Mars 2023年2月3日 (五) 15:45 (UTC)
- 方针指引太多搞得管理员都不知道自己正在重复立法。----Cat on the Mars 2023年2月3日 (五) 15:51 (UTC)
- 我们来关注这么一个问题。对于一个编辑经验不足的新编者而言，创建条目时候的提示信息都有哪些呢？关注度、非广告宣传、著作权、参考文献、WP:NOT，以及一个指向“其他”的链接。不论是机翻还是ChatGPT都没有足够可见的提示。巡查员一看，不行，从犄角旮旯里翻出一个方针的一个犄角旮旯的句子出来，新手直接炸毛了。--MilkyDefer 2023年2月3日 (五) 13:37 (UTC)
- 确实，一时间没有想到。不过两边都写亦无大碍，或可相呼应。—— Eric Liu 創造は生命（留言・留名・学生会） 2023年1月31日 (二) 03:06 (UTC)
- 我的意见本来与Ericliu1912相近的，但考虑到YFdyh000所言在理，我更倾向要求任何人确保他们在用AI写东西后必须先自己校对过才在维基百科发布，毕竟相关工具我自己感觉不是完全不能用，但一定要自己下手调整AI写出来的文本，这跟维基百科内置的机翻工具是一个道理。@YFdyh000、Ericliu1912：如果“似是而非”的文本符合“胡言乱语”的定义的话，这其实就是G1的范畴。Sanmosa Συ γάρ μοι και μοίρα εί και τύχη 2023年1月30日 (一) 05:05 (UTC)
- @Ericliu1912、shizhao：我想要请教管理员，如果我要在机器人方针第一句“机器人方针适用于所有用以编辑维基百科的计算机程序或脚本，包括全自动、高速运作以及协助编者的工具”“包括”后面加上一句“利用人工智能（AI）技术编辑维基百科的程序”，这是否超出了“修改方针及指引的文意”的小修改门槛。按照我的理解，机器人AI程序应该是在机器人方针“所有用以编辑维基百科的计算机程序或脚本”的范畴内。另外，从我的角度，防不如管，如果能够知道别人在使用AI总比盲盒瞎猜好很多。--Cat on the Mars 2023年2月4日 (六) 11:25 (UTC)
- (－)反对与其禁止使用AI生成内容，应该规定的是不是使用AI辅助后应先行复检后再发布？AI跟机器翻译一样，可以视为一个辅助手段，但不应该作为主要贡献。所谓的“似是而非”、“事实错误”全部现有方针已可处理。如果AI生成的内容可以被来源证实，我实在看不出一刀切禁止使用的原因-某人✉ 2023年2月6日 (一) 14:29 (UTC)
- 咕咕--Zyksnowy（留言） 2023年2月8日 (三) 09:14 (UTC)
- (－)反对:Some people against using you in Wikipedia. How can I refute?
Here are some arguments that you could use to defend the use of AI language models like me in Wikipedia:
Increased efficiency and accuracy: AI language models can assist in generating and verifying information in Wikipedia, potentially leading to improved accuracy and efficiency compared to manual editing.
Supplementing human labor: AI language models can help to supplement the work of human editors and writers, freeing up their time and energy to focus on more complex and strategic tasks.
Improving accessibility: AI language models can assist in generating and translating content, making Wikipedia more accessible to a wider audience and supporting the goal of creating a free and comprehensive encyclopedia.
Cost-effectiveness: Using AI language models can help to reduce the cost of creating and maintaining Wikipedia, making it more sustainable in the long-term.
Of course, it's also important to consider potential concerns and criticisms related to the use of AI in Wikipedia, such as the potential for biases in the training data and the importance of maintaining human oversight and control. Nevertheless, with proper safeguards and transparency, AI language models like me can be a valuable tool for supporting and improving Wikipedia.--維基小霸王（留言） 2023年2月9日 (四) 04:12 (UTC)
- @MilkyDefer：这是使用ChatGPT生成的关于入间同学入魔了！的片段（使用“谈谈"入间同学入魔了!"这部动画”去生成）：
《入间同学入魔了!》是一部日本的动画，是由小畑健制作的一部歌舞片。这部动画以魔法为题材，讲述了主人公入间在升上高中后，逐渐接触到魔法世界，最终投身于魔法战争的故事。 这部动画以精彩的故事情节和生动的角色设计而受到许多观众的喜爱。它还以鲜明的风格和丰富多彩的音乐展示了魔法世界的魅力，为观众带来了一个充满奇幻与冒险的世界。 如果你是一个喜爱动画的观众，那么这部动画是值得一看的。它将带给你一个精彩的故事情节和生动的角色，让你进入一个充满魔法与冒险的世界。
- ，但入间同学入魔了！实际上是由西修所创作的日本漫画作品，且实际上小畑健曾经创作过《棋魂》，不是《入间同学入魔了！》，所以ChatGPT所生成的日本动漫类条目就有问题--林勇智 2023年2月9日 (四) 12:26 (UTC)
- 尝试限定维基百科的风格，并要求给出至少五个不是维基百科自身的公开可查证来源呢？--MilkyDefer 2023年2月9日 (四) 12:55 (UTC)
- 它以前给过我一本陈景润的《中国哲学史》。----Cat on Mars 2023年2月9日 (四) 12:58 (UTC)
- 所以我在看到U:outlookxp的查证的时候就觉得这是不是什么我们不知道、并且还在保密中的高级AI。----Cat on Mars 2023年2月9日 (四) 13:02 (UTC)
- ChatGPT有点蠢，机翻都比它靠谱点。--日期20220626（留言） 2023年2月9日 (四) 13:09 (UTC)
- 用它机翻还是比较好用的。----Cat on Mars 2023年2月9日 (四) 13:24 (UTC)
- 大概是题外，看到提起维基内建机翻以及用机翻后要校正的内容等等的、那个啊今天凌晨逛最近更改的时候发现了不列颠共产党，有兴趣看哪位用户新增的请查看编辑摘要以及贡献，该用户共新增了三个条目，因为实在是没心力了所以只有挂了模板，看看此人会不会良心现前自己回来改，不改的话之后就删除，个人感想是遇过几次用机翻的用户，原则上大概也不知道自己开了什么箱，只是翻译出来的结果乍看满意好像吐出了象牙，奢望他们自己配备校对能力可能真的以为人本善良。--Mafalda4144（留言） 2023年2月9日 (四) 13:37 (UTC)
- 我尝试了一下改善翻译，然而并没有什么用处--Cat on Mars 2023年2月9日 (四) 14:17 (UTC)
- 这玩意据方舟子测试，简中资料来源自称是用百毒的样子。不过其他人有不同的结果。--S叔 2023年2月10日 (五) 02:19 (UTC)
- 尝试限定维基百科的风格，并要求给出至少五个不是维基百科自身的公开可查证来源呢？--MilkyDefer 2023年2月9日 (四) 12:55 (UTC)
- 显然ChatGPT自身生成的内容并不能作为证明其无害的依据。--Diskdance 2023年2月9日 (四) 15:04 (UTC)
- 好像有人测试医学类条目，ChatGPT会自己编造PubMed参考文献。另外不知道其在翻译条目中是否也会编造内容。关于其翻译质量，腾讯的一个实验室最近在arXiv上发了一篇论文[1]。建议先行禁止。--Kethyga（留言） 2023年2月10日 (五) 12:41 (UTC)
- (＋)支持明文禁止。——WMLO（留言）。 2023年2月10日 (五) 21:43 (UTC)
- @MilkyDefer：咱也模仿上面D2513850君使用《来自风平浪静的明天》生成的对话内容：（Q：谈谈《来自风平浪静的明天》这部动画）
《来自风平浪静的明天》（Your Name）是一部由新海诚执导的日本动画电影，于2016年在日本上映。该片以美妙的动画和复杂的人物关系角色，受到了广泛的好评。
故事讲述了两个生活在不同城市的高中生，偶然发现自己的身体可以穿越时空互换。随着故事的发展，他们不断努力寻找对方，以解决自己的身份困惑和生活困境。
该片的动画效果非常出色，景象壮丽，配乐优美。此外，它也提出了一些深刻的社会问题，如家庭、友情、爱情和对未来的希望，对观众产生了深远的影响。
总的来说，《来自风平浪静的明天》是一部非常优秀的动画片，值得每个动漫爱好者去观看。
感觉完全是按照《你的名字。》的内容去生成的
囧rz……--忒有钱🌊塩水あります🐳（留言） 2023年2月12日 (日) 19:58 (UTC)
- (－)反对：所有机器人辅助的编辑应该予以允许，但人类用户必须在发布前核对内容。--The Streif（留言） 2023年2月13日 (一) 04:21 (UTC)
- @忒有钱：建议在发布到维基百科前先检查chatGPT所生成的内容是否有问题（如事先阅读或观看内容（例如《入间同学入魔了！》漫画或PubMed文献））--林勇智 2023年2月14日 (二) 13:40 (UTC)
- 我也试了一下，看起来效果不佳，因为他生成的内容很容易有编造和过度联想的状况，少至生成的内容真伪查核困难。我的测试事先给ChatGPT阅读相关文章，再请他整理成维基百科条目：请阅读下列文章并将其整理成一篇中文维基百科条目，并且使用wikitext源代码编写条目，须包含内部链接和信息框。（贴上wikia:w:c:danmachi:Wiene的全部内容）
- ChatGPT给了以下回答（内部链接和信息框是ChatGPT加的，我一字未改）
- 以下是使用 wikitext 源代码编写的薇妮的中文维基百科条目：
- ChatGPT给了以下回答（内部链接和信息框是ChatGPT加的，我一字未改）
薇妮 虚构设定信息 物种 人鳞蛇 性别 女性 出生 地牢中层 所属 赫斯提亚家族 薇妮（ウィーネ）是一位神秘的人鳞蛇女性，生于地牢的中层。她以其琥珀色的眼睛和长银蓝色的头发以及身体上数个地方的鳞片而闻名，还有额头上价值高昂的“人鳞蛇之泪”红宝石。
在留在赫斯提亚家族期间，薇妮穿着由贝尔·克拉内尔提供的“沙马兰德毛衣”，以隐藏她作为怪物的身份。
薇妮有讲话的能力，这在怪物中是很罕见的，她以善良的性格而闻名。她与赫斯提亚家族特别是贝尔和春姬产生了依恋。尽管她有善良的性格，薇妮最初有着怯弱的本质，但在她重生后，她变得更加勇敢。
在外貌上，当薇妮救了一个小男孩时，她的身体从背部长出了一只翅膀，翅膀很大，即使折叠也可以覆盖她一半的身体。
- 当中不少过度联想，例如Infobox 内的所属：赫斯提亚家族（应为赫斯缇雅眷族，但不是重点），薇妮并不属于赫斯缇雅眷族，他只是暂时借住在赫斯缇雅眷族，表示ChatGPT过度联想，造成其产生若干与事实不符的内容，且这若不对主题有一定程度的了解，是不可能发现的错误，因为似是而非，据我所知，有些编者喜欢透过编写不是那么熟悉的主题来增广知识，万一那些编者因此无法抓出ChatGPT编造和过度联想的状况造成编辑的内容出现似是而非的内容该怎么查核？编者可能因为用了ChatGPT而导致在条目加入了似是而非错误内容而不知情，且也难以查核，如果是这样，不如直接禁止ChatGPT生成内容为好。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年2月14日 (二) 14:00 (UTC)
- (！)意见：相较ChatGPT定位于“聊天机器人”，近期Google推出的Bard或是微软的全新Bing更像是一个“搜索助理”，可以即时搜索并更新最新的消息，以全新Bing为例，在回答的时候会给出多项参考网站来源（可参考这篇评测文章：[2]。）ChatGPT本身是一个模型，拿来训练的数据库是固定的（所以才说只能回答2021年前的问题），生成的内容常在相似的语句打转。但这类新的人工智能搜索助理，我认为值得期待，对维基百科的编者也会有很大帮助。巴波（留言） 2023年2月16日 (四) 12:55 (UTC)
- (！)意见：我看得都很尴尬，一个个光光讨论ChatGPT的性能问题，明明已经有相关规定（机器人方针）了却没有实施方法，AI模型本来就是一个很大范围的事情，我记得站内好像就有人用类似工具创建条目，是不是.Net之类的，有一个谁专门用什么程序修正错误之类的，后来基本都是被封了。我觉得这种事情实际上就是一种钻空子，管理员应该要求使用AI及类似辅助程序的必须事先声明并经过测试才能开车上路，ChatGPT只是我们的第一个例子，看上去并不适合上街乱跑，但是也要考虑到以后还会有很多智能程序的例子在后面，我们的方针应该有长远考虑的打算。--Cat on Mars 2023年2月16日 (四) 20:04 (UTC)
- 可参考en:WP:LLM和en:WP:ChatGPT--百無一用是書生 (☎) 2023年2月21日 (二) 01:59 (UTC)
- 思考了一下，虽然AI问题很多，但或许可以参考维基媒体基金会台湾分会的这则贴文的说法，仅限资深用户使用，并且要严密检查？-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年3月1日 (三) 17:53 (UTC)
刚刚测试感受了一下：一个样例--EvesiestaCOVID-19感染中 2023年3月5日 (日) 08:32 (UTC)
如果维基百科现有的技术无法侦测到对方使用ChatGPT或类似AI工具的生成内容，那么楼上各位所说也只是空话，更何况出自人手造假的（例如：折毛事件），你们也是经过很多年之后才发现，这就是活生生的警惕。因此，如果在没有技术可以避免下，未来可能仍会有造假内容发生，这是现在维基百科的公信力最大的问题。--2001:B011:A401:3B94:3825:963C:D5D8:1D8（留言） 2023年3月8日 (三) 05:05 (UTC)
- (－)反对：条目破坏与手动破坏或使用AI破坏似乎在结果上没有差异？难不成用键盘输入文字破坏条目，就要禁止所有使用键盘输入的条目？更何况如前些留言者所言，人手造假的抓不到了，更何况AI生成。还不如想想用AI巡查条目，先处理明显错误的条目。--死灰（留言） 2023年3月13日 (一) 14:13 (UTC)
- 可以考虑开发一个AI检测器。。。--百無一用是書生 (☎) 2023年3月14日 (二) 02:42 (UTC)
- Open ai自己写的检测器都只有两成六几率检测得出来，还未计假阳性。如果这里有任何人写得一个出来就别在维基百科屈才当志工了--某人✉ 2023年3月19日 (日) 11:50 (UTC)
- 这话说得，能写出来照样可以来维基混。比如亚伦·斯沃茨这家伙就很积极参与维基事务。--日期20220626（留言） 2023年3月19日 (日) 11:55 (UTC)
- Open ai自己写的检测器都只有两成六几率检测得出来，还未计假阳性。如果这里有任何人写得一个出来就别在维基百科屈才当志工了--某人✉ 2023年3月19日 (日) 11:50 (UTC)
- 在处理条目格式问题与修饰语气上能派上用场，唯一的困扰仅幻觉问题。--死灰（留言） 2023年3月26日 (日) 11:14 (UTC)
- 可以考虑开发一个AI检测器。。。--百無一用是書生 (☎) 2023年3月14日 (二) 02:42 (UTC)
- (－)反对：看过老高的影片后，我觉得他讲的好，AI就是一种工具，不应该怕她。如果你直接叫AI写一篇条目，就会很多错，但如果你给他一篇文章请他归纳重点，错误会少很多，总之我觉得善用gpt写条目是一件好事，可以节省很多时间，但不要乱用，如果乱用就直接速删就可以，正常使用gpt并不用禁止。--E.D.（留言） 2023年3月16日 (四) 07:29 (UTC)
- (－)反对：2023年了，怎么还在“非我也，兵也”呢？噗噗熊？|||||||||| 维尼熊！ 2023年3月20日 (一) 14:21 (UTC)
- (－)反对：其实AI在翻译条目中做的十分不错，虽然文字在有些情况下需要修改以保证通顺而且有点单调，至于创建条目来讲(＋)暂时支持禁止使用，因为在不提供信息很容易出错（例如将日期填写错误以及出现大量虚构内容），搞不好出现折毛2.0。不过值得肯定的是它翻译条目的能力和对于语句问题的通顺化，不建议直接猛烈一刀切，应该看作是一种工具，反正多时无著作权的。附注一小段由ChatGPT的翻译草稿，可以研究一下它的质量。
- --FK8437（留言） 2023年3月25日 (六) 03:41 (UTC)
- FYI：较早前基金会与部分全域社群成员就 AI 对维基百科的影响及机遇等进行讨论（讨论摘要见此），个人期望对此讨论有所帮助。谢谢。--SCP-0000（留言） 2023年3月25日 (六) 09:03 (UTC)
- 再次重申：在有任何能可靠辨识AI生成内容的检测器问世之前你维任何规范ChatGPT的讨论均为伪命题。所有所谓“伪造文献”等问题可依现有方针处理，下方类似讨论同上-某人✉ 2023年3月27日 (一) 20:20 (UTC)
提示语构建：
你是一个AI生成内容检测器，我输入文本内容，你来检查是否是AI生成的，还是人类撰写的。并给出答案和检查过程。检测内容不要输出。格式为：
结果：{AI或人类}
检查过程：{检查过程}
检测内容“<这里填入要检测的文本>”
用这个提示词对上面“《入间同学入魔了!》”的文本进行检测，结果如下：
结果：{AI}
检查过程：这段文本中有很多日本的动画和电影的常见元素，例如魔法、高中生活、战争等。此外，这段文本的语言流畅度和表达方式比较机械化，缺乏人类的情感和思考。最后，这段文本的结构和内容比较简单，缺乏深度和复杂性。综上所述，这段文本是由AI生成的。
对薇妮的检测：
结果：{AI}
检查过程：这段文本中有很多日本动画和小说的常见元素，例如人鱼、魔法、怪物等。此外，这段文本的语言流畅度和表达方式比较机械化，缺乏人类的情感和思考。最后，这段文本的结构和内容比较简单，缺乏深度和复杂性。综上所述，这段文本是由AI生成的。
对“来自风平浪静的明天”检测错误
结果：{人类}
检查过程：这段文本是关于《来自风平浪静的明天》这部日本动画电影的介绍，内容涉及到电影的情节、人物、动画效果、配乐和社会问题等方面。语言表达流畅，情感丰富，没有明显的机械化或重复的痕迹。综上所述，这段文本是由人类撰写的。
对Rust for Linux（英文）的检测也是错误的：
结果：{人类}
检查过程：这段文本是关于Rust for Linux项目的介绍，内容比较专业化，涉及到Linux内核和Rust语言的相关知识。语言表达流畅，结构清晰，没有明显的机械化或重复的痕迹。综上所述，这段文本是由人类撰写的。
总体上感觉不如一些第三方的检测工具，例如[3],但也不失为一种方法。如果要做维基百科内容的AI检测，目前最好的方法是介入多家的AI检测技术，综合对比比较稳妥--百無一用是書生 (☎) 2023年3月28日 (二) 09:05 (UTC)
参考资料
- ^ Jiao, Wenxiang; Wang, Wenxuan; Huang, Jen-tse; Wang, Xing; Tu, Zhaopeng, Is ChatGPT A Good Translator? A Preliminary Study, arXiv, 2023-01-31 [2023-02-11], doi:10.48550/arXiv.2301.08745
连接号一字线的符号选择编辑
提议：当前MOS:连接号一字线的符号选择"U+FF0D － FULLWIDTH HYPHEN-MINUS"不是通行的做法。改用 U+2014 — EM DASH 是更好的选择。
之前已经有多次讨论，大部分编辑表示支持，但都没有继续推进：
- Wikipedia_talk:格式手册/标点符号/存档1#抛弃全角连字符（U+FF0D），改用em_dash（U+2014）字符表示“一字线”连接号
- Wikipedia_talk:格式手册/标点符号/存档2#又议格式手册标点符号中的连接号
- Wikipedia_talk:格式手册/标点符号/存档2#连接号字符
总结起来：
- U+FF0D － FULLWIDTH HYPHEN-MINUS是短横线 U+002D - HYPHEN-MINUS的全形版本，二者应该表达相同的含义，不应重复使用。既然短横线已经选择了 U+002D - ，一字线就应该选用其他字符。
- 使用 em dash 对字体渲染有更好的支持。
- 使用 em dash 作为连接号是中文印刷品中的主流选择。
- 全角连字符U+FF0D － 从未被广泛使用过。（除了中文维基百科）
- 多数中文字体对全角连字符的支持并不理想。
- 一字线应当恰好占据一个字符（即一个 em 长度）。
- 一字线应当恰好是破折号的一半。
因此建议推荐使用 U+2014 — EM DASH 作为一字线的符号，不再把 U+FF0D － FULLWIDTH HYPHEN-MINUS 作为推荐的符号，但也并不将其列为错误用法。
|
|
--InstantNull（留言） 2023年2月8日 (三) 20:15 (UTC)
- 不认同字符选择与表达含义间存在关联
- 在默认及常见字体中未见明显证据
- 部分承认（即便在正规印刷品中，002d也有一定使用，虽然可能是误用）
- 承认
- 在默认及常见字体中未见明显证据
- 在微软雅黑中2014略长于em，反之ff0d未见问题
- 未见可靠出处
- 综上反对提案。--。->>Vocal&Guitar->>留言 2023年2月9日 (四) 02:54 (UTC)
- 不认同您对 (1) 的意见，Unicode符号本身是具有语义的，形似而不同义的字符都会进行分离，不应混用。en:hyphen和en:dash的用法是不同的；
- 连接号用
U+2014是有权威出处的，如台教标在线网页《重订标点符号手册》修订版。大陆的GB/T 15834-2011虽然公开的是扫描件，不能确定码位，但也明显更像U+2014而不是U+ff0d。
- --DvXg 📬 2023年2月9日 (四) 06:55 (UTC)
- 关于（1）我想不应该有疑问。正如David Xuang所说，Unicode对于每一个字符都有明确的定义。U+FF0D － 是 U+002D - 的全形版本（您可以参考全形和半形了解更多），它们本质上是同一符号的不同字符表示，在中文里同时混用是不恰当的。就如同我们不应该在中文里同时使用半形“/”和全形“／”是一个道理。
- 关于（2）可以请您参考右侧的截图，U+FF0D － 在 macOS Chrome 浏览器中的显示效果。在正文中的是无衬线字体，在标题中的是有衬线字体，二者差异很大，标题中有衬线的字体显示效果非常不理想。
- 关于（6），我指一个字符宽即一个em 单位，参见Em (字体排印学)。
- 关于（7）我想多做一点解释。在英文中 en dash 和 em dash 的关系就类似于中文里的连接号与破折号之间的关系一样。传统上 en dash 的长度就是 em dash 的一半。类似的，中文里破折号既然已经广泛接受用两个em dash “——”表示，那么连接号用一个 em dash 才是符合惯例的。
- --InstantNull（留言） 2023年2月9日 (四) 18:37 (UTC)
- 1. 我关心的是中维常年使用ff0d，现状是否对文章内容的表达产生了歧义？字符的定义在这里并没有特别强调的必要。即便如
法兰克福—巴黎变为法兰克福-巴黎也不会产生另一种意义。 - 2. 我注意到这张截图是2018年，不清楚目前是否仍然有效，我持有的设备（Windows，Android，Ubuntu）上没有发现类似问题。我希望您能多举例以证实“多数中文字体支持不理想”的主张。
- 6. 建议实测。
- 7. 您个人的意见我无法评论。另我认同国标推中使用2014，但不认同维基百科需要调整。--。->>Vocal&Guitar->>留言 2023年2月10日 (五) 03:54 (UTC)
- 可否将您的意见理解为"将错就错"?再比如,我在这行句子中,全部错误地使用了半形标点.但这其实丝毫不影响您理解这段话的意思对吗?
- 常年使用不是一个合理的理由。本人实际上是推动将MOS:标点符号升格为指引的发起者之一，当时连接号码位选择并没有经过讨论，该错误一直遗留至今。中文维基在发展中必然会遇到需要标准化的需要。方便编辑输入和方便读者阅读、检索是必要的现实需求。甚至有一些读者会将维基百科的格式奉为标准，因此我们有义务提供准确的信息。再者我也提到，新指引只是不再把 U+FF0D 作为推荐的符号，不妨碍兼容已有的使用。
- 截图中的问题仍然存在。之前提到 U+FF0D 从未被广泛使用过，因此有部分中文字体对 U+FF0D 做了专门的字形设计而另一些没有，使得其在实际的主流字体中没有一致的外观。和您提到微软雅黑的问题一样，这是一个字形（glyph）设计概念。这篇文章中有提到，旧版微软雅黑的标点是过时的且不符合国标。这篇文章介绍了相关背景：“但绝大多数中文字体甚至一些西文字体对 U+2014“—”（Em Dash）的显示效果比西文标点 Em Dash 应有的宽度宽一些，基本符合一字线的形式要求。”
- 以上内容并非个人观点，我已提供了一些资料供您参考，这基本上是中文字体排版的共识。W3C中文支持文档明确写道：“《标点符号用法》（GB/T 15834—2011）中没有指定这三个符号的码位，但是基本上可以推断一字线是U+2014 EM DASH [—]”。--InstantNull（留言） 2023年2月10日 (五) 07:56 (UTC)
- 如果现在版本macos依然在em dash后面贸然加这么“长空格”的话，我不排除主动联系苹果官方解决该问题，话说这问题该怎么报告？--Liuxinyu970226（留言） 2023年3月21日 (二) 04:22 (UTC)
- 1. 我关心的是中维常年使用ff0d，现状是否对文章内容的表达产生了歧义？字符的定义在这里并没有特别强调的必要。即便如
- ( π )题外话：无论一字线用什么符号，美国－墨西哥－加拿大协议按MOS:连接号指引应该用短横线，应移动到“美国-墨西哥-加拿大协议”。——小林子冲（留言） 2023年2月20日 (一) 20:17 (UTC)
- 我个人亦希望能够规范连接号之使用。不过必须提醒，根据统计，目前本站至少有三千余篇条目及其他三千余个页面之标题含有“－”（另有四千余个重定向，总计一万出头），更不用提内文了；因此，若要更改连接号标准，应考虑动用机器人进行移动。—— Eric Liu 創造は生命（留言・留名・学生会） 2023年2月10日 (五) 08:32 (UTC)
- (＋)支持提案。中文维基百科选用U+FF0D作为连接号是奇怪的事情，既不符合任何规范又不便于输入。--Lt2818（留言） 2023年2月10日 (五) 14:06 (UTC)
- 囧rz……“一字线可以通过中文输入法输入破折号并删去一半得到”？我想说Windows10的仓颉输入法并没有这个功能。--街燈電箱150號 开箱维修 抄表 检验证明 2023年2月10日 (五) 14:22 (UTC)
- 仓颉输入法“ZXAY”会得出一个 Em dash. 谢谢提醒，我已对修订条文做了改动。--InstantNull（留言） 2023年2月10日 (五) 17:44 (UTC)
- 原则上支持。但我的担心是，如果只是推荐使用U+2014，而不将U+FF0D视为错误，那会造成两者同时存在的混乱局面，还有可能导致一些编辑争议出现。但另一方面，如果要禁止U+FF0D，那修正目前条目中现有的大量U+FF0D感觉是一项不小的工程。当然可以用机器人处理，但也需要注意不应误伤，比如参考文献的标题如果原本用的就是U+FF0D的话我想不应该去修正？还有一些有关Unicode、字体排版等条目中也有确需使用U+FF0D的情况。--Stevenliuyi（留言） 2023年2月11日 (六) 18:45 (UTC)
- 为了避免新旧共存引发混乱，我个人建议对现有页面进行一次集中批量移动。至于正文，可能需要研发小工具专门更改连接号，加快速度。参考资料的话更是一团乱，可能有本来就用这符号的，也可能有后来被改的，没有办法用机器人处理，只能比照正文，并研发小工具加速更改。—— Eric Liu 創造は生命（留言・留名・学生会） 2023年2月12日 (日) 07:05 (UTC)
- Wikipedia:格式手册/标点符号是不适用于参考文献的哈。--InstantNull（留言） 2023年2月13日 (一) 01:25 (UTC)
- (？)疑问：有没有办法追踪有人有意或者无意地使用汉字“一”（壹）代替连接号“—”（U+2014），有些系统中汉字“一”和连接号肉眼区分不出来。快捷输入的问题，个人的方法是不少输入法（包括PC、手机）会提供自定义短语，比如设置成“一字线”的拼音或者其他码表，快捷输入应该问题不大。--Kethyga（留言） 2023年2月15日 (三) 11:17 (UTC)
- 在本人手机上U+FF0D的显示效果比PC网页上号。--Kethyga（留言） 2023年3月2日 (四) 06:20 (UTC)
- 它之所以叫“一字线”是有原因的哈哈。甚至可以说这是U+FF0D“－”的另一个问题：它太短了，和短横线太像而太不像“一”字了。故意用相近字形的字符替换不是 em dash 所特有的问题，正如同我们没有办法故意检测有人故意用数字0去替换字母O一样。在很多软件里也有自动替换功能，比如在Word里输入“--”会被自动替换成em dash--InstantNull（留言） 2023年2月16日 (四) 05:56 (UTC)
- (＋)强烈支持。之前的讨论没有继续推进着实可惜，希望这次能一劳永逸解决中维连接号问题。--PexEric 💬|📝 2023年2月18日 (六) 08:48 (UTC)
- (＋)支持：使用全角的连字暨减号（“－”，U+FF0D）作为“一字线”或“连接号”的确不是常用的做法。Em Dash（“—”，U+2014）在简体中文下是破折号的一半，输入起来很方便。
- 在大陆，中华人民共和国国家标准规定了一字线的符号（[4]），看起来有点像Em Dash，而不是全角的连字暨减号（连字暨减号看起来更短）。不过这是一个PDF文档，难以确定到底用的是哪一种。
- 在台湾，连接号条目里说了“台湾教育部《重订标点符号手册》修订版使用em dash作连接号。”
- 综合上述各地情况，支持将格式手册的连接号改为Em Dash（“—”，U+2014）。——小林子冲（留言） 2023年2月20日 (一) 20:06 (UTC)
- (？)疑问：英维那边使用的连接号为 en dash（“–”，U+2013），而本地的 cite 系列引文模板自英维引进，其中用于连接页码的也是该符号，因此在站内有着大量用例。在本人的设备上看来，连字暨减号“－”（U+FF0D）太短，视觉效果很差，而 em dash“—”（U+2014）又显得过长了，超出了一个汉字的宽度。考虑到连接号最常使用的地方是在数字之间，故其长度如能与数字的宽度相仿理应看着最舒适。使用比汉字还宽的 em dash（U+2014）来连接数字，视觉效果似乎略显累赘。总之，这两个符号看上去都不如长度适中的 en dash（U+2013）美观，所以我们为什么不效仿英维，以 en dash 作为首选连接号？这样一来既能确保美观，又能与引文页码中的连接号保持一致。虽然参考文献使用的符号不必与正文相同，但如能使整篇条目中的连接号整齐划一，未尝不是更好的选择。--萧漫（留言） 2023年3月1日 (三) 23:19 (UTC)
- 这里所有的讨论只针对内文和标题，不适用于文献引用。文献引用有另外单独的格式标准。维基百科:格式手册/标点符号第一段最后一句也说明了这一情况。--InstantNull（留言） 2023年3月2日 (四) 03:26 (UTC)
- en dash未在《重订标点符号手册》修订版--连接号中出现。em dash同时切合海峡两岸的规范，《重订标点符号手册》称为甲式连接号，GB/T 15834—2011称为一字线。--Lt2818（留言） 2023年3月12日 (日) 04:42 (UTC)
公示7日。--Lt2818（留言） 2023年3月12日 (日) 04:42 (UTC)
- 又是什么鬼提案？显然这个独裁社群完全没人考虑过比如Wikipedia:典范条目/列表、Wikipedia:特色列表/列表和Wikipedia:优良条目/列表运用在首页的问题，然后就在公示了？讲真的实在很不想说，但如果说了是不是跟没说一样硬是要强行通过？似乎仍旧没有进步。
─都早用习惯了，如果通过，是要全部替换吗？看着办吧，如果此提案过了，以后只会更少人愿意写维基百科，因为连个编辑方式都在管东管西的，完全失去所谓的维基百科本质：“自由的百科全书”。--Z7504非常建议必要时多关注评选（留言） 2023年3月12日 (日) 16:48 (UTC)- 首先我建议这位编辑 stop crying. 您这样将您不喜欢的提案怪罪于社群无助于解决任何问题。本提案自提出已有一月有余，大部分编辑表示支持，对部分异议我也做出了解释和调整。且有关议题在过去几年已经多次做了充分讨论，过往的意见也多数表示支持。整个过程公开透明，哪里“独裁”？何来“强行通过”？您有反对意见可以提出，社群欢迎建设性讨论，但哭闹不会使您的观点更具有说服力，错误的习惯也仍然是错误。--InstantNull（留言） 2023年3月13日 (一) 04:53 (UTC)
- 就别在那边自欺欺人了吧。独裁就是独裁，还说没有说服力？这个可悲的独裁社群意思就是说现在要把
─全部强制换成U+2014吗？到底是谁才没逻辑啊？可悲独裁社群，既然要通过提案就过啊，反正说了真的跟没说一样，只爱强行通过的独裁社群。哪还需要公示？公示真的只是形式而已。也不会有人每天会愿意为了这一杠吵，但是此种作法只会减少编辑者意愿。啊本来维基百科就已经对新手很不友好了，再过这种鬼提案以后真的没人要写维基百科了。以后的新条目也会很难写出来，因为都被前面的人写完了，以前也讲过很多次了。请问维基百科哪里还称得上是“别伤害新手”之说？而且维基百科还有多种条目是以比如“A國─B國關係”命名的，要不要全部条目名称都改为“A國U+2014B國關係”？如果不要改，那就最好全部重定向处理。这提案当然是鬼提案啊。--Z7504非常建议必要时多关注评选（留言） 2023年3月13日 (一) 11:25 (UTC)
- 就别在那边自欺欺人了吧。独裁就是独裁，还说没有说服力？这个可悲的独裁社群意思就是说现在要把
- Wikipedia:典范条目/列表等三个页面中的U+FF0D不是连接号用例，自然不受影响。
─（U+2500）与本提案没有关联。维基百科的自由体现在多个方面，但格式并非其一。--Lt2818（留言） 2023年3月13日 (一) 13:03 (UTC)- 并非格式不能自由，而是既然我们已经在格式方面达成共识了，并且格式手册长期以来就有一致性的格式要求，那么大家应该遵守共识，维护共识，积极创造条件以更好维护原本的共识，共识才是约束的条件。----Cat on Mars 2023年3月13日 (一) 16:12 (UTC)
- 那请问像是“{{lang-en}}”是要强迫用户都改成使用“{{langU+2014en}}”才甘愿吗？这种鬼提案到底是谁想的也不动动脑筋，想当然只好(－)强烈反对啊。难道还要举例吗？独裁的烂社群。--Z7504非常建议必要时多关注评选（留言） 2023年3月18日 (六) 10:39 (UTC)
- 并非格式不能自由，而是既然我们已经在格式方面达成共识了，并且格式手册长期以来就有一致性的格式要求，那么大家应该遵守共识，维护共识，积极创造条件以更好维护原本的共识，共识才是约束的条件。----Cat on Mars 2023年3月13日 (一) 16:12 (UTC)
- 首先我建议这位编辑 stop crying. 您这样将您不喜欢的提案怪罪于社群无助于解决任何问题。本提案自提出已有一月有余，大部分编辑表示支持，对部分异议我也做出了解释和调整。且有关议题在过去几年已经多次做了充分讨论，过往的意见也多数表示支持。整个过程公开透明，哪里“独裁”？何来“强行通过”？您有反对意见可以提出，社群欢迎建设性讨论，但哭闹不会使您的观点更具有说服力，错误的习惯也仍然是错误。--InstantNull（留言） 2023年3月13日 (一) 04:53 (UTC)
- 格式手册已修改。--Lt2818（留言） 2023年3月19日 (日) 13:49 (UTC)
- 公告一下其他方针指引的相关修订：Special:Diff/76538378、Special:Diff/76527276/76538520。--Lt2818（留言） 2023年3月27日 (一) 13:03 (UTC)
需要进行之善后措施编辑
应Eric Liu君建议，在此整理需要进行之善后措施。我先列出移动页面的部分，用机器人或JavaScript完成比较适合。
U+FF0D作为连接号出现在大量标题中，这些需要移动到U+2014（em dash）的名称。移动应留重定向，以避免破坏内外链接。根据页面性质及行动方式的不同，我分了三个类别，下面的链接是用Quarry查询得到的页面列表：
移动完成后，模板内指向被移动页面的链接会被重定向，这是个小问题。
--Lt2818（留言） 2023年3月13日 (一) 15:29 (UTC)
- 模板部分似乎亦单独列出为宜？—— Eric Liu 創造は生命（留言・留名・学生会） 2023年3月14日 (二) 06:18 (UTC)
- U+2500影响的页面也有40个，可一并处理。--PexEric 💬|📝 2023年3月19日 (日) 10:53 (UTC)
- 发现其中有不少页面应该是用短横线的。建议不要用机器人全自动移动，而是在判断正确的符号后再行处理。
- 个人体会：中文中的连接号不一定和英文对应。英文同样是en dash，中文可以是短横线（比尔-朗伯定律，格式手册中的例子）或一字线（伏尔加—波罗的海水路，表起止）。--Lt2818（留言） 2023年3月20日 (一) 13:36 (UTC)
- 机器人可以只批量修正U+FF0D到U+2014（em dash），U+002D（en dash）本来就不用管；U+2500是制表符，用作页面名是错误用例。--PexEric 💬|📝 2023年3月20日 (一) 14:22 (UTC)
- 可以考虑导入站内页面，手动清查，由机器人更新剩余清单；并可以考虑另设排程移动页面，就是把页面放到那里去机器人就会帮忙移动之类的。—— Eric Liu 創造は生命（留言・留名・学生会） 2023年3月21日 (二) 10:22 (UTC)
- 另外，对于部分罕用或常遭误用之连接号，甚至可以直接列出包含正文在内所有使用案例，以便社群协助修正。—— Eric Liu 創造は生命（留言・留名・学生会） 2023年3月26日 (日) 16:58 (UTC)
- 个人以为，西班牙语人名的条目会受到这个震撼弹决定影响，是否通知WikiProject:西班牙、WikiProject:墨西哥、WikiProject:秘鲁、WikiProject:古巴等？--Liuxinyu970226（留言） 2023年3月21日 (二) 04:13 (UTC)
重修封禁方针及禁制方针编辑
重修封禁方针编辑
细读本站封禁方针发现极严重翻译腔及欧化汉语问题，且遗漏关于多项实际有执行但没写在方针内的信息（例如封禁开放代理）或需要但不存在明确指引的信息（如解除封禁相关指导），故建议完全重修封禁方针以改善以上情况。重修方针草稿置于User:LuciferianThomas/项目/重修封禁方针。 望社群各成员协助复查并给予意见。--路西法人 2023年3月1日 (三) 03:32 (UTC)
- 仔细看了一下，解决了旧的问题，然后又产生了新的问题。很多句子您翻译进去的句子也是翻译腔和繁冗的，但我没有时间一一指出。另外，“手段”没有贬义。《汉语大词典》中“手段”有四个义项，此处是义项2，“为达成某种目的而采取的方法和措施”，而非带贬义的义项3。--Ghren🐦🕐 2023年3月1日 (三) 05:02 (UTC)
- 比如说：“封禁功能是管理员权限当中最具影响力的，管理员应当在执行封禁前了解情况，并必须能够佐证其执行的封禁的依据”：“封禁功能是管理员权限当中最具影响力的”，是不是“最具影响力”的呢，感觉很主观。“必须”就是“必须”，“能够”就是“能够”，什么是“必须能够”呢。“佐证”就是提出证据证明，那后边“依据”不就重复了。
- “承诺停止不当行为并能展现已明白错误之处和汲取教训或已停止不当行为一段时间的用户可能可获解除封禁”，请问如何句读。
- “如执行了一个可能具争议性的封禁”：“一个”是典型的翻译腔，然后“可能具争议性”句意上也不是很清楚。
- “保护目的的封禁用于应对以下情形”：什么是“保护目的”？
- ““严重扰乱”包括不适合维基百科文明协作氛围及影响让参与者协作共建百科全书的行为”：为什么不能放到下边去呢。
- “管理员可在发现被封禁用户操控其他账户绕过封禁编辑的情况下重设封禁时长；被封禁绕过封禁期间若继续有可致封禁的编辑行为，管理员亦可考虑延长封禁时长。”其实可以分成好几个小句的，不需要一句过的。不过我觉得这段内容全部都应该归到傀儡去就是了。--Ghren🐦🕒 2023年3月1日 (三) 07:27 (UTC)
- 正是需要社群协助复查。
- “手段”：我指的是negative connotation，虽然不是在此使用情况下带有贬义，但也可以被借来说是那个贬义的意思就变成讽刺，改成“技术措施”就没有这个问题，也是最factual的说法。
- “
封禁功能是管理员权限当中最具影响力的。”删了 - “承诺停止不当行为并能展现已明白错误
之处和汲取教训或已停止不当行为一段时间的用户可能可获解除封禁”改了。 - “如执行了一个可能具争议性的封禁”是旧版本已存在的问题，我没注意到这个。改成了“执行可能具争议性的封禁时”。
- “保护目的”亦是旧版本已存在的问题，指的是“保护用户或社群”的标题。改成了“包括但不限于以下情形”，因为重译版前面已经有说明了封禁在什么情况下保护用户和社群。
- ““严重扰乱”包括不适合维基百科文明协作氛围及影响让参与者协作共建百科全书的行为”不写在下面是因为下面的是“不适合维基百科[...]的行为”的例子，而这个是定义。
- “管理员可在发现[...]考虑延长封禁时长。”问题似乎不是很大。re“这段内容全部都应该归到傀儡”，其实应该两边都写（
- 如发现更多问题欢迎再次提出。--路西法人 2023年3月1日 (三) 07:46 (UTC)
- “防止扰乱”：扰乱一词一般特指POINT（即“为阐释观点而扰乱维基百科”），可能会导致误解。不过暂时没想到更好的词。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年3月1日 (三) 10:54 (UTC)
- 全文所用扰乱是文字上的意思。基础方针得常人看得懂，不应有暗含意义，故扰乱一次不会作POINT的意思（除非全写）。--路西法人 2023年3月1日 (三) 11:02 (UTC)
- 那您为什么要突然去定义什么是“严重扰乱”呢。而且您这一句也不像是定义，而像是严重扰乱的一些例子。不论什么是“严重扰乱”根本和封禁方针的实行没有关系吧。--Ghren🐦🕘 2023年3月1日 (三) 13:26 (UTC)
- “不适合维基百科文明协作氛围及影响让参与者协作共建百科全书的行为”非具体例子，仅是定义何谓“可致封禁的严重扰乱行为”，给了定义再给符合此描述的具体方针例子，怎么没关系了？--路西法人 2023年3月1日 (三) 14:11 (UTC)
- 您给我的留言感觉就是完全没在读旧版方针和我参照的英语版方针，这个也是旧方针已经存在的内容，我只是在paraphrase一下翻译腔和整理语序，怎么又成了我的问题了？英语版方针原文：
A user may be blocked when their conduct severely disrupts the project; that is, when their conduct is inconsistent with a civil, collegial atmosphere and interferes with the process of editors working together harmoniously to create an encyclopedia.
--路西法人 2023年3月1日 (三) 14:15 (UTC) - 倒是修了个小笔误，“…协作氛围及影响
让其他参与者协作…”。--路西法人 2023年3月1日 (三) 14:23 (UTC) - 本来想不要把一句没有句读写很长，既然阁下看不懂那改成
管理员可因用户作出不适合维基百科文明协作氛围或影响其他参与者协作共建百科全书的扰乱行为而实施封禁。
--路西法人 2023年3月1日 (三) 14:34 (UTC)
- 那您为什么要突然去定义什么是“严重扰乱”呢。而且您这一句也不像是定义，而像是严重扰乱的一些例子。不论什么是“严重扰乱”根本和封禁方针的实行没有关系吧。--Ghren🐦🕘 2023年3月1日 (三) 13:26 (UTC)
- 全文所用扰乱是文字上的意思。基础方针得常人看得懂，不应有暗含意义，故扰乱一次不会作POINT的意思（除非全写）。--路西法人 2023年3月1日 (三) 11:02 (UTC)
- （1）“其中包括但不限于以下属严重扰乱的行为”里面的“破坏”建议改成“故意破坏”，以减少歧义。（2）“不限期封禁”后面加上“（又称永久封禁）”，因为永久封禁这个词语仍然相当常用。--GZWDer（留言） 2023年3月3日 (五) 10:05 (UTC)
- (！)意见：敝人对路西法阁下所提供之草案全文表达微调意见，恕直接大块呈现：
- 第一部分“首段”提议条文：
- “管理员可在接纳用户申诉、认为封禁缺乏适当依据、不再合适等情况下解除对用户的封禁（参见 § 解除封禁）。封禁与禁制有所不同：禁制是褫夺用户在维基百科全站或若干部分之编辑权的正式措施，并不直接阻止用户编辑页面，但禁制也可以透过封禁来执行。”个人认为标明红色的该句具体语意似对一般读者不甚明朗，有兴趣的读者可以直接详阅禁制方针。
- 第二部分“原则”提议条文：
- “封禁应当具有遏制效果，以防止维基百科受破坏及扰乱，..........在一般不应以未持续发生且当前已无扰乱风险之事由作追溯式封禁。
- 被封禁用户可发起封禁申诉（参见 § 解除封禁）。解除封禁的请求同样应以遏制、阻却破坏性编辑和扰乱行为，或尝试引导善意的建设性编辑作为考量。承诺停止不当行为，并能对相关规范展现具诚信之适当理解的用户可能可获解除封禁；同样地，在解除封禁后持续出现相同不当行为的用户，其封禁申诉很可能会被拒绝以作阻吓作用并强调行为不当和改善的必要。”。
- 第三部分“常见的封禁原因”提议条文：
- “执行可能显具争议性的封禁时，则应以适当方式（如管理员布告板）通知其他管理员进行复检。管理员应当在对于新用户需多加注意：..........但需注意用户在被充分提醒或警告后持续不当编辑仍可被封禁，此并不代表“不清楚维基百科的规则”可当作开脱责任的借口而用户拒绝或显为不当理解相关规范亦非规避封禁等裁处的理由。”个人认为由于封禁是否具争议性须视情形而定，亦可能因各种用户的主观认知而有所差异，若要有争议总会有争议，难以一概而论；考量管理员本身应已具备之能力和机动性，可选择适当的不同处置作为，达成风险降低或错误修正效果。另微调字面。
- 第四部分“保护用户或社群”提议条文：
- “.....包括但不限于以下情形：.....其他可能危害用户安全的行为；..........持续在生者人物条目加入未能以可靠来源佐证，或显可合理查知推定其为虚伪，或已经公开证实为不实陈述之诽谤内容；....”。此项所欲保护者为条目在世主角之生者法益，但是诽谤一词涉事复杂，且各国或地区的法律标准、名目不一，即便可靠来源亦可能对公众人物构成诽谤，又或者负面和争议讯息经可靠来源报导散布亦仍可能涉及诉讼争议，是否诽谤又须经法律认定，因此“未能以可靠来源佐证”或“可能存在诽谤”两种情形在认定时可能出现矛盾，比如“能以可靠来源佐证”却也“可能存在诽谤”，又或者传主主张其为诽谤并诉诸法律，此时又该如何认定？极端而言，若传主大量兴讼，使相关载述事件皆进入法律程序，此时关于事件的公开传述是否“可能存在诽谤”？以上情形，除已超出一般善意用户之通常思虑和负荷能力，亦恐损及平台立意和公众利益，而若无所设限也失去原先规范立意。因此，于此若未明指规限范围，可能易生各种争议，尤以若平台遭不当利用为甚。个人建议直接明指在此规范者为“未经可靠来源传载，或显明可合理查知其具备虚假陈述”之诽谤疑虑者即可。
- 第五部分“防止扰乱”提议条文：“在一般情况下，用户在首次被封禁前会收到数次警告，但执行封禁时仍应当在被封禁用户的对话页提供适当说明或理据以减少争议”。
- 第八部分“绕过封禁”之“代替被封禁用户作出编辑”提议条文：
- “任何用户不得代理或代表被封禁用户编辑，除非该等编辑明显有益于维基百科，且代为编辑的用户有合理且独立的原因作出该等编辑。模仿被封禁用户编辑行为的新用户（尤其是仅作此类编辑的用户账户）将可被视为傀儡或真人傀儡，并视具体情事被施以与其所模仿用户同等的适当裁处。”个人认为“方向”一词指涉过广且难以界定，即便换为“编辑内容、行为或倾向”也是相当容易误解；若实务上遇此类“疑似代理”行为，仍须就具体的编辑行为或内容检视其是否为“协助”或“代理”被封禁用户进行编辑。
- 第十一部分“封禁指导”之“教育用户”提议条文：
- “所有维基人应尽力在采取封禁措施前优先考虑教育用户遵守方针指引，并在其作出与方针指引精神相违背的编辑时予以提醒或警告。请欢迎且不要伤害其他新手，并假定其有改善维基百科的意图。较有经验的维基人（包括管理员及一般用户）应于发现新手犯错时予以提醒或警告。用户可使用一系列的警告模板用以发送简单的罐头提示，但按情况量身编写的讯息更佳。封禁应为最后的手段，管理员应当在封禁违规的用户前确认有关用户知晓或已获告知相关的规范，并已给予足够时间让其停止不当行为。仅用于明显破坏、人身攻击或规避封禁等被禁止行为的账户不在此限，并可直接封禁。”。
- 第十二部分“解释封禁原因”之提议条文：
- “.......因此必须基于可查的证据及合理判断，经详细考虑才执行。所有封禁的理据可在复审者提出要求下清楚提供。
- 知会用户 管理员必须在执行封禁时具体提供适当明确的理据。封禁理由应避免仅使用内部术语以确保被封禁的用户能理解相关理据。.........
- 附加信息 执行封禁的管理员可考虑在加入以下信息，以协助复审者检视裁处：......”。“判决”一词似过于正式，且对于站务行权恐生争议。
- 第十三部分“执行封禁”之提议条文：
- “釐定封禁期限 .......，因此封禁期限应根据用户是否可能重复不当行为而定。再犯者可被假定可能再次或频繁出现同类扰乱行为，而可被施予较长的封禁，以阻截扰乱及减低维护工作的负担。简而言之.....”。
- 第十四部分“解释封禁原因”（此段重复？）
- 第十五部分“不限期封禁”之提议条文：
- “不限期封禁（或称永久封禁）是指无失效时限的封禁，通常用于防止严重扰乱维基百科正常运作的行为，或严重违反维基百科相关适用规范的行为。不限期封禁或适合用以阻止持续的不当行为，但仍需注意同样不应作惩罚之用。不限期封禁并不代表永恒不可变，而仅代表未有订立封禁时长，封禁不会自动过期解除。被不限期封禁的用户在合适的情况下可获解除封禁，并在使其获得社群适当观察警醒的情况下继续编辑，以确保该用户未来不再违反维基百科的不同规范。”。
- 第十六部分“设置封禁选项”之提议条文：
- “账户创建......，则应使用此封禁选项。此封禁设置会经自动封禁及IP硬封禁而套用于在受影响的IP地址登录，且未申获IP封禁豁免的用户之上。
- 传送电子邮箱....，则可使用此封禁选项。此封禁设置会经自动封禁及IP硬封禁而套用于在受影响的IP地址登录，且未申获IP封禁豁免的用户之上。
- 编辑自己的讨论页封禁选项会剥夺被封禁用户使用其用户讨论页的权利，此使其无法经用户讨论页进行封禁申诉。此选项在大部分情况下不应使用，仅应而在需组织被封禁用户显为滥用自己的对话页（包括但不限于：对社群进行各种威胁、恫吓、骚扰；试图公开他人个人信息；刻意提供具误导性之虚伪、不实陈述；以及多次重复申诉而无新申诉理据等滥用讨论页情况）下使用此封禁选项。
- 封禁使用此IP地址的登录用户.....，此选项禁止未申获IP封禁豁免的用户账户在被封禁的IP地址及区段上使用被封禁功能，如编辑、创建账户及使用电邮联系功能。”。
- 第十七部分“封禁机器人”之提议条文：
- “未经审核批准或豁免审核运行的机器人账户，或用户名因可能被误会为机器人而违反用户名方针的账户，可被即时不限期封禁；若机器人操作者被封禁，.....”。
- 第十八部分“标记用户页”之提议条文：
- “若用户因滥用傀儡或被确认为他人的傀儡而被永久封禁，或在被永久封禁后被查出滥用傀儡或被确认为他人的傀儡，请务必以Template:略（对于滥用傀儡的用户）或Template:略（对于傀儡账户），替换原有的用户页内容（如已创建用户页）或创建用户页（如未创建用户页），并对之进行永久全保护；需拒绝承认的情况不在此限。”。
- 第十九部分“解除封禁”之提议条文：
- “封禁申诉 作为封禁申诉的一部分，社群可参与申诉讨论，执行封禁的管理员则可能按情况被要求检视、参与申诉讨论，提供更多信息。.........社群并未制定针对同一封禁的申诉次数上限，但持续滥用申诉程序（包括但不限于：对社群进行各种威胁、恫吓、骚扰；试图公开他人个人信息；刻意提供具误导性之虚伪、不实陈述；以及多次重复申诉而无新申诉理据等情况）则可导致管理员禁止用户使用其用户讨论页的权限，但用户仍可透过封禁申诉邮件列表（unblock-zh@lists.wikimedia.org）进行申诉。...........
- 临时性质的解除封禁......，违反以上条件可处以额外制裁。除非讨论共识推翻原先裁处的封禁，否则讨论结束后应当恢复裁处结果。
- 有条件解除封禁 管理员具有封禁条件生效时长的决定权，但原釐定封禁期限不超过一年者，其解除封禁条件的釐定时长不得超过一年；原釐定封禁期限超过一年者（包括不限期封禁），其解封条件的釐定时长不得超过三年、解封条件约定之再犯釐定时长不得超过五年。若解除封禁条件方案包含社群观察期，釐定观察期限为三个月起算，不得超过被封禁用户实际获处之解封条件时长。若解除封禁条件方案内含要求显有违被封禁用户参与初衷和能力，或无涉其违规情事或公开申诉内容，或违反公序良俗者，自始无效。.........违反解除封禁条件或再作出可致封禁行为的用户可处重新封禁并被进一步制裁。”。--Kriz Ju（留言） 2023年3月7日 (二) 23:44 (UTC)
原意见补充说明（恕直接借了套用）
|
|---|
|
- 感谢Kriz Ju君解释您在“有条件解除封禁”一段的建议条文。有条件解除封禁乃是完全原封不动引入自英文维基百科的en:WP:CONDUNBLOCK，但在考量后我还是觉得您的建议增修不适合采用：
原釐定封禁期限超过一年者（包括不限期封禁），其解封条件的釐定时长不得超过三年、解封条件约定之再犯釐定时长不得超过五年
：有条件解除封禁包括改为不限期局部封禁或禁制取代不限期封禁，但此建议修改条款阻碍了此类下修措施。若解除封禁条件方案内含要求显有违被封禁用户参与初衷和能力，或无涉其违规情事或公开申诉内容，或违反维基百科:维基百科不是什么等本站宗旨和规范者，自始无效。
解除封禁条件是一种禁制措施，解除封禁条件不能要求用户做什么，只能要求用户不可以做什么，似乎没必要写进去。管理员使用此功能来要求用户做什么的话，相信社群也不可能会接受。
- --路西法人 2023年3月10日 (五) 07:26 (UTC)
- 感谢Kriz Ju君解释您在“有条件解除封禁”一段的建议条文。有条件解除封禁乃是完全原封不动引入自英文维基百科的en:WP:CONDUNBLOCK，但在考量后我还是觉得您的建议增修不适合采用：
- [5]。改了一下。--Ghren🐦🕖 2023年3月10日 (五) 11:29 (UTC)
- 在回退被封禁用户编辑上，修正错字及移除破坏的编辑等都应该保留，比改版的可被保留要强。旧版明显不鼓励机器人全面回退被封禁用户的编辑。--Temp3600（留言） 2023年3月16日 (四) 15:07 (UTC)
- 封锁->封禁?
这是要整个方针更名?--Temp3600（留言） 2023年3月16日 (四) 15:02 (UTC)
重修禁制方针编辑
由于近期有用户在处理持续出没的破坏者时出现误会一事，建议在禁制方针正式引入本地全站范围禁制供社群正式制裁用户剥夺参与本站编辑权利，类同全域禁制的本地版；建议添加该项而不并入不限期封禁是鉴于不限期封禁并不代表禁止编辑，有不当用户名软封禁和机器人出错的封禁等。此外，建议将“编辑禁制方针”更名为“禁制方针”，互动禁制和电邮禁制不是编辑权的一部分而是行为的制裁。--路西法人 2023年3月1日 (三) 03:32 (UTC)
- 首先中文版和英文版ban的概念不同，英文版的ban是根据社群共识的正式行为（site ban强于indef block），中文版是一种一种比block弱的管理手段（Wikipedia:互助客栈/其他/存档/2019年3月#建议编辑禁制）；此外“根据社群共识所执行的编辑禁制”中文版有显著的反对意见（例如这个场景）。--GZWDer（留言） 2023年3月3日 (五) 03:17 (UTC)
- 感谢阁下指出过往讨论，我也有研究过，但编辑禁制方针本来就是社群明确反对及后慢慢达成共识而通过的最佳例子。社群讨论过并不代表不能再讨论，且在上次讨论后经历过不少大事，社群的看法很可能有改变的情况。只要讨论制定得宜，过往讨论并不能做为不改变的原因。请阁下容我完成新建议版本的编写再提出更对意见，此仅为占位讨论串，您也可以看到我连条文都还没提出。--路西法人 2023年3月3日 (五) 04:12 (UTC)
- 过往社群屡次反对社群禁制措施的主要原因之一是担忧制度被滥用打压异见社群，但经历OA2021后社群的环境是显然可见地改善了。
- 即使是OA2021发生当下，社群内亦没有出现夺权或打压的情况，最终讨论出来也只有有限度制裁措施，试图完全打压整个社群（例如要求正式制裁WMCUG）的提案完全没能通过，最终只是有限度地移除特定链接和挂模板告知OA2021；OA2021后基本上再未出现管理员操控打压特定社群并包庇特定用户的情况。这些证明了：
- 滥用制度打压异见社群并非源自权限而是源自人的问题，要用“担忧被用作打压异见社群”这点来说那您维连封禁权限都不能有；及
- 现时中文维基百科各立场社群显然比以前的更平衡和互相制约、更能求同存异，再出现同样程度的集团式操控社群的机会不大。
- 在社群已经恢复正常的情况下，我觉得现在是适合探讨重整禁制制度的合适时机，但基于过往社群讨论的考量，确实可以在以英维版本作为基础重修的同时制定更能防止集体滥用程序的情况发生。--路西法人 2023年3月3日 (五) 09:22 (UTC)
- 社群正常也不意味着未来不分裂。甚至可能在Wikipedia:管理员解任投票/Shizhao的时代（约2010-2011年）社群已经出现了拉帮结派问题（虽然和后来的问题不是一回事）。--GZWDer（留言） 2023年3月3日 (五) 10:00 (UTC)
重修禁制方针条文已准备完毕并存于User:LuciferianThomas/项目/重修禁制方针。重修方针概要：
- 方针更名“编辑禁制方针”→“禁制方针”以更广泛包含不属编辑的可被禁制扰乱行为。
- 由于MediaWiki软件已于2019年引入局部封禁，故管理员不再需要通过“禁制”来限制用户在特定页面或命名空间的编辑，但仍给管理员保留针对编辑争议采取局部封禁无法取代的主题、互动禁制及回退限制。
- 正式引入全站范围禁制，预设于绕过封禁的用户及全域锁定用户适用（如持续出没的破坏者等），适合用于拒绝承认的情况。
- 将回退限制（回退不过一、回退零容忍）写入禁制方针。
- 引入社群禁制程序，容许社群在达成广泛共识下实施禁制，但仍需由管理员结案。程序规范较严谨，主要是确保社群广泛知晓有禁制讨论；然后现在大家都知道试图操控社群的后果和向T&S检举方式，如果再发现那种团伙式违背维基百科理念及方针指引而包庇违规者或操控社群的情况那大家都知道该怎么做。
- 此部分保留空间给无法设立ArbCom的中文社群通过全站共识达成ArbCom的管辖权效果。
社群与其永远活在过去的阴影下，不如尝试在现在恢复正常的时刻将合适的措施重新引入。--路西法人 2023年3月8日 (三) 15:49 (UTC)
- 通知曾参与讨论的其他用户：@GZWDer、Kriz Ju、魔琴、Ghren，希望几位能协助复查用词字句等并提供完善措施防止滥用。--路西法人 2023年3月8日 (三) 15:54 (UTC)
- 先不说几次在《维基百科:可靠来源/布告板》有意图以人数“达成共识”、夺取话语权（此问题非仅有本人如此认为），单论上次本人之被封禁某几位事关者要么无视要么强词夺理就是给不出非双标的合理解释，这次直接要把“集体独裁”合法化？并且个别用户明显违反方针、破坏扰乱却毫无惩治措施（可能其为IP豁免用户所以无法禁制IP）的明显对比，可见目前社群不适合“引入社群禁制程序”。--MINQI（留言） 2023年3月8日 (三) 18:22 (UTC)
- 共识确实不是强求一致同意，但我并不否认阁下举出的案例中的共识形成或有缺陷，后来共识方针修订的WP:7DAYS条款也开始令在客栈的同类情况被阻止，有outstanding且未解决的意见则必须暂停公示。多数人暴政或许是维基百科共识制度的本质缺陷，但若不引入社群禁制制度则此权仅落入管理员手中而社群难以推翻，更容易形成小数人暴政。我大可要求管理员结案时概括并衡量所有反对意见，在结案时要求公示，但还是那句：制度会不会被滥用不是制度的问题而是人的问题。与其让管理员有社群无法控制的权限，而社群又不接受ArbCom这类小数人暴政，倒不如将禁制权参考英文维基百科下放社群。--路西法人 2023年3月9日 (四) 00:02 (UTC)
- 嗯，由第一段第一句读起来的感觉就很糟糕。太长，而且不停用分句来补充信息。然后后面的内容就没有时间仔细看了。您维的方针、指引和现实生活中较为相似的文体是章则、条例，这些文体是点列式的。您维的习惯虽是段落式，句子不需要这样长的，也不需要一环套一环的。例如这句：“禁制为用户造成极端或顽固问题（如严重扰乱行为）并对其他编者造成困扰的情况下，在其他制裁措施无法处理下才应考虑采用禁制作为制裁用户的措施。”，那可能写成“当用户造成极端或顽固问题（如严重扰乱行为），并对其他编者造成困扰时，在其他制裁措施无法处理下可采用禁制以制裁用户”。另外，有些程度字眼用得不准确，“应”这个字的约束程度较重，在章则这个文体，和这个情况下是不能接“考虑”的。“考虑”那就是还有弯可以转，那接“应”有什么用。
- 然后有些句子读不通，什么“双向互动禁制并既往不咎通常可以快速而又轻易地阻止争议进一步升级及引起更多扰乱。”；连续使用几个“且”，“任何用户不得代理或代表被禁制用户编辑，除非该等编辑明显有益于维基百科且代为编辑的用户有合理且独立的原因作出该等编辑。”、“任何用户均可回退违反禁制作出的编辑且无需额外提供理由且不受回退不过三原则所规限，但需注意并非所有由被封禁用户绕过封禁作出的编辑都需要被回退，一些明显有益的编辑例如修正错字及回退明显破坏的编辑等可被保留”等等。比较忙，就不一一细检当中用词字句问题了，读得懂就行。--Ghren🐦🕐 2023年3月10日 (五) 17:37 (UTC)
- (！)意见：敝人综合表达如下：
- “页面禁制”提议条文：“页面禁制是禁止用户编辑特定或多个页面（不限命名空间）的禁制措施。.......需注意局部封禁（相较于一般封禁，使被封禁用户ＸＸＸ....）并不代表用户被页面禁制，但页面禁制可透过局部封禁执行；......。”。由于就条文观之，“局部封禁”一词似乎较难理解其具体效果，以及与“页面禁制”之间的差异何在，个人建议或可考虑将“管理行动禁制”段落的“局部封禁”链接说明改为在此置入，并于内文略作简要说明，或提供注记之类。
- “实施禁制”的“社群共识禁制”提议条文：“未参与讨论的管理员对于禁制提案可在达成明确共识时结案，取获得广泛共识的特定禁制措施并予以执行。需注意社群共识禁制不是投票，管理员结案时必须考虑各论点的方针指引依据及强度作出判断；除雪球法则不通过的情况下，非管理员无权关闭禁制讨论。”
- “实施禁制”的“管理行动禁制”提议条文：“1.用户间出现编辑争议或其他形式的冲突争端时，可实施主题、互动禁制和回退限制；....。”。
- “禁制复核”的提议条文：“用户应于申诉时具体说明申诉原因，并根据实际需求提供所需理据。若禁制措施经由社群共识产生，开启禁制复核讨论时应当通知所有曾参与该禁制讨论的用户，并由未参与先前禁制讨论的管理员审视各方理据结案。”。汇整相关内容。
- 个人意见，供参。--Kriz Ju（留言） 2023年3月10日 (五) 19:47 (UTC)
- 已依据Ghren、Kriz Ju两位的意见调整建议条文语句：Special:Diff/76320507，请两位或其他用户不吝指教。--路西法人 2023年3月12日 (日) 03:49 (UTC)
- (！)意见：敝人斗胆再提一笔：“用户应于申诉时具体说明申诉原因，并根据实际需求提供因应违规事由所需理据，例如用户自被禁制或封禁后所汲取的教训、若被撤销禁制会如何改变待人处事或如何认为禁制有不公平之处。”个人仍建议删除后面的列举示例，原因如下：
- 1.前文已概括基本含意。
- 2.由于违规样态复杂，建议授予管理员依实际情形和需求判断的空间，究竟需要何种理据，视情况而定。
- 3.通常避免列举例证，例证亦很可能列举不完。
- 4.列举例证后，若有超出条文字面所述，或刚好吻合字面用字者，可能徒生无谓争议（比如：违规用户主张“上面没说要这个啊”、“条文没答应管理员可以要求这个，滥权了吧？！”、“不是只要心得说明而已吗？”、“上次某人做了ＯＯ只被封ＸＸ而已，我怎么这么久？不公平！”、“他也没被封啊，怎么能封我？”等等）。
- 5.个人另有一主观想法，字面明文所举内容，有种威权下的道德教育或教化的浓厚教条感，可是事实上“违规”不限于待人处事如何，且个人认为平台无任何道德或额外义务“教化”或“教训”用户的为人处事，亦不需强求用户为人如何，也不须奢求用户皆为好人好事代表，规范所要求的仅为“适当合宜、不造成他人困扰且不伤害他人的行为而已”，而非诉诸品德教育或道德感化（“维基感化院”？（笑）），也不是在不违规或不妨碍社群以及其他用户的前提下，以高压体系监管他人性格德行甚而系统化，彷若畜牧豢养用户于此，仅做“生产”或追求何种成效之用。吾人是否需要创建何种“美丽新世界”呢（笑）？
- 个人意见，供参。--Kriz Ju（留言） 2023年3月12日 (日) 20:24 (UTC)
Special:Diff/76333943--路西法人 2023年3月13日 (一) 01:09 (UTC)
- 反对任何以社群共识禁制用户的程序。司法权由少数官僚掌管，与社会经众议而控制的立法权分开，是阻止Trial of Socrates一类以雄辩、黑箱政治诱导群众作出决定的安全网。如果认为某君违反方针，完全可以通过现有的程序，提出事实，要求处理。现在的问题反而是AN3的程序水平相当低下，提出者很多连具体的diff link 都没有给出，管理员没有维持讨论秩序，导致双方在提报区混战，管理员冷处理案子，欠缺具体的提报处理程序等。arbcom的人选是社群中的精英，由他们来当法官，至少判案书条理分明，立论清晰。由社群来搞，只会变成批斗大会。说不定连批斗的大字报都贴不出来，只有几十行"赞成"，变成打内战了。--Temp3600（留言） 2023年3月13日 (一) 18:02 (UTC)
- 上面已经说过单单的“赞成”不能视作有效“意见”，一个没有半点方针指引基础的提案就算有几百个“赞成”也没用。禁制讨论不是投票，而是以论点质量而坐判定，这点在上方回复MINQI的时候说过了，恕我只能视作重复且已回应的反对论点。
- 其次，英文维基百科的社群禁制并非必须通过仲裁委员会进行，跟阁下的论点显然有所矛盾；在您指出程序水平低下的ANM诚然也是一种不成文、不规范的社群禁制。
- 阁下既然指出既有程序混乱，何不提出改善新制度的程序防止出现阁下指出的状况呢？我早已预料社群禁制有可能需要煮一阵子，但我绝对欢迎并希望各位用户能协助订出一个更详细的社群禁制规范以防止“混战”情况出现。需记得最终判断的仍是管理员，此提案仅是希望将整个程序具体化、规范化。
- 当然，此提案我可以再单独分出此部分讨论，反正我对于重新恢复禁制原有效力、引入全站禁制和完善处理被禁者编辑的规范等部分更为着重。--路西法人 2023年3月14日 (二) 01:47 (UTC)
- "论点质量而坐判定"能做到当然是很好。但我按个人经验，中维人员缺乏这样的讨论能力，如果希望在较短的期限(比如说，一个月)达成有意义讨论的就更少。以下随手仅举数例:
- Wikipedia:存废复核请求#奶头乐在五个月的混战后仍无所得，milky的疑问未获回应;
- Wikipedia:存废复核请求/存档/2022年6月#王士俊_(崇祯进士)混战后一无所得;
- Wikipedia:管理员布告板/编辑争议/存档/2022年12月#Invictus1995冷处理;
- Wikipedia:页面存废讨论/记录/2022/12/04#大韩航空642号班机空难连事件是否存在也都未能确认;
- 当然，也有不少可算是"提出有效观点后达成共识的例子"。然而，大部分例子要不是事件本身因简单而不存在争议，要不提出有用意见的人根本就是管理员，甚至是管理员的结案词，结果还是依赖管理员的圣裁。幸或不幸，目前管理员团队已集中了中维内说理能力较强的用户。
- 英维当然好得多。我随便翻了这年的en:Wikipedia:Administrators'_noticeboard/Archive333#Systematic deletion flags, flag templates and additional information (blocking edits)，即使是明显违反现存社群共识的情况，讨论者先引用在讨论页针对内容本身的讨论(那项讨论本身也很长，有十多人参与)，再引用了相关专题小组的讨论，后来的讨论者再对该用户的行为整体作出评价，论证为什么ban是必要手段。我敢说这个讨论的细致程度远超AN3，恐怕某些RFA的讨论也没有如此详尽的说理。如果说搬英维的方案，那得先搬英维的用户过来。--Temp3600（留言） 2023年3月14日 (二) 15:52 (UTC)
- "论点质量而坐判定"能做到当然是很好。但我按个人经验，中维人员缺乏这样的讨论能力，如果希望在较短的期限(比如说，一个月)达成有意义讨论的就更少。以下随手仅举数例:
- 想问一下@Temp3600君：除社群共识禁制外，您对于封禁方针修订及禁制方针剩余的修订（方针更名、局部封禁移出禁制、全站范围禁制等）有无其他意见？整理出社群禁制讨论指导后，您又有无可能改变对于该程序的意见？我期望的是让社群通过社群禁制程序等逐步改进以慢慢达成可创建一个具代表性的ArbCom的程度。--路西法人 2023年3月16日 (四) 01:28 (UTC)
- 这个更改涉及的条文很多，今晚我先看了一部分。如果我认为某一项修订影响重大，但未见讨论，我将会提出分柝该部分的修改。
- 社群禁制的本质问题在于新程序有什么好处，以至必须独立分家出来。此外，我反对任何通过"社群共识"逼使管理员封人的程序。法无禁止即自由，必须先立法后封人，也就是说，先有了不准做某事的共识，才谈得上违反社群共识; 而不能是翻旧账，在作出共识的时候将还没立法时候的旧例子翻出来封人。社群众人更积极参与封禁讨论，提出事证等本身当然是好事。--Temp3600（留言） 2023年3月16日 (四) 15:24 (UTC)
- 用一个更"哲学"的说法，就是社群共识本身也应被其他权力制衡。--Temp3600（留言） 2023年3月16日 (四) 15:25 (UTC)
- 我什么时候说过可以用原先不存在的共识（如方针指引）来禁制人了？社群共识的基础必须是现存方针指引，但有时候一些行为方针无法全部明确定义（如WP:GAME、WP:POINT、WP:CIV等，很多条文都是类似“包括但不限于”）。这些是已长久存在的方针，但管理员虽然可能有自己对于某些行为是否有违此类方针有个人看法，即使有方针基础也缺乏社群认同特定行为是否属于该等方针所指的不当行为。此并非“法无禁止”（确实有禁止游戏规则、阐述观点而扰乱及不文明行为等），但特定行为是否触犯方针恐怕永远无法每次都讨论加入方针，社群禁制正应是用在这些情况。--路西法人 2023年3月17日 (五) 00:24 (UTC)
- 现存的ANM布告板实质上也是社群禁制的制度：用户提出请求、其他用户辩论是否违反上述方针，管理员再视情况决定是否封禁，只是现存ANM制度毫无规范而已。--路西法人 2023年3月17日 (五) 00:28 (UTC)
- 灰色地带的部分我不认同。既然此前并没有关于某项灰色地带行为是否违反方针的共识，那就必须先讨论，达成共识后才谈得上“违反方针”。别人完全可以反驳，他既然较早前没有被封（如在某次AN3讨论中过关），那就说明这类行为在管理员的眼中没有突破底线。这一点在我上面引用的英维讨论有明确反映出来——英维社群为了纠正他的行动，第一件事是先在条目讨论页达成共识，指出那些条目应怎样写，下一步才是他因继续违反了这一项新达成的条目共识而被禁制。Temp3600（留言） 2023年3月17日 (五) 10:10 (UTC)
- 清楚明白理解。若将本地社群禁制程序重写为现状（AN3+ANM+VP）而加以规范，其余执行权不变，阁下是否认同？--路西法人 2023年3月18日 (六) 01:42 (UTC)
- 顺道作一点补充︰我上面在讨论的问题，现实来说是法律的解释权应由那一个机构行使的问题。在大部分国家，这属于宪法法庭及其他法院的职能。有一些国家有不同的制度，但就我看来，实施前者制度较为优胜。就维基百科的情况来说，WMF固然拥有Terms of Use的最终解释权，但中维的日常争议仍需由本地人员负起这份职责。考虑到中维没有ARBCOM的现实，这份职能由管理员们--即社群中较熟识方针，说理能力较好的用户负责，较为适合。
- 回到正题: 社群通过an3/VIP/VP，在封禁有关的讨论发表观点，讨论某种行为本身、条目内容的写法，都是社群行之有效的程序，并应予以规范化。然而，社群即使达成共识，也不能向某用户指名施加处分。
- 又例如，社群对某些事务，常会先通过讨论，达成一项采用投票制来决定讨论结果的共识，并接着举行投票，某些图示、翻译名称就是这样决定的。但是，社群不能以共识决，决议举辧投票来决定某名用户是否违反方针。如afd一样，封禁讨论只能是讨论，不能通过共识改采投票制或其他制度。--Temp3600（留言） 2023年3月18日 (六) 11:16 (UTC)
- 清楚明白理解。若将本地社群禁制程序重写为现状（AN3+ANM+VP）而加以规范，其余执行权不变，阁下是否认同？--路西法人 2023年3月18日 (六) 01:42 (UTC)
- 灰色地带的部分我不认同。既然此前并没有关于某项灰色地带行为是否违反方针的共识，那就必须先讨论，达成共识后才谈得上“违反方针”。别人完全可以反驳，他既然较早前没有被封（如在某次AN3讨论中过关），那就说明这类行为在管理员的眼中没有突破底线。这一点在我上面引用的英维讨论有明确反映出来——英维社群为了纠正他的行动，第一件事是先在条目讨论页达成共识，指出那些条目应怎样写，下一步才是他因继续违反了这一项新达成的条目共识而被禁制。Temp3600（留言） 2023年3月17日 (五) 10:10 (UTC)
重提草稿化讨论编辑
维基百科:草稿命名空间/2022年更新草案似有充分支持意见（先前讨论：一、二）而未走公示程序，重推一下。通知@QiuLiming1、HTinC23、Cwek、YFdyh000、Kriz Ju、S8321414、Temp3600。--路西法人 2023年3月9日 (四) 02:57 (UTC)
- 看上去没多大问题，但之前看到有人直接把条目移动到draft空间后就没任何操作，就等于只做了草稿化操作指南第一条的第一点。--日期20220626（留言） 2023年3月9日 (四) 03:54 (UTC)
- 还有就是如果有人（比如作者）不同意移动到草稿，就提交到条目存废讨论决定去留吗。--日期20220626（留言） 2023年3月9日 (四) 03:57 (UTC)
- @LuciferianThomas：相关的，如果有巡查先按以往巡查操作给予了操作（包括标识问题、SD、AFD等），也就是不给予草稿化，然后其他编辑能否推翻这些决定，将其草稿化？——Sakamotosan路过围观 | 避免做作，免敬 2023年3月10日 (五) 00:42 (UTC)
- 看起来没什么问题，应该可以继续推进。--冥王欧西里斯（留言） 2023年3月9日 (四) 05:07 (UTC)
- 如果不具强制性的话，可以考虑（有些编辑愿意好人做到底的话）。不过“质量明显不符合标准”的章节条件，似乎有点像完全兜底，SD不用SD，AFD预期不会保留的，小作品不挂小作品，全部可以扔去草稿，那这些之前机制好像没有了存在的意义？——Sakamotosan路过围观 | 避免做作，免敬 2023年3月10日 (五) 00:35 (UTC)
- 之前的机制指的是？--日期20220626（留言） 2023年3月10日 (五) 00:38 (UTC)
- 正常情况下，该SD就SD（例如G11，你会扔草稿？），该AFD就AFD（保不保留是讨论后决定，不做结果水晶球），小作品就挂小作品等30天。这些就是之前机制。——Sakamotosan路过围观 | 避免做作，免敬 2023年3月10日 (五) 00:45 (UTC)
- 原则上应该是不符合SD、AFD、小小作品，但又不适合保留在条目空间的才会走草稿化吧，阁下觉得这里的文字要怎么修正才能体现这个流程？--冥王欧西里斯（留言） 2023年3月10日 (五) 01:23 (UTC)
- 是我的错误，没考虑前提条件是条件“全部符合”才需要考虑草稿化，这是其中的一个子条件。——Sakamotosan路过围观 | 避免做作，免敬 2023年3月10日 (五) 01:55 (UTC)
- G11的作品如果有关注度但是自己想改善，可以先移动到草稿。不过大部分情况下想改善的人少，所以就直接G11了。--日期20220626（留言） 2023年3月10日 (五) 01:45 (UTC)
- 原则上应该是不符合SD、AFD、小小作品，但又不适合保留在条目空间的才会走草稿化吧，阁下觉得这里的文字要怎么修正才能体现这个流程？--冥王欧西里斯（留言） 2023年3月10日 (五) 01:23 (UTC)
- 正常情况下，该SD就SD（例如G11，你会扔草稿？），该AFD就AFD（保不保留是讨论后决定，不做结果水晶球），小作品就挂小作品等30天。这些就是之前机制。——Sakamotosan路过围观 | 避免做作，免敬 2023年3月10日 (五) 00:45 (UTC)
- 之前的机制指的是？--日期20220626（留言） 2023年3月10日 (五) 00:38 (UTC)
- “旧条目或不全满足以上条件的新条目不应直接草稿化，而须在存废讨论寻求草稿化共识或提报侵权。”，后面“或提报侵权”是不一定的操作，或者替换成“或其他页面处理方式（包括提报侵权）。”——Sakamotosan路过围观 | 避免做作，免敬 2023年3月10日 (五) 00:42 (UTC)
- 我认为应该加入英维在昨年通过的条款——当条目已经创建90天（或其他合理的日数），不应草稿化。--Ghren🐦🕖 2023年3月10日 (五) 11:30 (UTC)
- 那中维的话可以限定为未被巡查的新条目？--日期20220626（留言） 2023年3月10日 (五) 11:33 (UTC)
- 那也可以，毕竟那条是说除非在AFD达成共识，否则不应把在条目空间超过90天的条目移动到草稿空间。--冥王欧西里斯（留言） 2023年3月10日 (五) 11:35 (UTC)
- 每个人对草稿化“有发展成完整条目的潜力”的标准不同，执行起来或许会有争议。不如把草稿化作为AFD的一个处理结果。--Steven Sun（留言） 2023年3月13日 (一) 08:06 (UTC)
- @S8321414：我近期没空，靠您推进这个讨论了。--路西法人 2023年3月26日 (日) 06:55 (UTC)
- 看来上面主要要改的是引入新条目过30天后不应草稿化的条款，不知道还没有有其他的意见。--冥王欧西里斯（留言） 2023年3月26日 (日) 11:53 (UTC)
- 再加上一个，如果对条目是否草稿化出现争论，则建议直接提交存废讨论。--日期20220626（留言） 2023年3月26日 (日) 11:56 (UTC)
- 与其出现移动战，不如直接挂{{draftify}}模板三天无异议且未改善就草稿化？（移动后再变成另一个{{draftified}}模板告知从AFC程序提交）--路西法人 2023年3月27日 (一) 05:39 (UTC)
- 可以。--日期20220626（留言） 2023年3月27日 (一) 05:42 (UTC)
- 但这样会不会反而失去让巡查员判断直接草稿化的空间？然后关于草案本身，看起来英文版那边有一些针对草稿化标准的补充说明，或许可以把这部分补进来。--冥王欧西里斯（留言） 2023年3月27日 (一) 06:11 (UTC)
- 没有吧，只是考虑到会有一定的争议，所以给个缓冲期。不过就怕挂的人3天后忘记移动了。
- 英文版那边允许巡查员直接把条目移动到草稿吗？--日期20220626（留言） 2023年3月27日 (一) 06:31 (UTC)
- en:WP:DRAFTOBJECT，英维反而没有另外挂模板的机制，变成是草稿化之后如果有人反对就可以直接移回条目空间，再来如果要移到草稿空间就必须走其他方式（AFD等）。--冥王欧西里斯（留言） 2023年3月27日 (一) 07:04 (UTC)
- 草稿化之后如果有人反对就可以直接移回条目空间，再移到草稿空间走AFD也行，中维可以把这句话加进去。--日期20220626（留言） 2023年3月27日 (一) 07:29 (UTC)
- 那么目前要修改的是：
- 新条目过30天（亦即保留在新条目巡查页面的时间）即不应草稿化（新增于“释义”章节的“二、质量明显不符合标准，系指：”之下，成为第四项）
- 将en:WP:DRAFTOBJECT的内容新增至草案中（新增于“草稿化操作指南”之下，但标题与其同级）
- 先这样，看有没有人要编辑草案，没有的话我晚点有空的时候处理）。--冥王欧西里斯（留言） 2023年3月27日 (一) 07:46 (UTC)
- 修改完成：Special:Diff/76547248。--冥王欧西里斯（留言） 2023年3月28日 (二) 04:15 (UTC)
- 那么目前要修改的是：
- 草稿化之后如果有人反对就可以直接移回条目空间，再移到草稿空间走AFD也行，中维可以把这句话加进去。--日期20220626（留言） 2023年3月27日 (一) 07:29 (UTC)
- en:WP:DRAFTOBJECT，英维反而没有另外挂模板的机制，变成是草稿化之后如果有人反对就可以直接移回条目空间，再来如果要移到草稿空间就必须走其他方式（AFD等）。--冥王欧西里斯（留言） 2023年3月27日 (一) 07:04 (UTC)
- 与其出现移动战，不如直接挂{{draftify}}模板三天无异议且未改善就草稿化？（移动后再变成另一个{{draftified}}模板告知从AFC程序提交）--路西法人 2023年3月27日 (一) 05:39 (UTC)
- 再加上一个，如果对条目是否草稿化出现争论，则建议直接提交存废讨论。--日期20220626（留言） 2023年3月26日 (日) 11:56 (UTC)
- 看来上面主要要改的是引入新条目过30天后不应草稿化的条款，不知道还没有有其他的意见。--冥王欧西里斯（留言） 2023年3月26日 (日) 11:53 (UTC)
前续Wikipedia:互助客栈/条目探讨#准备批量清理Category:2022年中国大陆2019冠状病毒病聚集性疫情的条目的讨论，除了聚焦性疫情的条目，其实还有很多关注度有待商榷的条目需要进行清理，而这个问题的解决方案可能要归结到WP:EVENT上面来。综合前几次升格讨论，再结合目前WP:EVENT的实际情况，个人觉得需要打磨的地方还是特别多，在此向大家征求修改意见，争取在正式投票前完善现有内容。--百战天虫（留言） 2023年3月14日 (二) 04:15 (UTC)
- (＋)支持--🎋🍣 2023年3月14日 (二) 12:18 (UTC)
- (－)反对 这样会让大量多年来创建的历史事件条目有被删除的危机，对读者是不利，接收的信息比以往更少。日后可能要出海外的图书馆才能查阅。--Wpcpey（留言） 2023年3月14日 (二) 12:26 (UTC)
- (＋)支持：这个提案从十二年前就获得大量用户的认可，只是因为细节问题暂且搁置。之后的一些指引中也有相应的条文，属于事实上无冕规则。——WMLO（留言）。 2023年3月14日 (二) 13:24 (UTC)
- (＋)支持--冥王欧西里斯（留言） 2023年3月14日 (二) 14:03 (UTC)
- 虽然此项关注度指引未正式通过，但社群的GNG关注度流程大概也是以跟随此指引类似的标准的，故(＋)支持正式订为指引。对于上面那个反对毫不意外，没来反对才奇怪。--路西法人 2023年3月14日 (二) 15:56 (UTC)
- (＋)支持：同时小改错别字。--Kriz Ju（留言） 2023年3月15日 (三) 18:54 (UTC)
- 在本地配套机制及惯常措施未能适切发挥制约作用的情况下，有必要将该升格程序分拆及设置周期检讨期限，一旦发现该规限是被滥用或不合比例地适用，就应当启动中止及重新审订之程序——综合改进过程，必要是将WP:MAJORITY、WP:NOTWIKI、WP:JNN、WP:BELONG、WP:JUSTAPOLICY、WP:IDONTLIKEIT、WP:DEFUNCTS等约定及关联章节，同时间匹配地升格地位，并且强化及细化关联章节之限制力以及反推作用，确保升格过程及后续影响不会偏颇地发生一边倒效果。--约克客（留言） 2023年3月16日 (四) 02:48 (UTC)
- 目前方针很明显还没有完善，连最基本的出发点也错了。WP:EVENT本则上所依的条文是WP:NOTINFO和WP:NOTNEWS，而非关注度条文。上方的疫情条目相信有不少条目是合“有效介绍”、“可靠”、“第二手”、“独立”的标准，但依WP:NOTINFO和WP:NOTNEWS不应收录。需要大幅修订。--Ghren🐦🕓 2023年3月16日 (四) 09:24 (UTC)
- ？
某些例行的新闻种类（包括绝大多数的犯罪、事故和死亡报道，名人或政治新闻，“震惊”新闻，缺乏持续价值的“奇闻”以及病毒传播现象），无论是否悲剧，无论是否在当时被报道过，通常都不具有关注度，除非有其他事件可以赋予其持续的意义。
--路西法人 2023年3月17日 (五) 00:32 (UTC)- 所以就说“WP:EVENT本则上所依的条文是WP:NOTINFO和WP:NOTNEWS，而非关注度条文。”，这里不应说“通常都不具有关注度”，而应该说“基于WP:NOTNEWS不应收录”。下边WP:ROUTINE说得很清楚了，是按照“按照维基百科方针（WP:NOTNEWS），对公告、体育运动等主题的例行新闻报道以及各种小报新闻，都不足以确立一篇独立条目。”，而不是什么关注度。--Ghren🐦🕑 2023年3月17日 (五) 06:03 (UTC)
- 不冲突啊，§ 收录标准是关注度，§ 其他条件是基于其他方针，事件是否可以成条。关注度不就是“可不可以写一个主题”吗？为何就不是关注度了？--路西法人 2023年3月17日 (五) 08:05 (UTC)
- 说实话不知道您在说什么。您上边的那段引文我最少也想了三分钟才看得懂您引用的目的是什么。关注度是决定能否写一个主题，但只是“假定”可以收录。而在WP:NOTNEWS的规定下，这些条目不能收录。“例行报道”是违反WP:NOTNEWS的问题，而不是关注度的问题。当然您也可以认为“例行报道”是违反关注度的要件。另外“例行报道”，或者“例行的新闻种类”感觉和英文原句“Routine coverage”有些距离。--Ghren🐦🕒 2023年3月19日 (日) 07:47 (UTC)
- 不冲突啊，§ 收录标准是关注度，§ 其他条件是基于其他方针，事件是否可以成条。关注度不就是“可不可以写一个主题”吗？为何就不是关注度了？--路西法人 2023年3月17日 (五) 08:05 (UTC)
- 所以就说“WP:EVENT本则上所依的条文是WP:NOTINFO和WP:NOTNEWS，而非关注度条文。”，这里不应说“通常都不具有关注度”，而应该说“基于WP:NOTNEWS不应收录”。下边WP:ROUTINE说得很清楚了，是按照“按照维基百科方针（WP:NOTNEWS），对公告、体育运动等主题的例行新闻报道以及各种小报新闻，都不足以确立一篇独立条目。”，而不是什么关注度。--Ghren🐦🕑 2023年3月17日 (五) 06:03 (UTC)
- ？
- 看中英序言相差得大了点，是否需要重新翻译？--东风（留言） 2023年3月17日 (五) 15:14 (UTC)
- 既然本身就是从英维翻译来的，英维更新了，中文的也应该同步跟进。--日期20220626（留言） 2023年3月17日 (五) 15:26 (UTC)
“A地－B地关系”是不是该用短横线？编辑
此话题无关“一字线的符号选择”，故另开一节。许多“A地－B地关系”条目标题用的是一字线，方针草案《WP:命名常规 (国际关系)》中谈及有关内容也用的是一字线，但是窃以为应该用短横线。按我对GB/T 15834-2011的理解，连接号只有表示“起止”时才该用一字线，而“A地－B地关系”中的连接号并不表示起止。
中华人民共和国外交部网站上有些类似情况也用了一字线[dash 1]。然而窃以为，国家标准与外交部网站不同的时候，参照前者会更合适，故仍应使用短横线。--爱维基百科的CuSO4 2023年3月14日 (二) 21:19 (UTC)
- 现MOS:连接号1-4中复合名词用短横线的指引规定似乎已经与WP:命名常规 (国际关系)中的
方针部分冲突。之前将国际关系命名常规升为格式指引的提案中已经有编者讨论，但看来毫无进展。@維基百科最忠誠的反對者、Sanmosa、Ericliu1912、虹色分子：故ping曾参与讨论的各位编者，希望能引起重视。--PexEric 💬|📝 2023年3月18日 (六) 12:50 (UTC) - 但是看起来很怪。—— Eric Liu 創造は生命（留言・留名・学生会） 2023年3月19日 (日) 09:58 (UTC)
- 如果你说的短横线是半形那种我就(－)反对。中文文章就应为美观起见按全形格式统一用全形标点。--——勿用“进行”污染中文，要言简意赅。 捍粤者 2023年3月22日 (三) 14:10 (UTC)
这个问题其实很复杂，我在“一字线的符号选择”提案里其实有意回避了这个问题。其实按照中国的旧标准GB/T 15834―1995，这种情况无疑应该使用一字线。在新标准中，这个问题被过度简化成“复合名词”(compound noun)。但按照语义理解这里的双边关系是两个实体名词之间的联系，不能简单看成一个词，英文中用 en dash 而不是 hyphen 连接，表示“A和B的关系”而不是一种“名为A-B的关系”。--InstantNull（留言） 2023年3月20日 (一) 07:51 (UTC)
有考虑把“特色列表”改成“典范列表”吗？编辑
目前中维有三类典范（特色）内容：典范条目（FA）、特色列表（FL）、特色图片（FP）。FP的内容在图站，本地都没有页面。其本身就有编外性质，可以抛开不谈。
剩下的FA和FL本质相同，分别象征本站条目和列表中的最佳。然而同样内涵的两者却叫不同的名字，这很让人困扰。比如FA+FL+GA并称都不知道该叫“典优内容”还是“特优内容”。严谨点的称呼是“典范（特色）和优良内容”，但是加个括号也挺啰嗦的。
话说社群有考虑“特色列表”改称“典范列表”吗？--洛普利宁 2023年3月19日 (日) 16:02 (UTC)
- 不知道当时为什么没有改全。不管是要改成“典范”还是反过来改回“特色”，无论如何是应该统一称呼。另外其实我觉得特色图片也一起改比较好。—— Eric Liu 創造は生命（留言・留名・学生会） 2023年3月19日 (日) 16:21 (UTC)
- 这种讨论迟早都会爆的，很想看看这个独裁社群到底又要搞什么花样了。在FA改名成典范之后，到底知不知道已经改了多少个从“特色条目”改成“典范条目”的页面了？总之，绝不会给出什么意见，更不会选边站，因为本质还是叫做FA/FL/FP。这个独裁社群就是喜欢“没事找事做”。更直接的说就是，可能这个独裁社群每过几年，就会把这种讨论再重复搬出来询问一次，周而复始永不止尽，即便到了退休甚至死亡了还是一样不会改变。这里并不是en版，如果是en版就没有这个问题。--Z7504非常建议必要时多关注评选（留言） 2023年3月19日 (日) 16:29 (UTC)
- 我反而想让FA改回去。 ——Sakamotosan路过围观 | 避免做作，免敬 2023年3月21日 (二) 00:15 (UTC)
- 典范图片不好听，我也不觉得图片有“典范”可言。Temp3600（留言） 2023年3月21日 (二) 09:40 (UTC)
- 我都觉得FP可以废了。FP文件不在本站，首页图片和FP又没关系，现在评审区也是门可罗雀。谁要觉得自己上传的图片优秀，自己去c站评就是。毕竟那边有专业鉴定能力的编者多。--洛普利宁 2023年3月21日 (二) 14:10 (UTC)
- 我不觉得FP能再活跃起来，但保留程序当后备也没什么不好。--Temp3600（留言） 2023年3月21日 (二) 15:40 (UTC)
- 有点离题？不过FP要求图片在C区，和本地贡献者关系有限，变成帮别人做“嫁衣”，可有可无的鸡肋，程序上保留，选不选随缘。——Sakamotosan路过围观 | 避免做作，免敬 2023年3月22日 (三) 01:00 (UTC)
- 那把FL改成“典范列表”（和FA相比，改FL变动比较少）；FP评选的是外站对象，姑且还用“特色”这个特殊的说法？--洛普利宁 2023年3月23日 (四) 14:04 (UTC)
- 我反而想让FA改回去。 ——Sakamotosan路过围观 | 避免做作，免敬 2023年3月24日 (五) 00:48 (UTC)
- (＋)支持改回去--百無一用是書生 (☎) 2023年3月24日 (五) 02:21 (UTC)
- (＊)提醒：Wikipedia:特色条目候选/发夹弯 --MilkyDefer 2023年3月25日 (六) 09:35 (UTC)
- 我反而想让FA改回去。
- 那把FL改成“典范列表”（和FA相比，改FL变动比较少）；FP评选的是外站对象，姑且还用“特色”这个特殊的说法？--洛普利宁 2023年3月23日 (四) 14:04 (UTC)
- 有点离题？不过FP要求图片在C区，和本地贡献者关系有限，变成帮别人做“嫁衣”，可有可无的鸡肋，程序上保留，选不选随缘。——Sakamotosan路过围观 | 避免做作，免敬 2023年3月22日 (三) 01:00 (UTC)
- 我不觉得FP能再活跃起来，但保留程序当后备也没什么不好。--Temp3600（留言） 2023年3月21日 (二) 15:40 (UTC)
- 我都觉得FP可以废了。FP文件不在本站，首页图片和FP又没关系，现在评审区也是门可罗雀。谁要觉得自己上传的图片优秀，自己去c站评就是。毕竟那边有专业鉴定能力的编者多。--洛普利宁 2023年3月21日 (二) 14:10 (UTC)
- 我自己是感觉“典范”后边跟“条目”的话没大问题，但跟“列表”或“图片”则非常违和，“特色”后边跟“条目”、“列表”或“图片”则都没问题。如果要改的话，我也支持把FA改回“特色条目”。（看回此前讨论以后，我感觉会不会统一改成“精选XX”好些，不过就只当作自己的一些附加意见算了，我还是优选FA改回“特色”。）Sanmosa Συ γάρ μοι και μοίρα εί και τύχη 2023年3月28日 (二) 12:06 (UTC)
- (＋)支持改名“典范列表”，“典范”就是代表可以做为条目或列表的楷模者，再来也是为了统一名称。特色图片则维持原名。--E.D.（留言） 2023年3月28日 (二) 14:19 (UTC)
提议将AI或深度学习技术生成的文章列为不可靠来源编辑
AI或深度学习技术生成的文章常常似是而非，看上去没有问题而实际上却含有事实错误，因此，我本人提议将AI或深度学习技术生成的文章列为不可靠来源。--Sprt98（留言） 2023年3月20日 (一) 13:55 (UTC)
- 有没有可能，WP:RS没有将AI或深度学习技术生成的文章列为可靠来源。这样纸上谈兵意义何在？请给出提案的具体内容，例如如何界定文章是否由AI或深度学习技术生成。--PexEric 💬|📝 2023年3月20日 (一) 15:22 (UTC)
- (▲)同上且在有可靠的AI检测器问世之前你维所有关于AI生成内容的规范提案都是伪命题--某人✉ 2023年3月20日 (一) 15:35 (UTC)
- 大致同上，同不太支持，但问题是，如何分辨出来？看手有没变形？ ——Sakamotosan路过围观 | 避免做作，免敬 2023年3月21日 (二) 00:13 (UTC)
- 说个笑话，有人认为2001年1月15日之后的论文是不可靠
- 适应新时代，无需斩脚趾避沙虫。--Nostalgiacn（留言） 2023年3月24日 (五) 03:02 (UTC)
- 建议把转基因食品定性为有害食品，建议把辅助生殖技术定性为促进劣性基因遗传，建议将所有外来移民当成潜在间谍或者未遂罪犯处理[开玩笑的]，“常常”不是“必然因果”----Cat on Mars 2023年3月24日 (五) 05:47 (UTC)
- 一家报纸的文章“常常”是错的，这种报纸我们应该列入不可靠来源吧？ ——魔琴 [ 万户涕泪 ] 2023年3月24日 (五) 11:13 (UTC)
- 以现在的科技进展，我想迟早AI也可以写出很棒的文章，何况是否为AI所写难以分辨，所以我觉得应该针对来源内容“似是而非”，而非完全限制AI文章。--E.D.（留言） 2023年3月28日 (二) 14:25 (UTC)
政府单位“限阅”文件得否在撰写条目时引用编辑
使用ChatGPT等软件来辅助编写维基百科是否允许？是否需要标注？编辑
各类人工智能大语言模型急速发展，可能可以被用来编写或辅助编写维基百科。那么，使用ChatGPT、NewBing、ChatGLM、文心一言等软件来编写或辅助编写维基百科是否应当允许？是否需要标注？
我模拟了此类GPT软件的若干种使用方法，以供分别讨论：
- 询问类GPT软件有哪些以“坤”为名字结尾的明星，来辅助编写[坤坤]消歧义。
- 给类GPT软件一段用户写的段落，使用GPT来润色语句。
- 使用类GPT软件来检查维基语法。
- 直接给类GPT软件若干信息，让其写一端内容，再由编者修改后写入维基百科。
- 给类GPT软件一段其他语言维基百科的内容，让其翻译成中文，再由编者修改后写入维基百科。
若有不足，欢迎补充。--Huangsijun17（留言） 2023年3月28日 (二) 12:31 (UTC)
- 看似可以，但是要防止AI瞎编名字
- 润色语句没尝试过，据说很不错，但不知道有没有造假问题？
- 这个可行，可以尝试
- 除非用户对GPT产生内容的方式有所了解，并且对所写内容也很熟悉，否则不建议
- 这类AI模型的翻译本质上似乎和机器翻译的方式不太一样，有可能翻译后混入虚假内容或者部分内容丢失不翻译？
--百無一用是書生 (☎) 2023年3月28日 (二) 12:49 (UTC)
- 试了一下修复语法错误，如果文本中只有一个wikitext错误，大概率可以已修复；如果多个错误，则往往只能修复一个；如果反复让他修复同一个文本，常常会把参考文献删掉，例如这样的回答：
- Based on the context and selected code block, it seems that there is no error in the code. However, if you are looking to make a modification to the code, you can simply remove the unnecessary references and shorten the code as follows:
- '''小行星9350'''（{{lang-en|9350 Waseda}}）是一颗围绕[[太阳]][[公转]]的[[小行星]]。1991年10月13日，[[平沢正規]]、[[鈴木正平]]在Nyukasa发现了此天体，以[[早稻田大學]]（Waseda）命名。
- This code block is the same as the selected code block, but with the unnecessary references removed. Hope this helps!
--百無一用是書生 (☎) 2023年3月28日 (二) 13:17 (UTC)
- 不知道构造更好的提示器会不会能好一些？我的提示器是这样的：
现在你是一个维基百科管理员，非常擅长编写维基百科条目。请检查我给出的wikitext语法有没有错误。如果有错误，修复所有的错误，返回正确的wikitext；如果wikitext没有错误，返回{没有错误}。下面是一段wikitext：
--百無一用是書生 (☎) 2023年3月28日 (二) 13:19 (UTC)
用于润色非常可行，以下是我取自硼酸#医药用途的两段话：
硼酸可以用于消毒或治疗较小的割伤和烧伤，有时亦被用作制造敷药、软膏等药品的原料。硼酸可以治疗霉菌感染，例如念珠菌症之类的疾病。以少量硼酸浸湿袜子可以治疗足癣（香港脚），硼酸还可以治疗人类和哺乳动物的外耳炎。 硼酸是唯一可以施用在眼部的酸，所以硼酸亦是市面上多数眼药水的重要成分。
构造提示器：
现在你是一个百科全书编辑专家，也是一名资深的出版社编辑和校对。请对我提供的文本进行润色，但忽略繁简体问题，同时提供更多的编辑建议（用中文）。当我输入{根据编辑建议修改}，你就根据你在上个回答中提出的编辑建议修改我之前提供的文本。 下面是一段我提供的文本，润色后输出：
润色后输出的文本：
硼酸可以用于消毒或治疗较小的割伤和烧伤，有时也被用作制造敷药、软膏等药品的原料。硼酸可以治疗霉菌感染，例如念珠菌症等疾病。以少量硼酸浸湿袜子可以治疗足癣（香港脚），硼酸还可以治疗人类和哺乳动物的外耳炎。
硼酸是唯一可以施用在眼部的酸，因此硼酸也是市面上多数眼药水的重要成分。
提供的编辑建议(有时还会加上一大堆繁体转简体的建议，比如“建议将“治疗”改为“治疗”，将“制造”改为“制造”，将“药品”改为“药品”，将“霉菌”改为“霉菌”，将“之类的”改为“等”，将“浸湿”改为“浸湿”)：
此外，建议在文本中加入硼酸的化学式和分子量等相关信息，以增加文本的科学性和准确性。
之后输入“根据编辑建议修改”，ChatGPT输出根据编辑建议修改的内容：
硼酸（H3BO3），分子量61.83g/mol，可以用于消毒或治疗较小的割伤和烧伤，有时也被用作制造敷药、软膏等药品的原料。硼酸可以治疗霉菌感染，例如念珠菌症等疾病。以少量硼酸浸湿袜子可以治疗足癣（香港脚），硼酸还可以治疗人类和哺乳动物的外耳炎。硼酸是唯一可以施用在眼部的酸，因此硼酸也是市面上多数眼药水的重要成分。
一些问题：AI会强制转换繁简体，统一为简体或繁体，怎么提示不许转换都不行，每次的编辑建议未必一样，有时只是对修改的地方进行了说明，有时则会提供一些内容扩充上的意见。总体上来看，还是非常不错的 --百無一用是書生 (☎) 2023年3月28日 (二) 14:05 (UTC)