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

[Chip Bennett]

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