Page MenuHomePhabricator

Create a system to encode best practices into editing experiences
Open, Needs TriagePublic

Description

🌱 In the forest that is Phabricator, this ticket is very much a seedling on the forest floor. Read: this task is a gathering place/work in progress.


This parent task is intended to help gather and advance the thinking around how the visual editor might be enhanced to help people learn the social conventions (read: policies and guidelines) and exercise the judgement necessary to become productive and constructive Wikipedia editors.

Background

Visual editor's growing popularity among people new to editing Wikipedia [i] suggests it has been reasonably successful at helping people to learn the technical skills [ii] necessary to edit Wikipedia.

Trouble is, the edits these new people make often break/defy Wikipedia policies and guidelines.

This task is about exploring how the visual editor could be augmented/enhanced to help people learn these policies and guidelines and exercise the judgement necessary to become productive and constructive Wikipedia editors.

Potential impact

New and Junior Contributors
Working on talking pages has led us to notice that for many newcomers, the earliest human interactions they have on-wiki centers around something they did wrong, like not contributing in the Wikipedia Way [iii] [iv][v][vi][viii].

We wonder how newcomers perceive these interactions and further, whether newcomers having a positive first interaction with another Wikipedia editor could increase the likelihood that they continue editing. [vii]

Senior Contributors
We wonder whether adding more "productive friction" to publishing flows could free Senior Contributors up to do more high-value work by:

  • Reducing the amount of work they need to do reverting lower quality edits by increasing the quality of edits
  • Reducing the amount of work they need to do blocking bad faith/vandalistic editors by lowering the likelihood these actors are able to complete/publish the changes that cause them to be blocked
  • Reducing the amount of work and time they spend writing on new users' talk pages to alert them of policies and/or guidelines they've [likely] unknowingly broken
  • Reducing the amount of time and energy they need to spend worrying about protecting the wikis. This could potentially relieve them of mental space to address new challenges.

Use cases

More in T284465.

Components

  • A way to codify rules and policies that machines could "read" / "interpret"
    • To start, a team like Editing could hardcode these rules and policies on a one-off basis. At scale, if/when the concept proves valuable, we envision a way for volunteers to write custom rules based on the consensus reached at their respective projects.
  • A way for the editing interface to locate where content exists that violate these rules and policies
    • Note: "content" in this context refers to content that has already been published on the wiki and content that volunteers have added and have not yet published.
  • A way to surface improvement suggestions to volunteers who have an editing interface open.
    • E.g. "This is the issue. This is where the issue exists within the artifact (read: article, talk page comment you are drafting, etc.). This is what you can do to remedy the issue."
  • A way to make volunteers aware that issues exist within content they are reading / have not yet started to edit.

Also see the ===Components section in T276857.

Naming ideas

  • Policy Check
  • Intelligent edits / Edit intelligence
    • I'm attracted to the idea of framing this as infusing the collective intelligence of the wikis into the editing interfaces.
  • Edit assistance
  • Assisted edits
  • Augmented edits

References

Related tickets

Data

Policy documentation

Research

  • Proposed: AI-Models-For-Knowledge-Integrity
  • Automatically Labeling Low Quality Content on Wikipedia By Leveraging Patterns in Editing Behaviors via @Halfak in T265163#7622952 non paywall link
  • Conversations Gone Awry: Detecting Early Signs of Conversational Failure
  • Wikipedian Self-Governance in Action: Motivating the Policy Lens
  • Twitter Prompts Findings
    • "If prompted, 34% of people revised their initial reply or decided to not send their reply at all."
    • "After being prompted once, people composed, on average, 11% fewer offensive replies in the future."
    • "If prompted, people were less likely to receive offensive and harmful replies back."
  • Unreliable Guidelines: Reliable Sources and Marginalized Communities in French, English and Spanish Wikipedias
    • "A new editor wrote in an email that they perceived Wikipedia’s reliable source guidelines to have exclusionary features."
    • "...community consensus is a foundational pillar of the Wikimedia movement. We learned trainers see this process as privileging those who participated first in the development of the encyclopedia’s editorial back channels. As well, the participants in our community conversations were uncomfortable with the presumption that agreement is communicated through silence, which privileges those who have the time and feel comfortable speaking up and participating in editorial conversations."
    • "In English, contributors from English-speaking countries in Africa said their contributions often faced scrutiny. One organizer from an unnamed African country who participated in our session said when they hosted events, contributions were deleted en-mass for lacking reliability. This was demoralizing for the participants and required extra work by the trainers to stand up for their publications and citations, said one participant...To avoid new editors experiencing these disappointing responses, other trainers in English Wikipedia explained they would review sources before new editors begin editing."
    • "...the quantity of material that a trainer is required to parse in relation to reliable source guidelines is immense. As one participant said:"
      • "This bushy structure makes the guidelines pages unreadable. Who has the time and the meticulousness to read it completely without being lost to a certain point? It took me a decade to go through it [in French] and I must admit I’m not done yet!"

Ideas

  • Ideas for where/how we might introduce this feedback/interaction: T95500#6873217

Related on-wiki tools

On-wiki documentation

Related third-party tools

Open questions

  • 1. Responsibility: How much responsibility should the software lead people to think they have for "correcting" the issues within the content they're editing?
  • 2. Authority: How might this capability shift editors' perception of who is the authority on what's "best"? Might this tool cause people to listen the software more than they do fellow editors?
  • 3. Audibility: How will this tool adapt/cope with the fact that policies and guidelines are constantly evolving?
  • 4. Reverts: Might this capability be impactful for people whose edits have been reverted?

Note: I've added the above to T265163's newly-created ===Open questions section.


i. https://superset.wikimedia.org/r/345
ii. Where "technical skills" could mean: adding text, formatting text, adding links, adding citations, publishing edits, etc.
iii. https://www.mediawiki.org/wiki/New_Editor_Experiences#Research_findings
iv. https://w.wiki/eMc
v. https://w.wiki/dSx
vi. https://w.wiki/dSv
vii. Perhaps the Research Team's "Thanks" research might be instructive here for it explore how positive interactions/sentiment affect editing behavior: https://meta.wikimedia.org/wiki/Research:Understanding_thanks
viii. https://en.wikipedia.org/w/index.php?title=User_talk:Morgancurry0430&oldid=1038113933

Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.
StatusSubtypeAssignedTask
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenBUG REPORTNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
Resolvedppelberg
OpenFeatureNone
Resolvedppelberg
OpenFeatureNone
ResolvedMNeisler
OpenNone
OpenNone
DeclinedSpikenayoub
OpenSpikeNone
OpenNone
Resolvedppelberg
OpenSpikeNone
OpenSpikeNone
OpenSpikeNone
Resolvedppelberg
OpenNone
Resolvedppelberg
OpenNone
OpenSpikeNone
OpenNone
DuplicateNone
OpenNone
OpenNone
Resolvedppelberg
OpenNone
OpenNone
OpenNone
OpenNone
OpenFeatureNone
OpenNone
OpenNone
OpenNone
OpenNone
DuplicateNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
DuplicateNone
OpenNone
OpenNone
OpenNone
In Progressnayoub
ResolvedVPuffetMichel
OpenNone
OpenFeatureNone
OpenFeatureNone
OpenNone
OpenBUG REPORTEsanders
OpenMNeisler
OpenNone
OpenNone
OpenFeatureNone
OpenNone
Openppelberg
OpenNone

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

@ppelberg, this is in response to your original, seedling post, and in particular, how to mitigate any damage to editor retention that may occur when an editor's first interaction with a Wikipedian is a warning on their user talk page, typically topped with a dry, ==Month YYYY== header. I am involved with two activities that result in messages on the user talk pages of new users:

What I am concerned about, are the users who get warnings before they are welcomed. The level-1 warnings are usually quite mild, and some are more informative than a warning, so not too scary, but still, it does come off as finger-wagging: 'You did something wrong! ' When I need to place a warning, I look at the seriousness of their mistake, and if not something egregious, I welcome them first, using one of the Welcome templates, and then after that, I leave the warning template I initially intended to.

I would like to encourage and facilitate the placement of welcome messages as the first message on the User talk page of any user about to get a warning, so the welcome appears before the warning, unless the warning is of such seriousness that it would make placing a welcome before it inadvisable. (But it would have to be pretty serious to nullify the possibility of welcoming a brand new user, in my opinion.)

I have made a few cursory overtures in this direction, such as Template:Welcome needed, which generates a search link listing users who have received a templated warning, but no welcome, and I have some other ideas as well (such as more formal connections between WP:WARN and WP:WC allowing level-1 warning message templates to be preceded by a welcome (via parametrization or some other method).

The reason I am posting now, is because of your intro post, and maybe you could add the issue of "unwelcomed warnees" to your list of things to consider, and perhaps improve. Perhaps there could be some synergy here, as I gradually move forward with some of the ideas I have had in the interstices of the WARN and Welcome projects.

I agree. When something not right come up on your watchlist (with many
edits to be reviewed), you just reach the appropriate Twinkle warning and
move on. If you were prompted to "do you want to add a welcome first?" with
a simple yes/no to click and everything after that is automated (doesn't
add unnecessarily to the workflow or interfere with the workflow).
Obviously where it is clear cut vandalism, you will click NO. It

@Mathglot and @Kerry_Raymond, thank you both for your comments.

This task mostly focuses on welcoming newcomers to the editing experience, more likely within that editing experience. It is not scoped to cover meta/community (inter)actions, such as receiving talk page welcome messages.

However, I can provide some advice on the case you raised. The best solution several wikis (including mine, French Wikipedia) have set up is to agree on one generic welcome message, signed by the mentors, and sent right after the account is created. This prevents the blank page effect, where a bot would be the first to post.

This way of doing things showed good results, sich as newcomers' first edit is a question to their mentor. Some users didn't like the fact that we welcomed potential vandals, but WP:AGF should be reminded: you don't know the intent of a new user!

Would you create a thread at the Welcoming Commitee talk page, and ping me, so that we can continue that conversation on wiki?

Adding on to @Trizek-WMF's comment, I had a very similar thought to the one you did, @Kerry_Raymond: We could modify Twinkle so that, when delivering a level-1 (and maybe also level-2) warning, there is a box autochecked by default with "send along with welcome". WT:Twinkle might be the place to get consensus for that feature, after which it could be added to the Twinkle GitHub for the developers to implement.