↓ メインコンテンツへスキップ

Oss に Contributeしよう! AWSにコントリビュートしてみた

· loading · loading ·
Aws Github
kiitosu
著者
kiitosu
画像処理やデバイスドライバ、データ基盤構築からWebバックエンドまで、多様な領域に携わってきました。地図解析や地図アプリケーションの仕組みにも経験があり、幅広い技術を活かした開発に取り組んでいます。休日は草野球とランニングを楽しんでいます。
目次

本記事は駆け出しエンジニア、OSSへのコントリビューションの経験が無い方向けに記載しています。

AWS関連のリポジトリにPRマージされるまでの全5ステップ
#

「OSS（オープンソースソフトウェア）へのコントリビュート」。この言葉を聞いて、あなたはどう感じますか？

「一部の凄腕エンジニアがやること」「英語がペラペラじゃないと無理」「ハードルが高すぎる」……そんなふうに思っていませんか？

実は私もそう思っていました。しかし、ある日届いたGitHubからのメールをきっかけに、「なんとなくかっこいいから」という単純な理由で挑戦してみることにしました。そして実際に手を動かしてみると、手順さえ踏めば誰でも貢献できるということがわかったのです。

この記事では、OSSコントリビュート未経験の方向けに、私が実際に体験した 「プロジェクト選びからプルリクエスト（PR）がマージされるまでの全工程」 を5つのステップで解説します。

おそらく皆さんに届いていると思うのですが、Githubから届いたメールは ✨ New to open source? You’re not alone. という件名です。 メールの内容は以下に翻訳しました。

Open Sourceへのコントリビュートのお誘い。githubからのメール

今日は実際にやった手続きを整理してご紹介します。

Step 1: 貢献するプロジェクトを見つける
#

最初のハードルは「何に貢献するか」です。いきなりLinuxカーネルのような超巨大プロジェクトに挑む必要はありません。

普段使っているツールこそが狙い目
#

一番のおすすめは、　「普段の仕事や個人開発で使っているツール・ライブラリ」　を選ぶことです。

私の場合は、業務で使用していた AWS Lambda Powertools を選びました。 普段使っているツールなら、「この機能が足りない」「ここの挙動がドキュメントと違う」といった**「自分ごとの課題」**が見つかりやすいからです。

AWS Lambda Powertools というのはLambdaの開発時に使えるライブラリです。以下などの機能があります。

  • logger
  • パラメータストアから値を取得する
  • XRay traceをワンタッチで設定する
  • 入力 event のvalidator
  • event データクラス

今回は event データクラス に新しい機能向けのデータクラスを追加する。というコントリビュートになります。

知らないツールのバグを探すよりも、自分が困っていることを解決する方が、モチベーションも維持できます。Good first issue（初心者向け）タグを探すのも良いですが、自分の「困った」を解決する方が、結果的にコミュニティへの最大の貢献になります。

コントリビュートの内容は機能に関与するコードである必要はありません。 ドキュメントの追加や、typoの修正でも立派なコントリビュートです。

Step 2: 郷に入っては郷に従え CONTRIBUTING.mdの攻略
#

プロジェクトが決まったら、すぐにコードを書き始める……のはNGです。まずはプロジェクトの「ルールブック」である CONTRIBUTING.md を読みましょう。

CONTRIBUTING.md が無いプロジェクトもありますが、その場合は README.md を読みます。それもない場合は、、、コントリビュートするのはやめておいたほうが良さそうです。せっかくPRを出しても放置されるのが想像に難くありません。

腰を据えてじっくり読もう
#

ファイルを開くと英語の長文で圧倒されるかもしれませんがここが最大の関門です。頑張って読みましょう。英語とは言え読むくらいなら誰でもできますよね？

今回は Lambda Powertools リポジトリへのPRを実施すべく、以下に CONTRIBUTING.md を読みました。

Lambda Powertoolsコントリビュートへの道：CONTRIBUTING.md読解編

まずは準備です。

  1. 既にその課題に取り組んでいることがいないことを確認する
    • オープンissue、クローズissueの両方を確認する
    • 最近のPull Requestを確認する
  2. リポジトリをforkする

その後以下の手順で作業をするように指示されます。

  1. コントリビュート対象の変更専用のブランチを作成してください
  2. make prで全てのテストとベースラインチェックをしてください Gitフックはlintingやformattingを行い、make prはCI processでも動作する詳細な確認を実施します。
  3. 明確なコミットメッセージを使ってコミットします
  4. conventional semantic titleでpull requestを送り、pull reqest作成時のデフォルトの質問に回答します。
  5. 自動化されたCIの失敗報告に注意をはらい、会話を続けてください。

作業手順は、当然かも知れませんがリポジトリによって様々なスタイルがあります。
ここをちゃんと読み込むことがマージへの最短ルートです。「急がば回れ」の精神でいきましょう。

以降は 実際の作業を紹介します。

Step 3: まずはIssueで会話しよう
#

いきなりPR（修正コード）を送るのではなく、まずは Issue（課題） を起票してメンテナーと会話を始めます。

Issueに取り組む優先権利を取りに行く
#

私が実際にLambda Powertoolsへコントリビュートした際は、以下のような流れでした。

  1. Issueを立てる: 「KinesisのTumbling window機能に対応するプロパティが足りていないようです」という内容を投稿しました。
  2. トリアージ（仕分け）: Botが反応し、その後メンテナーが確認してくれます。
  3. メンテナーからの返信: 数日後、メンテナーから 「Do you want to open a PR?（PRを出してみない？）」 という返信が来ました。

この「PR出してみない？」で「やります！」と手を挙げることで、重複作業を防ぎ、安心して実装に進むことができます。
実際には以下のような日程感で作業が進んでいきました。

  • 5月8日：issueを登録する
  • 5月12日：メンテナーから連絡が来る
  • 5月13日：コードを修正し、PRを出す
  • 5月14日：PRがマージされる

かなりスピーディーに対応してくれていると感じ、メンテナーの方々がコントリビューターを増やそうとしている意識がひしひしと伝わりました。

今回の変更点は慣れた人がやれば即座に終わるような内容でしたが、issueを上げた私に、やりたいか聞いてくれて、やりたいといえばアサインしてくれます。 我先に急いでPRを出さないとだめなのかと思ったのですが、一旦アサインされれば、担当者としてじっくり作業できます。

今回のように簡単な Issue でない場合は、修正方針について議論が交わされて設計が定まっていくと思います。設計が完了すれば後はやるだけですね。

Step 4: いざ実装＆PR作成
#

実装自体は皆さん日頃開発で実施されているものと何ら変わりはなく、何も難しくないです。

型を追加する変更だけでも立派な貢献
#

私が実際に行った変更は、以下のタンブリングウィンドウ機能向けの型情報を追加するものでした。これまでは Lambda Power Tools に型情報が無いために全開発者が個別に型定義を作っていたはずです。コントリビュートによって全世界の開発者に影響を与えられます！

Kinesis Data Analytics不要？Kinesis Data StreamsとDynamoDB Streamsから起動するLambdaでタンブリングウィンドウが利用可能になりました #reinvent | DevelopersIO

実際の機能的な変更点は以下です。型を足しただけです。

diff --git a/aws_lambda_powertools/utilities/data_classes/kinesis_stream_event.py b/aws_lambda_powertools/utilities/data_classes/kinesis_stream_event.py
index 6b189f937fd..dccb1931dce 100644
--- a/aws_lambda_powertools/utilities/data_classes/kinesis_stream_event.py
+++ b/aws_lambda_powertools/utilities/data_classes/kinesis_stream_event.py
@@ -100,6 +100,18 @@ def kinesis(self) -> KinesisStreamRecordPayload:
         return KinesisStreamRecordPayload(self["kinesis"])
 
 
+class KinesisStreamWindow(DictWrapper):
+    @property
+    def start(self) -> str:
+        """The time window started"""
+        return self["start"]
+
+    @property
+    def end(self) -> str:
+        """The time window will end"""
+        return self["end"]
+
+
 class KinesisStreamEvent(DictWrapper):
     """Kinesis stream event
 
@@ -113,6 +125,30 @@ def records(self) -> Iterator[KinesisStreamRecord]:
         for record in self["Records"]:
             yield KinesisStreamRecord(record)
 
+    @property
+    def window(self) -> KinesisStreamWindow:
+        return KinesisStreamWindow(self["window"])
+
+    @property
+    def state(self) -> dict:
+        return self["state"]
+
+    @property
+    def shard_id(self) -> str:
+        return self["shardId"]
+
+    @property
+    def event_source_arn(self) -> str:
+        return self["eventSourceARN"]
+
+    @property
+    def is_final_invoke_for_window(self) -> bool:
+        return self["isFinalInvokeForWindow"]
+
+    @property
+    def is_window_terminated_early(self) -> bool:
+        return self["isWindowTerminatedEarly"]
+
 
 def extract_cloudwatch_logs_from_event(event: KinesisStreamEvent) -> list[CloudWatchLogsDecodedData]:
     return [CloudWatchLogsDecodedData(record.kinesis.data_zlib_compressed_as_json()) for record in event.records]

これだけでいいの？と思うかもしれませんが、これで機能不足が解消されるなら立派な貢献です。

テストも忘れずに
#

コードを変更したら、それが正しく動くことを証明するテストコードも追加します。ローカルでテストを実行し、すべて通ることを確認したら、いよいよPRを作成します。

Step 5: レビュー対応とマージの瞬間
#

PRを出しても、すぐにマージされるわけではありません。メンテナーからのコードレビュー（フィードバック）があります。

メンテナーからの指摘
#

私のPRに対しても、メンテナーからリアルタイムでいくつかの指摘が入りました。

  • 「型アノテーションには | None もつけた方が安全だよ」
  • 「テスト用のJSONファイルは既存のものと分けた方がいいね」
  • 「ついでにDynamoDB Streamの方も対応しちゃわない？」

ここでもメンテナーの方はとても根気強く丁寧にレビューをしてくれたと記憶しています。自分たちで変更するなら一瞬のはずですが、ここでもコントリビューターを増やそうという思いが感じられます。指摘された箇所を修正し、再プッシュします。

そしてマージへ……
#

修正を確認してもらい、承認（Approve）されると、ついにPRがマージされます！

自分の書いたコードが本体に取り込まれ、世界中のユーザーに使われるようになる瞬間です。 GitHub上で**「Contributor」バッジ**が付与されたり、リリースノートに自分の名前が乗った時はとても嬉しかったです。

その他 OSS コントリビュート例
#

私は他にも以下などでOSSの世界に触れてみたことがあります。

  1. VSCode拡張にコントリビュート
    zenn-dev/zenn-vscode-extension: ブラウザ上の VSCode で Zenn をプレビューするための拡張 zennで記事を書くときにslug順になってしまうのが嫌だったのでタイトル順にするPRを出しました。IssueやPRに対して割とレスポンスが遅く、zenn関係はコントリビュートの第一歩としてはイマイチかも。

  2. 自作のVSCode拡張を公開
    png to jpg - Visual Studio Marketplace 画面キャプチャをペーストすると、PNGで保存されちゃいますよね。PNGはファイルサイズが大きくなりがちなので、まとめてJPGに変換するプラグインを作りました。vscodeプラグインは個人的なペインも思いつきやすいですし、簡単にリリースできるのでおすすめです。また自作のコードを大きくしていきたいときは CONTRIBUTING.md を必ず作成しましょう！

  3. Obsidianプラグインを公開
    日記を年ごとの横並びに表示させるプラグインです。5年日記のように横に前年の活動が見える感じのやつです。Obsidianのプラグインに登録されるにはObsidianのパッケージマネージャへの登録が必要になり、2本PRが必要になります。ちょっと面倒ですが、Obsidianを使っている人はチャンレジしてみては。 kiitosu/yearly-diary-comparator: show diary in diary note in comparable yearly comarable view

まとめ：あなたも最初の一歩を
#

OSSコントリビュートは、特別な才能が必要なものではありません。

  1. 使っているツールの「困った」を見つける
  2. ルール（CONTRIBUTING.md）を読む
  3. Issueで相談する
  4. コードとテストを書いてPRを出す
  5. レビューに対応してマージ！

この手順を一つずつ踏めば、誰でもコントリビューターになれます。 名高いソフトウェアの開発者の方々の世界に少しでも近づけるチャンスです！ まずは、ドキュメントの誤字修正からでも構いません。あなたも「憧れのOSSコントリビューター」への第一歩を踏み出してみましょう！

Reply by Email

関連記事

LocalStack Toolkitが永遠にStartingになる。Docker Eventsテンプレを直したら走りはじめた
· loading · loading
Aws Localstack Docker Github
Lambda Powertoolsコントリビュートへの道：プルリクエスト編
· loading · loading
Tech Aws Lambda-Powertools Github
Lambda Powertoolsコントリビュートへの道：issue提出編
· loading · loading
Tech Aws Lambda-Powertools Github