Hi Robert,
Robert Vojta wrote:
Honestly saying, I don't really know, why I care about issues, that could be resolved within minutes .. that I could resolve by myself, if just somebody would give me a hint .. just to see them targeted to OOo later, 2.0.1 or even worse beeing left without any comment.
just a small example, look at Issue #i35830#. From time to time, I'm
trying to go through issues with target milestone 'OOo Later' and
I'm trying to find the 'critical' ones which should be fixed in the
OOo 2.0, not later. I found one, the Issue #i35830#. I asked Pavel
if I can set the target milestone back to OOo 2.0, because it's
'important' from the users point of view (issues is about the fact,
that the the file is renamed if you change the export filter in the
save as dialog and the origin filename contains dots). He agreed and
I did it.
Simply changing target milestones without contacting the issue owner or project lead is never a good idea. A set target milestone in OOo means that the owner plans to fix it for that release. If the owner changes this to a later milestone, because of too much work, then changing this back won't change that he won't be able to do this. It only causes even more work to change this back.
BTW: A single issue is hardly ever the place to discuss the relative importance of the issue compared to others.
Few days ago I was examining Issues with target milestone
OOo 2.0 and this issue wasn't there. I opened it directly and what
a surprise, target milestone is back on OOo later without
a word.
A reason for that target milestone was given before. And personally I don't see this issue as critical as you do. The file dialog shows the name it will save under, so the user can still correct the problem. And if the changed name collides with that of an existing file, you'll be asked for confirmation that this is what you want to do. I believe there are other more critical issues.
OK, nevermind, I decided to look at the source code and
find where the problem is. I described it in the Issue, I proposed
three solutions and now, I need a small hint which solution is the
best one - not from the programmers point of view, but from the
users point of view - user interface.
Fine. Fortunately the issue has meanwhile been assigned to Falko (ft), who is in the User Experience group - so he's the right one to answer this one - but not for fixing it.
I didn't receive an answer till today, so, I can't fix it. If I'll receive an answer, I can fix it, I can create CWS (I've already got my first CWS integrated ;-) and I can push it to the QA process, so the fix will be integrated.
Your question isn't that old. But if he doesn'r respond, you might try prodding him with a personal mail. Note that changes that change the existing behavior for the normal case - and thus require a change of specification - are almost certainly not acceptable at this time, very shortly before release. So your solution c) is the only feasible option for 2.0 (and probably even for 2.0.1). If you have a patch that does this (and does not make it slow as hell), then it ought to be possible to get this in, possibly even for 2.0 (although acceptance of fixes for 2.0 becomes more and more restricted these days to stabilize the upcoming release). The currently attached patch simply removes a specified behavior and is not really acceptable.
Ciao, J�rg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
