hallo,
hätte ich Wünsche frei, dann wünschte ich, dass

-mails beginnen <Du hast recht, dies wäre die bessere Lösung> 
gefolgt von -falls vorhanden- Tipps, wie man mit OO das Problem 
-meist mühsamer- lösen kann. 
Beispiele, die m.M.n. nicht gut gelaufen sind (und Nutzer eher 
entmutigen statt das Produkt langfristig besser machen):
--Calc: Einfügen auf Mehrfachselektion ->das Mögliche ist zu 
programmieren und das Unmögliche melden, also schreib ein Request 
in IssueZilla!
--Calc: Auto-Füllgriff bei ganzen Zeilen oder Spalten ->das Bessere 
ist des Guten Feind, schreib ein Request in IssueZilla!
usw.

-die Diskussionen "Anforderungskatalog" in die richtige Bahn gelenkt 
wird; aus der Bitte, Testbeschreibungen (test case specs) zu machen 
wurde, etwas überspitzt gesagt, der Neustart des Projekts mit 
Sammeln der Anforderungen.
--SW-Qualitätssicherung beginnt beim Sammeln der Anforderungen und 
begleitet das Projekt bis zur Auswertung der Kundenmeinungen.
Qualität wird NICHT allein durch Testen erzeugt (doch bekommen die 
Tester am Ende des Prozesses am wenigsten Zeit und die meisten 
Prügel).
--Also sollte man beim jetzigen Stand des Projekts  die QS-Kette 
prüfen, ob der festgeschriebene Ablauf der QS funktioniert: Vor dem 
Schreiben neuer Anforderungen könnte/müsste man mal prüfen, ob sie 
schon gestellt sind und ob die erste Gruppe 
   'RFEs der QA'  http://qa.openoffice.org/issue_handling/index.html
in der Kette funktioniert, wie die Ergebnisse dem 'gewöhnlichen 
Nutzer' mitgeteilt werden und ob man u.U. schon für diese Truppe 
Verstärkung suchen soll/muss. Dann die nächste Stufe auditieren bis 
man auch bei der Testergruppe durch ist.
--oder mal schüchtern fragen, wer wann den letzten SW-Audit mit 
welchem Ergebnis durchgeführt hat und ob danach Abhilfe gemacht 
wurde. 

-die Diskussion DTB/Fliesstext still beendet wird. Bisschen salopp 
gesagt, hat bei TeX ein Programmierer, bei FrameMaker ein 
Schriftsetzer und bei m$ & Co halt ein Schreibmaschinen-Nutzer 
spezifiziert. Selbstverständlich kann man rationell und mit 
minimalem Lernaufwand "Fliesstext" in FrameMaker (als DTP- 
Vertreter) eingeben und braucht kein Wordpad dazu. Aus der 
Sicht eines SW-Entwicklers ist der Unterschied DTP/Fliesstext eher
minim, einige Grundelemente wie verkettbare Rahmen hat OOo ja schon.
Dies gilt für das Ziel: "mit OOo kann man (für alle Gestaltungs- 
Spielarten) ein fachgemässes Layout (ohne allzuviele 'Tips' zu 
benötigen) machen und mit dem Laserdrucker drucken". Also alles, 
was es für eine Mikro-Auflage eines Buchs braucht, sei vorhanden...
Layout hat mit Grafik und ein bisschen Kunst zu tun, viele Leute 
haben das Flair dazu (katastrophale Ausnahmen bestätigen :-) ).
  Die Druckvorstufe und Farbseparation ist ein anderes Ding, hier 
könnte man sich ein Zusatzmodul wünschen. Das ist ein anderes 
Handwerk, nicht jeder hat Zeit und Gelegenheit, sich auszubilden.

-Dachte, es bleibt bei drei Wünschen: 
Könnte/sollte man die Schreiber an die Liste ermuntern, 
Dreckfuhler :-) zu vermeiden bzw. die Rechtschreibprüfung zu 
nutzen? So würden Schnellleser nicht immer wieder abrupt gestoppt 
werden...

Grüsse
Wolfgang

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Antwort per Email an