Zum Inhalt springen
OTOBO Community Guide

Contributing im OTOBO Open-Source-Projekt

OTOBO ist Open Source unter der GitHub-Organisation RotherOSS (https://github.com/RotherOSS/otobo). Wenn du Bugs melden oder eigenen Code beisteuern willst, folge diesem Workflow:

1. GitHub-Workflow

Abschnitt betitelt „1. GitHub-Workflow“

1.1 Fork & Clone

Abschnitt betitelt „1.1 Fork & Clone“
  1. Lege dir einen Fork von https://github.com/RotherOSS/otobo an.
  2. Klone dein Fork lokal:
    Terminal-Fenster
    git clone https://github.com/<dein-user>/otobo.git
    cd otobo

1.2 Branching

Abschnitt betitelt „1.2 Branching“

Erstelle für jede Änderung einen neuen Branch:

Terminal-Fenster
git checkout -b feature/<kurze-beschreibung>

Beispiel:

Terminal-Fenster
git checkout -b feature/add-hello-world-module

1.3 Commit & Push

Abschnitt betitelt „1.3 Commit & Push“

  1. Implementiere deinen Code.

  2. Füge sinnvolle Commit-Messages hinzu:

    Terminal-Fenster
    git add .
    git commit -m "Adds HelloWorld module with basic functionality"

  3. Push deinen Branch:

    Terminal-Fenster
    git push origin feature/add-hello-world-module

1.4 Pull Request

Abschnitt betitelt „1.4 Pull Request“
  1. Öffne deinen Fork auf GitHub.
  2. Klick auf Compare & pull request.
  3. Beschreibe im PR-Text kurz, was dein Feature/Bugfix macht und warum es wichtig ist.
  4. Wähle den richtigen Ziel-Branch (meist master oder development).

2. Code Style & Tests

Abschnitt betitelt „2. Code Style & Tests“

2.1 CodePolicy

Abschnitt betitelt „2.1 CodePolicy“

RotherOSS nutzt das Tool CodePolicy (https://github.com/RotherOSS/CodePolicy), um Coding-Standards zu prüfen.

  • Installation:

    Terminal-Fenster
    cpanm CodePolicy

  • Ausführen im Repo-Root:

    Terminal-Fenster
    CodePolicy --check .

2.2 Perl-Module & POD

Abschnitt betitelt „2.2 Perl-Module & POD“
  • Jedes Kernel::System::* und Kernel::Modules::* Modul muss POD-Dokumentation enthalten.
  • Deklariere Abhängigkeiten in our @ObjectDependencies.
  • Achte auf use strict; use warnings;.

2.3 Unit-Tests

Abschnitt betitelt „2.3 Unit-Tests“

OTOBO benutzt Mojolicious-Tests und [Test::More]. Lege deine Tests in t/ ab:

Terminal-Fenster
prove -l t/MyModule.t

3. Issue-Management & Reviews

Abschnitt betitelt „3. Issue-Management & Reviews“

3.1 Issues öffnen

Abschnitt betitelt „3.1 Issues öffnen“
  • Suche zuerst nach bestehenden Issues.
  • Erstelle ein Issue mit Titel, Reproduktions-Schritten, Logs und Screenshots (falls nötig).

3.2 Labels & Templates

Abschnitt betitelt „3.2 Labels & Templates“
  • Nutze die Labels bug, enhancement, question.
  • Folge den Issue- und PR-Templates im Repo.

3.3 Code Reviews

Abschnitt betitelt „3.3 Code Reviews“
  • Reagiere zeitnah auf Review-Kommentare im PR.
  • Ergänze Tests oder ändere Stil, wenn Reviewer es vorschlagen.
  • Nach Approval wird dein PR gemerged.

4. Community & Support

Abschnitt betitelt „4. Community & Support“

Viel Erfolg beim Mitgestalten von OTOBO!

Häufig gestellte Fragen

Wo finde ich den offiziellen OTOBO-Quellcode und wie fange ich mit der Entwicklung an?

Der OTOBO-Quellcode wird aktiv unter der GitHub-Organisation RotherOSS auf https://github.com/RotherOSS/otobo entwickelt und gepflegt. Um mit der Entwicklung zu beginnen, solltest du zunächst einen Fork dieses Haupt-Repositories auf deinem eigenen GitHub-Konto erstellen. Anschließend klonst du diesen Fork lokal auf deinen Rechner. Dies ermöglicht es dir, Änderungen vorzunehmen, ohne direkt das Haupt-Repository zu beeinflussen, und bereitet dich darauf vor, deine Beiträge später über einen Pull Request einzureichen. Die RotherOSS-Organisation ist der zentrale Punkt für alle OTOBO-Entwicklungsaktivitäten.

Wie ist der empfohlene GitHub-Workflow, um Code-Änderungen für OTOBO einzureichen?

Der empfohlene Workflow beginnt mit dem Forken des RotherOSS/otobo-Repositories und dem lokalen Klonen deines Forks. Für jede neue Funktion oder Fehlerbehebung solltest du einen neuen Branch erstellen, zum Beispiel feature/kurze-beschreibung. Nachdem du deine Änderungen implementiert hast, fügst du sie mit git add . hinzu und erstellst aussagekräftige Commits mit git commit -m "Deine Commit-Nachricht". Anschließend pushst du deinen Branch auf deinen Fork. Der letzte Schritt ist das Öffnen eines Pull Requests (PR) auf GitHub, in dem du deine Änderungen beschreibst und den richtigen Ziel-Branch (meist master oder development) auswählst. Achte darauf, dass deine Commit-Nachrichten prägnant und informativ sind, um den Review-Prozess zu erleichtern.

Welche Coding-Standards und Best Practices gelten für die Entwicklung von OTOBO-Modulen?

Für OTOBO gelten strenge Coding-Standards, die durch das Tool CodePolicy (https://github.com/RotherOSS/CodePolicy) geprüft werden. Es wird empfohlen, CodePolicy lokal zu installieren (cpanm CodePolicy) und regelmäßig im Repo-Root mit CodePolicy --check . auszuführen. Insbesondere müssen Perl-Module wie Kernel::System::* und Kernel::Modules::* eine vollständige POD-Dokumentation enthalten, um die Verständlichkeit und Wartbarkeit zu gewährleisten. Zudem ist es obligatorisch, alle Objekt-Abhängigkeiten in our @ObjectDependencies zu deklarieren. Die Verwendung von use strict; und use warnings; am Anfang jedes Perl-Moduls ist ebenfalls eine Best Practice, um potenzielle Fehler frühzeitig zu erkennen und die Codequalität zu sichern.

Wie erstelle und führe ich Unit-Tests für meine OTOBO-Code-Änderungen aus?

OTOBO nutzt für seine Unit-Tests eine Kombination aus Mojolicious-Tests und dem Test::More-Framework. Wenn du Code-Änderungen vornimmst, ist es wichtig, entsprechende Tests zu erstellen oder bestehende Tests zu aktualisieren, um die Funktionalität und Stabilität deiner Beiträge zu gewährleisten. Deine Testdateien sollten im Verzeichnis t/ des OTOBO-Repositories abgelegt werden. Um einen spezifischen Test auszuführen, kannst du den prove-Befehl verwenden, zum Beispiel prove -l t/MyModule.t. Dies hilft dir, sicherzustellen, dass dein Code wie erwartet funktioniert und keine Regressionen einführt. Gut geschriebene Tests sind ein entscheidender Bestandteil des Entwicklungsprozesses und tragen zur hohen Qualität von OTOBO bei.

Was muss ich beim Erstellen eines Issues oder Pull Requests beachten und wie läuft der Review-Prozess ab?

Bevor du ein neues Issue erstellst, solltest du immer zuerst nach bestehenden Issues suchen, um Duplikate zu vermeiden. Beim Erstellen eines Issues ist es wichtig, einen aussagekräftigen Titel, detaillierte Reproduktionsschritte, relevante Logs und bei Bedarf Screenshots bereitzustellen. Nutze die im Repository vorhandenen Issue- und PR-Templates sowie die Labels bug, enhancement oder question. Im Rahmen des Code-Reviews für Pull Requests ist es entscheidend, zeitnah auf Kommentare der Reviewer zu reagieren. Sei bereit, Tests zu ergänzen oder den Stil deines Codes anzupassen, wenn dies vorgeschlagen wird. Erst nach einer erfolgreichen Überprüfung und Genehmigung (Approval) wird dein Pull Request in den Ziel-Branch gemerged. Eine gute Kommunikation und Kooperation sind hierbei der Schlüssel zum Erfolg.

Wo finde ich weitere Unterstützung und Community-Ressourcen für OTOBO-Entwickler?

Für OTOBO-Entwickler gibt es verschiedene Kanäle, um Unterstützung zu erhalten und sich mit der Community auszutauschen. Eine zentrale Anlaufstelle sind die GitHub Discussions unter https://github.com/RotherOSS/otobo/discussions, wo du Fragen stellen, Ideen diskutieren und Feedback erhalten kannst. Darüber hinaus findest du Links zu Mailinglisten und Chat-Möglichkeiten auf der offiziellen OTOBO-Website https://otobo.com/ im Bereich „Community“. Für umfassende technische Informationen und Anleitungen ist die zentrale OTOBO-Dokumentation unter https://doc.otobo.org/ die erste Adresse, insbesondere der Bereich „How to Contribute“ in den Developer-Docs. Diese Ressourcen sind unerlässlich, um effektiv zum OTOBO-Projekt beizutragen und auf dem Laufenden zu bleiben.