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
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
special-case more code and possibly add URL mappings in the diff viewer and
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
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
type. Reusing the "public" state for a review isn't good enough, because
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
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
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
existing comments over, because they may not make sense anymore in context.
decided long ago not to even attempt going that route when reviewing
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
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
your diff, and the best time to do that is when the diff is available for
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
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to
For more options, visit this group at