从Github 2021年度报告谈开源技术项目的文档问题
最近, Github发布了它每年一度的分析报告,https://octoverse.github.com/,内容很丰富,国内各大技术媒体也都有相关的报道,他们各有各的解读,有的是从中美开发者数量来解读,例如中国开发者数量约为700万;有的是从开发语言流行度来解读,比如最流行的开发语言还是JavaScript。我现在想从另外一个角度来解读这份报告,即documentation 文档。
这份报告里面有一个特定的部分是描述文档相关的统计情况和发展趋势。我们来仔细看一看。
首先是概述,repo中的Readme,Contribution guidelines and issues 是一个开源项目的秘密,保持它们update to date、detail、reliable,能提升开发人员50%的生产力。
我们先来看Readme文档部分,Report的overview中提到readme文档的重要性。
从统计图能看出,85%以上的开源项目都有了Readme文档。
然后我们来看Contribution Guidelines,显然越来越多的开源项目中有这份文档。
之后,Report也提到了Issue, issue也是很重要的文档,其中被标签为“Good First Issue”的issue是项目特意标出、
适合给new comer来完成第一个contribution的issue,Report表明repo如果“Good First Issue”的比例超过40%,能多获得21%的新贡献者。
最后,报告里说“Documentation is good for productivity and culture - it's a win-win”。
ok,对于报告的解读已经告一段落,那么对于一个开源项目来说,究竟哪些文档是必不可少的,而且这些文档最低限度需要达到什么质量要求呢?
带着这个问题,我组织了一个workingroup,邀请了KubeSphere社区的周鹏飞同学,和StreamNative社区的Yu和Jennifer同学,经过讨论和协作,大家一起完成一份文档即《开源技术项目的文档指南》,链接在这里---https://github.com/CommunityLeadershipDevelopment/doc_guide.
我们认为,一个希望进行社区协作的开源技术项目,至少需要如下4份文档:
- Readme: 用于描述项目的最基本信息,并用于链接到其他重要信息
- Quick Start:用于让用户在10分钟内体验到该技术项目的一个场景,从而让用户持续深入进去
- Contributing Guide:描述给这个项目做贡献相关的步骤和方法
- Code of Conduct:用于规定社区协作的最基本礼仪
其中每个文档指南都有自己最基本的质量要求,比如Readme文档需要包含项目介绍,和到QuickStart,Contributing Guide,Code of Conduct,License的链接,项目介绍需要通俗易懂;Quick Start文档需要包含如下模块和具体步骤:使用软件的先决条件,如何下载,如何安装,如何使用,文档需要易使用,易查找,易理解等。
这个文档指南的使用场景如下:
- 开源项目的负责人可以参考此文档,检查自己的开源技术项目是否已有这些文档,这些文档是否达到本指南的各个质量要求
- 开源项目的文档负责人可以参考此文档,把这些文档作为自己项目的文档模版,按需增补自己项目的特定内容,从而快速达到文档完备的基本要求
- 本指南作为开放原子基金会TOC的工作文档一部分,作为导师帮助孵化项目达到文档质量要求的参考和Checklist
- 作为开源项目技术传播社区(包括布道,文档等)的一个初始产出
目前这份指南已经出了1.0版本,也希望国内开源项目的同学可以一起来参与和讨论。
https://github.com/CommunityLeadershipDevelopment/doc_guide.
而且checklist已经正式作为开放原子开源基金会的导师工作手册的一部分,将帮助基金会内孵化项目的导师来进行项目文档质量的check。
另外,开源项目技术传播社区的二维码如下,欢迎大家扫码加入,和我们一起讨论开源项目技术传播的事情,包括技术文档协作,技术线上和线下布道等等。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
为什么要做漏洞扫描呢?
摘要:本文介绍做漏洞扫描的内外部驱动力。 本文分享自华为云社区《5W2H 分解漏洞扫描 - WHY》,作者: water^3 。 降低资产所面临的风险 我们知道,漏洞的典型特征:系统的缺陷/弱点、可能被威胁利用于违反安全策略、可能导致系统的安全性被破坏。 从信息安全风险评估规范GB/T 20984可以知道,分析风险的计算公式为:总风险 = 威胁 * 漏洞(脆弱性) * 资产价值。 由此可见漏洞是计算风险的重要变量,漏洞越严重,资产面临的风险越高。通过漏洞扫描及时发现漏洞,及时修复高危漏洞,能够有效降低资产的风险。 风险并非看不见摸不着的,漫漫历史长河里,风险的发生往往意味着大笔的钞票烟消云散。以2017年5月份爆发的WannaCry勒索病毒为例,它利用了微软公司MS17-010涉及到的SMBv1远程代码执行漏洞,最终150余个国家遭到攻击(幸免的国家,要么没有计算机,要么没有互联网),给全球造成逾80亿美元经济损失【引自路透社】。 如何防范这一攻击呢? 最经济有效的方法就是给受漏洞影响的Windows系统打上安全补丁。哪些版本的Windows系统存在相关漏洞呢? 事实上,2017年3月...
- 下一篇
可视化DataEase使用的心由历程,运维人员的可以轻松上手的开源软件。
前言: 关于DataEase,很早有所了解,是飞致云公司的开源产品,楼主曾经部署使用过他们家的Jumpserver开源堡垒机,KubeOperator多云管理平台,DataEase大数据大屏可视化BI(曾经的使用局限于部署层面,还没有把可视化数据进行呈现),这次双十一在北京出差的时间里,楼主下班后在酒店打开电脑开始重新部署起来了,目标是不仅仅是部署,而是实践使用,理解认知,在将来的工作和生活中,让软件服务工作和生活。楼主目前买了三台云服务器,配置是2核心4G的,部署可视化平台,就需要服务器,关于服务器资源这块,以前部署的思维是自己家是一台x99服务器,24线程,96G的,在家部署测试开源软件,其实无法做到随时可以访问,上云后,就可以很好的跑起来了,本次分享的DataEase也是在云上跑的,本文主要介绍了为什么部署,怎么部署,怎么实践,如果你也感兴趣,我们一起来体验和感受开源产品的数字化便捷之旅。 阅读本文,如下图所示,你将会get到新技能,自己手动部署一个可视化平台,用于运维,开发,和自己家里的智能家居的状态,公司业务状态都是可以使用的,非常直观而便捷,高大上。 DataEase出身...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Hadoop3单机部署,实现最简伪集群
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- MySQL8.0.19开启GTID主从同步CentOS8
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS7安装Docker,走上虚拟化容器引擎之路
- Docker安装Oracle12C,快速搭建Oracle学习环境