読者です 読者をやめる 読者になる 読者になる

kitak.blog

Kみたいなエンジニアになりたいブログ

会社でGHEのissueをつかった情報共有をはじめた

Diary

会社でGHEのissueをつかった情報共有をはじめました。

今、自分が所属している部署はフロントエンドエンジニアが20名くらいいて、やってくる企画に対して1~2名がアサインされています。 同じ部署の人がなにをやっているか知ったり、各人が知見を横に伝えるために週に一度、勉強会が開かれているのですが、
それとは別に、その都度、粒度の大小問わず、情報共有できる仕組みが欲しいな、と思っていました。

そこで、前職でおこなわれていた取り組みを真似して、GHEの所属している部署のorganizationの下に情報共有のためにissue専用のrepositoryをつくりました。 以下にあげるような内容を記事として投稿する(issueを開く)かんじです。

  • フレームワーク・ライブラリ・ツールの紹介
  • ブラウザのバグ
  • 社外の勉強会の参加レポート
  • アイディア
  • 「こんなのつくってみた」
  • 「これでハマった」

取り組みをはじめてから、さっそくいくつかの記事が投稿されています。 issueが開いたり、コメントがされたときにHipChatに通知がいくようにしたんですが、にぎやかでいいかんじです。

なんでGitHubのissue

なんでGitHubのissue機能なの?という話なのですが、以下の点を満たしていて、すぐに使いはじめることができるのがGitHubのissue機能だったというだけです。

  • 検索できる
  • markdownで書ける
  • 投稿を分類できる(ラベル)
  • 投稿にコメントできる
  • シンタックスハイライトできる

運用ルール

ふたつだけルールを設けました。

  • issueは原則オープンしたままにする。廃れてしまった知見(例えば、ブラウザの古いバージョンのバグなど)は適宜クローズする。
  • 同義のラベルの濫立を防ぐために、ラベルの名前はアルファベットのパスカルケースとする。ラベルの追加自体は各自が適宜おこなう。