SUMO community discussions

Revision approbation and rejection process

  1. To write a new article revision, it may need iterations from several users, each new revision being based on the previous one.

    For that case, I think it is better to approve the final revision and let the previous ones unreviewed and not rejected, in order to keep traceability of all changes through their description.

    If a revision is a dead branch, i.e. the next revision is not based on it, you can reject it

    To write a new article revision, it may need iterations from several users, each new revision being based on the previous one. For that case, I think it is better to approve the final revision and let the previous ones unreviewed and not rejected, in order to keep traceability of all changes through their description. If a revision is a dead branch, i.e. the next revision is not based on it, you can reject it
  2. Do all names get added to the credits at the bottom of the article?

    Do all names get added to the credits at the bottom of the article?
  3. Do all names get added to the credits at the bottom of the article?

    No, it does not change anything. I participated in the latest revision updating of:

    ''Do all names get added to the credits at the bottom of the article?'' No, it does not change anything. I participated in the latest revision updating of: * [[Using the QuickTime plugin with Firefox]] and I am not marked as a contributor because my revision has been rejected. * [[Firefox takes a long time to start up]] and I am not marked as a contributor because my revision has been unreviewed.
  4. Apparently, it doesn't matter whether your revision is rejected or not before a subsequent edit based on your revision is approved. It looks like only the person who submitted the approved revision gets credit, even if he just fixed a typo.

    Speaking of credit, I wrote the Fix common audio and video issues article for SUMO (back in the Alpha stage of SUMO) which scoobidiver is also working on. My name was stripped from the credit when the article was migrated from the old KB (not that I really care, since the article originally came from MozillaZine but I did put work into improving it). The same thing has happened with other articles I've worked on. Apparently the only credit given for a migrated article is the last person who revised the article before it was migrated, since the rest of the history is gone.

    Apparently, it doesn't matter whether your revision is rejected or not before a subsequent edit based on your revision is approved. It looks like only the person who submitted the approved revision gets credit, even if he just fixed a typo. Speaking of credit, I wrote the [[Video or audio does not play]] article for SUMO (back in the [https://wiki.mozilla.org/Support:Alpha_Article_Tracking Alpha stage of SUMO]) which scoobidiver is also working on. My name was stripped from the credit when the article was migrated from the old KB (not that I really care, since the article originally came from MozillaZine but I did put work into improving it). The same thing has happened with other articles I've worked on. Apparently the only credit given for a migrated article is the last person who revised the article before it was migrated, since the rest of the history is gone.

    Modified by AliceWyman on

  5. My primary intention is not about credit, it is about the change track because you don't look at change description of rejected revisions in an article history, even if they contributed to the article.

    For the credit part, may be a bug is necessary in order to add credit to people who wrote unreviewed revisions, assuming that if these are not rejected, they were useful for an approved revision.

    My primary intention is not about credit, it is about the change track because you don't look at change description of rejected revisions in an article history, even if they contributed to the article. For the credit part, may be a bug is necessary in order to add credit to people who wrote unreviewed revisions, assuming that if these are not rejected, they were useful for an approved revision.
  6. For that case, I think it is better to approve the final revision and let the previous ones unreviewed and not rejected, in order to keep traceability of all changes through their description.
    Yes, I'd also say that's the best way to go.

    About the credit: Actually, there is a bug about this already: https://bugzilla.mozilla.org/show_bug.cgi?id=628634

    <blockquote>For that case, I think it is better to approve the final revision and let the previous ones unreviewed and not rejected, in order to keep traceability of all changes through their description. </blockquote> Yes, I'd also say that's the best way to go. About the credit: Actually, there is a bug about this already: https://bugzilla.mozilla.org/show_bug.cgi?id=628634