How to get approvers to review other people's edits
Chris Ilias
other people's edits. Right now, all approvers are only approving their
own edits. I need some help identifying what is preventing them from
reviewing other people's edits, and what we can do to remove those
barriers. Any ideas?
Majken Connor
> _______________________________________________
> support-planning mailing list
> support-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/support-planning
>
Is there any sort of notification system that approvers could see there are
edits pending when they log in? Isn't there something in the contributor's
sidebar? Maybe we can get RSS hooked up for this?
I think this might get easier if we move away from bugzilla for article
requests like we've been talking about for a while, as well. Right now the
process still isn't very streamlined.
Maybe we should have a weekly time period designated for approvals, where
people can go through the list together, also making sure they're not
reviewing the same articles.
Also I do think it'd be worth considering not allowing approvers to approve
their own edits. There's value in having the second set of eyes. This
might encourage people to "trade" approvals and maybe get people looking at
the queue. I know this is would be a step back in some people's eyes, but if
you've written something yourself it's a lot easier for you to skip over
your own mistakes.
Chris Ilias
> Is there any sort of notification system that approvers could see there are
> edits pending when they log in? Isn't there something in the contributor's
> sidebar? Maybe we can get RSS hooked up for this?
We have a link to the "Waiting for review" category in the sidebar,
which separates the articles by language. The old link was recently
fixed to only include articles in one locale.
<http://support.mozilla.com/tiki-browse_categories.php?parentId=11>,
which has a watch function. I'll test that out.
> I think this might get easier if we move away from bugzilla for article
> requests like we've been talking about for a while, as well. Right now the
> process still isn't very streamlined.
While I agree about moving off of bugzilla for article *requests*,
review of article *edits* does not go through bugzilla.
> Also I do think it'd be worth considering not allowing approvers to approve
> their own edits. There's value in having the second set of eyes. This
> might encourage people to "trade" approvals and maybe get people looking at
> the queue. I know this is would be a step back in some people's eyes, but if
> you've written something yourself it's a lot easier for you to skip over
> your own mistakes.
I think that would really deter people from contributing further. I
think encouraging others to review your edit is good, but preventing
self-approval is going too far.
David Tenser
> Also I do think it'd be worth considering not allowing approvers to approve
> their own edits. There's value in having the second set of eyes. This
> might encourage people to "trade" approvals and maybe get people looking at
> the queue. I know this is would be a step back in some people's eyes, but if
> you've written something yourself it's a lot easier for you to skip over
> your own mistakes.
This sounds like a step we could make once we've actually gotten people
to review other people's edits. It's worth considering when we're ready,
but enforcing it today would probably disrupt more than it would help.
David Tenser
I'm inclined to say that the main reason why people don't review other
people's edits is a lack of overview of articles waiting for review.
We need to create a truly useful and dynamic start page for contributors
and make sure it's shown when you log in. If I go to support.mozilla.com
today and log in, I'm taken back to the start page again (for users, not
for contributors), which is not helpful at all.
As a contributor, I want to be presented with a page providing an
overview of the status that is relevant to me, such as
- a list of articles waiting for review in my locale
- a list of top articles that are still untranslated
- a list of unanswered forum threads
- a clear pointer to where discussions are taking place (contributor
forum? btw, didn't see this discussion there)
- a way to find out more about how to get involved
We also need to make the website truly helpful even for contributors.
The documentation should be naturally integrated with the website, and
not just a list of articles in the sidebar. For example, rather than
just showing a number of checkboxes and radio buttons in the Category
section of the Edit Article screen, we should explain what they are
supposed to be used for. Few contributors know what e.g. the "Firefox 3"
checkbox is for.
We could also make the SUMO community itself more personal and friendly.
Who are the most active/recent KB authors in my locale? How can I get in
touch with them? Wouldn't it be cool if there was a way to contact other
community members, either through the contributor forum or some other
direct PM way?
Majken Connor
> Chris Ilias wrote:
> > One thing I would like to accomplish is to get more approvers to review
> > other people's edits. Right now, all approvers are only approving their
> > own edits. I need some help identifying what is preventing them from
> > reviewing other people's edits, and what we can do to remove those
> > barriers. Any ideas?
>
> I'm inclined to say that the main reason why people don't review other
> people's edits is a lack of overview of articles waiting for review.
>
> We need to create a truly useful and dynamic start page for contributors
> and make sure it's shown when you log in. If I go to support.mozilla.com
> today and log in, I'm taken back to the start page again (for users, not
> for contributors), which is not helpful at all.
https://bugzilla.mozilla.org/show_bug.cgi?id=433425 is already on file, but
not given a priority also it looks like the contributor home page needs some
love after the redesign. It looks like it's getting hit by the same or
similar overlapping bug the sidebars were having.
>
>
> As a contributor, I want to be presented with a page providing an
> overview of the status that is relevant to me, such as
>
> - a list of articles waiting for review in my locale
> - a list of top articles that are still untranslated
> - a list of unanswered forum threads
> - a clear pointer to where discussions are taking place (contributor
> forum? btw, didn't see this discussion there)
> - a way to find out more about how to get involved
We had a module that showed changes since a person's last visit but we had
to disable it because of perf. We might want to try optimizing it and
turning it back on.
>
>
> We also need to make the website truly helpful even for contributors.
> The documentation should be naturally integrated with the website, and
> not just a list of articles in the sidebar. For example, rather than
> just showing a number of checkboxes and radio buttons in the Category
> section of the Edit Article screen, we should explain what they are
> supposed to be used for. Few contributors know what e.g. the "Firefox 3"
> checkbox is for.
>
> We could also make the SUMO community itself more personal and friendly.
> Who are the most active/recent KB authors in my locale? How can I get in
> touch with them? Wouldn't it be cool if there was a way to contact other
> community members, either through the contributor forum or some other
> direct PM way?
> _______________________________________________
>
Tikiwiki supports PM, overall, not just through the forum.
Majken Connor
>
>
> On Mon, Sep 22, 2008 at 9:34 AM, David Tenser <djst.m...@gmail.com>wrote:
>
>> Chris Ilias wrote:
>> > One thing I would like to accomplish is to get more approvers to review
>> > other people's edits. Right now, all approvers are only approving their
>> > own edits. I need some help identifying what is preventing them from
>> > reviewing other people's edits, and what we can do to remove those
>> > barriers. Any ideas?
>>
>> I'm inclined to say that the main reason why people don't review other
>> people's edits is a lack of overview of articles waiting for review.
>>
>> We need to create a truly useful and dynamic start page for contributors
>> and make sure it's shown when you log in. If I go to support.mozilla.com
>> today and log in, I'm taken back to the start page again (for users, not
>> for contributors), which is not helpful at all.
>
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=433425 is already on file,
> but not given a priority also it looks like the contributor home page needs
> some love after the redesign. It looks like it's getting hit by the same or
> similar overlapping bug the sidebars were having.
>
>
>>
>>
>> As a contributor, I want to be presented with a page providing an
>> overview of the status that is relevant to me, such as
>>
>> - a list of articles waiting for review in my locale
>> - a list of top articles that are still untranslated
>> - a list of unanswered forum threads
>> - a clear pointer to where discussions are taking place (contributor
>> forum? btw, didn't see this discussion there)
>> - a way to find out more about how to get involved
>
>
> We had a module that showed changes since a person's last visit but we had
> to disable it because of perf. We might want to try optimizing it and
> turning it back on.
>
>>
>>
>> We also need to make the website truly helpful even for contributors.
>> The documentation should be naturally integrated with the website, and
>> not just a list of articles in the sidebar. For example, rather than
>> just showing a number of checkboxes and radio buttons in the Category
>> section of the Edit Article screen, we should explain what they are
>> supposed to be used for. Few contributors know what e.g. the "Firefox 3"
>> checkbox is for.
>>
>> We could also make the SUMO community itself more personal and friendly.
>> Who are the most active/recent KB authors in my locale? How can I get in
>> touch with them? Wouldn't it be cool if there was a way to contact other
>> community members, either through the contributor forum or some other
>> direct PM way?
>> _______________________________________________
>>
>
> Tikiwiki supports PM, overall, not just through the forum.
>
>
The contributor toolbar is quite cluttered. It might help to move all the
documentation to one link rather than many in the side bar as per the
meeting. Also it might help if we can show the number of articles that are
ready to be reivewed in a contributor's locale in the sidebar.
Chris Ilias
> <http://support.mozilla.com/tiki-browse_categories.php?parentId=11>,
> which has a watch function. I'll test that out.
Okay, I've spent the past week testing this out, and it sends our
notification whenever any item is added or removed from that category,
regardless of language.
Chris Ilias
> The contributor toolbar is quite cluttered. It might help to move all the
> documentation to one link rather than many in the side bar as per the
> meeting. Also it might help if we can show the number of articles that are
> ready to be reivewed in a contributor's locale in the sidebar.
I agree. I've just trimmed it. I'm not sure about "My Personal
Dashboard" and "Articles I Monitor for Changes". Do we need those?
Do we need a link to "Advanced forum search"?
Majken Connor
> _______________________________________________
> support-planning mailing list
> support-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/support-planning
>
The Dashboard lets you see a list of your watches, forum and kb, and it
looks like "Articles I monitor for changes" just links to this same list, so
we should drop it and just go through the dashboard (leave it there). We
should clean up the display of the list though.
We'd need to ask if the advanced forum search is useful for forum
contributors, but it doesn't look like it would be, to me, in its current
state. I'd want to see a forum search geared towards contributors that
gives you options to search only solved or unsolved, and unanswered etc.
David Tenser
Which is principally what bug
https://bugzilla.mozilla.org/show_bug.cgi?id=444331 is about.
Chris Ilias
After emailing approvers and locale leaders, here is some of the reasons
for not reviewing other's edits:
* Waiting for notification (x4)
"because I don't know about any! I'm still waiting for a locale feed so
I'll be able to know if we have some review/approve tasks in our queue."
"But I don't know how to receive a notification each time an article is
modified and ready for revision."
"I'm never notified of edits. I don't know much about the ways of being
notified."
* because I don't have any edits within "my" files (at least, I think so)."
* Lack of time (x3)
"Mainly lack of time."
"I now have a full time job, and unfortunately, much less time for SUMO."
"I don't have much time."
* Not confident (x2)
"don't feel confident enough to review other peoples' edits." [wrt Mac
and linux data]
"I don't feel comfortable with approving, disapproving, or modifying
other people's pending edits."
* Web site performance (x1)
"the last few times I've tried to use the site, I've run into
performance problems with the site - too slow, database error, or whatever."
Here's an interesting one, which I think deserves some discussion:
"If volunteers like me are reviwing the pending edits then how can the
Mozilla support team know which editors should be given the authority to
approve their own edits?"
That's a good point.
Chris Ilias
No suggested solutions? Okay, here are some from me:
- Create email notification for edits waiting for review in each
language, and autosubscribe approvers to it, with the option of
unsubscribing
- From discussion during Monday meeting, proposals for new approvers can
be done via nomination (even self-nomination), and we can use the
Tikiwiki action log to review.
David Tenser
> On 10/15/08 4:08 PM, _Chris Ilias_ spoke thusly:
>> "If volunteers like me are reviwing the pending edits then how can the
>> Mozilla support team know which editors should be given the authority
>> to approve their own edits?"
>>
>> That's a good point.
>
> No suggested solutions? Okay, here are some from me:
> - Create email notification for edits waiting for review in each
> language, and autosubscribe approvers to it, with the option of
> unsubscribing
>
> - From discussion during Monday meeting, proposals for new approvers can
> be done via nomination (even self-nomination), and we can use the
> Tikiwiki action log to review.
As we discussed during the meeting, volunteers that review other
people's edits could certainly nominate/suggest new reviewers based on
the quality of their edits, but ultimately a potential review should
want to become one him/herself (so actually asking to become one should
be the first step, normally).
Once we have a nomination or a request to become a reviewer, we can take
a look at that person's past edits and also ensure that the person
understands the responsibilities of becoming a reviewer (it's not to
skip the process of having people review your edits (other than minor
typo fixes), it's about helping us reviewing other people's edits).
Majken Connor
> _______________________________________________
> support-planning mailing list
> support-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/support-planning
>
Another part of being a reviewer is being able to catch people's problems.
Someone might be a great reviewer but might not have time or enjoy writing
the content new. New articles have bugs, and when there's an edit waiting
for review it can be seen on the staging server. People who want to become
reviewers should maybe actually review a few edits, and then one of the
admins checks over their review.