开发者插件维护规范

面对人群：所有商城开发者                             启用时间：2023年

修改历史：

权利与义务总是相伴相随，插件上架帆软市场后，开发者在获取上架插件带来的收益同时也需要对自己名下的插件履行维护义务

1.插件上架

所有的插件在上架商城前都需要通过插件上架流程

说明：

所有插件在上架流程时都会创建对应的插件内部仓库，开发者需要将内部仓库fork到自己名下，后续所有改动都要提交PR到内部仓库

提交的PR的标题需要带上对应的OS（上架流程）或者POB（BUG流程）编号

包括初次上架及以后的每次更新都需要有对应的任务（上架或者BUG流程）支撑，否则插件会进入隐藏状态，直到正确更新才会在商城显示出来

插件申请上架时需要填写详细的插件说明，格式可参考：https://shimo.im/docs/9030MnLg2wh885qw/ 

♦2.关于BUG修复

所有测试组提出的插件BUG任务需要及时修复，未及时修复会影响当月分成的发放

细则：

• BUG分级（都是非SLA问题，SLA问题处理要求可见：第三方插件的sla协议）

根据影响程度将插件BUG打上标签

需修复 ：代表严重BUG，已经影响插件的某些基础功能使用

• 分成发放规则

没有BUG的开发者分成正常发放

有需修复标签BUG一个月未修复的开发者，当月起暂停发放分成

无标签的BUG重复出现三次次客户BUG则按需修复BUG处理

• BUG等级判定

BUG等级由内部对应模块研发判定，开发者有异议可以申诉，由ezreal-陈军和hugh-甘超复核判定

♦3.关于保证金

年初开发者在第一次提现时，系统会扣留该次提现的金额作为该开发者的保证金，年末会根据这一年的表现进行一定的增幅或者减幅，合并进当月分成中一起发放

细则：

• 保证金的额度500~2000

第一次提现不满足500的部分会在第二次提现中补满，超过2000的部分当月会正常发放

• 增减幅规则

本年度每个月都没有遗留的需修复BUG的     保证金增幅100%  ↑

本年度有遗留需修复BUG月份小于等于1，但是年底无遗留的    保证金增幅50%  ↑

本年度有遗留需修复BUG月份小于等于3，但是年底无遗留的    保证金增幅20%  ↑

本年度有遗留需修复BUG月份大于3，但是年底无遗留的    保证金不增幅正常发放

本年度有遗留需修复BUG月份大于3，且年底遗留需修复BUG数大于等于1小于3    保证金减幅10%  ↓

本年度有遗留需修复BUG月份大于3，且年底遗留需修复BUG数大于等于3小于5    保证金减幅30%  ↓

本年度有遗留需修复BUG月份大于3，且年底遗留需修复BUG数大于等于5    保证金减幅50%  ↓

4.关于插件迭代

为了保持商城插件活性以及竞争力，开发者需要对插件保持持续得更新迭代

细则：

• 大版本迭代

除了客观因素导致的外，所有商城上架插件需要跟随产品进行大版本迭代，且需要同时维护两个大版本（在新的大版本上架的插件除外）

举例：目前产品得大版本是11.0，等产品更新12.0时，插件也需要及时适配12.0，且需要同时维护11.0和12.0两个版本，如果是在12.0上架的新插件就可以只维护12.0版本

大版本迭代需要在产品大版本正式发布后的三个月内完成

开发者明确不适配的，原插件将转入插件池，另找其他的开发者接手维护

• 需求处理

客户对插件提出的众多需求，开发者需要对其中的合理需求进行处理

需求的合理性判定由内部对应模块研发判定，开发者有异议可以申诉，由ezreal-陈军和hugh-甘超复核判定

需求迭代需要在三个月内完成

三次合理需求无理由不开发，原插件将转入插件池，另找其他的开发者接手维护

说明：一次客户需求即计数一次，同一个需求三个不同的客户提也算三次

           若该插件未处理需求未达三次，客户需求可走定制实现，将优先选择原开发者以外的开发者接取任务

5.关于插件下架

因为种种因素，插件的下架是一个并不少见的情况，需要一定的规范，减少插件下架的负面影响

• 下架原因

开发者因自身原因表示不再维护想要下架插件

     原插件将转入插件池，另找其他的开发者接手维护

插件功能被做进主产品后插件下架

     被回收的插件参考已有流程:

插件上架后数据太差，考虑到资源优化而下架

参考数据：以正式上架一年为期限，同时满足下列条件的插件将进行插件下架优化

   销售套数≤2           

   销售金额≤10000

   覆盖合作&跟进客户数≤20

• 下架申请

开发者想要下架插件，需要提前三个月时间跟运营申请

这三个月是作为前方销售缓冲期，三个月期内开发者需正常维护BUG，需求可以不处理，三个月后，正式不维护

6.一些补充

• 关于插件池

除上述情况，一些历史课题也会放进插件池中，开发者可以对插件池中插件以及课题进行申报维护，内部核准后可以正常经手维护

目前的插件池可见：插件池地址

• 关于插件原开发者不再维护的情况：

插件转入插件池，看有没有开发者承接，没有就走定制任务，三次定制任务依然没人维护下架

1. 1. 新开发者承接后，后续插件收益归新开发者所有 
   2. 承接的开发者筛选条件：维护的插件数量/过往维护积极程度
   3. 走定制任务，原开发者将不再享受插件分成

对此规范有什么疑问可以直接联系运营Zack.Zhang同学~