反对司令

成熟小鸟
2022-03-16
39
30
思考时间
16 小时 31 分钟
23
首先要声明的一点是,笔者今天刚刚通过翠鸟社区下宣传的Minecraft服务器“发掘”到翠鸟社区,所以以下发言可能存在不客观、不理性、不中立等等情况。笔者明白在深入了解一个事物前就对其评头论足是极为愚蠢的,但作为一个社区新人,笔者迫切希望记录下接触到翠鸟社区的真实感受,并以此给各位带来启发,望各位海涵。注:以下发言不针对任何个人,不扭曲任何观点,不带有任何恶意。

一、翠鸟计划的模式——去中心化
简而言之:去中心化,不是不要中心,而是每个人都能成为中心。互联网时代,每个人都能成为信息的生产者和传播者,利用碎片化时间生产信息已然成为了一种趋势。Wiki的编写就是典型的去中心化。Wiki有运营者吗?有,负责维护硬件和软件,这和翠鸟社区的运作模式其实别无二致。任何人都可以参与运营、发起服务器周目更换的投票,便是去中心化模式的体现。

下面谈谈去中心化的优势与劣势
去中心化的优势其实很好理解,即能够有效利用每个参与者的时间与能力,将其转化为对应价值的信息输出,实现人尽其才。去中心化能大大提高信息的产量和生产信息的积极性,用户基数越高,积极性越高,由于成就感的存在,创作者是乐意将自己的信息与他人分享的,也是乐于参与到社区的建设中去的。
但这里涉及到一个用户基数与效率转化率的问题,也就是去中心化的劣势。用户基数越大,管理的难度越大,需要的运营人员也就越多,但用户中愿意担任运营人员的人却不一定成比例增长,这也是为什么有人不赞同大量新人涌入社区(这个之后讨论)。一旦用户基数超出了处理上限,就会造成社区质量下降,这是去中心化的劣势之一,也是老成员不愿看到的。这时有两种选择:鼓励更多的人成为“中心”(或放宽成为“中心”的门槛);限制新用户人数。

二、翠鸟计划的重心——社交属性
(能够联机的)沙盒类游戏,尤其是沙盒类生存游戏,是带有非常强的社交属性的。无论是Minecraft还是泰拉瑞亚(后者笔者并未实际游玩过,固以MC为例),都是沙盒类生存游戏。笔者认为,翠鸟计划下的公益服务器之所以强调“纯澈环境”,就是为了最大化Minecraft的社交属性。如果加入了地皮、领地、箱子锁等私有物品,就会在一定程度上将Minecraft变为一个竞技游戏,使得一部分社交行为缺失。笔者认为,最大化Minecraft社交属性的实例就是Vtuber圈的原生态Minecraft服务器,通过不同Vtuber(玩家)的行为的交互,假以不同视角展现出来,将社交性具象化地传达给观众。Minecraft在社交上其实可以大做文章,就连成就感都能为社交行为服务(公共建筑)。因此,通过社区结合沙盒类游戏的发展方向,是可圈可点的。

然而,无论哪一种沙盒类游戏都逃不开一个终极命题,那就是后期内容单一。Minecraft虽然可以通过各种方式弥补这点——玩家给自己找事做(修建建筑)、增加Mod(就连Minecraft官方也意识到了,因此更新了末影龙重生以延长游戏周期)——但凡事都有乏味的一天,老玩家离开老服务器是常态。即使这样,笔者也不认为频繁地开新周目、换整合包是个最优解。一方面,mc的整合包数量是有限的,mod数量也是有限的,速通可能使玩家错过优质的整合包,还会降低玩家对某个mod的新鲜感;另一方面,开新周目会重复游戏前期必要的游戏流程,笔者十分认同Bukeaton所言:
这也是绝大多数原版服务器需要以更换新周目这种形式来维持活跃的原因,我认为,这种方法没有解决根本的问题,为了一小部分新增的内容而去进行重复无趣的前期流程,前期的乐趣则需要玩家自己找方法填充。
这里笔者并不对翠鸟计划现有的两类服务器的更迭方式做过多评价,因为确实有老哥喜欢肝科技线,笔者在这里只给出Minecraft在社区构建中的背后逻辑与相关建议。
  1. 考虑到模组服比原版服在建筑与趣味性上的优势,对于内容优质的、模组丰富的整合包,不宜作为短期服务器开设,而应尽可能开设至版本过气,甚至可以和香草原版服务器相提并论。
  2. 同时开设的短期服务器不宜过多,否则将分流玩家,造成服务器资源浪费的现象。用户的需求理应得到尊重,但也要进行权衡。
  3. 鼓励用户将Minecraft中的游玩经历、心得体会分享到社区。
  4. 可以在社区开设“周目记录贴”。

三、翠鸟计划的现状
该部分不详细展开,若与事实不符请指正。
  1. 社区功能硬件强大,但主题数量较少,用户规模不大。
  2. 服务器资源优秀,但在线用户较少,时常“空载”。
  3. 用户质量高,但宣传过少,新用户难以发现翠鸟计划。
  4. 审核公平公正,但审核流程长、门槛高,新用户难以接近。
  5. QQ群分流了社区的部分功能。
  6. 对外,社区维度多元但内容稀缺,单靠社区本身不能在单领域形成强大竞争力。

四、对翠鸟计划的发展建议——非营利,但要有营销思维
AARRR.png
笔者在这里贴了一张AARRR营销漏斗模型的图,目的是为了说明营销思维的重要性。此图中,商业变现一栏可以转化为社区内容输出。
首先要说明的一点是,非营利与营销思维两者并不冲突,营销思维能够帮助我们思考出社群的不足之处以及解决之道。对于商业化社群而言,营销的目的在于谋利;对于公益性文化事业而言,营销的目的在于以人为核心,实现其最高理想与追求。

从该模型可以看出,用户从获取到自传播总共经历了五个环节。对于获客环节,笔者个人认为,所谓的小圈子、亚文化和社群规模没有太大联系,关键在于圈子的风气,而现在的用户基数显然是过少的。一方面,庞大的社区体系无人填充,优秀创作者的内容输出无人问津,由于得不到充分的肯定,进而对社区失去热情;另一方面,用户基数过少还会造成服务器资源的浪费,并使社交性下降(如果服务器在线人数过少,就不要想着有社交性了)。因此,增大用户群体规模是必需的,也是必然要发生的。为了增大用户群体规模,有以下两种选择:降低门槛或增大曝光度。
  • 对于降低门槛而言,由于与社区理念相悖,固只是一种替代性选择,目前不予考虑。
  • 对于增大曝光度而言,笔者认为是值得考虑的。就目前的门槛而言,几乎能完全屏蔽小鬼了(除非有人就是特意来捣乱)。增大曝光度造成的唯一不良影响就是审核的工作量(好像之后有新的加入方式?)。宣传时,需要注意宣传平台的用户画像,在抖音宣传和在b站宣传产生的效果将天差地别。
营销管理的实质是需求管理,包括对需求的促进与调节,即对现有用户与潜在用户的需求进行管理。根据用户对翠鸟计划的需求程度,我们可以将翠鸟计划的现有用户和潜在用户分为八个层级:负需求、无需求、潜在需求、下降需求、无序需求、充分需求、过量需求、有害需求。这里我们重点讨论潜在需求和下降需求。

1.潜在需求

(1)购买力不足型的潜在需求。
如:用户虽然没有正版游戏,但对翠鸟计划的服务器理念感同身受。
对于这一类用户,我们应鼓励其留意翠鸟社区,等待其日后购买正版游戏。
(2)适销商品短缺型的潜在需求。
如:用户对目前社区内容不感兴趣。
对于这一类用户,我们应对其展开问卷调查,并鼓励其成为社区板块内容建设的先锋者。
(3)对商品不熟悉型的潜在需求。
如:用户不了解翠鸟计划,甚至不知道翠鸟计划的存在。
对于这一类用户,我们应强调翠鸟计划的存在,通过宣传手段提升翠鸟计划的知名度。
(4)市场竞争倾向型的潜在需求。
如:用户在翠鸟计划和其他文化社区间摇摆。
对于这一类用户,可以选择直接放弃,也可以鼓励其进行体验(如:冒险模式一日游)。

2.下降需求

如:用户对服务器的热情下降,日在线时间减少。
对于这一类用户,如果原因在于游戏的生命周期,我们应通过创办活动的方式重振其热情。

五、附录&其他想法

公益性文化事业的本质特征,在于它的创造性和公益性。
公益性文化事业的创造性,是指公益性文化事业承担着一个社会文化的继承和创新职能;
公益性文化事业的公益性,是指公益性文化事业以社会效益为自身的最高追求,以提高社会的思想道德和科学文化素质为职能。

其实去中心化还有一个劣势,因为不是现阶段需要考虑的所以没有提及,那就是群体意识难以得到干预和控制。如果有人将谬误精心包装,并煽动他人以干预投票结果,其实是很考验社区的“净化”能力的。

Minecraft在社交性上其实大有可为。比如肝帝大佬们齐心协力研究整合包;比如更改玩家出生点,在不同区域形成特色功能建筑群,以此鼓励区域间的铁路建设;比如玩家共同建造公共建筑等等。

日后如果发展良好,可以尝试一些大胆创新的举动,比如邀请开服理念相同的服务器入驻。

之所以强调优质模组服的长期性,是因为模组服,尤其是科技模组居多的模组服,利用资源建造建筑的成就感更高,建造的建筑实用性更强、科技感更甚。

个人对出生点荒芜一片反而不觉得荒凉,因为这正值得人们去开拓与探索。

笔者发这篇文字不带有什么目的性,只希望能给各位带来一点启发(不知道会不会太自大)。

也希望翠鸟计划能够发展得越来越好。
 
最后编辑:

胡斯卡特

新生鸟蛋
2021-02-22
16
1
思考时间
3 小时 13 分钟
3
其实现在留下来活跃的玩家都是很佛系的,都想社区变得更好,但是不想做出太多的努力.
 
  • 支持
反馈: lhc_mo

rainsist

成熟小鸟
2020-10-08
78
38
思考时间
1 天 12 分钟
23
既视感很强,可以理解。不如具体说明一番:

门槛高意为它是留给少数人的通关奖励,空载是特性不是问题。
高度发达的硬件平台,资源庞大少数人使用,去中心化的希腊民主主义,你想到了什么?
欢迎来到翠鸟计划,意如其名。现在就开始探索吧!

另:知识有助于改良环境,忘掉你在外面一切“理所应当”的东西吧。
 
最后编辑:
  • 支持
反馈: 反对司令

反对司令

成熟小鸟
2022-03-16
39
30
思考时间
16 小时 31 分钟
23
既视感很强,可以理解。不如具体说明一番:

门槛高意为它是留给少数人的通关奖励,空载是特性不是问题。
高度发达的硬件平台,资源庞大少数人使用,去中心化的希腊民主主义,你想到了什么?
欢迎来到翠鸟计划,意如其名。现在就开始探索吧!

另:知识有助于改良环境,忘掉你在外面一切“理所应当”的东西吧。
rainsist我的理解是,拿福利、奖励来形容现有的服务器资源是不贴切的。
首先要明白加入翠鸟计划的用户的目的,他们是为了社区本身而来的,还是因为服务器资源而来的。
如果是因为后者,那就不存在奖励而言,因为这对于他们就是“理所当然”的。
而有人愿意无偿提供服务器资源,说明其心向翠鸟,更说明他希望看到翠鸟越来越好,如果把他人的好意当做是“理所当然”,其实既不合情,也不合理。
 
查看之前的回复…

rainsist

成熟小鸟
2020-10-08
78
38
思考时间
1 天 12 分钟
23
我的理解是,拿福利、奖励来形容现有的服务器资源是不贴切的。
首先要明白加入翠鸟计划的用户的目的,他们是为了社区本身而来的,还是因为服务器资源而来的。
如果是因为后者,那就不存在奖励而言,因为这对于他们就是“理所当然”的。
而有人愿意无偿提供服务器资源,说明其心向翠鸟,更说明他希望看到翠鸟越来越好,如果把他人的好意当做是“理所当然”,其实既不合情,也不合理。
反对司令公益服务器本身就不求回报。只是通过高门槛聚集起的一小批玩家而已。
如果你想回报什么, 不如多考虑工作。连自己都不能自保何谈贡献。
人生本来就是 give and take ,好一点就是 love and peace。才华要的不多,但是必须的。
 
  • 支持
反馈: 反对司令

反对司令

成熟小鸟
2022-03-16
39
30
思考时间
16 小时 31 分钟
23
公益服务器本身就不求回报。只是通过高门槛聚集起的一小批玩家而已。
如果你想回报什么, 不如多考虑工作。连自己都不能自保何谈贡献。
人生本来就是 give and take ,好一点就是 love and peace。才华要的不多,但是必须的。
rainsist我不知道您为什么得出“我想回报什么”的结论。
我并非强制要求社区成员回报什么,我仅仅是站在运营的角度,强调要将他人的好意作为运营的考量。公益服务器,是人提供的,而提供者也是个人,是人就有精神需求。
不知道您是否思考过,基于翠鸟理念的,服务器的提供者,他是乐意看到自己的服务器变得更好的,他的目的确实不是回报,但这不意味着这能成为忽视他诉求的理由。
不知道是否有人赞扬过运营者,不强制要求,但推崇拿来主义有害于社区风气。
 
最后编辑:

rainsist

成熟小鸟
2020-10-08
78
38
思考时间
1 天 12 分钟
23
我不知道您为什么得出“我想回报什么”的结论。
我并非强制要求社区成员回报什么,我仅仅是站在运营的角度,强调要将他人的好意作为运营的考量。公益服务器,是人提供的,而提供者也是个人,是人就有精神需求。
不知道您是否思考过,基于翠鸟理念的,服务器的提供者,他是乐意看到自己的服务器变得更好的,他的目的确实不是回报,但这不意味着这能成为忽视他诉求的理由。
不知道是否有人赞扬过运营者,不强制要求,但推崇拿来主义有害于社区风气。
反对司令您让我明白缄默才是正解,在此表示感谢。
 
  • 🤨
反馈: 10935336

10935336

成熟小鸟
2020-08-07
167
95
思考时间
6 天 8 小时 31 分钟
33
Mars
现在作为“中心”的人数显然是极少的。
既然如此,我们不妨用区块链网络的话来说,普通成员为节点,拥有网络实际管理权限的为超级节点。
超级节点则由普通节点票选而出,超级节点选出之后,普通节点就没事做了,正常参与交流投票即可;而超级节点则需要为整个网络服务。
那么问题来了:
  • 在我们的链形成早期,有很多质量不过关的节点加入,而我们不希望这些节点成为超级节点。
  • 在没有合理的驱动模式下,谁愿意担任超级节点。
  • 服务器处理资源无法进行去中心化,掌握该资源的节点将成为超超级节点。除非我们真的能将数据与处理资源去中心化。
  • 目前仅有一个超超级节点,没有任何超级节点。该超超级节点正在降级运行,无法很好地处理数据。
  • 在没有链上共识机制的情况下,我们如何选举出足够优秀的超级节点,来弥补超超级节点算力的不足,同时避免直连不高的超级节点导致网络环境下降。
  • 在现有的服务器处理资源实体上,超超级节点并没有进行零信任处理。
  • 而在没有零信任的情况下,超超级节点不放心让其他超级节点操作其实体资源。这决定了超级节点只能分担资源实体以为的工作。
也许我们并不缺乏对于现状的认知,而是网络处理能力受限。
  • 我们需要更多的普通节点,壮实网络的同时也能够提升发现优秀超级节点的概率。
  • 我们不需要质量太低的普通节点。
  • 我们需要更多的超级节点,但需要足够优质的超级节点。
也许基础的链上共识我们有了,只是具体的协议在哪里。

日后如果发展良好,可以尝试一些大胆创新的举动,比如邀请开服理念相同的服务器入驻。
反对司令这个是欢迎的,也不算大胆,我曾经想贡献空闲服务器来让社区成员随意开服。
此乃所谓社区。

题外话:我们的链还是比较优秀的,也许红色字和倒数第二句话在这里是不必要的。
 
最后编辑:
  • 支持
反馈: 反对司令

反对司令

成熟小鸟
2022-03-16
39
30
思考时间
16 小时 31 分钟
23
我对您的观点部分赞同。不过既然已经有了对现状的认知,就应当积极思考对策。
首先重新定义一下,超超级节点为服务器资源的实控者,超级节点为服务器资源以外的运营者,普通节点为享有基本权利的成员。
  • 在我们的链形成早期,有很多质量不过关的节点加入,而我们不希望这些节点成为超级节点。
  • 在没有合理的驱动模式下,谁愿意担任超级节点。
10935336
  1. 希望超级节点是优质的,那么就需要对应的超级节点选拔机制,在民意选举上叠加一个内部审核即可解决。
  2. 请不要妄自菲薄,请自大一些,难道您是受驱动模式的影响才担任超级节点的嘛?作为超级节点,请一定要持乐观态度,认为人人都有意愿担任超级节点。回归理性,驱动模式的缺乏的确是一个难题。在管理学上,驱动力由两种因素产生:激励与惩罚。要认识到的一点是,非营利,不代表不能盈利(当然,一切要以体验为前提,这不意味着将社区变为一个广告圣地是一个合适的选择),而这可以用于小小的激励。再者,激励不一定是物质上的,还可以是精神上的。在群和社区定期表彰超级节点的工作成果总不是什么难事吧?说句不厚道的,我还得通过头像下小小的文字才能得知您是运营组成员,有人愿意担任超级节点才怪哩!对于翠鸟计划而言,驱动模式下的惩罚,可以理解为教化。例如:有用户犯下了错误,如果是非原则性的,且有赎罪意愿的,可以考虑让其担任超级节点,“留校观察”。
  3. 驱动力还可以由理念和追求产生。如果有用户深刻理解翠鸟计划的理念,并希望践行它,那么其实是有充足的驱动力的。举一个不恰当的例子,百度贴吧的“台风吧”,是一个知识类吧。台风吧定期举行小吧主的选举,小吧主发布竞选信息,最后进行民意投票。我们这里不讨论该机制的漏洞,而是思考参与竞选者的驱动力——难道说担任小吧主有什么实质性的好处吗?显然没有。抛去小市民凑热闹的天性,可以认为,竞选者的驱动力完全来源于其对台风知识与台风吧的热爱。我不认为,翠鸟计划中缺乏这样的用户。
  • 服务器处理资源无法进行去中心化,掌握该资源的节点将成为超超级节点。除非我们真的能将数据与处理资源去中心化。
  • 目前仅有一个超超级节点,没有任何超级节点。该超超级节点正在降级运行,无法很好地处理数据。
  1. 认同该观点与现状。
  • 在没有链上共识机制的情况下,我们如何选举出足够优秀的超级节点,来弥补超超级节点算力的不足,同时避免直连不高的超级节点导致网络环境下降。
  • 在现有的服务器处理资源实体上,超超级节点并没有进行零信任处理。
  • 而在没有零信任的情况下,超超级节点不放心让其他超级节点操作其实体资源。这决定了超级节点只能分担资源实体以为的工作。
  1. 既然超级节点无法担任资源实体以外的工作,那么就需要在超级节点上进行再审核,选拔出超超级节点,即“足够优秀的超级节点”。首先要认识到什么才是“足够优秀的超级节点”——思想上认同翠鸟理念是前提,行为上恪守规则善恶分明是底线,技能上轻车熟路是加分项。
  2. 不是零信任,就靠沟通建立信任,如果沟通不能解决问题,就靠时间建立信任。
也许我们并不缺乏对于现状的认知,而是网络处理能力受限。
  • 我们需要更多的普通节点,壮实网络的同时也能够提升发现优秀超级节点的概率。
  • 我们不需要质量太低的普通节点。
  • 我们需要更多的超级节点,但需要足够优质的超级节点。
也许基础的链上共识我们有了,只是具体的协议在哪里。
那么,确定具体协议就是应该努力达成的事情了。

最后,建议在社区开设一个“开发板块”,记录下翠鸟正在推进的项目。
 
  • 支持
反馈: 10935336
查看之前的回复…

10935336

成熟小鸟
2020-08-07
167
95
思考时间
6 天 8 小时 31 分钟
33
Mars
零信任不是字面意思,而是一种安全模型。

为什么不愿意推进,首先是上面提到的,我们只有 0 个超级节点。
其次是驱动力问题,我们已陷入恶性循环,需要一些帮手来破局。

人少 → 反馈不足 → 执行力下降 → 各方面质量下降 → 人少

就好比,大澡堂就算只有 1 个人洗澡,那也得把热水器打开,而这个热水器是能够供应 100 个人。我不喜欢这样的资源浪费,虽然这几乎是必然,边际成本递减嘛。

再者是,我们社区是有 slogon 的「优雅硬核、和谐友善、相互信任、安逸舒适」的,我们必须贯彻 slogon,否则我们只会陷入同质化泥潭。
而在 slogon 之外,我们也必须贯彻“去中心化”,也就是平等,这也就是为什么:
说句不厚道的,我还得通过头像下小小的文字才能得知您是运营组成员,有人愿意担任超级节点才怪哩!
反对司令其实连这行小字都不应该有,我们也不知道限度在哪,这是需要调研的。
这很难,因为我们是有门槛的,如果要求高的节点加入后发现和说好的不一样,那他会怎么样想呢。

于是,要出方案就成了难题,在我们追求的“世外桃源”环境中,它必须足够优雅,它必须足够平等。
这样一来,有些事我们就不敢去做,或者说不能用传统的方式去做,这对脑力是一种挑战。
“超级节点应该具有什么样的权限,才能在贯彻平等的前提下能够进行一些特权操作”
超级节点在担任前就应该首先拿出方案,我们才能确定,方案是否违背社区理念,足够理解社区理念,才适合担任超级节点。
到目前为止,我还没有看到任何一个“施工方案”,我们缺少施工方案。

我们在追求“世外桃源”,但我却习惯于用社会的利益驱动来看问题,但结合其他社区的经验来看,这也是我找不到好方法去迈出腿的一点。
再一方面,这意味着要做,就要做到最好。否则只会让我们名不副实,不如不做,于是又不敢先迈出步子了,只想着一步到位。
项目管理中堆积如山的事务就很好的印证了这一点。
erPm6gHadlUIQB2.png


我知道我的想法有些问题,但我无法把握限度在哪。
那么,你和 BuKeaton 愿意担任超级节点吗?
游戏内建设者也是极度缺乏的。
同时我仍然建议去隔壁的 RIANyaacatSakuraRealm 进行调研。


题外话:
非常欢迎有不同的意见
“思维碰撞”,撞出智慧的火花。见解与批判都是推动思维进步的阶梯。
这是写在官网上的,也是我们需要贯彻的。
消极沟通,以及“摆烂”可不是什么好做法,有理有据说服对方才是正道。
 
最后编辑:
  • 支持
反馈: 反对司令

反对司令

成熟小鸟
2022-03-16
39
30
思考时间
16 小时 31 分钟
23
就好比,大澡堂就算只有 1 个人洗澡,那也得把热水器打开,而这个热水器是能够供应 100 个人。我不喜欢这样的资源浪费,虽然这几乎是必然,边际成本递减嘛。
10935336非常认同。
再者是,我们社区是有 slogon 的「优雅硬核、和谐友善、相互信任、安逸舒适」的,我们必须贯彻 slogon,否则我们只会陷入同质化泥潭。
而在 slogon 之外,我们也必须贯彻“去中心化”,也就是平等,这也就是为什么:
其实连这行小字都不应该有,我们也不知道限度在哪,这是需要调研的。
这很难,因为我们是有门槛的,如果要求高的节点加入后发现和说好的不一样,那他会怎么样想呢。
  • 对于去中心化,我想完全的去中心化只是理想化的,部分的去中心化才是符合实际的。什么样的去中心化才是合适的,确实应该深入讨论。也许去中心化也是循序渐进的,就像封建社会向现代社会制度的转变一样需要类似生产力和文化水平的因素来衡量和决定,在这里可能是效率。
  • 其实吧,我个人希望社区能够形成一种共识,或是价值观,那就是超级节点是荣誉象征而非地位之别。在这样的情境下,超级节点放下身段,平易近人地交流,不搞一言堂,问题是否简化了许多呢?
“超级节点应该具有什么样的权限,才能在贯彻平等的前提下能够进行一些特权操作”
超级节点在担任前就应该首先拿出方案,我们才能确定,方案是否违背社区理念,足够理解社区理念,才适合担任超级节点。
到目前为止,我还没有看到任何一个“施工方案”,我们缺少施工方案。
  • 有权限的限制是合理的,不过真正重要的还是超级节点是否会有意无意地滥用职权,因此需要有一个及时有效的监督反馈机制(比如打分),超级节点内部也需要拟定规则。不过权限也是一个值得确定的问题,需要深入沟通和交流,也许暂时无法得到一个完美的答案。
  • 问题就在于,普通节点在成为超级节点之前,对全局的了解是有限的,在这种情况下提出的方案,可能是局部性的,也可能是存在问题的。普通节点可能只适合提出微观上的方案,或对大方案进行细节上的完善?
我们在追求“世外桃源”,但我却习惯于用社会的利益驱动来看问题,但结合其他社区的经验来看,这也是我找不到好方法去迈出腿的一点。
再一方面,这意味着要做,就要做到最好。否则只会让我们名不副实,不如不做,于是又不敢先迈出步子了,只想着一步到位。
项目管理中堆积如山的事务就很好的印证了这一点。
  • 个人认为,利益驱动,是现阶段不得不采纳的思考模式之一,毕竟万变不离其宗,只是我不太喜欢让金钱成为起决定性作用的驱动力。也许等到推进之后,有些问题就不在是问题了(希望如此)。
  • 感同身受。人往往都有这样的毛病(如果没有请忽略),不愿看到自己的所作所为功亏一篑,因此而完美主义。不过事实上,对一个项目而言,计划和准备的阶段总是长于其他阶段,如果计划不得当,会对之后的执行产生不必要的麻烦。也许这并不是问题,而是一种良好的心态。不过话说回来,推进过程中难免出现问题,一步到位只是理想状态。
我知道我的想法有些问题,但我无法把握限度在哪。
那么,你和 BuKeaton 愿意担任超级节点吗?
游戏内建设者也是极度缺乏的。
同时我仍然建议去隔壁的 RIANyaacatSakuraRealm 进行调研。
  • 我粗略地看了一下RIA的社区和维基,他们的社区很活跃,如果我没搞错的话,他们是在Minecraft里构造城市文化。城市文化:城市社会成员在特定城市区域内,在社会实践中创造出来的为该城市社会成员所共享的物质财富和精神财富的总和。“人类所有的伟大文化都是有城市产生的。”——斯宾格勒《西方的没落》。
  • 个人认为这值得学习,不涉及到同质化与否,而是像科技发展的必进之路一样。
  • 我很乐意担任超级节点,只要是停留在爱好层面而非强制要求。毕竟这种事强制不来,也强制不得。

题外话:
您认为翠鸟和其他服务器社区最大的区别在哪里(差异化的重点)?
您希望服务器和社区的发展哪个占主导地位?服务器?社区?还是两者并重?
目前的翠鸟仍然在黑暗中沉睡,等到曙光初现,就会展翅翱翔。
 

10935336

成熟小鸟
2020-08-07
167
95
思考时间
6 天 8 小时 31 分钟
33
Mars
您认为翠鸟和其他服务器社区最大的区别在哪里(差异化的重点)?
反对司令如果是和其他成熟社区比的话
  • 我们将社区作为前提,而不是服务器,服务器是社区的附属品。
  • 我们是“去中心化”的,这让每个人都能发挥最大的价值,也更需要“智者”。
  • 更在于“多元化”的体现。
  • 更加注重版权。
  • 在于我们更注重底层逻辑,更注重为什么。
    • 在于我们更希望让人们理解为什么要这样做,它的逻辑在哪里,而不是用冷冰冰的规则来约束。
    • 我们不希望有过多的规则,但这需要人们理解为什么,需要心中有杆秤。
也许还可以挖出更多 ……

您希望服务器和社区的发展哪个占主导地位?服务器?社区?还是两者并重?
我认为服务器应当为社区服务,但服务器仍然是重点对象,毕竟那里的“内容”似乎要多一些。
建设服务器 → 产生内容 → 吸引新人 → 产生新内容 → ……
建设社区→ 产生内容 → 吸引新人 → 产生新内容 → ……


我很乐意担任超级节点,只要是停留在爱好层面而非强制要求。毕竟这种事强制不来,也强制不得。
那肯定只是爱好,又不是有合同什么的。就算想强制也是做不到的,直接走人就行。

那么既然愿意,我想知道,你有什么计划,以及需要什么样的权限来进行操作(群管理?社区管理?服务器操作员?)。


问题就在于,普通节点在成为超级节点之前,对全局的了解是有限的,在这种情况下提出的方案,可能是局部性的,也可能是存在问题的。普通节点可能只适合提出微观上的方案,或对大方案进行细节上的完善?
这个我倒是不同意,超级节点获取信息只是更方便一些。
 
最后编辑:
  • 支持
反馈: 反对司令

反对司令

成熟小鸟
2022-03-16
39
30
思考时间
16 小时 31 分钟
23
如果是和其他成熟社区比的话
  • 我们将社区作为前提,而不是服务器,服务器是社区的附属品。
  • 我们是“去中心化”的,这让每个人都能发挥最大的价值,也更需要“智者”。
  • 更在于“多元化”的体现。
  • 更加注重版权。
  • 在于我们更注重底层逻辑,更注重为什么。
    • 在于我们更希望让人们理解为什么要这样做,它的逻辑在哪里,而不是用冷冰冰的规则来约束。
    • 我们不希望有过多的规则,但这需要人们理解为什么,需要心中有杆秤。
也许还可以挖出更多 ……
10935336我想我的想法和您有些出入,这就是我提这几个问题的重要原因,而这则涉及到翠鸟计划的核心。
我认同将社区作为前提,但不认同现阶段的“服务器是社区的附属品”。原因如下:
  • 现在的社区难以脱离服务器独立存在(不是物理意义上的脱离);
  • 现在的社区很大程度上是在为服务器服务(Request);
  • 大部分用户是通过服务器了解到翠鸟计划,而非社区本身;
  • 翠鸟社区可替代性强,核心竞争力尚未形成。
建设服务器 → 产生内容 → 吸引新人 → 产生新内容 → ……
建设社区→ 产生内容 → 吸引新人 → 产生新内容 → ……
对,就是这个逻辑让我感到不安,实际上换一个角度:
社区内容不足→生产新内容→需要新人→需要宣传→现阶段社区竞争力不足→需要借助服务器宣传→需要重点建设服务器环境→社区成为服务器的“附属品”

您应该是想表达“服务器不是翠鸟的唯一内容”的看法吧。只是不管是社区、论坛还是软件,小众平台的起步都是艰难的,因此前期往往靠盗版资源吸引用户,并以此形成核心竞争力,而这与翠鸟计划的理念相去甚远。既然这条路走不通,那么依靠其他内容为社区引流便是捷径。抛开创始人的初衷,我认为其他社区以服务器为重是有原因的,因为服务器是吸引新用户的一大来源。我尚不清楚您产生此想法的原因,不过如果仅仅是差异化的考量,我的建议是这不是现阶段应该差异化的地方。兵棋社区需要兵棋,二次元社区需要ACG,游戏社区需要游戏。我的理解是,翠鸟计划下的服务器是用户共同话题的重要来源,也是构筑用户羁绊的重要载体。翠鸟计划始于服务器,也许在将来,社区完善了,讨论的话题种类更多了,Minecraft服务器在社区中的地位慢慢下降了,那么届时Minecraft服务器自然会成为“附属品”。

我并非全盘否定社区的重要性,事实上若社区能够摆脱服务器的“控制”,成为比服务器还要重要的存在,那绝对是翠鸟计划上一页崭新的篇章,但是一步到位是不可能的。
这个我倒是不同意,超级节点获取信息只是更方便一些。
主要是,我尚有很多信息没有获取到,这就是为什么我之前强调之前的发言仅仅作为启发。我不了解正在进行的项目管理中的事务,我不了解现任哨兵的担任者及准入原则/共识,我不了解即将要发生改变的加入方式的形式,我不了解翠鸟计划的历史……我对翠鸟其实是缺乏了解的,如果您可以告诉我哪些我无权过问,哪些不会影响我制定计划,哪些是可以公开的就好了。或者您觉得,我只需要提供计划,再交由您审阅即可?
那肯定只是爱好,又不是有合同什么的。就算想强制也是做不到的,直接走人就行。

那么既然愿意,我想知道,你有什么计划,以及需要什么样的权限来进行操作(群管理?社区管理?服务器操作员?)。
读了上面的留言,您可能意识到我对翠鸟的认知有限,和您的想法也有些出入,因此我下面提出的,与其说是计划,不如说是构想(由于技能水平有限,我一个人不一定搞得定)。
  1. 长期计划:建立招收和培养超级节点的长效机制及编写内部管理的规章和预案(并非冷冰冰的规则);
  2. 短期计划:推进服务器宣传的准备工作,暂时想到的是在b站建号并发布宣传片,预计今年暑假或明年年前是最佳宣传窗口期,宣传与否取决于准备工作的完成程度(如宣传片进度等);
  3. 其他计划:若宣传效果良好,我可能需要临时“借用”一台服务器——当然我会通过社区提出正式的申请,主要是有新的想法想要尝试,这个日后再说,不能也无妨;
  4. 其他计划:如果可能,推进新用户加入方式的转变(我到现在也不知道新方式是啥)。
权限的话,目前暂时用不到,等用到我再找您索要。

另:您的其他观点我没有回复,因为认同。
 

10935336

成熟小鸟
2020-08-07
167
95
思考时间
6 天 8 小时 31 分钟
33
Mars
理解了,原来是这样。


我认同将社区作为前提,但不认同现阶段的“服务器是社区的附属品”。原因如下:
反对司令实际上我想说的是,社区在服务器之前,而不是服务器在社区之前。
你加入的是社区,而不是服务器。
我想强调的是这一点,至于其他的,我想这并不冲突。
我们想要组建一个更加多元而丰富的社区,而不是仅仅是依赖 Minecraft 或是依赖于什么游戏,它只是我们兴趣圈的冰山一角,我们不仅仅是服务器玩家,更是社区的一员。


主要是,我尚有很多信息没有获取到,这就是为什么我之前强调之前的发言仅仅作为启发。我不了解正在进行的项目管理中的事务,我不了解现任哨兵的担任者及准入原则/共识,我不了解即将要发生改变的加入方式的形式,我不了解翠鸟计划的历史……我对翠鸟其实是缺乏了解的,如果您可以告诉我哪些我无权过问,哪些不会影响我制定计划,哪些是可以公开的就好了。或者您觉得,我只需要提供计划,再交由您审阅即可?
其实
  • 项目管理是给我自己看的,起因是 golfos 提到需要有一个待办列表。
  • 哨兵是早期较为活跃的 6 位成员,还活跃中的只有 2 人,仅仅是在图书馆拥有编辑通过页面的权限。这些都是后面需要重来的,不用太在意。
  • 新加入方式,当然是没想好的,不然也不会还沿用老问卷了。也许还是用问卷,但问题可能会更倾向于你对某某事物有什么样的看法之类的题,更加契合社区。
所有东西都是可以公开的,只是我们有一些顾虑,或是因为这些软件本不是我们开发的,无法做到我们想要呈现的功能亦或者是隐私问题等等。
在“去中心化”的前提下,没有您,也没有无权过问,这点请注意。大可不必这么拘谨,贯彻理念我们是认真的。

读了上面的留言,您可能意识到我对翠鸟的认知有限,和您的想法也有些出入,因此我下面提出的,与其说是计划,不如说是构想(由于技能水平有限,我一个人不一定搞得定)。
  1. 长期计划:建立招收和培养超级节点的长效机制及编写内部管理的规章和预案(并非冷冰冰的规则);
  2. 短期计划:推进服务器宣传的准备工作,暂时想到的是在b站建号并发布宣传片,预计今年暑假或明年年前是最佳宣传窗口期,宣传与否取决于准备工作的完成程度(如宣传片进度等);
  3. 其他计划:若宣传效果良好,我可能需要临时“借用”一台服务器——当然我会通过社区提出正式的申请,主要是有新的想法想要尝试,这个日后再说,不能也无妨;
  4. 其他计划:如果可能,推进新用户加入方式的转变(我到现在也不知道新方式是啥)。
其实没什么出入,历史资料是后期要强化去做的东西,这是很重要的一部分,现在确实比较欠缺。

1.同意。其实对服务器管理员有用的手册我也在图书馆写过一些,是有想作为“教材”使用的目的的。
2.同意,但我认为视频宣传很难,这也是为什么我们没有去做。我看了太多低质量宣传,却有很多播放,我其实是比较反感的。你可以看一下 RIA 的账号,我觉得质量很高。
3.不必如此拘谨,服务器挺多的,只是单核心强劲的服务器只有一台,其他倒是有很多。
4.同意。

其实我问权限,是想说超级节点需要什么样的权限,才能更好的实施。


另外为什么现在的模组服务器还要装FTBC(FTB Chunks),担心他人破坏嘛?可是翠鸟的理念不是夜不闭户、互相信任嘛:mc_391-0:
在低版本(1.12 及以下)使用的是 FTB Utilities,这是一个综合管理模组:
  1. 可视化认领区块还能够调整区块内的设置,比如防止苦力怕爆炸,也能够强制加载区块。
  2. /back /home /tpa /spawn 等基础命令。
  3. 定时重启。
  4. 权限管理。
  5. 部分版本有备份功能(已拆分为独立模块)。
  6. 组队功能。

在高版本(1.13 及以上),FTB Utilities 拆分为了 FTB Ranks(权限管理)、FTB Chunks(区块管理)、FTB Essentials(基础命令)、FTB Backups(备份)、FTB Teams(组队)。
FTB Chunks 主要用来强制加载区块,以及在区块内防止爆炸,甚至还提供一个小地图。
其实我一直在强调,不要使用 FTB Utilities(FTB Chunks)以外的区块加载器,就是因为 FTB Chunks 方便可视化管理。
偷偷加载区块是很难查出来的,甚至离线仍然加载而区块加载对服务器性能有非常大的影响。这是后面逐光章改造时需要进行原理说明的。
TPS 失控时也可以配合 Tiquality 来进行管理。
保护功能不是其重点。

我们不使用“混合服务端”(混合模组和插件),目前我们也没有能力开发自己的管理模组,因此这些不一定 100% 是我们想要的。
就像 QQ 群也不是我们开发的,我们不想设置所谓的“管理员”但这是没办法的。
很多时候我们只是使用者,没有能力去改变这些东西来配合我们的理念。
包括为什么图书馆没有开放注册,因为我们的验证码坏了,会有很多机器人跑来注册,上次尝试修了一下也没有修好。
 
最后编辑:

反对司令

成熟小鸟
2022-03-16
39
30
思考时间
16 小时 31 分钟
23
理解了,原来是这样。



实际上我想说的是,社区在服务器之前,而不是服务器在社区之前。
你加入的是社区,而不是服务器。
我想强调的是这一点,至于其他的,我想这并不冲突。



其实
  • 项目管理是给我自己看的,起因是 golfos 提到需要有一个待办列表。
  • 哨兵是早期较为活跃的 6 位成员,还活跃中的只有 2 人,仅仅是在图书馆拥有编辑通过页面的权限。这些都是后面需要重来的,不用太在意。
  • 新加入方式,当然是没想好的,不然也不会还沿用老问卷了。也许还是用问卷,但问题可能会更倾向于你对某某事物有什么样的看法之类的题,更加契合社区。
所有东西都是可以公开的,只是我们有一些顾虑,或是因为这些软件本不是我们开发的,无法做到我们想要呈现的功能亦或者是隐私问题等等。
在“去中心化”的前提下,没有您,也没有无权过问,这点请注意。大可不必这么拘谨,贯彻理念我们是认真的。


其实没什么出入,历史资料是后期要强化去做的东西,这是很重要的一部分,现在确实比较欠缺。

1.同意。其实对服务器管理员有用的手册我也在图书馆写过一些,是有想作为“教材”使用的目的的。
2.同意,但我认为视频宣传很难,这也是为什么我们没有去做。我看了太多低质量宣传,却有很多播放,我其实是比较反感的。你可以看一下 RIA 的账号,我觉得质量很高。
3.不必如此拘谨,服务器挺多的,只是单核心强劲的服务器只有一台,其他倒是有很多。
4.同意。

其实我问权限,是想说超级节点需要什么样的权限,才能更好的实施。



在低版本(1.12 及以下)使用的是 FTB Utilities,这是一个综合管理模组:
  1. 可视化认领区块还能够调整区块内的设置,比如防止苦力怕爆炸,也能够强制加载区块。
  2. /back /home /tpa /spawn 等基础命令。
  3. 定时重启。
  4. 权限管理。
  5. 部分版本有备份功能(已拆分为独立模块)。
  6. 组队功能。

在高版本(1.13 及以上),FTB Utilities 拆分为了 FTB Ranks(权限管理)、FTB Chunks(区块管理)、FTB Essentials(基础命令)、FTB Backups(备份)、FTB Teams(组队)。
FTB Chunks 主要用来强制加载区块,以及在区块内防止爆炸,甚至还提供一个小地图。
其实我一直在强调,不要使用 FTB Utilities(FTB Chunks)以外的区块加载器,就是因为 FTB Chunks 方便可视化管理。
偷偷加载区块是很难查出来的,甚至离线仍然加载而区块加载对服务器性能有非常大的影响。这是后面逐光章改造时需要进行原理说明的。
TPS 失控时也可以配合 Tiquality 来进行管理。
保护功能不是其重点。

我们不使用“混合服务端”(混合模组和插件),目前我们也没有能力开发自己的管理模组,因此这些不一定 100% 是我们想要的。
就像 QQ 群也不是我们开发的,我们不想设置所谓的“管理员”但这是没办法的。
很多时候我们只是使用者,没有能力去改变这些东西来配合我们的理念。
包括为什么图书馆没有开放注册,因为我们的验证码坏了,会有很多机器人跑来注册,上传尝试修了一下也没有修好。
10935336原来如此,那么我也没有什么顾虑了。
我会先去了解一下,如果有进度会发布在社区。
至于超级节点到底需要什么权限,由于目前超级节点太少的原因而难以得出答案,也许取决于超级节点正在执行的计划。
 
最后编辑:

反对司令

成熟小鸟
2022-03-16
39
30
思考时间
16 小时 31 分钟
23
另外为什么现在的模组服务器还要装FTBC(FTB Chunks),担心他人破坏嘛?可是翠鸟的理念不是夜不闭户、互相信任嘛:mc_391-0: