Growth/Personalized first day/Structured tasks/ja

このページで解説する「新人編集者向けタスク」プロジェクトの作業は、Growthチームが取り組む編集初学者向けの「タスク集」と「各人のホームページ」というプロジェクトに関連します. このページでは主要なアセット、設計、決定課題、意思決定について述べます. 進捗状況で増えた更新のほとんどは一般向けの Growthチームの更新ページに、そしてこのページには特定の大規模または詳細な更新をそれぞれ掲載します.

現状

 * 2020-05-01: 最初に表示する文の立案と作文
 * 2020-05-17: コミュニティの議論を開始する
 * 2020-05-29: 基本的な枠組みの検討
 * 2020-08-24: この週は今後のミーティング予定を立てる
 * 2020-09-08: 設計最新版について、コミュニティに協議を呼びかける
 * 2020-10-21: デスクトップ版設計の利用者テストを実施

要約
Growth チームでは2019年11月に「編集初学者向けのタスク集」を実装、各人の新規利用者のホームページにお勧めの編集作業をいくつか提供しはじめました. 2020年4月時点では、経験の長い編集者が管理用テンプレートを貼ったページに限定して編集作業を推奨、ただしどの文言や文、段落を編集するかどうかは指示していません. それでも編集初学者の皆さんがお勧めのページで生産的な編集を続けていることは喜ばしい傾向です.

管理用テンプレートにより、編集初学者向けのタスクはいくつもの種類が用意できても、広範すぎたり正解が複数あって達成感に結びつかない恐れがあります. それに加えて、携帯端末だと画面の小ささという制限のため、初学者にとっていきなり編集機能（ビジュアル式でもウィキ文式でも）を使うのは複雑すぎます.

以上により、当初は「構造化したタスク」という発想を実証したいと考えます. これは編集のワークフロー（作業手順）を連続する複数の段階に切り分け、編集初学者が1段階ずつ完成するようにまとめるという発想です. 先行するAndroid版ならびに言語部門の成功事例を追って、この種の編集なら初学者が取り組みやすく、携帯端末でも作業が楽で、初学者が編集実績を増やす支援ができると考察します. 初学者には、編集初学者向けタスクプロジェクトの一環として構造化したタスクを提供します.

編集作業はややこしい
私たち Growth チームの経験知から、編集初学者はウィキで歩み始めると、ごく初期の体験で活動を続けたいか辞めたいか決まる傾向にあります. 私たちの見るところ、さっさと編集ができて肯定的な経験をした編集者は、活動を続けようと思うようです. ところがウィキペディアへの貢献は -- さまざまな方法はありますがどれも -- ややこしいし、編集初学者にとっては早い段階でどんどん成功体験を積むのを難しくしています. 一例として、既存の記事にたった 1 文を加筆するのに、手順は 12 回ほどあります:


 * 1) 適した記事を選ぶ.
 * 2) 自分が加筆したい情報がその記事に欠けているかどうか確認.
 * 3) その加筆をする節を選択.
 * 4) クリックして編集を開始.
 * 5) 正しい位置に文を加筆.
 * 6) 出典ボタンを押す.
 * 7) 情報源を開き、リンクもしくは出典情報を確認.
 * 8) 出典フォームの各欄に記入して、終わったら保存.
 * 9) 保存用のボタンを押す.
 * 10) 編集の要約を記入.
 * 11) 公開する.

編集初学者がビジュアルエディターまたはウィキテキスト エディターを開いても上記のような手順があるとは書いてないし、それぞれの順序や、どのボタンを押すと上記のリストのどの作業ができるのかさえ、説明がありません. これを換言するなら、初学者の経験は構造化されていないのです. 面倒くさいから、やめてしまいます. あるいは失敗を積み上げたせいで、活動歴の長い編集者から気分の悪い対応をされます. そこがこのプロジェクトの出番です: 編集初学者の人がワークフローを正しい順番でこなすには、私たちはどんな補助をすればよいか?

他の部門の知見を援用
編集ワークフローの構造化は、ウィキメディアのプロジェクト群にとって長年の課題でした. たとえばいくつかの例をあげます.


 * HotCat：この拡張機能を使うと、ほんの数回クリックするだけで記事へのカテゴリ追加ができ、ウィキ文を手入力する必要がありません.
 * コモンズ・アップロード・ウィザード：コモンズにメディアを投稿する手順を段階分けし、簡単なステップの連続に変えます.
 * Citoid：ビジュアルエディタに付属する拡張機能. 出典を追加する手順をいくつかの段階に分解し、出典の記述およびテンプレートを自動生成するアルゴリズムを組み込んであります.

最近は「タスクの構造化」という発想がウィキペディアの Android アプリならびにコンテンツ翻訳拡張機能で成果を上げています. その取り組みにヒントをもらいました.

Android チームの取り組みでは「おすすめ編集」プロジェクトを作成、ウィキペディアの題名について説明文を書き込む作業をワンステップ化、専用の入力ボックスに記入するだけに変えました. 記事題名の説明文に関しては、その翻訳も同様にワンステップ化. ワークフローを構造化しない場合、同じまずウィキデータを開き、同じ結果しか表示しないのに何段階も処理が必要です. 担当チームは、Android 版ではこういう細かい作業を何百件もこなしてくれる利用者が多いことに気づき、この方法の有効性を認めています.

言語チームが開発したコンテンツ翻訳ツール（拡張機能）は記事の翻訳に複数の要素を持ち込み、構造化しました. 翻訳作業用の欄を横に並べたインターフェースを開発、また翻訳原文をいくつかのブロックに切り分け、機械翻訳のアルゴリズムで自動処理します. もちろんウィキメディアンの皆さんはこのツールがなくても記事の翻訳ができます が、手入力で処理する部分のせいで作業はややこしく、面倒を増やしていました. コンテンツ翻訳ツールは普及しており、翻訳記事が10万件単位で増加しています. 記事を翻訳するときに作業が多段階化してあるとrote部分（原文ママ・文字部分？）の自動処理（機械翻訳の実行） によって、翻訳記事の数が増えることがわかりました.

私たち Growth チームでも記事のコンテンツ編集に同様の原則を取り入れられないか、たとえばリンクや画像、出典の追加や、加筆に応用できないか検討しています.

構造化したタスクのイメージ
タスクの多段階化をどのようにとらえているか、うまく説明するには簡単な状況設定をお見せするとよいかもしれません. いちばん初めに想定したのは、「（内部）リンクを追加」するタスクの多段階化でした. でも同じ多段階化の発想なら対象は「画像の追加」でも「出典の追加」あるいは「事実の追加」でもよかったのです.

編集初心者向けのタスク機能を使った多くの初学者が「（内部） リンクの追加」作業 -- 青字のリンクが少ない記事に内部リンクを追加する作業を完了しています. はじめに取り組むには、簡単な編集タスクといえそうです. ただし、青字のリンクを追加する一連の作業をゼロから説明したところで、初学者の多くは理解できるかどうか、あるいはリンクを張る文字列の選び方もわからないと担当チームでは理解しています. We're imagining a workflow that walks them through it, step-by-step, with the assistance of an algorithm that can guess which words or phrases might make the best links.

In the sketch below, the newcomer arrives on an article, and is given a suggestion of a word that might make a good (wiki)link. If they agree that it should be made a link, they are walked through the steps of making the link. This will hopefully teach them to add links on their own in the future -- and perhaps they'll enjoy continuing to receive these algorithmic link suggestions. アルゴリズムに関してはウィキメディア財団の調査チームが初期の作業を実施しており、懸案のアルゴリズムは十分に実現できると確信しています.



この発想から、さらに第2案を大まかに考えました. 次のワークフローでは、編集初学者にビジュアルな編集機能を使ってリンクの追加を教える代わりに、アルゴリズムが提案を示し、利用者は短時間で承認するか却下するか判断して直接、記事を編集します. こちらではリンクの追加を学ぶ代わりに、初学者が量の多い編集作業を学ぶ役に立ち、実力を身につける段階でも生産的な活動を希望する利用者には、こちらの方が適している可能性があります. あるいはまた、とても簡単な編集だけ やりたい利用者向けとも言えるし、Android アプリで記事の題名の説明 だけ ならやる気が出るという利用者と共通項があります.



タスクの構造化についてさらに考えると、かなり根深い問題かもしれません. ワークフローの方向性として、編集初学者に従来のツールの使い方を教えるのか、もしくは、単純な編集を量的にこなす能力を伸ばすのか？

この案を優先する根拠
手間をかけずに生産的な編集ができると、編集初学者の達成感につながると考えました. 編集作業を少し経験すると、ウィキでの経験はたちまち豊かに感じられます. 自分の編集の影響を理解したり感謝の通知が来たり、 基礎知識を学んで指導役に質問したり、自分の利用者ページを作ることなどもできるようになります. そこで、できるだけ多くの編集初学者に、さっそく編集作業を始めてもらいたいのです. 編集初学者向けタスクのプロジェクトから、編集初学者で簡単な編集を求める人が多いとわかってきました. しかしながら、次の各点も観察しました.


 * 新規登録者でおすすめ編集をクリックし、実際に編集したのはたった 25% 前後.
 * おすすめ編集に着手した人で別のおすすめもやったのはたった 25% 前後.
 * おすすめへんしゅうに没頭する初学者も5、6人はいて、毎日、せっせと10件単位で課題をこなしています. ここから、ウィキの作業を大量に達成する初学者の能力が浮かんできます.
 * 実時間の利用者テストでは、初学者に記事の文字編集あるいはリンク追加を頼んだ場合、どの文章もしくは単語が作業の対象か、しばしば被験者から質問されます. 換言するなら、全文を編集するという指示はあまりに曖昧です.

これらの所見と前述の Android アプリの利用者の傾向、コンテンツ翻訳機能の担当チームの経験知などを踏まえると、ウィキペディアのコンテンツ編集の一部を構造化することで、編集を始める初学者を増やし、さらに続けてもらうことができると考えます.

構造化したタスクの利用価値
編集のワークフローをいくつかの段階に分解し、これを「多段階のタスク」と呼ぶことにします. その方法に見込まれる利点には以下のものが含まれます.


 * 編集初学者にも楽に有意義な貢献ができる.
 * モバイル版に適した編集ワークフローを開発すること. モバイル版の設計原理に従うと、利用者には1回に1段階ずつ表示し、ワークフロー全体を一度に見せるべきではないとされています.
 * 新人編集者に段階的に腕を上げてもらうこと. すると難度が高い種類のタスクでも、うまく達成できるようになるはずです.
 * 皆さんが自分にぴったりの編集経験と出会えるようにすること. 新人編集者に構造化した一連のタスクを提供すると、どんなタスクが自分の好みか、選べるようになります.
 * 将来的には、編集歴の長い編集者にも同様のワークフローを提供することができそうです.

構造化したタスクの問題点と短所
ウィキペディアの編集に新しい手法を導入するたび、うまくいかないことも多く発生します.


 * 編集があまり短時間に簡単にできるようでは、荒らしを呼びこんだり、注意散漫な編集をする人を増やさないか.
 * 簡単なワークフローばかり教えると、最も影響力のある編集に不可欠な従来の編集ツールを学ぶチャンスを奪うのではないか.
 * 言語の違い、またはウィキ文の特性によっては多段階のタスクが適合せず、今までと違うバグを生まないか.
 * 構造化したタスクを浮上させるアルゴリズム精度が足りない可能性と、編集初学者が手を出すべきでない編集作業をむだにお勧めしていないか.

コミュニティの議論
In May 2020, we conducted discussions with community members in six languages (English, French, Korean, Arabic, Vietnamese, Czech) about the above ideas for structured tasks. The English discussion mostly took place on the discussion page here, with other conversations on English Wikipedia, and local language conversations on the other five Wikipedias. We heard from 35 community members, and this section summarizes some of the most popular and interesting thoughts. These discussions heavily influenced our next set of designs.


 * Community members were generally positive about the potential for structured tasks to help newcomers start editing. But it was also a widely expressed view that it's important for newcomers to be introduced to the conventional source and visual editors during the process.  Community members want to make sure that newcomers are not siloed in a separate editing experience, and that they can find their way to more valuable edits.
 * The Czech community talked about ideas for how the structured tasks can place inside the visual editor, so that newcomers can start getting used to being in the editor. Perhaps the editing tools that are not needed for the structured task can be grayed-out.
 * コミュニティの皆さんから質問があり、なぜ当チームはもっと量が多い課題ではなく「リンクの追加」を最初の多段階タスクの課題に選んだか、尋ねられました. ビルドする側からこのタスクがいちばん簡単だった理由を述べ、試作版を作り多段階タスクについて早く知識を深めたいこと、また初学者が記事に害を及ぼす可能性が低く、タスクとしててはリスクが比較的低いことを説明しました.
 * 単語の正確なつづり（スペル）は特に重要な課題だという声は、複数のコミュニティから聞こえていて、では間違ったスペルの見本をどうすれば作れるか、チームで議論しました. 詳細はこれらのメモに記しました.
 * また議論した中に、編集初学者に荒らし行為の巻き戻しが適するかどうかという課題もありました. 明確な答えはなさそうで、将来的に議論する余地が残りました.
 * もっと難しいタスクへ「編集初学者をステップアップ」する方法は何度も繰り返し出てきた発想で、おそらくは簡単なタスクに成功すると何かごほうびがもらえる設定が良いかどうかです.

タスクの種類
多段階化に向きそうな編集のワークフローには、いろいろなタイプがあります. 編集初学者向けタスクのワークフローをこちらで設計した時、ワークフローのリストづくりを開始しており、その後、多段階化に最適なものを短いリストにまとめ直しました. それらに仮の優先順位を付けて、以下の表にまとめます.

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.