[Opensim-dev] Fwd: mantis resolved vs. closed

Sun Feb 1 01:01:02 UTC 2009

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.

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.

Regards,
dahlia

On Sat, Jan 31, 2009 at 6:24 AM, James Stallings II <
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> 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> 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> 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
>> > 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
>> >
>> >
>> _______________________________________________
>> Opensim-dev mailing list
>> 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
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090131/f6ed8321/attachment-0001.html>