Page MenuHomePhabricator

Community Configuration Edit Summary
Closed, ResolvedPublic3 Estimated Story Points

Description

User story & summary:

As an editor of Community Configuration, I want to view an edit summary before I save a Configuration change, so that I can review.

As an editor of Community Configuration, I want to have a helper text always available when saving changes, mentioning the importance of adding an edit summary, so that I am prompted to include one.

Background & research:

This task is important because Community Configuration changes can be very impactful, and editors should generally provide an explanation for why they are making a change.

Design:

The Edit summary should display text of the setting that has been adjusted.

Dialog (5).png (390×518 px, 30 KB)
Screenshot 2024-03-21 at 10.07.39.png (470×858 px, 64 KB)
NOT in the scope of this task, but in T358035In scope, but without the "Review your changes" cta

Figma designs

NOTE: the "diff" part of the edit summary is part of a separate task: T358035: Community Configuration: Design Diff for Edit Summary
Acceptance Criteria:

Given I make a Community Configuration edit,
When I proceed to publish the change,
Then I receive an edit summary before I can Save changes.

(deferred) Given I make a Community Configuration edit,
When I DO NOT provide an edit summary and proceed to publish the change,
Then I come across a helper text prompting me to add one before I save changes.

Related Objects

Event Timeline

There’s already a similar feature in MediaWiki core: Prompt me when entering a blank edit summary (or the default undo summary), did you consider using that? It’s opt-in on most wikis, though (and not opt-out).

There’s already a similar feature in MediaWiki core: Prompt me when entering a blank edit summary (or the default undo summary), did you consider using that? It’s opt-in on most wikis, though (and not opt-out).

Thanks for bringing this up!
Given that a Community Configuration edit is potentially very high-impact, and more likely to always require an edit summary, I'm not sure if we would want to rely on that setting if it's opt-in on most wikis.

But if others think it's problematic to not follow that Editing Preference, I'm willing to reconsider.

KStoller-WMF set the point value for this task to 3.Feb 20 2024, 4:36 PM

I think the "diff" preview might be challenging to display when several changes have been made. @JFernandez-WMF do you have advise on how could we handle that situation? I suggest splitting the preview into a different task.

I think the "diff" preview might be challenging to display when several changes have been made. @JFernandez-WMF do you have advise on how could we handle that situation? I suggest splitting the preview into a different task.

I've split the diff preview into a separate task and assigned to @JFernandez-WMF to finalize requirements: T358035: Community Configuration: Design Diff for Edit Summary

I updated the task description with some changes regarding this dialog and its edit summary. We are going to have now a helper text instead of a message reminder, so the helper text is always going to be there (meaning it will NOT be prompted by an action), under the edit summary field. @Cyndymediawiksim feel free to ask any questions if this needs more clarification.

I’m not sure if this is a good change. With the reminder approach, the user needs to acknowledge the reminder, which a) makes sure that they noticed it and b) makes sure that they can’t accidentally (e.g. by pressing Enter while focusing on the wrong button) submit the edit without the summary. With the helper text approach, neither is true.

I’m not sure if this is a good change. With the reminder approach, the user needs to acknowledge the reminder, which a) makes sure that they noticed it and b) makes sure that they can’t accidentally (e.g. by pressing Enter while focusing on the wrong button) submit the edit without the summary. With the helper text approach, neither is true.

Thank you for spending the time to give us feedback! Honestly, I have the same hesitation, and I wouldn't suggest this approach for a feature that was going to be used by all editors. But given that edits to Community Configuration will only be made by very experienced editors (only Admins at this point), I'm less concerned with this simplification.

In general, I agree with your thoughts about aligning the design with the current VisualEditor save dialog (https://phabricator.wikimedia.org/T358035#9612918). But since edits to Community Configuration will only happen occasionally and only be made by Admins, I think it's probably safe to limit some of the complexity if it saves considerable engineering time. We are building out the Community Configuration Edit Summary using Codex. There are still some components missing from Codex, and it would drastically increase the scope of this work if we mirrored the VisualEditor save dialog exactly.

@Tacsipacsi given that info, are you still concerned about this simplified approach?

I’m not sure if this is a good change. With the reminder approach, the user needs to acknowledge the reminder, which a) makes sure that they noticed it and b) makes sure that they can’t accidentally (e.g. by pressing Enter while focusing on the wrong button) submit the edit without the summary. With the helper text approach, neither is true.

Thank you for spending the time to give us feedback! Honestly, I have the same hesitation, and I wouldn't suggest this approach for a feature that was going to be used by all editors. But given that edits to Community Configuration will only be made by very experienced editors (only Admins at this point), I'm less concerned with this simplification.

Accidental submission isn’t a problem specific to newcomers. Also, the starting point was that the edit summary should be “more required” than when editing regular pages – now the opposite is the case, because it’s technically entirely optional (no warning when not provided, it’s even labeled (optional)), even for people who turned on the preference mentioned in T354463#9439215.

We are building out the Community Configuration Edit Summary using Codex. There are still some components missing from Codex, and it would drastically increase the scope of this work if we mirrored the VisualEditor save dialog exactly.

So Codex seems to be intentionally designed to be quite similar yet subtly different from OOUI… I’m not sure if this was a good decision by the Codex developers, but Community Configuration probably can’t do much about it.

Change 1010495 had a related patch set uploaded (by Cyndywikime; author: Cyndywikime):

[mediawiki/extensions/CommunityConfiguration@master] Implement EditSummaryDialog in Community Configuration

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

Accidental submission isn’t a problem specific to newcomers. Also, the starting point was that the edit summary should be “more required” than when editing regular pages – now the opposite is the case, because it’s technically entirely optional (no warning when not provided, it’s even labeled (optional)), even for people who turned on the preference mentioned in T354463#9439215.

Thanks for the feedback!
I agree that the optional label is odd, and I actually mentioned a similar sentiment in the Figma designs:

I wonder if this "(Optional)" text is appropriate? When editing on English Wikipedia the comparable text is: "(Briefly describe your changes)". Given that we want to encourage all admins to leave an Edit Summary, perhaps we should either remove "Optional" or have different copy here?

I'll discuss with our designer who is finalizing copy.

And I've added a follow up task for the larger effort of presenting a warning for blank edit summaries: T359984: Community Configuration: adhere to "Prompt me when entering a blank edit summary" settings

I still don’t understand why you changed your minds about how required the edit summary should be, but as long as T359984 will get implemented, I’m fine with it.

Change rMW1011094ce102 had a related patch set uploaded (by Cyndywikime; author: Cyndywikime):

[mediawiki/extensions/CommunityConfiguration@master] Implement EditSummaryDialog in Community Configuration

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

Change 1010495 abandoned by Cyndywikime:

[mediawiki/extensions/CommunityConfiguration@master] Implement EditSummaryDialog in Community Configuration

Reason:

Abandoned in favour of this patch : https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CommunityConfiguration/+/1011094

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

Change #1011094 merged by jenkins-bot:

[mediawiki/extensions/CommunityConfiguration@master] Editor: Add EditSummaryDialog to Community Configuration

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

Etonkovidova subscribed.

Checked in eswiki beta. For @JFernandez-WMF quick review - the screenshot below is the Edit Summary in eswiki beta. All seems to be according to the mockup in the task description (given that some features will be addressed later). If everything looks ok - you may move it to Test in Production.

Screen Shot 2024-03-28 at 2.52.10 PM.png (960×1 px, 162 KB)

Two minor questions:

  • on submitting edits in VE, there is a footer with legal clause with links to licensees and to the Terms of Use. Do we need a link to the Terms of Use in the Edit Summary too?

Screen Shot 2024-03-28 at 3.44.53 PM.png (900×1 px, 117 KB)

  • the placement of the Reminder is the same as for the footer for saving edits which might confuse those users who used to see different footer.

Screen Shot 2024-03-28 at 2.52.10 PM.png (960×1 px, 162 KB)

I noticed two differences that I’m not sure if they are intentional:

  • The (optional) text is bold. In both designs in the description, it has a normal weight.
  • The summary box is huge. In one design, it’s a two-line textbox, in the other one, it’s a one-line input; in the implementation, it’s eight lines tall. This gives the impression that the edit summary can be however long I want it to be (and indeed, nothing on the frontend prevents me from writing an over 1000 characters long summary, even though the backend (MW core) caps the summary at 500 characters).

Two minor questions:

  • on submitting edits in VE, there is a footer with legal clause with links to licensees and to the Terms of Use. Do we need a link to the Terms of Use in the Edit Summary too?
  • the placement of the Reminder is the same as for the footer for saving edits which might confuse those users who used to see different footer.

What if both messages were displayed below each other, with the Reminder being above and maybe on a grey background (like the checkboxes in VE)? Especially the color difference would stress that this is not just the usual stuff.

A tangential comment: I could change and save the configuration on eswiki beta without getting any error message. Of course, the configuration wasn’t in fact saved, since I’m not an admin or interface admin there. While it’s useful in this testing phase that I can try out much of the interface even if I don’t have rights, it shouldn’t remain this way in the finished version.

Thank you for testing, @Tacsipacsi! I added your comments in https://phabricator.wikimedia.org/T354463#9674654 to T361324: [QA task] Community Configuration UI evaluation . That task is for having one place for me to keep track of all UI issues found during testing.

A tangential comment: I could change and save the configuration on eswiki beta without getting any error message. Of course, the configuration wasn’t in fact saved, since I’m not an admin or interface admin there. While it’s useful in this testing phase that I can try out much of the interface even if I don’t have rights, it shouldn’t remain this way in the finished version.

This is a known issue and will be addressed in T360919: Design: Special:CommunityConfiguration should display in an inactive state to non-administrators.

  • The summary box is huge. In one design, it’s a two-line textbox, in the other one, it’s a one-line input; in the implementation, it’s eight lines tall. This gives the impression that the edit summary can be however long I want it to be (and indeed, nothing on the frontend prevents me from writing an over 1000 characters long summary, even though the backend (MW core) caps the summary at 500 characters).

@JFernandez-WMF, in line with @Tacsipacsi's comment, what should be the correct number of lines given the backend (MW core) caps the summary at 500 characters)?

what should be the correct number of lines given the backend (MW core) caps the summary at 500 characters)?

Both the first design and VisualEditor present the edit summary as a textbox with two lines by default (VE uses an autosized box, the design shows a grabber). I think that’s convenient (and consistent with VE).

Also, in VisualEditor, the frontend caps the summary at 500 characters, not the backend, and it shows the number of characters left when the user exceeded 400 characters; this should be implemented here as well, because this gives the user a chance to rephrase the summary to stay within the limit, rather than cutting off potentially in the middle of a word. (I couldn’t find an option in Codex to do this, so maybe Codex should be enhanced to support at least the maxlength attribute, but potentially also the “characters left” thing.)

Hi all, there's an option in Codex to add a character count, so we can use that:

Dialog (12).png (316×518 px, 28 KB)

I am guessing we can either have the character count start at 500 straight away, or start showing the character count when there are 99 characters left, like VE does.

Thanks, @JFernandez-WMF!
I've created a separate task to cover that work: T362285: Community Configuration: Add Character count to Edit Summary

start showing the character count when there are 99 characters left, like VE does.

I went with that approach, but open to other options if anyone has an argument to consider showing the count immediately.

Moving this task back to QA so @Etonkovidova can determine if the original task is resolved. Thanks!

Thanks, @JFernandez-WMF!
I've created a separate task to cover that work: T362285: Community Configuration: Add Character count to Edit Summary

start showing the character count when there are 99 characters left, like VE does.

I went with that approach, but open to other options if anyone has an argument to consider showing the count immediately.

Moving this task back to QA so @Etonkovidova can determine if the original task is resolved. Thanks!

Thx, @Kirsten - I've reviewed the task acceptance criteria and the current implementation on eswiki betalabs - all seem to be in place. I'm moving the task to Verify in Production column.