随着Venus体系逐渐定型，社区和产品对Venus需求变多。建立一套适用于Venus产品需求管理流程。本文档将着重于来自团队外部的需求管理。
当前针对Venus产品的需求类型大致分为以下类型：
- 社区需求
- PM需求
- 生态合作伙伴需求
社区需求着重于鼓励社区参与到issue提交的过程中。尽量引导/鼓励社区对其所期望的应用场景，即，想要得到的结果，来提出issue。这样由社区提出场景，然后Venus团队具体进行工程设计的模式推进。
PM会在不断追踪Boost和Lotus的新功能特性的同时，把他们的一些好的实践同样以issue的形式作为需求提到Venus相关的repo中。产品和PR追踪都在github上以讨论的形式留下记录。
当Venus需要集成生态合作伙伴时，团队可能需要对Venus系统本身做出调成，以对接生态合作伙伴的需求。这个部分可能会对应到更大，更全面的一个业务场景流。
- 由PM统一对接外部需求
- 在明确要做的情况下，建立
issue，加入到sprint开发计划；[流程结束] - 在不明确要不要做的情况下，由PM对
issue打上C-triage标签，并assign一位工程师，如工程师不熟悉该issue的领域可以询问或者assign另一位工程师
- 在明确要做的情况下，建立
- 每个
sprint总结会之前，被assign``issue的工程师需要对其被assign的C-triage的issue列表进行评估- 如可直接判断需求不需要做，在
issue中选择Closed as not planned；[流程结束] - 如可直接判断需求已经满足，在
issue中选择Closed as completed；[流程结束]；（可选）并关联相关PR或者功能特性说明 - 如判断需求有效，那么把需求
issue加入到开发计划中
- 如可直接判断需求不需要做，在
- 在
sprint总结会上，对需要C-triage的issue进行整体把控，把有问题的issue单独拿出进行讨论；[流程结束]
- 每月一次对运维，商务，生态，社区等用户的需求做收集。
- 对收集的需求，核心开发者内部开专门会议进行需求分析。
- 分析结果在共享文档上进行记载，记录对应的issue，并通过venus群、共享文档和github等方式向需求方进行反馈。