[theme-reviewers] Twenty Ten Child 2010 Weaver V 1.2.1

[Chip Bennett]

Comments interspersed...

On Mon, Aug 2, 2010 at 11:42 AM, Bruce Wampler <brucewampler at gmail.com>wrote:

>  A note about 2010 Weaver V 1.2
>
> This new version of my theme has been in the queue for over 3 weeks now
> (ticket 366). It
> is a "child" theme of Twenty Ten (actually, a "pseudo-child" since in
> included all the
> code from Twenty Ten as well as its own code.)
>
> Since I submitted V 1.2, Twenty Ten released Version 1.1 which had some
> minor fixes,
> but generated a couple of also minor but visible incompatibilities with the
> child.
>
> I just submitted 2010 Weaver 1.2.1 that includes the newest Twenty Ten 1.1,
> and
> fixes the incompatibilities. The new ticket is 541. I would like to
> respectfully request
> that when the turn for ticket 366 comes up (it is just a few down at the
> moment) that
> the version 1.2.1 be used instead, and not be sent to the end of the line.
> This change
> was caused by the release of a new version of the parent.
>
> This of course again brings up the issue of handling child themes. Which
> versions of
> which parent/child themes are compatible? And after experiencing this very
> issue
> with 2010 Weaver 1.2, I believe even more that the proper way to handle
> child
> themes in the published library is to do it the way I have with 2010 Weaver
> - leave
> it up to the theme developer to included the files from the parent as well
> as the
> child in a "pseudo-child". At least then when a new parent version is
> published, the
> child theme will continue to work, even if it doesn't take advantage of
> whatever
> is new in the parent.
>

I disagree with this point. What you suggest would deprive "pseudo-child"
Themes of the vast majority of their power and usefulness.
I believe what you call a "pseudo-child" Theme would be more properly termed
a *derivative* Theme. I think both *derivative* Themes and *child* Themes
have their place.

As for your specific issues regarding incompatibility from TwentyTen 1.0 and
1.1: without seeing all the files from TT 1.0 and 1.1, as well as your
Theme's two versions, it is difficult to speak definitively. However, is it
possible to code either a child or derivative Theme in such a way that it
would degrade gracefully in case of up-version induced incompatibilities?

It's probably outside the scope of this mail list, but if you would like to
discuss your specific Theme-incompatibility issues, I'd be happy to do so
individually. I'm totally guessing, but it seems to me that we can find a
way to ensure more robust compatibility, and/or more graceful degradation.


> In times when there is not a very long queue for reviews, a few days
> probably won't
> matter if a new update of the child is needed. But when the queue is
> several weeks
> long, or more, and the child is based on a major theme (like Twenty Ten), I
> think
> it is fair to account for the special case of a parent's update requiring
> changes in
> the child and not bump the new version all the way to the end of the queue.
>
> And this really applies to any theme for that matter. If a theme author
> discovers
> an issue with a theme in the queue, I think the revised version should
> retain
> the original place in the queue. To do otherwise is to discourage authors
> from
> supplying the best versions of their theme. I think many authors would
> rather see
> their slightly buggy theme get reviewed as soon as possible, rather than
> submit
> a revision that could delay the release of their theme for several weeks.
>
> So rather than closing the first ticket, perhaps it should remain in the
> queue but
> contain a comment and link to the newer version. When its turn comes up,
> then
> all associated tickets can be closed.
>

On this point, I agree. I don't think that Theme authors should be penalized
for finding/fixing errors or issues with their Themes between the time the
Theme is queued and the time that it is reviewed.

Perhaps we can strike some balance here?

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