The general concepts and ideas being put forward with the last several replies to this thread have gone around many times before and yet here we do it again.<br><br>How many times does the Theme Review team need to ask, and in how many ways does it have to be worded: input from Automattic/WPORG is required.<br>
<br>It is required for the reason: the Theme Reviewers make an interpretation of what is required, recommended, or optional only to be chastised most every time for their interpretation and subsequent actions. How is the core team putting forward their valued "education and community involvement" standards in this manner? It is, at best, counter-productive.<br>
<br>The "abide by the list mentality" as its being referred to is simply all we have to work with under the current review process conditions. Is it the only viable method, most likely not, but it is the only available method at this time. The options are getting rather simple: continue as is, and improve the process as we go; stop everything and all approvals until a thoroughly vetted and approved Theme Review process can be developed and put in place; or, let the core devs do all of the theme reviews as they would be the best judges of what is acceptable and what is not.<br>
<br>If you consider those three points as those of a triangle then somewhere in the middle is most likely the best place to find a solution; but, it is equally likely not to be arrived at without mutually cooperative communication and actions being taken together by all parties involved: the community (Theme Review team, Developers/Authors, etc.) and Automattic/WPORG (core/dev team members).<br>
<br>So once again I will ask of the teams, as has already been asked even in this thread: what is expected and under what criteria are the Theme Reviewers to be going forward with?<br><br><br>Cais.<br><br><br><br><div class="gmail_quote">
On Sun, Sep 12, 2010 at 7:54 PM, Chip Bennett <span dir="ltr"><<a href="mailto:chip@chipbennett.net">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;">
<div class="gmail_quote"><div class="im">On Sun, Sep 12, 2010 at 6:28 PM, Chris <span dir="ltr"><<a href="mailto:chris@thematic4you.com" target="_blank">chris@thematic4you.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;">
<div link="blue" vlink="purple" lang="DE">
<div>
<p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);" lang="EN-US">We allow themes to stay for a certain time in the repository
without any change before we put these themes into a ‘sleep’ mode,
but we require a new or updated theme to use the latest and greatest functions.
This isn’t consistent.</span></p></div></div></blockquote><div><br></div></div><div>Actually, no Theme currently in the repository is touched at all. I think it's wrong, and inconsistent with the stated objectives of the repository and of the Theme Review process/team. I proposed a process to suspend obsolete Themes in the repository, but was over-ruled. So, I've dropped the idea for the time being.</div>
<div><br></div><div>You're right; it makes no sense to leave Themes in the repository that have not been updated for over two years, yet make currently supported Themes to meet a considerably higher quality standard. But, we (the Review Team) can't control either the handling of Themes in the repository, or the decision regarding such handling. So we focus instead on that which we can control: the quality standard for Themes being submitted for inclusion. </div>
<div class="im">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div link="blue" vlink="purple" lang="DE"><div>
<p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);" lang="EN-US"> </span></p>
<p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);" lang="EN-US">I don’t know how many themes don’t use sanitizing
functions at all. Why shouldn’t we allow a grace period for switching
from clean_url() to esc_url()? We could use this grace period to educate the
developers with some help from the core team members.</span></p></div></div></blockquote><div><br></div></div><div>That's the idea, actually: to allow for a grace period, and to help provide the necessary educational tools. That's why the Guidelines are so well cross-referenced. That's why we have a section for Guideline revisions that will coincide with the release of WP 3.1. That's why Phil is working on a "knowledge base" Codex reference, to help explain best practices, and how to implement the guidelines.</div>
<div><br></div><div>But it is still up the the Theme developers to make use of those resources. And, as I've said previously: it is incumbent upon Theme developers to keep themselves abreast with WordPress core changes and how those changes impact their Themes.</div>
<div><br></div><font color="#888888"><div>Chip </div></font></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>