Growth/Personalized first day/構造化タスク
|
Newcomer tasks
 Recommend tasks to newcomers that help them start editing
|
このページではGrowthチームが取り組む「構造化タスク」プロジェクトについて記述します。このプロジェクトは、「新規参加者タスク」および「新規参加者ホームページ」プロジェクトに関連します。 このページでは主要なアセット、設計、決定課題、意思決定について述べます。 進行中の増分更新のほとんどは全般的なGrowthチームの更新ページに投稿されます。このページにはいくつかの大規模または詳細な更新を掲載します。
このページは全般的な「構造化タスク」の概念を扱い、チームが構築できそうな特定の種類のタスクを協議する場でもあります。ここでの全般的な議論を受け、それぞれの特定のタスクの設計およびエンジニアリングを始めました。これらのタスクの種類ごとに独自のプロジェクトページを設けており、新しい情報の大半はそちらに投稿されています:
現状
- 2020-05-01: 最初のメモを計画と文書化
- 2020-05-17: コミュニティの議論を開始する
- 2020-05-29: 最初のワイヤーフレーム
- 2020-08-24: この週は今後のミーティング予定を立てる
- 2020-09-08: 設計最新版について、コミュニティに協議を呼びかける
- 2020-10-21: デスクトップ版設計の利用者テストを実施
- 2021-05-27: 「リンクを追加」機能を4つの早期導入ウィキペディア（アラビア語、チェコ語、ベトナム語、ベンガル語）に展開。
- 2021-07-21: より多くのウィキペディアに「リンクの追加」の拡大を継続 (T304110)
- 2022-08-20: 構造化タスクに関する巡回者のフィードバックに対処する作業を開始 (T315732)
- 2022-09-02: 新規参加者タスクの編集の種類の分析を公開
要約
Growth チームでは2019年11月に「新規参加者タスク」を実装、各人の新規参加者ホームページにお勧めの編集作業をいくつか提供しはじめました。 2020年4月時点では、経験を積んだ編集者が適用したメンテナンステンプレートがある記事のみを提案し、新規参加者にどの文、単語、あるいは節に特に注目する必要があるかという具体的な指示は与えません。 それでも新規参加者がお勧めのページで生産的な編集を続けていることは喜ばしい傾向です。
メンテナンステンプレートは新規参加者に様々な種類の編集を提供できるものの、新規参加者には広範すぎたり終わりがなく成功に結びつかないかもしれません。さらに携帯端末では、小さな画面で新規参加者がビジュアルエディタやウィキテキストエディタを使うと圧倒されてしまうかもしれません。
したがって、「構造化タスク」という発想を試行したいと考えます。 これは編集のワークフロー（作業手順）を連続する複数の段階に切り分け、新規参加者が1段階ずつ完成するようにまとめるという発想です。 先行するAndroid版ならびに言語部門の成功事例を追って、この種の編集なら新規参加者が取り組みやすく、携帯端末でも作業が楽で、新規参加者が編集実績を増やす支援ができると考察します。 新規参加者には、新規参加者タスクプロジェクトの一環として構造化タスクを提供します。
背景
編集作業はややこしい
私たち Growth チームの経験知から、新規参加者はウィキで歩み始めると、ごく初期の体験で活動を続けたいか辞めたいか決まる傾向にあります。 新規参加者がすばやく編集して肯定的な経験をできれば、活動を続けたくなると信じています。 ところがウィキペディアへの貢献は -- ほとんどどの方法であっても -- ややこしくて、新規参加者がすばやく成功体験を積むのを難しくしています。 一例として、記事にたった1文を加筆するような単純なことのために、たくさんの手順を必要とします：
- 正しい記事を検索する。
- 自分が加筆したい情報がその記事に欠けているかどうか確認。
- その加筆をする節を選択。
- クリックして編集を開始。
- 正しい位置に文を加筆。
- 出典ボタンを押す。
- 情報源を開き、リンクもしくは出典情報を確認。
- 出典フォームの各欄に記入して、終わったら保存。
- 保存用のボタンを押す。
- 編集の要約を記入。
- 公開する。
新規参加者がビジュアルエディターまたはウィキテキスト エディターを開いても上記のような手順があるとは書いてないし、それぞれの順序や、どのボタンを押すと上記のリストのどの作業ができるのかさえ、説明がありません。 これを換言するなら、新規参加者の経験は構造化されていないのです。 ただ圧倒されて去ってしまうかもしれません。 あるいは試行錯誤して、失敗したせいで、経験を積んだ編集者から否定的な意見を受け取るかもしれません。 そこがこのプロジェクトの出番です: 新規参加者がワークフローを正しい順番でこなすには、私たちはどんな補助をすればよいか？
他の部門の知見を援用
編集ワークフローの構造化は、ウィキメディアのプロジェクト群にとって長年の課題でした。たとえばいくつかの例をあげます。
- HotCat：利用者がウィキテキストを手動で入力することなく、数回クリックするだけでカテゴリを選択して記事に追加することができようにします。
- コモンズ・アップロード・ウィザード：コモンズにメディアを投稿する手順を段階分けし、簡単なステップの連続に変えます。
- Citoid：ビジュアルエディタに付属する拡張機能。出典を追加する手順をいくつかの段階に分解し、出典の記述およびテンプレートを自動生成するアルゴリズムを組み込んであります。
最近、「構造化タスク」という発想がウィキペディアの Androidアプリならびにコンテンツ翻訳拡張機能で成果を上げています。それらの取り組みからひらめきを得ました。
Android チームの取り組みでは「おすすめ編集」プロジェクトを作成、ウィキペディアの題名について説明文を書き込む作業をワンステップ化、専用の入力ボックスに記入するだけに変えました。 記事題名の説明文に関しては、その翻訳も同様にワンステップ化。 構造化したワークフローなしで同じタスクをこなすには、利用者はウィキデータへ移動し、複数の段階を経て同じ編集をする必要があります。 担当チームはこの方法がうまくいくことを知りました：多くのAndroid利用者がこうした小さな貢献を何百件もこなしています。
言語チームが開発したコンテンツ翻訳ツールはいくつかのことをして、記事を翻訳する工程を構造化しました。 翻訳作業用の欄を横に並べたインターフェースを開発、また翻訳原文をいくつかのブロックに切り分け、機械翻訳のアルゴリズムで自動処理します。 ウィキペディアンはこのツールがなくても記事の翻訳ができていましたが、多くの手動の手順が必要とされるため非常に面倒でした。 コンテンツ翻訳ツールは普及しており、翻訳記事が10万件単位で増加しています。 記事の翻訳が段階に分けてあると、機械的な（決まりきった）部分を（例えば機械翻訳を実行して）自動的に処理するによって、より多くの記事が翻訳されることがわかりました。
私たち Growth チームでも記事のコンテンツ編集に同様の原則を取り入れられないか、たとえばリンクや画像、出典の追加や、加筆に応用できないか検討しています。
-
ウィキペディアAndroidアプリでは「おすすめ編集」が表示され、例えばタイトルの説明の翻訳を、ウィキデータに移動することなく、利用者は簡単なワンステップで編集できます。
-
コンテンツ翻訳ツールは記事の翻訳作業を原文の節単位に分解、機械翻訳の自動化アルゴリズムから支援を受けます。
構造化タスクのスケッチ
構造化タスクに関する我々の考えを説明するには、簡単な状況設定を示すのが最善の方法かもしれません。最初に考えた構造化タスクは、「（内部）リンクの追加」でした。しかし同じアイディアは「画像の追加」、「出典の追加」あるいは「事実の追加」に対してさえ構造化タスクに適用できるかもしれません。
新規参加者タスク機能では、多くの新規参加者が「（ウィキ）リンクの追加」タスク -- 青リンクが少ない記事に内部リンクを追加する作業を完遂しています。 はじめに取り組むには、簡単な編集タスクといえそうです。 しかし、多くの新規参加者はどうやってリンクを追加する手順を踏めばいいのか理解できないかもしれませんし、リンクを追加すべき単語がわからないかもしれないと我々は考えています。 リンクするのに最善と思われる単語を考えることができるアルゴリズムで支援して、新規参加者に1段階ずつ作業の段取りを説明するワークフローを想定しています。
以下のスケッチでは、新規参加者がページを訪れ、（内部）リンクすると良いかもしれない単語の提案を受けます。 リンクすべきだと同意するならば、リンクを作成する手順をひと通り説明します。 この方法なら将来、自分でリンクを作る役に立つと期待されます -- そしてもしかするとアルゴリズムによるリンクの提案を受け取り続けるかもしれません。 アルゴリズムに関してはウィキメディア財団の調査チームが初期の作業を実施しており、懸案のアルゴリズムは十分に実現できると確信しています。
この発想から、さらに第2案を大まかに考えました。 次のワークフローでは、新規参加者にビジュアルエディタを使ってリンクを追加することを教える代わりに、アルゴリズムからのおすすめを利用者は承認するか却下するかすばやく判断して直接、記事を編集します。 こちらではエディタでリンクを追加する方法を教えない代わりに、新規参加者が大量に編集するのに役に立ち、実力を身につける段階でも単純なタスクで生産的な活動をしようと試みる利用者には、こちらの方が適している可能性があります。 あるいは、Androidアプリに記事の題名の説明 だけ書きたい利用者がたくさんいるのと同じように、とても簡単な編集だけやりたい利用者に適しているかもしれません。
構造化タスクについて考えると、これが大きな疑問に思えるかもしれません：ワークフローは、新規参加者に従来のツールの使い方を教えることを目的とすべきなのか、それとも新規参加者が単純な編集を大量にこなすことができるようにすることを目的とすべきなのか？
この案を優先する根拠
手間をかけずに生産的な編集ができると、新規参加者の達成感につながると考えました。 編集作業を少し経験すると、ウィキでの経験はたちまち豊かに感じられます。 新規参加者は自分の編集の影響を理解したり、感謝の通知が来たり、基礎知識を学んで指導役に質問したり、自分の利用者ページを作ることなどもできるようになります。 そこで、できるだけ多くの新規参加者に、さっそく編集作業を始めてもらいたいのです。 新規参加者タスクのプロジェクトから、多くの新規参加者が簡単なタスクを探していることが既にわかっていました。 しかし以下のようなことも観察していました：
- 新規参加者でおすすめ編集をクリックし、実際に編集したのはたった 25% 前後。
- おすすめ編集に着手した人で別のおすすめもやったのはたった 25% 前後。
- おすすめ編集を実際に達成し、多数のタスクを毎日こなしている新規参加者も一握りはいます。これは新規参加者がウィキの作業を大量に達成できる可能性を示しています。
- ライブ利用者テストで、新規参加者に記事の校正あるいはリンク追加を頼んだとき、正確にはどの文章もしくは単語が作業の対象なのか、しばしば被験者から質問されます。換言するなら、編集を試みるときに記事全体では大まかすぎます。
これらの所見と前述の Android アプリの利用者の傾向、コンテンツ翻訳機能の担当チームの経験知などを踏まえると、ウィキペディアのコンテンツ編集の一部を構造化することで、編集を始める新規参加者を増やし、さらに続けてもらうことができると考えます。
構造化タスクで得られる好機
編集のワークフローをいくつかの段階に分解し、これを「構造化タスク」と呼ぶことにします。その方法に見込まれる利点には以下のものが含まれます。
- 新規参加者が有意義な貢献をしやすくなる。
- モバイルでわかる編集ワークフローを開発すること。モバイル設計の原理に従うと、利用者には複雑な作業スペースではなく、1つずつ手順を見せるべきです。
- 新規参加者に段階的に腕を上げてもらうこと。すると難度が高い種類のタスクでも、うまく達成できるようになるはずです。
- 人々が自分にぴったりの編集経験と出会えるようにすること。新規参加者に構造化タスクを供給することによって、自分の好みのタスクを見つけることができます。
- 将来的には、経験を積んだ編集者にも同様のワークフローを提供することができそうです。
構造化タスクへの懸念と短所
ウィキペディアの編集に新しい手法を導入するたび、うまくいかないことも多く発生します。
- 編集をあまりにもすばやく簡単にできるようにしてしまうと、荒らしや、編集するときに十分な注意を払わない利用者を引き込んでしまうかもしれません。
- 新規参加者に簡単なワークフローを与えると、最も影響力のある編集に不可欠な従来の編集ツールを学ぶチャンスを奪ってしまうかもしれません。
- 構造化タスクは言語の違い、あるいはウィキテキストの特異性を考慮するのは苦手で、他の種類のバグを引き起こしてしまうかもしれません。
- 構造化タスクを表面化させるアルゴリズムの精度が不十分で、新規参加者が手を出すべきでない編集作業を誤ってお勧めしてしまうかもしれません。
コミュニティの議論
2020年5月に6言語（英語版、フランス語版、朝鮮語版、アラビア語版、ベトナム語版、チェコ語版）のコミュニティと前述の構造化タスクのアイディアについて協議しました。 英語の議論は主にこちらの議論ページ、とその他の英語版ウィキペディアでの対話と共に実施され、ローカル言語の対話はその他5つのウィキペディアで実施されました。 コミュニティの35人のメンバーに聞き取りを行っており、この節では最も人気があり興味深い考えを要約します。 これらの議論は設計の次の段階に大きく影響しました。
- コミュニティのメンバーは、構造化タスクが新規参加者が編集を開始する手助けする可能性について概ね肯定的でした。しかし、その過程で新規参加者に従来のソースエディタとビジュアルエディタを紹介することも重要であるという指摘が多くありました。コミュニティのメンバーは、新規参加者を切り離された編集体験に閉じ込めるのではなく、もっと価値のある編集方法を見つけることができるようにしてほしいと考えています。
- チェコ語のコミュニティは構造化タスクをビジュアルエディタの内部に取り込むことで新規参加者がエディタを使って始められるようにする方法についてアイディアを語りました。もしかすると構造化タスクに必要とされない編集ツールは、グレーアウトする（対象から外す）ことができるかもしれません。
- コミュニティのメンバーから、なぜもっと価値の高い種類の編集ではなく「リンクの追加」を最初の構造化タスクとして選択したのか尋ねられました。このタスクが構築するのが最も簡単で、構造化タスクからすぐに知識を得るための試作品として役に立ち、新規参加者が記事に害を及ぼす可能性が低く、リスクが比較的低いタスクであることを説明しました。
- 単語のつづり（スペル）の訂正は特に重要な課題であると複数のコミュニティで言及されており、間違っているかもしれないスペルの一覧を生成する方法の技術的な選択肢に関して我々は議論しました。さらなる詳細はこれらのメモをご参照ください。
- 荒らしの差し戻しが新規参加者に適するかどうかに関しても話し合いました。明確な答えはなさそうで、将来的に議論する余地が残りました。
- もっと難しいタスクへ「新規参加者をステップアップ」する方法は何度も繰り返し出てきた発想で、おそらくは簡単なタスクに成功すると何かごほうびがもらえる設定が良いかどうかです。
タスクの種類
構造化できる可能性のある編集のワークフローには、様々な種類があります。 新規参加者タスクのワークフローをこちらで設計した時、ワークフローのリストづくりを開始しており、その後、構造化に最適なものを短いリストにまとめ直しました。 それらに仮の優先順位を付けて、以下の表にまとめます。
| 仮の優先順位 | タスクの種類 | うまくいきそうな点 | 利点 | 懸念 |
|---|---|---|---|---|
| 1 | Add a link | For articles without enough wikilinks, an algorithm (existing) suggests words or phrases that should become wikilinks, and the newcomer accepts or rejects the suggestions. | Linking is a quick and easy way to edit, and has low potential to damage articles. | Understanding when to add a link takes judgment, and we don't want articles to be overlinked. It is also not the most valuable type of edit. |
| 2 | Add an image | For articles without an illustration, an algorithm (potential) suggests an image from Commons. This might be a simple algorithm that just looks at what images are used on that article in other languages. The newcomer decides if the image belongs, and where in the article to add it. | Good images make a big difference in an article, and newcomers are interested in adding images. | Adding the wrong image to an article could damage the article in a very visible way. |
| 3 | Add a reference | Some sentences or paragraphs clearly need citations. An algorithm (in development) would point out which sentences likely need suggestions, and the newcomer would seek sources to add as citations in a step-by-step workflow. | References are of clear importance to the core of the encyclopedia. | This task may not be exciting to newcomers. They may also struggle to find and use sources without guidance. |
| 4 | Copyedit | Using open-source spellcheck dictionaries and code, or using Wiktionary, identify likely misspelled words, and point them out to newcomers, who can use the visual editor or wikitext editor to fix them one at a time. | Clearly valuable and needed in any wiki, satisfying to newcomers. Helps them start editing the main text of articles, as opposed to peripherals parts of the article. | Scaling to any language may be difficult, depending on the availability of good spellchecking algorithms. |
| 5 | Add a section | An algorithm detects when an article could use additional sections, based on the kinds of section headers that similar articles have (e.g. all biographies of scientists tend to have "Publications" sections). The newcomer is walked through producing a well-referenced paragraph. | Real content additions that could help close knowledge gaps. | A much more challenging task than the others, requiring many wiki skills to be used together. May produce low-quality content. |
Prioritizing "add a link"
The Growth team currently (May 2020) wants to prioritize the "add a link" workflow over the other ones listed in the table above. Although other workflows, such as "copyedit", seem to be more valuable, there are a set of reasons we would want to start first with "add a link":
- In the near term, the most important thing we would want to do first is to prove the concept that "structured tasks" can work. Therefore, we would want to build the simplest one, so that we can deploy to users and gain learnings, without having to invest too much in the first version. If the first version goes well, then we would have the confidence to invest in types of tasks that are more difficult to build.
- "Add a link" seems to be the simplest for us to build because there already exists an algorithm built by the WMF Research team that seems to do a good job of suggesting wikilinks (see the Algorithm section).
- Adding a wikilink doesn't usually require the newcomer to type anything of their own, which we think will make it particularly simple for us to design and build -- and for the newcomer to accomplish.
- Adding a wikilink seems to be a low-risk edit. In other words, the content of an article can't be as compromised through adding links incorrectly as it could through adding references or images incorrectly.
Notes on "copyedit"
In conversations with community members on this project's discussion page, many people brought up the question of how to make a structured task around copyediting. Correcting spelling, grammar, punctuation, and tone seemed to everyone to be a clearly useful task that should be prioritized. The Growth team initially shied away from this workflow because of scaling concerns: even if we were able to find or develop an algorithm that could reliably find copyedits in one language, would we be able to do that in dozens of other languages?
We began to learn more about this by talking with User:Beland, who developed the "moss" script for English Wikipedia's Typo Team. We wanted to understand how the process works, and what it might look like to do something similar in other languages. In short, it sounds like the most promising avenue is through existing open-source spellcheckers and dictionaries. Two examples are the aspell and hunspell libraries. Below are our notes from learning about "moss" with User:Beland.
- Prospects for doing something similar in other languages
- A process like this should theoretically work in other languages, given that other languages also have Wiktionaries and open-source spellcheckers.
- But it would not be possible to deploy in a new language without native speakers validating it. There would likely need to be customization for many languages.
- Likely more challenges for languages without word segmentation (e.g. Japanese).
- Likely more challenges for agglutinative languages.
- Different projects have differing manuals of style, which may cause issues.
- If an algorithm is performing poorly, it should always be possible to change its thresholds so that it identifies fewer potential errors, but with higher confidence.
- How does moss work?
- Download the dump files of all of English Wikipedia every two weeks.
- In order to cut down on false positives, remove templates and everything inside quotation marks, etc. Only want to work on the main text in the article: the things written “in Wikipedia’s voice”.
- Check that every word is in English Wiktionary.
- Uses Python NLTK (natural language toolkit) for word segmentation.
- Looks at edit distance to classify misspellings. e.g. “T1” is one edit distance (95% precision). Also classifies “TS” whitespace errors.
- Also includes an English open-source spellchecker to narrow the search space so that the algorithm can run faster.
- He has also started trying to add grammar rules (e.g. identifying passive voice), but that’s more experimental, and much more difficult than spelling.
- At the end of the process, it produces a list of articles and likely typos. The user opens the article and searches for the likely typo.
Many copyedit requests are also editors whose native language is not English, asking for English polishing. See WikiProject Guild of Copy Editors.