@Pginer-WMF This is great! I really like the check icon for resolved topics, and keeping the summary in the header makes sense. The prototype and video were also super helpful. :)

I wrote the new spec at the top of the ticket, in as much detail as I could think of. There are some questions that came up:

#1. I think we need a Cancel link for all of the actions (resolve, reopen, summarize, edit summary).

#2. For a resolved topic, you can see the messages by clicking on the topic header. Can you hide them again the same way? Also: we removed collapse/uncollapse from the board a little while ago because it didn't really fit any use case except to be a ToC. If you can collapse/uncollapse for resolved topics, should that also happen on open topics? (My preference would be to only have that on resolved topics, because there's an actual use case for it.)

#3. I'm assuming you can edit the summary on a resolved topic. Is that right?

#4. In the current Lock user flow, we put "This topic was locked by Username", but we don't put a byline on the topic summary. I'm glad we're combining the "reason" into the summary, but the "Summary by Username" byline feels heavy to me -- especially for the summary on an open topic. The most common use cases for summary & resolving may be things that are done as a matter of course -- "This discussion will be closed on Thursday" -- and it doesn't really matter who pulls the trigger on resolving it. We could treat it with the same weight as people who edit a post -- putting it down on the lower right. What do you think?

#5. This one's actually a bug in the current feature :) -- if you edit an existing summary and blank the text, to remove the summary completely, the Summarize button grays out and doesn't let you do it. I corrected that in the spec above.

#6. The "Keep summary" button doesn't quite fit when you're editing an existing summary, or reopening the topic. The editing field opens, and you could edit or blank the summary. What should the button say for Edit summary and Reopen topic?

#7. Do we have already have the icons for the checkmark in the topic header, the checkmark in the dropdown, and the Reopen topic icon in the dropdown?

#8. I think we'll need to adjust the topic headers for Hide/Delete/Suppress. Those will need "Hidden by Username timeago" in the summary area under the line.

Okay, those are all the details I can think of. :) Brain tired now.

1. I think we need a Cancel link for all of the actions (resolve, reopen, summarize, edit summary).

There are a couple of details on the rational of some design decisions that may help to clarify this:

• Making Resolve/Reopen direct. For an action such as resolve or reopen it make sense to make them as direct as possible: you mark it as resolved and it becomes resolved. There is no need for usr confirmation since (a) it is clear that it became resolved (with the aded tick mark) and (b) it is clear how to revert the actin if it was a mistake (the user will just go to the same menu and reopen it). For other actions (e.g., if they make the content disappear) it may make sense to apply other patterns (such as notification + undo, or asking for permission).

• Connecting closing actions with the summary actions. After resolve/reopen a topic it makes sense to provide a summary. When transitioning the user to the summary editing we need to adjust a bit the messages to clarify the current status: if you show a "cancel" option, it is not clear whether that action will revert the "resolve" action you triggered before. By showing "Skip summary" in this context we communicate the idea of cancelling the summary action but keep the topic as resolved. Note that these changes will only happen when accessing the summary editing as part of the resolve/reopen workflow. For other context, the labels should remain unafected (e.g., if I click summarize anytime, I'll see the "cancel" button).

2. For a resolved topic, you can see the messages by clicking on the topic header. Can you hide them again the same way? Also: we removed collapse/uncollapse from the board a little while ago because it didn't really fit any use case except to be a ToC. If you can collapse/uncollapse for resolved topics, should that also happen on open topics? (My preference would be to only have that on resolved topics, because there's an actual use case for it.)

I think it make sense to collapse/uncollapse resolved topics and it is ok if we just provide the functionality for them since they are collapsed by default.

3. I'm assuming you can edit the summary on a resolved topic. Is that right?

Yes. You can edit the summary on any topic. The resolved/reopen actions transition automatically to edit summary (with some adjustment in the action names as described above) for convenience (anticipating the next step), but the regular summary editing should remain as it is.

4. In the current Lock user flow, we put "This topic was locked by Username", but we don't put a byline on the topic summary. I'm glad we're combining the "reason" into the summary, but the "Summary by Username" byline feels heavy to me -- especially for the summary on an open topic. The most common use cases for summary & resolving may be things that are done as a matter of course -- "This discussion will be closed on Thursday" -- and it doesn't really matter who pulls the trigger on resolving it. We could treat it with the same weight as people who edit a post -- putting it down on the lower right. What do you think?

The reason was to keep the placement consistent with author info which is at the top-left of the content they create on posts. I kept the author of the summary in grey (and combined with the "summary label) to reduce the prominence, but we can think of other approaches.

6. The "Keep summary" button doesn't quite fit when you're editing an existing summary, or reopening the topic. The editing field opens, and you could edit or blank the summary. What should the button say for Edit summary and Reopen topic?

"Keep summary" is only expected to be shown when (a) the user access the summarize action as a continuation from resolve/reopen actions, (b) the topic has already a summary, and (c) the user has not modified the summary text yet. That allows to keep the summary (including the authorship by another user), and communicate that the resolve/reopen action is positively completed (in this context a "cancel"-like action would be confusing).
In other contexts, the regular summary actions ("cancel" and "summarize" are expected).

7. Do we have already have the icons for the checkmark in the topic header, the checkmark in the dropdown, and the Reopen topic icon in the dropdown?

There is an icon for the tick mark. The rest were created as I explored ways to represent concepts such as resolved/ongoing conversations. I'll export them and add them to this ticket.

8. I think we'll need to adjust the topic headers for Hide/Delete/Suppress. Those will need "Hidden by Username timeago" in the summary area under the line

I'm less familiar with those actions. We can create a ticket with screenshots to adjust those and make sure they remain consistent.

Currently, rev_mod_reason is used for the lock reason (lock is a moderation action)
We'll want to stop using rev_mod_reason and change summary (another revision object) when locking (now resolving).
But other places (e.g. recentchanges etc) may depend on rev_mod_reason to render moderation related things.

We'll want to stop using rev_mod_reason and change summary (another revision object) when locking (now resolving).

We discussed instead just using a simulated message (e.g. "Resolved the topic") as the rev_mod_reason.

When this is implemented, what's going to happen to topics that were already Locked?

Do they still look the same way, or should it change to the new format?

Change 217017 had a related patch set uploaded (by Mattflaschen):
WIP: Implement "Mark as resolved" user workflow

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

When this is implemented, what's going to happen to topics that were already Locked?

I think they should change to the new format. I see our change more as a rename (making the action more clear and fluent to apply) rather than removing some state and introducing a completely different one.

Keeping the old "locked" would also imply keeping the "unlock" action for those posts which may make things more complex than needed.

In T98929#1350053, @Pginer-WMF wrote:

When this is implemented, what's going to happen to topics that were already Locked?

I think they should change to the new format. I see our change more as a rename (making the action more clear and fluent to apply) rather than removing some state and introducing a completely different one.

We're on the same page then. This is pretty much how I'm implementing it.

Excellent, that's what I was hoping for. :)

Change 217408 had a related patch set uploaded (by Mattflaschen):
WIP: Add ongoingConversation icon

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

Change 217408 merged by jenkins-bot:
MediaWiki, Apex themes: Add ongoingConversation icon

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

I looked at this on RoanWiki, and found a few bugs to clear up.

• The styling for the summary should be the same size, spacing etc as regular text.
• A resolved topic should say "closed timeago" in place of the regular timeago.
• A reopened topic should go back to regular timeago, showing the time of the last post or edit -- not showing the time when it was resolved or reopened.
• When there's an existing summary, the link for "Skip summary" should not appear. In those cases, just have the "Update summary" button.
• The clickable area for collapsing should include the summary.

The clickable area for collapsing should include the summary

If I make the entire topic area clickable, it also gets activated when I click the timestamp or any menu item.

I can make the topic title and the summary clickable and not the space in between?

Whatever we choose, I feel we are missing a visual cue that something is even clickable and what it's going to do.

Yes, do the topic title and summary, without the space in between.

I agree that we may be missing a visual cue. My plan is to try it out and see what happens.

A resolved topic should say "closed timeago" in place of the regular timeago.
A reopened topic should go back to regular timeago, showing the time of the last post or edit -- not showing the time when it was resolved or reopened.

I think these are very interesting ideas and I would like to do them. If you think the feature is usable as is, I would like to merge it and get some serious QA before adding anything else. Let me know if you want me to work on it right away or create another task.

Great progress! I tried the patchset and I wanted to comment on some details worth considering (even if they are executed in upcoming iterations):

• When a topic is collapsed, the "X comments" indicator should act as a trigger to expand/collapse it. It should behave as a regular link (turning blue on hover, and turning the cursor into the usual pointing hand). The topic link can also use the "hand" cursor to convey the interaction a bit more.
• The action for mark as resolve in the menu should not be red. Red communicates data loss (which is not the case) and sends a warning message for an action that we are presenting as positive (you are getting work done) and fluent (you can undo it easily). We can make it blue on hover (quiet-progressive) to indicate it moves the topic one step in a process and distinguish it from simple navigation actions.
• A placeholder text is missing in the summary text area. Especially when transitioning from resolving a task, the summary can help explain why the user is asked to add some text. The summary can be something along the lines of "Describe briefly the outcome of this discussion". Even if it cannot be done for VE due to T96593, we should support it at least for Wikitext.
• For a resolved topic, if it has no summary reopening it should not open the (empty) summary to be edited. If the conversation was closed and there is no summarised outcome, it is not likely that there will be one when reopening it. Note that for resolved topics with a summary, it makes sense to ask the user to consider updating them since the discussion outcome may not apply after reopening it again.
• On summarised topics there is no indication of authorship. In the prototype I included a label above the summary ("Summarised by X") to make it clear that the text below is a summary and who created it.
• When editing a summary after resolving a topic, the "update summary button" should be disabled until the text is modified. Otherwise the user is presented a choice between that and "Skip summary" which is not clear (since both actions do the same at that point in time).

When a topic is collapsed, the "X comments" indicator should act as a trigger to expand/collapse it. It should behave as a regular link (turning blue on hover, and turning the cursor into the usual pointing hand). The topic link can also use the "hand" cursor to convey the interaction a bit more.

Done. The style of the link may need some tweaking. It stands out a lot:

The action for mark as resolve in the menu should not be red. Red communicates data loss (which is not the case) and sends a warning message for an action that we are presenting as positive (you are getting work done) and fluent (you can undo it easily). We can make it blue on hover (quiet-progressive) to indicate it moves the topic one step in a process and distinguish it from simple navigation actions.

Done but mw-ui-icon-ongoingConversation-progressive-hover doesn't render, or doesn't exist. I don't know how it works, I'll check with @Catrope

On summarised topics there is no indication of authorship. In the prototype I included a label above the summary ("Summarised by X") to make it clear that the text below is a summary and who created it.

Was extracted to T102665: Mark as resolved: Add authors line to topic summary (v2 if needed)

Done. The style of the link may need some tweaking. It stands out a lot:

Sorry, I didn't describe it properly. The idea was to make it consistent with the timestamp next to it: grey by default ,but styled as a link on hover.

Change 219419 had a related patch set uploaded (by Sbisson):
Add progressive variant to ongoingConversation icon

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

Change 219419 merged by jenkins-bot:
MediaWiki theme: Add progressive variant to ongoingConversation icon

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

Change 217017 merged by jenkins-bot:
Implement "Mark as resolved" user workflow

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

• https://gerrit.wikimedia.org/r/217017 (branch master): WMF-deploy-2015-06-16_(1.26wmf10)

In T98929#1384824, @Forrestbot wrote:

• https://gerrit.wikimedia.org/r/217017 (branch master): WMF-deploy-2015-06-16_(1.26wmf10)

That's wrong, removing. Bug in @Forrestbot ?

In T98929#1385349, @Catrope wrote:

In T98929#1384824, @Forrestbot wrote:

• https://gerrit.wikimedia.org/r/217017 (branch master): WMF-deploy-2015-06-16_(1.26wmf10)

That's wrong, removing. Bug in @Forrestbot ?

Presumably because https://gerrit.wikimedia.org/r/217408 was linked here?

Checked on http://test.wikimedia.beta.wmflabs.org/wiki/Talk:ET9.

Only two(small) things to address (besides the issue with not displaying user names for closed/re-opened topics).

1. clicking 'Mark as resolved' - the 'Update summary' button appears active and green, not according to the following requirement:

Update summary button is grayed out until there's text in the field

2. Currently, there is no indication that a topic was closed/re-opened. If we decide to show that a topic was re-opened, what to do with a timestamp for re-open action?

A resolved topic should say "closed timeago" in place of the regular timeago.
A reopened topic should go back to regular timeago, showing the time of the last post or edit -- not showing the time when it was resolved or reopened.