[webkit-dev] Review tool changes

[Chris Marrin]

On Sep 20, 2010, at 11:36 AM, Maciej Stachowiak wrote:

> 
> On Sep 20, 2010, at 11:32 AM, Darin Adler wrote:
> 
>> On Sep 20, 2010, at 10:22 AM, Darin Fisher wrote:
>> 
>>> How about this?
>>> 
>>> If any annotations were made to the patch, then "the button" gets named Preview.  Else, the button is named "Publish" and when clicked performs its work in one shot.
>>> 
>>> Was there a strong outcry for removing the preview step?  I only found it bothersome when I wanted to issue a quick r=me on a patch that didn't require any additional changes.
>> 
>> Good idea. Here’s another idea:
>> 
>> The button starts out named Preview and works with a preview.
>> 
>> If the review or commit-queue flag is altered then the button is changed to “Publish” and works without a preview.
>> 
>> Thus if I like the preview work flow, I don’t set those flags until I get to the preview page. If I like the faster work flow, I can set a flag and then push Publish.
>> 
>> One type of person who is not served by my proposal is someone who wants to add comments only and not set a flag but wants the faster work flow.
> 
> 
> Changing the button based on seemingly unrelated flag settings does not strike me as clear UI design.
> 
> If people really want to be able to review a patch without the extra preview step, then I think two buttons would be preferable to a solution where the button changes based on something you did while reviewing. But I also think the always-preview workflow is entirely reasonable.

Yeah, I much prefer previewing. It gives you a chance to check your work and to see what exactly will be posted. And it gives you a chance to add general comments to the review. I think it's a mistake to allow blind publishing of a review. It will cause lots of mistakes to get added to the bug traffic and increase the noise level.

-----
~Chris
cmarrin at apple.com