Hallo,
zu den Dingen, die die Welt braucht, gehoert sicherlich die Methode, wie
bestimmen wir die 10 wichtigsten Korrekturen fuer OpenOffice ?
ich würde die Zahl sicher nicht auf 10 begrenzen. Und da ich aus der
Emailadresse lese, daß Du zu Sun gehörst: Was verstehst Du unter "wir"?
Sun oder die Community?
Aktuell sehe ich nicht, daß die Community hier irgendeine
Entscheidungsgewalt darüber hat, was die Entwickler (die wohl in der
Mehrzahl von Sun bezahlt werden) machen bzw. wann sie es tun.
Und mir ist auch nicht ganz klar, inwieweit die Community QA, das
Vetorecht hat, eine Release abzulehnen, wenn sie der Meinung sein sollte,
daß die Qualität unzureichend ist.
Diese 10 issues zu bestimmen ist beliebig schwierig, da die Ermittlung
von der persönlichen Betrachtungweise, Kulturkreis, etc. abhaengt. Ein
Regelwerk, welches isssuew, deren votes, duplicates, prioritaeten und
deren type (DEFECT, RFE) auswertet, waere von erheblichen Nutzen und es
erliechtern, Entscheidungen wie diese zu rechtfertigen. Ein solches
allgemein anerkanntes Regelwerk waere ein sehr nuetzliches Hilfsmittel.
Ich denke, dass Anregungen hierzu auf Resonanz stossen werden.
Ich glaube nicht, daß Sun's legimite wirtschaftliche Interessen Geld mit
dem Verkauf des Produktes StarOffice zu verdienen, sich mit den Interessen
der Community in dieser Hinsicht decken.
Aus Sun's Sicht könnte es sich z.B. als Vorteil erweisen, mit dem
PDF-Import aus Marketingsicht ein Feature vorweisen zu können, welches die
Wettbewerber nicht haben und daraus einen Wettbewerbsvorteil zu ziehen,
der zu einem stärkeren Verkaufsergebnis führt, während die Community evtl.
eher an Bugfixing interessiert ist oder ein UI Verhalten beibehalten will.
Aber sei's drum. Aus meiner persönlichen Sicht würden Entscheidungen wie
folgt fallen:
1. Alle Bugfixes haben generell vor RFEs Vorrang.
Eine Ausnahme ist dann gegeben, wenn der Import / Export vom / zum
Wettbewerber ohne Durchführung eines RFEs nicht mehr möglich ist (z.B. der
Wettbeweber führt ein neues Dateiformat ein) oder das Produkt ohne
Anpassung nicht mehr lauffähig wäre (z.B. neue OS Version)
2. Crashes sind mit höchster Priorität zu fixen.
Es wird ohne Ausnahme erst dann released, wenn keine offenen Crash
Bugmeldungen mehr vorliegen.
3. Starke Forcierung des Vote Systems, weitere Bugmeldungen sind anhand
ihrer Votes und Duplicates zu priorisieren und zu bearbeiten
Bei Duplicate Statusänderung werden alle Votes des Duplicates auf den
Master-Report übertragen. Zusätzlich sollte evtl. die Wichtigkeit der
Meldung mit steigender Anzahl der Duplicates noch weiter erhöht werden.
Der Nutzer sollte in Summe (nicht pro Issue) weit mehr Votes abgeben
können, als jetzt möglich (aktuell gehen glaube ich nur 3 Votes mit 2
Stimmen oder so pro Thema) um alle seine persönliche Favoriten anzugeben.
4. Festlegung eines festen Prozentsatzes der Zeit für kurzfristig
korrigierbare (auch low-priority) Bugfixes (Korrektur voraussichtlich mit
weniger als x Minuten Aufwand bzw. mit weniger als y Lines of Code
möglich, z.B. bei Kleinkram wie Manualfehlern, Textfehlern in Menüs etc.
In dieser Zeit werden soviel Bugs wie möglich gefixed.
5. RFEs müssen der Community zur Abstimmung vorgelegt werden (z.B. um
unerwünschte UI Änderungen per Veto zu verhindern)
6. Über den Zeitpunkt von Releases und Ausnahmen von o.g. Regeln
entscheidet ein QA Gremium der Community, welches ermächtigt ist, bei
Bedarf Abstimmungen durchführen zu lassen.
(Mir ist natürlich klar, daß das so nie laufen wird, es ist nur meine
persönliche Wunschvorstellung).
Gruß
Guido
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
