Recapping the contributor process
Chris Ilias
re-summarize the process of contributing and reviewing:
* For each article, there is a knowledge base version, and staging copy.
The staging copy is given the same name as the KB version, but with an
asterisk in front. (KB=Passwords, Staging=*Passwords)
* In order to edit an article, one must edit the staging copy first.
* Once an edit is made, the edit is tagged for review. Anyone with given
permission, can either approve or reject the edit.
** Once approved, the edit is applied to the KB version of the article.
** If the editor has reviewer permission, their own edit is
automatically approved.
** Approvals and rejections are done on an edit-by-edit basis; so if
there has been more than one edit to a staging copy, each edit has to be
approved or rejected. (Could be tricky in cases where a good edit comes
after a rejected edit.)
If that's it, some specific details are:
* There's no need for an edit button on KB articles. Only edit staging copy.
* Clicking on edit staging copy will show a preview of the staging copy,
in case it is different from the live version.
* Clicking on edit staging copy will show a message saying that it the
changes will require review. before going live.
* Once an edit is made, we need a way of listing edits in need of
review, for reviewers.
* Once the edit is made, we need a simple approval/rejection mechanism,
like buttons [Approve] [Reject].
* Once approved, the contributor's name is also added to the KB version.
Jason Barnabe (np)
> ** Approvals and rejections are done on an edit-by-edit basis; so if
> there has been more than one edit to a staging copy, each edit has to be
> approved or rejected. (Could be tricky in cases where a good edit comes
> after a rejected edit.)
Is there a danger with cluttering up the history by doing this? I know
I like to save often.
> * There's no need for an edit button on KB articles. Only edit staging copy.
Approvers will still need the edit button. Maybe do "edit"->"edit live
version" and "edit staging copy"->"edit" to make things more clear?
Chris Ilias
> On Nov 6, 2:12 am, Chris Ilias <n...@ilias.ca> wrote:
>> ** Approvals and rejections are done on an edit-by-edit basis; so if
>> there has been more than one edit to a staging copy, each edit has to be
>> approved or rejected. (Could be tricky in cases where a good edit comes
>> after a rejected edit.)
>
> Is there a danger with cluttering up the history by doing this? I know
> I like to save often.
I don't think that should cause a problem.
>> * There's no need for an edit button on KB articles. Only edit staging copy.
>
> Approvers will still need the edit button. Maybe do "edit"->"edit live
> version" and "edit staging copy"->"edit" to make things more clear?
Right now, approvers see two buttons: [edit] and [edit staging copy]. If
all edits (by approver or not) have to be done to the staging copy
first, I don't see the need for a edit button.
Ideally, I'd like this recap implemented before opening the door on l10n.
David Tenser
> Okay, given the discussions over the past weeks, I think we need to
> re-summarize the process of contributing and reviewing:
>
> * For each article, there is a knowledge base version, and staging copy.
> The staging copy is given the same name as the KB version, but with an
> asterisk in front. (KB=Passwords, Staging=*Passwords)
>
> * In order to edit an article, one must edit the staging copy first.
>
> * Once an edit is made, the edit is tagged for review. Anyone with given
> permission, can either approve or reject the edit.
The tagging should be done automatically, if possible. (bug filed?)
> ** Once approved, the edit is applied to the KB version of the article.
> ** If the editor has reviewer permission, their own edit is
> automatically approved.
> ** Approvals and rejections are done on an edit-by-edit basis; so if
> there has been more than one edit to a staging copy, each edit has to be
> approved or rejected. (Could be tricky in cases where a good edit comes
> after a rejected edit.)
Might be possible to treat several consecutive edits from the same
contributor as one single edit? That would solve Jason's use case (a
behavior I have as well, btw).
>
> If that's it, some specific details are:
> * There's no need for an edit button on KB articles. Only edit staging
> copy.
Yes, but it should be called "Edit This Page". The fact that it's queued
for review should be reflected on the message you mention below.
> * Clicking on edit staging copy will show a preview of the staging copy,
> in case it is different from the live version.
Not sure if this is needed. It might be sufficient to just say "The
article you are editing differs from the live version bla bla." and then
the contributor can preview by clicking the button as normal.
> * Clicking on edit staging copy will show a message saying that it the
> changes will require review. before going live.
Yeah, this is the message I referred to twice above.
> * Once an edit is made, we need a way of listing edits in need of
> review, for reviewers.
Just a simple tag query that we add a link to on the contributor page
(or even in the contributor tools box).
> * Once the edit is made, we need a simple approval/rejection mechanism,
> like buttons [Approve] [Reject].
Bug for that?
> * Once approved, the contributor's name is also added to the KB version.
Bug for that?
Good list of what we need to make contributing not suck. The question
now is how we want to prioritize this (before or after l10n). I have no
direct answer, but both this and l10n are critical to the community
acceptance of SUMO.
Chris Ilias
> Chris Ilias wrote:
>
>> * Once an edit is made, the edit is tagged for review. Anyone with
>> given permission, can either approve or reject the edit.
>
> The tagging should be done automatically, if possible. (bug filed?)
Sort of. <https://bugzilla.mozilla.org/show_bug.cgi?id=401916>
Part of the reason for this recap is get a clearer definition of the
entire structure, so we can better define to people like Nelson and
Mike, what we want.
>> ** Approvals and rejections are done on an edit-by-edit basis; so if
>> there has been more than one edit to a staging copy, each edit has to
>> be approved or rejected. (Could be tricky in cases where a good edit
>> comes after a rejected edit.)
>
> Might be possible to treat several consecutive edits from the same
> contributor as one single edit? That would solve Jason's use case (a
> behavior I have as well, btw).
Right now, I'm inclined to say yes that would solve Jason's problem,
because I know there are times where I've made edits, then found a bunch
of mistakes I've made.
>> * Clicking on edit staging copy will show a preview of the staging
>> copy, in case it is different from the live version.
>
> Not sure if this is needed. It might be sufficient to just say "The
> article you are editing differs from the live version bla bla." and then
> the contributor can preview by clicking the button as normal.
Nelson and I discussed this last week, and what I found was that the
preview page (click on edit, then click preview) gives what we want,
which is a preview of the article, and the editor underneath.
The only problem was the message at the top, saying "Note: Remember that
this is only a preview, and has not yet been saved!" would need to be
different.
>> * Once an edit is made, we need a way of listing edits in need of
>> review, for reviewers.
>
> Just a simple tag query that we add a link to on the contributor page
> (or even in the contributor tools box).
FWIW, I added it to the contributor box last night. :-)
>> * Once the edit is made, we need a simple approval/rejection
>> mechanism, like buttons [Approve] [Reject].
>
> Bug for that?
Not yet. I'll file it tonight.
>> * Once approved, the contributor's name is also added to the KB version.
>
> Bug for that?
https://bugzilla.mozilla.org/show_bug.cgi?id=401917
> Good list of what we need to make contributing not suck. The question
> now is how we want to prioritize this (before or after l10n). I have no
> direct answer, but both this and l10n are critical to the community
> acceptance of SUMO.
Right now, I'd like this stuff to go before l10n.
Jason Barnabe (np)
> Right now, approvers see two buttons: [edit] and [edit staging copy]. If
> all edits (by approver or not) have to be done to the staging copy
> first, I don't see the need for a edit button.
Yeah, if you have an approve button, you don't need it...
Chris Ilias
> On 11/6/07 4:42 PM, _David Tenser_ spoke thusly:
>> Chris Ilias wrote:
>>
>>> * Once the edit is made, we need a simple approval/rejection
>>> mechanism, like buttons [Approve] [Reject].
>>
>> Bug for that?
>
> Not yet. I'll file it tonight.
David Tenser
> On 11/6/07 4:42 PM, _David Tenser_ spoke thusly:
>> contributor as one single edit? That would solve Jason's use case (a
>> behavior I have as well, btw).
>
> Right now, I'm inclined to say yes that would solve Jason's problem,
> because I know there are times where I've made edits, then found a bunch
> of mistakes I've made.
We should have a bug for that too I think, but it's obviously low prio.
>
>>> * Clicking on edit staging copy will show a preview of the staging
>>> copy, in case it is different from the live version.
>>
>> Not sure if this is needed. It might be sufficient to just say "The
>> article you are editing differs from the live version bla bla." and
>> then the contributor can preview by clicking the button as normal.
>
> Nelson and I discussed this last week, and what I found was that the
> preview page (click on edit, then click preview) gives what we want,
> which is a preview of the article, and the editor underneath.
>
> The only problem was the message at the top, saying "Note: Remember that
> this is only a preview, and has not yet been saved!" would need to be
> different.
Yeah. The message would reflect the fact that the staging version is
different from the live version, and alert the editor of that.
>
>>> * Once an edit is made, we need a way of listing edits in need of
>>> review, for reviewers.
>>
>> Just a simple tag query that we add a link to on the contributor page
>> (or even in the contributor tools box).
>
> FWIW, I added it to the contributor box last night. :-)
Woohoo!
>> Good list of what we need to make contributing not suck. The question
>> now is how we want to prioritize this (before or after l10n). I have
>> no direct answer, but both this and l10n are critical to the community
>> acceptance of SUMO.
>
> Right now, I'd like this stuff to go before l10n.
It might make sense to get some of it done by .2 but we need to figure
out the most critical things. Otherwise we won't have time to even plan
.3 and .4 (which are stated as Q4 2007 goals).
Chris Ilias
> Chris Ilias wrote:
>> On 11/6/07 4:42 PM, _David Tenser_ spoke thusly:
>>> Might be possible to treat several consecutive edits from the same
>>> contributor as one single edit? That would solve Jason's use case (a
>>> behavior I have as well, btw).
>>
>> Right now, I'm inclined to say yes that would solve Jason's problem,
>> because I know there are times where I've made edits, then found a
>> bunch of mistakes I've made.
>
> We should have a bug for that too I think, but it's obviously low prio.
That's actually included in bug 402884. File a separate bug for it?
David Tenser
I'm indifferent. Just leave it as it is is my recommendation. Saves time. :)