Comment #7 on issue 831 by chipx86: Can't leave comments before you publish your own newly created review request http://code.google.com/p/reviewboard/issues/detail?id=831
When I said we shouldn't allow it, I meant we should disable commenting on draft 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 history. 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 webapi 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 review after publishing a review request. 2) We'd need to decide what publishing a review against an unpublished diff means. 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 automatically. 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 more 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 another 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, writing 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. We 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 publish! 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: http://code.google.com/hosting/settings --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "reviewboard-issues" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/reviewboard-issues?hl=en -~----------~----~----~----~------~----~------~--~---
