bessere Gliederung der Component-Liste

[Stephan Richter]

Ich brauche meistens sehr lange eine passende Component zu finden, da sie in der Liste nicht gruppiert sind, z.B. statt

AV-Medien
Drucker
Fileserver
Hardware
Netzwerktechnik
Server(paedml)

würde ich vorschlagen:

Hardware: Arbeitsplätze
Hardware: AV-Medien
Hardware: Drucker
Hardware: Fileserver
Hardware: Server
Netzwerk: Switches
Netzwerk: WLAN

Entsprechend Kategorien für Software etc. .

Dann hätte man immer alle in Frage kommenden Kategorien im Blick.

[Rüdiger Kupper]

Gute Idee. Vielleicht können wir die Liste auch ein wenig ausmisten.

[lehm]

Das war meine Idee, bevor ich dieses Ticket gesehen habe. Mein Ziel war es, möglichst einfache Kategorien für's Kollegium zu finden. Die Unterscheidung zwischen Hard- und Software ist doch im Grunde egal, da die Tickets eh bei uns landen. Eine feinere Ausdifferenzierung ist bei unserer Personallage nicht wirklich sinnvoll, oder?

[Stephan Richter]

@lehm: Ich stimme dir voll zu, für das Kollegium wären wenige, klare Kategorien hilfreich - die meisten werden einen Unterschied zwischen WLAN und Netzwerk oder gar Switch nicht vornehmen.

Die Frage ist nur, ob wir für uns auch darauf verzichten, oder ob wir zur Sortierung trotzdem weiter unterteilen wollen? Zum Beispiel sortieren wir im Tablet Team immer nach AppleTVs, Lehrergeräte, Schülergeräte - einfach um den Überblick zu behalten... . Das könnte man zwar über Milestones machen, wäre dann aber nicht im Sinne des Erfinders.

[Stephan Richter]

Was wäre denn für das Kollegium sinnvoll? Bitte ergänzen!

Hausmeister
Klassenraum-Technik
Lehrerzimmer-Technik
Netzwerk
Sonstiges
Tablets

[lehm]

Ich stimme dir zu Stephan, für viele Bereiche ist ein feine Untergliederung total sinnvoll. Gerne könne wir die Tablet-Technik in feinere Kategorien einteilen! Die Kategorien sollten halt selbsterklärende Namen tragen.

Ich finde deine Idee mit der Gruppierung innerhalb der Liste super! Wie wäre es denn mit einer Art Präfix:

Problem melden: Hausmeister
Problem melden: Klassenraum-Technik
Problem melden: Lehrerzimmer-Technik
Problem melden: PC-Raum-Technik
Problem melden: Netzwerk & WLAN
Problem melden: Tablets
Problem melden: Apple-TV
Problem melden: Sonstiges

[lehm]

PS:

Mit

"Die Kategorien sollten halt selbsterklärende Namen tragen."

meinte ich die Kategorien für die Kollegen, nicht eure/unsere internen.

[Rüdiger Kupper]

Replying to lehm:

Die Unterscheidung zwischen Hard- und Software ist doch im Grunde egal, da die Tickets eh bei uns landen.

"bei uns" sind aber Verschiedene und es ist wünschenswert, dass die Tickets ohne weiter Maßnahme direkt den Richtigen erreichen. Bei den stationären Rechnern unterscheidet Software und Harware z.B. zwischen Kupper und Baumgärter und dem Rest des Teams. Die Software mache nunmal nur ich. Ich stimme völlig zu, dass das für die Kollegen weniger relevant ist, für uns aber sehr.

[Rüdiger Kupper]

Generell gute Idee, doch „Problem Melden“ ist keine Komponente. Was Du vorschlägst wäre eher ein neuer Tickettyp „Problemmeldung“ in Kombination mit den bekanten Komponenten. Doch bringt ein solcher neuer Tickettyp etwas? Scheint mir keine Verbesserung gegenüber dem normalen Ticket zu bringen.

Ticket-Typen (= Vorgänge) und Zuständigkeiten (= Komponenten) sollten schon voneinander getrennt bleiben, andernfalls verschwenden wir eine der besten Eigenschaften von Trac, nämlich, genau zwischen diesen beiden orthogonalen Dimensionen eines Problems zu unterscheiden.

Replying to lehm:

Ich stimme dir zu Stephan, für viele Bereiche ist ein feine Untergliederung total sinnvoll. Gerne könne wir die Tablet-Technik in feinere Kategorien einteilen! Die Kategorien sollten halt selbsterklärende Namen tragen.

Ich finde deine Idee mit der Gruppierung innerhalb der Liste super! Wie wäre es denn mit einer Art Präfix:

Problem melden: Hausmeister
Problem melden: Klassenraum-Technik
Problem melden: Lehrerzimmer-Technik
Problem melden: PC-Raum-Technik
Problem melden: Netzwerk & WLAN
Problem melden: Tablets
Problem melden: Apple-TV
Problem melden: Sonstiges

[Rüdiger Kupper]

Eine feinere Untergliederung der Komponenten sehe ich eher kritisch – wir haben bereits viel zu viele Komponenten. Eine typische Falle in der Problem-Triage ist, zu viele Fälle zu unterscheiden. Die klassiche Triage (daher kommt der Name und das Konzept stammt aus den Weltkriegen) unterscheidet daher nur zwischen drei Wichtiggeitsstufen – wir haben in unserem Trac bereits vier. Dazu noch vier Dinglichkeitsstufen. Das spannt einen Raum auf, den wir mit unseren Ressourcen eigentlich gar nicht mehr verwalten können.
Ich würde eher dafür plädieren, die Zahl der Dringlichkeitsstufen, Wichtigkeitsstufen und vor allem die Zahl der Komponenten zu reduzieren, und diese stattdessen besser auf unsere Teammitglieder zu verteilen.

[Rüdiger Kupper]

Replying to rich:

@lehm: Ich stimme dir voll zu, für das Kollegium wären wenige, klare Kategorien hilfreich - die meisten werden einen Unterschied zwischen WLAN und Netzwerk oder gar Switch nicht vornehmen.

Die Komponenten dienen in erste Linie uns.

[Rüdiger Kupper]

Replying to rich:

@lehm: Ich stimme dir voll zu, für das Kollegium wären wenige, klare Kategorien hilfreich - die meisten werden einen Unterschied zwischen WLAN und Netzwerk […] vornehmen.

"WLAN" und "Netzwerk" sind auch wirklich keine getrennten Komponenten, sonder eine Hierarchie. Verbesserungsvorschlag:

1. stationäres Netzwerk
2. mobiles Netzwerk

oder mit Präfixen:

1. Netzwerk: stationär
2. Netzwerk: mobil

Um es den Kollegen noch leicher zu machen, könnte man "stationär" noch durch "Kabel" und "mobil" durch "Funk" ersetzen. Dann kann es wirklich niemand mehr verwechseln. Oder?

[lehm]

Ja, stimmt.

Mir ist halt aufgefallen, dass ich bei einigen die Klassenraumtechnik betreffende Tickets keine Benachrichtigung per Mail bekomme. Entweder weil eine "falsche" Komponente ausgewählt oder als Owner bau eingetragen wurde. Diese Tickets gehen zum Teil unter.

Im Grunde reicht doch ein einziger Eintrag für die Kollegen: Problem melden

Die Zuteilung kann dann ich vornehmen: Hardware/Beamer lehm, Software kup, AppleTV Tablet-Team usw.

[Rüdiger Kupper]

Die Komponenten dienen in erste Linie uns.

So war jedenfalls damals meine Idee. Ich glaube, wir müssen erst mal überlegen, ob die Komponenten eher für die Kollegen aussagekräftig sein sollen oder eher möglichst gut uns bei der Verteilung helfen soll. Das schöne ist halt, dass trac einem die Arbeit abnehmen kann, weil jede Komponente einen "Hauptzuständigen" hat, so dass Du das eigentlich nichgt von Hand machen müsstest.

[Stephan Richter]

Ich wäre dafür, die Komponenten für uns zu strukturieren, nicht für die Kollegen. Trotzdem sollten wir sie etwas entschlacken.
Der default Eintrag ist zur Zeit "sonstiges". Vielleicht kann man den in "ich weiß nicht" umbenennen. Diese Tickets bekommt dann @lehm zum zuordnen.
Wenn ein Kollege gleich zuordnen will, dann kann er das dann trotzdem sinnvoll machen.

[Rüdiger Kupper]

Ich habe nun einfach mal die Komponenten mit Präfixen versehen, so wie Stephan vorgeschlagen hat, im Wissen, dass wir wohl keine allgemeingültige Methode zur Kategorisierung finden werden. Pragmatisches Ziel ist, dass man beim Erstellen der Tickets die richtige Komponente einfach schneller findet.

Schaut Euch die Liste mal an und macht Verbesserungsvorschläge!

[Stephan Richter]

Super, vielen Dank!

Leider hat das zur Folge, dass man nach den alten Tickets (z.B: Component "Tablets") nicht mehr suchen kann :-/. Wir hatten da Custom Queries für uns angelegt.... .

Kann man irgendwie per batch-Prozess von allen alten Tickets die Component ändern?

[bau]

Das müsste eigentlich in der MySQL-Datenbank gehen.
Ich bräuchte eine Liste, der Art:

[Alte Bezeichnung 1] [Neue Bezeichnung 1]
[Alte Bezeichnung 2] [Neue Bezeichnung 2]
...

[Rüdiger Kupper]

Replying to rich:

Super, vielen Dank!

Leider hat das zur Folge, dass man nach den alten Tickets (z.B: Component "Tablets") nicht mehr suchen kann :-/.

Die Tickets, die zuvor die Component "Tablets" hatten, haben jetzt "Hardware: Tablets". Wenn ihr danach sucht, müsst ihr alle Tickets finden.

Wir hatten da Custom Queries für uns angelegt.... .

Dann müsst ihr vermutlich nur die Custim Queries anpassen.

Kann man irgendwie per batch-Prozess von allen alten Tickets die Component ändern?

Ist m.E. nicht nötig. Ich nehme an, Trac speichert intern nur eine ID für die Component, nicht den String. Die Component-ID hat sich durch das Umbenennen nicht geändert.

[Rüdiger Kupper]

Per Link:
https://paedml.kg-fds.de/trac/query?status=!closed&component=Hardware%3A+Tablets

Oder per Makro:
[[TicketQuery(status!=closed,component=Hardware: Tablets)]]

#3737

Drucken direkt von Lehrergeräten

#5551

Apple Intelligence - Einschränkungen auf Koffer- und Leihgeräten definieren

#5719

iPads 10er aufsetzen

#5810

Apple-TV R 5.29

[Stephan Richter]

Ah, okay. Da hatte ich einen Fehlschluss: Die alte Component war nicht mehr wählbar. Dass die Components nur per id verknüpft sind, war mir nich klar. (zumal sich ja die Anzahl der Komponenten auch evtl. verändert hat).

[Rüdiger Kupper]

Ja, das stimmt, hätte ich die Component gelöscht und eine neue angelegt, dann hätten wir genau das Problem. Ich habe aber nur die Beschreibung der bestehenden Components geändert.

[Rüdiger Kupper]

Replying to rich:

Dass die Components nur per id verknüpft sind, war mir nich klar.

Trac ist ja auch eine dieser datenbankbasierten Webanwendungen. Es wäre Verschwendung, den kompletten String mit jedem Ticket zu speichern. Stattdessen wird eine Zahl gespeichert und der dann in einer zweiten Tabelle die Beschreibung zugeordnet.

[lehm]

Gefällt mir gut!