決定総評などのページ凍結
spamや迷惑ユーザーのブロック
とりあえず少しずつでも議論を進めていきましょう。
決め事?に対するたたき台として、勝手ながらメリデメを列挙しました。
あとで評価軸ごとにマトリックスにしてみようと思いますが、
ひとまず、下記の内容についてご指摘があればお願いします。
iiiは有志の方が名乗り出て頂ければアリな選択肢ではありますが、
管理人さんに何かあった場合にサービス継続が困難になること、
管理人さんに負担が一極集中することから、
基本的には避けた方がいいと思います。
基本的には三つに分類できます。
@wiki、pukiwiki系、その他です。
@wikiは独自エンジン、pukiwiki系はpukiwiki/pukiwiki plus/pukiwiki advanceのいずれか、
その他は後述します。
@wikiは基本的には高機能であり、管理権限の分配や、管理者行方不明時のパスワード譲渡も出来ます。
また、トップシェアなのでサービスが突然終了したりしないという安心感もあります。
ただ、@wikiに移住する場合、データ移行はすべて手入力になると思われます。
記法にも細かい差異があるため、表示の調整に相応の期間と労力がかかります。
また、同社には情報漏えいを起こした過去があり、その際の対応が不透明であったため、
管理者・利用者に不安を与える可能性があります。
(※@chs,@pages,@wikiで立て続けにユーザ情報を流出させた。また、@wikiに関する釈明文でクラッキングの事実を認めなかったため、ユーザ離れを招いた。）
完全な主観ですが、当方は漏えいの被害を受けたため、全く信用していません。
ちなみに、@wikiは特定のメンバーに管理権限を分配できることが知られていますが、その内容は以下の通りです。
共同管理設定 (α版)
管理者以外のメンバーに部分的に管理者としての役割を設定をします
閲覧・編集権限変更･･･各ページの閲覧・編集権限の変更が行えます
編集モード変更･･･ページの編集モードを変更することが出来ます
ファイル削除･･･ページにアップロードされたファイルの削除が出来ます
注１：これらの権限をあたえたユーザは、自動的に全ページが閲覧・編集可能となります
注２：これらの設定は、設定を行い該当ユーザが再ログインしたあとに反映されます
(つまり、権限の剥奪もすぐには反映されません)
注３：コンテンツの管理責任は、あくまでもウィキをレンタルされたユーザ様(管理者様)にございますので、ご配慮の上ご利用ください
(権利者様からの権利侵害報告などがあった場合も、@wikiから連絡させていただくのは管理者様1名のみです。)
注４：「編集・閲覧権限変更」を付与するということは、「管理者のみ編集可能なページで利用できるプラグイン」の利用権限を付与するということと同じ意味となります。 危険性のあるタグなどの利用も可能となりますので十分ご注意ください。
これを読む限り「ページの削除と凍結ができるようになる」くらいであり、
アクセス規制などの分担はできません。
pukiwiki系のフリーサービスについては基本的には現状のwikiと変わらないはずです。
ただ、pukiwiki系のサービスであれば現wikiから抜き出したデータを丸ごと移植可能な可能性があります。
運営会社に相談しなければわかりませんが、データさえあれば技術的には全く難しくありません。
（ファイルの移植だけで済むため）
また、サーバ性能については現サーバよりもこちらの方が優れている可能性があります。
その他のサイトについてはケースバイケースです。
seesaa wiki、fc2 wikiについては独自エンジンで、後発のため高機能であると思われますが
利用事例が少ないため、情報を集める必要があります。
Wikipediaと同じエンジン（MediaWiki）を使っている「Wikia」というサイトもあります。
ただし、これらのサイトも@wiki同様、データ移行が手入力になる可能性があります。
他に、スレではGoogleSitesなどが挙がっておりました。
こちらも共同編集機能があるようですが、当方はまだ調査しておりません。
どなたか情報をお持ちの方はご提供お願いします。
基本的にはpukiwiki派生か、MediaWikiにすることになります。
まず、Pukiwiki派生の最大のメリットは
現wikiのコンテンツをそのまま移植できる点です。
Pukiwikiはディレクトリ構造が決まっており、ファイルのみで管理しているので、
前述の通り、ファイルの移植だけで済みます。
また、もう一つの利点はDBを使わずに済む点です。
最悪、フリーサーバでも運用できる可能性があります。
（サービスの継続性や、広告表示の観点からあまり勧めません）
もう一つ加えると、、PukiwikiのソースはPHPであり、
それほど複雑な処理をしていないので、ちょっとした改造であれば可能であると思われます。
たとえばの話ですが、凍結の処理に書かれているパスワード認証を
管理者パスワードでなく別の文字列（共用パスワード）にしてしまうことで、
atwiki程度の管理者権限の分担であれば対応可能であるかもしれません。
（上記については裏は取っていないので、来週中にソースコードを読んでみます。）
一方で、Pukiwiki派生のデメリットは、
全般的に更新が停滞しており、
脆弱性、PHPのバージョンアップによる動作不具合などの問題が
発生する可能性があることです。
今後、長期的に使うにはやや不安が残るソフトです。
MediaWikiはWikipediaのバックで動いているソフトであり、
更新も活発で、高機能です。
きちんと調べてはいませんが、おそらく管理者権限の分担もあるはずです。
また、データ移行については、
pukiwikiとの完全な互換性はありませんが、方言レベルの違いなので
サーバの機能を使えばある程度自動化することができます。
デメリットは、DBが必須であること、
動作の重さがわからないことです。
（Pukiwikiよりも重いかもしれないし、軽いかもしれない）
iのデメリットについてはかなりクリティカルであり、
覆すことは難しいと思います。
iiの有志の信任が得られなかった際のみ、検討すべきかと思います。
wikiだけの.tarで91.2MB、attachとbackup含めて127MB（含携帯ゲー）
据置のみに絞るとwikiだけ40.7MB、attachとbackup含めて50.1MB
| wikiのみ | attach、backupも含む | |
|---|---|---|
| 据置＋携帯 | 91.2MB | 127MB |
| 据置のみ | 40.7MB | 50.1MB |
