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.stalli...@gmail.com <mailto:james.stalli...@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 <adj...@gmail.com > <mailto:adj...@gmail.com>> wrote: > > +1 on removing states rather than adding as well. > > Adam > > On Fri, Jan 30, 2009 at 11:53 PM, MW <michaelwr...@yahoo.co.uk > <mailto:michaelwr...@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 <jeffa...@gmail.com <mailto:jeffa...@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@lists.berlios.de > <mailto:Opensim-dev@lists.berlios.de> > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev@lists.berlios.de > <mailto:Opensim-dev@lists.berlios.de> > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de <mailto:Opensim-dev@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@lists.berlios.de <mailto:Opensim-dev@lists.berlios.de> > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev -- justincc Justin Clark-Casey http://justincc.wordpress.com _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
