编者按：开放源码街道社区在这儿？去年我累积了些为 GitHub 工程项目工程建设开放源码街道社区的实战经验，N45EI243SF思索那个难题。前段时间，GitHub 面世了几项新功能，才让我确认标准答案：对两个 GitHub 的开放源码工程项目，它的街道社区就在 GitHub 上。
责任编辑页数：4537，写作时数约： 7两分钟
https://mp.weixin.qq.com/s/KIEJEy_Ut-h7KSYcTLaGEA
译者：打建筑工人 Coco
开放源码街道社区在这儿？
去年我累积了些为 GitHub 工程项目工程建设开放源码街道社区的实战经验，N45EI243SF思索那个难题。
前段时间，GitHub 面世了几项新功能，才让我确认标准答案：对两个 GitHub 的开放源码工程项目，它的街道社区就在 GitHub 上。
你或许觉得我在说废话。
假如你那么想，请听我细看道来。
GitHub 上的新街道社区
“全世界的现代人都在亲吻开放源码和 GitHub。GitHub 不但是标识符开发人员的家，也成了各个领域的现代人组织工作、自学、与街道社区交互、为开放源码作重大贡献的网络平台。” —— GitHub 2020 年报GitHub 是亚洲地区最小的开发人员网络平台，也是两个街道社区型的标识符工程项目协同网络平台。
GitHub 的新一代统计数据表明，GitHub 在亚洲地区范围内已近 5600 万开发人员使用者（我国使用者数量名列第三，仅次英国），近两年内造成了 19 万次重大贡献。
那些重大贡献的绝大多数，都源自开放源码街道社区。
开放源码，意味着同街道社区一起交互、自学、创造。
但 GitHub 是否适合作为开放源码街道社区的大本营，组织街道社区成员进行交互、自学、创造？
无论你是工程项目的维护者还是使用者，都值得好好琢磨下那个难题。
假如你是工程项目的维护者，请问问自己：
◈ 你如何与街道社区对话？
◈ 街道社区成员如何与彼此对话？
◈ 你如何组织街道社区成员、完成更卓越的重大贡献？
假如你是工程项目的使用者，请问问自己：
◈ 你的难题如何得到快速响应和解答？
◈ 你如何获知该工程项目的新一代动态、公告？
◈ 你如何与工程项目建立连接、做出力所能及的重大贡献？
为了做到那些，开放源码街道社区至少要具备以下基础设施：
◈ 交互交流区
◈ 官方公告栏
◈ 街道社区知识库
此前，GitHub 只提供议题(issue)、拉取请求(Pull Request)功能进行街道社区的交互交流。这两种页面都是线性组织的，适合快速合并标识符，但不适合多线程的沟通和街道社区知识库的累积。而 GitHub 的 wiki 功能则相对较重，不适合碎片化优质内容的累积。
因此得出结论：
此前，GitHub 本身并不能很好地支撑开放源码街道社区的基础设施工程建设。
这就导致了，围绕工程项目造成的街道社区分散在互联网各个区域。
拿两个标识符工程项目举例：
◈ 工程项目的日常交流可能在 Gitter（一款即时聊天工具）、Slack、微信上
◈ 工程项目使用难题可能在 Stack Overflow、GitHub Issues 上
◈ 具体事项的讨论可能在自建的论坛、Google 群组上
◈ 街道社区相关的公告可能在维基、公司官网的新闻公告上……
如此“分布式”的交互，容易导致街道社区的松散、无组织：一方面很多优质的讨论和内容流落在外，另一方面为新成员融入街道社区平添了许多摩擦。
假如你也有同感，现在可以松一口气了。
因为 GitHub 近期提供了讨论(Discussions)功能，将“流落在外”的街道社区重新聚集起来，带回了离源标识符更近的地方——工程项目仓库 (repository)本身。
Discussions 功能简介
“软件街道社区的成员不只在一起写标识符。他们还能一起头脑风暴出新想法、新功能，帮助小白使用者快速上手，探索软件的最佳实践。街道社区需要自己的交互空间，这就是 Discussions 的意义。” —— 某 Hacker News 使用者“讨论”是 GitHub 去年年初面世的内测功能，当时官方选取了几个工程项目做内测，包括 Next.js、Tailwind CSS、Office 365 CLI 等。
该功能于 12 月 8 号正式开放公测。
目前，每个公共仓库都可以在 “Settings/Options/Features/Discussions” 处启用该功能。
启用讨论功能的设置页面
启用后，“讨论”作为仓库的两个独立区域（下图红框位置），用于街道社区成员问答交互，类似于论坛。
Next.js 工程项目的讨论首页
单个讨论页面与议题页面很相像，但讨论还提供以下新功能：
◈ 支持自定义讨论分类（比如可以有问答区、脑洞区、新工程项目展示区、求助区等）
◈ 支持将已近的议题迁移成讨论
ck Overflow）
◈ 支持开启对话的线索（类似于 Slack）
◈ 支持在讨论首页固定最多 4 个讨论（可作为官方公告栏）
讨论的利与弊
对工程项目维护者来说，“讨论”的好处如下：
◈ 补全 GitHub 的社交性，与仓库的其他功能紧密结合，共建完整的街道社区
收集 bug 和功能需求用 议题(Issues)、接受重大贡献用 拉取请求( Pull Requests)、工程项目协同及管理用 工程项目( Projects )和 看板(Kanban)、标识符持续集成部署用 动作( Actions)、接受街道社区赞助用 赞助者( Sponsors)、发布重要文档用 维基( wiki)，街道社区公告及交互用 讨论( Discussions)，一条完整的街道社区链路似乎已然补全了 🙂◈ 可以把除了 bug 报告和新功能需求的议题通通迁移到讨论，进行分类管理，减少议题中的噪音
一些大型仓库动辄就有上千议题，包括 bug 报告、新功能需求、使用者的使用难题、已近功能的讨论等等。议题种类混乱，极易堆积，管理起来十分痛苦。假如能将部分议题迁移到讨论，合理分类，借助街道社区的力量解决难题，或许能减轻工程项目维护者的负担。◈ 讨论版块作为街道社区入口，方便新人了解工程项目情况、街道社区文化
可以在讨论版块内放置工程项目的上手资料、重大贡献指南、标识符规范、博客链接甚至公开适配器列表、统计数据表现等等，鼓励街道社区成员在离源码更近的地方自学、交流、造成连接、累积知识库。
比如下图是 Next.js 工程项目专门建的讨论页面，鼓励街道社区主动完善适配器列表：
适配器列表所在的讨论页面
讨论的坏处如下：
◈ 对业余工程项目的维护者来说，启用讨论可能会加重他们的负担
讨论降低了交互的门槛，当更多的讨论涌入，维护者的组织工作就更多了。◈ 与议题的区分有些不明晰，工程项目维护者在初期可能要耗费一些精力来教育使用者，分清两种功能的定位
而对工程项目使用者来说，目前来看该功能有利无弊。
使用者的难题解决路径原来或许是这样的：
工程项目使用过程中碰到难题 -> Google -> Stack Overflow 或 GitHub 议题 -> 假如没有标准答案，则新建难题现在或许是这样的：
工程项目使用过程中碰到难题 -> 搜索工程项目的讨论 -> 假如没有标准答案，则新建讨论讨论慢慢会变成使用者第一时间寻求解决方案的地方，因为这里就是工程项目的专有街道社区。
GitHub 街道社区新形态展望
好的街道社区不但要让重大贡献者持续增长和参与，还必须尽量减轻工程项目维护者的负担。 —— GitHub 2020 年报有了讨论，未来的 GitHub 开放源码街道社区将呈现何种新形态？
那个难题目前很难回答，但我们可以看看从年初就开始内测讨论功能的工程项目，或许能一探未来的趋势。
去年 3 月，Office 365 CLI 工程项目宣布解散他们的 Gitter 论坛，以后所有的讨论都迁移至讨论：
Office 365 CLI 解散 Gitter 论坛的官推
Next.js 仓库去年 1 月开始使用讨论，截至 10 月，已使用超过 3000 个讨论进行交流协同。并且，在过去的两年中，向仓库做出重大贡献的人中近半数都使用了讨论。（统计数据源自 GitHub 2020 年报）
Next.js 仓库甚至将 RFC 从议题迁至了讨论，方便街道社区成员第一时间参与到新功能的讨论中（瞧瞧评论区的反响，这才是“活生生”、“有人气”的街道社区啊！）：
讨论版块下创建的 RFC 页面
目前 Next.js 仓库首页对街道社区的导流只有两处：两个是 GitHub 讨论，另两个是 Discord（轻量的聊天应用）。前者用于提问、分享新想法和新工程项目，后者用于与街道社区成员聊天。
Next.js 仓库首页对街道社区的引流
从上面的例子可以看出，社区正朝着统一化的方向在发展。统一网络平台的街道社区管理方式，不但能降低街道社区成员的参与成本，也能在一定程度上减轻工程项目维护者的运营压力。
因此，我斗胆在这展望下日后的开放源码街道社区形态：
All in GitHub
◈ GitHub 议题：用于收集 bug 和待开发的新功能
◈ GitHub 讨论：用于发布三类信息 (1) 新功能的 RFC；(2) 帮助和公告信息，如重大贡献指南、标识符规范、街道社区活动的宣传等；(3) 日常的问答与交流
◈ GitHub 工程项目：用于追踪开发进度、街道社区成员可以参与协同
◈ GitHub 拉取请求：用于提交标识符、街道社区成员可以参与审校
讨论让工程项目信息的发布变得更快捷、集中、透明。街道社区成员留下的每一条问答，都是对街道社区知识库的重大贡献；他们在 RFC 讨论区留下的每两个，都真正参与了工程项目的决策。
每个开放源码工程项目的译者，或许都梦想过拥有两个活跃、自治、重大贡献度高的开放源码街道社区，加速工程项目的高质量迭代。
现在，我们离那个梦，似乎又更近了一步。
结语：GitHub 的雄心壮志
毋庸置疑，GitHub 是一款非常棒的产品。自 2018 年被微软收购后，面世了更多走心、实用的功能。
作为一名 GitHub 的产品粉，我由衷地感到欣慰，GitHub 仍在积极地重新定义产品的边界，不断面世让千万使用者眼前一亮的新功能。
但在 Hacker News 上，许多开发人员对 GitHub 王国的「版块扩张」表示担忧：
◈ 2008 年，新功能 Pages 发布，与诸多网站托管网络平台对线
◈ 2016 年，新功能 Projects 发布，与 Trello、Waffle 对线
◈ 2018 年，新功能 Actions 发布，与 Travis、CircleCI 对线
◈ 2019 年，新功能 Sponsors 发布，与 Patreon 对线
◈ 2020 年，新功能 Discussions 发布，与 Stack Overflow 对线
GitHub 在性能和 UI 方面做得很好，使用者很难抗拒在同一网络平台上把那些事全做了。但在长远看来，网络平台建立垄断性优势，对使用者来说未必是件好事。
这或许确实是 GitHub 的雄心壮志。
不过，站在 GitHub 的角度无可厚非，站在用户的角度有利有弊。
目前看来，对普通的工程项目译者和使用者，利肯定远远大于弊。至于未来如何，让我们拭目以待吧。
