[theme-reviewers] Formal Request for Change of Methodology.

Wed Jun 26 23:38:47 UTC 2013

You have some very credible thoughts on this.    Just to ponder some additional value to it, you are never ‘locked in’; your data is never lost.   There are a multitude of plugins available that convert post types, taxonomies, meta fields in posts...   Creating a loop for the end user to port their data from one meta-field to another or even providing the code as inclusion to other themes is more then possible. ... There has never been a situation that I have come up with that will disallow the data used from one of my themes to be unable to be used in any other themes.   While it might not have been ‘straightfoward’ and immediately accessible,  the data is never lost.

Pretty sure every developer who makes a theme is also a user.

Your 2 euro’s was definitely well spent ;) though.

From: Jasper Kips 
Sent: Wednesday, June 26, 2013 4:03 PM
To: theme-reviewers at lists.wordpress.org 
Subject: Re: [theme-reviewers] Formal Request for Change of Methodology.

I think we really losing track of two important things here. The first is the reason for the guidelines. The WordPress repository is the business card of WordPress. And as such, a consistent quality is of utmost importance. Whether developers agree or not, it is.  

The second one is more important, because y'all talk about them, but I see only one real life user -me- participating in the discussion. AND THE USERS ARE THE BIGGEST PART OF THE WORDPRESS COMMUNITY!!!!!!!

There are things important to users, backward compatibility, or actually it is forward compatibility, is one of the most important ones. As a user I actually care if I can switch themes, if I can rely on the quality of themes (and plugins, but that is an aside) and if I can rely on the fact that there will be support for themes I use in the future. 
Just read that sentence again, and and again, and then ponder on the implications.

It boils down to a couple of things. The first. If themes that are currently available in the WP repository use things that in the past years have moved into the realm of plugins, I would most certainly not like it if that was suddenly stopped. It would break my sites, and the sites I administer. Losing data would be out of the question, as would losing the ability to display the data, as I have done in the past. And there are ways to educate us users, about incompatibilities and such. Plugins that do that, nag me to death in the admin screens, about steps I need to take to retrieve the lost functionality. I see no reason themes couldn't do that.

The second, user experience should be paramount. Not the ideas of developers, not the ideas of review teams, the user experience should be the number one concern, for developers and all involved. Themes that use their own, say private, functionality, outside the main functionality of displaying, seriously decrease the satisfaction of the users. It locks us in, into the theme. And, as a matter of fact, it has been one of the main reasons in businesses I work with, in the past not to use WordPress, because of the intertwining of themes and functionality. (Yes I am a user, so yes I am allowed to be irrational, as this statement seems to contradict the first one I made about us users).

Now, there is however a solution to the dilemma the developers face. And it is built in into WordPress. I can see the urge, and the conviction and dedication that goes into developing themes, it is the way great themes are born. But why don't we try to get to a solution, one that might not be perfect, but can be pragmatical, and actually can be done within the guidelines -which actually should be guidelines, not law carved into stone- but asks a little more fantasy from developers as well as reviewers, and still keeps the users satisfied.
What would be, the conceptual problem, with layering themes. I mean the following:

Suppose you have theme with 'propriety' functionality, that defines shortcodes for instance, and thereby falls short of approval by the review team. My solution would be, build the theme without the offending functionality, but deliver it with a child theme, that actually incorporates the functionality. From my point of view, as a user remember, it would be ideal. You give me the choice, use the theme with, or without the functionality. You force me to make an informed decision, . A click on a checkbox is not really informed decision making. The main theme still falls within the guidelines, they actually force you to make themes that support child themes anyway. So turn it around and use the requirement.

Now I realize, it puts an extra burden on the developer, but realize that developers -without intent I am sure- now put that burden on the user and the review team. But if you are a disciplined developer, you built it modular already, right? 

Ironically, the idea of vendor lock in, is one argument I often use for open standards and open source, but in the mean time, open source developers are creating vendor lock in themselves. 

I inflated my prices by the way, it my is my 2 euro's worth by now.

Sincerely, 

Jasper Kips

Op 27 jun. 2013, om 00:18 heeft Srikanth Koneru <tskk79 at gmail.com> het volgende geschreven:

  A new tag perhaps for all these "incompatible under new rules" themes like "Advanced" or "use at own risk" or similar name? 

  Put all these themes in that tag, exclude them from tag filter searches, Recently updated, new themes, popular lists on wordpress.org/themes/ ( so only experienced users and current users can find them )
  Themes under this tag to have a big bold disclosure saying they are meant only for experienced users and maybe be locked in or will have trouble migrating etc.

  That way their current user base who are happily using the existing functionality can keep getting updates and no new user of WordPress will be inconvenienced when they switch from these advanced themes and loose all their data. If any new theme wants to add plugin functions, they can add this new tag and they can be used by experienced users. 

  Support responsibility for these themes to be on the theme authors and they should actively provide support, so current support warriors won't be burdened?

  We can have the best of both worlds this way, Directory can host advanced themes too and new users won't complain WordPress is hard to use.

  On Thu, Jun 27, 2013 at 3:26 AM, Philip M. Hofer (Frumph) <philip at frumph.net> wrote:

    Thanks!  .. sadly no, it's not that simple; there are still roughly 25k'ish users out there (that can be counted with services like Comic Rocket+backlinks+etc) that still haven't migrated to Comic Easel - which only counts to a modest (/grin) 150ish sites using it right now.

    It's rather unfortunate that I have to point people to the github to download the updated ComicPress that keeps it compatible with the recent releases of WordPress. - even then, I have seen some version 1.6's out there of ComicPress running wordpress 2.0 something's heh.

    -----Original Message----- From: Otto
    Sent: Wednesday, June 26, 2013 12:05 PM 

    To: theme-reviewers at lists.wordpress.org
    Subject: Re: [theme-reviewers] Formal Request for Change of Methodology.

    On Wed, Jun 26, 2013 at 12:31 PM, Philip M. Hofer (Frumph)
    <philip at frumph.net> wrote:

      My ComicPress theme the same way, it's completely embedded with options that
      are specific to the code required to run it, while there's an addon
      available in plugin that plugin will only work for the theme.   It's useless
      otherwise.

    Is that still around? I thought you'd ported most users over to Comic Easel.

    Comic Easel is a better choice all around, I'd say. That's more of a
    doing-it-right approach.

    -Otto
    _______________________________________________
    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/20130626/c7b1e184/attachment.html>