缺氧 Wiki:分叉讨论

致各位《缺氧》中文玩家、缺氧中文 wiki 的使用者：

缺氧中文 wiki 在 Fandom 建站至今，已经走过了接近三年时间，看到这个 wiki 能成长到现在的规模是一件令人高兴的事情。不过，随着使用缺氧中文 wiki 的人越来越多，我们也听到了不少玩家的抱怨——主要是关于 Fandom 的访问性问题。由于网络环境原因，部分地区和运营商的用户访问 Fandom 时会遇到速度慢或打不开等困难。此外，Fandom 近年的作为也有不少值得指摘之处，包括广告投放、移动端兼容性、分叉政策变更等。不过，Fandom 提供的平台服务仍然相当可靠。

目前，缺氧英文 wiki（首页）的管理员已经开始进行向 wiki.gg 迁移的工作（其迁移投票页见此），本站的去向也亟需定夺。为此我们创建了本讨论页面。

决定是否迁移不是一件简单的事情！除了幕后的迁移工作外，迁移后的站点还需要面临关注度、搜索引擎优化等与玩家社群息息相关的问题。在此我们呼吁所有《缺氧》中文玩家尽可能地参与这次迁移讨论，以你的使用体验、所知所见在下面发表意见，并将这一页面转发给你认识的《缺氧》中文玩家！

即使不参与讨论，你也能以其他形式帮助缺氧中文 wiki！我们持有了 oxygennotincluded.wiki 域名，并会一直将其重定向至最新的 wiki 站点——现在就是 Fandom 站。请你在收藏夹里添加这一网址，并向周围人宣传它！这样，如果我们决定迁移，大家都能及时被指引到最新的站点。

本次讨论预定截止于 2024 年 6 月 2 日（北京时间）。希望各位玩家多加转发宣传，帮助我们度过这一特殊时期！缺氧中文 wiki 在此感谢大家的支持！

必读事项

参与讨论前，建议注册或登录 Fandom 账号。

发表意见时，请使用以下语法，其中尖括号（<>）与其括起的内容是可变的，其余内容请勿变更。关于意见模板的用法，详见 Template:意见。如果你不清楚如何使用语法编辑，请参见教程视频。

<之前的讨论>
# {{意见|<你的意见>}} - <留言> ~~~~

意见不是投票计数，每一条留言和意见都会被充分地纳入考虑。

如果你的方案不在下面的选项中，请在“其他选项提名”中提出。

讨论

选项1：Fandom（不分叉）

概述：不采取分叉动作，维持现状。

1.  意见 - 留在 Fandom 是维持 wiki 稳定运行的最无脑（？）解，但是访问不流畅是个大问题。所以我想 请求后面的使用者反馈一下现在的访问体验？
   我在广东的时候有遇到难以访问的情况，在北京校园网访问流畅。 Tuode（留言） 2024年5月2日 (四) 13:19 (UTC)
2.  意见 - Fandom在大中华区多地无法直连。通过浏览器开发者工具分析，页面加载项过多，拖累了访问速度。登录用户，在使用加速器后的使用体验和wiki.gg差异不大，但游客的使用体验很低。如果这些负面体验对wiki编辑者无影响，要想增加游客的阅览体验，建议在多个wiki农场建镜像站点。 Cnctema（留言） 2024年5月2日 (四) 13:42 (UTC)
3.  反对 - 登录体验不佳，Fandom中国区经营并不如意，为应对变化有必要设计预案。 低效（留言） 2024年5月3日 (五) 06:39 (UTC)
4.  中立 - 优缺点都很明显。有点在于页面体验上佳，编辑比较容易，稳定性也不错。缺点是连通性和广告问题，可以通过梯子和插件解决，但这对于用户有一定的要求。 胡西瓜(留言) 2024年5月4日 (六) 16:17 (UTC)
   1.  信息 - AdBlock 之类的插件确实能阻挡广告，但是我们不能远程操控每个访问者都装一个插件（）所以要考虑的主要是没有这些工具的用户体验。
      现在其实有一个与插件类似的解决方案——我们为登录用户提供了一个 adRemove 小工具，可以在用户设置里开启。 Tuode（留言） 2024年5月4日 (六) 09:46 (UTC)
5.  支持 - 就目前掌握的线索而言wiki.gg没有明显的访问速度优势，而国内的wiki农场或多或少存在隐患，建立镜像站点所需的技术支持目前看也是一个难点。 Phos39（留言） 2024年5月4日 (六) 16:28 (UTC)

选项2：wiki.gg

概述：迁移至 wiki.gg。

1.  支持 - 本人认为，中英文站台应当步调一致。 Clayblockunova（留言） 2024年5月2日 (四) 06:00 (UTC)
   1.  反对上述理由。中文站已经很大地独立于英文站了，他们的迁移恐怕不构成我们也迁到 wiki.gg 的主要考量。 Tuode（留言） 2024年5月2日 (四) 13:19 (UTC)
   2.  中立 - 跟随迁移后，和现在的情况不一样，中英文 wiki 似乎能够实现真正的“合流”，除文字外，图片资源等也可以直接复用。不过由于当前中文站并非从属于英文站，此后可能需要做出一些架构上的调整甚至让步。如果原站长 DDElephant 有时间参与讨论的话，也希望他分享下当初的构想。DarkSolo（留言） 2024年5月2日 (四) 16:30 (UTC)
      1.  询问 - 请问上述的“合流”是什么意思？ Tuode（留言） 2024年5月3日 (五) 03:33 (UTC)
      2.  补充说明 - 即指数据模块、文件资源的集中、统一化。具体来说，像游戏数值、游戏文本（包含各语言的本地化）、版本历史、贴图这些，一个站点理论上只需要存储一份。当前情况显然并非如此，其历史原因之一可能是：英文站在从 gamepedia 迁移至 fandom 时能够保留 Cargo 扩展，使得他们在存取数据时得以持续利用 Cargo 的特性；而中文站建立后则无权使用 Cargo 扩展，需要从头编写数据模块，最终中英文站点形成不同的路径依赖，差异性持续增大。
         鉴于 wiki.gg 支持 Cargo 扩展，可以想见英文站的团队今后会继续依赖此方式。DarkSolo（留言） 2024年5月3日 (五) 11:05 (UTC)
      3. 感谢说明，那么我 不同意上述前述意见 - 我认为游戏内数据和图片等文件资源的统一化是完全不必要的。作为例证，中文Minecraft Wiki就并未和英文站进行图片资源合流（不过一些其他语种，如西语、葡语好像有合流现象）。另外，虽然创建工作比较困难，但是我认为中文站基于 lua 的存储方式比 Cargo 灵活很多。现在让我们回头用 Cargo 感觉是重复造一个更粗糙的轮子。
         另注：显然新 MCW 的网址已经被 Fandom 拉上黑名单了，疑似有点谔谔。 Tuode（留言） 2024年5月4日 (六) 08:33 (UTC)
         1.  中立 我其实过了前期阶段以后也没那么在意 Cargo 了。之前作为 Fandom 志愿者的时候，有见到很多因为滥用 Cargo 导致性能问题的站点，但 Lua 因为学习门槛较高就相对少见类似现象。不可否认确实（由于 MC 的带头作用？）熟悉 Cargo 的 Wiki 编辑会更多一些（而且我记得之前 MC 那边为了性能因素好像也在往 Lua 方向改造？），但既然你站的基础设施已经基本建设完成并且现在还有活跃的编辑有 Lua 脚本的维护能力，确实大规模重构的是需要慎重考虑的。 DDElephant（留言） 2024年5月5日 (日) 17:54 (UTC)
   3.  中立 其实我个人作为玩家和活跃编辑时也偏好中英文站托管于同一平台并结构相似，但是主要出发点其实是跨语言链接能快速对照中英文内容（跨平台按理来说应该也能有类似功能，但总归有些限制或者需要额外的沟通成本）。 DDElephant（留言） 2024年5月5日 (日) 17:54 (UTC)
2.  支持 - 速跑。 Loriaaa（留言） 2024年5月2日 (四) 14:17 (UTC+8)
3.  中立 - 总体而言，在几个迁移选项间我也倾向于选择 wiki.gg，因为：1、广告投放少；2、wiki.gg 应该算较为成熟的 wiki 农场了，还为从 Fandom 迁出做了优化；3、没有什么额外的限制。不过我对迁移本身的效果持保留态度。迁移的一大考量是解决访问性问题，但我有点怀疑迁移之后我们能指引几成用户使用新站点，这其中有多少是因为迁移解决了访问性问题的。或许这个月内这个帖子的讨论度能作为一个参照。
   另注：我有听说部分地区 Fandom 和 wiki.gg 都完全无法访问，包括使用代理…… Tuode（留言） 2024年5月2日 (四) 13:19 (UTC)
   1.  中立 - 确实同样作为外站我觉得 wiki.gg 的访问性优势可以忽略不计：即使当前略有优势，未来如果访问量大了之后也随时可能被针对... DDElephant（留言） 2024年5月5日 (日) 17:54 (UTC)
4.  支持 - 在大中华区可以直连。加载速度比Fandom更稳定、更快。 Cnctema（留言） 2024年5月2日 (四) 13:42 (UTC)
5.  中立 - 个人体验.gg上登录并没有提升效率，同样具有加载慢、脱线问题。 低效（留言） 2024年5月3日 (五) 06:39 (UTC)
6.  中立 - 江苏地区似乎对.gg持反对意见,目前.gg在苏州地区直连已经回被跳转到反诈页面了,普通用户似乎也不会搞代理什么的.不过听说其他地区直连倒是可以访问. Charles（留言） 2024年5月4日 (六) 04:09 (UTC)
7.  询问 - 我记得泰拉瑞亚那边之前也是英文站迁到.gg以后中文站跟过去了，有人考据过一下那边中英文社区的想法么？说不定有一些参考作用🤔 DDElephant（留言） 2024年5月5日 (日) 18:05 (UTC)

选项3：灰机

概述：迁移至灰机wiki。一般情况下灰机wiki 要求著作权人对其授权内容商用，与本站当前授权协议有冲突，需要争取豁免。

1.  反对 - 实名编辑都不说，实名才能查看源代码作为编辑者实难接受……对广大玩家潜在编辑意愿的坏影响，不可估量（） Tuode（留言） 2024年5月2日 (四) 13:19 (UTC)
2.  反对 - 灰机实名编辑的要求，增加了用户编辑wiki的门槛，而Fandom允许匿名用户编辑。灰机的技术支持虽然有其特色，能更方便管理员进行管理，但对编辑wiki的普通用户体验不佳。选择该wiki农场后，可能会对本站的影响范围进一步限缩，非大陆区域的SEO搜索结果会降低。 Cnctema（留言） 2024年5月2日 (四) 14:24 (UTC)
3.  信息 - 背景历史：根据创站说明，前站长考察过灰机的页面，该站页面较少且在当时也已处于欠维护状态，此后偶有零散编辑及上传记录。DarkSolo（留言） 2024年5月2日 (四) 17:17 (UTC)
   1.  补充说明 - 这是当时的站点状况，应该和我们的迁移考虑没有关系。另有 信息：灰机缺氧维基的现任管理员为本站相关人士。 Tuode（留言） 2024年5月3日 (五) 03:33 (UTC)
4.  反对 - 灰机的商用协议不符合wiki的发展和长期运行。 低效（留言） 2024年5月3日 (五) 06:39 (UTC)

选项4：BWIKI

概述：迁移至 BWIKI。BWIKI 要求对内容使用的完全授权，与本站当前授权协议有冲突，需要争取豁免。

1.  信息 - 背景历史：根据前站长的博客记录，本站曾与BWIKI合并，包括条目导入和编辑人员的转移，合并后该站便中止维护。DarkSolo（留言） 2024年5月2日 (四) 17:48 (UTC)
2.  中立 - 虽然与灰机同样要求实名编辑，但是个人认为能用 Bilibili 账号登录体验好多了（）一个需要 注意的点是 BWIKI 的扩展性如何——尤其是有没有/能否启用 Scribunto 扩展。本站的运行极度依赖该扩展。 Tuode（留言） 2024年5月3日 (五) 03:33 (UTC)
3.  建议 - BWIKI 用户群体庞大，缺氧大 UP 主较多，有一定优势。然而协议政策需要关注。 低效（留言） 2024年5月3日 (五) 06:39 (UTC)
   1.  反对上述意见 - bilibili 的 up 主群体和 BWIKI 有什么联系吗？没太看出来（） Tuode（留言） 2024年5月4日 (六) 09:37 (UTC)

选项5：镜像站

概述：在一个或数个 wiki 农场建立镜像站。

1.  疑问 - 镜像站大概是最理想的一个方案，但是需要的技术工作也最多。我主要有两个问题想问：1、镜像站的只读怎么实现？2、镜像站的时效性如何实现？希望提出者能来描述一下。 Tuode（留言） 2024年5月2日 (四) 13:19 (UTC)
   1.  建议 - 1. 镜像站的只读，设想的是通过禁止匿名用户、普通注册用户编辑操作，只保留管理员、机器人账号进行编辑来实现。wiki各个页面的内容，会定期从主站点拷贝过来覆盖。 2. 镜像站点分为两部分进行更新：文章、模板代码/模组。需要给 BotNotincluded 项目增加新功能，在 Github Action 挂载脚本，定期执行。循环更新周期可自己定义。该部分只讨论了技术问题，其他合规问题请继续补充。 Cnctema（留言） 2024年5月2日 (四) 14:40 (UTC)
   2.  追加询问 - 我知道每个页面可以被独立保护以使得只有管理员可编辑，但我尚未了解过能否批量保护所有页面。另，若如此操作，尚未知主站点数据库是否带有保护策略信息，如果有的话每次覆盖都要重新保护一次？不知道还有没有其他办法，希望后来的用户补充信息。 Tuode（留言） 2024年5月2日 (四) 15:31 (UTC)
   3.  建议 - 如果保护页面的操作比较繁琐，则可以在从主站点同步内容至镜像站时，每次都对镜像站点各个页面的当前内容进行全覆盖。即在同步覆盖范围内，忽略任何用户此前在镜像站点上提交的编辑更新。而对于镜像站在同步过程中不会被覆盖的页面，则不做特殊处理。 Cnctema（留言） 2024年5月2日 (四) 16:36 (UTC)
   4.  支持上述方案 - 对页面逐个进行覆盖是可行的。按我观察，中文 Minecraft Wiki 的 BWIKI 镜像站也是如此处理的。需 注意这里不应使用数据库导入，因为数据库会覆盖掉编辑历史，恐违反子站的许可协议。 Tuode（留言） 2024年5月3日 (五) 03:33 (UTC)
2.  中立 - 该选项只有在主站点是建立在 Fandom 或者是 wiki.gg 等海外 wiki 平台上，并且有出现部分地区无法访问、访问限速严重时，才有必要考虑此方案。并且有几点值得注意的事： 1. 建立镜像站主要是为了改善普通非登录游客的阅读体验，因平台差异，对 wiki 编辑者的体验可能没有明显增益。2. 该选项需要wiki小组有数量相对稳定的技术支持成员，并且对开发迁站工具有足够的技术储备。 3. 对各wiki农场的平台条款需要另外研究。 Cnctema（留言） 2024年5月2日 (四) 14:56 (UTC)
   1.  补充信息 - 我个人已经见到过无法访问或难以打开 Fandom 的反馈，但不确定是否是地区性现象。看起来镜像站方案也可以作为以上迁移选项的补充措施，可以共存。确实镜像站无法改善编辑者的体验是一个局限。另有 疑问，如果镜像站仅作为只读的访问接口存在，则数量稳定的技术支持人员、对开发迁站工具的技术储备可能是不必要的？后者是为了防备主站服务提供商突然变更服务条款导致镜像失去合法性吗？ Tuode（留言） 2024年5月2日 (四) 15:31 (UTC)
   2.  补充信息 - 如不需要技术支持，则将主站内容同步到镜像站的内容，需要管理员定期手工执行。使用技术手段，仅是将此过程通过脚本自动化完成，是一种投资一次，间断维护，持续收益的逻辑。因此对于技术相关的建议，是针对有将该过程使用脚本自动化执行的需求时，需要有相关维护人员应对主站点和镜像站之间接口变动、模板依赖更新的问题而提出的。 Cnctema（留言） 2024年5月2日 (四) 16:26 (UTC)
3.  补充提问 - 一个小问题：把站点数据库上传到 GitHub 的私密仓库会违反什么许可协议吗？ Tuode（留言） 2024年5月2日 (四) 15:31 (UTC)
   1.  建议 - 将站点数据备份至Github仓库，建议先给仓库选择一个能兼容相关许可协议的开源协议。文字内容、图片、代码文件，分别放置不同目录下。目录下分别附上对应的许可协议文件。有关原游戏生产厂商相关的版权声明，需要谨慎处理。另外，Github是一个代码托管平台，对于二进制文件的差量更新能力较弱。大量将二进制文件加入版本管理，会急剧增大仓库的总大小。请尽量将文本文件交由Github进行托管。 Cnctema（留言） 2024年5月2日 (四) 16:26 (UTC)
4.  赞同 - 镜像站拥有灵活的生存效率，但是近乎独立的运行方式，技术支持和服务器支持需要考虑。 低效（留言） 2024年5月3日 (五) 06:39 (UTC)
5.  赞同 - 镜像站似乎是解决网络访问问题的最佳方式,就是需要考虑后续维护的问题. Charles（留言） 2024年5月4日 (六) 04:09 (UTC)
6.  赞同 - 镜像站可以在1d甚至7d的频率同步，使用镜像站进行一种快照方式的Wiki服务是一种不错的选择。即备份了Wiki，也可以借助镜像站点扩大我维的服务范围。 120.245.10.238 2024年5月4日 (六) 08:23 (UTC)