Page MenuHomePhabricator

[Tone Check] Present survey when people choose to "Decline" invitation to revise tone
Closed, ResolvedPublic

Description

This task involves the work of reconsidering what happens when people elect to decline taking action on a Peacock Check that is presented to them.

The need for this exploration emerged during a 19 March Editing Team discussion wherein we came to align on the following disconnect:

  1. Publishing an edit that introduces text written in – what experienced volunteers are likely to consider – a non-neutral tone is relatively disruptive
  2. Dismissing a Peacock Check, at present, is relatively lightweight/seamless

The disconnect between "1." and "2.", we think, will send people encountering Peacock Check a conflicting message.

Stories

  • As a newcomer/Junior Contributor who has explicitly chosen to forego revising the tone of what they've written, I would like to know what information/content I can offer to the experienced volunteers who are likely to review/patrol this soon-to-be published edit, so that I can increase the likelihood that the contribution I consider to be useful and worthwhile remains on the wiki.
  • As an experienced volunteer who is reviewing an edit in which someone has a) added new text written in a tone considered to be non-neutral and b) decided NOT to revise the tone of said text, I would like to know why this person made this decision so that I can decide what – if any – action (e.g. revert the edit, post a message on the person who made the edit's talk page, etc.) to take in response

Requirements

User experience

  • When people choose to Decline revising the tone of the new text they are writing when Tone Check invites them to consider doing so...
    • Present the following "survey" (see mockup below) that prompts people to indicate why they've declined to revise the tone of what they've written by selecting one of the following three options:
      • The tone is appropriate
      • I’m not sure how to revise the tone
      • Other (for now, we will only include the "Other" option without TextInput, and we will include it in T397889)
    • On desktop, the decline survey ought to be presented in the sidebar, per T381610
    • The Decline response someone submits needs to be logged so that we can aggregate these responses
      • Based on what the Editing Team discussed offline on 12 May, this logging should happen automatically via VEFU.

Mockup

image.png (1×2 px, 327 KB)

NOTE: UX adjustments (e.g. button treatment, card title, etc.) should also be applied to the Reference Check decline survey

Decision(s) to be made

  • 1) What - if any – modifications will we make to the Peacock Check's "decline path" to ensure it reinforces the importance of considering tone when adding new content to Wikipedia and the potential impact of not doing so?
    • See ===Requirements
  • 2) How/if might we use the signal the decline path ideally captures/elicits could be useful for the model retraining the ML Team is planning in T393103
    • We're deferring this question for now and will, instead, revisit this when we prioritize work on T393103.
  • 3) Related to "2)," how might we surface the signal the decline path [ideally] captures to volunteers so they can use it as an input to improve moderation processes? E.g. maintain an allow-list of sorts to avoid false positives.
    • One idea, might it be possible to look at the SHAP values the model returns for edits where some declines to revise what they've written and log this in some place?
    • Note: we're going to defer this question for now and instead revisit it when we prioritize work on T395175.
  • 4) How – if at all – will we pass on the responses volunteers offer to the model/ML Team?

Done

  • Potential "Approaches" are documented
  • An "Approach" is chosen
  • Approach is implemented
  • ⭐️ Editing QA to verify events are being emitted client-side as expected
  • @MNeisler to verify decline responses are being logged in VEFU as expected

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
ppelberg updated the task description. (Show Details)
ppelberg updated the task description. (Show Details)

Next step(s)

  • @nayoub to add final design we converged on during last week's offline Editing Team meeting so that engineering can be work on implementation.
Aklapper renamed this task from [SPIKE] Reconsider the Peacock Check decline path to [SPIKE] Reconsider the Tone Check decline path .May 28 2025, 11:43 AM
ppelberg moved this task from Doing to Ready to Be Worked On on the Editing-team (Kanban Board) board.
ppelberg added a subscriber: nayoub.
ppelberg renamed this task from [SPIKE] Reconsider the Tone Check decline path to [Tone Check] Present survey when people choose to "Decline" invitation to revise tone.Jun 25 2025, 11:20 PM
ppelberg updated the task description. (Show Details)

As in T397178: Reference Check: Disable the card when the "Add a citation" popover is displayed, I would suggest improving this declining survey by:

  • Title: Use the title from the Edit Check instead ("Revise tone") so users can easily relate this step to its Check. We can rely on the card's description to explain to users that this step is to share your reason about declining.
  • Buttons: Update them to "Back" (Neutral Normal) + "Submit" (Primary Progressive)
  • Other: include a TextInput to allow the user to input a custom response (see Codex guidelines)
  • Disable pagination when this step is visible
    image.png (1×2 px, 327 KB)

Regarding the text input, where will this information be posted? How can it be moderated? Some people add personal info in edit summaries, for instance: "that's how the text must be written as it is our page, if you disagree, call us at [phone number]".

With multi-check, we can have multiple declines, with multiple other inputs. How do we connect each "other" reasons to their respective paragraph?

My personal advice is to remove the "other" option.

We previously chose not to do an "other" in the add-reference check, for the general reasons Benoit stated.

As in T397178: Reference Check: Disable the card when the "Add a citation" popover is displayed, I would suggest improving this declining survey by:

  • Title: Use the title from the Edit Check instead ("Revise tone") so users can easily relate this step to its Check. We can rely on the card's description to explain to users that this step is to share your reason about declining.

Good spot and agreed. Requirements updated.

  • Buttons: Update them to "Back" (Neutral Normal) + "Submit" (Primary Progressive)

Good spot and agreed. Requirements updated.

  • Other: include a TextInput to allow the user to input a custom response (see Codex guidelines)

I'd like for us to defer this for now and instead, revisit the potential of adding this functionality in T397889.

  • Disable pagination when this step is visible
    image.png (1×2 px, 327 KB)

Good spot and agreed. Requirements updated.

Regarding the text input, where will this information be posted? How can it be moderated? Some people add personal info in edit summaries, for instance: "that's how the text must be written as it is our page, if you disagree, call us at [phone number]".

Per above, we're going to defer incorporating the text input for now. We'll, instead, explore the value and priority of including this in T397889.

With multi-check, we can have multiple declines, with multiple other inputs. How do we connect each "other" reasons to their respective paragraph?

Great spot. At present, we do not have a way of associating decline responses with the specific spans of text/content they are associated with. I've created T397969 to track this work.

My personal advice is to remove the "other" option.

I'd like for us to keep the "other" option for now considering:

  1. We're not implementing a text field along with it.
  2. The inclusion of the Other option does nothing to affect the fact that, at present, we do not have the ability to relate a decline reason to the specific text/content it is relevant to.

Change #1164536 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/VisualEditor@master] Edit check: refactor the feedback form into the ActionWidget

https://gerrit.wikimedia.org/r/1164536

What should the text above the survey be? In the mockup (which shows the "add reference" decline survey) it has been changed to the generic "Other editors would value learning more about your decision to ignore." which is generic but sounds awkward.

For now I've put a generic one in the patch as "Other editors would value learning more about your decision to skip this check."

Change #1164538 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/VisualEditor@master] Edit check: add a feedback survey to the decline step of tone check

https://gerrit.wikimedia.org/r/1164538

El T389443#10955712, @DLynch escribió:

What should the text above the survey be? In the mockup (which shows the "add reference" decline survey) it has been changed to the generic "Other editors would value learning more about your decision to ignore." which is generic but sounds awkward.

For now I've put a generic one in the patch as "Other editors would value learning more about your decision to skip this check."

I would not say "check" in that form since that word is not appearing in the previous steps, so it could be confusing for users. What about:

"Other editors would value learning why you made this choice."

We could use this description in the surveys for all checks for consistency.

Change #1164536 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Edit check: refactor the feedback form into the ActionWidget

https://gerrit.wikimedia.org/r/1164536

Change #1164538 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Edit check: add a feedback survey to the decline step of tone check

https://gerrit.wikimedia.org/r/1164538

In a follow-up (because of https://gerrit.wikimedia.org/r/c/mediawiki/extensions/VisualEditor/+/1164978/3) we're going to make it so that when a check loses focus during a survey its state is reset. (This is sometimes inevitable when we lose track of a check after a major change to the document.)

Change #1166004 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/VisualEditor@master] EditCheckActionWidget: clean up the feedback form on togglecollapse

https://gerrit.wikimedia.org/r/1166004

Change #1166004 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] EditCheckActionWidget: clean up the feedback form on togglecollapse

https://gerrit.wikimedia.org/r/1166004

ppelberg updated the task description. (Show Details)

✅ Survey is displayed as expected:

Screenshot 2025-07-09 at 21.24.00.png (640×676 px, 72 KB)

⚠️ On scroll, the popup goes under the sticky toolbar nav
Screenshot 2025-07-09 at 15.45.31.png (680×824 px, 80 KB)

Captura de pantalla 2025-07-10 a las 15.51.14.png (518×638 px, 52 KB)

Paddings are unbalanced. They should be fixed as follows:

  • Top padding in the white content should be spacing-75 (12px), as the bottom one (currently 8px)
  • Padding between the Radios and Buttons should be spacing-100 (16px) (currently 8px)

Are we tagging the rejection reasons? Patrolling edits tagged for both will be super useful for experienced users!

@Trizek-WMF No tagging of rejection-reasons -- same as the reference check, where we removed the tagging.

Are we tagging the rejection reasons? Patrolling edits tagged for both will be super useful for experienced users!

@Trizek-WMF No tagging of rejection-reasons -- same as the reference check, where we removed the tagging.

Note: we'll revisit the question of enabling volunteers to see the decline reason(s) on-wiki, on a per edit basis in T387918 and/or T395175.

Moving to ready to be worked on to address UI tweaks @bmartinezcalvo outlined in T389443#10992107,

Note: potential that the above might require upstream changes...

✅ Survey is displayed as expected:

Screenshot 2025-07-09 at 21.24.00.png (640×676 px, 72 KB)

⚠️ On scroll, the popup goes under the sticky toolbar nav
Screenshot 2025-07-09 at 15.45.31.png (680×824 px, 80 KB)

@EAkinloose: as part of the QA of the decline survey UI you completed above, did you also QA the events the decline responses should be emitting? If so, could you please verify whether the events were being emitted as described in the task description?

Yes, an action-reject event is emitted.

You should see feature: editCheck-tone, action: action-dismiss when you click "decline", then feature: editCheck-tone, action: edit-check-feedback-reason-[whatever you picked] when you submit the feedback.

Next steps:

Next steps:

Task created T399883: Edit Check: adjust paddings

Next steps:

action: "action-dismiss"
editor_interface: "visualeditor"
feature: "editCheck-tone"
integration: "page"
is_bot: false
...
user_is_temp: false
wiki: "enwiki"

(I'd like to verify this)

I've verified that we are seeing these events logged in VEFU as expected based on test events logged to date.

The following decline survey events are logged with feature = editCheck-tone :

  • edit-check-feedback-reason-appropriate
  • edit-check-feedback-reason-other
  • edit-check-feedback-reason-uncertain

Test events have been logged on enwiki, eswiki, and frwiki so far. 1 event on mobile so far and 10 on desktop.

@DLynch I noticed there's also a edit-check-feedback-shown event. Is this event sent each time the decline survey appears for either tone or reference check?

@MNeisler yeah, edit-check-feedback-shown will happen on the feature editCheck-[type] whenever any check uses the generic survey code.

As verified by @MNeisler , we get the events emitted and QA is complete here. Events for decline journey, up to the dialog being closed look like screenshot below:

image.png (1×1 px, 383 KB)

EAkinloose moved this task from QA to Ready for Sign Off on the Editing-team (Kanban Board) board.

Leaving open for @ppelberg to double check for open comments if any and close out.