{"id":807,"date":"2026-07-30T12:21:34","date_gmt":"2026-07-30T12:21:34","guid":{"rendered":"https:\/\/matforge.org\/?p=807","raw":"https:\/\/matforge.org\/?p=807"},"modified":"2026-07-30T12:21:34","modified_gmt":"2026-07-30T12:21:34","slug":"feature-requests-vs-bug-reports-knowing-the-difference","status":"publish","type":"post","link":"https:\/\/matforge.org\/de\/feature-requests-vs-bug-reports-knowing-the-difference\/","title":{"rendered":"Feature Requests vs. Bug Reports: Den Unterschied kennen","raw":"Feature Requests vs. Bug Reports: Den Unterschied kennen"},"content":{"rendered":"<span class=\"span-reading-time rt-reading-time\" style=\"display: block;\"><span class=\"rt-label rt-prefix\">Reading Time: <\/span> <span class=\"rt-time\"> 6<\/span> <span class=\"rt-label rt-postfix\">minutes<\/span><\/span><p>In der wissenschaftlichen und Engineering-Software kommt die gr\u00f6\u00dfte Frustration nicht von schwierigen Problemen &#8211; es kommt von unklaren Problemaussagen. Ein Ticket, das \u201efalsch klingt\u201c, k\u00f6nnte tats\u00e4chlich eine fehlende F\u00e4higkeit beschreiben. Eine Anfrage nach einer \u201ekleinen Verbesserung\u201c k\u00f6nnte darin bestehen, einen Defekt zu maskieren, der die Ergebnisse besch\u00e4digt. Wenn Teams Tickets falsch klassifizieren, verschwenden sie Zeit: Entwickler untersuchen Phantomfehler, Forscher warten auf Features, die nie im Ziel waren, und Priorit\u00e4ten driften.<\/p>\n<p>Dieser Leitfaden hilft Ihnen dabei, schnell zu entscheiden, ob es sich um einen Fehlerbericht oder eine Feature-Anfrage handelt, und zeigt, wie Sie jeden einzelnen schreiben, damit das Team darauf reagieren kann. Das Ziel ist einfach: weniger Hin- und Her-Kommentare, schnellere Triage und weniger \u00dcberraschungen bei Ver\u00f6ffentlichungen.<\/p>\n<h2>Warum die Unterscheidung wichtig ist<\/h2>\n<p>Fehlerberichte und Funktionsanforderungen werden in den meisten Workflows (TRAC, JIRA, GitHub Issues, Redmine usw.) unterschiedlich behandelt. Sie haben unterschiedliche Dringlichkeit, unterschiedliche Akzeptanzkriterien und verschiedene M\u00f6glichkeiten, die Schleife zu testen und zu schlie\u00dfen.<\/p>\n<ul>\n<li>Ein Fehlerbericht hat normalerweise die Erwartung der Richtigkeit: Die Software verst\u00f6\u00dft gegen ihren eigenen Vertrag, ihre Dokumentation oder ihr etabliertes Verhalten.<\/li>\n<li>Eine Feature-Anfrage fragt nach neuem Verhalten: etwas, was die Software derzeit nicht verspricht, auch wenn es n\u00fctzlich w\u00e4re.<\/li>\n<\/ul>\n<p>Wenn Sie das Ticket richtig beschriften, wird die Triage einfacher: Betreuer k\u00f6nnen reproduzieren, priorisieren und Arbeiten zuweisen, ohne zu erraten, was \u201esoll\u201c passieren sollte.<\/p>\n<h2>Die Kerndefinitionen<\/h2>\n<h3>Was ist ein Fehlerbericht?<\/h3>\n<p>Ein Fehler ist, wenn sich das System im Vergleich zu einem vereinbarten Referenzpunkt falsch verh\u00e4lt. Dieser Bezugspunkt kann sein:<\/p>\n<ul>\n<li>Dokumentation oder eine ver\u00f6ffentlichte Schnittstelle (API-Vertrag)<\/li>\n<li>Vorheriges stabiles Verhalten (eine Regression)<\/li>\n<li>Wissenschaftliche Korrektheit (z. B. Erhaltungsgesetze, erwartete Invarianten, Einheitskonsistenz)<\/li>\n<li>klar angegebene Anforderungen (einschlie\u00dflich Tests oder Spezifikationen)<\/li>\n<\/ul>\n<p>Kurz gesagt: Ein Fehlerbericht beschreibt einen Fehler, der behoben werden sollte, um die Korrektheit wiederherzustellen.<\/p>\n<h3>Was ist eine Funktionsanfrage?<\/h3>\n<p>Eine Feature-Anforderung schl\u00e4gt eine F\u00e4higkeit oder Verbesserung vor, die das System n\u00fctzlicher, flexibler oder effizienter machen w\u00fcrde, aber nicht f\u00fcr die Richtigkeit des aktuellen Verhaltens erforderlich ist. Beispiele sind:<\/p>\n<ul>\n<li>Unterst\u00fctzt einen neuen Randbedingungstyp<\/li>\n<li>Hinzuf\u00fcgen eines Exporters f\u00fcr ein neues Dateiformat<\/li>\n<li>Die Leistung \u00fcber die aktuellen Ziele hinaus verbessern<\/li>\n<li>Hinzuf\u00fcgen von UI\/CLI-Optionen, die noch nicht vorhanden sind<\/li>\n<\/ul>\n<p>Kurz gesagt: Eine Funktionsanforderung beschreibt etwas Neues, das das System tun sollte.<\/p>\n<h2>Schnelle Entscheidungs-Checkliste<\/h2>\n<p>Wenn Sie sich nur an eine Regel erinnern, verwenden Sie diese:<\/p>\n<ul>\n<li>Wenn die Software ein Versprechen bricht, ist es ein Fehler.<\/li>\n<li>Wenn Sie ein neues Versprechen w\u00fcnschen, ist es eine Funktion.<\/li>\n<\/ul>\n<p>Stellen Sie sich diese Fragen:<\/p>\n<ol>\n<li>Hat es jemals zuvor im selben Szenario funktioniert? Wenn ja, wahrscheinlich ein Fehler (m\u00f6glicherweise eine Regression).<\/li>\n<li>Gibt es eine Dokumentation, die besagt, dass das Verhalten funktionieren sollte? Wenn ja, Bug.<\/li>\n<li>Ist das Verhalten mehrdeutig und Sie schlagen vor, was es sein sollte? wahrscheinlich ein Feature (oder zuerst eine Spezifikationskl\u00e4rung).<\/li>\n<li>Ist das Problem, dass Sie \u00fcberhaupt nichts tun k\u00f6nnen, aber nichts ist mit vorhandenen Ausgaben \u201efalsch\u201c? wahrscheinlich eine Funktion.<\/li>\n<li>Erzeugt es falsche Ergebnisse, Abst\u00fcrze, besch\u00e4digte Daten oder verst\u00f6\u00dft gegen physische Einschr\u00e4nkungen? K\u00e4fer<\/li>\n<\/ol>\n<h2>Side-by-Side-Vergleich<\/h2>\n<table class=\"custom-table\">\n<tbody>\n<tr>\n<th>Aspekt<\/th>\n<th>Fehlerbericht<\/th>\n<th>Feature-Anfrage<\/th>\n<\/tr>\n<tr>\n<td>Bedeutung<\/td>\n<td>Im Vergleich zum erwarteten Verhalten stimmt etwas nicht<\/td>\n<td>etwas Neues oder Verbessertes ist erw\u00fcnscht<\/td>\n<\/tr>\n<tr>\n<td>Bezugspunkt<\/td>\n<td>Dokumente, Tests, Vorversionen, Korrektheitskriterien<\/td>\n<td>Benutzerbed\u00fcrfnisse, Forschungsziele, Verbesserungen der Benutzerfreundlichkeit<\/td>\n<\/tr>\n<tr>\n<td>Typische Beweise<\/td>\n<td>Reproduktionsschritte, Protokolle, falsche Ausgabe, Crash-Trace<\/td>\n<td>Anwendungsfall, Nutzen, vorgeschlagenes Verhalten, Akzeptanzkriterien<\/td>\n<\/tr>\n<tr>\n<td>Priorit\u00e4tstreiber<\/td>\n<td>Schweregrad, Umfang, H\u00e4ufigkeit, Ergebnisrisiko<\/td>\n<td>Auswirkungen, Nachfrage, strategische Roadmap, Aufwand<\/td>\n<\/tr>\n<tr>\n<td>Wie es &#8222;auf&#8220; ist<\/td>\n<td>verifizierter Fix; Testdurchl\u00e4ufe; Regression verhindert<\/td>\n<td>implementierte Spezifikation; dokumentiert; End-to-End nutzbar<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>Beispiele im wissenschaftlichen Rechnen<\/h2>\n<h3>Beispiel 1: Falsche Ergebnisse aufgrund von Unstimmigkeiten der Einheiten<\/h3>\n<p>Sie f\u00fchren eine Simulation durch und bemerken, dass ein als \u201eMeter\u201c dokumentierter Parameter als \u201eMillimetern\u201c behandelt wird und die Ergebnisse um das 1000\u00d7 verschiebt. Wenn Dokumentation und Code nicht \u00fcbereinstimmen und die Ausgaben f\u00fcr die dokumentierte Verwendung falsch sind, ist dies ein Fehlerbericht. Ihr Ticket sollte den Parameter enthalten, in dem es dokumentiert ist, ein minimaler Fall und ein Hinweis auf eine Nicht\u00fcbereinstimmung.<\/p>\n<h3>Beispiel 2: Ben\u00f6tigen Sie einen neuen PDE-Term oder eine neue Kopplung<\/h3>\n<p>Sie m\u00f6chten einem vorhandenen Transportmodell einen Elektromigrationsbegriff hinzuf\u00fcgen. Der aktuelle Code funktioniert wie geplant; Es enth\u00e4lt nur diese Physik. Das ist eine Feature-Anfrage. Ihr Ticket sollte die ma\u00dfgebliche Gleichung, die erwarteten Eingaben und die Validierung (Benchmarks oder analytical limits) erl\u00e4utern.<\/p>\n<h3>Beispiel 3: \u201eEs ist zu langsam\u201c<\/h3>\n<p>Leistung kann entweder sein. Wenn der Code in 5 Minuten ausgef\u00fchrt wird und jetzt 50 Minuten f\u00fcr das gleiche Setup dauert, ist dies ein Fehler (eine Leistungsregression). Wenn der Code immer 50 Minuten gedauert hat und Sie m\u00f6chten, dass er 5 dauert, ist dies eine Feature-Anfrage (Optimierungsarbeit), es sei denn, die Langsamkeit beruht auf einem unbeabsichtigten Verhalten (wie ein Solver, der aufgrund eines Konvergenzproblems feststeckt).<\/p>\n<h3>Beispiel 4: Verwirrende Fehlermeldung<\/h3>\n<p>Eine verwirrende Fehlermeldung ist in der Regel eine Feature-Anforderung (Verbessern Sie UX), es sei denn, die Nachricht ist sachlich falsch oder maskiert den realen Fehler auf eine Weise, die die Diagnose verhindert. In vielen Teams wird die \u201eFehlermeldung verbessern\u201c als Verbesserung und nicht als Fehler verfolgt.<\/p>\n<h2>H\u00e4ufige Fehlklassifizierungen und wie man sie behebt<\/h2>\n<h3>Fehlklassifizierung: \u201eEs st\u00fcrzt ab\u201c (aber nur mit ung\u00fcltiger Eingabe)<\/h3>\n<p>Wenn die Software bei ung\u00fcltigen Eingaben abst\u00fcrzt, kann dies ein Fehler sein, wenn das Programm ordnungsgem\u00e4\u00df ausfallen sollte (Fehler l\u00f6schen, keine besch\u00e4digten Dateien). Wenn ein Absturz erwartet wird, da die Eingabe au\u00dferhalb der unterst\u00fctzten Einschr\u00e4nkungen liegt und das Tool dies bereits dokumentiert, kann dies eine Verbesserungsanforderung sein, um die Validierung und das Messaging zu verbessern.<\/p>\n<h3>Fehlklassifizierung: \u201eDie Ausgabe sieht falsch aus\u201c (aber die Erwartungen sind unklar)<\/h3>\n<p>Wenn das Ticket nicht definiert, was &#8222;richtig&#8220; bedeutet, k\u00f6nnen die Betreuer Bug vs. Feature nicht entscheiden. Schreiben Sie in diesem Fall das Ticket als Frage plus eine vorgeschlagene Erwartung und f\u00fcgen Sie Beweise bei. Oft ist der beste erste Schritt: \u201eErwartetes Verhalten kl\u00e4ren\u201c &#8211; dann als Fehler oder Feature erneut einreichen, sobald best\u00e4tigt.<\/p>\n<h3>Fehlklassifizierung: \u201eBitte Option X hinzuf\u00fcgen\u201c (der Code unterst\u00fctzt sie bereits)<\/h3>\n<p>Dies ist weder eine Funktion noch ein Fehler im Kernverhalten &#8211; es kann eine Dokumentationsl\u00fccke sein. Wenn die F\u00e4higkeit vorhanden ist, aber nur schwer zu finden ist, erstellen Sie ein Doc-Ticket (oder eine Verbesserung, die sich auf die Benutzerfreundlichkeit konzentriert).<\/p>\n<h2>So schreiben Sie einen hochwertigen Fehlerbericht<\/h2>\n<p>Ein guter Fehlerbericht erleichtert das Reproduzieren, Diagnostizieren und Verifizieren der Korrektur.<\/p>\n<h3>Fehlerbericht-Vorlage<\/h3>\n<ul>\n<li>Zusammenfassung: Ein Satz beschreibt das falsche Verhalten<\/li>\n<li>Umgebung: OS, Python\/C++-Version, Paketversion\/Commit, MPI\/Solver-Versionen ggf.<\/li>\n<li>Schritte zum Reproduzieren: Minimale Schritte, minimale Eingabedateien, minimaler Code-Snippet<\/li>\n<li>Erwartetes Ergebnis: Was sollte passieren und warum (Dokumente \/ Tests \/ vorheriges Verhalten)<\/li>\n<li>Tats\u00e4chliches Ergebnis: Was passiert stattdessen (Protokolle, Stapelverfolgung, Screenshots, Ausgabediff)<\/li>\n<li>Auswirkung: Schweregrad (Absturz, falsche Wissenschaft, geringe Benutzeroberfl\u00e4che), H\u00e4ufigkeit, Problemumgehung, falls vorhanden<\/li>\n<\/ul>\n<h3>Beispiel eines Fehlerberichts (kurz)<\/h3>\n<p>Zusammenfassung: Diffusionsbeispiel schl\u00e4gt mit Dirichlet BC im 3D-Raster fehl.<\/p>\n<ul>\n<li>Erwartet: Simulation l\u00e4uft und erzeugt stabile Feldwerte wie in 2D.<\/li>\n<li>Tats\u00e4chlich: Solver divergiert nach n Schritten; Werte werden zu Nan.<\/li>\n<li>Evidenz: Geben Sie minimale Skripte, Parameterwerte und Protokollausgaben an.<\/li>\n<\/ul>\n<h2>So schreiben Sie eine starke Feature-Anfrage<\/h2>\n<p>Eine starke Feature-Anfrage liest sich wie ein Mini-Design HINWEIS: Sie erkl\u00e4rt, warum die Funktion wichtig ist, wie \u201eerledigt\u201c aussieht und wie Sie sie \u00fcberpr\u00fcfen.<\/p>\n<h3>Feature-Anforderungsvorlage<\/h3>\n<ul>\n<li>Problemstellung: Was Sie heute nicht tun k\u00f6nnen<\/li>\n<li>Anwendungsfall: Wer braucht es und warum (Forschungsworkflow, Lehrmodul, Produktionspipeline)<\/li>\n<li>L\u00f6sungsvorschlag: Verhalten auf hoher Ebene, \u00c4nderungen an der Benutzeroberfl\u00e4che\/API, Standardeinstellungen<\/li>\n<li>Akzeptanzkriterien: Was muss wahr sein, um es vollst\u00e4ndig zu betrachten?<\/li>\n<li>Validierung: Testen (Benchmarks, Unit-Tests, Analysel\u00f6sungen, Regressions-Suite)<\/li>\n<li>Alternativen betrachtet: Problemumgehungen oder andere Ans\u00e4tze<\/li>\n<\/ul>\n<h3>Beispiel f\u00fcr Feature-Anforderung (kurz)<\/h3>\n<p>Anfrage: F\u00fcgen Sie eine Option zum Exportieren des Simulationsstatus in ein standardisiertes Visualisierungsformat in konfigurierbaren Intervallen hinzu.<\/p>\n<ul>\n<li>Anwendungsfall: Gro\u00dfe L\u00e4ufe auf HPC, bei denen eine Zwischenvisualisierung f\u00fcr die \u00dcberwachung erforderlich ist.<\/li>\n<li>Akzeptanz: Export funktioniert f\u00fcr 2D\/3D-Raster; Enth\u00e4lt Metadaten (Zeitschritt, Einheiten); Keine gr\u00f6\u00dfere Verlangsamung.<\/li>\n<li>Validierung: Vergleichen Sie exportierte Felder mit Arrays im Arbeitsspeicher; Stellen Sie sicher, dass das Nachladen den Zustand innerhalb der Toleranz wiedergibt.<\/li>\n<\/ul>\n<h2>Wenn ein Ticket zwei werden sollte<\/h2>\n<p>Viele reale Probleme mischen Fehler und Funktionen. Das Teilen beschleunigt oft den Fortschritt.<\/p>\n<ul>\n<li>Wenn es einen Absturz (Bug) und auch den Wunsch nach einer netteren Nachricht (Feature) gibt, reichen Sie zwei Tickets ein.<\/li>\n<li>Wenn es ein Problem mit der Korrektheit (Bug) und auch eine Anfrage zur Unterst\u00fctzung eines neuen Regimes gibt, trennen Sie das \u201eAktuelle Verhalten\u201c von der \u201eErweiterungsf\u00e4higkeit\u201c.<\/li>\n<li>Wenn die Anfrage &#8222;schneller&#8220; ist, aber Sie vermuten, dass Sie eine Regression vermuten, legen Sie einen Fehler f\u00fcr die Regression und eine Funktion zur weiteren Optimierung ein.<\/li>\n<\/ul>\n<p>Durch das Teilen von Tickets k\u00f6nnen Teams den Fehler schnell schlie\u00dfen und die Verbesserung sinnvoll planen.<\/p>\n<h2>Triage-Tipps f\u00fcr Betreuer und Leads<\/h2>\n<h3>Verwenden Sie Etiketten und einen kurzen Entscheidungskommentar<\/h3>\n<p>Wenn ein Ticket mehrdeutig ankommt, f\u00fcgen Sie einen kurzen Kommentar hinzu, der die Klassifizierung sperrt:<\/p>\n<ul>\n<li>\u201eAls Fehler klassifizieren, weil Verhalten dem Dokumentationsabschnitt X widerspricht.\u201c<\/li>\n<li>&#8222;Klassifizierung als Feature-Anforderung, da dadurch neue Solverfunktionen hinzugef\u00fcgt werden, die derzeit nicht unterst\u00fctzt werden.&#8220;<\/li>\n<\/ul>\n<h3>erfordern minimale Akzeptanzkriterien f\u00fcr Funktionen<\/h3>\n<p>Feature-Anfragen scheitern, wenn \u201eFertig\u201c unklar ist. Fragen Sie fr\u00fch nach Akzeptanzkriterien: Welche Ausgabe, welche Schnittstelle, welche Tests, welches Beispiel. Ein Feature ohne Akzeptanzkriterien ist effektiv ein Wunschlistenelement.<\/p>\n<h3>Verwandeln Sie wiederkehrende Fragen in Dokumentationsaufgaben<\/h3>\n<p>Wenn mehrere \u201eFeature-Anfragen\u201c tats\u00e4chlich Anleitungsanfragen sind (\u201eWie mache ich\u2026?\u201c), Erfassen Sie diese als Dokumentenverbesserungen. Dies ist insbesondere in wissenschaftlichen Bibliotheken \u00fcblich, in denen F\u00e4higkeiten vorhanden sind, die jedoch nicht offensichtlich sind.<\/p>\n<h2>Praktische Vorlagen, die Sie in Tickets kopieren k\u00f6nnen<\/h2>\n<h3>Einzeiler-Klassifikator<\/h3>\n<p>Verwenden Sie dies als erste Zeile Ihrer Ticketbeschreibung:<\/p>\n<ul>\n<li>BUG: \u201eBeobachtetes Verhalten widerspricht dem erwarteten Verhalten von [docs\/test\/previous version].\u201c<\/li>\n<li>Feature: \u201eNeue Funktion zur Unterst\u00fctzung von [use case] erforderlich, derzeit nicht verf\u00fcgbar.\u201c<\/li>\n<\/ul>\n<h3>Akzeptanzkriterien Starterset f\u00fcr Features<\/h3>\n<ul>\n<li>API: Neue Option\/Parameter mit Standardeinstellungen dokumentiert<\/li>\n<li>Beispiel: Minimales Arbeitsbeispiel in Dokumenten\/Beispielen<\/li>\n<li>Tests: Mindestens ein automatisierter Test deckt das Hauptverhalten ab<\/li>\n<li>R\u00fcckw\u00e4rtskompatibilit\u00e4t: Vorhandene Skripte laufen unver\u00e4ndert weiter (oder Migrationsschritte dokumentiert)<\/li>\n<\/ul>\n<h2>Schlussfolgerung<\/h2>\n<p>Fehlerberichte stellen das Vertrauen wieder her; Feature-Anfragen erweitern die F\u00e4higkeit. Beide sind in wissenschaftlicher Software unerl\u00e4sslich, aber sie sind nur erfolgreich, wenn sie mit der richtigen Absicht und Beweisen geschrieben werden. Wenn Sie Fehler an einen Referenzpunkt verkn\u00fcpfen und Funktionen an einen klaren Anwendungsfall mit Akzeptanzkriterien binden, reduzieren Sie die Triage-Reibung, beschleunigen die Entwicklung und machen Releases vorhersehbarer &#8211; was letztendlich die Forschungsgeschwindigkeit und die Zuverl\u00e4ssigkeit der Ergebnisse verbessert.<\/p>\n","protected":false,"raw":"<p>In der wissenschaftlichen und Engineering-Software kommt die gr\u00f6\u00dfte Frustration nicht von schwierigen Problemen - es kommt von unklaren Problemaussagen. Ein Ticket, das \u201efalsch klingt\u201c, k\u00f6nnte tats\u00e4chlich eine fehlende F\u00e4higkeit beschreiben. Eine Anfrage nach einer \u201ekleinen Verbesserung\u201c k\u00f6nnte darin bestehen, einen Defekt zu maskieren, der die Ergebnisse besch\u00e4digt. Wenn Teams Tickets falsch klassifizieren, verschwenden sie Zeit: Entwickler untersuchen Phantomfehler, Forscher warten auf Features, die nie im Ziel waren, und Priorit\u00e4ten driften.<\/p>\n<p>Dieser Leitfaden hilft Ihnen dabei, schnell zu entscheiden, ob es sich um einen Fehlerbericht oder eine Feature-Anfrage handelt, und zeigt, wie Sie jeden einzelnen schreiben, damit das Team darauf reagieren kann. Das Ziel ist einfach: weniger Hin- und Her-Kommentare, schnellere Triage und weniger \u00dcberraschungen bei Ver\u00f6ffentlichungen.<\/p>\n<h2>Warum die Unterscheidung wichtig ist<\/h2>\n<p>Fehlerberichte und Funktionsanforderungen werden in den meisten Workflows (TRAC, JIRA, GitHub Issues, Redmine usw.) unterschiedlich behandelt. Sie haben unterschiedliche Dringlichkeit, unterschiedliche Akzeptanzkriterien und verschiedene M\u00f6glichkeiten, die Schleife zu testen und zu schlie\u00dfen.<\/p>\n<ul>\n<li>Ein Fehlerbericht hat normalerweise die Erwartung der Richtigkeit: Die Software verst\u00f6\u00dft gegen ihren eigenen Vertrag, ihre Dokumentation oder ihr etabliertes Verhalten.<\/li>\n<li>Eine Feature-Anfrage fragt nach neuem Verhalten: etwas, was die Software derzeit nicht verspricht, auch wenn es n\u00fctzlich w\u00e4re.<\/li>\n<\/ul>\n<p>Wenn Sie das Ticket richtig beschriften, wird die Triage einfacher: Betreuer k\u00f6nnen reproduzieren, priorisieren und Arbeiten zuweisen, ohne zu erraten, was \u201esoll\u201c passieren sollte.<\/p>\n<h2>Die Kerndefinitionen<\/h2>\n<h3>Was ist ein Fehlerbericht?<\/h3>\n<p>Ein Fehler ist, wenn sich das System im Vergleich zu einem vereinbarten Referenzpunkt falsch verh\u00e4lt. Dieser Bezugspunkt kann sein:<\/p>\n<ul>\n<li>Dokumentation oder eine ver\u00f6ffentlichte Schnittstelle (API-Vertrag)<\/li>\n<li>Vorheriges stabiles Verhalten (eine Regression)<\/li>\n<li>Wissenschaftliche Korrektheit (z. B. Erhaltungsgesetze, erwartete Invarianten, Einheitskonsistenz)<\/li>\n<li>klar angegebene Anforderungen (einschlie\u00dflich Tests oder Spezifikationen)<\/li>\n<\/ul>\n<p>Kurz gesagt: Ein Fehlerbericht beschreibt einen Fehler, der behoben werden sollte, um die Korrektheit wiederherzustellen.<\/p>\n<h3>Was ist eine Funktionsanfrage?<\/h3>\n<p>Eine Feature-Anforderung schl\u00e4gt eine F\u00e4higkeit oder Verbesserung vor, die das System n\u00fctzlicher, flexibler oder effizienter machen w\u00fcrde, aber nicht f\u00fcr die Richtigkeit des aktuellen Verhaltens erforderlich ist. Beispiele sind:<\/p>\n<ul>\n<li>Unterst\u00fctzt einen neuen Randbedingungstyp<\/li>\n<li>Hinzuf\u00fcgen eines Exporters f\u00fcr ein neues Dateiformat<\/li>\n<li>Die Leistung \u00fcber die aktuellen Ziele hinaus verbessern<\/li>\n<li>Hinzuf\u00fcgen von UI\/CLI-Optionen, die noch nicht vorhanden sind<\/li>\n<\/ul>\n<p>Kurz gesagt: Eine Funktionsanforderung beschreibt etwas Neues, das das System tun sollte.<\/p>\n<h2>Schnelle Entscheidungs-Checkliste<\/h2>\n<p>Wenn Sie sich nur an eine Regel erinnern, verwenden Sie diese:<\/p>\n<ul>\n<li>Wenn die Software ein Versprechen bricht, ist es ein Fehler.<\/li>\n<li>Wenn Sie ein neues Versprechen w\u00fcnschen, ist es eine Funktion.<\/li>\n<\/ul>\n<p>Stellen Sie sich diese Fragen:<\/p>\n<ol>\n<li>Hat es jemals zuvor im selben Szenario funktioniert? Wenn ja, wahrscheinlich ein Fehler (m\u00f6glicherweise eine Regression).<\/li>\n<li>Gibt es eine Dokumentation, die besagt, dass das Verhalten funktionieren sollte? Wenn ja, Bug.<\/li>\n<li>Ist das Verhalten mehrdeutig und Sie schlagen vor, was es sein sollte? wahrscheinlich ein Feature (oder zuerst eine Spezifikationskl\u00e4rung).<\/li>\n<li>Ist das Problem, dass Sie \u00fcberhaupt nichts tun k\u00f6nnen, aber nichts ist mit vorhandenen Ausgaben \u201efalsch\u201c? wahrscheinlich eine Funktion.<\/li>\n<li>Erzeugt es falsche Ergebnisse, Abst\u00fcrze, besch\u00e4digte Daten oder verst\u00f6\u00dft gegen physische Einschr\u00e4nkungen? K\u00e4fer<\/li>\n<\/ol>\n<h2>Side-by-Side-Vergleich<\/h2>\n<table class=\"custom-table\">\n<tbody><tr>\n<th>Aspekt<\/th>\n<th>Fehlerbericht<\/th>\n<th>Feature-Anfrage<\/th>\n<\/tr>\n<tr>\n<td>Bedeutung<\/td>\n<td>Im Vergleich zum erwarteten Verhalten stimmt etwas nicht<\/td>\n<td>etwas Neues oder Verbessertes ist erw\u00fcnscht<\/td>\n<\/tr>\n<tr>\n<td>Bezugspunkt<\/td>\n<td>Dokumente, Tests, Vorversionen, Korrektheitskriterien<\/td>\n<td>Benutzerbed\u00fcrfnisse, Forschungsziele, Verbesserungen der Benutzerfreundlichkeit<\/td>\n<\/tr>\n<tr>\n<td>Typische Beweise<\/td>\n<td>Reproduktionsschritte, Protokolle, falsche Ausgabe, Crash-Trace<\/td>\n<td>Anwendungsfall, Nutzen, vorgeschlagenes Verhalten, Akzeptanzkriterien<\/td>\n<\/tr>\n<tr>\n<td>Priorit\u00e4tstreiber<\/td>\n<td>Schweregrad, Umfang, H\u00e4ufigkeit, Ergebnisrisiko<\/td>\n<td>Auswirkungen, Nachfrage, strategische Roadmap, Aufwand<\/td>\n<\/tr>\n<tr>\n<td>Wie es \"auf\" ist<\/td>\n<td>verifizierter Fix; Testdurchl\u00e4ufe; Regression verhindert<\/td>\n<td>implementierte Spezifikation; dokumentiert; End-to-End nutzbar<\/td>\n<\/tr>\n<\/tbody><\/table>\n<h2>Beispiele im wissenschaftlichen Rechnen<\/h2>\n<h3>Beispiel 1: Falsche Ergebnisse aufgrund von Unstimmigkeiten der Einheiten<\/h3>\n<p>Sie f\u00fchren eine Simulation durch und bemerken, dass ein als \u201eMeter\u201c dokumentierter Parameter als \u201eMillimetern\u201c behandelt wird und die Ergebnisse um das 1000\u00d7 verschiebt. Wenn Dokumentation und Code nicht \u00fcbereinstimmen und die Ausgaben f\u00fcr die dokumentierte Verwendung falsch sind, ist dies ein Fehlerbericht. Ihr Ticket sollte den Parameter enthalten, in dem es dokumentiert ist, ein minimaler Fall und ein Hinweis auf eine Nicht\u00fcbereinstimmung.<\/p>\n<h3>Beispiel 2: Ben\u00f6tigen Sie einen neuen PDE-Term oder eine neue Kopplung<\/h3>\n<p>Sie m\u00f6chten einem vorhandenen Transportmodell einen Elektromigrationsbegriff hinzuf\u00fcgen. Der aktuelle Code funktioniert wie geplant; Es enth\u00e4lt nur diese Physik. Das ist eine Feature-Anfrage. Ihr Ticket sollte die ma\u00dfgebliche Gleichung, die erwarteten Eingaben und die Validierung (Benchmarks oder analytical limits) erl\u00e4utern.<\/p>\n<h3>Beispiel 3: \u201eEs ist zu langsam\u201c<\/h3>\n<p>Leistung kann entweder sein. Wenn der Code in 5 Minuten ausgef\u00fchrt wird und jetzt 50 Minuten f\u00fcr das gleiche Setup dauert, ist dies ein Fehler (eine Leistungsregression). Wenn der Code immer 50 Minuten gedauert hat und Sie m\u00f6chten, dass er 5 dauert, ist dies eine Feature-Anfrage (Optimierungsarbeit), es sei denn, die Langsamkeit beruht auf einem unbeabsichtigten Verhalten (wie ein Solver, der aufgrund eines Konvergenzproblems feststeckt).<\/p>\n<h3>Beispiel 4: Verwirrende Fehlermeldung<\/h3>\n<p>Eine verwirrende Fehlermeldung ist in der Regel eine Feature-Anforderung (Verbessern Sie UX), es sei denn, die Nachricht ist sachlich falsch oder maskiert den realen Fehler auf eine Weise, die die Diagnose verhindert. In vielen Teams wird die \u201eFehlermeldung verbessern\u201c als Verbesserung und nicht als Fehler verfolgt.<\/p>\n<h2>H\u00e4ufige Fehlklassifizierungen und wie man sie behebt<\/h2>\n<h3>Fehlklassifizierung: \u201eEs st\u00fcrzt ab\u201c (aber nur mit ung\u00fcltiger Eingabe)<\/h3>\n<p>Wenn die Software bei ung\u00fcltigen Eingaben abst\u00fcrzt, kann dies ein Fehler sein, wenn das Programm ordnungsgem\u00e4\u00df ausfallen sollte (Fehler l\u00f6schen, keine besch\u00e4digten Dateien). Wenn ein Absturz erwartet wird, da die Eingabe au\u00dferhalb der unterst\u00fctzten Einschr\u00e4nkungen liegt und das Tool dies bereits dokumentiert, kann dies eine Verbesserungsanforderung sein, um die Validierung und das Messaging zu verbessern.<\/p>\n<h3>Fehlklassifizierung: \u201eDie Ausgabe sieht falsch aus\u201c (aber die Erwartungen sind unklar)<\/h3>\n<p>Wenn das Ticket nicht definiert, was \"richtig\" bedeutet, k\u00f6nnen die Betreuer Bug vs. Feature nicht entscheiden. Schreiben Sie in diesem Fall das Ticket als Frage plus eine vorgeschlagene Erwartung und f\u00fcgen Sie Beweise bei. Oft ist der beste erste Schritt: \u201eErwartetes Verhalten kl\u00e4ren\u201c - dann als Fehler oder Feature erneut einreichen, sobald best\u00e4tigt.<\/p>\n<h3>Fehlklassifizierung: \u201eBitte Option X hinzuf\u00fcgen\u201c (der Code unterst\u00fctzt sie bereits)<\/h3>\n<p>Dies ist weder eine Funktion noch ein Fehler im Kernverhalten - es kann eine Dokumentationsl\u00fccke sein. Wenn die F\u00e4higkeit vorhanden ist, aber nur schwer zu finden ist, erstellen Sie ein Doc-Ticket (oder eine Verbesserung, die sich auf die Benutzerfreundlichkeit konzentriert).<\/p>\n<h2>So schreiben Sie einen hochwertigen Fehlerbericht<\/h2>\n<p>Ein guter Fehlerbericht erleichtert das Reproduzieren, Diagnostizieren und Verifizieren der Korrektur.<\/p>\n<h3>Fehlerbericht-Vorlage<\/h3>\n<ul>\n<li>Zusammenfassung: Ein Satz beschreibt das falsche Verhalten<\/li>\n<li>Umgebung: OS, Python\/C++-Version, Paketversion\/Commit, MPI\/Solver-Versionen ggf.<\/li>\n<li>Schritte zum Reproduzieren: Minimale Schritte, minimale Eingabedateien, minimaler Code-Snippet<\/li>\n<li>Erwartetes Ergebnis: Was sollte passieren und warum (Dokumente \/ Tests \/ vorheriges Verhalten)<\/li>\n<li>Tats\u00e4chliches Ergebnis: Was passiert stattdessen (Protokolle, Stapelverfolgung, Screenshots, Ausgabediff)<\/li>\n<li>Auswirkung: Schweregrad (Absturz, falsche Wissenschaft, geringe Benutzeroberfl\u00e4che), H\u00e4ufigkeit, Problemumgehung, falls vorhanden<\/li>\n<\/ul>\n<h3>Beispiel eines Fehlerberichts (kurz)<\/h3>\n<p>Zusammenfassung: Diffusionsbeispiel schl\u00e4gt mit Dirichlet BC im 3D-Raster fehl.<\/p>\n<ul>\n<li>Erwartet: Simulation l\u00e4uft und erzeugt stabile Feldwerte wie in 2D.<\/li>\n<li>Tats\u00e4chlich: Solver divergiert nach n Schritten; Werte werden zu Nan.<\/li>\n<li>Evidenz: Geben Sie minimale Skripte, Parameterwerte und Protokollausgaben an.<\/li>\n<\/ul>\n<h2>So schreiben Sie eine starke Feature-Anfrage<\/h2>\n<p>Eine starke Feature-Anfrage liest sich wie ein Mini-Design HINWEIS: Sie erkl\u00e4rt, warum die Funktion wichtig ist, wie \u201eerledigt\u201c aussieht und wie Sie sie \u00fcberpr\u00fcfen.<\/p>\n<h3>Feature-Anforderungsvorlage<\/h3>\n<ul>\n<li>Problemstellung: Was Sie heute nicht tun k\u00f6nnen<\/li>\n<li>Anwendungsfall: Wer braucht es und warum (Forschungsworkflow, Lehrmodul, Produktionspipeline)<\/li>\n<li>L\u00f6sungsvorschlag: Verhalten auf hoher Ebene, \u00c4nderungen an der Benutzeroberfl\u00e4che\/API, Standardeinstellungen<\/li>\n<li>Akzeptanzkriterien: Was muss wahr sein, um es vollst\u00e4ndig zu betrachten?<\/li>\n<li>Validierung: Testen (Benchmarks, Unit-Tests, Analysel\u00f6sungen, Regressions-Suite)<\/li>\n<li>Alternativen betrachtet: Problemumgehungen oder andere Ans\u00e4tze<\/li>\n<\/ul>\n<h3>Beispiel f\u00fcr Feature-Anforderung (kurz)<\/h3>\n<p>Anfrage: F\u00fcgen Sie eine Option zum Exportieren des Simulationsstatus in ein standardisiertes Visualisierungsformat in konfigurierbaren Intervallen hinzu.<\/p>\n<ul>\n<li>Anwendungsfall: Gro\u00dfe L\u00e4ufe auf HPC, bei denen eine Zwischenvisualisierung f\u00fcr die \u00dcberwachung erforderlich ist.<\/li>\n<li>Akzeptanz: Export funktioniert f\u00fcr 2D\/3D-Raster; Enth\u00e4lt Metadaten (Zeitschritt, Einheiten); Keine gr\u00f6\u00dfere Verlangsamung.<\/li>\n<li>Validierung: Vergleichen Sie exportierte Felder mit Arrays im Arbeitsspeicher; Stellen Sie sicher, dass das Nachladen den Zustand innerhalb der Toleranz wiedergibt.<\/li>\n<\/ul>\n<h2>Wenn ein Ticket zwei werden sollte<\/h2>\n<p>Viele reale Probleme mischen Fehler und Funktionen. Das Teilen beschleunigt oft den Fortschritt.<\/p>\n<ul>\n<li>Wenn es einen Absturz (Bug) und auch den Wunsch nach einer netteren Nachricht (Feature) gibt, reichen Sie zwei Tickets ein.<\/li>\n<li>Wenn es ein Problem mit der Korrektheit (Bug) und auch eine Anfrage zur Unterst\u00fctzung eines neuen Regimes gibt, trennen Sie das \u201eAktuelle Verhalten\u201c von der \u201eErweiterungsf\u00e4higkeit\u201c.<\/li>\n<li>Wenn die Anfrage \"schneller\" ist, aber Sie vermuten, dass Sie eine Regression vermuten, legen Sie einen Fehler f\u00fcr die Regression und eine Funktion zur weiteren Optimierung ein.<\/li>\n<\/ul>\n<p>Durch das Teilen von Tickets k\u00f6nnen Teams den Fehler schnell schlie\u00dfen und die Verbesserung sinnvoll planen.<\/p>\n<h2>Triage-Tipps f\u00fcr Betreuer und Leads<\/h2>\n<h3>Verwenden Sie Etiketten und einen kurzen Entscheidungskommentar<\/h3>\n<p>Wenn ein Ticket mehrdeutig ankommt, f\u00fcgen Sie einen kurzen Kommentar hinzu, der die Klassifizierung sperrt:<\/p>\n<ul>\n<li>\u201eAls Fehler klassifizieren, weil Verhalten dem Dokumentationsabschnitt X widerspricht.\u201c<\/li>\n<li>\"Klassifizierung als Feature-Anforderung, da dadurch neue Solverfunktionen hinzugef\u00fcgt werden, die derzeit nicht unterst\u00fctzt werden.\"<\/li>\n<\/ul>\n<h3>erfordern minimale Akzeptanzkriterien f\u00fcr Funktionen<\/h3>\n<p>Feature-Anfragen scheitern, wenn \u201eFertig\u201c unklar ist. Fragen Sie fr\u00fch nach Akzeptanzkriterien: Welche Ausgabe, welche Schnittstelle, welche Tests, welches Beispiel. Ein Feature ohne Akzeptanzkriterien ist effektiv ein Wunschlistenelement.<\/p>\n<h3>Verwandeln Sie wiederkehrende Fragen in Dokumentationsaufgaben<\/h3>\n<p>Wenn mehrere \u201eFeature-Anfragen\u201c tats\u00e4chlich Anleitungsanfragen sind (\u201eWie mache ich\u2026?\u201c), Erfassen Sie diese als Dokumentenverbesserungen. Dies ist insbesondere in wissenschaftlichen Bibliotheken \u00fcblich, in denen F\u00e4higkeiten vorhanden sind, die jedoch nicht offensichtlich sind.<\/p>\n<h2>Praktische Vorlagen, die Sie in Tickets kopieren k\u00f6nnen<\/h2>\n<h3>Einzeiler-Klassifikator<\/h3>\n<p>Verwenden Sie dies als erste Zeile Ihrer Ticketbeschreibung:<\/p>\n<ul>\n<li>BUG: \u201eBeobachtetes Verhalten widerspricht dem erwarteten Verhalten von [docs\/test\/previous version].\u201c<\/li>\n<li>Feature: \u201eNeue Funktion zur Unterst\u00fctzung von [use case] erforderlich, derzeit nicht verf\u00fcgbar.\u201c<\/li>\n<\/ul>\n<h3>Akzeptanzkriterien Starterset f\u00fcr Features<\/h3>\n<ul>\n<li>API: Neue Option\/Parameter mit Standardeinstellungen dokumentiert<\/li>\n<li>Beispiel: Minimales Arbeitsbeispiel in Dokumenten\/Beispielen<\/li>\n<li>Tests: Mindestens ein automatisierter Test deckt das Hauptverhalten ab<\/li>\n<li>R\u00fcckw\u00e4rtskompatibilit\u00e4t: Vorhandene Skripte laufen unver\u00e4ndert weiter (oder Migrationsschritte dokumentiert)<\/li>\n<\/ul>\n<h2>Schlussfolgerung<\/h2>\n<p>Fehlerberichte stellen das Vertrauen wieder her; Feature-Anfragen erweitern die F\u00e4higkeit. Beide sind in wissenschaftlicher Software unerl\u00e4sslich, aber sie sind nur erfolgreich, wenn sie mit der richtigen Absicht und Beweisen geschrieben werden. Wenn Sie Fehler an einen Referenzpunkt verkn\u00fcpfen und Funktionen an einen klaren Anwendungsfall mit Akzeptanzkriterien binden, reduzieren Sie die Triage-Reibung, beschleunigen die Entwicklung und machen Releases vorhersehbarer - was letztendlich die Forschungsgeschwindigkeit und die Zuverl\u00e4ssigkeit der Ergebnisse verbessert.<\/p>\n"},"excerpt":{"rendered":"<p><span class=\"span-reading-time rt-reading-time\" style=\"display: block;\"><span class=\"rt-label rt-prefix\">Reading Time: <\/span> <span class=\"rt-time\"> 6<\/span> <span class=\"rt-label rt-postfix\">minutes<\/span><\/span>In der wissenschaftlichen und Engineering-Software kommt die gr\u00f6\u00dfte Frustration nicht von schwierigen Problemen &#8211; es kommt von unklaren Problemaussagen. Ein Ticket, das \u201efalsch klingt\u201c, k\u00f6nnte tats\u00e4chlich eine fehlende F\u00e4higkeit beschreiben. Eine Anfrage nach einer \u201ekleinen Verbesserung\u201c k\u00f6nnte darin bestehen, einen Defekt zu maskieren, der die Ergebnisse besch\u00e4digt. Wenn Teams Tickets falsch klassifizieren, verschwenden sie Zeit: [&hellip;]<\/p>\n","protected":false,"raw":""},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_locale":"de_DE","_original_post":"https:\/\/new.matforge.org\/?p=50","iawp_total_views":0,"footnotes":""},"categories":[3],"tags":[],"class_list":["post-807","post","type-post","status-publish","format-standard","hentry","category-issue-tracking-tickets-technical-requests","de-DE"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v28.1 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Feature Requests vs. Bug Reports: Den Unterschied kennen (mit Beispielen)<\/title>\n<meta name=\"description\" content=\"Erfahren Sie, wie Sie Funktionsanforderungen aus Fehlerberichten abgeben, bessere Tickets schreiben und die Triage mit praktischen Beispielen, einer Vergleichstabelle und Vorlagen beschleunigen.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/matforge.org\/de\/feature-requests-vs-bug-reports-knowing-the-difference\/\" \/>\n<meta property=\"og:locale\" content=\"de_DE\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Feature Requests vs. Bug Reports: Den Unterschied kennen (mit Beispielen)\" \/>\n<meta property=\"og:description\" content=\"Erfahren Sie, wie Sie Funktionsanforderungen aus Fehlerberichten abgeben, bessere Tickets schreiben und die Triage mit praktischen Beispielen, einer Vergleichstabelle und Vorlagen beschleunigen.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/matforge.org\/de\/feature-requests-vs-bug-reports-knowing-the-difference\/\" \/>\n<meta property=\"og:site_name\" content=\"matforge.org\" \/>\n<meta property=\"article:published_time\" content=\"2026-07-30T12:21:34+00:00\" \/>\n<meta name=\"author\" content=\"Priya Nair\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Verfasst von\" \/>\n\t<meta name=\"twitter:data1\" content=\"Priya Nair\" \/>\n\t<meta name=\"twitter:label2\" content=\"Gesch\u00e4tzte Lesezeit\" \/>\n\t<meta name=\"twitter:data2\" content=\"9\u00a0Minuten\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/matforge.org\\\/de\\\/feature-requests-vs-bug-reports-knowing-the-difference\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/de\\\/feature-requests-vs-bug-reports-knowing-the-difference\\\/\"},\"author\":{\"name\":\"Priya Nair\",\"@id\":\"https:\\\/\\\/matforge.org\\\/#\\\/schema\\\/person\\\/2effd7bc155a5e6357f31dac970c5795\"},\"headline\":\"Feature Requests vs. Bug Reports: Den Unterschied kennen\",\"datePublished\":\"2026-07-30T12:21:34+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/de\\\/feature-requests-vs-bug-reports-knowing-the-difference\\\/\"},\"wordCount\":1727,\"commentCount\":0,\"articleSection\":[\"Issue Tracking, Tickets & amp; Technische Anfragen\"],\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/matforge.org\\\/de\\\/feature-requests-vs-bug-reports-knowing-the-difference\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/matforge.org\\\/de\\\/feature-requests-vs-bug-reports-knowing-the-difference\\\/\",\"url\":\"https:\\\/\\\/matforge.org\\\/de\\\/feature-requests-vs-bug-reports-knowing-the-difference\\\/\",\"name\":\"Feature Requests vs. Bug Reports: Den Unterschied kennen (mit Beispielen)\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/#website\"},\"datePublished\":\"2026-07-30T12:21:34+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/#\\\/schema\\\/person\\\/2effd7bc155a5e6357f31dac970c5795\"},\"description\":\"Erfahren Sie, wie Sie Funktionsanforderungen aus Fehlerberichten abgeben, bessere Tickets schreiben und die Triage mit praktischen Beispielen, einer Vergleichstabelle und Vorlagen beschleunigen.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/de\\\/feature-requests-vs-bug-reports-knowing-the-difference\\\/#breadcrumb\"},\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/matforge.org\\\/de\\\/feature-requests-vs-bug-reports-knowing-the-difference\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/matforge.org\\\/de\\\/feature-requests-vs-bug-reports-knowing-the-difference\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/matforge.org\\\/de\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Feature Requests vs. Bug Reports: Den Unterschied kennen\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/matforge.org\\\/#website\",\"url\":\"https:\\\/\\\/matforge.org\\\/\",\"name\":\"matforge.org\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/matforge.org\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"de\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/matforge.org\\\/#\\\/schema\\\/person\\\/2effd7bc155a5e6357f31dac970c5795\",\"name\":\"Priya Nair\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/f11e168d4cd2f1eff83cbb851d6cff42d81d88bb59d8831ee77468aa4a5eea88?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/f11e168d4cd2f1eff83cbb851d6cff42d81d88bb59d8831ee77468aa4a5eea88?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/f11e168d4cd2f1eff83cbb851d6cff42d81d88bb59d8831ee77468aa4a5eea88?s=96&d=mm&r=g\",\"caption\":\"Priya Nair\"},\"sameAs\":[\"http:\\\/\\\/matforge.org\"],\"url\":\"https:\\\/\\\/matforge.org\\\/author\\\/priya-nair\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Feature Requests vs. Bug Reports: Den Unterschied kennen (mit Beispielen)","description":"Erfahren Sie, wie Sie Funktionsanforderungen aus Fehlerberichten abgeben, bessere Tickets schreiben und die Triage mit praktischen Beispielen, einer Vergleichstabelle und Vorlagen beschleunigen.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/matforge.org\/de\/feature-requests-vs-bug-reports-knowing-the-difference\/","og_locale":"de_DE","og_type":"article","og_title":"Feature Requests vs. Bug Reports: Den Unterschied kennen (mit Beispielen)","og_description":"Erfahren Sie, wie Sie Funktionsanforderungen aus Fehlerberichten abgeben, bessere Tickets schreiben und die Triage mit praktischen Beispielen, einer Vergleichstabelle und Vorlagen beschleunigen.","og_url":"https:\/\/matforge.org\/de\/feature-requests-vs-bug-reports-knowing-the-difference\/","og_site_name":"matforge.org","article_published_time":"2026-07-30T12:21:34+00:00","author":"Priya Nair","twitter_card":"summary_large_image","twitter_misc":{"Verfasst von":"Priya Nair","Gesch\u00e4tzte Lesezeit":"9\u00a0Minuten"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/matforge.org\/de\/feature-requests-vs-bug-reports-knowing-the-difference\/#article","isPartOf":{"@id":"https:\/\/matforge.org\/de\/feature-requests-vs-bug-reports-knowing-the-difference\/"},"author":{"name":"Priya Nair","@id":"https:\/\/matforge.org\/#\/schema\/person\/2effd7bc155a5e6357f31dac970c5795"},"headline":"Feature Requests vs. Bug Reports: Den Unterschied kennen","datePublished":"2026-07-30T12:21:34+00:00","mainEntityOfPage":{"@id":"https:\/\/matforge.org\/de\/feature-requests-vs-bug-reports-knowing-the-difference\/"},"wordCount":1727,"commentCount":0,"articleSection":["Issue Tracking, Tickets & amp; Technische Anfragen"],"inLanguage":"de","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/matforge.org\/de\/feature-requests-vs-bug-reports-knowing-the-difference\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/matforge.org\/de\/feature-requests-vs-bug-reports-knowing-the-difference\/","url":"https:\/\/matforge.org\/de\/feature-requests-vs-bug-reports-knowing-the-difference\/","name":"Feature Requests vs. Bug Reports: Den Unterschied kennen (mit Beispielen)","isPartOf":{"@id":"https:\/\/matforge.org\/#website"},"datePublished":"2026-07-30T12:21:34+00:00","author":{"@id":"https:\/\/matforge.org\/#\/schema\/person\/2effd7bc155a5e6357f31dac970c5795"},"description":"Erfahren Sie, wie Sie Funktionsanforderungen aus Fehlerberichten abgeben, bessere Tickets schreiben und die Triage mit praktischen Beispielen, einer Vergleichstabelle und Vorlagen beschleunigen.","breadcrumb":{"@id":"https:\/\/matforge.org\/de\/feature-requests-vs-bug-reports-knowing-the-difference\/#breadcrumb"},"inLanguage":"de","potentialAction":[{"@type":"ReadAction","target":["https:\/\/matforge.org\/de\/feature-requests-vs-bug-reports-knowing-the-difference\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/matforge.org\/de\/feature-requests-vs-bug-reports-knowing-the-difference\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/matforge.org\/de\/"},{"@type":"ListItem","position":2,"name":"Feature Requests vs. Bug Reports: Den Unterschied kennen"}]},{"@type":"WebSite","@id":"https:\/\/matforge.org\/#website","url":"https:\/\/matforge.org\/","name":"matforge.org","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/matforge.org\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"de"},{"@type":"Person","@id":"https:\/\/matforge.org\/#\/schema\/person\/2effd7bc155a5e6357f31dac970c5795","name":"Priya Nair","image":{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/secure.gravatar.com\/avatar\/f11e168d4cd2f1eff83cbb851d6cff42d81d88bb59d8831ee77468aa4a5eea88?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/f11e168d4cd2f1eff83cbb851d6cff42d81d88bb59d8831ee77468aa4a5eea88?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/f11e168d4cd2f1eff83cbb851d6cff42d81d88bb59d8831ee77468aa4a5eea88?s=96&d=mm&r=g","caption":"Priya Nair"},"sameAs":["http:\/\/matforge.org"],"url":"https:\/\/matforge.org\/author\/priya-nair\/"}]}},"_links":{"self":[{"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/posts\/807","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/comments?post=807"}],"version-history":[{"count":1,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/posts\/807\/revisions"}],"predecessor-version":[{"id":917,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/posts\/807\/revisions\/917"}],"wp:attachment":[{"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/media?parent=807"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/categories?post=807"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/tags?post=807"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}