(In reply to comment #4)
> (In reply to comment #2)
> > Just as an addition to this: I'm not sure if just the checkbox is what is
> > needed. The current work flow has a whole separate page because we need to
> > show the diff involved for the review. I imagine that can be done without
> > going to a new page but either way they should be able to review the diff
> > (and preferably leave a comment like you can in the review page now) before
> > checking any kind of approve box since they become somewhat responsible for
> > those edits.
> 
> Yes, indeed; I was imagining:
> 
> * on load, an alert in the edit notices saying "You will need to accept the
> outstanding changes before saving" (or whatever the current message is) -
> possibly with a link to the below?
> * on entering the save dialog, the save button will be disabled with another
> copy of the "You will need to accept the outstanding changes before saving"
> text (in the same place as the edit conflict / CAPTCHA / DOM corruption
> warnings)
> * in the line of buttons ("Save page", "Review your changes") there should
> be a
> third button, "Review outstanding changes", which on click pops up the diff
> of
> outstanding changes, with a text box for the optional review comment and an
> "accept these changes" button that takes you back to the save dialog, now
> with
> the save button enabled.
> 
> Feels a little clunky, though - perhaps we could make the process in-line
> with
> the edit summary message?

Since this is going to need to be fully in javascript for VisualEditor, and the interface for this in FlaggedRevisions is already mostly in javascript (a small bit is done server-side through EditPage hooks), I recommend we not duplicate all of this logic and API handling for:
* "advertise you are reviewing this"
* API handling "leave comments"
 "get the diff against the latest stable version"
* "mark as reviewed" 
* etc.

And instead depend on the logic being in FlaggedRevisions in a re-usable way that we can just call from within VisualEditor.

Ideally they would also make their styling more pretty so that we can actually re-use it. Alternatively they'll have to make the logic re-usable separate from the UI as the current UI is not going to fit in (not just visually foreign to VisualEditor or usable interfaces in general, but also technically due to the DOM structure and layout properties).