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 cmar...@apple.com _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
