[theme-reviewers] WPTRT = TSA?

Thu Jan 20 03:17:15 UTC 2011

Originally, Child Themes were intended to be *update-proof*, not "more
update-proof", than (stand-alone) Themes. They were intended as a way for
the *end user* to add Theme modifications that would be retained when the
Parent Theme was updated.

The point of the Repository (at least, now that it is tied into wp-admin via
automatic updates) is to push Theme updates to end users.

Thus, the two purposes - to provide a means of update-proof Theme
modifications and to push Theme updates - conflict, if the code in question
is the same (i.e. a Child Theme).

If end users will be asked to change the Name: tag of the Child Theme, in
order to prevent it from being over-written, then what is the point of
hosting that Child Theme in the Repository in the first place?

(Now, on the other hand, I can see great advantage in encouraging Child -
rather than derivative - Themes for TwentyTen, TwentyEleven, or whatever
current default Theme.)

Chip

On Wed, Jan 19, 2011 at 8:54 PM, Philip M. Hofer (Frumph) <philip at frumph.net
> wrote:

>  Child themes are more update proof then the standard theme, not sure
> where you are getting and really would like an elaboration on the 'intented
> benefit of child themes'.  Which i'm going to assume you're thinking of the
> fact that it's good to have a child theme that is not going to lose it's
> look when the main parent theme is updated.   In that case I am going to
> note that a child theme can still be customized to denote a non-update path
> by changing the name in the style.css;  just like a theme.   If you're going
> to snag a child theme or theme and make customizations it would be a benefit
> to customize the name to remove it from upgrade notification.
>
>
>
> ----- Original Message -----
> *From:* Chip Bennett <chip at chipbennett.net>
> *To:* theme-reviewers at lists.wordpress.org
> *Sent:* Wednesday, January 19, 2011 6:42 PM
> *Subject:* Re: [theme-reviewers] WPTRT = TSA?
>
> I would like to do something about the horribly out-of-date and obsolete
> Themes in the repository, but maybe now isn't the right time - other than
> trying the positive-reinforcement route (a Theme adoption program). Maybe
> once we've had a year or so of Themes passing the Theme Review process,
> we'll have enough of a selection to justify arguing to begin suspending the
> most egregiously obsolete Themes.
>
> I go back and forth on Child Themes, but at the moment, I'm leaning
> *against* having Child Themes in the Repository. I really believe strongly
> that Child Themes should be left completely to the *End Users*, as their
> means of implementing update-proof Theme modifications. If we start
> encouraging the distribution (and, therefore, *update*) of Child Themes, we
> encourage depriving the End User of the the primary, intended benefit of
> Child Themes.
>
> The Frameworks discussion has progressed well, and as you said: now is
> probably a good time to move that discussion to a wider audience, via a post
> on the Make site. I think we can make some good strides with Frameworks.
>
> I agree regarding SVN-commit access for *trusted* developers - especially
> initially (or as a trial run). The potential for abuse is huge - and
> SVN-commit access for Themes could be pitched as a form of
> award/recognition/achievement for great contributions to the Theme
> Repository.
>
> (Did I forget to mention Theme Documentation? Darn it; I meant to talk
> about it.)
>
> Chip
>
> On Wed, Jan 19, 2011 at 8:19 PM, Philip M. Hofer (Frumph) <
> philip at frumph.net> wrote:
>
>>  We'll get there with the plans we have setup ya?, just gotta have da
>> patience.
>>
>> Donncha's reference reminds me of my tagline "I'm in your site touching
>> your stuff."  kinda brings a new meaning to it ;/  where's the girl wearing
>> the bikini to try to circumvent the system, i'd totally let that happen.
>>
>> The completeness of Justin's "Great strides in cleaning up the repository"
>> statement leaves me to think we really haven't gotten anywhere close to
>> cleaning up the "old" things in the repository.   There is much more we can
>> do to deal with that, given any abilities that Otto might let us have.
>> Think the whole 'up to a certain version' those old themes needs to be
>> inacted upon with the 'adopt' program. (need to continue discussion on it on
>> a make.wordpress.org/themes post)  The issue being that this makes work
>> for Otto to move the ownership of the theme to someone else, if there can be
>> some work done on that to make his life easier that'd be great, or even some
>> automation for pross/cais/chip to handle it.
>>
>> Next is getting the 'flags' set and working for child themes.     This
>> could be done with a bit of code for the repository to associate one theme
>> with another theme as it's parent, since this is bbpress couldn't child
>> theme's be just children post of the parent?  Dunno.   But we still need to
>> look into how to make it work without dropping the ball completely and
>> letting it slide like it has been.
>>
>> Frameworks - frameworks being 'the code behind the templetes'  we've
>> already been having that as part of the discussion we just need to finalize
>> it and so far noone really had any doubts to themes created with framework
>> backends to be put on the repository it's just the definetions that need to
>> be finished so that there's a clear cut view of reviewing them.
>>
>> Chip's SVN itemized in his list brings me to thinking that there are some
>> serious quality theme designers that would warrant this ability to have SVN
>> access; .. but not everyone.  If it's possible to enable svn access to
>> 'known developers of good intent' I'm all for that.
>>
>> One of the things that 2011 is missing in all of those responses is the
>> advent of deeper and more quality documentation from developers utilizing
>> current and new methods instead of some of the ../shudder/ code that is
>> currently out there.
>>
>> I'm also believing that Premium Themes will offer more then just their
>> themes, but direct monthly support contracts for maintenance; installation
>> and customizations - more so then just the theme sale.
>>
>>
>>
>>
>>   ----- Original Message -----
>> *From:* Edward Caissie <edward.caissie at gmail.com>
>> *To:* theme-reviewers at lists.wordpress.org
>> *Sent:* Wednesday, January 19, 2011 5:56 PM
>> *Subject:* Re: [theme-reviewers] WPTRT = TSA?
>>
>> You are correct ... now that you mention it I remember from reading
>> earlier today.
>>
>> Still good to be noticed all the same (*grin*) ... we need something to
>> help generate more interest. Now if we could only get the "Make" site on the
>> proverbial (social media) map.
>>
>> On Wed, Jan 19, 2011 at 8:52 PM, Chip Bennett <chip at chipbennett.net>wrote:
>>
>>> Actually, that was Donnacha's description...
>>>
>>>
>>> On Wed, Jan 19, 2011 at 7:48 PM, Edward Caissie <
>>> edward.caissie at gmail.com> wrote:
>>>
>>>> I guess I can't complain ... at least Ryan took the time to think of and
>>>> write that description.
>>>>
>>>> ... any notice is better than not being noticed at all.
>>>>
>>>>  On Wed, Jan 19, 2011 at 8:20 PM, Chip Bennett <chip at chipbennett.net>wrote:
>>>>
>>>>>  Quite the metaphorical description!
>>>>>
>>>>>  The gates to the official WordPress.org theme repository are now
>>>>> guarded by a hardcore volunteer militia, the Theme Review Team, with all the
>>>>> no-nonsense attitude of a cranky TSA junk-fondler whose hasn’t yet had his
>>>>> afternoon box of donuts.
>>>>>
>>>>>
>>>>> Interesting read from WPCandy today<http://wpcandy.com/presents/the-future-of-wordpress-themes-in-2011>
>>>>> .
>>>>>
>>>>> (Although my attitude is generally more driven in indirect proportion
>>>>> to my daily coffee intake...)
>>>>>
>>>>> 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
>>>
>>>
>>  ------------------------------
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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/20110119/c5133a91/attachment.htm>