Daisuke Miyamoto
dai.0****@gmail*****
2009年 8月 17日 (月) 17:44:49 JST
都元です。 進捗をまとめておきます。 > 1．ミッションステートメントの策定 別スレで意見募集中。 > 2. コミュニケーションインフラのあり方（外部に対する透明性等） MLをメインに移行で決定。 > 3. 定例ミーティング 月一で持ち回り幹事制で決定。 > 4. プロジェクトの切り方 > 5. 実装方針 これらも、書いてある通りで決定。 という感じですかね。 2009/08/10 15:05 に Daisuke Miyamoto<dai.0****@gmail*****> さんは書きました: > 都元です。 > > この週末にチャットで色々話をした結果、簡単な内容を以下にまとめます。 > まだ決定事項とはしませんので、ご意見募集します。 > > ====================================================================== > 1．ミッションステートメントの策定 > > 対外的のみならず、メンバー間の意識統一のために、Jiemamy Projectのミッションを明文化する必要があるかな。 > 現在、都元ブログ・はてなキーワード・プレゼン資料・地豆Webサイト等、各地に説明文があるが、統一されていない。 > また、その場その場で書いた文章なので、表記にブレやヌケがあるはず。これを整備したい。 > > http://producingoss.com/ja/getting-started.html#mission-statement > ↑この辺りをベースに考えようと思う。先日チャットで話し合ったのだが、途中までしか考えられなかった。 > 最初の一文はこんな感じ。 > > 「Jiemamy Projectは、データベースの進化的設計を実現します」 > > この後について、ここで色々話し合いながら、文章を完成させて行きたい。ご意見求む。 > > ====================================================================== > 2. コミュニケーションインフラのあり方（外部に対する透明性等） > > コミュニケーション手段に関しては、現状維持という意見もあるし、俺はちょっと調整した方がいいのかな、と考えてる。 > 現在はSkypeによってコミュニケーションをはかっているが、「話のテンポが良い」というメリットもあるのだが、 > 様々な問題点を感じている。 > > ・ログが残らない／追いづらい：オフラインの間のメッセージが飛んでくる順番もバラバラだし、まとまりがないので。 > ・閉鎖的：コミッタ外に開かれていない。一応オープンチャットで出入り自由だが、Skype v4からオープンチャットは廃止 > ・昼間onlineに出来ない人が入りにくい：チャットの会話はリアルタイムに流れていないと入りづらい > > 一方、コミュニケーションインフラをML中心に変えた場合、これらのデメリットが解消されるが、別のデメリットも > 現れる。「スピード感が失われる」「ブレスト的な作り方ができない」「チャットでは喋れるがML投稿は敷居が高く感じる」など。 > > 開発初期の段階は、それなりのスピード感が必要だったが、そろそろ腰を落ち着けて話すのもいいかと思っている。 > ブレストしながら作っていくシーンも減ってきたように感じるし。 > また、ML投稿の敷居が高くて発言できない、に関しては、ひとまずチャットも残すことで対処しようと思う。ただし、 > チャットでの議論は、文章にまとめてMLに再掲しなければ、基本的に内容を考慮されない可能性がある、ということにしたい。 > > 極論を言ってしまえば、MLに投稿できない人はオープンソース活動をするのは難しいのではないか、と。 > ということで、今後、議論の中心はMLに移行させたいと思う。ただし、初期議論の場／雑談の場としてSkypeは残す。 > > ということを考えています。ご意見求む。 > > ====================================================================== > 3. 定例ミーティング > > ■月１で最近地豆開発でハマったり悩んだりしてることない？お茶会 > > 月一定例って数ヶ月間やったんだけど、最近止まっちゃってる。 > 各自持ち回りでバトン方式で幹事やってくれたりすると助かる。前回の幹事が次回の幹事を調整する。 > > やっぱり、場所決めたり何なりって毎月やってると結構大変だし、色々「前回と違った趣向」を凝らして貰うことも出来る。 > 幹事の独断（例えば平日派とか休日派とか）が入ると、バラエティに富む。色んな人が参加できるようになるのではないか。 > > 場所案「リナカフェ」 > 暇な方リナカフェで地豆なうしない？くらい軽いのでもいいと思う > それで人が来るなら、その方式でやりたいがなーｗ 理想的な形だよねｗ ゆるい感じで。 > だが、合計3人程度は集まらないと、MTGの場としてなかなか維持が難しい気がする。 > > 場所案「ルノアール会議室」 > 結構本格的なイメージかな〜。一人1000円程度はかかっちゃうし。 > 是非プロジェクターを使いたい、という要件がある場合、特例で検討の価値が > あるもんだと思うが、定期的にルノ会議室はちょいとやりすぎな気がする。 > > 場所案「ファミレス」（ジョナサン、デニーズ等） > 規模的には最適。地理的に意外と難しいか？ と思いきや。意外と山手線駅から200m圏内くらいにあったりする。 > 有力候補。 > > 場所案「小川さんち」 > 小川さん曰く「ガンガン使ってくれていいんだけどねぇ。嫁も来客がある方が喜ぶ。場所的に集まりやすいか？は謎だけれども。」 > というわけで、幹事さんの判断によっては使わせていただくかもしれない。 > > ■1Qに一回くらいみんな集まってご飯食べようぜOFF（飲み） > > 3回に1回は、上記MTGの後に飲み会に流れることにする。その幹事も持ち回りで。 > > ■その他リリースパーティー > > まぁ、これは都度企画ですな。 > > ====================================================================== > 4. プロジェクトの切り方 > > zeus+artemis, 各importer/exporter, hestia等、大きな区切りごとに完全に依存を切って、お互いにSNAPSHOTに依存 > しないようにしたらどうか？ > > 例えば、hestia （Eclipse上のエディタ）に新機能を実装することになったとする。 > 新機能のために、coreに手を加える必要がある、という状態。 > 今までは、coreとhestiaを同時修正して、hestiaがcoreのSNAPSHOT（リリースされていないもの）に > 依存する状態にして、並行して修正をしていた。 > が、「必要な機能をまずcoreに実装してリリース」→「hestiaの修正」というステップを踏むように変更する > > これにより、hestiaリーダーがcoreリーダーに依頼して待つ、という形になる。 > hestiaな人は、coreの実装に関与する必要がない。必要な機能のインターフェイスを二者間で揉んでもらうところから始まるかな。 > > リリース頻度の増加によって、APIの互換性維持が難しくなるが、そこは努力。あとv1.0以前は完全に厳密でなくても > 良いかな、という判断のもとに動く。 > > ====================================================================== > 5. 実装方針 > > 実装したい機能が広がりすぎてしまっている。 > 各個興味の対象と出来る事等が異なるので、バラエティに富んでいたほうが興味のある所をたたけると思っていたが、 > マイルストーン毎に実装する機能を絞って、全員で一丸になって取り組んでいく方式のほうがいいかもしれない。 > > ====================================================================== > > その他、引き続き「オープンソースソフトウェアの育て方」を読んで感じた、現状の地豆の問題点があればご指摘ください。 > そして、現在まで出た上記５点について今週いっぱいくらい意見を募って叩いて行きたいと思ってます。 > 特になにもなければ、この方針で行きます。 > > 以上。 > > > 2009/07/31 1:48 に Daisuke Miyamoto<dai.0****@gmail*****> さんは書きました: >> 都元です。 >> >> Skypeチャットを覗いている方は感じていると思いますが、最近のJiemamyにはちょっと停滞感があると思います。 >> 原因はいくつか考えられると思うんですが、結論として、コミュニティ運営の考え方を見直そうと考えています。 >> >> http://d.hatena.ne.jp/daisuke-m/20090730/1248947975 >> >> 従来は、メンバーにタスクを「課す」ことはできない。誰かにやってもらえることは期待しちゃいけない、 >> という考えに偏って、完全にメンバーの自主性に頼って運営、言い換えると、ぶっちゃけ「放置」だった訳です。 >> >> そして、一人でプロジェクトを支える（決して、自分一人でプロジェクトを全部支えてきた、という主張をしたいのではなくｗ） >> ことに、限界を感じてきたため、色々考えなければいけない段階に来ているのかな、と思いました。 >> >> そんな中で、「オープンソースソフトウェアの育て方」という書籍を紹介してもらい、今日、その本を購入して、 >> 精読を始めたところです。そして、恐らくベストプラクティスであろうこの本の内容に注目しています。 >> >> この本が絶対か？と言えばそうではないと思いますが、今までの運営方法を踏まえつつ上手くカスタマイズするほど >> 運営に長けている人もいませんし、自分自身、書籍の理解も進んでいないです。 >> >> なので、、ここはひとまず、書籍の内容に馬鹿正直に従ってみようかな、ということを考えています。 >> >> >> というわけで、メンバー各自がこの文書を読んだ上で話し合い、運営方法を再考しようと思っています。 >> ただ、全員が「読んだ！」となるまでダラダラと待つわけにもいかないので、1週間という期限を切ります。 >> この期間内に読めるところまで精読するか、もしくは期間内に読み終わるように流すか、等は各自にお任せします。 >> >> 書籍を購入した方が深い理解が得られるとは思いますが、お金をかけたくない人は、Webに無料配布されている >> 文書ですので、こちらを読んでみてください。 http://producingoss.com/ja/ >> >> >> 従来通り、メンバーにタスクを「課す」ことはしませんが、「お願い」することにしました。 >> 1週間の期間内でこの文書を自分なりに読んで、その上で話し合いに参加して下さい。お願いします。 >> >> 話し合いは、Skype上で、来週末の金土日の期間で進めることになると思います。その場でリアルタイムに >> 議論に参加できない方も、ログを読んで頂いて、自分が発言できる時に意見を流してもらえれば、と思います。 >> >> 以上、よろしくお願いします。 >> >> >> -- >> email: dai.0****@gmail***** >> http://jiemamy.org/ >> > > > > -- > email: dai.0****@gmail***** > http://jiemamy.org/ > -- email: dai.0****@gmail***** http://jiemamy.org/
