该如何弥补 GitHub 功能缺陷？
译者 | 弯月
责编 | 屠敏出品 | CSDN（ID：csdnnews）
自从被微软收购之后，GitHub 就像腾飞的火箭一样，接二连三地发布新功能，比如免费的私有代码仓库、GitHub 赞助商项目等，都获得了开发者社区的青睐。
但是作为开源的中转中心，它离用户的期望还有一定的距离。
这篇文章讨论的就是这类的一个期待：一个 GitHub 尚未实现的功能，我以产品优先的方式，作为业余项目构建了这个功能。
缺失的功能
GitHub 最初是一个以 Git 版本控制系统为基础的代码托管平台，后来发展成了一个完整的软件开发平台。它非常适合软件开发的生命周期，人们通过各种方式使用它（改天我会写一篇博文介绍 GitHub 带来的网络效应及社会影响）。
Isaac 的代码仓库（https://github.com/isaacs/github）就是这个平台的冰山一角，人们在该代码仓库中请求 GitHub 提供新功能，他们会为自己希望的功能创建 issue，并为别人的评论点赞，期待着 GitHub 能够听到他们的请求。实际上 GitHub 的确听到了。我很喜欢利用表情符号对评论做出反应的功能，而这个功能就是起源于该代码仓库，后来被 GitHub 注意到且实现了。
找到需要完成的任务
“了解客户的真正需求。”
想知道产品有什么问题？只要去用户论坛或客户反馈频道看看，就能得到答案。
一年多以前，我在寻找一个业余项目，而这个代码仓库正是寻找 GitHub 缺失功能的地方。
现在我来公布大家最关注的缺失功能：关注组织。没错，你没办法像关注一个普通用户那样通过一个组织的账号来关注他们的行动。这是 Issac 的代码仓库上获赞最多的一个功能。
GitHub 会将用户产生的行为（如创建、加星、创建代码仓库分支等）显示在你的时间线中，以方便用户发现新动态（详情请阅读我的博文《GitHub 网络上的信息动态》（https://hackpravj.com/blog/information-dynamics-on-github/））。但没办法订阅某个组织并在组织产生行为（如组织创建了新的代码仓库）时获得通知。
是不是已经厌倦了？
如果你不想阅读有关开发过程的东西，那么可以跳过下面的内容，直接去访问 followgithub.org，这是一个浏览器扩展，允许你关注一个 GitHub 组织。它也是开源的，所以你可以随便修改。
选择了想法之后，就应该制定一个计划，通过尽早创建低成本原型的方式来管理风险，避免做出没人想要的东西。
根据该功能的动机，我的目标是在实现上花费最少的实践来开发最初的版本，来验证我的假设。首先，我只能在周日偶尔做这个项目，所以没有太多资源；其次，我不希望跟史蒂夫・布兰克的精益创业思想背道而驰。
“用最廉价的方法测试目标，时刻关注代价。”
我发现，解决方案的核心是主动地查询新的事件，但最难的地方是通知用户正在发生的事件。
我尝试了一些常用和不常用的信息发布渠道，如电子邮件通知（事件发送给经过验证的电子邮件地址）、推特机器人（随时更新关于某个组织的推特话题，或者针对打了标签的问题做出回应）。但这些解决方案并没有打动我，因为它们会在接触潜在用户之前，就将解决方案束缚在特定的渠道上。
我突然意识到，真正的发布渠道就在我眼前，那就是 GitHub。它非常适合将产品发布给正确的人群。它的社会化拉取功能可以让社区更紧密，让用户互相产生价值。最常见的例子就是各种 awesome 的列表（https://github.com/topics/awesome-list）。
有了这个想法，我就不需要再研究邮件通知服务，也不需要选择那些没有潜在用户的渠道（如推特）了。
我的朋友 Amit 把这个 MVP 发表在了 HackerNews 上（https://news.ycombinator.com/item?id=19261376），获得了一些早期的认同。
改进
几天之后，我开始与一些用户交流，为下一次迭代做准备。交流内容包括目前的优缺点，用户关注组织之后的感想，以及 issue 话题是否会造成重复的评论、错过一些事件等。
我根据 Rob Fitzpatrick 提出的 The Mom Test 方法准备了一系列的问题。
开放式问题：这个产品带来了什么改变？
日常习惯：平常怎样使用 GitHub？
过去的方式：以前怎样找到喜欢的 GitHub 代码仓库？
我意识到目前的产品在用户体验方面做得很差。（用于新建代码仓库的）通知发送系统并没有提供符合用户浏览习惯的原生 GitHub 体验。用户需要多次操作才能关注一个组织。
首先查找希望关注的组织对应的 issue 是否存在
建立一个 issue，评论中写上该组织的链接
有一天一个朋友在讨论中指出了 refined-github，这个著名的浏览器扩展能够简化 GitHub 的用户界面，添加有用的功能。这时我发现了一个能满足所有需求的真正的发布渠道。
使用浏览器扩展，你可以轻而易举地关注一个 GitHub 组织。
扩展和怀疑论
在与潜在用户和已有用户交流的过程中，我发现并不是所有人都喜欢浏览器扩展。由于潜在的安全风险，一些用户非常反感浏览器扩展。
于是我决定将这个扩展开源，以开源的方式构建。
通向成功之路
就像 Mike Perham 说的那样（https://www.indiehackers.com/interview/sidekiq-6e71309457），由于热情而创造并免费赠与，最后只能被大量的请求而压垮，导致项目失败。
我意识到，我应该给我在开发中投入的每一分钟都明码标价，至少要能付得起服务器的费用。我认为，出现了以下两种情形，项目才能称为可持续的成功：
GitHub 构建了该功能
我不再需要自己掏钱来维持该产品
标明正确的价格
在决定了成功之路后，就该明码标价了。我阅读了不同的定价策略（即 SaaS 的定价策略原理），发现每种策略都是双刃剑。
根据成本定价：如果项目依赖外界因素，那就很难计算出决策。而且，客户也不关心你的成本。
根据价值定价：很难将产品产生的价值量化。但如果产品有价值，那么该策略能够衡量用户的支付意愿。
深思熟虑后，我决定采用基于价值的免费增值定价结构，我觉得这是在目前情况下的正确策略。但我必须想出一种度量来定义用户产生的价值。
在该项目中，被关注的组织总数是非常好的度量。我设置的 “采纳者” 版本的限制为 10 个组织，原因如下：
用户不应该为了免费而放弃太多东西
10 个组织很接近部分新用户的关注数量（小样本统计结果）
折扣的促进作用
为了获取前 10 个或前 100 个客户，每个人都有自己的策略，而我的策略如下。
由于 GitHub 是强社会化游戏（也许并不适用于每个 GitHub 用户），人们想要通过创建代码仓库或为已有代码仓库做贡献的方式来创造价值，来换取在整个网络中的特别地位。在社交网络中鼓励更多的用户参与创造价值的努力，能带来更多的用户。
因此，我决定为那些为浏览器扩展做出贡献的人提供折扣。任何做出了有效贡献的人，我都会提供免费的 “支持者 " 授权。
欢迎所有人向这个项目做贡献，只要对最终用户有好处即可。
欢迎你提出对该浏览器扩展的看法。
原文：https://hackernoon.com/building-a-missing-github-feature-using-github-3f1f431lk
作者：Pravendra Singh，followgithub.org 的创始人，产品经理 @Vernacular.ai。
以上，便是今日分享，觉得不错，还请点个在看，谢谢～