[theme-reviewers] New Ticket Resolution

[Edward Caissie]

As Chip is suggesting, I would agree ... looking at the WorkFlow image (the
wiki is now on my reading list), the "trainee" workflow is essentially the
following:

New --> Assigned --> Accepted --> Closed (resolved?)

... with "Accepted" not currently used in any of the Theme Review porcesses
and a "Reviewer" is required to close, or make a resolution on the ticket.



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

> On Thu, Oct 14, 2010 at 1:44 PM, Otto <otto at ottodestruct.com> wrote:
>
>> On Thu, Oct 14, 2010 at 1:35 PM, Chip Bennett <chip at chipbennett.net>
>> wrote:
>> > On Thu, Oct 14, 2010 at 1:32 PM, Edward Caissie <
>> edward.caissie at gmail.com>
>> > wrote:
>> >> Also, just as a reminder for those not familiar with Trac, all
>> >> resolutions, no matter their label, close the ticket.
>> >
>> > 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.
>>
>> The problem with the idea of a suggest-whatever resolution and the
>> ticket closing has to do with how trac works. When a ticket is closed,
>> changing it to another resolution means reopening it and then
>> resolving it with the new resolution. Two steps, basically. This
>> rapidly becomes annoying.
>>
>> Now, the TracWorkflow *is* adjustable, but I don't know much about how
>> to do it at present. Here's a page on the topic:
>> http://trac.edgewall.org/wiki/TracWorkflow
>>
>> For those who don't want to read through it all, this graphic
>> illustrates the default workflow:
>> http://trac.edgewall.org/chrome/common/guide/basic-workflow.png
>>
>> The wiki page has several examples of how we can modify it to have
>> "review" states or similar. We can try to implement some of those if
>> it would be helpful to the process.
>>
>> I would suggest that, for now, let's see how the manual approach we're
> currently using works.
>
> One thing that would help us would be the ability to create reports based
> on User Group (primarily, "Reviewer" vs "Authenticated"). If we can generate
> reports of tickets assigned to Authenticated users (i.e. the Reviewer
> Trainees who are not yet added to the "Reviewer" group), then we can
> probably make-do with what we're doing now...
>
> Chip
>
>
> _______________________________________________
> 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/a4baed3f/attachment.htm>