Wikipedia:村のポンプ (提案)/アーカイブ 184

テンプレートで ECP を使用する必要がありますか?

以下のディスカッションは、コメント要求のアーカイブされた記録です改造しないでください。 このディスカッションをこれ以上編集しないでください。 到達した結論の要約は次のとおりです。
この提案には(ほぼ満場一致の)コンセンサスがありますそして、ここ 1 週間ほどでコメントが散発的にしか入ってこないことから、WP:SNOWも当てはまることは明らかです。RandomCanadian (トーク/投稿) 2021 年 9 月 3 日 22:42 (UTC)


管理者は高リスクのテンプレート に拡張確認済み保護を適用することを許可されるべきですか? 03:59、2021 年 8 月 17 日 (UTC)

Wikipedia:管理者の掲示板から移動§ TemplateProtector ボットが更新されました。テンプレートで ECP を使用する必要がありますか?
 – Wug・a・po・des 2021年8月17日20:45

8 月 16 日のインシデント(固定リンク)、およびその後いくつかのプラットフォームで受信した pingに対応して、 User:MusikBot II/TemplateProtectorの動作を変更し、設定に基づいて保護レベルを引き上げました今日まで、ボットは完全に保護されていないテンプレートのみを検索していました。以前はこれは主にパフォーマンスのために必要でしたが、今では問題ではないと思います。今日の出来事を受けて、この追加の自動化レイヤーの必要性が認識されることを願っています。

とはいえ、ボットを実行する前に、影響を受けるページの完全なリストをじっくりと確認しました。保護が変更されたものについては、私はかなり自信を持っています。以前の編集者がほとんどまたはまったく編集できないこと、またはコンテンツがほとんど変更されないこと (つまり、リダイレクト) を確認しました。いくつかの異常値については、 WP:IAR を少し使用し以前の編集者が引き続き貢献できるように、拡張確認済み保護を適用しました。他のいくつかはボットの除外リストに追加したので、永久に無視されます。

そこで次の質問になりますが、テンプレートでの ECP のプリエンプティブな使用を許可すべきでしょうか? 現在、ポリシーでは、まだ発生していない混乱に対する予防策として拡張確認済み保護を使用すべきではないと述べています私もこの意見に全面的に同意しますが、大規模な混乱を引き起こしやすいテンプレートやモジュールの場合は明らかに状況が異なります。テンプレートを取得:オーストラリアの政治/政党の色例として。経験豊富なユーザーによって定期的に編集されます。すべて拡張が確認されていますが、どれもテンプレート エディターではなく、おそらくこのようなテンプレートを編集するためだけのエディターにはならないでしょう。一方、トランスクルージョンは本質的に政治的なものであるため、標的を絞った破壊行為のリスクが高くなります。したがって、拡張確認は非常に良い妥協案のように思えます。そのため、このケースではこれを適用しました (そうでなければボットはテンプレート保護に移行したでしょう)。

プリエンプティブな目的で ECP の使用を正式に許可する場合は、自動確認 (現状) で 500 を超えるトランスクルージョン、次に拡張確認で 5000 を超えるトランスクルージョン、そしておそらくテンプレート エディターで 8000 ~ 10000 を超えるようにボット構成を変更することをお勧めします (現時点では) >5000 に設定します)。ECP を考慮すれば、破壊行為の可能性はかなり排除されるはずだと私の意見ではあります。ただし、私の知る限り、2019 年 2 月以降、ボットがテンプレート保護を適用した後に誰かがテンプレート保護を解除したケースが数件あったことは言及する価値があります。つまり、テンプレート エディターには 5000 が妥当であることがわかり、その場合は ECP を 3000 程度に設定することになります。ただし、まず ECP を使用することに同意する必要があります:)

考えは?このトピックに関する以前の議論は、元のボット提案に記載されています。よろしくお願いします。MusikAnimal talk 02:38、2021 年 8 月 17 日 (UTC)

  • 特に技術的なものよりもコンテンツ指向のテンプレートの場合、これが合理的な妥協策であることに私は同意します。また、一部の非常に可視性の高いコンテンツ指向のテンプレートについて、ロジックをカバーする TPE で保護されたテンプレートと、コンテンツをカバーする XCP で保護されたサブテンプレートに分割することの実行可能性にも興味があります (おそらく、サニタイズするための仲介 Lua モジュールを使用します) CSS 破壊行為の可能性)。しかし、それは単なる問題です。-- Tamzin [鯨類が必要] (彼女/彼ら) 2021 年 8 月 17 日 03:43 (UTC)
  • 私もこれが理にかなっているということに同意します。HighInBC 助けが必要ですか? ちょっと聞いてください。03:59、2021 年 8 月 17 日 (UTC)
  • すべての作業に感謝し、プリエンプティブ ECP をサポートします。おそらく、特定のカテゴリのテンプレート/モジュールに対して半保護のみを許可する除外方法が必要ですが、トランスリュージョン数があるしきい値を超えている場合、除外は無視されます。しきい値として提案された数値が高すぎます。1 つの不満によって 3,000 件の記事が簡単に損なわれることは望ましくありません。Johnuniq (トーク) 04:04、17 8月 2021 (UTC)
  • MusikAnimal さん、ご尽力いただきありがとうございます。私もECPを支持しますが、閾値が高すぎるという Johnuniq の意見に同意します。2018 RfC200 ~ 250 を超えるとセミプロテクトにするというコンセンサスが得られたので、それをより良いカットオフとして提案します。私たち人間は、大きな数字が何を意味するのかを理解するのが苦手だとよく思います。そこで、次のような見方ができます。未承認の編集者または IP 編集者が、一連のページに対して 500 件の同様の編集を急速に行うことを決定した場合、私たちはどう感じるでしょうか? たとえ彼らが誠意を持って言ったとしても、反応は(理想的には友好的なバージョンの)「まあ、少しゆっくりして、そんなに重要なことをする前に、このあたりのことをよく知るために少し時間を取ってください」になると思います。これは、500 個のトランスクルージョンを含むテンプレートの編集と完全に類似しているわけではありません。後者は元に戻すのがより簡単であるためです。ただし、それでも、同じ影響について話しているので、中断を防ぐために同様のレベルの制限が必要です。{{u| SDKB }}トーク04:41、2021 年 8 月 17 日 (UTC)
  • 私はこれらの措置を支持しますが、3,000 人の閾値は引き下げられるべきだとも感じています。Schwede 66 04:56、2021 年 8 月 17 日 (UTC)
  • はい、絶対にここには重大な欠点は見当たりません。TP を使用したくないページがある場合、これは良い妥協策です。上記の Schwede66 と同様に、私はしきい値を下げることを支持します。ヴァナモンデ(トーク) 06:26、17 8月 2021 (UTC)
  • 4 桁の範囲内で適切と思われるしきい値でプリエンプティブ ECP をサポートします。ECP は広く利用できるため、これが更新の大きな妨げになることはありません。このような変更により、テンプレートで保護されたしきい値の増加が可能になるのであれば、それが完全に独占的な権利のままであれば、それはより良いことです。CMD (トーク) 09:33、2021 年 8 月 17 日 (UTC)
  • はい; ECP のしきい値をもう少し低く、>1500 程度に設定することもできます。MusikAnimalさん、お疲れ様でした。レクトナー(トーク) 10:02、2021 年 8 月 17 日 (UTC)
  • いいえ、ここでは正当な理由 (EC がテンプレート作成能力とあまり相関しないなど) で EC の使用を禁止する RfC がありました。Wikipedia:コメントのリクエスト/拡張確認された保護ポリシー 2少なくとも、AN の議論ではなく、これに関して別の RfC が必要です。EC のしきい値はとにかくばかげており、EC が全面的に適用されるトピック分野では法外すぎるProcrastinatingReader (トーク) 10:11、17 August 2021 (UTC)
    • また、EC 以外の TE も、「可視性が低い」テンプレートを編集するために EC を必要とするのでしょうか?
      WP:PERM で EC が許可され、編集数が 500 未満の編集者がこれらのテンプレートのいずれかを編集する必要がある場合にパーマをリクエストできるようになれば、この提案にさらに満足します。ProcrastinatingReader (トーク) 10:27、17 August 2021 (UTC)
      「EC はテンプレート作成能力と相関関係がよくありません。」 - 問題はテンプレート作成能力との相関関係ではありません。昨日のエピソードで証明されたように、一部の破壊者は非常に熟練しています。重要なのは、EC が Wiki への一般的な投資と何らかの相関関係があるということです。カバイ(トーク) 10:33、2021 年 8 月 17 日 (UTC)
      それは上を行きます。すべての破壊者を排除することは十分可能ですが、正規の編集者も排除します。一人の編集者がナチスのシンボルを追加したからといって、それを生産的に編集している何千人もの編集者を頭ごなしに止めるべきではありません。WP:PERM でリクエストしてもらいます。ProcrastinatingReader (トーク) 10:35、17 August 2021 (UTC)
      これに締め出されて噛まれる編集者の実例を見て​​みたいと思います。一般的なルールとして、在職期間が 30 日未満で編集回数が 500 回未満の人は、記事を書くかコンテンツを改善することだけに興味があります。テンプレートのバックエンド作業は、ある程度の知識を持った経験豊富な編集者のみが興味を持ちます。Ritchie333 (トーク) (続き) 2021 年 8 月 17 日 10:42 (UTC)
      実際にはそのようなロードマップはありません。荒らし対策のみを行う編集者、テンプレートのみを作成する編集者、コンテンツのみを作成する編集者、それらすべてを組み合わせて実行する編集者もいます。これらの各グループに属する編集者を誰もが思い浮かべることができると思います。実際に編集を開始する前にアカウントを登録していなければ、これで締め出されていたでしょう。登録がもう少し遅かったら、もっと荒らしにならなかったでしょうか?
      また、これは私が今思いついただけです... このナチスの問題を解決する 2 つのことは次の 2 つです: 1) 保護ボットがすでに保護されているページをスキップしないこと。これは重要です。2) MusikAnimal フィルターへの変更が適用されました。これら 2 つのことはすでに行われています。この3 番目の変更が何を妨げているのかは明らかではありません現在の構成の TE 保護は >5000 です。これを 8000 ~ 10000 に変更し、5000 を超える場合は ECP を実行することを提案しています。それで...私たちは、より多くの編集者が保護を通じて編集できるようにすることを提案していますか? ProcrastinatingReader (トーク) 11:05、2021 年 8 月 17 日 (UTC)
      リッチーさんの意見に同意。さらに、テンプレートを直接編集できない人でも、トーク ページでいつでも編集リクエストを行うことができます。ソース表示ページからこれを行うのは難しくありません (そして、難しいと感じる人がいるとしたら...その人はまだテンプレートを編集する準備ができていない可能性があります)。{{u| Sdkb }}トーク11:06、2021 年 8 月 17 日 (UTC)
      TE パーマをかける前は、編集リクエストをしなければならないのがかなりイライラしたことを覚えています。より複雑なものは、レビューされるまでに時間がかかるか、レビューされないだけです。コードが機能し、コンセンサスを適切に表現しているかどうかは他の誰か (おそらくテンプレートに詳しくない人) が責任を負わなければならず、レビューするだけでも非常に時間がかかります。彼ら。より多くの編集者がパーマネントを持っているため、ECP の場合はそれほどではないのではないかと思いますが、同時に ECP 編集者の一部のみがテンプレート編集リクエストをレビューします (おそらく TE と同じサブセットであるため、同様の数字)。承認したくないが元に戻すことはできないさまざまな変更もありますが、それらはすべて漸進的な改善です。ProcrastinatingReader (トーク) 11:21、17 August 2021 (UTC)
      ProcrastinatingReaderも、EC 以外の TE は、「可視性の低い」テンプレートを編集するために EC を必要とします正直なところ、延長確定前に誰かがTPEを受けるケースは考えられません。ホタル( tc ) 2021 年 8 月 17 日 11:24 (UTC)
      ファイアフライ、まあ、禁止された編集者の靴下がそれを試してみたいと思うかもしれないけど、できれば見つけられるといいな。:-) Ritchie333 (トーク) (続き) 2021 年 8 月 17 日 11:52 (UTC)
      Ritchie333 さん、確かに、人々がそれを要求するかもしれないことは理解できますが、あなたの言うように、例外的な状況がなければ実際に許可されるとは思えません。ホタル ( tc ) 2021年8月17日 13:18 (UTC)
      @ ProcrastinatingReader明確にするために、WP:PERM/ECで EC をリクエストできます。また、これはテンプレートの作成能力に関するものではなく、非常に目立つテンプレートを中断から守るためのものであることにも注意してください。これらのテンプレートの多くはテンプレート編集スキルをまったく必要としませんが、意図的な破壊行為は広範囲に影響を及ぼします。現在、準保護からテンプレート保護に移行していますが、これはかなり大きなジャンプです。間に中間があればいいですね。2016 年の RfC は、これまでに発生した多くのテンプレート荒らしの波よりも前のものでもあります。そこで提起された点が今日では価値があるとは信じていません。そのため、私を含む多くの管理者は、そうする必要がある場合にテンプレートで ECP を使用し続けてきました (トランスクルージョンの数が多いですが、通常の編集者は TE ではありません)。私には別の RfC を行うための時間もエネルギーもありません。そのため、それが必要だと感じた場合は、他の誰かがその取り組みの先頭に立たなければなりません。音楽アニマル トーク2021 年 8 月 17 日 15:37 (UTC)
      ユーザーは代替アカウントに対してそれをリクエストできます。他のリクエストはすべて拒否されます。だから、それはあまり重要ではないと思います。私の理解では、ボットに加えた変更により、このナチスの問題は 55,000 件のトランスクルージョンがあるため、回避できたはずです。そのため、問題がすでにパッチされている場合、さらに多くの先制保護層を設ける必要はないと思います。他の唯一の合理的なアイデアは、自動保護に加えて、現実的に変更する必要のない単純なテンプレートを TE が保護することです。(例: Template:Wbrの仮説的な 1k トランスクルージョンのバリアント。) しかし、EC がテンプレート空間で意味のあるものを基本的に保護するのはやりすぎのように思えます。ProcrastinatingReader (トーク) 15:46、17 August 2021 (UTC)
      WP:PERM/ECのバナーは、まれな状況で非 alt アカウントにパーマを許可するための扉を開いたままにします。たとえそうでなかったとしても、WP:IAR はそうします。EC 以外の編集者が ECP テンプレートの編集を開始することが百科事典にとって明らかに利益となる状況があった場合、その編集者に許可を与えることは標準的な管理裁量の範囲内となります。私は、複数の管理者から功績を理由に EC を勧められ、断った新規ユーザーを少なくとも 1 人知っています。(ずっと前の 2012 年、私は 3 日のマークで承認され、13 日のマークでロールバックされました。おそらくもうそんなことは起こらないでしょう。) -- Tamzin [鯨類が必要] (彼女/彼ら) 18:00 、2021 年 8 月 17 日 (UTC)
      @ Tamzin :非 EC 編集者による成功した EC リクエスト (EC alt がなく、システムのゲーム用に最初にプルされた後に ECP が付与されたケースではない) をリンクしてもらえますか? 理想的にはここ 1 ~ 2 年以内です。ProcrastinatingReader (トーク) 18:15、17 August 2021 (UTC)
      数か月前を振り返ってみても何も見えませんが、それが私の言いたいことではありません。私が言いたいのは、これはポリシーによって許可されており、誠実な新規ユーザーが ECP 化されたテンプレートに対する編集リクエストをシステムに大量に送り始めるシナリオでは、どの管理者もそのビットを付与する権限を持っているということです。ただ、それが起こる可能性はかなり低いシナリオです。一方、ECP の現在のユースケースでは、特に IIRC が通常は適格ではない編集者に ECP を付与しても、その編集者が DS から免除されるわけではないため、ニーズに基づいてビットを付与する理由を考えるのは困難です。 /GS 30/500 制裁。-- Tamzin [鯨類が必要] (彼女/彼ら) 2021 年 8 月 17 日 18:34 (UTC)
      @ ProcrastinatingReader :ログを詳しく調べるつもりはありませんが、ECP を早期に配布したことはほとんどありません。これは、別のプロジェクトの確立された編集者がここでコンテンツの翻訳を行おうとしていたことに関連していると思います。これは、現在は避けるよう特別な注意を払う必要がある 500/30 arbcom の救済策を無効にするものではないことを強く思い出させるものでした。xaosflux トーク19:00、2021 年 8 月 17 日 (UTC)
  • より重要な決定は、すでに保護されているテンプレートをボットに再評価させることです。TE 保護のしきい値の最大 10 倍に達したテンプレートの半保護は、重大な危険信号です(装飾なし)カバイ(トーク) 10:24、2021 年 8 月 17 日 (UTC)
  • ProcrastinatingReader が提起したすべての理由から反対します。しかし、私はカバイ氏のアイデアは良いものだと思います。ジョジョ・エウメルス(トーク) 10:31、17 August 2021 (UTC)
  • セキュリティ上の理由からプリエンプティブな使用を増やすことをサポートし、編集者が一般的にテンプレート編集の実践にもっと関与することを奨励します。ここでは説明しませんが、逆に懸念されるのは、いくつかの人気のあるページに追加される、軽くトランスクルージョンされたテンプレートですが、それに関するポリシーの変更はありません。シュシュガ (彼/彼 • 話す) 2021 年 8 月 17 日 10:30 (UTC)
  • コメント: 昨日の混乱が実際にどれくらい続いたか知っている人はいますか? 問題の大部分は、テンプレート上での破壊行為は 5 分以内に取り消すことができますが、キャッシュ上の理由から、そのテンプレートがトランスクルージョンされているすべてのページにすぐには伝播しない可能性があることだと思われます。誰でもページを手動でパージできますが、特定のカテゴリまたはリスト (ここではトランスクルージョンのリスト) 内のすべてのページを自動的にパージするツールはありますか? そうでない場合、作成することはできますか、それともサービス拒否攻撃にさらされる可能性がありますか?
    このような破壊行為が 5 分以内に取り消せるのであれば、私はおそらく厳重さの強化に反対するでしょうが、昨日の繰り返しを止める他に方法がないのであれば、おそらく支持するでしょう。この攻撃を阻止するために必要なのは、MusikBox の昇格修正 (私は完全にサポートしています) だけであることに注意してください。Bilorv (トーク) 15:39、2021 年 8 月 17 日 (UTC)
    はい、User:ProcBot/PurgeListです。しかし、ソフトウェアのジョブキューは通常のページパージを非常に迅速/即時に実行すると確信しています。時間がかかるのは特定のタイプだけです(それらのタイプはここでは適用されません)。ProcrastinatingReader (トーク) 15:48、17 August 2021 (UTC)
    さて、昨日の破壊行為は本当にほんの数分程度 (5? 10? 20?) で終わったのでしょうか? また、ただの吐き出しですが、この荒らしの目的、つまり閲覧数の多いページに損害を与えることの根本原因に迫るボット保護の方法を誰かが考えたことがありますか? 破壊者は、1 日あたりのビュー数が 50,000 未満の非メインスペース ページでこれを行うことはないと思います。メイン ページに使用しているようなカスケード保護を低スケールで、先月閲覧数が X 件を超えたものにボットによって適用することもできます。実現可能性に興味があるだけです。Bilorv (トーク) 16:06、2021 年 8 月 17 日 (UTC)
    クソ磁石、どうやって動くの?El_C 2021 年 8 月 17 日 22:49 (UTC)
    @ Bilorv :変更が元に戻された後、1 分以内にページに反映されたのではないかと思います(私のボットが 55,000 ページをパージするには 1 分かかります。現時点ではジョブ キューにバックログはありません。統計が正確であれば、バックログになることはほとんどありません。) あなたのアイデアに関しては、それは実現可能に思えます。考えられる 1 つのアプローチ: WMF は、使用できるこのデータ ダンプを提供します。これを使用すると、X ページビューを超える各ページで使用されているテンプレートを一括フェッチし、すべてを合計することができます。ProcrastinatingReader (トーク) 14:07、2021 年 8 月 18 日 (UTC)
    はい、ビロルフ、修正するのに5分かかりました(ボールを持っていた人たちはよくやった)。また、 WP:VRTへの 15 通以上の電子メール、少なくとも 1 件の報道機関からの問い合わせ (私が見て対応したものだけを数えています)、2 件以上の報道、そしてウィキペディアへの風評被害もありました。5分間の努力の損失は最小限のダメージでした。カバイ(トーク) 09:51、18 8月 2021 (UTC)
  • サポートいいですね、MusikAnimalボットには必ず特別なおやつを与えてください。El_C 17:06、2021 年 8 月 17 日 (UTC)
  • 保護ポリシーの更新は、適切な場所で宣伝されているWP:RFCに対するアクションです。WP:AN はその場所ではありません。-- Izno (トーク) 2021 年 8 月 17 日 19:19 (UTC)
  • サポート、そして私は率直に言って、これがまだ行われていなかったことに驚いています。これが新しいテンプレート編集者にどのような影響を与えるかについての議論は説得力がありません。辛抱強く続ければ、500 件の編集を得ることができます。それは厳しくない!さらに、読者と対象者 (特に BLP ページ) への危害を最小限に抑えるためにできる限りのことを行う必要があります。BLP の誰かがナチスであると「偶然に」示唆することは、私たちが越えるべきではない明るい一線であるか、あるいはそれを越えるために使用できる道路さえ提供しているように思えます。ヨルム(トーク) 19:33、17 August 2021 (UTC)
  • サポート使用されているテンプレートの数が少ないテンプレートでこれを行っていたら、おそらくもっと長く捕まらなかっただろう。これは、積極的に直接貢献できる人がいるにもかかわらず、短期間は編集リクエストをしなければならないことを意味していると思いますが、それは多くの記事に当てはまり、それらは単一の記事です。—valeee (トーク) 2021 年 8 月 17 日 21:11 (UTC)
  • マウスを数回クリックするだけで最も閲覧数の多い何千ものページを破壊することを困難にする合理的なアクションをサポートします。保護されていないテンプレートが膨大な数の非常に顕著なページ、特に BLP にトランスクルージョンされているため、大規模な破壊行為が驚くほど簡単かつ一般的になります。-天体恐怖症(トーク) 2021 年 8 月 17 日 21:31 (UTC)
  • これをサポートするのは理にかなっています。また、ECP のしきい値を 3000 ページ (またはさらに低い値) に下げることもサポートされています。 ジェイク・ウォーテンバーグ(トーク) 2021 年 8 月 17 日 21:38 (UTC)
  • 「サポート」テンプレートは非常に目立つため、破壊行為、テスト編集、テンプレートの仕組みやコード、またはフォーマットの理解不足の影響が大きくなります。この理由により、私はより低いしきい値をサポートします。たとえば、自動確認のトランスクルージョン > 100、EC の場合 > 250、TE の場合 > 1000。トム (LT) (トーク) 2021 年 8 月 17 日 22:00 (UTC)
  • サポート高リスクのテンプレートに関する当社の長年のポリシー(ガイドラインのタグにもかかわらずポリシーです) は、EC ポリシーよりもはるかに古いものです。私はこれらに対して正確なしきい値を指定するのは好きではありませんが、必要に応じて高リスクのテンプレートに EC を使用する必要がありますか? もちろん。-- zzuuzz (会話) 2021年8月17日 22:18 (UTC)
  • ECP として分類するかどうかに関係なく、保護をサポートします。「高リスク」に関しては、DYK の推薦などの編集を許可するホワイトリストを使用して、テンプレートの名前空間をデフォルトで保護する必要があるとまで言いたいと思います。新しいユーザーが、保護された編集リクエストを通じて処理されないほど、テンプレートに対して有意義で積極的な貢献を行っているのを見たことがありますか? シャクナゲの \\ 2021 年 8 月 17 日 22:35 (UTC)
    • ああ、たくさん。一部のテンプレートは、ほぼ完全にアノンによって維持されています。特にスポーツ テンプレートだけでなく、他の多くのタイプも同様です。それによって生じるであろう膨大なバックログとコンテンツ不足を理解するために、最近の変更を見てみましょう。-- zzuuzz (会話) 2021年8月17日 22:46 (UTC)
      テンプレート スペース全体を保護することは重要な変更であり、スポーツ シーズンの順位などのテンプレートが新しい編集者または未登録の編集者によって生産的に更新されることは珍しいことではないことに同意します。さらに、任意の名前空間からのトランスクルージョンが許可されているため、編集者はさらに多くのテンプレートをプロジェクト空間に配置し始めるだけです。isaacl (トーク) 2021 年 8 月 17 日 23:14 (UTC)
      EC 以外の編集者によってテンプレートに追加される新しい画像を監視する編集フィルターを用意する価値があるかもしれません。名前空間全体へのアクセスを制限できない場合でも、少なくとも監視を容易にすることはできます。これをWP:EFNに実行しますWug・a・po・des 00: 30、2021 年 8 月 18 日 (UTC)
      リンクありがとうございます。彼らは私が注目しているどのトピック分野にも属していないだけだと思います。シャクナゲの \\ 2021 年 8 月 18 日 19:02 (UTC)
  • 特に、テンプレート保護が生産的なリビジョンに不当に干渉する可能性がある{{カラー トピック}} のようなコンテンツ テンプレートをサポートします。このテンプレートにはメインスペースに 233 のトランスクルージョンがあり、Tom (LT) が提案した EC カットオフのすぐ手前にあります。ランドリーピザ03 ( d ) 01:16、2021 年 8 月 18 日 (UTC)
  • サポートの理由は非常に多く、それらを列挙すると丸一日かかるほどです。ただし、テンプレート編集者の権限で ECP で保護されたテンプレートの編集が許可されていることを確認することは価値があります。これが保証される場合、まれに例外が発生する場合があります。リスク者(トーク) 02:42、2021 年 8 月 18 日 (UTC)
  • サポートこれは、完全な保護をより広範に使用するための唯一の実行可能な代替手段です。ただし、管理者は EC を許可できることを思い出させる必要があると思います。ここで見るまで忘れていました。DGG (トーク) 03:24、18 8月 2021 (UTC)
  • 自動確認以上、テンプレート エディター未満の保護を備えたテンプレートが明らかに必要であるため、サポートします。「拡張確認済み保護は、まだ発生していない中断に対する先制手段として使用すべきではない」という文言をECP ポリシー ページから削除する必要があります。ユーザー:力(power~enwiki, π , ν ) 03:54、2021 年 8 月 18 日 (UTC)
  • サポート- 半保護と TPE 保護の間の非常に合理的な妥協点として (更新される一部のコンテンツ テンプレートに障壁が課されると思われます)。また、パフォーマンスの問題が解消されたことを考慮して、MusikBot II ではトランスクルージョン数の増加に応じて保護レベルが上がるようになったことを非常にうれしく思います。素晴らしい仕事でした MusikAnimal :) firefly ( t · c ) 06:24、18 8月 2021 (UTC)
  • サポート私はこれを長年支持しており、正規ユーザーへの被害を最小限に抑えながら、テンプレートの破壊行為を減らすのに大きな効果があると信じています。-- Trialpears (トーク) 08:39、18 8月 2021 (UTC)
  • テンプレートを保護するための追加レベルとして ECP の導入をサポートします。TE 保護のしきい値の引き上げに反対します。以前に評価したテンプレートを再評価するボットをサポートします。ボットが保護の手動調整を尊重する必要があることに注意して、保護レベルが標準と同期していないことをどこかでフラグを立てる (調整している管理者に ping する) ことが望ましいでしょう。また、多くの機密テンプレートが置き換えられており、トランスクルージョンの数がすべてではないことにも注意してください。カバイ(トーク) 09:57、18 8月 2021 (UTC)
  • 上記のサポート。―  Qwerfjklトーク2021 年 8 月 18 日 10:06 (UTC)
  • 上記のサポートを積み上げてください。 -- John Cline (トーク) 13:21、18 2021 (UTC)
  • 反対- 気づくと遅くなってもう雪が降っています、でも聞いてください。ECP はゲーム可能な保護レベルです。これをゲーム化するには、より献身的な破壊者が必要ですが、SPI での私の経験から、それはセミレベルよりもほとんど抑止力がないと信頼できます。テンプレートを使用すると、その見返りとして、あなたの破壊行為がおそらく数万のサイトに即座に表示されます。記事を一気に。さらに、あなたが引き起こした混乱は、3日後もANIの苦情を引き起こし、この提案のような深刻な反応を引き起こし、広範囲に影響を及ぼします。500 件の無意味な編集 (または 1 つの編集と、数日間で 499 回クリックして元に戻すスクリプト) と 30 日間の保留 (カレンダーにリマインダーを設定) と引き換えに、これは最近のナチスにとってはかなり甘い取引だったでしょう。破壊者。一方、テンプレート保護は、リスクの高いテンプレートをコミュニティの他のメンバーによって精査された編集者のみに保護します。これはゲームとしてははるかに難しいプロセスです。テンプレートの破壊行為が広範な問題になりつつある場合 (すでにかなり前から問題になっていると思います)、記事スペースに表示されるテンプレートに対して何らかの形式で保留中の変更を保護することを検討する必要があります。Ivanvector のリス(/木の実) 2021 年 8 月 18 日 13:55 (UTC)
    • 私の理解が正しければ (決して当然ではありません!)、この提案はテンプレートで ECP を許可するかどうかであり、具体的なレベルは後で決定されます。提案を読み直してみると、示されている例は確かに一部のテンプレートの保護を低下させることになるようですが、これが正式に提案された場合は私は反対するでしょう。おそらく、現在のしきい値を維持し、ECP のトランスクルージョン 2500 で別のしきい値を挿入することをお勧めします。MusikAnimal - 考えていますか? :)ホタル ( t · c ) 2021 年 8 月 18 日 14:45 (UTC)
      はい、しきい値の調整については別の議論で決定します (RfC は必要ないと思います)。いずれにせよ、ボットが ECP を使用しない場合でも、プリエンプティブな方法での ECP の使用をポリシーに記載してもらいたいと考えています。上で述べたように、通常のテンプレート エディターの保護ではすべての編集者がシャットアウトされてしまうことを考えると、 Template:Australian の政治/政党の色はその代表的な例です。MusikAnimal talk 16:13、2021 年 8 月 18 日 (UTC)
      • 同意しました、そして私もそう思っていました。ありがとう!ホタル ( tc ) 2021年8月18日 16:46 (UTC)
  • サポート現在の 2 つのオプションは基本的に「全員が編集できる」と「管理者とごく少数のユーザーのみが編集できる」であるため、ここで別のレベルの保護を利用できるようにするのが賢明であると思われます。はい、もちろん EC パーミッションを利用してゲームを行うことは可能ですが、よりゲームしやすいパーミッションに制限することが正しい解決策であるとは思えません。192.76.8.74 (トーク) 2021 年 8 月 18 日 21:28 (UTC)
  • サポートこれは、特に昨日見た大規模な破壊行為を防ぐのに役立つのであれば、合理的だと思われます。クローバーモス (トーク) 2021年8月18日 22:29 (UTC)
  • 完全に合理的な提案を支持してください。 -- Jezebel のPonyo bons mots 2021 年 8 月 19 日 16:38 (UTC)
  • サポートこの提案により、テンプレートの破壊行為をなくすことはできませんが、それを減らすことができる可能性があります。そして、涅槃の誤謬に従って、破壊行為を減らすものであれば、それでもやる価値があります。—  Shibboleth ink ( ) 2021 年 8 月 22 日 15:31 (UTC)
  • 中間ステップとして ECP を追加することは支持しますが、 TEP のトランスクルージョンしきい値 5000 の引き上げには反対します。頻繁に使用されるテンプレートの保護レベルを下げるよりも、上記で提案されている 250/2500/5000 のようなものが合理的だと思います。--アヘクト(トーク
    ページ
    ) 2021 年 8 月 23 日 21:30 (UTC)
  • サポート10 件の編集を行って 4 日間待ちますか? 簡単。500 回の編集を行って 30 日も待つ必要があるでしょうか? それほど多くはありません。🐔 チクダット・  ボーク、私に!2021 年 8 月 24 日、10:31 (UTC)
  • 支持— Ivanvector の反対については、テンプレート保護のしきい値を下げる代わりに、これは主に、現在は半保護されているが、延長確認された保護を保証するのに十分な高リスクのテンプレートに使用されるべきだと思います。Tol (トーク|投稿) @ 20:25、2021 年 9 月 1 日 (UTC)
  • 特定のトランスクルージョン数を伴うサポート、または物議を醸すトピックや人気のあるトピックにテンプレートが表示されるなど、リスクが高いサポート。クラウチ、スウェール(トーク) 20:51、3 September 2021 (UTC)
    サポート: 使用頻度が高くないデッドゾーンにあるテンプレートの別のオプションとして役立つ可能性があります。セミを使用するにはあまりにも高度に使用されていますが、テンプレート保護を使用する必要があるほど十分ではありません。よろしく、ユーザー:TheDragonFire300(お問い合わせ|貢献)。21:44、2021 年 9 月 3 日 (UTC)

ディスカッション (ECP およびテンプレート)

  • 適切な RfC を行う気力がないので、誰かにこれを締めくくるように頼もうとしていたところですが、とにかくやろうとしているようです。このスレッドを今ご覧になっている方へ: このスレッドは、最近の破壊行為事件に対応して、私が管理しているボットに関する更新として始まりました。ボットによるテンプレート保護について取り上げられる記事の多くが ECP を必要としているように見えたので、私は ECP の使用への関心を測っていました。したがって、とにかく、この RfC の目的上、有権者は、どのようなしきい値を使用するかなど、ボットに関するすべての提案を無視できます。これは、ECP の使用に関する合意が確立されれば、後で解決できます。ありがとう、MusikAnimal トーク2021 年 8 月 17 日 21:20 (UTC)
    ご説明いただきありがとうございます。私は本質的に、ボットへの変更を個別に処理することについてあなたが言ったことを言おうとしていました。私は、半保護とテンプレートエディタ保護の間に段階があることを評価する個人的な偏見を持っているため、これが拡張確認保護を使用することのマイナス面を評価するのを妨げている可能性があります。(テンプレート エディターの役割が存在する前に私が書いたモジュールがあり、その後テンプレート エディターで保護されました。管理者が親切にそれを下げ、対応するテンプレートを半保護に下げてくれたので、必要に応じてサポートし続けることができました。私はそれができることを知っています。いつでもテンプレート エディターで保護された状態に戻されるため、編集リクエストに頼る必要があります。これは大したことではなく、変更は頻繁ではありませんが、将来的には障害となる可能性があります。) isaacl ( talk ) 21:37、8 月17日2021 (協定世界時)
  • コメント- ECP は確かに半保護よりもはるかに安全ですが、それでも、熱心な破壊者が他の人に目を向けることなく克服できるものです。新しいアカウントにサインアップし、500 件の編集を行い、30 日間待つのは想像の域を超えません。このような注目度の高いテンプレートにはテンプレート保護を使用した方がよいのではないでしょうか? 明らかに、これはそれらに微調整を加えようとしている他の正当なユーザーにとってイライラを引き起こすでしょうが、私はそれが8月16日の大失敗の危険を再び冒すよりも良い解決策だと思います。—  Amakuru (トーク) 08:14、18 August 2021 (UTC)
    一部の破壊者はそこまでするかもしれません - 私たちはいつも他の場所でそれを見かけます - それは間違いなく重要な障壁ですが。多くはECに向かう途中で捕まるだろうが、ECにたどり着く人もいるだろう。少なくとも、その過程でいくつかのタイプミスは修正されるかもしれません。これまでにも、大量の靴下人形遣いをする管理者や、メイン ページを削除した管理者がいたため、完璧なものはありません。問題はコストと利益のバランスを正しく取ることだけであり、この提案はそれを行うための追加のオプションを提供します。-- zzuuzz (会話) 2021 年 8 月 18 日 09:02 (UTC)
  • この事件に関連するすべてを読んでいないため、議論を見逃していた場合はご容赦ください。MusikBOT は、管理者が故意に低い保護レベルを設定してボットが上書きするのを避けるために、保護を強化しないことを知っています。このような場合には、ボットによる変更を防ぐために、 {{ bots }} テンプレートを使用してこのようなケースを制御する方が合理的ではないでしょうか。-- Trialpears (トーク) 08:34、2021 年 8 月 18 日 (UTC)
    「テンプレートを使用する」というのは、{{ボット}} のことを意味していると思いますか? このタスクはこのように除外に準拠すべきではないと思います。なぜなら、破壊者は、たとえば、タスクをより可視的なテンプレートにトランスクルージョンする直前に、このタスクが保護されるのを防ぐためにこれを行う可能性があるからです(これも自動的に保護されるべきですが、議論のために、そうではないことにしましょう)。ボットは、User:MusikBot II/TemplateProtector/configignore_offsetのオプションに従って、過去 7 日間に最近ページ保護が変更されたページのみを無視します。人間は、わずか 500 個のトランスクルージョンがあるテンプレートに数百万個のトランスクルージョンがあることをわざわざ遡って確認することはないので、この状態が永遠に続くことは望ましくありません。人間は忘れますが、ボットは忘れません:) ただし、管理者は構成を介して特定のページを明示的に除外することもできるため、ボットにテンプレートを無視させる手段はまだあります。MusikAnimal talk 15:53、2021 年 8 月 18 日 (UTC)
    これは確かにテンプレートですが、{{ t }} を忘れただけです。ボットが除外の申し立てを受けるのは良い考えではないという意見はおそらく正しいですが、構成ソリューションは十分であるようです。7 日間の無視オフセットも見つかったようですが、では、なぜ {{ wbr }} や関連するディスカッションで言及されている他の項目で保護を強化しなかったのでしょう-- Trialpears (トーク) 2021 年 8 月 18 日 21:31 (UTC)
    昨日まで、ボットは完全に保護されていないテンプレートに対してのみ動作していました。これで、設定に応じてセミエディタからテンプレートエディタにエスカレートします。これを行うための技術的手段は、ほんの数か月前に可能になったばかりです。したがって、このケースではボットが助けに来るのが遅すぎましたが、少なくとも新しいデータベースのレプリカがこの機能を可能にするのに十分な速度を持っていることを喜ぶべきです:) — MusikAnimal talk 03:37、19 August 2021 ( UTC )
    トランスクルージョン数を定期的に確認したいという要望はありがたいのですが、7 日間という最低期間が十分な長さであるかどうかはわかりません。ボット セットの保護の場合は問題ありませんが、管理者が保護レベルを設定した場合、テンプレートが今後 1 週間以上使用される可能性を考慮したはずです。isaacl (トーク) 2021 年 8 月 19 日 20:17 (UTC)
上記の議論は終了しました。改造しないでください。その後のコメントは、適切なディスカッション ページで行う必要があります。このディスカッションをこれ以上編集しないでください。

アンチリンク腐敗ドライブを開始する

現在の集計によると、リンク切れの問題が発生した記事の数は、ゆっくりと、しかし着実に 300,000 点に近づいています。これは英語版ウィキペディアの 5% 未満であり、ほとんどの引用が適切である記事を主に扱っていますが、どこにも見つからないページを参照している記事がある場合、これはかなり問題になると思います。アーカイブ、特にそのソースを参照するお気に入り。その場合、情報の更新、削除が必要になる場合があります(WP:VまたはWP:BLPに基づいて)懸念)、または単純にリファレンス内のリンクを変更する必要があるかもしれませんが、いずれもボットだけでは処理できません。これは、より楽しい部分に関連するバッジ/栄誉ではなく、単に百科事典の日常的なメンテナンスであるため、一般にウィキペディアの編集者が特に触れていないように見える領域でもあります。

これが Village Pump での最初の投稿なので、ここがその提案の適切な場であることを保証してください (そうでない場合は、別のフォーラムにリダイレクトしてください)。そしてもちろん、それについてあなたの意見を聞きたいと思っています。シュメンデロヴィツキ(トーク) 14:40、2021 年 9 月 3 日 (UTC)

アイデアをありがとう、シュメンデロヴィッキさんこの村のポンプはこのような提案に常に使用されているため、適切な会場にいます。リンクの破損を解決することは確かにプラスなので、リンクの破損を解決するのに協力する人は誰でも良いことをしています。ただし、これが最も緊急のバックログであるとは言えません。{{ 要出典}} よりも深刻ではありません (死んだ参考文献は、たとえ検証不可能であっても、少なくともその資料をサポートしている可能性がありますが、要引用参考文献は完全にサポートされていないとマークされます)資料)、編集者の数を大幅に増やさない限り、引用が必要なバックログを解決することはできません。
私が疑問に思っていることの 1 つは、インターネット アーカイブは理論上、Wikipedia から発信されるすべてのリンクをアーカイブすることになっているため、最近タグ付けされたリンク腐敗の事例がどこから来たのかということです。これらは IA がそうする前からの古いリンクなのでしょうか、それとも実際には IA を通じて利用できるのに編集者がリンクが永久に無効になっていると誤解したのでしょうか、それとも IA がすべてをキャプチャできていないのでしょうか? {{u| Sdkb }}トーク18:55、2021 年 9 月 3 日 (UTC)
おそらくそれらすべてのことです。Wayback と Archive.today でのリンクの体系的な保存は、2012 年頃までは行われていませんでした。現在の保存方法は、いくつかの理由から 100% ではありません。タグの一部は解決可能ですが、ボットまたは人はまだ解決できません。IMO のより大きな問題は偽陰性です。リンクは無効になっているが、マークされていない、またはソフト 404 やその他の問題によりボットによって保存されていないリンク。私たちが使用している方法には問題があります。解決策は、すべてのリンクがアーカイブされて生まれることです。アーカイブ URL は、ボットではなく自動的にレンダリングされるページの一部です。-- Green C 19:37、2021 年 9 月 3 日 (UTC){{dead link}}
前者のケースのようです (これらの多くは 2007 年から 2012 年のものであるため、見つけるのが難しいことがよくあります。明らかに 2013 年に引用されて消滅したものもありますが (たとえば、 here )、この記事では 2015 年について説明します。スペイン映画なのに公式サイトは死んでいてリンク腐ったタグが残っている。
Internet Archive は理論的には Wikipedia からのすべてのリンクをアーカイブすることになっていますが、自動的にはアーカイブされません。少なくとも、この記事内の参考文献は 2 か月ほどアーカイブされないままです (ただし、正直に言うと、熱波がニュースになったときに IA ボットがそのページを 1 ~ 2 回閲覧したことがあります)。
IMO のより大きな問題は偽陰性です。リンクは無効になっているが、マークされていない、またはソフト 404 やその他の問題によりボットによって保存されていないリンク。20 ~ 30 件の記事のサンプルでこの作業を行った時点では、実際にはその問題に遭遇していませんでした。いずれにしても、実際にページにアクセスして URL とアーカイブの両方を確認するまでは、それを認識することはできません。これは人間にしかできません。
「要引用」バックログに関しては、これはデッドリンクよりもはるかに困難になるでしょう。後者ではページをアーカイブされたバージョンと照合する (またはタイトルをコピーする) だけで済むのに対し、前者では実際に情報を見つけることは困難なことが多く、複数の言語が関係するためです。つまり、アンチリンク腐りドライブはより迅速な修正です (確かにそれほど根本的ではありませんが)。
解決策は、すべてのリンクがアーカイブされて生まれることです。アーカイブ URL は、ボットではなく自動的にレンダリングされるページの一部です。ウィキペディアに送信したリンクのクエリを自動的に IA に送信し、引用に追加する必要があるということですか? とてもクールに聞こえますが、これは IA のサーバーに大きな負荷を与えます。シュメンデロヴィツキ(トーク) 01:30、2021 年 9 月 4 日 (UTC)
「すべてのリンクを送信します。IA に Wikipedia を送信します」は、Internet Archive でWikipedia:Link_rot#Automatic_archivingと見られるものです規模感を表すと、Wikipedia には約 500 のサイトに約 1 億から 2 億の一意の URL があります。ウェイバック マシンは 1,070 億を超える Web ページをアーカイブしました。偽陰性の問題は逸話的なものではなく、適切なサイズのデータ​​セットに基づいて推定できます。サイレントデッドリンクを含む記事が 300,000 件以上存在するというのは、突飛な推測ではありません。アーカイブされたリンクの例については、frwiki を参照してください。これはその解決策を推奨するものではありませんが、別の方法で実行できる例です。--グリーンC 18:58、2021 年 9 月 4 日 (UTC)
それが、この場合そのようなドライブを開始するさらなる理由です。シュメンデロヴィエツキ(トーク) 06:47、2021 年 9 月 5 日 (UTC)
内部リンクの腐敗に関する問題もいくつかあり、検討する価値があります。存在しなくなったか名前が変更された記事の特定のセクションを指すリダイレクト ({{ r からセクション}} および {{ r からアンカー}} によって分類されるもの) があります。これらにより記事に移動できますが、適切なセクションや情報を見つけるのが難しい場合があります。Wug・a・po・des 20:59、2021年 9 月 7 日 (UTC)

テンプレートの削除

テンプレートの削除には 2 票の投票が必要です。ほとんどの経験豊富な編集者が削除の話を疫病のように避けるのは理解しています...しかし...テンプレートの削除には基本的な投票数が必要だと思います。現時点では、1 票によって削除されたテンプレートが多数あります...多くの場合、その 1 票はここの編集者がわずか 1 年ほど編集したものです。-- Moxy -2021年8月30日20:03 (UTC)

悪いアイデア。レール テンプレートの Module:Adjacent stationへの移行などのクリーンアップに続いて、大量の TfD がラバー スタンプされています時には彼らが参加しないこともありますが、長年の前例を考慮すると、彼らがどうなるかは近くの人にとって明らかです。クローザーには、削除がどの程度議論の余地があるかを評価する資格があります。同じ原則が AfD にも適用されます ( WP:SOFTDELETE を参照)。実際に、この方法で閉じられた TfD が誤った決定に達し、したがって覆されたことを示す DRV へのリンクなど、ここに問題の証拠はありますか? ProcrastinatingReader (トーク) 2021 年 8 月 30 日 20:09 (UTC)
WP:NPASRに従って修正します...Wikipedia の領域にはこれより優れたオーバーサイトがないのが残念です...いつかは改善されることを期待できます。モクシー-00:58、2021 年 8 月 31 日 (UTC)
プロシージャに同意します。TfD の多くは票を獲得できず、AfD や RfD と同様、1 週間後に削除される可能性があります。もちろん、コンセンサスが非常に弱い場合には、ほとんどの管理者は要求に応じて削除を取り消すと思います。Elli (トーク|投稿) 20:12、2021 年 8 月 30 日 (UTC)
プロクはよく言いましたね。大量の TfD はまったく議論の余地のないもので、過去に同様の削除が多数発生しており、さらに議論がなされています。これらは多くの場合未使用であり、編集者が知っているほとんどのテンプレートとは異なり、数百または数千のページで使用されることはありません。問題を抱えている具体的な TfD がある場合は、常連の方が喜んで話し合ったり、必要に応じて変更したりしてくれると思います。クローザーのプールが非常に小さいことには多くの問題がありますが、標準を変更するのがはるかに簡単になります。-- Trialpears (トーク) 2021 年 8 月 30 日 20:28 (UTC)
  • 反対してください。Proc の状況分析に同意します。また、厳密に言えば、削除議論には投票はありません。編集者が推奨事項を作成し、クロージングパーティが議論の量だけでなく質に基づいて決定します。C.Fred (トーク) 2021 年 8 月 30 日 20:32 (UTC)
  • 議案ごとに反対する{{u| Sdkb }}トーク00:48、2021 年 8 月 31 日 (UTC)
  • 上記のとおりだと思いますが、反対しますクローザーが管理者であれば、おそらくそれを理解するのがかなり得意です。それを製品のように扱うだけだと思います...誰かがそれを指名し、かなりの時間が経っても誰も反対しませんでした。管理者は削除できますが、削除しないように裁量を使用し、そのような場合は要求に応じて削除を取り消します。私は推測する。ヘロストラトス(トーク) 00:47、2021 年 9 月 3 日 (UTC)
  • いや、編集者たちは全員、たった 1 年ほどしか編集していないのに、私たちに何ができるでしょうか? 反対:実証された利点はない私の経験では、上にリンクされているWP:SOFTDELETEのような現在のガイドラインで十分に作業を処理できます。~~~~
    ユーザー:1234qwer1234qwer4 (トーク)
    17:44、2021 年 9 月 8 日 (UTC)

モバイルビューに「お問い合わせ」ボタンと「ヘルプ」ボタンを追加します。

ファイル:Mobile Wikipedia Menu.png

これら 2 つのオプションにより、Wikipedia のモバイル版がよりユーザーフレンドリーになることは明らかです。星間(トーク) 16:31、2021 年 9 月 1 日 (UTC)

  • ノムとしてサポートします。星間(トーク) 16:31、2021 年 9 月 1 日 (UTC)
  • 提案されている「お問い合わせ」ボタンは記事のトーク ページにリンクしますか、それとも別のものを提案していますか? Blueboar (トーク) 16:47、2021 年 9 月 1 日 (UTC)
  • Wikipedia:Growth_Team_features#Help_panel はすでに開発中です。モバイルの左側のサイドバーについて話しているのであれば、おそらく広範な議論が役立つでしょう。{{u| Sdkb }}トーク16:57、2021 年 9 月 1 日 (UTC)
    • 初心者は基本的にこの目的でグロース チームの機能をうまく活用していることがわかりました。可能であれば、その使用の拡大を検討すべきであることに同意します。Wug・a・po・des 20:28、2021年 9 月 1 日 (UTC)
  • ? @ Interstellarity :どのモバイルビュー (具体的に教えてください)? これらのターゲットは何になると思いますか? これは私たち英語版ウィキペディア編集者が技術的に実装できるものでしょうか? xaosflux トーク17:56、2021 年 9 月 1 日 (UTC)
  • こんにちは、みんな、
提案されている「お問い合わせ」リンクはWikipedia:Contact usにリンクし、ヘルプ リンクはHelp:Contentsにリンクしたいと考えています。モバイル サイドバー (右の画像) では、どちらのリンクも「Wikipedia について」リンクと「免責事項」リンクの隣に配置するのが最適だと思います。英語版 Wikipedia の編集者が技術的に実装できるかどうかはわかりませんが、これについて十分な情報を詳細に提供できたことを願っています。星間(トーク) 18:19、2021 年 9 月 1 日 (UTC)
これをローカルで実行できる場所はないようです。まず、モバイルフロントエンド開発者に問い合わせて、次のことを確認してください。(a) プロジェクト固有のサイドバー リンクは、WebUI などでサポートされる可能性があります。(b) ここでプロジェクト固有のパラメータがサポートされる可能性があります。(c) これがマスター拡張機能に組み込みたいものである場合。xaosflux トーク18:53、2021 年 9 月 1 日 (UTC)
@ Xaosflux :モバイル インターフェイスの開発責任者の連絡先情報を教えていただけますか。それはとても役に立ちます。ありがとう、Interstellarity (トーク) 18:54、6 September 2021 (UTC)
@ Interstellarity :ほとんどのものと同様、開発者コミュニティによってサポートされています。このワークボードはここにあります。 @ Fuzheado :はそのプロジェクトにリストされており、さらに詳しい情報がある可能性があります。xaosflux トーク19:17、2021 年 9 月 6 日 (UTC)
うーん、私がプロジェクトにリストされているという点で何を言っているのかわかりませんか?フズヘッド| トーク00:25、2021 年 9 月 7 日 (UTC)
@ Fuzheado :ここをクリックすると、あなたは実際に「Mobile」プロジェクトの唯一のメンバーとしてリストされています。ただし、phab のプロジェクト管理は今ではいい加減な混乱になっていると思います。xaosflux トーク02:44、2021 年 9 月 7 日 (UTC)
@ SGrabarczuk (WMF)、このアイデアは主に Olga のチームのためのものではないでしょうか? Whatamidoing (WMF) (トーク) 19:17、9 September 2021 (UTC)
また、MobileFrontend プロジェクトのリストもここにあります。xaosflux トーク02:45、2021 年 9 月 7 日 (UTC)
編集者はそのような連絡に対して返答する方法があるでしょうか? この開発の最も価値のある部分は、 WP:THEYCANTHEARYOUを回避する方法かもしれませんサーテス(トーク) 19:06、2021 年 9 月 6 日 (UTC)
Interstellarity は、 Wikipedia:Contact usへの目立つリンクを追加することを提案しており、記事を大胆に編集すること、Teahouse に投稿すること、 Wikipedia:Volunteer Response Teamに電子メールを送信すること、その他いくつかのことを推奨しています。ほとんどのウィキペディア編集者は、それらの一部には返信できますが、その他は表示されません。Whatamidoing (WMF) (トーク) 19:20、9 September 2021 (UTC)

自動保護に関する推奨事項

つまり…有効期限が切れたため、保護されていない大量の閲覧記事がたくさん表示されています。1 日あたり 250,000 ビューを超える記事を自動保護するボットのアイデアについて議論し始めるべきでしょうか。B クラスか GA クラスかなどのサイズに応じて、記事を保護する必要があります。これは、ほとんどの CVU/AVU ジョブに役立ちます。Moonlight Vector 2021 年 9 月 7 日 16:21 (UTC)

これは誰でも編集できる百科事典であるため、保護されていないページが多くのビューで表示されています保護以外の他のツールでは解決できない特定かつ永続的な問題がない限り、他の Web サイトとは一線を画す 1 つのことに何千人もの人々が関与することを禁止すべきではありません (WP:NOPREEMPT を参照)破壊行為対策パトロール員が特定のページが継続的に妨害されていることに気付いた場合、ページビューの統計に関係なく、ページ保護のリクエストに応じて保護を要求することができ、人間が妨害を阻止する最適なツールを確認しますウグ・ア・ポ・デス2021年9月7日20:04 (UTC)
非常に控えめな基準を設けたとしても、この案が可決される可能性はほとんどありませんが、すぐに無視しないでほしいと思います。私たちは最近、先手を打って行動するのではなく、破壊行為が発生するかどうかを待っていると何が起こり得るかについて、非常に深刻な教訓を得ました500 件の小さな記事に表示されるテンプレートと、非常に注目度の高い 1 つの記事とでは、ページビューに大きな違いはありません。ページビューが最も多い保護されていないページのリスト (できれば非公開が望ましいですが、お気軽にメールしてください) を見てみたいと思っています。創業時の理念の背後には十分な根拠がありますが、現時点でそれらは 20 年前であり、福音ではないため、必要に応じて再検討することを恐れるべきではありません。{{u| SDKB }}トーク21:10、2021 年 9 月 7 日 (UTC)
@ Sdkb 、 500 件の小規模な記事に表示されるテンプレートと、非常に注目度の高い 1 つの記事の間にページビューに大きな違いはないかもしれませんがテンプレートでは記事よりも複雑な wiki 構文を使用することがはるかに一般的であるため、保護これにより、単に荒らし行為だけでなく、経験の浅い編集者による誠意を持った「修正」が失敗したことによる広範な被害を防ぐことができる可能性があります。もちろん、これは記事でも同様に起こる可能性があります (そして実際に起こります)。しかし、繰り返しになりますが、これらは通常、より単純な構文を持っています (そして、VisualEditor が現在標準オプションになっているのではないかと思います)。~~~~
ユーザー:1234qwer1234qwer4 (トーク)
15:43、2021 年 9 月 8 日 (UTC)
実際、テンプレートを保護する理由はページビューではなく、テンプレートの動作方法の技術的な側面にあります。善意による不正確な編集による害が主な理由ですが、テンプレートに対する悪意のある編集によって引き起こされた損害は、ページの解析方法と読者への提供方法が原因で、元に戻した後でも持続する可能性があります。リーダーがサーバーにリクエストするたびに各ページを処理するのではなく、ページをキャッシュします。編集すると常にキャッシュが無効になり、コンテンツの再レンダリングが強制されます。ほとんどの荒らし行為はフィルターを通過した場合でもすぐに元に戻され、編集によってキャッシュが削除されるため、荒らし行為はすぐに消えます。これはテンプレートには当てはまりません。テンプレートを更新すると何百万ものキャッシュが無効になる可能性があるため、テンプレートの更新は、それを使用するページ全体にゆっくりと展開されます。そのため、テンプレートに対する荒らし行為がどれほど迅速に元に戻されたとしても、元に戻されてからキャッシュが更新されるまで、記事上に数時間も放置される可能性があります。これらは被害のレベルが大きく異なり、プリエンプティブなテンプレート保護がプリエンプティブな記事保護と同じであるという考えは、これらの攻撃がどのように機能するかを詳細に掘り下げない限り意味がありません。多くの小さな記事で使用されているテンプレートに対する破壊行為は、非常に目立つ単一の記事に対する破壊行為よりもはるかに大きな結果をもたらす可能性があります。
@ Sdkb :私がそのアイデアを即座に却下しているように見えるかもしれませんが、実質的に同じトピックについて数週間ごとに複数の段落に分かれた回答をすることに興味はありませんし、提案が何の理解を示さない場合はさらに興味がありません。私たちのポリシー、または私たちのアーカイブにある多数の実質的に同様の提案。この掲示板での先制的保護に関する最近の議論は 1 週間も前に終了し、その前の議論は 2 か月続いた後、2 週間も前に終了しました。これら 2 つの最新の提案と今回の提案を比較して、なぜ私がそれらの提案にもっと真剣に取り組みたいと思ったのかを考えてください。昨日の一部は、最新の議論を反映するために保護ポリシーと説明補足を更新するのに費やしました。そのため、すでに書いたことをここで書き直すつもりはありません。昨日はWP:PPOLWP:HRTチェスタトンの柵のたとえ話のように、ウェブサイトの基本原則と保護ポリシーの主要な条項を修正するつもりなら、支持する前に、保護ポリシーについてある程度の理解を示すか、少なくともそれに言及する提案が欲しいと思います。多大なボランティア時間を費やして、永続的な提案を楽しんでいます。Wug・a・po・des 21:27、2021年 9 月 8 日 (UTC)
@ Wugapodes、それは公平です。これはまだWP:PERENNIALリストに追加されていないようですが、これは良いアイデアかもしれません。最近議論されたトピックが取り上げられた場合、ウィキリンクを使用して簡潔な歴史に簡単にアクセスできると便利です。{{u| Sdkb }}トーク21:35、2021 年 9 月 8 日 (UTC)
@ Wugapodes 、これが誰でも編集できる百科事典であるという事実は、プリエンプティブな保留中の変更保護を絶対にインストールすべきではないという意味ではありません。これにより、誰もが記事を編集できるようになりますが、編集内容は表示される前にレビューの対象となります。私はこの問題について強い意見を持っているわけではありませんが、冒頭のコメントで述べた「保護」は必ずしも編集からの保護を指すわけではないことを指摘したかったのです。~~~~
ユーザー:1234qwer1234qwer4 (トーク)
15:55、2021 年 9 月 8 日 (UTC)
私たちは数年前、多くの人が参加した RfC でそのアイデアをきっぱりと拒否したと思っていました。それ以来、私たちの状況がさらに悪くなったようには見えません。(時々 deWP を編集しようと思うことがありますが、変更保護が保留されているため、いつも諦めてしまいます。) DGG (トーク) 06:35、10 September 2021 (UTC)

Template:Findsourcesのカスタマイズを改善するための提案

背景

これは、編集者が記事を改善するためのソースを見つけやすくするために、{{ Talk header }} ()で頻繁に使用されるテンプレートである{{ findsources }}の機能を拡張するという提案です。具体的には、医学記事の医学情報源へのリンクなど、記事の種類ごとに異なるリンクのセットを表示できるようにすることを目指しています。

現在、ソースの検索リンクを生成する 3 つの関連テンプレートがあります。

将来的には、他の主題分野向けにこのファミリーの追加のテンプレートが作成される可能性があると予想されます。この提案では、トーク ヘッダーは利用可能なテンプレートの中から自動的に、または手動で設定されたパラメータに基づいて選択し、特定のページに最も適切なものを表示します。

選定の考え方

使用するリンクのセットを選択する方法について、いくつかの可能なアプローチを検討しています。

  1. 手動で設定できる新しいパラメータを使用して (つまり、Talk:Giardiasisで医療リンクを表示するには、そのページで{{talk header}}変更します){{talk header|search-domain=medical}}
  2. WikiProject バナーの自動検出を通じて (つまり、Talk:Giardiasis は、{{ WikiProject Medicine }}バナーが含まれているため、医療リンクの使用に切り替わります)
  3. ウィキデータ プロパティの自動検出を通じて (つまり、トーク:ジアルジア症は、ウィキデータ アイテムの自動分析によって医療トピックとして識別されるため、医療リンクの使用に切り替わります)

オプション 2 – 1 を組み合わせたアプローチを実装するなど、これらのアプローチを組み合わせることが可能です。これにより、{{ Talk header }} の場合はデフォルトでオプション 2 (プロジェクトの自動検出) になりますが、任意の編集者がパラメータ (例: {{talk header|search-domain=medical}}) は、プロジェクトの自動検出よりも優先されます。このパラメーターを使用できるようにすると、プロジェクト検出が適用できない記事ページの他のテンプレートで使用するために拡張することもできます。以下を参照してください。

以前の議論はテンプレート talk:Talk header にあり、トーク ヘッダー サンドボックスにオプション 1 と 2 の機能プロトタイプを作成しました。これは、関連するテスト ページで見ることができます(現在のサンドボックス リビジョンではメソッド 2 が使用されているため、メソッド 1 のテストケースは現在失敗しますが、正しいサンドボックス リビジョンが設定されていれば成功します。)

どのアプローチを好みますか?

デザイン

私たちは、検索ドメインのすべての検出を実行し、テンプレートの正しいフレーバーをトランスクルードするラッパー テンプレート (ここ) を介した実装を検討しています。ラッパー テンプレートを現在のタイトル ( Template:Findsources ) に配置し、古いコンテンツをTemplate:Findgeneralsourcesに移動すると、これはトップレベルで透明なままになります。切り替え後のTemplate:Find ソースの現在のすべてのトランスクルージョンは、ラッパーを呼び出します。これにより、{{一般的なソースの検索デフォルトでは }} です。これは、Talk ヘッダー テンプレートの外側で、他のすべてのトランスクルージョンがシームレスに移行することを意味し、本番稼働後に以前とまったく同じことを実行します。つまり、モジュールを呼び出す {{一般ソース}} が {{ ソース検索 }} をトランスクルードする追加の呼び出しが 1 つあるにもかかわらず、基本的な「ソースの検索」リンク セットを引き続き呼び出します。

現在、Template:Talk ヘッダーには、パラメーターによって抑制されていないすべての記事のソース リンクの基本セットが含まれています。稼働後、選択したソリューションに応じて、 Template:Talk ヘッダーの「ソースの検索」の動作が変更される可能性があります。パラメーター方式が選択された場合、誰かがパラメーターを追加するまで、Talk ヘッダー内のリンクは同じままになります。WikiProject による自動検出が選択されている場合、医療関連トピックのページのトーク ヘッダー内のリンクは医療リンクに切り替わり、ビデオ関連トピックのページはビデオ リンクに切り替わります。他のすべての Talk ヘッダーは以前のままになります。

他のテンプレートへの影響

他のテンプレートは、{{ unsourced }} などの { { findsources }} テンプレートやその他のメンテナンス テンプレートを使用します。どのアプローチを選択するかによって、他のテンプレートがそれらを利用できるかどうかに影響する可能性があります。自動検出とパラメータ経由を可能にする組み合わせアプローチにより、両方が可能になります。

上記の考慮事項と提案全体についてのフィードバックをお待ちしております。ありがとう!Mathglot (トーク) と{{u| Sdkb }}トーク2021 年 8 月 12 日 23:20 (UTC)更新され、伝記情報源が追加されました。by Mathglot (トーク) 2021 年 8 月 13 日 22:32 (UTC)

  • リストされている場所: Wikipedia トーク:WikiProject MedicineMathglot (トーク) 2021 年 8 月 12 日 23:49 (UTC)
  • リストされている場所: Wikipedia トーク:WikiProject ビデオ ゲームMathglot (トーク) 2021 年 8 月 12 日 23:53 (UTC)
  • このトーク ページ バナーの有用性を拡張するためにサポートします。私は特に、ラッパー テンプレートのアイデアのファンです。これは、最も混乱が少ないものであるためです。バナー内で MEDRS が必要であるとページにラベルを付ける方法については、「search-domain=medical」によるパラメータ アプローチが最良の解決策だと思いますが、自動ラベル付けは良いアイデアだと思います。私の提案としては、まず自動ラベル付けを試して、うまくいかなくなって不要なものにラベルがたくさん付いてしまった場合は、医療に関するものはすべて手動ラベル付けに戻すことです。 -- Shibboleth ink ( ) 2021年8月12日 23:57 (UTC) )
  • 共同推薦者として、私は明らかにこれを支持します。ソース検索リンクがどれほど広範囲に表示されるかを考えると、リンクが可能な限り役立つことが重要だと思います。これは、リンクをコンテキストにより適切なものにすることで役立ちます。
    選択方法に関しては、私は主にオプション 2 (プロジェクト バナー) を好みますが、オプション 1 (手動パラメーター設定) を介してオーバーライドする機能を備えています。これを広範に採用するには自動化の要素が重要だと思うからです。オプション 3 (ウィキデータ) は技術的に実現可能ではないようなので、プロジェクトのバナーが残ります。「これは {{ WikiProject Medicine }} でタグ付けされていますか?」と思います。プロジェクト タグはすべての医学関連記事に属しており、基本的に医学リンクが必要なセットでもあるため、これは優れたメトリクスです。ただし、期待どおりに動作しないまれなケースに備えて、デフォルトをオーバーライドできる機能があると便利です。オプション 1 のパラメーターを使用すると、それが可能になります。唯一の障害となるのは、コードの複雑さの追加です。
    ラッパー テンプレートの実装に関しては、Mathglot が重点的に取り組んでいる分野なので、Mathglot やここでコメントしている他の人たちの意見に従うことにします。また、これらすべてが VPR で発生するいくつかの内容よりも複雑であることは承知しています。そのため、質問がある場合や説明が必要な場合は、遠慮せずに質問してください。乾杯、{{u| Sdkb }}トーク05:50、2021 年 8 月 13 日 (UTC)
  • 私は一般案を支持します。実装に関していくつか質問があります。自動検出システムが実装される場合、「これには WikiProject Medicine のバナーがありますか?」よりももう少し繊細さが必要になると思います。医学関係者、医療会社、医学書や雑誌、医学の歴史や社会的/政治的側面などに関する記事には通常 WPM のタグが付けられていますが、これらの記事は必ずしもすべての主張について MEDRS の出典を必要とするわけではありません。これが「珍しい」ケースであるとは言えません。交差点を渡れるならWikiProject バナーの数を考慮する (たとえば、WPMed に加えてページに WPBiography タグがある場合、デフォルトで「医療情報源を検索」しない) と役立つかもしれませんが、これは監視付き AWB 実行または似ている。また、「医療情報源の検索」テンプレートと「一般情報源の検索」テンプレートのハイブリッドは、MEDRS 情報源が必要だが厳密には医学的ではない主張が含まれる可能性があるトピックに役立つ可能性があります。スパイシー(トーク) 19:54、13 8月 2021 (UTC)
    あなたが挙げた例では、ほとんどのソースでは MEDRS 標準が必要ありませんが、いくつかのソースでは必要になる可能性があるため、ハイブリッド テンプレートの考え方が気に入っています。たとえば、医学研究者は自分たちの発見について議論するページの一部、企業は自社の製品について議論するページ、自分の研究についての医学論争を議論する雑誌、パンデミックに関与したウイルスの医学的詳細について議論する歴史ページなどに必要となるでしょう。などSdkb }}トーク20:40、2021 年 8 月 13 日 (UTC)
    @ Spicy :、「WPMed に加えてページに WPBiography タグがある場合、デフォルトで「医療ソースを検索」しない」に関して、これは間違いなく追加される可能性があります。大きな困難はなく、ラッパー内で分離されます。それはそのアイデアがコンセンサスを得られるかどうかにかかっています。
    考慮すべきもう 1 つのオプションは、「ソースの検索」リンクのセットを 1 つだけ選択する必要はないということです。例のように記事が両方のプロジェクトにある場合、さまざまな結果が想像できます。Talk ヘッダー テンプレートに医療リンクを自動的に取得させ、その下に伝記リンクを追加し、2 番目のリンクも自動的に追加するか、または{{伝記情報源ボックスを手動で追加してください}}。さらに別の可能性は、WikiProject の順序を重要にすることです。Med が最初で Biog が 2 番目の場合、「医療リンクの検索」のみが自動的に取得され、それ以外は手動で追加する必要があります。もし伝記ウィキプロジェクトが最初だったら、それは逆になるでしょう。しかし、たとえ十分に文書化されていたとしても、操作的には微妙すぎるのかもしれません (「つまり、臭い文書を読む気になったということですか?」) なぜ AWB が関与するのかはわかりません。すべてラッパー内で実行できると思います。
    すべての可能性を考えると麻痺してしまうため、選択肢が多すぎると問題が発生することがあります。そのため、最初はコンセンサスが得られる最もシンプルで有用な提案を採用する傾向があります。それは、テンプレート作成者にとって作業が容易になるからではなく、編集者が新しい機能を確認して使用する時間が得られるためです。その後、これらの機能は、実際の経験に基づいて、より具体的で情報に基づいた追加機能の要望リストに浸透する可能性があります。初期のバージョン。Mathglot (トーク) 2021 年 8 月 13 日 22:11 (UTC)
    私が AWB を提案した理由は、一部のエッジケースでは人間の判断が必要になる可能性があると思うからです。医療機器会社の年間収益を引用するには MEDRS 準拠の情報源が必要であるという印象を人々に与えるべきではないと思います。 、 例えば。これは、あなたが説明したシステムやSdkbのハイブリッドテンプレートのアイデアなど、他の方法で処理できると思います(ただし、どちらもWikiProjectのタグ付けが正確であるという前提に依存していますが、常にそうであるとは限りません)... (トーク) 06:16、2021 年 8 月 31 日 (UTC)
    AWBにはあまり詳しくありませんが、 WikiProject に基づいたMathglot のロジックベースのアプローチを手動でオーバーライドして最初に使用することに重大な欠点はありますか? 可能な限りロジックを集中化することが望ましいと思われます。医療会社の場合は、優先ロジックを追加して「WikiProject Companies」をチェックし、一般的なリンク セットを表示するためにそれらのトピックを割り当てるだけでよいでしょう。ルート ロジックで説明できないシナリオがある場合でも、AWB を使用してオーバーライドを一括適用できます。- Wikmoz (トーク) 2021 年 8 月 31 日 20:48 (UTC)
    @ Spicy :、うまくいけば、人々がそれをライブで見て、展開された/docを読むと、オプションのいくつかが表示され、目的の表示を得るために意味のあるものは何でも適用できるでしょう。医療機器会社の収益ケースに MEDRS リンクが必要ない限り、以前に述べたことを何も変更せずに 2 つの可能性が思い浮かびます (ただし、これらの例は実際には行われておらず、ドキュメントもないため、明らかに明白ではありません)。
    • Talk ヘッダーの後に{{一般ソース ボックス}}を個別に追加することで、新しいヘッダー機能の範囲外でヘッダーに追加のリンク セットを追加します。これにより、医学ごとの新しいテンプレート機能によって両方の医学リンクが自動的に追加されます。プロジェクトの存在「通常の」リンク。これが、「Cochlear Limited」記事のモックアップされた Talk ページでどのように見えるかを見ることができます(注: 実際の Cochlear 記事 TP には、トーク ページに WikiProject Medicine が*ありません*。私は、それをモックアップに追加する必要がありました。このテストの目的)
    • 既存の「非表示」パラメータを使用してソース検索リンクをオフにし、{{一般ソース ボックス}} を追加します (つまり、トーク ページは現在のように表示されます) (3 番目の「ハイブリッド」ソリューションはすでに説明しました)
    私は、医学ウィキプロジェクトがすでに存在している医療機器会社を探していたので、それがあなたの懸念の良い例となるでしょうが、あきらめて、テスト用のモックアップにプロジェクト医学を強制的に組み込む必要がありました。(私はあまり真剣に見ていませんでした。) 質問は次のとおりだと思います: 「プロジェクト検出によって医療リンクが自動的に生成されることの利点は、症例の一般的な「ソースを検索」リンクが失われることで引き起こされる可能性のある混乱に見合う価値があるのか​​?プロジェクト Medicine でタグ付けされた医療機器会社のようなものでしょうか、それとも正しい WikiProject が適用されていないため、一般的なリンク セットの方が適切な場合でしょうか?」それはあなたの懸念に対する公正な表明ですか? 誰かが賢明な分析を行って、現在何が存在しているのかを確認したいと思わない限り、試してみるまでその答えがわかるかどうかはわかりません。Mathglot (トーク) 01:47、2021 年 9 月 1 日 (UTC)
  • 私はこのアイデアを広く支持しており、ユーザビリティの問題を適切に解決するための調整は可能です何らかの方法で人々を適切な情報源に誘導することは価値があります。シューターウォーカー (トーク) 2021 年 8 月 13 日 22:18 (UTC)
  • サポートこれは良いアイデアだと思います。クローバーモス (トーク) 2021年8月13日 22:23 (UTC)
  • リストされている場所: モジュール トーク:ソースの検索Mathglot (トーク) 2021 年 8 月 13 日 22:28 (UTC)
  • リストされている場所: WT:WikiProject BiographyMathglot (トーク) 2021 年 8 月 13 日 23:23 (UTC)
  • サポート非常にクールなアイデアであり、 MathglotSdkbの素晴らしい仕事です オプション 2 (手動オーバーライド機能を使用) が最良のアプローチのように思えると思います。おそらく、エッジケースにこだわりすぎる価値はありません。これらについては、ハイブリッドまたはスタックされたリンク セットを避けるために、設計と保守が最も簡単なアプローチを優先します。- Wikmoz (トーク) 01:35、2021 年 8 月 22 日 (UTC)
  • MathglotSdkb : 次のステップは何でしょうか? - Wikmoz (トーク) 04:46、2021 年 8 月 31 日 (UTC)
    フォローアップありがとうございますWikmoz さんこれにはあまり多くの参加が集まっていませんが、目に見える場所に設置されており、これまでのところ好意的な反応が得られているため、手動オーバーライド機能を備えたオプション 2 を使用して実装を進めるのが安全だと思います。{{u| Sdkb }}トーク20:31、2021 年 8 月 31 日 (UTC)
    はい、それは私には合理的に思えます。テンプレート形式でライブに移行し、ある程度のページビューを獲得する時間ができたら、初めてこれに遭遇したユーザーからのフィードバックに基づいて、さらなる調整やその他の変更が必要かどうかを確認するためにもう一度検討することができます。おそらくその後、その一部をモジュールに移動するかどうかを確認することになると思います。Sdkbを追加しますMathglot (トーク) 20:48、2021 年 8 月 31 日 (UTC)

グロースチーム機能のトライアル拡大のご提案

以下の議論は終了です。改造しないでください。その後のコメントは、適切なディスカッション ページで行う必要があります。このディスカッションをこれ以上編集しないでください。


皆さんこんにちは – 私は WMF のグロース チームのプロダクト マネージャー、マーシャル ミラーです。過去 3 年間にわたり、Growth チームは新しい編集者のエクスペリエンスを向上させることを目的とした一連の機能を開発してきました。私たちの仕事の目標は、新人が挫折や混乱から離れるのではなく、最初の編集を成功させることができるように支援することです。このページに参​​加し、この提案をまとめるのに協力してくれた 多くのコミュニティ メンバーに感謝します。

2021 年 4 月の VPR に関する議論の後、この機能は試験的に新規アカウントの 2% に適用されました。フォローしているコミュニティ メンバーは、最初のトライアルで良い結果が得られたことに同意したため、機能を受け取る新しいアカウントの割合を 2% から 25% に増やすことを提案します(いくつかの注意事項があります)。

成長機能は、プロジェクト ページで説明されているように、初心者をガイドすることを目的としています。最も重要な要素は次のとおりです。

英語版ウィキペディアの新規ホームページ
  • 初心者ホームページ: 初心者がアカウント作成後すぐにアクセスすることを推奨される、便利なアクションが記載された特別なページです。
  • 推奨される編集: {{ Advert }} や {{ Underlinked }}などのメンテナンス テンプレートを含む記事のフィード。初心者は、「ファッション」、「歴史」、「物理学」など、興味のあるトピックを選択してフィードをフィルタリングできます。
  • メンターシップ: 新人には、経験豊富なボランティアのリストからメンターが割り当てられますポップアップ フォームは、シンプルなインターフェイスを使用してメンターのトーク ページに質問を送信するのに役立ちます。Adopt-a-user は新人にとって永続的なつながりを目的としているのに対し、Growth 機能の「メンターシップ」は簡単な質問を目的としています。
  • ヘルプ パネル: 新人が記事を編集しているとき、ヘルプ パネルは折りたたみ可能なミニホームページのようなもので、関連するヘルプ リンクとメンターに質問する機能が提供されます。
英語版 Wikipedia のヘルプ パネル

Growth 機能は現在、フランス語、スペイン語、ロシア語、ポルトガル語などの大規模なウィキペディアを含む 50 のウィキペディアに掲載されており、ドイツ語とオランダ語のウィキペディアは最近トライアルを開始しました。これらの機能により、コミュニティに負担をかけることなく、新規参入者のエンゲージメントが向上することが証拠で示されています。

2021 年 4 月に、英語版 Wikipedia の機能のテストについてこのページで議論しました。6 月に新規アカウントの 2% (毎月約 2,000 の新規アカウント) に機能を提供し始め、1 か月後にデータと結果を投稿しました。主な成果は 2 つあります。

  • 「提案された編集」機能により、元に戻す率が低くても多くの優れた編集が行われているようです。6 月のテスト期間中の復帰率は 9% でした (その月の新規編集のベースライン復帰率は 27%)。現在までに 2,325 件の記事が編集されました。多くのユーザーはこれらの編集を何十回も行います。これらの差分は、[最近の変更] で「新人タスク」編集タグにフィルタリングすることで確認できます。
  • 「メンターシップ」機能は、いくつかの良い質問と、いくつかの低品質またはナンセンスな質問を生成します。現在までに、登録した 22 人のメンターに 329 件の質問がありました。私たちはメンターの能力を拡大する最善の方法と、質の高い質問を奨励する方法についてまだ議論しています。これらの差分は、「最近の変更」で「メンターシップ モジュールの質問」編集タグと「メンターシップ パネルの質問」編集タグにフィルタリングすることで確認できます。

次のステップは、新規アカウントの 25% (約 25,000 の新規アカウント) に 1 か月間 Growth 機能を提供することだと考えています。例外はメンターシップ機能です。これについては未解決の質問があり、主にここで議論されています私たちは、メンターに圧倒されないように、メンターシップを受ける新人の割合を 5% までに増やしたいと考えています。テストのこのフェーズを 1 か月間実行し、その結果をここに戻して、その機能を使用する新規ユーザーのシェアをさらに増やすかどうかを決定します。データを見て、次の質問について考えます。

  • 提案された編集の取り消し率。巡回員に過度の負担をかけることなく、高品質の編集が生成されていますか?
  • メンターからの質問の量。これにより、新規アカウントを 100% 処理するには何人のメンターが必要になるか、または増加した量に対処するにはメンターシップ機能をどのように改善する必要があるかを推定できるようになります。
  • メンターの質問の質。初心者が有益な質問をできるように機能を改善できることはありますか?

私たちは、あらゆる質問、アイデア、懸念事項を聞きたいと考えています。また、Growth 機能のテストの次の段階に移行するための一般的なサポートがあることを期待しています。また、次のフェーズで寄せられる質問の量の増加に対処するために、メンターとして登録していただける約 20 名をさらに募集しています。メンターは、トーク ページで週に 3 ~ 4 件の質問を受け取ることを期待する必要があります。詳細については、このページでサインアップしてください。ありがとう!-- Mミラー (WMF) (トーク) 2021年9月2日 23:33 (UTC)

私は「あなたの影響」セクションが好きです。何か新しいことを始めようとしているとき、自分がやっていることが変化を生んでいるかどうかについてのフィードバックが得られないと、本当に落胆することがあります。提案された編集を選択する際に何が行われるのかについてもっと知りたいと思っていますが、初心者に今すぐできる具体的なことを提示するというアイデアは確かに素晴らしいです。そして、私はモックアップの Tinder 風の「左にスワイプ、右にスワイプ」の U/I が好きです。-- RoySmith (会話) 00:00、2021 年 9 月 3 日 (UTC)
調べてくれてありがとう、@ RoySmith ! あなたの質問を見て、誰でも Growth 機能をオンにして試すことができる方法についての手順を投稿するべきだったと気づきました。以下の手順に従って実行できます
コメントと質問について: Impact モジュールが正しい軌道に乗っていると考えていることを聞いてうれしく思います。目的は、ウィキペディアの編集は価値があり、刺激的であるということを初心者が理解できるようにすることです。現時点では間違いなく非常に初歩的なものですが、来年にはさらに強力にする予定です (最終的には、この現時点で最低限のページにアイデアを投稿する予定です)。
提案された編集に関しては、初心者が簡単に編集できる興味深いページを見つけて、Wiki ですぐに成功できるようにしたいと考えています。現在、{{ Advert }}などのメンテナンス テンプレートを通じて記事を調達しています。これは、「コピー編集」タスク用の記事を見つけるために使用するテンプレートの 1 つです。実際に、コミュニティ メンバーが Growth 機能を設定できるようにするために作成した新しい特別ページ ( Special:EditGrowthConfig ) を通じて、どのタイプのタスクにどのテンプレートが使用されているかを正確に確認 (および編集) することができますこのページでは、初心者が Growth 機能をどのように体験するかについての制御の多くは、コミュニティ管理者の手に委ねられています。
ユーザーが適用するメンテナンス テンプレート以外にも、アルゴリズムに基づいて提案された編集を作成する実験を行ってきました。現在、いくつかのウィキでテストされている方法の 1 つは「リンクの追加」と呼ばれるもので、アルゴリズムを使用してウィキリンクにできる単語やフレーズを提案します。今のところ順調に進んでいます。詳細はこのプロジェクトページに記載されています。そして、その流れで、私たちは、図示していない記事に追加できる画像を提案するタスクの最初の試みも構築しています。このバージョンにはさらに多くの未解決の質問とリスクがあるため、トーク ページでより多くのコミュニティ メンバーからの意見をお待ちしています。
また、ユーザーが興味のあるトピック (「音楽」、「スポーツ」、「ヨーロッパ」など) を選択できるという点では、それらは、記事で使用されている単語に基づいて記事がどのトピックについてであるかを評価しようとする機械学習モデルから来ています。それ。英語版 Wikipedia の WikiProject タグを使用してトレーニングされており、かなり正確になる傾向があります。そのモデルがどのように機能するかについての情報はここにあります。
その他の質問やアイデアがあれば喜んでお答えします。Mミラー (WMF) (トーク) 00:30、2021年9月3日 (UTC)
  • 25%への引き上げを支持します。MMiller とその他の Growth チームは、コミュニティでこれらの機能の開発において私たちと協力して模範的な仕事をしてくれました。上で要約したように、これまでの結果は非常に有望です。このロールアウトは適切に慎重であり、最終的なリリースを知らせるためのより多くの情報を提供しながら、より多くの新規参入者がその恩恵を受けることができるようにします。{{u| Sdkb }}トーク00:20、2021 年 9 月 3 日 (UTC)
  • サポート- MMiller と彼のチームは両方とも優れたプロジェクトを持っており、コミュニティとの連携において素晴らしい仕事をしており、私たちの特定のリクエストに対応しています (一例として、成長パネルの取得とメンターの取得を分離する機能を追加しました)私たちのトライアル希望に適応するため)。これは、それを展開するための素晴らしい次のステップであり、利点とリスクをより適切に予測するために十分な試験データを提供すると思います。ノーズバグベア(トーク) 00:53、2021 年 9 月 3 日 (UTC)
  • サポートは次のステップとして妥当だと思われます。* Pppery * 始まりました... 00:56、2021 年 9 月 3 日 (UTC)
  • サポート上記の私のコメントからは明らかではない場合に備えて、これを明確にします。-- RoySmith (会話) 01:06、2021 年 9 月 3 日 (UTC)
  • これは非常に価値があると思われるので、提案どおりに前進することを支持します。-- Malcolmxl5 (トーク) 2021 年 9 月 3 日 01:25 (UTC)
  • サポートとても価値のあるプロジェクトだと思います。これを担当する WMF チームはコミュニティに対して非常に丁寧に対応してくれました。Calliopejen1 (トーク) 18:41、2021 年 9 月 3 日 (UTC)
  • 上記のサポート。―  Qwerfjklトーク2021 年 9 月 3 日 19:42 (UTC)
  • メンターとして支援を申し出た者としてサポートする。新しいユーザーがウィキペディアで編集する方法を習得できるように支援することは、健全で成長するコミュニティを確保するために私たちができる最も重要なタスクの 1 つだと思います。イザベル 🔔 2021 年 9 月 3 日 22:52 (UTC)
  • 指導者として、そして成長機能のトークでこれについて少しフィードバックを提供してきた人として、強力なサポート。私が見た限りでは、これまでのところ順調であり、25% に引き上げるのが正しい次のステップです。Bilorv (トーク) 2021 年 9 月 3 日 23:04 (UTC)
  • サポートよくやった; これは、プロジェクトと編集者の両方に利益をもたらす非常に歓迎すべき取り組みのようです。サーテス(トーク) 15:31、2021 年 9 月 4 日 (UTC)
  • 絶対サポートしますこれまでのところ期待できる結果が得られています。これは、私の最優先事項である編集者の維持と採用にとって貴重なツールのようです。キャプテンイーク 編集 ホーキャップン! 2021 年 9 月 6 日 22:38 (UTC)
  • サポート新しい編集者には指導が必要です。MMiller とチームの共同作業に感謝します。Johnuniq (トーク) 2021 年 9 月 6 日 23:43 (UTC)
  • この取り組みに関してコミュニティと協力して熱心に取り組んでくれた MMiller に感謝の気持ちを込めてサポートします。ProcrastinatingReader (トーク) 00:15、2021 年 9 月 7 日 (UTC)
  • サポート前進する準備ができている素晴らしいプロジェクト。メンターシップ プログラムが 100% までスケールアップするかどうかについてはまだ懸念がありますが、他の部分はそうです。-- Trialpears (トーク) 09:12、2021 年 9 月 7 日 (UTC)
  • サポートこれを自分の靴下アカウント用にオンにしました。このアイデア、特にホームページの「影響」の概要がとても気に入りました。クリーンアップ タグは役に立たない乱雑なものだとずっと思っていましたが、ついにクリーンアップ タグの有用性について考えが変わったかもしれません。メンターシップ コンポーネントは拡張性が最も低いように思われるため、個別にオプトインする必要があることに同意します。また、最終的にはモバイルでも利用できるようにしたいと考えています。最初に考えたのは、「スナックサイズのタスク」モデルがモバイル編集に適しているということでしたが、デスクトップ モードに切り替えずにこれを有効にする方法は見つかりませんでした。オパビニア レガリス(トーク) 2021 年 9 月 7 日 20:51 (UTC)
    こんにちは @ Opabinia regalis -- 機能をお試しいただきありがとうございます。元の投稿で、これらの機能はモバイルとデスクトップの両方で利用できると言うべきでしたが、確かに私たちはこれらの機能がモバイル編集者に最適であると考えており、期待しています。おそらく、モバイルで機能を見つける際にいくつかの課題を認識しているかもしれません。モバイルでは左上の「ハンバーガーボタン」をタップするとナビゲーションメニューが開きます。次に、そのメニューでユーザー名をタップしてホームページに移動します。それはあなたにとって効果がありますか?もっとわかりやすくアクセスできる方法はありますか?
    モバイル編集について言えば、Growth チームは特にモバイルでの使いやすさを目的としたいくつかの新しいタイプのタスクを構築してきました。現在、約 10 のウィキペディア (ドイツ語、アラビア語、フランス語、ポーランド語、その他いくつか) でテストされている最初のウィキペディアは「リンクの追加」と呼ばれるもので、アルゴリズムがウィキリンクにできる単語やフレーズを提案し、ユーザーに「はい」または「いいえ」をタップしてリンクを追加します。非常にシンプルな編集ですが、おそらくバス通勤中に手すりにしがみつきながら、片手で携帯電話を操作するだけで編集できるように設計されています。これまでのテストでは順調に進んでいます。プロジェクトをチェックして、ここまたはトーク ページに自分の考えを追加していただければ幸いです。Mミラー (WMF) (トーク)) 2021 年 9 月 8 日 17:06 (UTC)
    @ MMiller (WMF) :調べていただきありがとうございます。私が気づいた問題は、おそらく機能がすでに有効になっている初心者には関係ないと思うので、それほど重要ではないかもしれません。モバイルタスクについて聞いてうれしいです。
    もっと明確にすべきだったのですが、2 つのことに気づきました。まず、モバイル サイトを使用して機能を有効にできませんでした。今改めて見てみると、これはモバイルの「設定」がSpecial:Preferencesに対応すると期待していた私の誤解だったと思います直接リンクを使用して設定にアクセスできますが、そこへのインターフェイス リンクが見つからないようです。
    次に、「詳細」モバイル ビューを使用していることに気づきませんでした。そのビューでは、ハンバーガー メニューに自分のユーザー名へのリンクが表示されません。そのビューをオフにすると、ユーザー名をクリックすると、ご提案どおり新しいホームページにアクセスできました。ただし、少し直感的ではありません。「ホーム」リンクと「ホームページ」リンクの両方がありますが、これらは同じものではありません。「ホーム」はメイン ページに移動するため、ホームページが必要な場合はユーザー名をクリックします。 「ホーム」ではありません。私が言いたかったのは、これを詳細ビューでも見たいということだと思います (編集には一般的にこの方が適していると思います)。Opabinia regalis (トーク) 19:23、8 September 2021 (UTC)
    こんにちは @ Opabinia regalis -- 説明ありがとうございます。はい、完全な環境設定が利用できないため、モバイルからは機能を有効にできないのは事実です。これはモバイル スキン全体の潜在的な改善だと思います。私たちの展開では、初心者はこれらの機能を自動的にオンにするため、オンにする方法を知る必要はありません。ただし、これは重要な注意事項です。たとえば、モバイルのみを使用する経験豊富な編集者は、モバイルを有効にするにはデスクトップ ビューに切り替える必要があります。
    詳細モードでは、実際にホームページにアクセスすることができます。ルールとしては、メニュー内のユーザー名をクリックすると、いつでもホームページにアクセスできるということです。非詳細モードでは、見つけたように、ユーザー名がハンバーガー メニューに表示されます。ただし、詳細モードでは、画面右上の「人」アバターの下にあります。
    おっしゃるとおり、ホームページの命名法は難しいです。ハンバーガーメニューの最初の項目が「ホーム」と呼ばれていた時期もあったと思いますが、混乱を避けるために「メインページ」に変更したと思います。「ホーム」または「メインページ」と呼ばれるものが見えますか? Mミラー (WMF) (トーク) 04:18、10 9月 2021 (UTC)
    モバイル専用の小さなタスクというアイデアが気に入っています。私が効果を確認できたもう 1 つのタスクはスペル チェック/修正ですが、「リンクの追加」タスクは Wiki 固有のスキルであるため、特に優れているようです。-- RoySmith (トーク) 2021 年 9 月 8 日 22:00 (UTC)
    @ RoySmith -- スペルチェックについて言及していただいてうれしいです。私たちが最初に「リンクの追加」タスクについて話し始めたとき、多くのコミュニティ メンバーからそのアイデアを聞きました。その流れで、私たちはそのようなタスクを構築する方法についていくつかの研究を開始しました。スペル チェック用のタスクの作成に関してアイデアや懸念がある場合は、ここまたは研究のトーク ページでご連絡いただければ幸いです。Mミラー (WMF) (トーク) 04:22、10 9月 2021 (UTC)
  • サポート最初のトライアル結果を考慮すると、現時点で拡張するのは理にかなっています。G en Q uest 「scribble」 2021 年 9 月 8 日 12:31 (UTC)
  • サポートメンターシップ プログラムに参加するのは楽しかったし、機能全体がプラスの影響を与えているのを確認してうれしく思います。経験から言えますが、質問の質はさまざまですが、回答の仕方によっては、それでも価値のあるものになる可能性があります。たとえば、「こんにちは」とだけ言う編集者が 1 人か 2 人いました。私はこれを機会と捉え、ユーザー トーク ページにウェルカム テンプレートを残しました。別の投稿者は、自分たちが王族を追放されたという信念に関連する複数の文章を投稿した。残念ながら、私は編集者が飽きて去ってしまうまで投稿を無視し、その後トーク ページを整理しました。こうした質の低い質問は、前向きなやり取りによって補われます。個人的には投稿数はそれほど多くありませんが、2% から 25% になればおそらく状況は変わるでしょう。おそらく、Tech News、Signpost、Wug・a・po・des 21:50、2021年 9 月 8 日 (UTC)
  • これまで私がサポートしてきたサポートは、WMF から提供されるインターフェースや作業スタイルに影響を与える提案に対してやや消極的な傾向がありましたが、最近では非常に便利になってきており、これは彼らの良い提案の 1 つのように思えますおそらく何年も前に自分たちでそれを行うことができたし、そうすべきだったと思いますが、それができてうれしいです。DGG (トーク) 06:40、2021 年 9 月 10 日 (UTC)
  • MarioGomをサポート(トーク) 2021 年 9 月 10 日 22:40 (UTC)
上記の議論は終了しました。改造しないでください。その後のコメントは、適切なディスカッション ページで行う必要があります。このディスカッションをこれ以上編集しないでください。

イスラムにおける性奴隷制 - 記事の保護

こんにちは!この投稿を正しい場所に掲載しているかどうかはわかりませんが、そうでないことをお許しください。

「イスラムにおける性的奴隷制」という記事は、参照されている大規模なテキスト ブロックを削除するユーザー (多くの場合匿名 IP) によって継続的に破壊されています。その理由は、その情報がイスラム教に対する中傷であるためとみられる。これらの編集は経験豊富なユーザーによって常に取り消されます。また、これらの編集は決して参照されず、代わりに参照情報が削除されるため、参照情報を削除するユーザーには宗教的な偏見があると容易に推測されます。彼らの宗教を悪い意味で捉えているのです。最近、私自身も記事内の特定の情報からの引用を求めていますが、たとえそうでなくても、これらの文には参照があると主張したユーザーによって、これは取り消されました。明らかに、この記事は感情を惹きつけています。

別の問題も浮上しました。記事には長い間中立性のテンプレートが存在していました。一貫した破壊行為のため、中立のテンプレートが実際に元々宗教的偏見のために配置されたのではないかと思いました。トークページでこの質問をしたところ、確かにテンプレートは削除されました。その後復元されました。言わなければならないのは、この記事は膨大であり、私はすべてを読んだわけではなく、この主題の専門家ではないため、中立性テンプレートが保証されるかどうか完全に確信が持てません。そして、これはデリケートな問題であると認識しているので、これ以上関与するエネルギーがありません。

しかし、この記事は非常にデリケートなテーマに関するものであると言っても過言ではなく、私は不思議に思うほど頻繁に破壊行為を元に戻さざるを得ません。この記事のように非常にデリケートで頻繁に破壊されている記事には、何らかの保護が必要ではないでしょうか? 頻繁に破壊される機密性の高い記事の多くには、少なくとも IP 編集に対してそのような保護が施されています。そこで私の質問は次のとおりです。この記事は保護できるでしょうか?本当に必要なので、ウォッチリストの他の記事よりも頻繁に破壊行為を元に戻さなければなりません。ご挨拶 --アシラム(トーク) 17:04、2021 年 9 月 8 日 (UTC)

@ Aciram Protection はWP:RPPでリクエストできます~~~~
ユーザー:1234qwer1234qwer4 (トーク)
17:07、2021 年 9 月 8 日 (UTC)
現在、記事は半保護されています。Johnuniq (トーク) 02:02、2021 年 9 月 9 日 (UTC)
このページは少し中立的ではなく、多くのコンテキストが欠落している可能性があることに同意します。このように論争が多いものやデリケートなものの場合、各発言には 1 つだけではなく、複数の独立した信頼できる情報源が必要です。そうしないと、攻撃ページとして受け取られる可能性があります適切な行動は、この問題をトーク ページに持ち込んで議論し、場合によってはそのページを削除するよう指名することだと思います。Aasim (トーク) 19:33、2021 年 9 月 13 日 (UTC)

分割された提案のバックログに対処する方法はありますか?

こんにちは皆さん!私はここ数時間を費やして、(議論が失敗した後に削除されなかった大量のタグに加えて)決して注目されなかった古い分割提案のかなりの量の未処理があることに気づきました。ウィキペディアはこれにどう対処できるでしょうか? DYK の QPQ システムは、未解決の推薦を処理するのに非常に優れていますが、それをここにどのように適用できるかわかりません。関連する WikiProject を含める必要がある分割テンプレートに何らかのパラメータを追加すると、ボットがその WikiProject 内にトーク ページを自動的に作成するため、提案への注目がさらに高まります。ご意見、または他にアイデアがある場合はお知らせください。よろしくお願いします、AC Santacruz Talk 2021 年 9 月 14 日 10:06 (UTC)

必ずしもこの考えに反対しているわけではありませんが、私たちのウィキプロジェクトの約半分が瀕死であることに注意してください。瀕死のウィキプロジェクトに通知してもあまり役に立ちません。Blueboar (トーク) 12:46、2021 年 9 月 14 日 (UTC)
念のために言っておきますが、分割とマージについては、 WP:AALERTSの各プロジェクトの「分割する記事」と「マージする記事」で説明されています。 ヘッドボム{ t · c · p · b } 2021 年 9 月 14 日 23:33 (UTC)

自身のユーザーページの保護リクエスト専用ページ

以下の議論は終了です。改造しないでください。その後のコメントは、適切なディスカッション ページで行う必要があります。このディスカッションをこれ以上編集しないでください。


それで、IPS破壊のために自分のトークページ(保留中)を保護したいのですが、WP:RFPPに大きなバックログがあるので、これ以上追加したくありません。これは管理者にとって、または単なる通常の特別ページに適していますSpecial:CreateAccountのようなMoonlight Vector 2021 年 9 月 15 日 16:03 (UTC)

@ MoonlightVector : WP:RFPP には現在 1 日未満のバックログがあるようです。そこに投稿してください。現在進行中の荒らし行為がある場合は、WP:AIVに投稿してください。xaosflux トーク16:12、2021 年 9 月 15 日 (UTC)
上記の議論は終了しました。改造しないでください。その後のコメントは、適切なディスカッション ページで行う必要があります。このディスカッションをこれ以上編集しないでください。

既存の作品にパラメータを追加することで Template:Infobox アーティストを改善する提案...

以下の議論は終了です。改造しないでください。その後のコメントは、適切なディスカッション ページで行う必要があります。このディスカッションをこれ以上編集しないでください。



情報ボックスパラメータ追加リクエスト:既存作品

説明: 現存または存続している絵画、素描、彫刻、またはその他の芸術作品の数

次の情報ボックスのパラメータは、生き残った絵画の数を示します。たとえば、エル・グレコには 500 点の絵画が現存しています。

これは歴史家が各画家の作品の数を理解するのに役立ちます。モネには 2500 点の現存作品があります。

現存する作品= 500 点の絵画が残っている

Tzim78 (トーク) 2021 年 8 月 13 日 22:05 (UTC)

 現時点ではまだ行われていません。テンプレートを使用する前に、この変更についての合意を確立してくださいホタル( tc ) 2021年8月14日 11:04 (UTC){{edit template-protected}}

Infobox_artist



  • 反対します(これはここではなく、ビジュアルアートプロジェクトで提起されるべきでした)。多くの場合、特に図面の場合、数値は不確実です。帰属に関しては多くの意見の相違があることがよくあります。情報ボックスとしては詳細すぎるため、煩雑さが増します。今も活動を続けているアーティストのために何かしてあげますか?全体的に悪い考えです。ぜひ記事に情報を追加してください。ただし、ボックスには適していません。実際、エル グレコは、その絵画の数が非常に物議を醸しているため、問題を非常によく示しています。El_Greco #Debates_on_attribution にはいくつかの数字が示されていますが、どれも 500 点にとても近いものではありませJohnbod (トーク) 2021 年 8 月 14 日 20:06 (UTC)
  • Johnbod に従って反対し、これが適切なフォーラムではないことに同意します。このディスカッションはTemplate talk:Infobox ArtistまたはWT:Visual Artsに移動できますが、ここに留まるべきではありません。雪が降ると予想されているので、RfC が必要かどうかは疑問です{{u| Sdkb }}トーク20:29、2021 年 8 月 14 日 (UTC)
  • 議論ごとに反対するピカソが夕食代を稼ぐために描いた落書きを数えると、10億以上の芸術作品がある。ランディ・クリン(トーク) 2021 年 8 月 14 日 20:51 (UTC)
  • これは無効な RfC です。ステートメントもタイムスタンプもありません。WP:RFCST を参照してください。それがTemplate talk:Infobox Artist#Template-protected edit request on 13 August 2021 に関連している場合、スレッド全体もWP:MULTIに違反しているようです。-- Red Rose64 🌹 (トーク) 2021 年 8 月 14 日 23:08 (UTC)
  • 反対これが、私が個々の作品に喜んで使用している情報ボックスがアーティストの略歴、特に中世後期/近世のアーティストについてはほとんど何も知られておらず、帰属について激しく議論される場合に適さない理由です。Tzim78 は IGF として活動していますが、ここでも雪が見られます。Ceoil (トーク) 2021 年 8 月 14 日 23:27 (UTC)
  • すでに述べた理由から、引用された情報源によっては、反対の数字があちこちにあるでしょう。記事の本文で扱う方がよいでしょう。ユールプ(トーク) 00:10、2021 年 8 月 15 日 (UTC)
  • 反対- 間違いの余地が多すぎます。機関、国、大陸を越えて作品がカタログ化されていないアーティストのための、そのような統計の中央データベースや情報交換所は存在しません。これは、アーキビストによって作品がまだカタログ化されていない現代アーティストやカタログレゾネのない現代アーティストに特に当てはまります。(何千ものアーティスト。) これらの統計は、インフォボックスではなく個々の記事に属します。ネザーゾーン(トーク) 03:06、15 8月 2021 (UTC)
  • 反対- これは記事の本文に含めることができます。さらに、同じ主題について 2 つの RFC を開始することはフォーラム ショッピングであり、非推奨です。 ロバート・マクレノン(トーク) 03:05、2021 年 8 月 16 日 (UTC)
  • 反対し、他のものにエコーする - 特に提案された例の場合、さまざまなソースを正確に表現するには、情報ボックスを介して合理的に提供できる、または提供されるべきよりもはるかに多くのコンテキストが必要になります。これはあからさまに、体に任せたほうがよい情報です。怒っているハーピー‍ トーク11:57、2021 年 8 月 16 日 (UTC)
上記の議論は終了しました。改造しないでください。その後のコメントは、適切なディスカッション ページで行う必要があります。このディスカッションをこれ以上編集しないでください。

ウィキペディアの下書きには「レビューのために下書きを送信する」というオプションがありません

ウィキペディアユーザーの皆さん、こんにちは!

英語版 Wikipedia の新しいページを編集する資格のない新規ユーザーは、https://en.m.wikipedia.org/wiki/Wikipedia:New_user_landing_page で下書きを作成するときに、「レビューのために下書きを送信する」というオプションを選択できません。下書きを本文に移動したいと考えています。このオプションは、下書きを英語版 Wikipedia の記事にするために下書きを作成する新しい Wikipedia ユーザーに必要となるため、追加してください。

ありがとうARBENTUZI (トーク投稿者) によって追加された前の署名のないコメント04:48, 18 September 2021 (UTC)

@ARBENTUZI ボタン作成を開始してください!記事ウィザードの見出しの下で、オプションを選択した後、「送信」ボタンを使用して下書きを作成できます。それがあなたが尋ねていたことですか?―  Qwerfjklトーク2021 年 9 月 18 日 10:28 (UTC)

いいえ、草案を主要な記事として移動するために、草案に「レビューのために送信」というオプションを作成するようお願いしています。ARBENTUZI (トーク投稿) 11:23、2021 年 9 月 18 日 (UTC)によって追加された前の署名のないコメント

@ARBENTUZI ドラフトスペースの重要な点は、名前空間に移動する前にレビューされることです。そうしないと、新規ユーザーが記事を作成できないようにする意味がありません。―  Qwerfjklトーク2021 年 9 月 18 日 11:58 (UTC)
すべてのWikipedia:Autoconfirmed ユーザーは、ページを Draft: から記事のメインスペースに移動できます。新人編集者の何パーセントが、記事の下書きを終えるまでに自分でそれを行うことができるだろうか?たとえば、ARBENTUZI にはあと 2 回の編集が必要です。
また、「レビュー」と呼ばれる別のプロセスがあり、これはWikipedia :作成用の記事ではなく、 Wikipedia:新規ページのパトロールによって行われます。おそらく質問はそれについてです。 WhatamIdoing (トーク) 2021 年 9 月 20 日 21:04 (UTC)
  • これを別の言い方にすると…誰かが Draftspace でドラフトを作成すると、それはレビューのために自動的に「送信」されます。ボタンは必要ありません。ブルーボア(トーク) 13:24、2021 年 9 月 18 日 (UTC)
    いいえ、それは良い考えではありません。レビュー担当者は、レビューの準備ができたことをどのようにして知るのでしょうか? 部分的に完成した下書きが却下され、レビュー担当者の時間を無駄にすることになります。レビューの未処理状態はすでに深刻で、途中で完了したすべての草案をレビューリストに入れると耐えられなくなります。 RudolfRed (トーク) 17:23、18 September 2021 (UTC)
  • ドラフトスペースで記事を作成するときは、ページの上部に{{ドラフト記事}} テンプレートを配置します。これには、準備ができたら「レビューのために送信する」オプションが含まれます。-- Malcolmxl5 (トーク) 2021年9月18日 19:56 (UTC)

ウィキペディア管理者の皆さん、こんにちは!

新しい Wikipedia ユーザーがレビューのために下書きを送信するか、自動的に記事として承認されるか、または 10 回の編集を必要とせずに新しい記事を直接作成できるようにしてください。他のすべての Wikipedia に直接記事を作成するのと同じように。

ありがとうARBENTUZI (トーク投稿) 21:40、20 9月 2021 (UTC)によって追加された先行の署名のないコメント

新しく登録されたアカウントがメインスペースで記事を直接作成できるようにするのをやめたのには理由があります。変更をロールバックするには、これに対する新たな合意が必要です。ソースの編集方法を知っている場合は、{{subst:submit}} を使用してレビューのために下書きを送信できます。すべてのボタンがあるということに全面的に依存するのはやめましょう。ちょっと青いボリ v^_^v Jéské Couriano 2021 年 9 月 20 日 21:46 (UTC)
@アルベントゥジ:
  1. 新しいユーザーのランディング ページ、 をクリックします。作成を開始する
  2. アドバイスを読んでクリックしてください終わった時に。
  3. それをもう一度やってください。
  4. 次のプロンプトに正直に答えます。
  5. 回答によっては、さらにいくつかのプロンプトを読む必要がある場合がありますが、最終的には下書きページのタイトルを作成するように求められます。バーに入力してクリックします新しい記事の下書きを作成する始めるために。
  6. ページの作成が完了したら、 をクリックします。変更を公開するドラフトを公開します。
  7. 最後に、製品が次のようになったらをクリックします。ドラフトをレビューのために提出してください。そのことをするために。MJLトーク 2021 年 9 月 21 日 17:26 (UTC)
Arbentnui 様、私は上記のすべての点に同意します。ここで受け取ったフィードバックをお読みください。Varousz (トーク) 2021 年 9 月 22 日 22:05 (UTC)
  • {{ Submit }} (記事を AfC に送信する) を編集者に頼って追加したり、編集者自身で誤って削除したりするのではなく、実際には {{ Submit }} (記事を AfC に送信する) をインターフェースに統合すべきだという ARBENTUZI の意見に私は同意しなければなりません{{u| Sdkb }}トーク04:44、2021 年 9 月 23 日 (UTC)
    @ Sdkb「参考文献なしで提出された AfC 草案」タグに引っかかったすべての記事をチェックしていたところ、不正な投稿が 3 件見つかりました。ソース検索すればもっと簡単に見つかると思います。―  Qwerfjklトーク2021 年 9 月 23 日 19:59 (UTC)

ページや書籍を印刷するための EPUB

Wikipedia:書籍や記事にはPDFに変換するオプションがあります追加でEPUBも提供することを提案します。.... 0mtwb9gd5wx (トーク) 01:15、2021 年 9 月 19 日 (UTC)

@ 0mtwb9gd5wx : Wikipedia ブックは基本的にもう存在しません --オフライン コンテンツ ジェネレーターは維持する必要がなくなったため非アクティブ化され、Books 名前空間は廃止され、既存のブックはすべて削除されました。代替の「PDF をダウンロード」リンクは、サーバー上で Chrome のコピーを実行しているだけで、組み込みの「PDF に印刷」機能を使用しているため、他の形式に変換するオプションはありません (印刷と変換はまったく異なるプロセスであるため)。 。ただし、MediaWiki2LaTeX (https://mediawiki2latex.wmflabs.org/) を使用してページを EPUB に変換することはできます。--アヘクト(トーク
ページ
) 2021 年 9 月 24 日 13:36 (UTC)

最も人気のある Wikipedia 記事の期限切れドメイン

https://archive.is/zeW6f

(申し訳ありませんが、ウィキペディアは完全な URL を受け入れないため、ページはアーカイブされています。) 37.115.210.35 (トーク) によって追加された前の署名のないコメント2021 年 9 月 23 日 19:10 (UTC)

ここで具体的にどのような変更が提案されているのかわかりません。—  JohnFromPinckney (トーク/編集) 16:51、2021 年 9 月 25 日 (UTC)

Wikipedia:Notability (テレビ) をガイドラインとして確立するための RfC 通知

これは、 Wikipedia:Notability (テレビ)の草案をガイドラインおよびWP:SNGとして実装する必要があるかどうかについてコメントを求める RfC が開始されたという通知ですここのディスカッションでコメントを歓迎します- Favre1fan93 (トーク) 2021 年 9 月 27 日 16:34 (UTC)

 MediaWiki talk:Editpage-head-copy-warnでのディスカッションに参加するよう招待されています。 § コンテンツ再利用の免責事項を削除できますか? {{u| Sdkb }}トーク03:03、2021 年 10 月 2 日 (UTC)

拡張確認済みユーザーが自分のトーク ページを保護する機能

これは現時点で非常に大きくて良い機能です。私のページをかなりの量の IP が荒らしており、トーク ページを保護するリクエストを行うのは時間がかかります。私がリクエストしたい機能はすべての拡張ユーザー向けです。トーク ページを IP から保護できるようにするためです。MoonlightVectorトーク ページ2021 年 10 月 4 日 14:50 (UTC)

MoonlightVectorこれは永続的提案の形式です。Wikipedia :永続的提案#ユーザー空間内で非管理者に管理機能を付与するを参照してください。331dot (トーク) 2021 年 10 月 4 日 14:52 (UTC)
1 ページに保護を追加できるのと同じように、すべてのページに保護を追加できるように、管理者権限なしで特定のページを保護する許可をユーザーに与えることは不可能だと思います。ただし、これが可能である場合、ユーザーがそれを正しく使用できることを証明するために、ロールバックと同様の Extended confirmed とは別の権限を設定する必要があり、単にユーザーが警告したりトークページで何かをしたりするのを防ぐために使用するのではないと思います。331dot は上記で良い点を指摘しています。ブレイズ・ザ・ウルフトークBlaze Wolf#6545 14:53、2021 年 10 月 4 日 (UTC)
  • IP によるトーク ページの破壊に常習的に問題がある場合は、無期限の保護をリクエストできます。331dot (トーク) 2021 年 10 月 4 日 14:55 (UTC)
  • もう 1 つのオプションは、ユーザー トーク ページを電話のボイスメールと同じように扱うことです。保持したくないメッセージを単純にクリアまたは削除します。
私は新しいメッセージ(荒らしだけでなく)を読んだ後、ユーザートークページを定期的に消去します。そして、あなたが応答しなければ、破壊者は立ち去る傾向があることがわかりました。Blueboar (トーク) 15:16、2021 年 10 月 4 日 (UTC)
2 番目の部分が、 WP:DENY が存在する理由全体ですトロルたちは注目を集めたいのです。それをあなたが否定すると、彼らは飽きて去っていきます。ブレイズ ザ ウルフトークBlaze Wolf#6545 2021 年 10 月 4 日 23:39 (UTC)

UFC イベントの半保護ページ

UFC イベントの結果がしばしば破壊行為の対象となることはよく知られています。(イベントが近づいたら)記事を半保護して、登録ユーザーのみが編集できるようにした方がよいのではないでしょうか。これらの偽の編集のほとんどは IP アカウントからのものです。登録ユーザーが不気味な行為をした場合、アクセス禁止の対象となります。私はこの提案をWT:WikiProject 総合格闘技に投稿しました。しかし、非常に非アクティブなため、応答には疑問がありました。私はそれほど経験豊富な編集者ではありません。ここで私の提案を編集者に共有したいと考えました。 -- Atlantis77177 (トーク) 10:09、6 10月 2021 (UTC)

最初のアカウント登録を必要とせずにウィキペディアの編集を試すことを奨励することがポリシーであるため、私たちは通常、事前にページを保護しません。短期間に繰り返される破壊行為や妨害がページ上で問題になった場合、ページを一時的に保護したり、不正な編集が行われている IP アドレスや範囲をブロックしたりできます。-ドナルド・オルベリー2021 年 10 月 6 日 13:50 (UTC)

スパム/破壊行為 IP の最近の変更点

問題のある IP に対して管理者の介入を求めるときの一般的なテーマは、生産性の高いユーザーが多すぎると広い範囲のブロックに巻き込まれてしまうということです。

破壊行為/スパム問題のある IP 範囲をログに記録し、これらの範囲に限定された最近の変更キューを生成するページを持つことに価値はあるでしょうか? Slywriter (トーク) 12:43、2021 年 10 月 1 日 (UTC)

  • 興味深いコンセプトです。そのようなことをすると、2 つ (またはそれ以上) の問題が発生します。おそらく、ウォッチャーがほとんどいない、またはまったくいない記事ページを表示するページなど、閲覧するには「管理者のみ」にする必要があります。その目的は、破壊者にとって簡単に実現できる成果を防ぐことです。第 2 に、適切な範囲をボットに判断させると問題が発生します。範囲は単純なものではなく、v6 と v4 の範囲を考慮する必要があるため、多くのコーディングとデバッグが必要になります。このようなページ、基本的にホット スポット範囲のリストには、たとえ範囲が多少ずさんだったとしても価値があることがわかりますが、問題は、そのメリットが関連する作業を上回るかどうかということです。わからない。次の質問は、これを保守するボットを誰が喜んで作成するかということです。繰り返しになりますが、興味深いアイデアですが、未知の利益を得るにはかなりの投資が必要になります。 デニス・ブラウン- 11:37、2021 年 10 月 7 日 (UTC)

2021年ロシアの同窓生およびメンター向けのCentral Noticeバナー

親愛なる同僚の皆様、2021 年ロシア卒業生および指導者向けの記事執筆コンテスト向けの Central Notice バナー提案についてコメントしてください。(2021 年 9 月 15 日 → 2021 年 11 月 30 日、ロシアのすべての IP、Wp、1 週間あたり 3 つのバナー インプレッション)。ロシアの IP のみ。ありがとう。JukoFF (トーク) 13:34、11 October 2021 (UTC)

  • これは、meta:Central Notice/Request/Alumni and Mentors of Russia 2021 にあります。 — xaosflux Talk 13:44、11 October 2021 (UTC)

en-xx UI の亜種を避ける

Wikipedia:Village_pump_(technical)#Paalika_KekaとMediaWiki:Preferences-summary/en-gbの編集概要のフォローアップとして、ユーザーが en-ca と en を選択することを「思いとどまらせる」文言を特に追加することを提案します。 -gb インターフェイスのバリアント。これらの亜種により、ユーザーはインターフェイス メッセージのローカライズを見逃すことになり、デフォルトのメッセージに戻るか、translatewiki の編集者が設定したものをそのまま受け入れるかのどちらかを選択することになります。これらのフォールバックを強制的に行ったほうが良いのですが、現時点ではそれはソフトウェアのオプションではありません。xaosflux トーク20:42、2021 年 9 月 24 日 (UTC)

最近関与した編集者に ping を送信します: @ PrimeHunterMike PeelRedrose64、およびJdforrester :xaosflux トーク20:42、2021 年 9 月 24 日 (UTC)
  • はい、ロットを廃棄します。これらのオプションを選択する人は、それが記事のテキストを構成するものであると信じてそうしているのではないかと思います。変更されないのはそれだけです私たちのほとんどは、ガソリンとガソリンが同じ物質であることを知っていますが、英国/米国の異形を含む単語がインターフェイス メッセージにどのくらいの頻度で現れるでしょうか? -- Red Rose64 🌹 (トーク) 2021 年 9 月 24 日 20:50 (UTC)
  • 上記のすべての理由により、ロットの非推奨化を完全にサポートします。それらは問題を引き起こすだけであり、その後 VPT(!) で解明する必要があります。ホタル ( tc ) 2021年9月24日 20:55 (UTC)
  • サポート私はかつて完全な en-gb ファイルを調べましたが、色/色などのわずかなスペルと句読点の違いが 10 個ほどあるだけで、ガソリン/ガソリンなどの単語の違いはありませんでした。そのため、英語版 Wikipedia 用にカスタマイズされた多くのメッセージ (ポリシー、プロセス、ヘルプ ページへのリンクなど) が失われます。たとえば、en と en-gb の完全に保護されたページの編集ページを比較します (管理者が表示するにはログアウトする必要があります)。en-gb ユーザーは、インターフェイスについて他のユーザーと議論する際に混乱を引き起こすことがあります。また、一部のヘルプ ページが表示内容と一致しません。en-ca (カナダ英語) にも同じ問題がありますが、ユーザーが少ないため、めったに表示されません。PrimeHunter (トーク) 2021 年 9 月 24 日 21:18 (UTC)
  • サポート; それらはトラブル以外の何ものでもありません。バリアント内のメッセージの一部をカスタマイズして、適切な設定を選択する方法をユーザーに示します。Jonesey95 (トーク) 00:33、2021 年 9 月 25 日 (UTC)
  • Primefac ごとのサポート。SD0001 (トーク) 02:21、2021 年 9 月 25 日 (UTC)
  • はい、サポートしますTol (トーク|投稿) @ 02:41、2021 年 9 月 25 日 (UTC)
  • ピンが来たのでコメント。設定にはすでに警告があります: 「言語 (警告:「en - English」以外の言語を選択すると、英語版 Wikipedia のインターフェイスのカスタム部分が表示されなくなる可能性があり、不正確な外部翻訳が表示される可能性があります。):" ( 「外部翻訳」の部分が奇妙/間違っています - これは MediaWiki に組み込まれた翻訳です)。おそらく、これを拡張して en-GB と en-CA に対して警告することができるでしょう。ただし、私は一般的に人々に選択を与えることに賛成です。また、母語話者ではないときに他の言語でインターフェイスを参照すると便利なので、完全に無効にするべきではありません (私は他の言語の Wiki でこれを頻繁に行っています)。ありがとう。マイク ピール(トーク) 10:11、
引用された警告は今年、MediaWiki:Your languageに追加されました。これは、言語がまだデフォルトの en である場合にのみ表示されます。PrimeHunter (トーク) 2021 年 9 月 25 日 13:35 (UTC)
外部翻訳に関する部分は、WMF Wiki ではないTranslatewiki.netで行われているため、正しいです。ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (トーク) 05:15、26 September 2021 (UTC)
  • @ Mike Peel :これらをローカルで完全に削除する能力は私たちにはないと思います。これは現時点ではこれを「思いとどまらせる」程度であり、言語がこれらの英語版である場合には警告を追加することも含まれる可能性があります。xaosflux トーク2021 年 9 月 25 日 10:20 (UTC)
  • 明確にしておきたいのですが、この提案はインターフェースのみに関するものであり、記事の内容や記事内の engvar のスタイルマニュアルにはまったく影響を与えません。xaosflux トーク2021 年 9 月 25 日 10:20 (UTC)
  • 名目ごとのサポート―  Qwerfjklトーク2021 年 9 月 25 日 14:21 (UTC)
  • サポート翻訳ウィキで過去 30 日間の統計を確認すると、en-gb には 44 件の翻訳があり、en-ca にはわずか 4 件の翻訳があります。これは、これらの亜種のメンテナが非常に少ないことを示しており、そのため、en.wp ユーザーが気づくまでテスト編集や破壊行為が検出されないことになります。translationwiki とローカルの en.wp の両方にアクティブなメンテナが不足しているため、英語版のインターフェースを選択したユーザーは次善のエクスペリエンスを得ることができます。したがって、英語のバリアント インターフェイスは、基本 en を優先して使用しないようにする必要があります。ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (トーク) 05:15、26 September 2021 (UTC)
  • en-GB と en-CA を削除することはできないでしょうか? それらはどのような目的に役立つのでしょうか? – ジョー (トーク) 07:55、2021 年 9 月 26 日 (UTC)
    @ Joe Roe :場合によってはそうです - この提案の一部は、実際に編集者がその言語を「選択」することを思いとどまらせることです - 単にメッセージをクリーンアップするだけではありません。以前のメッセージでは、誰かがこれらの設定を使用することを思いとどまらせることについて反発していました。押し付けがましいものは何もありません。設定などに、誰かが実際に設定した場合にこのオプションが推奨されないことを警告するラベルが付けられているだけです。xaosflux トーク09:42、2021 年 9 月 26 日 (UTC)
    つまり、オプションとして削除されたため、これらのメッセージを表示する必要がなくなります。– ジョー (トーク) 09:46、2021 年 9 月 26 日 (UTC)
    特にユーザーのインターフェイスの好みはローカルだけではなくグローバルになる可能性があるため、おそらく言語チームからの開発作業はゼロではありません。イズノ公開トーク) 2021年9月26日 15:15 (UTC)
    開発作業が行われている場合、正しい解決策は phab:T57473 を修正し、問題全体を無効にすることです。* Pppery * 始まりました... 2021 年 9 月 26 日、22:57 (UTC)
    @ Pppery :一般的な技術的問題は、ローカライズされたメッセージが基本言語で存在するが、ユーザーが基本バリアント言語を使用するように設定されている場合、基本バリアント言語がローカライズされていない場合、ユーザーの言語フォールバック チェーンがもたらされないことです。それらを基本言語に変換します。xaosflux トーク2021 年 9 月 26 日 23:32 (UTC)
    phab:T57473 は何か他のものを指しているのでしょうか? * Pppery * 始まりました... 2021 年 9 月 26 日 23:34 (UTC)
    これはベース言語のみのフォールバック チェーンに関するもののようです。ベースバリアント フォールバックに関する別の phab チケットがあると思いますが、今は覚えていません。— xaosflux Talk 11:01、2021 年 9 月 27 日( UTC )
    おお。私が実際に言いたかったのは、一般的な問題を修正することであり、誤ってリンクした可能性のある特定の症状を修正することではありません。* Pppery *始まりました... 2021 年 9 月 27 日、14:14 (UTC)
  • はい、やめてください。VPT で混乱した質問を受けるのにはうんざりしています。:^) -- Iznoパブリック(トーク) 15:16、2021 年 9 月 26 日 (UTC)
  • 開発者に許可を得ることができれば強制的に非推奨にし、それができない場合はサポートを第二の選択肢として選択します。状況を理解している合理的なユーザーは en-XX を選択しないでしょうし、オプションを残しておくと人々は混乱するだけで、正しい選択を見つけるのに時間を無駄にすることになります。また、編集者が en-XX UI セットを維持するためにエネルギーを無駄にしないように、できる限りのことを行うべきです。これらの UI セットをフォークすることは、英語版 Wikipedia をアメリカ英語版 Wikipedia とイギリス英語版 Wikipedia にフォークするのとまったく同じくらい意味があります。つまり、意味がありません。{{u| Sdkb }}トーク18:03、2021 年 10 月 1 日 (UTC)
  • サポートGB- User_talk:SilkTork#What's_broken?を選択すると問題が発生しました。この問題は標準の en に戻すことで修正されました。それが提供するもの(単純なスペルチェック)は、それ自体が問題になる可能性があります。なぜなら、記事がアメリカ語であるはずの場合でもそのオプションが提供されるため、修正すべきではない記事内のスペルを自動的に「修正」していることに私は気づいているからです。つづり。ということで、かなり役に立たないガジェットです。 SilkTork (トーク) 16:45、5 10月 2021 (UTC)
  • サポートグローバル設定でen-GBを設定しましたが、複数のプロジェクトで問題が発生した後、enに戻す必要がありました。選択した時点では、それがどのような問題を引き起こすかは予想できませんでしたし、問題に直面したとしても、それがen-GB の設定によって引き起こされたものであるかどうかは必ずしも明らかではありませんでしたMarioGom (トーク) 08:36、13 October 2021 (UTC)
  • サポートカスタマイズされたメッセージがある場合の動作 (en.wikipedia では非常に一般的です) は、ユーザーにとって混乱を招くだけです。時折米国の綴りを見なければならないよりもはるかに悪いことです。「?! 09:35、2021 年 10 月 13 日 (UTC)

アーカイブ URL を WebCite から Wayback Machine に移行する

WebCite はもう時代遅れになっているように思えますスクリプト実行/ボット実行を実行して、WebCite を使用するすべてのアーカイブ リンクを Wayback Machineを使用してアーカイブ リンクに移行することをお勧めします。私たちの記事によると、WebCite は 2 月以来新しいアーカイブ リクエストを受け付けておらず、サイトは 8 月からダウンしているようです。WebCite が復活するかどうかは不透明なため、より安定したアーカイブ サービスに切り替えることが望ましいと思われます。特に、元のリンクが無効で WebCite アーカイブ リンクが使用されている場合は、可能であればそのリンクを Wayback Machine リンクに置き換えるべきだと思います。この作業に何回の交換が必要になるかわかりませんが、手動で行うのは非現実的であると予想されます。山口敏夫トーク)) 09:16、2021 年 9 月 30 日 (UTC)

  • 賢明なようです。窒息(トーク) 11:13、2021 年 10 月 13 日 (UTC)

このボット WaybackMedic は実行の承認を得ており、過去に実行され、WebCite を Wayback に変換しました。思ったよりも難しいです。問題: WebCite は長い間、ユーザーがその時点でページを保存できる「ページを今すぐ保存」機能を提供する唯一のプロバイダーでした。Wayback を含む他の企業は、散発的な自動クロールのみを実行しました (最終的には SPN を提供しました)。そのため、コンテンツがずれているページを保存したい場合には、このサイトが推奨されました。継続的に変化するページ上の気象統計。そのため、WebCite から Wayback に変換する場合、Wayback が同じ日の完全に一致する必要があるため、正しく変換するのは非常に困難です。そうしないと、コンテンツがずれたアーカイブが作成される危険があります。理想的な方法はコピーですWebCite ページを別のプロバイダーに転送することについては検討中ですが、今のところこれ以上言うことはありません。記録として、enwiki には 238,851 の WebCite リンクがあります。手動での移動が最善の選択肢ですが、それには何年ものコミュニティの努力が必要です。本当に気になるページがある場合は、そうすることをお勧めします。--グリーンC 16:36、2021 年 10 月 13 日 (UTC)

興味深い情報 - 私はいつもGreenC さんから何かを学んでいます。編集者にとっては完璧なタスクのように思えますが、もうそのようなことをやらないのは残念です :-( 専門知識をありがとう。MarnetteD | Talk 16:57、13 October 2021 ( UTC )
ありがとう、MarnetteD、あなたの言う通りだと思いますが、それは魅力的で、多くの面があります。1 つのアイデアは、WebCite が非推奨であるという目に見えるメッセージを追加し、新しいアーカイブ リンクを見つけるように CS1|2 グループを説得することです。非推奨をサポートする RfC が存在しますが、それ以来状況は悪化しています。--グリーンC 17:18、2021 年 10 月 13 日 (UTC)

政党の若者の翼のテンプレート

こんにちは、

私がパイオニアおよび共産主義青年同盟の記事をナビゲートしていたとき、政党の青年団体に関連するすべてのテンプレート (つまりナビゲーションボックス) が分類されていないまたは地理的論理に基づいて分類されており、イデオロギー、場所、またはイデオロギーには無関係であることがわかりました。主題の地政学的階層におけるレベル。そこで、これらのテンプレートを追加するための既に作成されたテンプレート カテゴリがあるかどうかを見つけようとしましたが、見つかったのはカテゴリ:政党テンプレートカテゴリ:政治イデオロギー テンプレートまたはカテゴリ:組織テンプレートだけでした。

そこで、2 つの質問があります。

  • それは良いアイデアですか? (私はそう思いますが、私は UNCAT プロジェクトに繰り返し貢献しているので、貢献者の意見を知り、分類するときに自分自身に問いかけることができる特定のジレンマを明確にするために、原則に関するいくつかの質問をしたいと思います)私には終わったようです。)
  • 「はい」の場合、関連する親カテゴリ内で最適な名前のカテゴリ (必要に応じて) を作成し、分類して作業を行うためのテンプレートのリストを作成するのを誰かが手伝ってくれませんか。

-- Anas1712 (トーク) 2021年10月17日 16:02 (UTC)

PS: 質問するのに最適な場所ではない場合は、コミュニティの年配の方が質問を再投稿する場所を教えてください。

あなたの声明のフランス語部分を英語に翻訳していただけますか。GoodDay (トーク) 16:53、17 October 2021 (UTC)
緑色のチェックマークY-- Anas1712 (トーク) 2021年10月17日 17:57 (UTC)
この議論については、Wikipedia talk:WikiProject Politicsにメモを残しましたThryduulf (トーク) 16:55、2021 年 10 月 17 日 (UTC)

ウィキフィクション

私は、クリエイティブな執筆のための複数著者のスペース、WikiFiction (または WikiNovelist) を作成することを提案したいと思います。

ウィキ小説家は複数著者の書籍に参加できるように寄付をする必要があり、寄付するには全員が事前に登録する必要があります。このプロセスにより、退屈した嫌悪者や破壊者を多忙なクリエイターから遠ざけることができ、現代の連続魔女焼きをする人たちを潜在的な知的生命体から遠ざけることができます。

WikiFiction は、このプロジェクトや他のウィキメディア プロジェクトのための資金を獲得する方法になる可能性があります。

この新しいプラットフォームは、おそらく有効な携帯電話による登録要件を追加して、現在の Wikipedia プラットフォームを再利用することができます。一部の書籍が混雑しすぎて内容が混乱し、いつまでも変更されないようにするには、一定期間の書籍ごとの著者の最大数を設定する必要があります。

最終的な本の一貫性をチェックできる著者と編集者がいるはずです。最終バージョンが合意されるまで、すべてのバージョンを保管する必要があります。著者や編集者は名前やニックネームで登録できますが、すべて身元を証明できる方法で登録する必要があります。

WikiFiction の書籍から得た利益は、理想的には主要著者の投票によって選ばれた非営利慈善団体に提供され、その割合が WikiFiction の維持に充てられるべきです。

ウィキ小説家への寄付金の一部は基金に貯められ、他の方法では寄付できない人たちに無料パスを提供する予定だ。つまり、地球のどこかの人里離れた村に住む若いレオナルド・ダ・ヴィンチは、たとえ収入がゼロだったとしても、おそらくユニークなアイデアで本に貢献することができるのです。

私たちが直面している未来の解決策を見つけるには、創造的な文章や想像力全般が緊急に必要とされています。百科事典や歴史は、過去の素晴らしい (またはひどい) アイデアを私たちに与えてくれます。一部の小説は(科学のようなものですが)、未来を予測したり創造したりするための貴重な手段となる可能性があります。

テストとして、最初の小説の第 1 章のアイデアを投稿してみます。この本は、プラスチックやリサイクルを大きな問題として捉えることから、私たち人類の人口過剰がこの地球上の本当の問題であると認めるまで、気候変動に関連するパラダイム変化に焦点を当てた複数著者の本となることを目指しています。この本はそれを中心に展開していきます。

この創造的な作品には、科学者、現代哲学者、社会人類学者の意見が必要です...そして、できるだけ早く展開を開始する必要があります... — 94.252.121.207 (トーク) 13:44、16 October 2021 (UTC)によって追加された前の署名のないコメント

あなたはこれに関して間違ったページにいるだけでなく、完全に間違ったプロジェクトに取り組んでいます。あなたの提案はウィキペディアの目的から完全に外れています。新しいプロジェクトについては、meta:Proposals を読んでみてください。-- Red Rose64 🌹 (トーク) 2021 年 10 月 16 日 14:38 (UTC)
これはウィキペディア向けのものではありません。それはウィキメディアにとっても当てはまらないかもしれません。🐔 チクダット・  ボーク、私に!09:58、2021 年 10 月 17 日 (UTC)
@ Chicdat :​​ 同意します。ウィキメディア財団の全体の目的は、無料のオープンコンテンツのウィキ プロジェクトを運営することです。アクセス料を支払う必要があり、各ページを限られた人だけが編集でき、編集するには電話番号の登録が必要なプロジェクトは、財団の趣旨と完全に矛盾しています。ここでは、財団の残りの部分に資金を提供するのではなく、寄付が他の慈善団体に寄付されるという、かなり奇妙な提案された構造もあります。正直に言うと、完全に別のウェブサイトの提案のように読めます。192.76.8.77 (トーク) 18:40、2021 年 10 月 18 日 (UTC)
ウィキメディア財団の慈善目的は「教育」であることがお分かりいただけると思います。米国連邦法では、501(c)(3)非課税組織に共通する 6 つの慈善目的を挙げていますhttps://www.irs.gov/charities-non-profits/charitable-Purposes も参照してください。Whatamidoing (WMF) (トーク) 02:33、20 10月 2021 (UTC)
@ Whatamidoing (WMF) :確かに、しかしウィキメディア財団のミッションステートメント [1] は、彼らが教育資料を提供する方法として多言語ウィキプロジェクトを実行することを意図していることを明らかにしています。私が言いたいのは、編集するために支払い/「寄付」が必要で、編集が少数の人に制限されている Web サイトは、一般的に想定されている Wiki ベースのプロジェクトを運営するという概念に完全に反するということです適度にオープンで編集可能。192.76.8.77 (トーク) 09:10、2021 年 10 月 20 日 (UTC)
正しい。IPv4 ノミネーター、これに最も近いのは、まったく別の Web サイトです。🐔 チクダット・  ボーク、私に!2021 年 10 月 20 日、10:22 (UTC)
ミッションステートメントでは、目標は「教育コンテンツを収集し、開発すること」であると述べられています。なぜクラウドソーシングの小説が何らかの形の「教育コンテンツ」とみなされるのか、私にはわかりません。Whatamidoing (WMF) (トーク) 2021 年 10 月 21 日 20:01 (UTC)

緊急: MCDC 選挙ウォッチリスト/MassMessage およびローカル情報ページ

英語版ウィキペディア コミュニティは、運動憲章起草委員会の現在の選挙について伝えるために何をすべきでしょうか? 03:58、2021 年 10 月 12 日 (UTC)

皆さん、こんにちは。運動憲章起草委員会(「運動憲章」、つまり世界的なウィキメディアコミュニティのための実質的な憲法の起草を任務としています)の選挙が現在開始されており、2021年10月24日まで約2週間投票が行われます。 (情報: 発表メール、ローカル情報ページ。) できれば選挙までにまだ時間があるうちに、決めるべきことが 3 つあります。

  1. 選挙はマスメッセージによって enwiki 上の有権者に宣伝されるべきですか (ArbCom 選挙の場合と同様)?
  2.  すでに完了しています- 選挙の監視リスト通知を投稿する必要がありますか (RfA の場合など)。
  3.  すでに完了しています- enwiki は、適切な情報/FAQ およびリンクを含む、この選挙に関するローカル情報ページを維持および使用する必要がありますか? 私が草稿 ( Wikipedia:2021 年運動憲章起草委員会選挙) を書き始めたとき、メタ文書が実際には十分に整理されておらず、これまでのメッセージングにはすでにいくつかの失敗があることに気づきました (前日の投票開始時に選挙は発表されませんでした) ; 投票用紙には候補者が 19 人であると記載されていますが、実際には 70 人です; など)。この質問に対する答えが「はい」の場合、すべてのローカル アナウンス (必要に応じてウォッチリスト/MassMessage を含む) にそのローカル リンク (メタ リンクの代わりに) を使用できます。いずれにせよ、地元の情報ページの構築に大胆に協力してください。

選挙は 13 日で終わるため、この RfC は必然的に標準の 30 日よりも短くなります。ベスト、KevinL (別名 L235 · t · c ) 03:50、2021 年 10 月 12 日 (UTC)

  • 1、2、3 についてはそうです。急いでこれを書いたことをお詫びします。この選挙に関して調整されたコミュニケーションが行われないことに私はすぐに気づきませんでした。KevinL (別名 L235 · t · c ) 03:53、12 10月 2021 (UTC)
  • 3 つすべてをサポートしますこれは認識されている以上に大きな問題であり、運動の組織方法を根本的に変える可能性があります。この選挙で en-wiki が十分に代表されるようにすることが私たちの最大の利益であり、3 つのアイデアはすべて、そのための合理的な方法であると私には思われます。(大量メッセージングは​​少し煩わしいですが、オプトアウトするのも非常に簡単です。) また、IAR の精神に基づき、この RfC が速やかに、できれば 1 週間以内に閉じられることを願っています。よろしく、特別令状(トーク) 05:04、2021 年 10 月 12 日 (UTC)
  • 3 つすべてをサポートし、正直に言って、最後の 2 つだけを大胆に実行してください。エンタープライズ (トーク! ) 06:47、12 10月 2021 (UTC)
  • 3 つすべてをサポートし、2 と 3 をできるだけ早く実行してください。ホタル ( tc ) 2021 年 10 月 12 日 07:12 (UTC)
  • [開示: 候補者] - 今すぐ 2 と 3 をお願いします。そして 3 人全員をサポートしてください。Nosebagbear (トーク) 08:46、12 October 2021 (UTC)
  • したがって、何万ものトーク メッセージを送信することに可能な限り最も強く反対します。これについてはすでに中央通知が出されています。通常、すでに CN がある場合は WLN を掲載しません。しかし、人々がそれを望むのであれば、もちろんそうします。誰かがローカル ページを実行したい場合は、より強力な権限を与えられます。xaosflux トーク10:13、2021 年 10 月 12 日 (UTC)
    • ローカルページが何をする必要があるのか​​さえ分かりませんが、私は特に気にしません。候補者はすでに選択されており (meta:Movement_Charter/Drafting_Committee/Candidates)、投票はすでに開始されています (meta:Special:SecurePoll/vote/390)。コミュニティが実際に「行う」ことは、有権者を送り込むことだけです。xaosflux トーク10:17、2021 年 10 月 12 日 (UTC)
      @ Xaosflux :この時点で、おそらく必要なのは、 WP:ACE2021のようなメイン ページWP : MCDCE2021 ではなく、 Wikipedia:ArbCom 選挙の 5 分ガイドに似た「MCDC 選挙の 5 分ガイド」です。私が知っていることは、メタページを読もうとしたものの内容が理解できなかった十数人のウィキペディアンに、MCDC とは何か、人々がなぜ気にする必要があるのか​​、投票して情報を見つける方法を説明したということです。 MC がそうなるので、何らかのローカル ページが必要です。KevinL (別名L235 · t · c ) 2021 年 10 月 12 日 14:43 (UTC)
      現在、コンパスの質問に対する候補者の基本的なスタンスを簡単な表形式で表示するページを作成中ですが、膨大な数考えると時間がかかります
    • FWIW、 MediaWiki_talk:Watchlist-messages#Movement_Charter/Drafting_Committee/Electionsで WLN を準備しましたxaosflux トーク11:08、2021 年 10 月 12 日 (UTC)
    • この世界的な取り組みが、すべての有権者にトークページを送信するようなレベルの広告を必要とするものであれば、それはすべての WMF プロジェクトの上流に要求されるべきであり、そのようなことを行っているプロジェクトを他に知りません。これは重要なことのように思えますが、英語版ウィキペディアにとって、ある種の絶滅レベルの出来事には至っていないように思えます。xaosflux トーク10:51、2021 年 10 月 13 日 (UTC)
  • 2 と 3 を (すぐに) 実行し、1 をニュートラルにします。このような状況では、RfC は約 30実行されるはずです。ArbCom のメッセージはちょっと腹立たしいですが、少なくとも私は ArbCom が何であるかを知っています。ウィキメディア運動や運動憲章について聞いたことがなく、草案を作成する必要があり、そのために選挙が行われることも知らなかったウィキディアンは私だけではないかと心配しています。私は今、名前さえ知っている 3 人の候補者と他の 69 人を比較検討しなければなりません。私の言いたいことは、編集者が聞いたことのない内容の MassMessage をどの程度受け入れるかについては疑問です。あるいは、ここで無知なのは私だけかもしれません。—  JohnFromPinckney (トーク/編集)12:12、12 October 2021 (UTC)編集:候補者は72名あるようです—  JohnFromPinckney (トーク/編集) 12:16、2021 年 10 月 12 日 (UTC)
  • 混乱ウィキペディア:2021 年運動憲章起草委員会選挙、メタ:運動憲章、メタ:グローバル評議会をざっと読みましたが、この選挙が何に関するものなのか、英語版ウィキペディア (または英語版ウィキペディア) にどのような影響を与えるのかまったくわかりません。他のウィキペディア)。そうですね、本質的にはmeta:Movement Charterに関するものだとは思いますが、この「憲章」がプロジェクトにどのような影響を与えるのか、あるいは与えることになっているのか(EN Wikipedia)、私にはすぐにはわかりません。理解できる人が、これがEN Wikipediaに与える直接的な影響について簡単な概要を書いてくれるといいのですが。山口敏夫(トーク) 2021年10月12日 13:58 (UTC)
    @山口俊夫:この質問こそが、ローカルなディスカッションと情報ページを設ける最も重要な理由です。簡単に言うと、運動憲章はウィキメディア運動に対する将来のあらゆる変化がどのように起こるかを規定するものである、ということです。それは財団に対して世界的な運動を代表する権限を持つ「世界評議会」(m:Global Council)を構成します。MCDCが何を書くかによっては、予算、スタッフ、弁護士、拘束力のある世界政策を採用し、ローカルプロジェクトを無効にする権限、今後のWMFとプロジェクトの関係の変更に同意する能力なども持つ可能性がある。本質的には、それは次のとおりである。世界的なウィキメディア運動全体のための政府委員会であり、MCDC はそれがどのように形成されるか、つまり選出されるか任命されるか (または混合)、どのような多様性要件があるか、各プロジェクトがどのような発言権を持つかを決定する責任を負っています。それを選択し、Enwiki が評議会の議席に占める割合はかなり小さいと思われます。これがお役に立てば幸いです – そして、これが重要である理由を簡潔に説明できるようご協力いただける場合は、大胆に編集してください。Wikipedia:そう言う2021年運動憲章起草委員会選挙。ベスト、KevinL (別名 L235 · t · c ) 14:31、2021 年 10 月 12 日 (UTC)
@ L235 :それは実に明確で簡潔な要約です。そのページに追加することをお勧めします。ザ・ランドトーク) 18:11、12 October 2021 (UTC)
  • WMF がこれに関する最新情報をここに掲載していることに注意してください: Wikipedia:Village_pump_(miscellaneous)#Voting_to_elect_members_for_the_Movement_Charter_drafting_committee_is_now_openxaosflux トーク17:17、2021 年 10 月 12 日 (UTC)
  • つまり、間違いなく 2。おそらく 3. 1 では中立ですが、これまでのところ私が予想していたよりも多くの支持を得ています。ローカル情報ページに関しては、英語版ウィキペディアの読者にとって全体が何なのかをわかりやすく説明するものであれば何でも良いでしょう。メタドキュメントは今日中に少し改善されましたが、それに関してやるべきことはまだたくさんあります。それに貢献できることをうれしく思います (とはいえ、私も候補者の 1 人なので、言えることは限られていますが)。よろしく、ザ・ランド(トーク) 18:08、2021 年 10 月 12 日 (UTC)
  • 3 つすべてをサポートし、コミュニケーションが増えることは間違いなく良いことです。Jack Attack1597 (トーク) 18:49、12 October 2021 (UTC)
  • 大量のメッセージに反対してください。すでにサイト バナーがあるときに通知を大量に送信しないでください。ウォッチリスト通知をサポートしローカルページでは中立ですが、誰かがそれを維持したい場合は、より多くの力を与えます。Wug・a・po・des 20:57、2021年 10 月 12 日 (UTC)
    @ Wugapodes :うーん、私はマス メッセージの方が、(1)バナーの盲目さを克服し、(2) ローカル情報ページや 5 分間のガイド ページにリンクして、選挙(ArbCom の選挙と同じかそれ以上に重要であることは間違いありません)、そして(3)それを有効にしている人に電子メールを送信します。ベスト、KevinL (別名 L235 · t · c ) 02:56、2021 年 10 月 13 日 (UTC)
    @ L235 :聞いたこともない委員会の役職について、知らない人々からの 70 件以上の発言をわざわざ読む人がどれだけいるか、あなたは過大評価していると思います。メタ選挙の重要性については明らかに同意しますが、単に重要であるというだけでは、他の 2 つの著名な場所の情報と重複する何万もの通知を正当化することはできません。ユーザーのトーク履歴をざっと読んでみましたが、理事会の選挙の方がはるかに重要で理解しやすいにもかかわらず、理事会の選挙に関する大量のメッセージを受け取ったことがないと思います。バナーブラインドネスと戦う方法は、より良いバナーをデザインすることであり、すでに無視したり参加したりすることを選択したものに関する情報で人々を殴りつけることではありません。誰もがメタで何が起こっているかに興味や関心を持っているわけではありません。それを知るための数多くの方法。バナーブラインドの話ばかりしているにもかかわらず、無駄な大量メッセージングを継続的に行うと、一般に人々が大量メッセージングをオプトアウトするリスクがあることを忘れています。私たちはすでに大量の ACE 大量メッセージを送信しており、約5,000 人の編集者が大量メッセージ配信をオプトアウトしていますバナーを修正するのは簡単ですが、大量のメッセージを再購読してもらうのは困難です。さらに、誰かが enWiki の進行状況から切り離されすぎて、中央の通知や監視リストのバナーを何週間も見逃した場合そうなると、トークページのメッセージや電子メールが、おそらく聞いたこともない委員会のほぼ 4 つの音楽候補を読むきっかけになるとは思えません。ほとんどの人にとってニッチな関心のある選挙のために、すでに広く入手可能な情報をウォッチリスト、トークページ、電子メールの受信トレイに溢れさせることに私は価値があるとは思えません。大切ですか?もちろんですが、それがすべてのページの上部にバナーがある理由です。Wug・a・po・des 18:01、2021年 10 月 13 日 (UTC)
  • 情報 注:上記の議論を踏まえて、ウォッチリスト通知WP:BOLDlyを追加しました。Mz7 (トーク) 02:54、2021 年 10 月 13 日 (UTC)
  • 注: オプション 2 と 3 はすでに完了しています。したがって、誰かがそれらを取り消したいと主張しない限り、これは現時点でほぼ 1 位です。30 日未満でも問題ないようですが、膨大な数のトーク メッセージを実行して送信する前に、その部分については少なくとも「非常に多くの参加者が集まる」必要があると思います。xaosflux トーク10:42、2021 年 10 月 13 日 (UTC)
    @ Xaosflux : 私はこの会話を監視しており、彼がウォッチリスト通知を実装する前に Mz7 と簡単に話し、それに対するコンセンサスがあることを確認しました。私たちのポリシー、ガイドライン、手順に従って、特に今回の場合、コンセンサスを見つけるのに必ずしも 30 日待つ必要はないことに同意します。しかし、影響の大きさを考慮すると、より多くの編集者の参加が必要になるでしょう。ベスト、Barkeep49 (トーク) 00:40、2021 年 10 月 14 日 (UTC)
  • 3 つすべてを支持してください、これはウィキメディアの歴史の中で最も重要な選挙になるかもしれませんこの選挙の賭けには、ウィキメディアの寄付の一部に大きな影響が含まれます。この運動憲章は少なくとも 10 年間続くガバナンス文書となる予定で、その間にウィキメディア財団はウィキメディア コミュニティへの約 10 億米ドルの寄付を集める予定です。このガバナンス文書は、その 10 ~ 70% の範囲内での割り当てを指示する可能性があります。控えめに言っても、この文書は、これまで資金調達について検討も議論もされていなかった大義、目的、人々、場所に、少なくとも10年以内に1億ドルを送ることになると思います。これは本当に大変なことです。この状況と通知は、これまでの他のコミュニティ通知よりも多くのチャネルでより多くのコミュニケーションを行う候補です。しかし、今回の選挙はその一部に過ぎず、そして、その直後にある同じくらいインパクトのある部分のランディング ページに人々の注意を向けたいと思うかもしれません。私たちがこれらの起草者を選出した後、彼らが運動憲章を作成している間、ウィキメディア コミュニティの誰もがトーク ページにコメントを投稿できるようになります。これを次のように考えてください米国の権利章典誰かが起草者に含めるべきテキストを提案した場合、憲章にそれを盛り込むことができ、それによってウィキメディア運動の憲法上の権利となるでしょう。起草者に投票するだけでなく、人々は選出された起草者にコメントする準備を整える必要があります。ブルーラズベリー(トーク) 00:24、15 October 2021 (UTC)
  • 1 には反対しますが、2 と 3 は支持します1 は私には不必要だと思われますが、WP:CENTにリストされているのとは重複しますそして、Central Notice と Watchlist 通知は言うまでもなく、WP:ANでそれに関する宣伝文を掲載しています。言葉を伝える方法はたくさんあります。また、スチュワード選挙中はユーザーに大量のメッセージを送信しないことにも注意したいので、この場合もそうする理由はないと思います。申し訳ありませんが、この議論はWP:CENTに掲載されているもののようですそれに応じてコメントの一部を削除しましたが、この RfC の騒動が落ち着いたら、Wikipedia:2021 運動憲章起草委員会選挙をそこに掲載することを強く支持します。 OhKayeSierra (トーク) 00:44、2021 年 10 月 15 日 (UTC) ( WP:CENTに関する間違いのためコメントを編集しました。OhKayeSierra (トーク) 00:49、2021 年 10 月 15 日 (UTC))
  • (開示: 私は候補者です。) 選挙は残り 17 時間です。おそらく、何らかの方法でこれを閉じる時期が来たでしょうか?--ヤイル・ランド(トーク) 2021 年 10 月 24 日 18:52 (UTC)
  • RFC バナーを削除しました。この議論は現時点では OBE、つまり投票の終了です。-- Izno公開(トーク) 2021 年 10 月 25 日 18:59 (UTC)

「Bill Pay」を使用して寄付者を無視するのはやめてください

以下の議論は終了です。改造しないでください。その後のコメントは、適切なディスカッション ページで行う必要があります。このディスカッションをこれ以上編集しないでください。


私はウィキペディアに、「Bill Pay」経由で寄付した人を保存し、寄付リクエストページに「Bill Pay 経由で寄付」チェックボックスを追加することを提案したいと思います。何年も寄付をしてきた人たちにとって、もっとほしいと手を差し伸べる以外にほとんど感謝の気持ちを示さないのは、かなり腹立たしいことだ。W!k!pita1! によって追加された前の署名のないコメント (トーク •投稿) 21:42、27 10月 2021

わくぴた1! 寄付リクエストのメッセージについて言及している場合は、アカウントの設定でメッセージをオフにすることができます。331dot (トーク) 2021 年 10 月 27 日 21:48 (UTC)
@W!k!pita1!:フィードバックありがとうございます。寄付メッセージは英語版ウィキペディアに表示されていますが、サーバーとインフラストラクチャを運営しているウィキメディア財団からのものであり、すべてのプロジェクトに表示されています。私たちの地元のボランティアは寄付に直接対応しませんが、詳細について、またはその件に関するフィードバックを提供するには、donate @wikimedia.orgまでご連絡ください。よろしくお願いします。 — xaosflux トーク2021 年 10 月 27 日 23:04 (UTC)
また、「小切手で支払う」ことを希望する場合 (ほとんどの請求書支払いシステムはこの方法に戻ります)、その方法で寄付する方法については、このリンクを参照してください。xaosflux トーク2021 年 10 月 27 日 23:06 (UTC)
上記の議論は終了しました。改造しないでください。その後のコメントは、適切なディスカッション ページで行う必要があります。このディスカッションをこれ以上編集しないでください。

url-status=ライブペイウォールエスケープ

元の URL がライブでペイウォールの背後にあり、アーカイブ URL がペイウォールの背後にない場合には、 の|url-status=ような新しい値が必要です。live paywall escapeこの状況では、マークアップを使用すると|url-status=live、ほとんどの読者にとってリンクはあまり望ましくないソースになりますが、|url-status=deadそうではありません。アノマロカリス(トーク) 06:20、2021 年 10 月 29 日 (UTC)

ソースの Web サイトからペイウォールをバイパスするリンクを意図的に奨励すべきでしょうか? つまり、ソース リンクとアーカイブ リンクを持つことと、ソース リンクと ---> ペイウォールをバイパスするにはここをクリック <-- (アイコン形式) を持つことは別のことです。ProcrastinatingReader (トーク) 12:33、2021 年 10 月 29 日 (UTC)
代替手段が合法である場合に限り、そうすべきだと思います。これに関して適切な法的アドバイスはありますか? 私たちの中には、Wikipedia のDOIからのリンクを回避することに慣れている人もいます。DOI は、著者の大学など、無料の合法的な代替ソースがある場合に、貪欲な出版社を指していることがよくあります。 サーテス(トーク) 12:40、2021 年 10 月 29 日 (UTC)
私はよく JSTOR に含まれている雑誌の記事を引用しますが (私は個人アカウントを持っているので問題ありません)、大学のサイトからも無料でアクセスできます。私が JSTOR ID を含めていたため、編集者がフリーアクセス URL エントリを引用文から削除したことを思い出します。これに関連して、記事のドラフト バージョンに無料でアクセスできますが、最終的な公開バージョンはペイウォールの内側にあります。ドラフトを読めるのはいいのですが、正式に公開されたバージョンで何が変わったのかはわかりません。また、削除されるまで主著者の大学を通じて入手できたNatureの論文も引用しました( Natureの記事が公開されることを期待しています)著作権を保持する素材を非常に保護します)。したがって、パブリッシャーが著作権を行使しているために、ペイウォール以外のソースが削除される可能性が常にあります。しかし全体的には、著作権が侵害されていないことが合理的に確信できる限り、読者を情報源として無料でアクセスできるサイトにリンクするためにできる限りのことを行うべきだと思います。-ドナルド・オルベリー18:11、2021年10月29日 (UTC)
  • 技術的なメモとして、これはおそらく|url-access=よりもに適しています|url-status={{u| Sdkb }}トーク20:34、2021 年 10 月 29 日 (UTC)
  • これには法的な側面よりも倫理的な側面があると思います。ウィキペディアは質の高い情報源に依存しており、質の高いジャーナリズムを生み出すのは無料ではありません。経営不振に陥っている新聞社が、業界の悲惨な状況への対応としてペイウォールを設けることを選択したのであれば、読者がその事実に気付かないほど簡単にペイウォールを回避できるようにすべきかどうかはわかりません。ソースは寄付を求めています。本当に情報が必要な人にとっては、アーカイブ リンクが引き続き存在するため、ペイウォールを回避するのが非常に簡単になります。{{u| Sdkb }}トーク20:34、2021 年 10 月 29 日 (UTC)
    ガーディアン紙が記事を調査して執筆し、礼儀正しく寄付を求めて誰でも閲覧できるようにするのと、エルゼビア社がウェブホスティングだけが貢献している研究論文を封鎖するのとの間には違いがあるサーテス(トーク) 2021 年 10 月 29 日 20:48 (UTC)
    法外な料金を請求するパブリッシャーは確かに存在しますが、何が「有効な」ペイウォールで何がそうでないのかを判断しようとすることは、私たちにとって適切な範囲をはるかに超えています。{{u| Sdkb }}トーク21:09、2021 年 10 月 29 日 (UTC)
  • IMO では、ペイウォールを回避するという公然としたビジネスに携わるべきではありません。--グリーンC 2021 年 10 月 29 日 20:44 (UTC)
  • より倫理的ではありますが、ユーザーフレンドリーではない選択肢は、常にライブバージョンではなくアーカイブを優先することです。これは、編集者がコンテンツを調達したときのソースをそのまま提供するのと同じことになります。 Slywriter (トーク) 2021 年 10 月 29 日 21:25 (UTC)

GA/FA モバイルトピックのブレインストーミング

これは「昔ながらのファブ」T75299: モバイル スキンへのトピックソンの実装です。読者のモバイル化が進むにつれて、ページが本当に高品質であるかどうかを理解できる読者はますます少なくなります。GA および FA 記事に費やした多大な時間と労力が評価されなくなります。昨年、ファブに関しては活発な議論が行われましたが、明らかな解決策はありませんでした。技術的な解決策を提案できるコーダーと、(配置する場合) トピコンをどのように配置するかに関するコミュニティのコンセンサスを提案できるプログラマーが必要です。あるいは、トピックス全般の提示方法を再考する必要があります。したがって、GA/FA ステータスの表示をモバイル読者にも見えるように修正する方法をブレーンストーミングしていただければ幸いです。キャプテンイーク 編集 ホーキャップン! 2021 年 10 月 29 日 21:33 (UTC)

  • 私はこのファブチケットに対処するよう努めてきましたが、3月には進展しているように見えましたが、その後は後退しました。これは間違いなく非常に重要ですが、どれだけのブレーンストーミングが残っているかはわかりません。必要なのは、それを実装するために WMF からの注意だけです。{{u| Sdkb }}トーク21:44、2021 年 10 月 29 日 (UTC)
  • PC と同じくらい携帯電話からも編集する人として (特に PC で vpn を使用する必要がある場合)、モバイルでの使用に関するあらゆる改善が本当に感謝されます。あなたの提案には含まれていませんが、最近、トーク ページのバナー (COI/有料開示、制裁警告、その他の非常に重要なものなど) を表示する方法について議論されましたか? AC Santacruz Talk 2021 年 11 月 3 日 23:40 (UTC)

ポリシーとガイドラインのリストからWP:5 つの柱を削除

以下の議論は終了です。改造しないでください。その後のコメントは、適切なディスカッション ページで行う必要があります。このディスカッションをこれ以上編集しないでください。



WP:5P が正式なポリシーではなく、コミュニティでの議論がまったくないまま変更 (たとえば、5P1 に「地名辞典」を追加) が加えられたことを知って驚きましたこれをさまざまな P&G テンプレートだけでなく、Wikipedia:ポリシーとガイドラインのリストに含めることに本当に意味があるのでしょうか? これは、その重要性を減じることを意図したものではなく、正しくラベルを付けることを目的としています。dlthewave 03:44、2021 年 11 月 8 日 (UTC)

えーと、これはWP:NOTBURO (官僚主義ではありません) が適用されるWikipedia です。各ページにラベルを貼る必要はなく、例外は許容されます。5P への" " の追加を元に戻す ( diff ) と、私の編集概要では、ページへのリンク (linkcount) が 370 万件あることが示されました。{{Information page|5P}}これは、5P が単なる「情報」以上のものであることを裏付けています。これはポリシーではなく、明らかにガイドラインでもありませんが、基本をきれいにまとめたものとして受け入れられています。「地名辞典」問題は話し合いで解決できる。Johnuniq (トーク) 04:06、2021 年 11 月 8 日 (UTC)
最も精査されたコミュニティ ページの 1 つです。現在の状況に到達するまでに、膨大な量の議論が行われてきました。基本についての素晴らしい紹介が 1 ページにあり、最も重要なポイントへのリンクが付いています。ヘルプ:イントロMoxyの成人版です04:15、2021 年 11 月 8 日 (UTC)
  • 私は現状に何の問題もないと考えており、5 本の柱のページに「ラベルを付ける」努力はやめさせたいと思います。私たちは長年にわたり、5 本の柱が当社の基本原則を正確に表していると考えてきました。ウィキペディアの初心者にとって、このページはウィキペディアのポリシーとガイドラインの精神を理解するのに役立ちます。ある意味、従来のレーベルの枠を超えた、かなりユニークな企画ページです。「情報ページ」とすると、そのページの重要性が明らかに過小評価され、 Wikipedia:ポリシーとガイドラインのリストから削除されることになります。ただし、このページを「ポリシー」または「ガイドライン」として説明すること自体も不正確です。なぜなら、このページは推奨される特定の実践方法を具体的に説明するものではなく、基本原則の要約を目的としているからです。特に「地名辞典」に関しては、この言葉について「コミュニティでの議論がまったくなされていない」と言っても過言ではないと思います。実際、これはWP:NGEOの基礎として参照されています。Wikipedia5 つの柱によれば、この百科事典には地名辞典の機能が含まれています。したがって、ウィキペディアの一般特筆性ガイドライン(GNG)を満たす地理的特徴は、特筆性があると推定されますが、保証されるものではありません。 ) 06:08、2021 年 11 月 8 日 (UTC)
  • @ Dlthewave :テンプレートトーク:Wikipedia のポリシーとガイドライン#RfCで密接に関連する RfC を開催しています: Wikipedia:5 つの柱を削除します- WP:MULTIを尊重してください。-- Red Rose64 🌹 (トーク) 2021 年 11 月 8 日 10:31 (UTC)
  • Redrose64 が言及した RfC は、この WP:MULTI ディスカッションと同様に、雪のように終了することを願っています。これらの柱はその名前が示すとおり、プロジェクトとそのポリシーとガイドラインの基盤として機能し、引き続きリンクされ、広く配布される必要があります。ランディ・クリン(トーク) 11:27、2021 年 11 月 8 日 (UTC)
上記の議論は終了しました。改造しないでください。その後のコメントは、適切なディスカッション ページで行う必要があります。このディスカッションをこれ以上編集しないでください。

こんにちは、私は最近、他の言語で記事リストを作成するボットを作成しています。現在、ボットは jawiki と zhwiki で実行されており、結果が表示されると思います。ボットはこのように言語ごとのリストを作成します。このように、Wikipedia:注目記事を他の言語で強化してみてはいかがでしょうか? カナシミ(トーク) 03:40, 20 October 2021 (UTC)

そのページは履歴としてマークされているため、ボットで復活できる場合は、そうしてください。{{u| Sdkb }}トーク00:56、2021 年 10 月 21 日 (UTC)
ありがとう。ただいま準備中…カナシミ(トーク) 2021年10月21日 11:31 (UTC)
@kanashimi :英語版 Wikipedia でボットを実行するに、ここで承認をリクエストする必要があることに注意してください: WP:BRFAxaosflux トーク11:36、2021 年 10 月 21 日 (UTC)
わかりました。他にご意見があれば数日お待ちさせていただきます。カナシミ(トーク) 2021 年 10 月 21 日 11:41 (UTC)
もちろん!ボットが (少なくとも現時点では) 1 ページのみを更新する場合は、問題なく承認されるはずです。ボット独自のユーザーページ (User:Bot/SampleReport など) で少量のテストを行うこともできます。例を挙げて説明するのは良い方法です。xaosflux トーク2021 年 10 月 21 日 11:50 (UTC)
(編集の競合) BRFA を開く必要がないように、このタスクに関する関連する問題についてここで議論できるかもしれませんが、BRFA が価値がないか、要件を満たしていないか、最終的には実行不可能であることがわかります。カナシミ(トーク) 2021 年 10 月 21 日 11:53 (UTC)
@ Sdkb @ Xaosflux Wikipedia:他の言語の注目記事/アフリカーンス語でアフリカーンス語のリストを生成しました問題があるかどうか確認するのを手伝ってもらえますか? ありがとう。カナシミ(トーク) 05:02, 22 October 2021 (UTC)
、 区切り文字を、標準のセミコロンや中央のドットなど、英語で一般的なものに置き換えることができます。いくつかの説明も必要です(チェックマークと緑色の背景は記事が存在することを意味しますなど)。それ以外は、私にとっては良さそうです。Kusma (トーク) 06:34、2021 年 10 月 27 日 (UTC)
そうそう、これ忘れてます。現在は修正されています。フィードバックをお寄せください。ありがとうございます。カナシミ(トーク) 09:13, 27 October 2021 (UTC)
@kanashimi フィードバックです。―  Qwerfjklトーク09:36、2021 年 10 月 27 日 (UTC)
もう少しコメントを追加してください。それとも、もういい感じですか? カナシミ(トーク) 09:40, 27 October 2021 (UTC)
見た目がずっと良くなります。Wikipedia :他の言語の注目記事/ヘッダーを編集可能なサブページにすることは素晴らしい選択であり、他の人が説明をさらに改善できるようになります。Kusma (トーク) 09:45、2021 年 10 月 27 日 (UTC)
ありがとう。:)カナシミ(トーク) 2021 年 10 月 27 日 10:01 (UTC)
Wikipedia:他言語の注目記事/アフリカーンス語の「同名の記事」の意味がわかりません「記事がありません」または「記事が存在しません」は十分に明らかですが、「同じ名前」の場合はそうではありません。—  JohnFromPinckney (トーク/編集) 2021 年 10 月 27 日 13:11 (UTC)
私に言わせれば、各エントリの前の色分け + またはは、凡例を完全に省略しても十分に自明です。怒っているハーピー‍ トーク14:12、2021 年 10 月 27 日 (UTC)
コメントありがとうございます。@ JohnFromPinckney「記事タイトルがウィキデータラベルと同じである」という意味です。コメントを変更しましたので、お役に立てれば幸いです。@ AngryHarpy並べ替え用です。この機能のみになるように色を削除します。カナシミ(トーク) 2021 年 10 月 27 日 17:50 (UTC)
ああ。したがって、英語の記事の下の ✗ 赤いセルについては、アフリカーンス語のタイトルと一致する赤でリンクされたタイトルがある場合、それは英語の記事が存在しないことを意味し、青でリンクされた一致するタイトルがある場合、それは英語へのリンクです -その名前の WP dab ページ。その列に別の名前がある場合は、アフリカーンス語の主題に対応する en-WP 記事があるものの、タイトルが異なることを意味します。そしていずれの場合も、✗アフリカーンス語の記事と何らかの関連があるウィキデータ項目へのリンクを含む赤いセル{{d:Q12345678}}(同じ名前ではない場合でも)。
すべて正しく理解できましたか?
また、「言語」列には、そのトピックに関する記事があるウィキペディアの数が表示されます (ただし、その数は記事の「言語」リストでは一致していないようです)。はい?—  JohnFromPinckney (トーク/編集) 07:41、2021 年 10 月 28 日 (UTC)
ああ、はい、わかりました!誰もが意味を理解できるように、誰かがさらに説明を追加してくれることを願っています。カナシミ(トーク) 08:04, 28 October 2021 (UTC)
いいね。物事をより明確にすることを期待して、現在 /header ページのいくつかの編集を試しています。そこで別の質問が生まれます。
最初の列には「#」というラベルが付いていますが、それ以外の説明はありません。この列の数字には何か特別な意味があるのでしょうか? 編集者が他の列でソートするのに役立つと思いますか? 私には、これは「言語」によるソートに基づいた半ば偶然のランキングにすぎないように思えます(そして、たとえば、5 つの記事がすべて同じ記事数を持っている場合、これは任意です)。では、この列なしでも大丈夫でしょうか? (それは、とりわけ、それを説明する手間を省くでしょう。)—  JohnFromPinckney (トーク/編集) 11:03、28 10月 2021 (UTC)
はい、「#」フィールドは基本的に「言語」で並べ替えます。同じ「言語」を持つ 2 つの行がある場合、「英語の記事」で並べ替えられます。これが大きな違いです。「言語」のヘッダーをクリックして「言語」で並べ替えると、「#」フィールドが連続していないことがわかります。カナシミ(トーク) 2021 年 10 月 28 日 11:28 (UTC)
さて、この編集を見てください詳細の一部がより明確になることを願っています。いずれにしても、/whatever language ページの概要を説明します。フィードバックは歓迎です。—  JohnFromPinckney (トーク/編集) 2021 年 10 月 28 日 12:29 (UTC)
良い!ありがとうございました!カナシミ(トーク) 2021 年 10 月 28 日 13:09 (UTC)
ウィキデータへの参照は省略することをお勧めします。ここ WP.en の編集者の多くは、その特定のプロジェクトの大ファンではありません。Blueboar (トーク) 2021 年 10 月 27 日 21:29 (UTC)
まあ、これは本当に問題です。ウィキデータへのリンクは削除できますが、ウィキデータ ラベルのない海外の記事には何も残りません。これはもっと有益でしょうか?カナシミ(トーク) 2021年10月27日 22:04 (UTC)
WD リンクを含めることには問題があることを知っておいてほしいのです… WD リンクに多くの時間を費やす前に、それを知っておく方がよいでしょう。ブルーボア(トーク) 12:46、2021 年 10 月 28 日 (UTC)
アドバイスありがとうございます。カナシミ(トーク) 2021 年 10 月 28 日 13:10 (UTC)
メインスペースに WD リンクを含めることは確かに議論の余地がありますが、プロジェクト ページで WD へのリンクを避ける必要はまったくありません。SD0001 (トーク) 07:43、2021 年 11 月 10 日 (UTC)
@カナシミ:アフリカーンス語のページは素晴らしいですね! このボットを他の Wiki で実行する予定がある場合は、新しく更新されたデータの場所を確保するために、Wikipedia:他の言語の注目記事を何らかの方法でアーカイブできるでしょうか? Artem.G (トーク) 2021 年 11 月 2 日 19:16 (UTC)
はい、他の Wiki にも立候補する予定です。最終的に、他の言語での Wikipedia:注目の記事は、 ja:Wikipedia:諸言語版の秀逸な記事、または zh:Wikipedia:その他语言的维基百科典范条目のようになります。カナシミトーク) 2021年11月2日 21:48 (UTC)

BRFA申請済み--カナシミ(トーク) 06:25、10 11月2021 (UTC)

映画記事リストのジャンル欄

以下の議論は終了です。改造しないでください。その後のコメントは、適切なディスカッション ページで行う必要があります。このディスカッションをこれ以上編集しないでください。


編集者の皆さん、映画のジャンルの列を追加すると非常に便利です。私はこの「2017 年のアメリカ映画のリスト」のようなリストをよく読みますが、いつもジャンルが足りないと感じます。これを検討して、できるだけ多くの該当するリストで実現してください。できるだけ。

2017 年に最も興行収入を上げた映画
ランク タイトル 卸売業者 国内総計 ジャンル
1 スター・ウォーズ:最後のジェダイ ディズニー 620,181,382ドル スペースオペラ
2 美女と野獣 5億4,014,165ドル ロマンチックなファンタジー
3 ワンダーウーマン ワーナーブラザーズ。 412,563,408ドル
4 ジュマンジ:ウェルカム・トゥ・ジャングル ソニー 404,515,480ドル
5 ガーディアンズ・オブ・ギャラクシー Vol. 2 ディズニー 3億8981万3101ドル
6 スパイダーマン: ホームカミング ソニー 334,201,140ドル
7 それ ワーナーブラザーズ。 327,481,748ドル
8 ソー:ラグナロク ディズニー 315,058,289ドル
9 怪盗グルーの月泥棒3 ユニバーサル 2億6,462万4,300ドル
10 ジャスティス・リーグ ワーナーブラザーズ。 229,024,295ドル

--アブ・アーミル(トーク) 2021 年 11 月 11 日 19:25 (UTC)

多くのドライブバイ編集者が、映画 (およびその他の作品) の記事に、自分に合っていると思ってランダムにジャンルを追加していることを考えると、これは悪い考えです。そのようなリストを提供する他の情報源が映画のジャンルを日常的に提供している場合、それを含めることができるという理論的根拠もあるかもしれませんが、映画リストでそれが通常行われていない場合、それは私たちにとってジャンルのクズの問題を引き起こすことになります。-- Masem ( t ) 19:37、2021 年 11 月 11 日 (UTC )
上記の議論は終了しました。改造しないでください。その後のコメントは、適切なディスカッション ページで行う必要があります。このディスカッションをこれ以上編集しないでください。