Moin,
Guido Ostkamp wrote:
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.
Ich wuerde gerne erreichen, dass wir ein gemeinsames Bild von den
"wichtigen" issues erhalten. Das war in der Vergangenheit nicht immer
der Fall was dazu gefuehrt hat, dass diejenigen, die die Hand am code
hatten, ihr Bild umgesetzt haben. Das fuehrt nicht in jedem Fall zu
optimalen Ergebnissen und das sollten wir änderen. Der Begriff mit der
"Entscheidungsgewalt" ist mir zu mächtig, es sollte an einer gemeinsamer
Zielrichtung gearbeitet werden, so dass Konsenz ueber ein gemeinsames
Vorankommen besteht, jemanden anderen eine Richtung "gewaltmaessig"
vorzugeben, wird in einem freien Projekt auf Dauer nicht erfolgreich sein.
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.
Das OOo QA Projekt arbeitet mittlerweise aktiv an der Freigabe der
Releasecandidates mit und hat die Moeglichkeit, Einwaende aufzuwerfen
(s. http://wiki.services.openoffice.org/wiki/ReleaseStatus_Minutes ).
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.
Du wirst immer jemanden suchen muessen, der die Motivation fuer einen
Bugfix mitbringt, ich denke aber, dass die kommerziellen Kontributoren
Resourcen in wichtige Bugfixes zu investieren um das Produkt insgesamt
erfolgreich zu machen.
Schwieriger wird es halt, die Wichtigkeit eines issues einzuschaetzen,
allein die Prioritaet des issues reicht dazu nicht aus, folgene Aspekte
gilt es zu klären:
* gibt es einen Workaround ?
* wieviele Szenarien sind von dem issue betroffen ?
* wieviele Anwender sind betroffen ?
* ist es eine regression ?
usw.
bei der Entscheidung, Resourcen in den issue zu stecken, muss natuerlich
auch beleuchtet werden:
* wie gross ist der Aufwand fuer einen Fix ?
* habe ich Leute, die sich mit dem entsprechenden code auskennen,
ueberhaupt zur Verfuegung ?
etc.
Bei der Beurteilung eines issues ist das Umfeld oft schwer zu
beurteilen, ist der issue von einem erfahrenen consultant geschrieben
worden, der sein "wichtigstes" Problem aus x OpenOffice.org Schulungen
bzw. kommerziellen Einsatz bereits gefiltert und bewertet hat oder was
es Lieschen Mueller, die ein Einzelfall problem beschreibt. Votes helfen
hier nur bedingt weiter.
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.
hmmm, eine ketzerische Frage sei erlaubt: Ist die OOo Community
repraesentativ fuer die Anwender von OpenOffice.org ? Ich will damit
sagen, dass die von Dir erwaehnte " persönlichen Betrachtungweise,
Kulturkreis, etc" immer eine grosse Rolle spielt und zu verschiedenen
Sichtweisen führt.
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)
ich wuerde hier "alle" und "generell" streichen wollen. Wir werden immer
Bugs haben die wir nicht fixen werden, da die Randbedingungen, unter der
dieser auftritt, viel zu selten ist (oder gar ein Einzelfall) und/oder
der Aufwand fuer einen fix unangemessen hoch ist. Erweiterungen des
Produktes sollten gemacht werden, so dass es wettbewerbsfaehig bleibt.
Generell stimme ich Dir zu, dass neue Features erst dann angegangen
werden sollten, wenn die existierenden vernuenftig funktionieren (das
kann man aber auch nicht als eine "muss" Regel einführen, da zu viele
Entwickler am Gesamtprojekt arbeiten, so dass man diese Regel hoechsten
auf Einzelentwickler oder kleine Teams anwenden sollte (Du faengst bitte
erst ein neues feature an, wenn du alle wichtigen issues in deinen alten
features gefixt hast))
2. Crashes sind mit höchster Priorität zu fixen.
s/hoechster/hoher , siehe Argumentation oben.
Es wird ohne Ausnahme erst dann released, wenn keine offenen Crash
Bugmeldungen mehr vorliegen.
dann werden wir nie wieder was releasen :-) Im Ernst, wenn jemand einen
reproduzierenden crash hat, sollte das dem release status meeting
bekannt gemacht werden, wenn dieses kein exotischer Einzelfall ist,
sollte das bereits gaengige Praxis sein.
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.
ja, gerne.
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.
Das kann fuer jedes Projekt individuell eingestellt werden, i.d.R 5
votes und max 2 votes pro issue. Ich bin hier fuer konstruktive
Vorschlaege fuer aenderungen offen, das sollte in qa projekt mal
diskutiert werden.
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.
Wenn es Mengen an solchen einfachen Fixes gibt, sollten wir hierfuer
neue contributoren werben, dass scheint mir dann ein prima Einstieg zu
sein. Ein Gesamtaufwand von lediglich weniger Minuten scheint mir ein
Ausnahmefall zu sein und eher ein Abfallprodukt beim review oder aendern
von code zu sein.
5. RFEs müssen der Community zur Abstimmung vorgelegt werden (z.B. um
unerwünschte UI Änderungen per Veto zu verhindern)
specs werden auf spec.announce angekuendigt. review und Kommentare sind
ausdruecklich erwuenscht, eine groessere Beteiligung ist sicher
wuenschenswert.Du weisst vermutlich schon dass ich mit Begriffen wie
Entscheidungsgewalt und Vetorecht meine Probleme habe ;).
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.
siehe Release Status meeting.
(Mir ist natürlich klar, daß das so nie laufen wird, es ist nur meine
persönliche Wunschvorstellung).
Gruß
Guido
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
