Wikipedia‐ノート:ページの分割と統合/過去ログ1

過去ログ1 - 過去ログ2 - 過去ログ3 - 過去ログ4 - 過去ログ5 - 過去ログ6 - 過去ログ7 - 過去ログ8 (edit)

起案にあたって

たたき台としてまとめてみました。皆さんのご意見をお聞かせ下さい。また、履歴統合の手順は、リバートでも良いように思ったのですが、管理者がリバートすると、要約欄にその旨のメッセージが入ってしまうようですので、本文のような手順を記載しておきましたが、もっとよい手順があったら、訂正して下さい。最終的に履歴統合したことが、履歴ページを見て分かるようにしておけば、多少であれば、時系列的に重複する履歴の混在も許容されるかな、という趣旨です。内容面に関してご検討の上、ご意見よろしくお願いします。また、わかりにくい文章や、誤解を招きそうな文章があれば、ご指摘下さい。--oxhop 2004年10月25日 (月) 11:25 (UTC)

統合の提案のセクションについて

「されるべきです」の記載は一方的かも知れません。「統合が提案されています」くらいのニュアンスでいいのではないでしょうか（削除依頼の議論も踏まえて）。また、テンプレートがあると楽かも知れません。竹麦魚 2004年10月25日 (月) 11:27 (UTC)

こんな感じでどうでしょう。使い方は、{{記事統合|統合相手の記事名|議論を行う場所}}

--oxhop 2004年10月28日 (木) 13:48 (UTC)

分かりやすくていいと思います。個人的には即採用です。竹麦魚 2004年10月28日 (木) 13:52 (UTC)

複数記事の統合ということがありえますので、第一引数は二重ブラケットをはずしておくほうが無難でしょう。議論がノート以外で行われることまでは想定しなくても良いかもしれませんが。--61.195.111.40 2004年10月28日 (木) 13:58 (UTC)

統合した方がいい場合ですが、「記事A中のセクション a を記事 B 中の新しいセクションに移すのが望ましい」というような、いわゆる部分統合というか、移植のようなものも考えられますね。これはこのページで扱うべきなのか、ちょっと迷いました。手続き的には管理者による履歴統合処理では対処しきれないですし、面倒なケースですし。

Tomos 2004年11月7日 (日) 16:45 (UTC)

この記事統合のテンプレは僕が先日作成しましたのでお知らせいたします。（詳しくはこちらの統合依頼のページに）MASA 2004年12月14日 (火) 01:38 (UTC)

記事の分割

表から転記しました。--oxhop 2005年3月2日 (水) 12:55 (UTC)

草案ということで、こちらにコメントを。開発者の人と話したときに、開発者なら履歴の分割を出来る（コピーして同じ履歴をもったものを二つ作る）、それはメタで頼んでくれればやるが、出来れば100件くらいたまってから頼んでほしい、ということをいっていました。この作業のためには要約欄だけでなく、どこかに分割した記事の情報をストックしておいたほうがよいと思います。[[利用者:Aphaia|Aphaea*]] 2004年10月25日 (月) 11:29 (UTC)

今回の草案の手順でそのまま適用できそうなのは記事に関連したリストや最初から単独記事として完結を前提にした独立志向の章立ての文章に限るのではないでしょうか。と言いますのも大抵の記事は分割を前提にして書かれていないことが多く、一つの記事として体裁を整えたものが多いと感じます。具体的には甲が Section-A, B,-C で構成された記事で、乙を Section-B とした時、Section-B に書かれた文章に「○○については（Section-Cで）後述」や「（Section-A にある）前述の○○のように」といった表現で互いに引用・連携されている可能性があります。『分離すべき部分を削除しリンクを貼る』際には元記事単体でもひとまずは機能するように最低限度の要約をまとめておき、より詳しい内容については Section-B を参照、といった表現にしないと元記事そのものが不完全なものになる可能性は無いでしょうか。分割手順の前段取りとして甲の記事の本文やノートで十分に分割した後も支障が起きないように議論を重ね、乙の体裁は元より、甲のまとめ文や乙が成長した際のフォローアップ、更なる分割が起きる場合の甲との関係なども想定して検討したほうが良いのではないかと感じます。Koba-chan 2004年10月25日 (月) 12:47 (UTC)

Wikipedia:履歴、GFDLとの関係など

Oxhopさんにとっては既に耳新しい話などはないように思いますが、いくつか確認なども含めてGFDLにおける履歴保存の要求との兼ね合いについて、考えてみました。

ちなみに、おおざっぱに言って、このような変更に僕は賛成です。

１）GFDLとの関係

まず、ここで提案されている内容は、履歴を保存しないままの記事の分割や統合を暫定的、または非暫定的に認める、ということになると理解しましたが、それでよいでしょうか？

そうすると、これは履歴を保存せよというGFDLの要求とかなりあからさまに反してしまいそうなところが気になります。（ただ、個人的にはその要求は非常に不便なので、何とか回避できるようにしたいと思いますし、そういう合意がとれればいいとも思っていますが。）

２）GFDLとウィキペディアの関係についてのこれまでの議論

次に、ウィキペディア日本語版の内部での文書の扱いにGFDLが適用されるべきなのかどうかについては、Modehaさん、ゆすてぃんさんから、そう考えないこともできると指摘されているように思います。個人的には特にゆすてぃんさんの議論については、有力な論拠もあると思いました。そうであれば、そもそもこの統合・分割に関する提案がGFDLに沿っていようがいまいが気にしなくてもよいかも知れない、と思います。

ただ、これまでの議論では、そういう風に（日本語版内でのコピペなどについてはGFDLが適用されないと）解釈しよう、ということでは合意がとれず、Suisuiさんから、GFDLはウィキメディアのプロジェクトの中核的な要素だと聞いているのでGFDL以外の条件を導入するのであれば最低でも財団の了解をとる必要があるという意見が出ています。また、日本語版独自のライセンスを導入するなどは望ましくないとも。

更に、GFDLから変更するのであれば、わかりやすい説明を提供して時間をかけて広く賛成意見が出るのでなければやるべきではない、という意見も出ています。

そこで、GFDLからやや外れることになるこの文書についても、同様の手続きを踏まない限りは実行しない方がよい、というのがその際議論に参加されていた人の合意かと思います。

３）この案と、GFDLとの関係

以上から、とりあえずウィキペディア内部での文書の扱いがGFDLに即したものであるべきだという仮定で議論をもう少し進めてみます。

まず、この案が具体的にどのようにGFDLから外れるか、というのは次のように言っていいかと思いました。

「自分の作成した文書（記事であれ、それ以外であれ）が、場合によっては、自分の名前なりユーザ名なり、IPなりと切り離されて利用されてもよい、という許諾を、いわばGFDLに加えてウィキペディア日本語版の他の参加者に与える。」

（と、間違っていたら済みません。）

つまり、今までGFDLにはなかった、別の許諾を与えて、場合によってはそちらの許諾条件にのっとって文書を利用・処理してもよい（具体的には記事の統合・分割をしてもよい）ということです。

４）追加許諾ができない人

この案が、追加許諾だということだとしたら、この追加許諾を与えることができない人がいる、というか、分割・統合をしたいと思っている人が関係者から許諾をとりつけたいと思っても、とりつけられない人が3種類ほどいると思います。

1. 活動を停止した人。既に過去に投稿され、この案の導入時点でウィキペディアで活動していない人
2. 外部のコンテンツ提供者。ウィキペディアにコンテンツを提供する許諾（GFDLとWikipedia:著作権、および関連ページへの同意）をしたが、直接ウィキペディアには投稿していない人
3. 他言語版などの参加者。ウィキペディア日本語版には参加しておらず、英語版など他言語版でGFDLの文書を作成し、それが翻訳されるという形で日本語版のコンテンツに貢献している人

この3種類の寄稿者の扱いをどうするべきか、というのがひとつの難所だと思います。

僕が安直に思いつくのは、「そういう人が履歴に含まれている記事は履歴をきちんと保存する形でなければ分割・統合してはいけない」というものです。ただ、「ある特定のセクションなど文書の一部のみを履歴と切り離して分割・統合したい場合、その部分に携わった執筆者全員が、含まれないようなら、分割・統合してもよい」とは言えます。

ちなみに、上記のModehaさん、ゆすてぃんさんの論が正しい、これまで投稿ボタンを押した際の合意内容を、そう解釈することで合意がとれる、ということであれば、上記の1のタイプにのみ属する人については、その必要はないということになりそうですが、2,3には対処できないので、そういう人が履歴に含まれている場合には別の取り扱い（GFDLに即したもの）をしなければならない、ということになると思います。

５）法的なトラブル

それから、これがGFDLとは別の、追加許諾だとして、この案だと、その許諾に基づいた記事の統合・分割をいつしてもよく、いつしてはいけないか、という点については、若干曖昧さが残っているのが気になります。法的な問題に関係のない他の件であれば、曖昧さがあってこそ柔軟な対応ができるわけで、それでも構わないように思うのですが、この件については、「あなたは私の書いたものを履歴から切り離して別のページに移したけれども、それはこのガイドラインにある記事の分割が推奨されるケースにあてはまっていない」というような苦情が出る場合には、それはひいては「GFDL以外の条件で文書を扱ってはいけなかった場面で、こちらの条件で扱ってしまった」、つまりGFDL違反であり、著作権違反である、というようなトラブルになる可能性も一応考えられると思いました。

しかも、分割をしてから随分経ってからその苦情がやって来て対応に非常に困る、というようなこともあるかも知れません。唯一考えられる対応は、ついているべき履歴がついていない文書なので削除する、というものですが、これを避けたいと思うケースもあるだろうと思います。でも、削除依頼が出て、管理者も対応を迫られるかも知れません。悪質ないたずらの類（分割しなくてもいいものをわざわざ5つに分けるとか。。）であれば、削除で対応するのがいい場合もあるでしょうが、単なるミスであれば、例えば統合された記事を丸ごと削除するのは避けたい、ということもあるかも知れません。

そこで、この案にある種の免責事項のようなものをくっつけておくのはどうだろうか、と思いました。安直な案として思いつくのは、「手続き」の上でこの案に沿って分割・統合を行った場合には、仮にそれが「統合・分割にふさわしいか」の判断を誤っていたとしても、それだけを理由に削除をする必要はないことに同意する、また統合・分割を行った者や速やかに削除を行わない管理者に対して著作権侵害その他の理由で訴訟を起こさない、というものです。

そのような免責条項に全員が同意するのであれば、上記のようなトラブルは避けられると思うので。ただ、削除しない場合には、他にどういう措置がとれるのか、もう少し案が出せればいいのですが、ちょっと咄嗟に思いつきません。

これとよく似た形で、例えばUTCにしなければいけないところをJSTにしてしまったとか、リンク先を打ち間違えて赤リンクになってしまったとか、いろいろなミスが起こった場合に、それでもまあそれほどひどいものでなければ、できる範囲で修繕すればいい、という規定があるといいんじゃないかと思いました。どういう風に修繕するのかは、ある程度具体化されているといいだろう、とも。

もうひとつ別種のトラブルも考えられます。

許諾をとりつけることができない過去の投稿者など、上記の1-3にあてはまる人が履歴に入っているのにそれを切り離してコピペをしてしまった、という場合には、基本的にGFDLのみの許諾をもらったにも関わらずそれに反して利用してしまうことになるので、削除以外に手がないかな、と思いました。

そして、こういう手続きが導入されると、コピペ一般がOKだと勘違いしてしまって、（そういう勘違いはこの手続きがなくてももちろん存在するわけですが）、上記の1-3にあてはまる人が履歴に含まれているのに記事を分割してしまったり、統合してしまう、というような人が増えるかも知れません。そうなると、なかなか気づきにくいけれども実は履歴情報が間違っていてGFDL上不備のある文書がウィキペディア日本語版内に増えてしまうということにもなります。これは、ウィキペディアのコンテンツを別の文脈で利用したいと考える人（外部サイトでも、出版社でも、CD-ROMの出版社でももいいですが）にとって問題になるかも知れません。投稿者にとっても問題になるかも知れません。

管理者や財団は、特に責任を負うことはないかと思います。（通知があったのに放置するなどすれば問題ですが）　

投稿者の場合、履歴に不備があるGFDL文書に、そうとは知らずに加筆・編集を行ってしまった人は、それを理由に著作権侵害で責められるということはないんじゃないかという気がするのですが、ちょっと断言できません。これは、一応は、著作権を侵害している文書を複製・加工し、自分の名前を加えて出版（というか公衆送信可能化）することに近いので、問題を作り出した本人（著作権侵害をした人）とは到底いえないまでも、その被害を拡大させた人にあたり、責任が発生してしまうでしょうか？　これを避けるためにどうするといいか、というと、免責条項を導入することでは対応できないように思います。上記の1-3の人たちには免責条項を導入して同意してもらうこともできませんので。

そうすると、できるのは、導入する前にもした後にも、できるだけ多くの人に知ってもらって、そういうコピペ事故が起こらないようにする、という予防措置かな、と思いました。

そして、コンテンツを利用する外部サイトや出版社などですが、ここでも、同じように、出版社なら出版社が負うべき注意義務があって、それに反したと解釈されるとその分責任を負わされることになるようですから、ウィキペディアには実はきちんとした合意もなく履歴と切り離された文書がたくさん混じっている、ということになると、その分利用者にとってもリスクが高くなるかと思います。

これも特に免責などで片付く問題ではないので、探して削除するなり、履歴の統合などの措置を施すなり、ということをするのがいいかと思います。

とりあえず考えたのは以上です。脳内ソースに頼っているので、関連ページへのリンクなどはしていませんし、もしかすると誤認があるかも知れませんが、とりあえず。

Tomos 2004年11月7日 (日) 16:47 (UTC)

何度も読み返して、考え込んでいるうちに日が経ってしまい、大変お返事が遅れてしまい申し訳ありません。

1. 履歴を保存せよというGFDLの要求との関係ですが、例えば、記事Aを記事Bに分割した場合、Bの履歴ページの2ページ目として、Aの履歴ページを扱うということで、この要求を満たすことができるのではないかと考えました。もちろん、直接履歴ページ同士を相互リンクすることはできませんが、履歴の要約欄を見れば容易にたどることができるので、外部でGFDLに基づき利用しようという人に対して履歴情報を提供することができます。
2. 私も、内部にGFDLが適用されるかどうかについては、Suisuiさんと同意見です。ですから、この文書を何とかGFDLに適応させる方向にもっていきたいと考えています。
3. 例えば、AをBに分割した場合、Aの履歴がBに移行しないので、Aへの投稿者名とBへ分割された記事とは確かに切り離されます。しかし、履歴ページの要約欄を通じて、何とか繋がっていると解釈することはできないでしょうか。
4. したがって、追加許諾ではなく、GFDLをWikiシステムに適用する際の解釈の変更ということで突き詰めていければ、と思ってます。
5. 問題点は、Wikipedia‐ノート:著作権#コピー・アンド・ペーストの際に履歴を保存しなくてよいという規定でTomosさんがご指摘になっておられるように、移動や分割が複雑になったり、一方が履歴ごと削除されてしまった場合に、履歴情報を提供できなくなることです。このような場合が予測される場合には、履歴の分割（複写）や統合、あるいは、ノートへの履歴情報のコピペで対応するというのではダメでしょうか。--oxhop 2005年2月1日 (火) 17:09 (UTC)

分割時の主となる記事の選定について

つい先ほど知ったのですが、月は東に日は西にが分割されていたようです。と、これだけであればここで挙げるようなことでもないのですが、その分割の結果履歴情報が訳のわからない状態になってしまったのです。

この記事なんですが、元々月は東に日は西に ～Operation Sanctuary～の内容で書かれていた物ですが、途中から漫画の記述が書き足されるという形になっていました。この状態であれば、私としては「今は現状のままにしておいて、XMLインポートが実装されたら履歴を複製してそれから分割すればいいかな」という感じであったのです。が、分割が行われたことによって、途中から漫画の方の履歴になってしまったと言う感じなのです(ここからここへつながる)。このような分割は履歴情報的に問題になるのではないでしょうか?--PiaCarrot 2004年11月22日 (月) 14:25 (UTC)

ちょっと整理すると、

1. 最初にその記事がたった時点ではAに関する記述であった。
2. 後に別分野Bに対しての内容が書き足された。
3. さらに版が進んで、AとBに分ける必要が出てきた。

というときに、どっちの分野を残すべきかという問題です。--PiaCarrot 2005年3月25日 (金) 12:18 (UTC)

基本的にどっちでも良い。履歴に占める重要度が高い方に履歴本編を入れたら良いと思いますが、重要度の判断は人によってわかれます。初版がどちらかとか、どちらの編集回数が多いとか、どちらの文章のが多いとかは、重要度と相関の高い事柄ではありますが、定量的に判断するのは難しいものです。結局は分割した人の好みってことになるでしょうし、その好みに異議を唱える必要もないでしょう。というか、エロゲーとエロゲー以外を 1 ページに混ぜるのはやめて。お願い。―غاز_(Ghaz) 2005年3月25日 (金) 14:17 (UTC)

移動した上で跡地に分割で取り出した物を戻す、というのも手法としては十分あると思います。(私自身は月は東に日は西にに関しては、まず既存の記事を月は東に日は西に ～Operation Sanctuary～に移動した上で、漫画の部分を月は東に日は西にに戻すという手法を考えてましたし)。その辺の方針だけでも決めておいたほうがいいと思います。--PiaCarrot 2005年3月25日 (金) 14:30 (UTC)

当然あるでしょう。あるとした上で「元の場所に履歴本編を残す」「履歴本編ごと移動する」の好きな方を分割者が選択すれば良いというのが僕の主張です。ところで「方針」ってどんな感じのものを考えてるんですか？ 素案よろしく。―غاز_(Ghaz) 2005年3月25日 (金) 15:10 (UTC)

私が考えた素案はこんな感じですかね。

• 履歴上主なものを主流記事とし、他の記述を取り出すことによって分割する。この主流記事の判断としては、基本的には最初に有用な記述があったものを主流とする。ただし、最初に記述されたものよりもそれ以外の記述のほうが編集回数が多い場合はこの限りではない。
• 分割に当たって主流としたものに対して記事名が不適切であると思われる場合、主流の記事をふさわしい名前に移動した上で、分割で取り出されたものの1つ、もしくは分岐関係の情報を移動した跡地に埋める。
• シリーズをまとめていた記事を各作品別に分割する場合、元の記事名には筆頭となるタイトルの記述を残す。

--PiaCarrot 2005年3月25日 (金) 15:43 (UTC)

対案あるいは感想を。そんな瑣末なルールは要らない。普通に分割すればよい。以上、ごめんね。―غاز_(Ghaz) 2005年3月25日 (金) 16:38 (UTC)

Ghazさんに同感。どちらを主にするかは、恣意的に決めていいのではないでしょうか。--Tamago915 2005年3月25日 (金) 16:48 (UTC)

履歴の保存

話がややこしくてわからないのですが、少なくとも現在は、統合（分割）するときは統合（分割）先に、元の文章をコピーしておかなければダメということですよね？履歴をノートページに書いたり、統合・分割履歴専用のページを別途に作成したりしても十分ではないということでしょうか？chicken 2004年12月5日 (日) 06:25 (UTC)

Wikipedia‐ノート:著作権の過去ログやWikipedia‐ノート:履歴あたりによると、記事ページとノートページはそれぞれ独立したものと考えざるを得ないようです。--oxhop 2005年2月1日 (火) 17:10 (UTC)

分割のための記事の複製の提案

「GFDL の要件を満たさない」コピーで分割された記事が削除対象になっている事例をいくつか見かけます。この事態を回避するため、記事の複製機能を実装することを提案します。

現状でも記事の移動ができるわけですから、同様のインターフェイスで記事の複製ができるようになればよいと考えます。また、記事の複製によって、ある記事と同じ内容・同じ履歴を持つ新しい名前の記事が作成されるようにします。

記事の複製が実装されれば、記事甲を記事乙と記事丙に分割する手続きは以下の手順で実現できます。

1. 記事甲を記事乙に複製する。
2. 記事甲を記事丙に移動する。
3. 記事乙・記事丙のそれぞれについて、不要な部分を削除する。

これで GFDL の要件を満たす記事の分割が、簡単な方法で可能になりますが、いかがでしょうか。--Tamago915 2005年1月7日 (金) 12:22 (UTC)

誰にでも複製を許すというのは賛成できません。使用不可能攻撃に使われるおそれがあります。現状開発者への依頼でとくに困ることもありませんし、ご提案には残念ですが魅力を感じません。--Aphaea* 2005年1月13日 (木) 10:53 (UTC)

誰がこの機能を使えるようにするか、という点を除けば、賛成です。少し違いますがWikipedia:XML インポートが導入されれば実質的には同じことを管理者が実行できるようになると思います。Tomos 2005年1月15日 (土) 05:54 (UTC)

技術的に可能なら、望ましいですね。現在は、特別な依頼が必要なのではないのですか？--っ 2005年1月13日 (木) 09:48 (UTC)

恐らくXMLインポートが実装されれば解決可能だと思います。後、現状でも必要な分割であればWikipedia:履歴複製依頼（多分っさんの言う「特別な依頼」とはこれだと思います）にメモしておいてくれるとうれしいです。聞いた話では現状でも相当数集めれば開発者に依頼して複製してもらうことができるそうですし、集まらなくてもこのメモを元にXMLインポート実装後に複製を行うことができますので。--PiaCarrot 2005年1月18日 (火) 06:55 (UTC)

（↑っ さんと PiaCarrot さんの意見を、Wikipedia:井戸端#分割のための記事の複製の提案から移動させていただきました。--Tamago915 2005年1月18日 (火) 09:44 (UTC)）

Aphaea さんのいう「開発者への依頼」がWikipedia:履歴複製依頼だと、今気づいた次第です。XML インポートの導入後、「分割依頼」か「複製依頼」をコミュニティに提示し、合意をもって管理者が記事の複製（XML インポート）を行うという流れにすれば、スムーズな記事の分割ができるように感じました。--Tamago915 2005年1月18日 (火) 09:44 (UTC)

管理者への依頼というのは文字通り管理者に直接依頼することであって、Wikipedia:履歴複製依頼とは異なります。後者は前者を行うためのメモに過ぎません。また XML インポートは当分（下手すれば永久に）導入されないだろうという話もちらほらありますので、過剰な期待は持たないほうがよろしいかと思います。--Lem 2005年1月18日 (火) 10:43 (UTC)

本題とはずれてきますが、投稿時の注意書き（「投稿する前に以下を確認してください」）の部分に、Wikipedia:記事の分割と統合へのリンクを張って GFDL に反した分割を行わないように促せば、いくらかの効果はあるのではないでしょうか。--Tamago915 2005年1月18日 (火) 09:44 (UTC)

これも本題とはずれると思うのですが、クライアント側でなくサーバー側でコピーする方法だけならありますね。{{subst::複写される記事名}}だけを新しい記事に書くことです（コロンが２つです）。要約欄にも同じように{{subst::[[複写される記事名]]}}のように書けば、どう複写したのかわかりやすいですよね。--っ 2005年1月18日 (火) 15:57 (UTC)

で、↑やこのノートの記事にあるような、履歴を記録する手順で分割作業してもよいものなのでしょうか。いくつかやりたいのがありますので。Ribbon 2005年1月23日 (日) 12:01 (UTC)

単なる茶々入れですが、っ さんのおっしゃる方法は記事を展開して張り付けるだけですから、解説ページにあるように全文コピペする方法と基本的に何も変わりません。変わらないどころか、バグなのか仕様なのか、どうやら <nowiki> や <gallery&gt といったタグ（他にもあるかもしれませんが）は subst で破壊される（サンドボックスの初期化をしようとして気づいたことです）ようなので、汎用性がありません。 --Lem 2005年1月27日 (木) 08:31 (UTC)

確かにそうです。他にも、<math>とか、いろいろありますね。「/」を含む記事名へのリンクも、ヘンテコになります。バグなのでしょうけれど。あと、絶対的な欠点として、{{subst::○○}}を実行したのと同じ「分」に、○○の記事が編集されると、履歴を見ても○○の編集前のものが読み込まれたのか、後のが読み込まれたのか、判断が付きません。やめといたほうが良さそうです。--っ 2005年1月27日 (木) 08:48 (UTC)

下のような順番でもよいのかどうか。

1. 記事甲を記事丙に移動する。
2. 記事丙を記事乙に複製する。（複製の際、不要な部分は複製しない）
3. 記事乙・記事丙のそれぞれについて、不要な部分を削除する。

もしくは、管理者以外でもできる方法として

1. 記事甲を記事乙に複製する。（複製の際、不要な部分は複製しない）
2. 記事甲の不要な部分を削除する。（記事分割の場合は分割先を要約欄に書いておく）
3. 記事甲を記事丙に移動する。（移動しなくてもよい場合がある）

順番は（履歴統合の場合を含め）どうあれ、GDFLの要件を満たせば問題ない。 --2005年3月20日 (日) 07:11 (UTC)

要約欄に履歴の継承のための記載がないコピペ移動について

分割・統合にかかわらず、コピペ移動したときには要約欄に履歴の継承のための記載をすることになっていますが、実際には Wikipedia:削除依頼 2005年1月#日本の姓の一覧から分割された記事のように、記載のないコピペが見られます。 だからといって、必ずしも削除すればいいと言うものでもないと思うのです。実際には、コピペの後に編集されていたりするのですから。 救う方法はないのでしょうか？ いくつか考えてみました。

1. 「この記事の初版記事は○○からのコピペです」というような内容を要約欄に書いて、空編集する（なにも実際には編集しないでセーブする）。
2. 上の作業をもう少し丁寧に２段階に分ける
   1. 「初版記事にrevert。○○からのコピペです」というような内容を要約欄に書いて、初版記事にrevert
   2. その直前の（実質的に最後の記事）にrevert
3. 技術的に可能なら、コピペ移動前の記事の履歴を新規記事（分割の場合はそのすべて）に統合する。

--っ [Café] [φ] 2005年2月2日 (水) 11:15 (UTC)

Wikipedia‐ノート:著作権に似たような提案があります。私はそういう断り書きをつけることには反対はしないが、わざわざ立案するつもりはないので、発案者の方にまとめてくれるよう依頼しましたが、その後、議論はとまってます。Modeha 2005年2月2日 (水) 13:29 (UTC)

っさんの提案についてですが、1. は実際に試してみると分かりますが、要約欄だけに記載をして本文に全く手を加えない状態では受け付けてもらえません。2. は煩雑であること、何のためにリバートなのかよく理解できないこと、そして最も重要な点ですが、この履歴情報を外部で使用しようとする人を混乱をさせるだけのような気がします。3. はそれが適切な場合もありますが、分割やコピペ移動後すぐの状態（分割やコピペ移動した人以外に創作性のある加筆がない場合）は削除で対処すべきだと思います。救済措置としては、履歴統合の手順案みたいな感じで、要約欄に、救済措置である旨の何らかの印と、履歴情報のどれがどこからの分割かなどを具体的に明示し、本文には コメントアウトで<!-- 分割記録追加-->などを加筆というのではどうでしょうか（コメントアウト部分については次回以降の投稿の際に削除）。--oxhop 2005年2月4日 (金) 13:14 (UTC)

コメント欄に書くべき情報を入れ忘れた場合の対処法として、3月2日付けの投稿履歴のような感じでどうでしょう? 間に他の投稿が入ってしまった場合は、id番号で特定。--oxhop 2005年3月2日 (水) 13:17 (UTC)

この部分は草稿で、まだ効力がないはずなのですが、「要約欄にその旨の記述がないのでGFDL違反」という理由で削除依頼にかけられるケースが続出しています。ほかの場所にも書きましたが、これは(1)GFDLとMediaWikiに整合性がないためにとる緊急避難的な措置であること (2)この記事の手順に従うことによって、GFDL上の問題が解消できるわけではないこと (3)このルールに従わない記事作成をGFDL違反であると断定するものではなく、ほかにもっとよい方法が見つかった場合、そちらを利用する可能性があること を、草案の状態ででも入れておくことを要求します。Modeha 2005年11月1日 (火) 11:37 (UTC)

特に意見もないようなので繰り入れました。Modeha 2005年11月4日 (金) 15:26 (UTC)

つ氏、oxhop氏両氏が考案した案についても、特にどなたからも異議がなさそうなので本文に繰り入れました。ニュアンスがちょっと違うかもしれませんが、そのときは指摘してください。Modeha 2005年11月6日 (日) 11:55 (UTC)

2005年11月6日 (日) 17:01 と2005年11月7日 (月) 02:42に書かれた物がrevertされたようです。「その方法は削除対象です」というのが理由のようですが、実際の所その後の修正で分割前より良くなった物もある文を「規定に従っていない」の理由だけで削除するのはちょっとどうかと思います。そこで、統合依頼にこのようなケースの復帰依頼を認めてはどうでしょうか。つまり

1. 統合依頼に「「甲」の項目は「乙」からの復歴無き分割のため復帰統合」との依頼をする。
2. 可否を問い統合に賛成であれば、「乙」に「履歴無き分割のため[[甲]]に差し戻し」と書いて、最終更新を「甲」に「履歴無き分割作業により「甲」より分割された「乙」 20xx年xx月xx日 xx:xx UTC を統合」と記載して統合する。この場合、「[[乙]] 20xx年xx月xx日 xx:xx UTC 誰々執筆 を統合」のように統合元のリンクを付けません。
3. 分割のままがよい場合、2,の方法で統合した後、正規の方法で「乙」に分割する。
4. 削除した方がよい場合、そのまま削除依頼に出す。

としてはどうでしょうか。こうすれば書いた文が無駄になりませんし、経歴を継承しているのでよいのでは。 --219市115丁223番151号(仮)2005年11月20日 (日) 09:03 (UTC)

履歴統合に関する部分の正式採用

長い間、草案として提示してきましたが、そろそろ正式化したいと思います。ただ、GFDLの解釈との調整が不十分なようですので、今回は、その点に関しては問題がない「履歴統合」の部分のみを合意形成の対象とさせていただきます。 特に大きな変更点は、

1. Wikipedia:ページ名の変更#コピー&ペーストでの移動の修復に記された、管理者が行う手順の変更
   • 履歴ページにおいて履歴統合をした旨を明示させるため
2. Wikipedia:リダイレクトの削除依頼では管理者自身が他者の依頼なしに自己判断で履歴統合を行うことができるか否か明らかでないのを明確化すること--oxhop 2005年2月21日 (月) 11:54 (UTC)
   • 現在、管理者はこれをできると解釈されている方が多いようですが、履歴統合は一度実行すると元に戻せないこと、また、それほど緊急性があるわけではないことから、合意形成までは不要としても、依頼者と統合実行者は別人として慎重を期すようにした方が良いというのが変更の趣旨です。

以上よろしくご検討下さい。--oxhop 2005年2月21日 (月) 11:54 (UTC).

ちょっとだけコメント。うっかり履歴統合した場合でも、部分版の復活機能をうまく使えば復旧できます。めんどくさい作業ですし、どっちがどっちの履歴か切り分けるのも大変なので、慎重を期した方が良いのは確かです。Wikipedia:即時削除の方針#技術的理由での削除の記述は、「項目全体のコピペ移動」に対しては単独判断で履歴統合可能、「複数の項目をコピペ統合」した場合の履歴統合についてはWikipedia:リダイレクトの削除依頼などで合意形成が必要、と解釈していますが、他の人の解釈と違うのかなぁ。―غاز_(Ghaz) 2005年3月25日 (金) 13:45 (UTC)

3月2日に正式化した履歴統合の手順について、管理者業務の実態に適応しないこと、及び、そもそも履歴の錯綜するような履歴統合は、GFDL違反になる（GFDLが要求しているのは、各版の差分）ということで、改訂されましたので、ご報告をさせていただきます。改訂内容は、

1. 履歴が錯綜するような場合は、履歴統合しないこと。
2. 履歴統合をしても、要約欄には履歴統合した旨は明記されない

ということです。

なお、コピペの対処法については、もう一度、議論してみる余地があると思います。--oxhop 2005年6月18日 (土) 14:54 (UTC)

分割後の処置について提案

分割された後の記事に、その分割元の記事とその記事の履歴へのリンクを提供するTemplateがあった方がいいでしょうか。後、分割されたものはすべて元の記事からの履歴複製待ちにするということも提案しておきます。--PiaCarrot 2005年3月30日 (水) 13:10 (UTC)

履歴の複製機能が実装される見込みは当面なさそう、と感じているので項目本文に Template を張ってしまうことには反対しておきます。「'''{{PAGENAME}} の初版は [[{{{1}}}]]（{{{2}}}の版）からの分割によって作成されました。'''----」みたいな Template をノートに貼っておくのは無意味ではない気がするので、貼る労力に見合った効能があると考える方がいらっしゃるなら検討してみてもいいんじゃないかと思います。―غاز_(Ghaz) 2005年3月31日 (木) 14:10 (UTC)

なぜノートになんでしょうか。そこが気になります。

私としては、分割によりできた記事用に貼るTemplateによって「過去版の履歴を複製する必要がある」旨の表示と、その元の記事への履歴を提供できると思います。後、Templateにカテゴリを設定することで、どの記事が履歴複製の必要があるかをリストアップすることができるのではないでしょうか(そしてそこから必要な版を割り出してWikipedia:履歴複製依頼に必要な版を記録、という使い方もできるでしょう)。--PiaCarrot 2005年3月31日 (木) 14:35 (UTC)

いつ解除されるかわからない「履歴複製待ち」掲示で本文が汚れたままになるのがイヤだからです。ぶっちゃけ趣味の問題なので、本文に張った方が良いと言う人が多ければ受け入れます。PiaCarrot さんが想定している使い方は、ノートに Template を貼ることでも同等の効果が得られると思います（なんか考え落としあるかな……？）。―غاز_(Ghaz) 2005年4月2日 (土) 05:01 (UTC)

Template は要らないと思います。--Lem 2005年4月2日 (土) 05:16 (UTC)

私ももしテンプレートを貼るならノートで十分だと思います。編集上の情報はノートでしょう。それ以前に、「分割されたものはすべて元の記事からの履歴複製待ちにする」かどうかのほうが重要では？--っ [Café] [Album] 2005年4月2日 (土) 05:55 (UTC)

統合作業の便のために

現在統合時には末尾に置くようになってますが、全部末尾に置くのは実際に作業するときにやりづらい気がするのですがどうでしょうか?私としては、その統合を行う部分にまず原文を貼って（貼り方については現在あがっている手順の通り）、その次の編集で実際に統合を行うというのでもいいと思います。--PiaCarrot 2005年4月5日 (火) 15:12 (UTC)

72時間ルールに関して

細かい事で申し訳ないのですが、「統合の提案」節に「提案後、72時間経過しても、反対意見や統合後の方針に関する意見がない場合は、次の手順を参考にして統合作業を行なって下さい。」と記述されているのを他のユーザーからの発言で改めて知ったのですが、72時間では少々足りない気がしますし、少数の記事を統合する場合ならまだしも相当数の記事を統合する場合がやはり存在しますので、統合により影響を与える範囲が大きければ大きいほど周知徹底期間は長く取ったほうがいいと私は考えます。修正を提案します。

私個人としてはまずは最低1週間ほど待つのがいいと思っていますので

• 「提案後、1週間以上の十分な時間が経過しても、他の利用者からの明確な反対意見がないもしくは他の利用者との統合に関する議論が起きない場合は、次の手順を参考にして統合作業を行なって下さい。」

という風に考えています（時間以外の部分もいじってしまっていますが変えるべきではないというのであれば時間に関してのみに絞ります）。意見よろしくお願いします。Tekune 2005年5月12日 (木) 03:15 (UTC)

こんな感じでどうでしょうか。でも管理人の裁定って受ける仕組みって無いですね。

「～提案後、1週間以上経過した場合において反対意見や統合後の方針に関する意見その他の議論がない場合は、統合作業へと進んでください。反対意見や議論が出た場合においては、最後の意見・議論が提出されてから1週間以上経過した場合に、統合の決を取ってください。決の取り方は、以下の通りです」

• 削除依頼と同様に、ノート上でコメントを付けて行います。
• コメントをつけるときには以下の書式で書き込んでください。

* （統合） /（存続）/（保留）/（コメント）に続いて意見 --~~~~

統合の決は、取り始めてから1週間を期限とします。過半数が統合を可とする場合は、可決された旨をノートに明記してから、統合作業に進んでください。また、それ以外の場合は、否決された旨をノートに一旦明記してください。なお、削除依頼とは違い、意見または決が提案者だけのものしか無くても有効です。

取り下げの場合は（取り下げ）と書きます。ただし取り下げを表明した場合や、一旦否決された場合でも、それ以降の意見・議論の提出を妨げるものではありません。統合の決は何度でも取れますが、同一の統合依頼に関して重複（同時並行）して取らないでください。なお、最初の提案から3ヶ月以上経過してもなお議論が紛糾する場合は、管理人の裁定を受けて下さい。

--Willpo 2005年5月12日 (木) 04:45 (UTC)--fmt@Willpo 2005年5月12日 (木) 04:48 (UTC)

72時間でよいと思います。1週間と3日間では、なんの違いもありません。統合を元に戻すことはいつでも可能ですし（revertするだけ）むやみに時間をとることもないと思います。問題のある統一ならノートにすぐコメントが書かれます。この72時間ルールは記事名変更のときのルールでもありますので統一した方が良いでしょう。ただし統合依頼に掲示しない統合提案は気がつきにくいので、自分で統合するときも必ず統合依頼リストに掲載するというのが望ましいと思います。--Ligar 2005年5月12日 (木) 08:28 (UTC)

Willpoさんへ。記事を分割・統合する事、あるいはその内容に関してはやはり、基本的には関係ユーザー間でやってもらうのが筋だと思います（管理者も議論に参加しているでしょうがその時はその分野に明るい一般参加者として意見を述べているはずです）。それはさておき、投票よりまずは合意形成を試みるのが先行しますし、私が提案しているのは呼びかけをした後誰からも反応がなかった場合に対してなので…。必要であるならばWikipedia:論争の解決へのリンクを貼ってもいいとは思うのですが。

Ligarさんへ。時間に関しては、ウィキペディアに参加できる時間が限られているユーザーに対してもある程度考慮するべきだと考えます。例えばほぼ毎日Wikiに参加ができているユーザーがいますが、その反面私生活が忙しい等の理由で参加できる時間が限られているユーザーだっているわけで、そういったユーザーが統合が提起されているのを知ったらなにか有意義な意見が出てくるかもしれない、その可能性はゼロではないでしょう。3日間の呼びかけでは気付かなかったけれども1週間ほど待っていたら気付いていたかもしれない、何らかの発言が行われた可能性だってあるわけです。全員が全部の記事を、あるいは自分の分野の記事すべての監視を毎日できているわけではないでしょう。もちろんずっと何らかの意見が出るまで待つと言うわけでもないし、逆に待つという事は告知・予告し続けている事でもあるため、意見が出ない状態で待てば待つほど積極的な反対意見がでない＝実行してもかまわないという判断を取りやすくなります。以上から、72時間では私は少し短いと考えますので、せめて1週間ぐらいというのを提起しています。

次に、revertするだけという考えではいたずらに無駄な履歴を増やす可能性があります。統合先が加筆されていれば単にrevertするだけでは修正が効かなくなる事もありえます。記事に対して大きな影響を与える手段なのですから少しぐらい慎重に行ってもいいのではないかと思います。記事名変更に関しては、こちらの方が移動を元に戻すだけですから原状復帰は容易いとは思いますが、明らかな間違い等ならばともかく同様に慎重にいくべきだと考えます。必要であるならば72時間ルールそれ自体を見直す事が必要かどうか、検討してみます。Tekune 2005年5月13日 (金) 19:23 (UTC)

たしかに1週間待てばチャンスは拡大するでしょう。しかし例えばですが、『ひらけポンキッキ』と『ひらけ!ポンキッキ』という項目が複数たった場合、統合に1週間も時間が必要なのかという疑問があります。--Ligar 2005年5月14日 (土) 13:10 (UTC)

(1)Tekuneさんへ:とりあえず管理者裁定等の制度はなじまないようですねその件は取り下げておきます(2)Wikipedia:ページ名の変更によると、ページ名変更の時の猶予期間は48時間（2日間）のようです。(3)Tekuneさんの言われるとおり、「週末執筆者」の都合もある程度考慮してあげた方がwikipediaのためにもなるんではないでしょうか。(4)Ligarさんの「ポンキッキ」の例ですが、削除の場合は即時削除と言う制度がありますが、即時統合と言う制度は無いようですし、即時統合の条件を「誰が見ても明らかに統合されるべき」としても一般的には判断に窮する気もしますので、結果、即時統合と言う制度はなじまないのではと思います。統合が及ぼすwikipediaへの影響は、一般的には、統合提案に対する意見の多さで推し量るべきだと考えます。他方、統合は提案者1人だけが推進して他の人が気づかないうちに統合されてしまうと言う問題点があると思います--Willpo 2005年5月15日 (日) 16:45 (UTC)

「即時統合」と銘打たれてはいませんが、似たようなスキームは既にありました。「統合すべきでない場合：2つの記事が全く同じ情報しか含んでいない場合→統合するまでもありません。一方をリダイレクトにして下さい。 」の部分です。（これも即時削除みたいなtemplateを貼るようなスキームにするべきか否かは別にして、）、「ポンキッキ」の例については、２つの項目が全く同じ情報しか含んでいない場合には猶予時間が3日でも7日でも関係ない事になりますし、多少でも違う情報が含まれている場合は統合依頼を掲出すべきでしょう。--Willpo 2005年5月16日 (月) 01:41 (UTC)

結局、「ノートで提案したもののなんの返事もない場合、消極的合意とみなすにはどのくらいの時間が必要か」という問題ですね。Wikipedia:ページ名の変更では48時間、Wikipedia:記事の分割と統合では72時間でバラバラですが、72時間か1週間かに統一したほうが良いような気がします。投票してはどうでしょうか。--Ligar 2005年5月16日 (月) 03:01 (UTC)

統合の対象となる記事の数に比例して、いわゆる提案した後「待つ」期間を長く取ってもらいたいというのが私の考えなのですが、2つの記事を統合しようとする場合など、少数の記事が対象だったりすればそれほど長く時間をとらなくてもいいのかもしれません（記事の主題が相当大きいもの2つをさっさと統合されるというのはさすがによくないですが）。

では、文面の案を修正して

• 「提案後、72時間から1週間程度の十分な時間が経過しても、他の利用者からの明確な反対意見がないもしくは他の利用者との統合に関する議論が起きない場合は、次の手順を参考にして統合作業を行なって下さい（統合する記事の数が多いほど周知徹底のための期間は長く取るのが望ましいでしょう）。」

というのではいかがでしょう。Tekune 2005年5月16日 (月) 04:42 (UTC)

いいんじゃないでしょうか--Ligar 2005年5月17日 (火) 01:15 (UTC)

修正しました。Tekune 2005年5月27日 (金) 02:43 (UTC)

一番町の分割について

一番町という項目の分割について質問があります。現状では履歴がたどれる状態なのか判断できません。表ページにはある項目をAとBに分割する方法が書かれています。今回のようにある項目をAとBに分け、元の項目を曖昧さ回避にした場合の手順については読み取れませんでした。このような場合の正しい手順について教えていただければ幸いです。61.115.201.81 2005年6月22日 (水) 09:37 (UTC)