SUMO community discussions

Updating our Article Review Guidelines

  1. Hey folks,

    If you are a Knowledge Base reviewer, please read this thread carefully.

    One of the goals this year for the content team is to take a holistic approach to information architecture to design and organize our content, empowering us to establish improved processes and tooling. As part of that goal, the content team is updating the Article Review Guidelines for the Knowledge Base reviewers.

    Here are some notable changes with this update:

    • Minor update on what’s considered a big change.
    • Update on the review guidelines for staff and contributors based on the type of product.
    • Added article review compliance.

    Please take your time to review the new Article Review Guidelines. We’ll be talking more about that in our upcoming community call on May 31, 2023. You will have a chance to ask questions or provide your feedback about this update directly with the content team during the call. However, you can always reply to this thread with questions.

    On behalf of the Customer Experience team, Kiki

    Hey folks, If you are a Knowledge Base reviewer, please read this thread carefully. One of the goals this year for the content team is to take a holistic approach to information architecture to design and organize our content, empowering us to establish improved processes and tooling. As part of that goal, the content team is updating the [https://support.mozilla.org/kb/article-review-guidelines Article Review Guidelines] for the Knowledge Base reviewers. Here are some notable changes with this update: * Minor update on what’s considered a big change. * Update on the review guidelines for staff and contributors based on the type of product. * Added article review compliance. Please take your time to review the new Article Review Guidelines. We’ll be talking more about that in our upcoming community call on [https://wiki.mozilla.org/Support/Weekly_Meetings/Agenda_2023-05-31 May 31, 2023]. You will have a chance to ask questions or provide your feedback about this update directly with the content team during the call. However, you can always reply to this thread with questions. On behalf of the Customer Experience team, Kiki
  2. I have a revision pending, to rename the new "Article review guidelines" section to "Article review and approval guidelines", because 1) the entire article is titled Article Review Guidelines and having a section with that title is a bit confusing and 2) the new content covers rules for self-approval.

    I'm assuming KB reviewers can still defer revisions without a second-party review.

    P.S. What about reviewing pending revisions with minor errors such as typos and markup? My habit has been to approve them and then submit and self-approve a new revision to fix those minor errors. Should those revisions now be left pending and a second pending revision submitted to fix the errors, or should they be approved and a new revision submitted, which would then need a second party review?

    I have a revision pending, to rename the new "Article review guidelines" section to "Article review ''and approval'' guidelines", because 1) the entire article is titled Article Review Guidelines and having a section with that title is a bit confusing and 2) the new content covers rules for self-approval. I'm assuming KB reviewers can still defer revisions without a second-party review. P.S. What about reviewing pending revisions with minor errors such as typos and markup? My habit has been to approve them and then submit and self-approve a new revision to fix those minor errors. Should those revisions now be left pending and a second pending revision submitted to fix the errors, or should they be approved and a new revision submitted, which would then need a second party review?

    Modified by AliceWyman on

  3. Just to clarify, the guidelines state that "For updates to existing content — you can approve all revisions (including your own) that you think improve the article. ", but further down it is made very clear that self reviewing is not allowed - something I think is a good idea.

    Can the guidelines be clear that self reviewing is not allowed in all parts of document?

    Just to clarify, the guidelines state that ''"For updates to existing content — you can approve all revisions (including your own) that you think improve the article. "'', but further down it is made very clear that self reviewing is not allowed - something I think is a good idea. Can the guidelines be clear that self reviewing is not allowed in all parts of document?
  4. As Paul noticed (good catch) the old guidelines still have information that self-approval is allowed, which conflicts with the new content. See these sections:

    As Paul noticed (good catch) the old guidelines still have information that self-approval is allowed, which conflicts with the new content. See these sections: *https://support.mozilla.org/en-US/kb/article-review-guidelines#w_top-articles *https://support.mozilla.org/en-US/kb/article-review-guidelines#w_other-articles

    Modified by AliceWyman on

  5. The new guidelines at https://support.mozilla.org/en-US/kb/article-review-guidelines#w_content-contributor-review-guidelines say this:

    Content contributor review guidelines

    Free products

    Please do not self-approve your own revisions (EN-US only). Please ask other contributors or staff members to review them, instead.

    There may be exceptions where certain content requires staff review and approval. In these situations, the author will indicate in the revision notes that 'Staff review required.' If you happen to propose a revision to one of these articles, please be sure to flag it for a staff writer's attention (via SUMO direct message or Slack), so they can provide the necessary review and approval.


    I don't have access to Slack. Does "SUMO direct message" mean a Private Message? The Meet the Team article specifies staff contact via Matrix rather than PM.

    The new guidelines at https://support.mozilla.org/en-US/kb/article-review-guidelines#w_content-contributor-review-guidelines say this: ==Content contributor review guidelines== ===Free products=== Please do not self-approve your own revisions (EN-US only). Please ask other contributors or staff members to review them, instead. There may be exceptions where certain content requires staff review and approval. In these situations, the author will indicate in the revision notes that 'Staff review required.' If you happen to propose a revision to one of these articles, please be sure to flag it for a staff writer's attention (via SUMO direct message or Slack), so they can provide the necessary review and approval. ---- I don't have access to Slack. Does "SUMO direct message" mean a Private Message? The [[Meet the Team]] article specifies staff contact via Matrix rather than PM.
  6. I think that adding Matrix to the list of contact options is a good idea.

    I think that adding Matrix to the list of contact options is a good idea.
  7. Another option: Recent revisions for en-US should be reviewed daily by staff and reviewers alike. Pending revisions should be approved or deferred without needing to be contacted. If there isn't a critical reason for immediate approval, a reasonable amount of time (such as a week) should pass before an editor should contact staff or another reviewer, if staff approval is not needed.

    Staff should also periodically check the list of unreviewed edits on this list: https://support.mozilla.org/en-US/contributors/unreviewed

    Many revisions fall through the cracks. The unreviewed list can be sorted by "Most recent" to find the oldest revisions at the bottom. The KB Overview Status column doesn't include revision dates (a bug?)

    Another option: [https://support.mozilla.org/en-US/kb/revisions?locale=en-US&users=&start=&end= Recent revisions for en-US] should be reviewed daily by staff and reviewers alike. Pending revisions should be approved or deferred without needing to be contacted. If there isn't a critical reason for immediate approval, a reasonable amount of time (such as a week) should pass before an editor should contact staff or another reviewer, if staff approval is not needed. Staff should also periodically check the list of unreviewed edits on this list: https://support.mozilla.org/en-US/contributors/unreviewed Many revisions fall through the cracks. The unreviewed list can be sorted by "Most recent" to find the oldest revisions at the bottom. The [https://support.mozilla.org/en-US/contributors/kb-overview?product= KB Overview] Status column doesn't include revision dates (a bug?)
  8. Hi all! Thank you for your review and feedback of the new article guidelines. A few notes below:

    - I changed the article title to "Article review and approval guidelines" - great suggestion, Alice! - I removed the copy "For updates to existing content — you can approve all revisions (including your own) that you think improve the article." - good catch, Paul! I also updated the other sections indicated self-approval is permitted. - To clarify, all revisions require a second-party approval, even if it's just minor grammar or formatting changes. - I added Matrix as a contact option and clarified SUMO direct message/private message - Thanks for the additional content about the revision dashboards. I added this into the article (but changed daily to three times per week).

    Keep the questions and feedback coming! Let me know if anything else pops up!

    Thank you! Abby

    Hi all! Thank you for your review and feedback of the new article guidelines. A few notes below: - I changed the article title to "Article review and approval guidelines" - great suggestion, Alice! - I removed the copy "For updates to existing content — you can approve all revisions (including your own) that you think improve the article." - good catch, Paul! I also updated the other sections indicated self-approval is permitted. - To clarify, all revisions require a second-party approval, even if it's just minor grammar or formatting changes. - I added Matrix as a contact option and clarified SUMO direct message/private message - Thanks for the additional content about the revision dashboards. I added this into the article (but changed daily to three times per week). Keep the questions and feedback coming! Let me know if anything else pops up! Thank you! Abby
  9. AliceWyman said

    I have a revision pending, to rename the new "Article review guidelines" section to "Article review and approval guidelines", because 1) the entire article is titled Article Review Guidelines and having a section with that title is a bit confusing and 2) the new content covers rules for self-approval.

    Since Abby changed the title of the entire article to "Article review and approval guidelines" I have a revison pending to change the title of the new section to "Approval guidelines".

    ''AliceWyman [[#post-85466|said]]'' <blockquote> I have a revision pending, to rename the new "Article review guidelines" section to "Article review ''and approval'' guidelines", because 1) the entire article is titled Article Review Guidelines and having a section with that title is a bit confusing and 2) the new content covers rules for self-approval. </blockquote> Since Abby changed the title of the [[Article review and approval guidelines|entire article]] to "Article review and approval guidelines" I have a revison pending to change the title of the new section to "Approval guidelines".
  10. Thanks for all of your feedback, folks!

    @Alice I just deferred your latest revision since the current title sounds more aligned with the current article title and the sub-headings for that specific section.

    Thanks for all of your feedback, folks! @Alice I just deferred your latest revision since the current title sounds more aligned with the current article title and the sub-headings for that specific section.
  11. ''Abby [[#post-85487|said]]'' <blockquote> - To clarify, all revisions require a second-party approval, even if it's just minor grammar or formatting changes. </blockquote> Can you reconsider and/or add something to [[Article review and approval guidelines]], seeing how staff is self-approving their own edits? For example, see these staff self-approvals since Jun 1 2023 <sub>(some minor, some not)</sub> with no indication of second-party review (see the [https://support.mozilla.org/en-US/kb/article-review-guidelines#w_staff-review-guidelines staff review guidelines]): https://support.mozilla.org/en-US/kb/add-on-badges/revision/261749 https://support.mozilla.org/en-US/kb/how-do-i-cancel-my-subscription-mozilla-vpn/revision/261571 https://support.mozilla.org/en-US/kb/import-data-another-browser/revision/261517 https://support.mozilla.org/en-US/kb/import-data-another-browser/revision/261516 https://support.mozilla.org/en-US/kb/import-data-another-browser/revision/261515 https://support.mozilla.org/en-US/kb/switching-devices/revision/261487 https://support.mozilla.org/en-US/kb/switching-devices/revision/261486 https://support.mozilla.org/en-US/kb/quarantined-domains/revision/261512 https://support.mozilla.org/en-US/kb/what-do-after-you-have-subscribed-mozilla-vpn/revision/261505 ^ <sub> edited to add more examples.</sub>

    Modified by AliceWyman on

  12. For the record, here are the current staff review guidelines:

    Staff review guidelines

    All products

    All internal staff members are required to have their en-US content reviewed by at least one other party. Examples of content reviewers may include product support managers, product managers, legal, marketing, PR, or community contributors.

    Content reviews can take place within SUMO or within a Google Doc. If your content went through a review outside of SUMO, simply add a note in your SUMO revision, mentioning the team or individuals who gave it a thumbs up. See an example below.

    Article revision comment {note}Note: We understand there may be some situations that require staff to self-approve content. Please provide a rationale for skipping a content review in the SUMO revision note.{/note}

    For the record, here are the current [https://support.mozilla.org/en-US/kb/article-review-guidelines#w_staff-review-guidelines staff review guidelines]: ==Staff review guidelines== ===All products=== All internal staff members are required to have their en-US content reviewed by at least one other party. Examples of content reviewers may include product support managers, product managers, legal, marketing, PR, or community contributors. Content reviews can take place within SUMO or within a Google Doc. If your content went through a review outside of SUMO, simply add a note in your SUMO revision, mentioning the team or individuals who gave it a thumbs up. See an example below. [[Image:Article revision comment]] {note}'''Note: We understand there may be some situations that require staff to self-approve content. Please provide a rationale for skipping a content review in the SUMO revision note.'''{/note}
  13. AliceWyman said

    Can you reconsider and/or add something to Article review and approval guidelines, seeing how staff is self-approving their own edits?

    Hi Alice, let me help to address your question here. In the Staff review guidelines, it was mentioned that content reviews on the staff side can take place within SUMO or Google Doc. I believe those revisions have been approved internally, but the author may failed to mention in the revision note. I'll make sure to remind the content team to uphold the guidelines next time.

    For more context, there's also a transition process going on between the content team staff members currently that may have been contributed to the lack of resources internally. I'll share more about that in the next week or so. Please stay tuned!

    ''AliceWyman [[#post-85512|said]]'' <blockquote> Can you reconsider and/or add something to [[Article review and approval guidelines]], seeing how staff is self-approving their own edits? </blockquote> Hi Alice, let me help to address your question here. In the Staff review guidelines, it was mentioned that content reviews on the staff side can take place within SUMO or Google Doc. I believe those revisions have been approved internally, but the author may failed to mention in the revision note. I'll make sure to remind the content team to uphold the guidelines next time. For more context, there's also a transition process going on between the content team staff members currently that may have been contributed to the lack of resources internally. I'll share more about that in the next week or so. Please stay tuned!
  14. Kiki, what about minor edits by staff to fix things like typos, formatting, grammar, etc? Are those also approved internally, with a second-party review? I find that hard to believe.

    Speaking of staff, the Meet the team article doesn't mention Lucas Siebert as a staff member. Neither does his profile, https://support.mozilla.org/en-US/user/lsiebert/

    Something else that has been bothering me are the consequences for contributors who are not compliant with the rules. This is copied from the Article review and approval guidelines:


    Review guidelines compliance

    Creating content that is consistent, accurate, and relevant is important, but it's not the only step in the process. To make sure our content maintains its quality over time, we need everyone involved to understand and follow the review and approval processes. Our staff will be keeping an eye on how well we're following the new guidelines to make sure everything stays on track.

    To retain your Knowledge Base Reviewer permission as a contributor:

    • Adhere to the above review guidelines.
    • Adhere to the CPG.

    We also strongly encourage all Knowledge Base Reviewers to review at least three (3) article revisions per month.

    Your Knowledge Base Reviewer permission as a reviewer may be revoked if you self-approve en-US content. Please see guidelines below:

    • 1st violation: A private, written warning from SUMO staff, with clarity of violation and consequences of continued behavior.
    • 2nd violation: A second private, written warning from SUMO staff, with clarity of violation and consequences of continued behavior.
    • 3rd violation: A private, written message and your permission as a reviewer will be revoked. If you wish to regain the permission, you are required to wait at least six (6) months before requesting.

    By embracing this approach, we encourage teamwork, ensure the best possible content, and create an environment where everyone's expertise contributes to our success.


    The section is aimed at contributors. Shouldn't there be similar "consequences" that apply to staff for repeated violations, including losing approval permission? If not, what are the consequences for staff non-compliance? In any case, that section of the rules sounds threatening and somewhat insulting to long-time contributors. Mozilla Support depends on volunteers for many of the updates to existing content and some new content.

    Kiki, what about minor edits by staff to fix things like typos, formatting, grammar, etc? Are those also approved internally, with a second-party review? I find that hard to believe. Speaking of staff, the [[Meet the team]] article doesn't mention Lucas Siebert as a staff member. Neither does his profile, https://support.mozilla.org/en-US/user/lsiebert/ Something else that has been bothering me are the consequences for contributors who are not compliant with the rules. This is copied from the [[Article review and approval guidelines]]: ---- ==Review guidelines compliance== Creating content that is consistent, accurate, and relevant is important, but it's not the only step in the process. To make sure our content maintains its quality over time, we need everyone involved to understand and follow the review and approval processes. Our staff will be keeping an eye on how well we're following the new guidelines to make sure everything stays on track. To retain your Knowledge Base Reviewer permission as a contributor: *Adhere to the above review guidelines. *Adhere to the CPG. We also strongly encourage all Knowledge Base Reviewers to review at least three (3) article revisions per month. Your Knowledge Base Reviewer permission as a reviewer may be revoked if you self-approve en-US content. Please see guidelines below: *'''1st violation''': A private, written warning from SUMO staff, with clarity of violation and consequences of continued behavior. *'''2nd violation''': A second private, written warning from SUMO staff, with clarity of violation and consequences of continued behavior. *'''3rd violation''': A private, written message and your permission as a reviewer will be revoked. If you wish to regain the permission, you are required to wait at least six (6) months before requesting. By embracing this approach, we encourage teamwork, ensure the best possible content, and create an environment where everyone's expertise contributes to our success. ----- The section is aimed at contributors. Shouldn't there be similar "consequences" that apply to staff for repeated violations, including losing approval permission? If not, what are the consequences for staff non-compliance? In any case, that section of the rules sounds threatening and somewhat insulting to long-time contributors. Mozilla Support depends on volunteers for many of the updates to existing content and some new content.
  15. AliceWyman said

    Kiki, what about minor edits by staff to fix things like typos, formatting, grammar, etc? Are those also approved internally, with a second-party review? I find that hard to believe.

    Hi Alice, if you check the staff approval section, we mentioned in the 'note' section that there might be some situations that require staff to self-approve a revision. There might also be other nuance within the internal content team (imposed deadline from the product team, total of stand by staff members, etc) that may affect the approval process internally.

    Speaking of staff, the Meet the team article doesn't mention Lucas Siebert as a staff member. Neither does his profile, https://support.mozilla.org/en-US/user/lsiebert/

    I've published a blog post to introduce Lucas and he also came to our community meeting multiple times by now. We missed adding him to the Meet the team article, but it's not a reason to doubt Lucas' staff credential. That being said, I'll take the action item to update the article to include Lucas.

    The section is aimed at contributors. Shouldn't there be similar "consequences" that apply to staff for repeated violations, including losing approval permission? If not, what are the consequences for staff non-compliance? In any case, that section of the rules sounds threatening and somewhat insulting to long-time contributors. Mozilla Support depends on volunteers for many of the updates to existing content and some new content.

    We'll handle things internally when it comes to any actions that need to be taken with a staff member as it relates to compliance to the article review guideline. We only get positive feedback so far from the other contributors about this update. We also have tried our best to review contributor revisions in a timely manner.

    In this case, I need you to lead with good intentions. We still strongly believe that contributors are key-part of Mozilla Support, and we only update the guidelines to make sure that we can maintain high quality articles within our platform.

    ''AliceWyman [[#post-85524|said]]'' <blockquote> Kiki, what about minor edits by staff to fix things like typos, formatting, grammar, etc? Are those also approved internally, with a second-party review? I find that hard to believe. </blockquote> Hi Alice, if you check the staff approval section, we mentioned in the 'note' section that there might be some situations that require staff to self-approve a revision. There might also be other nuance within the internal content team (imposed deadline from the product team, total of stand by staff members, etc) that may affect the approval process internally. <blockquote> Speaking of staff, the [[Meet the team]] article doesn't mention Lucas Siebert as a staff member. Neither does his profile, https://support.mozilla.org/en-US/user/lsiebert/ </blockquote> I've published [https://blog.mozilla.org/sumo/2022/10/31/introducing-lucas-siebert/ a blog post] to introduce Lucas and he also came to our community meeting multiple times by now. We missed adding him to the [[Meet the team]] article, but it's not a reason to doubt Lucas' staff credential. That being said, I'll take the action item to update the article to include Lucas. <blockquote> The section is aimed at contributors. Shouldn't there be similar "consequences" that apply to staff for repeated violations, including losing approval permission? If not, what are the consequences for staff non-compliance? In any case, that section of the rules sounds threatening and somewhat insulting to long-time contributors. Mozilla Support depends on volunteers for many of the updates to existing content and some new content. </blockquote> We'll handle things internally when it comes to any actions that need to be taken with a staff member as it relates to compliance to the article review guideline. We only get positive feedback so far from the other contributors about this update. We also have tried our best to review contributor revisions in a timely manner. In this case, I need you to lead with good intentions. We still strongly believe that contributors are key-part of Mozilla Support, and we only update the guidelines to make sure that we can maintain high quality articles within our platform.
  16. Kiki said

    Hi Alice, if you check the staff approval section, we mentioned in the 'note' section that there might be some situations that require staff to self-approve a revision. There might also be other nuance within the internal content team (imposed deadline from the product team, total of stand by staff members, etc) that may affect the approval process internally. <snip>

    "Some" situations? Self-approval by staff is taking place in every situation. I have yet to see an example where a recent staff revision (since the new guidelines) is left pending for second-party review. Can you point to a recent example in case I missed it? <- I found this May 30, 2023 revision that Fabi left pending but that was because she asked me by PM for help with the {for} markup.

    We only get positive feedback so far from the other contributors about this update.

    I've been getting negative feedback myself, by private message. I've added some of that negative feedback to this thread in my last post (consequences for contributors who are not compliant with the rules), since I share that opinion. I asked one person to voice their concerns, if not publicly then by PM to staff. I can understand why contributors might hesitate to voice negative feedback, since they don't want to offend. As for Lucas, I saw the blog post and never doubted he was staff. I just mentioned it as a nudge to update the Meet the team article.

    In this case, I need you to lead with good intentions. We still strongly believe that contributors are key-part of Mozilla Support, and we only update the guidelines to make sure that we can maintain high quality articles within our platform.

    I do have good intentions. I've been reviewing the Unreviewed Changes and I've been approving or deferring many of the older pending revisions, including some of yours. I might just stop making edits to KB articles altogether and just stick to approvals, "Need change" entries and things like article name changes and article archiving, which don't have a second-party approval process or guidelines so far and can be done by reviewers unilaterally (and without any documentation, although I do document such changes by posting a KB discussion thread). See Bug 732668 Article history should document changes of every kind marked "wontfix" by Seburo (part of a project as I remember, to clear out old bugs).

    By the way, is there a metric for approvals and deferrals by individual KB reviewers? there should be, so you know which reviewers are active and which aren't.

    ''Kiki [[#post-85532|said]]'' <blockquote> Hi Alice, if you check the staff approval section, we mentioned in the 'note' section that there might be some situations that require staff to self-approve a revision. There might also be other nuance within the internal content team (imposed deadline from the product team, total of stand by staff members, etc) that may affect the approval process internally. <snip> </blockquote> "Some" situations? Self-approval by staff is taking place in every situation. I have yet to see an example where a ''recent'' staff revision (since the new guidelines) is left pending for second-party review. Can you point to a recent example in case I missed it? <- <sub>I found [https://support.mozilla.org/en-US/kb/import-bookmarks-google-chrome/revision/261369 this May 30, 2023 revision that Fabi left pending] but that was because she asked me by PM for help with the {for} markup.</sub> <blockquote> We only get positive feedback so far from the other contributors about this update. </blockquote> I've been getting negative feedback myself, by private message. I've added some of that negative feedback to this thread in my last post (consequences for contributors who are not compliant with the rules), since I share that opinion. I asked one person to voice their concerns, if not publicly then by PM to staff. I can understand why contributors might hesitate to voice negative feedback, since they don't want to offend. As for Lucas, I saw the blog post and never doubted he was staff. I just mentioned it as a nudge to update the [[Meet the team]] article. <blockquote> In this case, I need you to lead with good intentions. We still strongly believe that contributors are key-part of Mozilla Support, and we only update the guidelines to make sure that we can maintain high quality articles within our platform. </blockquote> I do have good intentions. I've been reviewing the [https://support.mozilla.org/en-US/contributors/unreviewed Unreviewed Changes] and I've been approving or deferring many of the older pending revisions, including some of yours. I might just stop making edits to KB articles altogether and just stick to approvals, "Need change" entries and things like article name changes and article archiving, which don't have a second-party approval process or guidelines so far and can be done by reviewers unilaterally (and without any documentation, although I do document such changes by posting a KB discussion thread). See ''[https://bugzilla.mozilla.org/show_bug.cgi?id=732668 Bug 732668] Article history should document changes of every kind'' marked "wontfix" by Seburo (part of a project as I remember, to clear out old bugs). By the way, is there a metric for approvals and deferrals by individual KB reviewers? there should be, so you know which reviewers are active and which aren't.

    Modified by AliceWyman on

  17. I have a revision pending review since June 8 to the Article review and approval guidelines. My proposed revision is to add Templates under the Special articles section (above Canned responses):

    • Templates include content used in multiple articles and should be considered as top articles. All templates, including those that need review, are listed on this page. See Using Templates for additional guidelines.

    Templates, like most canned responses can apply to different Mozilla products and the number of article visits also doesn't apply. I think that this change should require staff approval since it adds a "policy" about how templates are considered.

    I was also thinking about "How to contribute" articles, which don't fall under either Free products or Subscription/Premium products. I think the Article review and approval guidelines should include something about "How to contribute" articles,which are under the Contributor product. Since these articles are aimed at contributors, not Mozilla product end users, I think that special rules should apply; for example

    • Revisions that include a new or change in policy require staff approval
    • Other revisions can be approved by any reviewer or can be self-approved
    I have a [https://support.mozilla.org/en-US/kb/article-review-guidelines/revision/261929 revision] pending review since June 8 to the [[Article review and approval guidelines]]. My proposed revision is to add '''Templates''' under the [https://support.mozilla.org/en-US/kb/article-review-guidelines#w_special-articles Special articles section] (above '''Canned responses'''): *'''Templates''' include content used in multiple articles and should be considered as top articles. All templates, including those that need review, are listed on [/contributors/kb-overview?category=60 this page]. See [[Using Templates]] for additional guidelines. Templates, like most [[common forum responses|canned responses]] can apply to different Mozilla products and the number of article visits also doesn't apply. I think that this change should require staff approval since it adds a "policy" about how templates are considered. I was also thinking about "How to contribute" articles, which don't fall under either Free products or Subscription/Premium products. I think the [[Article review and approval guidelines]] should include something about "How to contribute" articles,which are under the [https://support.mozilla.org/en-US/products/contributor Contributor] product. Since these articles are aimed at contributors, not Mozilla product end users, I think that special rules should apply; for example *Revisions that include a new or change in policy require staff approval *Other revisions can be approved by any reviewer or can be self-approved

    Modified by AliceWyman on

  18. AliceWyman said

    I have a revision pending review since June 8 to the Article review and approval guidelines. My proposed revision is to add Templates under the Special articles section (above Canned responses): <snip>

    My revision was never reviewed. If admin disapproves of my revision can it at least be deferred so I know that it was considered but turned down?

    On self-approvals, <snip> It might help if the warning message a reviewer gets when self-approving can be made stronger and maybe link to Article review and approval guidelines? Self-approvalWarning Self-approvalWarning

    ''AliceWyman [[#post-85554|said]]'' <blockquote> I have a [https://support.mozilla.org/en-US/kb/article-review-guidelines/revision/261929 revision] pending review since June 8 to the [[Article review and approval guidelines]]. My proposed revision is to add '''Templates''' under the [https://support.mozilla.org/en-US/kb/article-review-guidelines#w_special-articles Special articles section] (above '''Canned responses'''): <snip> </blockquote> My revision was never reviewed. If admin disapproves of my revision can it at least be deferred so I know that it was considered but turned down? On self-approvals, <sub><snip></sub> It might help if the warning message a reviewer gets when self-approving can be made stronger and maybe link to [[Article review and approval guidelines]]? Self-approvalWarning [[Image:Self-approvalWarning]]

    Modified by AliceWyman on

  19. AliceWyman said

    By the way, is there a metric for approvals and deferrals by individual KB reviewers? there should be, so you know which reviewers are active and which aren't.

    Never answered, I guess there isn't?

    ''AliceWyman [[#post-85534|said]]'' <blockquote> By the way, is there a metric for approvals and deferrals by individual KB reviewers? there should be, so you know which reviewers are active and which aren't. </blockquote> Never answered, I guess there isn't?
  20. Pocket is now a Mozilla Support product: https://support.mozilla.org/en-US/products/pocket We should add it to Article review and approval guidelines. If Pocket is going to be considered a Subscription/Premium product (it has a Premium option) then I'll stop approving pending Pocket revisions.

    The Content contributor review guidelines https://support.mozilla.org/en-US/kb/article-review-guidelines#w_content-contributor-review-guidelines section currently has the following:


    Free products

    Please do not self-approve your own revisions (en-US only). Please ask other contributors or staff members to review them, instead. <snip> Review requirements matrix

    Content review matrix

    * Unless indicated by the author as “Staff approval required” in revision notes.

    Subscription/Premium products

    Please don’t self-approve your revisions or approve revisions from other contributors (en-US only). This includes Canned Responses and Templates for subscription/premium products. If you propose a revision, please flag it to a staff writer for approval (via SUMO direct message/private message, Matrix or Slack). <snip>

    Review requirements matrix

    Content review matrix paid

    Pocket is now a Mozilla Support product: https://support.mozilla.org/en-US/products/pocket We should add it to [[Article review and approval guidelines]]. If Pocket is going to be considered a Subscription/Premium product (it has a Premium option) then I'll stop approving pending Pocket revisions. The '''Content contributor review guidelines''' https://support.mozilla.org/en-US/kb/article-review-guidelines#w_content-contributor-review-guidelines section currently has the following: ---- ===Free products=== Please do not self-approve your own revisions (en-US only). Please ask other contributors or staff members to review them, instead. <snip> '''Review requirements matrix''' [[Image:Content review matrix]] <nowiki>*</nowiki> Unless indicated by the author as “Staff approval required” in revision notes. ===Subscription/Premium products=== Please don’t self-approve your revisions or approve revisions from other contributors (en-US only). This includes Canned Responses and Templates for subscription/premium products. If you propose a revision, please flag it to a staff writer for approval (via SUMO direct message/private message, Matrix or Slack). <snip> '''Review requirements matrix''' [[Image:Content review matrix paid]]
  1. 1
  2. 2