コントリビューションの WhyとHow

コントリビューションの動機づけと始め方（Kubernetes Upstream Training）の紹介をします。

Transcript

1. コントリビューションの WhyとHow NECソリューションイノベータ 　武藤　周 　解　紫圯
2. 自己紹介 武藤　周 (Shu Muto) NECソリューションイノベータ Kubernetes SIG UI Chair Kubernetes Dashboard Maintainer Kubernetes Upstream Training Organizer CNCF Ambassador CNCJ Organizer 解　紫圯 (XIE ZIYI) NECソリューションイノベータ Kubernetes SIG Storage contributor Kubernetes SIG Docs contributor Kubernetes Upstream Training Organizer CNCJ Organizer
3. コントリビューションの Why 01
4. オープンソースとライセンス（おさらい） OSSを使いやすくするための指針となった • ビジネスで安心してOSSを調達、利用できるようにした • OSSの普及に大いに貢献した • 「オープンソース」の定義を満たすと認定した一覧 • 条件の違い：無償利用の範囲や方法、再配布の方法、派生物の公開義務など • 商用利用できるライセンス、それを採用している OSSの明確化 • オープンソース・イニシアティブ(OSI)によって定義された用語 • 無償、ソースコード公開、変更可能、要ライセンス、要ライセンス再配布、差別禁止 （個人、組織、分野、ソフトウェア、技術） オープンソースの定義　https://opensource.org/osd 「ライセンス」一覧　https://opensource.org/licenses
5. 4つの観点：OSS普及とその影響 あるいは、オープンソースの定義や認定ライセンス一覧が伝えなかった事 • 簡単すぎる調達 • ライセンスの範囲 • 導入後にかかるコスト • 業界に対する貢献 • スキルアップ • 大きな開発者満足度 • 誰でも参加できる開発手法／文化 • 開発者や企業が参加、貢献する目的 モノ：OSSそのもの ヒト：OSS開発者・貢献者の意図 カネ：コストはかかる コト：ソースがオープンである 　　　意味と価値
6. モノ：OSSそのもの • 「条件に従って使っていいよ」という利用許諾 • 利用者が責任を持って使う • ダウンロードするだけ • 無償利用可能（購入手続なし） • これらの強すぎた価値 簡単すぎる調達 ライセンス範囲
7. カネ：コストはかかる 利用者が責任を持って使うためにかかるコスト • ほとんどのプロジェクトで無視できな い量のOSSが利用されている • 複雑な依存関係 • 開発時だけでなく、運用後にもかかる コスト • サプライチェーンのサステナビリティ 確保 • バージョンアップなどで使えなくなる、 適用し直す必要がある バージョンアップにかかるコスト OSSプロジェクトの存続のリスク バグや脆弱性が発覚するリスク 自分で修正パッチや使い方のTipsな どを抱えるリスク
8. カネ：コストはかかる • 自発的、迅速、直接的な課題解決が、お客様や市場に評価される • 源泉であるOSSコミュニティ（アップストリーム）に貢献（還元） • 貢献を出発点とすることを「アップストリームファースト」と呼ぶ リスク回避の有効な手段 割とすぐに評価される価値
9. ヒト：OSS開発者・貢献者の意図 • スキルだけでなく、モチベーションやエンゲージメントの向上 • 人材獲得チャンスと人材流出リスク ◦ この価値を認識し、評価している企業に開発者が流れる傾向 ◦ 組織として認識する必要性 • OSS貢献で得られる多大で多様な学びと刺激 ◦ スキル、カルチャー、リーダーシップ、交流、 etc ◦ オープンでグローバルな実績 業界・社会に対する貢献と大きな開発者満足度 評価されるまで遠い価値
10. コト：ソースがオープンである意味と価値 • 未来の価値 • 世界中の開発者とユーザーがコラボレーションする場 • 多様性と包括性を持ったコミュニティ 誰もが参加できる開発手法であり文化 評価されるまで遠い価値 • オープンイノベーションに参加し、実践すること 開発者や企業が参加、貢献する目的
11. 組織や国境を越えて協力して課題を解決し、 発展する方法としての オープンソースの価値を得る！ • OSSそのものだけでなく、コミュニティ（ヒトやコト）の価値を得る！ • 「オープン」かつ大規模な集合知による、「イノベーション」の実践！ • 自らの事業、お客様、業界／社会の「三方良し」で実践しましょう！
12. コントリビューションの How 02
13. 日々の仕事で使っているOSSにバグが発生した際に、プロジェクトにフィードバックするの もコントリビューションの一つ！ OSSへのコントリビューション方法 機能要望やバグ発生 ソースコード変更による機能追加／変更やバグフィックス 品質確保 テスト追加 説明不足 ドキュメンテーション 課題管理 バグ報告などのフィードバック 進捗管理 プロジェクト運営 販売促進 イベント開催やブログ／SNS発信 情報収集 カンファレンスやユーザー会への参加
14. ▪ 知らない方とたくさんやり取りしな いといけません… ▪ 英語で交流するのは基本ですが、 英語苦手でうまく交流できるか不安 … 遭遇する可能性のある問題 ▪ どこでどなたにフィードバックすれ ばいいですか… ▪ 各プロジェクトそれぞれルールも ありそうで、どうフィードバックすれば いいですか… どこでどう始めればいいか コミュニケーション不安
15. プロジェクト参加の方法を調べる ▪ GitHubにCONTRIBUTIONとい う貢献方法を明記するファイルが 置いてあることがある ▪ GitHubのIssuesが利用されて いることが多い ▪ SBOM などを作成すると、情報 として記載されたりする ▪ 貢献内容によって、どのレベル の技術やコミュニケーションが必要 か見てみましょう ▪ GitHubで管理されていることが 多いので、GitやGitHubの操作方 法を習得しましょう コードリポジトリを探す 他人の修正提案を参照する Issueトラッカーを探す GitHubで作業する方法を学ぶ
16. Issue登録の流れ Issueトラッカー参照 ◦ 同じ内容のIssueが既にないかを確認 ◦ どのような内容を報告すればよいかを確認 Githubアカウント作成 ◦ コメントやIssue登録する際にGithubアカウントが必要 Issue登録 ◦ 既存のIssueにコメントを追記する ◦ フォーマットに沿って新規にIssueを登録する ◦ 必要な情報を詳しく分かりやすく説明する ◦ ラベルをつけてレビュアーをアサインする
17. Issueトラッカー(Kubernetesプロジェクト) ▪ バグ報告(kind/bugラベル)だけでなく、機能要望(kind/featureラベル)や使い方の 質問なども混在している ▪ 大規模なリポジトリでは、機能別 (SIG: Special Interest Groups)にラベルが設定さ れていたりする
18. バグ報告GitHub Issueの作成 ▪ 必要な情報を全部明記するとスムーズに 進められると思います！ ▪ バグ報告Issueに記載すべき内容： ・発生した現象 ・想定していた動作 ・再現手順 ・バージョン ・実行環境 ・開発環境など ・ログを張り付ける場合、隠すべき情報がな いかよく確認すること！認証情報、秘密情 報、IPアドレス、ホスト名など
19. コミュニケーションを難しく考えない ▪ 世界中の開発者が英語を流暢に 扱える人ばかりというわけでもない ▪ もちろん、流暢な英語であればコ ミュニケーションは捗るが、過分な心 配は不要 ▪ ソースコードの読み書きでも一部 の意図は読み取れる 英語はカタコトでも伝わればよいの だ、という認識で良い 行動規範にある通り「良き市民」ば かりなので、臆することはない ▪ 【例】CNCFの行動規範には「良き 市民となりましょう」と明記してある ▪ やってみよう、という姿勢が大事で す。不明点はプロジェクトの人々が 親切に教えてくれる
20. お礼、言葉だけでは不足しがちな感情を表す、 自分の返事として、他者の発言に対する同 意や反対、などを表すのに最適です！ コミュニケーションのコツ
21. チャットでの略語などはよく使われます。 •I’m facing the same issue. / 私も同じ問題を経験しています •ditto / (既に指摘した部分に続いて、) 同上です •WDYT (What do you think?) / どう思いますか？ •LGTM (Looks good to me) / 大丈夫だと思います。 •SGTM (Sounds good to me) / いいと思います。 いいね。 •SG (Sounds good) / いいと思います。 いいね。 •FYI (For your information) / 参考までに •IMHO (In my humble opinion) / つまらない意見ですが、私に言わせていただければ •TBH (To Be Honest) / 正直に言うと、はっきり言って コミュニケーションのコツ
22. ▪ Issue や PR を作ったら GitHub 上でレ ビュー依頼を出していますが、Slack で直接連 絡して依頼することもある ▪ 依頼方法： ・PR上の `/assign` コマンドを活用する ・Slack上のSIGのチャンネルで依頼する ・Slack上で by name で依頼する などが、確実にレビュアーを見つける コミュニケーションのコツ(Kubernetesプロジェクト)　
23. Kubernetes Upstream Trainingについて Kubernetesコミュニティ貢献をハンズオン形式で体験できるトレーニングです！ オンデマンドで自習も可能です！ 「コミュニティーメンバーは皆と ても親切な人で、英語が流暢 でなくても、遠慮せずになんで も言える」というメッセージを届 けたい
24. CREDITS: This presentation template was created by Slidesgo, and includes icons by Flaticon, and infographics & images by Freepik THANKS