[theme-reviewers] New Ticket Resolution

Thu Oct 14 18:41:40 UTC 2010

True enough, "suggest-approval" is fairly redundant compared to "approved"
... although I would suggest simply not using that particular resolution for
the time being. My idea being: how does removing a resolution affect tickets
already using it?

IF there is no effect, I imagine once someone with the appropriate
permission set has time they can remove it. If it does have an effect then
just leave it alone until those affects can be sorted out and addressed
properly.

Cais.

On Thu, Oct 14, 2010 at 2:35 PM, Chip Bennett <chip at chipbennett.net> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/27c37fc5/attachment-0001.htm>