Wikipedia‐ノート:同じ記事への連続投稿を減らす
出典: フリー百科事典『ウィキペディア(Wikipedia)』
難しい問題です。
- プレビュー機能でも負荷が高いときにレスポンスが鈍るのは変わらない。
- ブラウザ上で編集する場合、こまめにでも投稿しておかないと、サーバーか投稿者のマシンに何かあった場合に修正した文章自体が消えてしまう。
- テキストエディタでは表示結果がわからない。
- エディタを使用しても、投稿者が完成された文章を最初から用意できる訳ではない。
wikipediaのシステム的に上記のような問題があると思われます。(管理者からしてみれば、投稿者のレベルの方が上げることを期待しがち、だとは思いますが)
あと、誘導も大事ですが、以下の考慮も必要です。
- IPで書いているからといって初心者とは限らない。(諸事情で名前を固定したくない場合もある。)
- 個性的な投稿者が多いと思われるので、管理者が無理に誘導しつづけると投稿者が嫌悪して減り、wikipedia自体成り立たなくなる恐れがある。
改良するとしたら、
- プレビューをしたときに?仮保存が効くようにする
- 短時間で連続投稿した場合の履歴は、最終のものだけ残す
などが考えられます。負荷が高い場合は投稿自体キャンセルされますので。
気になっていたのであえて意見を書きましたが、管理者にいらぬお世話と言われれば、それまでです。 (匿名)2005年3月13日 (日) 12:22 (UTC)
この項目に関連すると思われる重要な機能マイナーエディット、すなわち「これは細部の編集です」についての記述がありません。
「履歴」や「最近更新したページ」を閲覧する時に、 同じ人の些細な修正が連続すると、全体の見通しが悪くなり、 誰がいつどこを変えたかを見たい時に、手間取ります。 (常に要約フィールドに記入するも参照のこと)
とありますが、「最近更新されたページ」については、細分の編集フラグを付けたものは表示しないことができるので、「細部の編集」について述べておくことは有効だと思います。 「履歴」については「細部の編集」マスクが機能しません。履歴でも細部の編集マスクが機能するように実装すべきです。
ちなみに、昔Wikipediaで使われていたUseModWikiでも、「細部の編集」は「最近更新されたページ」には効きますが「履歴」には効きません。現在Wikipediaで使われているMediaWikiもこれをひきずっているだけかもしれない。 -HarpyHumming 2005年3月18日 (金) 13:50 (UTC)
目次 |
[編集] 理由にサーバーエラーの現象を追加しませんか?
ある会話で起こったことを見て思ったのですが、理由に「サーバーエラー時に投稿を繰り返すと履歴が複数残ると共に差分が時刻のみになる場合があります。そのため、プレビュー機能を使用して誤解(署名改ざんと受け取られる)を招かないようにする必要があります。」を追加してはどうでしょうか。時々時刻だけを変えられる方を見かけてなぜそういうことをしているのかと思っていたのですが、今回見かけた会話で疑問が解けました。この提案が反映されて、意図していない理由により連続投稿になってしまった方、連続投稿者を減らそうと尽力された方、の双方の誤解などが今後すこしでも無くなればと思います。いかがでしょうか。--Toto-tarou 2005年5月30日 (月) 16:44 (UTC)
- 取り下げておきます。--toto-tarou 2005年11月16日 (水) 18:22 (UTC)
[編集] 投稿のボタンサイズ
- 投稿ボタンのほうが大きく押しやすく、流れでつい押してしまうことが多々あるプレビューのボタンも同じ大きさか、大きくすれば連続投稿は少しでも減ると思うじぶんとしては。--Nnn 2005年12月25日 (日) 02:46 (UTC)
[編集] 節単位の編集について注意追加案
Suisuiさんから指摘を受けて、あんまり考えずに質問したら「自分で調べろよ」「指摘するなら分かりやすいポインタ示せよ」みたいな感じでもめてしまったんで、今後そういうことがないようにここに書いておいた方がいいと思うこと。
- 現在、記事は節単位で「編集」ができるようになっています。
- しかし、データは節単位ではなく1文書1レコードになっています。
- そのため、同一の記事を節単位でこまめに更新することは、システム上意味がないばかりか、履歴が増えることで逆に負荷を増やしてしまうことになります。
- なので、複数の節を更新する時は、文書全体をまとめて修正して投稿しましょう(一括投稿)
私は編集単位からみて、ページテーブルと、記事の内容テーブルが1:nになっていると思っていました。そう思っている人に「一括投稿を」と言っても「節単位投稿の方が効率がいいじゃない?」となってしまいます。まぁ、Wikipedia:節#各節の編集を読めば、なんとなくデータの構造が推測できるんですが、なかなかそこまで読み込まないと思うので。
興味のある人のために、上記に加え、実際に使われたDDLへのリンクもつけてあげればなおよしだと思います。 http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/maintenance/tables.sql (こいつぅさん、Suisuiさん情報ありがとう)
ご意見お願いします。 また、もし他のところに上記の注意書きがあるようでしたらおしえてください。 Fuji 3 2006年5月19日 (金) 09:50 (UTC)
[編集] frでの強制プレビュー
フランス語版では、IPユーザーについては、プレビューしないと投稿できないようになっているようです。どのような機能を使っているか知りませんが、連続投稿を減らすのに少しは役立つのではないでしょうか。--竹麦魚(ほうぼう) 2006年12月17日 (日) 23:56 (UTC)
- こんにちは、Tanadesukaと申します。最近更新したページを拝見致しますと、連続投稿されていらっしゃるのはやはりIPユーザーが多いようです。これは、IPユーザーのほうがアカウントユーザーよりも参加されてから日が浅いからと、参加日数が少ないユーザーのほうが当方針同じ記事への連続投稿を減らすをご存じないから、なのではないかと存じます。もし竹麦魚(ほうぼう)さんがご指摘の機能を日本語版でもオンにすれば、参加日数が少ないほうのユーザーに当方針を周知する事になるのではないかと存じますし、それは当方針をまたご存知でないほうのユーザーにより重点的に周知する事になるのではないかと存じますので、大変効果的なのではないかと存じます。--Tanadesuka 2006年12月18日 (月) 14:23 (UTC)
[編集] 記事の破壊の恐れがあるのでオフライン編集に関する記述の一時抹消を提案します
本解説で、「(ローカルの)テキストエディタを使って編集すること(オフライン編集と便宜上言います)の利点」を列挙されていますが、
- 競合編集が発生するはずのシチュエーションで警告なしに投稿できてしまい、他者の編集内容を上書き破壊してしまう
という大きな危険性があります。 これは、そもそもオフライン編集の手順そのものと、誤った手順で行った場合の危険性に関する注意が解説にないことに起因しています。オフライン編集の手順は、
- ブラウザで編集対象のページを開く
- [編集 (e)]をクリックし編集モードに入る
- TEXTAREA(wpTextbox1)にフォーカスを当て、全文選択しクリップボードにコピーする
- ローカルのテキストエディタを開く
- テキストエディタにクリップボードから記事本文をペーストする
- テキストエディタで適宜編集する
- テキストエディタの編集結果を全文選択しクリップボードにコピーする
- TEXTAREA(wpTextbox1)にフォーカスを当て、全文選択しクリップボードからペーストする
- プレビューしレンダリングを確認し適宜修正する
- [以上の記述を完全に理解した上で投稿する]をクリックし投稿を完了する
の様になろうと思います。(環境により細部は違うと思いますし表現が技術亭過ぎますが、いま重要なのは流れです)
問題なのは、2.から10.までの間、記事編集中のブラウザのウィンドウは閉じてはいけないということです(セッション管理による競合編集の検出が不可能にななってしまうのです)。もし閉じてしまうと、1.からやり直すことなり、その間に他の人が記事に変更を加えているかも知れず、このまま7.以降の手順を行うと、競合編集の警告なしに他人の記事への編集をキャンセルしてしまうことになります。
困ったことに現在の、「テキストエディタで編集すると、次のような利点があります。」の1.および2.は、やってはいけない「記事編集中のブラウザのウィンドウは閉じること」を前提としています。
以上から、オフライン編集手順の解説文書と危険性に関する注意が用意できるまで、本解説からオフライン編集に関する記述を一時的に抹消することを提案します。--Ef3 2006年12月18日 (月) 15:35 (UTC)
- (賛成)その後、「履歴を巻き戻せば上書きは買い前に戻せるではないか」と言う観点から提案の論理強度の検証を試みましたが、
- 上書き破壊に原因を作った者は気づかない
- 上書き破壊に気ずくのは破壊された編集を行った人である可能性が高い
- ∴不当な rv を科されたと理解してしまい上書き破壊を行ったものと(誤解に基づく)論争になる可能性がある
- ⇒上書き破壊後に編集が行われてから上書き破壊に気ずく可能性が高い
- ⇒単純にキャンセルすると上書き破壊をキャンセルする(ロールバックする)とその後の編集も巻き添えを食らう
- ∴上書き破壊後の編集と上書きに破壊された編集のマージコストを誰が負担するかが問題となる
- ⇒単純にキャンセルすると上書き破壊をキャンセルする(ロールバックする)とその後の編集も巻き添えを食らう
- 上書き破壊に気ずくのは破壊された編集を行った人である可能性が高い
- 上書き破壊に原因を作った者は気づかない
- と上書き編集事態は可逆でも、その後新しい編集が行われた場合の修正はロールバックで壊されてしまうので、上書き破壊を未然に防ぐこと(上書き破壊の恐れのある手順を行わないこと)には意味・意義があるという結論になります。以上は提案者による(賛成票)--Ef3 2006年12月20日 (水) 03:11 (UTC)
- (反対)上書き破壊の件はWikipedia:編集の競合で触れられていますね。広義の編集競合ということで、当ガイドラインでも考慮されてないわけではないと思います。一括投稿やエディタ使用の利点は確かにあるので、削除すべきではなく、現在あまり触れられていない”問題点”の方を加筆することで事足りると考えます。Fuji 3 2006年12月20日 (水) 04:23 (UTC)