- ページ: BugTrack2
- 投稿者: 名無しさん
- 優先順位: 低
- 状態: 保留
- カテゴリー: その他
- 投稿日: 2010-04-27 (火) 22:40:15
- バージョン:
メッセージ†
BugTrack/588（案2: BugTrackあるいは開発日誌を別のシステムに分ける (保留)）の「そろそろBugTrackについてはSourceForgeのシステムを使ったり・・・」より
PukiWiki公式のBugTrackなどをSourceForge.JPのサービスで利用するかどうか。という議論があってもいいのでは？ということから
SourceForge.JPで利用できるサービス†
利用方法詳細：SF.JP-Help:FrontPage
- ニュース
- Wiki（ドキュメントの作成）
- 文書管理（リリースファイル以外のファイル管理）
- チケット（プロジェクト運用）
- フォーラム
- メーリングリスト
※ニュースとメーリングリストは現在（2010年4月）利用中
※チケット機能は、その前身であるトラッカーかタスクの機能が有効だったため、利用可能な状態（ただし、SF.JPへのログインが必要）
PukiWiki公式 to SourceForge.JP†
Official（org）とDevの特性を考慮する必用がありますが、概ねは以下のように別けられるのではないでしょうか？
- BugTrack、BugTrack2、欲しいプラグイン、自作プラグイン、自作スキンはSF.jpのチケットを利用する。
- 開発日誌、PukiWiki News、Web委員日誌はSF.jpのニュースを利用する。
- 開発談義、質問箱、雑談はSF.jpのフォーラムを利用する。
- 各種ドキュメントはSF.jpのWikiや文書管理を利用する。
Official（org）とDevの特性について†
コメント†
- ロードマップの維持負担の削減に繋がればよいですが、SourceForge.JPを使うことが負担にならないように進めていく必用があります。ただ、大前提として、SourceForge.JPの機能を利用することが出来るのか？という問題があります。今後SourceForge.JPを利用するためには何が条件になりますか？ -- 提案者
- メッセージの各種ドキュメントには、PukiWiki/1.4/Manual/Plugin 以下のページなどデフォルトのPukiWiki 書式*1 のヘルプ文章や、official のDownload やInstall やQ&A などの文章ページも全部入ってます？ -- 名無しさん１
- もしそうなら、PukiWiki公式 to SourceForge.JP を全部実行すると、デモサイト以外を維持する意味がほとんど無くなりますね・・・。（ナビ用に、SourceForge.JP の各該当ページへのリンクを置くだけになってしまう） -- 名無しさん１
- それ以前の問題として、BugTrack/588 の提案当時のようにサイトそのものが機能しない（表示できない）状況ならともかく、単純に移管するだけで本当に負担が減らせるのかという問題が・・・（開発に関してはそのままですし、SPAM がきた場合など管理権限が必要な場合は何らかの形でメンバーに出張って来て貰わないといけないので、現状とほとんど変わらない気が・・・） -- 名無しさん１
- 全部入っています。PukiWikiとSF.JPのWiki書式の違いももちろん考慮する必用があります。ただし｀PukiWiki公式 to SourceForge.JP｀は、｀SF.JPを利用するなら該当の機能が使える。｀という例ですので全部SF.JPにするという意味ではありません。
- 議論の結果として、全部SF.JPを利用ようになれば全部SF.JPになったといえますし、「デモサイト以外を維 ～略～ なってしまう） 」となってもいいでしょう。
- 負担が減らせるかと言う問題の以前に、SF.JPを利用することが出来るか？です。出来るなら利用するための条件の一つに「負担減」があるということです。そのほかの利用するための条件には何があるか？ということを、PukiWiki Developers Teamにご回答いただけないと、話が進まないということで・・・。 -- 提案者
- 条件って、結局はTeam にメリットがあるかどうかじゃないの？
（場合によっては過去データの移動が発生するなどというような）デメリットよりもメリットの方が大きい、と誰にでもわかる形で明示できない限り、現状維持になるだけでしょ。（例: Subversion 関連のまとめ） --
- この議論は意味あるものなんですか？どんなに良い意見であっても、どうせ、採用されないんだろうし。 --
- 「PukiWiki公式 to SourceForge.JP」でOfficial（org）とDevの特性についてわかりづらいと思いましたので追記。 -- 提案者
- Teamの回答が無いのであまり話は進めたくなかったのですが、1ヶ月以上放置ですので自分なりに進めてみます :) -- 提案者
- SF.JPの機能が使えるか使えないかのレベルの話であれば、既にチケット機能は有効になっているので使っています。ただ積極的に使っていない状況です。使えないと言うなら「他の機能と同様にチケット機能を無効にした方がいいのではないか」という話になります。今回の話題ではチケット等SF.JPの機能を積極的に使えればということです。
- SF.JPのチケット機能は、PukiWikiのチケット・SourceForge.JPのチケット ／ TicketAdmin・TicketUserをご覧いただいてもわかるとおり、プロジェクトが抱える問題等を一元的に扱い、それをチケットの種類・コンポーネント・マイルストーンで様々な分類をします。チケットの分類だけでなく、検索機能の充実した条件設定、RSS・モニタから個人が個別の話題を追跡できます。
- チケットを利用する理由は、trackerやbugtruck等で同じようなことが出来ますが、PukiWikiに比べチケット機能の方が格段に優れていると言う点です。利用者側の視点として、チケットの機能は、official/devのBugTrackや自作プラグイン等のページを全て一カ所で扱え、PukiWikiに欲しい機能について、実装されているなら「本体なのか、プラグイン・スキンなのか（それは本体の？自作？）」、未実装なら「要望として出ているのか、実装途中なのか、実装直前なのか」と言った検索、議論・開発に対して掛かる負担を大幅に軽減できるのでは？と考えています。また、PukiWiki開発者、プラグイン・スキン開発者にとっても、ファイル添付が出来る点で、自ら配布場所を用意する必用がない、配布場所の閉鎖等によるファイル消失、等の問題でもかなりの負担軽減されます。
- SF.JPの文章管理やWiki機能で利用することについて、チケットやフォーラム機能を利用する状態になっていれば、official/devで扱うコンテンツの大半がドキュメントになります。今回の話題では、そのドキュメントもSF.JPのWikiや文書管理機能で利用することも含んでいます。ですが、まずドキュメントの性質を考えないと、ご指摘の通り「デモサイト以外を維持する意味がほとんど無くなる」状況になってしまします。それを回避するために、｀Official（org）とDevの特性｀のWeb委員/歴史/2004でhenoheno氏が指摘による「非ユーザーを含む一般利用者」のグループと「管理者・デザイナーを含む開発者」のグループについてを考慮し、それぞれの特性に応じてドキュメントを整理します。
- 私の案は、玄関口であるofficialを「非ユーザーを含む一般利用者向けのコンテンツ」を中心にし、SF.JPの各機能を「管理者・デザイナーを含む開発者向けのコンテンツ」にするのが、henoheno氏の指摘したグループ別けに近い状態になり、それぞれの好みあった運営が出来ると考えています。質問箱等はこの場合で、｀非ユーザーを含む一般利用者｀の分をofficialにし、他の分についてはフォーラム機能へとするのが望ましい。
- 他に、このグループ分けの条件の下でドキュメントを別けると、「PukiWiki本体ドキュメントの作業場所としての用（BugTrack/762でpkgに当たる部分）」が残ってしまいます。この場合、SF.JPのWiki文法が異なることから運用するのは非効率となるため、別の方法を考慮する必用があります。この作業場所を別に作るか、CVS上で行うか、officialで行うか、・・・いろいろ*2ありますが、少し難しい案件です。
- グループ分け後、SF.JPに移行する各種ドキュメントについて、今までofficial/devで作成された各ページを「(1) 全て移行するのか」「(2) 全く移行しないのか」「(3) 部分的に移行するのか」という問題が出ます。これについて、単純に全てのページを移行するとなると、ページの内容や関連性等を保ちながら移行するのは多大な負担になることから、必要性に応じて各ページを移行するのが最も負担なく作業できます。
- 以下はチケット・フォーラムに移行する各ページも含め、大雑把な振り分けです。重複している内容はそれぞれのページに応じて対応するという意味です。
- 「(1) 全て移行する」｀SF.JPにあった方が良いとされるページ｀
→ 各種ドキュメント類（管理者や開発者向け）、その他重要なページ
- 「(2) 全く移行しない」｀SF.JPから関連としてのリンクする。または、全く何もしない。｀
→ 古い各種ドキュメント類（管理者や開発者向け）、BugTrackの各ページ、各質問箱、開発日記、Web委員日誌、WebTrack、各雑談、各ユーザーのページ、SPAM対策で凍結されたページ
- 「(3) 部分的に移行するのか」｀必要に応じて移行するページ。｀
→ BugTrackの各ページ、自作・欲しいプラグインやスキンの各ページ
- 移動しなかったページ・ドキュメントに対してはofficial:WebTrack/80（PukiWiki-Archive）の様に、更新のないページの保管場所にし閲覧出来るようにしておきます。ただ、新たにPukiWikiを設置するより、現行のofficial/devを過去のページ・ドキュメントとしての保管場所に切り替えて、新たにofficialを設置し棲み分けする。とした方がドキュメントの移動負担を最小限に抑えられます。
- 以上、主に利用者側の視点ですが、ここからは管理者側の視点で。
- 管理者にとってみても、チケット・フォーラム等の機能を利用することは、各機能の問題（SPAM/セキュリティ/システム等）への対処は機能提供側のSF.JPにお任せ出来るので、Teamの取り分けコミッタとWeb委員がPukiWiki公式を管理する負担軽減にも繋がるのではないかと考えています。
ここで言う負担は、
- 「(1) BugTrack・質問箱・雑談等の続ページ作成と更新に関する負担」、
- 「(2) 日々増え続けるofficial/devのページの管理負担」、
- 「(3) 新しいPukiWikiにバージョンアップする負担」、
- 「(4) 新しいPukiWikiにした時の各ページの互換性に関する問題」
等です。
- PukiWikiシステム上で運営し問題が起こり、それに対応するための問題の共有する点、日々の運営ノウハウを開発に反映出来る点などから見れば有意義ですが、利用者・開発者にとっては、問題が致命的であればあるほど、PukiWikiシステム上での運営は危険であり、危ない綱渡りではないかと思えます。PukiWikiシステムに問題があり、結果、利用者・開発者だけでなくSF.JPに迷惑を掛けることになる場合も考えれば、それに対応する負担も含め、安定的な運営かつ開発出来る環境を構築するには、SF.JPの各機能へシフトするのが最善ではないでしょうか？
- この点で、 `officialを「非ユーザーを含む一般利用者向けのコンテンツ」を中心にし、SF.JPの各機能を「管理者・デザイナーを含む開発者向けのコンテンツ」にする` という私の案は矛盾していますが、 ｀非ユーザーを含む一般利用者向けへの宣伝｀ 、 ｀管理者・開発者に対して安定的な場をSF.JPに作り、運営・開発への影響を少なくし、officialをPukiWikiシステムで運用することで「問題の共有する点、日々の運営ノウハウを開発に反映出来る点」｀を考慮すると、このような使い分けが最適ではないかと考えています。
- 以上、長いですが、大体のことは記載出来たと思います。SF.JPの機能を利用することで全ての負担がゼロになるわけではありませんが、かなりの点で負担軽減になると思います。 -- 提案者
- フィルタをすり抜けたスパムに対しては、削除等管理する必用があります。これはPukiWikiシステムを使っても、SF.JPの各機能でも管理上の負担は同じレベルだと考えています。この点、全ての負担がゼロになるわけではない理由です。
- 「チケット＃12477」等について、現状放置されているのは「チケットそのものを積極的に利用していないことから来るものか？」と言う疑問があります。このようなスパムを放置し、管理しないのであれば、チケット機能を無効にする必用があるのでは？ということになります。
- 日々増え続けるページの管理負担について、言葉足らずでしたが、容量の負担という意味もあります。｀SF.JPのWebスペースでの容量に対する問題｀です。チケット #8641: [pukiwiki] Webサーバーのgroup quotaについてで一応は対応して貰っていますが、このまま増え続ける状態を改善しなくても良いのか？と言う疑問もありました。今後、official/devの利便性向上のため、添付ファイルの解禁が出来たとしても、この容量問題が発生してするのでは？と考えています。
- 「チケットにファイルを添付するにはSourceForge.JPアカウントにログインしている必用がある」という点でログインする負担があると言うことですか？であるなら、SF.JPアカウントを作成すれば問題ないでしょう。添付ファイルの管理上の問題、添付した人の責任等も考えれば、それぐらいの負担はすべきですし、今後PukiWikiシステムで添付を行えるようになったとしても、そのような負担を求められるようになると思います。 -- 提案者
コメント: 自作プラグインの(分散管理を含む)維持管理について†
- アカウントを作成が必須なら、自作プラグインのデータをPukiWikiのプロジェクトに保管ではなく、各自が作成したプロジェクト領域を使うべきでは？（でないと、webスペースだけが一時的に減ったとしても、PukiWikiプロジェクトの他の領域がオーバーしかねない） -- 名無しさん１
- プロジェクト外での保管のする場合ですが、現在の添付ファイルが使えず個人サイトで配布している自作プラグインや自作スキンと同じ問題である、アカウントの削除でファイルや記録が消失してしまう問題を解決出来ないと思いますが、いかがでしょうか？チケットの利用した運営の方が記録についても添付ファイルについても良いと思うのですが。またチケットはWebスペースの様な容量制限がないのも良い点です。 -- 提案者
- いくら制限がないとはいえ、Mozilla Add-onsのような使い方をチケットでする事をSourceForge.jpが想定しているのかな・・・？プロジェクト本体ほどではないにしろ、ある程度のダウンロード数が予想されるのならファイルリリースシステムを使ってミラーしてもらうなどしないと、負荷が大きすぎると怒られるのでは？ -- 名無しさん１
コメント†
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
