<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez <span dir="ltr"><<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">This is an interesting blog post with a paragraph about GNOME triaging<div>
<br></div><div><a href="http://afaikblog.wordpress.com/2014/04/09/enabling-participation/" target="_blank">http://afaikblog.wordpress.com/2014/04/09/enabling-participation/</a></div>
<div><br></div><div>Interestingly it's pretty much exactly the same approach I followed with the triaging I had done with 0.100. It would be good to have a simple set of rule like that written down before the meeting. I think the way we triage has a huge impact on lowering contribution barriers,<div class="">
<br></div></div></blockquote><div><br></div><div>+1</div><div><br></div><div>We need at least verify  all the "Unconfirmed" tickets. We can start now, don't need wait until the triage meeting.</div><div>I assume, if the bug is confirmed, we should set:</div>
<div>Milestone = 0.102</div><div>Status = New</div><div><br></div><div>or close them if are not longer present.</div><div><br></div><div>Would be good if we can reset all the priorities to "Unassigned", </div><div>
in all the  tickets with module=Sugar,the field content does not have any sense right now.</div><div>Then we can use the triage meeting to finish the confirmation and to set the priorities.</div><div><br></div><div>What you think?</div>
<div><br></div><div>Gonzalo </div><div><br></div><div><br></div><div><br></div></div>
</div></div>