[theme-reviewers] Theme Options and Functions

[Chip Bennett]

On Wed, Oct 20, 2010 at 12:08 PM, Demetris Kikizas <kikizas at gmail.com>wrote:

> On Wed, Oct 20, 2010 at 7:44 PM, Jon Cave <jon at lionsgoroar.co.uk> wrote:
> > On Wed, Oct 20, 2010 at 5:38 PM, Demetris Kikizas <kikizas at gmail.com>
> wrote:
> >> For example, why serialization of options should be even a
> recommendation?
> >
> > It's not, that was just suggested in Chip's first email and, from what
> > I can see, it was decided not to be included in the recommendations.
> > Only prefixing functions/options was agreed upon.
> >
> It may not become a recommendation, but it shows the way of thinking
> that brought us to this point.
>
> This way of thinking is perverse.
>

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.


>
> Instead of looking for solutions to practical problems, it comes up
> with solutions for problems that do not exist.
>
> Recommendations and requirements for themes should only be there if
> they solve practical problems.
>

Given that you have yet to review any Themes, how would you know what
"practical problems" exist?

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.

But since you've not contributed any Theme
reviews<https://themes.trac.wordpress.org/search?q=demitris>,
you wouldn't really have any idea of the kinds of issues that we see come up
frequently in submitted Themes.

>
> For example:
>
> Never hardcode the URI of your theme’s stylesheet.  It is not allowed
> for this or that reason.
>
> Or:
>
> wp_head() is strictly required for this and that reason.
>

Both of which are examples for which valid reasons exist for their inclusion
in the Guidelines.

>
> The way I see it, a requirement should only be added when we are
> confronted with a real, practical problem and, after we explore all
> possible solutions, we conclude that the only way to solve the problem
> is by a formal, strict requirement.


So, what are the specific "strict requirements"  with which you disagree,
and why?

Chip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20101020/f52971df/attachment.htm>