Closed LinuxSuRen closed 6 months ago
这是非常有意思的一个问题，感谢这位朋友的提问。
提到开源项目，其实会有很多不同的类型，可能会收到项目的发起人（公司、组织等）、成员组成、治理模式等等的因素影响，具体到特定的开源项目他们的协作方式不尽相同，甚至有可能是千差万别的。以下是我个人比较认可的模式（社区驱动的项目）：
让我们假设项目 A 是为了解决特定领域的技术问题，或者是特定的用户场景需求，项目发起人已经当前阶段的维护者（maintainer）在这个项目的投入过程中是以解决问题为主。也许会出现如下的角色：
当某个 feature 或者 bug 的修复方式是否被接受，可能是由项目发起人、或维护者集体（通常不需要全体，也就是对这个领域感兴趣的部分）讨论来决定。
如果我理解没错的话， @wu-sheng 认为一个大的 feature 被接受的前提是现有的维护者愿意持续维护，或者那个 contributor 是被这个社区所熟知并认可的。毕竟，任何优秀的代码赖以生存的前提就是有人持续维护。
最后，建议本短文的读者努力采用异步沟通的方式来进行，避免 DM（直接发消息给某个维护者）。另外，建议把 issue 当作一个问题或 feature 的交流场所，而讨论或者提问则在 discussion 中进行。
这是非常有意思的一个问题，感谢这位朋友的提问。
提到开源项目，其实会有很多不同的类型，可能会收到项目的发起人（公司、组织等）、成员组成、治理模式等等的因素影响，具体到特定的开源项目他们的协作方式不尽相同，甚至有可能是千差万别的。以下是我个人比较认可的模式（社区驱动的项目）：
让我们假设项目 A 是为了解决特定领域的技术问题，或者是特定的用户场景需求，项目发起人已经当前阶段的维护者（maintainer）在这个项目的投入过程中是以解决问题为主。也许会出现如下的角色：
当某个 feature 或者 bug 的修复方式是否被接受，可能是由项目发起人、或维护者集体（通常不需要全体，也就是对这个领域感兴趣的部分）讨论来决定。
最后，建议本短文的读者努力采用异步沟通的方式来进行，避免 DM（直接发消息给某个维护者）。另外，建议把 issue 当作一个问题或 feature 的交流场所，而讨论或者提问则在 discussion 中进行。