技术社区委员会未来发展(草案)

Conflux主网上线至今,链上已通过的生态项目数目已超过60,对于这一成果的取得,技术社区委员会功不可没。但由于社区中生态项目申请日渐增多,审核需求愈发强烈,技术社区委员会的日常运转也需要不断更新发展。

所以,我们结合现阶段发展情况,在原本评审流程的基础上制定了2021年技术社区委员会工作改进方案,借以提高委员会运行效率,推动技术社区更加快速的发展向前。

技术社区委员会委员工作:

1. 制定委员会纳新退出机制

1.1 不符合标准的委员退出

基金会参与监督管理工作,制定委员合格标准并在社区公示。标准实行后多次行为不符合标准的委员应退出技术社区委员会。

1.2 委员会纳新机制

在委员会下发小组中工作并对生态作出贡献的人可以申请加入技术社区委员会,委员会投票通过后在社区进行公示。

2. 社区内工作

委员会牵头成立以下各种小组,并收集各小组负责人上报的资源需求和预算。

2.1 对社区内小组【活跃、人员备案、github标签、小组负责人】

  • 项目协助小组:

    • 管理社区人才库,将生态项目成员备案。
    • 所有生态项目的github上都加上Conflux标签;
    • 所有标注开源或部分开源的项目必须对代码开源情况进行审查。
    • 优先为所有为Conflux提供过代码的开发团队提供便利;
    • 每月末组织生态项目进行线上路演,生态项目方报名参加,向社区汇报项目进度,并起到宣传作用。
  • 各类技术社区小组

    • 已成立的测试小组
      委员会持续关注测试小组工作,推动社区产出更多好用的产品,而不是虎头蛇尾的薅羊毛项目。
    • 已成立的社区学院
    • Bounty的升级小组,负责Bounty的改版和升级。
    • 已有生态产品的BUG反馈小组
    • Reach相关小组
    • 文档类工作小组
      负责提供文档类更新或提PR及翻译;
      协助整理FAQ并参与解答 协助建立技术/工具相关FAQ;
      协助回答技术相关问题,活跃社区。

2.2 技术社区对外扩张小组:【吸引开发者、吸引团队、吸引项目】

  • 成立对外扩张小组

    技术社区委员招募社区人才,组织成立“对外扩张”小组,负责吸引外部团队、项目和开发者。

    委员也可牵头成立社区技术队伍,参加黑客松等技术比赛比赛,在赛场上做一些宣传和招募外部开发者的工作。参加技术会议、黑客松等活动可向基金会申请机票酒店的提供。

    小组可凭借工作完成情况申请激励。

  • 组织建立技术运营小组

    技术社区委员招募社区人才,组织成立技术运营小组,帮助社区的生态项目方在社区招聘板块完成招聘、联系基金会完成宣传等工作。也可向基金会申请帮助完成赞助、媒体报道、线下路演等工作。
    技术运营小组需和项目方沟通,了解项目方的真正需求,并将需求传达给技术管理委员会和基金会。

(投后服务:项目团队需要认清如果真正拿项目当business运行需要什么级别的资源。优秀的生态项目如有融资或上交易所的需求,可向基金会申请扶持。除此之外的其他需求也可向基金会申请,基金会将酌情提供帮助。)

3. 完善生态项目流程

按照项目的不同类型和完成度,Conflux对生态项目的奖励分为L1、L2、L3三种不同阶段。L1对应的项目为只有创意但还未成型的项目,这类项目在申请时不要求有demo,只需要有创意的提供。

L1项目需要在2个月内完成,激励最高可达1.5万美元。

技术委员会目前负责L1阶段的项目。

注意,基金会所承担的L1项目的开发成本只包括两个月内的开发成本费用,不包含因为团队进展缓慢而产生的时间成本。

项目通过评审不代表能够拿到全部的申请费用,在项目后期进行测试验收之后,根据项目完成度,分期发放部分或者全部费用。

对于非基础设施类的项目,其需要明确做完后是否持续运营,如果不继续运营则需要谨慎通过。经费中如包含运营经费,项目方需要明确给出运营目标,细化费用的具体消耗。在达到项目期望目标后,运营经费进行发放。技术开发经费与运营经费分开发放,在开发完成后,可以先进行技术开发部分的经费发放。

*海外社区用户足够多的时候我们会开辟海外模块,现阶段辛苦海外社区的用户朋友使用谷歌翻译查看L1阶段现有的项目。

生态项目申请数量日益增多,对生态项目的评审机制也应当随之优化。目前的评审机制已经不能很好地适应繁多的生态项目申请,于是新的评审方案也应势而生。

3.1 生态项目评审新方案:

3.1.1 委员会招募评审小组分工负责新项目分析

  1. 技术社区委员会在社区招募擅长项目分析的人才,组成评审小组。在评审会议前,评审小组对提出申请对项目进行分析,决定其是否有资格参与会议评审。评审小组的每位成员需有不同类型的擅长项目,如Defi、NFT等,从而可以针对项目类型提出自己的意见。

  2. 评审小组核定一个评审专用问题库,评审分析时由项目负责人进行逐条解答。问题库的问题包括但不限于一下几种:

    (1) 核心解决的问题是什么?

    (2) 定义一下项目的类型?

    (3) 为什么要这样一个平台,项目平台对用户有什么价值?

    (4) 传统互联网的平台也可以解决这个问题,为什么用区块链?区块链平台在这里提供的差异化价值是什么?

    (5) 第一阶段产品主要完成什么功能?

    (6) 请给出项目的用户画像

    (7) 请描述一下项目的时间节点及每阶段的产出和阶段目标

  3. 项目申请进入公示期后,依据项目类型由相应的评审组员对接。该项目的负责组员和项目方沟通后,将项目相关信息交与Conflux协调小组、技术社区测试小组以及评审小组,三小组开会分析项目,确定项目的可行性,汇总评审时的问题和意见。

    分析汇总之后,该项目的负责组员将评审时间和链接发到生态项目申请帖子下,并附上对项目的提问和意见。

    在项目方案正式施行之后,单独创建评审会议帖。该项目的负责组员在帖中放入评审会议时间和链接,邀请全社区参加评审会议。在本帖下,评审小组需解答社区的疑问,听取社区的建议。

  4. 该项目的负责组员主持评审会议,项目方负责人必须参与,评审小组需要有半数以上人员参与,社区成员自愿旁听。(注:Conflux市场组、产品组、技术组分别会有一个同事参会,跟进项目评审。

  5. 评审结束后,由该项目的负责组员牵头在评审小组内部召开投票会议,评审小组讨论后进行投票。项目申请金额是否合理、是否通过、通过与否原因等都应该在投票选项中包含。

    若少数组员投票时认为金额需要修改,应当给出自己的理由,项目的负责组员根据理由进行判定,并对判定结果负责。

    重申:对于非基础设施类的项目,其需要明确做完后是否持续运营,如果不继续运营则需要谨慎通过。经费中如包含运营经费,项目方需要明确给出运营目标,细化费用的具体消耗。在达到项目期望目标后,运营经费进行发放。技术开发经费与运营经费分开发放,在开发完成后,可以先进行技术开发部分的经费发放。

  • 投票者必须说明同意与否的理由

    在组员进行投票时,应当说明投票的理由,单纯地选择某个选项而不说明原因的投票视为作废。多次不投票或无理由投票的组员视为行为不符合标准,应当退出评审小组。

  • 公示投票结果需要注明通过和不通过的理由

    组员对生态项目投票后,应当由该项目的负责组员在投票结果公示时在帖子中备注每位组员投票意向的原因和意见。

  • 生态项目需要有专门组员负责

    评审小组的每位组员根据自身所长合理选择不同类型的项目进行负责,每个项目由1-2位组员牵头。

3.1.2 关于生态项目方的要求

  • 生态项目方需介绍清楚自己的项目

    对项目的熟悉体现在可以清楚且明确地知道项目所解决的问题、项目的需求及目标、产品的应用场景及有缺点、可能会面临的问题及法律责任、对问题的解决方案等方面。

  • 生态项目方需及时更新自己的项目进展

    项目方在申请项目时所设定的时间节点将被列入验收标准之一,严重超时将影响验收评分,进而影响完成后所获得的激励金额。申请时未设定时间节点的项目,在评审通过后的一周公示期内,需补充完整时间节点。

  • 一个月之内没有同步进展、拖延时间过长(超过规定时间一个月),需要重新进行项目申请工作。

3.2 生态测试验收团队

Conflux生态测试验收团队的主要工作主要由两大主要内容组成:

1. 测试

根据项目方提供的测试用例或主要完成功能,对项目方提交的产品进行功能性测试,并将测试发现的问题分为产品类和开发类进行梳理总结。根据项目方的反馈,及时对已经解决的问题进行回归验证。

2. 验收

针对项目方在生态项目立项时作出的承诺和验收申请中提交的要点,负责验收的人员需要在实际验收产品功能时将目标与成果进行逐一对照,并对目标实现情况评价。

测试验收工作侧重点:

针对不同的群体,工作的重心不同。对于商业化公司申请的生态项目或较大规模的生态项目(INS3、MoonSwap等)更侧重于目标实现评价,对于社区成员立项的规模较小的项目(gourd生态钱包等)则侧重测试+目标实现评价。

详细内容参见:Conflux生态项目测试验收工作流程


相关参考

[1] Conflux生态基金申请流程说明

[2] Conflux技术社区生态项目申请孵化原则

[3] Conflux生态项目建设申请须知

[4] 诚邀项目方加入Conflux生态,邀请人可获得X个usdt奖励

[5] Conflux 生态项目扶持计划首批扶持项目出炉

注:该草案在上周末开始试运营,之后也会根据实践反作出相应调整。

1 Like

Q. 评审小组投票时把是否通过、通过与否原因、金额是否合理等也算作投票选项
A. 同意

Q. 评审小组中,是否给认为金额需要修改的组员更多投票权重?
A. 认为金额需要修改的组员应当给出自己的解释,由负责该项目的组员去判定并为这个结果负责。

1 Like

Q. 测试小组把验收报告提交给委员会之后,是否需要一个开会讨论的流程?
A. 测试小组如果有很大疑问,可以提出开会。

Q. 项目申请资金的条件(开发、服务器?艺术家?)
A. 必须开源承担开发成本;承担大概半年服务器的成本;艺术家不能单独申请一个项目,应该确定他的艺术作品发在哪个平台,由这个平台来申请资金。

Q. 同类项目的申请应该如何资助?
A. 需要生态里出现优秀的项目之间的正向竞争,鼓励项目向社区外拓展,不鼓励对已有社区反复消耗。

不错,有专门运营部门是好的!

建议:鼓励在不同细分领域的拓展,鼓励生态内项目间联合推广相互赋能。
个人不太建议纯ip层面差别,其他方面基本或完全同质化的方案,除非特殊情况。

2 Likes

%E5%9B%BE%E7%89%87

新规则草案很好,细化和完善了很多内容。终于发布了。

P.S.

赞同这个观点,建议改变不支持同类项目的惯例,改为鼓励支持细分领域。
不是消耗。
对于早期开荒阶段来说,良性竞争和配合,互相促进开疆拓土,一家独行发展不快。