Another approach to this issue, which more closely tracks the way in which the broader group wants to use mantis, would be to take the elimination of ticket states to the extreme, and have only two states: Unacknowleged (e.g., the issue has been reported), and Acknowleged (e.g., the ticket has been seen and assigned.<br>
<br>Using these two terms achieves the goal of simplifying ticket state, and leaves the final disposition of the ticket in an open state, until such time as the submitter closes it or it is cleaned up by others working to maintain the mantis in a more general sense.<br>
<br>Cheers<br>James<br><br><div class="gmail_quote">On Sat, Jan 31, 2009 at 8:24 AM, James Stallings II <span dir="ltr"><<a href="mailto:james.stallings@gmail.com">james.stallings@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Yes, the states are confusing. That was the point of the whole thread, I think :)<br><br>Taking more states out will not necessarily cause mantis to reflect the state of an issue more accurately, and will potentially add to the confusion if insufficient states are shown that dont correlate with the facts.<br>

<br>I would remind you all that this is precisely what happened with idb and myself: mantis, for whatever reason, showed me a state for my issue that did not reflect the facts. Worse, it reflected actions by idb he did not actually take, and spawned a big misunderstanding.<br>

<br>I urge you to take the appropriate action to cause tickets to reflect the actual state of the issues that are reported; otherwise, you just continue to sew seeds of misunderstanding and confusion.<br><br>If the problem with tickets and their states is that there are too many tickets, or too many tickets of poor quality, or too many tickets abandoned by their reporters, then the solution is not to limit the number of available states for an issue; rather, the solution is to limit access to the ticketing system to approved bug reporters.<br>

<br>Cheers<br><font color="#888888">James</font><div><div></div><div class="Wj3C7c"><br><br><br><div class="gmail_quote">On Fri, Jan 30, 2009 at 11:30 PM, Adam Johnson <span dir="ltr"><<a href="mailto:adjohn@gmail.com" target="_blank">adjohn@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
+1 on removing states rather than adding as well.<br>
<font color="#888888"><br>
Adam<br>
</font><div><div></div><div><br>
On Fri, Jan 30, 2009 at 11:53 PM, MW <<a href="mailto:michaelwri22@yahoo.co.uk" target="_blank">michaelwri22@yahoo.co.uk</a>> wrote:<br>
> +1, lets not make things even more complicated. A lot of people aren't sure<br>
> what state to set already. So if we made some changes my vote would be more<br>
> for removing some of the states, rather than adding more.<br>
><br>
> Jeff Ames <<a href="mailto:jeffames@gmail.com" target="_blank">jeffames@gmail.com</a>> wrote:<br>
><br>
> Hello,<br>
><br>
> I was originally thinking that we might have more states in mantis<br>
> than we really use, so I agree with Mike that we probably don't need<br>
> to make it more complicated.<br>
><br>
> If people do find separate 'resolved' and 'closed' states to be<br>
> useful, though, I'm happy with leaving them as is. They do seem to<br>
> end up closed eventually one way or another, so it's not a big deal.<br>
><br>
> Jeff<br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
><br>
><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br></div></div><div><div></div><div class="Wj3C7c">-- <br>===================================<br><a href="http://osgrid.org" target="_blank">http://osgrid.org</a><br><a href="http://del.icio.us/SPQR" target="_blank">http://del.icio.us/SPQR</a><br>
<a href="http://twitter.com/jstallings2" target="_blank">http://twitter.com/jstallings2</a><br>
<a href="http://www.linkedin.com/pub/5/770/a49" target="_blank">http://www.linkedin.com/pub/5/770/a49</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>===================================<br><a href="http://osgrid.org">http://osgrid.org</a><br><a href="http://del.icio.us/SPQR">http://del.icio.us/SPQR</a><br><a href="http://twitter.com/jstallings2">http://twitter.com/jstallings2</a><br>
<a href="http://www.linkedin.com/pub/5/770/a49">http://www.linkedin.com/pub/5/770/a49</a><br>