Hi J�rg,
On Fri, May 06, 2005 at 12:22:03PM +0200, Joerg Barfurth wrote:
> Andre Schnabel wrote:
> >As Christian already said .. we *are* helping, some of us *did* go
> >through the RFE process (I never did, as I've foreseen, what would
> >happen). But sometimes it seems, our help is not wanted.
>
> It is my impression that the RFE process never took off, because it was
> too late for OOo 2.0. And not much has happened since the initial ideas
> were floated, because 2.0 is still not out and most work still goes there.
Noone expected the process to have influence on OOo 2.0
And furthermore the whole thing is not about getting the features
implemented, but getting decisions.
> OOo 2.0 had one big step forward in handling planned changes by making
> most of the work public.
It was a step forward, but this had absolutely no influence on handling
RFEs in issuezilla.
> The 'Q concept' was published, specs were
> published and announced
So where are these specs "announced"?
It doesn't really help if the final spec gets announced.
> - sometimes well before implementation and most
> feature issues were entered in IZ instead of the Sun-internal bug
> tracking system. This already would have allowed community
> participation, but it was not explicitly solicited. It is my impression
> that this opportunity was not used very much.
Again: These doesn't help regarding the handling of the issues as these
issues already have had a decision. Furthermore: you have virtually no
chance of hitting such an issue with a query (only if you know the magic
word "Q-PCD") - the summaries are non-telling.
And even when one stumbles across one of these and reads a spec.. Why
should one expect to be listened to if even the comments from developers
are ignored? (Just take the spec regarding the (non-)saving of the last
cursor position).
And BTW: Most of those long-term-Features are not the problem. The
problem are recently changes things.
But again: These are different (although related topics).
1) handling/processing the issues
2) having influence on the actual implementation of an issue
1) has always been a problem and has not improved at all since the
beginning of OOo.
2) has been a problem lately since major changes in usability were done
and there was no process/no way to veto the changes. This in fact still
is a problem. People are trying to change the spec, but Sun's people
don't listen/are not willing to correct "mistakes".
Some examples:
* quickstarter
* mail-merge
* cursor-position
* line-breaks in justified paragraphs
* change of defaults (compatibility options)
* printer-configuration
* toolbar-"blinking" of docked, contextual toolbars
* [...]
some are resolved, others are not.
The quickstarter-issue was a huge fight, the toolbar-issue is in the
works (not that hard to get a correction this time), the others (esp.
the line-break one) are negated/not taken seriously ("old behavoiur was
a bug").
I'm sure that the qa-engineers know about the duplicates, but still they
close them as "Wontfix". I cannot tell (and don't want to judge) whether
this is bad will (for the "statistics") or just laziness (don't want to
look-up the other issue).
What I want to say is:
These are urgent problems and they have to be considered *now* and not
for OOo 3.0
> [...]
> What did you foresee would happen with the RFE process?
Just answer this little question:
What is the difference between having 600+ issues assigned to "bh" and
600+ issues assigned to "requirements" when the last action of all those
issues is "reassigned to bh/requirements"?
My wishes:
* way to escalate issues for the current version
* getting decisions of other issues in a timely fashion. Having
untouched issues that are 2 years and older (without *any* action at
all) really sucks.
> AFAICT the plan
> was to implement a better RFE process for the release after 2.0, and
> this is still possible and you can participate in making that a reality.
There is no visible improvement. And the request for another process is
not new at all. Neither is the offer to help. But everytime the answer
was "we are working on a new process" (that was in 2003)
http://qa.openoffice.org/servlets/ReadMsg?list=dev&msgNo=1071
http://qa.openoffice.org/servlets/ReadMsg?list=dev&msgNo=1117
> If you don't participate, you shouldn't complain if it doesn't happen.
> And if you and others don't participate because you 'foresee' it not
> becoming a reality, then that may simply be a self-fulfilling prophecy.
Just have a look how long it took to get back the old quickstarter (and
the responsible owner of the spec still thinks he was right apparently)
- just see the feedback of the incompatible change regarding line-breaks
justified paragraphs. Just take the crippled mail-merge.
But most important: Do a query for open RFEs. Pick 50 random issues. And
all 50 of these will have "reassigned to <bh/ft/requirements>" or "What
is going one with this issue" as last comment.
And the problem is the "participate". Currently, the only way to
participate is to move issues around (assign them to requirements
instead of bh) and take care of the technical quality of the issue.
But this doesn't help at all.
> Of course the very long release cycle we've been having is a large part
> of the problem and because of it most RFE submitted after the 2.0
> planning phase are still waiting in some queue.
Issues that were submitted before that planning phase, issues submitted
during the planning phase and issues submitted after the planning phase
are still waiting in the "queue" (you cannot call it queue sind this
would imply that there is some ongoing work on those).
The only issues that were worked on were those created by Sun. Or those
that happened to be covered by other issues.
> But that this is a
> problem is known and there is an ongoing discussion how this problem can
> be avoided - again for the time *after* 2.0.
What ongoing discussion? You mean this one?
> >Honestly saying, I don't really know, why I care about issues, that
> >could be resolved within minutes ..
>
> How do you know that? If you know, why don't you resolve them yourself?
He would resolve himself if he would get an answer on what approach he
should take.
> Do you have examples?
* Zoom in toolbar has been around for years with patch but ignored for
years. The current implementation of zoom in toolbar sucks compared to
the proposed solution.
* Fixed-width font in math's editing area (finally implemented after the
patch has been lying around for years)
* word-count - a macro has been around for years and still the
implementation lacks the features of that macro.
* render eps without preview by using external tools
* save images in documents using context-menu (and not having to unzip
the document) - patch lying around for years.
etc.
Last but not least the translation fixes that sometimes take years as
well.
> Do you consider that changing the user interface
> requires more than changing the code (e.g. specifications,
> documentation, translation).
But where's the problem with this? Rewriting the interface of a whole
application is OK whereas adding an item to a toolbar would be too much
trouble?
What really pisses me off is the line-break behaviour. Everything is
rejected/retargeted because "would alter the way old documents will be
rendered -> needs compatibility option" and not this one is changed
without an option to get the old behaviour.
> There certainly were problems with how some issues were handled.
There still are.
> But all
> participants occasionally make mistakes (e.g. some issues remain
> unhandled, because they have the wrong owner, component, status or
> target milestone.
.. or because they are flagged as Feature or Enhancement.
> If you see some systematic problem, then you should
> attempt to get the process improved. For RFEs the need to improve the
> process is known and has just been sleeping.
No, even if it would continue (which it acutaly does) - this doesn't
help with the problem. The issues are just thrown onto the pile of
issues. But nobody will have a look at that pile to reduce the issues in
there.
If handling the mass of issues doesn't work (and it doesn't) you really
should consider the review-proposal and voting system.
> [...]
ciao
Christian
--
NP: Hamlet - Mira hacia atr�s
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
