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

Mon Aug 16 18:58:10 UTC 2010

Yes, and no.

The way I see it: all Themes must meet standards that are current *at the
time the Theme is submitted*. Afterward, all submitted Themes cannot be more
than one release-cycle out of date with respect to new functionality and
deprecated functions.

That's a pretty generous amount of leeway for maintaining Themes against
current standards.

As long as the intent is explained clearly in this manner (and Themes are
handled as fairly as possible), I don't think Theme developers will have
much room for complaint.

Chip

On Mon, Aug 16, 2010 at 1:52 PM, Edward Caissie <edward.caissie at gmail.com>wrote:

> 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/70db1e29/attachment-0001.htm>