編集チェック

This page is a translated version of the page Edit check and the translation is 89% complete.

2024-2025予算年度、当編集機能チームはビジュアルエディターの改善点として、新人ボランティアの皆さんがウィキメディアのプロジェクト群で建設的な編集を貢献できるようにするため、方針とガイドラインの理解を補佐して守りやすくすることを目指しました。

以下の情報ではこのプロジェクトの目標を述べ、それを決めた背景や、ウィキメディア財団の製品部門がこれを優先する根拠をご説明します。

当プロジェクト関連のミーティング予定は 編集チーム/コミュニティの会話 をご参照ください。

Several features are available within Edit Check:

目的

  1. 編集初学者およびジュニア投稿者で活動地域がアフリカ大陸のサハラ以南地域の人たちは、自分の編集した箇所が経験を積んだボランティアに有益な編集だと認知されたと分かると、(次から)編集に自信が持てるし、変更箇所を安心して保存できるようになります。
  2. ウィキペディアの英語版とフランス語には新規参加者を見つめるモデレーター(調整役)がいて、その人たちの編集の質が改善したと気づくと、編集チェックでウィキペディアの編集の方針をどう提示したら良いか、考えるきっかけになっています。

現状

 
Mockup showing how Paste Check might appear to people pasting text into the visual editor.

Paste Check

The Editing Team is actively working on a new Edit Check: Paste Check.

Paste Check will prompt people pasting text into an article to confirm whether they did or did not write the content they attempting to add.

Now that the general scaffolding of the user experience is in place, we need help answering some open questions.

You can find the specific questions we need help answering on the talk page.

Note: thank you to @Pikne and Lectrician1 who helped inspire this Check.[1][2]

Edit Check work is ongoing in a few areas:

 
Reference Check demo at Wikimania (2024) by Selena Deckelmann, Wikimedia Foundation's Chief Product and Technology Officer
  1. T341308 - Refining the user experience for showing multiple Edit Checks within a single edit
  2. T360591 - Developing an API to increase the speed and ease with which new Edit Checks and Suggested Edits can be introduced within/alongside the visual editor.
  3. T364505 - Creating a UI framework to ensure people experience new Edit Checks and Suggested Edits as part of a common language
  4. T368274 - Researching the feasibility of using a large language model to detect peacock behavior within the edits people are making.

Looking ahead, the Editing Team will continue developing Edit Check during the 2024-2025 fiscal year. This work will support the Wiki Experiences Objective.

In other Edit Check news:

This Wednesday (3 July) from 17:30 until 18:50 UTC, the Editing Team will host the next Community Conversation.

Wednesday's conversation will be focused on the following Edit Check-related topics:

  1. Discussing the user experience for Paste Check. This next Edit Check we'll be introducing is meant to help newcomers adding new content unknowingly make a copyright violation.
  2. Reviewing the state of the Edit Check proejct. What Checks are available at what wikis? What new Check are being planned? More broadly, what strategy is guiding the Edit Check in this coming year? Etc.

On Tuesday (18 June), Reference Check became available by default at all Wikipedias except bn, de, en, hi, id, nl, pl, and ru.[3]

 
Feedback people will receive when attempting to link to a blocked domain within the visual editor.

Beginning Thursday (13 June), people who attempt to add an external link in the visual editor (desktop and mobile) will receive immediate feedback when they attempt to link to a domain a project has decided to block.

Link Check (as we are calling it) evaluates all external domains people attempt to link to against the following sources:

  • Local lists: MediaWiki:BlockedExternalDomains.json and MediaWiki:Spam-blacklist
  • Global list: meta:Spam_blacklist

Technical demo showing what it could be like for Edit Checks to appear within/alongside the editable surface.

Demo: Edit Checks while actively editing

Currently, people have the potential to encounter Edit Checks in one of two moments while editing:

  1. In the publishing flow, when people attempt to publish new content without a reference

In Citoid, when people attempt to cite a domain that a project has deemed worthy of blocking

While presenting Checks in the moments above have proven effective, for a while, volunteers and staff have been sharing ideas for Checks that could appear while people are actively adding/changing content within the article.

With this initial technical demo, the Editing Team is exploring what it could be like for Checks to:

  1. Appear within/alongside the editable document, in the moment when people make a change that causes a check to be activated
  2. Respond when people make a change that impacts the Check that they activated

What do you think about this idea? What questions/concerns/ideas/etc. does it bring to mind?

Please share what you think on the talk page!

References check A/B report is now available. Reference Check caused an increase in the quality of edits newcomers publish and did not cause any significant disruption.

編集チェックA/Bテスト (T342930) の最初の結果は次の結果を返した:

  • 編集チェックが利用できる場合、新人および若手の寄稿者は、新しいコンテンツ編集に新しい出典を追加する可能性が2.3倍高くなります。
  • 編集完了率と編集放棄率の大幅な低下は観測されませんでした。
  • 編集チェックは、初心者やモバイルのユーザーにとって特に影響があります。
  • 編集チェックが表示された場所では、編集チェックが表示されなかった場所と比較して、編集品質がわずかに低下するか変化がないことが観測されました。
  • 出典を含む新しいコンテンツ編集が元に戻される割合は増加します。影響についてはさらに調査する必要があります。

その結果、編集チェックがデフォルトとして A/B Wiki に配備されました。

Reference Reliability

On 7 March, the first iteration Reference Reliability check became available to everyone at all wikis, by default.

This means that whenever anyone attempts to cite a source that a project has blocked, they will be made aware directly within Citoid and prompted to try another source.

Where "blocked" on in this context means the domain someone is attempting to cite is lited on MediaWiki:Spam-blacklist or MediaWiki:BlockedExternalDomains.json.

進行中

  • 出典チェックの展開 - (出典の)編集チェック機能の1版目はウィキ22件で運用中です。 新規のウィキ群A/B 試験の対象になります。 利用者の皆さんが編集の途中でチェック機能を利用して作業を続けているかどうかを評価する予定です。
  • 多重チェック - 現状では、編集チェックの設定ではフィードバックは1件のみ表示しており、他にもフィードバックが正当化されたかどうかと結びついていません。 1回内の編集で多重チェックを表示できるように、ユーザー体験の設計が進行中です。

今後の予定

  • 出典の信頼性 - 出典の信頼性は、ソースが MediaWiki:Spam-blacklist または MediaWiki:BlockedExternalDomains.json の下にリストされているかどうかをユーザーに通知します。 展開は出典チェックのA/B 試験と並行して実施します。

進行中

 
ha.wikiの新人は、編集チェックを求められた後、追加していた新しいコンテンツを参照とともに追加しました。

今後の予定

  •  
    多重チェックのユーザー体験がどのようなものになるかを示す初期のモックアップ。
    ユーザースクリプト - 編集チェックはまもなく ユーザー スクリプト 経由で利用できるようになります。 これにより、評価対象のWikiに編集チェックが配備されているかどうか、またどのように配備されているかに関係なく、ボランティアが編集チェックを試すことが容易になります。
  • 多重チェック - 現在、編集チェックは他のフィードバックが保証されるかどうかに関係なく、ユーザーに1つのフィードバックを表示するように構成されています。 チームは、1回の編集内で多重チェックをユーザーに提示できるユーザー体験を設計する初期段階にあります。

 
編集チェック (出典の信頼性) 設計の検討

次の機能: 出典の信頼性

最初の編集チェック (editcheck-references) では、新しいコンテンツを追加するユーザーが、自分でそうしない場合でも出典を含めるように促されました。

次の編集チェックは、プロジェクトがスパムであると判断したドメインを引用しようとしたときに、ソースを置き換えるように促します。

編集チームはこれを、編集インターフェイスが w:WP:RSP などのページに保存されているコンセンサスを使用して、引用しようとしている情報源に関するフィードバックを人々に提供できるという潜在的な未来に向けた第一歩であると考えています。

私たちが検討しているデザインはここに掲載されています。

私たちは今あなたの助けが必要です: どのアプローチが最も気に入っていますか? そのアプローチについてどのような点を高く評価しますか? これらのアプローチによって、どのような疑問や懸念が思い浮かびますか?

トークページであなたの意見を共有してください!

 
ha.wikiにおける編集チェックの確認

先週の水曜日(2023年10月11日)、編集チェックは、Wikiの初期セットでデスクトップおよびモバイルのビジュアルエディター内で使用できるようになりました。 dag.wiki, ee.wiki, fat.wiki, gur.wiki, gpe.wiki, ha.wiki, kg.wiki, ln.wiki, tw.wiki

editcheck-references-activated タグを使用して Special:RecentChanges をフィルタリングすることで、編集チェックが有効になった編集内容を確認できます。

 
編集チェック偽陽性報告ページ

Reporting False Positives

Ahead of the first iteration of Edit check being 編集チェックを初回の繰り返し作業として提携先ウィキの初期の1群に提供する前に、誤検知を報告する右の新しいページ : 編集チェック/偽陽性 があります。

このページ Wikipedia:編集フィルター/誤検知 からインスピレーションを得ています。 人々が次のことを簡単に行えるように設計されています:

  1. 編集チェックが有効化されるべきではなかったと思われる編集を報告し
  2. 編集チェックの構成方法 に対する変更を提案します

私たちは –もしあれば– 質問、懸念事項、および/またはこの新しいページ に思い浮かぶアイデアを知りたいと思っています。

 
本番環境での編集チェック (en.wiki)

Trying Edit Check in production

現在、ビジュアルエディターを使用してメイン名前空間内のウィキペディアのページを編集することで、誰でも編集チェックを試すことができます。

編集チェックを試すには、編集したいページのURLに次のパラメータを追加してください: ecenable=1例: https://en.wikipedia.org/wiki/Jollof_rice?veaction=edit&ecenable=1

 
出典を含む新規コンテンツ編集の割合

Baseline metrics

 
ユーザー体験レベルごとに元に戻された新規コンテンツの編集の割合

編集機能チームは、次の指標2件を用いて、出典チェック導入の初期の波及効果を計測する計画です。

  1. 新規コンテンツ編集のうち元に戻された割合の減少
  2. 出典を含む新規コンテンツ編集の割合の増加

上記2つの指標の目標設定を支援するために、私たちは最近ベースライン分析を完了しました。 私たちが学んだことの一部は次のとおりです:

  • 全てのウィキペディアにわたって、出典を含む新規コンテンツ編集は、出典を含まない編集 (11.5%) よりも元に戻される可能性が ~2倍 低くなります (6.2%)
  • 全てのウィキペディアにわたって、新人や若手編集者は、上級編集者に比べて、新規コンテンツ編集に新しい出典を含める可能性が低いです。
    • 初心者がウィキペディア全体で行ったすべての新規コンテンツ編集のうち、12%には出典が含まれています。
    • ウィキペディア全体で500件以上の累積編集を行ったすべての新規コンテンツ編集者のうち、これらの編集の26%には出典が含まれています

ここの完全なレポートでWikiごとの内訳を確認できます。

応答拒否の保管と掲示

3月、編集チェックでソースの追加を求められたときにソースの追加を拒否した人に、その決定を下した理由を共有する方法を提示する計画を共有しました

この一週間、経験豊富なボランティアに私たちはどのように編集チェックが最初にこれらの応答を利用可能にするかについて話し合いました...

まず、編集チェックで出典の追加を勧められたときに、誰かが出典の追加を「拒否」した理由は、その編集に「追加」される編集タグとして記録されます。

これらの未定義のタグの定義は、最終的にここ: 編集チェック/タグ に保存されます。

2つの新しい変更タグ

今週、Special:RecentChangesをフィルターするために使用できる2つの新しい編集チェック関連のタグの変更 が利用可能になりました。

これらのタグは出典編集チェックによってユーザーが追加する新規コンテンツに出典を伴う可能性がどの程度高まるかを集合的に評価するのに役立ちます。

タグ 解説 試してみる
editcheck-newreference メイン名前空間の記事に「新しい」出典を追加することを人々に巻き込む「ビジュアルエディタ」を使用した編集。 en.wiki, fr.wiki
editcheck-newcontent メイン名前空間の記事に新しい記事を追加することを人々に巻き込む「ビジュアルエディタ」を使用した編集。 en.wiki, fr.wiki

注: 2つのタグがいつ適用されるかを決定するロジックは、出典編集チェックをユーザーに表示するかどうかを決定するために使用される同じロジックです。

出典編集チェックのデモ(モバイル)

編集チェックプロトタイプ (モバイル) 対応準備完了

最初の編集チェック用のプロトタイプが完成しました! 現在、実稼働環境でベータ機能として有効にする前に、どのように修正および改善する必要があるかを特定するために、皆様のご協力が必要です。

編集チェックプロトタイプを試してフィードバックを共有する手順については、トークページ: フィードバックの募集: 編集チェックプロトタイプ をご覧ください。

コンテキストとしては、この最初の編集チェックは、対応する「出典」を含めて「新規コンテンツ」を投稿している「初心者」に、そうすることを検討するよう促します。

 
What people who ''decline'' to add a citation when Edit Check invites them to do so might see.

First version

The first version of Edit Check is almost ready for you all to try!

Within the next week, you can expect us to share a link to a test wiki where you can try the Edit Check prototype.

This first iteration will invite people who add more than 50 new characters to an article in the main namespace to include a reference in the edit they're making, IF they have not already done so themselves.

In the meantime, you can see the kinds of edits EditCheck currently thinks warrant a reference, by filtering Recent changes using the newly-introduced editcheck-references tag. View the tag on en.wiki and fr.wiki.

Informed by community conversations (still ongoing)[4][5][6][7] and a series of technical and design investigations[8][9][10], during February the Editing Team became clear about the first version of Edit Check on mobile...

 
編集チェック機能の初期版でシステムが脚注の追加をうながすと、利用者はこんな体験をした。
  • User Experience: the first version of Edit Check will introduce a new step within the mobile visual editor's publishing workflow that people will see if/when they add new content without a reference. Design for the desktop user experience is still underway. See T329579.
  • Usability Testing: to learn whether people understand and can intuitively navigate the mobile Edit Check workflow, we will soon begin a series of usability tests. See T327356.
  • Technical Investigation: Edit Check will use a "transaction-based" approach for determining what new content is added within a given edit session. Work on developing a way to detect individual sentences is ongoing in T324363.
  • Initial Heuristic: To start, the initial Edit Check heuristic will be relatively straightforward in so far as it will prompt people to decide whether the change they are making warrants a reference if/when they are adding a new paragraph and that paragraph does not already contain a reference. See T324730 and T329988#8654867.

Next up: the Editing Team will be implementing the initial Edit Check heuristic (T324730) and a corresponding hidden change tag (T324733) so that we – volunteers and members of the Editing Team – can evaluate the extent to which the reference check heuristic is getting initiated in expected cases.

Work on Edit Check is underway! Below you will find an overview of what the Editing Team is actively working on…

  • Community conversations: Between October 2022 and January 2023, the Editing Team hosted seven community conversations to learn what contributing to Wikipedia has been like for people living in and from Sub-Saharan Africa. Next week, you can expect the team to publish the findings from these conversations and how they will inform the work we do on this project.
  • Initial Focus: The first feature the team will be introducing is one that checks whether the new content people are attempting to add includes a reference. Learn more in the Strategy and Approach section below.
  • Design: The team is actively working on a proposal for what the mobile user experience for the first reference check could be like. In the coming weeks, we will be inviting volunteers to help us revise and refine these designs. In the meantime, you can follow along with this work in Phabricator.
  • Talking with experienced volunteers: for the "reference check" to be useful to inexperienced and experienced volunteers alike, it will need to guide people to cite references in ways that projects expect. In the coming weeks, we'll begin conversations with experienced volunteers to learn what these expectations are so that we can ensure Edit Check is configured in ways that align with them.
  • Technical investigations: For the "reference check" to work, the software will need to know when people are attempting to add new content, whether that new content warrants a reference, and whether it currently contains a reference. The Editing Engineering team is currently doing a series of technical investigations to decide how we will approach building this functionality.

戦略とアプローチ

To equip newcomers and Junior Contributors from Sub-Saharan Africa with the know-how and tools to publish changes they are proud of and that experienced volunteers consider useful, the Editing Team will be introducing new functionality within the visual editor (desktop and mobile ) that will check the changes people are attempting to make and present them with actions they can take to improve these changes in ways that will align with established Wikipedia policies and guidelines.

The first "check" the Editing Team will be introducing is one that will detect when people are attempting to add new content to an existing article without a corresponding reference and prompt them to do so. The functionality will be accompanied by a complimentary set of features that will enable moderators to configure the user experience newcomers and Junior Contributors will see to ensure the software is guiding them to take actions that align with project policies and conventions.

問題点

The visual editor's growing popularity among people who are new to editing Wikipedia[11] leads us to think that the editing experience has been reasonably successful at helping inexperienced volunteers learn the technical skills necessary to publish changes to Wikipedia.

The trouble is that the visual editor and other editing interfaces do not make people aware of the Wikipedia policies and guidelines they are expected to follow.

As a result, the changes inexperienced volunteers publish often break established best practices and lead to undesirable outcomes for inexperienced volunteers, experienced volunteers, and Wikipedia projects as a whole:

  1. Inexperienced volunteers become disappointed and frustrated when the good-faith change(s) they arrived to the wiki seeking to make are undone (read: reverted), deleted, and/or scrutinized in inequitable ways. These poor interactions are demotivating and drive these could-be volunteers and community members, and the knowledge that are uniquely positioned to offer, away.[12]
  2. Experienced volunteers/moderators need to do more work reverting low-quality edits and posting messages on inexperienced volunteers' talk pages to make them aware of the policies and/or guidelines they are likely to have unknowingly broken. Continually needing to educate inexperienced volunteers and undo their changes can lead to experienced volunteers becoming skeptical of inexperienced volunteers and impatient with them.
  3. Wikipedia projects struggle to grow and diversify their volunteer populations and shrink the knowledge gaps present within Wikimedia wikis.

This project seeks to address the challenges above by:

  1. Offering inexperienced volunteers relevant and actionable feedback about Wikipedia policies in the precious moments when they are in the midst of making a change using the visual editor.
  2. Equipping moderators with a new ability to specify the feedback inexperienced volunteers are presented with while they are editing

変化の理論

This project is built on the belief that by surfacing relevant guidance in the precious moments when inexperienced volunteers are in the midst of making a change to Wikipedia and equipping them with the know-how and tools necessary to apply this guidance, they will make changes they are proud of and that experienced volunteers value.

In the longer term, the Editing Team thinks that people who are new, particularly people who have historically been excluded from and harmed by established power structures, will feel safe and motivated making changes to Wikipedia if they can accurately predict whether the changes they are attempting to make are aligned with existing Wikipedia policies, guidelines, and/or cultural conventions.

More broadly, the Editing Team thinks that to evolve towards a future where wikis' policies and cultural norms – and ultimately, content – reflect the diverse experiences of the people these projects are intended to serve, we first need to make the norms and standards that are currently in place legible and actionable to people while they are editing.[13] This way, volunteers can develop shared awareness of cases where these norms and standards are not having the impacts they were intended to have and decide what – if any – changes they think are worth making to them in response.

第一の観衆

編集機能チームではこの作業の主な対象として、以下の人々のニーズに着目します。

  1. 体験: ウィキペディア投稿入門編を学ぶ
    • 当プロジェクトの範囲では、「入門段階の人」を、言語版1件もしくは複数言語版のウィキペディアで編集回数の累計が100回未満の人と考えています。 これには、生まれて初めてウィキペディアの編集をしてみた人も含まれます。
  2. 場所: 生活の場はアフリカ・サハラ以南
  3. プロジェクト: 投稿先は英語とフランス語ウィキペディア
  4. 動機: ウィキペディアにある落差を埋めたいから

上記の重点基準4件は、次の作業に立脚しました。

  • 新規参加者の半数は、アフリカもしくはアジア在住の可能性が大です。[14]
  • ウィキメディア運動ではヨーロッパや北アメリカの圏外で暮らす編集者集めに苦心[14]
  • サハラ以南アフリカ在住の人々は、ウィキメディア運動できちんと代表されていません。サハラ以南の人々は世界人口の15%、インターネット世界人口の7%を占めているのに、ウィキメディアの個別編集者全体の1%に過ぎないのです。[15]
  • サハラ以南アフリカのアカウント登録済み編集者は、80%がウィキペディアの英語版またはフランス語版に投稿しています。[16]



設計

出典の検出

まず最初に、編集チェック機能の取り組みにおいて編集チームが目指すところとは、偽陽性の疑いを低減すること、プロジェクト単位で[17]に沿って実施することでボランティアを支援、やがては進化によって自己改革[18] をより強固にしていこうとしています。

この戦略を進めると、編集チェックを有効にするタイミングと前提は、以下の条件全てを満たかどうかになります。

  1. 誰かが編集中の記事に、新たに追加された段落が1件以上ある場合
  2. 「新たに追加された段落」には、脚注は含みません
  3. 条件「1.」と「2.」の変更は記事名前空間(メイン空間)のページで実施した場合 (NS:0)

上記の条件は実施と管理を書いたコードはこちら:editcheck/init.js

当編集機能チームが達した結論とは、手始めに点数を絞り込み複雑ではないルールの組み合わせで開始 してみることにして、次の目的を目指しました。

  1. 編集初学者とジュニア投稿者が編集チェックを使ってガイダンスに気づくこと、編集という体験をもっと広い目で見ることができるようになること、編集ヘックが直感的でわかりやすく、もう一度、編集しようと戻ってくるように導くこと。
  2. 編集チェックが原因で、経験を積んだボランティアの作業を増やしてしまわないように、無用な箇所なのに編集初学者やジュニア投稿者に出典を追加するように促さないこと。

You can learn more about the assumptions that informed the thinking above in phab:T329988#8654867.

その他の応用編

関連項目: Edit check/Ideas

設定が可能なこと

当編集機能チームでは調整役の皆さんに設定権限を預かってもらい、編集チェック機能を有効にするタイミングと対象を決めてもらうことを重視しています。この方法でなら、このソフトウェアが調整役の皆さんから見て、生産的と認める動作を促していると確信してもらい、そうでなかった場合にはソフトウェアを改変できます。

上述との整合性を保ち、また編集フィルタ機能やGrowthチームとコミュニティによる設定作業ではボランティアの皆さんがどのようにしてウィキ上でそれぞれの機能の動作確認と構成変更ができたか発想を借りており、編集チェックの場合は、システム導入によりボランティアはプロジェクト単位で、次のことが可能になります。

  • 編集チェックがいつ発動するか決定するロジックを監査および編集し、
  • 編集チェックが表示されている利用者がどんな内容の編集をしているか評価する

これらを実施するため、作業をphab:T327959で進めています。

利用者の体験(UX)

モバイル版

編集チェック機能の初版では、モバイル版 のビジュアル編集機能の公開ワークフローに新しい手順を導入、新しいコンテンツを加筆して出典を添付しなかった場合 に発動させます。

デスクトップ版

デスクトップ版の利用者体験の設計はまだ進行中です。 T329579 を参照してください。

Experiments

Reference Check A/B Test

To learn whether the Reference Edit Check is effective at causing newcomers to make edits they intended and experienced volunteers value, we conducted an A/B test with 15 Wikipedias.

Below you can read more about what this experiment demonstrated, what the Editing Team is planning in response, and more details about the test's design.

Conclusion and next step(s)

Reference Check caused an increase in the quality of edits newcomers publish and did not cause any significant disruption.

This combination is leading the Editing Team to be confident that offering Reference Check as a default-on feature would have a net positive impact on all wikis and the people who contribute to them.

You can read the full A/B test report here.

Findings

 
There was 2x increase in the proportion of new content edits by newcomers, Junior contributors, and unregistered users that included a reference when Reference Check was shown to eligible edits.

New content edits *with* a reference

People shown the Reference Check are 2.2 times more likely to publish a new content edit that includes a reference and is constructive (not reverted within 48 hours).

  • Increases were observed across all reviewed user types, wikis, and platforms.
  • The highest observed increase was on mobile where contributors are 4.2 times more likely to publish a constructive new content edit with a reference when Reference Check was shown to eligible edits.

Revert rate

  • New content edit revert rate decreased by 8.6% if Reference Check was available.
    • New content edits by contributors from Sub-Saharan Africa are 53% less likely to be reverted when Reference Check is shown to eligible edits.
    •  
      We observed increases on both desktop and mobile. On mobile, users are 4.2 times more likely to include a reference with their new content when the reference check is shown to eligible edits.
      While some non-constructive new content edits with a reference were introduced by this feature (5 percentage point increase), there was a higher proportion of constructive new content edits with a reference added (23.4 percentage point increase). As a result, we observed an overall increase in the quality of new content edits.
 
There was a -8.6% decrease in the revert rate of all new content edits comparing edits where Reference Check was shown in the test group to edits that were eligible but not shown Reference Check in the control group.

Constructive Retention Rate

  • Contributors that are shown Reference Check and successfully save a non-reverted edit are 16 percent more likely to return to make a non-reverted edit in their second month (31-60 days after).
    • This increase was primarily observed for desktop edits. There was a non-statistically significant difference observed on mobile.

Guardrails

Edit Completion Rate

  • We observed no drastic decreases in edit completion rate from intent to save (where Reference Check is shown) to save success overall or by wiki.
  • Overall, there was a 10% decrease in edit completion rate for edits where Reference Check was shown.
    • There was a higher observed decrease in edit completion rate on mobile compared to desktop. On mobile, edit completion rate decreased by -24.3% while on desktop it decreased by -3.1%.

Block Rate

  • There were decreases or no changes in the rate of users blocked after after being shown Reference Check and publishing an edit compared to users in the control group.

False Negative Rate

  • There was a low false negative rate. Only 1.8% of all published new content edits in the test group did not include a new reference and were not shown Reference Check.

False Positive Rate

  • 6.6% of contributors dismissed adding a citation because they indicated the new content being added does not need a reference. This was the least selected decline option overall.

Test design

11 Wikipedias participated in the test. At each wiki, 50% of users were randomly assigned to a test group and 50% were assigned to a control group.

Users in the test group were shown the Reference Check notice prompting them to decide whether the new content they were adding need a reference (if they had not already added one themselves).

User in the control group were shown the default editing experience, even if they did not accompany the new content they were adding with a reference.

Timing

This analysis was completed on 16 April 2024 and analyzed engagement data at the 11 participating wikis from 18 February 2024 through 4 April 2024.

Evaluating impact

The viability of the features introduced as part of the Edit Check project depends on the impacts it causes and averts.[19]

This section describes the:

  1. Impacts the features introduced as part of the Edit Check are intended to cause and avert
  2. Data we will use to help[20] determine the extent to which a feature has/has not caused a particular impact
  3. Evaluation methods we will use to gather the data necessary to determine the impact of a given feature
Desirable Outcomes[21]
ID Outcome Data Evaluation Method(s)
1. Increase the quality of edits newcomers and Junior Contributors editing from within Sub-Saharan Africa publish in the main namespace Decrease in the proportion of published edits that add new content and are reverted within 48 hours or have a high revision risk score

Comments/reports from experienced volunteers about the quality of edits Edit Check is activated within[22]

A/B test[23], qualitative feedback (e.g. talk page discussions, false positive reporting)
2. Increase the likelihood that newcomers and Junior Contributors editing from within Sub-Saharan Africa will accompany the new content they are adding with a reference Increase in the percentage of published edits that add new content and include a reference

Increase in the percent of newcomers or Junior Contributors from SSA that publish at least one new content edit that includes a reference

Increase in the likelihood that someone includes a reference the next time they contribute new content.

A/B test[23]
3. Newcomers and Junior Contributors editing from within Sub-Saharan Africa will report feeling safe and confident making changes to Wikipedia Newcomers and Junior Contributors find the feedback and calls to action Edit Check presents them with to be:
  1. Helpful
  2. Supportive
  3. Motivating
Qualitative feedback via channels like:Community Calls, talk pages, event organizers, etc.
4. Experienced volunteers will independently audit and iterate upon Edit Check's default configurations to ensure Edit Check is causing newcomers and Junior Contributors to make productive edits.
5. Newcomers and Junior Contributors will be more aware of the need to add a reference when contributing new content because the visual editor will prompt them to do so in cases where they have not done so themselves. Increase in the percent of newcomers or Junior Contributors from SSA that publish at least one new content edit that includes a reference. A/B test[23]
Risks (Undesirable Outcomes)[24]
ID Outcome Data Evaluation Method(s)
1. Edit quality decreases Increase in the proportion of published edits that add new content and are reverted within 48 hours or have a high revision risk score

Comments/reports from experienced volunteers about the quality of edits Edit Check is activated within[22]

A/B test[23], qualitative review and feedback
2. Edits become more difficult to patrol because unreliable citations are difficult to detect Significant increase in the percentage of new content edits new and developing volunteers make that include a reference

Comments/reports from experienced volunteers about the quality of edits Edit Check is activated within[22]

A/B test[23], qualitative review and feedback
3. Edit completion rate drastically decreases Proportion of edits that are started (event.action = init) that are successfully published (event.action = saveSuccess). A/B test[23]
4. Edit abandonment rate drastically increases Proportion of contributors that are presented Edit Check feedback and abandon their edits (indicated by event.action = abort and event.abort_type = abandon) A/B test[23]
5. Blocks increase Proportion of contributors blocked after publishing an edit where Edit Check was shown is significantly higher than edits in which Edit Check was not shown A/B test[23]
6. High false positive or false negative rates Proportion of new content edits published without a reference and without being shown Edit Check (indicator of false negative)

Proportion of contributors that dismiss adding a citation and select "I didn't add new information" or other indicator that the change they are making doesn't require a citation

A/B test[23], qualitative feedback received from volunteers about the accuracy and usefulness of Edit Check's current configuration [25]
7. Edit Check is too resource intensive to scale Efficiencies do not emerge over time making each new Edit Check as "expensive" to implement as the first one Qualitative assessment by the Edting team

Deployment process

Please see Deployment status#Deployment process .

背景

ウィキメディア運動の各所で活動するボランティアの皆さんは、長い間、次の作業に骨を折ってこられました。

  • 積極的に編集初学者を教え、ウィキペディアを改善する変更を指導し、本人にとってやりがいのある変更になるようにすること
  • 予防として利用者が破壊的な変更を後悔しないようにすること、それに加えて
  • 対応および仲裁としてウィキペディアの記事の変更点に介入すること。

いくつかの先行例から当編集機能チームならびにこのプロジェクトはインスピレーションを得ており、その一部を以下に述べます。 もし皆さんから、目を配っておくと良いプロジェクトあるいは情報源のおすすめがありましたら、トークページで発言をお願いします。

イニシアティブ 説明 導入の要素
CopyPatrol Tool that allows you to see recent Wikipedia edits that are flagged as possible copyright violations Community Tech Team
paper: Automatically Neutralizing Subjective Bias in Text Method for automatically bringing inappropriately subjective text into a neutral point of view ("neutralizing" biased text). Reid Pryzant, Richard Diehl Martinez, Nathan Dass, Sadao Kurohashi, Dan Jurafsky, Diyi Yang
Wikipedia:Citation watchlist User script that adds visual indicators to watchlist and recent changes entries when unreliable sources are added to articles. Harej, Ocaasi
Internet Archive Reference Explorer Explore references included in Wikipedia articles via a range of criteria
WikiScore A tool created to validate edits and count scores of participants in wikicontests.
Earwig's Copyvio Detector This tool attempts to detect copyright violations in articles. The Earwig
CiteUnseen A user script that adds categorical icons to Wikipedia citations, providing readers and editors a quick initial evaluation of citations at a glance. SuperHamster
Credibility bot Monitors and collects data on source usage within Wikipedia articles Harej
Salebot (fr.wiki) A counter-vandalism bot that uses regex to identify issues.
Edit intros (en.wiki) A message is shown automatically when editing a page categorized as either Category:Living people or Category:Possibly living people.
ビジュアルエディタ機能で編集の通知をもっと目立つように表示 編集作業中の人を対象に現状では 編集の通知機能でお知らせしている内容を表示し、その情報を「自分のものにする」ように働きかけるには?(内省化) User:Stjn
インターネット・アーカイブが提供する出典検索機能 情報源の品質を自動検出 Ocaasi
要望:新規記事の作成時に、出典の提示を要件とすること 脚注がない新規の記事が必要 User:Mega809
編集の通知 編集画面の上部に、ボランティア個人ごと、プロジェクトごとに特性の通知を表示でき、ページや名前空間その他の状況ごとに調整可能。
ページ通知
メンテナンス用テンプレート
Extension:AbuseFilter 権限を預かる利用者は、引き金となる他の利用者による操作、例えば編集などの条件に一致すると、特定の対処操作を設定できるようにします。
Extension:Disambiguator 曖昧さ回避ページへのリンクを追加した利用者が2006年版/2010年版のウィキ文 編集機能を使っていたら、画面に通知を表示。 Community Tech
ORES Halfak (WMF)
おすすめ編集機能
CiteHighlighter 情報源 1800 件をそれぞれの信頼性の評価にしたがい、緑色、黄色、オレンジ色、赤のどれかで強調表示。 Novem Linguae
Checkwiki ウィキペディアのソースコードに照らし、構文その他のエラーのクリーンアップを補佐 Stefan Kühn, Bgwhite
編集の差分をタグ付け ウィキペディアの該当する編集の差分を対象に、自動的に評価できるさまざまなタグを並べる (通常は基本的なヒューリスティクスを援用) Isaac (WMF)
CivilityCheck ウィキコミュニティ内の虐待問題の対処と編集者の減少防止を目指すプロジェクトとして、ウィキペディアの議論ページのコメントを対象に礼儀の良・不良を評価。 Deus Nsenga, Baelul Haile, David Ihim, and Elan Houticolo-Retzler
BOTutor botを運用して投稿しようとする人にメッセージを発信、その編集は既存のルール類に違反すると知らせる ValeJappo
Gadget-autocomplete.js ערן
Text reactions ひとつの提案 として、 利用者が編集欄に記入した内容に編集インタフェースが対応 できるようにすること SD0001
Editwizard 編集初学者がウィキペディアの記事に加筆しようとするとき、加筆の内容に出典を書く手順をステップ単位で指導 Ankit18gupta, Enterprisey, Firefly, and SD0001
Headbomb/unreliable "スクリプトはリンクの信頼性の〈深刻度〉に応じて、さまざまな情報源ごとに分類。 一般論としてはこのスクリプトをWP:RSPSOURCESに適合させ、多少の誤差はあるにせよ{{Predatory open access source list}}やWP:NPPSGWP:SPSLIST(全面運用は準備中)や WP:CITEWATCHどの整合性を図ります。" Headbomb, SD0001
The Wikipedia Adventure Game based on the tech of Extension:GuidedTour that teaches basic wikitext markup and the rules about reliable sources and neutral point of view. Research into its effectiveness is described at meta:Research:Impact of The Wikipedia Adventure on new editor retention. Ocaasi
w:Help:Introduction 英語版ウィキペディアの場合、編集初学者対象のチュートリアルとは方針を覚えること、ビジュアルエディタとウィキ文の両方で技術的な研修が占めています。 直近の改訂は2020年後半で、管理はTWA(Trusted Web Activities)の方が実際に進んでいます。 Sdkb, Evolution and evolvability, and others
User:Phlsph7/
HighlightUnreferencedPassages
このユーザスクリプトは出典がない文に赤帯を敷いて、強調表示します。 主眼は記事名前空間と下書き空間を対象に、文中で出典のない文や文章、節が簡単に見つかること Phlsph7
Wish: Add notice to the visual editor that unsourced edits may be reverted ビジュアルエディタの利用者に「変更を保存」のダイアログで出典のない編集は削除されると知らせる User:Lectrician1
Wish: Warn when adding a url reference that matches the SpamBlacklist 典拠としてURLを加筆したとき、それがブラックリスト SpamBlacklist に登録済みの場合に警告(して除去?)、ページ保存の時に同じ警告が表示されないようにする。 User:DSan
Edit FIler #686 この編集フィルタが発動するタイミングとは、編集初学者が存命の人物の伝記ページ(BLP)に出典のない記述を加えたとき。 User:Rich Farmbrough
WikiLearn 研修用のプラットフォーム
DannyS712/copyvio-check.js 新規立項したページのバックグラウンドで著作権違反の割合を検証してレポートを作成、その情報を同レポートへのリンク付きで、ページ検証ツールバーの「情報」パネルに表示する。 DannyS712
XLinkBot ボットの作業として、外部リンクを追加した編集に、そのサイトはこれこれの理由で適切ではないと警告する。 Versageek, Beetstra

関連項目

脚注

  1. T300942#9597055 via @Pikne
  2. T300942#9597611
  3. Reference Check will be made available to remaining wikis via T366381 and T367343.
  4. Editing team/Community Conversations#January 2023
  5. T327330
  6. Talk:Edit check#So glad to see!
  7. en:When should newcomers be prompted to add sources?
  8. T324364
  9. T323145
  10. T326856
  11. Superset: Wikipedia edits by interface and experience level
  12. Growth Team: IP editing Research Report
  13. The Tyranny of Structurelessness
  14. 14.0 14.1 コミュニティの洞察2021年報告書
  15. 四半期単位の地域学習セッション(2022年6月、Google文書形式)
  16. Superset
  17. T327959
  18. T324730
  19. Where "viability" in this context refers to a feature being fit for being scaled to all projects as determined by the extent to which it has been proven to have a net positive impact on wikis and the volunteers who build and maintain them.
  20. Emphasis on "help" seeing as how all decisions will depend on a variety of data, all of which need to be weighted and considered to make informed decisions.
  21. T325838: Finish Edit Check measurement plan proposal
  22. 22.0 22.1 22.2 At every project where Edit Check is available, volunteers will be able to use the editcheck-reference-activated tag to review edits where the reference check is shown to people in the process of publishing an edit. Learn more about Edit Check tags.
  23. 23.0 23.1 23.2 23.3 23.4 23.5 23.6 23.7 23.8 [Analysis] Run an A/B test to evaluate Edit Check (references) impact
  24. T325851: Conduct pre-mortem for Edit Check project
  25. In addition to existing feedback channels (Phabricator, talk pages, etc.) there will be a minimum of two additional ways for people to share feedback about Edit Check: A) reporting edits that you think Edit Check should not have been shown within and B) declining to add a reference mid-edit by indicating you think Edit Check was shown when it shouldn't have been.