faithcreates/hubot-fgb に review / reject を追加

faithcreates/hubot-fgb に次の 2 つのコマンドを追加した。

• @user review [<owner>/]<repo>#<issue>
• @user reject [<owner>/]<repo>#<issue>

Issue Tracking System を Backlog から GitHub に移している。

Repository ごとの Issue を使うようにしていたのだけど 2 つの問題があった。

• 運用が複雑になる
• Write 権限を渡さないといけない

前者は自分たちが面倒というだけではなく、新しく人が入ったときなどの説明が難しいなどの問題もある。複雑よりはシンプルな方が良い。

後者は push してしまったり、誤ってマージする危険性があったり、新しく人が入ったときの権限の制御が難しくなる。

そこで解決策として Issue のための Repository を用意することにした。

• Issue のための Repository は Write 権限を持つ
• Pull Request (Source Code) のための Repository は Read 権限を持つ

これによって以下のようなメリットが得られた。

• Issue をどのリポジトリにあるのか探さずに済む
• Issue をどのリポジトリに登録すべきか迷わずに済む
• Issue 以外は Read 権限にできる

代わりに Read のみになった Repository の Pull Request をレビュー依頼時に assignee を変えたり label を変えたりができなくなった。

そして、話は冒頭に戻る。

マージは以前からのコマンドがあるので、次のようなフローになる。

1. Issue を Issue 用 Repository に登録。
2. WIP Pull Request を Source Code 用 Repository に登録。
3. Pull Request を rebase & force push する。
4. Slack で @reviewer review repo#123 でレビュー依頼する。
5. レビュアーが Slack で @reviewee reject repo#123 でリジェクトまたは @hubot merge repo#123 でマージする

シンプル！これでしばらくは運用していく。

Splatoon 30 min/d

amiibo ガールのチャレンジの 4 行目 16, 17, 20, 4 BOSS タコツボファングをクリア。ミニゲームを手に入れた。

ガチマッチは 8 勝 15 敗。負けすぎ……。ブキを変えてみている。スプラシューター。慣れていないけど N-ZAP より明らかに強い。N-ZAP 4 確ならもっと移動速度を上げても良い気がする。

comic 1 episode/d

ヒストリエ (32) エウメネスはわざと背中を切られた状態で敵陣へ。池を渡れることを敵にわざと教える。

ナルト (373) 輪廻眼。