Was sind Ticket-Typen? Bearbeiten

Ticket-Typen dienen dazu, Vorgänge, Aufgaben und Änderungen im System möglichst klar zu unterscheiden, gezielt zuzuweisen und effizient zu steuern. Jeder Ticket-Typ beschreibt einen bestimmten Anwendungsfall und legt fest, welche Zusatzfelder und Auswahlmöglichkeiten bei der Ticketerstellung angeboten werden. So lässt sich der gesamte Lebenszyklus eines Tickets – von der Erstellung bis zur Abarbeitung – transparenter und komfortabler abbilden.

Der Hintergrund: Durch die klare Typisierung können Tickets bestimmten Personen, Teams oder Projekten zugeordnet und spezifische Automatisierungsregeln hinterlegt werden. Zusatzfelder (z. B. Dropdown-Auswahlen, Häkchen oder Datumsfelder) ermöglichen eine präzisere Steuerung und sorgen dafür, dass wichtige Informationen direkt erfasst werden – ohne dass alles mühsam als Freitext eingetragen werden muss. Das verbessert nicht nur den Komfort für alle Beteiligten, sondern auch die Übersicht und Nachvollziehbarkeit im System.

Technisch gesehen: es handelt sich bei den Ticket-Typen um sogenannte „Subtypen“ im Maniphest-Modul von Phorge. Lass dich von dieser Begrifflichkeit nicht verwirren – wir sprechen im Wiki der Einfachheit halber immer von „Ticket-Typen“. Hintergrund ist, dass Maniphest intern Aufgaben (Tasks) grundsätzlich als Typ T behandelt und darunter dann verschiedene Subtypen definiert werden können (z. B. Wartungsaufgabe, Konfigurationsänderung, Legal/Compliance usw.). Die gleiche Logik gilt für andere Bereichstypen wie Dateien F oder Journaleinträge J.

Hinweis zur Auswahl und Änderung von Ticket-Typen Bearbeiten

Die Auswahl des passenden Ticket-Typs ist entscheidend für die korrekte Bearbeitung und Nachverfolgung eines Vorgangs. Solltest du beim Anlegen eines Tickets unsicher sein, welcher Typ passt, kannst du dich an das Support-Team wenden oder zunächst einen passenden Typ auswählen und dies im Beschreibungstext vermerken.

Ticket-Typen sind im System nachträglich änderbar:

Wenn sich während der Bearbeitung herausstellt, dass ein anderer Typ besser passt (z. B. weil aus einer Standardaufgabe ein Feature-Request wird), kann der Typ problemlos gewechselt werden. Auch die spezifischen Felder passen sich dann automatisch an den neuen Typ an. Das Wechseln erfolgt über die Kommnentarfunktion, nicht über den Edit-Button in der Box rechts. → Siehe: Hilfe:Phorge/FAQ#Wie_ändere_ich_den_Ticket-Typ


Hinweis: Einige Ticket-Typen stehen nur bestimmten Benutzergruppen zur Verfügung. Wenn du einen Typ nicht auswählen kannst, liegt das an den hinterlegten Berechtigungen oder technischen Einschränkungen.

(Anmerkung: Technische Filter und weiterführende Übersichten sind in Planung, um die Verwaltung und Auffindbarkeit der Tickets weiter zu erleichtern.)

Ticket-Typen im Detail Bearbeiten

Bug Bearbeiten

Ein Bug ist ein Fehler oder ein unerwartetes Verhalten – egal, ob im Wiki, in anderen Tools oder Systemen, die wir betreiben. „Bug“-Tickets helfen dabei, Fehler systematisch zu dokumentieren, zu analysieren und (hoffentlich) zu beheben.

Typische Themen:

  • Unerwartete Fehlermeldungen
  • Funktionen, die nicht wie erwartet arbeiten
  • Plötzliche Systemabstürze oder „Hänger“
  • Reproduzierbare Fehler, die andere nachvollziehen können

Hinweis: Falls es zum gleichen Fehler schon ein Ticket gibt, ist das kein Problem – ergänze ruhig weitere Infos, falls sich die Ursache besser eingrenzen lässt. Tickets werden bei Bedarf zusammengeführt (gemerged).

Task (Aufgabe) Bearbeiten

Das „Task“-Ticket ist das Universal-Ticket für alle anfallenden Aufgaben – egal, aus welchem Themenbereich. Wenn du nicht sicher bist, welchen Typ du nutzen sollst: Im Zweifel immer ein „Task“-Ticket anlegen!

Typische Themen:

  • Allgemeine Aufgaben und To-dos (egal aus welchem Bereich)
  • Organisatorische Abläufe und Koordination
  • Aufgaben für Bot-Jobs (Sonderfall: Es gibt ein eigenes Feld „Bot-Task“ – bitte nutzen, falls es sich um einen Bot-Auftrag handelt. Auch Freigaben oder Anpassungen laufen über diesen Typ.)
  • Administration von Phorge selbst: Projekte beantragen, Zugang zu Projekten, Formularanpassungen und andere Phorge-interne Themen (werden automatisch dem Admin-Team zugewiesen)

Randnotiz: Bots schließen Tickets leider nicht automatisch – auch nicht, wenn sie Aufgaben erledigen. :)

Abuse Bearbeiten

Abuse-Tickets sind für alle Themen rund um Missbrauch, Fehlverhalten, Spam und den AbuseFilter zuständig. Das umfasst sowohl das Melden von aktuellen Spam- oder Missbrauchsfällen als auch alles rund um Filterverwaltung, Entsperrungen und Fehlverhalten bei Automatisierungen.

Typische Themen:

  • Abuse-Filter anlegen oder ändern
  • Abuse-Filter prüfen, debuggen oder anpassen (z. B. bei Fehlalarmen)
  • Whitelist-/Entsperr-Anträge (z. B. für Nutzer, IPs, Bereiche)
  • Blacklist-/Sperranträge (z. B. für IPs, Nutzer, Domains)
  • Spam- oder Missbrauchsmeldungen
  • Fehlverhalten oder Missbrauch durch Bots/Automationen
  • Meldung von Massenbearbeitungen oder automatisierten Angriffen
  • Sonstige Fälle rund um Filter, Missbrauch und Automatisierung

Auch wenn der Vorfall schon im Filter protokolliert ist oder ein Ticket schon existiert, kannst du weitere Hinweise hinzufügen – gerade bei Falsch-Positiven oder komplexen Fällen hilft zusätzliche Info immer weiter.

Security Bearbeiten

Security-Tickets dienen der Meldung von Sicherheitsproblemen oder Vorfällen mit besonderer Dringlichkeit. Hierzu zählen Schwachstellen, Account-Übernahmen, Datenschutzprobleme und alle anderen sicherheitsrelevanten Vorkommnisse.

Typische Themen:

  • Schwachstelle (Bug/Exploit)
  • Zugangs-/Authentifizierungsproblem
  • Rechte- oder Rollenkonflikte
  • Datenleck oder Privacy-Issue
  • Whistleblowing/sonstiges Fehlverhalten
  • Kompromittierte Accounts
  • Verdacht auf Backdoor, Bot oder Schadcode
  • Phishing-Versuche
  • Sonstiges, was sicherheitsrelevant sein könnte

Die Sicherheits-Kritikalität (wie dringend ist das Thema?) wird direkt im Ticket angegeben und kann von „sehr hoch“ (sofortige Reaktion) bis „nicht sicherheitsrelevant“ reichen. Die Priorität des Tickets wird auf Basis deiner Angaben automatisch festgelegt und kann nicht manuell geändert werden.

Dokumentationsaufgabe Bearbeiten

Ein Docs-Ticket wird erstellt, um eine strukturierte Dokumentationsaufgabe festzuhalten – meist als Hilfsticket zu einer Änderung, einem Projekt oder einem größeren Vorgang. Ziel ist es, sicherzustellen, dass wichtige Änderungen nicht nur umgesetzt, sondern auch nachvollziehbar dokumentiert werden: Im Code, im Repository, in der Konfiguration oder auf einer Hilfeseite.

Typische Themen:

  • Dokumentation von Änderungen an Konfigurationen, Systemen oder Schnittstellen
  • Nachziehen oder Erstellen von Hilfeseiten nach größeren Umstellungen
  • Festhalten von Doku-Bedarf für Entwickler oder Admins (z. B. technische Details, die nur mit Code-Einblick erklärbar sind)
  • Erinnerung an das Development-Team, dass bestimmte Vorgänge oder Prozesse dokumentiert werden müssen

Hinweis: Dieses Ticket ersetzt nicht das freie Anlegen von Hilfeseiten durch Benutzer! Es geht darum, dass *verbindliche* oder *strukturell wichtige* Dokus nicht untergehen und dauerhaft gepflegt werden.

Wartungsaufgabe Bearbeiten

Ein Wartungs-Ticket wird erstellt, um eine geplante oder regelmäßige technische Aufgabe festzuhalten, die für den stabilen Betrieb eines Systems notwendig ist. Ziel ist es, Wartungsarbeiten nachvollziehbar zu dokumentieren, Transparenz für alle Beteiligten zu schaffen und den Ablauf planbar zu gestalten.

Typische Themen:

  • Durchführung von Server- oder Betriebssystem-Updates
  • Pflege und Migration von Datenbanken
  • Erstellung und Wiederherstellung von Backups
  • Überwachung und Management von Logfiles
  • Anpassungen an der Infrastruktur (z. B. Umzüge, Hardwaretausch)
  • Routinewartungen (regelmäßige Checks, Reboots, Cleaning Tasks)
  • Wartung und Überprüfung von Skripten oder Automatisierungs-Bots
  • Geplante Neustarts oder Downtime-Ankündigungen

Hinweis: Wartungstickets sind kein Ersatz für Incident-Meldungen (Fehler) oder spontane Notfallaktionen! Sie sind ausschließlich für planbare, vorhersehbare Aufgaben gedacht – insbesondere dann, wenn sie dokumentations- oder abstimmungspflichtig sind. Bei Aufgaben mit potenzieller Downtime ist vorab zu prüfen, ob eine Wartungsankündigung erforderlich ist.

Legal/Compliance Bearbeiten

Ein Legal/Compliance-Ticket wird erstellt, um auf rechtliche oder compliance-relevante Themen aufmerksam zu machen und entsprechende Vorgänge nachvollziehbar zu dokumentieren. Dieser Typ kommt zum Einsatz, wenn mögliche Verstöße gegen geltende Gesetze, Lizenzbedingungen oder interne Richtlinien erkannt werden, aber auch bei Fragen zu notwendigen Nachweisen und Dokumenten.

Typische Themen:

  • Meldung eines (vermuteten) Copyright- oder Bilderrechtsverstoßes
  • Fehlende Urheber- oder Lizenznachweise bei Dateien oder Texten
  • Plagiatsverdacht oder Copy-Paste-Vorwürfe
  • Verwaltung und Pflege von Vertragsdokumenten, Impressum, Datenschutz, AGB & Co.
  • Sonstige Compliance- oder Rechtsfälle

Hinweis: Dieses Ticket dient nicht der Rechtsberatung, sondern ausschließlich der internen Nachverfolgung, Dokumentation und Bearbeitung von Compliance-Themen. Die Bearbeitung erfolgt ausschließlich durch die Betreiberin oder berechtigte Personen. Standard-Nutzer oder Admins bearbeiten diese Tickets in der Regel nicht. Die Nachvollziehbarkeit von Entscheidungen (z. B. bei Sperren, Reverts oder Löschungen) steht dabei im Vordergrund.

Konfigurationsänderung Bearbeiten

Ein Config-Ticket wird erstellt, wenn tiefgreifende Änderungen an zentralen Systemeinstellungen oder Berechtigungsstrukturen erforderlich sind. Dazu zählen insbesondere Anpassungen, die den Betrieb, die Sicherheit oder die Rechteverwaltung des Systems betreffen. Solche Änderungen dürfen ausschließlich durch autorisierte Mitglieder des Development-Teams vorgenommen und müssen lückenlos dokumentiert werden.

Typische Themen:

  • Anpassung von Rechten, Gruppen oder Benutzerrollen
  • Änderungen an der LocalSettings.php oder vergleichbaren Kernkonfigurationsdateien
  • Aktivierung, Deaktivierung oder grundlegende Anpassung von Extensions
  • Einführung, Änderung oder Entfernung von Namensräumen
  • Konfiguration von APIs, Integrationen oder sicherheitsrelevanten Schnittstellen
  • Festlegen oder Ändern von Standardwerten, die systemweit wirken


Hinweis: Dieses Ticket ist ausschließlich für tiefgreifende, freigabepflichtige Konfigurationsänderungen vorgesehen, die den sicheren und stabilen Betrieb betreffen. Die Bearbeitung erfolgt nur durch entsprechend berechtigte Personen aus dem Development-Team. Allgemeine Wartungs- oder Fehlerbehebungs-Tickets sind hier nicht gemeint.

Verlaufsentscheidung Bearbeiten

Ein Decision-Ticket wird erstellt, um grundlegende, richtungsweisende Entscheidungen außerhalb des Community-Bereichs transparent und nachvollziehbar zu dokumentieren. Gemeint sind vor allem Off-Wiki-Entscheidungen, die den technischen Betrieb, die Projektstrategie oder die Systemarchitektur betreffen und maßgeblich den weiteren Kurs des Projekts bestimmen.

Typische Themen:

  • Einführung, Änderung oder Ablehnung zentraler System- oder Betriebsfunktionen (z. B. Umgang mit temporären Konten, Aktivierung spezieller Erweiterungen)
  • Festlegung technischer, organisatorischer oder datenschutzrelevanter Grundsätze durch den Betreiber, das Tech-Team oder andere Entscheidungsträger
  • Dokumentation von Alternativen und abgewogenen Argumenten bei wegweisenden Projektentscheidungen
  • Nachvollziehbare Ableitung von Maßnahmen, die sich aus der Entscheidung ergeben (z. B. Anpassung von Rechten, Aktivierung neuer Funktionen)

Hinweis: Dieses Ticket ist ausdrücklich nicht für allgemeine Abstimmungen, Layoutfragen oder inhaltliche Diskussionen gedacht. Entscheidungsfindungen, die im Wiki oder in der Community getroffen werden, fallen nicht unter diesen Typ. Es geht ausschließlich um dokumentationspflichtige „Weichenstellungen“, die den strukturellen oder technischen Rahmen des Projekts betreffen und durch Betreiber, Tech-Team oder Redaktion beschlossen werden.