[theme-reviewers] Formal Request for Change of Methodology.
Paul Appleyard
paul at spacecat.com
Tue Jul 2 02:53:26 UTC 2013
Jasper, I don't think that you can compare theme dev and plugin dev - a
plugin can alter one tiny part of a theme or WP functionality, whereas a
theme must comply with a wide range of functional and aesthetic
restrictions.
That being said, the guidelines do tend to descend in to an almost
legalese style of wording that can verge on the opaque for newer
reviewers, not to mention there are items in there tagged 'draft' -
something I've just noticed and which apparently take away their
'required' status.
When it comes down to it the guidelines are there to shepherd non-admins
in filtering out the majority of the overtly crap themes that are way
off base, so that the admins can do their final review. The guidelines
are not meant to be all-powerful, and theme authors can go to the list
if they feel they've been dudded by their reviewer.
So - there probably needs to be a higher emphasis placed on the
ephemeral nature of said guidelines, and a greater underlining of the
function of the list.
IMHO :)
Paul Appleyard
On 26/06/2013 7:31 PM, Jasper Kips wrote:
> Speaking as a developer, I wholeheartedly agree with Philip.
> Developers should be given as much leeway as feasible.
>
> Having said that, there are some points I would like to point out as
> an administrator of websites.
> I expect themes to have one major functionality; to display the
> content in a pleasing and correct way. Most certainly I do not expect
> themes to incorporate functionality that will break the displaying of
> content, when switching to another theme. Case in point, I do not
> expect a theme to use its own shortcodes, switching themes then
> becomes a nightmare, instead of a breeze.
> Even when it is opt-in, for the owner (not necessarily the
> administrator) of a site it should be easy to change themes, without
> having to worry about extra things. Themes that allow inserting of
> scripts, have built-in widgets, just fall short of that standard.
> Remember, users will use functionalitiy if it is there.
>
> Just to be clear, by breaking I mean that the main content, that what
> is returned by the_content, is not shown as intended, hence the no no
> on my administrator side, of shortcodes.
>
> Furthermore, I expect a certain level of quality of the theme code.
> Developers are human, and they do make mistakes. The main engine, PHP,
> changes, removes, adds, changes the way functions work. Etcetera. All
> these things require that troubleshooting should be as easy as
> possible. This is not only in the interest of the user, but also of
> the theme developer. I remove themes themes which I can't easily
> troubleshoot. Another missed opportunity for the developer.
> The lack of requirements on theme documentation is disturbing in my view.
>
> I do not think the current methodology is wrong, actually it is quite
> good, and in ways better than the methodology used for plugin
> reviewing, and in ways better than most QA processes I encounter in my
> job. I regularly encounter problems with plugins, but seldom with
> themes, that should actually say something about the quality of themes
> in the WordPress repository.
>
> The problem lies in the implementation. Reviewers are human, and have
> their own ideas by certain standards. Following the discussion, I bet
> there are themes that reviewed by reviewer A, and pass, while if they
> would have been reviewed by reviewer B they would fail. This is no
> problem in itself, but it reveals some underlying problems in the
> implementation of the guidelines. And, more acute, the way the
> guidelines are explained. To say something in a theme is plugin
> territory, and thereby rejecting the theme, is plain stupid. One
> should, at the very least, explain WHY it is plugin territory. And
> why, given that the guidelines put emphasis on the display
> functionality, but don't exclude other functionalities, it is a good
> reason not use theme specific functionality that is considered plugin
> territory.
>
> There is a great risk that the guidelines will be seen in a legalistic
> way. This is, in my opinion, somewhat overshooting the idea of the
> guidelines. Note that the reviewers, and most of the theme developers,
> are volunteers, doing it besides their regular job. They should be
> encouraged, not decouraged, by the review process, the guidelines and
> the way their theme, or review, is appreciated.
>
> So, long story short, Philip has a good point, but I feel the process
> should be looked at, not the methodology.
> Just my penny.
> Sincerely,
>
> Jasper Kips
>
>
> Op 26 jun. 2013, om 07:43 heeft Emil Uzelac <emil at uzelac.me
> <mailto:emil at uzelac.me>> het volgende geschreven:
>
>> here* is the thing, not hear, sorry my phone is acting weird!
>>
>>
>> On Wed, Jun 26, 2013 at 12:41 AM, Emil Uzelac <emil at uzelac.me
>> <mailto:emil at uzelac.me>> wrote:
>>
>> So hear is the thing. With the blessings of others, I am thinking
>> that
>> Themes should not be "crucified" the way we're doing this now. As
>> I was previously expressing, not all things are the
>> "plugin territory".
>>
>> My personal methodology is, if nothing breaks, or interferes with the
>> core and it's useful to users, let it be, as simple as that.
>>
>> Restricting and eliminating rather harmful stuff, will project very
>> negatively to Theme authors.
>>
>> I don't want to step on anyone's toe here and this is what I believe
>> is right, or at least it should be :)
>>
>> Emil
>>
>>
>> On Wed, Jun 26, 2013 at 12:35 AM, Philip M. Hofer (Frumph)
>> <philip at frumph.net <mailto:philip at frumph.net>> wrote:
>>
>> i.e. don't even give it a second glance, that's a feature of
>> the theme
>>
>>
>>
>> -----Original Message----- From: Philip M. Hofer (Frumph)
>> Sent: Tuesday, June 25, 2013 10:35 PM
>>
>> To: theme-reviewers at lists.wordpress.org
>> <mailto:theme-reviewers at lists.wordpress.org>
>> Subject: Re: [theme-reviewers] Formal Request for Change of
>> Methodology.
>>
>> There's no question about it, as long as it passes the theme
>> unit test with
>> default settings it would pass right?
>>
>>
>>
>> -----Original Message----- From: Daniel
>> Sent: Tuesday, June 25, 2013 10:31 PM
>> To: theme-reviewers at lists.wordpress.org
>> <mailto:theme-reviewers at lists.wordpress.org>
>> Subject: Re: [theme-reviewers] Formal Request for Change of
>> Methodology.
>>
>> What about themes like my one where you can remove the header and
>> footer because your using a bridge like wp-united? Where do
>> those sort
>> of things come into play?
>>
>>
>>
>>
>> On Wed, Jun 26, 2013 at 3:29 PM, Philip M. Hofer (Frumph)
>> <philip at frumph.net <mailto:philip at frumph.net>> wrote:
>>
>> These are features of a theme, the shortcodes and more
>> are 'features' of the
>> theme.
>>
>> If they use the theme and use those shortcodes, then that
>> is the theme that
>> is using it, to require shortcodes to be cross compatible
>> and in a plugin is
>> simply ridiculous.
>>
>> The end user, while picking a theme will choose a theme
>> that has features
>> that they want. When they choose another theme that
>> doesn't have those
>> previous themes features they miss out, it's not a
>> question of requiring a
>> compatibility.
>>
>> This also goes with themes that have specialty
>> programming in the way of
>> custom post types and the like. - again the data is not
>> lost, it's still
>> there, just switching to a different theme will not grant
>> access to it.
>>
>> The age of feature rich themes and innovation should be
>> promoted not
>> stifled.
>>
>>
>> -----Original Message----- From: Harish
>> Sent: Tuesday, June 25, 2013 10:24 PM
>> To: theme-reviewers at lists.wordpress.org
>> <mailto:theme-reviewers at lists.wordpress.org>
>> Subject: Re: [theme-reviewers] Formal Request for Change
>> of Methodology.
>>
>>
>> Good suggestions by Philip (Frumph) however I have to
>> disagree with:
>>
>> " the idea that a theme must adhere and be cross
>> compatible with other
>> themes in features is a nuance that is unnecessary to
>> worry about."
>>
>> Themes do not have to be cross compatible with other
>> themes, but they should
>> not be the cause of the end user losing data when
>> changing their themes.
>>
>> 2 of the most common issues are shortcodes and custom
>> meta boxes where the
>> key has "_" in front to hide it from the custom meta
>> fields section.
>>
>> If theme developers are worried of making things easier
>> for the end user,
>> most of these things should not have been in the theme in
>> the first place.
>>
>>
>>
>> Regards,
>> Harish
>>
>>
>> -----Original Message-----
>> From: theme-reviewers
>> [mailto:theme-reviewers-bounces at lists.wordpress.org
>> <mailto:theme-reviewers-bounces at lists.wordpress.org>]
>> On Behalf Of Philip M. Hofer (Frumph)
>> Sent: Wed 26 June 13 10:41 AM
>> To: theme-reviewers at lists.wordpress.org
>> <mailto:theme-reviewers at lists.wordpress.org>
>> Subject: [theme-reviewers] Formal Request for Change of
>> Methodology.
>>
>> 1) Remove all requirements and recommendations, change it
>> all to 'best
>> practices', do not remove anything in the codex just yet.
>>
>> 2) Theme review process.
>> * Theme reviewers tag a theme for review. / It already
>> passed the upload
>> checker
>> * Check theme with the other plugin(s)[1] available for
>> development, check
>> it for notices, warnings, fatals and deprecation
>> messages, Pass/Fail
>> * Check theme with theme unit test. Pass/Fail
>> * Review the tags, website links, theme name. Pass/Fail
>>
>> It's done, it's reviewed, it's over, if it passed all of
>> those, flag it as
>> passing review and live.
>>
>> 3) Anything else missing on the above list that is a MUST
>> should be added to
>> the list but only if it's a MUST, and can't go live no
>> exception.
>>
>> [1] Make the plugins work for the theme review team; add
>> common security
>> problems, etc.
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> This is it, this is all that is needed. Everything
>> else is icing on the
>> cake for best practices.
>>
>>
>> Themes are the 'meat and potatoes' of WordPress, the idea
>> that a theme must
>> adhere and be cross compatible with other themes in
>> features is a nuance
>> that is unnecessary to worry about. Plugins are made to
>> enhance themes;
>> if a plugin doesn't work with a theme the community WILL
>> contact the author;
>>
>> they always do. As long as the theme is up to date with
>> core coding which
>> all of the tools at our disposal make you aware of - of
>> which even the
>> messages from core will also state things it is
>> unnecessary to do anything
>> otherwise.
>>
>> // not sure about
>> Not sure what Nacin wrote in entirety on the Make site,
>> but having the
>> themes that are live and pass the upload process and
>> immediately go live
>> again would be a boon; that basically makes it like the
>> theme developer has
>> svn access, without having svn access.
>>
>>
>>
>>
>>
>> _______________________________________________
>> theme-reviewers mailing list
>> theme-reviewers at lists.wordpress.org
>> <mailto:theme-reviewers at lists.wordpress.org>
>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>
>> _______________________________________________
>> theme-reviewers mailing list
>> theme-reviewers at lists.wordpress.org
>> <mailto:theme-reviewers at lists.wordpress.org>
>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>> _______________________________________________
>> theme-reviewers mailing list
>> theme-reviewers at lists.wordpress.org
>> <mailto:theme-reviewers at lists.wordpress.org>
>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>
>> _______________________________________________
>> theme-reviewers mailing list
>> theme-reviewers at lists.wordpress.org
>> <mailto:theme-reviewers at lists.wordpress.org>
>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>
>> _______________________________________________
>> theme-reviewers mailing list
>> theme-reviewers at lists.wordpress.org
>> <mailto:theme-reviewers at lists.wordpress.org>
>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>> _______________________________________________
>> theme-reviewers mailing list
>> theme-reviewers at lists.wordpress.org
>> <mailto:theme-reviewers at lists.wordpress.org>
>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>
>>
>>
>> _______________________________________________
>> theme-reviewers mailing list
>> theme-reviewers at lists.wordpress.org
>> <mailto: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/20130702/05d32425/attachment-0001.html>
More information about the theme-reviewers
mailing list