I tried to give guidelines for getting a patch reviewed at <a href="http://trac.webkit.org/wiki/CodeReview">http://trac.webkit.org/wiki/CodeReview</a>. Feel free to add to or modify that list. I&#39;ve included the contents of that page below:<div>

<span class="Apple-style-span" style="font-family: Verdana, Arial, &#39;Bitstream Vera Sans&#39;, Helvetica, sans-serif; font-size: 13px; "><p>Once you put a patch up for review (i.e. mark a patch r?), it goes into the <a class="ext-link" href="https://bugs.webkit.org/request.cgi?action=queue&amp;requester=&amp;product=&amp;type=review&amp;requestee=&amp;component=&amp;group=requestee" style="text-decoration: none; color: rgb(187, 0, 0); border-bottom-width: 1px; border-bottom-style: dotted; border-bottom-color: rgb(187, 187, 187); "><span class="icon" style="background-image: url(http://trac.webkit.org/chrome/common/extlink.gif); background-attachment: initial; background-origin: initial; background-clip: initial; background-color: initial; padding-left: 12px; background-position: 50% 50%; background-repeat: no-repeat no-repeat; "> </span>Review Queue</a>. That may not be enough to get it reviewed in a timely manner. WebKit reviewers are all overloaded. The responsibility is on the committer to make it as easy as possible to get the code reviewed. To that end, you should:</p>

<ul><li>Look at the people who most recently modified the code you&#39;re changing and explicitly CC them on the bug.</li><li>Add a layout test when you fix a bug/change a behavior or explain why that isn&#39;t possible and add a manual test to WebCore/manual-tests.</li>

<li>Make your patch as small as possible. <strong>Really, seriously, go out of your way to make sure you&#39;ve broken down your patch into the smallest self-contained chunks possible.</strong></li><li>Only do/fix one thing per patch. Don&#39;t change a behavior and then add a fix for an incidental thing that you noticed while doing the original change. It should be two patches.</li>

<li>Do style cleanup or other significant refactoring in a separate patch, preferably as a precursor to the patch you want to land. Especially end of line whitespace cleanup as this just adds a lot of visual noise to the review.</li>

<li>Add short per function comments in the change log (see any of Darin Adler&#39;s changes for a good example). These help reviewers quickly understand why you are doing a change in that function.</li><li>Fix errors from any bots that run after you upload your patch.</li>

</ul><p>If you&#39;ve done all the above, then you can also ping on #webkit to see if there are any reviewers who can review it for you. If it&#39;s a trivial change, than anyone can review it. If it&#39;s a complicated or gnarly part of the codebase, you&#39;ll likely need to of the approval of one of the people who recently modified the code.</p>

</span></div>