[theme-reviewers] New Ticket Resolution

Thu Oct 14 15:06:42 UTC 2010

RE: License - the current Guideline requirement is *either* a full-text
license.txt *or* License/License URI header tags. Several Themes have a
"This Theme, including all blah-blah-blah is licensed under the terms of the
GPL. http:(insert one of many URLs here)". Such a statement does not conform
to the current Guidelines as written.

How would you handle this one, if not with an
approved-but-fix-this-in-the-next-version status?

RE: CSS - the current Guideline requirement is that Themes use valid CSS
(per the W3 Validator), with an exception for browser-specific property
prefixes (-moz-box-shadow, etc.). How would you rewrite this requirement
such that it can be enforced in the way that you are suggesting?

Chip

On Thu, Oct 14, 2010 at 9:58 AM, Edward Caissie <edward.caissie at gmail.com>wrote:

> My position on the "license" issue, as was previously discussed, is that
> the format of the "standardization of license declaration" will be addressed
> and enforced with the release of WordPress 3.1, until then we should be
> making (strong) recommendations to follow that future reference.
>
> "I also passed one that had one, single, very minor CSS validation error."
> I would expect no less ... if you have to question if this is right or wrong
> then I believe there must be other underlying issues that need to be
> addressed first, especially if your intent is to fail it if the author does
> not correct it with the next immediate version.
>
> As to CSS validation, IMHO, it would be blatantly obvious if the theme is a
> mess due to its CSS, and with that a review for valid CSS would be strongly
> recommended, but to fail a theme for minor CSS validation errors is not the
> way we should be approaching things in my mind.
>
>
> Cais.
>
>
> On Thu, Oct 14, 2010 at 10:41 AM, Chip Bennett <chip at chipbennett.net>wrote:
>
>> Again, I disagree.
>>
>> There are some things in the Requirements that are indeed *minor* (with
>> respect to the end-user), but that are enforcing a higher quality standard,
>> or are creating a standardization.
>>
>> Some people put a license declaration statement in style.css. We ask them
>> to format it in a standard way (using header tags). If this is the only
>> issue, I'm not going to fail a review just because of it; I'll ask the
>> developer to format the license statement in the standard manner in the next
>> revision.
>>
>> (I had just such a ticket recently.)
>>
>> Your position would seem to advocate that my approach was wrong, and that
>> one of two things should have happened:
>>
>> 1) I fail the review merely for a non-standard license declaration
>> 2) we no longer enforce standardization of license declaration
>>
>> Seriously? Approving the ticket, with the caveat that the license
>> declaration re-formatted to conform to the standard in the next revision
>> isn't a viable alternative here?
>>
>> And what of other "minor" issues? I also passed one that had one, single,
>> very minor CSS validation error. What should I have done? In that
>> circumstance, I see three alternatives to the approving with the caveat to
>> fix in the next revision:
>>
>> 1) Fail the review for the minor error
>> 2) Maintain a list of acceptable versus unacceptable errors, and pass/fail
>> Themes accordingly
>> 3) No longer enforce CSS validation
>>
>> Which of those alternatives is preferable to approving the Theme asking
>> the developer merely to fix the CSS validation error in the next Theme
>> revision?
>>
>> Chip
>>
>> On Thu, Oct 14, 2010 at 9:33 AM, Edward Caissie <edward.caissie at gmail.com
>> > wrote:
>>
>>> 2b) Is probably the most important point here ... if these are *minor*
>>> issues then perhaps they should *not be required*.
>>>
>>> If there are many different "minor" issues that are being allowed then
>>> perhaps all of those should be reviewed to actually see if they need to be
>>> required.
>>>
>>> The whole point is a minor issue is *not* a requirement ... as to the
>>> resolutions, we can fill pages with them but to add more based on this
>>> current thread at this point does not make any sense as what I see coming
>>> forward from this discussion is once again some of the Theme Review
>>> guidelines and expectations may need to be re-addressed.
>>>
>>> As I see it, we are starting to diverge on this topic. We are speaking
>>> both of "minor" issues; and, resolving tickets as "approved' knowing there
>>> are issues of apparent significance that must be addressed. Perhaps similar,
>>> but for all intent and purpose different.
>>>
>>>
>>> Cais.
>>>
>>>
>>> On Thu, Oct 14, 2010 at 10:18 AM, Chip Bennett <chip at chipbennett.net>wrote:
>>>
>>>> Again, I disagree.
>>>>
>>>> If we take your approach, one of two things will happen:
>>>>
>>>> 1) We will not approve Themes that have only one or two minor issues
>>>> that violate the Theme Review Guidelines, thus needlessly
>>>> frustrating/angering Theme Developers
>>>>
>>>> 2) We will approve Themes that have only one or two minor issues that
>>>> violate the Theme Review Guidelines. We will continue to let those issues
>>>> slide in subsequent revisions, which:
>>>>
>>>> a) Will further frustrate/anger Theme Developers, who will accuse us of
>>>> subjective enforcement of the Guidelines and of treating Theme Developers
>>>> unfairly, due to different treatment, and
>>>>
>>>> b) Will lead eventually to those criteria being de facto removed from
>>>> the Guidelines, because we will never be enforcing them.
>>>>
>>>> I don't like any of those options.
>>>>
>>>> Thus, the "Required, But Can Be Fixed in Next Revision" comments.
>>>>
>>>> Chip
>>>>
>>>>
>>>> On Thu, Oct 14, 2010 at 9:10 AM, Edward Caissie <
>>>> edward.caissie at gmail.com> wrote:
>>>>
>>>>> My point is the issues are either minor or they are not ... obviously
>>>>> the flexibility to approve themes with "minor" issues should and is being
>>>>> used ... but, and I write again, if they are *required* to be fixed with the
>>>>> next revision then they should have been *required* to be fixed with the
>>>>> current version as they were IMO not "minor" to begin with if the reviewer
>>>>> is resolving as "not-approved" with the next revision.
>>>>>
>>>>> If the same "minor" issue was later decided to be not a "minor" issue
>>>>> then that is a different matter.
>>>>>
>>>>>
>>>>> Cais.
>>>>>
>>>>>
>>>>> On Thu, Oct 14, 2010 at 10:03 AM, Chip Bennett <chip at chipbennett.net>wrote:
>>>>>
>>>>>> I disagree. We need *some* flexibility to approve tickets that have
>>>>>> only minor issues.
>>>>>>
>>>>>> At the same time, if we approve a ticket with such minor issues, *with
>>>>>> the expectation that those issues are addressed in the next revision*,
>>>>>> then we should not let those minor issues pass in the review of the next
>>>>>> revision.
>>>>>>
>>>>>> Chip
>>>>>>
>>>>>>
>>>>>> On Thu, Oct 14, 2010 at 8:42 AM, Edward Caissie <
>>>>>> edward.caissie at gmail.com> wrote:
>>>>>>
>>>>>>> If a ticket requires a special resolution as a pointer for
>>>>>>> "approved-with-next-revision-fixes" then perhaps the ticket should be
>>>>>>> immediately re-reviewed for those concerns.
>>>>>>>
>>>>>>> IMO, if they are relevant enough to stop future versions of the theme
>>>>>>> from being approved if not addressed, they are relevant enough to stop the
>>>>>>> ticket at hand from being approved.
>>>>>>>
>>>>>>>
>>>>>>> Cais.
>>>>>>>
>>>>>>> On Thu, Oct 14, 2010 at 8:45 AM, Chip Bennett <chip at chipbennett.net>wrote:
>>>>>>>
>>>>>>>> As we approve more Themes - and especially, Themes that are
>>>>>>>> approved, but that have comments indicating certain issues are "Required,
>>>>>>>> but Can Be Fixed in Next Revision" - I'm thinking that we might want to
>>>>>>>> consider another ticket resolution: "approved-with-comments" or
>>>>>>>> "approved-with-next-revision-fixes" or something along those lines.
>>>>>>>>
>>>>>>>> The reason? I'm seeing tickets for "next revisions" of such tickets,
>>>>>>>> that seem to ignore completely the issues indicated as "Required, but Can Be
>>>>>>>> Fixed in Next Revision".
>>>>>>>> Of course, I'm resolving such tickets as "not-approved" - but the
>>>>>>>> reason I bring it up is that we haven't really discussed how we handle such
>>>>>>>> tickets.
>>>>>>>>
>>>>>>>> My process for a Priority #1 Queue ticket is:
>>>>>>>>
>>>>>>>> 1) Check previous-tickets report, to ensure ticket is in correct
>>>>>>>> queue (Pross: can we get the *resolution* column to display by default on
>>>>>>>> this report?)
>>>>>>>> 2) If correct queue, assign ticket to myself
>>>>>>>> 3) Open previous ticket, to check for any issues indicated as "Can
>>>>>>>> Be Fixed in Next Revision"
>>>>>>>> 4) Diff-Review
>>>>>>>> 5) Theme-Check
>>>>>>>> 6) Summarize status of previous-ticket comments
>>>>>>>> 7) (if necessary) Install/check activated Theme
>>>>>>>> 8) Close/resolve ticket
>>>>>>>>
>>>>>>>> The problem I'm foreseeing, of course, is that the previous-ticket
>>>>>>>> comments can very easily fall through the cracks, unless the next-ticket
>>>>>>>> reviewer makes a conscious effort to check the previous ticket. We could
>>>>>>>> alleviate this concern by introducing an appropriate ticket resolution, that
>>>>>>>> would alert the next-ticket reviewer to the presence of any such
>>>>>>>> previous-ticket issues.
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>>
>>>>>>>> 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
>>
>>
>
> _______________________________________________
> 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/20101014/c255df91/attachment-0001.htm>