I just encountered a suggestion (see screenshot) that I assume to be out of alignment with an en.wiki convention (en:WP:LEADCITE): add a reference to the lead section of an article.

Intuitively, my next thought was: "I want to fix this! Where "this" refers to the suggestion itself.

Which then lead me to wonder: what if we offered a text input field within the card that would automatically start a discussion on a centralized "suggestions" talk page?

Another idea: maybe the dialog, for right now, links directly to https://fr.wikipedia.org/wiki/MediaWiki:Editcheck-config.json ?

...although, for the idea above to be viable, we'd need that page to include the context / guidance necessary for someone encountering a page of this sort for the first time to make sense of it and edit it ways it's meant to be.

This all brings me back to: T372927: Enable volunteers to configure Edit Check using Community Configuration

I’m sharing a proposed UX flow and copy for submitting feedback on suggestions.

1. CTA to collect feedback inside the suggestion's card:
   • Copy: Suggest change. I would avoid terms like “feedback” since is harder to translate across languages.
   • Design: To keep the interaction as lightweight as possible, I would add a small quiet progressive button alongside the main actions just in the expanded card, using a smaller caption text size so it doesn’t distract from the primary actions in the suggestion card.
2. Dialog with the form:
   • Following the feedback Dialog shared in the task description, I'm adding Subject + Message.
3. Success message (once shared the feedback in the Dialog):
   • Copy: "Your suggested change was successfully posted on this Talk page." (avoiding long links)
   • Design: Instead using another confirmation Dialog, we could use a success Toast, auto-dismissable after 4-6 seconds.

Desktop card	Mobile bottom sheet	Flow

Thanks for sketching this out, Barbara! A few initial thoughts:

• I don't think it'd be clear to me out of context that "Suggest changes" refers to suggesting changes to the feature itself, as opposed to the article. I might assume that it's to the article, i.e. something that posts a message to the article talk page.
• Learning how Talk pages work is an important skill we want to be teaching newcomers, and I'd like to think that, with the improvements we've made in recent years through DiscussionTools, it's no longer insurmountably difficult. Are the benefits of using a feedback form worth passing up that learning opportunity? And could it cause other issues like making it harder for editors to understand where their report is going/see other reports/go back for follow-up?
• Related to the above, I worry that "Your comment helps improve suggestions on Wikipedia. It will be reviewed by people and won't affect this edit automatically." is not going to be enough information to teach newcomers how to offer useful feedback. We've seen with Mentorship that making it very easy to post a message results in a lot of gibberish-type messages from users asking for e.g. help with their homework. And making a good Suggested Edits bug report is fairly complicated, since it involves understanding both how the suggestion is supposed to work and some way in which that's going awry, and then articulating it. I guess we could just wait to see what sort of messages we get, but I fear that, without additional explanation (and perhaps even with it) we may get so much spam that we end up ignoring the feedback page (or restricting feedback to more experienced editors). One way to make things more structured might be to split the "Message" field into several questions guiding users through the steps of a good bug report. While not as lightweight as the current design, fewer low-effort reports could be desirable if it clears out some of the spam.

@Sdkb thank you for the feedback. Responding to your points:

• I agree we should clearly communicate that the feedback is about the specific suggestion, not the article. However, in order to keep the CTA short and non-disruptive with the rest of the suggestion's card content, I would include that clarification into the Dialog (via the title and/or description), where there’s more space to explain this.
• Regarding the Talk pages, the dialog could also explain that comments are posted to a Talk page, what that means, and how users can follow up there, with an optional “learn more” link for additional context if it would be needed.
• To reduce the off-topic feedback, we could add lightweight guidance in the Dialog itself (e.g. short descriptive text below the TextArea prompting users to focus on how the specific suggestion works) and optionally a simple Radio group to indicate the type of issue before adding more details.

@bmartinezcalvo: holding aside comments about the copy that appears within the workflow aside for a moment, the general flow you shared in T401739#11533573 looks wonderful to me.

A couple of comments/questions in response to the proposal you shared and the points @Sdkb helpfully raised...

• Feedback call to action: what about something like Report?
• Learning how talk pages work: @Sdkb, while I agree with you in thinking it's important that newcomers learn where/how to discuss with other volunteers, I think A) we are learning that newcomers learn most effectively by doing, B) it's important that we continue to apply what we are learning through Edit Checks: put the solution where the problem is, and C) it's important we assume this CTA will, to start, likely only be exposed to experienced volunteers.
• Feedback form: While I agree in thinking the copy of the form could be improved, I think we can defer any more substantive changes to the form once we get a sense for the kinds of feedback people are submitting through it.
  • Per above, I think this approach is viable in the short-term where we intend this feedback CTA to only be exposed to experienced volunteers.

Thanks for the follow-ups! When I shared my initial impressions above, I moreso had in mind newcomers. Realizing that this is intended at the moment (and maybe permanently?) for experienced editors changes my perspective. I wonder whether we're over-engineering. Experienced editors are very used to being sent to talk pages to report issues, so perhaps all we need to add is just a button that goes to a talk page that has an intro paragraph at the top explaining what we're looking for in feedback. But if we've already done the work to make a feedback form, I think it may work just as well.

One aspect that I'm not sure we've covered yet is how we're going to capture the information about which phrase on which article triggered the suggestion. That's info that I presume we want, as it could help us with any investigation we make. Ideally the feedback form will generate it and attach it automatically to the post. A lighter-weight approach would be to just ask in the instructions that editors include it when making a report.

how we're going to capture the information about which phrase on which article triggered the suggestion.

Good spot. Could you please review the following requirements and share what (if anything) about the below you think would need to be added/changed to address the point you're raising here?

Each piece of submitted feedback should be automatically accompanied by:

• RevisionID of the article the suggestion was surfaced on/in
• The type of suggestion
• Username of the person submitting feedback
• The span of content that caused the Suggestion to be shown

Ah, my bad, I missed those requirements! That basically captures it; the only remaining element would be the implementation of how those pieces of data are actually displayed on the talk page where reports go.

Thank you for the feedback. Sharing the updated design proposal based on the discussion so far:

CTA/Entry point.

After exploring different options, and considering that we may want to include additional secondary actions later without disturbing the main content and actions in the suggestion card, I’ve explored using a MenuButton to keep the card visually clean while grouping this and other potential secondary actions. The menu would include:

1. About suggestions – navigating to general information about how Suggestion Mode works, especially useful for first-time users (aligned with the explorations being worked in T414518).
2. Report a problem with this suggestion – opening the feedback dialog. Since this lives inside a menu, a slightly longer and clearer copy is non-disruptive. If needed, we could still shorten it (e.g. “Report a problem”) and provide full context in the dialog.
3. Copy link to this suggestion – as a utility action for sharing or discussion. Additional actions could be added here in the future as Suggestion Mode evolves.

Dialog

The dialog is intentionally simple for this first iteration and includes the following elements (we could iterate it later if we decide to move to a different form direction):

• A short description clarifying that the report is about the specific suggestion, and explaining that it will be posted on the relevant Talk page (linked).
• An optional Radio group to indicate the type of issue, to help us filter the reports collected.
• A free-text textarea for additional details.

Success message

A confirmation message explaining that the report was posted on the Talk page and providing a direct link so users can navigates to the discussion.

Next steps

• @ppelberg to finalize requirements
  • More specifically, express a point of view about what is acceptable for the initial en.wiki beta feature release:
    • Are we okay with including a link to the talk page where we are gathering feedback? If so, what (if any) content would we like pre-loaded into the New Topic Tool for people who tap it?
    • Is it necessary that the initial version include an in-line form? And if so, what (if any) information is automatically published with the feedback people share (e.g. revisionID, text span, etc.?)

I like those updates, @bmartinezcalvo! We should probably ensure that editors are automatically subscribed to the section that they create on the talk page, since otherwise they might miss follow-ups or be unable to get back to the report they made (since there's nothing in their browser history, and not all newer editors know how to use their contribution history to navigate).

Per today's offline team discussion, we're going to break the feedback flow feature out into two releases:

• Release #1: ahead of the en.wiki beta feature release (T399611), we're going to:
  • Update the Suggestion card to include the ••• affordance (F71589938)
  • Within the ••• affordance will be the following copy + links:
    • [[mw:VisualEditor/Suggestion_Mode|About suggestions]]
    • [[mw:Talk:VisualEditor/Suggestion_Mode/Feedback|Report a problem]] with this suggestion.
  • Both links, when people tap/click them, should see said pages opened in new tabs
  • When people tap/click the [[mw:Talk:VisualEditor/Suggestion_Mode/Feedback|Report a problem]] and navigate to said talk page, they should see the new topic tool automatically opened
• Release #2: ahead of the all wikis beta feature release (T415320), we're going to implement a version of the flow @bmartinezcalvo specified in T401739#11544744.

Now, in terms of organizing the work...

• I'm going to create a new ticket for Release #1
  • ✅ T415936
• I'm going to update this ticket (T401739) to include the requirements for Release #2

@ppelberg to update scope to be limited to integrated feedback flow. We'll integrate metadata about suggestion in a v3, once work on T415935 is complete.