[theme-reviewers] Theme Review for blog and business (CMS) themes

Mon Mar 19 19:12:54 UTC 2012

Bear in mind: the repository might not be the most appropriate place for
all Themes - and there's nothing wrong with that. Commercial Theme shops
cater to a subset of the market, and even among the commercial Theme shops,
there are botique/niche Theme shops, that cater to an even smaller subset
of the market. Hooray for variety, and free-market forces. :)

But at the end of the day, because the repository is tied so intimately
into WordPress itself and therefore so easily accessible by every WordPress
end user, it is rather important that repository-hosted Themes, in general,
be suitable for the widest-possible audience. We do have processes in place
for truly niche/special-case Themes. The point where we're in disagreement,
I think, is that the things you've mentioned (title length, navigation
links, blog functionality, etc) *do not constitute* niches. They are far
too trivial to be considered as niche.

I would disagree that the guidelines result in cookie-cutter Themes -
especially from the perspective of the end user. (Do Themes tend to become
more cookie-cutter under the hood? Perhaps, but I would suggest that such
an outcome isn't necessarily a bad thing, if it means that fewer Themes are
_doing_it_wrong() with functional implementation.)

Regarding review templates: we've tried in the past, but it hasn't been all
that useful/successful in practice, for many reasons. I think the most
important thing to focus on is to ensure that, regardless of the format of
the review comments, the review itself focus and clarifies the REQUIRED
issues.

And none of this is spamming or trolling. It is why the list exists. :)

Chip

On Mon, Mar 19, 2012 at 2:00 PM, Mario Peshev <mario at peshev.net> wrote:

> @Cais - a great reply there, kudos. Normally I'd agree with everything.
> The only 'but' here is that for a theme to be a super-widespread template
> and apply everywhere it should be so general that ends as a blank theme at
> the very end. That's why we have so many skeletons submitted with no
> styling at all (not to say 'ugly' though sometimes they are indeed) just to
> meet the expectations easily. Themes could be more-niche alike and serve
> better specific purposes and make more clients happier instead of having
> 1M+ customers in one of the largest market places out there.
>
> @Chip, 2 notes here and I'll stop flooding and trolling here.
>
> 1) I think that we should ignore recommended and info as you suggested. We
> should keep reviews straight to what is critical and required to get in.
> The rest is for the user personal feedback which has nothing to do with the
> submission but just for making a theme even better.
>
> 2) is to present some templates for theme documentation, readme file and
> reviewer feedbacks. Having some blank files to use and some reviewer
> template used by everyone would be great. I have one template built based
> on Yulian and Emil's remarks and recommendations but everyone uses his own
> style.
>
>
> Mario Peshev
> Training and Consulting Services @ DevriX
> http://www.linkedin.com/in/mpeshev
> http://devrix.com
> http://peshev.net/blog
>
>
>
> On Mon, Mar 19, 2012 at 8:45 PM, Chip Bennett <chip at chipbennett.net>wrote:
>
>> Comments in-line (sorry, Cais!)
>>
>> On Mon, Mar 19, 2012 at 11:59 AM, Mario Peshev <mario at peshev.net> wrote:
>>
>>> Listing several comments from trac reviews and the theme review page:
>>>
>>> REQUIRED: Theme options must be added to the database via a single
>>> options array, rather than separately - I know that it is a good-to-have,
>>> but I wouldn't personally reject a theme for that reason.
>>>
>>
>> As far as I'm concerned (speaking personally) this one is a no-brainer.
>> This is just a matter of good stewardship of users' resources. NOT doing it
>> this way, at this point, is little more than a sign of laziness.
>>
>>>
>>> Recommended (highly) is the support of all add_theme_support features.
>>> Well, for some themes this might be obsolete. Let's take super minimalist -
>>> clean classic themes (no post thumbnails) or specifically business themes
>>> or anything else (no custom backgrounds, headers).
>>>
>>
>> "Recommended" is only that: recommended. A Theme would never fail a
>> review for not implementing a recommended feature. To go even further:
>> reviewers should not even be *mentioning* a recommended feature in a review
>> summary. (Now, a recommended *implementation* is another matter. I think it
>> is good practice for reviewers to suggest best-practice implementations of
>> certain features.)
>>
>>>
>>> Our theme test data advices us, as authors and/or reviewers, to test the
>>> site with very long titles, headings, anything that could break the layout.
>>> This is normally good-to-have and very hard-to-achieve. This leads to
>>> limited design creativity actions as reviewers keep declining theme
>>> submissions by testing with a blog title with 150 characters or the
>>> super-large-title-test-post that is in the test data.
>>>
>>
>> Let's start with the overarching philosophy that drives these Theme Unit
>> Tests: these are publicly distributed Themes, used on sites over which the
>> Theme developer has no control of content. Thus, it is prudent to ensure
>> that Themes handle reasonable edge cases. As for the specifics: do you
>> suggest less-extreme edge cases for each of these tests?
>>
>>>
>>> wp_link_pages and pagination hooks might not be used as well. I think
>>> that the pagination in WordPress with next/prev only is not useful and
>>> normally use custom or third-party solutions so having this as required
>>> doesn't make sense to me. Especially for a corporate/business site that
>>> doesn't even need news (pages only). SInce I've bought around 80 themes
>>> from ThemeForest for clients and friends and so, a percentage of them
>>> doesn't use news or blog.
>>>
>>
>> A non-blog use of any Theme in the repository *already* won't show
>> previous/next links on Pages. I'm not sure what the issue is here. Again:
>> just because the developer envisions a Theme only to be used for a site
>> without a blog doesn't mean that, with a few almost-trivial changes, an end
>> user couldn't also use that same Theme for a site that does have a blog.
>>
>> As for third-party implementations of navigation links: they should be
>> hooking into core functions. I could be wrong, but I'm pretty sure core
>> functions already cover just about every navigation case imaginable.
>>
>>>
>>> The required CSS classes or HTML tag stylings are a common reason to
>>> reject a theme as well. .wp-caption, .wp-caption-text, .gallery-caption,
>>> .sticky, .bypostauthor are classes I add specifically for a theme before
>>> submission, never used in my demos or sites otherwise.
>>>
>>
>> Even sites without a blog could conceivably still attach images to posts.
>> The only one of those CSS classes that is exclusively blog-related is
>> .sticky - and bear in mind: we don't actually require Theme developers to
>> *style* those classes. Rather, we just require that they *include* them, so
>> that they've at least *considered* whether their design should incorporate
>> a particular style for sticky posts, and/or for author comments.
>>
>>>
>>> Some themes are rejected due to: 'this is not described in readme.txt'.
>>> We should probably define a template to be filled for every theme, for a
>>> standardization. In addition to that people won't google the markup styling
>>> for readme files, common thing for themes and plugins on WPORG.
>>>
>>
>> The only things that should be *required* to be described in the Theme
>> documentation are limitations, design constraints, design assumptions, or
>> unique setup instructions for the Theme. And yes: if they apply, they DO
>> need to be documented, so that the end user can know HOW to use the Theme
>> as it's intended to be used.
>>
>>>
>>> There are other remarks as well, but these are a few I just found out.
>>>
>>
>> I'm not seeing anything here that would need any significant changes.
>>
>> One thing I would like to see is for reviews to get more consistent in
>> the manner and content of information presented. I think it would help
>> Theme developers the most if the reviews simply listed the things that are
>> REQUIRED. I cringe a bit when I see reviews that include a long list of
>> RECOMMENDED/INFO observations that have no bearing on the ultimate approval
>> of the Theme. Perhaps the process would be easier for Theme developers if
>> the review summaries were a bit more condensed, with emphasis on what is
>> REQUIRED in order for the Theme to be approved. (I think that would
>> eliminate some of the points you listed above.)
>>
>> Chip
>>
>>
>>
>>>
>>>
>>> A quick offtopic, this is not working:
>>> http://themes.trac.wordpress.org/report/14 , outputs:
>>>
>>> *Trac detected an internal error:*
>>>
>>> KeyError: 'numrows'
>>>
>>>
>>> Mario Peshev
>>> Training and Consulting Services @ DevriX
>>> http://www.linkedin.com/in/mpeshev
>>> http://devrix.com
>>> http://peshev.net/blog
>>>
>>>
>>>
>>> On Mon, Mar 19, 2012 at 6:41 PM, Edward Caissie <
>>> edward.caissie at gmail.com> wrote:
>>>
>>>> I agree with all of Chip's point here ... especially the following
>>>> statement:
>>>>
>>>>
>>>> On Mon, Mar 19, 2012 at 12:36 PM, Chip Bennett <chip at chipbennett.net>wrote:
>>>>
>>>>> Ultimately, though: any discussion such as this one should include
>>>>> specific Guidelines that you want to see changed or removed. I'm not sure a
>>>>> wholesale change in philosophy is either plausible or prudent at this point.
>>>>
>>>>
>>>> As much as we are open to discussing the guidelines, it is much easier
>>>> to deal with specifics and review those than to take a run at the whole
>>>> gamut of what the guidelines entail.
>>>>
>>>>
>>>> Cais.
>>>>
>>>> _______________________________________________
>>>> theme-reviewers mailing list
>>>> theme-reviewers at lists.wordpress.org
>>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>>
>>>>
>>>
>>> _______________________________________________
>>> theme-reviewers mailing list
>>> theme-reviewers at lists.wordpress.org
>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>
>>>
>>
>> _______________________________________________
>> theme-reviewers mailing list
>> theme-reviewers at lists.wordpress.org
>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>
>>
>
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20120319/5ac17569/attachment-0001.htm>