社区专页是为用户讨论编辑相关话题设立的。用户也可以在对应页面、用户的讨论页讨论。在发言后请记得添加~~~~签名。
请了解,Minecraft Wiki在共识系统上运作而不是投票决定,清楚地阐述自己的理由比简单地支持争论的一方更有效。
Minecraft Wiki不是客户服务中心!游戏问题请移步Minecraft帮助中心或者玩家游戏社区。
所有在该页面上发表的无关话题都将被存档至无意义话题处。
语言
- 快捷方式
- MCW:CP
- MCW:PORTAL
- MCW:社区
- 最新Wiki新闻
- 2023年8月31日 - 中文Minecraft Wiki确定将迁移至Weird Gloop(议题原文)。
- 2023年7月4日 - 英文Minecraft Wiki公开发布了关于Minecraft Wiki是否要从Fandom迁移至别的站点的讨论(链接)。
- 2023年6月1日 - 新的巡查员Siiftun1857上任。
- 2023年5月4日 - 中文Minecraft Wiki使用的MediaWiki版本已升级至1.39。
- 2023年1月31日 - 新的管理员Anterdc99上任。
制作了总讨论页的顶端目录
本人制作了用于总讨论页的顶端目录,可以方便的查看当前存在的论题及相关信息,具有多种的标记功能(功能一看就懂就不赘述了),效果如下。
如觉得不错可考虑应用于Minecraft Wiki:社区专页和Minecraft Wiki:管理员告示板的header中。--Star Zero · 维基假期中 2021年4月3日 (六) 07:13 (UTC)
- 问题:就目前来看此模块仍存在较多影响正常使用的问题,因此暂持保留意见。MysticNebula70 T 2021年4月3日 (六) 07:53 (UTC)
- 问题已全部解决。--Star Zero · 维基假期中 2021年4月4日 (日) 04:05 (UTC)
- 根据你的成果重写了模块,如测试无问题且无异议即可将其转正。MysticNebula70 T 2021年4月4日 (日) 13:36 (UTC)
- 感谢猫猫的协助。--Star Zero · 维基假期中 2021年4月6日 (二) 14:42 (UTC)
- 另此模板还需要修改讨论通过论题后的颜色,原通过模板背景颜色与24小时内更新颜色不易区分。--Star Zero · 维基假期中 2021年4月6日 (二) 14:42 (UTC)
重新规划生物分类
由于生物分类异常混乱且缺乏规则,我一点时间整理了这些内容。然而,介于这是一个不小的变动,对先前分类方式的完全颠覆,我希望在大动干戈之前能够先取得社区共识。
草稿已经提交至沙盒,包含对生物条目和{{Entities/content}}的更改。
这个变更的主要内容是将生物分类由被动型/中立型/敌对型这三大类改为友好生物/敌对生物这两类,抛弃中立型类别并将其中的生物送入前两个大类的子分类。
如果达成共识,那么所有生物条目的infobox内的生物类型也会更新,并且在这一方向将不再与En看齐。--Magnussiiftun1857[T/C/E] 2021年4月5日 (一) 07:29 (UTC)(最后编辑于2021年4月5日 (一) 13:24 (UTC))
- 支持对生物分类进行变更, 较反对全部改变到新分类方式。先不论文章实际内容(因为反正总得有个标准),抛弃中立型合并到其他类别的变更会给读者造成直觉阻碍。虽然很多页面都要说“中立型和敌对型”,然后再去除中立型里面的动物,确实造成了表意赘余,但是除了这种赘余之外,是否还有更多需要改动的必要?
此外,两个分类方式是否有源代码层面的依据?目前的提案应该是来源自声音事件分类,但是这似乎不能说“就和源代码层面对Mob的处理”完全一致。如果有人能基于某一套反混淆(我建议yarn或者Mojmap)给出相应的依据,我觉得会更清晰一些。--
Lakejason0(论•功) 2021年4月5日 (一) 07:41 (UTC) - 问题:友好生物/敌对生物如何判定?这只能主观判定吧。-- Dianliang233 T•C
2021年4月5日 (一) 08:33 (UTC)
- per myself,根据sounds.json内的声音事件类别。--
Lakejason0(论•功) 2021年4月5日 (一) 08:37 (UTC) - 标准的选择其实相当多……不过我倾向于,将是否被进度“怪物猎人”和“资深怪物猎人”追踪,视为目前的决定性标准。
实际上,友好生物和敌对生物分类的内容来自先前的被动型和攻击型,区别只有多了原本归类于中立型的生物。--Magnussiiftun1857[T/C/E] 2021年4月8日 (四) 18:05 (UTC)
- per myself,根据sounds.json内的声音事件类别。--
- 关于区分友好生物和敌对生物,游戏里本身也分不清楚(比如可以蜇人的蜜蜂属于友好生物,猪灵属于敌对生物,北极熊在Java版算友好生物在基岩版却算敌对生物),所以我个人还是赞成保留现有的区分方法。--Lxazl5770zh.admin(论 ▪ 功) 2021年4月13日 (二) 02:51 (UTC)
现有分类方式确需改进 不建议这样更改。很多读者可能已经习惯了现有的分类方式,这样更改会使一些人难以接受。我认为基于现有的分类方式上进行合理的更改会更好。--Endearing Cat(讨论) 2021年4月15日 (四) 13:55 (UTC)
提议修改格式指导,以及再次更新Message box样式
下列有关更新模板的讨论已经结束,请不要再编辑此段。任何想要进一步探讨的编辑者应该新建一个话题。
讨论结果为 同意更新。
目前中文wiki的msgbox是放在infobox之后的,这并不符合大多数wiki的主流布局。我建议按照多数wiki的做法来,先msgbox然后infobox,并修改格式指导。
然后,目前的msgbox样式不能适应以上的调整,需要相应修改。大致需要更改的内容有:
- 将所有非mini的msgbox统一宽度;
- 增加msgbox的外边框;
- 两个相邻的msgbox取消间隔;
- msgbox内的文本改为左对齐。
另外,msgbox可以使用预设的颜色(目前有7个:red、orange、yellow、green、blue、purple和magenta),以不同的颜色表示不同类型的信息(如红色表示需要立即执行的操作,橙色表示页面有内容方面的问题,等等),同时仍然支持自定义颜色。
此处可以预览新样式。
现在此征询社区的意见。MysticNebula70 T 2021年4月16日 (五) 12:24 (UTC)
- 支持。不过和英文的差别还是很大,和正经Ambox的差距倒是很小。--
Lakejason0(论•功) 2021年4月16日 (五) 14:07 (UTC)
- 大部分 支持。只不过那个灰色的border我不大喜欢。-- Dianliang233 T•C
2021年4月16日 (五) 14:11 (UTC)
- 需要修改的还有消歧义模板。正常的顺序为消歧义-讯息框(msgbox)-信息框(infobox)。
- 对于预设颜色,我建议使用type(模式),每个模式对应一种颜色,然后选择模式。以及我个人建议不同名字空间设置不同样式。
- 对于文本左对齐,我认为现在mcw的讯息框宽度太小了,居左可能不太好看,如果要居左最好宽度拉长点,视具体情况而定。--Star Zero · 维基假期中 2021年4月16日 (五) 14:12 (UTC)
- 支持,预览看着不错。不过调换很多页面的顺序确实是个很麻烦的工作。。--Snow dash(论 & 功) 2021年4月16日 (五) 14:14 (UTC)
- 同意,新样式挺好看--Lxazl5770zh.admin(论 ▪ 功) 2021年4月16日 (五) 15:35 (UTC)
目前有部分成员提出不添加灰色边框。对此条建议有其他看法的请在此回复。MysticNebula70 T 2021年4月17日 (六) 11:33 (UTC)
- 移除了灰边框,效果请自行对比。MysticNebula70 T 2021年4月20日 (二) 10:28 (UTC)
预设颜色的用途
各个预设颜色的使用场合是什么?有关想法请在此提出。对配色本身有意见也在此提出。MysticNebula70 T 2021年4月17日 (六) 02:26 (UTC)
- 忽然才意识到这些配色在我的显示器上很素,很暗。如果改的更亮一点呢?--
Lakejason0(论•功) 2021年4月17日 (六) 03:40 (UTC)
目前英文wiki选取的颜色用途:
- red:disclaimer和提删;
- purple:建议页面移动、拆分、合并;
- orange:页面存在内容问题;
- yellow:页面存在格式问题;
- green:标记页面的其他状态(例如
是stub、正在编写中); - blue:标记版本相关(例如版本独有、将在下个版本添加);
- magenta:未使用/自定义。
以上内容可供参考。
另:若按照type来选取颜色,则仍然需要确定一些预设的type用来对应颜色。如果同意使用type,可在此提议type。MysticNebula70 T 2021年4月17日 (六) 11:43 (UTC)(最后编辑于2021年4月17日 (六) 12:31 (UTC))
- 建议:新增颜色
gray,用于表示丢失(如{{Lost version}}、{{Lost pre-reupload}})、未发布(如{{Unreleased}})或者可能不存在(如{{Unproven}})的版本。--Ultim 0 ( VIEW | TALK | CONT ) 2021年4月17日 (六) 12:21 (UTC)(最后编辑于2021年4月17日 (六) 12:39 (UTC)) - 这样的
type咋样:- red->important
- purple->pageaction
- orange->problem
- yellow->notice
- green->pagestatus
- blue->version
- --
Lakejason0(论•功) 2021年4月17日 (六) 12:44 (UTC)(最后编辑于2021年4月17日 (六) 12:45 (UTC))
- 不认可:都不怎么样,行为和程度混杂,单词和双词混杂,而且和用途不搭,建议全部重定。--Star Zero · 维基假期中 2021年4月19日 (一) 01:40 (UTC)
- 建议方案:
| 类型(颜色) \ 名字空间 | 条目名字空间 | 文件名字空间 | 讨论名字空间 |
|---|---|---|---|
| delete(red) | 请求删除 | ||
| move(purple) | 移动、拆分和合并 | 移动和重命名 | 合并,拆分和重命名 |
| content(orange) | 内容问题 | 严重警告和问题 | 大部分警告和提醒 |
| style(yellow) | 格式问题 | 较轻警告和问题 | 较小警告和提醒 |
| protection(grey) | 保护 | ||
| version(blue) | 版本 | \ | \ |
| notice(default) | 条目注意 | 注意 | 通知和消息 |
- Star Zero · 维基假期中 2021年5月4日 (二) 10:43 (UTC)
| 类型(颜色) \ 名字空间 | 条目名字空间 | 文件名字空间 | 讨论名字空间 |
|---|---|---|---|
| warning(red) | 警告消息和请求删除 | 请求删除 | |
| move(purple) | 移动、拆分和合并 | 移动和重命名 | 合并、拆分和重命名 |
| content(orange) | 内容问题 | 严重警告和问题 | 大部分警告和提醒 |
| style(yellow) | 格式问题 | 较轻警告和问题 | 较小警告和提醒 |
| protection(grey) | 保护 | ||
| version(blue) | 版本 | \ | \ |
| status(green) | 状态 | \ | \ |
| notice(default) | 条目注意 | 注意 | 通知和消息 |
- Star Zero · 维基假期中 2021年5月4日 (二) 11:33 (UTC) (最后编辑于2021年5月4日 (二) 11:35 (UTC))
- 模板已更新,各用到msgbox模板的模板需要单独更新。MysticNebula70 T 2021年5月4日 (二) 13:28 (UTC)
是否应加入有关盔甲和工具的重定向
我最近在Wiki上进行某些条目的翻译工作时,想使用和en一样的重定向(比如说[[Diamond Armor]]和[[Iron Armor]],均会被重定向到[[Armor]]),但是发现中文Wiki除了皮革盔甲之外没有其他相关的重定向了。
如题,加入的理由有如下:
- 某些编辑者可能更倾向于输入
[[钻石盔甲]]而非[[盔甲|钻石盔甲]]; - 一些初来乍到的编辑者对Wiki是否有这样的重定向不熟悉,可能会直接输入
[[钻石盔甲]];发现Wiki上没有这样的重定向之后,为了方便此编辑者可能会输入钻石[[盔甲]],这样不符合部分读者的习惯——他们可能会在看不清楚的情况下点击“钻石”而非“盔甲”。
综上,我认为有一定的必要加入相关重定向,现在此提出意见,征求社区的共识。--AblazeVase69188(讨论 | 贡献) 2021年4月23日 (五) 14:18 (UTC)(最后编辑于2021年5月1日 (六) 03:55 (UTC))
- 如果需要的话,您可以自行添加重定向。MysticNebula70 T 2021年4月23日 (五) 14:31 (UTC)
相关重定向已全部创建,如有异议请在此提出。--AblazeVase69188(讨论 | 贡献) 2021年4月30日 (五) 15:15 (UTC)
深层绿宝石(铜、煤)矿石的相关解释需要改吗?
如题,21w17a的数据包中已经可以生成这三种矿石的深层变种,但数据包的更新内容需要和正式更新内容一起写吗?--Minesunset1030(讨论) 2021年4月30日 (五) 22:15 (UTC)
重写LootChest模块
本人受中文McWiki管理员邀请,重写LootChest模块,原模块有以下问题:
- 代码杂乱,严重过长
- 数据结构复杂,维护困难
- 运行效率低
虽然原义只是修改后端代码而不动前端显示效果,但基于以下原因,我也一并进行了重构:
- 原模块生成的表格过长,对于大表较难对应左边和上面的标尺。
- 原模块生成表格将不同结构合并为一张大表,导致浪费空间多。
- 移动端显示效果差。
因此我预计进行以下更改:
- 将数据储存方式更改为原文件的格式(JSON),其他运算全部在模块内进行,不需要人工进行编辑。
- 提高了模块运行效率,从而可以一次性生成全部结构的表格,不需要箱子战利品加载多个页面的形式。
- 对于前端输出显示效果,一个结构输出一个表格,通过flex布局的形式进行合并,从而优化查找数据方便程度和移动端显示效果。
当前重写后的模块存在以下问题:
- 由于拆分table的原因,虽然提高了查找效率,但表格不对齐对于观感有部分破坏。
- 由于重写为非人工编写的数据储存方式,可能有个别功能无法继承(大部分都可以继承)。
当前已发现的问题:
- 部分物品和全部结构名无法进行转换,将会添加转换表进行转换。
- 同一个大结构里的不同箱子结构无法归于同一个整体,这个可以人工分段解决。
- java开发版和基岩版后续会添加支持。
当前的数据储存页面:
当前的进度:
- 结构输出:指定结构 ✓
- 结构输出:全部结构 ?
- 物品输出:单个物品 X
- 物品输出:全部物品 X
当前的示例页面:
- 源代码存放:模块:Sandbox/Star00/LootChest
- 指定结构输出:project:沙盒/LootChest
- 全部结构输出:Test wiki上的沙盒页
由于未知原因,相同的代码在mcwiki上无法实现效果,因此请先前往Test wiki进行查看。
请发表重构模块的建议,感激不尽。--Star Zero · 维基假期中 2021年5月1日 (六) 14:08 (UTC)
- 没有什么更好的建议了(在群里都交流过了,但是似乎不太明朗),就 支持一下重构吧。EN那边感觉也找不到人解释。--
Lakejason0(论•功) 2021年5月1日 (六) 15:36 (UTC) - 支持重构,希望还能加入的一点就是java版和be版相同时的合并表格。--Snow dash(论 & 功) 2021年5月1日 (六) 16:16 (UTC)
- 可否考虑i18n?方便维护也方便迁移到其他wiki。--RealCuervo(讨论) 2021年5月4日 (二) 16:36 (UTC)
修改Minecraft Wiki:管理制度
- 背景
中文Minecraft Wiki现行与过去的管理员选举机制存在明显漏洞和缺陷,为某些图谋不轨的管理员施行专政封闭的管理提供了可乘之机。几年前发生过的反pow团队割裂现象,推进了管理制度的制定。但是,它反而成了管理员滥权的工具。因此,有必要重定管理员选举制度,主要是管理员与巡查员的产生办法。
- 原因
- Minecraft Wiki:管理制度的制定和后续修订均未经过社区共识审批。
- Minecraft Wiki:管理制度中所规定的“行政员保留无理由撤销管理层职务的权利””在职务到期时由行政员根据其表现决定是否刷新和延长时限”“不多于n名在职管理员对其就职提出反对”“3⁄4以上的在职管理员认可其对Wiki的贡献。”使管理员可以“钦定”管理员、巡查员的就职和任免,严重违反了wiki社区共识高于一切的基本法。
- 现今中文wiki社区环境已经成熟,共识系统可以确立,“人少”“效率低”已不是借口。
- 修改办法
见Minecraft Wiki:沙盒/Minecraft Wiki:管理制度。请善用比较功能查看差异。修改内容主要有:
- 全面摈除专制选举的陋制
- 加入管理员投票选举制度和巡查员符合要求即授予制度
- 提高了巡查员和管理员的要求
- 总结
这是社区从选举层面坚持和完善社区共识制度体系、确保wiki长治久安的必要之举,充分体现了正当性和进步性。相信通过选举制度的完善,Minecraft Wiki一定能够走出长期存在的“专制泥沼”,集中精力完善内容、添砖加瓦,再创发展奇迹。仅代表个人,不代表Fandom意见。希望得到各位的支持。-- Dianliang233 T•C
2021年5月5日 (三) 03:14 (UTC)
- 支持。我认为新的管理制度很好,提高了对管理人员申请的要求,也能有效防止“专制”的负面影响,等等。只有实行了更完善的管理制度才能让我们的Wiki变得更好。--Endearing Cat(讨论) 2021年5月5日 (三) 04:15 (UTC)(最后编辑于2021年5月5日 (三) 04:19 (UTC))
- 一个我比较担心的一点是管理员并没有CheckUser的权限——每一次都要申请职员去排除分身账号是不现实的,加上Fandom注册分身账号极其容易,因此这种理论上较好的制度可能会因为这种原因而反应不出社区共识。--
Lakejason0(论•功) 2021年5月5日 (三) 04:23 (UTC) - 同上,本人不认为只要是“自动确认用户”就享有表决权,享有表决权应该设立以下限制:
- 必须是一名自动确认用户
- 注册时间须大于3个月,且总编辑数不少于50次
- 无重大封禁记录(违反Wiki条例且拒绝改正者须永久剥夺表决权)
- 满足以上所有条件的用户才能享有表决权。
- 以及,满足以下任一条件的表决应被视为无效投票:
- 投票本身已经违反“一人一票”原则(例如重复投票和使用傀儡账号投票)
- 没有说明支持或反对原因
- 说明原因时离题或者使用不雅语言
- 投票后干扰别人的选择,例如怂恿其改变想法等
- 为了保证本Wiki的表决不受外界干扰,设立以上门槛是非常有必要的。--Lxazl5770zh.admin(论 ▪ 功) 2021年5月5日 (三) 05:18 (UTC)
- @Lakejason0和Lxazl5770:意见刚刚已由本人加入到草稿。不过作为一个“投票”而不是“讨论”,理由等还是免了吧。-- Dianliang233 T•C
2021年5月5日 (三) 06:13 (UTC)
- @Lakejason0和Lxazl5770:意见刚刚已由本人加入到草稿。不过作为一个“投票”而不是“讨论”,理由等还是免了吧。-- Dianliang233 T•C
- 支持修改管理制度。
- 但是本人也认为修改中的管理制度有上述的缺点,对表决权的拥有者的要求确实应该更高,以保证投票结果真实可信。能合理地选举出巡查员、管理员和行政员的用户应该在Wiki上活跃一段时间,对Wiki的内容和其他活跃社区成员有一定的了解,而且个人的品行也:不能让其他社区成员感到反感。
- 由此提出下列关于对享有表决权的用户的要求的建议:
- 是一名自动确认用户
- 注册时间超过三个月、总编辑数不少于70次
- 曾经在Wiki上活跃过至少一周时间
- 一个月内在Wiki上活跃过至少两天
- 30天内无被封禁记录,一年内无被重大封禁记录(防编辑冲突等特殊原因除外)
- 此外,修改中的管理制度疑似没有明确能够正式成为巡查员的条件(如管理员的“在14日内,若至少70%的参与者支持,且没有更多的真实争议,则管理员申请通过”),在此提出疑问。--AblazeVase69188(论·功) 2021年5月5日 (三) 06:31 (UTC)
- 巡查员应该是达到条件直接给予的。不过还是有些问题,我近期会修正的。-- Dianliang233 T•C
2021年5月6日 (四) 12:50 (UTC)
- 巡查员应该是达到条件直接给予的。不过还是有些问题,我近期会修正的。-- Dianliang233 T•C
- 粗略地阅读了一下新的管理制度,如果我没猜错的话,实际上是把行政员的权力架空了。--Lxazl5770zh.admin(论 ▪ 功) 2021年5月5日 (三) 15:46 (UTC)
- 先从机制说起吧。明明在行政员的职责上写着“赋予或撤销用户权限”,可是在流程上的任何地方都没显示和行政员有任何联系。按照你的流程,完全可以用一件插件来替代,而且更高效便捷,提交者和投票者的资质审查完全可以交给机器处理且不会出错。你的提案将行政员从“人”用规则束缚成了“机器”,这是对行政员的正当权利的直接损害,不可接受。
- 谈完机制谈缘由。在帮助wiki对分配权限流程是这么描述的:“如果你拥有许多管理员,你可能开始需要记录过程管理他们的行为,例如,什么时候应该保护一个页面,还是不保护它好? 你甚至可能会达到一种情况——你需要一个文件化程序来决定谁将成为一个管理员,以及应该撤销谁的管理员权利,为了应付这种情况,你不妨提拔几个用户进入“行政员”用户组(少数你最信任的用户)来管理分散提拔/撤销管理员的工作量。在一些大型wiki上,用户在被授予额外权限之前应由其他用户投票决定,而管理组则通过指控委员会调查不当行为来撤销其权利,除了最大的维基社区外,这些流程不太可能是必需的。”这其中明确指出行政员(按程序)有权限进行提拔和撤销,而投票流程也可能不是必需的。这其中也没有规定该程序需要“经过社区共识审批”,“严重违反了wiki基本法”的说法完全就是对它自身的歪曲解读。
- 在整篇提案中,你咄咄逼人地说“(现有制度)成了管理员滥权的工具”,“(wiki需要)走出长期存在的“专制泥沼”(来继续发展)”,但完全没有提供任何支撑,完全是纸上谈兵。希望你能提供实例(不是“可能性”,而是已经发生的事实和数据)来证明现有制度被滥用,为什么它与所谓的社区共识相左,它如何限制了发展(及发展的定义是什么),和为什么你的改革能确实地进行所谓的发展。
-- Powup333(讨论) 2021年5月5日 (三) 19:41 (UTC)
- 管理员和行政员确实就应该是执行社区共识的机器。请问行政员的正当权益是什么?行政员和管理员的权限,就是基于社区给予你的信任!别忘了你来自哪里!
当不当管理员应该没什么大不了的。
- 最近听说你wiki已经把社区自治列入wiki规则了?同上一条,要明白,wiki上一切用户所有的权利都是共识给予的,你的权限同样也应该是社区共识收回的。另外,help wiki作为权威参考我是绝对支持的,但是我认为某位用户用来调侃我的话也同样适用来回应你:
wiki不是可口可乐,不是全世界的wiki都有一样的制度
- 如果有“实例”的话,你我还用在这里长篇大论?为什么现有制度可能是管理员滥权的工具我已经讲的很明白了。潜在的问题就不是问题?至于你wiki管理层独裁的事实证据那倒是有。铁证都可以在一个叫做ag的用户的言辞上看到。我是后辈,这方面您比我更有经验吧?
- 个人言论,不代表Fandom。--34.92.62.159 2021年5月6日 (四) 12:40 (UTC)(最后编辑于2021年5月6日 (四) 13:23 (UTC))
- 忘记登录了,Dianliang233对此留言负责。-- Dianliang233 T•C
2021年5月6日 (四) 12:43 (UTC)
- 忘记登录了,Dianliang233对此留言负责。-- Dianliang233 T•C
- “管理员和行政员确实就应该是执行社区共识的机器”这话我就不懂什么意思了,既然这样的话我觉得可以写一个插件让它来当管理员,如果mw的运行机制允许这么做的话。至于ag,欲加之罪,何患无辞呢(可以参考ag对某位名叫MashKJo的用户发生的经历)。
顺带提一提管理制度本身就有个缺陷:没有规定管理员/行政员数量。这意味着只要实行所谓的“投票制”,理论上是可以无限增加管理员/行政员的数量的。但是我们都知道这样做只会导致权力高度分散而出现拉帮结派(或者说所谓的“多党制”)的场面,这显然不利于wiki的健康发展。--Lxazl5770zh.admin(论 ▪ 功) 2021年5月6日 (四) 13:36 (UTC)- 正是因为不可能实现才有的管理员。
- 管理员数量确实不设限,但是能做管理员的用户数量是有限的、社区自己的容忍度是有限的。-- Dianliang233 T•C
2021年5月6日 (四) 21:01 (UTC)
- 什么叫正当权益?正道权益就是能在规则下行使权利的自由。打个银行卡的比方,我有能在我账号存取钱的正当权益,银行可以设置限制说“一天最多取走一定金额”,“月底卡里必须剩余一定金额”,这也是银行的正当权利。但银行不能说“你无权自行进行存取操作”,“你必须在收到银行通知后存取银行规定的金额”。这合理吗?这不合理。你的提案完全剥夺了行政员(在常态下)行使“赋予或撤销用户权限”的自由,这就叫损害了正当权益。
- 那么现在,就轮到你来解释你的核心理念了,请你翻译翻译什么叫社区共识。社区有多广,共识又有多深?这社区是包括了上万名的读者,上千名的用户,还是目前157名的活跃用户,目前参与了当前话题讨论的6个人?共识是指全体一致,绝对半数,三分之二,或是某百分比?过去的共识能否限制未来的共识,而未来的共识又能否推翻过去的共识?最初的社会共识是否需要获得社区共识的认可,当前社区共识又能否定义未来的社区共识?你又如何证明那不是现在的情况的另一个版本呢? Powup333(讨论) 2021年5月7日 (五) 05:31 (UTC)
- 我再重申一遍,行政员“赋予或撤销用户权限”的自由,本就是我社区共识授予你的。至于需不需要收回,什么时候收回,这也是社区共识说了算的。至于你举的银行卡的例子,完全是颠倒黑白:银行卡里的钱倒是你的所有,wiki可是你的所有?
- 作为“业务熟练”的管理员,我很惊讶的是你连共识的基本概念都不清楚?是不是独裁久了忘记民主观念了?是装糊涂还是真糊涂?在此对你wiki某些管理员的业务能力提出质疑。我懒得说,自己去看wikipedia:zh:WP:共识!
- 希望阁下下次提出质疑能提出一些合理、正确、有建设性、自己点击保存按钮的时候问心无愧的问题,不要再把阁下狼狈的那一面展现给大家了。-- Dianliang233 T•C
2021年5月7日 (五) 22:47 (UTC)
- 插:请两位在讨论的过程中友善发言,不要进行人身攻击,围绕论题进行。--Star Zero · 维基假期中 2021年5月8日 (六) 01:47 (UTC)
- 我想说明的是:我提出来修改选举制度,完全就是临时起意的产物。我没有想到的是,这刺痛了某管理员的痛点,面对质疑,不但不正面回复、反思,还颠倒是非、进行诡辩。我看到了人的阴暗面。对于这种人,其心可诛。-- Dianliang233 T•C
2021年5月8日 (六) 06:19 (UTC)
- 你是不是对pow有着很大的偏见和不满?如果仅仅是这样,那么你们俩的事完全可以通过私下里沟通来解决,而不是把事情上升到全体管理层,甚至是管理制度的层面,把私仇变为公愤。--_Regera_ 2021年5月8日 (六) 08:38 (UTC)
- 再次重申:我与pow完全没有任何私人恩怨。请阁下在留言前自己确认留言是否合适,不要进一步激化矛盾。-- Dianliang233 T•C
2021年5月8日 (六) 10:23 (UTC)
- 再次重申:我与pow完全没有任何私人恩怨。请阁下在留言前自己确认留言是否合适,不要进一步激化矛盾。-- Dianliang233 T•C
- 诗云:“兄弟阋于墙,外御其侮。”请大家不要把个人情绪代入到中文Minecraft Wiki的讨论,这对管理团队甚至中文Minecraft Wiki都不利。--Ultim_0 ( USER | TALK | CONT ) 2021年5月8日 (六) 08:52 (UTC)(最后编辑于2021年5月8日 (六) 11:51 (UTC))
- 你是不是对pow有着很大的偏见和不满?如果仅仅是这样,那么你们俩的事完全可以通过私下里沟通来解决,而不是把事情上升到全体管理层,甚至是管理制度的层面,把私仇变为公愤。--_Regera_ 2021年5月8日 (六) 08:38 (UTC)
- 首先,我上述留言中,只点出了:1)你wiki管理制度有缺陷,纵容行政员钦定管理员;2)你wiki管理层在各项事物上普遍存在独裁倾向或实际行为;3)所谓管理制度本身也是钦定的产物;4)所有管理层成员都是钦定讨论出的;5)某(些)管理员(貌似)连wiki基本理论都不大了解。而没有点出:1)有人曾经滥用过管理制度,以其作为保护伞;2)所有管理层成员都有独裁钦定行为;3)我在留言最开始是假定恶意;4)所有管理层成员都尸位素餐,没有实力。平心而论,我对各位管理员和巡查员都心怀感谢:感谢你们为wiki的辛勤付出;感谢你们对我wiki经验的成长中的批评、指正和宽容。但是,某(些)管理员的丑恶面孔,大家都已经看到了……-- Dianliang233 T•C
2021年5月8日 (六) 06:52 (UTC)
- 为什么拉帮结派的情况不太可能发生,我已经阐述过了。如果说行政效率变低我倒是同意,不过人事任免的效率不大需要多快。被外界干扰已经被“投票权”的门槛挡住了。-- Dianliang233 T•C
2021年5月8日 (六) 06:24 (UTC)
应当事人要求就此折叠上述讨论。--Lxazl5770zh.admin(论 ▪ 功) 2021年5月10日 (一) 14:27 (UTC)
- 利益不相关:作为非本维基管理组,通过我在WP的认知和我在某维基担任主要管理者的经验来谈谈维基中的民主体制。
- 声明:本人不清楚本维基管理层情况,请根据实际情况实行。
- 引子
- 目前来说,对于社群民主实践最深的维基网站来说,毫无疑问是维基百科,在维基百科中有着这样的描述:
(是否是管理员)不应该有什么大不了的。
管理员没有任何高于其他用户的特权,唯能实现社群讨论所得的共识。
- 但是这并非所有维基都要遵循这样的理念,因为每个维基的现状不同,维基百科有着独特的实践条件(后文会提及),重新引用上面的引用语:
wiki不是可口可乐,不是全世界的wiki都有一样的制度
- 上面的讨论,我认为过多的使用了其他维基的条文来讨论“制度应该是怎么样的”,我认为不必过多的参考其他维基,而是从实际情况出发,我简要的谈谈实际情况中我的认知。
- 维基百科具有以下的条件:
- 维基百科编者众多
- 编者具有社群选举的参与度
- 编者有相关的选举观念
- 而到了本维基,我们就不得不思考以下几个问题:
- 管理组的人数是否需要控制?
- 毫无疑问是需要的,基于一个社群中管理员适宜的占比以及上文提到的“拉帮结派”原因,管理员应该被控制在一个数量。
- 上文电量量有说到社区会自己控制管理员的数量,但是:
- 我们的编者是否对于管理员选举有认知?
- 本维基没有维基百科长期的民主政治历史,因此本维基的编者真的有充分对于“一个人是否应该成为管理员”的认知吗?相反,由于社群较小,社群中的编者大都互相认识,由于关系亲近,对于相熟的人自然会带有自己的偏移,给予更放松的通过条件(比如说大家对于界管权限的认知)。
- 以当前Mcwiki的社群讨论环境,很有可能会发生上面的情况,且大部分社群成员对于管理员上任的重要性可能没有概念,不参与或盲目投支持票,而不考虑社群是否需要更多管理员,管理员和社群考虑的方向是有区别的,再者:
- 我们编者的人数真的足够进行通过民主投票,表现社区真正公正的共识吗?
- 实际上,维基百科由于其编辑者的众多,进行投票的人数非常广泛,而我们维基进行投票会有多少满足条件的编者参与社群投票?
- 电量量说“社群条件已成熟”,而我从我这段时间的观察来说可能未必,况且是满足条件的编者,比如,现在发投票,能有20个人参与吗?
- 如果参与投票的人数没有达到一定规模,那么投票的结果就无法反映社群意见,而可能会发生上文提到的“倾向性投票”。依据现状,很有可能没有足够的人参与到社群讨论投票中,导致投票结束无限拉长。
- 我们真的需要完全民主吗?
- 综上所述,Mcwiki完全改制可能还为时过早。让我们思考以下,当前的寡头制管理组织形式真的很不堪吗?当然不是,寡头制管理有效率高等优点,社群也有足够的空间进行民主讨论,但最大的问题是寡头制过于依靠几位管理者的道德品质与个人能力,可能会导致滥权的发生,因此要考量的是:管理组现在真的有存在滥权专制的现象吗?这就要看本维基具体情况了。
- 最后
- 其实我个人是比较欣赏社群民主体制和电量量的改革精神,我自己在管理的维基也进行过多次这方面的改革,但是这可能不太符合实际情况。
- 我本人对本提案不持有立场,内容仅供引发思考,也望电量量放下立场,思考这些内容是否合理。
- 我个人认为现阶段不必操之过急,不必直接使用投票制度而是逐渐添加管理者的限制,减少可能使管理人专制的条件,将权利逐渐分散到社群中。
- 另:如果巡查员要改为即授予制,可能要选择降低一下巡查员的权限,目前权限确实有点超过用户组应有的权限。
- Star Zero · 维基假期中 2021年5月8日 (六) 09:56 (UTC)
- 同意Star Zero的观点。之前我考虑不周,盲目地表达自己观点。中文Minecraft Wiki的社区环境确实不够成熟,而且目前管理层滥权的可能性也不大,个人认为现阶段的任务应该是努力发展Wiki与其社区成员。由于我个人对本Wiki的深层和历史情况也不是非常熟悉,所以持 中立态度。
- 不过我觉得适当提高对进入管理层的用户的要求也是合理的,但我认为沙盒中的管理制度上更改的要求未免有点高了,例如对巡查员的要求“在中文Minecraft Wiki的编辑记录达600条以上”以及对管理员的要求“在中文Minecraft Wiki的Template(模板)名字空间编辑记录达100条以上”。--AblazeVase69188(论·功) 2021年5月8日 (六) 13:06 (UTC)
- 我不知道我应该做出什么评价。
少打一点感叹号,少打一点问号,少打一点粗体。能正常说话就不要写那么多反问句。不要让越来越强烈的语气演变成咄咄逼人的攻击性。
这个话题崩溃的一塌糊涂,上头了的话就应该先去洗把脸清醒一下。--Magnussiiftun1857[T/C/E] 2021年5月8日 (六) 11:18 (UTC)(最后编辑于2021年5月8日 (六) 11:20 (UTC)) - 支持。EPIC! MC中文wiki的毒菜问题也不是一天两天了,不彻底根治的话只会持续发酵下去,没个好的,加速编者流失。不过毒菜问题真的能靠自下而上的提案让毒菜结束吗?--Kaniol233(讨论) 2021年5月8日 (六) 14:35 (UTC)
- 意见:
肉食者谋之,又何间焉?
- 私之栖于Minecraft Wiki,尚不足期年,个中条例,犹有不通,故 不予置评。--Ultim_0 ( USER | TALK | CONT ) 2021年5月8日 (六) 15:34 (UTC)
以下部分段落文字,移动自管理员告示板。
对“修改Minecraft Wiki:管理制度”话题的回应:
- 首先,恳请大家先了解一点:不是所有事物都是非黑即白(binary)的。
- 众决没错,但是要依情景而论
- 对于众决好不好,对效率有何影响,政治科学、管理学、组织行为学等都有涉及,知乎之类也有很多高论,我才疏学浅不敢高谈阔论。但是我想简单引用弗雷德·菲德勒的权变理论来解释我上述的这个论点。简要地说,工作结构的不同,需要采取不同的职务权力才能达成合适的效果,而没有完全众决一定是最好的简单的非黑即白的说法,否则上述几个学界的研究者恐怕也没有存在的必要了。当然在Wiki里行政员和管理员也都应该是普通的编辑者,不过我想在一定程度上进行仲裁对于日常运作还是有必要的。
- 中文Minecraft Wiki已经非常开放
- 就拿英语Minecraft Wiki来说,据我所知没有任何管理员推举公示的制度,而英语Wiki的规模少说有中文Wiki的10倍。本Wiki上全保护页面也已经尽量减少,就连首页也有部分片段可以开放给所有注册用户编辑,这一点上就算不是绝无仅有也是非常少的。之前的Wiki条例修订,也经过了公示咨询,绝对不存在哪个行政员、管理员一手遮天的情况。
- 所有编辑者都是善意的,包括管理员
- 提出修改管理制度也是为了Wiki的良好发展才做出的,这一点我愿意相信。但是可否请大家也相信管理员有自己的坚持也是为了Wiki的良好发展?在这里我想稍微辩护几句,对Wiki最恶意的人最该做的就是不来编辑(请不要把这句话反过来理解,编不编辑是个人的自由),而不是参与在其中“浪费”自己的时间,能参与讨论的,已经都是非常关心Wiki的同好了。如果大家都能有这个前提的话,我相信交流当中也会少一些矛盾。
- 之后的安排
- 我们会讨论修改管理制度,同时行政员、管理员的组成也会再加考虑,请各位耐心等待。
- --一名编辑者RealCuervo(讨论) 2021年5月9日 (日) 08:47 (UTC)
- 我想说的话大体上已经在编辑者QQ群里说完了,我在这里顺便补充一些需要了解的东西:WP:DEM、WP:POLL、WP:BATTLEGROUND和WP:FAITH。--Lxazl5770zh.admin(论 ▪ 功) 2021年5月9日 (日) 09:32 (UTC)
- 感谢管理的真诚回应。其他的就不多说了,决裂过的人也没必要再挽回了。--
Lakejason0(论•功) 2021年5月9日 (日) 10:23 (UTC)
- 这里指的不是电量。我甚至都不认为哪一个(只有一个例外)决裂的人是因为wiki事务才决裂的。--
Lakejason0(论•功) 2021年5月9日 (日) 10:24 (UTC)(最后编辑于2021年5月9日 (日) 10:38 (UTC)) - 讨论及决定的不是管理组,是社群本身,即本讨论。--Star Zero · 维基假期中 2021年5月10日 (一) 14:18 (UTC)
- 这里指的不是电量。我甚至都不认为哪一个(只有一个例外)决裂的人是因为wiki事务才决裂的。--
- 对于Cuervo/a2的发言我就不用说太多了;因为已经很久没有在这里编辑过了,又因为每一次出现都能被说是旧病复发,我知道我没有多少发言权。关于管理员(此处尤其指某位行政员)是否能够一手遮天的问题,我想有过遭遇的自然会知道答案。如果中文 Minecraft Wiki 真的能够做到长久以来虚无的“皿煮”的话,那我就在幕后为你们的成功庆祝吧。另外,好像看到有一名马迷成功上任了管理员,这个也一定要祝贺一下,这是坠吼的!
Minecraft Wiki Anti-* Safe House. --SkyFuInMC (DI/CO) 2021年5月27日 (四) 14:46 (UTC) from Onion Network
- 对于Cuervo/a2的发言我就不用说太多了;因为已经很久没有在这里编辑过了,又因为每一次出现都能被说是旧病复发,我知道我没有多少发言权。关于管理员(此处尤其指某位行政员)是否能够一手遮天的问题,我想有过遭遇的自然会知道答案。如果中文 Minecraft Wiki 真的能够做到长久以来虚无的“皿煮”的话,那我就在幕后为你们的成功庆祝吧。另外,好像看到有一名马迷成功上任了管理员,这个也一定要祝贺一下,这是坠吼的!
加入标签储存模块
在21w19a中Mojang加入工具加速破坏的方块相关标签后,{{ID table}}中包含标签的方块大幅度增加;且快照更改标签相关内容的频率有所提高。我希望将游戏data文件夹中标签相关的内容经过脚本整理后,储存到Wiki模块。Template:Sandbox/GameTag/doc是一个样板。用途有两点:
- 类似于模块:SpecialConversion,在
{{ID table}}的|blocktags=参数中返回涉及到的相关标签。这样便于维护,更改时只需要更新数据模块,且更新标签从无到有或从有到无的相关方块物品页面即可。 - 在标签的表格中使用。输出标签包含内容,引用的其他标签也能自动生成链接以方便页面内点击跳转,便于维护。
现就这些问题发布于社区专页:
- 是否需要更改
{{ID table}}以支持自动生成标签或提供报错分类。以提示过时的手动参数、空标签或自动合并相同标签。但技术难度很大,现有的rowspan都是手动指定的。 - 现有的输入都是手动输入,更改需要不小的编辑量,在此申请社区共识认同。
谢谢。--Snow dash(论 & 功) 2021年5月16日 (日) 02:54 (UTC)
如果改的话,顺便把基岩版的标签也弄一下?不过基岩版目前标签有亿点点乱--2190303755(T|C) 2021年5月16日 (日) 03:49 (UTC)
BE开发版归属问题
既然允许存在这种1.16.200+的开发版包含1.17的特性,那要不要把目前1.4.0的前四个开发版(1.2.13.8·1.2.13.10·1.2.13.11·1.2.13.12)还给1.2.13,更何况1.2.13正式版也加入了对应的实验性玩法。与此同时我认为既然这样的过渡版本开发版内容已经不再属于当前的主版本号的更新主题,应该考虑为其划分出独立的定位,而不是直接放到一起。可以参考
| 版本 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 开发周期 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 资源更新 |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-Jingji132(讨论) 2021年6月4日 (五) 08:00 (UTC)
- 不建议:自1.16.200发布以来,1.16.200+正式版从未出现过“Caves and Cliffs”这个实验性玩法选项,即这些正式版不包含洞穴与山崖特性,而不像1.2.13那样,可以通过实验性玩法启用水域更新的部分特性;况且这些开发版也不全都测试洞穴与山崖特性,也有其他内容(如1.16.200.53加入光追),且会发布到正式版中,并非过渡更新;直白地说,这些开发版如同一个实验工具,用完了该放哪放哪。至于1.2.13的问题,参见:en:User talk:Ff98sha#1.3 builds don't exist (yet)。--XiaoXin666(T·C) 2021年6月4日 (五) 15:46 (UTC)
- 我的主要目的还是回过头讨论1.2.13开发版的归属问题,我认为目前的规则与1.2.13时所讨论出的规则并不相符,1.2.13那时认为的包含新内容的后续开发版都属于1.4,但它们本质上是1.2.13的开发版,甚至1.2.13正式版都加入了对应的实验性功能;而现在1.16.200+的规则认为开发版加入了新内容,即使正式版不包含对应的实验性功能,也保持从属关系。我认为这两个规则是近乎完全相反,按理应该选择其一,个人倾向于1.16这种更合乎常理。在这一前提下,我再建议考虑为那些添加新内容的开发版划分出独立区域,而非像现在这样让人以为1.16.200+是为了下界更新搞了一堆开发版,具体的形式肯定不是能直接确定下来的,我只是提供参考,为的是说明目前确实存在一定弊端。-Jingji132(讨论) 2021年6月5日 (六) 03:53 (UTC)
You'll see more 1.16 versions before seeing 1.17. Increasing the second octet is still a little ways off, even though we're still testing Caves and Cliffs features. At the end of the day, it's just a version number.
你将会在1.17发布之前见到更多的1.16版本。进一步加入新特性还要走很多路,即使我们现在仍在测试洞穴与山崖特性。最后,它只是个版本号。
- 由上可见,官方也把1.16.200+当作了版本号,从未将它们视为洞穴与山崖的版本(开发版也如此)。而且若照此划分,许多版本的归属将会变得很奇怪,1.16.201、1.16.221,以及那些没有加入洞穴与山崖特性而加入其他特性的开发版,如RTX beta、1.16.200.53、1.16.210.50等,也和洞穴与山崖有从属关系?这一弄不就更让人不解了吗?不论如何,它们本质上就属于1.16(下界更新)的次版本或开发版,即使与下界更新关联不大,只不过它们被借去当作了测试洞穴与山崖特性的工具,没必要给它们单独搞个工具箱,用完了还是要回到1.16,不然Mojang不会在正式版移除这些特性。所以我还是认为 维持现状即可。补充说明一下,我关心的是1.16.200+版本的问题,1.2.13的问题我不作讨论。--XiaoXin666(T·C) 2021年6月5日 (六) 05:19 (UTC)(最后编辑于2021年6月5日 (六) 07:13 (UTC))
- 你自始至终都没有讨论到人家的频道上去啊,Jingji132也明确指出他赞同目前1.16的版本分类现状,你“当做对方反对你的观点然后额外赘述一堆这些话”是没有必要的。他对于1.16的的观点与你是一样的,维持现状。如果不讨论1.2.13的问题,请不要发表不必要的言论。方法放寒假 (Talk - Contributions) 2021年6月6日 (日) 15:58 (UTC)
- 本人只是就“添加新内容的开发版划分出独立区域”的建议而讨论,反对拆分独立区域而已(
一开始我写的是反对拆分),不过没有想到什么好建议,只好维持现状。--XiaoXin666(T·C) 2021年6月6日 (日) 16:23 (UTC)
- 本人只是就“添加新内容的开发版划分出独立区域”的建议而讨论,反对拆分独立区域而已(
- 你自始至终都没有讨论到人家的频道上去啊,Jingji132也明确指出他赞同目前1.16的版本分类现状,你“当做对方反对你的观点然后额外赘述一堆这些话”是没有必要的。他对于1.16的的观点与你是一样的,维持现状。如果不讨论1.2.13的问题,请不要发表不必要的言论。方法放寒假 (Talk - Contributions) 2021年6月6日 (日) 15:58 (UTC)
- 由上可见,官方也把1.16.200+当作了版本号,从未将它们视为洞穴与山崖的版本(开发版也如此)。而且若照此划分,许多版本的归属将会变得很奇怪,1.16.201、1.16.221,以及那些没有加入洞穴与山崖特性而加入其他特性的开发版,如RTX beta、1.16.200.53、1.16.210.50等,也和洞穴与山崖有从属关系?这一弄不就更让人不解了吗?不论如何,它们本质上就属于1.16(下界更新)的次版本或开发版,即使与下界更新关联不大,只不过它们被借去当作了测试洞穴与山崖特性的工具,没必要给它们单独搞个工具箱,用完了还是要回到1.16,不然Mojang不会在正式版移除这些特性。所以我还是认为 维持现状即可。补充说明一下,我关心的是1.16.200+版本的问题,1.2.13的问题我不作讨论。--XiaoXin666(T·C) 2021年6月5日 (六) 05:19 (UTC)(最后编辑于2021年6月5日 (六) 07:13 (UTC))
- 赞同,无论是从发布时间来看,还是从“都是1.2.13.x”来看,还是从特性的继承性来看,1.2.13.8·1.2.13.10·1.2.13.11·1.2.13.12都属于1.2.13的测试版,而非1.4的,纵使有1.4的特性加入,但是1.2.13正式版将这些新特性重新放回实验性玩法也不足以支持“这四个版本不是1.2.13”的开发版。首先,将新特性放入实验性玩法只是改动一行代码的事情,1.2.13正式版是基于1.2.13.12而发布的;其次,将新特性放入实验性玩法其实是正确的事,正式版是正式发布的,新内容可能尚有bug,没有充分的测试自然不能当做正式特性加入游戏,不管是这些特性放入beta,还是这些特性放入实验性玩法,他们的目的都是一样的,“测试新特性”,这是合乎常理的需求,跟“1.2.13正式版的测试版到底有谁”丝毫没有关联。目前把1.2.13的四个测试版归为1.4正式版的内容据我所知有页面分类和infobox、
{{Development versions}}。希望速速更正。——方法放寒假 (Talk - Contributions) 2021年6月6日 (日) 16:00 (UTC)
命令描述页面,把“示例”挪到“效果”与“输出”之前
本主题或以下段落文字移动自MCW:管理员告示板。
如题。
当前命令介绍页面的格式大致是:语法,参数,效果,输出,示例,历史。
对于一条命令,想要查找资料的初学者,示例显然比输出更重要。把示例往上放到参数下面应该更好,这样也便于阅读者对比示例中的例子用到了上面的什么参数。
如:/clear
请自行用预览功能尝试
在读示例的时候会轻松很多,去对比参数与语法。
en版是把示例示例放最后了?算了跟我们无关……我是觉得改一下更好--Dahesor(讨论) 2021年6月7日 (一) 20:21 (UTC)
赞同:明晰而立竿见影的案例比晦涩且难以理解的说教更具动力。
收回前言:案例固然重要,但不是命令子页面的必需。--Ultim_0 ( USER | TALK | CONT ) 2021年6月8日 (二) 03:59 (UTC)(最后编辑于2021年6月8日 (二) 05:13 (UTC))- 反对。本来就是给命令提供参考的页面,对于初学者来讲是上面那么回事,其他人呢?针对不太依赖示例的人来讲,确认命令的输出更实际点。而且我也没见事情本身的特性没解释完就写例子的玩意,真那么写的多半都给人一种莫名其妙编排混乱的感觉。至于对比,我觉得开MC手写命令去对比更实际点,而且实践一直都是学习的方法之一。顺带提一句,命令介绍页本身就不是放教程的地方。——IcyPhantom 讨论I贡献 2021年6月8日 (二) 04:35 (UTC)
- 反对。首先明确“命令”下面的子页面是手册页性质的,而不是教程性质的。而无论什么手册页,示例都是放在最后,或者干脆不放示例。
- 就比如,在runoob上描述函数的顺序就是“描述”(对应“导言”),“声明”(对应“语法”),“参数”,“返回值”(对应“效果”和“输出”)和“实例”(对应“示例”)。
- 在man7(甚至没有示例)或者其他地方的类似内容基本也是同样的顺序。
- 另外,我 同意IcyPhantom的意见。--
Anterdc99(论·功) 2021年6月8日 (二) 04:51 (UTC)(最后编辑于2021年6月8日 (二) 04:58 (UTC)) - 这是坏的,因为抄示例不会让新手变的更强……虽然大部分新手很可能没有耐心看完语法。嘛,也算是一种矛盾,本来之前准备写如何阅读命令相关页面的教程的,但是不太好写就咕了,嗯。以及个人意见,新手要用好命令页面,绝不应该一上来就往示例里面看。--
Lakejason0(论•功) 2021年6月8日 (二) 05:23 (UTC)
- 顺便我们有一个东西叫做目录,如果新手想看的话完全可以直接点目录就是。虽然我们都知道就算目录摆在那里我们也一次都不会点(真是矛盾)。--
Lakejason0(论•功) 2021年6月8日 (二) 05:28 (UTC)
- 顺便我们有一个东西叫做目录,如果新手想看的话完全可以直接点目录就是。虽然我们都知道就算目录摆在那里我们也一次都不会点(真是矛盾)。--
- 反对。不管是技术类教科书还是指导书还是其余的手册/教程性质的文本,都只有两种排版方式:1. 根据示例来讲效果;2 列举效果最后放个例子。MCW的命令子页面很明显不适合第一种(第一种的页面应该归到教程的子页面)。对于初学者不想看“效果”与“输出”的话可以直接跳到最后看示例,但是根据内容完整度或连贯度来看,示例不应该提前。
(我甚至想把示例直接删掉)。——方法放寒假 (Talk - Contributions) 2021年6月8日 (二) 05:24 (UTC) - 留言。好吧,那既然大家都反对,我就放弃辩论啦--Dahesor(讨论) 2021年6月8日 (二) 05:32 (UTC)
关于“你知道吗”段落的规范化
目前“你知道吗”段落内容泛滥,是时候要加以规范了。这是en搬运来的格式指导,不知各位的意见如何。--Lxazl5770zh.admin(论 ▪ 功) 2021年6月8日 (二) 15:48 (UTC)
- 支持,这个指导内容很详细明确。--Snow dash(论 & 功) 2021年6月8日 (二) 15:50 (UTC)
- 提醒:这些格式指导的内容与MCW:SG/F#你知道吗大致相同,只是未见规范效果。--葉月 桐§ 2021年6月8日 (二) 15:56 (UTC)
fandom INTERNAL_SERVER_ERROR, 500
我之前在试用wiki的新皮肤fandomDesktop,发现参数设置里还有第三个皮肤,是mobile开头的。 选上这个皮肤然后保存设置之后,就再也打不开Minecraft wiki了,任何页面都是500错误,只好通过清除cookie解除登录状态才能打开wiki。现在我重新登录后依旧是提示500。fandom什么时候能修复这个bug?有没有什么临时的解决方案(除了退出登录以外)?--207.180.203.231 2021年6月10日 (四) 17:10 (UTC)
- 终于找到解决办法了,在网址后面加上 ?mobileaction=toggle_view_mobile 之后就能进去了。fandomsb --(和上面是同一个人的)145.239.77.243 2021年6月11日 (五) 00:54 (UTC)
“开始游戏”上的一个链接过期
本主题全部或部分段落文字已移动至Talk:Minecraft Wiki。
广告
广告太多!有wiki的,还有google的。 173.255.254.49 2021年7月13日 (二) 09:33 (UTC)
- 这些广告不是我们Wiki能控制的,因为我们(包括管理员等在内)没有网站的实际控制权。您可以通过登录账号以及使用浏览器插件来减少广告的显示。--Endearing Cat(讨论) 2021年7月13日 (二) 09:41 (UTC)
更新携带版/基岩版版本记录中引用的链接
许多携带版版本页面中(例如携带版0.4.0)底部引用的修复漏洞列表由于mojang.com迁移的原因均已失效。 三种修改方案:1.使用web.archive.org,访问该页面的存档。缺点是国内无法访问 2.使用bug.mojang.com的筛选器功能,筛选出在某个版本被修复的bug。 3.从英文站上直接复制。 MinecraftPig321(讨论) 2021年7月14日 (三) 04:40 (UTC)
