昨今のプロジェクトは不確実性が高いものが多く、そのマネジメントも簡単ではありません。私たちソニックガーデンで取り組むプロジェクトにも、うまくいくものもあれば、あやしい雲行きになるものもあります。 成功するための要諦は見つけにくいですが、失敗しそうなプロジェクトには共通項があります。それは「イシュー」のマネジメントをしていないことです。イシューを適切に扱っていないプロジェクトの先行きは不安です。 本稿では、私が不確実性の高いプロジェクトに取り組む際に実践した方がよいことの一つと考えている「イシューのマネジメント」について紹介します。 イシューのないプロジェクトが失敗する理由 プロジェクトを進めていて、どうもうまく成果に繋がっていないとしたら、 やるべき仕事に注力できていないことが原因かもしれません。たとえば新規事業のような不確実性の高いプロジェクトでは、やることが膨大にあります。 そうしたと
要約：OSS開発プロジェクト運営者の側でとれる対策はいくつかあるよ。issueは基準を設けてどんどん閉じてしまおう。GitHubならActionsで自動化も簡単だよ。自動テストを整備するように、必要なコストだと思って割り切るといいよ。 結城です。 GitHub Actionsに関することならなんでもありらしいアドベントカレンダーとのことでしたので、ほんのちょっとかすっているだけではありますが、4日目にエントリーさせて頂きます。 「軽率に寄せられる報告や要望がOSS開発者を疲弊させる」という問題について語るOSS開発者は少なくないです。私の観測範囲内では最近も、イシュートラッカーにissueを立てようとすること自体に待ったをかける記事1や、「要望には初手で『なぜ自分で実装しない？』と訊ね、次に『継続的にメンテナンスしてくれるの？』と訊ねるドライな対応がおすすめ」という趣旨に受け取れる発言など
要約 OSS プロジェクトに issue を立てる事について。「最適化するな！」と同程度に「issueを立てるな！」を守りましょう。 導入 OSS プロジェクトに対して気軽に issue を立てられる事が良い事だと思ってる人が存外多いようで、その事に危機感を覚え、この記事を書き殴りました。 OSS プロジェクトに対して気軽に issue を立てられる事が良い事だとする認識は「地獄への道は善意で舗装されている」を地で行ってます、、、 見えてる景色の違い 世の中、無数に OSS プロジェクトが存在しますが、恐らく、、、 90% の OSS プロジェクトは作ってる本人以外誰にも見向きされてない。 9% の OSS プロジェクトは作ってる本人以外にも多少は興味を持たれている。 0.9% の OSS プロジェクトは普通に人気がある。 0.1% の OSS プロジェクトは大人気。 、、、細かい数字の精
GitHub Issueのコメントは書く時に戦々恐々とするものです。分量や記載する内容等、コメントというかwikiじゃないかと思えるほどに積もりゆく文章。とりあえず書いた内容がノイズにならないように心がけ始めたことを書いてみました。 GitHub Issueに作業進捗をコメントとしてこまめに書いていた時期がありました。気がつくと短期間で20コメントくらい付いており、内容を読み取るにも各コメントのコンテキスト理解が必要になり、結果大量のノイズと化していました。 フロー型のSNSのノリで書いていたことも原因だったと思います。最近は意識して体裁建てた結果、1コメントに1ページのWikiのようなノリになりつつあります。そんな書くにも悩ましいGitHub Issueのコメントについて、最近構えた個人的な方針を書いてみることにしました。 とりあえずHeaderでタイトルを書く Issueのタイトルをコ
Issueまで至らない要望やメモ書き等をGitHub上でどうやって管理するか悩みものでした。Projectの動作を一つ一つ確認してみて、現状のワークフローに合わせて極力管理の負担が増えずに実現する方法を模索してみました。 以前チーム内でタスク管理の精度を上げるためにIssueとPRについてルール付を行い、ガイドラインとしてのテキストも作成しました。 これで迷いはなくなったと思っていましたが、一つ難点が。予めルール付したIssueの定義を埋めることができない、つまりはやるべきことが確定していない「ふわっとした」状態の所謂「提案」や「願望」を置くことができません。 コントリビューター向けテキストに書いた「マイルストーン」での解決も試みましたが、このマイルストーンはIssueとして確定したもののみを含めることができる仕様でした。要は私の動作把握漏れ。代わりの手段は無いものかとGitHubリポジト
というのを作ったました。ちょこちょこ機能改善してます。 yuroyoro/git-issue · GitHub git-issue | RubyGems.org | your community gem host 仕事では、異臭管理システムはRedmineを使っていて、作業はsshでサーバに入ってコード書いてるわけです。 で、次どのチケットやろうか、とか今やってるチケットの細かい仕様どうだっけ？みたいなときに、 いちいちブラウザに切り替えて目的のチケットを検索するのタルすぎて死ねる。 もうターミナルから離れたくないんだ俺は。 そこで、'git issue 1000'ってやると1000番のチケットを見ることができるようにした。 $ git issue 15 [open] #15 Issueをadd/updateするときに引数で全部渡すのタルい ------------------------
ようやく仕事でもGitHubが利用出来るようになりつつあり、結構前に作っていた 拙作のgit-issue用のzsh補完関数が役に立つ日がきたのでご紹介。 glidenote/git-issue-zsh-completion git-issue : CLIでRedmine/Github-issuesのticketをbrows/editできるgitサブコマンド - ゆるよろ・オブ・ザ・( ;ﾟ皿ﾟ)ﾉｼΣ ﾌｨﾝｷﾞｨｨｰｰｯ!!! 日記 導入方法 当然ですが、git-issueが導入してある必要があります。 git cloneして$fpath配下に補完関数を配置。 mkdir ~/repos/ cd ~/repos/ git clone git://github.com/glidenote/git-issue-zsh-completion.git sudo cp git-issue-zsh-
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
