小组支持
Title
小组支持
Patlet
如果某个团队或个人不再支持 InnerSource 项目怎么办? 由一群感兴趣的个人组成小组来保持项目活跃。
问题
即便是一个广受欢迎的 InnerSource 项目也可能陷入孤立的困境。
当前没有明确的出路。
故事
一个 UI 组件类库,在全公司有 50 多个项目使用。 该类库的开发团队在资源耗尽后,宣布解散。 起初,没有人注意到,但过了一段时间,每当有人问“谁负责它”时,得不到答案。 接下来会怎么样? 新的团队会避免使用它吗? 该项目是否会停滞不前,直到其用户最终被迫转向其他项目? 如果一个完美且有价值的项目出现这种情况,那将是多么令人遗憾!
上下文
广受欢迎的 InnerSource 项目。
作为一个构件时的依赖项使用(比如 代码模块)。
没有活跃的开发者提供支持。
公司无法指派团队提供支持。
约束
没有人在日常工作中被指派负责这项工作。
每个人都很忙。
项目迁移的成本很高。
解决方案
团队应尽全力从以下方面管理项目:
维护. 如果项目在标准用例中完全失效,那就修复它。 随着项目使用的依赖关系和框架的不断发展,及时更新项目。
新人上手. 如果有人对如何使用项目有疑问,确保他们能得到合理的答复。
更新. 如果有人想在项目中添加新功能,请为他们提供必要的设计和技术支持,以便他们实现该新功能,使其既能为自己所用,又能为项目增光添彩。 及时评审收到的 PR。
由于该小组由志愿者组成,因此重要的是要传达提供“尽力而为”的支持。 因此,这种支持模式不太适合像实时 API 这类运行时关键的生产项目。 它更适合在构建时使用的项目,例如类库/包/模块。 该小组预计不会为其他人实现任何新功能。
结果背景
对 InnerSource 项目有些微弱的支持。
理由
已知实例
WellSky
状态
结构化
作者
翻译校对
最后更新于
这有帮助吗?