<div class="gmail_quote">On Wed, Oct 20, 2010 at 12:08 PM, Demetris Kikizas <span dir="ltr"><<a href="mailto:kikizas@gmail.com">kikizas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Wed, Oct 20, 2010 at 7:44 PM, Jon Cave <<a href="mailto:jon@lionsgoroar.co.uk">jon@lionsgoroar.co.uk</a>> wrote:<br>
> On Wed, Oct 20, 2010 at 5:38 PM, Demetris Kikizas <<a href="mailto:kikizas@gmail.com">kikizas@gmail.com</a>> wrote:<br>
>> For example, why serialization of options should be even a recommendation?<br>
><br>
> It's not, that was just suggested in Chip's first email and, from what<br>
> I can see, it was decided not to be included in the recommendations.<br>
> Only prefixing functions/options was agreed upon.<br>
><br>
</div>It may not become a recommendation, but it shows the way of thinking<br>
that brought us to this point.<br>
<br>
This way of thinking is perverse.<br></blockquote><div><br></div><div>Or, it is merely the Review Team bringing up a potential issue, and discussing whether it is worth addressing, and if so, how it should be addressed.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Instead of looking for solutions to practical problems, it comes up<br>
with solutions for problems that do not exist.<br>
<br>
Recommendations and requirements for themes should only be there if<br>
they solve practical problems.<br></blockquote><div><br></div><div>Given that you have yet to review any Themes, how would you know what "practical problems" exist? </div><div><br></div><div>You see, one of the "practical problems" with which we as a diverse Review Team must deal is the fairness and objectiveness of our reviews. If one of us finds that we are making similar comments on several Themes, regarding issues that are either not addressed in the Guidelines, or else are not addressed clearly enough, we bring such issues up to the Team as a whole, to determine how we can ensure that we are all handling such issues fairly and objectively.</div>
<div><br></div><div>But since <a href="https://themes.trac.wordpress.org/search?q=demitris">you've not contributed any Theme reviews</a>, you wouldn't really have any idea of the kinds of issues that we see come up frequently in submitted Themes.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
For example:<br>
<br>
Never hardcode the URI of your theme’s stylesheet. It is not allowed<br>
for this or that reason.<br>
<br>
Or:<br>
<br>
wp_head() is strictly required for this and that reason.<br></blockquote><div><br></div><div>Both of which are examples for which valid reasons exist for their inclusion in the Guidelines. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
The way I see it, a requirement should only be added when we are<br>
confronted with a real, practical problem and, after we explore all<br>
possible solutions, we conclude that the only way to solve the problem<br>
is by a formal, strict requirement.</blockquote><div><br></div><div>So, what are the specific "strict requirements" with which you disagree, and why?</div><div><br></div><div>Chip</div></div>