InnerSourceCommons / InnerSourceCommons/InnerSourcePatterns

Pattern Idea: InnerSource Program Office

未关闭
#365 6 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

:book: Type - Content Work 1-initial
主要语言
HTML
星标
853
派生
206
平均合并
1 天 23 小时
30 天内合并 PR
2

描述

In our Slack this conversation happened:

Q: Is there a place where I can find a charter for an InnerSource program office?
A: The “charter for InnerSource Program Office” depends on the situation your company is in and where it wants to go — there are as many designs as there are members in the InnerSource Commons. Do you have an effort with top-level management support or more a grassroots movement? Are you trying to improve transparency, cross collaboration, communication, reuse, time to market, reduced defects, or something else? Do you have a picture of the current barriers and what capabilities need to be developed for your next low hanging fruits?

We have some patterns that either mention an InnerSource Program Office (ISPO), or are written from the perspective of an ISPO. Of particular interest could be the Explicit InnerSource Principles pattern that has a section on "Why does the organisation want to adopt InnerSource?".

However we don't have a pattern describing what an ISPO is, how to establish one, and what problems can be addressed through it.

We recognize that there may be different reasons for establishing an ISPO, as well as different charters that an ISPO may follow. However we think that it is possible to describe the main building blocks for establishing an ISPO in the form of a pattern.

Things that could support the creation of such a pattern

  • list the patterns that mention an ISPO already (or similar concepts) => allows us to understand whether we even mean the same thing when talking about an ISPO in the existing patterns
  • review content from the TODO Group on how to create an OSPO. That might be similar to the creation of an ISPO.

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

调研方向

首先审阅 Explicit InnerSource Principles 模式以及 issue 中链接的 TODO Group OSPO 指南。盘点提到 ISPO 或类似概念的现有模式,然后利用这项研究定义该模式的主要构建模块。当一个模式解释 ISPO 是什么、如何建立 ISPO,以及它可以解决哪些问题时,即视为完成。

由索引模型根据 Issue 内容生成。

评估

领域
documentation
Issue 类型
文档
难度
5/5
预计耗时
一周以上
活跃度
停滞
描述清晰度
基本清楚
新手友好度
25/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。