有关limelight的数据去向

原limelight善后讨论
1

这是关于原limelight站点数据目前的几种方案和动向。

数据去向：

我们只会迁移limelight论坛的内容分区，包括公开区、用户区以及各隐私分区（基于不同的公益分区善后方案，也可能会包含知识库）。公益分区将由公益分区负责人单独处理善后。所有私信、站务分区的内容我们均不会迁移。具体迁移方式请参考迁移相关问题部分。

具体迁移方式有以下方案：

  1. 迁移至Futarino，作为Futarino的子分区： 也就是说，保留所有limelight的分区结构，将limelight挂载在Futarino的分区下。

  2. 与futarino合并： 同样是迁移至Futarino，本方案将合并类似的分区（例如原limelight公开区 合并到 公开区 ，原limelight用户区合并到 天空岛 ）。

  3. 以limelight的身份原地复活： 前提是有人愿意捐助服务器资源和自己的管理精力。本方案字面意义地将limelight以原样恢复，重新运营。

    可能的捐助方案有：

    • 由个人或组织捐赠服务器资源。
    • 如果各位有意愿，可以众筹维护limelight服务器。
    • 由Futarino为limelight提供服务器赞助。

  4. limelight作为Futarino的子项目：limelight保持独立，但与futarino共享服务器。也就是说，本站服务器上同时运营两个论坛项目futarino和limelight。

迁移相关问题：

对于第一、第二种方案，有以下几个问题需要讨论

  1. 分区结构如何对接： 即合并、整体迁移、或重新组织分区结构如何选择，如何进行。

  2. 是否迁移所有用户： 我们可能会删除无内容的用户。但是这样会导致旧注册帐户不一定能正常登录。

  3. 归档还是继续运营： limelight的数据可能将仅作为归档保存。或者由楼主决定是否在Futarino中继续开启讨论，或者，所有数据均继续在Futarino中正常开放。

  4. 内容是否加密/隐藏： 如果选择归档的话，可能会编写插件，将内容暂时隐藏，等待用户回归后重新打开。

  5. 社区处罚是否延续： 目前Futarino没有延续limelight的被处罚用户。若合并，是否延续limelight的社区固有处罚？

复活相关问题：

对于第三、四种方案，有以下问题：

  1. 后续管理问题： 目前的计划是 @零卡既死又活 和 @雪乃 后续将仅在社区管理上提供有限的支持。也就是说，如果选择复活方案，需要用户对limelight的管理能拿出自己的办法。

  2. 与futarino关系问题： 如果limelight以独立的名义复活，需要讨论与Futarino的关系。包括确定到底由Futarino提供赞助支持、技术支持，还是其他合作方式。

额外问题：

  • 争议用户如何处理：limelight的个别用户可能会拒绝limelight迁移其数据，或反对limelight重新运营。

  • 社群争议相关问题：3月份的争议给limelight带来了相当大的冲击，无论是迁移还是复活，这种冲击都很可能再次发生，包括可能蔓延到Futarino。

  • 社区定位与门槛：考虑到社群环境已经再次发生重大变化，无论是迁移或是复活，都要考虑limelight未来的定位以及门槛，如改为邀请制、不再开放注册等。

2 Likes
2
3

我比较喜欢第二种方案。
归档还是继续运营我觉得折中吧，就由楼主决定，内容也隐藏比较好。
社区处罚我也觉得折中比较好。
迁移用户方面，当初移到limelight的时候仍是原先账号，但是到了futarino我好像是重新创了个账号，到时候账号合并与否会不会有什么问题？
分区我觉得可以慢一点，先分到大类里，以后再慢慢分小类，或者专门标个标签这是旧limelight的哪个分区？不过我记得上次登上那个只读的limelight，好像看到了超多的分区

3 Likes
4

这个应该不会有什么问题。部分徽章可能会丢失吧。基本上帖子什么的，应该都不会丢。

合并用户是基于电子邮件的。用的是相同的电子邮件就会合并到一起来。当然能证明的话，合并完了也是可以继续合并的。

超多的分区都是后来乱的时候加的，真正作用的三个区和futarino其实是同一个结构

这个感觉和第一种方案差不多的样子？

5

这个让用户自行操作就好？

1 Like
6

怎么自行操作？

7

独立运作的话引导用户销号，迁移至futatino的话不清楚。

8

如果不直接去操作数据库，基本上办不到永久删除之。

9

方案二看上去更简洁点 至少比分区下套分区好点
有相同邮箱的进行合并 没有的话有统一账号管理然后著名来源或者直接隐藏（因为有人可能不愿意迁移）
知识库的文章有像是默认cc协议这种说明吗 有的话就按照cc协议迁移（或者建个统一账号后按cc迁移） 没有就和上面一样处理
统一账号管理的问题是后续麻烦一大堆（指原用户识别）
直接隐藏或归档我其实觉得也行 因为对于有本站账号的用户也可能会有人拒绝
或者是默认隐藏 然后相同账号的自己取消

10

这个有什么麻烦？迁移的时候，密码也会一起迁移的。

1 Like
11

我們也許可以？

12

我说的不是连用户一把迁啊
这相当于创造了一堆无使用者的账号（当然后续可能会有人使用）

13

为什么会无使用者啊

14

只继承 limelight 的数据而不继承 limelight 的争议是可以做到的吗？

15

我不能确定，不过其实争议的话，主要还是来自几个人吧…

16

那真是太可怕了。

17

其实我想的是limelight的用户量 指tl0的数量
虽然要说的话大部分账号都是有人注册的就是了
或者干脆全合并 然后默认隐藏 由用户激活了之后再显示？

18

或许…维持现状，但在本站添加到llt的跳转链接，然后llt首页公告改成“仅浏览”
似乎有点类似某些Minecraft服务器的怀旧服(世界)，玩家可以传送过去，但是不可以和世界进行任何交互

1 Like
19

感觉还是第二种比较好…
第一种的子分区感觉太臃肿了；第三种可行性感觉不太高；第四种…同时运营两个项目，感觉完全没必要吧…
合并的话可能可以加一个limelight的tag区分一下（

1 Like
20

方案3、4基本上是没可能的，个人倾向于方案2，方案1就算了，分区太多太臃肿了，

疑问：

  1. 迁移帖子时，若楼主希望迁移，但楼层中的用户拒绝迁移自己的回帖，如何处理？
  2. 楼层中具有处罚（隐藏、警告、删除等）的回帖是否迁移？迁移后如何处理其处罚？
  3. 若用户希望迁移自己在楼层里的回帖，但楼主不希望迁移自己的帖子，如何处理？
  4. 对于一个不完整的帖子（仅迁移了部分楼层），中间缺少的内容有无填充方案？（比如留下一个指向limelight的链接或者其它的什么占位符）
1 Like