github label有什么用？

国庆前夕的小休日，闲来无事翻看我们的第一个开源github项目- WeCMDB，突然发现一个很意外却很有趣的话题现象 - Issue Labels。

先解释一下什么是github issue label？ 下面的截图是github官方给出的解释：

Github为开发者提供了许多便于开发的功能，其中，issues功能被用来追踪各种想法，增强功能，任务，bug等。

再看看官方给出的默认 Labels有哪些:

好，看过这些，身为程序猿?攻城狮?的本猿?本能的在想，项目开源，去接受公众的洗礼，如果按照这个分类来说，bug 这个label下面的issue应该是最多的，毕竟那么多双眼睛在看，发现的bug应该很多。
（其实也不是很多双眼睛?在看，目前也就是116个star ?… 欢迎各位持续关注）

然后我就被啪啪打脸了，出现最多的issue不是bug，而是 - enhancement

没图说个xx，上图：

这说明项目的有较大提升空间。为什么会这样呢？

• 本位
  早些年有个这样一个经历：那年我大学暑假，家里的七大姑八大姨看我挺闲的，让我给我远方表弟补习一下小学三年级数学，热心的我二话没说就答应了。然而，这个补习只持续了一节课，因为当我说这道题应该用函数去解，可爱的弟弟问我什么是函数的时候，我: ,.%$#。??? (我太难了?)。
  所以说，开发者要换位思考，去站在用户的角度想问题，用户可能是懂技术的，也可能不是懂技术的，不要用开发者的技术栈和技术水平去理所当然认为用户也应是在一个水平线上，要放低姿态，从小处着手。
• 产品设计
  在传统闭源开发项目中，项目人员分工明确，产品会给需求，设计会给UI设计稿，开发者来搬砖实现产品。拷问灵魂的额问题来了，你觉得你写完的代码，做出的功能好用吗？答案一定不是100%好用，因为有的时候就算没懂需求，照着设计稿也能把产品做出来交差。
  项目开源之后，开发者也承担起了产品设计工作。原本只需要码代码的程序猿?们攻城狮?们也开始了写需求文档，画页面交互（天道有轮回，苍天绕过谁），不得不说，这种模式开发的功能模块比以前质量高很多，使用起来更顺手，也更符合产品定位。
  只有你真正理解了你要做的产品，你才会把产品做好。

项目开源，是一个起点，一定不是终点。革命尚未成功，同志仍需努力。?