--- a/docs/mozreview/bugzilla.rst
+++ b/docs/mozreview/bugzilla.rst
@@ -7,18 +7,21 @@ Bugzilla Integration
 MozReview and the Review Board web interface are tighly integrated with
 Bugzilla.
 
 Shared User Database and Authentication
 =======================================
 
 Review Board shares its user database with Bugzilla.
 
-Your Review Board login credentials are your Bugzilla email address and
-password.
+Logging into Review Board is done through Bugzilla.  The *Log in* link
+in Review Board will redirect you to Bugzilla, where you should
+provide your usual Bugzilla credentials. Note that if you have an
+active Bugzilla session, you will automatically be redirected back to
+Review Board without having to provide your credentials again.
 
 Your Review Board username is derived from your name in Bugzilla. If you
 are using the ``Firsname Lastname [:ircnick]`` convention, your Review
 Board username will be your IRC nickname, ``ircnick`` in this example.
 
 Forms that accept users in Review Board all accept email addresses, IRC
 nicknames, full names, and Review Board usernames.
 
@@ -26,18 +29,27 @@ Review Flags
 ============
 
 Asking a user for review on Review Board will create an attachment on the
 associated Bugzilla bug and will set the ``review`` flag to ``?`` to
 request review from the specified user. Clicking on the attachment in
 the Bugzilla user interface or following the link to the review will
 redirect you to Review Board.
 
-If someone gives a *Ship It* on a review request, a ``review+`` will be
-set in Bugzilla.
+When someone leaves a review on a review request, the chosen flag
+value will be set in Bugzilla (or cleared if the empty value is
+chosen).
+
+If a new revision of a commit is pushed up to MozReview, a new
+attachment will not be created. Rather, any ``r-`` and cleared review
+flags on the original Bugzilla attachment will be reset to ``r?``.
+Any existing ``r+`` flags will be left as is, that is, the review is
+carried forward. This last part is under discussion and may change in
+the future. There is also work under way to allow explicitly
+re-requesting review even if a ``r+`` has previously been granted.
 
 Review Comments
 ===============
 
 Review comments will be turned into Bugzilla comments when reviews are
 published. The full content of the review comment will be reflected in
 Bugzilla.
 

--- a/docs/mozreview/reviewboard.rst
+++ b/docs/mozreview/reviewboard.rst
@@ -193,38 +193,42 @@ Conversion to Bugzilla Comments
    When reviews are published, their content is converted to text and
    posted to Bugzilla as a comment.
 
    (There is talk of changing this behavior because capturing the rich
    review interface in Bugzilla comments can be challenging and appears
    to offer little value over just going to Review Board and looking at
    the original comments there.)
 
-Granting Review via Ship It
-   There is a **Ship It** checkbox in the reviewer interface of each
-   commit review request. This is Review Board's way of granting
-   review (``r+`` in Bugzilla terminology). Since each commit has an
-   associated attachment with review flags in Bugzilla, they need to
-   be reviewed separately.
+Granting, Denying, and Clearing Reviews
+   There is a dropdown containing standard Bugzilla review flags
+   (``r?``, ``r+``, and ``r-``) in the **Finish Review** dialog in
+   each commit review request. The selected value will be set on the
+   corresponding attachment in Bugzilla when the review is
+   published. There is also a blank value, which will clear the review
+   flag. Since each commit has an associated attachment with review
+   flags in Bugzilla, they need to be reviewed separately.
+
+   Note that, if a reviewer has previously left a ``r+`` or ``r-``
+   review, or has cleared the review, resetting it to ``r?`` will
+   cause the review flag in Bugzilla to be both set and directed to
+   the reviewer, since a user cannot set a review flag as someone
+   else. If the original ``r?`` has never been changed, then it will
+   be left as is, i.e., set by the commit author.
 
    While the parent review request (available from the **Review
    Summary** link on any commit review request) provides a collapsed
    view of all commits and can be useful to get a global view of the
    whole commit series, reviewers should generally not leave reviews
-   on it.
+   on it. Correspondingly, the review-flag dropdown is disabled on
+   parent review requests.
 
    There is currently no equivalent to ``feedback+``. This workflow is
    still being discussed.
 
-Cancelling Reviews
-   If a reviewer leaves a review without a **Ship It**, an existing
-   ``r?`` or ``r+`` flag on the commit attachment will be cleared. The
-   flag will still be cleared even if the review does not open any
-   issues.
-
 Working With "Patches"
 ----------------------
 
    The review description field contains an url to pull down the commits
    under review. If you want to view the patch as plain text, import it
    into a mercurial queue, push it to another tree, etc. this is the way
    to go.