@Gene -<br><br>As to how far back in previous tickets you should read before doing or during a review, I would refer to replies in this thread and using the new(?) report go back *at least* to the last approved ticket that was resolved based on a full review.<br>
<br>The diff reviewed tickets will generally cover the changes but if something has changed with the guidelines since the last "full" review they may not have been addressed in the diff reviews and require more than a quick perusal of prior tickets.<br>
<br><br>Cais.<br><br><div class="gmail_quote">On Thu, Oct 14, 2010 at 10:49 AM, Gene Robinson <span dir="ltr"><<a href="mailto:emhr@submersible.me">emhr@submersible.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div style="word-wrap: break-word;">I agree with Chip on this. For example look at the last two reviews of Thematic. <a href="http://themes.trac.wordpress.org/query?keywords=%7Etheme-thematic" target="_blank">http://themes.trac.wordpress.org/query?keywords=~theme-thematic</a> A ton of work went into preparing 0.9.7.6 ...believe me. That work was recognized and and the theme approved. Yea!! Chip noted some minor issues. They were discussed and addressed in the next release. <div>
<div><br></div><div>While I see the value in a black and white required or recommended approach to the guidelines. I think that there is cooperative value and respect in a more flexible dealings with theme developers who are obviously putting effort into their corrections for approval.</div>
<div><br></div><div>I think the new resolution could safeguard the process from small oversites in shared reviews. Currently, It seems like the prerequisite for any review atm is to go over the previous reviews before proceding woth the current one. It would be convenient to have a resolution that communicated whether that was necessary or not.</div>
<div><br></div><font color="#888888"><div>-Gene<br><div><br></div></div></font><div><div></div><div class="h5"><div><div>On Oct 14, 2010, at 10:41 AM, Chip Bennett wrote:</div><br><blockquote type="cite">Again, I disagree.<div>
<br></div><div>There are some things in the Requirements that are indeed *minor* (with respect to the end-user), but that are enforcing a higher quality standard, or are creating a standardization.</div>
<div><br></div><div>Some people put a license declaration statement in style.css. We ask them to format it in a standard way (using header tags). If this is the only issue, I'm not going to fail a review just because of it; I'll ask the developer to format the license statement in the standard manner in the next revision.</div>
<div><br></div><div>(I had just such a ticket recently.)</div><div><br></div><div>Your position would seem to advocate that my approach was wrong, and that one of two things should have happened:</div><div><br></div><div>
1) I fail the review merely for a non-standard license declaration</div><div>2) we no longer enforce standardization of license declaration<br><br></div><div>Seriously? Approving the ticket, with the caveat that the license declaration re-formatted to conform to the standard in the next revision isn't a viable alternative here?</div>
<div><br></div><div>And what of other "minor" issues? I also passed one that had one, single, very minor CSS validation error. What should I have done? In that circumstance, I see three alternatives to the approving with the caveat to fix in the next revision:</div>
<div><br></div><div>1) Fail the review for the minor error</div><div>2) Maintain a list of acceptable versus unacceptable errors, and pass/fail Themes accordingly</div><div>3) No longer enforce CSS validation</div><div><br>
</div><div>Which of those alternatives is preferable to approving the Theme asking the developer merely to fix the CSS validation error in the next Theme revision?</div><div><br></div><div>Chip</div><div><br></div><div><div class="gmail_quote">
On Thu, Oct 14, 2010 at 9:33 AM, Edward Caissie <span dir="ltr"><<a href="mailto:edward.caissie@gmail.com" target="_blank">edward.caissie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
2b) Is probably the most important point here ... if these are *minor* issues then perhaps they should *not be required*.<br><br>If there are many different "minor" issues that are being allowed then perhaps all of those should be reviewed to actually see if they need to be required.<br>
<br>The whole point is a minor issue is *not* a requirement ... as to the resolutions, we can fill pages with them but to add more based on this current thread at this point does not make any sense as what I see coming forward from this discussion is once again some of the Theme Review guidelines and expectations may need to be re-addressed.<br>
<br>As I see it, we are starting to diverge on this topic. We are speaking both of "minor" issues; and, resolving tickets as "approved' knowing there are issues of apparent significance that must be addressed. Perhaps similar, but for all intent and purpose different.<br>
<br><br>Cais.<div><div></div><div><br><br><div class="gmail_quote">On Thu, Oct 14, 2010 at 10:18 AM, Chip Bennett <span dir="ltr"><<a href="mailto:chip@chipbennett.net" target="_blank">chip@chipbennett.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Again, I disagree.<div><br></div><div>If we take your approach, one of two things will happen:</div><div><br></div><div>1) We will not approve Themes that have only one or two minor issues that violate the Theme Review Guidelines, thus needlessly frustrating/angering Theme Developers</div>
<div><br></div><div>2) We will approve Themes that have only one or two minor issues that violate the Theme Review Guidelines. We will continue to let those issues slide in subsequent revisions, which:</div><div><br></div>
<div>a) Will further frustrate/anger Theme Developers, who will accuse us of subjective enforcement of the Guidelines and of treating Theme Developers unfairly, due to different treatment, and</div><div><br></div><div>b) Will lead eventually to those criteria being de facto removed from the Guidelines, because we will never be enforcing them.</div>
<div><br></div><div>I don't like any of those options.</div><div><br></div><div>Thus, the "Required, But Can Be Fixed in Next Revision" comments.</div><div><br></div><div><font color="#888888">Chip</font><div>
<div></div><div><br><br><div class="gmail_quote">
On Thu, Oct 14, 2010 at 9:10 AM, Edward Caissie <span dir="ltr"><<a href="mailto:edward.caissie@gmail.com" target="_blank">edward.caissie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
My point is the issues are either minor or they are not ... obviously the flexibility to approve themes with "minor" issues should and is being used ... but, and I write again, if they are *required* to be fixed with the next revision then they should have been *required* to be fixed with the current version as they were IMO not "minor" to begin with if the reviewer is resolving as "not-approved" with the next revision.<br>
<br>If the same "minor" issue was later decided to be not a "minor" issue then that is a different matter.<br><br><br>Cais.<div><div></div><div><br><br><div class="gmail_quote">On Thu, Oct 14, 2010 at 10:03 AM, Chip Bennett <span dir="ltr"><<a href="mailto:chip@chipbennett.net" target="_blank">chip@chipbennett.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">I disagree. We need *some* flexibility to approve tickets that have only minor issues.<div>
<br>
</div><div>At the same time, if we approve a ticket with such minor issues, <i>with the expectation that those issues are addressed in the next revision</i>, then we should not let those minor issues pass in the review of the next revision.</div>
<div><br></div><div><font color="#888888">Chip</font><div><div></div><div><br><br><div class="gmail_quote">On Thu, Oct 14, 2010 at 8:42 AM, Edward Caissie <span dir="ltr"><<a href="mailto:edward.caissie@gmail.com" target="_blank">edward.caissie@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
If a ticket requires a special resolution as a pointer for "approved-with-next-revision-fixes" then perhaps the ticket should be immediately re-reviewed for those concerns.<br><br>IMO, if they are relevant enough to stop future versions of the theme from being approved if not addressed, they are relevant enough to stop the ticket at hand from being approved.<br>
<br><br>Cais.<br><br><div class="gmail_quote"><div><div></div><div>On Thu, Oct 14, 2010 at 8:45 AM, Chip Bennett <span dir="ltr"><<a href="mailto:chip@chipbennett.net" target="_blank">chip@chipbennett.net</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div></div><div>
As we approve more Themes - and especially, Themes that are approved, but that have comments indicating certain issues are "Required, but Can Be Fixed in Next Revision" - I'm thinking that we might want to consider another ticket resolution: "approved-with-comments" or "approved-with-next-revision-fixes" or something along those lines.<div>
<br></div><div>The reason? I'm seeing tickets for "next revisions" of such tickets, that seem to ignore completely the issues indicated as "Required, but Can Be Fixed in Next Revision". </div><div>
Of course, I'm resolving such tickets as "not-approved" - but the reason I bring it up is that we haven't really discussed how we handle such tickets. </div><div><br></div><div>My process for a Priority #1 Queue ticket is:</div>
<div><br></div><div>1) Check previous-tickets report, to ensure ticket is in correct queue (Pross: can we get the *resolution* column to display by default on this report?)</div><div>2) If correct queue, assign ticket to myself</div>
<div>3) Open previous ticket, to check for any issues indicated as "Can Be Fixed in Next Revision"</div><div>4) Diff-Review</div><div>5) Theme-Check</div><div>6) Summarize status of previous-ticket comments</div>
<div>7) (if necessary) Install/check activated Theme</div><div>8) Close/resolve ticket</div><div><br></div><div>The problem I'm foreseeing, of course, is that the previous-ticket comments can very easily fall through the cracks, unless the next-ticket reviewer makes a conscious effort to check the previous ticket. We could alleviate this concern by introducing an appropriate ticket resolution, that would alert the next-ticket reviewer to the presence of any such previous-ticket issues.</div>
<div><br></div><div>Thoughts?</div><div><br></div><font color="#888888"><div>Chip</div>
</font><br></div></div>_______________________________________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org" target="_blank">theme-reviewers@lists.wordpress.org</a><br>
<a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
<br></blockquote></div><br>
<br>_______________________________________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org" target="_blank">theme-reviewers@lists.wordpress.org</a><br>
<a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
<br></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org" target="_blank">theme-reviewers@lists.wordpress.org</a><br>
<a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
<br></blockquote></div><br>
</div></div><br>_______________________________________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org" target="_blank">theme-reviewers@lists.wordpress.org</a><br>
<a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
<br></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org" target="_blank">theme-reviewers@lists.wordpress.org</a><br>
<a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
<br></blockquote></div><br>
</div></div><br>_______________________________________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org" target="_blank">theme-reviewers@lists.wordpress.org</a><br>
<a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>theme-reviewers mailing list<br><a href="mailto:theme-reviewers@lists.wordpress.org" target="_blank">theme-reviewers@lists.wordpress.org</a><br><a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
</blockquote></div><br></div></div></div></div><br>_______________________________________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</a><br>
<a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
<br></blockquote></div><br>