Wikipedia:井戸端/subj/節単位編集の多用

井戸端のタグ：節編集リンク [編集]

節単位の編集について

利用者‐会話:Ef3#一括投稿のお願いにおいてちょっと話し合いというか議論になっているので、皆様のお知恵を拝借したく思います。節単位の編集についてですが、節単位の連続編集は「一括投稿のお願い（Template:一括）」があるようにあまり好ましくないとされていたと思います。

今回、Ef3氏のノートに対して、このお願いをしたことが論議の始まりです。理由は[1]の記事についての連続投稿についてです。その際、連続投稿の利点をEf3氏は主張し、私は、ルールの観点から好ましくない、としているのですが、こういった、マークアップなどの方法で、Ef3氏は節単位のほうが利点が多いと主張していおり、確かに一理はあると思います（私個人としては同一人物の編集履歴が連なるのは余り良い気はしないのですが）。しかし、やはりそれは好ましくないから避けるべきと言うべきなのでしょうか（私はとりあえずはそういう旨の返答を返しましたが・・・）？それとも、こういった形の編集は許容し、むしろ歓迎すべきなのでしょうか？詳しくは利用者‐会話:Ef3#一括投稿のお願いを読んでいただくとして・・・皆様の意見をお願いします。--koon1600 2006年12月16日 (土) 12:23 (UTC)

当該会話ページの節にリンクを張り替え。×２ --Ef3 2006年12月16日 (土) 12:53 (UTC)

当該ノートをちらっと読んで思ったのですが、節単位の編集ができるのを見ると、やっぱりデータも節単位で持っていると思いがちな気がしますし、だとするとサーバ負担の軽減、編集箇所の明確化、作業の便宜等を考えて、節単位で編集した方がいいと考える方も多いのではないでしょうか？実際には節単位の編集でもデータは記事全体で持っているので、少なくともDB容量的には効率悪いことは確かですね。Fuji 3 2006年12月16日 (土) 15:28 (UTC)

大きな画像や長大なテンプレートが存在する記事で、次の節にそれらの一部がはみ出してしまう場合があります。そういったはみ出しによって、編集したい節やその後ろの節のレイアウトを崩してしまうことがあるので、バランスを見たりするためにも全体編集を使うようにしています。差分を見やすくするために履歴を分けた方がよいという考えがあるようですが、少なくとも私は、同一ユーザーによる編集が連続している場合、差分の閲覧も一度にまとめてしてしまいます（差分にしろ履歴にしろ、分けて読むのは面倒に感じるので）。

サーバーの負荷に関して。最終的に記事全体を編集するのであれば、分けて行おうとまとめて行おうと投稿時の負荷に大差は無いように思います（分けた場合記事に戻る回数が、まとめて編集した場合プレビュー回数が各々増えると思われる）。ただ、他の利用者による差分の閲覧回数が増えるとすれば、それは負荷の増大になるはずです。Wikipediaにおいては記事自体のサイズより、記事表示ごとに付随して読み込まれるファイル群の転送量の方が一般に多いらしいので^†、記事表示の回数が負荷によりよく対応するように思われます。

• †「付随して読み込まれるファイル群（合計100KB程度）」をすべてローカルコピーから読み出すようにしたところ、記事表示までの時間が（表示が特に重くない時間帯でさえ）数分の一にまで短縮されたので、これは確かかと思われます。-- D.328 2006/12/16 16:44 (UTC)

本題から少し外れますが、画像やテンプレートによるレイアウト崩れについては、画面解像度や使用しているスキンなどにも依存し、個々人で変わります。画面解像度だけを見ても、800×600の環境の人もいれば、1600×1200の環境の人もいます。自分の環境で適切と思われる表示でも、他の方の環境では見づらい、ということもあり得ますので、ガイドラインやスタイルマニュアルなどで規定・推奨されている書式やスタイル上の問題がない限り、あまり気にしても意味がないと思います。

さらに「同一ユーザーによる編集が連続している場合、差分の閲覧も一度に」というのは、記事の変更履歴からなら容易ですが、たとえばあるユーザ単位の「投稿記録」からは直接できないという欠点があります（“xxxx年mm月dd日 (曜) hh:mm (履歴) (差分) 記事名”の“(履歴)”リンクを押す場合は1編集分の差分しか見られない）。

なお、本題の「節単位編集か全体編集か」については、編集したい箇所が1節内のみなら節単位編集、そうでなければ全体編集（同一記事に対して節単位での連続編集はしない）が好ましいと思いますし、私自身はそうしています。節単位で編集を始め、途中で他節も編集が必要と思ったら、その編集内容をローカルのエディタにコピー&ペーストしてから改めて全体編集として始める（エディタにペーストした内容は全体編集の該当節部に貼り付けたりする）ようにしています。--220.145.16.100 2006年12月17日 (日) 02:29 (UTC)

細部の編集なのになぜ1回でやらないんだろう、と思いました。全体を編集して「マークアップを整頓」と書けば十分でしょうし、加筆箇所は「～に加筆」として、修正箇所は修正した節の名称を書き、必要ならば理由も付け加えれば、要約欄に全部入ると思います。一回編集してみて、また書きたいことが浮かんだので加筆した、というのであればそういうことはできませんけど。--草薙 2006年12月16日 (土) 17:05 (UTC)

私のマイ・トークが話題になっているようなので現れました。

まず、立場をはっきりさせておきます。「一括投稿を推奨する」あるいは「同じ記事への連続投稿は減らせる余地はないかと考えるべきだ」と言うご意見に、一般論として私は賛成です。ただし次のようなケース、

1. レンダリングの結果確認が必要なため、オフライン編集できない場合。
2. （節ごとでなく）ページ全体を編集して編集結果のレンダリングを確認すると、編集箇所を探すのが困難な場合。
3. （狭幅環境検証のため）使用端末が PDA でなるべく編集単位を小さくする必要がある場合。
4. 節への編集でないと履歴性を損なう場合。

は節単位の編集という方法がふさわしいと思います。4.は判りにくいですが、井戸端の履歴が良い例です。Wikipedia:井戸端では（形式的には）連続投稿が多く観られますが、これをとがめる人はいないと思います。対象になる節（井戸端の場合はarticle）を明確にするで範囲を限定できるからです。このように節単位の編集がふさわしい場合もあり、ふさわしいかふさわしくないかは、履歴表示中の編集時刻と編集ユーザ名の時間的な局在だけでは一意に判断できない（ので利用者:会話で指摘する場合は、精査と履歴による具体的な編集行為の指摘が必要）、というのが発言の趣旨です。

もちろん同じ節単位の編集でもより粗粒度（===より==）で編集できる場合は、粗い粒度で行うべきであるのは言うまでも有りません。この件については、どちらが良い・悪いという二元論的な議論は、主観的になりやすかったり接続環境に依存する面があるので、いつまで達ても平行線にしかなりません。なので、ガイドライン（Wikipedia:同じ記事への連続投稿を減らす）ならびに「一括投稿のお願い（Template:一括）」の有効性・有用性に疑問があると考えています。

プレビューを行うべきだという議論は、これにあたりません。むしろプレビューしないで投稿できる今のシステムに疑問を持っています。未プレビューの投稿は、どんなに軽微でも推奨できませんし、おそらく［以上の記述を完全に理解し同意した上で投稿する］にディフォルトでフォーカスが当っている事が理由の操作ミスでしょう。ディフォルトフォーカスは［プレビューを実行］に当っているべきです事実誤認でした、フォーカスが問題でなく、編集内容の要約のエンター時のアクションが投稿であるためでした、がこの挙動を変えるとユーザビリティが大きく変わったと感じる人がいるでしょうから、単純な挙動変更では新たな問題を作りそうです）。

（以下、蛇足）MediaWikiの実装は、節単位で編集してもページ単位（記事全体）で編集しても、競合編集についての挙動・データストレージの消費などにおいて差がない事を承知しています（ソースから；ただし編集内容の要約 に /* 節名 */ が自動的に入るのでドキュメンテーション支援という意味では微かに違う）。特に１文字書き換えるのも、全文字を書き換えるのもストレージ容量の消費という意味では差がない（フラグメンテーションの話ではありません、各版の内容は差分でなく全文が保存されている）ので、その意味では一括投稿の方が節毎投稿よりも、サーバに対する資源要求は有意に小さいです。しかし、この場合重要なのはどちらですか？サーバ資源削減の為に、ドキュメント性や、編集者へのユーザビリティを落とすべきでしょうか？もしサーバ資源削減が重要という立場を取るのであれば、（MediaWikiを改良して）コミットのたびに全文を保存するのではなく（rcs/cvs/svnの様に）直前の版との差分を保存すべきです。この改良を行えば、履歴から差分を得る場合のサーバ負荷が低減するという副作用的な利点も期待できます（そうすればより高度な|差分を最小にする|diff アルゴリズムを採用することが出来るかもしれません）。あえて言えば差分でなく全文を毎版保存しているのはMediaWikiの設計ミスです。また別の視点で履歴が同じユーザの編集により埋め尽くされるのが（一回に見渡せる履歴が少なくなるということで）可読性を落としていると考えるのであれば、同じ人間の連続した編集履歴を１行（ないし最初と最後の２行）にシュリンクして表示する機能を MediaWiki に実装するというのも有意義な取り組みかもしれません。また最近更新したページには「細部の編集を隠す」の機能がありますが、記事の履歴や、ウォッチリスト、投稿記録にはありません（なぜ？）。運用上の工夫も大事ですが、システムの提供できる（システムにしか提供できない）使用性の向上や機構の改善の余地は、まだまだ多いように思えます。（バグの報告・Bugzillaネタに相応しいかは思案中です）--Ef3 2006年12月18日 (月) 05:32 (UTC)

えっと、つまり、Ef3さんの論は極論的に言えば、「現状の設計仕様に問題があるのが悪い」ということでしょうか？これにはちょっと同意しかねます。なぜならば、ウィキペディア、メディアウィキは非営利目的で作られているものであり、12月18日現在、上に出ているように寄付金で成り立っています。つまり、私たちはボランティアで投稿しているのはもちろんでありますが、逆に運営している側もボランティアであるということを忘れてはなりません。つまり、ボランティアである以上、その活動を円滑に行うために存在するガイドラインを、守ると言うのはモラルの面で重要なのではないでしょうか？たしかにEf3さんが現状の仕様に不満なのはわかります。しかし、それはガイドラインを意図的に無視する理由には成り得ないはずです。

また、理由に挙げている4についても同意しかねます。私は逆に連続投稿が履歴の見易さ、利便性を損なっているように感じていますので（たしかにこれは個人的な観点でしょう。しかし、そうなればあなたの出しているドキュメント性や、編集者へのユーザビリティも個人によって感じ方は変わります。少なくとも私はマイナスの印象を感じています。井戸端の場合は、一括編集はプレビューなどの際に重すぎるというのが大きく、ドキュメント云々ではないのでは？）。2についても、三島大通り商店街のような記事は全体編集をおこなったとしても警告文すら出ない、大きさとしては中の下くらいの記事です。それほど困難とは思えません。

また、ウィキのサーバーは有限であり、さらに寄付で成り立っている以上、私も含めて1円も寄付していない人は可能な限り資源を活用するような編集を心がけるのは、大切な心がけであると思います（ただ、これは寄付を実際にしている人も同様です。負担を減らすことは決して悪いことではないので。さらに言えば寄付をしているとしてもルールを無視する理由には成り得ません）。また、現状Ef3さんの投稿を見ると、節単位の利点以上に連続投稿の問題点のほうが多いように感じます。

たしかに現状の仕様・設計は完璧ではなく、また、不完全な部分もあると思いますし、それを直そうという行動は歓迎されるべきであり、もちろん良い行動であると思います。しかし、だからといってルールを意図的に無視する（というか推奨されていない行動を行う）と言うのはちょっと問題があるのではないでしょうか？そういった行動を取るのは改正されてからでも遅くないはずです。--koon1600 2006年12月18日 (月) 11:30 (UTC)

ルールの無視は推奨していません

失礼ながらkoon1600さんに於かれては、根本的な誤解があるようです。2.について理解するには3.と併せて判断することが必要です。私の「会話」で「端末についての予断」と申したのは、「全員が常に中程度以上の解像度の PC を使っているのではない」という意味です。

ボランティア／寄付金の件、koon1600さんMediaWikiとWikiMediaを混同してませんか？

三島大通り商店街の件、最初の投稿から6回目の投稿まで、2時間以上の時間が経過しています（うち3分間に3回投稿しているのは最初の編集に錯誤を発見したことに伴う打消し（編集内容の要約参照））。また、その間に別の記事を編集しています[2]。加えて、私はこの間に居場所を移動しているのです。

「井戸端の場合は、一括編集はプレビューなどの際に重すぎるというのが大きく、ドキュメント云々ではないのでは？」と主張されていますが、その通り。{{一括}}を適用する前に、連続編集の対象となった記事のサイズを確認すべきです。これは、koon1600さんからではありませんが、（比較的大きな）静岡市の編集を節ごとに行ったことについても批判的ご意見を頂いています。このように「連続編集」と一律に履歴から判断するのは非常困難（不可能）です。少なくとも時間間隔・対象ページの大きさ・編集規模は考慮する必要はありそうです。この種の仕事には Bot が適しているのですが、そんな Bot を野に放したら・・それこそサーバの負荷になってしまいます。還言すれば、{{一括}}を適用すると言う行為（の前提の編集履歴と編集対象の調査行為）は、精密に行う必要があり・かつ・それを実際に行うとサーバの負荷になるということです。

私はこの件をルール論・マナー論で考えるべきでなく純粋に技術論で考えないと、合理的な判断は出来ないのではないかと思います。少なくとも結論の妥当性の検証には技術的な側面からの精査が必要です。「サーバのストレージの負荷になる」：合理性がありますか？少なくとも検証可能な有意な差がありますか？小さなページなら相対的にサーバへのストレージ負荷は当然小さいでしょう（×ｎオーダーです）。大きな記事の場合は大きいということが理由で、節ごとの編集が（合理的な範囲で）許容されます。とするのであればサーバ負荷はこの件の要因から消去できる筈です（この論点自身にも検証の必要はあります）。履歴の相対的なボリュームが増えるのは事実です。が、これが問題になる局面というのが「同じ記事の節だけ違う変更履歴が連続する」というのであれば、これはそれ自体で特異なことで履歴に現れる／目を引くべきです（実際、これはあなたの目を引いたわけですね）。基本的な私の立ち位置は「コミット粒度を細かくする利点」です。繰り返しますが（繰り返しますが）闇雲に細かくすれば良いといっていません。適切な粒度は非常に議論の多い問題ですが、ただ言えるのは「粒度が荒い方が良い」というのは適切さを欠いた意見だと思います。抽象的に言えば「世代管理・履歴管理を行なう動機、にかなう十分な細かさ」・「世代管理・履歴管理を行なう動機、にかなう十分な粗さ」が求められているわけです。世代管理・履歴管理を行なう動機は、将来、記事がどの様な変遷を経て何が残され何が捨てられ来たかを読み取り、また立ち戻れるようにすることだと私は思います（それゆえ先行投資的で効果の検証に困難が伴います）。あまりにも粒度が粗いと（一度に沢山の新しい特徴が記事に加わり、また削除されると）その意図を理解するのがひどく困難になるのを私は心配しています。

ということで単に節毎編集の欠点への反論と、節毎編集が不要であるとされる論法についての反論をしているだけで無批判に節毎編集が推奨しているわけではなく、サブセクション毎の編集をする前に、より大きなセクションを単位に編集できるか都度考慮すべきだと思い実践しています。改めて「現状の設計仕様に問題があるのが悪い」というのが私の論点だということを強く（強く）否定させていただきます。もちろん、ルールの無視は推奨していません。--Ef3 2006年12月18日 (月) 14:34 (UTC)

そうでしたか。私にはそのように見えたので。お気に触られましたら失礼。えっと、私は逆に技術面での考えはあまり必要ないと考えています（もちろん、行うことによるマイナス面は技術面オンリーなわけですが、でもそれはルールを改定するさいに考えることではないでしょうか？）。ルールが上に来るべきと考えているので。技術面を考える余りルールを破ってしまっては本末転倒ではないでしょうか？いろいろ理由をつけても結局のところは破っていることに変わりないと思います（他の方も疑問を投げかけていますし）。

そして、残念ながら、私はあなたの心配は杞憂であると思わざるを得ません。何が削除されなにが追加されたかは、本来は履歴を1つさかのぼればよいだけです（少なくとも、三島大通り商店街や静岡市についても、分けなければならないほどのの変更がなされたとは、私は思えません。どちらも単なるスタイル調整がほとんどですし）。Ef3さんのは、さかのぼらなければならない履歴を闇雲に細かく深くしているだけのように感じます。なお、私が目を引かれたのは単にEf3さんの履歴が大量に並んでいる「良くない状況（つまり純粋なマイナスイメージ）」と感じただけであり・・・見やすくなったとは、申し訳ありませんが欠片も感じられませんでした。

それと・・・「全員が常に中程度以上の解像度の PC を使っているのではない」という話や接続環境ですが、これは、正直理由として出すのはナンセンスではないかと思います。こういった話になると「そんなものを使っているのが悪い」のか「そういった状況に対応していないのが悪い」のかという話になり、これは結論が出ません（管理側にとっては、システムの問題上切り捨てる環境が存在するのは許されるべきですが、切り捨てをなるべく行わないようにする努力を怠ってはいけない）。また、逆に言えば「そういった環境だからと言ってルールに反れた行動を取っても良い」かといえばそれはやはりノーで、かといって「ルールにあるからと言ってそれを守れない環境を完全に締め出してよいのか」といえば、またこれもノーです（ただ、双方ともに、なるべく推奨される環境に近づく努力と、あわせる努力は行うべき）。ただ・・・あの際は「競合編集しました。箇条書きマークアップした30行ほどの長文が失われました。」というのにちょっときたものがあるのでいわせてもらっただけです（普通、この文だけを見た場合、被害者加害者と言う問題がでませんかね？）。

なお、移動を挟むなど、あなたの環境は私には完全には分かりません。ただ、編集は腰をすえてじっくりと行ったほうがよろしいのではないでしょうか？そうすれば、錯誤を発見したことに伴う打消しなども行う必要はなく、節単位の編集も、ほとんど無しにまで減らせるのではないでしょうか？余計なおせっかいといわれればそれまでですが、アドバイスとして受け取ってください。--koon1600 2006年12月18日 (月) 16:24 (UTC)

アクセシビリティについての立ち位置の違いですね、なんで「そんなものを使っている」かと言えば、「そういう環境でのアクセスを配慮したようにコンテンツを改良する為」と申すしかありません。いまの多くの記事は、端末環境に特定の OS、特定のブラウザを仮定した記述方法が多く観られます。前述の段組などが良い例です。このような出力環境依存は百科事典としてのウィキペディアにとって悪い特徴です。また、XHTMLとして構造がおかしなマークアップも多く見られます。これらはむしろ、バニラ（非CSS適用の状態）の方がよりはっきりと表示に反映されます。あなたが私の編集の差分から読み取れない意味というものの多くは、マークアップの修正（より小規模の編集で是正するように努力しています）の意図に対する理解の問題だと思います。失礼ながら、あなたの利用者ページを拝見いたしますと、マークアップについての基礎的な理解の不足からくる不備が散見されます。特に箇条書きの Wiki 記法だけでも多用されるので、Wikipedia:箇条書きのマークアップ等を参照して、いまご理解されるのは無駄ではないと思います。また、Wikipedia:改行記号は使うなも御覧になると良いと思います。ご自身の読解力を他人のせいにしてはいけません。--Ef3 2006年12月18日 (月) 16:55 (UTC)

箇条書きについては、そのうち直そうと思っています（基本的に読み上げページで読まれるような内容、場所ではないため、私の中で優先度が低いだけです。また、利用者ページにはほとんど無頓着なので、適当に作った代物なので突っ込まれても少々困ります）。改行記号については・・・段落を下げるだけの理由で入れているわけではないため、<br/>を入れるつもりにはなりません（多分空白明けの改行をするくらいまで増えるんですよ・・・将来は）。マークアップの知識不足といわれればそれまでですが（なにぶん、この範囲についてはまともに勉強したことも無いですし、興味もほとんど0のため学ぶ優先順位が低いので。指摘されれば直しますけど。なお、これらの指摘はノートにいただければ幸いです。）。なお、私はどちらかといえば、大きな側よりも小さい側が改良してあわせるべきと言うスタンスのため、Ef3さんとは考え方が反対なのかな？とは思います。それと、「ご自身の読解力を他人のせいにしてはいけません。」この一文なのですが、すくなくとも私はマークアップについての無知をあなたのせいにした記憶はありませんが（どこかで誤解を受けるような発言をしましたかね？誤解でそう感じられたならあやまりますけどね）？ルールについてはともかく。編集競合について言えばシステムとして認められているものですし。ただ、あなたが私の利用者ページのマークアップが不適切ではないかと気にするように、私もあなたの連続編集が不適切でないかと感じていることは、お分かりいただけるかと思います。--koon1600 2006年12月18日 (月) 17:39 (UTC)

「少なくとも、三島大通り商店街や静岡市についても、分けなければならないほどのの変更がなされたとは、私は思えません。どちらも単なるスタイル調整がほとんどですし」を読んで私はどう感じたかを想像してみてください。アクセシビリティについては、

• 自分の親が、視覚障害者だったと想像してみてください。
• 自分の恋人や配偶者が、視覚障害者だったと想像してみてください。
• 自分の子供が、視覚障害者だったと想像してみてください。
• 最後に自分自身が、視覚障害者だったと想像してみてください。

あとは、あなたの想像力に期待するだけです。--Ef3 2006年12月18日 (月) 17:50 (UTC)

はて・・・それと「節編集多用」がなにか関連がありますか？たとえば、履歴を分けまくらなければ音声読み取りソフトが機能しないとか？単なるスタイル調整といったのは、スタイル調整のみであり、加筆、または文の削除が行われていない、ということです。やることに意味がないとは一言も言っていません（むしろやること自体は意義があると思いますよ。今回の場合、方法に問題があると思いますけど）。問題は内容関係無しにわずか1行程度の追加にいくつもの履歴を生み出していることであり、視覚障害者のためのスタイル云々ではありません。--koon1600 2006年12月18日 (月) 18:04 (UTC)ちょっと修正--koon1600 2006年12月18日 (月) 18:11 (UTC)

ちょっと追記。人にどう感じたかを問うているので、「競合編集しました。箇条書きマークアップした30行ほどの長文が失われました。」というのについても、私がどう感じたのかを想像してみてください。--koon1600 2006年12月18日 (月) 18:11 (UTC)

今の連続編集のテンプレートを読んで、『ホントにそんなにサーバへの負荷や容量圧迫があるのかなあ』と思う事はありますね。どこでその負荷や圧迫を確認したらいいのか判りませんし。 数文字修正するくらいで連続編集を行うということではなく、編集内容を判りやすくするという意味で粒度を小さくすべきという Ef3 さんの意見は納得できます。 ただ、出来るだけまとめて（粒度を大きく）編集すべしというガイドラインがあります。粒度を小さくしての編集については、まずは負荷等の面含め実際どうなのかを検討し、広く同意を得てから行うべきではないでしょうか。「悪法でも法は法」という言葉もありますし、ましてウィキペディアのガイドラインは専制君主が決めるものではないのですから現在のガイドラインを決めた時にはそれなりの理由があったはずです。もし現状ではその理由に意味がなくなっていたり、より良いガイドラインの提案があるのであれば、きちんと変更の手順を踏むべきでしょう。単なるガイドラインだからまるっきり考慮せずとも良いという訳ではないですよね。 By 健ちゃん 2006年12月19日 (火) 07:07 (UTC)

en:Wikipedia:Don't worry about performanceというのが英語版にあります。サーバーは英語版も日本語版も同居(なのかな?)だと思うのですけど、私はこの意見が自然に思えます。編集ユーザーがサーバーパフォーマンスを考えるのは本当に最後のことだと思うんです。つまり普通は考えなくていいと思うんです。というかストレートに言うと、そういうことにとらわれていてはいけないと思うんです。リダイレクトがサーバーに与える影響があるとのご指摘を自分が受けたときにこの文章をみつけて、同じ考えだと思ったんですよ。こういう開発チームに支えられているWikipediaは信頼できると思ったんです。そうでなければ、たとえば、ウィキメディア・コモンズでできるだけ大容量の画像が推奨されていることの説明ができないですよね。ですからガイドラインでサーバーパフォーマンスに触れながら編集に制限をかけているのは誤りではないかとも思っていますけど。編集は百科事典としてそしてWikipediaとしての機能と意味においてガイドされるものだと思います。その点で、今回の議論では同じユーザーの履歴が続いてしまうことに関してのみどうにかならないかなとは思います。(自分もよくやるので。できたらシステム的にほしいなあと。いえ、これは単なる勝手な希望です・・。)--Pararinpooh 2006年12月19日 (火) 16:49 (UTC)

サーバの負荷は1つの記事への連続した異なる節の編集を行うべきでない理由となりえるか

健ちゃんさんのサーバへの負荷や容量圧迫に関するご意見・Pararinpoohさんのサーバーパフォーマンスを考えるのは本当に最後とのご意見と重複しますが、「サーバの負荷」は「1つの記事への連続した異なる節の編集を行うべきでない」とする理由となりえないと言う立場の意見を述べます。

「1つの記事への連続した異なる節の編集を行うべきでない」とする主張の1つの根拠に、「サーバ負荷の増加」が上げられます。 Wikipedia:同じ記事への連続投稿を減らす（2006年11月5日 (日) 18:39 版）から関係する部分を、引用します。

理由は

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

1.は、背景に　MediaWiki は版の間の差分ではなく各々の版の全文を保存しており、版数増加がそのままサーバー（バックエンド）のストレジ容量要求の増加となるという技術的な事情があります。しかし、このことは小さな記事であればその影響は軽微であるので無視できるという結論につながります。

2.の前半「表示が遅くなります」は「履歴項目が多くなれば複数ページになり各ページのサイズは変わらない」事から合理的な理由ではないです。後半の「データ容量も増えます」は履歴管理の容量コストの増加を言っているのですが、これも自身で「非常にささいなもの」としているように有意差はなく重要度は低い（重要でない）と考えられます。

また、Pararinpoohさんのサーバーパフォーマンスを考えるのは本当に最後とのご意見で参照されている、en:Wikipedia:Don't worry about performanceの論旨は日本語版にも当てはまると思います。英語版のガイドラインが日本語版で有効だろうかというのは興味深い議論の対象ですが、言語にる差異がない事項を扱っているので、英語版のガイドライン（の策定根拠）は参考になると思います。

以上から、容量負担を含むサーバ負荷は「1つの記事への連続した異なる節の編集を行うべきでない」と言う結論を得るに足る理由ではありません。（「Wikipedia:同じ記事への連続投稿を減らす」のノートではなく、井戸端で続けたのは、同じ事を理由とするガイドラインがあるからです）--Ef3 2006年12月20日 (水) 01:08 (UTC)

節単位の編集を1つに記事に行うことが必要になる理由

1つの記事を全体を一括でなく、節単位で編集することが必要になる理由を考えてみました。

1. 全体では、レンダリング結果の確認が困難な場合
2. 複数の性質の異なる変更を1つに記事に行う場合
3. 危険なオフライン編集の回避
4. 編集漏れをした節の編集
5. 競合編集機会の削減

1.の具体例として、前わたしが連続投稿をご指摘いただいた静岡市の履歴[3]を上げます。私の名前で同じ要約「段組」が続いており典型的な「１つの記事への連続投稿」ですが、1つの差分を観てみましょう[4]。差分だけでも複数ページにわたる規模のものです。編集内容は table を使っていた3段組みレイアウトのリキッドレイアウトへの変更です。

table を使っていた3段組みレイアウト

葵区 静岡市立中央図書館 静岡市立御幸町図書館 静岡市立藁科図書館 静岡市立西奈図書館（リンク西奈） 静岡市立北部図書館

駿河区 静岡県立中央図書館 静岡市立南部図書館 静岡市立長田図書館 静岡キリスト教点字図書館

清水区 静岡市立清水中央図書館 静岡市立清水興津図書館 静岡市立蒲原図書館

リキッドレイアウト

葵区

• 静岡市立中央図書館
• 静岡市立御幸町図書館
• 静岡市立藁科図書館
• 静岡市立西奈図書館（リンク西奈）
• 静岡市立北部図書館

駿河区

• 静岡県立中央図書館
• 静岡市立南部図書館
• 静岡市立長田図書館
• 静岡キリスト教点字図書館

清水区

• 静岡市立清水中央図書館
• 静岡市立清水興津図書館
• 静岡市立蒲原図書館

いまごらんのあなたのブラウザのウィンドウの幅を小さくしてみてください。前者は3段組のまま、後者は表示幅に合わせて3段組→2段組→1段組と変わるはずです。このように出力ディバイスの幅に相応しい組版を行うという特徴を記事に組み込みました。この特長はハンディーフォン・PDAでの閲覧や高品位タイプセッターへの出力などのシチュエーションでアクセシビリティとレンダリング品質を向上させます。問題になっている静岡市の記事はとても大きく（87 キロバイト）上記の特徴を組み込む時に必要な編集とプレビューをもし全体に行っていたら、変更箇所を確認するという仕事は非常に困難を極めたでしょう（静岡市の記事のWikiソースから上記の図書館の部分を探してみてください）。

2.は記事の加筆推敲とマークアップの修正をドキュメンテーション上の見地から分離したい場合などのことです。また前後を入れ替える編集も他の編集と分離しないと差分がとても煩雑になります。これらは編集単位を２つ以上に分けることで「編集内容の要約と差分の対応関係（＝編集意図）」がはっきりします。

3.は、「Wikipedia‐ノート:同じ記事への連続投稿を減らす#記事の破壊の恐れがあるのでオフライン編集に関する記述の一時抹消を提案します」でも指摘していますが、「競合編集が発生するはずのシチュエーションで警告なしに投稿できてしまい、他者の編集内容を上書き破壊してしまう」という極めて危険な特徴のあるオフライン編集を回避するという意味です。4.と5.は自明ですね。

以上の様に、一括でなく節ごとに記事を編集することに合理性があるケースもあるので、単に編集履歴が時間的に連続している異なる節への編集が観られても、Template:一括を利用者の会話ページに substするには情報量が不足しているといえます。特に加筆修正ではなくマークアップの変更の場合はレンダリング結果の差異を確かめ、連続した節単位の編集の妥当性の検証をする事が警告前に必要で、これは機械的に行うことが困難（おそらく不可能）です。--Ef3 2006年12月20日 (水) 02:47 (UTC)（「変な」XHTMLの構文が蔓延すると困るので修正しました。--Goki 2006年12月23日 (土) 03:23 (UTC)）修正ありがとうございます。議論の対象であるレンダリングの挙動が同じであれば、文法的な修正は間違えの伝播の予防という意味で大切だと思います。ただ、width: 指定を変更している部分はレンダリングが変わってしまうのと、新たに加えられた vertical-align: top; は、display:block な div には無効な指定ですので、差し戻させて頂きました。（width: NNem は、white-space:nowrap; max-width:24em あたりが良かったかもしれません）--Ef3 2006年12月23日 (土) 08:12 (UTC)

「外形だけをもって一律に"Template:一括"を貼ることに反対」には賛成です。

列挙理由の

1. 全体では、レンダリング結果の確認が困難な場合

2. 複数の性質の異なる変更を１つに記事に行う場合

は賛成します。ただ、

3. 危険なオフライン編集の回避

は、オフライン編集をする人が気を付けるべきというだけの問題で、これを理由に節単位投稿を勧めることは反対です。{{工事中|NNNN分}}使うだけでも大分違うかと。また、

4. 編集漏れをした節の編集

は、そもそも一括投稿した方が節の編集漏れは減るような気がしますし、うっかり編集漏れをする人は他にもうっかりをしている可能性が高いことを考えると必ずしも節単位の編集を勧める理由になるとは思えません。

5. 競合編集機会の削減

は、wikipediaが版全体でデータ管理している以上、節単位で編集しようが一括で編集しようが機会は変わらないと思います。作業時間の長さが問題なら上記「工事中」を使用するのがいいと考えます。Fuji 3 2006年12月20日 (水) 04:40 (UTC) (列挙番号が滑っていましたので手で振りました) --Ef3 2006年12月20日 (水) 06:46 (UTC)

1.2.にご賛同ありがとうございます。3.を{{工事中|NNNN分}}で回避しようというのは『履歴を増やす』と言う観点からは解決になっていない気がします（編集する節の数が多い場合には、それでも有効だと思います）。また{{工事中|NNNN分}}を使ってくれる程に配慮されている方ならば、上書きもまたしないと思います。4.は一括編集し投稿したあと間違いに気づき節単位で修正した場合ですので、微妙に今回問題にしている状況と異なりますが、履歴に残る絵姿として似ているので含めました（間違えに気づいたら、節単位で編集すると思います）、うっかり者に一括編集が向いているか節単位編集が向いているかは一概に言えないと思いますが、節単位であるほうがプレビューの中の自分の変種箇所を探すことが簡単（1.の事）とはいえると思います。5.は節単位の方が（記事一括に比べ）短時間に編集が終わるので競合編集の機会が減るという意味です（また、競合編集の発生した時もマージが楽になります）。競合編集については、MediaWikiが patch(1) の様に差分からマージし、失敗した時だけ競合編集を人間に助けを求めれば良いのですが、現状の実装はそうなっていませんMediaWikiには競合の自動解決機能が実装されています。これは diff3(1) によるものです。（⇒Wikipedia:編集の競合#編集の競合ページのレイアウトの最後の行）（訂正：Ef3 2006年12月20日 (水) 09:51 (UTC)）。--Ef3 2006年12月20日 (水) 06:46 (UTC)

(5)については、全員が節単位で編集すればそうなると思いますが、Aさんが節単位で細々と更新している一方で、Bさんが一括で更新しようとしている場合、Aさんの編集競合遭遇確率は減りますが、Bさんが編集競合に遭遇する確率は変わらないと思います。現状の仕様で、全ての編集を節単位で行うように推奨することには賛成しかねますし、実質そういう誘導になってしまう(5)を節単位編集が優先されるべき理由として挙げることは適切とは思いません。wikipediaがどれだけ大きいDBで運用されているのかは知らないので、単に技術屋さんのケチケチ感覚に過ぎないかもしれませんが…Fuji 3 2006年12月20日 (水) 07:04 (UTC)

「Aさんが節単位で細々と更新している一方で、Bさんが一括で更新しようとしている場合、Aさんの編集競合遭遇確率は減りますが、Bさんが編集競合に遭遇する確率は変わらない」のであれば、Aさんの選択は正しいように思えます（厳密に言えば編集競合遭遇時作業量ですが）。ともあれ、無条件に「一括編集よりも節単位の編集の方が優れている」と主張するのは無謀な主張だと承知しています。私が考えているのは、「どのような粒度で投稿するのが適切か、の議論が必要であろう」という事です。特に現状のWikipedia:同じ記事への連続投稿を減らすには 2. の様な観点がゴッソリ抜けているように思います。曰、「同じ人の些細な修正が連続すると、全体の見通しが悪くなり、誰がいつどこを変えたかを見たい時に、手間取ります。」（Wikipedia:同じ記事への連続投稿を減らすから抜粋）） --- 「些細な修正」の定義が必要なのではないでしょうか？また、それに適切な定義がないのであれば、ルール自体の不備といえるのではないでしょうか？ --Ef3 2006年12月20日 (水) 08:31 (UTC)

脇から失礼します。上の議論で、一つ疑問が在ります。「Aさんが節単位で細々と更新している一方で、Bさんが一括で更新しようとしている場合、Aさんの編集競合遭遇確率は減りますが、Bさんが編集競合に遭遇する確率は変わらない」のではなく、「同じ記事の投稿者としてをAさんとBさんが存在して、Aさんが節単位で細々と更新している一方で、Bさんが一括で更新しようとしている場合、Aさんの編集競合遭遇確率は減りますが、Bさんが編集競合に遭遇する確率は増える」危険性が高いのではないですか？Wikipediaに書き込む為のフォーマットというか、定義がきちんと決まっていて、テキスト文書をコピー＆ペーストすれば記事を投稿できるので、じっくり考えて、休日に十分な環境でまとめてコピペ投稿すれば良いところを節単位に急いで編集する必要あるのかな？と思います。それは、どのような粒度にもよらず、です。上のWikipedia:同じ記事への連続投稿を減らすはそういうことがいいたいのではないでしょうか？

あと、「些細な修正」の定義って、どうやっても主観によるところが出てくるんじゃないかな？--218.251.125.114 2006年12月21日 (木) 02:41 (UTC)

細々と理由を挙げているけれど。実際のところ静岡市の履歴を見ても『編集競合の怖れがあった』とは到底思えません。私には、Ef3さんの書いていることは『自分を正当化する為の屁理屈』にしか見えないですね。決まりごとの表現に文句をつけるのも感心しません。現実に『些細な修正』は存在しています。定義どうこうは、境界線を引かないといけない時にでも議論して下さい。 -- ＮｉＫｅ 2006年12月21日 (木) 03:06 (UTC)

辛辣なご意見ですが、静岡市の例は、『編集競合の怖れがあった』ケースではなく、

1. 全体では、レンダリング結果の確認が困難な場合

の例です。お確かめください。--Ef3 2006年12月21日 (木) 08:02 (UTC)

まず第1に、何故そのケースがプレビューの使用で解決できないのか、私には理解できません。具体的に説明して下さい（ここを読め、などでも可）。第2に、そのように見かけについて凝る必要性が理解できません。第3に、編集競合が問題としての連続投稿の実例が示されていないように思えます。 -- ＮｉＫｅ 2006年12月22日 (金) 03:04 (UTC)

上述の「（静岡市の記事のWikiソースから上記の図書館の部分を探してみてください）」は試されましたか？また「見かけについて凝」っていたのは私の編集の前の TABLE による段組版で、わたしはそれをブラウザの表示幅に依存しないように（自動で段組を調整するように）改良しただけです。編集競合については4.についての議論を御覧ください。主要な論点はWikipedia:編集の競合#編集の競合ページのレイアウトにあるとおり衝突のない編集の競合は MediaWiki が diff3 をつかって自動編集統合する（そしてそれに失敗すれば確実に「競合の編集」ページで競合編集の修正機会が与えられる）という点です。それから、井戸端にあっても、編集内容の要約は記入するようにしましょう（⇒Wikipedia:常に要約欄に記入する）。--Ef3 2006年12月22日 (金) 03:30 (UTC)

第1点。「静岡市」のソースは見ましたが、あなたが何を言わんとしているのかは分かりかねます。説明して下さい。第2点。前よりマシ、とおっしゃりたいのは分かりますが、2段とか3段とかにしようとすること自体『見かけについて凝る』行ないのように思えます（見易くなるのは良いことですから、悪いとは言いませんが）。第3点。編集競合になるようなケースの実例は？ -- ＮｉＫｅ 2006年12月22日 (金) 10:42 (UTC)

MediaWikiには、異なる節の編集の競合を自動で統合する機能があります

私も今日気がついたのですが、MediaWikiには、異なる節の編集の競合を自動で統合する機能があります。

2人のユーザーが別の節を編集していた場合など、別の箇所の編集が競合した場合には、diff3（英語版記事: diff3）によって自動で編集が統合されます。

（Wikipedia:編集の競合#編集の競合ページのレイアウトより抜粋。）

この事は、節単位の編集の投稿の位置づけを（若干ですが）正当と位置づける事実だと思います。また上の引用では不明確ですが、diff3は行を単位に機能するので、１行をあまり長くすると（ソースであまりにも改行を使わないで長く繫げていると（<br />は無関係））diff3による自動統合を阻害することになります（Wikipedia:改行記号は使うなで否定されているルール改行を適宜入れるべきは適切なルールだったのかもしれません）。--Ef3 2006年12月20日 (水) 10:08 (UTC)