[theme-reviewers] Discussion on suspension of old themes in the extend/themes

Edward Caissie edward.caissie at gmail.com
Mon Aug 16 18:52:42 UTC 2010 

All themes currently in Trac are being reviewed to current standards, which
is to say WordPress version 3.0 functionality, which conflicts with: "...
Theme developers will have 10-12 months to bring their Themes into
compliance with the current WP version, and 5-6 months to bring their Themes
into compliance with -1 WP version."

More an observation than anything else, I understand your point, but this
potential contradiction would need to be addressed.


Cais

On Mon, Aug 16, 2010 at 12:58 PM, Chip Bennett <chip at chipbennett.net> wrote:

> That's why I would propose a 2-cycle cutoff as more reasonable.
>
> While WordPress 2.8 was released in June 2009 - and with it, various
> required functionality - we are giving Theme developers until June 2010 to
> conform. Granted, we at that point require that the Theme *also* meet the
> standards introduced with WordPress 2.9 - but I don't believe that
> requirement to be overly cumbersome.
>
> On average, Theme developers will have 10-12 months to bring their Themes
> into compliance with the current WP version, and 5-6 months to bring their
> Themes into compliance with -1 WP version.
>
> Chip
>
>
> On Mon, Aug 16, 2010 at 11:47 AM, Edward Caissie <edward.caissie at gmail.com
> > wrote:
>
>> I would expect the only way to get around a reviews in these cases is if
>> the suspension is based on a date when a new core function was added that is
>> now considered a "must" include, for example, body_class(). Anything prior
>> to the introduction of that function would not pass the Theme Review
>> process; and, that will essentially take us to a single release cycle!
>>
>> Anyone notice how slippery the slope is getting?
>>
>>
>> Cais.
>>
>>
>> On Mon, Aug 16, 2010 at 12:38 PM, Chip Bennett <chip at chipbennett.net>wrote:
>>
>>> I think that will be asking too much of the Theme Review team.
>>>
>>> We already know that, given the commit date of a Theme, which subsequent
>>> features and deprecations that Theme will not support.
>>>
>>> I don't think it is asking too much of the Theme developers to
>>> familiarize themselves with the Theme Review standards, and to ensure that
>>> their re-submitted Theme meets those standards.
>>>
>>> A "formal" review of Themes that we know will fail that review adds no
>>> value to the process, and gets us no closer to our goal.
>>>
>>> Chip
>>>
>>>
>>> On Mon, Aug 16, 2010 at 11:34 AM, Edward Caissie <
>>> edward.caissie at gmail.com> wrote:
>>>
>>>> bah ... suspend 'em all and let Matt sort 'em out! (j/k)
>>>>
>>>> Actually, after the first full pass to get somewhat current, I would
>>>> suggest simply starting with the oldest (read: last updated per
>>>> Extend/Themes) and run full reviews on the remaining themes, that is, create
>>>> a Trac ticket and all that it entails; then, formally review the theme with
>>>> the idea of reaching a target of a (minimum) two release cycle for
>>>> repository themes.
>>>>
>>>>
>>>> Cais.
>>>>
>>>> On Mon, Aug 16, 2010 at 11:58 AM, Philip M. Hofer (Frumph) <
>>>> philip at frumph.net> wrote:
>>>>
>>>>>  * Like you relayed later in your comments, it's all about the
>>>>> transitioning, this is the first pass, then theme admins determine what
>>>>> steps to take afterwards based on how effective it was ya?  and adjust
>>>>> methodology based on outcome.
>>>>>
>>>>> Alright, so these are the steps as per noted by cais, chip and myself.
>>>>>
>>>>> 1) Post the forum post, get it stickied.  Note date of suspension as
>>>>> sept 1st (2 weeks)
>>>>> 2) Update related codex material - note this is the first pass and that
>>>>> in 2 months time after the first pass we're going to be doing the same for
>>>>> all themes 2 revisions previous (2 major revisions), i.e 1 year.
>>>>> 3) Field any questions on said forum post.
>>>>> 4) Transfer ownerships by requests from ORIGINAL owner.
>>>>> --- Wait two weeks.
>>>>> 5) Start suspending those that have a date previous to december of
>>>>> 2008.
>>>>> 6) Wait until november of 2010, start the revision suspension of those
>>>>> 2.8.* and previous.
>>>>>
>>>>> A) Find a way to automate this with scripting.
>>>>>
>>>>> ----- Original Message -----
>>>>> *From:* Chip Bennett <chip at chipbennett.net>
>>>>> *To:* Philip M. Hofer (Frumph) <philip at frumph.net>
>>>>> *Cc:* theme-reviewers at lists.wordpress.org
>>>>> *Sent:* Monday, August 16, 2010 8:49 AM
>>>>> *Subject:* Re: [theme-reviewers] Discussion on suspension of old
>>>>> themes in the extend/themes
>>>>>
>>>>> On Mon, Aug 16, 2010 at 10:28 AM, Philip M. Hofer (Frumph) <
>>>>> philip at frumph.net> wrote:
>>>>>
>>>>>>  After a lengthy discussion with Cais in the #wp-themes we've come to
>>>>>> a conclusion that a 2 revision suspension would not be entirely justified
>>>>>> and would harshly impact the themes available that still will work with the
>>>>>> 3.0 series albiet even if using deprecated and non standard code.
>>>>>>
>>>>>
>>>>> I'm not entirely sure I understand this reasoning. "Suspending" a Theme
>>>>> in the repository would have no impact on any current users. It would merely
>>>>> prevent the Theme from being downloaded by a *new* user.
>>>>>
>>>>> Why would we want users downloading Themes that are clearly obsolete,
>>>>> and potentially buggy - if not security-vulnerable?
>>>>>
>>>>>
>>>>>>
>>>>>> We've thought about it and discussed the functionality of the
>>>>>> wordpress themes and what they do and what revision base at this time would
>>>>>> be best to spend anything of it and less then.
>>>>>>
>>>>>> Anything from december 2008 and before should be suspended for 'old
>>>>>> and needs upgraded' themes, that is the release time when 2.7 came out, 2.7
>>>>>> was the the release that really gave themes something more then previous
>>>>>> revisions that match more closely with with what 'works' in a theme.   It
>>>>>> was in essence really 2.8, but 2.7 was the start of it.  So anything
>>>>>> previous to the 2.7 release really can be considered old and needing
>>>>>> updated.
>>>>>>
>>>>>> Then on the 3.1 release, do the 2.8 as the base and so on.
>>>>>>
>>>>>
>>>>> That's probably fair, for a first-pass effort.
>>>>>
>>>>> At some point, though, we probably need to tighten the leash a bit.
>>>>> Giving Theme developers 2 release cycles (which normally translates to 10
>>>>> months to a year) should be sufficient time to update an actively supported
>>>>> Theme, no?
>>>>>
>>>>>
>>>>>>
>>>>>> The concern is the 'warning' to developers that when it will be
>>>>>> happening and enough word out to them that it will be happening.  Giving
>>>>>> ample time for developers who might want to 'rescue' old themes from the
>>>>>> repository to revive them.
>>>>>>
>>>>>> Which brings up two thoughts, information needed to change ownership
>>>>>> of said themes and ample time for developers to revive them.   And
>>>>>> information theme developers that it's going to be happening.
>>>>>>
>>>>>> Me? I don't care, suspend em, if they want them back up, they resubmit
>>>>>> them.
>>>>>>
>>>>>>
>>>>>
>>>>> Exactly. We want actively supported Themes in the repository, right? If
>>>>> so, then we need to hold developers accountable to providing  a modicum of
>>>>> active support: to wit, keeping the Theme updated with current functionality
>>>>> and replacing deprecated functions.
>>>>>
>>>>>
>>>>>>  Cais wants mass emails done, however collectively finding the
>>>>>> authors emails would be a chore, let alone the fact that WordPress
>>>>>> practically *never* mass emails and I doubt that it will ever happen, ever.
>>>>>> So alternatives need to be addressed as the following:
>>>>>>
>>>>>> So what's the minimal that should be done?
>>>>>>
>>>>>> A stickied post on the theme developement forum and a codex entry, in
>>>>>> the most relevant places.
>>>>>>
>>>>>> What would be optimal?
>>>>>>
>>>>>> A post by Matt or the developers blog that gets seen in the RSS feed
>>>>>> list of all wordpress sites, with the minimal post in the forum and codex
>>>>>> entry information.
>>>>>>
>>>>>> The idea' is to not be 'harsh' about the suspension of said themes,
>>>>>> hence to backtrack to the pre 2.7 release, which keeps WordPress in a good
>>>>>> light, while still giving a couple weeks ample warning.
>>>>>>
>>>>>
>>>>> I still like the old "update within one month of the WordPress version
>>>>> release, or the Theme is suspended" route. In other words, within one month
>>>>> after WordPress 3.1 comes out, all Themes not updated since the release of
>>>>> WordPress 2.9 are automatically suspended, until they are updated.
>>>>>
>>>>> (Of course, if a given WordPress release doesn't incorporate any new
>>>>> functionality, or newly deprecate any functions, then it could be excluded
>>>>> from the suspension time frame.)
>>>>>
>>>>>
>>>>>>
>>>>>> ------ Side Note:
>>>>>> Information about how to 'take over' an old theme, i.e. reviving it
>>>>>> should be noted as well and that all old themes should have their original
>>>>>> authors contacted then original author of said theme needs to email the
>>>>>> repository theme admin requesting the ownership change, pretty much how it's
>>>>>> already being done.
>>>>>>
>>>>>> Side effect of the removal/suspension would also be that when they
>>>>>> resubmit they will be automatically added to the theme trac when resubmit,
>>>>>> which is a goal that would benefit everyone.
>>>>>>
>>>>>> Additonal note: While the GPL Compatibility issue arose with the
>>>>>> suspensions previously and there were some very vocal people about
>>>>>> suspending the themes at that time, it was still done regardless of those
>>>>>> complaints.   It was justified and responsible of the theme repository admin
>>>>>> to do it.  It is the same with this;  The theme repository has an underlying
>>>>>> responsibility to the end user to keep the repository up to date and in a
>>>>>> manageable state to the end user.
>>>>>>
>>>>>
>>>>> Agreed; provided that the way it is handled is the absolute best that
>>>>> it can be. I'm advocating suspending outdated Themes, but I also think that
>>>>> Theme developers should be given every opportunity to know that the change
>>>>> is coming, and to know how to avoid Theme suspension.
>>>>>
>>>>> Communication is key.
>>>>>
>>>>> Chip
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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/20100816/5044ed31/attachment-0001.htm>

More information about the theme-reviewers mailing list