@MMiller_WMF @RHo could you please review this and let us know what you'd like the business rules to be for 1) the post edit dialog showing or not and 2) the edit tag(s) that should appear?

In T288916#7285916, @kostajh wrote:

@MMiller_WMF @RHo could you please review this and let us know what you'd like the business rules to be for 1) the post edit dialog showing or not and 2) the edit tag(s) that should appear?

Hi @kostajh - imo for 1) the post-edit dialog should still be shown since they did enter the article for editing through suggested-edits and successfully edit so the message and prompt is still valid (edit successful, here's another article).
For 2), I would definitely NOT include Suggested:Add links since this is meant to track specific usage of the structured add link task. Newcomer tasks should probably not be include either since at face value someone who is switching across to two editors to use source is fairly unlikely to be a newcomer, but OTOH an argument could be made that this is counting the origin of the task edit as from the Newcomer tasks feature so defer to @MMiller_WMF's thoughts on that one.

For context, we didn't really try to differentiate between suggested and normal edits for the old (non-structured) tasks. The only difference was whether the help panel included guidance, and that was both not very relevant (e.g. users could still ignore it and make other types of changes, so it wasn't really a guarantee of what the edit would contain) and technically complicated to use for things like edit tags. So we ended up with the business rules that

1. a server-side suggested edit session is any edit the user to an article within 7 days of clicking on the corresponding task card
2. a client-side suggested edit session is any edit the user makes after clicking on a task card, within the same browser tab, until the point where they either close the tab or navigate away from the task page / talk page.
3. guidance and the post-edit dialog is shown while the user is in a client-side suggested edit workflow; edit tags are applied when the user is in a server-side suggested edits workflow.

With stuctured tags, these don't hold up so well:

• users can switch between different editing modes so a client-side session can contain a mix of structured and unstructured edits now
• structured edits restrict the kind of changes a user can make, so the edit tag is more meaningful and placing it on the wrong kind of edit is more confusing
• we do have the means to detect the type of edit on the backend, so using that information for edit tags is possible now

So we should probably implement different rules for structrured tasks:

• apply change tags iff the edit was made in VisualEditor's machine suggestions mode
• show the post-edit dialog iff the edit was made in VisualEditor's machine suggestions mode
• probably the same for guidance?
• we might also want to think about how eventlogging works: we use a shared token to connect our own log events with events in the EditAttemptStep schema, but that schema doesn't currently tell you whether the edit is structured or normal - not sure if that's something we'd want to improve