Minecraft Wiki

除另有声明,转载时均必须注明出处若簡繁轉換出錯,請以遊戲內為準请勇于扩充与修正内容有兴趣逛逛我们的微博沟通交流,欢迎到社区专页需要协助,请在告示板留言

了解更多

Minecraft Wiki
Advertisement

社区专页是为用户讨论编辑相关话题设立的。用户也可以在对应页面、用户的讨论页讨论。在发言后请记得添加~~~~签名。

请了解,Minecraft Wiki在共识系统上运作而不是投票决定,清楚地阐述自己的理由比简单地支持争论的一方更有效。

涉及管理员权限的相关事宜请发布于管理员告示板。涉及繁简字词转换等问题请到繁体中文问题报告中提出。

常用页面

Minecraft Wiki不是客户服务中心!游戏问题请移步Minecraft帮助中心或者玩家游戏社区。

所有在该页面上发表的无关话题都将被存档至无意义话题处。

请点击下面的“发起议题”按钮或页面上面的“添加话题”标签在页面底部发表新的议题。


语言

最新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上任。
# 话题 发言条数 参与人数 发起者 最后发言者 最后发言时间(UTC)
1 制作了总讨论页的顶端目录 6 2 star00 star00 2021年4月6日 (二) 14:42
2 重新规划生物分类 7 5 siiftun1857 Endearing Cat 2021年4月15日 (四) 13:55
3 提议修改格式指导,以及再次更新Message box样式 18 7 MysticNebula70 MysticNebula70 2021年5月4日 (二) 13:28
4 是否应加入有关盔甲和工具的重定向 4 3 AblazeVase69188 AblazeVase69188 2021年4月30日 (五) 15:15
5 深层绿宝石(铜、煤)矿石的相关解释需要改吗? 2 2 Minesunset1030 Lxazl5770 2021年5月5日 (三) 15:56
6 重写LootChest模块 8 6 Star00 RealCuervo 2021年5月4日 (二) 16:36
7 修改Minecraft Wiki:管理制度 14 7 Dianliang233 Powup333 2021年5月7日 (五) 05:16
话题

制作了总讨论页的顶端目录

本人制作了用于总讨论页的顶端目录,可以方便的查看当前存在的论题及相关信息,具有多种的标记功能(功能一看就懂就不赘述了),效果如下。

如觉得不错可考虑应用于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)给出相应的依据,我觉得会更清晰一些。-- LakeJasonFace Lakejason0) 2021年4月5日 (一) 07:41 (UTC)
 问题:友好生物/敌对生物如何判定?这只能主观判定吧。-- Dianliang233 TC 16 2021年4月5日 (一) 08:33 (UTC)
per myself,根据sounds.json内的声音事件类别。-- LakeJasonFace Lakejason0) 2021年4月5日 (一) 08:37 (UTC)
标准的选择其实相当多……不过我倾向于,将是否被进度“怪物猎人”和“资深怪物猎人”追踪,视为目前的决定性标准。
实际上,友好生物和敌对生物分类的内容来自先前的被动型和攻击型,区别只有多了原本归类于中立型的生物。--Magnussiiftun1857[T/C/E] 2021年4月8日 (四) 18:05 (UTC)
关于区分友好生物和敌对生物,游戏里本身也分不清楚(比如可以蜇人的蜜蜂属于友好生物,猪灵属于敌对生物,北极熊在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样式不能适应以上的调整,需要相应修改。大致需要更改的内容有:

  1. 将所有非mini的msgbox统一宽度;
  2. 增加msgbox的外边框;
  3. 两个相邻的msgbox取消间隔;
  4. msgbox内的文本改为左对齐。

另外,msgbox可以使用预设的颜色(目前有7个:red、​orange、​yellow、​green、​blue、​purplemagenta),以不同的颜色表示不同类型的信息(如红色表示需要立即执行的操作,橙色表示页面有内容方面的问题,等等),同时仍然支持自定义颜色。

此处可以预览新样式。

现在此征询社区的意见。MysticNebula70 T  2021年4月16日 (五) 12:24 (UTC)

 支持。不过和英文的差别还是很大,和正经Ambox的差距倒是很小。-- LakeJasonFace Lakejason0) 2021年4月16日 (五) 14:07 (UTC)
大部分 支持。只不过那个灰色的border我不大喜欢。-- Dianliang233 TC 16 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)

忽然才意识到这些配色在我的显示器上很素,很暗。如果改的更亮一点呢?-- LakeJasonFace 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
-- LakeJasonFace 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)
建议补充green,用于标示正在进行的工作以及未完成的页面。--Ultim_0 ( USER | TALK | CONT ) 2021年5月4日 (二) 10:54 (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除了皮革盔甲之外没有其他相关的重定向了。

如题,加入的理由有如下:

  1. 某些编辑者可能更倾向于输入[[钻石盔甲]]而非[[盔甲|钻石盔甲]]
  2. 一些初来乍到的编辑者对Wiki是否有这样的重定向不熟悉,可能会直接输入[[钻石盔甲]];发现Wiki上没有这样的重定向之后,为了方便此编辑者可能会输入钻石[[盔甲]],这样不符合部分读者的习惯——他们可能会在看不清楚的情况下点击“钻石”而非“盔甲”。

综上,我认为有一定的必要加入相关重定向,现在此提出意见,征求社区的共识。--AblazeVase69188讨论 | 贡献) 2021年4月23日 (五) 14:18 (UTC)

如果需要的话,您可以自行添加重定向。MysticNebula70 T  2021年4月23日 (五) 14:31 (UTC)
 支持 这种确实对新手会产生困扰,我以前也体会过hhhhh Yfohdit讨论) 2021年4月23日 (五) 17:46 (UTC)

相关重定向已全部创建,如有异议请在此提出。--AblazeVase69188讨论 | 贡献) 2021年4月30日 (五) 15:15 (UTC)

深层绿宝石(铜、煤)矿石的相关解释需要改吗?

如题,21w17a的数据包中已经可以生成这三种矿石的深层变种,但数据包的更新内容需要和正式更新内容一起写吗?--Minesunset1030讨论) 2021年4月30日 (五) 22:15 (UTC)

数据包的内容不大可能和常规内容共存,因为它已经不属于原始玩法。--Lxazl5770zh.admin) 2021年5月5日 (三) 15:56 (UTC)

重写LootChest模块

本人受中文McWiki管理员邀请,重写LootChest模块,原模块有以下问题:

  1. 代码杂乱,严重过长
  2. 数据结构复杂,维护困难
  3. 运行效率低

虽然原义只是修改后端代码而不动前端显示效果,但基于以下原因,我也一并进行了重构:

  1. 原模块生成的表格过长,对于大表较难对应左边和上面的标尺。
  2. 原模块生成表格将不同结构合并为一张大表,导致浪费空间多。
  3. 移动端显示效果差。

因此我预计进行以下更改:

  1. 将数据储存方式更改为原文件的格式(JSON),其他运算全部在模块内进行,不需要人工进行编辑。
  2. 提高了模块运行效率,从而可以一次性生成全部结构的表格,不需要箱子战利品加载多个页面的形式。
  3. 对于前端输出显示效果,一个结构输出一个表格,通过flex布局的形式进行合并,从而优化查找数据方便程度和移动端显示效果。

当前重写后的模块存在以下问题:

  1. 由于拆分table的原因,虽然提高了查找效率,但表格不对齐对于观感有部分破坏。
  2. 由于重写为非人工编写的数据储存方式,可能有个别功能无法继承(大部分都可以继承)。

当前已发现的问题:

  1. 部分物品和全部结构名无法进行转换,将会添加转换表进行转换。
  2. 同一个大结构里的不同箱子结构无法归于同一个整体,这个可以人工分段解决。
  3. java开发版和基岩版后续会添加支持。

当前的数据储存页面:

当前的进度:

  • 结构输出:指定结构
  • 结构输出:全部结构 ?
  • 物品输出:单个物品 X
  • 物品输出:全部物品 X

当前的示例页面:

  • 源代码存放:模块:Sandbox/Star00/LootChest
  • 指定结构输出:project:沙盒/LootChest
  • 全部结构输出:Test wiki上的沙盒页

由于未知原因,相同的代码在mcwiki上无法实现效果,因此请先前往Test wiki进行查看。

请发表重构模块的建议,感激不尽。--Star Zero · 维基假期中 2021年5月1日 (六) 14:08 (UTC)

没有什么更好的建议了(在群里都交流过了,但是似乎不太明朗),就 支持一下重构吧。EN那边感觉也找不到人解释。-- LakeJasonFace Lakejason0) 2021年5月1日 (六) 15:36 (UTC)
 支持重构,希望还能加入的一点就是java版和be版相同时的合并表格。--Snow dash & ) 2021年5月1日 (六) 16:16 (UTC)
 支持,见前面Sigma166/ 2021年5月2日 (日) 09:40 (UTC)
分为共有,java版,基岩版三个部分如何。--Star Zero · 维基假期中 2021年5月2日 (日) 09:57 (UTC)
 支持。--Minesunset1030讨论) 2021年5月2日 (日) 10:16 (UTC)
 支持。也许可以用{{only|je}}{{only|be}}Sigma166/ 2021年5月2日 (日) 10:41 (UTC)
可否考虑i18n?方便维护也方便迁移到其他wiki。--RealCuervo讨论) 2021年5月4日 (二) 16:36 (UTC)

修改Minecraft Wiki:管理制度

背景

中文Minecraft Wiki现行与过去的管理员选举机制存在明显漏洞和缺陷,为某些图谋不轨的管理员施行专政封闭的管理提供了可乘之机。几年前发生过的反pow团队割裂现象,推进了管理制度的制定。但是,它反而成了管理员滥权的工具。因此,有必要重定管理员选举制度,主要是管理员与巡查员的产生办法。

原因
  • Minecraft Wiki:管理制度中所规定的“行政员保留无理由撤销管理层职务的权利””在职务到期时由行政员根据其表现决定是否刷新和延长时限”“不多于n名在职管理员对其就职提出反对”“3⁄4以上的在职管理员认可其对Wiki的贡献。”使管理员可以“钦定”管理员、巡查员的就职和任免,严重违反了wiki社区共识高于一切的基本法。
  • 现今中文wiki社区环境已经成熟,共识系统可以确立,“人少”“效率低”已不是借口。
修改办法

Minecraft Wiki:沙盒/Minecraft Wiki:管理制度。请善用比较功能查看差异。修改内容主要有:

  • 全面摈除专制选举的陋制
  • 加入管理员投票选举制度和巡查员符合要求即授予制度
  • 提高了巡查员和管理员的要求
总结

这是社区从选举层面坚持和完善社区共识制度体系、确保wiki长治久安的必要之举,充分体现了正当性和进步性。相信通过选举制度的完善,Minecraft Wiki一定能够走出长期存在的“专制泥沼”,集中精力完善内容、添砖加瓦,再创发展奇迹。仅代表个人,不代表Fandom意见。希望得到各位的支持。-- Dianliang233 TC 16 2021年5月5日 (三) 03:14 (UTC)

 支持。我认为新的管理制度很好,提高了对管理人员申请的要求,也能有效防止“专制”的负面影响,等等。只有实行了更完善的管理制度才能让我们的Wiki变得更好。--Endearing Cat讨论) 2021年5月5日 (三) 04:15 (UTC)(最后编辑于2021年5月5日 (三) 04:19 (UTC))
一个我比较担心的一点是管理员并没有CheckUser的权限——每一次都要申请职员去排除分身账号是不现实的,加上Fandom注册分身账号极其容易,因此这种理论上较好的制度可能会因为这种原因而反应不出社区共识。-- LakeJasonFace Lakejason0) 2021年5月5日 (三) 04:23 (UTC)
同上,本人不认为只要是“自动确认用户”就享有表决权,享有表决权应该设立以下限制:
  1. 必须是一名自动确认用户
  2. 注册时间须大于3个月,且总编辑数不少于50次
  3. 无重大封禁记录(违反Wiki条例且拒绝改正者须永久剥夺表决权)
满足以上所有条件的用户才能享有表决权。
以及,满足以下任一条件的表决应被视为无效投票:
  1. 投票本身已经违反“一人一票”原则(例如重复投票和使用傀儡账号投票)
  2. 没有说明支持或反对原因
  3. 说明原因时离题或者使用不雅语言
  4. 投票后干扰别人的选择,例如怂恿其改变想法等
为了保证本Wiki的表决不受外界干扰,设立以上门槛是非常有必要的。--Lxazl5770zh.admin) 2021年5月5日 (三) 05:18 (UTC)
@Lakejason0Lxazl5770:意见刚刚已由本人加入到草稿。不过作为一个“投票”而不是“讨论”,理由等还是免了吧。-- Dianliang233 TC 16 2021年5月5日 (三) 06:13 (UTC)
 支持修改管理制度。
但是本人也认为修改中的管理制度有上述的缺点,对表决权的拥有者的要求确实应该更高,以保证投票结果真实可信。能合理地选举出巡查员、管理员和行政员的用户应该在Wiki上活跃一段时间,对Wiki的内容和其他活跃社区成员有一定的了解,而且个人的品行也:不能让其他社区成员感到反感。
由此提出下列关于对享有表决权的用户的要求的建议:
  1. 是一名自动确认用户
  2. 注册时间超过三个月、总编辑数不少于70次
  3. 曾经在Wiki上活跃过至少一周时间
  4. 一个月内在Wiki上活跃过至少两天
  5. 30天内无被封禁记录,一年内无被重大封禁记录(防编辑冲突等特殊原因除外)
此外,修改中的管理制度疑似没有明确能够正式成为巡查员的条件(如管理员的“在14日内,若至少70%的参与者支持,且没有更多的真实争议,则管理员申请通过”),在此提出疑问。--AblazeVase69188· 2021年5月5日 (三) 06:31 (UTC)
巡查员应该是达到条件直接给予的。不过还是有些问题,我近期会修正的。-- Dianliang233 TC 16 2021年5月6日 (四) 12:50 (UTC)
粗略地阅读了一下新的管理制度,如果我没猜错的话,实际上是把行政员的权力架空了。--Lxazl5770zh.admin) 2021年5月5日 (三) 15:46 (UTC)
  • 先从机制说起吧。明明在行政员的职责上写着“赋予或撤销用户权限”,可是在流程上的任何地方都没显示和行政员有任何联系。按照你的流程,完全可以用一件插件来替代,而且更高效便捷,提交者和投票者的资质审查完全可以交给机器处理且不会出错。你的提案将行政员从“人”用规则束缚成了“机器”,这是对行政员的正当权利的直接损害,不可接受。
  • 谈完机制谈缘由。在帮助wiki对分配权限流程是这么描述的:“如果你拥有许多管理员,你可能开始需要记录过程管理他们的行为,例如,什么时候应该保护一个页面,还是不保护它好? 你甚至可能会达到一种情况——你需要一个文件化程序来决定谁将成为一个管理员,以及应该撤销谁的管理员权利,为了应付这种情况,你不妨提拔几个用户进入“行政员”用户组(少数你最信任的用户)来管理分散提拔/撤销管理员的工作量。在一些大型wiki上,用户在被授予额外权限之前应由其他用户投票决定,而管理组则通过指控委员会调查不当行为来撤销其权利,除了最大的维基社区外,这些流程不太可能是必需的。”这其中明确指出行政员(按程序)有权限进行提拔和撤销,而投票流程也可能不是必需的。这其中也没有规定该程序需要“经过社区共识审批”,“严重违反了wiki基本法”的说法完全就是对它自身的歪曲解读。
  • 在整篇提案中,你咄咄逼人地说“(现有制度)成了管理员滥权的工具”,“(wiki需要)走出长期存在的“专制泥沼”(来继续发展)”,但完全没有提供任何支撑,完全是纸上谈兵。希望你能提供实例(不是“可能性”,而是已经发生的事实和数据)来证明现有制度被滥用,为什么它与所谓的社区共识相左,它如何限制了发展(及发展的定义是什么),和为什么你的改革能确实地进行所谓的发展。

-- Powup333讨论) 2021年5月5日 (三) 19:41 (UTC)

  • 管理员和行政员确实就应该是执行社区共识的机器。请问行政员的正当权益是什么?行政员和管理员的权限,就是基于社区给予你的信任!别忘了你来自哪里!

当不当管理员应该没什么大不了的。

——Jimmy
  • 最近听说你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 TC 16 2021年5月6日 (四) 12:43 (UTC)
“管理员和行政员确实就应该是执行社区共识的机器”这话我就不懂什么意思了,既然这样的话我觉得可以写一个插件让它来当管理员,如果mw的运行机制允许这么做的话。至于ag,欲加之罪,何患无辞呢(可以参考ag对某位名叫MashkJo的用户发生的经历)。
顺带提一提管理制度本身就有个缺陷:没有规定管理员/行政员数量。这意味着只要实行所谓的“投票制”,理论上是可以无限增加管理员/行政员的数量的。但是我们都知道这样做只会导致权力高度分散而出现拉帮结派(或者说所谓的“多党制”)的场面,这显然不利于wiki的健康发展。--Lxazl5770zh.admin) 2021年5月6日 (四) 13:36 (UTC)
  • 正是因为不可能实现才有的管理员。
  • 管理员数量确实不设限,但是能做管理员的用户数量是有限的、社区自己的容忍度是有限的。-- Dianliang233 TC 16 2021年5月6日 (四) 21:01 (UTC)
  • 什么叫正当权益?正道权益就是能在规则下行使权利的自由。打个银行卡的比方,我有能在我账号存取钱的正当权益,银行可以设置限制说“一天最多取走一定金额”,“月底卡里必须剩余一定金额”,这也是银行的正当权利。但银行不能说“你无权自行进行存取操作”,“你必须在收到银行通知后存取银行规定的金额”。这合理吗?这不合理。你的提案完全剥夺了行政员(在常态下)行使“赋予或撤销用户权限”的自由,这就叫损害了正当权益。
  • 那么现在,就轮到你来解释你的核心理念了,请你翻译翻译什么叫社区共识。社区有多广,共识又有多深?这社区是包括了上万名的读者,上千名的用户,还是目前157名的活跃用户,目前参与了当前话题讨论的6个人?共识是指全体一致,绝对半数,三分之二,或是某百分比?过去的共识能否限制未来的共识,而未来的共识又能否推翻过去的共识?你又如何证明那不是现在的情况的另一个版本呢? Powup333讨论) 2021年5月7日 (五) 05:16 (UTC)
Advertisement