Comment #7 on issue 831 by chipx86: Can't leave comments before you publish  
your own newly created review request

When I said we shouldn't allow it, I meant we should disable commenting on  
diffs to satisfy the bug. Yes, I agree that it would be nice to be able to  
review a
draft diff, but there are problems with this:

1) A draft diff has no revision and no place in a review request's diff  

This means it works quite a bit differently from published diffs, and we'd  
need to
special-case more code and possibly add URL mappings in the diff viewer and  
just for this case, which clients (including the JavaScript code in the  
diff viewer)
would have to conditionally use. There may also be migration issues for the  
after publishing a review request.

2) We'd need to decide what publishing a review against an unpublished diff  

Do we publish a review automatically with a review request? No, as it may  
not be
finished yet. So instead we need to know that a review has been published  
but is not
meant to be shown.

This would require that our code be updated to allow for handling reviews  
of this
type. Reusing the "public" state for a review isn't good enough, because  
you don't
necessarily want publishing a review request to publish this type of review

So now we have to add this new state, and migrate over the review's type  
when the
review request is published, meaning the review request now needs to have  
control over reviews, complicating things quite a bit.

3) Showing reviews against unpublished diffs doesn't make sense.

Even with the above state tracking and such, it doesn't make any sense for  
user to see a review against an unpublished diff. They can't view the diff  
yet, so
all they could see is the context in the review. We also would need to now
special-case e-mail, the API results, etc.

Really, it's just too early. What if you begin a review on your own code,  
detailed explanations and then, as you're reviewing, realize you've screwed  
up on the
diff? You'd need to upload a new diff and redo the review. We can't just  
migrate your
existing comments over, because they may not make sense anymore in context.  
decided long ago not to even attempt going that route when reviewing  
another person's
diffs, and the reasons still apply for reviewing your own draft diffs.

4) You can already review your own diffs, as long as you do it after you  

Go over your diff if you want, but then when you're sure this is the diff  
you want
the world to see, publish it. Then go and review it and give notes on  
things you want
people to know about. The end goal is to give people a list of things you  
noticed in
your diff, and the best time to do that is when the diff is available for  
them to
see. It saves a lot of complexity in the product and in the interaction.

You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:

You received this message because you are subscribed to the Google Groups 
"reviewboard-issues" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to