InnerSourceCommons / InnerSourceCommons/InnerSourcePatterns
Pattern idea: Common metadata format to aid discovery of Inner Source projects
まだ誰も着手していません。
- 主要言語
- HTML
- スター
- 853
- フォーク
- 206
- 平均マージ
- 1日 23時間
- マージ済み PR(30日)
- 2
説明
Following on from a conversation in the ISC Slack, would a metadata file added to Inner Source repos in source control (e.g. inner-source.json or inner-source.yaml) aid discovery of Inner Source repos within an organisation? If so, should we define a common format for this metadata?
Alternatively, should this information be derivable from your SCM tool (GitHub/GitLab/Bitbucket etc.)? This would negate the need to add a file to each inner source repo in your organisation.
One suggested format:
# description should be one paragraph
description: This is where you describe the purpose to your users.
Is this a component library, is this a template project, what
benefit is there to me if I use this library in my own project. You
Could even say something about how the project is versioned here.
# github pages or a conflunce link by default
# could be a readme for the project
documentation: https://github.com/InnerSourceCommons/InnerSourceLearningPath/
# technologies used
technologies: Javascript, React, Graphql, etc..
# comma separated list, name <email> (url)
maintainers: Barney Rubble <brubble@flintstones.net> (http://barnyrubble.tumblr.com/)
Prior art:
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
まず、この issue で提案されている YAML フィールドを確認し、Prior art にリンクされている GrimoireLab projects file と Eclipse Foundation initiative を比較します。リポジトリファイルと併せて、ソース管理メタデータという代替案も検討してください。合意された形式に到達するか、形式を定義しないという明確な決定に至れば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- github, gitlab
- 領域
- developer-experience, tooling
- issue の種類
- 機能追加
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 25/100