@Dogu Would you be available to work on this?

Is the proposal here to have "accept changes" have a border, and "reject changes" have no border? That doesn't seem right, since both actions edit the database. Might be better to have "reject changes" have a border.

Hey @DTorsani-WMF, Thanks for reaching out! Unfortunately, I’m currently tied up and won’t be able to work on this immediately.

@Novem_Linguae One is a normal weight button while the other is a quiet weight button, since the "reject changes" button is used less, and while it is a somewhat equivalent action, it is also destructive, so it becomes more prominent than the "accept" action. This is why we suggest using a quiet button, so to not over power the neutral, "accept" action, and because it is used less commonly than the accept action.

@Dogu Thanks for the heads up. We can leave this task open until someone is able to work on it.

• The combination of Buttons when reviewing revisions should be neutral normal for "Accept revision" and destructive quiet for "Reject changes".

Couldn’t it remain as it is, with one normal progressive and one normal destructive button? Couldn’t Codex be reverted to use less colors for non-neutral normal buttons? A quiet button means something relatively safe to me (compare the Cancel button of the edit window ­– it does nothing, just closes the edit window without saving), and this one isn’t safe: while it asks once again, it makes an edit (a revert) after that question, which isn’t safe.

• When a revision is either accepted or rejected, we suggest not showing the fact that this action is "done" using a disabled Button. Instead a Toast should be used when that becomes available in Codex. In the meantime, changing the actions is probably enough to show that something was done.
• When a revision is accepted, the "Reject changes" button should remain disabled, and the other action should remain a destructive normal Button.

I don’t follow you. In the first bullet point, you say FlaggedRevs should not use a disabled button; in the second bullet point, you say it should. (By the way, we already have mw.notify() readily available, why does the MediaWiki ecosystem need yet another way to display messages, namely Toast?)

• Additionally, the "Filter pending changes" Button on the Special:PendingChanges page should be a neutral normal Button.

OOUI special pages (Special:Log, Special:Contribs etc.) usually use primary progressive buttons; for consistency, I’d keep this one progressive (and maybe make it primary instead of normal). However, if the change is made consistently across all special pages, I have nothing against it.

Just to clarify, are toast and mw.notify two different things? If so what does a toast look like?

See the screenshots in the description of T303612. A toast message is centered/full screen width and usually at the bottom of the screen, while mw.notify() appears at the bottom right of the screen on desktop skins – however, Minerva actually makes mw.notify() a toast message by displaying it centered, in almost full screen width at the bottom of the screen.

Regarding the Toast, I've removed that part of the recommendation from the task description to avoid confusion. It is a recommendation for future improvement but cannot be implemented today until the Toast is added to Codex (T303612). mw.notify() will likely be eventually ported to use the Codex Toast for consistency.

In T384331#10497438, @CCiufo-WMF wrote:

Regarding the Toast, I've removed that part of the recommendation from the task description to avoid confusion. It is a recommendation for future improvement but cannot be implemented today until the Toast is added to Codex (T303612). mw.notify() will likely be eventually ported to use the Codex Toast for consistency.

Actually, I guess it could be implemented using mw.notify() in the interim if that's accessible here.

I have revised the task description to hopefully add some more clarity to this guidance. Additionally, as mentioned, this guidance will be documented on the "Using links and buttons" page on the Codex docs site. These guidelines will be published soon, but can be previewed in the patch preview. From a Codex perspective, we feel confident in these guidelines, visual styles, and have attempted to apply them to the scenario discussed. However, we are not the experts in the FlaggedRevisions extension, so we defer to the maintainers on the best application of these guidelines for this feature.