[theme-reviewers] Spammy theme?

Tue Jul 26 03:48:57 UTC 2011

>
> *The idea of "adoption" is for the benefit of *end users*, who would have
> a seamless upgrade experience from the old version of the previously
> abandoned Theme, to the updated version post-adoption.
> *

This would still be possible...but with the added benefit of being able to
inform the user that it's not from the original source. Instead of "click
here to upgrade your Theme," it would say "your Theme was retired, but click
here to switch to a newer Theme that is compatible with the one you're
using."

*The Theme upgrade process deals only with Theme name/slug...
> *

I'm not sure what you mean by this. Or I guess I should say: I don't know
how the update notices are pushed out to users from WordPress.org. I'm
assuming that interface can accommodate fork updates without too much
modification. Is that incorrect?

*Properly attributed Themes - both originals and forks - wouldn't need any
> additional header tags in order to indicate the original:fork relationship,
> because that relationship would be indicated clearly by the
> copyright/attribution notice.
> *

Problems:

1. The copyright/attribution notice does not have a standardized format, so
machine-readability would be a challenge.
2. There isn't a 1:1 relationship between authors and Themes. Using
attribution would fail in instances where one author has created 2 or more
Themes.

Regarding the GPL, the license encourages openness and freedom, but it also
requires proper attribution. Thus, even if "same Theme, different author" is
convenient for WordPress.org's upgrade system, the GPL--or copyright law in
general--considers it "different Theme, different author." Consequently, the
pre-adoption source code would still need to be provided as a separate work.

On Mon, Jul 25, 2011 at 8:20 PM, Chip Bennett <chip at chipbennett.net> wrote:

> The idea of "adoption" is for the benefit of *end users*, who would have a
> seamless upgrade experience from the old version of the previously abandoned
> Theme, to the updated version post-adoption.
>
> The GPL poses no issues or problems whatsoever with "adoption"; if
> anything, the GPL actually facilitates the concept, because it permits
> modification and redistribution of the code. Bear in mind: the GPL deals
> with *copyright*, not *trademark*. The Theme upgrade process deals only with
> Theme name/slug, and as such would be a *trademark* question rather than a
> *copyright* question.
>
> But I wholeheartedly agree that if the original developer indicates that he
> does not want the Theme to be "adopted", then as the trademark owner, that
> decision should be respected.
>
> Themes can be forked right now; no changes needed. While I'm all in favor
> of making a transition as easy as possible, whatever changes that could be
> made to the infrastructure in order to tie the *fork* to the *original*,
> none of those changes would benefit those who need it most: i.e. those who
> are using the *original* version of the obsolete Theme.
>
> Properly attributed Themes - both originals and forks - wouldn't need any
> additional header tags in order to indicate the original:fork relationship,
> because that relationship would be indicated clearly by the
> copyright/attribution notice.
>
> Chip
>
> On Mon, Jul 25, 2011 at 8:08 PM, Darren Slatten <darrenslatten at gmail.com>wrote:
>
>> Theme adoption seems like it could raise issues with the GPL, regarding
>> the need to clearly distinguish between original code and post-adoption
>> code. I'm guessing not too many Theme developers would appreciate having
>> their name/attribution diluted by the adoption process. Perhaps a better
>> solution would be to allow "forking" a Theme. Details and benefits would be
>> something like this:
>>
>>
>>    - Add a new style.css key/value pair to define a "Fork of:
>>    {$retired_theme_name}" relationship.
>>    - A retired Theme would keep its own attribution and statistics data.
>>    - New Theme would be named something different and effectively treated
>>    as an independent Theme (i.e., a retired Theme could be forked by more than
>>    one developer).
>>    - The "Fork of:" data could be used to trigger a separate kind of
>>    update notice--one that makes the distinction between a simple update and a
>>    "Under New Management!" update.
>>    - Retired Themes could still be resumed by original authors, even if
>>    the Theme has been dormant for awhile (and forked in that time).
>>    - WordPress.org could provide aggregate statistics on original+fork
>>    downloads.
>>    - Themes could be forked whether they're retired or not.
>>    - Users could get a better understanding of how a certain Theme will
>>    function (e.g., I'd rather download a Twenty Eleven fork than a Classic
>>    fork).
>>    - Users could filter their Theme search by origin.
>>
>>
>> Just throwing some ideas out here...
>>
>>
>>
>>
>> On Mon, Jul 25, 2011 at 6:45 PM, Vicky Arulsingam <
>> vicky.arulsingam at gmail.com> wrote:
>>
>>> I like this idea a lot, especially allowing other developers to adopt
>>> a theme and bring it up to WP standards.
>>>
>>> Should the original theme author be contacted about their outdated
>>> theme or is it considered forfeit especially since a theme hasn't been
>>> updated in 2 years
>>>
>>> On 7/26/11, Edward Caissie <edward.caissie at gmail.com> wrote:
>>> > The basic premise I have always tried to champion is moving the "older"
>>> > themes into a secondary repository so they are not lost but are
>>> obviously
>>> > shown as "out-of-date"
>>> >
>>> > There are many older themes that can be easily brought up to current
>>> > standards but the original author's are no longer interested in
>>> updating
>>> > and/or involved with WordPress.
>>> >
>>> > I would like to see these themes simply moved, then after another
>>> arbitrary
>>> > time limit made available to be adopted by a new author. I have put
>>> forward
>>> > this idea at least once before and still see it as having a great deal
>>> of
>>> > potential (aside from all necessary changes to the repository to make
>>> it
>>> > work).
>>> >
>>> >
>>> > Cais.
>>> >
>>> >
>>> > On Mon, Jul 25, 2011 at 4:15 PM, Claude Needham <gxxaxx at gmail.com>
>>> wrote:
>>> >
>>> >> On Mon, Jul 25, 2011 at 1:11 PM, Angelo Bertolli
>>> >> <angelo.bertolli at gmail.com> wrote:
>>> >> > Why not just have a "works with version X" selection for users like
>>> on
>>> >> > the plugin side?  Then the users could decide what was working, and
>>> >> > things could be pruned accordingly.
>>> >> >
>>> >> If a theme seriously does not work with the current version of
>>> >> wordpress, it should be retired.
>>> >> I am assuming that we are trying to encourage people to work with the
>>> >> latest release that they can.
>>> >>
>>> >> I have been in situations where a plugin that I relied upon had not
>>> >> been updated yet. (A shopping cart).
>>> >> But if I need an old obsolete theme -- I probably already have it
>>> >> installed on my site.
>>> >>
>>> >> If I am theme hunting, it would be very disappointing to dl a theme
>>> >> from wporg that is obsolete under the most current core.
>>> >>
>>> >> Just my thoughts,
>>> >> Claude Needham
>>> >> _______________________________________________
>>> >> theme-reviewers mailing list
>>> >> theme-reviewers at lists.wordpress.org
>>> >> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>> >>
>>> >
>>>
>>>
>>> --
>>> -----
>>> Vicky Arulsingam
>>> _______________________________________________
>>> theme-reviewers mailing list
>>> theme-reviewers at lists.wordpress.org
>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>
>>
>>
>>
>> --
>> Darren Slatten
>>
>>
>> _______________________________________________
>> 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
>
>

-- 
Darren Slatten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20110725/d07a65a6/attachment-0001.htm>