推荐项目的审核标准

[521xueweihan]

推荐项目的审核标准

此文档目的：

1. 为了提高 HelloGithub 的项目推荐质量
2. 可以起到引导推荐者更好的去认识开源

注意：推荐项目分为 开源项目 or 自荐项目

列表的内容：

1. Doc
2. Star
3. Insights
4. Issues
5. AdditionalRemarks

文档

1 是否有完善的文档

原因：文档对于一个开源项目是至关重要的，有助于别人理解项目的目的以及技术细节。

[1.1] 一般文档包含的内容：

1. 项目介绍 (必须)
2. 特性 (必须)
3. 快速开始 (必须)
4. API (可选)
5. ChangeLog (自荐项目可选，开源项目必须)
6. FAQ (可选)
7. 贡献 (可选)
8. 版权/协议 (必须)

Star

2Star数的判断

原因：这是一个主观判断，因为有可能目标项目的star数出现'水份'，但是高star项目必定有其原因，尤其是对开源项目来说。

[2.1] 判断依据

1. 对于开源项目 star是一个参考标准
2. 对于自荐项目 star可以是可选标准

Insights

3Insights数据判断

原因：Insights可以看到项目维护的数据，从而判断项目的活跃度，以及判断是否有弃坑的风险

[3,1] 判断依据

1. 对于开源项目 & 自荐项目 Insights是必选参考项

Issues

4Issues close/open判断

原因：通过 Issues close/open数量可以判断一个项目的活跃度

[4.1] 判断依据

1. 开源项目为必须参考项
2. 自荐项目为可选参考项

AdditionalRemarks

5AdditionalRemarks(补充说明)

原因：前面的4条都是针对项目是否符合开源规范而制定的，但是基于大环境所致，真正属于开源的项目其实很少的，所以有了补充说明。

自荐项目

对于自荐项目的筛选我认为除了上述几条规范还应该从以下几点考虑

1. 此项目属于什么类型？

我认为一般项目分为两种，一种服务业务，一种是创建技术。如果自荐项目是偏业务那我们需要对其考虑是否符合大部分需求，而如果是技术类型，我们则需要判断是否会有同类型的项目，或者说同类型的项目数量是否很多。如果过多我们应该不予推荐

2. 项目是否已经运用到了生产环境中？

如果自荐项目已经使用到了生产环境中，我们应该去深入理解这个项目是否有值得推荐的亮点

3. 推荐细化分类

对于自己熟悉的领域，应该把推荐做出更加细致的分类，这个分类可以是针对不同技术水平的人做出分类