介绍
使用开源软件现在已成为我们生活的一部分。现在可以说，开源软件几乎在所有领域都占有主要市场份额。
亲自验证应用程序内部发生的情况在 DeFi 中尤其重要，其中透明度和开放性是关键的哲学因素。例如，任何第三方安全研究人员都可以审核和验证任何开源项目的安全状态。这在最终用户和其他开发人员之间建立了很大的信任。
如果需要，每个人都可以帮助改进他们使用的软件，这在开发人员之间建立了联系，并围绕软件形成了一个社区。
毫不奇怪，这些想法是 Web3 和开放区块链运动的关键要素。
与开源社区合作的初步技巧
您或您的公司是否刚刚开始构建开源项目？与开源社区合作可能非常棘手！关于社区指南和所需工具的独特功能，有很多东西需要了解。
今天，让我们分解这些初始步骤，看看它们如何真正使您的项目和社区受益！
GitHub 作为开源代码的主要平台，实际上在每个存储库中都有这些指南。
我们以wemake-python-styleguide 项目为例。
GitHub 清单包括：
- 描述
- 自述文件
- CoC
- 贡献.md
- 执照
- 问题模板
- 拉取请求模板
在本报告中，我们将浏览列表中的所有项目，并进一步讨论 GitHub 未在上面列表中作为“强制”包含的重要功能。
问题和请求请求
问题和拉取请求是任何软件项目的基本要素。
没有这两种形式的沟通，你绝对无法构建一个社区项目。
但如何组织这种沟通存在很多陷阱。
幸运的是，有一些功能和技术可以帮助您！
表格/模板
任何开发人员在谈论问题时面临的第一个问题是需要用户提供哪些信息来修复错误/开始新功能讨论。
现在，我们需要使用 GitHub 问题模板或/和表单来指定我们需要哪些信息。以下是一些帮助您入门的示例：
不同之处在于它们可以忽略所有模板字段。该表单可以包含必填字段。
文档：
我想指出的是，您可以而且应该向模板添加标签：
Name: Rule request
About: Request a new rule to be checked
Labels: 'rule request', 'feature'
指定的标签将自动用于创建的问题。为什么这有帮助？
它可以帮助维护人员根据这些标签轻松过滤不同的问题类型。
您还可以在“创建新问题项目页面”上附加外部资源的其他链接 - 例如，https: //github.com/python/cpython/blob/main/.github/ISSUE_TEMPLATE/config.yml 和https://github.com/python/cpython/blob/main/.github/ISSUE_TEMPLATE/config.yml 和https:// /github.com/python/cpython/issues/new/choose。
如果您想突出显示现有的外部资源（例如支持论坛、社区不和谐等），这可能会有所帮助。
同样，您可以为拉取请求创建一个模板 - example。
它通常会要求您在提交代码之前检查是否正确执行了所有操作。
CONTRIBUTING.md它通常最精确地匹配实际项目（我们将在下面讨论）。
已保存的回复
困扰开源维护者的下一个问题是相同的讨论会多次出现！
公司可以针对持续存在的问题开发共享文本响应：
- 垃圾邮件
- 问题超出范围
- 错误报告不完整
- 无法重现的错误
- 不会实现的功能。
为了解决此类问题，使用了一个包含准备好的和批准的答案列表的私人存储库。
算法很简单：
- 开发人员注意到一个反复出现的问题。
- 他们在私人存储库中创建一个问题。
- 公司签署并创建一个包含现成答案的文件，该文件很容易找到。
- 完毕。
该文件还可能包含需要执行的操作 - 例如，删除评论、禁止用户等。
一些常见的答案可以保存到您的个人资料中：https://docs.github.com/en/get-started/writing-on-github/working-with-saved-replies/about-saved-replies。
例如，如何打击垃圾邮件？我的“已保存回复”：
Hi, I will assume this was an accident because this entry looks like spam. Maybe you miss-posted this by accident?
In any case, I will delete this entry for now. In case this was actually spam, we will have to block you at the next attempt to post something unrelated because it will consume the unpaid time of our open-source contributors.
使用准备好的措辞良好的回复来解决重复出现的问题，并为自己节省一些时间来处理重要的事情。
代码审查实践
代码审查非常困难，因为这是工程和同理心技能必须共同发挥作用的地方 - 特别是当您的团队成员来自不同的文化和语言背景时。
人们很容易无意中发表一些严厉的评论。
我使用并向其他人推荐「语义代码审查」风格：https://conventionalcomments.org/
这种方法可以高精度地识别您的意图，这使得您的代码审查注释非常容易解释。
此外，还有一系列您应该做的事情：
- 运用同理心
- 提供帮助
- 说“谢谢”，要有礼貌
- 热情好客，成为你想与之共事的人
- 自动化所有事情。从机器人那里获得反馈比从人类那里更容易
- 提出问题，提出替代方案
- 教育他人并向他人学习
- 批评解决方案。
以及你完全不应该做的事情：
- 假设每个人都知道与您相同的事情。
- 假设每个人都以与你相同的方式思考和做事。
- 批评或责备某人。
同样重要的是要明白，不仅你说的“内容”很重要，而且你说的“方式”也同样重要。为开发人员提供良好的「语气」指南：
- https://developers.google.com/style/tone
- https://linkedin.com/learning/inclusive-tech-conducting- humane-code-reviews/tone-of-voice
这套简单的规则可以提高您的代码审查实践并让人们更快乐。
代码所有者
有时，新的贡献者会遇到代码某些部分的问题，但他们不知道向谁寻求帮助或审查。
如果将.github/CODEOWNERS文件添加到存储库，则可以指定哪个用户审阅应用程序的特定部分。当不同的人或团队处理应用程序的不同部分时，这对于大型项目尤其重要。文档在这里。
您甚至可以将所有者的评论设置为“强制” -例如。
安全
安全问题不应公开报告，否则不良行为者可能会利用公开的安全问题来谋取利益。
但 GitHub 具有处理安全性所需的最低限度的必要功能。
存储库的所有者需要安装：
- 安全策略：带有路径的文件
.github/SECURITY.md，其中描述了用户在项目安全中发现严重错误时该怎么做。经典解决方案：写信到特定的电子邮件地址（并且不公开发布报告）示例在这里。 - 安全建议：您可以针对已知和已修复的漏洞打开 CVE。
- Dependabot 警报：如果您的依赖项之一获得新的 CVE，则来自 GitHub 的通知。
- 代码扫描警报：使用 CodeQL 时自动创建。
这四个简单的步骤可以满足您项目的安全需求。
另外，请确保遵循代码内安全最佳实践并使用特殊工具作为 CI 的一部分。
自动化
如果某件事可以自动化，那么它可能应该是自动化的！
GitHub 应用程序和操作在问题和 PR 的管理方式方面发挥着重要作用。您可以使用现有的自动化，甚至可以编写我们自己的自动化。例如：
- 您可以添加 Stale Bot，它将关闭旧的和不活跃的问题和 PR —例如
- 如果贡献者需要在发送代码之前签署 CLA，您可以添加 CLA Bot —示例
- 自动添加必要的标签来发行：https ://github.com/marketplace/issue-label-bot
- 您可以根据特定标准甚至随机自动选择 PR 的审阅者：https://github.com/marketplace/actions/reviewer-lottery
- 您可以使用 GitHub Actions 或 Danger 编写自动化： https: //github.com/danger
不需要的行为
现在，让我们将焦点转向人，因为没有用户，您的社区项目就不会成功。
与人合作是很困难的！
不同的问题情况甚至冲突都会发生。这就是可悲的事实。
值得庆幸的是，已有关于如何制造、预防和解决冲突的指南。
这些指南被称为“行为准则”，它们是无价的。毫不奇怪，大多数最大的开源项目已经拥有一个。
良好行为准则的示例：
- https://github.com/python/.github/blob/master/CODE_OF_CONDUCT.md 和 https://www.python.org/psf/conduct/
方向：GitHub、邮件列表、会议。
为什么它被认为是好的？
尽可能详细地写出不良行为的示例。它们应该包括广泛的历史事件，这些事件已经被纳入规则中。
公开“违规行为”列表的可用性：https://pythondev.readthedocs.io/diversity.html#python-code-of-conduct-bans
公开讨论问题，例如：https ://discuss.python.org/t/discussion-about-recent-coc-events/5778
适应各种沟通渠道。
为什么它被认为是好的？
它涵盖了广泛的问题。
它为广泛的开源社区提供服务。
它拥有大量的实际经验和多个正在改进的版本。
值得指出的是，您可以为组织中的所有项目创建一个 CoC - 例如，https://github.com/python/.github/blob/master/CODE_OF_CONDUCT.md
包含代码
让您的项目变得更受欢迎的另一个重要部分是在代码库中使用包容性语言：变量名称、注释、配置选项等。
以下是有关此主题的一些良好指南的链接：https://chromium.googlesource.com/chromium/src/+/master/styleguide/inclusive_code.md
自述文件.md
您的自述文件是您项目的入口点。
这是每个人看到的第一件事。
给人留下良好的第一印象很重要！
一个好的东西README.md有：
- 项目目的明确
- 演示/代码示例
- 下一步
一个好的例子README.md： https: //github.com/wemake-services/wemake-python-styleguide
互联网上有许多样式、指南和现成的模板。您可以选择您喜欢的：
- https://www.makeareadme.com/
- https://thoughtbot.com/blog/how-to-write-a-great-readme
- https://gist.github.com/ramantehlan/602ad8525699486e097092e4158c5bf1
我想指出的是，您还可以README.md在组织级别上创建文件，例如：
它对于突出常见的事物很有用：重要链接列表、沟通渠道、特色项目、支持等。
CONTRIBUTING.md
每个开源项目都有不同的贡献规则和流程。
新手如何知道每种情况下该做什么？
CONTRIBUTING.md正好解决这个问题！
该文件处理向您发送 PR 所需执行的操作。它可以非常简单： https: //github.com/wemake-services/wemake-python-styleguide/blob/master/CONTRIBUTING.md
或者它可以像一本书一样大：
在编写自己的贡献指南时，您应该瞄准什么？关键标准：
- 步骤清晰
- 深度以及描述了多少典型问题
- 实用性：它需要有用于主要任务的命令/片段：发布、运行测试、构建等。
它通常显示创建 PR 的确切方法：包含什么和不包含什么。
此外，经常描述核心开发人员的规则：如何合并分支、如何在压缩时重命名提交等。示例： https: //github.com/python/mypy/blob/master/CONTRIBUTING.md
有了好的东西，CONTRIBUTING.md吸引新的贡献者就会容易得多。
许可证
许可证很复杂。对于特定东道国每个特定项目的许可证选择，有必要与专业律师进行长时间和深入的咨询。
您需要额外注意：
- 在私人项目中使用您的代码的可能性
- 使用您的代码创建其他人的专利的可能性
- 可以将您的代码“作为服务”用于其他公司（典型示例：数据库即服务）
或者您可以使用https://choosealicense.com等服务。
最流行的选择是：MIT, BSD, Apache, GPL。
发布
完成上述所有步骤（编写代码并发送、审查和合并 PR）后，就可以发布版本了。
将发布信息存储在项目的存储库中非常重要。为什么？
- 让社区及时了解新版本。GitHub 甚至还特别订阅了“仅发布”存储库。这对于那些关注更新的人很有用。
- 描述技术变更：API/ABI/插件/构建/等。——开发者感兴趣的一切。
- 否则，您的用户将很难理解：发布了什么、未发布什么、哪个版本是最新的等等。
GitHub 有一个内置的git tag发布和发布控制系统。例子：
- 标签： https: //github.com/wemake-services/wemake-python-styleguide/tags
- 发布：https ://github.com/wemake-services/wemake-python-styleguide/releases
有一种最流行的格式来跟踪此类更改：CHANGELOG.md称为“保留更改日志”的文件+文本格式：https://keepachangelog.com/en/1.0.0/
另一个问题是：如何生成下一个版本号？
有几种版本控制系统（按流行度/适用性排序）：
有一个选项可以根据CHANGELOG.md提交消息自动生成和创建版本： https: //github.com/semantic-release/semantic-release
但这是个人喜好，完全没有必要。
对话中还可以提及 GitHub Package Registry 和 GitHub Container Registry。这些是容器或特定于语言的包的工件存储库，它们不仅需要作为存储缓存和中间工件的“技术”位置。它们应该被视为创建版本的官方场所。
讨论
如果存储库对其使用有很多疑问，有两种策略：
- 在 StackOverflow 上创建您自己的标签（如果有人具有特定的声誉阈值）
- 启用 GitHub 讨论以进行一起讨论。
通常，选择是根据活动量做出的：如果 SO 的讨论已经开始，那么继续下去会更合乎逻辑。如果讨论是在 GitHub 上进行的，那么将其转移到其他地方就没有意义。
有时，人们使用“讨论”来表达支持问题和新功能想法，而使用“问题”来表达错误报告。
结论
我们已经介绍了您开始开源之旅时所需的大部分初始技巧：从提交想法到发布其实现的所有内容。
但这还不是全部！
建立和管理一个健康的开源社区需要大量的知识、热情、同理心和奉献精神。咨询其他维护者，向他们学习，作为大型项目的贡献者参与，并向他们学习！
并且不要忘记享受乐趣。
本站所提供的所有资讯均仅供读者参考。这些资讯不代表任何投资建议、提供、邀请或推荐。读者在使用这些资讯时，应当考虑自己的个人需求、投资目标和财务状况。所有投资都伴随着一定的风险，在做出任何投资决策之前请多加留意。