Issue Tracker für Discourse

Entwickler
1

Die Diskussion wird fortgesetzt von Tickets Plugin :tickets::

Ich suche nach einer Möglichkeit, entweder etwas wie das Tickets Plugin zu verwenden oder mich mit Forgejos Issue Tracker und Discourse zu integrieren. Vielleicht wäre letzteres einfacher?

Bei der Beantwortung dieses Themas bitte bedenken Sie, dass die Idee nicht darin besteht, eine einmalige Lösung zu schaffen, sondern einen interessanten Ansatz für die Open-Source-Community zu bieten, um sich mit Entwicklungswerkzeugen außerhalb von Github zu integrieren. Forgejo hat Vorrang, da es zur ersten Wahl außerhalb von Github und Gitlab geworden ist, z. B. auf Codeberg.org. Aber man könnte auch SourceHut in Betracht ziehen, da es ein hervorragendes Frontend für diese minimalistische, E-Mail-basierte Forge für Hacker wäre.

Ursprünglich wollte ich dieses Thema im Marketplace platzieren, da ich jemanden suchte, der das Tickets-Plugin übernimmt, aber ich erkenne, dass vorher eine Diskussion stattfinden muss, bevor dies geschehen kann.

Insbesondere möchte ich wissen, wie Sie Discourse in Kombination mit oder als Ersatz für Ihre Code-Forge oder Ihren Projektmanagement-Issue-Tracker verwenden. Feedback vom Discourse-Team ist willkommen!

1 „Gefällt mir“
2

Ein anderer Ansatz wäre die Entwicklung eines Systems, das das Assign Plugin verwendet. Ich denke, das könnte die meisten Kriterien eines Issue Trackers oder Ticketsystems erfüllen.

Wahrscheinlich weiß niemand mehr darüber als sie.

3

Ja, die Erweiterung oder Verwendung des Assign-Plugins könnte nützlich sein. Da @angus anderweitig beschäftigt ist, wollte ich auch das Wasser testen und sehen, ob jemand daran interessiert ist, solche Arbeiten durchzuführen. Mit den noch laufenden NGI Zero-Zuschüssen könnten dies finanzierte Arbeiten sein.

4

Pavilion kann neue Projekte annehmen.

Wir benötigen lediglich Folgendes:

  • eine Funktionsspezifikation
  • Finanzierung
  • einen Vertrag

:slight_smile:

2 „Gefällt mir“
5

Glauben Sie, es wäre besser, auf Tickets, auf Zuweisungen zu bauen oder etwas anderes zu tun?

6

Haben wir eine funktionale Spezifikation?

Wenn nicht, lasst uns zuerst diese erstellen!

1 „Gefällt mir“
7

Ich habe einen ähnlichen Vorschlag bei Forgejo eingereicht, da sie eine Diskussion darüber führen, wie das Issue-Tracking als Diskussionsraum genutzt werden kann. Ich denke, eine Discourse-Integration würde das Beste aus beiden Welten vereinen.

Aus dem Stegreif wäre eine funktionale Spezifikation:

  • Unterstützung mehrerer Repositories
    • (vielleicht mehrere Organisationen)
  • Automatische Erstellung von Themen, wenn Issues erstellt werden
    • (vielleicht beschränkt auf Issues, die als Diskussion markiert sind)
  • Automatische Erstellung eines Issues, wenn ein markiertes Thema erstellt wird
    • (vielleicht als Ticket)
  • Integration von Remote-Benutzern entweder über SSO (z. B. Oauth2) oder ActivityPub (wenn das ActivityPub-Plugin vorhanden ist)
  • Bereitstellung eines einfachen Dashboards in Discourse
    • mit Filterfunktionen
    • vielleicht mit Kanban-Unterstützung

Natürlich würde dies etwas mehr Diskussion und Verfeinerung erfordern, bevor wir zu einem geeigneten Projekt gelangen können.

3 „Gefällt mir“
8

Oh! Ich habe gerade Using discourse to track issues? gepostet, weil ich dachte, das gäbe es schon.\n\nIch wäre bereit, meine Discourse-Instanz zu nutzen, um Ideen oder Vorschläge zu prototypisieren.

9

Wenn Sie Budget haben, sollten Sie im Marketplace posten.

10

Danke, guter Vorschlag.

Da das Projekt seit langem Probleme mit langwierigen Diskussionsfäden hat, werde ich in meinem Discourse-Server einige Kategorien und Themen erstellen und uns die Möglichkeit geben, einige Zyklen durchzuarbeiten, damit wir die Anforderungen identifizieren können.

1 „Gefällt mir“
11

Klingt nach einem guten Ansatz :+1:

12

Gibt es Fortschritte bei diesem Thema?
Das Tickets-Plugin scheint ins Stocken geraten zu sein und weist einige kleine Fehler auf, die ohne gezieltere Eingriffe unwahrscheinlich behoben werden. Dennoch bin ich mehr daran interessiert, Webhooks zu verwenden und die Integration mit Forgejo vorzunehmen, da dies der Zweck ist und die Codeintegration unterstützt. Aber sowohl die Discourse- als auch die Forgejo-Community scheinen den Vorschlag ignoriert zu haben. :person_shrugging:
@blaisep, haben Sie eine geeignete Lösung für Ihren Fall gefunden?

1 „Gefällt mir“
13

Ich habe

erstellt, das komplexe menschliche Arbeitsabläufe und Burn-Down-Statistiken ermöglicht.

2 „Gefällt mir“
14

Wir sind auf eine Reihe von Konflikten auf OSI-Ebene 9 (Politik) gestoßen, daher haben wir keine Fortschritte gemacht. Dennoch werde ich mir die Links von @merefield ( :bow: ) mit großem Interesse ansehen, denn bisher scheint er es wirklich verstanden zu haben.

In anderen Nachrichten gibt die #fedora-Community ihre Forge auf und prüft portable Möglichkeiten, Workflows in den Git-Host der Wahl (forgejo, codeberg usw.) zu integrieren. Es gibt ein großes Interesse daran, die Abhängigkeit von github.com aus Gründen zu reduzieren.

1 „Gefällt mir“