[theme-reviewers] New Ticket Resolution

Chip Bennett chip at chipbennett.net
Thu Oct 14 18:35:43 UTC 2010


I'm under the assumption at this point that, unless we hear otherwise from
Otto or someone, that the original Trainee Workflow idea isn't feasible. So,
under that assumption, we'd have no need for "suggest-approval" or
"suggest-not-approved" as ticket resolutions.

For the time being, having the Trainee indicate one of those two
resolutions, and then having a Reviewer resolve/close the ticket
accordingly, will probably work about the best we can hope for.

In which case, we can eliminate "suggest-approval" as a ticket Resolution.

Chip

On Thu, Oct 14, 2010 at 1:32 PM, Edward Caissie <edward.caissie at gmail.com>wrote:

> Yes, in the most minimalist fashion, resolutions of: Yes, No, and Maybe are
> all that we need, but we have also recently put forward, as in another
> suggestion of yours to use "suggest-approval" and "suggest-not-approval" for
> the Theme Reviewer "Trainees" which although the balance of the idea is not
> well supported by our current tools, those resolutions still make sense to
> use under their "new" proposed meanings.
>
> Also, just as a reminder for those not familiar with Trac, all resolutions,
> no matter their label, close the ticket.
>
>
> Cais.
>
>
> On Thu, Oct 14, 2010 at 12:45 PM, Chip Bennett <chip at chipbennett.net>wrote:
>
>> Okay, then, here's what I propose:
>>
>> 1) Eliminate "needs-additional-review"
>> 2) Eliminate "suggest-approval"
>>
>> We have no need for either one:
>>
>>    - "approved" - Theme passes review, and ticket is closed
>>    - "not-approved" - Theme does not pass review, and ticket is closed
>>    - "closed-newer-version-uploaded" - ticket is closed, and a newer
>>    version of the Theme is reviewed
>>
>> That covers all of our bases right now.
>>
>> Chip
>>
>> On Thu, Oct 14, 2010 at 11:37 AM, Edward Caissie <
>> edward.caissie at gmail.com> wrote:
>>
>>> "approved with comments" and related ideas were the impetus to the
>>> creation of "needs-additional-review" and IIRC "suggest-approval"
>>> resolutions ... if we are going to add more resolutions we need to
>>> understand what the existing ones are to be used for.
>>>
>>> So as you think I have a problem or issue with this approach, I would
>>> rather write I have concerns in continually going forward without looking at
>>> where we came from.
>>>
>>> We should be solidifying our basics before building on them. As I
>>> mentioned before, the current resolutions need to be better defined so
>>> reviewers and end-users alike understand what they are for. If that means we
>>> need to add more afterward I am fine with that, too, but currently we have
>>> resolutions that were meant to cover your "original subject" to my
>>> understanding.
>>>
>>> If our current resolutions are not sufficient, obviously we can add more,
>>> but we should define the existing ones first is essentially what I am
>>> putting forward.
>>>
>>>
>>> Cais.
>>>
>>>
>>> On Thu, Oct 14, 2010 at 12:23 PM, Chip Bennett <chip at chipbennett.net>wrote:
>>>
>>>> So, we circle back to the original subject: the use of "approved with
>>>> comments".
>>>>
>>>> I'm trying to understand your disagreement with this method. To me, it
>>>> is a reasonable compromise between approving generally good Themes, while
>>>> also moving Theme Developers toward increased conformance to the Guidelines.
>>>>
>>>> So, can you help me understand your problems/issues with this approach?
>>>> Is it the approach itself, or is it the idea of formalizing it?
>>>>
>>>> Chip
>>>>
>>>> On Thu, Oct 14, 2010 at 11:15 AM, Edward Caissie <
>>>> edward.caissie at gmail.com> wrote:
>>>>
>>>>> On Thu, Oct 14, 2010 at 11:53 AM, Chip Bennett <chip at chipbennett.net>wrote:
>>>>>
>>>>>> AFAIK, either we enforce them, or we don't.
>>>>>
>>>>>
>>>>> If that is our method then there are no "minor" issues ... and quite
>>>>> simply that is the crux of the matter.
>>>>>
>>>>> The guideline needs to be strongly adhered to with a "black or white"
>>>>> premise but that does not preclude reasonable exceptions and as you are want
>>>>> to describe "selective enforcement", or in my mind reasonable
>>>>> interpretations of the Theme Review page(s) to meet the requirements as they
>>>>> are expected to be met.
>>>>>
>>>>> Would I ignore the current license requirement as you are quoting, in a
>>>>> word: Yes. Would I ignore the complete lack of any sort of GPL-compliance
>>>>> declaration, again in a word: No. If the author has chosen another method to
>>>>> declare the theme GPL compliant that resembles the quote above, then I would
>>>>> likely accept it and most likely suggest they use what the Theme Review
>>>>> page(s) state should be used (at this time). We have already decided that
>>>>> will be changing to something much more "blank and white" in the (near)
>>>>> future.
>>>>>
>>>>> Rather than continually re-hashing this particular point we should be
>>>>> addressing the future requirements of the GPL compatible license
>>>>> declaration(s) and putting that forward.
>>>>>
>>>>> Also to the CSS requirements ... once "FixPress" is not required to
>>>>> have a standard default WordPress installation using the most current Theme
>>>>> Unit Test data pass the validation test(s) I will be happy to re-consider
>>>>> setting a resolution  of "not-approved" based on minor CSS issues, until
>>>>> then I will remain using, as you like to refer to it, "selective
>>>>> enforcement".
>>>>>
>>>>>
>>>>> Cais.
>>>>>
>>>>> _______________________________________________
>>>>> 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/0fdf0479/attachment.htm>


More information about the theme-reviewers mailing list