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

Mon Aug 16 16:58:02 UTC 2010

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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20100816/8ec7cbf6/attachment-0001.htm>