[theme-reviewers] New Ticket Resolution

Thu Oct 14 15:44:08 UTC 2010

If the license declaration is accurately conveying GPL compliance I would
likely approve the theme, even if it is not letter-compliant to the
"Guideline" ... we will be taking the next step with version 3.1 by giving
them a full example of what to be expected. Essentially a copy and paste
block, as I understood it, that will meet the guidelines and therefore
become an easily enforced "requirement".

As to existing themes not meeting the exact requirement at this time, but
still clearly conveying the theme is being released under a GPL-compatible
license, I would suggest using the "new" format but I would not hold it
against the theme until the above is implemented.

To be honest, and I have been struggling with the wording for some time,
"Guideline" and "requirement" should not be used in the same sentence IMO.
It is either one or the other in simpler thinking. That being said, I treat
the CSS validation as more a guideline than a requirement; and, I make every
effort to stay consistent in how I approach the CSS when reviewing a theme.

Cais.

On Thu, Oct 14, 2010 at 11:06 AM, Chip Bennett <chip at chipbennett.net> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/2ac31529/attachment-0001.htm>