本文内容来自 Polkadot 大使联盟系列直播的第三期，负责人 Lucy 邀请了几位技术 Fellowship 成员来一起聊了聊技术 Fellowship 的运作模式，以及这个组织在 Polkadot 生态中的定位和角色！本文内容较长，PolkaWorld 将分为上下两部分发布，本文为上半部分，主要内容包括：

• 自我介绍

• 什么是技术 Fellowship？如何加入？

• Fellowship 成员如何获得奖励？

• Technical Fellowship 的体验非常“去中心化”

• Fellowship 的唯一一条规则——“别当混蛋”

• 技术 Fellowship 在 Polkadot 生态中的角色

继续阅读，查看全部精彩内容！

Lucy：大家好，欢迎来到 Polkadot 大使 Fellowship 系列直播第三期。今天我们请到了 Polkadot 首批技术 Fellowship 的几位成员，我们先请大家做一个自我介绍，告诉大家你在 Technical Fellowship 的等级以及对应的等级含义。

Oliver：我是 Oliver，在技术 Fellowship 里是三级成员。最初我是以一级成员加入的，当时 Technical Fellowship 刚成立，大家对等级制度还不是很明确，所以大家初期的等级都被评得比较低，后来才慢慢提升到实际的等级。

我来自德国，从 2019 年开始从事加密领域的工作，最初用 Golang 和 Solidity 在以太坊上开发状态通道解决方案。三年半前我开始接触 Polkadot，现在在 Parity 工作，负责 Polkadot 和 Kusama 的运行时开发，主要使用 Rust 语言，业余时间我也和一些同事在做一个 JAM 客户端的项目，也挺有意思的。

Clara：大家好，我是 Clara，我主要在做 Snowbridge 项目。Snowbridge 是一个连接以太坊和 Polkadot 的去信任桥，它的代码是 Polkadot SDK 的一部分，所以我平时也经常和 Technical Fellowship 的成员们打交道。

我住在南非的比勒陀利亚，我加入 Technical Fellowship 差不多快一年了，目前是一级成员，可能快升了吧哈哈，不过我还是会专注做好手头的工作。我在加密行业也大概三年半了，从一开始就在 Snowfork 公司工作，一直专注做 Snowbridge，这是我第一个区块链项目，可以说我是在实践中迅速成长起来的，我也非常喜欢这份工作。

Donal：大家好，我是 Donal，我加入 Technical Fellowship 差不多也是一年前，现在是一级成员。我在 Parity 工作了一年半，也就是说刚进 Web3 不久，我原本是做粒子物理研究出身的，后来想换个方向，做一些能真正对世界有积极影响的事，于是就选了 Web3。我当时在找最优秀的技术栈和最正直靠谱的团队，就找到了 Parity 和 Polkadot，感觉他们非常契合我的理念。我是在 2023 年 9 月加入 Parity 的，大概工作了六个月后申请加入 Technical Fellowship ，然后就成功加入了。最近我本想申请晋升二级，但很遗憾，因为提交证明材料太晚，被延期了，现在是一个“等待区”的状态。

Lucy：那多久能再次申请晋升呢？

Donal：我记得大多数等级之间需要间隔一年时间，至少初期等级是这样。一旦晋升，计时就会重新开始。

Lucy：那你下次申请不会又要等一年吧？

Donal：具体规则还在梳理中。其实这里有点复杂，我现在是一级，如果想保留这个等级，就需要每三个月写一次“保级证明”，然后由其他人帮忙把它提交到链上进行投票，如果投票通过你就保住等级了。通常你需要成功保级四次，才有资格申请晋升。所以一般的流程是：保级四次，再申请升一级。

Lucy：好的，原来是这样！接下来我们先向大家介绍一下什么是 “Technical Fellowship ”？为什么叫“ Fellowship ”？在整个生态系统里这个词意味着什么？对你来说又代表着什么？

Oliver：其实，“Fellowship”在我们这里指的是一种类似 DAO（去中心化自治组织）的结构。它是去中心化的——形式上没有中心机构，在法律上独立运作；但在思想层面，它是围绕一个明确使命运作的，这个使命其实就是 Gavin Wood 写下的 Fellowship “宣言”。

我们一直严格遵循这份宣言，虽然这些年来几乎没有大的变动，但我们坚持下去是因为，这份“宣言”是得到了 OpenGov 通过投票的认可和授权，换句话说，这个宣言不仅仅是 Gavin Wood 个人的观点或愿景，而是经过 Polkadot 社区的正式投票程序，决定授予 Fellowship 团队遵循并执行的权力。

你可以把它看作是我们的“服务合同”。像我们每季度要做的保级工作，听起来可能有点繁琐，但这些流程的存在，归根结底是因为我们是为 OpenGov 和整个 Polkadot 生态服务的。如果我们擅自更改 runtime 代码，或者不再遵守这些规定，外界可能就会觉得，“这个 Fellowship 开始脱轨了，开始胡来。”我们之所以恪守规则，就是为了向整个生态证明我们不会那样做。

总的来说，这份纲领明确了我们对生态的承诺，也为外界设定了清晰的预期。

Lucy：那我想接着问一个更实际的问题，如果现在有新人想加入 Technical Fellowship ，会是一个什么样的流程？

Oliver：其实现在加入的流程也保持去中心化的特点，任何人都可以提名新人加入。我最近就推荐了一位贡献者，他在资产类型迁移的测试中帮了我们很多，展现出了很强的技术能力。我就问他要不要来试试看，他说“这正是我想做的”。通常从 Rank 1 开始，成员就可以提名候选人。

被提名为候选人之后，会有一年时间可以申请晋升。这个候选人身份本身就像是一种“荣誉提名”，不会有固定的任务期限或薪酬，更像是对你潜力的认可，让大家看到你可能会成为正式成员。

接下来的事情就需要候选人主动推进了。他们需要主动参与贡献、展示成果，并提交晋升申请。通常不会有人替你主动发起，当然如果运气好也许会有人帮你，但大多数情况下，这一步得靠自己去争取。很多人也会在正式申请前“试水”一下，看看时机是否成熟。

Lucy：那 Clara，你是去年加入的，同时还有一份全职工作是在 Snowfork 做 Snowbridge。你是怎么平衡 Fellowship 的工作和你本职工作的？或者说，你的 Fellowship 工作是怎么融入到你平时工作的？

Clara：其实我挺幸运的，我的本职工作和 Technical Fellowship 的工作高度重合。因为我现在在做的 Snowbridge，是基于 Polkadot SDK 的，而这个 SDK 本身也属于我们 Technical Fellowship 关注的内容，所以我现在的工作内容其实已经包括了 Fellowship 所需的很多部分。

Fellowship 的工作更像是一种“锦上添花”吧，我当初申请 Fellowship 的时候过程也很顺利，在 GitHub 上有一个 README 文档，里面详细写了你需要完成的每一步。按照步骤走基本不会出错，所以整个流程还是比较清晰、流畅的，现在唯一的难点就是要记得定期提交“保级证明”，我自己就忘了几次哈哈。

Lucy：那这种保级材料准备起来会不会很花时间？

Clara：其实还好，两个小时差不多就能搞定。你需要静下心来回顾一下，“我这三个月都做了些什么”，这个过程本身就是一个很好的自我总结，不过你不能只是列个清单说，“我做了这些，请保我级”，还得说明这些工作对 Polkadot 社区有什么价值，有什么正向贡献，然后先在 GitHub 库提交材料，其他 Technical Fellowship 成员会先给你反馈，调整好后才会上链投票。

Lucy：那我还想了解一下奖励机制是怎么运作的？我知道你们在 Parity 和 Snowfork 等机构工作是有薪资的。在任何组织里，贡献者都需要奖励和认可机制，我们现在也在设计大使项目的奖励体系，你们的机制是什么样的呢？过去一年里，你参与过哪些工作并因此获得奖励？如何保持活跃度？比如你是 Rank 1 级别的成员，那你刚加入的时候，会知道从哪里开始做起吗？

Donal：我觉得在 Technical Fellowship 这边，因为我们做的事情跟 Polkadot 系统本身的开发和维护是高度相关的，所以很多时候你一开始做的事其实和那些能拿到 tip（赏金）的项目是有重叠的。

比如你可能先通过 tip bot（小费机器人）获得一些奖励，但一旦你成为了正式的 Technical Fellowship 成员，开始拿工资了，那这些临时性的奖励基本就不再适用了。换句话说，早期你还没加入时，可以通过做一些对生态有帮助的工作拿 tip，这些也是你日后申请加入 Fellowship 时的重要“作品集”。当你的工作达到一定影响力、对生态有价值时，你就可以用这些成果作为申请 Fellowship 的依据。

等你加入之后，如果表现持续优秀，就可以晋升。晋升的核心是你的贡献范围在不断扩大，比如 Rank 1 的要求其实并不高，Rank 2 也还好，但到了 Rank 4、5、6，要求会陡然提升很多，你需要设计并实现一些全新的关键功能，还要维护你之前做过的部分。

在我看来，晋升就是一个“扩大影响力+提升责任感”的过程，你要逐步成为某个技术模块里“那个被人问的专家”，真正拥有属于自己的领域，越往后，像教学、带新人也会逐渐成为你的职责。

至于临时奖励（tip），一旦你开始在 Fellowship 领工资了，基本就不会再考虑这种方式了。

Lucy：所以 Technical Fellowship 里有一些是专职的全职成员，其他很多人可能就是兼职做一点，慢慢积累。那是不是说你级别越高，就必须投入更多时间？还是说只是工作难度在增加？

Donal：我觉得主要是工作本身变得更复杂了，投入的时间不一定线性增长，可能在某些阶段会有峰值，但不是说你 Rank 高了就得全天候在线，越往高层，你可能就不再是天天写底层代码了，而是要做架构设计、带团队、定义方向，我理解的晋升路径更多是从“执行者”变成“引领者”。

Lucy：那像你们现在的工作内容，比如系统升级、版本发布，总是会有任务嘛，那这些具体的需求是记录在哪儿的？我们 Ambassador Fellowship 这边现在在做一个任务看板，准备下一阶段大量用起来。比如说，我们要办一场夏季快闪活动，现在就需要一整套品牌设计，但现阶段无资金支付，所以我们就把所有的任务贴在看板上，标注出大致价值和要求。你们那边是怎么管理的？谁来协调？

Oliver：我们这边协调工作主要是围绕每次的版本发布展开的，大部分功能的协作和分工基本都是在 Parity 的 GitHub 库中进行的。

因为 Technical Fellowship 的成员大多也在 Parity 工作，所以两边的流程有很大重合，这其实是件好事。Parity 有比较成熟的流程，我们也受益不少，如果哪一天 Fellowship 里的成员都不再来自同一家公司，那可能就得重新搭建一套自己的协调系统了。

Lucy：明白，那我们来聊聊文化氛围吧。Clara，你觉得 Technical Fellowship 的氛围它更学术化？还是偏极客？合作氛围强不强？有没有趣味性？你觉得这种“社交氛围”怎么样？

Clara：我觉得整体来说是非常技术导向的，我们团队中有很多技术高手，但大家都很平易近人，高级别成员也不摆架子。我感受到大家有一种很强的“主人翁意识”，大家都在做自己真正认可、真正在乎的项目，也都以自己的工作为荣。我加入 Technical Fellowship 之后，最直观的感受就是学习变得容易了，因为你跟其他成员之间有了身份上的“关联”，所以交流起来也更自然。我就经常去“骚扰”Oliver，跟他请教问题哈哈，总的来说，我非常喜欢这里的氛围。 Fellowship 是一个非常有技术含量、但同时又很有支持感的社区。

Lucy：太好了。Donal，你刚才又提到“导师制度”，我一直试图将 Ambassador Fellowship 与 Technical Fellowship 做类比——我相信任何组织都难免有磨合期的问题，但 Technical Fellowship 显然是一个结构完善、运作良好的范例。我们打算在第二阶段引入“导师机制”，Technical Fellowship 的指导机制是怎样的？是否有正式架构，还是说加入后会被分配导师？具体是什么样的？

Donal：其实并没有严格的架构。Technical Fellowship 的体验非常“去中心化”——有些人加入之后，可能从头到尾都不会跟任何人在线下交流，也有人会积极社交，全凭个人选择。指导机制也类似，不像公司里的正式师徒制，更多是通过代码评审、交流想法自然发生的。

就像 Clara 说的，大家都很平易近人，能接触到顶尖程序员和工程师，从他们那里获得架构和代码上的建议与反馈。你如果很被动，可能会觉得这里完全没有导师、没人理你。但如果你愿意主动联系别人、勇敢说出自己的想法，哪怕有些建议最后被“无情打回”，你也会收获很多。重要的是大家批评的是“想法”而不是“你这个人”。

Oliver：我想补充一点，Technical Fellowship 并非“培养型”机制——我们依赖成员本身的能力，选拔时更倾向于“择优录取”，而非广泛接纳后再培养。这导致我们的成长速度较慢，可能每月仅新增一两名成员，无法像大使项目那样快速扩大规模。

Lucy：那你们现在大概有多少成员呢？

Oliver：目前整个 Technical Fellowship 的成员，包括候选人在内大概有 70 多人。如果不算候选人，真正成为正式成员的可能在 45 个左右。活跃成员的话，大概 40 个上下。

Lucy：那有没有“活跃度”的要求？必须保持活跃才能继续待在里面吗？

Oliver：是的，宣言中明确规定了活跃度要求，多数等级需保持约 90% 的活跃状态，剩余 10% 可用于假期报备为非活跃状态。但总的来说，大家都预期是要保持活跃的。目前已有机制会逐步降级长期不活跃成员，其实这个机制已经存在，只是以前有点漏洞，现在我们正在修复它。

Lucy：你们显然还是需要一个小型的协调核心团队，当然不是中心化的控制，我们这边目前还有一个更大的运营团队，因为我们正在建设一个很大的社交网络结构。但你们那边有出色的秘书 Anel，那她都负责哪些协调工作呢？你认为 Technical Fellowship 正常运作的基础是什么？

Oliver：Anel 负责很多事情，其中一个最明显的工作是发布通知，比如每次有版本发布，她会通知相关的人。我们有一些专门的沟通频道，里面会邀请生态中的重要成员，及时接收发布和更新信息，特别是如果有“破坏性变更”的话，提前提醒是非常重要的。

另外她还会维护“贡献证明”相关的资料库，大家提交的晋升申请、项目成果她都会负责检查格式是否正确、README 有没有问题、有没有需要修复的内容。她也会协助组织会议，包括公开的开发者电话会议（Open Dev Call）。对我们来说，有这样的角色非常重要，因为开发者一般不会主动沟通哈哈。我个人也很感激她，比如她帮我审核我的晋升申请，确保没有低级错误。总之，她非常重要。

Lucy：确实，我也知道开发者都非常有激情，而且有时候表达也会非常直接，甚至会有很激烈的分歧。那你们遇到这种情况时怎么处理？怎么达成共识呢？是不是会投票？因为你们的宣言里写着，低级别的成员一般要服从高级别的决定，是这样运作的吗？如果有人提出不同意见会怎样？

Oliver：这个话题其实挺敏感的。一方面，我们不希望 Fellowship 被“外部势力”操控，比如说某些有目的的组织进来投票控制方向，所以如果低等级成员经常对高等级提案投反对票，那可能是一个“信号”，说明这个人可能是恶意的，但这并不意味着你不能有不同意见，比如在 RFC 流程中，确实会有争议，但大多数时候这些争议都会在讨论阶段被解决。

如果意见不合，有些人会选择不投票，或者投“反对票”（nay），这也是可以接受的，但主要的争论基本都集中在“RFC 讨论阶段”，最后必须在技术上达成某种共识，否则项目就没法继续推进。

不过，说到底，“低等级挑战高等级”这个话题本身就是有争议的。如果你感兴趣，我可以详细讲讲，但那可能就要单独开一个话题了哈哈。

Lucy：我是觉得，大家自然会信任晋升到更高级别的成员，但我想这里的讨论氛围还是很开放的，允许公开探讨和辩论，毕竟大家都很平易近人。如果所有人都反对高级别成员的意见，那他们可能本就不该处于那个位置，还好你们已经有一整套机制来防止这种情况发生。不过知道每个人的声音都能被听到总是好的——何况你们的工作很多都是基于事实，甚至写进了代码里，让人无从争辩。

Donal：补充一点，我认为这种基于事实的机制很好，而且项目也很任人唯贤。即使是一级成员，只要有充分理由支持某个方案，一样能影响决策。虽然我没有具体案例，但很多时候，低级别成员提出的方案比高级别成员的更优，最终也会被采纳。

如果遇到两种方案各有优劣、陷入僵局的情况（目前还没遇到过），由于都是技术问题，总能通过论证或验证找到解决方案。大家争论的是想法本身，而非针对个人，这种就事论事的氛围很好。

Lucy：我们在大使宣言里其实也照搬了你们 Technical宣言中的行为准则。就像 Gav 一直说的那样，我们的唯一一条规则就是“别当混蛋”。所以我们也是鼓励大家表达观点时要讲礼貌，要讲理。那我想问一下，你们有没有真的因为有人“当混蛋”被踢出去了？当然你不用说名字。

Oliver：目前没有，迄今为止只有那种长期未能提交留任材料或活跃度不达标的人会被降级或除名，但不是因为行为问题。

Lucy：接下来谈谈 Technical Fellowship 在 Polkadot 生态中的整体定位。它是怎么融入 OpenGov 和更广泛治理框架的？我知道你们确实在某种程度上也引导着 OpenGov 的方向，但作为自治组织，你们的定位是什么？实际的内部投票机制是怎样的？如何融入更广泛的 Polkadot 生态？

Oliver：Technical Fellowship 的投票机制与OpenGov 不同，但可以视为一个“子议院”。类似政治体系中的两院制，我们在运行时升级的快速跟踪机制中扮演特定角色——对升级方案进行投票，向社区证明其合理性，最终由 OpenGov 做出最终决策。这一设计初衷是为了支持运行时升级，或在出现问题时进行修复。

但如果是像白名单调用（Whitelist Calls）这种更广泛的事情，目前还没有特别明确的机制——我们之前就遇到过类似的情况，有一个平行链出问题， Technical Fellowship 想要介入救助，但后来攻击者绕过了防御，造成了尴尬的局面。

所以我觉得 Technical Fellowship 的定位得“具体情况具体分析”。但总体而言，Technical Fellowship 不应被视为“替人收拾烂摊子”的角色，这会传递不良信号。因此，将职责集中在运行时升级相关的核心任务上更为合理。

Lucy：那外部团队呢？比如开发者、平行链项目方、社区成员，或者像我们的 Ambassador Fellowship ，想和 Technical Fellowship 对接时应该怎么做？举个具体例子：大使模块由 Technical Fellowship 在大使计划第二阶段开发，但当时未能落地。现在我们正在进行修改，由一级成员 Jesse 负责编码，Oliver 审核，预计最快 7 月中旬、最晚 8 月上链。但这个过程对我来说很漫长，因为最初公投通过后，我们不知道如何推进，最终还是由 Technical Fellowship 接手完成的。那我想问的是：通常大家该怎么和你们对接？是可以主动来找你们帮忙开发吗？协作流程是怎样的？

Oliver：需要明确的是，Technical Fellowship 通常不会主动承接这类开发需求。比如“Optimistic Funding”或其他大型提案通过 OpenGov 投票后，Fellowship 的态度是：“如果有人开发，我们会审核通过，但不会亲自开发”——因为我们的核心职责是确保运行时安全。因此，我们自视为 OpenGov 的“质量控制机构”，而非开发团队。

具体流程是：外部团队找到开发方完成开发，若需将功能集成到 Runtime，提交给 Fellowship 审核，通过后上链。希望未来随着智能合约的普及，这类依赖会减少——目前所有功能都需通过模块实现，每次更新都要进行运行时升级，非常繁琐。如果能通过智能合约实现（如 OpenGov 模块、国库、投票机制等），任何人都可以直接在链上提案升级，无需修改运行时代码。这也是推动智能合约发展的重要原因。

Lucy：好的，关于开发团队的合作——比如 Donal，你和 Jesse 同级，你们会和开发团队合作吗？是否有人可以直接找到你们说“我们在做这个项目，能否审核通过？”具体流程是怎样的？比如我发布了 RFP，BlockDeep Labs 这样的团队承接了项目，那他们是直接来找你们吗？因为所有东西最后都需要你们批准嘛，你们会跟他们直接对接吗？

Donal：我目前正在参与 OG Rust Bounty，在这个项目中我们确实直接与 BlockDeep 的成员合作。这个计划旨在为非 Technical Fellowship 成员的开发工作提供一种支付渠道——正如 Oliver 所说，当某个提案通过公投或社区明确表达需求后，开发者可以通过两种方式参与：一是向 OG Rust Bounty 提交提案，获得资金支持，用于集成现有模块、开发新模块或抽象功能；但获得资金并不意味着其成果会自动被纳入运行时，最终仍需向 Technical Fellowship 的运行时代码仓库提交拉取请求。

具体来说，开发者需要将修改后的代码（可能是 Polkadot 开发工具包中的模块，或来自外部仓库的自定义模块）提交至运行时仓库，并附上测试用例等证明材料，以证明其功能合规。审核采用评分制，高级别成员的评分权重更高，需获得跨级别的多数认可才能通过。通过审核后，代码将被合并到运行时仓库，最终上链只是时间问题。

Lucy：我学到了很多。如前所述，我们的大使模块有望在六周内上链，同时还有通过公投的 Fragment Initiative Fund 需要开发——这是一种类似“乐观资助”的机制。虽然 OG Rust Bounty 表示可以资助，但找到合适的开发团队比想象中困难得多。如果有观众能提供推荐，欢迎联系我们。