402884 - Approve and Reject buttons for reviewing article edits

Status: RESOLVED FIXED

(support.mozilla.org :: Knowledge Base Software, task)

Description

[Chris Ilias [:cilias]]

When someone makes an edit to a staging copy, and that edit is waiting for review, reviewers need a simple Approve/Reject mechanism. Ideally, this would be in the form of buttons.

[Reject] would erase the edit, and adjust any subsequent edits waiting for review (if needed).

[Approve] would apply the edit to the live version of the article, as well as add the contributor's name to the live version (that's bug 401917)

Notes:
- This is "per edit"; so one article can receive many edits, and each edit has a Approve/Reject mechanism.
- Consecutive edits by the same person should be treated as one edit.

Comment 1

[Chris Ilias [:cilias]]

I should add:

- this should only apply to articles starting with an asterisk.

- we should also have a method of documenting who approves each edit.

Comment 2

[Nelson Ko [:nkoth]]

It is very difficult for me to "*adjust* any subsequent edits waiting for
review (if needed)". I probably don't want to try.

Why not have just one approve? I think it is easier for the reviewer to see the combined changes all at one go. 

If you really want to have multiple approves, it is a bit more work, but doable, but it won't allow inter-edit *adjustments*.

Either way, the user list will be correct, and the wiki history in both pages will reflect the exact edits as submitted.

Comment 3

[Nelson Ko [:nkoth]]

there are some thing done upstream that will be available with next Tiki sync.

For now, I have created:

1) A button that will open in a new window showing the diff between the last approved version and the currently staged version (i.e. cumulative changes). At the bottom of the diff will be a list of versions (just like the current history page). You can see who did edits between this version and the current one. To see each individual commit, you can diff it as per the current UI for history. You can also rollback, as per the current UI, or make your own fine-tuning edits.

2) An approve button that will approve the cumulative changes. This is to be used once you are happy with the article. On approval, the approved article authorship is updated with content & authorship & tags. You will see a table of versions and authors that led up to the current approval.

I'll leave it like this for now. We can do future enhancements after this is in broader use.

Comment 4

[Chris Ilias [:cilias]]

That sounds good. The only concern that comes to mind, is being able to choose the type of diff. I find HTML diff useless, and I always use side-by-side diff. In fact, if there's anyone that objects, I'd like side-by-side to be the default. But that's another bug to be filed. :-)

Comment 5

[David Tenser [:djst]]

One thing that seems to have been forgotten here is automatically removing the "review" keyword from the staging copy when an edit is completed. I've filed bug 406793 for the corresponding adding of the keyword when editing a staging copy.

Comment 6

[David Tenser [:djst]]

(In reply to comment #5)
> One thing that seems to have been forgotten here is automatically removing the
> "review" keyword from the staging copy when an edit is completed. I've filed
> bug 406793 for the corresponding adding of the keyword when editing a staging
> copy.
> 

Please disregard my last comment. Here's how it will work according to Nelson:

"actually what will happen is that when a staging copy is edited, it is placed in the "out of sync" category (you can set this any other name, e.g. "Needs Review"). When it is approved, it is taken out of there. You can see stuff that is out of sync by browsing the "out of sync" category."

Comment 7

[Chris Ilias [:cilias]]

I just tried editing an a staging copy on support-stage, and I didn't see any "out of sync" category afterwards, nor did I see any [Approve] or [Reject] buttons.

Comment 8

[David Tenser [:djst]]

The FIXED resolution reflects that this is fixed in upstream Tiki, which will be synced for SUMO. Nelson, is that correct?

Comment 9

[Nelson Ko [:nkoth]]

yes. maybe you should not set the VERIFY status until it is actually all done?

Comment 10

[David Tenser [:djst]]

"maybe" -- definitely :) My mistake, sorry about that.

Comment 11

[Nelson Ko [:nkoth]]

Please try it on support-stage now. As the db is resynced in the morning, some settings are lost and may need to be reset in the mornings. I will do this if I remember - otherwise:

go to Admin Home... Wiki, under "Wiki page staging and approval", check all the checkboxes, and set "category to Out of Sync" to "Out of Sync" and the other two categories to "Staging" and "KB" respectively. 

Then go to "Admin Home...Categories" , and set "Exclude These Category IDs from Path (comma delimited)" to "11,12,13,14" or whatever the category Ids are of the categories for "Out of Sync", "Firefox 2", "Firefox 3" and "Ready for Review".

These appear as checkboxes when editing an article (so they are to be used instead of tags for such things).

Comment 12

[Nelson Ko [:nkoth]]

See comment of bug 398761 for more info on how this is different from the future hidden tags feature.

Comment 13

[Chris Ilias [:cilias]]

I'll comment on the category and hidden tag stuff in their respective articles. As far as approve/reject buttons, I only see an approve mechanism.

Comment 14

[Nelson Ko [:nkoth]]

yes. there is only an approve mechanism. To reject, you have to manually roll-back in the history or make further edits before approving.

Note that credit is given wiki-style, i.e. everyone is given credit, even if their edit is rolled back/accepted in part. If you really don't want to give someone credit at all, for example, in the case of a vandal, you can (as an admin) totally delete that version from the wiki history. But only admins can do this, for good reason.

I recommend anyone be given credit unless it is clearly vandalism, because it in typical wiki spirit, even bad suggestions help form the final product, but showing what are bad suggestions.