[Opensim-dev] Fwd: mantis resolved vs. closed
Justin Clark-Casey
jjustincc at googlemail.com
Sun Feb 1 18:29:15 UTC 2009
Dahlia Trimble wrote:
> I'd like to share some thoughts even though they may be at risk of going
> against the tide..
>
> Opensim has been a hobby activity for me, and I suspect that's true for
> many of the developers, testers, and users as well. I like to see
> properly functioning software which is one of the reasons I began
> contributing. I also wanted use of some features that didn't yet exist
> in the software so I took it upon myself to implement them and also
> share them with the rest of the community. Since then I continue to make
> time to contribute, in the form of bug fixes, enhancements, or new
> features. This takes time away from the time I have to actually use the
> software as I intended in the first place. I don't mind sharing some of
> my time and effort in support of community goals as in the case of a
> community project such as Opensim I generally get more benefit out than
> I put in. I suspect that many users and testers feel the same way and
> they may often have passionate feelings about their contributions which
> can sometimes result in conflict. Perhaps some conflict can be a healthy
> thing but I'm just not sure in the case which inspired this thread.
> Personally I do review mantis issues frequently and I tend to address
> some when I have a reasonable understanding of the affected portions of
> the code base, when there is sufficient information available in the
> Mantis entries, when I have the resources to easily replicate the
> problem, and when I have sufficient time available to attempt and test a
> fix. Once I've successfully implemented a fix then I submit it and
> either mark the issue as resolved or add a note asking for others to
> help test. I seldom close an entry and usually leave it for the
> submitter to close.
>
> I think most of the information that is submitted on Mantis has
> potential value and I'm not sure that limiting access will be
> beneficial. I would rather propose that simple guidelines be developed
> which describe helpful and effective reports, and these guidelines be
> displayed in a prominent manner during the submission process. I also
> would like to suggest that many of the developers are in a similar
> situation as myself; this is a low level and uncompensated activity for
> them and they simply don't have the resources to address all mantis
> entries. This should not mean that some issues are more important than
> others or that some are being purposely ignored.
>
> With regards to state: The current ones are usable but there is some
> confusion on my part about the best way to use them. I would like to see
> a state along the lines of "solution implemented, awaiting feedback from
> community". The only state which appears to fit in this situation is
> "resolved" or "patch feedback". Somehow "patch feedback" doesn't seem to
> fit as I haven't actually submitted a patch, but rather I've attempted
> to implement a solution.
There are some guidelines for bug submitting at
http://opensimulator.org/wiki/Bugs
as well as a guide to what the different states mean (although the diagram misses out the closed state). I've always
regarded 'resolved' as the "solution implemented, awaiting feedback from community" state.
Perhaps as a group we need to go back and review that page and see how it could be made clearer if it's lacking. I
suspect that changing the states we currently have will bring only marginal benefits, if any at all. I also agree with
Dahlia in that that limiting who can report bugs won't be benificial overall (bureaucracy around who has access, higher
cost in reporting bugs, etc.)
>
> Regardless of the outcome of this discussion, I am hopeful that affected
> parties can remain mindful that we should try to remain tolerant and
> respectful of each other and not let individual events steer the project
> towards a position of less tolerance.
Some time ago we had more active management of bug reports (most of which was done by non-developers). I think this is
very helpful when that management is done in a respectful, tolerant if occasionally firm way.
>
> Regards,
> dahlia
>
>
> On Sat, Jan 31, 2009 at 6:24 AM, James Stallings II
> <james.stallings at gmail.com <mailto:james.stallings at gmail.com>> wrote:
>
> Yes, the states are confusing. That was the point of the whole
> thread, I think :)
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Cheers
> James
>
>
>
> On Fri, Jan 30, 2009 at 11:30 PM, Adam Johnson <adjohn at gmail.com
> <mailto:adjohn at gmail.com>> wrote:
>
> +1 on removing states rather than adding as well.
>
> Adam
>
> On Fri, Jan 30, 2009 at 11:53 PM, MW <michaelwri22 at yahoo.co.uk
> <mailto:michaelwri22 at yahoo.co.uk>> wrote:
> > +1, lets not make things even more complicated. A lot of
> people aren't sure
> > what state to set already. So if we made some changes my vote
> would be more
> > for removing some of the states, rather than adding more.
> >
> > Jeff Ames <jeffames at gmail.com <mailto:jeffames at gmail.com>> wrote:
> >
> > Hello,
> >
> > I was originally thinking that we might have more states in
> mantis
> > than we really use, so I agree with Mike that we probably
> don't need
> > to make it more complicated.
> >
> > If people do find separate 'resolved' and 'closed' states to be
> > useful, though, I'm happy with leaving them as is. They do
> seem to
> > end up closed eventually one way or another, so it's not a
> big deal.
> >
> > Jeff
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> <mailto:Opensim-dev at lists.berlios.de>
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> >
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> <mailto:Opensim-dev at lists.berlios.de>
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> >
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
>
> --
> ===================================
> http://osgrid.org
> http://del.icio.us/SPQR
> http://twitter.com/jstallings2
> http://www.linkedin.com/pub/5/770/a49
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
--
justincc
Justin Clark-Casey
http://justincc.wordpress.com
More information about the Opensim-dev
mailing list