Atlassian JIRA (Projektmanagement-Suite)

Ich habe Atlassian JIRA auf unserem OSEG-Server installiert und konfiguriert sowie eine Evaluierungslizenz erworben. Wenn es uns zusagt, können wir nach Ablauf der Testphase eine kostenlose Open-Source-Lizenz beantragen.

Jeder kann sich hier registrieren und anmelden:
http://opensourceecology.de:8080

Fühlen Sie sich frei, Projekte, Bugs und Ähnliches hinzuzufügen.

Shure

Großartig! Danke!

Bis wann ist die Evaluierungslizenz gültig?

30 Tage ab gestern.

Hallo, wie ist es ausgegangen? Oder sollen wir uns für eine Open-Source-Entwicklung entscheiden? Nicht

Ich weiß nicht, ob ich wirklich ein Projektmanagement-Tool brauche. Wer soll all diese Informationen eingeben? Das ist eine Menge Arbeit … Zeit, die wir in die Entwicklung investieren könnten. :mrgreen:

Ansonsten habe ich das hier gefunden:
Dieses aus dieser Liste (siehe *) sieht nach einem (nützlichen? aber wahrscheinlich überladenen?) Tool aus:
http://www.libreplan.com/features/
Demo: http://demo.libreplan.org/libreplan/planner/index.zul (extrem langsam, oder nur bei mir?)



Blog - Übersichten

Es gibt keine aktive kollaborative Entwicklung ohne die fortlaufende Dokumentation und Zusammenarbeit in einem Projektmanagementsystem :neutral_face:
Im Moment gibt es GitHub, MediaWiki, Etherpad, Trello, dieses Forum, Mailinglisten und so weiter. Es gibt immer noch keine einfache Standardlösung für die kollaborative Entwicklung bei OSEG. Ich würde ein Ticketsystem für jeglichen Support und E-Mail-Angelegenheiten bevorzugen, sowie ein Projektmanagement mit Versionierung. Letzteres ist derzeit GitHub.

Jira wurde nicht viel genutzt und ist auf dem Server nicht mehr aktiv. Zumindest für den Moment würde ich es sogar bevorzugen, Git mit Issue-Tracking zu verwenden, anstatt einer ausgewachsenen Projektmanagement-Suite.

Danke für den Input zu den Alternativen!

Du hast recht, ich bevorzuge auch ein Ticketsystem wie Trac. Was mich am meisten beeindruckt hat, ist die wirklich gute Integration ihres SVN- und Git-Repositorys in 0 A.D. Oh warte, ich möchte unsere Entwickler nicht an 0 A.D. verlieren, bitte verlasst uns nicht, … ich möchte nur ihr Trac-System als Beispiel verwenden.


Ich mag ihr Trac-Tool-Setup (wir haben es auch an der Universität verwendet, aber dort sieht es nicht so überzeugend aus). Die Forenintegration ist immer noch nicht perfekt, aber sie ist zumindest ein wenig in das Forum integriert (z. B. wird der Ticketstatus auch im Forum angezeigt, wenn ein Ticket dort zitiert wird, alles automatisch ohne Benutzereingabe). Der Informationsverlust in den Datenmassen des Forums ist jedoch immer noch ein Problem.

Generell hätte ich in einem Forum gerne eine Zusammenfassungsseite für jeden Thread, aber den ersten Beitrag dafür zu nutzen – obwohl möglich – ist keine gute Idee, da der erste Beitrag HTML- und Wiki-Tags erlauben sollte und ich nicht weiß, ob das möglich ist (noch zu klären) … Wenn nicht, könnten entweder nur Administratoren und Moderatoren neue Threads/Themen erstellen, da nur sie die Rechte für HTML und Wikitags haben (diese Hierarchie mag ich ohnehin nicht), oder die Moderatoren müssen HTML- und Wikicodes für jedes neue Thema aktivieren – ein ziemlich hoher Arbeitsaufwand. :confused:

Ich weiß, es gibt die Möglichkeit, ein kleines Textfeld einzufügen, das für alle Benutzer bearbeitbar ist und Wiki-Tags erlaubt … aber ich bin immer noch nicht dazu gekommen, es umzusetzen (über PHP-Templates). … ja … nun ja, warum? Ich weiß es nicht wirklich, vielleicht bin ich einfach nicht gut genug. :wink:

Wenn das funktioniert, wäre das die Lösung für das Foren-Chaos, das man überall im Web sieht (sogar auf microcontroller.net).

Das Trac-/Ticketsystem, das selbst die Versionierung der Entwicklerdateien integriert, bietet eine einfache Möglichkeit, alle Änderungen an jedem beliebigen Element anzuzeigen, indem man auf dieses Symbol klickt

, wenn man diese Beispiel-Übersichtsseite für Änderungen erreicht. Beachte, dass dies natürlich keine Frage von Git vs. SVN vs. Mercurial vs. Bazar ist. Es geht um die Ticket-Integration. Zum Beispiel werden die gelösten Tickets automatisch durchgestrichen. Jedes Mitglied kann den Ticketstatus frei ändern und Antworten posten. Ich finde das ziemlich cool.)

Ich habe auch einen Monolog über die Wiki-Entwicklerseiten-Integration geschrieben und hoffe, dass daraus eine hitzige Diskussion entsteht: ( :
https://discourse.test.opensourceecology.de/t/sollte-das-wiki-entwicklerseiten-spiegeln/504/1

Ein weiterer Vorteil von Trac gegenüber Bazaar/Launchpad ist, dass die Suchfunktion offensichtlicher ist. Bei Bazaar/Launchpad habe ich den Eindruck, dass zunächst alles versteckt wirkt (siehe zum Beispiel die fehlende oder schwer zu findende Suchfunktion) und sie oft einen vertikalen statt eines horizontalen Ansatzes verfolgen. Das mag natürlich für Android-Geräte und Ähnliches ein Vorteil sein, aber ich mag das kompakte Design von Trac in der Datei-Browser-Ansicht. Bazaar ist natürlich online… während Trac auf einem Server oder Webspace installiert werden muss (wenn ich das richtig verstehe), und ich bin mir nicht sicher, ob wir das wollen. Ich habe auch keine Ahnung von der Funktionalität des in Trac integrierten Wikis. Unsere Wiki-Style-Engine auf Trac umzustellen, ist eine wichtige Funktion, die wir benötigen, da Tony und seine Kollegen bereits viel Arbeit mit unseren Websites hatten.

Ich weiß derzeit auch nicht, wie man Forum und Trac-System kombinieren kann und wie man es ermöglicht, ein Konto für alle unsere Seiten zu verwenden. Derzeit haben wir Wiki-, Forum- und Blog-Konten getrennt…

Eine Sache, die ich mich derzeit frage, ist, wie wir idealerweise mit Excel/Tabellenkalkulationen im Zusammenhang mit dem Single-Source-Prinzip umgehen könnten und sollten. Bei der Entwicklung von „buildtheenterprise“ verwenden wir Google-gehostete Tabellen, aber ich glaube nicht, dass das perfekt ist, denn wenn wir aus den Parametern in unseren Tabellen ein Modell erstellen wollen, müssen wir die Google-Seiten parsen. Und das ist keine gute Idee. Vor allem ist es sehr wartungs- und traffic-intensiv, da Dinge leicht kaputtgehen. Wenn jemand eine gute Lösung dafür kennt, lassen Sie es uns bitte wissen.

Wir könnten natürlich versuchen, ODF (Open Document Format, zu lesen: OpenLibreOffice) Tabellen direkt zu manipulieren. Das ist derzeit unsere beste Option, und ich könnte es mit JAVA Server Pages tun, ohne von einer laufenden Open/LibreOffice-Instanz abhängig zu sein oder diese installiert haben zu müssen. Für die automatische Konvertierung in PDF wäre es natürlich gut, LibreOffice installiert zu haben. Ich kenne nur die PDF-Erstellung von DOCX/XLS-Dateien, die keine Programm-Instanz verwendet. Für ODF/ODS habe ich derzeit keine alternative Idee, aber ist es ein Problem, LibreOffice auf dem Server installiert zu haben – ich denke nicht.

Sobald wir ein PDF haben, könnten wir sogar Diagramme aus der Tabelle extrahieren und sie direkt auf der Wiki-Seite spiegeln, um die Ergebnisse der neuen Parameter fast in Echtzeit anzuzeigen. Alternativ könnten wir einfach HTML5 / Javascript d3.js direkt für die Erstellung der Vorschau verwenden, aber das würde eine Menge Code-Anpassung für jedes Diagramm erfordern.

Sie sehen, ich bin etwas unschlüssig, welchen Ansatz ich wählen soll. Die Gesamtstrategie, die ich derzeit bevorzuge, ist jedoch:

  1. Ableitung grundlegender Anforderungen/Max-Min-Werte aus physikalischen Überlegungen (nur die, die w i r k l i c h benötigt werden).
  2. Generierung eines 3D-Modells aus diesen Anforderungen. Am besten durch die Verwendung eines Generator-Addons in Blender.
  3. Konstruktion der Details im Single-Source-3D-Modell nach Spezifikation und in Originalgröße.
  4. Generierung von Dokumentation, Stückliste (BOM) sowie physikalischen Größen und Einschränkungen aus diesem Modell. Außerdem automatische Berechnung der endgültigen Masse und Trägheit.
  5. Rendering des FEM-Analyseergebnisses.
  6. Generierung von Fertigungsdateien.

Ist Atlassian JIRA Open Source? Ist es eine gute Wahl? Ich teile Ihre Meinung, dass wir unsere Bemühungen bündeln sollten.