ich habe vor einiger Zeit einen Bug im Issue Tracker gemeldet, der jetzt als „not scheduled“ gelabelt wurde.
Ich weiß, dass einige Issues pro Tag eingehen und es viel Arbeit ist, das zu verwalten, aber könnte man wenigstens einen kurzen Satz dazu schreiben, wie es zu der Entscheidung kam? Ich mein, in dem speziellen Fall ist der komplette Produktexport nutzlos, weil er nicht richtig funktioniert. Wurde das in einer neueren Version behoben?
Außerdem finde ich die Formulierung „Wenn sich mehrere Kunden für die Umsetzung aussprechen (bspw. über die Vote-Funktion oder über Support-Tickets)…“ bei Bugs etwas unglücklich. Ich mein, bei Feature-Wünschen kann ich es verstehen, dass hier nach User-Votes entschieden wird, aber bei Fehlern in der Software? Sollten die nicht grundsätzlich behoben werden und nicht nur, wenn gerade mal zufällig keine anderen Fehler mehr vorhanden sind oder es ein paar mehr Leuten auffällt, dass es bei ihnen auch nicht funktioniert?
Wie gesagt, ein Satz würde schon viel weiterhelfen („Wurde in Version XY behoben“, „Wird nicht behoben, weil…“).
Ich denke man muss hier grundsätzlich etwas klar stellen. Es wird niemals eine Software geben die fehlerfrei ist, somit muss es zwangsweise eine Priorisierung der eingehenden Tickets geben, denn es kann schlichtweg nicht jeder Bug gefixt werden. Du hast ja schon selbst gesagt, dass jede Woche unmengen von Tickets reinkommen, daher kann auch ein Bugfix durchaus nicht für eine kurzfristige Umsetzung eingeplant sein.
Natürlich schauen wir die Tickets regelmäßig durch und beheben zunächst die Dinge, die auch am häufigsten bei uns aufkommen (das Screening ist hier ziemlich breit: Support, Forum, SocialMedia, Issuetracker, Hotline,…). Aber auch hier muss man natürlich den Aufwand in Relation stellen. Es gibt Bugtickets die schnell umgesetzt sind und auch in ein kleineres Release können und es gibt große Tickets die auch eine Erweiterung der aktuellen Funktion voraussetzen. Nicht jedes Ticket hat den gleichen Umfang.
Das Ticket was du speziell ansprichst, ist vom Umfang her so aufwendig, dass dieses Thema wahrscheinlich erst nach der kompletten Refaktorierung der Frontend-Preisberechnung erfolgen wird. Entsprechend sind wir hier sicherlich noch einige Monate weiter (= Not Scheduled). Eine Umsetzung auf derzeitiger Basis würde eher mehr Probleme schaffen als zu beheben. Hintergrund ist hier, dass es in Shopware aktuell keine zentrale Stelle zur Preisberechnung gibt, sondern jedes Modul versucht die Logik im Frotnend nachzubilden. Hier muss zunächst eine gemeinsame Basis geschaffen werden. Sonst läufst du bspw. in Probleme, dass die Export-Preise sich von den Detailseiten-Preisen im Cent-Bereich unterscheiden können.
Wir haben die Ausgabe der Beschreibungen ja erst kürzlich im Issuetracker angepasst, damit man mit den einzelnen Zuständen (Status) des Tickets mehr anfangen kann. Ggf. wird es hier auch in Zukunft noch weitere Optimierungen geben.