Hi Bert,
thank you for the examples, they really help clarifying things.
regarding the non linguistic bugs. Let's leave them in the spreadsheet
for the moment. We may need to convert them into single issues depending
who is going to fix what ... but that is definitively something that we
will need to evaluate in a second step.
as for where to begin, I think that there was a bit of misunderstanding
about what you meant by major issues, etc. However, the summary is that
Santiago and Nicole do definitively agree to start with Calc, that is to
say to implement all corrections which are reported in spreadsheets
referring to the Calc module....
After this first *big* step, I like Santiago's idea saying:
I think that with
the experience we get from Calc we´ll be able to suggest alternative
approaches to other modules, as well as be able to measure better the time
needed and the difficulty, learn how to flag issues that are incorrect in
the report, or unacceptable, or that cannot be changed by Alpha, etc, etc.
Bert, Santiago and all,
I think that we have clarified most of the thing and that we can
definitively start :-) .
One more thing regarding communication and process overview. I found and
still find that the web page at
http://nl.openoffice.org/t9n_nl2_en.html is serving this purpose very
well. Do you think it would help adding some information on this review
project?
Rafaella
Bert Meersma wrote On 02/14/06 18:01,:
Hi Rafaella,
Rafaella Braconi wrote:
Hi Bert and All,
let me clarify a couple of things:
- the possible refers to actions which need to be taken by us SUN -
preparation of files, etc....
ok, clear.
- regarding the strings to delete, yes if you have a couple of
examples it would really help.
They're not specifically about the deletion of strings, but they are
regarding changes in the help content itself.
First example:
http://www.openoffice.org/issues/show_bug.cgi?id=59867
This issue is about customizing toolbars. The helpcontent mentioned
describes the procedures for OOo1.x.x. At first, this issue was set to
invalid. After some discussion about it, it was reopened and it was
decided to delete the specific page. Of course that's a solution, but
I think there's no guide to customizing toolbars left now....
Second example:
http://www.openoffice.org/issues/show_bug.cgi?id=60967
This one is about accelerator keys. When the very first version of
OOo2.0 was released, the accelerator keys were kind of messy. Leo
Moons has put in a lot of effort to correct this and as thanks this
issue was set invalid. Again, after some discussion we managed to have
it reopened again.
Third example:
http://www.openoffice.org/issues/show_bug.cgi?id=59307
This issue is about add-in functions in Calc. The text in the OLH
simply doesn't match the GUI. This issue wasn't set as invalid, but
the target was set to OOoLater, what basically means the same as invalid.
- regarding the non linguistic bugs .... yes filing bugs it's the
process.... however, what I was referring to is: who is going to
write bugs for all non linguistic things? My suggestion would be
after Alpha implements all linguistic corrections in the files and
highlights the non-language bugs, they re-submit the spreadsheet. It
will be you then to write single bugs for all those instances.... Any
other idea?
Yes, I do have another idea. Instead of creating single issues it
would be better to simply attach the spreadsheet to a single issue.
The rest of the plan I can live with.
Regarding the time frame ... I was hoping it, too .... however, such
a re-work can only happen in quite periods like between 2 releases
.... this is why I was realistically targeting 2.03.
I think 2.03 is indeed the realistic option at this time.
Getting a new set of help files with all the frequently found errors
corrected would seriously improve review speed.
Yes, I definitively agree and if you prefer, instead of starting with
the Calc module Alpha could start fixing major problems throughout
the Help files. However, it would definitively help if we could get
from you a spreadsheet with the major issues you are referring to.
May be we could limit them to 20 major issues? As it is now, without
such a list , Alpha would need to go through the spreadsheet an filer
out the major issues which is definitively time consuming. I think
that it is really important that Alpha uses their resources to
implement the corrections... and in order to make it possible for us
to see them in a build we need to make it as smooth as possible.
Why "*instead *of starting with the Calc module"? Wouldn't the logical
thing to be to do it both? In fact, Natalie has already finished
another file that contains almost all StarBasic files. I would be in
favour of having those corrected as well.
Regarding the preparation of list with major issues: Alpha has to go
through the entire sheets already. I'm not sure about Alpha's working
method, but would it really be a problem to fix a major bug every time
they encounter one?
Regards,
Bert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
