Hi,
From a Quality Assurance point-of-view, Dimitry's suggestion makes a
lot of sense. It will also increase transparency to our user community,
which was going to be one of my suggestions. It is really good to know,
as a user, that someone has been assigned the problem you reported and
when they predict they'll have a fix for it. It's a lot easier to be
patient if you know your problem hasn't slipped through the cracks.
One way to make this a bit easier is to switch to Bugzilla as a bug
tracker. The latest versions of Eclipse work with a plugin that allows
them to query the Bugzilla (or Trac) problem tracking databases, and
keep track of who is working on what. We can do the same with the
current SourceForge problem database, but with less functionality.
I can't judge, on my own, if this is a good time to make such a move,
but it's something we should think about.
Ray
P.S.: Of course, if we wait, someone is bound to write a plugin to allow
Eclispe to talk to SourceForge, or one of us could do it.
Dimitry Polivaev wrote:
Hi Chris and Dan,
for my part, I don't see this as dramatic as you displayed it. I'm
working on the issues constantly and the ones you mentioned aren't so
grave IMHO.
We know that you keep working, but nobody knows what issues you are
going to solve next, what issues should be solved by me, what issues
should be postponed and what issues are rejected. And keeping this
things clear is important for both the submitters and for us, just to be
sure that nothing relevant is forgotten. That's why I think that we need
a way to track status of all issues. Particularly I do not know what is
the status of the mentioned issues even now after your answer.
Not all of the issues are in the bug tracker, but even for the issues
already put in the bug tracker we do not have any policy.
That's why I make the following proposal:
1. Every bug may be entered in the bug tracker by any of us or by the
community,
2. Chris or Dan are going to work on it next time or make a decision to
postpone or to reject it, he assign the bug to himself, and if I should
work on it, the bug should be assigned to me.
3. The bug resolution field should be used. If the entered bug is fixed,
its resolution field is set to fixed, if the entered bug is postponed,
its resolution field is set to postponed, if the entered bug is
rejected, its resolution field is set to fixed.
With regards to the user icons, please ask Dan if he wants you to fix
this single issue out of about ten open issues with user icons, which I
don't see useful, as we need a better handling for user icons at all and
I don't want to spend time and code to improve this "bad" solution (the
solution is not good as it is not useable for 96% of all our users).
Dan, look here: currently user-defined icons are not exported to HTML
because the directory containing them is not searched and the things are
not found. I would like to fix the issue in 0.9.0. Could you support my
proposal?
I have opened a bug tracker item
https://sourceforge.net/tracker/index.php?func=detail&aid=1795830&group_id=7118&atid=107118
so that you can use it to communicate your decision.
Best regards,
Dimitry
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Freemind-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freemind-developer
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Freemind-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freemind-developer
