<HTML><HEAD>
<META content="text/html charset=iso-8859-1" http-equiv=Content-Type></HEAD>
<BODY
style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space"
dir=ltr>
<DIV dir=ltr>
<DIV style="FONT-FAMILY: 'Calibri'; COLOR: #000000; FONT-SIZE: 12pt">
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>Pretty sure every developer who makes a theme is also a user.</DIV>
<DIV> </DIV>
<DIV>Your 2 euro’s was definitely well spent ;) though.</DIV>
<DIV
style="FONT-STYLE: normal; DISPLAY: inline; FONT-FAMILY: 'Calibri'; COLOR: #000000; FONT-SIZE: small; FONT-WEIGHT: normal; TEXT-DECORATION: none">
<DIV style="FONT: 10pt tahoma">
<DIV><FONT size=3 face=Calibri></FONT> </DIV>
<DIV style="BACKGROUND: #f5f5f5">
<DIV style="font-color: black"><B>From:</B> <A title=jasper@planetkips.nl
href="mailto:jasper@planetkips.nl">Jasper Kips</A> </DIV>
<DIV><B>Sent:</B> Wednesday, June 26, 2013 4:03 PM</DIV>
<DIV><B>To:</B> <A title=theme-reviewers@lists.wordpress.org
href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</A>
</DIV>
<DIV><B>Subject:</B> Re: [theme-reviewers] Formal Request for Change of
Methodology.</DIV></DIV></DIV>
<DIV> </DIV></DIV>
<DIV
style="FONT-STYLE: normal; DISPLAY: inline; FONT-FAMILY: 'Calibri'; COLOR: #000000; FONT-SIZE: small; FONT-WEIGHT: normal; TEXT-DECORATION: none">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.
<DIV> </DIV>
<DIV>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!!!!!!!</DIV>
<DIV> </DIV>
<DIV>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. </DIV>
<DIV>Just read that sentence again, and and again, and then ponder on the
implications.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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).</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV>What would be, the conceptual problem, with layering themes. I mean the
following:</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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? </DIV>
<DIV> </DIV>
<DIV>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. </DIV>
<DIV> </DIV>
<DIV>I inflated my prices by the way, it my is my 2 euro's worth by now.<BR>
<DIV>Sincerely,
<DIV> </DIV>
<DIV>Jasper Kips<BR><BR></DIV></DIV>
<DIV> </DIV>
<DIV>
<DIV>Op 27 jun. 2013, om 00:18 heeft Srikanth Koneru <<A
href="mailto:tskk79@gmail.com">tskk79@gmail.com</A>> het volgende
geschreven:</DIV><BR class=Apple-interchange-newline>
<BLOCKQUOTE type="cite">
<DIV dir=ltr>
<DIV>
<DIV>A new tag perhaps for all these "incompatible under new rules" themes
like "Advanced" or "use at own risk" or similar name? <BR><BR></DIV>Put all
these themes in that tag, exclude them from tag filter searches, Recently
updated, new themes, popular lists on <A
href="http://wordpress.org/themes/">wordpress.org/themes/</A> ( so only
experienced users and current users can find them )<BR>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.<BR><BR>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. <BR><BR></DIV>
<DIV>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?<BR></DIV>
<DIV> </DIV>
<DIV>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.<BR></DIV></DIV>
<DIV class=gmail_extra><BR><BR>
<DIV class=gmail_quote>On Thu, Jun 27, 2013 at 3:26 AM, Philip M. Hofer
(Frumph) <SPAN dir=ltr><<A href="mailto:philip@frumph.net"
target=_blank>philip@frumph.net</A>></SPAN> wrote:<BR>
<BLOCKQUOTE
style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex"
class=gmail_quote>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.<BR><BR>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.<BR><BR>-----Original Message----- From: Otto<BR>Sent: Wednesday, June
26, 2013 12:05 PM
<DIV class="im HOEnZb"><BR>To: <A
href="mailto:theme-reviewers@lists.wordpress.org"
target=_blank>theme-reviewers@lists.<U></U>wordpress.org</A><BR>Subject: Re:
[theme-reviewers] Formal Request for Change of Methodology.<BR><BR></DIV>
<DIV class=HOEnZb>
<DIV class=h5>On Wed, Jun 26, 2013 at 12:31 PM, Philip M. Hofer
(Frumph)<BR><<A href="mailto:philip@frumph.net"
target=_blank>philip@frumph.net</A>> wrote:<BR>
<BLOCKQUOTE
style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex"
class=gmail_quote>My ComicPress theme the same way, it's completely
embedded with options that<BR>are specific to the code required to run it,
while there's an addon<BR>available in plugin that plugin will only work
for the theme. It's useless<BR>otherwise.<BR></BLOCKQUOTE><BR>Is
that still around? I thought you'd ported most users over to Comic
Easel.<BR><BR>Comic Easel is a better choice all around, I'd say. That's
more of a<BR>doing-it-right
approach.<BR><BR>-Otto<BR>______________________________<U></U>_________________<BR>theme-reviewers
mailing list<BR><A href="mailto:theme-reviewers@lists.wordpress.org"
target=_blank>theme-reviewers@lists.<U></U>wordpress.org</A><BR><A
href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers"
target=_blank>http://lists.wordpress.org/<U></U>mailman/listinfo/theme-<U></U>reviewers</A>
<BR>______________________________<U></U>_________________<BR>theme-reviewers
mailing list<BR><A href="mailto:theme-reviewers@lists.wordpress.org"
target=_blank>theme-reviewers@lists.<U></U>wordpress.org</A><BR><A
href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers"
target=_blank>http://lists.wordpress.org/<U></U>mailman/listinfo/theme-<U></U>reviewers</A><BR></DIV></DIV></BLOCKQUOTE></DIV>
<DIV> </DIV></DIV>_______________________________________________<BR>theme-reviewers
mailing list<BR><A
href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</A><BR>http://lists.wordpress.org/mailman/listinfo/theme-reviewers<BR></BLOCKQUOTE></DIV>
<DIV> </DIV></DIV>
<P>
<HR>
_______________________________________________<BR>theme-reviewers mailing
list<BR>theme-reviewers@lists.wordpress.org<BR>http://lists.wordpress.org/mailman/listinfo/theme-reviewers<BR></DIV></DIV></DIV></BODY></HTML>