oss2009_reviewed
の編集
https://floss-lab.org/pukiwiki/?oss2009_reviewed
[
トップ
] [
編集
|
差分
|
履歴
|
添付
|
リロード
] [
新規
|
一覧
|
検索
|
最終更新
|
ヘルプ
]
-- 雛形とするページ --
(no template pages)
[[みずきたん]]~ ｜＿[[CollabTech2009 & OSS2009>mizuki_OSS2008]]~ ｜＿[[査読結果 CollabTech2009>CollabTech2009_Reviewed]]~ ｜＿''査読結果 OSS2009''~ **査読結果 [#b5ae96d2] &color(red){''不採用''}; **査読結果を踏まえて今後 [#rc70bc59] -以下の目的で分析を進める --成功プロジェクトでは，どのようにオープネスが変化し，ソフトウェアの進化に関与しているかなどを明らかにするという切り口 +オープン性だと思われるメトリクスを分析する --オープン性のメトリクス ---パッチのアクセプト率（コア，ノンコア） ---パッチへのレビュ率（コア，ノンコア） ---コメントへの返信率（コア，ノンコア） --基本となっている概念 ---コア，ノンコアに関わらず開発者同士が関与するということがオープンである +何のオープネス性と人数の推移や貢献数に関係しているのかを見る +プロジェクト数を増やす -以下の結果になるだろうと仮定 --レビュ率やコメントへの返信率がノンコアの増減や貢献数に深く関わっている --アクセプト率は？？？ コアに比べ極端に低い時であっても，レビュ率などが高く，貢献数や，開発者の推移には関わらない -問題点 --バグ管理システムはどうするか？ ---今回の実験は，メーリングリスト対象でコアとノンコア開発者に絞ったが，バグ管理システムを入れると，アクティブユーザーをも対象とすることになる． --メーリングリストとバグ管理システムの扱い ---バグ管理システムでは，アクティブユーザー，コア，ノンコアが存在するが，アクティブユーザーとノンコアを，どのように分けるか？そもそも分けれるか？ **査読結果 [#r2199c6f] **内容まとめ [#b2c49b86] +ひとつのプロジェクトしか分析していないので，この論文では一般的なことを言えない +アブスト，インストの以下の部分が難解 --The condition of bazaar in a successful OSS community with a long history hanges over time in evolving to adapt itself and its products to the rapidly changing external environment +CVSとmailinglistで異なるID持ってるらしいが，どんな関係があるのか，もっと明確に書く必要あり．そしてどっちが深くコア開発者に関係してるのか？（4.3章） +「ノンコアとコアの貢献のアクセプタビリティ」と書いてあるが貢献がアクセプトされたかどうかは，この分析からでは分からない +他の人が，再現できるように，どのlistをつかったか書く必要あり +議論に深みを増すためにアパッチのバージョンも考慮する必要あり +議論が飛躍している +Apacheのバグ管理システムはジラーです **上記の番号に対応したコメント [#l08f3463] +複数のプロジェクトに対して，同様な実験を行う +アブスト，インストを修正 --成功プロジェクトでは，どのようにオープネスが変化し，ソフトウェアの進化に関与しているかなどという切り口 +IDの部分をもっと丁寧に書く．参考文献をうまく引用する必要あり． +レビュー率だけを調べていたが，実際にアクセプトされているかも調べる必要あり． +4.2章のデータソースでアパッチの開発者メーリングリストと記すだけで，明らかな字足らずでした --we chose the developer’s mailing list in the Apache community +確かにアパッチのverを考慮に入れる必要あり +議論をメルヘンにしすぎた +確かにApacheのバグ管理システムはジラーでしたが，Apache http serverはBugzillaでした **原文 [#v6834555] ----------- &color(red){''査読者１''}; ----------- The main contribution of the paper is the study of the Apache HTTP Server community from the point of view of how contributions of non-core developers are accepted, and how that is related to the growth of the non-core developers number, and to the number of non-core contributions. However, the analysis is performed only on one project, which is certainly not enough to draw general conclusions about how OSS projects in general behave. The wording of the hypothesis "The condition of bazaar in a successful OSS community with a long history changes over time in evolving to adapt itself and its products to the rapidly changing external environment" is hard to understand. And since it is in the abstract and introduction, may lead to difficuties in the appreciation of the value of the paper. (by the way, probably "in evolving" should be "is evolving"). In fact, probably there are other ways of stating the main hypothesis of the paper. From my point of view, it is more related to how "openess" evolve ober time in a succesful project. Page 2: "This implies thatbazaar-like software development might not be a critical success factor of OSS products and communities. If so, how could certain products and communities such as Linux and Apache achieve great success and survive in a free competitive market for more than a decade? Our study is motivated to answer this question." To me, it is not clear how the first sentence is related to the second. Probably more explanation about this should be included. Developers have diffrent ids in CVS (CVS ids) and in mailing lists (email addresses). The authors should clarify how they relate both, which is critical for deciding (according to their definition in subsection 4.3) who are core developers. The sentence "(3) the acceptability of contributions from core and non-core members (i.e., the rate of patches reviewed by other developers)." does not make it clear when a contribution is considered as accepted. When there is a reply to the message with the patch? (the next paragraph suggests this). When there is some positive acceptance of it? Something else? This should be clarified, since it is key to understand the results of the paper. In any case, it is not clear how replys to messages with patches show that those patches are accepted. The reply could say "I don't want this patch to be considered", for example. The lists consideres should be detailed. From the context, probably it is "httpd-devel", but that should be detailed, to facilitate reproduction of results by other parties. In fig. 2, the number of patches by non-core developers decreases after 2002. But the total number of patches decreases too. Therefore, maybe something happened around that date which cuased less number of patches sent to the project (maybe the release of the 2.0 version of Apache, which has a modular architecture?). This fact should be at least discussed, since could invalidate the support of the hypotesis. The section on discussion goes too far. Many of the comments there cannot be derived from the data presented in the paper. Those comments are probably out of scope in this paper. On the contrary, I would expect that this section consdiers the possible problems of the methodology, and the validity of the results. Apache is, as far as I know, using Jira, and not Bugzilla, since some time ago, for issue tracking. -------------- &color(red){''査読者２''}; -------------- If the authors had of limited their conclusions to the culture of openness in the Apache project I would have fewer issues with the paper, however I must take issue with the sweeping generalizations made on the basis of examining one atypical FLOSS project. Furthermore the hypotheses posed in section 3.2 are unremarkable and do little to support the hypothesis outlined in section 1 (and the stated aim of the paper). The work is not without merit but the paper requires a significant rewrite and the research needs to be framed appropriately.
タイムスタンプを変更しない
[[みずきたん]]~ ｜＿[[CollabTech2009 & OSS2009>mizuki_OSS2008]]~ ｜＿[[査読結果 CollabTech2009>CollabTech2009_Reviewed]]~ ｜＿''査読結果 OSS2009''~ **査読結果 [#b5ae96d2] &color(red){''不採用''}; **査読結果を踏まえて今後 [#rc70bc59] -以下の目的で分析を進める --成功プロジェクトでは，どのようにオープネスが変化し，ソフトウェアの進化に関与しているかなどを明らかにするという切り口 +オープン性だと思われるメトリクスを分析する --オープン性のメトリクス ---パッチのアクセプト率（コア，ノンコア） ---パッチへのレビュ率（コア，ノンコア） ---コメントへの返信率（コア，ノンコア） --基本となっている概念 ---コア，ノンコアに関わらず開発者同士が関与するということがオープンである +何のオープネス性と人数の推移や貢献数に関係しているのかを見る +プロジェクト数を増やす -以下の結果になるだろうと仮定 --レビュ率やコメントへの返信率がノンコアの増減や貢献数に深く関わっている --アクセプト率は？？？ コアに比べ極端に低い時であっても，レビュ率などが高く，貢献数や，開発者の推移には関わらない -問題点 --バグ管理システムはどうするか？ ---今回の実験は，メーリングリスト対象でコアとノンコア開発者に絞ったが，バグ管理システムを入れると，アクティブユーザーをも対象とすることになる． --メーリングリストとバグ管理システムの扱い ---バグ管理システムでは，アクティブユーザー，コア，ノンコアが存在するが，アクティブユーザーとノンコアを，どのように分けるか？そもそも分けれるか？ **査読結果 [#r2199c6f] **内容まとめ [#b2c49b86] +ひとつのプロジェクトしか分析していないので，この論文では一般的なことを言えない +アブスト，インストの以下の部分が難解 --The condition of bazaar in a successful OSS community with a long history hanges over time in evolving to adapt itself and its products to the rapidly changing external environment +CVSとmailinglistで異なるID持ってるらしいが，どんな関係があるのか，もっと明確に書く必要あり．そしてどっちが深くコア開発者に関係してるのか？（4.3章） +「ノンコアとコアの貢献のアクセプタビリティ」と書いてあるが貢献がアクセプトされたかどうかは，この分析からでは分からない +他の人が，再現できるように，どのlistをつかったか書く必要あり +議論に深みを増すためにアパッチのバージョンも考慮する必要あり +議論が飛躍している +Apacheのバグ管理システムはジラーです **上記の番号に対応したコメント [#l08f3463] +複数のプロジェクトに対して，同様な実験を行う +アブスト，インストを修正 --成功プロジェクトでは，どのようにオープネスが変化し，ソフトウェアの進化に関与しているかなどという切り口 +IDの部分をもっと丁寧に書く．参考文献をうまく引用する必要あり． +レビュー率だけを調べていたが，実際にアクセプトされているかも調べる必要あり． +4.2章のデータソースでアパッチの開発者メーリングリストと記すだけで，明らかな字足らずでした --we chose the developer’s mailing list in the Apache community +確かにアパッチのverを考慮に入れる必要あり +議論をメルヘンにしすぎた +確かにApacheのバグ管理システムはジラーでしたが，Apache http serverはBugzillaでした **原文 [#v6834555] ----------- &color(red){''査読者１''}; ----------- The main contribution of the paper is the study of the Apache HTTP Server community from the point of view of how contributions of non-core developers are accepted, and how that is related to the growth of the non-core developers number, and to the number of non-core contributions. However, the analysis is performed only on one project, which is certainly not enough to draw general conclusions about how OSS projects in general behave. The wording of the hypothesis "The condition of bazaar in a successful OSS community with a long history changes over time in evolving to adapt itself and its products to the rapidly changing external environment" is hard to understand. And since it is in the abstract and introduction, may lead to difficuties in the appreciation of the value of the paper. (by the way, probably "in evolving" should be "is evolving"). In fact, probably there are other ways of stating the main hypothesis of the paper. From my point of view, it is more related to how "openess" evolve ober time in a succesful project. Page 2: "This implies thatbazaar-like software development might not be a critical success factor of OSS products and communities. If so, how could certain products and communities such as Linux and Apache achieve great success and survive in a free competitive market for more than a decade? Our study is motivated to answer this question." To me, it is not clear how the first sentence is related to the second. Probably more explanation about this should be included. Developers have diffrent ids in CVS (CVS ids) and in mailing lists (email addresses). The authors should clarify how they relate both, which is critical for deciding (according to their definition in subsection 4.3) who are core developers. The sentence "(3) the acceptability of contributions from core and non-core members (i.e., the rate of patches reviewed by other developers)." does not make it clear when a contribution is considered as accepted. When there is a reply to the message with the patch? (the next paragraph suggests this). When there is some positive acceptance of it? Something else? This should be clarified, since it is key to understand the results of the paper. In any case, it is not clear how replys to messages with patches show that those patches are accepted. The reply could say "I don't want this patch to be considered", for example. The lists consideres should be detailed. From the context, probably it is "httpd-devel", but that should be detailed, to facilitate reproduction of results by other parties. In fig. 2, the number of patches by non-core developers decreases after 2002. But the total number of patches decreases too. Therefore, maybe something happened around that date which cuased less number of patches sent to the project (maybe the release of the 2.0 version of Apache, which has a modular architecture?). This fact should be at least discussed, since could invalidate the support of the hypotesis. The section on discussion goes too far. Many of the comments there cannot be derived from the data presented in the paper. Those comments are probably out of scope in this paper. On the contrary, I would expect that this section consdiers the possible problems of the methodology, and the validity of the results. Apache is, as far as I know, using Jira, and not Bugzilla, since some time ago, for issue tracking. -------------- &color(red){''査読者２''}; -------------- If the authors had of limited their conclusions to the culture of openness in the Apache project I would have fewer issues with the paper, however I must take issue with the sweeping generalizations made on the basis of examining one atypical FLOSS project. Furthermore the hypotheses posed in section 3.2 are unremarkable and do little to support the hypothesis outlined in section 1 (and the stated aim of the paper). The work is not without merit but the paper requires a significant rewrite and the research needs to be framed appropriately.
テキスト整形のルールを表示する
![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
