opera-wiki 2.0 構築計画(下書き)

(2008-12-04 追記)この計画は白紙撤回とします。今後の予定ですが、暫くは現状維持とだけ言っておきます。

下書きっていうか脳内にあるものをそのまま書いただけ。草案とかそんな段階でもありません。

目標

弥助がサーバー代だけ出しているような状況でも、健全な運営が可能なポリシーを作成する

日程

  • 11/3 計画・運営ポリシー(草案)の発表(ただしbtsの設置が問題なく出来た場合…)
  • 11/3〜11/14 計画・運営ポリシーを叩く
  • 11/14 確定 この日で運営ポリシーも完全な確定とする。これ以降は変更しない。
  • 11/15〜12/1 移行作業
  • 12/1〜12/10 予備
  • 12/10 pukiwikiサイトのリードオンリー化。oldへ移動させ、mediawikiを表に持ってくる。

運営ポリシー

初めに

現在のopera-wikiは正式版情報、WeeklyBuild情報、FAQ、カスタマイズ、質問箱の5大要素とその他に分類できる。これは長く運営されてきた中で自然に出来あがってきたものであり、今後も大きく変わることはないだろう。

ゆえにこのそれぞれに対し明確な作成ポリシーを制定する。

全体に関すること
  • 基本的にページ作成者がそのページの管理の任に付く。
    • ページ作成はユーザー登録者のみが可能とする
    • もちろん作成者以外もそのページを編集できる
正式版情報カテゴリ
  • Opera[VerNo]と作成する ex. Opera9.5
    • VerNoは9.5, 9.6, 9.7と小数点1位刻みとする
    • 「最新版」という名前で最新Verのページへエイリアスをかける
  • 初めてopera-wikiを訪れ、初めて導入するものでも、ここだけ読めば問題なく導入できるよう作成する
  • α、βに関してはこちらでは扱わず、WeeklyBuildで扱うこととする
  • 旧Verのページに関しては基本的に維持しない
    • 旧Verのページは維持されていない旨が書かれた案内をposition:fixedで表示する(出来る、よ、ね…)
  • ページ内容は「重要な案内」「ダウンロード・公式告知」「変更点」「バグ情報」「FAQ」
    • 「重要な案内」はインストール前に知っておかなければ重大な不利益が起きる可能性がある情報を書く
    • 「ダウンロード・公式告知」はその名のとおり
    • 「変更点」は前Verから比較し、特に良くなった、または悪くなった思われる項目を書く。ページ作成者の主観が入って良い(むしろ入れるほうが望ましい)。
    • 「バグ情報」はさらに「最新版でも発生」「修正済み」「前Verで発生していたが修正されたか未確認なもの」の3項目に分け、2chなどに書かれたバグを書く
      • 2chに書かれたバグは出来る限りレスのコピペにしておくことが望ましい(どこが重要な情報になるか判断が難しい為)
      • 「前Verで発生していたが修正されたか未確認なもの」に書かれたバグは有志や2chのレスで確認が取れた段階で「最新版でも発生」「修正済み」のどちらかに移動させる
        • このような方法を取るのは、作成者の手元で前Verでも起きていなかったバグを修正されたか判断するのは不可能である為。
        • 次Verページを作成する段階にあっても「前Verで発生していたが修正されたか未確認なもの」にリストされているバグは修正されたと判断し次Verに引きつがない。ex. Opera9.7というページを作成するときは、Opera9.6の「前Verで発生していたが修正されたか未確認なもの」は消去する（…うまく書けない)
    • 「FAQ」はこのVerで起きる問題、よくある質問を列挙する
      • 後述するがpukiwikiにおけるFAQカテゴリは廃止予定。ゆえに内容がかなり膨らむ可能性がある。
      • 前Verと記述や項目が被っても気にしない。維持に関しては常に最新Verの記述のみを修正する。
WeeklyBuildカテゴリ
  • WeeklyBuild[VerNo]と作成する ex. WeeklyBuild9.5
    • VerNoは9.5, 9.6, 9.7と小数点1位刻み
    • 「WeeklyBuild」という名前で最新Verのページへエイリアスをかける
  • 正式版ページへの下書きの役割も担う
  • α、βに関してもこちらで扱う
  • 旧Verのページに関しては基本的に維持しない。このポリシーも正式版ページと同等。
  • ページ内容は「重要な案内」「ダウンロード・公式告知」「変更点」「バグ情報」「FAQ」
    • 「重要な案内」「変更点」「バグ情報」「FAQ」は正式版情報と同等
    • 「ダウンロード・公式告知」はα、βのリリース情報を記述する
    • DesktopTeam発表のリリース情報はWeeklyBuild[日付]で、別ページを作成して記述する。バグが修正された場合はで、別ページを作成して記述する。
    • 「バグ情報」に書かれたバグが修正された場合はWeeklyBuild[日付]のページへリンクを付けつつ修正済みへ移動させる
カスタマイズカテゴリ
  • pukiwikiのFAQカスタマイズは独立したカテゴリとしてここで扱うことにする
  • カスタマイズをするときに知っていなければならない基本情報ページ(1ページ)と、具体的な方法が書かれたページ(具体的な方法ごとにページ作成)
    • 基本情報のページは常に最新正式版に準拠させる。WeeklyBuildでなにか特殊なことがある場合はWeeklyBuildページ内のFAQでフォローする
    • 具体的な方法が書かれたページは方法ごとにページを作成する
      • ページ作成者がそのページの管理人を名乗り、今後の維持を行う
      • テンプレートに「動かないボタン」を付加する。これを押すとbtsへ簡単に投稿出来るようにする。(技術的に可能であれば実施・btsでなくノートに書く形のが良いか？)
ドキュメントカテゴリ
  • wikiのオリジナルドキュメントカテゴリ
  • pukiwikiのFAQカテゴリ(カスタマイズ以外)はここへ統合する
  • ページは自由に作成して良い。ただし前述のとおり、ページ作成者を管理人と位置付け、維持の面倒を見なければならない。
    • 維持が続けられなくなった場合は「飽きた」テンプレートを貼る。ついでにbtsやノートで引き継ぎを募るのが望ましい
    • 維持されていないと判断出来るページは、誰でも「飽きた」テンプレートを付加することが出来る。同時に作成者への連絡を試みるのが望ましい。
bts.opera-wiki.com
  • 「質問箱」はここへ統合予定。(みんなの部屋もここ？)
  • ポリシーの変更を行いたい場合はbtsで提案し、議論する
  • 他、ネタの投稿も可としたい
トップページ

現在の形から大きく変更せず、弥助が管理する(つもり)。

狙いとか。

情報の散乱の対策

諸悪の根源はpukiwikiのFAQカテゴリにあるのは皆同意するところだと思う。考えた結果、僕は「FAQカテゴリが、実はFAQではない」ことが一番の問題だと結論づけた。

対策として、FAQからドキュメントへとカテゴリ名を変更する。こうやって名前を変えるだけで見る意識作る意識が変わるような気がするのだが、どうだろうか。

そしてドキュメントカテゴリは基本的にはページ作成者が維持することとする。これで「どこを維持しなければならないのかわからない」「どこから手をつけたらいいのかわからない」という問題も解消する。自分が作ったところを維持すればいい。

もし維持されてなさそうなページを見つけたら、とりあえずの修正をしながら「飽きた」テンプレを貼りつけ、ノートと作成者の個人ページに罵声を送りつけることでストレス解消。

そして正式版情報ページにのみFAQ欄を作成し、ここさえ読めば全ての情報が入手できるように作る。これで情報の散乱も解消されるはずだ。

FAQのある項目が巨大化した場合は、ドキュメントカテゴリにそこを分離したページを作成する。当然、分離したひとがこの先も維持をしていくことになる。(言い出しっぺの法則)

僕や編集人のモチベーション

僕の場合、結局、自分の居場所が消えてしまうのではないか、という不安が大きな要因だということに気付いた。ゆえにドキュメントカテゴリを作成者管理とすることで、自分のゾーンを確保できるようにした。ま、当然、その自分のゾーンは自分で維持する必要がある。

ユーザー登録することで貢献度もわかるので、編集人のモチベーションも維持できる、と、いいなぁ。

維持

基本的には「最新版」のページと「自分が作ったページ」を維持していけば良いことになる。維持しなければならない場所を捜し回ったりする必要がなくなり、精神的にも楽になる、と、思う。