Hallo Mathias, Thorsten, *,
Mathias Bauer schrieb:
Thorsten Ziehm wrote:
Hi Christian,
[...]
Auch die Arbeit mit dem Issue-Tracker, in dem ja eigentlich alles
zusammenläuft wird direkt mit dem QA-Team und den als erstes zuständigen
Leuten in Verbindung gebracht. Hier gilt es, auch mal gesammelt die
„Karteileichen“ [...]
Die Berge unbearbeiteter RFEs?
Gerade hier wird es schwierig werden, welches Projekt sich dieser
Aufgabe annehmen wird. Seit kurzem gibt es das User Experience Projekt
[1][2] auf OOo. Ich gehe davon aus, dass sich dieses Projekt dieser
heroischen Aufgabe annehmen wird und muss.
Das würde IMHO die Aufgabe dieses Teams in eine völlig falsche Richtung
lenken. Wir haben schon in den letzten Jahren von unserem eigenen
UX-Team gelernt, dass das nicht der rechte Platz ist. Insbesondere ist
hinderlich, dass viele Issues ohne den technischen Background, die
Einschätzung der Resourcen-Lage etc. nur geparkt werden. Das kann es
nicht sein.
Ich teile diese Einschätzung. Wie schon erwähnt, halte ich es für
sinnvoll, die verschiedenen Bereiche nicht isoliert zu betrachten.
Insofern wäre es mE der richtige Weg, wenn sich ux, qa und die
Modulprojekte gemeinsam darum kümmern. Und das in einer geeigneten
Reihenfolge bzw. Zusammensetzung.
Die Auswahl, was man demnächst angehen möchte, sollte aus den Projekten
kommen. Das sieht auch der Project Lead des UX-Projekts nicht anders
(wir hatten heute zufällig(?) gerade ein Gespräch darüber). Das heißt
nicht, dass UX sich da raushält, es heißt nur, dass das systematische
Vorgehen ein Interesse und daher am besten auch eine Aufgabe der
jeweiligen Projekte ist. UX wird dann sicherlich bei der Umsetzung
der Aufgaben eine wichtige Rolle spielen. Sie sollten aber nicht die
Roadmap machen.
Halte ich auch für sinnvoll. Es lässt sich aus dem Issue Tracker sicher
ablesen, welche Themen am dringensten sind (Votes, Duplicates). Aber
eher die Projekte haben den Überblick, in welchen Themenbereichen der
größte Handlungsbedarf ist und können gleichzeitig eine Einschätzung
vornehmen, wie aufwändig die Umsetzung wäre. Ein einzelner Issue mit 50
Votes oder Duplicates muss gegen eine "Issue-Gruppe" zum Thema
"Kapitelnummerierung" oder "Serienbriefe" sehr genau abgewägt werden
(das waren willkürlich gewählte Beispiele :-) ). UX sehe ich besonders
dann als gefragt, wenn es darum geht, *wie* eine Funktion umgesetzt
werden soll. Die Entscheidung *was* umgesetzt wird, sollte mE schon
vorher bei den Experten des entsprechenden Bereichs fallen.
Ich habe damit auch schon für den Writer angefangen, indem ich die
Sichtung aller Issues mit mehr als 30 Votes mir als Ziel für 2.3 gesetzt
habe (die Sichtung - nicht das Bearbeiten ;-)). Die Zahl ist dabei
willkürlich und orientiert sich nur an der Machbarkeit. Schön wäre es,
wenn man dabei themenorientiert auch an der Konsolidierung der Issues
arbeiten könnte, also das, was Jacqueline wohl mit "Karteileihen"
bezeichnet hat, auszufiltern.
Das Stichwort "themenorientiert" finde ich in diesem Zusammenhang sehr
wichtig. Ich denke, anders würde es bei der Komplexität des Programms
auch gar nicht mehr gehen (s.o.). Insofern ist das genau dieses
strukturierte Vorgehen, das ich mir wünsche, um in einem Arbeitsschritt
auch mal die "weniger wichtigen" Issues mit anzugehen.
Und um das nochmal loszuwerden: Ich finde es sehr gut, dass die
Community frühzeitig über geplante Änderungen informiert wird und damit
die Möglichkeit zu Kommentaren hat. Und dass diese Kommentare dann auch
wirklich ernsthaft in die Überlegungen einbezogen werden, ist für mich
einer der wichtigen Gründe, warum ich gerne an solchen Sachen mitarbeite.
Ciao,
Mathias
Gruß,
Jacqueline
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
