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
Freemind-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freemind-developer