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 摘要。