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)

日本語版でもログインした上でのオプションで設定できたように感じます。これをIPユーザーに適用できるとかなり軽減されるのではないかと思います。--ちゃたま（会話|投稿記録） 2006年12月18日 (月) 14:27 (UTC)

機能が確認できましたので、MediaWiki:Monobook.jsを変更しました。とりあえず試験運用してみましょう。--竹麦魚（ほうぼう） 2006年12月20日 (水) 13:40 (UTC)

記事の破壊の恐れがあるのでオフライン編集に関する記述の一時抹消を提案します

本解説で、「（ローカルの）テキストエディタを使って編集すること（オフライン編集と便宜上言います）の利点」を列挙されていますが、

• 競合編集が発生するはずのシチュエーションで警告なしに投稿できてしまい、他者の編集内容を上書き破壊してしまう

という大きな危険性があります。 これは、そもそもオフライン編集の手順そのものと、誤った手順で行った場合の危険性に関する注意が解説にないことに起因しています。オフライン編集の手順は、

1. ブラウザで編集対象のページを開く
2. ［編集 (e)］をクリックし編集モードに入る
3. TEXTAREA（wpTextbox1）にフォーカスを当て、全文選択しクリップボードにコピーする
4. ローカルのテキストエディタを開く
5. テキストエディタにクリップボードから記事本文をペーストする
6. テキストエディタで適宜編集する
7. テキストエディタの編集結果を全文選択しクリップボードにコピーする
8. TEXTAREA（wpTextbox1）にフォーカスを当て、全文選択しクリップボードからペーストする
9. プレビューしレンダリングを確認し適宜修正する
10. ［以上の記述を完全に理解した上で投稿する］をクリックし投稿を完了する

の様になろうと思います。（環境により細部は違うと思いますし表現が技術亭過ぎますが、いま重要なのは流れです）
問題なのは、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)

まず、本解説（Wikipedia:同じ記事への連続投稿を減らす）ではそもそも、Wikipedia:編集の競合について触れられていませんね。上書き破壊は「編集の競合」であって競合編集ではありません（「編集競合」という　Wikipedia 独自の用語に新しい語義を加えるのは良くありません）この点、私に錯誤あり「編集の競合」と「競合編集」で警告の有無を区別していると思っていました。。当ガイドラインがWikipedia:同じ記事への連続投稿を減らすの事であるならば考慮されていません。考慮されていれば、

1. ウィキペディアのサーバの負荷が高すぎて書き込みが正常に行われないことがあります。このような場合ブラウザ上で作業しただけだと、せっかくの執筆・編集の結果が失われてしまいます。エディタで編集してローカルに保存しておけばそういう心配は要りません。
2. ネットワークから切り離した環境でも執筆が可能です。これは、移動時など常時接続ができない場合でも作業が続けられるということです。

の様な迂闊かつ危険な **利点** は示さないはずです。

また私は削除でなく「オフライン編集手順の解説文書と危険性に関する注意が用意できるまで、本解説からオフライン編集に関する記述を一時的に抹消することを」提案しています（抹消が HTML の <del> である旨を書くべきでした）。その意味で、Fuji 3さんの意見は私の主張を補強するものでこそあれ「（反対）」してはいません。Fuji 3だんと私はおそらく問題意識を共有していると思います。--Ef3 2006年12月20日 (水) 10:29 (UTC)

なんか、レアケースでそんな議論をしてもしかたないと思うのですが。そうしたケースは止めようがないし、履歴から巻戻せるのだから、特に不便はないと思うのですが。ブラウザを開いている間だけをどうしてそんなに特別視するのでしょう。--ゆきち 2006年12月20日 (水) 12:35 (UTC)

ブラウザを開いている間は、MediaWiki のセッション管理の下にあり、編集競合を検出し diff3 で自動的に編集統合が行われ、それが不可能な場合は「編集の競合」のページが表示され **上書き破壊は起こらない** のです。なのでこの（安全な）条件は特別視すべきなのです（⇒Wikipedia:編集の競合）。またレアケースですが、実際に発生するケースで、実際に私は不適切なオンライン編集手順で記事を上書き破壊された経験がありますし（⇒[1]）、レアケースゆえ、また警告が上書き破壊した時に出ないゆえ、履歴を巻き戻そうにも「上書き破壊した版に基づく編集」が加えられた後になりがちです。この事は rv では二次的な破壊が起こることを示しており、破壊された編集を行った人・破壊した人・破壊後新たな編集を加えた人の３者が関係した競合編集の解決協議が必要となりそれ終わるまで記事の編集は出来なくなります。この状況を「特に不便はない」とは考えられません（⇒Wikipedia:編集の競合#revert （元の版に戻す））。--Ef3 2006年12月20日 (水) 23:16 (UTC)

問題意識というか、問題があるという認識は共通していると思いますが、その解消のための手法として現在記載されている利点を一時的にせよ抹消すべきかどうかという認識が異なっているんだと思います。私は、オンラインで編集するかオフラインで編集するかはケースバイケースで各人の判断だと思ってますし、どう判断するかの判断材料は十分に提供すべきという認識です。上記例が”利点”であることは確かだと思っているので消す必要はないし、それに対する問題点（注意点）の記述が少ないのも確かだと思うので、加筆。利点を消してしまうのは、各人の判断材料をなくしてしまう上に、ガイドラインの意味もずれかねないために賛成できかねます。Fuji 3 2006年12月20日 (水) 14:23 (UTC)

「一時的にせよ抹消すべき」という方法論には、皆さんのご賛同を得られないことを認識しました。また、「本解説の不足を補い、問題点・回避方法・注意点などについて整備する事」、が最終的なあるべき姿であるという共通認識であることも判りました。いま、「オフライン編集（仮）」の手順を書くのがこの解説でよいのか思案中です。とりあえず、ここに書いて落ち着いたら分割するというのが落としどころでしょうか。--Ef3 2006年12月20日 (水) 23:16 (UTC)

利点と問題点の両論併記、実際の判断は個々の利用者に委ねる、というのが中立性の上でもよろしい対応ではないかと思われます。-- D.328 2006/12/20 19:12 (UTC)

この提案への、Template:SeeTalk を追加しました

遅ればせながら、本解説に{{SeeTalk|提案|記事の破壊の恐れがあるのでオフライン編集に関する記述の一時抹消}} を追加しました。この議論そのものが注意の呼びかけになると考えたからです。一部抹消より（目立つので）有効だと思います。
これをもって次の段階、本文に加えるべき

• オフライン編集手順の解説文書
• オフライン編集の危険性に関する注意

の議論（草稿作成に）移ろうと思うのですが、ご意見を聞かせてください。--Ef3 2006年12月20日 (水) 21:20 (UTC)

同じID or IPで連続投稿したらその最後の投稿のみサーバに残すようにすれば万事解決ぢゃないですか？ てゆーかサーバ増強すれば良いのか．みんな寄付してね♥--ネオ筑摩屋 松坊堂 2006年12月23日 (土) 13:08 (UTC)

連続投稿の履歴を消去する権限を管理者に与える

先日、管理者のCalveroさんに、連続投稿のご指摘を受け、恐縮致しましたので投稿します。おそらく、初めから意図して連続投稿をする人はまれだと思いますが、私のようにそそっかしい人間が”つい”犯してしまうミスだと思います。
そこで提案ですが、このようなミスで皆さんに迷惑をかけるのは不本意なので、管理者さんに、消去しても支障の無い範囲で（連続投稿で修正された内容が全て検証できるという前提で）連続投稿の履歴を消去する権限を与えるのはどうでしょうか？（管理者さんの負担を増やしそうな提案ですみません。また既にそのような権限が与えられているのでしたら、私の無知ですすみません。） --Kk8998982 2007年1月14日 (日) 10:50 (UTC)

現在特定版削除が実装されていないので（全削除・特定版復帰のみ）効率が非常に悪そうです。--たね 2007年2月11日 (日) 18:40 (UTC)

たねさんコメント有難うございます。私も、効率が悪いと思います。プログラミングに秀でた管理者さんが、自動的に利用者(投稿者本人)が自らの連続投稿履歴を削除するプログラムを開発していただけたら良いと思います。いけないと分かっていても"ついやってしまう"のが、この"連続投稿"だと思います(自分のミスが放置されて曝されるのが恥ずかしいほうなので)。将来ますます、全世界的にウィキペディアプロジェクトへの投稿が爆発的に増え続けると思いますので、このようなプログラムを開発するのは、サーバーの負担を減らす意味でも非常に有用だと思うのですが。遺憾ながら私はそのような能力が無いのでどうしても"他力本願"になってしまいますが。--Kk8998982 2007年2月11日 (日) 19:26 (UTC)

sysopから聞いていますが、特定版削除をしても、ログとしては保存されています（錯誤による復帰のため）。従って、削除するロジックそのものを改革しない限り、ここでいう連続投稿の改善にはなりません。--ゆきち 2007年2月11日 (日) 20:18 (UTC)

タブを戻します。
ゆきちさんコメント有難うございます。論点を整理したいと思います。
1.各利用者(IPユーザー)が活動を始める前にこの方針を読んで、そもそも"連続投稿"をしないよう注意すべきである。
2.どんなに気をつけていても"連続投稿"を無くすことはできないので、"連続投稿"をしてしまった後で、その弊害を無くすることを各利用者ができないか。
という考え方があると思います。先ず、記しますが上にも書いているとおり、私が"連続投稿をしてしまったこと"を自己弁護するためにこの提案をしているのでは無い積りです。ですから1.の考え方は当然存在するものとして認識しております。
しかし、仮に、私がウィキペヒアの執筆活動を停止(あるいは追放)しても、"連続投稿"を無くすことはできないと思います。なぜなら、"連続投稿"は"荒らし"と異なり、悪意が有ってしていることではないと思うからです。私の例で言えば、"キーボードを入力中に誤って"へんな"キーを叩いたために、大量の入力内容が消えてしまい、また一から入力をし直す"ということが頻繁に起こったために、つい"投稿"ボタンをこまめに押してしまった、というのが実態です。
プレビューボタンを押せばこの事態を防げる、という智恵は後から知りました。しかし、"余計なログを残してサーバーに負担をかけてしまった"という事実は解消されないために、せめてそういう機能を作れないかと思い上記"2."の観点から私はこの問題を提起した積りです。--Kk8998982 2007年2月11日 (日) 21:09 (UTC)

そこまで深く考えなくともよろしいかと存じます。確かに、連続投稿を根絶することは不可能でしょうし、同じ人の細かい編集が履歴にずらずらと並んでいると、非常に見づらいです。しかしながら、履歴を整理したとしても、データはサーバに保存されたままですので、ディスク容量の節約にはならないですし、逆に整頓作業することによってサーバに付加を与えてしまいます。また、特定版の削除は、他の管理者による確認が必要とされているほどデリケートな作業です。ので、あまり多用しない方が無難なのではないかと思います。以前、特定版の即時削除を可能にすべきではないかという意見が他所で出されましたが、止めておいたほうがよいということになったと記憶しております。なお、現在IPユーザーはプレビューが強制になっていますので、多少改善されているのではないかと思います。--Calvero 2007年2月12日 (月) 06:36 (UTC)

有難うございます。今後は気をつけたいと思います。--Kk8998982 2007年2月12日 (月) 06:49 (UTC)

要約欄入力中にうっかり仮名漢字変換OFFにしてると、Enterキー押下で意図しない投稿が実行されてしまう

要約蘭の記入中にうっかり仮名漢字変換OFF状態でEnterキー押し（or ON状態でのEnterキー2連打)をやらかしてしまい、不完全な要約は登録されるは、もう一回プレビューをと考えていた文章も記事として登録されるは、というのをときおりやらかしております。これを修正しようとすると必然的に履歴版が一枚増えてしまう事に。要約欄に入力する文字列だけはメモ帳か何かのエディタで別に作成して、要約欄へ貼り付けた方がいいのでしょうか？ちなみに仮名漢字変換の確定操作にEnterキーを使っております（Windows XP SP2+IME 2003）。多少キーボード（and キーボード切換器）にも不具合がありそうですが・・・ --Westwind 2007年3月15日 (木) 20:52 (UTC)

そこの修正をするくらいであれば、その旨をノートに書けばいいのではないでしょうか。翻訳や継承などを除いて、要約欄で求められることは、それほど多くないはずです。--ゆきち 2007年3月15日 (木) 21:52 (UTC)

利用者:Tietew/ユーザースクリプト集にTietewさんさんが書き下ろしたスタイルシートがあるのでそれを使う（自己責任）方法もあります。そうするとうっかり投稿が減るかもしれません。Wikipedia:ユーザースタイルシート--たね 2007年3月16日 (金) 01:22 (UTC)

要約欄の記述ミスのみである場合は、再修正は掛けず放置している場合が多いです。重要な内容が内容が要約欄に記入できていない場合は・・・ノートに専用の節を作って補正ですかね、やはり。（○○の日時の版に対する正誤表のような形で）。ついつい、修正内容をあれこれ要約欄に書き込んでしまう点も改善点かな？（＞自分自身）

要約入力中のうっかり投稿警告スクリプト‥css書いたこと無いからな～。うっかり変更でウィキペディア自体の表示を崩してしまっては元も子もなし。修行した後に導入可否を考えます。（情報ありがとうございました）--Westwind 2007年3月18日 (日) 07:10 (UTC)

応答の時期を逸していますが、バグだとしてBugzilaに申し入れましたが、対処しないとの結論に至り、その後日本語版内で技術に詳しい諸氏によって試行錯誤されましたが解決に至っておりません。詳細と顛末はWikipedia:井戸端/subj/要約欄でのEnterを投稿ではなくプレビューに変更できないかを見て下さい。--Namazu-tron 2009年1月22日 (木) 13:34 (UTC)

節ごとの編集と全体の編集のサーバ負荷

はじめまして、少し分からないことがあるので質問致します。

(A)

「節ごとの編集と全体の編集のサーバ負荷」はどの程度あるものなのでしょうか？ 前者の編集を繰り返して編集すると、サーバ負荷が取り返しがつかないほど増加してしまうのでしょうか？

どうもシステム関係のことがよく見えないので推測ですが、Wikiは編集履歴を残せることが特徴です。 しかしこれは全ての編集版を保存していることとは意味しないのではと推定しています。 プログラムの履歴管理システムと同様に、差分をデータベースに保存しているのではないでしょうか？

サーバ負荷とはCPUの負荷とHDDの負荷が考えられます。 CPU負荷について。前者は比較する文章の量が少ないため、短時間で比較は終了するが、後者は（記事にもよりますが）時には数百KBの文章を比較する負荷が発生します。したがい、こまめな節編集の方がむしろ得策に思えます。

HDDの負荷は「差分保存」が正しいとすれば、編集差異の文章が同じであれば、両者に大きな違いは無いはず。

(B)

もうひとつの疑問は、オフラインのテキストエディタを推奨していることです。 確かにネットワークの品質が悪くて、よく落ちる環境ではこの方法しかないかもしれません。 しかし大きなデメリットがあります。

wikipediaは多言語対応を謳い、内部的にはUNICODEを使用しているようです。 それに対してテキストエディタ側には、UNICODEを対応するものもありますが、対応しないものも少なからずあります。 UNICODE云々はシステム関係に詳しくない人にはよくわからない事項です。 UNICODE非対応のエディタで編集して投稿すれば、UNICODEによる多言語部分が文字化けとなります。 そしてUNICODE云々を知らない人には、なぜ文字化けとなったのか意味が分かりません。

(C)

最後にこのルールは日本語版特有なのでしょうか？ 英語版の相当するものを読もうとしましたが、Interlinkがありません。 英語版にもこのルールに相当するものがあるのでしょうか？

Mue aka 2007年4月22日 (日) 12:19 (UTC)

(A)についてですが、大方の予想と異なり、差分ではなく全体で版を管理しているようです。[2]を見ると分かります。なので、節ごとの編集でも無駄にHDD容量は食います。個人的にはたいした量ではないと思いますが、むやみにこまめな編集は避けた方がいいとは思います。CPU負荷についてはおそらくほとんど変わらないかと。

(B)について、ファイルを直接IMPORTしているわけでもないので、コピペした後、ちゃんとプレビューまで行えば問題ない（通常編集のリスクと変わらない）と思いますが、何か私の認識がずれていますか？

(C)要約欄を見る限りそうでしょう（そうでなければGFDL違反）。ルール自体は至極当たり前のことを書いていると思うので、英語版などにも追加した方がいいでしょう（私は英語でそのプロセスを完遂するほどの根気はないので、やる気はないですが）。　Fuji 3 2007年4月23日 (月) 02:09 (UTC)

(A)についてリンク先をみましたが、これでは真相はよくわかりませんね。本当に差分ではないのでしょうか？常識的なシステムエンジニアならば、そのようなHDD資源の枯渇を招きかねない実装は避けると思われますが？

(B)についてUNICODEによる多言語部分が文字化けとなります。分からなければ、ハングルとかアラビア文字とかでお試しください。

(C)について。私は英語版にルールが無いことが何か「くさい」と思えます。WIKIPEDIAのシステムを良く理解していない日本の誰かが自己流の考えてこのルールを書き下した可能性はないのでしょうか？

それでは今後ともよろしく。Mue aka 2007年4月28日 (土) 12:58 (UTC)

（A）Viewにテーブル定義があるので確認してください。文章はtextテーブルに入りますが、リビジョン毎にテキストを保存して、節や差分を判別するカラムはありません。削除されていますがwikipedia：節の過去版にそれを想像させる記述があります（なぜ消えているのか分かりません）。

常識的かどうかは、同じ感想を持つ人は多いと思います。ちなみに、私は差分であることを前提に節ごとの編集が常に望ましい（複数の節の変更を行う場合、節毎に分けて編集）と思っていました。にも関わらず、全文保存形式になっているのは、ライセンスの関係もあると思いますが、容量への負荷と文章構成の負荷を考慮した結果、前者の方が軽いと考えたからかとも思います。過去データは圧縮保存される上、HDDの追加は比較的容易ですが、差分から文章を構成する負荷はwikipediaのように大量のアクセスをさばかなければいけないシステムでは深刻なボトルネックになりかねない・・・てな推測です。

（B）wikipedia→テキストエディタの際の文字化けのことだったのでしょうか？すみません、読み間違えていました。気の利いたエディタなら保存する時に変換できない文字コードが含まれていることを教えてくれますし、多言語部分を編集しようと考えている人は、その辺りを分かっていると思うので問題は少ないと思います。ただ、一般記事の他言語リンクあたりは事故になりやすいでしょうね。まぁ、どちらにせよプレビューを間に入れれば、気付く話だとは思います。Fuji 3 2007年4月28日 (土) 23:25 (UTC)

（C）日本の誰かが自己流に考えたとしても内容が妥当であれば問題ないと思います。ただ、現状でも当ガイドラインにはいくつか問題がありそうに思えますので、修正は構わないと思います。Fuji 3 2007年4月28日 (土) 23:25 (UTC)

(A) 特定版削除などの機能を実装するのに、差分のみの保存では都合が悪いのではないでしょうか（現在の差分表示機能を見る限り 個人的には、分かち書きがされない日本語の文章で、差分の検出がどの程度の精度を達成できるのか疑問です）。

(B) 私の場合ですが、ハングルやアラビア文字で

Wikipedia（コピー）→エディタ（ペースト）→保存して閉じる→再度開く（コピー）→Wikipediaプレビュー（ペースト）

とやっても最後まで文字化けは起こりません。エディタがUnicodeに対応していて、ハングルやアラビア文字を含むフォントをお使いなら、問題は全く生じないと思われます。メモ帳 (WinXP) でさえ、ハングルなどを何も考えずに保存しようとすると 保存時にUnicode形式を選ぶよう警告を出してきます。-- D.328 2007/04/29 03:13 (UTC)

(A)特定版削除は可能なのでしたっけ？ある版以降が全て消されてしまうような記憶がありますが？

(B)それはあなたの使っているエディタが「たまたま」Unicodeに対応しているからですよ。それと、メモ帳もWindowsのバージョンによってUnicodeに対応しているか否かが分かれます。この辺も素人にはわかりずらいでしょうね。個人的な経験を元に、議論をすすめると間違った結論にたどり着きますので気をつけてください。Petz 2007年4月29日 (日) 04:05 (UTC)

(A) 特定版削除はないようですが、特定の版の復帰が存在します。記事を一旦すべて消してしまったあとに、残したい版を選択（版ごとにチェックボックスが出る）し復帰を行う機能です。見た目上、特定の版を削除したのと変わりません。

(B) 確かにそうでしょうね（だからこそ「私の場合ですが」とわざわざ断って書いたのですが……）。-- D.328 2007/04/29 08:11 (UTC)

なるほど、Wikipediaのシステムはいろいろと複雑なのですね。Petz 2007年4月29日 (日) 17:13 (UTC)

サーバーのパフォーマンスは気にするなと言われる

Mue akaさんの 2007年4月22日 (日) 12:19 (UTC)に関して：常識、常道としての差分記憶保存や英文版に何処かで示されるかは同じ考えです。一括編集や節ごと編集に関し、約1ケ月経過の新入り利用者ですが、一括にして欲しいとの指摘を受け、 Wikipedia‐ノート:ガイドブック 編集方針#サーバーに負荷をかけない編集方針または方法を参照して下さい。--60.238.161.115 2007年8月6日 (月) 12:41 (UTC) に書いた通り、疑問に思い、英文版で調べていたら、日本語の

Wikipedia:Don't worry about performance　（英文版も有り）に辿りつきました。

Wikipedia‐ノート:Don't worry about performanceに書き残しましたが

この『解説Wikipedia:同じ記事への連続投稿を減らす』に縷々書かれる事との整合性はあるのでしょうか疑問です。 （勿論連続投稿は投稿ごとの日時利用者等の記録を残し記憶容量を少なからず食い望ましく有りませんが、十分な推敲、事前準備、連続にて次の投稿を躊躇するなど個人の習慣や癖との複雑な関係にあると考えます。） 個人的には、当方利用者の中でも年配に属し、若い人の口語調記述の方が冗長多く、無駄と思われます。固い文語調や馬鹿丁寧、過剰丁寧と言わないまでも、本文ノート共端的記述を望みたい。美しい本来の日本語の書き言葉です。 （罪滅ぼしに相場300GB程度のHDD代金相当を寄付した。）--60.238.161.115 2007年8月6日 (月) 17:08 (UTC)

私も自分の連続投稿癖が治らないのと、それに対する罪悪感があります。上記の寄付はいいですね。私も行います。根本的な解決策にはなっていませんが、精神的にかなり楽になります。--背番号９ 2007年10月25日 (木) 09:11 (UTC)

英語版ってないんですか？

いま、このガイドラインに疑問があって、オリジナルを探しているのですが、英語版が見つかりません。 ご存知の方がいたら教えてください。--H335 2008年11月1日 (土) 05:48 (UTC)

ガイドライン本体の英語版はなさそうですが、en:Template:Uw-preview、Template:Previewなどと関連して作成されていると思います。ガイドラインのどのあたりに疑問をお持ちなのでしょうか。--Tiyoringo 2008年11月1日 (土) 06:49 (UTC)

回答ありがとうございます。我が家でもMediaWikiをインストールしたのですが、履歴データでデータ容量を圧迫したり、履歴表示でCPU時間を圧迫したりするように思えません。通常の記事のサイズならば、(加筆された量)+(削除された量)に対して、加筆積み重ねたことによる増分は、0.5%未満です。さらに、日本語版Wikipediaだけこのルールがあるならば、現在、日本語版ウィキペディアの全言語版に占める割合は4%未満ですから、システムへのインパクトは0.02%以下です。これは日々の記事の増分とくらべると、無視できるほど小さいといえます。また、CPU負荷についても、2004年当時と違い履歴を見る人が履歴を表示するコストよりもはるかに一般読者が記事を閲覧されるコストのほうが大きくなっています。

1. 保存される「過去の版」（「履歴」）の数が増え、サーバを容量的に圧迫する。
2. 「履歴」の利用時のちょっとした負荷になる。これは、システムの仕様上の理由もあるのですが、履歴がたくさんあると、表示が遅くなります。個々の記事において増えるデータ量はささいなものであっても、システム全体からすれば増えるデータ量は非常に大きなものになります。

これは根拠としてあげられるととても説得力がありますが、上記の理由で過大評価しすぎですし、上にいる60.238.161.115さまや背番号９さまのように、言われれば相当なプレッシャーを感じるものです。--H335 2008年11月1日 (土) 07:24 (UTC)

編集タブによる一括編集

と題する案内が無いので知らない新人もいると思われます 下記の文言の節を設けてはどうでしょう： [3]の様な例も有りますので。

タブ (GUI)#ウェブサイトにおけるタブに示されるように、編集しようとする記事の最上位置に左から、本文、ノート、編集、履歴などのタブがあります。この編集タブをクリックして記事全体の編集を一括して行えます。節ごとの編集とは違い、全体が現れますので編集する際には本文のどこに相当するか、十分な注意が必要で、プレビューを表示で慎重に確認してから、投稿します。（編集に慣れたらこれも使って下さい。）<-この（　）内は要検討。--Namazu-tron 2009年1月19日 (月) 07:06 (UTC)
編集タブを内部リンク化と修正。--Namazu-tron 2009年1月24日 (土) 09:15 (UTC)

考慮すべきガイドラインからはずすことについて

解決済み

「サーバーの負荷になる」という一切定量的な根拠のない理由で、非常に不思議なガイドラインの運用が行われて、そして定着してしまったようです。定量的な情報を集めた上で、勘違いであることが明らかになった時点で「考慮すべきガイドライン」からはずしましょう。その上でプレビュー機能の利点、上の節で言われている節編集以外の方法があることなど、「編集方法の手ほどき」を案内するページとして、使いやすいページへしていきましょう。定量的な情報の投稿をお待ちします。--was a bee 2009年1月21日 (水) 21:29 (UTC)

サーバーの負荷になり悪影響があるかどうかは連続投稿が続いた場合、ウォッチリストが少数の記事で一杯になったり、Wikipedia:削除依頼/他者による削除版書き戻しが疑われる中日ドラゴンズ所属のプロ野球選手記事のケースのように履歴チェック作業がはかどらなくなったりします。問題ある記述がされていたものを見逃し特定版削除によって多くの有用な加筆が失われることもあるでしょう。連続投稿がなるべく減るにこしたことはありませんので考慮すべきガイドラインから外すことには反対します。--Tiyoringo 2009年1月24日 (土) 18:31 (UTC)

Tiyoringoさんのご意見でひとつ疑問点があります。サーバーの負荷と履歴が汚くなることは直接関係ないことなのではないでしょうか?たしかに特定版削除の必要が出た場合に履歴の調査が大変だ、というのはよくわかりますが、技術面からはピントのずれた指摘ではないか、と思います。--Ziman-JAPAN 2009年1月24日 (土) 22:00 (UTC)

（反対）サーバー資源は有限です。有限である以上、最小で最大の効果を得られるよう努力するのは当然のことではありませんか？まず、「サーバー資源が有限でない」かつ「過去の履歴を破損無く保存できる」ような状況にならない限り、どのような編集でも「サーバーの負荷になる」のです。Wikiのシステムでは、変更された部分を保存しているのではなく、変更されていない部分を含めて全て保存しているはずです（特定版削除など削除された版も含めてです）。システムに詳しくないので、この程度しか知りませんが、それでもガイドラインから外すメリットを感じません。--Kodai99 2009年1月26日 (月) 11:34 (UTC)

資源の問題で人々を萎縮させるなというのは財団の方の考えです。それをあえて全員に気にさせる、というのであれば、それを正当化させるだけのデータが必要です。定量的な情報をお願いします。--was a bee 2009年1月26日 (月) 12:15 (UTC)

「Wikipedia:サーバの負荷を気にしすぎない」の英文版も生きており、一方またKodai99の言う有限資源でもあります。あくまで「気にしすぎない」であって全く気にしなくて良い訳ではなく、 連続投稿を減らす様に努める事が良い事となります。と言う程度で両論並記の文言で収めたいものです。個人的には定量的データもさる事ながら、荒しや、各種のガイドラインの不備などに起因する無駄とも思える議論や、Wikipedia:井戸端/subj/IPユーザーのいたずら防止策などを例とするなんらかの策がむしろ有効・必要と考えます。--Namazu-tron 2009年1月26日 (月) 12:53 (UTC)

定量的な情報を集めなければならないのは、むしろWas a beeさんの方ではないでしょうか。ガイドラインの廃止を提案するのであれば、その根拠を示すのは提案者として当然のことではないかと思います。しかしながらWas a beeさんは連続投稿とサーバーとの関係をご自身の言葉で説明できていませんし、Tiyoringoさんが指摘している連続投稿のもう一つの問題点「『履歴』や『最近更新したページ』の見通しが悪くなる」という点にも触れていません。両方を解決して初めて提案としての説得力が生じるものかと思います。さて私の意見として、「サーバの負荷を気にしすぎない」というガイドラインの草案の文面から考えれば、技術的な問題をあたかも「方針」という絶対的なものとして扱うことは好ましくないと思います。しかしガイドラインという、方針より緩やかなものとして自主的に守ることは、そう悪いことではなのでは、と思いました。そしてもう一つの、履歴や「最近更新したページ」の問題は、連続投稿を防いでもらう以外の解決策が考え付きません。履歴は以前Was a beeさんから「履歴圧縮機能」といった話を伺った覚えがありますが、「最近更新したページ」はどうにもならないと思います。以上のことを考えれば、ガイドラインから外すことには反対です。さらに言えば、「『編集方法の手ほどき』を案内するページ」にするならば、むしろガイドラインの方が良いと思います。現状のまま「使いやすいページ」に作り直していくことも可能なのではないでしょうか。--Bellcricket 2009年1月26日 (月) 13:30 (UTC)

毎回500回ずつ投稿するようなのは言語道断で、完全に無駄です。それは当然です。それは基本前提として共有します。あとご存知だと思いますが、最近更新したページもウォッチリストも拡張機能が利用できます。これもひとつの前提として共有します。ここまでは前置きです。以下、本題です。

ガイドラインとして維持することにむしろ私は賛成です。しかしその維持を可能とするには理由・目的を書き変える必要があります。

このページの問題は利用されている理由をちゃんと書けていない所です。人々が断続編集に苛立つ本当の理由は容量のせいでも何でもありません。このページの役割は別のものです。それは「新人は見られていることを知らない問題」です。言いかえればプライベートとパブリックの問題です。記事の編集はウォッチリストを通じて、数人から時に数十、数百の人々の目に止まります。そして投稿者がIPユーザーや新人である場合には、ベテランはその編集内容を逐一確認しにいきます（コピペしてないか、記事を破壊してないか、途中の版におかしな文章を紛れ込ませてないか等々が不安なため）。しかし新人は裏でそんな作業がなされてることを全く知りません。つまり編集は完全に自分一人のプライベートな作業だと思って気ままに編集を行います。そこから新人特有の断続的な超継続編集が生まれます。しかし実際には編集作業は多くの人に見られており（つまり半ばパブリックなものであり）、そしてベテランユーザーは新人の断続編集を細かくチェックする作業を行って居ます。いつか気づくだろう、と大体最初は我慢してますが、そのうち「相手が自分のチェックの気苦労を何一つ知らないこと」にある種の理不尽さを感じてくるようになります。そこでこのページが出てきます。つまり新人に本当に注目してもらうべきことは、データの容量の問題ではなく、「あなたの編集は多くの人に見られている」「多くの人に確認の義務を生じさせている」という素朴な事実だけです。ここらへんの理由をちゃんと直して、ガイドラインとして維持出来るなら、それが一番良い方向でしょう。－－was a bee 2009年1月26日 (月) 19:09 (UTC)

（賛成）「あなたの編集は多くの人に見られている」「多くの人に確認の義務を生じさせている」という素朴な事実だけですには目から鱗的項目です。ただ、この節は何をはずすかですが初心者も様々、編集知識と認識、自覚の問題であり、重要度からの取捨選択より、多面的網羅がいいと考えます。脚注、内部リンク、先々必要なら別の記事の分け{{main|ＸＸＸＸＸ}}で案内するなど駆使すれば良いでしょう。案内やべからず集ともなり、またいろんな人が対象ですから、冗長なく、一方漏らさず盛り込みたい。議論で丁々発止やるつもりは毛頭有りませんが。--Namazu-tron 2009年1月27日 (火) 02:13 (UTC)

（反対）Kodai99さんとほぼ同じ理由です。余計な版を重ねないよう心がけるのは当然かと思います。--Paperones 2009年2月20日 (金) 10:01 (UTC)

（コメント）かなりどうでもいいガイドラインだと思う。あってもなくてもいいというか。重要なのは記事の質をあげることで、サーバーの負荷を気にすることは二の次なのだから。基本的に記事の質を上げようとしている投稿だったら、投稿が連続何回あろうが、このガイドラインを盾にその投稿者に注意を行うなどの行為は厳につつしまないとだめだろう。--Afaz 2009年2月20日 (金) 18:27 (UTC)

（反対）システム管理者からのサーバー負荷を理由とした連続投稿を減らす求めがない限り、Wikipedia:サーバの負荷を気にしすぎないを理由として、サーバー負荷に関する説明の部分の削除には賛成致します（サーバー負荷を理由とした方針の作成はシステム管理者からの指示が条件では）。しかし、サーバー負荷以外にも連続投稿を減らすべき理由（履歴の見通しを良くするなど）は存在する為、「考慮すべきガイドライン」からの除外には反対致します。--４行ＤＡ 2009年2月21日 (土) 08:31 (UTC)

（反対）こういう提案をするからにはwas a beeはサーバーぐらいいくつでも買えるだけの寄付をしているだろうが、寄付もしない者には他人様（ウィキメディア財団）の資源を無駄に浪費しないように注意するのは当然。--220.213.78.124 2009年3月28日 (土) 15:21 (UTC)

まずとりあえず方針関係のページにIPや捨てアカで出てこないように。定量的な見積もりについては、以前の議論としてWikipedia:井戸端/subj/長大な記事（世界の一体化）についてで簡単な計算を行っています。また財団の予算規模についてこちらで簡単に解説しています。Wikipedia:井戸端/subj/ウィキペディア日本語版の会計情報。--was a bee 2009年3月28日 (土) 15:34 (UTC)

斜め読みしたがサーバー資源は無限だとは書いてないから無駄に浪費しないように注意するのは当然だと思うが「（何の方針に書いてあるのか知らんが）IPは出てくんな！」ということなのでこれで終わり。--220.213.78.124 2009年3月28日 (土) 16:01 (UTC)

（反対）何でもタダで運営できるわけではないのはご存知のことと思います。サーバが無尽蔵にあったとしても、その設置には土地代も電気代も回線料もそれに空調代、それらの面倒を見る人件費もかかっていますし、それは決して安い物ではありません。サーバの増強は常に行われいますし[4]、それらは個人や企業からの寄付でまかなわれています。日本語版だけを触っている限り、大きな問題は見えにくいですが、つい先日もヨーロッパのサーバは落ちて一部機能は死んでいますし[5]、Wikimedia財団は現在のフロリダとは別のデータセンターを探し始めたところです[6]。そこにまた別にお金が新たにかかるのは間違いありません。ウィキペディアを今使い続けられるのは、絶え間なくこういった努力が積み重ねられていることと、それに対して寄付をする人が居るからで、何の種もしかけもなく永遠に存続すると考えているのであれば大きな誤りです。今後存続し続けるように利用者が何らかのこと（具体的には寄付が最短ですが）をしなければ存続し続けるとは言いきれません。

これら全てのお金を全てあなた（達）が支払っているのであればこのルールに意味など無い、好き勝手にやらせてほしい、と発言しても問題ないと思いますが、そうでなければサーバを管理していらっしゃる方達に大変失礼です。その意味で上でIPの方が発言されていることは言葉遣いはともかく、大変的を得ていると思います。上で負荷について論じておられる方もいらっしゃいますが、これは負荷についての話ではありません。負荷はほとんど関係ないでしょう。Wikipedia:井戸端/subj/長大な記事（世界の一体化）についてで Was a bee さんはおかしな計算をされていますが、相当に見当違いなことをされていると思います。こういった24時間365日動作のサーバのHDDは街で売っているものでは信頼性が低くて実用には堪えませんし、多重化などの手段で信頼性を確保して安いものを使うにしても、HDDそのものを買うお金よりも、増えたHDDを設置するためのデータセンター内の土地代の方が通常はかなり高くつくからです。わかりやすく言えば、HDDの容量は買った時点で支払い終了ですが、HDDを設置し続けるための土地代、電気代は、たった数十平方センチ、たった数ミリアンペアと思われるかもしれませんが、それはウィキメディアがWebに存在する限り未来永劫永遠に支払い続ける必要があるのです。そこに過去版が存在するだけの理由で、誰も閲覧しなくても一分あたり何セント、全体では何ドルという単位で消費していきます。自分の時給として考えてみてください。HDDの大容量化で多少その増加速度が改善する見込みがあるとはいっても、一度保存したデータはどんなに圧縮してもゼロにはなりません。情報理論の通りです。なので根本的には保存する物を気をつけて減らす以外に今できる対策はありません。

版のいたずらな増加はデータベース保存に必要なHDDの増加とイコールです。それは今後ウィキメディア財団がウィキペディアを運営していくのに必要な日銭にそのまま跳ね返ります。それはそのままウィキペディアが存続し続ける日数の短縮も意味します。言い換えると、版のいたずらな増大は寄付金をドブに捨てることに等しい行為です。もちろん、サイトの目的である百科事典の充実に必要な版は増やしてしかるべきです。しかし自分が使いやすいからこうしたい、といった身勝手な解釈での物ならばそれは慎むべきと存じます。いろいろ言いましたが、かかってるお金はこれだけではないでしょうし、お金がどうこうではなく私はこういう理由でイヤだと明言しておきます。無駄な版を保存するのはmottainaiの精神に反します。保存する物がゼロでないかぎり、どんなに少なくともそれは消費をしています。気をつければ減らせる物なのですから減らしましょう。どんなに保存してもHDDを消費しないというデータを示していただければ考えを改めます。--Mage Whopper 2009年4月11日 (土) 07:54 (UTC)

（賛成）「考慮すべきガイドライン」から外すことに賛成し、またサーバ負荷に関する説明の削除に賛成いたします。

サーバ負荷について、H335殿が実際にMediaWikiをインストールし、連続投稿がデータ容量を圧迫したり、履歴表示でCPU時間を圧迫することはないというご報告が、このノートにてすでになされています。was a bee殿より定量的な見積もりの試算について紹介もされています。一方、「サーバを容量的に圧迫する」、「システム全体からすれば増えるデータ量は非常に大きなものになる」という説明の根拠が示されておりません。また、Mage Whopper殿の事例は連続投稿が原因なのか、説明がされておりません。Mage Whopper殿のご意見は、その説明があって初めて意味を成します。そもそも、資源は無限でないという説明は、連続投稿は問題であるという説明になっておりません。テキストデータより画像データの方が、はるかにデータ量が多いです。連続投稿が開発者の負担になっているとは思えないし、負担になっているという説明もいただいておりません。

また、「寄付をしない者は資源を浪費しないのは当然」というご意見にも反対です。逆に寄付をすれば資源を浪費しても良いということにはならないでしょう。寄付でウィキペディアの利用に差を付けるのは絶対にあってはならないことです。

また、Wikipedia:サーバの負荷を気にしすぎないには、「効率に関する方針を作らないで下さい」、「サイトの運用と維持は開発者の考えること」、「開発者からお知らせがあって始めて負荷を気にすればよい」とあります。Mage Whopper殿より説明していただいた事例も、サイトの運用と維持に相当します。サーバ負荷やサイトの運用と維持に自分なりに配慮するのは良いことだとは思いますが、連続投稿について開発者からお知らせがないかぎり、サーバ負荷を方針とするのは反対です。

そもそも、「考慮すべきガイドライン」とサーバ負荷に関する説明について、もっと重大な問題があります。「考慮すべきガイドライン」への移行にも、サーバ負荷に関する説明追記にも、ノートの合意形成が成されておりません。方針変更を提案する側に説明を要求するのは、きわめて問題であると考えざるを得ません。H335殿の嫌疑があった時点で方針変更を検討するべきだったのです。「考慮すべきガイドライン」から外し、サーバ負荷に関する説明も削除するべきです。その後で「履歴の見通し」など内容を精査し、「考慮すべきガイドライン」を目指すべきです。--伏儀 2009年4月20日 (月) 15:58 (UTC)

反対 Wikiとは一回保存するたびにそのページを丸ごと履歴に保存するシステムらしいので、連続投稿するとサーバの記録用資源を浪費するはず。一方、「サーバの負荷を気にしすぎない」でもあるので、努力目標で拘束力のないガイドラインになっている現状を維持すべき。--MadCat 2009年4月21日 (火) 05:53 (UTC)

コメント努力目標なら別にヘルプ文書でもいいんじゃないの？開発者が効率に関する方針を作らないでくれって言っているんだから素直にしたがってればいいんじゃないかね。サーバがサーバがと、とくに具体的数値もあげずにここで議論するほうがよっぽど資源を圧迫してると思うよ。:p --Afaz 2009年4月21日 (火) 08:46 (UTC)

賛成 日本以外の全言語のWikipediaにはWikipedia:サーバの負荷を気にしすぎないがあるだけです。「利用者である皆さんはウィキメディア・プロジェクトのサーバへの負荷を気にする必要はありません。」この通りです。我々の行動によってサーバーが遅くなったり、速くなったりすることは無い。開発者（最高技術責任者）がそう言っているのだからそれに従うべきです。連続投稿によって容量が圧迫される事が問題なら、もっと以前から技術的な制限が加わるはずです。あきらかに素人の仮定に基づいています。履歴がたくさんあると、表示が遅くなる？履歴は最新50までしか表示されません。謎です。殆どの記事の履歴が50以下だった頃に作成されたのでしょうか。これについても「履歴のせいでサーバーに負荷がかかっている」という間違った仮定に基づいている点が重要です。更に、この明らかに些細な問題によってユーザー間が衝突することもあります。勘違いによって他人にルールを強制し、衝突が起きる。完全に馬鹿げています。--6a4de67fe8b1988b3fe6f90375ab6a44038c5cfd 2009年5月5日 (火) 11:39 (UTC)

Wikipedia:サーバの負荷を気にしすぎないがあるのは日本語版以外に3言語のみ。他はなし。--hyolee2/H.L.LEE 2009年5月6日 (水) 02:16 (UTC)

左下に他の言語があるのだからその位解ります。要は日本版のみ存在する方針であると言いたいのです。--6a4de67fe8b1988b3fe6f90375ab6a44038c5cfd 2009年5月6日 (水) 04:15 (UTC)

（反対）ガイドラインから外すことには反対。ただしサーバの負荷に関しての記述を除去することは妨げません。もしガイドラインから外すのであれば、{{一括}}等、参照しているテンプレート等の改訂ないし廃止が必要です。--郁 2009年5月6日 (水) 02:35 (UTC)

（インデント戻し）「参照しているテンプレート等の改訂ないし廃止が必要」だから反対というのは本末転倒ではないでしょうか。あくまで「考慮すべきガイドライン」として適切かどうかを検討するべきではないですか？　仮に「考慮すべきガイドライン」を維持しても、テンプレートや他のガイドラインからサーバの負荷に関しての記述を除去する必要があるので、意味を成さないご意見ではないかと感じました。

「考慮すべきガイドライン」として適切かどうかについて意見を述べさせていただきます。「テキストエディタや文書作成ソフトでの編集」節と注意点の「特定の文字や記号などの処理に注意」節は、執筆の下書きについてであり、連続投稿とは関係ありません。「「要約欄が空欄の場合に警告する」設定を利用する 」節と注意点の「編集の競合に注意」節は、ウィキペディアに投稿する際に注意するべきことについてであり、連続投稿とは関係ありません。さらに、ウィキペディアのルールを説明する内容でなく、執筆のコツを指南したり、投稿の際に注意するべきことを説明しているので、ガイドラインでなくヘルプ文書とするべき内容でしょう。現在のWikipedia:同じ記事への連続投稿を減らすは、ガイドラインとヘルプ文書の役割分担ができておりません。

つまり、サーバ負荷の記述を除去した場合、ガイドラインとしての内容は、以下の「履歴の見やすさ」についてのみになります。

「履歴」や「最近更新したページ」を閲覧する時に、同じ人の些細な修正が連続すると、全体の見通しが悪くなり、誰がいつどこを変えたかを見たい時に、手間取ります。（常に要約欄に記入するも参照のこと）

これはテンプレートや他のガイドラインに直接記述すれば済むので、わざわざ１ページを用意して解説する必要はありません。それにこのページを参照していただくより、テンプレートや他のガイドラインを読むだけで済むように直接記述した方が便利でしょう。

以下の３つの対応を提案します。

• Wikipedia:同じ記事への連続投稿を減らすは「歴史的文書」として失効させる。
• 「履歴の見やすさ」についてはテンプレートや他のガイドラインに直接記述する。
• 執筆のコツを指南したり、投稿の際に注意するべき内容は新たにヘルプ文書を作成して解説する。--伏儀 2009年6月18日 (木) 10:44 (UTC)

執筆のコツを指南したり投稿の際に注意するべき内容は、新たにヘルプ文書を作成するよりWikipedia:記事を執筆するの「操作に注意しましょう」節に移動した方がよいですね。一方、「履歴の見やすさ」について、下にある「連続投稿はしない」節でも言及されています。やはりこのガイドラインは不要であると考えます。--伏儀 2009年6月21日 (日) 16:57 (UTC)

反対 最近Wikipedia:利用案内#English wikipediaにてヴァンダリズムとして拒否という事例がありました。en:User_talk:昔神童今心房細動によると連続投稿がテスト投稿と見なされたようです。この事例から見ると、本ガイドラインはそもそもWikipedia:荒らしに含まれることになるので日本語版以外ではことさらにルール化されていないのだと言えそうです。公式な方針であるWikipedia:荒らしがあれば不要とも言えなくはないですが、日本語版で要約欄に何も書かれていない連続投稿がしばしば見られる現状では特に本件について個別のガイドラインとしておく事が望ましいと考えます。--アルビレオ 2009年6月26日 (金) 21:25 (UTC)

質問よろしいでしょうか。そちらのコメントを拝見しましたが、英語版で荒らし扱いされた原因は漢字のユーザ名が文字化けしてでたらめな文字列になったほかに、履歴が未記入な連続投稿を行ったためでは、とあります。さらに、英語版では履歴を記入すべきと考えられているとあります。問題は連続投稿よりむしろ履歴の未記入にある、と私は理解しましたが、どうなのでしょう。

あと、Wikipedia:荒らしには連続投稿について一切触れられておりません。また、連続投稿を荒らしとする合意形成は存在しません。ノートでの合意形成なしにこのページが「考慮すべきガイドライン」へ移行された問題はすでに指摘済みです。ご確認下さい。質問のご回答お待ちしております。--伏儀 2009年6月27日 (土) 03:03 (UTC)

まず、利用案内での私のコメントは、User_talkを読む前に書いたものです。その時点では英語版のUser_talkを確認しておりませんでした。で、確かに「要約欄の未記入」も問題ですが、「要約欄に未記入な投稿が連続していたこと」が荒らしと判断された理由であり、「要約欄の未記入」と「連続投稿」がどちらか一方であれば必ずしも荒らしと判断されなかった、というのが現時点での私の判断です。

次に日本語版のWikipedia:荒らしに連続投稿が触れられていない、とのご指摘ですが、確かに明確に連続投稿を荒らしとする記述はありませんし、日本語版で連続投稿を荒らしとする合意は無いと認識しています。私としてもいきなり連続投稿を荒らしとみなすつもりは全くありません。

しかし、少なくとも英語版では「要約欄の未記入な投稿が連続していたこと」から荒らしと判断されることがあり、ことさら「サーバの負荷」についての無いからと言って連続投稿が全く問題ないと考えられているわけではないとも認識しています。

現時点で日本語版ウィキペディアに「要約欄の未記入な投稿の連続」がそれなりに観測されることから、本ガイドラインで注意を促すことは有益と考えます。

実際のところ、日本語版でほとんどの投稿に要約欄がきちんと記入されるようになれば、本ガイドラインが必要なくなるとは思っています。これでお答えになっているでしょうか。--アルビレオ 2009年6月27日 (土) 04:32 (UTC)

「履歴が見づらくなるので連続投稿しないようにしましょう」という条文は、今のところ反対意見もないので、「考慮すべきガイドライン」のままでよいと私も考えております。ただ、「サーバ負荷」を削除すると、「履歴が見づらくなる」の他には「エディタの利用」や「要約欄が空欄の場合に警告する機能」、「編集競合」といった連続投稿とは直接関係ない記述しか残らないので、同じく「考慮すべきガイドライン」であるWikipedia:記事を執筆するへの記事統合でよいというのが私の意見です。「履歴が見づらくなる」ことを警告する際にガイドラインを示す必要がありますが、Wikipedia:記事を執筆するの「連続投稿はしない」節を読むよう伝えれば済むので、このガイドラインがなくても特に問題はないと思います。もちろん、このガイドラインに記述されている「履歴が見づらくなる」についての補足を加筆する必要がありますが。--伏儀 2009年6月27日 (土) 05:01 (UTC)

記事のほうで「5000版問題」を加筆してみました（何で今まで書かれていなかったのか）。この問題を考えると、無駄な連続投稿は控えてもらうに越したことはなく、ゆえに「考慮すべきガイドライン」から外すことには賛成できません。特別:編集履歴の多いページはもう長いこと止まっているし、Wikipedia:編集回数の多いページの一覧も編集は半年に一度。某記事は700版/月を越えるという状況で、悠長なことを言っていると技術的な問題が発生してしまいます。--ラッキースター・キッド ◆Luck.w.AEQ 2009年8月4日 (火) 23:38 (UTC)

そろそろ結論を出しませんか。今までの議論を確認しましたところ、「考慮すべきガイドライン」を維持する意見が多いですが、「連続投稿を避けるべき理由」の2番はWikipedia:サーバの負荷を気にしすぎないに反しており、また説明が全くの虚偽ではないかという指摘がなされています。「5000版問題」の加筆は反対意見がないですね。とりあえず以下の３つを結論として、今回の議論を終了させるということでいかがでしょうか。

1. 「考慮すべきガイドライン」を維持する
2. 「連続投稿を避けるべき理由」の2番（サーバ負荷）を削除する
3. 「5000版問題」を加筆する

とりあえず１ヶ月待ってから対応させていただこうかと思います。よろしくお願いします。--伏儀 2009年9月5日 (土) 12:11 (UTC)

「連続投稿を避けるべき理由」の2番（サーバ負荷）を削除いたしました。あと、今気づいたのですが、「連続投稿を避けるべき理由」の1番からサーバー容量の記述を削除した場合、3番でも言及されている説明しか残らなくなるので不要ですね。「連続投稿によって容量が圧迫される事が問題なら、もっと以前から技術的な制限が加わるはずです。」というご指摘にも反論がないので、削除しておきます。--伏儀 2009年10月5日 (月) 15:56 (UTC)

削除し、対応が完了いたしました。この章の冒頭に「解決済み」のテンプレートを張っておきます。また、サーバー負荷を理由とした連続投稿の自粛に関する記述がテンプレートやほかのガイドラインにあるので、これも削除しておきます。--伏儀 2009年10月5日 (月) 16:02 (UTC)

Wikipedia:記事を執筆するとTemplate:一括より、サーバー負荷に関する記述を削除しました。また、議論終了に伴い、Wikipedia:ウィキプロジェクト プロジェクト関連文書の「現在進行中の議題」より、このガイドラインを外しました。これですべての対応が完了となります。不備があれば指摘していただければと思います。--伏儀 2009年10月5日 (月) 16:19 (UTC)

節単位の編集

ひとつの記事の異なる節に対し、節単位の編集を行った場合、即このガイドラインを適用するのは好ましくないなあ。という話です。

割と長い記事を全体で編集するのはリスクがあるし、難しい。どこを修正するかを探すのに手間取るし、何か違うところを消すんじゃないかという恐怖やリスクもあります。で、節単位の編集というのは便利で、直したいところだけ編集できる、プレビューできる。これはいい、といったところで直したいところが複数箇所あった場合に、3,4回の節単位編集を行う。そのときにこのガイドラインに基づいて、注意が行われる場合があります。これはこのガイドラインの理念とも少しずれている場合があると思います。プレビューの代わりに保存を繰り返して、ものすごい勢いでおなじ執筆者の履歴が増えていくこととは区別されるべきです。

まず、前提として、それらがすべて有用な加筆だということにします。プレビューをすれば防げるものや、荒らしなどではない、ちゃんとした編集です。

まず、履歴は増えます。版数が増えることに対しての懸念はおそらく、履歴がおいにくいことと、サーバ資源が増えるということをよく聞きます。履歴を負うことに関しては、むしろ要約欄に節名が自動挿入されるため、編集箇所がわかるという利点があります。サーバ資源については、あとで書きます。

大きな記事の複数箇所を編集する場合、外部エディタを使用すれば良いでは、ということについて、これは結構リスクがあって、テキストフィールドにコピペした際のミスで記事がこわれたり、文字が化けたりします。文字化けはかなり悲惨です。正直、ユニコードをまともに扱えないエディタを使うなら節単位で編集してくれと切実に思います。

ディスク容量についてです。上記のような節単位の編集に対して、注意を行った場合も保存領域を消費します。ここで私が仮定しているような編集に対してそれが行われた場合、その注意のほうがむしろ資源の無駄な気がします。節単位の編集が、注意深くおこなわれているように見えるものであれば、プレビューも使用されていると考えるべきで、それに対してプレビューを行えという注意は何の意味もありません。確かにスパム投稿や荒らしも多いですが、別の節を編集しているな、とか、どんな内容の編集を行っているか、などは少し見ればわかることと思います。

サーバの負荷の件ですが、Wikipedia:サーバの負荷を気にしすぎないにある通り、気にしすぎないことは大切です。荒らしなどは別として、正当な編集に対してサーバ負荷を理由としてその活動を抑止するのは技術者に対する侮辱であり冒瀆です。「負荷は気にせず編集してくれ、インフラを整備するのは俺たちの仕事だ」という彼らの矜持に対しては。少なくとも、DOSアタックを仕掛けたり、スパム投稿をするくらいには失礼な行為です。個人的に大きなデータセンタにいたことがあるからそう思うのかもしれないですが。

サーバ負荷についての余談ですが、Wikipedia:サーバの負荷を気にしすぎないのサーバ負荷とディスクの容量とはまた別だと思います。Wikipedia:サーバの負荷を気にしすぎないでは、「サーバ負荷」というか、サイト・パフォーマンスについて言及されていますが、ディスクの容量については言及されていないと思います。

このガイドラインは「あ、そういえば」について言及しています。そのためにいくつかの理由が示されています。しかし、その理由をもって、別々の節に対して節単位の編集を行うことをことさら忌避するのは、趣旨から外れるのではないかと考えます。長文になりましたが、ご意見をいただければ幸いです。--Mymelo^talk 2009年7月7日 (火) 16:57 (UTC)

私も節単位の編集は問題とされるべきではないと思っております。--伏儀 2009年9月5日 (土) 12:22 (UTC)