It wouldn&#39;t be *entirely* no different from the current Reviewers group - I assume that Pross can work some SQL magic to generate reports of tickets assigned by User Group? If so, then Report #7 becomes incredibly useful for the Training workflow.<div>
<br></div><div>Otherwise, yes: we could add Trainees to the Reviewers group, and just instruct them only to use &quot;suggest-approval&quot; and &quot;suggest-not-approved&quot; resolutions for closing tickets.</div><div>
<br></div><div>Which causes me to ask another question: can we add Statuses, and assign resolutions to a Status other than &quot;Closed&quot;?</div><div><br></div><div>If so, we could have a &quot;Pending&quot; Status, and have tickets resolved as &quot;suggest-approval&quot; or &quot;suggest-not-approved&quot; change to &quot;Pending&quot; status, rather than &quot;Closed&quot;.</div>
<div><br></div><div>(I think, though, that I remember Otto saying that adding Statuses was much more difficult than adding Resolutions.)</div><div><br></div><div>Chip<br><br><div class="gmail_quote">On Fri, Oct 8, 2010 at 2:02 PM, Edward Caissie <span dir="ltr">&lt;<a href="mailto:edward.caissie@gmail.com">edward.caissie@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Now that I see &quot;authenticated&quot; users really cannot be much use to new Theme Reviews I better understand the idea you are putting forward, but unless we can restrict resolution options by group then what you are suggesting would be no different from the &quot;reviewers&quot; group that already exists ... at least that is how I am reading the permission sets available on the Trac wiki here: <a href="http://trac.edgewall.org/wiki/TracPermissions" target="_blank">http://trac.edgewall.org/wiki/TracPermissions</a><br>


<br>There may be potential to a group that is only able to &quot;suggest&quot; resolutions as that will also allow for clearer explanations of what each resolution means to a Theme author.<br><br>Cais.<div><div></div><div class="h5">
<br><br><div class="gmail_quote">

On Fri, Oct 8, 2010 at 2:44 PM, Chip Bennett <span dir="ltr">&lt;<a href="mailto:chip@chipbennett.net" target="_blank">chip@chipbennett.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">


1) We don&#39;t want everyone and their brothers (i.e. all authenticated users) to be resolving tickets. So, I would advise against this approach.<div><br></div><div>2) The issue isn&#39;t that &quot;merely&quot; authenticated users cannot review Themes or leave comments on tickets; rather, it is that the process of &quot;assigning&quot; those Themes, and then following up on them, is an entirely manual process without a Trainee user group.</div>



<div><br></div><div>So, the only way to allow tickets to be assigned (in the system), and tracked (in the system), without allowing the entire world the ability to resolve/close tickets, is to add a Trainee group.</div><div>



<br></div><div>Is there some downside to this idea that you&#39;re seeing and that I&#39;m not seeing?</div><div><br></div><div><font color="#888888">Chip</font><div><div></div><div><br><br><div class="gmail_quote">

On Fri, Oct 8, 2010 at 1:30 PM, Edward Caissie <span dir="ltr">&lt;<a href="mailto:edward.caissie@gmail.com" target="_blank">edward.caissie@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">Although I haven&#39;t tested it, the current permission set allows anyone to log in and start reviewing.<br>


<br>As long as the reviewer, new or &quot;trainee&quot;, assigns the ticket to themself then the process should flow correctly.<br>


<br>The only benefit I am seeing at the moment to a &quot;Trainee&quot; group, and that can simply be done by adjusting the &quot;authenticated&quot; group, is the resolution restrictions.<br><br><br>Cais.<br><br>PS: Confirmed an authenticated user can only leave comments no resolution or assigning permissions available. EAC<br>





<br><div class="gmail_quote"><div><div></div><div>On Fri, Oct 8, 2010 at 1:59 PM, Chip Bennett <span dir="ltr">&lt;<a href="mailto:chip@chipbennett.net" target="_blank">chip@chipbennett.net</a>&gt;</span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"><div><div></div><div>

<div class="gmail_quote"><div>On Fri, Oct 8, 2010 at 12:22 PM, Edward Caissie <span dir="ltr">&lt;<a href="mailto:edward.caissie@gmail.com" target="_blank">edward.caissie@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">






I agree with the idea of new reviewers having some sort of workflow to follow to make the initial reviews easier to get done; and, for these new reviewers to become more involved with the process.<br><br>Although I understand the suggestion of a &quot;Reviewer Trainee&quot; group the basic premise is any community member can write a review for most any theme provided they follow the basic guidelines for writing a Theme review. We essentially have this already documented, perhaps it needs to be re-worded or re-written to take into consideration the recent changes in the Theme Trac management.<br>








<br>IMO, if a new reviewer is not able to follow the outline(s) already provided putting them in a &quot;Reviewer Trainee&quot; group may not correct any potential issues but would create more administrative maintenance. </blockquote>






<div><br></div></div><div>True; but what I&#39;m envisioning by leaving the Trainee workflow as informal would *also* lead to additional administrative maintenance. Without a Trainee being able to assign himself a ticket to review, we (the Reviewers) have no idea what ticket a Trainee is reviewing (or, we&#39;re dependent upon them leaving a comment on the ticket, &quot;claiming&quot; it). I can see some workflow &quot;clashes&quot; if a Trainee &quot;claims&quot; a ticket, only to have another Reviewer complete the review for that ticket simultaneously (since everyone is working from the FIFO model for the review queue).</div>






<div><br></div><div>Further: we have no direct way of knowing when a Trainee has completed a review, since the Trainee cannot change the ticket status. We are again dependent upon the Trainee reporting back to the Team, via email or whatever.</div>





<div>
<div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">Explaining and documenting the process to be used may be more beneficial than restricting what resolutions a new reviewer can use.<br>








<br>Given all of the above still leaves me with a question, or two: do you see a great influx of new reviewers around the corner; and, how long do you expect a new reviewer to have the &quot;Trainee&quot; status?<br></blockquote>






<div><br></div></div><div>1) I&#39;m certainly *hoping* for an influx of reviewers. The process is simply not sustainable without more hands. Frumph had a mad rush to get the queue back in line several weeks ago, but that certainly wasn&#39;t sustainable, as it took basically all his time for about an entire week. I&#39;ve been trying to do the same, but I&#39;ve been operating at a pace that is also not sustainable, long-term. (That said, I&#39;m going to try to clear out the Priority #2 Queue tonight and tomorrow, as I have some free time.)</div>






<div><br></div><div>2) I would think that a new reviewer getting &quot;Trainee&quot; status would be as simple as someone saying, &quot;how do I review Themes?&quot;, and then you or Pross adding that person to the Reviewer Trainee group, and setting them off to work on the first available ticket. :)</div>






<div><br></div><font color="#888888"><div>Chip</div></font></div>
<br></div></div><div>_______________________________________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org" target="_blank">theme-reviewers@lists.wordpress.org</a><br>
<a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
<br></div></blockquote></div><br>
<br>_______________________________________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org" target="_blank">theme-reviewers@lists.wordpress.org</a><br>
<a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
<br></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org" target="_blank">theme-reviewers@lists.wordpress.org</a><br>
<a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
<br></blockquote></div><br>
</div></div><br>_______________________________________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</a><br>
<a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
<br></blockquote></div><br></div>